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.
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:
projects / matthieu / frr.git / log