Some recent changes in BGP now require that the
peer's nexthop have a valid ifp when we are looking
at:
case BGP_ATTR_NHLEN_IPV6_GLOBAL_AND_LL:
case BGP_ATTR_NHLEN_VPNV6_GLOBAL_AND_LL:
This assumption makes sense for this type of Nexthop Attribute.
So for the test let's jimmy up a `fake` enough interface pointer
so that the actual test we can focus on what we are actually
testing.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Added the cli for doing route-map filtering on imported routes via
the new "import vrf route-map <NAME> command.
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Connected routes redistributed into BGP as well as IPv4 routes with IPv6
link-local next hops (RFC 5549) need information about the associated
interface in BGP if they are candidates to be leaked into another VRF. In
the absence of route leaking, this was not necessary. Introduce the
appropriate mechanism and ensure this is used during route install (in
the target VRF).
Ticket: CM-20343, CM-20382
Testing done:
1. Manually verified failed scenarios and some additional ones - logs
in the tickets.
2. Ran bgp-min and evpn-min - results are good.
3. Ran vrf smoke - has some failures, but none which look new
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ensure that when a route redistributed into a VRF is subsequently
deleted, it is properly removed from the VPN table (if exported)
so that it can be removed from other VRFs and withdrawn from
L3VPN peers.
Ticket: CM-20345
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
The VRF routes exported to the global VPN table must not be
imported routes. It is not necessary to check if they originate
in the global VPN instance as that doesn't hold good for VRF-to-
VRF route-leaking. Merely checking that they are not imported
should handle both L3VPN and VRF-to-VRF route-leaking use cases.
Ticket: CM-20283
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
When routes are imported into a VRF from the global VPN table, the
parent instance is either the default instance in the case of L3VPN or
the source VRF in the case of VRF-to-VRF route leaking. Hence, obtain
the source peer by just looking at the parent route information.
Ticket: CM-20283
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Implement fixes for route leaking between VRFs through BGP, especially for
the scenario where routes are leaked from a VRF X to multiple other VRFs.
This include making sure that import and export happen via the global VPN
table, setting RD correctly and proper handling for multiple import/export.
Ticket: CM-20256
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Setup a per-VRF identifier to use along with the Router Id to build the
RD. Define a function to encode the RD. Code is brought over from EVPN
and EVPN code has been modified to use the generic function.
Ticket: CM-20256
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
When routes are injected into the VPN table and then leaked into candidate
VRFs, the source should be the default instance. Also, the loop check when
withdrawing routes from a VRF should be that the route's origin isn't that
VRF; this handles VRF route leaking also and is consistent with checks in
other places.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
(cherry picked from commit 0149d2848c59bfb3277592caf0a5d5e07a2de872)
Ticket: CM-20256
When the `import vrf XXX` command is entered under
an afi/safi for bgp and the XXX vrf bgp instance
does not yet exist, auto-create it using the same
ASN that the we are importing into.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
add the `import vrf XXXX` command
router bgp 4 vrf DONNA
<config>
!
router bgp 4 vrf EVA
<config>
address-family ipv4 uni
import vrf DONNA
!
!
This command will allow for vrf EVA to specify that it would like
to receive the routes from vrf DONNA into it's table.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Adding to mtracebis querying with group address. Same change
to vtysh mtrace command. Support for querying (S,G) and (*,G)
state in mtrace router code. Further improvments to mtrace router
code with closer complience to IETF draft. More references in
comments to the draft. Man page has been updated accordingly.
Signed-off-by: Mladen Sablic <mladen.sablic@gmail.com>
The addr value will never be null because of the way we do the
cli, but the SA system doesn't understand this. Add an assert
to make it happy.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1) addr will never be non-null because of the way we build the cli
at this point in time, but the SA system does not understand this,
add a bread crumb for it.
2) Fix a possible memory leak of the pbr_ifp
3) Fix possible integer overflow when bit shifting.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
issue found by cppcheck
[isisd/dict.c:1320] -> [isisd/dict.c:1065]:
(warning) Either the condition '!dn' is redundant or
there is possible null pointer dereference: newnode.
[isisd/dict.c:1320] -> [isisd/dict.c:1068]:
(warning) Either the condition '!dn' is redundant or
there is possible null pointer dereference: newnode.
Signed-off-by: Ilya Shipitsin <chipitsine@gmail.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
When we are debugging add a bit of extra information
so we can know what we are redistributing to our peers
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Rename client_connect and client_close hooks to zapi_client_connect
and zapi_client_close
* Remove some more unnecessary headers
* Fix a copy-paste error in zapi_msg.[ch] header comments
* Fix an inclusion comment in zserv.c
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
zserv.c was using hardcoded callbacks to clean up various components
when a client disconnected. Ergo zserv.c had to know about all these
unrelated components that it should not care about. We have hooks now,
let's use the proper thing instead.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
zserv.c has become something of a dumping ground for everything vaguely
related to ZAPI and really needs some love. This change splits out the
code fo building and consuming ZAPI messages into a separate source
file, leaving the actual session and client lifecycle code in zserv.c.
Unfortunately since the #include situation in Zebra has not been paid
much attention I was forced to fix the headers in a lot of other source
files. This is a net improvement overall though.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
For the last six years this source file has been using a type defined in
a header it did not include.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The grammar sandbox has had the ability to dump individual commands as
DOT graphs, but now that generalized DOT support is present it's trivial
to extend this to entire submodes. This is quite useful for visualizing
the CLI space when debugging CLI errors.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Add general-purpose DFS traversal code
* Add ability to dump any graph to DOT language
* Add tests for graph datastructure
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Thread statistics are collected and stored in a hashtable shared across
threads, but while the hashtable itself is protected by a mutex, the
records themselves were not being updated safely. Change all thread
history collection to use atomic operations.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
For the last six years this source file has been using a type defined in
a header it did not include.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
bgp route extra->bgp_orig for routes leaked vpn->vrf should be set
to original extra->bgp_orig if it is set, not vpn's bgp instance.
The initial leak is OK because it goes through a loopback path
in the vrf->vpn leaking code, but it is possible later re-leaks (e.g.,
if the destination vrf's leak configuration is changed) could
set the wrong extra->bgp_orig and break the route's nexthop.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
When sending a bgp route down to zebra for deletion, the
ZEBRA_FLAG_ALLOW_RECURSION and ZEBRA_FLAG_IBGP flags
are not needed in zebra. So remove the setting
of the api.flags. If we remove this data from being
passed down we no longer need the peer data structure.
Remove the lookup of the peer data structure and the setting
of the flags as that peer was NULL in some evpn symmetric
routing cases for shutdown of bgp.
Ticket: CM-20720
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
