From: Scott Morris (swm@emanon.com)
Date: Wed Jan 04 2006 - 19:01:06 GMT-3
The mroute works because otherwise you were seeing multicast messages come
in and were killing them (debug ip mrouting rpf) since your unicast route
back to the source IP address was different than the interface they were
being received on.
Multicast is a strange creature that way, because technically we are trying
to establish best-paths by reverse-routing instead of forward-thinking on
things. I'm not sure whether that makes things right-brained or
left-brained, but it can get awfully messy!
Tilt your head to one side, then the other. Then stand on your head for 30
seconds. After righting yourself, the perspective should be ok. ;)
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Greg
Gombas
Sent: Wednesday, January 04, 2006 4:44 PM
To: swm@emanon.com; ccielab@groupstudy.com
Subject: RE: PIM Sparse-Mode join RPF question
You are correct, let me expand on the diagram a bit...
[Source]
|
[R1]-L0 150.1.1.1 <--- This is the RP
s0| |s1
| |
s0| |s1 <--- This interface is preferred route to RP but PIM is disabled.
[R2]
|
[Receiver]
The source is hanging off R1, the receiver is hanging off R2.
R1's loopback is configured as the static RP address.
R2's route table shows R1's Serial1 interface as the next hop to R1's
loopback.
Unfortunately, the task does not allow you to enable PIM on serial1 of
either router.
The solution is to add the following static mroute pointing to the Serial0
address of R1:
ip mroute 0.0.0.0 0.0.0.0 132.1.0.1
132.1.0.1 is the IP address of R1's serial 0 interface.
I will not be able to sleep at night until I figure out why this static
mroute works...
----Original Message Follows----
From: "Scott Morris" <swm@emanon.com>
Reply-To: <swm@emanon.com>
To: "'Greg Gombas'" <ggombas@hotmail.com>,<ccielab@groupstudy.com>
Subject: RE: PIM Sparse-Mode join RPF question
Date: Wed, 4 Jan 2006 16:26:40 -0500
Yes, sorry for not clarifying. (I couldn't tell which piece in your diagram
was going to be the source there)
The PIM DR by the source will unicast an SA message to the RP. If/when
there are joins going on, then you are correct, they're handled through the
PIM conversations multicast to 224.0.0.13 (AllPIMRouters).
While this conversation goes on, each router attempts to built an mroute
(incoming and outgoing interface lists), which obviously can only include
PIM-participating interfaces. At this point in time, there is no RPF check
occuring. It is only a hop-by-hop buildout. Once the actual multicast
messages start to flow at that point, there's an RPF check.
Does that help explain it better? What I'm getting by the question is that
the source is located somewhere else separate from these two routers...
Correct me if I'm wrong in that assumption.
Scott
-----Original Message-----
From: Greg Gombas [mailto:ggombas@hotmail.com]
Sent: Wednesday, January 04, 2006 2:16 PM
To: swm@emanon.com; ccielab@groupstudy.com
Subject: RE: PIM Sparse-Mode join RPF question
Hello Scott,
Thank you for replying.
When you say "the initial conversation to the RP is unicast" you are
referring the register message from the source, correct?
What I am talking about is the join message from the routers along the
shared tree to the RP. I thought the join messages are multicast hop-by-hop
to the destination address 224.0.0.13?
If so do the routers do an RPF check before sending the join packet? If so
how does an mroute solve this issue?
----Original Message Follows----
From: "Scott Morris" <swm@emanon.com>
Reply-To: <swm@emanon.com>
To: "'Greg Gombas'" <ggombas@hotmail.com>,<ccielab@groupstudy.com>
Subject: RE: PIM Sparse-Mode join RPF question
Date: Wed, 4 Jan 2006 13:25:25 -0500
The mroute is only an override to the INCOMING multicast stream check. So
yes, you would need it, because as any information comes from the RP it
would show the wrong interface. The same may be true of your multicast
source IP (if you had one) for the stream itself.
As for outbound information, the initial conversation to the RP is unicast,
so the path doesn't always matter (that's the simple answer, there are more
complicated reasons with this that may be more than you care to get into!
(the Beau Williamson book from Cisco Press is very good at this)). If you
run into issues or have multicast in both directions, it may also be
necessary for an ip mroute on R1 that shows R2's information (typically the
multicast source IP whether an ethernet or loopback).
If you want to watch the process and get a much better feel for it, type
doing a "debug ip mpacket detail" and "debug ip mrouting rpf-events" to see
whether things are what you expect or not!
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Greg
Gombas
Sent: Wednesday, January 04, 2006 11:56 AM
To: ccielab@groupstudy.com
Subject: PIM Sparse-Mode join RPF question
I was hoping one of the resident Multicast experts could explain this
scenario - maybe Mr. Scott Morris? (I read your chapter in CCIE practical
studies!)
[R1]-L0 150.1.1.1 <--- This is the RP
s0| |s1
| |
s0| |s1 <--- This interface is the preferred unicast route to RP but PIM
s0| |is
disabled.
[R2]
R1 and R2 are connected to each either by two point to point T1 links.
R2 needs to send a pim sparse-mode join to the RP which is the loopback
address of R1.
R2's unicast routing table shows Serial1 as the best route to the RP.
Unfortunately PIM is not allowed to be enabled on Serial1 and is only
enabled on Serial0.
In this situation, would the PIM join then be sent via Serial 0 instead? Or
would this cause an RPF failure?
I'm thinking the join would not be forwarded.
I believe the solution was to add a quad zero mroute pointing to the IP of
R1's Serial 0 interface.
Could someone explain why that would worK?
Thanks in advance!
This archive was generated by hypermail 2.1.4 : Wed Feb 01 2006 - 07:45:47 GMT-3