From: ccie2be (ccie2be@nyc.rr.com)
Date: Fri Mar 25 2005 - 11:36:07 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:51 GMT-3