From: Bob Sinclair (bsin@cox.net)
Date: Sun Oct 24 2004 - 17:20:17 GMT-3
Tim,
It seems to me that whether a spoke-to-spoke mutlicast tunnel will require a
static mroute depends on the comparison of unicast metrics to the traffic
source. By default, my tunnel has a bw of 9 and a delay of 500000. You
could manipulate the unicast table by playing with the bandwidths or delay.
Generally, the static mroute is a better solution, since it is
multicast-specific.
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 2:55 PM
Subject: Re: Multicast over NBMA
> Bob,
>
> I'm happy that in a small way I was able to add to our understanding of
> this. I agree with you that this stuff is not all that well documented.
> Now, getting back to the original issue of when a spoke to spoke tunnel is
> needed, would you agree to the following?
>
> Tunnel not needed if:
> a) running sparse-mode (or sparse-dense) & auto-rp over partial meash F/R
> AND
> b) MA is located on or behind hub AND
> c) Mcast source is behind a spoke. AND
> d) Hub has ip pim nbma-mode configured on it's multipoint interface.
>
> If all the above conditions aren't met, then config a tunnel between the
> spokes.
>
> That said, I'm not sure if a tunnel by itself will work without also
> configuring a static mroute because I suspect the rpf check will fail.
>
> Suppose, for example, the MA were behind one spoke and the RP were behind
> the other spoke. With a spoke to spoke tunnel but without a static
> mroute,
> would the rpf check fail? My guess is that it would but I'm far from sure
> about that. What do you think?
>
> Tim
>
> ----- Original Message -----
> From: "Bob Sinclair" <bsin@cox.net>
> To: "ccie2be" <ccie2be@nyc.rr.com>; "Cisco certification"
> <ccielab@groupstudy.com>
> Cc: "Group Study" <ccielab@groupstudy.com>
> Sent: Sunday, October 24, 2004 2:16 PM
> Subject: Re: Multicast over NBMA
>
>
>> 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
>>
>> _______________________________________________________________________
>> 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