ZEBRA_IMPORT_CHECK_UPDATE has been gone for more than a year; remove
some leftover dead references to it.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
1. Added interface name, group address and detail option to existing
"show ip igmp groups" so that user can retrieve all the groups
or a particular group for an interface. Detail option shows the source
information for the group. With that, the show command
looks like:
"show ip igmp [vrf NAME$vrf_name] groups [INTERFACE$ifname [GROUP$grp_str]] [detail$detail] [json$json]"
2. Changed pim_cmd_lookup_vrf() to return empty JSON if VRF is not present
3. Changed "detail" option to print non pretty JSON
4. Added interface name and group address to existing
"show ip igmp sources" so that user can retrieve all the sources for
all the groups or, all the sorces for a particular group for an
interface. With that, the show command looks like:
"show ip igmp [vrf NAME$vrf_name] sourcess [INTERFACE$ifname [GROUP$grp_str]] [json$json]"
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Topology Used:
=============
Cisco---FRR4----FRR2
Initially PIM nbr is down between FRR4----FRR2 from FRR2 side
Cisco is sending BSR packet to FRR4.
Problem Statement:
=================
No shutdown the PIM neighbor on FRR2 towards FRR4.
FRR2, receives BSR packet immediately as the new neighbor
comes up. This BSR packet is having no-forward bit set.
FRR2 is not able to process the BSR packet, and drop the
BSR packet.
Root Cause:
==========
When PIMD comes up, we start BSM timer for 60 seconds.
Here, the value accept_nofwd_bsm is setting to false.
FRR2, when receives no-forward BSR packet, it is getting
accept_nofwd_bsm value as false.
So, it drops, the no-forward BSM packet.
Fix:
===
Set accept_nofwd_bsm as false after first BSM packet received.
Signed-off-by: Sarita Patra <saritap@vmware.com>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
After doing "no ipv6 pim" and "ipv6 pim" on receiver interface in LHR,
mroutes were not created.
When we enable pim after disabling it, we refresh the membership on pim interface.
First we clear the membership on the interface, then we add it back.
For PIMv6 we were only clearing it, membership was not added back. So mroutes were not created.
Now added code to fetch all the local membership information into PIM.
Fixes: #12005, #12820
Signed-off-by: Abhishek N R <abnr@vmware.com>
We have this valgrind trace:
==1125== Invalid read of size 4
==1125== at 0x170A7D: pim_if_delete (pim_iface.c:203)
==1125== by 0x170C01: pim_if_terminate (pim_iface.c:80)
==1125== by 0x174F34: pim_instance_terminate (pim_instance.c:68)
==1125== by 0x17535B: pim_vrf_terminate (pim_instance.c:260)
==1125== by 0x1941CF: pim_terminate (pimd.c:161)
==1125== by 0x1B476D: pim_sigint (pim_signals.c:44)
==1125== by 0x4910C22: frr_sigevent_process (sigevent.c:133)
==1125== by 0x49220A4: thread_fetch (thread.c:1777)
==1125== by 0x48DC8E2: frr_run (libfrr.c:1222)
==1125== by 0x15E12A: main (pim_main.c:176)
==1125== Address 0x6274d28 is 1,192 bytes inside a block of size 1,752 free'd
==1125== at 0x48369AB: free (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1125== by 0x174FF1: pim_vrf_delete (pim_instance.c:181)
==1125== by 0x4925480: vrf_delete (vrf.c:264)
==1125== by 0x4925480: vrf_delete (vrf.c:238)
==1125== by 0x49332C7: zclient_vrf_delete (zclient.c:2187)
==1125== by 0x4934319: zclient_read (zclient.c:4003)
==1125== by 0x492249C: thread_call (thread.c:2008)
==1125== by 0x48DC8D7: frr_run (libfrr.c:1223)
==1125== by 0x15E12A: main (pim_main.c:176)
==1125== Block was alloc'd at
==1125== at 0x4837B65: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==1125== by 0x48E80AF: qcalloc (memory.c:116)
==1125== by 0x1750DA: pim_instance_init (pim_instance.c:90)
==1125== by 0x1750DA: pim_vrf_new (pim_instance.c:161)
==1125== by 0x4924FDC: vrf_get (vrf.c:183)
==1125== by 0x493334C: zclient_vrf_add (zclient.c:2157)
==1125== by 0x4934319: zclient_read (zclient.c:4003)
==1125== by 0x492249C: thread_call (thread.c:2008)
==1125== by 0x48DC8D7: frr_run (libfrr.c:1223)
==1125== by 0x15E12A: main (pim_main.c:176)
and you do this series of events:
a) Create a vrf, put an interface in it
b) Turn on pim on that interface and turn on pim in that vrf
c) Delete the vrf
d) Do anything with the interface, in this case shutdown the system
The move of the interface to a new vrf is leaving the pim_ifp->pim pointer pointing
at the old pim instance, which was just deleted, so the instance pointer was freed.
Let's clean up the pim pointer in the interface pointer as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
After restarting pim6d, in some cases the ifindex is 0 for the interfaces,
so the vif index is also assigned as 0.
This causes the interface name to be pim6reg.
Fix:
If the ifindex is 0 and the interface name is not "pimreg" or "pim6reg",
the function will return without assigning vifindex with an error message.
Issue: #12744
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
When hitting gm_sg_update from the S,G expiry timer, t_sg_expire will
already be cancelled. But when arriving there from e.g. the MLD packet
getting cleared out, it'll still be running.
Clear out the timer if we arrive with `has_expired == true`.
Fixes: #12441
Reported-by: Vijay Kumar Gupta <vijayg@vmware.com>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
While configuring global or non-multicast address for IPv6 mld join command,
displaying a custom error-message "invalid multicast address"
Signed-off-by: Sai Gomathi N <nsaigomathi@vmware.com>
New correct behavior:
eva# conf
eva(config)# ip pim rp 192.168.1.224 224.0.0.0/24
No Path to RP address specified: 192.168.1.224
eva(config)# ip pim rp 224.1.2.3 224.0.0.0/24
% Bad RP address specified: 224.1.2.3
eva(config)#
Fixes: #12970
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If the pimreg device exists but it has not been set to the pim->pimreg pointer we can have
a crash. Just prevent the crash since it's some sort of startup / re-org the network
issue.
(gdb) bt
0 0x00007f0485b035cb in raise () from /lib/x86_64-linux-gnu/libpthread.so.0
1 0x00007f0485c0fbec in core_handler (signo=6, siginfo=0x7ffdc0198030, context=<optimized out>) at lib/sigevent.c:264
2 <signal handler called>
3 0x00007f04859668eb in raise () from /lib/x86_64-linux-gnu/libc.so.6
4 0x00007f0485951535 in abort () from /lib/x86_64-linux-gnu/libc.so.6
5 0x00007f0485c3af76 in _zlog_assert_failed (xref=xref@entry=0x55692269b940 <_xref.23164>, extra=extra@entry=0x0) at lib/zlog.c:680
6 0x00005569226150d0 in pim_if_new (ifp=0x556922c82900, gm=gm@entry=false, pim=pim@entry=false, ispimreg=ispimreg@entry=true,
is_vxlan_term=is_vxlan_term@entry=false) at pimd/pim_iface.c:124
7 0x0000556922615140 in pim_if_create_pimreg (pim=pim@entry=0x556922cc11e0) at pimd/pim_iface.c:1549
8 0x0000556922616bc8 in pim_if_create_pimreg (pim=0x556922cc11e0) at pimd/pim_iface.c:1613
9 pim_ifp_create (ifp=0x556922cc0e70) at pimd/pim_iface.c:1641
10 0x00007f0485c32cf9 in zclient_interface_add (cmd=<optimized out>, zclient=<optimized out>, length=<optimized out>, vrf_id=77) at lib/zclient.c:2214
11 0x00007f0485c3346a in zclient_read (thread=<optimized out>) at lib/zclient.c:4003
12 0x00007f0485c215ed in thread_call (thread=thread@entry=0x7ffdc0198880) at lib/thread.c:2008
13 0x00007f0485bdbbc8 in frr_run (master=0x556922a10470) at lib/libfrr.c:1223
14 0x000055692260312b in main (argc=<optimized out>, argv=0x7ffdc0198b98, envp=<optimized out>) at pimd/pim_main.c:176
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Topology:
========
FHR----Source
Problem:
=======
When FHR receives multicast traffic, there is no RP configured,
PIMD does NHT register for RP address 0.0.0.0 and group 224.0.0.0/4
PIM6D does NHT register for RP address 0::0 and group FF00::0/8
frr# show ip pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
frr# show ipv6 pim nexthop
Number of registered addresses: 1
Address Interface Nexthop
---------------------------------------------
Fix:
====
Dont track nexthop for RP 0.0.0.0 & 0::0.
frr# show ip pim nexthop
Number of registered addresses: 0
frr# show ipv6 pim nexthop
Number of registered addresses: 0
Issue: #12104
Signed-off-by: Sarita Patra <saritap@vmware.com>
Topology:
RP---FHR---Source
Problem Statement:
1. In FHR, Enable PIM and IGMP on source connected interface
2. Start multicast traffic. (s,g) mroute and upstream will be created as expected.
3. Disable PIM on source connected interface.
4. Disable IGMP on source connected interface.
5. Stop the traffic.
Mroute will never get timeout.
Root Cause:
In FHR, when PIMD receive multicast data packet on
source connected interface which is IGMP enabled, but PIM
not enabled. PIMD process the packet, install the
mroute and start the KAT timer.
Fix:
Don't process multicast data packet received on PIM disabled
Signed-off-by: Sarita Patra <saritap@vmware.com>
Topology:
=========
RP---FHR<ens224>---Source
Problem Statement:
=================
Step 1:
Enable PIM and IGMP on source connected interface ens224
Step 2:
Start multicast traffic. (s,g) mroute and upstream will be created as expected.
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM ens224 pimreg 1 00:37:55
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:37:57 --:--:-- --:--:-- 00:02:43 1
Step 3:
Disable PIM on source connected interafce ens224
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM ens224 pimreg 1 00:38:05
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:38:08 --:--:-- --:--:-- 00:02:32 1
Step 4:
Disable IGMP on source connected interface ens224
dev# show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
ens224 50.0.0.4 225.1.1.1 NotJ,RegJ 00:38:15 --:--:-- --:--:-- 00:03:27 1
dev# show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit for SSM FHR
Source Group Flags Proto Input Output TTL Uptime
50.0.0.4 225.1.1.1 SF PIM <iif?> pimreg 1 00:38:18
Pim upstream IIF is still pointing towards the source connected
interface which is not pim enabled and not IGMP enabled and
Mroute is still present in the kernel and KAT timer is still running
on the interface, where ifp->info is already set to NULL.
This leads to crash.
Root Cause:
==========
When "no ip pim" commands get executed on source connected interface,
we are updating upstream IIF only when IGMP is not enabled on the same
interface.
Fix:
===
When PIM is disabled on source connected interface, update upstream IIF
no matter if IGMP is enabled or not on the same interface.
Issue: #12848
Issue: #10782
Signed-off-by: Sarita Patra <saritap@vmware.com>
Before fix:
==========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
After fix:
=========
frr(config-if)# do show ipv6 mld interface
Interface State Address V Querier QuerierIp Query Timer Uptime
ens224 up fe80::250:56ff:feb7:a7e3 1 local fe80::250:56ff:feb7:a7e3 00:01:22.263 00:08:00.237
Issue: #11241
Signed-off-by: Sarita Patra <saritap@vmware.com>
We should not display down interfaces or MLD disabled interfaces in
"show ipv6 mld interface" command.
Before fix:
==========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens192 up 2 fe80::250:56ff:feb7:d04 query 00:00:25.432 00:00:07.038
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
pim6reg down
After fix:
=========
frr# show ipv6 mld interface
Interface State V Querier Timer Uptime
ens192 up 2 fe80::250:56ff:feb7:d04 query 00:00:25.432 00:00:07.038
ens224 up 1 fe80::250:56ff:feb7:a7e3 query 00:00:24.219 00:00:07.031
Issue: #11241
Signed-off-by: Sarita Patra <saritap@vmware.com>
When upstream RPF address is secondary address, and
neighborship is built with primary address,
then pim_neighbor_find() fails.
Verify the upstream RPF address is present in the
neighbor primary and secondary address list.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When upstream RPF address is secondary, and
neighborship is built with primary address,
then pim_neighbor_find() fails, due to which when there
is upstream change it wont send prune.
Verify the nexthop is present in the neighbor primary
and secondary address list.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When there is a mismatch in nexthop address (secondary address)
and neighborship address(primary address) on the same interface,
RPF check fails.
This is fixed now.
Signed-off-by: Sarita Patra <saritap@vmware.com>
When route to RP is having nexthop secndary address,
neighborship is built with primary address,
then pim_neighbor_find() fails, which causes RP IIF
Unknown.
Fix:
Verify pim neighborship on the RP connected interface.
Issue: #11526
Signed-off-by: Sarita Patra <saritap@vmware.com>
Problem 1:
When route to BSR is having nexthop secondary address,
neighborship is built with primary address,
then pim_neighbor_find() fails, which cause drop of BSM
packet.
Fix 1:
Verify pim neighborship on the BSM received interface.
Problem 2:
Problem 2:
Source IP BSM address is primary address, where
as nexthop also can be primary or secondary address.
Fix 2:
Avoiding the check (nhaddr == src_ip) for PIMV6
Issue: #11957
Signed-off-by: Sarita Patra <saritap@vmware.com>
For incoming no-receiver SSM traffic, there isn't going to be a RP, much
less a RPF. We should install an MFC entry with empty oif regardless,
so we don't get swamped with further notifications.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Whether due to a pimd bug, some expiry, or someone just deleting MFC
entries, when we're in NOCACHE we *know* there's no MFC entry. Add an
install call to make sure pimd's MFC view aligns with the actual kernel
MFC.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This path here is pretty far on top of the list of issues that operators
will run into and have to debug when setting up PIM. Make the log
messages actually tell what's going on. Also escalate some from
`debug mroute detail` to `debug mroute`.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Coverity complains that MLAG_MSG_NONE cannot be reached in
the switch statement. Which is true so let's make it happy.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
