Filtering Multicast traffic in a LAN

[Carlo Zaina]

Hi.

Cisco Call Manager generates lot of multicast traffic for Music on Hold through the VOICE Vlan.

I wish to filter this traffic from being transmitted on a specific switchport belonging to this LAN: there is a way to achieve this?

I cannot use VACL (multicast is needed), Port ACL (it filters only incoming traffic on a port) or features like switchport block multicast, for what i read.

There is maybe some trick with IGMP i could use?

By the way, the switch is a 3560X IPServices.

Thank you

C

[Julio Garcia]

Carlo,

Is igmp snooping enabled on this particular vlan?

[Carlo Zaina]

I write the configuration as it has been implemented by the local administrator:

ip igmp snooping vlan 10 mrouter interface Gi3/0/1

ip igmp snooping vlan 10 mrouter interface Gi3/0/3

ip igmp snooping vlan 10 immediate-leave

Nothing else about igmp snooping.

VLAN 10 is the Vlan requiring the filtering and Gi3/0/1 and Gi3/0/3 are interfaces connected to the CUCM server.

Personally, i think the configuration is not correct, although my experience with multicast is limited: i see no point to define an interface connected to a server generating multicast as a static multicast router.

Beside this, there is no need to generate a multicast distribution tree: PIM DM or SM are not needed since the multicast has to be kept locally.

[Julio Garcia]

Hi Carlo,

Do you have an IP address in 'interface vlan 10?' 

you should do :

(config)# ip igmp snooping vlan 10 querier address x.x.x.x

and remove the other 2 commands  with the 3/x interfaces

i think in this way -- the igmp snooping will work fine and only ports that need the multicast will get it.

can you double check igmp snooping is enabled on that vlan with

#sh ip igmp snooping

there is another messier way to solve your problem -- using private vlans within your primary vlan 10 -- but i dont think its worth to go down that route.

[Carlo Zaina]

I figured initially the private vlan, but it's too complicated, considering the topology and the traffic path.

Returning to the first proposal: yes, the interface vlan 10 has its own ip address 172.21.254.249/24

Also, the switch is linked via a Layer 2 etherchannel to another switch with ip address 172.21.254.250/24

The switches are configured with HSRP with virtual address 172.21.254.252, but both servers are connected to the 172.21.254.249

So, you recommend, Rob, to use the ip igmp snooping vlan 10 querier address x.x.x.x. The address i should use is the virtual one (i think not) or rather the physical one?

[Julio Garcia]

Hi Carlo,

it doesnt really matter , its just acting as a querier , use the address set up on the interface vlan and not the virtual hsrp

let me know how it goes

follow up with :

#sh ip igmp groups vlan 10

before and after to see if its working okay..

you should see multicast group with a port list of ports interested in multicast.. eg..

Vlan      Group                    Type        Version     Port List

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

302       234.10.20.31          igmp                    Fa0/9, Fa0/47

[Carlo Zaina]

Hi Rob

I've implemented the config on a test network

At the moment, i have a station on the lan broadcasting on 239.1.1.1 address.

A host is receiving traffic for this multicast address although it didn't subscribe for the multimedia stream.

The show ip igmp group command shows nothing..

Anyway i will keep to work on and let you know as soon i have some news

Thank you

[Julio Garcia]

Hi Carlo,

i set up as you did and you are right , the igmp snooping doesnt work very well even with querier,

the solution i did which works perfectly fine is as follows,

keep igmp snooping on

remove all of your querier commands

on vlan svi interface , put in  > ip pim sparse-mode

although you are not doing multicast routing per se, it seems like it makes igmp snooping work as it should

so if you now do #sh ip igmp groups vlan 10   , you can see for yourself, if you test it -- am very confident it will be working as you want it.

only problem is you need ip multicast routing turned on, my set up...

3560_SW#sh run | include multicast

ip multicast-routing distributed

3560_SW#sh ver

Cisco IOS Software, C3560 Software (C3560-IPSERVICESK9-M), Version 12.2(55)SE, RELEASE SOFTWARE (fc2)

[Carlo Zaina]

Hi Rob.

This is just what i did yesterday and it worked!

I configured the switch in this simple way:

ip multicast-routing distributed

ip igmp snooping vlan 100 querier address 192.168.100.254

interface Vlan100

ip address 192.168.100.254 255.255.255.0

ip pim sparse-dense-mode

ip igmp version 3

In fact, the querier address has no effect in the forwarding on the port associated to LAN 100, and although it seemed unnecessary to me, i've enable the multicast routing and it works perfectly. Only the station joining the group receives the desidered multicast traffic.

I replied the situation on a 1841 with HWIC module 4ESW, but in this situation the traffic is flooded to all the ports. There is no way to prevent this or containing the multicast: it's treated like a broadcast.

According to Cisco data sheet, the HWIC supports the IGMP and not CGMP, but it doesnt work.

Anyway, i've reached the result.

Thank you for the support!

[Carlo Zaina]

Hi Rob.

In the end this is how it works.

A server directly connected to the switch transmit the multicast traffic (the switch is configured to performing routing).

This traffic is flooded to all the ports belonging to the VLAN, indipendently they joined or not the group. Interesting, a second switch connected to the first switch, with a Layer 2 link, receives as well all of the multicast traffic but it doesn't flood this traffic to all of its ports. This means the IGMP is working

Working in a routed environment (EIGRP Neighborship) and configuring PIM (sparse mode) and multicast routing on the SVI facing the server doesn't help, unfortunately: traffic is still flooded across the server's VLAN ports on the first switch. However, setting up a neighbor PIM, solves the problem: the switch stops flooding the traffic. Only the station joining the group will receive the traffic.

At this point, if we lose the neighbor PIM, the things keep working: no flooding.

To make it short: all i observed is that after the power on, the switch needs to setup at least one neighborship PIM to perform correct traffic forwarding on the connected ports.

Unfortunately i've found no documentation around about this, so this is only my observed experience.

I hope this will help