From: Bob Sinclair (bsin@cox.net)
Date: Sat Oct 23 2004 - 18:28:12 GMT-3
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
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:52 GMT-3