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>
(cherry picked from commit 201a31b977)
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>
(cherry picked from commit 7ae7a3bfd6)
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>
(cherry picked from commit d77da853f0)
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>
(cherry picked from commit 689b9f10fc)
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>
(cherry picked from commit e14ba24874)
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>
(cherry picked from commit ae5bcac0ae)
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>
(cherry picked from commit 2c6a32f9be)
Modify pim_neighbor_find() API to find the neighbor
in neighbor secondary list.
Signed-off-by: Sarita Patra <saritap@vmware.com>
(cherry picked from commit 3dbf370ac0)
Once RP/BSR address is learned in PIMD, PIMD does nexthop tracking
in Zebra.
For IPV6 address, the nexthop type is either NEXTHOP_TYPE_IPV6
or NEXTHOP_TYPE_IPV6_IFINDEX.
Zebra should send nexthop ifindex information along with nexthop address
to the client (PIMD).
Issue: #11526
Issue: #11957
Signed-off-by: Sarita Patra <saritap@vmware.com>
(cherry picked from commit ed9323604a)
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>
(cherry picked from commit cbb1e51311)
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>
(cherry picked from commit fe4db62c3d)
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>
(cherry picked from commit 9e01548593)
It was hard to catch those unless using higher values than uint32_t, but
already hit, it's time to fix completely.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit d782e3ffa2)
Since we increased peer->af_flags from uint32_t to uint64_t,
peer_af_flag_check() was historically returning integer, and not bool
as should be.
The bug was that if we have af_flags higher than uint32_t it will never
returned a right value.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit 2c722516c3)
The l2vpn afi was not being properly displayed
when a show run was being issued. Add a
afi2str_lower function and use it.
Fixes: #12867
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 0884f1644b)
According to the flowspec RFC 8955 a flowspec nlri is <length, <nlri data>>
Specifying 0 as a length makes BGP get all warm on the inside. Which
in this case is not a good thing at all. Prevent warmth, stay cold
on the inside.
Reported-by: Iggy Frankovic <iggyfran@amazon.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 0b999c886e)
Before:
```
r1# sh ip bgp wide
BGP table version is 1, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* 172.16.255.254/32 192.168.2.2 0 0 (65003) i
*> 192.168.1.2 0 0 (65002) i
Displayed 1 routes and 2 total paths
r1#
```
After:
```
r1# sh ip bgp wide
BGP table version is 1, local router ID is 192.168.2.1, vrf id 0
Default local pref 100, local AS 65001
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* 172.16.255.254/32 192.168.2.2 0 0 (65003) i
*> 192.168.1.2 0 0 (65002) i
Displayed 1 routes and 2 total paths
r1#
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit fccd7e53db)
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>
Sometimes bgp connections can be rejected for a variety of reasons. Give
a bit more context about what is going wrong so that the operator can
make better decisions about their network.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 7c5062fb27)
An rfapi timer callback is responsible for the memory in a
context object, even in special-case exit paths. Always
free that object.
Signed-off-by: Mark Stapp <mjs@labn.net>
(cherry picked from commit 870d3d2cb8)
When we specify remote-as as external/internal, we need to set local_as to
bgp->as, instead of bgp->confed_id. Before this patch, (bgp->as != *as) is
always valid for such a case because *as is always 0.
Also, append peer->local_as as CONFED_SEQ to avoid other side withdrawing
the routes due to confederation own AS received and/or malformed as-path.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
(cherry picked from commit db5a5ee6e4)
- dont delete the callback on opaque data delete
- require explicit registration
Signed-off-by: Christian Hopps <chopps@labn.net>
(cherry picked from commit 703d2c0a3e)
