stop multicast flooding in a vlan with no ip address

CrackedJack1 · ‎02-13-2014

To keep machines isolated for testing, I have a few vlans defined that have no IP address on them to prevent anything from getting in/out. The machines in these vlans do not have a gateway set (I do have ip routing and ip multicast-routing enabled on the switch but I don't want any traffic from the vlan getting out unless I specifically put in a route)

Since the vlan has no ip address, when there is multicast traffic it ends up being broadcast in the given vlan to all machines.

The "normal" vlans have ip pim set on them.

For these isolated vlans, is there a way to set a querier address that only works within that vlan so as to prevent the flooding but still remain isolated?

Would something like this work for machines in an isolated vlan:

int vlan 300

ip igmp snooping querier 10.12.30.2 [an unused ip address in the range of the other machines]

I don't want to affect anything else, just stop the flooding in this vlan.

Thanks

Steve Fuller · ‎02-13-2014

Hi,

The problem you mention here is typically the opposite of what you would see when there is no IGMP querier i.e., a router, for a VLAN. In that situation IGMP snooping on the Layer-2 switch means that rather than multicast traffic being flooded, it is dropped. As such no clients will receive the stream.

If you're seeing flooding of IP multicast traffic then it could be that IGMP snooping has been disabled.

So if you want to filter IP multicast traffic such that it's only sent to clients who have registered via IGMP then, assuming IGMP snooping is enabled, the IGMP snooping querier is one option. This is discussed as solution 2 in the Troubleshooting TechNote Multicast Does Not Work in the Same VLAN in Catalyst Switches along with a number of other solutions.

What you describe i.e., the flooding of multicast, is actually shown as Solution 5 in the aforementioned TechNote.

Regards

Jon Marshall · ‎02-13-2014

Hi Steve

The problem you mention here is typically the opposite of what you would see when there is no IGMP querier i.e., a router, for a VLAN. In that situation IGMP snooping on the Layer-2 switch means that rather than multicast traffic being flooded, it is dropped. As such no clients will receive the stream.

Just for may own clarification have you seen this happen. I ask because my understanding was that if IGMP snooping was enabled but nothing was making IGMP queries (PIM or snooping querier) then all multicast is simply treated as broadcast and not dropped because IGMP snooping can do nothing in this scenario.

Jon

CrackedJack1 · ‎02-13-2014

Hi Jon,

That was my understanding and that's what I saw initially. Without an IP on the vlan, I can't use PIM so I was thinking my only solution was the querier address but i've never tried it and I don't want to lose my isolation or mess up any other routing.

CrackedJack1 · ‎02-13-2014

I have not touched snooping so as far as I know, it should still be on since it's the default. During my initial tests I was seeing flooding but are you saying I should not have seen flooding if snooping was enabled? (keeping in mind there was no ip address on the vlan or an routes to allow traffic to get out of the vlan)

I've seen that page but what has me worried is that option seems to have it on globally and a mrouter port gets created/discovered and this might allow multicast out.

Maybe the easiest thing is just to put in the commands and cross my fingers it all just works and nobody notices if it doesn't?

Jon Marshall · ‎02-13-2014

If you do not enable PIM on any of your interfaces then multicast traffic cannot get out of the vlan.

However if you enable IGMP snooping querier then it may mean multicast traffic can go across uplinks to other switches in the same vlan. But the querier does not enable multicast routing between vlans It simply makes IGMP queries so IGMP snooping can correctly map the L2 multicast mac address to the relevant ports.

But multicast routing is still L3 and without an IP on the SVI and PIM it won't route.

Edit - IGMP snooping should be enabled by default. The querier function won't be.

Jon

CrackedJack1 · ‎02-13-2014

Sounds like what you described is exactly what I want. No routing between vlans but allow other machines on the same vlan on other switches to get multicast trafic.

So on an SVI with an ip address, putting setting PIM allows for routing and gives you a querier "automatically" (but without enabling ip multicast routing globally, you can't route between vlans)

Without an IP address on the SVI, I can explicitly set a querier within that vlan and keep multicast from flooding all while keeping it constrained within the vlan. PIM, even if set on the SVI, it useless without an IP address.

Am i understanding correctly?

Jon Marshall · ‎02-13-2014

Yes you understand correctly (or at least to my understanding).

With an SVI configured with an IP to enable multicast routing you need to -

1) enable multicast routing globally

2) enable PIM on the each SVI you want to route multicast between

by enabling PIM that automatically enables IGMP queries.

PIM on an SVI without an IP but with multicast routing enabled is not something i have ever tested for the obvious reason if i was enabling PIM i would be wanting to route multicast traffic.

But without an IP no i do not believe it would work

And yes the querier function as i say is only for making IGMP queries, it has nothing to do with routing multicast traffic.

Jon

Steve Fuller · ‎02-13-2014

Hi,

I think Jon has answered the original question, but obviously posed another in his first response.

... my understanding was that if IGMP snooping was enabled but nothing was making IGMP queries (PIM or snooping querier) then all multicast is simply treated as broadcast and not dropped because IGMP snooping can do nothing in this scenario.

So we all agree that IGMP snooping is used as a way to constrain multicast flooding, but the question is obviously around what happens when there is no IGMP snooping.

Based upon your comment I started to question what I'd said and as I couldn't find a good reference to support my statement I retired to the test lab.

So the test environment was a Cisco Catalyst 6500 with 12.2SXI and two Red Hat Linux hosts. The multicast source (a host named rhel2) is connected to Gi4/6, and I've a second host (called rhel1) connected to Gi4/26. Both of these hosts are in VLAN 12.

These two hosts are the only devices in the VLAN and I've shut the SVI so I've no IGMP querier.

So here's my test:

IGMP snooping enabled
No IGMP querier in VLAN
Single multicast source (rhel2) connected to gi4/6
Second host (rhel1) connected to gi4/26 not joined to any multicast group

Clear the counters on the ports before the source starts sending.

6504-2#clear count

Clear "show interface" counters on all interfaces [confirm]

6504-2#

Feb 13 17:15:00.477 GMT: %CLEAR-5-COUNTERS: Clear counter on all interfaces by sfuller on vty0 (192.168.11.100)

Start the source sending at 1000 packets per second for 10-seconds to 239.255.2.2 from 192.168.12.191 into VLAN 12.

[sfuller@rhel2 ~]$ udpsend -rate 1000 -addr 239.255.2.2 -mttl 15 -if 192.168.12.191 -secs 10

udpsend - UDP Benchmark Tool

Version 1.8.0 2003/07/28

udpsend: Sending 128 byte packets from 192.168.12.191 to 239.255.2.2

on port 4000 at 1000pps (at constant rate)

udpsend: 10000 in last 10.0093s (999.067ps), total: 10000 in 10.0093s (999.067ps)

[sfuller@rhel2 ~]$

If we look at the MAC address table for VLAN 12 we can see the multicast MAC address for group 239.255.2.2 (0100.5e7f.0202) but there's no ports associated with the entry. I would say that's correct as no hosts have registered to receive the group, and as a multicast MAC address is not used as a source MAC it isn't learnt through source MAC learning.

6504-2#sh mac add multicast vlan 12

Legend: * - primary entry

age - seconds since last seen

n/a - not available

vlan mac address type learn age ports

------+----------------+--------+-----+----------+--------------------------

Active Supervisor:

* 12 0100.5e7f.0202 static Yes -

* 12 3333.0000.000d static Yes - Gi3/1,Gi3/4,Gi3/5,Gi3/6

Gi3/7,Gi3/8,Gi3/9,Gi3/12

Gi3/16,Gi3/17,Gi3/23,Gi4/3

Gi4/6,Gi4/10,Gi4/11,Gi4/13

Gi4/16,Gi4/26,Gi4/45,Gi4/48

Po1,Router,Switch

* 12 3333.0000.0001 static Yes - Switch

* 12 3333.0000.0016 static Yes - Switch

On the second host I started a tcpdump to capture any Ethernet traffic received on the eth1 interface that had the Group bit of the destination address set.

[root@rhel1 root]# tcpdump -i eth1 ether multicast

tcpdump: listening on eth1

17:15:04.544301 802.1d unknown version

17:15:06.544516 802.1d unknown version

17:15:07.372861 rhel2-bond0.ntilab.net.4000 > 239.255.2.2.4000: udp 100 (DF)

17:15:07.372867 rhel2-bond0.ntilab.net.4000 > 239.255.2.2.4000: udp 100 (DF)

[snip for some brevity]

17:15:07.425441 rhel2-bond0.ntilab.net.4000 > 239.255.2.2.4000: udp 100 (DF)

17:15:07.426444 rhel2-bond0.ntilab.net.4000 > 239.255.2.2.4000: udp 100 (DF)

17:15:08.544628 802.1d unknown version

17:15:10.545562 802.1d unknown version

17:15:12.600122 802.1d unknown version

68 packets received by filter

0 packets dropped by kernel

So in the tcpdump we see a number of packets destined to 239.255.2.2 received by the second host i.e., flooded on the port to the host, but these stop within approximately 50ms.

A short while after the source finished sending I grabbed the interface counters from the switchports connected to the two hosts. From this we can see that the interface to the source received 11667 multicast packets, but the switchport connected to the second host has sent only 515 multicast packets between me clearing the counters and capturing them at the end of the test.

6504-2#sh int counters | in ^Port|^Gi4/6|Gi4/26

Port InOctets InUcastPkts InMcastPkts InBcastPkts

Gi4/6 1840252 1961 11667 150

Gi4/26 2620 34 0 0

Port OutOctets OutUcastPkts OutMcastPkts OutBcastPkts

Gi4/6 66400 234 471 0

Gi4/26 81518 229 515 150

6504-2#

Given there are other frames floating around in VLAN 12 with the G bit set it makes sense that the count has incremented more than by just the 56 frames that I saw with tcpdump, but clearly all the multicast frames are not being flooded.

Given that some frames are flooded when the source first starts it seems that the switch is setting up some state, and once that state is created, it then drops all subsequent frames. I have to admit that I don't see how it would be IGMP snooping creating that state as there is no IGMP. The source simply sends without registering to the group first, and there are no receivers or IGMP queriers configured.

There would appear to be something else going on here that's not related to IGMP snooping, but is optimising multicast flows in the switch such that they're not flooded. I'm still trying to find some documentation explaining this, but no joy so far.

Regards

Jon Marshall · ‎02-13-2014

Steve

It's at times like this i wish i had access to test kit

Many thanks for taking the time to set this up and test. I will have a few further reads of your post but i too cant see how IGMP snooping is involved here so there must be something else going on.

I'll have a dig around as well as between us we may find something useful.

Jon

CrackedJack1 · ‎02-13-2014

Just like Jon i'm giong to read this post a few more times but that's an interesting test. Hopefully I can make some time in the next few days to get a couple machines and put in the querier stuff and redo my test both before and after. I probably can't go as deep as you guys but I can see if wireshark explodes with UDP packets when I start a capture

Thanks

Jon Marshall · ‎02-13-2014

Worth bearing in mind that your 3850s might not necessarily exhibit the same behaviour as the 6500 as they are very different switches.

Would be interested to hear the results as the test Steve has done is not showing the behaviour i would have expected.

Jon

paul driver · ‎02-14-2014

Hello

PIM on an SVI without an IP but with multicast routing enabled is not something i have ever tested for the obvious reason if i was enabling PIM i would be wanting to route multicast traffic.

FYI -

mc scr ---Sw1----Sw2 --- mc host

SWxx

ip multicast-routing distributed

ip igmp snooping querier

sh debugging

IGMP Snooping:

etc..
.

IP multicast:

IGMP debugging is on

sh ip igmp snooping vlan 5

Global IGMP Snooping configuration:

-------------------------------------------

IGMP snooping : Enabled

IGMPv3 snooping (minimal) : Enabled

Report suppression : Enabled

TCN solicit query : Disabled

TCN flood query count : 2

Robustness variable : 2

Last member query count : 2

Last member query interval : 1000

Vlan 5:

--------

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

int vlan 5

ip pim dense-mode

*Mar 1 01:30:00.166: IGMPQR: vlan_id 5: timer GQ_PIM Timer expired in Querier state

*Mar 1 01:30:00.166: (igmpsn_l2mc_get_system_ip) (Platform defined) System ip address 0.0.0.0

*Mar 1 01:21:23.277: IGMPQR: vlan_id 5: Failed to send GQ because there is no IP address configured on this system

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Jon Marshall · ‎02-14-2014

Paul

Thanks for that. Always good to know something works as expected.

Jon

CrackedJack1 · ‎02-14-2014

So I did a quick little test.....

on my 3850, vlan 322

gi1/0/29 is sender

gi1/0/30 is receiver

I'm using a couple of little utilities I got from cisco while troubleshooting another multicast program to generate traffic and to join a group.

I started wireshark on the receive but did not join any groups. I started the generating traffic on the sender and wireshark (on receiver) was showing my all the packets... i was getting flooded.

I used the command from Steve's post to check counters:

sh int counters | in ^Port|^Gi1/0/29|Gi1/0/30

Port            InOctets    InUcastPkts    InMcastPkts    InBcastPkts
Gi1/0/29         2104603           8600           4375            210
Gi1/0/30          158785             43            484            494
Port           OutOctets   OutUcastPkts   OutMcastPkts   OutBcastPkts
Gi1/0/29          498244           4461            987            510
Gi1/0/30          382602            157           4941            226

and then ran it again a minute later....

Port            InOctets    InUcastPkts    InMcastPkts    InBcastPkts
Gi1/0/29         2189448           8600           5691            211
Gi1/0/30          164713             43            512            533
Port           OutOctets   OutUcastPkts   OutMcastPkts   OutBcastPkts
Gi1/0/29          504940           4463           1025            549
Gi1/0/30          468215            159           6267            227

and then a couple minutes later

Port            InOctets    InUcastPkts    InMcastPkts    InBcastPkts
Gi1/0/29         2359067           8600           8321            215
Gi1/0/30          178969             43            584            623
Port           OutOctets   OutUcastPkts   OutMcastPkts   OutBcastPkts
Gi1/0/29          521258           4467           1119            639
Gi1/0/30          639896            163           8919            231

the sh mac add multicast vlan 332 (or any other vlan) returns nothing in my case (perhaps because I'm not the core?)

Next I tried to added the following

ip igmp snooping vlan 322 querier address 10.13.22.2

and that did nothing I still got flooded. I tried making my gateway on the two machines 10.13.22.2 but that didn't help.

For reference, vlan 332 is defined as:

interface Vlan332

no ip address

end

I ran

sh ip igmp snooping querier

and

sh ip igmp snooping mrouter

and they didn't have anything for vlan 332 listed after I added the snooping line.

I don't know if i have to add that querier command at the core (i'm trunked to our core) but at least on my 3850, where the two test machines are plugged in, i didn't see any change. Still getting flooded.

edit: just doing a little more reading and i'm getting the feeling that without an ip address on the vlan, it just won't work. That means I either live with flooding or put in an IP address and retry the querier stuff and use an ACL to do the isolation for me (which is probbaly another post )