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.
Donald Sharp [Thu, 11 Jun 2015 16:11:12 +0000 (09:11 -0700)]
When an interface is disabled, a Cumulus kernel patch causes route deletes to
be issued to Quagga. Quagga will in turn try to re-add the route(s) back to
the kernel and this will result in an error back from the kernel. This change
is to make sure these error messages are not logged by default. Subsequent
changes will cleanup this handling (to address CM-4577).
Donald Sharp [Wed, 20 May 2015 23:55:57 +0000 (16:55 -0700)]
vtysh-integrated-fix.patch
Lost config when switching back and forth between 'service integrated-vtysh-config'.
Also it was possible to have config files not be read in if they were not generated.
Ticket: CM-6011, CM-6033
Reviewed By: Daniel Walton <dwalton@cumulusnetworks.com>
Testing Done: See bugs
Donald Sharp [Wed, 20 May 2015 14:00:02 +0000 (07:00 -0700)]
Fixup 'force' -vs- 'all' compile issue
Our code implemented 'force' for a keyword while quagga mainline implemented 'all'.
This fixups the #define usage that was missed that came in during one of the patch
files. This is a compile only testing
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:46:10 +0000 (18:46 -0700)]
bgpd-ttl-fix.patch
BGP: Fix MINTTL and IPV6_MINHOPCOUNT
The #defines for IP_MINTTL and IPV6_MINHOPCOUNT need to be handled
correctly as part of the configure.ac code. Instead of hard coding
the values directly in the code
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:45:53 +0000 (18:45 -0700)]
bgpd-ebgp-multihop-fix.patch
BGP: Fix EBGP multihop transitions correctly
Since BGP connection setup has migrated to using NHT to decide when to bring a
session up, we have to handle ebgp multihop transitions correctly to ensure NHT
registrations are correctly handled.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:29:17 +0000 (18:29 -0700)]
debian: modify quagga pkg depend on cl-utilities pkg
Modified debian/control file to list as a dependency the cl-utilities package
as the cl-utilities package provides start-stop-monitor which is needed by
quagga to be monitored correctly.
Basically ZEBRA_INTERFACE_LINKDETECTION is set to on by default now.
Virtual links are failing to identify as up because of this code change.
Modify ospf to set the flag as appropriate
Donald Sharp [Wed, 20 May 2015 01:29:16 +0000 (18:29 -0700)]
bgpd-hostname-cap.patch
bgpd: Exchange hostname capability and display hostnames in outputs
This patch adds a hostname capability. The node's hostname and
domainname are exchanged in the new capability and used in show command
outputs based on a knob enabled by the user. The hostname and domainname
can be a maximum of 64 chars long, each.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:29:16 +0000 (18:29 -0700)]
quagga: quagga-debian-upgrade.patch
debian: The upgrade is failing due to missing files Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
Donald Sharp [Wed, 20 May 2015 01:29:16 +0000 (18:29 -0700)]
quagga: quagga-startup-fds.patch
Setup default number of filedescriptors allowed in quagga defaults and ulimit calls Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
Donald Sharp [Wed, 20 May 2015 01:29:14 +0000 (18:29 -0700)]
ospfd: ospfd-warnings.patch
Remove compile warnings for the ospfd/ospf6d directory Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:
Donald Sharp [Wed, 20 May 2015 01:04:25 +0000 (18:04 -0700)]
bgpd: bgpd-no-as.patch
bgp: Fixup of the remote-as command to allow user to not have to enter an actual as number Signed-off-by: Donald Sharp<sharpd@cumulusnetworks.com>
Reviewed-by:
Donald Sharp [Wed, 20 May 2015 01:04:20 +0000 (18:04 -0700)]
If a route-map is used on a neighbor default-originate statement we need to dynamically add/del the default route if the permit/deny result of the route-map changes.
Donald Sharp [Wed, 20 May 2015 01:04:20 +0000 (18:04 -0700)]
bgpd-nht-import-check-fix.patch
BGP: Fix network import check use with NHT instead of scanner
When next hop tracking was implemented and the bgp scanner was eliminated,
the "network import-check" command got broken. This patch fixes that
issue. NHT is used to not just track nexthops, but also the static routes
that are announced as part of BGP's network command. The routes are
registered only when import-check is enabled. To optimize performance,
we register static routes only when import-check is enabled.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:04:19 +0000 (18:04 -0700)]
During connection setup, there may be two connections in progress for a BGP
peer - one initiated by the local system and the other initiated by the peer.
Enhance key debug logs to also print the socket file descriptor so that it is
clear which events pertain to which connection.
Donald Sharp [Wed, 20 May 2015 01:04:18 +0000 (18:04 -0700)]
When a peer is unbound from its peer-group, in some situations the peer is
deleted while in other situations, the peer continues to exist but its
global flags have all been reset. This is incorrect, particularly for the
CONFIG_NODE flag as other parts of the code depend on this flag being set
for a configured peer. This patch ensures that the correct flags still
remain set for the peer after unbind from its peer-group.
Donald Sharp [Wed, 20 May 2015 01:04:17 +0000 (18:04 -0700)]
The retry of BGP connection after expiry of connect retry timer was
broken by some earlier patches. Instead of staying in Connect state
after reattempting the connection, the state used to go back to Idle
and then try to connect. This patch fixes this error.
Donald Sharp [Wed, 20 May 2015 01:04:16 +0000 (18:04 -0700)]
Zebra: Don't resolve routes over default for nexthop tracking
Resolving routes over the default route for NHT can lead to all sorts
of problems. So, we explicitly exclude resolving routes for NHT over the
default route. A knob is provided to allow the route to be resolved over
the default in case of special circumstances.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:04:16 +0000 (18:04 -0700)]
Zebra: Ensure we compare prefix and NHs when checking if NH changed
In nexthop tracking, the code currently compares the nexthop state of the
resolved_route for a prefix with the previous nexthop state. However, if
the resolved route itself changes, we can end up comparing the RIBs of
unrelated prefixes and assuming that nothing has changed. To fix this, we
need to store and compare the new resolved route with the previously
resolved route. If this has changed, assume the NH associated with a route
has changed.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:04:15 +0000 (18:04 -0700)]
Zebra: Static NHT fixes
When NHT calls rib_process() to be invoked for a prefix, the RIB has already
been marked as having NH changes. The first call to nexthop_active_update
clears this flag and attempts to re-determine if there are any NH changes for
a prefix. However, when the NH is recurisve, this fails. Furthermore, since
NHT has already determined that this RIB has NH changes, there's no need to
ascertain that again. The original patch used static route as the proxy to
skip this call which was incorrect since rib_process can be invoked for
static routes for reasons other than NHT. So, this patch removes the check
for static route and directly checks if the NH changed flag has been set.
Signed-off-by: Dinesh G Dutt <ddutt@cumulusnetworks.com> Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Donald Sharp [Wed, 20 May 2015 01:04:15 +0000 (18:04 -0700)]
ospfd: ospf_cli_fixes
ospf: Fix cli issues with timers throttle spf and no ip ospf authentication...
When entering no timers throttle spf there was no way to specify the delay, hold
time and max hold time so the command was rejected. This is useful for automated
processes that take currently entered cli to remove the cli.
When entering no ip ospf authentication most forms of the command were being
ignored, this fixes that as well.
Signed-off-by: Donald Sharp <sharpd at cumulusnetworks.com>
Reviewed-by:
Donald Sharp [Wed, 20 May 2015 01:04:14 +0000 (18:04 -0700)]
When an incoming connection is received from a neighbor that is configured but
is not activated for any address-family, the connection is accepted without
taking further action. This causes the connection to hang in OpenSent on the
neighbor and can in turn delay the connection setup. Fix to reject incoming
connections when there is no address-family activated for the neighbor.
Donald Sharp [Wed, 20 May 2015 01:04:13 +0000 (18:04 -0700)]
initd-status.patch
Add support for service quagga status.
As per LSB initscript status code definitions, support is added for
querying status of quagga. All daemons supposed to have been enabled, will
be checked as running and if any one of them is found to be not running, the
appropriate status code is returned.
Note that if watchquagga is running, a status indicating a problem maybe a
trasient problem because watchquagga will start back an unresponsive or dead
process.
http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
Donald Sharp [Wed, 20 May 2015 01:04:13 +0000 (18:04 -0700)]
zebra-rtadv-suppress-default-config.patch
Zebra: Suppress displaying default config as part of running config
Quagga doesn't display default config as part of the running config, only
what is different from the default. However, in the case of rtadv, every
link displays the default "ipv6 nd suppress-ra" as part of running config.
This patch fixes that.
Donald Sharp [Wed, 20 May 2015 01:04:12 +0000 (18:04 -0700)]
When a peer that is Established goes down, it is moved into the Clearing
state to facilitate clearing of the routes received from the peer - remove
from the RIB, reselect best path, update/delete from Zebra and to other
peers etc. At the end of this, a Clearing_Completed event is generated to
the FSM which will allow the peer to move out of Clearing to Idle.
The issue in the code is that there is a possibility of multiple Clearing
Completed events being generated for a peer, one per AFI/SAFI. Upon the
first such event, the peer would move to Idle. If other events happened
(e.g., new connection got established) before the last Clearing_Completed
event is received, bad things can happen.
Fix to ensure only one Clearing_Completed event is generated.
Donald Sharp [Wed, 20 May 2015 01:04:12 +0000 (18:04 -0700)]
When unexpected events are received, do not silently transition to Idle
state through bgp_ignore() as that may not do required cleanup. Instead,
define a new event handler to handle such cases, which will go through
bgp_stop(). A similar change is also done to handle the case where an
event handler fails.
Also add a couple of variables to keep track of events for a peer.
Donald Sharp [Wed, 20 May 2015 01:04:11 +0000 (18:04 -0700)]
initd-reload.patch
init.d: Add reload option
Add an option to apply only modifications to running configuration from the
specified configuration file. The default modification file is
/etc/quagga/Quagga.conf. A new script, quagga-reload.py, has been added to
the tools directory.
Donald Sharp [Wed, 20 May 2015 01:04:11 +0000 (18:04 -0700)]
vtysh-add-mark-cmd.patch
VTYSH: Add support for marking a file with appropriate end of context
To support applying only differences to the existing config, this patch
enables supplying the appropriate end markers to a provided file (or
stdin). By end markers, I mean, adding "end" and "exit-address-family"
at the appropriate places in the configuration to ease finding the
differences with the running configuration.
Donald Sharp [Wed, 20 May 2015 01:04:10 +0000 (18:04 -0700)]
Zebra: Fix multiple RNH deletes
The code is structured in a way that ends up invoking zebra_delete_rnh()
multiple times which can lead to crashes and asserts. This patch fixes
the issue by setting a flag when an RNH structure is being deleted and
ignores any further attempts to delete the structure.
Donald Sharp [Wed, 20 May 2015 01:04:10 +0000 (18:04 -0700)]
Zebra: Add onlink attribute even for recursive routes
When a route is resolved recursively, and the recursively resolved nexthop
has the onlink attribute, the route is not programmed with the nexthop with
the onlink attribute. This patch addresses that.
Donald Sharp [Wed, 20 May 2015 01:04:09 +0000 (18:04 -0700)]
BGP: Fix update-groups commands to match neighbors
show update-groups summary was mislabeled. What it displays is not a summary
at all, but the detailed info about all update-groups. Furthermore, there
was no way to get detailed info about a specific subgroup.
This patch renames "show * update-groups summary" to "show * update-groups"
and adds an option to see the info specific to a subgroup only. It also
validates the subgroup-id.
show * update-groups summary will be added separately.
Donald Sharp [Wed, 20 May 2015 01:04:08 +0000 (18:04 -0700)]
Cleanup some code related to NHT.
When BGP connection setup was moved to rely on nexthop tracking, a few silly
bugs were introduced.
- bgp_connect_check() was called unnecessarily which resulted in false
positives which resulted in log messages indicating an error and the FSM
was unnecessarily reset.
- When routes to peer disappeared, and the peer was not directly connected,
the session was not immediately torn down, but only on hold timer expiry.
- When NHT indicated that route to session IP addr was available, the previous
state was not reset and as a result, connect retry timer had to expire
before a reconnection was attempted.
- connected check MUST be enabled only for EBGP non-multihop sessions and
only if disbale-connected-check option is not enabled.
Donald Sharp [Wed, 20 May 2015 01:04:07 +0000 (18:04 -0700)]
Changing router-id inline isnt handled correctly in the current implementation.
At the minimum, the OSPF_LSA_SELF logic isnt foolproof, and it may hit assert
in ospf_refresh_unregister_lsa on a router-id change.
Once OSPF has created and flooded LSAs, its not a good idea to change
router-id inline. Tying it to restart has at least two benefits:
- Implementation can remain sane by not having to re-adjust neighbors and LSAs,
based on the new router-id.
- Works as a deterrent for the user to not meddle with the router-id unless
really needed.
projects / mirror / frr.git / log