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.
49
31 (63%)
18 (37%)

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 (27% of all builds triggered)
4 (8% of all builds triggered)
-9
Build Completed Code commits Tests
FRR › FRR › #2806 2 months ago
pimd: re-name SwitchToSptDesired to SwitchToSptDesiredonRp
Criteria for switching to SPT is different on RP and LHR. Re-name
the functions to make that apparent.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup join desired handling to match the RFC defined macro
This commit includes the following changes -
1. kat needs to be included when evaluting join desired on a (S,G)
   entry.
2. there were cases where we were adding OIF based on joindesired
   being true for unrelated reasons (on other OIFs). cleaned up those
   cases.
3. make all calls to pim_upstream_switch conditional on the JoinDesired
   macro.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: display changes to indicate if a SG entry is still on the RPT
Sample output -
root@leaf-12:~# net show pim state
Codes: J -> Pim Join, I -> IGMP Report, S -> Source, * -> Inherited from (*,G), V -> VxLAN, M -> Muted
Active Source           Group            RPT  IIF               OIL
1      *                239.1.1.111      y    swp1              swp3( J   )
1      6.0.0.28         239.1.1.111      y    swp1
1      *                239.1.1.112      y    swp1              swp3( J   )
1      6.0.0.28         239.1.1.112      y    swp1
1      *                239.1.1.113      y    swp1              swp3( J   )
1      6.0.0.28         239.1.1.113      y    swp1
1      *                239.1.1.114      y    swp1              swp3( J   )
1      6.0.0.28         239.1.1.114      y    swp1
root@leaf-12:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: send an immediate XG JP message when switching from SPT to RPT
Today we are only pruning the SPT when (S,G) upstream entry
switches from Joined toNotJoined. This leaves the source still
pruned along the RPT till the next periodic XG join-prune is sent
to the RPF(RP). Traffic from the source will be blackholed for this
duration. To prevent that we need send a new JP message
to RPF(RP) immediately.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: prevent unconditional SG join sends
It was causing a Join on (S,G) who's prune state was being cleared. This
was an inactive (KAT not running; no immediate OIL) entry that was being
flushed out but because of this incorrect Join (that was being done with
out join-state checks) the source was getting populated repeatedy i.e.
never aged.

Output of "ip monitor mroute"
=============================
(27.0.0.11,239.1.1.102)          Iif: lo          State: resolved Table: default
Deleted (27.0.0.11,239.1.1.102)          Iif: lo          State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: pimreg      State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: lo         Oifs: uplink-1  State: resolved Table: default
(27.0.0.11,239.1.1.104)          Iif: lo         Oifs: pimreg uplink-1  State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: lo         Oifs: pimreg uplink-1  State: resolved Table: default
Deleted (27.0.0.11,239.1.1.102)          Iif: lo          State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: pimreg      State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: uplink-1    State: resolved Table: default
(27.0.0.11,239.1.1.102)          Iif: lo         Oifs: uplink-1  State: resolved Table: default

These mroute events (on a no longer existing multicast souce) continue in
a never ending loop.

Triggered joins/prunes MUST only done via state machine transitions i.e.
via pim_upstream_update_join_desired.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: display the per-RPF neighbor join-prune agg list
root@leaf-12:~# vtysh -c "show ip pim jp-agg"
Interface        RPF Nbr         Source          Group           State
swp1             6.0.0.26        *               239.1.1.111         J
swp1             6.0.0.26        *               239.1.1.112         J
swp1             6.0.0.26        *               239.1.1.113         J
swp1             6.0.0.26        *               239.1.1.114         J
root@leaf-12:~#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: on some triggers use_rpt re-evaluated for all groups
RP config change is a big hammer and use_rpt/spt needs to be
re-evaluated on all existing (S,G) entries.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: rename the upstream-join-desired command to "show ip pim channel"
This re-naming was needed because the JD state on an upstream is
not just based on channel info i.e. we can have JD=true even if there
is no downstream channel. The "show ip upstream-join-desired" command
will be changed to display that info i.e. upstream's JD state instead
of downstream channel params. The downstream channel params are now
available via "show ip pim channel"

PS: This change maybe reverted if upstream NAKs it. But there is a
pressing need for it to debug some not-so-reproduible problems.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: handle RPF resolution while in joined state
If an dummy upstream entry (no RPF nbr) which is already in a JOINED
state is resolved we were not triggering an immediate join via the
per-interface upstream switch list.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: re-eval JD on sources when a STAR_OIF is removed
When a inherited OIL becomes empty join-desired can go to false. So
we need to re-run join-desired evaluation on any inherited OIL changes.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: re-eval c_oil mute flags on upstream attach/detach
Theoretically there should be no case where the channel-oil hangs
around after the upstream entry is removed. But currently there are
cases where it does. This is a precautionary fixup till we are
rid off all of those cases.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup whitespace errors reported by CI
No functional changes.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: update add_oif and del_oif debugs to print caller
These logs were printing file name which has little value (is always
pim_oil.c). Instead print the caller.

add_oif/del_oif are being called directly from one too many. Instead OIF
setup needs to be consolidated via the PIM state machine. These
debugs are expected to help in understanding what needs to be cleaned up.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: set mfcc_parent at the time of MFCC programming
mfcc_parent for an (S, G) entry was being updated on any upstream RPF
change. With the change to use RPT for (S,G) in some cases we can no
longer do that. Instead the upstream entry's RPF neigbor is managed
separately form the channel_oil's mfcc_parent i.e. via NHT. And the
mfcc_parent is evaluated at the time of mroute programming.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: decide between SPT based and RPT based forwarding
An (S,G) mroute can be created as a result of rpt prune. However that
entry needs to stay on the parent (*,G)'s tree (IIF) till a decision is
made to switch the source to the SPT.

The decision to stay on the RPT is made based on the SPTbit setting
according to - RFC7761, Section 4.2 “Data Packet Forwarding Rules”

However those rules are hard to achieve when hw acceleration i.e.
control and data planes are separate. So instead of relying on data
we make the decision of using SPT if we have decided to join the SPT -
Use_RPT(S,G) {
    if (Joined(S,G) == TRUE          // we have decided to join the SPT
            OR Directly_Connected(S) == TRUE // source is directly connected
            OR I_am_RP(G) == TRUE)   // RP
        //use_spt
        return FALSE;
    //use_rpt
    return TRUE;
}

To make that change some re-org was needed -
1. pim static mroutes and dynamic (upstream mroutes) top level APIs
have been separated. This is to limit the state machine to dynamic
mroutes.
2. c_oil->oil.mfcc_parent is re-evaluated based on if we decided
to use the SPT or stay on the RPT.
3. upstream mroute re-eval is done when any of the criteria involved
in Use_RPT changes.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: update (S,G,rpt)'s IIF when the parent (*,G)'s IIF changes
If a source is being forwarded along the RPT it uses the parent (*,G)'s
IIF. When the parent's IIF changes all the children need to be updated

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: MUTE flag to suppress traffic forwarding on non-DF
If an mroute loses DF election (with the MLAG peer) it has to stop
forwarding traffic on active-active devices such as ipmr-lo used
for vxlan traffic termination. To acheive that this commit
introduces a concept of OIF muting. That way we can let the PIM and
IGMP state machines play out and silence OIFs after the fact.

Relevant outputs:
=================
1. muted OIFs are displayed with the M flag in "pim state" -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@TORC12:~# net show pim state |grep "27.0.0.13"|grep 100
1         27.0.0.13        239.1.1.100      uplink-1          ipmr-lo(   *M)
root@TORC12:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
2. And supressed altogether in the mroute output -
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
root@TORC12:~# net show mroute |grep "27.0.0.13"|grep 100
27.0.0.13       239.1.1.100     none   uplink-1         none             0    --:--:--
root@TORC12:~#
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: insert upstream entry into nbr's jp-agg list when a new nbr is added
A dummy pim upstream entry can be in a JOINED state before its RPF nbr is
added. Handle that case by triggering an immediate join.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: add caller string prefix to pim_rpf_update logs
No functional change; log enhancements only.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: re-eval JD unconditionally when an ifchannel is removed
This is to account for cases like prune-pending which is treated
as joined.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: enforce PIM_ENFORCE_LOOPFREE_MFC at the time of MFC programming
This is needed for two reasons -
1. The inherited OIL needs to be setup independent of the RPF interface
to allow correct computation of the JoinDesired macro.
2. The RPF interface is computed at the time of MFC programming so
it is not possible to permanently evict the OIF at that time oif_add

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: RPF change to unreachable was leaving a stale entry in the jp-agg list
This was causing pimd to crash later; call-stack -
(gdb) bt
    context=<optimized out>) at lib/sigevent.c:254
    group=group@entry=0x7ffffa9797e0) at pimd/pim_rp.c:207
    grp=grp@entry=0x7ffffa9799fe, sgs=sgs@entry=0x560ac069edb0, size=52)
    at pimd/pim_msg.c:200
    groups=<optimized out>) at pimd/pim_join.c:562
    at pimd/pim_neighbor.c:288
    at lib/thread.c:1599
    at lib/libfrr.c:1024
    envp=<optimized out>) at pimd/pim_main.c:162
(gdb) fr 4
    group=group@entry=0x7ffffa9797e0) at pimd/pim_rp.c:207
207     pimd/pim_rp.c: No such file or directory.
(gdb) fr 6
    grp=grp@entry=0x7ffffa9799fe, sgs=sgs@entry=0x560ac069edb0, size=52)
    at pimd/pim_msg.c:200
200     pimd/pim_msg.c: No such file or directory.
(gdb) p source->up->sg_str
$1 = '\000' <repeats 31 times>, <incomplete sequence \361>
(gdb)

This problem can manifest in the following event sequence -
1. upstream RPF neighbor is resolved
2. upstream RPF neighbor becomes unresolved (but upstream entry
   stays on the jp-agg list)
3. upstream entry is removed
on the next old-neighbor jp-agg-list processing the stale entry is
accessed resulting in the crash.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup kat restart to conform to the RFC
1. KAT should be re-started only if traffic rxed along the SPT i.e.
IIF == RPF_Interface(S).
Only exception to the rule is if you are LHR.
2. KAT should be started on all routers (not just FHR, RP, LHR).

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: bring back "show ip pim upstream-join-desired"
It is now used to evaluate and display join-desired state for
each upstream entry -
root@spine-1:~# net show pim upstream-join-desired
Source          Group           EvalJD
*               239.1.1.111     yes
6.0.0.28        239.1.1.111     yes
6.0.0.29        239.1.1.111     no
6.0.0.30        239.1.1.111     yes

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: exclude pimreg from the inherited OIL
Inherited OIL is used as a part of the JoinDesired macro. And in FRR we
use the channel OIL as the inherited OIL (to reduce processing overhead
everytime JD needs to be re-evaluated). On a FHR pimreg is a part of the
channel-OIL but must not be used for JD computation.

This commit blacklists pimreg from the inherited_oil i.e. present but
ignored.

Note: This fixup is being done to address topotest failures.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup (S,G,rpt) prune to conform to the RFC
Deviations -
1. Avoid using SPTbit setting. Replace that with Use_Spt macro.
2. If S is supposed to be forwarded along the RPT but has an empty OIL
prune it.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: jp-agg list update debug logs
Added event logs around add/del of upstream entries into the nbr's
jp-agg list. This is to help debug a problem with stale (deleted)
upstream entries being present in the list causing pimd to crash on
the periodic processing.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: eval use_rpt on new upstream post IIF setup but before MFC programming
use_rpt macro depends on JoinDesired macro and is mostly independent of the
actual RPF interface i.e. doesn't change when the RPF interface changes.

There is however one exception to this handling and that is on the
first hop router (DR or non-DR). On the DR the FHR flag is set so the
RPF interface stays irrelevant to use_rpt eval. But on the non-DR the
IIF is the only way to know we are directly connected to the SG i.e.
to know that we must NOT switch the source to RPT.

This commit fixes up the order of use_rpt eval -
1. it is done before mroute programming
2. but after IIF setup, for SRC_NOCACHE and STATIC_IIF upstream entries

Note: drop an unnecessary check to verify that the RPF interface is
pim enabled. This is just to make the code consistent.

Ticket: CM-27446

Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: OIF add with PROTO_PIM is not happening if join rxed in PP state
Dumps while in problem state -
============================
[from "show ip pim state"]
Active Source           Group            RPT  IIF               OIL
1      6.0.0.31         239.1.1.111      n    swp1              swp4( J * )
[from "show ip pim join"]
Interface        Address         Source          Group           State      Uptime   Expire Prune
swp3             6.0.0.22        6.0.0.31        239.1.1.111     JOIN       --:--:-- 03:11  --:--

You can see from the dumps that the pim downstream router has joined on
swp3 but that OIF has not been added to the OIL with flag
PIM_OIF_FLAG_PROTO_PIM. This is because the join was rxed while the
ifchannel was in a prune-pending state.

Relevant logs -
===============
[
PIM: recv_prune: prune (S,G)=(6.0.0.31,239.1.1.111) rpt=1 wc=0 upstream=6.0.0.22 holdtime=210 from 6.0.0.28 on swp3
PIM: pim_upstream_ref(pim_ifchannel_add): upstream (6.0.0.31,239.1.1.111) ref count 3 increment
PIM: pim_upstream_add(pim_ifchannel_add): (6.0.0.31,239.1.1.111), iif 6.0.0.26/0 (swp1) found: 1: ref_count: 3
PIM: pim_ifchannel_add: ifchannel (6.0.0.31,239.1.1.111) is created
PIM: pim_joinprune_recv: SGRpt flag is set, del inherit oif from up (6.0.0.31,239.1.1.111)
PIM: pim_mroute_add(pim_channel_del_oif), vrf default Added Route: (6.0.0.31,239.1.1.111) IIF: swp1, OIFS: swp4
PIM: pim_channel_del_oif(pim_joinprune_recv): (S,G)=(6.0.0.31,239.1.1.111): proto_mask=4 IIF:1 OIF=swp3 vif_index=3
PIM: recv_join: join (S,G)=(6.0.0.31,239.1.1.111) rpt=0 wc=0 upstream=6.0.0.22 holdtime=210 from 6.0.0.28 on swp3
PIM: PIM_IFCHANNEL(swp3): (6.0.0.31,239.1.1.111) is switching from SGRpt(PP) to JOIN
PIM: Sending Request for New Channel Oil Information(6.0.0.31,239.1.1.111) VIIF 1(default)
]

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: replace direct accesses to t_ka_timer with a kat_running macro
No functional change, simple cleanup to improve readability

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup JD macro to use "peer-msdp-sa" check instead of I_am_RP check
JD macro is defined by the RFC as -
bool JoinDesired(S,G) {
    return (immediate_olist(S,G) != NULL
        OR (KeepaliveTimer(S,G) is running
        AND inherited_olist(S,G) != NULL))
}

However for MSDP synced SA the KAT will not be running so an exception is
needed. Earlier I had done this by relaxing KAT_run requirements entirely
on the RP. However as that prevents the source from being aged out in some
cases I have made the check more narrow i.e. has to an MSDP peer added
entry.

Ticket: CM-24398

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: build a temp copy of the OIL for kernel mroute add
1. This avoids the needs to re-run "muting" decisions.
2. Avoids the need to restore's pim OIL after fixup and send to kernel
(this is getting harder to manage).

In the future we need to also move the PIM maintained channel OIL from
an array of MAXVIFs to a simple DLL. This will be a significant
optimization in memory usage and preformance (OIL reads, copies etc).

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: fixup pim_channel_oil_empty macro
The macro was always returning non-empty because of comparing an
array of u8_t with an array of u32_t.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: we cannot change the Joined state based on RPF resolution
Joined state is computed based on the downstream state and cannot be
changed if the RPF link flaps.

Reference: rfc 7761, section 4.5.5

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: drop redundant checks for RPF interface
pim_upstream_kat_start_ok was checking if RPF interface was present,
twice!

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: prevent LHR from register forwarding packets for non-FHR sources
SPT switchover handling is done by adding pimreg in the OIL of the (*, G)
entry on the LHR. This causes multicast data with that destination to be
sent to pimd as IGMPMSG_WHOLEPKT. These packets trigger creation of (S,G)
and also register forwarding. However register forwarding must only be done
if the router is also a FHR. That FHR check was missing causing strange
source registrations from multicast routers that were not directly
connected to the source.

Relevant logs from LHR -
PIM: pim_mroute_msg: pim kernel upcall WHOLEPKT type=3 ip_p=0 from fd=9 for (S,G)=(6.0.0.30,239.1.1.111) on pimreg vifi=0  size=98
PIM: Sending (6.0.0.30,239.1.1.111) Register Packet to 81.0.0.5
PIM: pim_register_send: Sending (6.0.0.30,239.1.1.111) Register Packet to 81.0.0.5 on swp2

And 6.0.0.30 is clearly not directly connected on that router -
root@tor-11:~# ip route |grep 6.0.0.30 -A2
6.0.0.30 proto ospf metric 20
        nexthop via 6.0.0.22 dev swp1 weight 1 onlink
        nexthop via 6.0.0.23 dev swp2 weight 1 onlink
root@tor-11:~#

Ticket: CM-24549

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
7193 passed
FRR › FRR › #2399 7 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 8 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 9 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 9 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 8 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 1 year 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 1 year 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 1 year 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 10 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 11 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 1 year 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 1 year 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: 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: 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>
6890 passed