Anuradha Karuppiah <anuradhak@cumulusnetworks.com>: Author Summary

Builds triggered by Anuradha Karuppiah <anuradhak@cumulusnetworks.com>

Builds triggered by an author are those builds which contains changes committed by the author.
50
27 (54%)
23 (46%)

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.
13 (26% of all builds triggered)
5 (10% of all builds triggered)
-8
Build Completed Code commits Tests
FRR › FRR › #2399 2 months ago
pimd, zebra: request for replay of SG entries on startup
zvni setup in zebra is controlled via bgpd i.e. advertise_all_vni
from bgpd triggers this setup. As a part of zvni creation we may need
to setup BUM mcast SG entries which are propagated to pimd for MDT setup.

Now pimd may not be present at the time of zvni creation or may restart
post zvni creation so we need a mechanism to replay (on pimd startup) and
to cleanup (on pimd stop). This is addressed via zebra_vxlan_sg_replay and
zebra_evpn_pim_cfg_clean_up.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
8763 passed
FRR › FRR › #2349 2 months ago
pimd: remove pim and igmp OIFs when ifchannel_delete happens
In a pim-evpn setup (say TORC11<=>TORC12) an mroute can have a mix of
PIM and IGMP joins. The vxlan termination device ipmr-lo is IGMP
joined on termination mroutes and the peerlink-rif can be pim joined
on the same mroute if the MLAG peer (TORC11) loses all its uplinks to
underlay -
root@TORC12:~# net show pim state 239.1.1.101|grep pimreg
1         *                239.1.1.101      uplink-1
             pimreg(I    ), ipmr-lo( J   ), peerlink-3.4094( J   )
root@TORC12:~#

When the uplinks come back up on TORC11 it will prune the peerlink-rif
and join the RP (say spine) via the uplinks.

TORC12 is rxing the prune and removing the if_channel
(pim_ifchannel_delete). However it is not removing the OIF from
mfcc_ttl basically leaving behind a leaked OIF in the forwarding
entry. And this is because it is deriving the owner flag from the
parent upstream entry and incorrectly concluding that all OIFs are
IGMP joined.

Thix fix flushes out both PIM and IGMP ownership when the ifchannel is
deleted.

There is a second fix in the commit and that is to set the proto mask
correctly (to STAR) for inherited OIFs. (S,G) entries can inherit the
OIF from the (*, G) entry and this decision can change when the pim/igmp
ifchannel is removed. The earlier code was setting the proto-mask
incorrectly to PIM or IGMP.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit d4d1d968dbbe61347393f7dace8b675496ff1024)
pimd: ensure that the oif is removed from all the mroutes pre-vifi deletion
When a link goes down the vifi was being deleted but the OIF stayed
in the OIL with a stale vifi -
oroot@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source           Group            IIF               OIL
1         *                239.1.1.111      swp1s1            pimreg(I    ), ipmr-lo( J   )
1         6.0.0.28         239.1.1.111      lo                pimreg( J   ), ipmr-lo(    *), swp1s1( J   )
root@act-7726-03:~# ip link set swp1s1 down
root@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source           Group            IIF               OIL
1         *                239.1.1.111      swp1s0            pimreg(I    ), ipmr-lo( J   )
1         6.0.0.28         239.1.1.111      lo                ipmr-lo(    *), swp1s0( J   ), <oif?>( J   ) >>>>>>>>
root@act-7726-03:~#

The problem was as a part ifchannel_delete the join state of the channel
was checked to avoid incorrect OIF deletion this was preventing the OIF
from being flushed. Fix is to flip the channel join-state to NOINFO before
deleting it.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1 of 8244 failed
FRR › FRRREL70 › #3 4 months ago
zebra: display metric for connected routes
In a VRR/VRRP setup we can have connected routes with different costs.
So this change eliminates suppressing metric display for connected routes.

Sample output -
root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1"
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       > - selected route, * - FIB route

VRF vrf1:
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36
C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36
C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set connected route metric based on the devaddr metric
MACVLAN devices are typically used for applications such as VRR/VRRP that
require a second MAC address (virtual). These devices have a corresponding
SVI/VLAN device -
root@TORC11:~# ip addr show vlan1002
39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::2/64 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~# ip addr show vlan1002-v0
40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::a/64 metric 1024 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~#

The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via
the SVI. To acheive that functionality the macvlan network's metric
is set to a higher value.

Zebra currently ignores the devaddr metric sent by the kernel and hardcodes
it to 0. This commit eliminates that hardcoding. If the devaddr metric
is available (METRIC_MAX) it is used for setting up the connected route
otherwise we fallback to the dev/interface metric.

Setting the macvlan metric to a higher value ensures that zebra will always
select the connected route on the SVI (and subsequently use it for next hop
resolution etc.) -
root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64"
Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 1024, vrf vrf1
  Last update 11:30:56 ago
  * directly connected, vlan1002-v0

Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 0, vrf vrf1, best
  Last update 11:30:56 ago
  * directly connected, vlan1002

root@TORC11:~#

Ticket: CM-23511
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Testless build
FRR › FRRV601 › #3 4 months ago
zebra: set connected route metric based on the devaddr metric
MACVLAN devices are typically used for applications such as VRR/VRRP that
require a second MAC address (virtual). These devices have a corresponding
SVI/VLAN device -
root@TORC11:~# ip addr show vlan1002
39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::2/64 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~# ip addr show vlan1002-v0
40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::a/64 metric 1024 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~#

The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via
the SVI. To acheive that functionality the macvlan network's metric
is set to a higher value.

Zebra currently ignores the devaddr metric sent by the kernel and hardcodes
it to 0. This commit eliminates that hardcoding. If the devaddr metric
is available (METRIC_MAX) it is used for setting up the connected route
otherwise we fallback to the dev/interface metric.

Setting the macvlan metric to a higher value ensures that zebra will always
select the connected route on the SVI (and subsequently use it for next hop
resolution etc.) -
root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64"
Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 1024, vrf vrf1
  Last update 11:30:56 ago
  * directly connected, vlan1002-v0

Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 0, vrf vrf1, best
  Last update 11:30:56 ago
  * directly connected, vlan1002

root@TORC11:~#

Ticket: CM-23511
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: display metric for connected routes
In a VRR/VRRP setup we can have connected routes with different costs.
So this change eliminates suppressing metric display for connected routes.

Sample output -
root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1"
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       > - selected route, * - FIB route

VRF vrf1:
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36
C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36
C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
438 passed
You have insufficient permissions to see all of the builds.
Build Completed Code commits Tests
FRR › FRR › #2349 2 months ago
pimd: remove pim and igmp OIFs when ifchannel_delete happens
In a pim-evpn setup (say TORC11<=>TORC12) an mroute can have a mix of
PIM and IGMP joins. The vxlan termination device ipmr-lo is IGMP
joined on termination mroutes and the peerlink-rif can be pim joined
on the same mroute if the MLAG peer (TORC11) loses all its uplinks to
underlay -
root@TORC12:~# net show pim state 239.1.1.101|grep pimreg
1         *                239.1.1.101      uplink-1
             pimreg(I    ), ipmr-lo( J   ), peerlink-3.4094( J   )
root@TORC12:~#

When the uplinks come back up on TORC11 it will prune the peerlink-rif
and join the RP (say spine) via the uplinks.

TORC12 is rxing the prune and removing the if_channel
(pim_ifchannel_delete). However it is not removing the OIF from
mfcc_ttl basically leaving behind a leaked OIF in the forwarding
entry. And this is because it is deriving the owner flag from the
parent upstream entry and incorrectly concluding that all OIFs are
IGMP joined.

Thix fix flushes out both PIM and IGMP ownership when the ifchannel is
deleted.

There is a second fix in the commit and that is to set the proto mask
correctly (to STAR) for inherited OIFs. (S,G) entries can inherit the
OIF from the (*, G) entry and this decision can change when the pim/igmp
ifchannel is removed. The earlier code was setting the proto-mask
incorrectly to PIM or IGMP.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
(cherry picked from commit d4d1d968dbbe61347393f7dace8b675496ff1024)
pimd: ensure that the oif is removed from all the mroutes pre-vifi deletion
When a link goes down the vifi was being deleted but the OIF stayed
in the OIL with a stale vifi -
oroot@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source           Group            IIF               OIL
1         *                239.1.1.111      swp1s1            pimreg(I    ), ipmr-lo( J   )
1         6.0.0.28         239.1.1.111      lo                pimreg( J   ), ipmr-lo(    *), swp1s1( J   )
root@act-7726-03:~# ip link set swp1s1 down
root@act-7726-03:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN
Installed Source           Group            IIF               OIL
1         *                239.1.1.111      swp1s0            pimreg(I    ), ipmr-lo( J   )
1         6.0.0.28         239.1.1.111      lo                ipmr-lo(    *), swp1s0( J   ), <oif?>( J   ) >>>>>>>>
root@act-7726-03:~#

The problem was as a part ifchannel_delete the join state of the channel
was checked to avoid incorrect OIF deletion this was preventing the OIF
from being flushed. Fix is to flip the channel join-state to NOINFO before
deleting it.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1 of 8244 failed
FRR › TOPOPR › #384 10 months ago
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › TOPOPR › #383 10 months ago
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

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

Ticket: CM-22700
5 of 1240 failed
FRR › TOPOPR › #382 10 months ago
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

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

Ticket: CM-22700
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 1240 failed
FRR › TOPOPR › #343 1 year ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
5 of 972 failed
FRR › TOPOPR › #342 1 year ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6 of 972 failed
FRR › TOPOPR › #339 1 year ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
689 passed
FRR › TOPOPR › #338 1 year ago
bgpd: unregister VNI learning from zebra on default instance delete
The code for this was always there but was not kicking in because of an
incorrect dependency on is_evpn_enabled. This API attempts to locate the
default instance from bgp_master's instance list. Only the instance
currently being deleted has already been removed from the instance list
by the time bgp_delete->bgp_zebra_instance_deregister is executed.

Symptom of this bug used to show up when a default instance is deleted
and created again. In that case bgp_zebra_instance_register would not be
effective as zebra ignores the register as dup (dereg didn't happen in the
first place) so bgpd wouldn't reload already configured L2-VNIs.
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
* 1000       L2   169.253.0.11:9   6646:1000  6646:1000 vrf1
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6646
root@cel-sea-03:~# sed -i 's/6646/6656/' /etc/frr/frr.conf
root@cel-sea-03:~# grep "router bgp"  /etc/frr/frr.conf
router bgp 6656
root@cel-sea-03:~# systemctl reload frr
root@cel-sea-03:~# net show bgp l2vpn evpn vni |grep 1000
root@cel-sea-03:~#

Fix simply changes the order of dereg to make
bgp_zebra_instance_deregister actually happen (by doing it before the
default instance is removed from the master list).

Ticket: CM-21566

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
10 of 824 failed
FRR › TOPOPR › #284 1 year ago
zebra: install EVPN gateway MAC as static/sticky
SVI interface ip/hw address is advertised by the GW VTEP (say TORC11) with
the default-GW community. And the rxing VTEP (say TORC21) installs the GW
MAC as a dynamic FDB entry. The problem with this is a rogue packet from a
server with the GW MAC as source can cause a station move resulting in
TORC21 hijacking the GW MAC address and blackholing all inter rack traffic.

Fix is to make the GW MAC "sticky" pinning it to the GW VTEP (TORC11). This
commit does it by installing the FDB entry as static if the MACIP route is
received with the default-GW community (mimics handling of
mac-mobility-with-sticky community)

Sample output with from TORC12 with TORC11 setup as gateway -
root@TORC21:~# net show evpn mac vni 1004 mac 00:00:5e:00:01:01
MAC: 00:00:5e:00:01:01
 Remote VTEP: 36.0.0.11 Remote-gateway Mac
 Neighbors:
    45.0.4.1
    fe80::200:5eff:fe00:101
    2001:fee1:0:4::1

root@TORC21:~# bridge fdb show |grep 00:00:5e:00:01:01|grep 1004
00:00:5e:00:01:01 dev vx-1004 vlan 1004 master bridge static
00:00:5e:00:01:01 dev vx-1004 dst 36.0.0.11 self static
root@TORC21:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Ticket: CM-21508
Testless build
FRR › TOPOPR › #283 1 year ago
zebra: install EVPN gateway MAC as static/sticky
SVI interface ip/hw address is advertised by the GW VTEP (say TORC11) with
the default-GW community. And the rxing VTEP (say TORC21) installs the GW
MAC as a dynamic FDB entry. The problem with this is a rogue packet from a
server with the GW MAC as source can cause a station move resulting in
TORC21 hijacking the GW MAC address and blackholing all inter rack traffic.

Fix is to make the GW MAC "sticky" pinning it to the GW VTEP (TORC11). This
commit does it by installing the FDB entry as static if the MACIP route is
received with the default-GW community (mimics handling of
mac-mobility-with-sticky community)

Sample output with from TORC12 with TORC11 setup as gateway -
root@TORC21:~# net show evpn mac vni 1004 mac 00:00:5e:00:01:01
MAC: 00:00:5e:00:01:01
 Remote VTEP: 36.0.0.11 Remote-gateway Mac
 Neighbors:
    45.0.4.1
    fe80::200:5eff:fe00:101
    2001:fee1:0:4::1

root@TORC21:~# bridge fdb show |grep 00:00:5e:00:01:01|grep 1004
00:00:5e:00:01:01 dev vx-1004 vlan 1004 master bridge static
00:00:5e:00:01:01 dev vx-1004 dst 36.0.0.11 self static
root@TORC21:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Ticket: CM-21508
Testless build
Build Completed Code commits Tests
FRR › FRR › #2114 4 months ago
bgpd: lock the tenant-vrf associated with the l2-vni
The l2vni (bgpevpn instance) was maintaining a back pointer to the
tenant vrf without locking it. This would result in bgp_terminate crashing
as the tenant-vrf is released before the underlay-vrf (vpn->bgp_vrf->l2vnis
is NULL). Call stack -
BGP: [bt 3] /lib/libfrr.so.0(listnode_delete+0x11) [0x7f041c967f51]
BGP: [bt 4] /usr/lib/frr/bgpd(bgp_evpn_free+0x26) [0x55e3428eea46]
BGP: [bt 5] /lib/libfrr.so.0(hash_iterate+0x4a) [0x7f041c95f00a]
BGP: [bt 6] /usr/lib/frr/bgpd(bgp_evpn_cleanup+0x22) [0x55e3428f0a72]
BGP: [bt 7] /usr/lib/frr/bgpd(bgp_free+0x180) [0x55e342955f50]
PIM: vxlan SG (*,239.1.1.111) term mroute-up del
BGP: [bt 8] /usr/lib/frr/bgpd(bgp_delete+0x43a) [0x55e342959d7a]
BGP: [bt 9] /usr/lib/frr/bgpd(sigint+0xee) [0x55e3428d6a5e]

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Vivek Venkataraman <vivek@cumulusnetworks.com>
Reviewed-by: Chirag Shah <chirag@cumulusnetworks.com>
6609 passed
FRR › FRR › #2037 5 months ago
bgp: fix misc evpn prefix match problems caused by using incorrect prefixlen
The evpn route prefix len was being hardcoded to 224 bits while the
length of a mac-ip addr is actually 288. Because of this many problems were
seen in the evpn-tests. The sample below is from a test that does a vm-move
to verify extended-evpn-mac-mobility - IP1-M1 => IP2->M1. You can see two
local neighs but only one was inserted into the per-vni route table.

root@TORC11:~# net show evpn arp vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
2001:fee1:0:1::10       local  active   00:54:6f:7c:74:64
2001:fee1:0:1::11       local  active   00:54:6f:7c:74:64
root@TORC11:~# net show bgp l2vpn evpn route vni 1001 |grep "2001:fee1:0:1::10\|2001:fee1:0:1::11"
*> [2]:[0]:[48]:[00:54:6f:7c:74:64]:[128]:[2001:fee1:0:1::11]
root@TORC11:~#

Similarly other traffic loss problems were seen because of one prefix updating
another prefix's route.

I think the 224-bits came from the packet format definition of type-2 routes.
However the way FRR maintains the key is very different than the format in
the packet so it seems best to just sizeof the addr.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6998 passed
FRR › FRR › #1879 7 months ago
bgpd: reinstate current bgp best route on an inactive neigh del
When an inactive-neigh delete is rxed bgp will not have a local path to
remove (and re-run path selection). Instead it simply re-installs the
current best remote path if any.

Ticket: CM-23018
Testing Done: evpn-min

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: propagate inactive neigh deletes to bgpd
When a local neigh is added with a MAC that is remote or absent the
neigh is kept in zebra as local/in-active. But not propagated to bgpd.
Similarly when an inactive neigh is deleted the del-msg is not propagated
to bgpd.

Without this change bgp and zebra would fall out of sync as that
bgp would not know to rerun bestpath and for it to reinstall a
known remote path for the mac-ip in question.  To fix this we
now propagate inactive neigh deletes to bgpd.

Ticket: CM-23018
Testing Done:
1. evpn-min
2. manually triggered the out-of-sync state and verified the fix

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: display metric for connected routes
In a VRR/VRRP setup we can have connected routes with different costs.
So this change eliminates suppressing metric display for connected routes.

Sample output -
root@TORC11:~# vtysh -c "show ipv6 route vrf vrf1"
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       > - selected route, * - FIB route

VRF vrf1:
K * ::/0 [255/8192] unreachable (ICMP unreachable), 00:00:36
C * 2001:aa:1::/64 [0/100] is directly connected, vlan1002-v0, 00:00:36
C>* 2001:aa:1::/64 [0/90] is directly connected, vlan1002, 00:00:36

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: fill the zebra mac-ip route via a common api
Move the info filling for zebra mac-ip install (sent by bgpd) to a
common place.

The commit also fixes missing ROUTER flag for one of the cases
added in a code branch that doesn't have the ROUTER changes -
[
6d8c603a
bgpd: use IP address as tie breaker if the MM seq number is the same
]

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set connected route metric based on the devaddr metric
MACVLAN devices are typically used for applications such as VRR/VRRP that
require a second MAC address (virtual). These devices have a corresponding
SVI/VLAN device -
root@TORC11:~# ip addr show vlan1002
39: vlan1002@bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:02:00:00:00:2e brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::2/64 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~# ip addr show vlan1002-v0
40: vlan1002-v0@vlan1002: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9152 qdisc noqueue master vrf1 state UP group default
    link/ether 00:00:5e:00:01:01 brd ff:ff:ff:ff:ff:ff
    inet6 2001:aa:1::a/64 metric 1024 scope global
       valid_lft forever preferred_lft forever
root@TORC11:~#

The macvlan device is used primarily for RX (VR-IP/VR-MAC). And TX is via
the SVI. To acheive that functionality the macvlan network's metric
is set to a higher value.

Zebra currently ignores the devaddr metric sent by the kernel and hardcodes
it to 0. This commit eliminates that hardcoding. If the devaddr metric
is available (METRIC_MAX) it is used for setting up the connected route
otherwise we fallback to the dev/interface metric.

Setting the macvlan metric to a higher value ensures that zebra will always
select the connected route on the SVI (and subsequently use it for next hop
resolution etc.) -
root@TORC11:~# vtysh -c "show ip route vrf vrf1 2001:aa:1::/64"
Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 1024, vrf vrf1
  Last update 11:30:56 ago
  * directly connected, vlan1002-v0

Routing entry for 2001:aa:1::/64
  Known via "connected", distance 0, metric 0, vrf vrf1, best
  Last update 11:30:56 ago
  * directly connected, vlan1002

root@TORC11:~#

Ticket: CM-23511
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6996 passed
FRR › FRR › #1675 10 months ago
bgpd: move non-best local path checks outside the function
This change is a fixup to -
7b5e18 -  bgpd: use IP address as tie breaker if the MM seq number is the
same

And is being done in response to review comments. This commit brings no
functional change; simply moves around code for easier maintanence.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: send a local-mac del to bgpd on mac mod to remote
When events cross paths between bgp and zebra bgpd could end up with a
dangling local MAC entry. Consider the following sequence of events on
rack-1 -
1. MAC1 has MM sequence number 1 and points to rack-3
2. Now a packet is rxed locally on rack-1 and rack-2 (simultaneously) with
source-mac=MAC1.
3. This would cause rack-1 and rack-2 to set the MM seq to 2 and
simultaneously report the MAC as local.
4. Now let's say on rack-1 zebra's MACIP_ADD is in bgpd's queue. bgpd
accepts rack-3's update and sends a remote MACIP add to zebra with MM=2.
5. zebra updates the MAC entry from local=>remote.
6. bgpd now processes zebra's "stale local" making it the best path.
However zebra no longer has a local MAC entry.

At this point bgpd and zebra are effectively out of sync i.e. bgpd has a
local-MAC which is not present in the kernel or in zebra.

To handle this window zebra should send a local MAC delete to bgpd on
modifying its cache to remote.

Ticket: CM-22687
Reviewed By: CCR-7935

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: set remoteseq to 0 when remote mac is deleted by bgpd
When the remote mac is deleted by bgpd we can end up with an auto mac
entry in zebra if there are neighs referring to the mac. The remote sequence
number in the auto mac entry needs to be reset to 0 as the mac entry may
have been removed on all VTEPs (including the originating one).

Now if the MAC comes back on a remote VTEP it may be added with MM=0 which
 will NOT be accepted if the remote seq was not reset in the previous step.

Ticket: CM-22707

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
bgpd: hidden commands to add/del a local mac
local mac add/del comes from zebra. the hidden commands help verify
various race conditions between bgp and zebra.

Ticket: CM-22687
Reviewed By: CCR-7939

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
zebra: make neigh active when it is modified from local to remote
This is a fixup to commit -
f32ea5c07 - zebra: act on kernel notifications for remote neighbors

The original commit handled a race condition between kernel and zebra
that would result in an inconsistent state i.e.
kernel has an offload/remote neigh
zebra has a local neigh

The original commit missed setting the neigh to active when zebra
tried to resolve the inconsistency by modifying the local neigh to
remote neigh on hearing back its own kernel update. Fixed here.

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

Ticket: CM-22700
bgpd: use IP address as tie breaker if the MM seq number is the same
Same sequence number handling is specified by RFC 7432 -
[
If two (or more) PEs advertise the same MAC address with the same
sequence number but different Ethernet segment identifiers, a PE that
receives these routes selects the route advertised by the PE with the
lowest IP address as the best route.

If the PE is the originator of the MAC route and it receives the same
MAC address with the same sequence number that it generated, it will
compare its own IP address with the IP address of the remote PE and
will select the lowest IP.  If its own route is not the best one, it
will withdraw the route.
]

To implement that specification this commit uses nexthop IP as a tie
breaker between two paths of equal seq number with lower IP winning.

Now if a local path already exists with the same sequence number but higher
(local-VTEP) IP it is evicted (deleted and withdrawn from the peers) and
the winning new remote path is installed in zebra. This is existing code
and handled implicitly via evpn_route_select_install.

If a local path is rxed from zebra with the same sequence as the
current remote winner it is rejected (not installed in the bgp
routing tables) and zebra is asked to re-install the older/remote winner.
This is a race condition that can only happen if bgp's add and zebra's add
cross paths. Additional handling has been added in this commit via
evpn_cleanup_local_non_best_route to take care of the race condition.

Ticket: CM-22674
Reviewed By: CCR-7937

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
bgpd: perform route selection again when the local path is deleted
This is needed to install the remote dst when a more preferred local
path is removed.

Ticket: CM-22685
Reviewed By: CCR-7936

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
6890 passed
You have insufficient permissions to see all of the builds.