frr
frr copied to clipboard
An invalid S,G entry gets created on LHR node with LHR network after configuration of static IGMP join
*** ATTENTION ***
YOU MUST READ THIS TO HAVE YOUR ISSUE ADDRESSED
PLEASE READ AND FILL OUT THIS TEMPLATE
NEGLECTING TO PROVIDE INFORMATION REQUESTED HERE WILL RESULT IN SIGNIFICANT DELAYS ADDRESSING YOUR ISSUE
ALWAYS PROVIDE:
- FRR Version 8.2.2
- Debian GNU/Linux 10 (buster)
- 5.13.0-52-generic
LHR(config)#
LHR(config)# do show ru
Building configuration...
Current configuration:
!
frr version 8.2.2
frr defaults traditional
hostname LHR
log syslog informational
no ipv6 forwarding
ip pim rp 1.1.1.1 224.0.0.0/4
service integrated-vtysh-config
!
interface eth3
ip address 30.1.1.2/24
ip ospf area 0
ip pim
exit
!
interface eth4
ip address 40.1.1.1/24
ip igmp
ip ospf area 0
ip pim
exit
!
router ospf
exit
!
end
LHR(config)#
LHR(config)# do show ip igmp gr
Total IGMP groups: 1
Watermark warn limit(Not Set): 0
Interface Group Mode Timer Srcs V Uptime
eth4 225.1.1.1 ---- 00:04:19 1 2 00:03:52
LHR(config)#
LHR(config)# do show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit set
Source Group Flags Proto Input Output TTL Uptime
* 225.1.1.1 SC IGMP eth3 pimreg 1 00:01:47
IGMP eth4 1
LHR(config)#
LHR(config)# do show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
eth3 * 225.1.1.1 J 00:02:43 00:00:48 --:--:-- --:--:-- 1
LHR(config)#
LHR(config)# do show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
O>* 1.1.1.1/32 [110/10000] via 30.1.1.1, eth3, weight 1, 00:03:40
O>* 10.1.1.0/24 [110/20000] via 30.1.1.1, eth3, weight 1, 00:03:50
O 30.1.1.0/24 [110/10000] is directly connected, eth3, weight 1, 00:04:45
C>* 30.1.1.0/24 is directly connected, eth3, 00:04:47
O 40.1.1.0/24 [110/10000] is directly connected, eth4, weight 1, 00:04:57
C>* 40.1.1.0/24 is directly connected, eth4, 00:05:02
O>* 172.16.0.0/24 [110/30000] via 30.1.1.1, eth3, weight 1, 00:02:55
LHR(config)#
LHR(config)# interface eth4
LHR(config-if)#
LHR(config-if)# ip igmp join 225.1.1.1 172.16.0.50
LHR(config-if)#
LHR(config-if)# do show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit set
Source Group Flags Proto Input Output TTL Uptime
* 225.1.1.1 SC IGMP eth3 pimreg 1 00:00:03
IGMP eth4 1
40.1.1.2 225.1.1.1 SF PIM eth4 pimreg 1 00:00:03
PIM eth3 1
LHR(config-if)#
LHR(config-if)# do show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
eth3 * 225.1.1.1 J 00:00:06 00:00:58 --:--:-- --:--:-- 1
eth4 40.1.1.2 225.1.1.1 J,RegJ 00:00:06 --:--:-- --:--:-- 00:03:23 3
LHR(config-if)#
LHR(config-if)# do show ru
Building configuration...
Current configuration:
!
frr version 8.2.2
frr defaults traditional
hostname LHR
log syslog informational
no ipv6 forwarding
ip pim rp 1.1.1.1 224.0.0.0/4
service integrated-vtysh-config
!
interface eth3
ip address 30.1.1.2/24
ip ospf area 0
ip pim
exit
!
interface eth4
ip address 40.1.1.1/24
ip igmp
ip igmp join 225.1.1.1 172.16.0.50
ip ospf area 0
ip pim
exit
!
router ospf
exit
!
end
LHR(config-if)#
- frr version 8.2.2
- IGMP v2 report for Group IP 225.1.1.1 is sent from a traffic generator
- The LHR learns the V2 report for 225.1.1.1
- On the interface through which the v2-report is learnt, an IGMP v3 static join is configured for the same group IP address 225.1.1.1 with source IP address in the source network.
- A new S,G entry with group ip address pointing to 225.1.1.1 and a random source IP address from the LHR subnet is added in the mroute entry which does not get deleted even after the static igmp join is deleted.
- on issuing a clear ip mroute * the random entry gets deleted.
- The down stream router's ip address is added in show ip pim upstream which is not right.
Describe the bug
Invalid S,G entry gets created on LHR node with LHR network after configuration of static IGMP join
- [Y] Did you check if this is a duplicate issue?
- [Y] Did you test it on the latest FRRouting/frr master branch?
To Reproduce
- Make sure IGMP and PIM is enabled on the interface connecting the LHR and the traffic generator.
- Send IGMP v2 report from a traffic generator for the group IP 225.1.1.1
- Check if the group is learnt by executing show ip igmp group on the LHR node
- Configure a v3 igmp static join with the same group ip 225.1.1.1 and the source ip pointing to an ip in source subnet
- Execute show ip mroute and you could find an invalid S,G entry with the source IP address pointing to traffic generator IP address or a random IP address with group ip address pointing to 225.1.1.1 is added automatically.
- On executing show ip pim upstream, you could find the down stream router's ip address displayed as PIM upstream IP.
Expected behavior
The expected behavior in this case is that v2 joins should be honoured even if a v3 static join is configured which is happening in the latest FRR code. But the Invalid S,G entry shouldnt be created and the down stream router IP address shouldnt get added as PIM upstream.
Screenshots
LHR(config-if)# do show ip mroute
IP Multicast Routing Table
Flags: S - Sparse, C - Connected, P - Pruned
R - SGRpt Pruned, F - Register flag, T - SPT-bit set
Source Group Flags Proto Input Output TTL Uptime
* 225.1.1.1 SC IGMP eth3 pimreg 1 00:00:03
IGMP eth4 1
**40.1.1.2 225.1.1.1 SF PIM eth4 pimreg 1 00:00:03
PIM eth3 1**
LHR(config-if)# do show ip pim upstream
Iif Source Group State Uptime JoinTimer RSTimer KATimer RefCnt
eth3 * 225.1.1.1 J 00:00:06 00:00:58 --:--:-- --:--:-- 1
**eth4 40.1.1.2 225.1.1.1 J,RegJ 00:00:06 --:--:-- --:--:-- 00:03:23 3**
LHR(config-if)#
LHR(config-if)# do show ru
Building configuration...
Current configuration:
!
frr version 8.2.2
frr defaults traditional
hostname LHR
log syslog informational
no ipv6 forwarding
ip pim rp 1.1.1.1 224.0.0.0/4
service integrated-vtysh-config
!
interface eth4
ip address 40.1.1.1/24
ip igmp
ip igmp join 225.1.1.1 172.16.0.50
ip ospf area 0
ip pim
exit
!
Versions
- OS Version: Debian 10
- Kernel: 5.13.0-52-generic
- FRR Version: 8.2.2
Additional context
Isn't it a configuration mistake? The interface is configured as IGMPv2 but you are configuring the join with (S,G) i.e IGMPv3. I want to understand more on why is this configuration even required?
Also is there a traffic with 40.1.1.2 as source? The traffic generator might be generating that, you can check.
If you can attach the debug logs for this, we can know exactly what is happening.
its not a configuration mistake. If a customer wants to have a multicast stream with zero loss, he would basically configure a static join on the receiver vlan even when we have *,G learnt. Having said that, the invalid S,G entry that gets created with peer IP address shouldnt happen.
There is no traffic in the system but the system for some reason treats the packet as data packet and the NO_CACHE message is received in pim. I would upload the logs at the earliest.
This issue is stale because it has been open 180 days with no activity. Comment or remove the autoclose label in order to avoid having this issue closed.
This issue will be automatically closed in the specified period unless there is further activity.