vivek <vivek@cumulusnetworks.com>: Author Summary

Builds triggered by vivek <vivek@cumulusnetworks.com>

Builds triggered by an author are those builds which contains changes committed by the author.
126
53 (42%)
73 (58%)

Breakages and fixes

Broken means the build has failed but the previous build was successful.
Fixed means that the build was successful but the previous build has failed.
41 (33% of all builds triggered)
11 (9% of all builds triggered)
-30
Build Completed Code commits Tests
FRR › FRR › #2003 2 months ago
zebra: Use next hop's VRF for EVPN-based routes
Ensure that the next hop's VRF is used for IPv4 and IPv6 unicast routes
sourced from EVPN routes, for next hop and Router MAC tracking and
install. This way, leaked routes from other instances are handled properly.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Allow EVPN-sourced routes to be leaked back into EVPN
Refine check on whether a route can be injected into EVPN to allow
EVPN-sourced routes to be injected back into another instance.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Recursively determine if route's source is EVPN
With leaking of IPv4 or IPv6 unicast routes whose source is a EVPN
type-2 or type-5 route between VRFs, the determination of whether
the route's source is EVPN has to be made recursively. This is used
during route install to pass along appropriate parameters to zebra.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Remove route sub-type checks in route-leak withdraw
The check on which routes are exportable is a superset, so remove the
route sub-type checks. Also, this change is needed to handle EVPN-imported
leaked routes correctly.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Correctly identify VPN-imported routes in a VRF
Refine check that looks for VPN routes imported into a VRF because
a VRF can have other imported routes too like IPv4 and IPv6 unicast
routes sourced from EVPN type-2 and type-5 routes.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: No nexthop tracking for EVPN-imported leaked routes
IPv4 or IPv6 unicast routes which are imported from EVPN routes
(type-2 or type-5) and installed in a BGP instance and then leaked
do not need any nexthop tracking, as any tracking should happen in
the source instance.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Leak EVPN-installed routes
IPv4 or IPv6 unicast routes which are imported from EVPN routes
(type-2 or type-5) and installed in a BGP instance can be leaked
to another instance.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Refine check for which routes can be exported into VPN
A non-imported route or a non-VPN imported route is a candidate to be
exported into the VPN routing table for leaking to other BGP instances
or advertisement into BGP/MPLS VPN. The former is a local or learnt
IPv4 or IPv6 route. The latter is an IPv4 or IPv6 route that is based
on a received EVPN type-2 or type-5 route.

Implement a function to specify if a route can be exported into VPN
and use in the appropriate places.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
3 of 6635 failed
FRR › FRR › #1978 2 months ago
*: Explicitly mark nexthop of EVPN-sourced routes as onlink
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface. Howver, in the model that
is supported in the implementation and commonly deployed, there is no
explicit Overlay IP address associated with the next hop in the tenant
VRF; the underlay IP is used if (since) the forwarding plane requires
a next hop IP. Therefore, the next hop has to be explicit flagged as
onlink to cause any next hop reachability checks in the forwarding plane
to be skipped.

https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.

Use existing mechanism to specify the nexthops as onlink when installing
these routes from bgpd to zebra and get rid of a special flag that was
introduced for EVPN-sourced routes. Also, use the onlink flag during next
hop validation in zebra and eliminate other special checks.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
zebra, bgpd: Use L3 interface for VRF's VNI in route install
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface.

https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.

Use the L3 interface exchanged between zebra and bgp in route install.
This patch in conjunction with the earlier one helps to eliminate some
special code in zebra to derive the next hop's interface.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
zebra, bgpd: Exchange L3 interface for VRF's VNI
In the case of EVPN symmetric routing, the tenant VRF is associated with
a VNI that is used for routing and commonly referred to as the L3 VNI or
VRF VNI. Corresponding to this VNI is a VLAN and its associated L3 (IP)
interface (SVI). Overlay next hops (i.e., next hops for routes in the
tenant VRF) are reachable over this interface.

https://tools.ietf.org/html/draft-ietf-bess-evpn-prefix-advertisement
section 4.4 provides additional description of the above constructs.

The implementation currently derives this L3 interface for EVPN tenant
routes using special code that looks at route flags. This patch
exchanges the L3 interface between zebra and bgpd as part of the L3-VNI
exchange in order to eliminate some this special code.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
6581 passed
FRR › FRR › #1972 2 months ago
bgpd: Fix EVPN advertise route-map application
When a IPv4 or IPv6 route that was formerly allowed by the route-map
to be injected into EVPN gets an updated set of attributes that now
causes it to be filtered, the route needs to be pulled out of EVPN.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
6581 passed
FRR › FRR › #1558 7 months ago
zebra: Remove unused parameter in MAC delete
When a MAC moves from local to remote, a replace is allowed, EVPN
no longer has to delete the local MAC before installing the remote
MAC.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Chirag Shah <chirag@cumulusnetworks.com>
zebra: Use boolean for certain VxLAN-EVPN flags
Use boolean variables instead of unsigned int for certain VxLAN-EVPN
flags which are really used as boolean.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Chirag Shah <chirag@cumulusnetworks.com>

Ticket: CM-22288
Reviewed By: CCR-7832
Testing Done:
Along with a subsequent, related commit
zebra: Fix neighbor update to BGP
Ensure that when the is_router condition changes for a locally learnt
neighbor, it is informed to BGP only if it is active i.e., the MAC is
also locally learnt.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Chirag Shah <chirag@cumulusnetworks.com>

Ticket: CM-22288
Reviewed By: CCR-7832
Testing Done:
1. Failed test
2. vxlan_routing_test.py
zebra: Uninstall remote MACs from kernel appropriately
When a remote MAC goes away, but there are neighbors referring to it,
ensure that when the last remote neighbor goes away, the MAC is
uninstalled from the kernel and no longer considered as remote.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by:   Chirag Shah <chirag@cumulusnetworks.com>

Ticket: CM-22130
Reviewed By: CCR-7777
Testing Done:
1. Replicated failed scenario and verified with fix.
2. evpn-min
7309 passed
FRR › TOPOPR › #358 8 months ago
bgpd, zebra: EVPN extended mobility support
Implement procedures similar to what is specified in
https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility
in order to support extended mobility scenarios in EVPN. These are scenarios
where a host/VM move results in a different (MAC,IP) binding from earlier.
For example, a host with an address assignment (IP1, MAC1) moves behind a
different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host
with an address assignment (IP5, MAC5) has a different assignment of (IP6,
MAC5) after the move. Note that while these are described as "move" scenarios,
they also cover the situation when a VM is shut down and a new VM is spun up
at a different location that reuses the IP address or MAC address of the
earlier instance, but not both. Yet another scenario is a MAC change for an
attached host/VM i.e., when the MAC of an attached host changes from MAC1 to
MAC2. This is necessary because there may already be a non-zero sequence
number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before
(IP, MAC2) is advertised, they may propagate through the network differently.

The procedures continue to rely on the MAC mobility extended community
specified in RFC 7432 and already supported by the implementation, but
augment it with a inheritance mechanism that understands the relationship
of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC
forwarding database entry). In FRR, this relationship is understood by the
zebra component which doubles as the "host mobility manager", so the MAC
mobility sequence numbers are determined through interaction between bgpd
and zebra.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Update neighbor state correctly upon move
When a host moves and is locally reachable, if the local neighbor event
is received before the local MAC event, flag the neighbor as inactive
just as would happen in the case of a new host. This ensures that the
MACIP route will get originated as soon as the local MAC event is got.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd, zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Enhancements to EVPN operational commands
Enhance the EVPN MAC and Neighbor cache display to show additional
information such as the mobility sequence numbers and the state.
Ensure that the neighbor state is set in a couple of places so
that the display is correct.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Merge remote-tracking branch 'upstream/master' into evpn-extended-mobility
Conflicts:
        zebra/zebra_vxlan.c
858 passed
FRR › TOPOPR › #357 8 months ago
zebra: Enhancements to EVPN operational commands
Enhance the EVPN MAC and Neighbor cache display to show additional
information such as the mobility sequence numbers and the state.
Ensure that the neighbor state is set in a couple of places so
that the display is correct.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Update neighbor state correctly upon move
When a host moves and is locally reachable, if the local neighbor event
is received before the local MAC event, flag the neighbor as inactive
just as would happen in the case of a new host. This ensures that the
MACIP route will get originated as soon as the local MAC event is got.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd, zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd, zebra: EVPN extended mobility support
Implement procedures similar to what is specified in
https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility
in order to support extended mobility scenarios in EVPN. These are scenarios
where a host/VM move results in a different (MAC,IP) binding from earlier.
For example, a host with an address assignment (IP1, MAC1) moves behind a
different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host
with an address assignment (IP5, MAC5) has a different assignment of (IP6,
MAC5) after the move. Note that while these are described as "move" scenarios,
they also cover the situation when a VM is shut down and a new VM is spun up
at a different location that reuses the IP address or MAC address of the
earlier instance, but not both. Yet another scenario is a MAC change for an
attached host/VM i.e., when the MAC of an attached host changes from MAC1 to
MAC2. This is necessary because there may already be a non-zero sequence
number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before
(IP, MAC2) is advertised, they may propagate through the network differently.

The procedures continue to rely on the MAC mobility extended community
specified in RFC 7432 and already supported by the implementation, but
augment it with a inheritance mechanism that understands the relationship
of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC
forwarding database entry). In FRR, this relationship is understood by the
zebra component which doubles as the "host mobility manager", so the MAC
mobility sequence numbers are determined through interaction between bgpd
and zebra.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Merge remote-tracking branch 'upstream/master' into evpn-extended-mobility
Conflicts:
        zebra/zebra_vxlan.c
4 of 1053 failed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › TOPOPR › #357 8 months ago
zebra: Enhancements to EVPN operational commands
Enhance the EVPN MAC and Neighbor cache display to show additional
information such as the mobility sequence numbers and the state.
Ensure that the neighbor state is set in a couple of places so
that the display is correct.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Update neighbor state correctly upon move
When a host moves and is locally reachable, if the local neighbor event
is received before the local MAC event, flag the neighbor as inactive
just as would happen in the case of a new host. This ensures that the
MACIP route will get originated as soon as the local MAC event is got.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd, zebra: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd, zebra: EVPN extended mobility support
Implement procedures similar to what is specified in
https://tools.ietf.org/html/draft-malhotra-bess-evpn-irb-extended-mobility
in order to support extended mobility scenarios in EVPN. These are scenarios
where a host/VM move results in a different (MAC,IP) binding from earlier.
For example, a host with an address assignment (IP1, MAC1) moves behind a
different PE (VTEP) and has an address assignment of (IP1, MAC2) or a host
with an address assignment (IP5, MAC5) has a different assignment of (IP6,
MAC5) after the move. Note that while these are described as "move" scenarios,
they also cover the situation when a VM is shut down and a new VM is spun up
at a different location that reuses the IP address or MAC address of the
earlier instance, but not both. Yet another scenario is a MAC change for an
attached host/VM i.e., when the MAC of an attached host changes from MAC1 to
MAC2. This is necessary because there may already be a non-zero sequence
number associated with MAC2. Also, even though (IP, MAC1) is withdrawn before
(IP, MAC2) is advertised, they may propagate through the network differently.

The procedures continue to rely on the MAC mobility extended community
specified in RFC 7432 and already supported by the implementation, but
augment it with a inheritance mechanism that understands the relationship
of the host MACIP (ARP/neighbor table entry) to the underlying MAC (MAC
forwarding database entry). In FRR, this relationship is understood by the
zebra component which doubles as the "host mobility manager", so the MAC
mobility sequence numbers are determined through interaction between bgpd
and zebra.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Merge remote-tracking branch 'upstream/master' into evpn-extended-mobility
Conflicts:
        zebra/zebra_vxlan.c
4 of 1053 failed
FRR › TOPOPR › #234 1 year ago
bgpd: Display table version for EVPN routes
Display the table version for EVPN routes like it is done for other
address families. Note that this is really relevant only for the
per-VNI routing table.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-12903
bgpd: Fix VRF route leaking for multipath routes
Ensure that the next hop of the leaked VRF is not overwritten when the
route is being imported into the target VRF from the VPN table. Also, in
the case of multipath routes, ensure that the nexthop's ifindex is not
inadvertently reset.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Update parent entry's refcount for imported routes
Imported routes in a VRF routing table have a reference to their parent
route entry which resides in the EVPN or IPVPN routing table. Ensure that
this reference uses appropriate locking so that the parent entry doesn't
get freed prematurely.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit 13cb6b22ba9d558b1b4a1e8752f63f13242462a7)

Conflicts:
        bgpd/bgp_mplsvpn.c

Ticket: CM-20471
Testing Done:
a) Ran vrf_route_leak tests without fix and hit crash, ran twice with fix
and did not see the crash.
b) Ran evpn-smoke and ensured there were no new failures.
zebra: Increase recvmsg buffer size for picking up netlink messages
Netlink messages from the kernel need to be received in a buffer larger
than 8K in order to handle some types of info - for example, the VLAN
information. Define a separate size for receive and set it to 32K, which
is the value used by other netlink receivers like iproute2.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Don't generate spurious warning on VNI deletion
There are situations in which zebra may issue more than one delete
notification, so BGP should not warn when it can't locate the VNI
at delete. This is comparable to the situation when a withdraw is
received but the route isn't present locally.

Signed-off-by: Vivek Venkatraman <vivek@cumulusmetworks.com>

Ticket: CM-17512
Reviewed By: Trivial
Testing Done: Manual
bgpd: Set NEXT_HOP attribute for EVPN imported routes
Ensure that when EVPN routes are imported into a VRF as IPv4 routes,
the NEXT_HOP attribute is set. In the absence of this, this attribute
is currently not generated when advertising the route to peers in the
VRF. It is to be noted that the source route (the EVPN route) will only
have the MP_REACH_NLRI attribute that contains the next hop in it.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by:   Don Slice <dslice@cumulusnetworks.com>
195 of 776 failed
FRR › FRR › #1081 1 year ago
bgpd, zebra: Handle EVPN router MAC per next hop
Ensure that when EVPN routes are installed into zebra, the router MAC
is passed per next hop and appropriately handled. This is required for
proper multipath operation.

Ticket: CM-18999
Reviewed By:
Testing Done: Verified failed scenario, other manual tests
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
3248 passed
FRR › TOPOPR › #226 1 year ago
bgpd: Fix route-leak/L3VPN delete of redistributed routes
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>
bgpd: Fix params/checks for route leaking and L3VPN
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
bgpd: Handle connected routes and IPv6 link-local nexthops for route leaking
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>
bgpd: Auto RD definitions and encoding
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>
bgpd: Enhance loop checking for VRF to VPN route export
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>
bgpd: Fixes for VRF route leaking
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>
bgpd: Fix peer determination from parent for imported routes
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>
bgpd: Implement show command for VRF route leaking
Implement "show bgp [vrf FOO] <afi> <safi> route-leak" which displays
operational information about VRF route leaking.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #225 1 year ago
bgpd: Fix route-leak/L3VPN delete of redistributed routes
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>
bgpd: Fix params/checks for route leaking and L3VPN
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
bgpd: Fixes for VRF route leaking
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>
bgpd: Handle connected routes and IPv6 link-local nexthops for route leaking
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>
bgpd: Enhance loop checking for VRF to VPN route export
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>
bgpd: Auto RD definitions and encoding
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>
bgpd: Fix peer determination from parent for imported routes
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>
bgpd: Implement show command for VRF route leaking
Implement "show bgp [vrf FOO] <afi> <safi> route-leak" which displays
operational information about VRF route leaking.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
5 of 776 failed
FRR › TOPOPR › #224 1 year ago
bgpd: Fix params/checks for route leaking and L3VPN
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
bgpd: Fixes for VRF route leaking
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>
bgpd: Enhance loop checking for VRF to VPN route export
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>
bgpd: Implement show command for VRF route leaking
Implement "show bgp [vrf FOO] <afi> <safi> route-leak" which displays
operational information about VRF route leaking.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Auto RD definitions and encoding
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>
bgpd: Handle connected routes and IPv6 link-local nexthops for route leaking
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>
bgpd: Fix route-leak/L3VPN delete of redistributed routes
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>
bgpd: Fix peer determination from parent for imported routes
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>
5 of 776 failed
FRR › TOPOPR › #209 1 year ago
bgpd: Use BGP instance to derive the VRF for route uninstall
When uninstalling routes from zebra, ensure that the BGP instance for
which processing is being done is used to derive the VRF. It is incorrect
to derive the VRF from the peer when dealing with scenarios like VRF route
leaking, EVPN symmetric/external routing etc., where the peer which sourced
the route could belong to a different VRF.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by:   Mitesh Kanjariya <mitesh@cumulusnetworks.com>

Ticket: CM-18413
Reviewed By: CCR-6778
Testing Done: Manual testing of BGP route withdraw/delete, bgp-min
10 of 721 failed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › FRR › #1082 1 year ago
bgpd, zebra: Handle EVPN router MAC per next hop
Ensure that when EVPN routes are installed into zebra, the router MAC
is passed per next hop and appropriately handled. This is required for
proper multipath operation.

Ticket: CM-18999
Reviewed By:
Testing Done: Verified failed scenario, other manual tests
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Fix VRF route leaking for multipath routes
Ensure that the next hop of the leaked VRF is not overwritten when the
route is being imported into the target VRF from the VPN table. Also, in
the case of multipath routes, ensure that the nexthop's ifindex is not
inadvertently reset.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
zebra: Increase recvmsg buffer size for picking up netlink messages
Netlink messages from the kernel need to be received in a buffer larger
than 8K in order to handle some types of info - for example, the VLAN
information. Define a separate size for receive and set it to 32K, which
is the value used by other netlink receivers like iproute2.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
bgpd: Display table version for EVPN routes
Display the table version for EVPN routes like it is done for other
address families. Note that this is really relevant only for the
per-VNI routing table.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-12903
bgpd: Don't generate spurious warning on VNI deletion
There are situations in which zebra may issue more than one delete
notification, so BGP should not warn when it can't locate the VNI
at delete. This is comparable to the situation when a withdraw is
received but the route isn't present locally.

Signed-off-by: Vivek Venkatraman <vivek@cumulusmetworks.com>

Ticket: CM-17512
Reviewed By: Trivial
Testing Done: Manual
3829 passed
FRR › FRR › #914 1 year ago
bgpd: Fix warnings
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Fix enum, use API for log string
Suggested-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Merge branch 'master' of https://github.com/frrouting/frr into pmsi-parse-display
Conflicts:
        bgpd/bgp_attr.c
Merge branch 'master' of https://github.com/frrouting/frr into pmsi-parse-display
bgpd: Fix warning
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Parse PMSI Tunnel Attribute and display
Received PMSI tunnel attributes (in EVPN type-3 route) were not recognized.
Parse them and display the tunnel type when looking at routes. Note that
the only tunnel type currently supported is ingress replication (IR). A
warning message will be logged if the received tunnel type is something
else, but the attribute is otherwise ignored.

Updates: a21bd7a (bgpd: add PMSI_TUNNEL_ATTRIBUTE to EVPN IMET routes)
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: Fix warning
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
3816 passed
FRR › FRR › #607 1 year ago
zebra: Fix MAC counts for EVPN
MAC entries are internally created for purposes such as when a local
neighbor is learnt but the MAC itself is not yet learnt. Such MACs are
not "real", so ensure they are not counted for UI output.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>

Ticket: CM-17991
Reviewed By: None
Testing Done: Manual, evpn-smoke
zebra: Handle L3 multi-tenancy correctly for EVPN
Fix following flaws that resulted in EVPN with L3 multi-tenancy (i.e.,
EVPN dealing with VxLAN routing in the presence of tenant VRFs) not
working properly:

1. EVPN enable ("advertise-all-vni") is a global command, ensure it is
accordingly processed. The config is maintained against the default VRF.
2. There was an incorrect attempt to derive the L3 VRF for L2 interfaces
- the VRF only applies for L3 interfaces, though the code may initialize
to the default value in other cases.
3. Functions to map (port, VLAN) to SVI or vice versa were incorrect -
particularly, zvni_map_svi() since it was looking in the L3 VRF for
"matching" L2 interface which it would never find. Fix.

In addition, since the 'zebra_vrf *' parameter is not relevant in most
places, it has been removed.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-17840
Reviewed By: CCR-6685
Testing Done: evpn-smoke, various manual tests
3549 passed
FRR › FRR › #28 2 years ago
Quagga: AFI/SAFI mappings IANA to/from internal values
Introduce internal and IANA defintions for AFI/SAFI and mapping
functions and modify code to use these. This refactoring will
facilitate adding support for other AFI/SAFI whose IANA values
won't be suitable for internal data structure definitions (e.g.,
they are not contiguous).
The commit adds some fixes related to afi/safi testing with 'make check
' command.

Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by:   Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>

Ticket: CM-11416
Reviewed By: CCR-3594 (mpls branch)
Testing Done: Not tested now, tested earlier on mpls branch
2805 passed
You have insufficient permissions to see all of the builds.