Nexus not receiving some IGMP Membership reports on the same VLAN

[g748437]

Hello,
I have been dealing with this Multicast issue for over a week now and I can't seem to understand why it's happening.
We have 2 Core Switches

Nexus 5548 with vPC (N5K-C5548UP-SUP, 7.3(5)N1(1)) and a 3750X (C3750X-48PF-S, 15.2(4)E9) stack with 5 SWs

They are connected via Port-channel

4094 (on the NX side) and Po10 (on the 3750 side), Po4096 is the vPC Peer-link.

These are the config for

VLAN interface 880

CORE-1# show run int vlan 880
interface Vlan880
no shutdown
ip address 172.30.80.2/24
ip pim sparse-mode
ip igmp version 3
hsrp version 2
hsrp 880
preempt
priority 80
ip 172.30.80.1




CORE-2(config)# show run int vlan 880
interface Vlan880
no shutdown
ip address 172.30.80.3/24
ip pim sparse-mode
ip igmp version 3
hsrp version 2
hsrp 880
preempt
priority 80
ip 172.30.80.1




CORE-2(config)# show ip igmp snooping mrouter vlan 880
Type: S - Static, D - Dynamic, V - vPC Peer Link
I - Internal, F - Fabricpath core port
C - Co-learned, U - User Configured
P - learnt by Peer
Vlan Router-port Type Uptime Expires
880 Po4096 SVD 24w6d 00:03:31
880 Vlan880 I 1w2d never




CORE-1# show ip igmp snooping mrouter vlan 880
Type: S - Static, D - Dynamic, V - vPC Peer Link
I - Internal, F - Fabricpath core port
C - Co-learned, U - User Configured
P - learnt by Peer
Vlan Router-port Type Uptime Expires
880 Po4096 SV 24w6d never
880 Vlan880 ID 1w2d 00:04:59




CORE-1# show ip igmp snooping querier vlan 880
Vlan IP Address Version Expires Port
880 172.30.80.2 v3 00:03:38 Vlan880 (internal)

CORE-2(config)# show ip igmp snooping querier vlan 880
Vlan IP Address Version Expires Port
880 172.30.80.2 v3 00:03:18 port-channel4096




The core switch is the mrouter for VLAN 880 and the 3750 stack shows the mrouter for VLAN 880 is the nexus:

IDF-3750X#show ip igmp snooping mrouter vlan 880
Vlan ports
---- -----
880 Po10(dynamic)




IDF-3750X#show ip igmp snooping querier vlan 880
IP address : 172.30.80.2
IGMP version : v3
Port : Po10
Max response time : 10s
Query interval : 125s
Robustness variable : 2




IDF-3750X#show ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
880 172.30.80.2 v3 Po10


The problem appear to be that not all the groups learned on the 3750 are reported to the Nexus.
On the 3750 I have 224.0.1.129 and 239.255.254.253. Only 239.255.254.253 shows on the Nexus via Po4094.




IDF-3750X#show ip igmp snooping groups vlan 880
Vlan Group Type Version Port List
-----------------------------------------------------------------------
880 224.0.1.129 igmp v2 Gi4/0/11, Gi5/0/38, Po10
880 239.255.254.253 igmp v2 Gi4/0/11, Po10


CORE-2# show ip igmp snooping groups vlan 880
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan Group Address Ver Type Port list
880 */* - R Vlan880 Po4096
880 224.0.1.129 v3 D Eth1/9

880 239.255.254.253 v2 D Eth1/9 Po4094

880 239.255.255.76 v3 D Eth1/9

880 239.255.255.250 v2 D Po101 Eth1/9 Po300
Po4091 Po4093

880 239.255.255.255 v3 D Eth1/9

CORE-1# show ip igmp snooping groups vlan 880
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port

Vlan Group Address Ver Type Port list
880 */* - R Vlan880 Po4096
880 224.0.1.129 v3 D Po4096

880 239.255.254.253 v2 D Po4096 Po4094

880 239.255.255.76 v3 D Po4096

880 239.255.255.250 v2 D Po101 Po4093 Po4096
Po300 Po4091

880 239.255.255.255 v3 D Po4096




I did a debug on the 3750 for this group and it shows is forwarding to the router ports but the Nexus never receives it or is silently discarding them.
I have not found a way to do a similar debug on the nexus but I did a capture using an SPAN port of Po4094 and no reports from group 224.0.1.129 are showing. See the screenshot attached.










IDF-3750X(config)#debug ip igmp snooping 224.0.1.129
Feb 4 21:43:32.652: IGMPSN: Received IGMPv2 Report for group 224.0.1.129 received on Vlan 880, port Gi5/0/38
Feb 4 21:43:32.652: IGMPSN: group: Received IGMPv2 report for group 224.0.1.129 from Client 172.30.80.52 received on Vlan 880, port Gi5/0/38
Feb 4 21:43:32.652: IGMPSN: Add v2 group 224.0.1.129 member port Gi5/0/38, on Vlan 880
Feb 4 21:43:32.652: IGMPSN: group: Added port Gi5/0/38 to group 224.0.1.129
Feb 4 21:43:32.652: IGMPSN: group: Forwarding 224.0.1.129 report to router ports
Feb 4 21:45:32.228: IGMPSN: Received IGMPv2 Report for group 224.0.1.129 received on Vlan 880, port Gi5/0/38
Feb 4 21:45:32.228: IGMPSN: group: Received IGMPv2 report for group 224.0.1.129 from Client 172.30.80.52 received on Vlan 880, port Gi5/0/38
Feb 4 21:45:32.228: IGMPSN: Add v2 group 224.0.1.129 member port Gi5/0/38, on Vlan 880
Feb 4 21:45:32.228: IGMPSN: group: Added port Gi5/0/38 to group 224.0.1.129
Feb 4 21:45:32.228: IGMPSN: group: Forwarding 224.0.1.129 report to router ports

Hope you can provide some advice to resolve this.

Thanks

[g748437]

Hello Paul,

I am aware than within a single VLAN PIM is not necessary. But since my environment has many Catalyst switches and after reading https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/68131-cat-multicast-prob.html I enabled it so the mrouter and querier could be dynamically learned on all the SWs. 

I am not trying to implement PTP. Just this Audio/Video devices that use PTP among them to synchronize their clocks and play audio. These are Dante or Shure devices that rely on multicast for almost everything.

Since I enabled PIM on the Core Nexus i did not have to use what you are suggesting since it is dynamically learned by all the switches with that VLAN:

ip igmp snooping querier 
or
ip igmp snooping vlan xx mrouter interface xx

My problem is that even when the Nexus receives those PTP packets destined to

224.0.1.129

it doesn't learn/accept or process those packets and they never show as a group on the VLAN. I have verified the Catalyst forward the membership reports to the

mrouter

port (towards the Nexus) with debugs and through packet capture I verify they are being received by the Nexus but no debug shows those packets as being processes. It' like the Nexus silently discard them without any trace. 

Using your suggestions won't change the this behavior ( I have already tried ) since the the effect would be the same for the Catalyst switches: They will forward the membership queries to the Querier (The Core Nexus) and they will be discarded. 

Do you think that because this packets are PTP ( all other multicast from this Dante/Sure devices are learned correctly on the Nexus) there should be an special configuration on the Nexus to process them appropriately?  

[Georg Pauwen]

Hello,

since that post has gotten rather long, I am not sure if you have already posted the 3750 config ? If not, do that, and maybe we can spot something in there.

[g748437]

I posted the

show ip igmp snooping vlan # 

output at the begining. The running config doesn't have anything in particular for multicast only this:

ip multicast-routing distributed

!
!
vlan configuration 880

!
vlan internal allocation policy ascending
!



The output of the command is this one again:




IDF-3750X#show ip igmp snooping vlan 888 detail
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled
IGMPv3 snooping (minimal) : Enabled
Report suppression : Enabled
TCN solicit query : Disabled
TCN flood PortFast : Disabled
TCN flood query count : 2
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000

Vlan 888:
--------
IGMP snooping : Enabled
IGMPv2 immediate leave : Disabled
Multicast router learning mode : pim-dvmrp
CGMP interoperability mode : IGMP_ONLY
Robustness variable : 2
Last member query count : 2
Last member query interval : 1000
Topology change : No




I do not think the issue is at the Catalyst since the debug shows it forwards the packets to the mrouter

IDF-3750X#
Feb 17 19:04:23.125: IGMPSN: Received IGMPv2 Report for group 224.0.1.129 received on Vlan 888, port Gi5/0/38
Feb 17 19:04:23.125: IGMPSN: group: Received IGMPv2 report for group 224.0.1.129 from Client 172.30.88.150 received on Vlan 888, port Gi5/0/38
Feb 17 19:04:23.133: IGMPSN: Add v2 group 224.0.1.129 member port Gi5/0/38, on Vlan 888
Feb 17 19:04:23.133: IGMPSN: group: Added port Gi5/0/38 to group 224.0.1.129
Feb 17 19:04:23.133: IGMPSN: group: Forwarding 224.0.1.129 report to router ports

[Georg Pauwen]

Hello,

I am thinking this somehow must be related to NX-OS only supporting sparse mode. That is why I wanted to look at the 3750 configs...

[paul driver]

Hello
TBH Ive never had any experience with dealing with PTP devices although I am aware of that specific MC address is used for PTP and that for cisco there is actual PTP documentation related to its implementation.
Now based on your previous OPs I cannot work out to as what state your MC network is currently set to, you state you have no MC routers and MC is all at L2 but then you state you've enabled

pim

?

Now if you have implemented

pim in sparse mode and igmpv3

and not using SSM then my understanding you would need to designate a RP unless that is you have

mc routing

disabled and then the NK it should act as a

mrouter

for that specific vlan only.

Lastly if you don't have no need for

PIm and L3 MC

routing and all MC is at L2 then your would need those access switch's to be able to receive group queries and send membership reports, unless snooping is disabled and your dense mode flooding which you dont say you are either?

[g748437]

Hello, 

My MC network is simple. This is for the test

VLAN 888

but for the actual production VLAN it would be similar, just add more IDF stacks hanging of the Core Switches.

I said I have no multicast routers since you asked about FHR and LHR between source and destination and that doesn't apply here.

The Core Nexus is the only device running

sparse-mode

interface Vlan888
description Dante-Test
no shutdown
ip address 172.30.88.1/24
ip pim sparse-mode
ip igmp version 3
ip igmp query-interval 30

I have not set a RP since honestly I am not sure if is need it for a single VLAN deployment and my understanding of it is still limitied to anticipate if there could be any impact on the rest of the network.

Checking the config of the Nexus I found configs regarding a RP for another VLAN. Check below: 

MDF-CORE-1# show run | inc igmp|ssm|pim
feature pim
ip pim rp-address 10.35.250.1 group-list 239.0.1.2/32
ip pim ssm range 232.0.0.0/8
ip pim sparse-mode
ip igmp version 3
ip igmp query-interval 30
ip pim sparse-mode
ip igmp version 3
ip igmp query-interval 30


MDF-CORE-1# show run int vlan 250

!Command: show running-config interface Vlan250
!Time: Tue Feb 22 08:43:15 2022

version 7.3(5)N1(1)

interface Vlan250
description VoIP
no shutdown
ip address 10.35.250.253/24
ip pim sparse-mode
hsrp version 2
hsrp 250
preempt
priority 80
ip 10.35.250.1

I really appreciate you helping me with this.

[paul driver]

Hello
You shouldn't need to do this even though that subnet its reserved for protocol control and specific application traffic the NKs should forward.

Maybe I'm missing something totally fundamental here, anyhow as a test you could try and add a static mac entry's on that specific vlan to forward traffic for that specific group address

224.0.1.129

to a single mc receiver (

IDF-3750x

switch)

example: 
MDF-CORE 1
mac address-table static 0100.5e00.0181 vlan 888 interface x/x (facing  IDF-3750x switch)




IDF-3750x switch
mac address-table static 0100.5e00.0181 vlan 888 interface x/x ( host)

[g748437]

Will try that and let you know.

Thanks again. 

[g748437 · Accepted solution]

I was able to solve this. One of the Nexus had the PTP feature enabled but there was no other configuration for PTP to forward packets to certain ports. Since all the 3750 stacks have Port-channels with 2 or more members the PTP Sync packets that take the path (based on the load balancing hash method) leading to Core-1 (the one with PTP feature enable) were not forwarded. That is why devices could learn and join the multicast group when I moved them. 

I am glad I got this solved and understand what was happening after all. Hope it can help someone in similar situation.