Multicast Issue Involving NAT

[ataripunk]

I am having issues explaining the reasons behind a multicast network problem I was able to mitigate...

The portion of the network experiencing issues involves a 3745 with a VLAN interface (VLAN 99) with the IP 10.1.1.2/24. Directly connected are multiple hosts in VLAN 99 (with a DFGW of .1), and the 3745 is connected to a 4507 using an interface in VLAN 99. The 4507 has the VLAN 99 interface 10.1.1.1/24. I know this is bad, but this emulates another network and cannot be changed. To make it worse, there is a NAT pool on the 3745 that is also in the same subnet as VLAN 99 (10.1.1.0/24). This NAT pool also cannot be changed.

The multicast source is on another subnet, and the source IP is NATd on the 3745 to a 10.1.1.x address. The 4507 has hosts on another VLAN (100) which need the multicast. PIM dense mode is used on the network, but the 4507 does not acknowledge the multicast unless IGMP static joins are placed on the VLAN 99 interface. I?m not certain if the 3745 is not sending it or if the 4507 is dropping it.

If I remove the NAT, everything works fine. If I change the link between the 3745 and the 4507 to a L3 link (on another subnet) everything works fine.

I suspect this has something to do with either IGMP snooping on the 3745 or the fact that the source appears to be local on the 4507, but I can't narrow it down to a definitive answer.

Can someone help me explain what exactly is causing this issue? I'm not looking for a solution, just an explanation of why.

Thanks,

John

[amritpatek]

To add a multicast router port (add a static connection to a multicast router), use the ip igmp snooping vlan mrouter global configuration command on the switch.

Switch# configure terminal

Switch(config)# ip igmp snooping vlan 200 mrouter interface gigabitethernet0/2

Switch(config)# end

Switch# show ip igmp snooping mrouter vlan 200

www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_guide_chapter09186a00801f0a40.html#37198

[ataripunk]

I'm not able to try this method on the network at this time, but it appears to achieve the same results as static IGMP group joins (without multiple commands). I can use this in the future. Thanks!

This doesn't really explain why this issue is occurring, though.

If there is a command I can put on the 3745 to mitigate this issue, that would be more helpful in this environment. Config changes on the 4507 are undesirable.

Is the problem really IGMP snooping on the 3745 or is it on the 4507? Is the problem a lack of query responses from the 4507 to the 3745 or from the multicast source to the 4507? Does the 4507 expect IGMP traffic from the source since it appears locally connected? Since the recievers are on a separate VLAN on the 4507, why isn't PIM more involved (as oppossed to IGMP) with the stream between the 3745 and the 4506?

These are the questions I can't seem to answer and would like someone to answer for me. I know this is a product of poor network engineering in the first place, but that's something that can't be changed at this point. Knowing why will help me build a case to correct the source of the issue eventually. In the meantime, I have to find a work-around or explain why there isn't one. Unfortunately, my work-around can only involve changes on the 3745.