From: Bob Sinclair (bsin@cox.net)
Date: Sun Oct 24 2004 - 15:16:21 GMT-3
Tim,
Very good point. I labbed this up and learned something. When I source the
multicast from a router behind R3, then R3 registers the source with the RP
at R2. R2 now knows the source address, and builds an SPT back through the
hub to R3. This S-bit join does trigger the placement of R2 in the OIL.
The traffic does flow, and pim NBMA-mode keeps track of the neighbors
separately on the multipoint.
By contrast, when I source the traffic from R3 directly (rather than from a
router behind R3), then we are counting on R1 to register traffic to an RP
that is on the same interface (which it seems not to do) and the traffic
does not flow.
So, the RP can be on a spoke with PIM NMBA-mode, as you originally
suggested. It does appear that both the *,G (shared tree) and S,G
(Shortest-Path Tree) joins will trigger the nbma-mode OIL. One caveat, it
seems the source must be behind, the other spoke, not the spoke itself.
Thanks!
Bob Sinclair
CCIE #10427, CISSP, MCSE
www.netmasterclass.net
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: "Bob Sinclair" <bsin@cox.net>; "Cisco certification"
<ccielab@groupstudy.com>
Cc: "Group Study" <ccielab@groupstudy.com>
Sent: Sunday, October 24, 2004 9:54 AM
Subject: Re: Multicast over NBMA
> Hey Bob,
>
> Thanks, that's a great example.
>
> But, what happens when R2, the RP, receives a join from a directly
> connected
> or downstream client? Wouldn't
> R2 try to create a SPT to the source by sending a (S, G) Join rather than
> a
> (*,G) join to R1 which R1
> would then forward to R3?
>
> I'm a little fuzzy on this because I don't know how R2 would know where
> the
> source is unless the source were already sending traffic.
>
> Tim
>
>
> ----- Original Message -----
> From: "Bob Sinclair" <bsin@cox.net>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Cisco certification"
> <ccielab@groupstudy.com>
> Sent: Saturday, October 23, 2004 5:28 PM
> Subject: Re: Multicast over NBMA
>
>
>> Tim,
>>
>> Suppose R1 is the hub and R2 and R3 are the spokes. You want to send
>> multicast from R3 to R2, or a client behind R2. Given this frame-relay
>> hub-and-spoke topology, that stream will have to go into and back out of
> the
>> R1 frame-relay multipoint interface. If you put the RP on R2, then R1
> will
>> never receive a *,G from R2 for the multicast group, and R1 will not put
> R2
>> on the outgoing interface. If you place the RP on R1 or R3 (so that R1
> sees
>> the *,G), then R2 will go on the OIL and the sparse-mode flow will work
> from
>> spoke to spoke. This is our experience. But again, I have not seen the
>> ability of nbma-mode to permit sparse-mode traffic from spoke to spoke
>> documented.
>>
>> HTH,
>>
>> Bob Sinclair
>> CCIE #10427, CISSP, MCSE
>> www.netmasterclass.net
>>
>> ----- Original Message -----
>> From: "ccie2be" <ccie2be@nyc.rr.com>
>> To: "Bob Sinclair" <bsin@cox.net>; "Cisco certification"
>> <ccielab@groupstudy.com>
>> Sent: Saturday, October 23, 2004 5:12 PM
>> Subject: Re: Multicast over NBMA
>>
>>
>> > Hi Bob,
>> >
>> > AFAIK, ip pim nbma isn't supported for dense mode - it only works for
>> > sparse
>> > or sparse-dense-mode.
>> >
>> > But, I'm not sure I understand what you mean when you say, "the
> multipoint
>> > interface must be on the path to the RP if nbma-mode is going work to
>> > allow
>> > sparse-mode flows into and back out of the hub on the same multipoint
>> > interface."
>> >
>> > Do you mean that the RP can't be configured on or behind a spoke router
> in
>> > a
>> > hub and spoke partial mesh even if the MA is configured on or behind
>> > the
>> > hub
>> > router? If so, why not?
>> >
>> > Tim
>> >
>> >
>> >
>> > ----- Original Message -----
>> > From: "Bob Sinclair" <bsin@cox.net>
>> > To: "Cisco certification" <ccielab@groupstudy.com>
>> > Sent: Saturday, October 23, 2004 4:06 PM
>> > Subject: Re: Multicast over NBMA
>> >
>> >
>> >> Tim,
>> >>
>> >> It is important to have the MA at the hub if you are distributing the
>> >> 224.0.1.40 group in dense mode. NBMA-mode is not effective for dense
>> >> mode
>> >> flows, since dense mode does not send the *,G entries that NBMA-mode
>> > relies
>> >> upon to populate the OIL.
>> >>
>> >> The prune-override function of nbma-mode is well-documented, but its
>> > ability
>> >> to overcome the hub-and-spoke-OIL problem is not, IMHO.
>> >>
>> >> We lab this up in NMC-1 class, and it is our experience that the
>> > multipoint
>> >> interface must be on the path to the RP if nbma-mode is going work to
>> > allow
>> >> sparse-mode flows into and back out of the hub on the same multipoint
>> >> interface.
>> >>
>> >> Bob Sinclair
>> >> CCIE #10427, CISSP, MCSE
>> >> www.netmasterclass.net
>> >>
>> >> ----- Original Message -----
>> >> From: "ccie2be" <ccie2be@nyc.rr.com>
>> >> To: "Bob Sinclair" <bsin@cox.net>; "AK Singh" <singh.anand@gmail.com>;
>> >> "Cisco certification" <ccielab@groupstudy.com>
>> >> Sent: Saturday, October 23, 2004 2:34 PM
>> >> Subject: Re: Multicast over NBMA
>> >>
>> >>
>> >> > Hi Bob,
>> >> >
>> >> > I'm not sure we're saying different things. I was going by what
>> >> > Beau
>> >> > Willianson wrote in his book Developing IP Multicast networks on
>> >> > page
>> >> > 458 -
>> >> > 460.
>> >> >
>> >> > In his example, the RP is behind a spoke router, but the MA is
>> >> > behind
>> > the
>> >> > hub router. The network is, of course, running Auto-RP.
>> >> >
>> >> > With the RP behind one of the spoke routers, the other spoke routers
>> > don't
>> >> > hear the rp annouce messages from the rp, but the MA behind the hub
>> > does.
>> >> > And, since the MA then sends out the rp to group mappings, all the
>> >> > spoke
>> >> > routers hear them. Is this not correct?
>> >> >
>> >> > And, when the hub is configured with ip pim nbma mode, joins and
> prunes
>> >> > from
>> >> > the spoke routers don't affect joins and prunes from other spoke
>> > routers.
>> >> >
>> >> > Have anything changed since this was written or am I
> mis-understanding
>> >> > something critical?
>> >> >
>> >> > Tim
>> >> >
>> >> > ----- Original Message -----
>> >> > From: "Bob Sinclair" <bsin@cox.net>
>> >> > To: "ccie2be" <ccie2be@nyc.rr.com>; "AK Singh"
> <singh.anand@gmail.com>;
>> >> > "Cisco certification" <ccielab@groupstudy.com>
>> >> > Sent: Saturday, October 23, 2004 12:07 PM
>> >> > Subject: Re: Multicast over NBMA
>> >> >
>> >> >
>> >> >> Tim,
>> >> >>
>> >> >> If you are saying that the placement of the RP is irrelevant to the
>> >> >> operation of PIM NBMA-mode in AK's scenario, then I beg to differ.
> If
>> > the
>> >> >> hub interface is not on the path between the spoke and the RP, then
>> >> >> the
>> >> > hub
>> >> >> will not receive a *,G from that spoke, that spoke will not show up
> on
>> >> >> the
>> >> >> hub's OIL, and it will not receive multicast traffic from another
>> > spoke.
>> >> >> Lab it up.
>> >> >>
>> >> >>
>> >> >> Bob Sinclair
>> >> >> CCIE #10427, CISSP, MCSE
>> >> >> www.netmasterclass.net
>> >> >>
>> >> >> ----- Original Message -----
>> >> >> From: "ccie2be" <ccie2be@nyc.rr.com>
>> >> >> To: "AK Singh" <singh.anand@gmail.com>; "Cisco certification"
>> >> >> <ccielab@groupstudy.com>
>> >> >> Sent: Saturday, October 23, 2004 11:24 AM
>> >> >> Subject: Re: Multicast over NBMA
>> >> >>
>> >> >>
>> >> >> > The way I understand it, it's not the placement of the rp that
>> > matters
>> >> > as
>> >> >> > far as reachability is concerned. It's the placement of the
> Mapping
>> >> >> > Agent.
>> >> >> > Also, this issue is only relevant when running Auto-rp. It's not
> an
>> >> > issue
>> >> >> > if using static rp or BSR.
>> >> >> >
>> >> >> > You are correct about not needing a tunnel between the spokes
>> >> >> > when
>> >> >> > ip
>> >> > pim
>> >> >> > nbma is running on the hub, but do you understand why that is?
>> >> >> >
>> >> >> > In case you don't, here's the reason. Without ip pim nbma on the
>> > hub,
>> >> >> > when
>> >> >> > a mcast stream starts flowing from the hub to the spokes assuming
>> >> >> > one
>> >> >> > spoke
>> >> >> > wants the stream but the other spoke doesn't, the spoke that
> doesn't
>> >> > want
>> >> >> > the stream sends a prune up to the hub.
>> >> >> >
>> >> >> > Without nbma mode on the hub, the hub doesn't realize that one of
>> >> >> > the
>> >> >> > spokes
>> >> >> > still wants the mcast stream. So, since the hub has only one
>> > interface
>> >> > to
>> >> >> > reach both spokes and it now gets a prune message, it removes
>> >> >> > that
>> >> >> > interface
>> >> >> > from the outgoing interface list (OIL) and stops the mcast stream
>> > from
>> >> >> > reaching either spoke.
>> >> >> >
>> >> >> > With nbma mode, the OIL contains both spokes. So, when the hub
> gets
>> >> >> > a
>> >> >> > prune
>> >> >> > from just one of the spokes, it only removes that one spoke from
>> >> >> > it's
>> >> > OIL.
>> >> >> > The other spoke continues to receive the mcast stream.
>> >> >> >
>> >> >> > For more details on this, look for the mcast training
> presentations
>> >> > slides
>> >> >> > on cisco.com
>> >> >> >
>> >> >> > HTH, Tim
>> >> >> >
>> >> >> >
>> >> >> > ----- Original Message -----
>> >> >> > From: "AK Singh" <singh.anand@gmail.com>
>> >> >> > To: "Cisco certification" <ccielab@groupstudy.com>
>> >> >> > Sent: Saturday, October 23, 2004 10:14 AM
>> >> >> > Subject: Multicast over NBMA
>> >> >> >
>> >> >> >
>> >> >> >> Hello folks,
>> >> >> >>
>> >> >> >> I know thie topic has been discussed in several ways on this
> alias.
>> > I
>> >> >> >> searched but couldn't get a direct answer hence posting on this
>> > alias.
>> >> >> >> Appreciate any response.
>> >> >> >>
>> >> >> >> Let us say we are running pim in sparse mode and we have take RP
>> >> >> >> issues (i .e spokes are learning correct RPs, the RP is places a
>> >> >> >> router which is on top of hub and we are using autorp listener).
>> >> >> >>
>> >> >> >> Now when to send a feed (ping to the group) from one of the
>> >> >> >> spoke
>> >> >> >> to
>> > a
>> >> >> >> group on other spoke, do we always need a tunnel to be created
>> > between
>> >> >> >> spokes for this?
>> >> >> >>
>> >> >> >> Here is my undestanding (please correct me), we don't need
> tunnel
>> >> >> >> between spokes when we are using either:
>> >> >> >>
>> >> >> >> 1) pim nbma mode
>> >> >> >> 2) spokes have brodcast capability between them.
>> >> >> >>
>> >> >> >> When else do we need? Any more lights on this topic.
>> >> >> >>
>> >> >> >> Thanks
>> >> >> >> -Anand
>> >> >> >>
>> >> >> >>
>> > _______________________________________________________________________
>> >> >> >> Subscription information may be found at:
>> >> >> >> http://www.groupstudy.com/list/CCIELab.html
>> >> >> >
>> >> >> >
>> > _______________________________________________________________________
>> >> >> > Subscription information may be found at:
>> >> >> > http://www.groupstudy.com/list/CCIELab.html
>> >> >
>> >> >
> _______________________________________________________________________
>> >> > Subscription information may be found at:
>> >> > http://www.groupstudy.com/list/CCIELab.html
>> >>
>> >> _______________________________________________________________________
>> >> Subscription information may be found at:
>> >> http://www.groupstudy.com/list/CCIELab.html
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:52 GMT-3