Why configure IGMP access-group if Multicast Boundary already configured?

[Gustavo Novais]

Hello,

I have a design where a customer has properly defined his multicast address scoping. This will mean that he is not interested on ANY groups other than the group ranges he has defined.

One of the recommendations I'm making regarding Multicast security is to apply ip multicast-boundary ACL on each host facing interfaces to drop all uninteresting traffic, either coming from sources or from receivers, allowing obviously routing protocols and control traffic.

My question is if there's any added gain in complementing the above command with ip igmp access-group in order to filter out IGMP reports from hosts on an interface where anyway the traffic will already be dropped by the multicast boundary?

the platforms that I'm talking about are 6500 and 3560's as switching and 2[89]xx as WAN routers.

Thanks

Gustavo

[Peter Paluch]

Hi Gustavo,

I personally do not believe that complementing the ip multicast boundary command with the ip igmp access-group is helpful. According to the command reference for the ip multicast boundary command, it provides a filtering mechanism for both PIM and IGMP messages. Having the ip igmp access-group would therefore probably just make the configuration slightly more complex without making it significantly more secure.

See the command reference here:

http://www.cisco.com/en/US/docs/ios/ipmulti/command/reference/imc_03.html#wp1068105

Best regards,

Peter

[IAN WHITMORE]

I think it's only useful if your boundaries are not uniform. Maybe you need a large TTL to reach some multicast routers in one part of the network but you don't want this multicast traffic to reach other parts which it would with a large TTL. So you filter it.

Did that make sense?

Regards,

Ian

[Peter Paluch]

Hi Ian,

I guess that the original question was not about the purpose of the ip multicast boundary command, rather whether it makes sense to use both ip multicast boundary and ip igmp access-group (obviously with the same ACL) to protect the multicast boundary. In my opinion, it does not make much sense. What's your opinion?

Best regards,

Peter

[IAN WHITMORE]

No, I agree. If the boundary is uniform it doesn't make sense to have both.

Regards,

Ian

[Gustavo Novais]

Hi all,

Thank you very much for your replies.

I do agree with the answers you've provided, the point I was trying to clarify is if performance/resource wasting  wise will there be any issue (will IGMP break or still create IGMP entry in IGMP cache?)

I'm allowing 224.0.0.x/24 through the multicast boundary, and I'm allowing the permitted groups membership reports (group specific) but what I'm afraid is that the router gets reports for groups it is not allowing and still create state in the IGMP cache, but in my view, I think that even those reports will get dropped by the multicast boundary, so no big risk.

My confusion is started by this document, ftp://ftp.icm.edu.pl/pub/unix/net/cisco-ipmulticast/config-notes/upnp-note.txt

where they do state that an IGMP entry for a denied group on multicast boundary is still created on the IGMP cache (which in my view is strange, as the unsolicited membership report sent towards the group address to be joined should be dropped).

Any views? I think I'll just lab this up and draw my own conclusions...

Thanks

Gustavo