Solved: Multicast group blocking for sources

Julio Garcia · ‎09-06-2010

Hi all,

need some help with something.

to block hosts joining multicast groups, there are a quite a lot of options, igmp filter profiles, igmp access groups etc.

But i was wondering if there is something of similar nature for sources, i dont mean source specific multicast, there is one source that is sending traffic for a lot of multicast groups, eg , 239.10.20.30, 239.10.20.31, 239.10.20.32 , the source is 10.40.10.10

what is the best way to configure so that a router will only allow through certain groups , such that when i do a ... #sh ip mroute , i dont see all the other groups , i only want 239.10.20.30 allowed through that sparse mode interface.

Many thanks

Lei Tian · ‎09-07-2010

Hi Rob,

Are you sure the ACL causes the cpu spike? There are other reasons can cause cpu high because packets been process switched. For example, if the FHR is not same as RP, it will send out join to the RP; that unicast join will be process switched. So, you can exclude the unwanted group from rp-group mapping acl. Another example, if the multicast traffic has ttl=1, it will be process switched as well.

If you use 6500, as long as ACL doesnt exceed the tcam size, cpu will not be used. However, for any packet need to be process switched, it will still be process switched on 6500.

HTH,

Lei Tian

View solution in original post

Lei Tian · ‎09-06-2010

Hi Rob,

If you are asking on the FHR, you can use multicast boundary (not available on all IOS) or use access-list on interface to block. If you are asking on other routers, remove the unwanted groups from RP to group mapping acl to make those group fall back to dense mode, and a sparse only interface won't propagate multicast group in dense mode.

Regards,

Lei Tian

Julio Garcia · ‎09-07-2010

Hi Lei,

Acl is not very efficient here ,

say for example i have a multicast source ip on subnet 10.40.40.10 as an example , and it is sending multicast traffic for 10 separate groups 239.10.10.10 .... 239.10.10.20

on the ip interface on router i would have a huge amount of traffic coming in that would need acl processing, 10 groups worth of multicast traffic even if router interface is running sparse mode.

I heard of protocol that can work in conjunction with igmp to stop this , rgmp? im not sure , anyone have any practical examples and/or configurations of how this would be done in the following senario ...

Multicast Source --- Igmp enabled switch --- Router

where source ip = 10.40.40.10 , router = 10.40.40.250 , and vlan on switch = 500

Many thanks

Lei Tian · ‎09-07-2010

Hi Rob,

If the FHR is catalyst switch, then the ACL is processed in hardware. As long as it doesn't exceed the TCAM size, there will be no problem. The interface mode, sparse or dense doesn't control what multicast traffic can be received on the interface. It only controls what multicast traffic can be sent out from the interface.

I am not aware of the feature you were asking for, hope somebody can chips in.

Regards,

Lei Tian

Julio Garcia · ‎09-07-2010

hi Lei,

FHR is a router , 3825

cpu struggles a lot , IP input is about 140megs, most of which is dropped by acl to allow the 6 megs of useful group traffic i need.

So if i used a catalyst switch, the acl will be compiled in tcam and i wont get any performance degradation? eg , a 650x series. Not sure if its the acl processing or the actual amount of traffic that is causing the problem, i think most probably the amount.

Lei Tian · ‎09-07-2010

Hi Rob,

Are you sure the ACL causes the cpu spike? There are other reasons can cause cpu high because packets been process switched. For example, if the FHR is not same as RP, it will send out join to the RP; that unicast join will be process switched. So, you can exclude the unwanted group from rp-group mapping acl. Another example, if the multicast traffic has ttl=1, it will be process switched as well.

If you use 6500, as long as ACL doesnt exceed the tcam size, cpu will not be used. However, for any packet need to be process switched, it will still be process switched on 6500.

HTH,

Lei Tian