Donald Sharp [Thu, 3 Sep 2015 13:50:16 +0000 (06:50 -0700)]
Fix neighbor coming up without an as specified
Ticket: CM-7012
Reviwed by: CCR-3451
Testing: See bug
When you specify a neighbor <interface> <something>
and don't specify a remote-as the neighbor relationship
will still come up with ipv6 unnumbered if you have
RA configured on the interface.
Donald Sharp [Wed, 2 Sep 2015 12:19:44 +0000 (05:19 -0700)]
Fix some more memory issues in Quagga
Ticket: CM-4109 Reviewed-by: CCR-3414
Testing: See bug
Fixup of these memory issues:
(A) peer->clear_node_queue was accidently removed. Add back in.
(B) Clean up bm->process_main_queue and bm->process_rsclient_queue initialization
(C) Some memory leaks
(D) Clean up unused threads
Steve Hill [Tue, 28 Jul 2009 20:36:14 +0000 (16:36 -0400)]
lib: Improve error reporting from broken config files
* command.h: (config_from_file) Add variable to interface for line
number reporting.
* command.c: (config_from_file) Set & increment 'line_num' while parsing.
* vty.c: (vty_read_file) Report parse errors in the correct order to
stderr, with added line numbers.
Conflicts:
lib/command.c
lib/vty.c
Integrated in changes made to continue loading code even after failure
to read a line in properly as part of this cherry-pick
Double commit of b76943235e09472ec174edcf7204fc82d27fe966 from br2.5. But, manually resolved all the compilation errors. Also, modified the shows to support the json format which was not supported in br2.5.
CM-6802 – Currently, BFD session status can be monitored only through ptmctl. There is no way to check the BFD status of a peer/neighbor through Quagga. Debugging becomes easier if BFD status is shown in Quagga too. BFD status is relevant when it is shown against the BGP peer/OSPF neighbor. For, this following code changes have been done:
- Only down messages from PTM were being propagated from Zebra daemon to clients (bgpd, ospfd and ospf6d). Now, both up and down messages are redistributed to the clients from zebra. BFD status field has been added to the messaging. Handling of BFD session up messages has been added to the client code. BGP/OSPF neighbor is brought down only if the old BFD session status is ‘Up’ to handle extra/initial down messages.
- BFD status and last update timestamp fields have been added to the common BFD info structure. Also, common show functions for showing BFD information have been added to BFD lib.
- Modified the BGP neighbor show functions to call common BFD lib functions.
- For ospf and ospf6, BFD information was maintained only at interface level. To show BFD status per neighbor, BFD information has been added at neighbor level too. “show ip ospf interface”, “show ip ospf neighbor detail”, “show ipv6 ospf6 interface” and “show ipv6 ospf6 neighbor detail” output have been modified to show BFD information.
CM-6952 - IBGP peers were always assumed to be multi-hop since there was no easy way to determine whether an IBGP peer was single hop or multihop unlike EBGP. But, this is causing problem with IBGP link local peers since BFD doesn't allow multihop BFD session with link local IP addresses. Link local peers were discovered when the interface peering was enabled. Interface peering is always singlehop. So, added checks to treat all interface based peers as single hop irrespective of whether the peer is IBGP or EBGP.
vivek [Sat, 29 Aug 2015 23:10:12 +0000 (16:10 -0700)]
BGP: Fix MD5 authentication for unnumbered neighbors
Ticket: CM-6369
Reviewed By: CCR-3318
Testing Done: Manual testing of various password scenarios.
This is a port of patch bgpd-unnumbered-nbr-fix-password.patch from
2.5-br.
In the case of BGP unnumbered, the peer IP address is derived and not
explicitly configured. If there is a password configured for the peer,
it can be set on the listen socket only after the IP address has been
derived and needs to be cleared when the IP address goes away.
vivek [Sat, 29 Aug 2015 18:40:32 +0000 (11:40 -0700)]
BGP: Handle interface or local address failure
Ticket: CM-6883
Reviewed By: CCR-3272
Testing Done: Tested on 2.5.3-SE-1
This commit is a port of the patch bgpd-handle-peer-local-address-failure.patch
from 2.5-br.
When a peering is being established, the IPv4 and IPv6 addresses of the
local end of the connection, as applicable, are obtained and stored in
the peer's 'nexthop' structure to facilitate filling of the NEXT_HOP
field in Update messages among other things. The process of obtaining the
local address involves examination of the list of interfaces to identify
a match corresponding to the socket address of the connection.
There are timing conditions, especially when BGPD starts with a config,
where the interface may not have reached BGP from Zebra at the time a
peering reaches the state to determine the local addresses. The code does
not handle this well and the result could be Updates generated with bad
(Martian) NEXT_HOP values. Resolve the issue by bringing down the connection
in this case as not identifying the local addresses is really an error.
PTM cable status updates were not being handled in the notification callback registered with the ptm lib. This results in interface ptm status mismatch between PTM and zebra when interface cable check status changes (pass->fail or fail->pass). Zebra requests PTM to send cable status updates using get-status command and PTM sends the cable status updates as command responses to get-status. This was being handled in the commmand response callback registered with ptm lib. But, the subsequent status updates come as notifications and handling of those notifications that was missing in the notification callback. Fixed the issue by making a common callback for command responses and notifications. All the command responses other than the responses to get-status are dropped/ignored.
In the presence of an IPv4 address that is not a /30 or /31 and the user
is trying to use BGP unnumbered, a warning message is printed which
seems confusing to the user. Fixing the warning message to indicate that
its only a v4 session isn't coming up makes it clearer.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Acked-by: Donald Sharp <sharpd@cumulusnetworks.com> Acked-by: Daniel Walton <dwalton@cumulusnetworks.com> Acked-by: Vipin Kumar <vipin@cumulusnetworks.com>
Donald Sharp [Wed, 26 Aug 2015 16:03:30 +0000 (09:03 -0700)]
Fix dynamic sessions with multiple bgp instances
Ticket:CM-6534
Reviewed by:CCR-3239
Testing: See Bug
Dynamic neighbors did not work properly with multiple bgp instances.
This was caused by the lookup for the dynamic range attempting to
break out of two for loops at the same time. The break only stopped
the innermost for loop, causing it to only ever find the listen-range
for the last instance in the bm->bgp list.
Additional bug fix for dynamic listen for peer groups that are configured
with internal or external key word.
Donald Sharp [Wed, 26 Aug 2015 14:44:57 +0000 (07:44 -0700)]
Fixup code to use correct XMALLOC operators
Ticket: CM-7177 Reviewed-by: CCR-3396
Testing: See bug
This code change does several small things:
(A) Fix a couple detected memory leaks
(B) Fix all malloc operations to use the correct XMALLOC operation in bgpd and parts of lib
(C) Adds a few new memory types to make it easier to detect issues
Donald Sharp [Mon, 24 Aug 2015 17:50:21 +0000 (10:50 -0700)]
Fix watchquagga to watch just one daemon
Ticket: CM-6669
Reviewed by: CCR-3249
Testing: See Bug
I believe in the past it made no sense to have only 1 quagga daemon running(zebra),
since it would just handle interface configuration and static routes, both of which
would be better handled through the linux cli.
Now that we have added recursive static routes and the ability to handle static
mpls labels to zebra, there are use cases where zebra would be the only be running.
This change allows watchquagga to behave with this setup.
Morgan Stewart [Fri, 7 Aug 2015 18:16:18 +0000 (11:16 -0700)]
Added json formating support to several show-...-detail ospf commands.
Ticket: CM-6520
Reviewed By: Daniel Walton <dwalton@cumulusnetworks.com>
Reviewed By: Donald Sharp <sharpd@cumulusnetworks.com> Signed-off-By: Morgan Stewart <morgan@cumulusnetworks.com>
Testing Done: Manual testing and smoketested
Whenever some sort of output is encountered, added a json version with
proper logic as well.
Donald Sharp [Fri, 31 Jul 2015 12:53:12 +0000 (05:53 -0700)]
Fix redistribute metric change not taking effect
Ticket: CM-6048 Reviewed-By: CCR-3251
Tested: See bug
When a redistribute metric is changed, the new metric
was not being used. Modify the code to look for existing
redistributed routes and fix their metric.
1. Fix useless call in bgpd/bgp_mplsvpn.c
Coverity scan ID : 1302528. Calling "decode_label(pnt)" is only useful
for its return value, which is
ignored. Removed the call.
2. Fix logically dead code in lib/stream.c
Coverity Scan ID 1302488. Test for size==0 makes no sense, since assert
immediately before it
would not let this code happen.
3. Fix Free Pointer dereference in lib/filter.c
Coverity Scan ID 23056. access is accessed after free in
access_list_delete
Donald Sharp [Wed, 22 Jul 2015 20:07:08 +0000 (13:07 -0700)]
ptm-integration.patch
Integrates Prescriptive Topology Module(ptm) into quagga.
If this module is enabled, link ups are notified only after the link is verified
as being connected to the neighbor specified. The neighbor specification and
checking is done by the ptm daemon.
<This is a recommit of this patch because it was changed in situ>
Donald Sharp [Wed, 22 Jul 2015 19:35:38 +0000 (12:35 -0700)]
bgpd-capability-cleanup.patch
BGP: Make Capability handling a little more robust
This patch does two things:
- Returns the right sub error code when a malformed capability is rcvd
- Verifies that the capability length is a multiple of an individual unit
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 22 Jul 2015 19:35:37 +0000 (12:35 -0700)]
This patch changes ospfd from only listening mode for BFD status updates to interactive mode of dynamically registering/deregistering neighbors discovered on BFD enabled interfaces with PTM/BFD through zebra. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered.
OSPF BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx).
interface <if-name>
ip ospf bfd <detect mult> <min rx> <min tx>
This patch also adds BFD support for IPv6 OSPF. ospf6d will dynamically register/deregister IPv6 neighbors with BFD for monitoring the connectivity of the neighbor. Neighbor is registered with BFD when 2-way adjacency is established and deregistered when adjacency goes down if the BFD is enabled on the interface through which the neighbor was discovered.
OSPF6 BFD command added to configure BFD and parameters (detect multiplier, min rx and min tx).
interface <if-name>
ipv6 ospf6 bfd <detect mult> <min rx> <min tx>
Donald Sharp [Wed, 22 Jul 2015 19:35:37 +0000 (12:35 -0700)]
When IPv6 peer BFD down status is received by BGP, all the the peers for which the BFD is enabled are brought down. This happens due to reverse memcmp check of destination and source IPv6 addresses with the BFD enabled BGP peers. Fixed it by doing the memcmp correctly.
Also, there is no reason stored in the last_reset field when BGP peer goes down due BFD. Incorrect/no peer down reason can get logged when BGP peer goes down due to BFD. Fixed it by adding new BFD peer down reason code and storing it in the peer last_reset field when peer is broght down due to BFD.
Donald Sharp [Wed, 22 Jul 2015 19:35:37 +0000 (12:35 -0700)]
The last BGP peer down reason code "PEER_DOWN_V6ONLY_CHANGE" has no corresponding logging/display string defined in "peer_down_str". This will cause incorrect or empty down reason to get logged when the peer is brought down because of interface based v6only config change.
Donald Sharp [Wed, 22 Jul 2015 19:35:37 +0000 (12:35 -0700)]
bgpd-interface-ipv4-cmd.patch
BGP: Determine peer's IP address if interface has /30, /31
Allow interface-based session config for IPv4 numbered links
if the link address is either /30 or /31. This is not RFC5549,
but can be deployed now, and independent of whether the peer
supports RFC5549 or not.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-By: Vivek Venkataram <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 22 Jul 2015 19:35:36 +0000 (12:35 -0700)]
The MD5 password configured for a BGP peer was incorrectly getting
deleted from the listen socket in some situations. This would lead
to incorrect behavior where a BGP connection from a peer that does
not specify the MD5 option would be accepted.
Donald Sharp [Wed, 22 Jul 2015 19:35:36 +0000 (12:35 -0700)]
watchquagga-mode-3-fix.patch
Watchquagga: In phased restart with zebra, invoke restart all when zebra dies
To correctly handle starting and stopping of individual daemons not affecting
watchquagga's monitoring, we resorted to fixing up watchquagga's daemon watch
list every time a daemon was started or stopped. This was done by restarting
watchquagga itself. This meant the handling of phased restart of individual
daemons was broken in watchquagga as it attempted to stop daemons individually
before starting them all individually. Fix this by restarting all when this
happens. This does make mode 4 indistinguishable from mode 1, but I don't
understood the point of mode 4 and we don't think users change watchquagga
modes.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Donald Sharp [Wed, 22 Jul 2015 19:35:36 +0000 (12:35 -0700)]
Add optional json capability to the "show ip ospf neighbor", "show ip ospf neighbor all", and "show ip ospf neighbor IFNAME" commands and whatever functions that they call.
Donald Sharp [Wed, 22 Jul 2015 19:35:36 +0000 (12:35 -0700)]
Add json capability to the "show ip ospf interface [INTERFACE]" and "show ip ospf <1-65535> interface [INTERFACE]" commands and whatever functions that they call. Option shows up as {json}.
Donald Sharp [Wed, 22 Jul 2015 19:35:35 +0000 (12:35 -0700)]
Add json capability to the ospf commands: "show ip ospf" and "show ip ospf <1-65535>". Optional argument will be {json} and will output a json object with all applicable information.
Donald Sharp [Fri, 12 Jun 2015 14:59:12 +0000 (07:59 -0700)]
bgpd-5549-display-ll-ifname.patch
BGP: Display Link local addr and ifname as part of 5549 support
As part of BGP unnumbered and RFC 5549 support, the implementation will honor the
link local address as the NH if present and so it'd be useful to display that
info along with the interface name, when displaying the BGP route summary. That
is what this patch aims to do.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Donald Sharp [Fri, 12 Jun 2015 14:59:11 +0000 (07:59 -0700)]
BGP: Restart the BGP FSM if update source fails.
For IPv6, update source sometimes fails at the first attempt. If we continue
ignoring the error, some sessions will not come up. If instead we check for
the error and return connect_error, the FSM will reset its state and try again
till the update source bind succeeds and the session will come up.
This patch adds checking for the result of bind and update_source to return
connect_error or success. The rest of the code handles the situation correctly
after that.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Donald Sharp [Fri, 12 Jun 2015 14:59:11 +0000 (07:59 -0700)]
bgpd-set-somark.patch
BGP: Set SO_MARK on connecting sockets to ensure lookup in right routing table
In the presence of a function such as management VRF/MRF, bgpd needs to be able
to specify that it intends to run in the dataplane and not the front panel.
To ensure this, we add a mark in the connecting socket so that the kernel
does the routing lookup in the right table. This assumes that an appropriate
ip rule has been configured (outside the scope of this package).
While we've forced the mark to be 254 for now, it maybe required to make it
configurable at a later time.
Donald Sharp [Fri, 12 Jun 2015 14:59:11 +0000 (07:59 -0700)]
This patch changes BGP from only listening mode for BFD status updates to interactive mode of dynamically registering/deregistering BFD enabled peers with PTM/BFD through zebra. Peer is registered with BFD when it goes into established state and de-registers when it goes out of establish state.
This patch also adds BFD multihop support for BGP. Whether a peer is multi-hop or single hop is determined internally. All IGP peers are considered as multi-hop peers. EBGP peers are considered as single hop unless configured as multi-hop.
BGP BFD command enhancement to configure BFD parameters (detect multiplier, min rx and min tx).
Donald Sharp [Fri, 12 Jun 2015 14:59:11 +0000 (07:59 -0700)]
Key changes:
- The aspath and community structures now have a json_object where we
store the json representation. This is updated at the same time
the "str" for aspath/community are updated. We do this so that we
do not have to compute the json rep
- Added a small wrappper to libjson0, the wrapper lives in quagga's lib/json.[ch].
- Added more structure to the json output. Sample output:
show ip bgp summary json
------------------------
BGP router identifier 10.0.0.1, local AS number 10
BGP table version 2400
RIB entries 4799, using 562 KiB of memory
Peers 17, using 284 KiB of memory
Peer groups 4, using 224 bytes of memory
Important info:
- r8 originates 8.8.8.8/32
- r1, r2, r3 -> r7 are 10.0.0.1, 10.0.0.2, etc
- 'bgp bestpath compare-routerid' is configured everywhere (we could still hit
the problem without this though)
Bestpath selection for 8.8.8.8/32 on r2 and r3 is inconsistent. Here r4
advertised the 8.8.8.8/32 to r2 first, r2 then advertised it to r3, r3 selected
the path from r2 as the bestpath due to lowest router-id.
r2
BGP routing table entry for 8.8.8.8/32
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.0.0.1 10.0.0.3 10.0.0.4
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
Last update: Fri May 1 14:46:57 2015
r3
BGP routing table entry for 8.8.8.8/32
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.0.0.4 90.1.1.6
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.2 (10.0.0.2)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Last update: Fri May 1 14:46:58 2015
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, confed-external
Last update: Fri May 1 14:46:57 2015
Here r4 advertised the 8.8.8.8/32 to r3 first, r3 then advertised it to r2, r2
selected the path from r3 as the bestpath due to lowest router-id.
r2
BGP routing table entry for 8.8.8.8/32
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.0.0.4
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, confed-external
Last update: Fri May 1 15:37:27 2015
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.3 (10.0.0.3)
Origin IGP, metric 0, localpref 100, valid, confed-internal, best
Last update: Fri May 1 15:37:27 2015
r3
BGP routing table entry for 8.8.8.8/32
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.0.0.1 10.0.0.2 10.0.0.4 90.1.1.6
(65002 65003) 80
10.0.0.7 (metric 50) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
Last update: Fri May 1 15:37:22 2015
The fix is to have bestpath prefer a confed-external path over a confed-internal
path. I added this just after the "nexthop IGP cost" step because some confed
customers will have one IGP covering multiple sub-ASs, in that case you want to
compare nexthop IGP cost.
The customer does this because they want to peer to 10.1.1.2 as a
confed-external peer but peer with 10.1.1.3 as a normal iBGP peer.
The bug was that we thought 10.1.1.3 was an EBGP peer so we did not send him
LOCALPREF which caused the Juniper to send us a NOTIFICATION. I confirmed
that quagga also sends a NOTIFICATION in this scenario.
The fix is to add a check to see if router bgp X and bgp confederation
identifier X are equal because that is a factor in determining if a peer is
EBGP or IBGP
Additional issues fixed in the this patch:
We were not properly removing all AS_CONFED_SEQUENCEs/SETs from the aspath
when advertising a route to an ebgp peer. This was due to two issues:
We only called aspath_delete_confed_seq() if confederations were
configured. We can RX as aspath with CONFED segments even if
confederations are not configured.
aspath_delete_confed_seq() was implemented based on the original confed
RFC 3065 which basically said "remove all of the leading
AS_CONFED_SEQUENCEs/SETs" where the new confed RFC 5065 says "remove ALL
of the AS_CONFED_SEQUENCEs/SETs"
peer-groups did not work for confed-external peers. peer_calc_sort() always
returned BGP_PEER_EBGP for a confederations where the remote-as was not
specified. The reason was the peer->as_type was AS_UNSPECIFIED but we checked
After fixing that I found that when we got to the else where we checked for
peer1 we could only possibly return BGP_PEER_IBGP or BGP_PEER_EBGP, we need
to also be able to return BGP_PEER_CONFED. I changed this to return
peer1->sort.
"show ip bgp x.x.x.x" would always display "Local" for the aspath. This is
because we were calling aspath_counts_hop() to determine if the aspath was
empty. This is wrong though because CONFED segments do not count towards
aspath hopcount. The fix is to null check aspath->segments to determine if
the aspath is actually empty.
"show ip bgp x.x.x.x" and "show ip bgp neighbor" always displayed
"internal" or "external" and never "confed-internal" or "confed-external".
This made troubleshooting difficult because I couldn't tell exactly what
kind of peer I was dealing with. I added the confed-internal and
confed-external output...also added a "peer-type" field in the json output
for 'show ip bgp x.x.x.x'
"show ip bgp peer-group" did not list the peer-group name if we hadn't
determined the "type" (internal, external, etc) for the peer-group
Donald Sharp [Fri, 12 Jun 2015 14:59:09 +0000 (07:59 -0700)]
When an interface goes down, any neigbors learnt on that interface
using IPv6 Router Advertisements (RAs) must be deleted. When an
interface comes up and neighbors are learnt on that interface, the
BGP FSM for any interface peer must be started only if a valid
local address exists; the local address may come up later after IPv6
Duplicate Address Detection.
Donald Sharp [Fri, 12 Jun 2015 14:59:09 +0000 (07:59 -0700)]
The nexthop reveived for a prefix in a BGP update is cached in the
nexthop cache in BGP and registered for resolution with the nexthop
tracking (NHT) component. If the prefix were to be received from the
same peer with a different nexthop, the prior nexthop needs to be
processed for cleanup and unregistered and removed from the cache, if
appropriate. That is handled with this patch.
Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Reviewed-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 12 Jun 2015 14:59:09 +0000 (07:59 -0700)]
If the received MP nexthop is a martian address, treat the update as
an implicit withdraw as is done for the NEXT_HOP attribute in the
update itself.
Note: Check is implemented only for IPv6 for the global nexthop. The
code will quietly ignore an invalid IPv6 link-local nexthop, if present;
this is the existing behavior and is not changed.
Signed-off-by: Vivek Venkataraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Donald Sharp [Fri, 12 Jun 2015 14:59:09 +0000 (07:59 -0700)]
When a route-reflector is configured with "next-hop self" towards an IBGP
peer, it will only set the nexthop to "self" for non-reflected routes.
To force the nexthop to "self" for reflected routes, a "next-hop self
force" configuration is required. With the introduction of the update
groups function, these two configurations are not distinguished correctly
leading to inconsistent behavior. Resolve by introducing the proper
distinction.
Donald Sharp [Fri, 12 Jun 2015 14:59:08 +0000 (07:59 -0700)]
When peering is done on link-local address, always store the local address
in the peer structure so that it can be used in setting the link-local nexthop
in updates. This would ensure that in the absence of a global IPv6 address on
the peering interface, a route-map can be used to specify a potentially
arbitrary global v6 nexthop and that would be sent in conjunction with the
correct link-local nexthop.
Donald Sharp [Fri, 12 Jun 2015 14:59:08 +0000 (07:59 -0700)]
With the dynamic update groups feature, BGP updates are formed for an update
group and then replicated and sent for each member peer. The nexthop field
in the update is set only as part of this final step, as it may differ per
member peer. Update logs to display the final nexthop that is sent.
Donald Sharp [Fri, 12 Jun 2015 14:58:14 +0000 (07:58 -0700)]
A nexthop value specified by an outbound routemap is not being
honored correctly for EBGP peers after the introduction of the
dynamic update groups functionality. Ensure this is handled
correctly. Also, the route-map can separately set different
nexthops - IPv4, IPv6 global or IPv6 link-local; treat these
separately.
Donald Sharp [Thu, 11 Jun 2015 16:19:59 +0000 (09:19 -0700)]
BGP Path attributes classified as well-known and mandatory need to be
present in any received Update. Make sure the validation is done correctly
for address families besides IPv4-unicast.
Donald Sharp [Thu, 11 Jun 2015 16:19:59 +0000 (09:19 -0700)]
When performing a delete of an IPv6 route, BGP passes along a nexthop
to zebra. If the nexthop value is non-NULL, Zebra would attempt to find
a route that not only matches the prefix but also the nexthop i.e., treat
the delete as a specific ECMP path delete. However, the intent in BGP is
not a path delete but a delete of the entire prefix. If the deletion were
triggered by the nexthop for a prefix changing from NH1 to NH2 and NH2 is
not reachable, the delete would be issued to zebra for the prefix with the
nexthop as NH2 and zebra wouldn't delete the prefix as it still has NH1 as
its nexthop.
Fix by not sending any nexthop in IPv6 route delete. This is based on the
assumption (currently valid) that BGP does a route add/replace for any
path changes and issues a route delete only when it needs to delete the
entire route.
Donald Sharp [Thu, 11 Jun 2015 16:19:59 +0000 (09:19 -0700)]
When a route-map configuration is used to set the nexthop to a value, make
sure that the value is acceptable. For example, if the route-map is setting
the IPv6 link-local nexthop, make sure the value is an IPv6 link-local
address.
Donald Sharp [Thu, 11 Jun 2015 16:19:12 +0000 (09:19 -0700)]
bgpd, zebra: rfc-5549-generic.patch
This adds support for BGP RFC 5549 (Extended Next Hop Encoding capability)
* send and receive of the capability
* processing of IPv4->IPv6 next-hops
* for resolving these IPv6 next-hops, itsworks with the current
next-hop-tracking support
* added a new message type between BGP and Zebra for such route
install/uninstall
* zserv side of changes to process IPv4 prefix ->IPv6 next-hops
* required show command changes for IPv4 prefix having IPv6 next-hops
Few points to note about the implementation:
* It does an implicit next-hop-self when a [IPv4 prefix -> IPv6 LL next-hop]
is to be considered for advertisement to IPv4 peering (or IPv6 peering
without Extended next-hop capability negotiated)
* Currently feature is off by default, enable it by configuring
'neighbor <> capability extended-nexthop'
* Current support is for IPv4 Unicast prefixes only.
IMPORTANT NOTE:
This patch alone isn't enough to have IPv4->IPv6 routes installed into
the kernel. A separate patch is needed for that to work for the netlink
interface.
Signed-off-by: Vipin Kumar <vipin@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Vivek Venkatraman <vivek@cumulusnetworks.com>
Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Thu, 11 Jun 2015 16:11:13 +0000 (09:11 -0700)]
zebra, bgpd, ospfd: 'redistribute table' to 'redistribute table <table-id>'
Table-id argument support wasnt complete, used the [proto, instance]
combination changes that were done for OSPF multi-instance. In this case
its 'table <table-id>' just like it was 'ospf <instance-id>'
Donald Sharp [Thu, 11 Jun 2015 16:11:12 +0000 (09:11 -0700)]
The CHANGED flag may be set for a route (RIB entry) due to change in
interface or nexthop status. However, this route may not be selected as
the best and may not be the prior best. The flag needs to be reset
after evaluating the route as not doing so may prevent future nexthop
validation for this route.
Donald Sharp [Thu, 11 Jun 2015 16:11:12 +0000 (09:11 -0700)]
If the nexthop is only resolved over a default route and that is not
explicitly allowed, don't treat it as a change for routes using this
nexthop, unless the resolution has really changed.
Donald Sharp [Thu, 11 Jun 2015 16:11:12 +0000 (09:11 -0700)]
Zebra: Implement route replace semantics.
Zebra currently performs a delete followed by add when a route needs to be
modified. Change this to use the replace semantics of netlink so that the
operation can possibly be atomic.
Donald Sharp [Thu, 11 Jun 2015 16:11:12 +0000 (09:11 -0700)]
Zebra: Don't resolve nexthops over default route unless explicitly allowed.
Ensure that resolution of a nexthop using a default route is not done in the
nexthop validation/update code in zebra_rib.c also. This is an addition to
the zebra-nht-no-default.patch which made the checks only in the NHT code. In
the case of scenarios like interface down, this nexthop update code will kick
in first to update the route before the NHT code comes into play; without the
additional fix, this code could incorrectly resolve the nexthop over a default
route, even when disallowed by the administrator.
projects / matthieu / frr.git / log