Hey Josh,
This one could be a pretty tough one to answer here! It might be a good one for TAC if the issue is still apparent
Disabling mls ip multicast seems to indicated that there was a forwarding issue in hardware but in these cases, it's best to take a good look at the data before speculating.
As you may be aware, the stateful information formed by the control plane (software config, routes, PIM etc) would be compiled into a forwarding information based (FIB) that would be programmed into the hardware forwarding tables.
An understanding of the software/hardware would be good. SUP type, DFC's vs CFC's, IOS version. Distributed vs centralised forwarding have different mechanisms
1. Firstly, I'd try to identify a trigger or any events that led up when the issue was first reported.
Get a clear picture of this. Things like changes, syslogs, other network issues and any examples of the tests used to validate the problem.
2. Understanding of the topology is required. Were there was any issues in routing. Was all the unicast and multicast routing checked? Any Anomalies?
We should also confirm whether multicast is in Sparse or dense. In sparse-dense mode, sparse should be used if RP is available, then dense mode used as a fall back. Unicast routing should be checked to ensure we don't run into RPF issues.
Taking this top down approach is required. If multicast routing is not correct, then hardware forwarding would be out of wack.
3. Once the control plane is validated, then you dive in the architecture .... best to get the TAC guys in for this!
Just a start but I Hope this helps somewhat
Eugene
