cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Join Customer Connection to register!
441
Views
0
Helpful
1
Replies
joshhaleaos
Beginner

Multicast Through 6509

Experienced an issue where multicast traffic was not being passed through a pair of redundant 6509's using EIGRP as the routing process.  Every port connecting from the source and destination had "ip pim sparse-dense mode" and used auto-rp as the rp deployment.  The only way that traffic could be passed was adding the command, "no mls ip multicast" globally to both chassis.  After that, multicast traffic worked correctly and voice/video was able to be seen at the spokes.  Has anyone seen anything like this before?

Thanks

1 REPLY 1
Eugene Lau
Cisco Employee

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