Donald Sharp [Fri, 10 Mar 2017 00:37:23 +0000 (19:37 -0500)]
zebra: Fix specific prefix handling
Suppose we are handling the process_workq and either a new static
route is installed or a Routing Protocol installs a new route.
We will call evaluate_rnh with a specific prefix. We might
have a situation where we clear the NHC flag prematurely.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The patch actually made the situation worse since the return value from
cmd_complete_command_real() was now inconsistently allocated from
different memory stat pools.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Tue, 7 Mar 2017 20:13:04 +0000 (15:13 -0500)]
zebra: Notify all nexthops that we've changed
Zebra when it was scanning the tree would unset NEXTHOPS_CHANGED
after the first notification. If the route we are notifying because
of covers multiple interesting nexthops then we would be unable
to know that we need to notify for that one as well because of
the flag removal.
Ticket: CM-15157 Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 2 Mar 2017 01:26:06 +0000 (20:26 -0500)]
bgpd: Fix memory leaks on shutdown
The original code on shutdown assumed a 'forced' mode
if there was no process_main_queue. This construct
was violated by commit 2e02b9b2d1ed29975001d6917f9f726854ec5559
due to not fully understanding the shutdown process.
If we are shutting down, don't store work to do later,
just gracefully don't do it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Quentin Young [Fri, 17 Feb 2017 18:19:27 +0000 (18:19 +0000)]
*: remove QUAGGA_NO_DEPRECATED_INTERFACES
This define is used only to guard macros in lib/linklist.h which
themselves are not used anywhere in the codebase and have been marked
deprecated since anno domini 2005
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Christian Franke [Thu, 23 Feb 2017 13:27:00 +0000 (14:27 +0100)]
bgpd: fix bgp_info_addpath_{rx,tx}_str if addpath info is not present
The buffer needs to be set to length 0 if nothing is written into
it, otherwise bgpd will log uninitialized memory, disclosing information
and possibly leading to a crash.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Renato Westphal [Wed, 14 Dec 2016 19:39:28 +0000 (17:39 -0200)]
ldpd: use red-black trees to store 'adj' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 15:53:07 +0000 (13:53 -0200)]
ldpd: use red-black trees to store 'l2vpn_pw' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 14:34:57 +0000 (12:34 -0200)]
ldpd: use red-black trees to store 'l2vpn_if' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 12:42:45 +0000 (10:42 -0200)]
ldpd: use red-black trees to store 'l2vpn' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Wed, 14 Dec 2016 11:14:52 +0000 (09:14 -0200)]
ldpd: use red-black trees to store 'nbr_params' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Tue, 13 Dec 2016 18:19:15 +0000 (16:19 -0200)]
ldpd: use red-black trees to store 'tnbr' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Tue, 13 Dec 2016 17:29:35 +0000 (15:29 -0200)]
ldpd: use red-black trees to store 'iface' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Renato Westphal [Sat, 3 Dec 2016 23:14:44 +0000 (21:14 -0200)]
ldpd: use red-black trees to store 'lde_map' elements
Using red-black trees instead of linked lists brings the following
benefits:
1 - Elements are naturally ordered (no need to reorder anything before
outputting data to the user);
2 - Faster lookups/deletes: O(log n) time complexity against O(n).
The insert operation with red-black trees is more expensive though,
but that's not a big issue since lookups are much more frequent.
Martin Winter [Fri, 3 Feb 2017 16:05:11 +0000 (23:05 +0700)]
ospfd: CID 1399387 (#1 of 2): Destination buffer too small (STRING_OVERFLOW)
Coverity: string_overflow: You might overrun the 100-character destination string vty_path by writing 4096 characters from vty_sock_path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Martin Winter [Fri, 10 Feb 2017 09:51:57 +0000 (16:51 +0700)]
vtysh: Fix Coverity Warning CID 1399479 (#1 of 1): Destination buffer too small (BUFFER_SIZE)
Coverity: buffer_size: You might overrun the 108 byte destination string addr.sun_path by writing the maximum 4095 bytes from path. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
Martin Winter [Fri, 3 Feb 2017 11:09:36 +0000 (18:09 +0700)]
ospfd: Fix Coverity Warning CID 1399480 (#1 of 1): Buffer not null terminated (BUFFER_SIZE_WARNING)
Coverity: buffer_size_warning: Calling strncpy with a maximum size argument of 100 bytes on destination array pid_file of size 100 bytes might leave the destination string unterminated. Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
David Lamparter [Thu, 9 Feb 2017 11:59:44 +0000 (12:59 +0100)]
ospfclient: #include sources
Pulling in source files from another directory breaks automake's
distclean target, and there seems to be no good fix for this...
(particularly since we need -fPIC build for a DSO here, while ospfd
compiles for an executable...)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
David Lamparter [Tue, 24 Jan 2017 20:35:08 +0000 (21:35 +0100)]
ospfd: isolate ospfapiclient lib from ospf lib
The OSPF API-client library doesn't really use anything from libospf
except some small dumping tools. Isolate these into a separate file
and detangle the ospfapiclient library.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Donald Sharp [Wed, 1 Feb 2017 15:31:40 +0000 (10:31 -0500)]
bgpd: Allow views to 'pretend' resolve nexthops
Views are supposed to be independent tables that have no connection to
routing tables. Since View's are 'independent' there is no way to do
'real' nexthop resolution since connected routes and interfaces are
associated with a particular table (or really vrf). So when we have a
bgp instance assume that nexthops specified are actually valid, since we
are propagating what our neighbors are telling us.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
[cherry-picked from master 6fa1ab2eecb39b35256739f7083196d6f556f639] Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
During Discussions with Lou, it was decided that his code
changes would handle this part, and my code changes would
fix up vtysh and bgp to be in sync again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 2 Feb 2017 18:56:56 +0000 (13:56 -0500)]
bgpd: Put back original behavior for some show bgp commands
The behavior of some show commands was switched from
showing the unicast data to all safi data. This
is a change in behavior and needs to be put
back for 2.0
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 2 Feb 2017 18:54:47 +0000 (13:54 -0500)]
bgpd: Allow vtysh to work for address-family
extract.pl.in requires the lines that are ignored
to be consisten with what is in the *.c file
that we are ignoring from, else we get ambiguous
commands.
This allows vtysh to enter address-family sub mode
in bgp again.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
David Lamparter [Wed, 1 Feb 2017 12:40:00 +0000 (13:40 +0100)]
bgpd: clear bgp_master at exit to help valgrind
bgp_master can retain pointers keeping allocated structures "reachable"
in valgrind. Clear to 0 to tell valgrind that everything should've been
freed really.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
projects / mirror / frr.git / log