anuradhak <anuradhak@cumulusnetworks.com>: Author Summary

Builds triggered by anuradhak <anuradhak@cumulusnetworks.com>

Builds triggered by an author are those builds which contains changes committed by the author.
3
0 (0%)
3 (100%)

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.
0 (0% of all builds triggered)
0 (0% of all builds triggered)
0
Build Completed Code commits Tests
FRR › FRR › #139 1 year ago
pimd: Allow SSM groups to co-exist with ASM groups.
SSM groups (232/8 or user configured SSM range) can exist in the same
multicast network as ASM groups. For such groups all RPT related state
machine operations have to be skipped as defined by section 4.8 of
RFC4601 -
1. Source registration is skipped for SSM groups. For SSM groups mroute
is setup on the FHR when a new multicast flow is rxed; however source
registration (i.e. pimreg join) is skipped. This will let the ASIC black
hole the traffic till a valid OIL is added to the mroute.
2. (*,G) IGMP registrations are ignored for SSM groups.

Sample output:
=============
fhr#  sh ip pim group-type
SSM group range : 232.0.0.0/8
fhr#  sh ip pim group-type 232.1.1.1
Group type: SSM
fhr#  sh ip pim group-type 239.1.1.1
Group type: ASM
fhr#

Sample config:
=============
fhr(config)# ip pim ssm prefix-list ssm-ranges
fhr(config)#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-15344
Testing Done:
1. SSM/ASM source-registration/igmp-joins.
2. On the fly multicast group type changes.
3. pim-smoke.
pimd: Fix pim_ssm build failure by including zebra.h
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: Remove interface type SSM.
Interface type has been replaced with the SSM range config. And SSM
groups can now co-exists with ASM groups. I have left the pim ssm
per-interface cli control hidden. It now enables pim-sm with a warning.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-15344
Testing Done: pim-smoke
2771 passed
FRR › FRR › #124 2 years ago
pimd: add new/distinct enumeration for pim register state
With the separation of register-state and upstream-join-state we no
longer need an enumeration that covers both states. This commit includes
the following -
1. Defined new enumeration for reg state (this 1:1 with RFC4601).
2. Dropped JOIN_PENDING enum value from upstream join state. RFC4601
only define two values NOT_JOINED and JOINED for this state.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-14700
Testing Done: Verified register setup manually and ran pim-smoke
pimd: simplify pim upstream state transitions
This is another follow-up change to the reg-state and up-join-state
separation. The upstream join state machine can now respond to
JoinDesired macro changes independent of router role.

I have also dropped the PRUNE state from the upstream-join-state
enumeration. RFC4601 only defines JOINED and NOTJOINED states. And PRUNE
can really be replace by NOTJOINED.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-14700
Testing Done: Register state machine in FHR only, combined FHR-RP and
FHR-RP-LHR/all-in-one setups. Also ran pim-smoke.
pimd: Separate the register and upstream join states on the FHR
On the FHR upstream-join-state is not particularly relevant as we
don't need to send upstream JPs for the SG. So that field was being
overloaded with the register-state. However some of the events that
triggered changes to the JoinDesired macro were accidentally overwriting
the state with join info (instead of treating it as register info)
confusing the register state machine.

To make the PIM RFC macros' implemention simple I have separated out
the register-state. And upstream->state now solely describes the
upstream-join-state independent of the role of the PIM router.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-14700
Testing Done: verified pim-register state-machine with separate and
combined FHR/RP routers. Also ran pim-smoke.
pimd: display reg-state and join-state info in the pim_upstream output
Changed the state field in the "sh ip pim upstream" output to include
register and join state info as a comma separated value. Register info
is supressed if reg-state=NoInfo.

Sample output:
=============
root@fhr:/home/cumulus# net show pim upstream
Iif       Source          Group           State       Uptime   JoinTimer
RSTimer   KATimer   RefCnt
swp1      33.1.1.1        239.1.1.2       J,RegP      00:00:18 --:--:--
00:00:44  00:03:24       2
root@fhr:/home/cumulus#

root@rp:/home/cumulus# net show pim upstream
Iif       Source          Group           State       Uptime   JoinTimer
RSTimer   KATimer   RefCnt
lo        *               239.1.1.2       J           00:02:08 00:00:52
--:--:--  --:--:--       1
swp1      33.1.1.1        239.1.1.2       J           00:00:16 00:00:11
--:--:--  00:03:26       1
root@rp:/home/cumulus#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>

Ticket: CM-14700
Testing Done: pim-smoke
2771 passed
FRR › FRR › #46 2 years ago
pim-nexthop: mroute and pim-upstream rpf are falling out of sync.
Currently the mroute-IIF and upstream RPF-IIF/neigh are resolved separately.
This must change i.e. be merged together for a couple of reasons -
1. In the case of ECMP we will use a load-share mechanism (based on G or
SG) to pick an RPF neighbor in 3.2.1 (to use the load-sharing cap of
anycast-RP). Using a different resolution mechanism for mroute-IIF will
simply not work.
2. In a non-CLOS topology it is actually possible to have routers that
do not participate in PIM. In this case the tree will be set up using
different routers than the ones chosen for the mroute IIF. And traffic
will not be forwarded.

This change is however too big for 3.2.0. So to handle CM-13714 I have
simply forced rpf update on neigh add which fixes the specific problem
seen on link flap in a clos (it is not very efficient but traffic
recovers).
In problem state -
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus# ip mr
(0.0.0.0, 225.1.1.1)             Iif: lo         Oifs: swp3 lo
(20.0.11.253, 225.1.1.1)         Iif: swp1       Oifs: swp3
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus# vtysh -c
"show ip pim upstream"
Iif       Source          Group           State       Uptime   JoinTimer
RSTimer   KATimer   RefCnt
lo        *               225.1.1.1       Joined      00:08:44 00:00:15
--:--:--  --:--:--       1
swp2      20.0.11.253     225.1.1.1       Joined      00:08:35 00:00:56
--:--:--  00:02:59       1
(jessie-30-dev-switch-amd64-sbuild)root@spine-1:/home/cumulus#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd: Drop local SA reference when the upstream SG is deleted
This is done irrespective of the reason for del and is intended as a
catchall for cases (unclear which ones) where the RP can drop the SG
without KAT expiry.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-msdp: Fix pimd crash on mesh-group delete.
The mesh group contents were being accessed after memory was freed.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: make the json output a bit more machine-friendly
Mixing well-known and variable property names makes the output difficult
to parse. so wrapped variable-keyed dicts with well-known property
names (such as "oil") in the following outputs -
"show ip mroute json"
"show ip msdp mesh-group json"

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Reviewed-by: Daniel Walton <dwalton@cumulusnetworks.com>
pim-anycast-rp: Support in BGP unnumbered networks.
Anycast rp requires multiple ip addresses on the lo. If PIM is used in
an unnumbered BGP network it picks one of the lo addresses as the
pim-primary for the swp interfaces. But if the anycast IP is picked up
by both sides pim nbr will never converge. So a static "use-source" config
is provided to allow the administrator to force the the hello source to the
unique IP address.

Sample output:
=============
dell-s6000-04(config-if)# do show running-config pimd
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
interface lo
 ip pim sm
 ip pim use-source 100.1.1.5
!
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
dell-s6000-04(config-if)# do show ip pim interface lo
Interface  : lo
State      : up
Use Source : 100.1.1.5
Address    : 100.1.1.5 (primary)
             100.1.1.100
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>
dell-s6000-04(config-if)# do show ip pim interface lo json
{
  "lo":{
    "name":"lo",
    "state":"up",
    "address":"100.1.1.5",
    "index":1,
    "lanDelayEnabled":true,
    "useSource":"100.1.1.5",
    "secondaryAddressList":[
      "100.1.1.100"
    ],
>>>>>> SNIPPED >>>>>>>>>>>>>>>>>

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim-nexthop: set the correct nexthop address in the rpf info.
When a nexthop lookup is done we can get an ECMP output. But not all
nexthops are pim neighbors. If for this reason PIM chose a nexthop other
than the first the rpf info was not being set correctly i.e.
nexthop ip was still the one associated with the first path but
interface was set to the one associated with second path.

This problem is seen on a link flap in the CLOS topology.

Ticket: CM-13714
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim-msdp: CLI and debug cleanup
No functional change.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-anycast-rp: Change the reason code on use-source config failure.
Was failing with a vague error -
"Source set failed"

Changed to used the error string (used by the rest of the commands) -
"Pim not enabled on this interface"

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-kat: changed kat handling to match rfc-4601 more closely.
1. This is needed to layout the MSDP macros for determining what SAs are
originated by a MSDP speaker.
2. We no longer let the kat timer expire on an active flow. Activity
counters/lastuse is polled via a wheel for every SG entry. If new
activity is detected the keepalive timer is started and SPT bit set.
A SRC_STREAM reference is also created for the entry if one doesn't
already exist.
3. If KAT actually expires it means the flow is no longer active. At
this point we stop advertising the SA to MSDP peers. We also pull
the SRC_STREAM reference (deleting the entry if there are no other
references).

PS: Checking counters on KAT expiry will come in the next change.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim-msdp: cleanup debug commands
And fixup display spacing. No functional change.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: Fix the number of SAs pushed into one MSDP SA-TLV
The entry_cnt in a SA TLV is one byte. I was trying to push 765 SAs into
each TLV resulting in strange problems in a scale setup.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: restart the ka timer after the sa adv timer
To avoid unnecessary ka activity in the network. When the SA
advertisment timer fires we build SA TLVs and send them to peers. As a
part of this tx we were also restarting the ka timer to avoid
unnecessary ka generation in the next 60 seconds. However because the
adv timer was restarted after tx (i.e. after ka restart) ka timer would
always endup firing just before the adv timer.
pim-msdp: part-4: cli cleanup
1. Add support for mesh-group based configuration that is easy to apply
via automation. The older per-peer configuartion is temporarily hidden
and will be cleaned up later.
Sample config -
ip msdp mesh-group cumulus source 100.1.1.4
ip msdp mesh-group cumulus member 100.1.1.5
ip msdp mesh-group cumulus member 100.1.1.6

2. Added support for detail peer and sa-cache displays. Along with
filter keys.

3. Add json output for all the msdp displays.

With this commit basic support for anycast-RP with MSDP (in numbered
network is complete). Unnumbered support will be added separately.

Ticket: CM-13306

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pim-msdp: Update the RP address in the SA cache entry on peer ip change
The RP address in the SA is only for informational/display purposes. It
is still confusing if we show a stale value.

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pim-anycast-rp: Add limited support for secondary addresses.
Anycast requires that the lo interface be associated with multiple
addresses. One is the anycast IP address (which is the same on all RPs
participating in RP redundancy) and the second is the unique IP address
that will be used as the router id by routing protocols.

To accomodate that we maintain a list of secondary addresses per-pim iface
and allow any of them to be the RP address. This lets the I_am_RP macro
succeed on anycast RPs.

Note that the support is limited i.e. we don't actually advertise a
secondary list to the neighbors. This is assuming the anycast IP will never
be used as a router id i.e. will never be an RPF neighbor.

Sample output:
==============
dell-s6000-04# sh ip pim interface lo
Interface : lo
State     : up
Address   : 100.1.1.1 (primary)
            100.1.1.2
            100.1.1.3
            100.1.2.1
>>>>>>> SNIP >>>>>>>>>>>>>>>
dell-s6000-04# sh ip pim interface lo json
{
  "lo":{
    "name":"lo",
    "state":"up",
    "address":"100.1.1.1",
    "index":1,
    "lanDelayEnabled":true,
    "secondaryAddressList":[
      "100.1.1.2",
      "100.1.1.3",
      "100.1.2.1"
    ],
>>>>>>> SNIP >>>>>>>>>>>>>>>
dell-s6000-04#sh ip pim rp-info
RP address       group/prefix-list   OIF         I am RP
100.1.2.1        224.0.0.0/4         lo          yes
dell-s6000-04#

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
Acked-by: Donald Sharp <sharpd@cumulusnetworks.com>
pimd: increase the maximum msdp TLV burst to 100 from 12
12 is too slow of a slow-start in scale setup (say with 6000 SAs)
when sources are being learnt one at a time (but in a rapid fire
fashion).

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: Add debug logs to help find problems with stream_read
Logs only. No functional change
Ticket: CM-13852

Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
pimd: reset packet size on tcp connection reset
If we were in the middle of a partial read when the tcp connection is
reset we were clearing the buffers but not the packet size. This can be
problematic when the connection is re-established.

There is no easy way to repro and test this without scale (and a timing
pattern that is hard to predict). So this change is mostly untested.

Ticket: CM-13852
Signed-off-by: Anuradha Karuppiah <anuradhak@cumulusnetworks.com>
2592 passed
Build Completed Code commits Tests
Build Completed Code commits Tests