From: Bob Sinclair (bsin@cox.net)
Date: Sat Mar 26 2005 - 18:03:26 GMT-3
Tim,
One good tool for detecting rpf failures is mtrace. Run it from a failing
client router to the source address of the multicast stream. It walks the
multicast shortest path path back to the source and reports the multicast
status of each hop. Another entire category of failure scenarios involve
OILIST problems, like the well-known spoke-to-spoke issue. The PIM
sparse-mode OILIST is built by receiving a *,G or S,G on the interface. Some
frame hub and spoke topologies may end up sending the *,G to the wrong
interface.
HTH,
Bob Sinclair
CCIE #10427, CCSI 30427, CISSP
www.netmasterclass.net
----- Original Message -----
From: ccie2be
To: Group Study
Sent: Saturday, March 26, 2005 8:55 AM
Subject: Finding mcast rpf failures - Best Practices
Hi guys,
Sometimes I have a difficult time finding mcast rpf failures.
When I suspect a rpf failure, I start at some mostly randomly picked router
and do a show mroute count to see if the router has denied any packets due
to rpf failure. If there were no rpf failures, I go on to another router
and do the same until I've gone through all the routers or have identified
the rpf failure and fixed it.
Sometimes this works but sometimes it doesn't.
If this process doesn't work, I go back and check that all routers and
interfaces have been properly configured, remove any acl's that may be
blocking packets, and do a show ip pim neighbors to make sure all neighbors
that should be seen are seen.
If this doesn't work, then I scratch my head and decide whether to give up
and move on to other problems or continue to troubleshoot.
BTW, I always make sure my IGP's are fully correct before going on to mcast
so at least I know I don't have a routing problem.
But, there must be a better way.
So, I've got a couple of questions:
Assuming auto-rp is configured and assuming all mcast rtr's have a correct
rp to mcast group mapping, and no acl's are configured that would block
pings, if pings don't work, how safe is it to conclude there is an rpf
failure?
Besides rpf failures as the cause of this problems, what other problems,
mistakes, or omissions should be at the top of list as potential causes?
Lastly, what is considered the best and fastest way of identifying rpf
failures?
As some of you already know, I recently failed the lab and multicast was a
small but contributing factor. So, I'm trying as hard as I can to
permanently remove mcast as impediment to my passing the lab. So, any help
and guidance would be warmly appreciated.
TIA, Tim
_______________________________________________________________________
Subscription information may be found at:
http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:52 GMT-3