04-20-2011 01:38 PM - edited 03-06-2019 04:43 PM
Hello,
I currently have a scenario where a multicast source is on the same vlan as multicast receivers. Both source and receivers are on the same switch.
I'm finding strange different situations regarding multicast source traffic flooding containment. I'm wondering if this is by design or if there's any way to work around it.
the platform is 3560/3750 running ip services, with multicast routing distributed enabled and IGMP snooping at its defaults.
I create a SVI Vlan interface and enable ip igmp snooping querier for that specific vlan:
I see then when firing up the source that traffic is flooded to router ports:
Apr 20 21:32:54: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 20
As soon as I have a receiver, sending IGMP reports, the traffic gets constrained to that specific receiver port.
L3SwWAN-1#
L3SwWAN-1#sh ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
20 239.255.240.1 igmp v2 Gi1/0/21
L3SwWAN-1#sh run int vl 20
Building configuration...
Current configuration : 61 bytes
!
interface Vlan20
ip address 20.0.0.254 255.255.255.0
end
L3SwWAN-1#sh run | inc igmp|multicast-routing
ip multicast-routing distributed
ip igmp snooping querier
ip igmp snooping vlan 20 querier address 20.0.0.254
L3SwWAN-1#
L3SwWAN-1#sh ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
20 20.0.0.254 v2 Switch
So far, so good.
Now, when disabling the igmp snooping querier, and enabling ip pim sparse-mode on the interface, I'm expecting the behaviour to be similar to the situation before, but it isn't. Traffic keeps on getting flooded into all ports on that vlan. Is this by design? IGMP snooping seems to still be listening to host reports, but its like the switch is ignoring it completely.
Have anyone else seen this? is there a workaround? Am I missing something? I will prefer to have ip pim sparse-mode enabled as I have two multicast enabled SVI's attacking that interface and I need to do multicast routing.
L3SwWAN-1#sh ip igmp snooping querier
Vlan IP Address IGMP Version Port
-------------------------------------------------------------
20 20.0.0.254 v2 Router
L3SwWAN-1#sh run int vl 20
Building configuration...
Current configuration : 81 bytes
!
interface Vlan20
ip address 20.0.0.254 255.255.255.0
ip pim sparse-mode
end
Thanks
Gustavo Novais
04-20-2011 01:54 PM
Just to add, that the flooding seems to be limited to the switch. If connecting another switch, on the same vlan the behaviour is as expected.
Thanks for any insight.
G
04-20-2011 02:53 PM
Hey Gustavo,
With PIM enabled, I would also expect the same behaviour as the querier. That is to restrain multicast traffic on the same switch.
Just a sanity check as I can't see the config -
Do you have an RP mapped for sparse mode?
Do you have ip multicast routing enabled?
How do you determine flooding?
#sh ip igmp group x.x.x.x
should show the ports that have joined that particular group.
Eugene.
04-21-2011 12:38 AM
Hi Eugene,
Thanks for your answer
in fact now you make me wonder of one thing. I do have specific ACL's indicating for which groups I'm using RP X, and I do not think the test group I'm using is covered there.
Regarding your questions:
I thought I had a RP (I have to confirm)
I have multicast-routing distributed enabled
I determine flooding via a third PC connected to that switch/vlan with Wireshark running.
#correction - sh ip igmp snooping groups show which switch ports have joined a group.
Anyway I'm not doing multicast routing (or at least not interested on it, as I'm on the same vlan), and I would expect IGMP snooping to be smart to contain flooding only to mrouter ports, no matter you are sparse or dense mode. Assuming that IGMP snooping querier and IGMP querier should "fuel" similarly the IGMP snooping engine, I'm finding it strange the difference in behaviour.
As you can see from my previous post, the IGMP querier is identified differently depending on ip pim XXXX mode (router) or ip igmp snooping querier (switch)
Thanks
Gustavo
04-21-2011 07:31 AM
Hi Eugene,
thanks for your help. I was indeed using a group that didn't have RP mapping. Apparently it caused all those strange behaviour, as I think that IGMP snooping interpreted it as a dense mode group (even though I had no ip pim dm-fallback, and had specifically ip pim sparse-mode configured), and floods everything everywhere.
When I tried with a test group that would fall into the mapped RP range, things worked as expected.
I really appreciate your help. Sometimes you get so deep into problems that you forget the basic stuff (or previous configs done).
Gustavo Novais
04-23-2011 10:46 PM
Apologies for the late reply Gustavo, having a nice 5 day Easter break here in Australia.
I completely understand and thanks for confirming!
I could have been clearer in stating my thoughts on the what could be happening to avoid any confusion
In these types of situations where something looks like it's behaving 50% correct (other switch was OK etc), I look for anything that may not be completely configured. A check to see if the knobs are working, so to speak. In the past, I have seen a few features such as NAT or multicast displaying "partial behavior" when "partially configured.
Eg.
Configuring a few global NAT statements but no inside or outside interfaces -> started showing some proxy ARP behavior. By configuring NAT, it enabled portions of the code. So a good idea to keep configs clean if not in use.
Also been caught by multicast tables looking correct but no routing, only to find after some time, that multicast routing wasn't enabled
Some times, A few simple steps could also help understand the situation.
Eg. In dense mode, nothing else is required other than PIM dense mode & Multicast routing - attempting to isolate the device/component from external factors. If this worked, I would continue to invest time in reviewing for valid RP's or something isolated to sparse mode before thinking there was any type of IOS bug.
Anyway, glad you got it resolved. Happy Holiday period if you have one!
Eugene
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: