From: Jongsoo.Kim@Intelsat.com
Date: Sun Mar 27 2005 - 00:25:36 GMT-3
Bob or anyone
Good point about FR h-s topology.
And I like to hear any comments on below accesssment while we are on that
subject( spoke-to-spoke issue).
Let's say I have the below topology.
R4( Spoke1)---104 pim sd---R1(hub)--pim sd--R5--pim sd--R2
MA=RP /
Join 225.1.1.1 103
mcast diabled
/
R3( spoke 2)
Basically, R1 is FR mulipoint interface hub, R4 and R3 are FR spoke.
Mcast is enabled all interface except the one between R1 and R3.
Basically, mcast is disabled on R3.
Now, without pim nbma-mode on R1, R1,R5 and R2 are trying to ping 225.1.1.1.
What will be the expected behavior of ping forwarding in R1?
I believe( it is my "logical" conclusion) without pim nbma-mode on, for R1
to forward ping to 225.1.1.1 member( R4),
R1 knows which interface to forward but doesn't know which DLCI to use.
It is because NBMA like FR don't have natural capability to support
multicast or broadcast( for example, one packet from hub can't reach
multiple spokes) so that at the end of day, it has no difference from a
"unicast" going over a specific PVC. But the issue is that F/R hub can't
reloved next-hop address( DLCI-PVC) from mroute table.
Mroute table is not meant to reslove a next-hop address but just outgoing
interface.
Mroute will be something like this ( ignore ip address )
(*, 235.0.0.1), 00:01:45/00:02:59, RP 20.0.0.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0, Forward/Sparse-Dense, 00:01:45/00:03:02
But, with pim nbma-mode on R1( FR Hub), it makes router to install next-hop
address in mroute table.
So Something like this( ignore ip address )
(*, 235.0.0.1), 00:00:27/00:03:24, RP 20.0.0.1, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0, 10.0.0.4, Forward/Sparse-Dense, 00:00:05/00:03:24
Serial0, 10.0.0.5, Forward/Sparse-Dense, 00:00:25/00:03:04
Thanks
Jongsoo
-----Original Message-----
From: Bob Sinclair [mailto:bsin@cox.net]
Sent: Saturday, March 26, 2005 4:03 PM
To: ccie2be; Group Study
Subject: Re: Finding mcast rpf failures - Best Practices
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