cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1379
Views
0
Helpful
5
Replies

Same vlan multicast source containment with 3560/3750

Gustavo Novais
Level 1
Level 1

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

5 Replies 5

Gustavo Novais
Level 1
Level 1

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

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.

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

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

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

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco