09-05-2011 08:00 AM - edited 03-07-2019 02:03 AM
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
09-05-2011 08:31 AM
Carlo,
Is igmp snooping enabled on this particular vlan?
09-05-2011 08:52 AM
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.
09-05-2011 08:59 AM
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.
09-05-2011 09:21 AM
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?
09-05-2011 09:32 AM
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
09-05-2011 10:07 AM
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
09-06-2011 03:16 AM
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)
09-06-2011 06:27 AM
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!
09-08-2011 04:42 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide