Daniel Walton [Thu, 20 Jul 2017 17:11:43 +0000 (17:11 +0000)]
lib: copy_nexthops() only copies the first nexthop
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
Before the fix NHT had each path resolving via swp1
cel-redxp-10# show ip route 20.0.11.253
Routing entry for 20.0.11.0/24
Known via "bgp", distance 20, metric 0, best
Last update 00:00:20 ago
* 169.254.0.1, via swp1
* 169.254.0.17, via swp2
cel-redxp-10#
cel-redxp-10# show ip nht
[snip]
20.0.11.253
resolved via bgp
via 169.254.0.1, swp1
via 169.254.0.1, swp1
Client list: pim(fd 19)
After the fix
cel-redxp-10# show ip nht
[snip]
20.0.11.253
resolved via bgp
via 169.254.0.1, swp1
via 169.254.0.17, swp2
Client list: pim(fd 19)
Quentin Young [Thu, 20 Jul 2017 15:48:52 +0000 (11:48 -0400)]
eigrpd, vtysh: add dummy route-map cli
eigrpd will successfully accept `(conf)# route-map foo ...` because it
is not sent to eigrpd from vtysh, but of course, this is the classic
node sync syndrome.
Since eigrpd apparently doesn't support proper routemaps yet just add
the cli so we can suppress the vtysh errors.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Don Slice [Tue, 18 Jul 2017 12:54:50 +0000 (12:54 +0000)]
bgpd: fix peer startup for labeled-unicast if linklocal address not found
Problem found in testing where ipv6 labeled-unicast prefixes were not received
on the peers if a "service networking restart" was issued. Same problem would
happen with an ifdown/ifup on the link to the peer. Found the problem to be
that peers would establish for labeled-unicast even if a link-local address was
not yet available on the interface toward the peer, causing updates to be sent
without a nexthop value. These were then rejected by the peer. Fix is to delay
peer establishment until after the link-local addresses are available.
Ticket: CM-16779 Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed By: Donald Sharp <sharpd@cumulusnetworks.com>
Testing Done: Manual testing successful. Bgp-smoke completed with no new failures
David Lamparter [Fri, 14 Jul 2017 15:53:59 +0000 (17:53 +0200)]
lib: parser: remove incorrect assert
A {foo|bar|baz} graph node will have more than 1/2 incoming links even
if no other references are left to it (which is what the assert was
previously trying to ensure.)
I don't see a good way to "fix" the assert so I'm just removing it.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Daniel Walton [Thu, 13 Jul 2017 19:56:08 +0000 (19:56 +0000)]
vtysh: return non-zero for configuration failures
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
This allows frr-reload.py (or anything else that scripts via vtysh)
to know if the vtysh command worked or hit an error.
Quentin Young [Wed, 12 Jul 2017 18:40:18 +0000 (14:40 -0400)]
lib, vtysh: pretty-print variable autocompletions
Pretty-prints variable autocompletions by breaking them up into multiple
lines, indenting them consistently and respecting the column width of
the terminal.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Donald Sharp [Tue, 6 Jun 2017 17:20:38 +0000 (13:20 -0400)]
bgpd: Refactor 'struct attr_extra' into 'struct attr'
Most of the attributes in 'struct attr_extra' allow for
the more interesting cases of using bgp. The extra
overhead of managing it will induce errors as we add
more attributes and the extra memory overhead is
negligible on anything but full bgp feeds.
Additionally this greatly simplifies the code for
the handling of data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Fix missing label set
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Donald Sharp [Fri, 26 May 2017 15:54:07 +0000 (11:54 -0400)]
bgpd: On cleanup make sure pointers exist
Test cases create fake bgp structure that is passed to
cleanup. The new evpn code assumed ( and probably rightly so)
that if the bgp structure was created it actually initialized
all useful data structures. Just make the evpn cleanup
functions be smart about attempting to free memory never
allocated.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 22:01:57 +0000 (15:01 -0700)]
bgpd: Additional configuration for EVPN
Implement configuration options for EVPN. The configuration options include
VNI configuration with RD and Import and Export Route Targets. Also, display
the EVPN configuration.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com>
vivek [Mon, 15 May 2017 21:42:57 +0000 (14:42 -0700)]
bgpd, zebra: Support for sticky MACs
Implement support for sticky (static) MACs. This includes the following:
- Recognize MAC is static (using NUD_NOARP flag) and inform BGP
- Construct MAC mobility extended community for sticky MACs as per
RFC 7432 section 15.2
- Inform to zebra that remote MAC is sticky, where appropriate
- Install sticky MACs into the kernel with the right flag
- Appropriate handling in route selection
Signed-off-by: Daniel Walton <dwalton@cumulusnetworks.com> Reviewed-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
vivek [Mon, 15 May 2017 21:34:04 +0000 (14:34 -0700)]
bgpd: EVPN route handling
Core EVPN route handling functionality. This includes support for the
following:
- interface with zebra to learn about local VNIs and MACIPs as well as
to install remote VTEPs (per VNI) and remote MACIPs
- create/update/delete EVPN type-2 and type-3 routes
- attribute creation, route selection and install
- route handling per VNI and for the global routing table
- parsing of received EVPN routes and handling by route type
- encoding attributes for EVPN routes and EVPN prefix creation (for
Updates)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com> Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com> Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
projects / mirror / frr.git / log