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>
Don Slice [Thu, 26 Jan 2017 20:49:00 +0000 (12:49 -0800)]
zebra: pass correct parameters to remove static routes with tags
Problem found in testing where certain "no ip route ... tag x" commands
would fail. This was due to a change in tag processing where the tag
value is validated and previously some of the parameters were passed
incorrectly. This caused the validation to fail. This change ensures
the correct parameters are passed for evaluation as tags. Manual testing
completed and the previously failing test now passes. bgp and ospf smoke
tests will also be performed before pushing.
Ticket: CM-14605 Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: CCR-5627
Dinesh G Dutt [Wed, 25 Jan 2017 19:55:02 +0000 (11:55 -0800)]
tools: Silly typo in regex for catching ip route syntax
Ticket: CM-14600
Reviewed By: CCR-5615
Testing Done: Verifying the issue with/without the fix
I had intended the regexp to catch both ip and ipv6 routes, but somewhere
along the way, I left out the grouping in the regexp to catch if it was
ip or ipv6 at the start. This caused all the rest of the matches and replaces
to be off causing the issue reported by the bug.
Don Slice [Fri, 13 Jan 2017 19:23:03 +0000 (11:23 -0800)]
zebra: send ipv4 singlepath delete messages to kernel without nexthop
Problem reported was stale routes left in the kernel in certain cases
when overlapping static routes were used and links were bounced. The
problem was determined to be an issue where the nexthop was changed
due to recursion as the link is going down, and the next-hop at the
time of deletion doesn't match what was previously installed by the
kernel. This caused the kernel to reject the deletion and the route
stuck around.
It was pointed out that the kernel doesn't actually require a next-hop
value on the netlink deletion call. In this fix, we are eliminating
the nexthop for RTM_DELROUTE messages to the kernel in the ipv4 singlepath
case. This approach could also be valid for other cases but the fix
as is resolved the reported failure case. More testing should be
performed before similar changes are made for other cases.
Testing included manual testing for the failure condition as well as
complete bgp-smoke and ospf-smoke tests with no new failures.
Ticket: CM-13328 Signed-off-by: Don Slice <dslice@cumulusnetworks.com> Reviewed-by: CCR-5562
radhika [Thu, 19 Jan 2017 22:23:21 +0000 (14:23 -0800)]
bgpd: Update BFD status when de-registering with PTM
Ticket: CM-14301
Reviewed By: Donald, Vivek
Testing Done: Unit, Min tests, PTM and BFD Smoke, BGP Smoke
Issue: BFD status is not changed from up to down for bgp peer even after the BFD session has been de-registered by bgpd.
Root Cause: This issue happens when bgpd detects peer down before getting the BFD down from PTM. bgpd will send the de-reg bfd session message to ptm after detecting peer down. If ptm receives the de-reg message before it detects the peer down, then the down message will not be sent to Quagga. This causes the bfd status in bgpd to remain unchanged.
Fix: Update the BFD status to down in bgpd before de-registering the session from PTM.
The JSON output of 'bgp neighbor show' lacked the decoded strings for
the last notification error code/subcode. Decoding these strings outside
quagga is painful, and then needs to match with any updates to the codes
from RFCs/drafts. Further, all apps that look to understanding this need
to then add their own decoders for these strings.
Just add the decoded strings to the JSON output as well. JSON key name
for this is 'lastNotificationReason'.
'ip route show' displays all routes as belonging to protocol zebra.
The user has to run an additional command (in vtysh) to get the actual
source of a route (bgp/ospf/static etc.). This patch addresses that by
pushing the appropriate protocol string into the protocol field of the
netlink route update message. Now you can see routes with the correct
origin as well as filter on them (ip route show proto ospf).
'ospf' is used for both IPv4 and IPv6 routes, even though the OSPF
version is different in both cases.
Sample output (old):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto zebra metric 20
9.9.13.3 proto zebra metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
Sample output (new):
9.9.12.13 via 69.254.2.38 dev swp3.2 proto bgp metric 20
9.9.13.3 proto bgp metric 20
nexthop via 69.254.2.30 dev swp1.2 weight 1
nexthop via 69.254.2.34 dev swp2.2 weight 1
nexthop via 69.254.2.38 dev swp3.2 weight 1
projects / mirror / frr.git / log