From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Aug 10 2004 - 21:32:35 GMT-3
> Now, I might be wrong. I haven't tested this. I don't have any first
> hand
> knowledge - only my limited understanding of what I've read in Beau's
book
> and some other sources. So, take what I say with a huge grain of
salt.
Tim,
The best approach is for you to test out the different setups
and look at what is happening in the mroute table and the debug output.
When you do this make sure you simulate traffic from the desired sources
as well, as the show output is no good unless there is an mcast feed.
What I mentioned before does not conflict with the text you are
referencing however. What he is effectively saying is that when you
have a dense group, it's traffic cannot be sent out the interface it is
received on. This is the reason that the MA should be at or behind the
hub. This is true.
What can make an exception to this is if your auto-rp candidate
RP and MA traffic are assigned to a default RP statically :) If the
group is sparse and nbma mode is enabled, the traffic can be sent out
the interface it is received on. It's not a very practical
configuration, but it's still a viable option.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> ccie2be
> Sent: Tuesday, August 10, 2004 5:47 PM
> To: Jongsoo.Kim@Intelsat.com
> Cc: andrew.m.edwards@boeing.com; tycampbell@comcast.net;
> chris.lord@lorien.co.uk; ccielab@groupstudy.com
> Subject: Re: Regarding "ip pim nbma-mode"
>
> I'm not entirely sure that's true.
>
> I suspect, but know for sure, that nbma mode *should* be used on hub
> router
> even if the multipoint f/r interface is running in sparse-dense mode.
>
> Here's my thinking.
>
> Once Auto-RP has completed it's mission of distributing all mcast
group to
> RP mappings, (which BTW, I don't think would be affected by whether or
not
> hub router's interface is running sparse-dense mode or not since the
auto-
> rp
> groups always run in dense mode), it's possible to have receivers
behind
> some spokes and no receivers behind other spokes.
>
> In this situation, I think that if nbma mode isn't running on hub
router,
> you'll have 2 problems.
>
> 1) When a receiver from behind one spoke sends a join up to the hub,
once
> the hub starts transmitting mcast traffic it will go to all spokes
since
> the
> hub's oil only has the multipoint interface as a whole in it's list,
not
> the
> individual ip addresses of the routers at each spoke. So, this will
> result
> in the spokes that don't want multicast traffic getting it anyway.
>
> 2) When a spoke router that doesn't want mcast traffic sends a prune
up
> to
> the hub, since the other routers don't hear that prune message, they
don't
> override it, so the hub stops sending mcast traffic down to the spokes
> even
> if some spokes want the mcast traffic.
>
> Now, I might be wrong. I haven't tested this. I don't have any first
> hand
> knowledge - only my limited understanding of what I've read in Beau's
book
> and some other sources. So, take what I say with a huge grain of
salt.
>
> HTH, Tim
>
>
> ----- Original Message -----
> From: <Jongsoo.Kim@Intelsat.com>
> To: <ccie2be@nyc.rr.com>
> Cc: <andrew.m.edwards@boeing.com>; <tycampbell@comcast.net>;
> <chris.lord@lorien.co.uk>; <ccielab@groupstudy.com>
> Sent: Tuesday, August 10, 2004 6:02 PM
> Subject: RE: Regarding "ip pim nbma-mode"
>
>
> > Tim
> >
> > I think it is subject to lab test. I hope someone do.
> > But how can you explain the fact that we shouldn't use ip pim
nbma-mode
> in
> > SD mode?
> >
> >
> > -----Original Message-----
> > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > Sent: Tuesday, 10 August, 2004 5:53 PM
> > To: Kim, Jongsoo; andrew.m.edwards@boeing.com;
tycampbell@comcast.net;
> > chris.lord@lorien.co.uk; ccielab@groupstudy.com
> > Subject: Re: Regarding "ip pim nbma-mode"
> >
> >
> > Number 2 is wrong.
> >
> > If you're running sparse mode, you MUST have nbma mode on the hub
> router.
> >
> >
> > ----- Original Message -----
> > From: <Jongsoo.Kim@Intelsat.com>
> > To: <ccie2be@nyc.rr.com>; <andrew.m.edwards@boeing.com>;
> > <tycampbell@comcast.net>; <chris.lord@lorien.co.uk>;
> > <ccielab@groupstudy.com>
> > Sent: Tuesday, August 10, 2004 5:44 PM
> > Subject: RE: Regarding "ip pim nbma-mode"
> >
> >
> > > Thanks Guys
> > >
> > > If I summarize all the stuff in this thread using the R1 as hub
and
> R2/R3
> > as
> > > spoke
> > > 1) Only use it in ip pim sparse-mode
> > > 2) Multicast will work over nbma with or without "ip pim
nbma-mode"
> > > 3) Though, ip pim nbma-mode is better to be used on R1(Hub)(but
> > R2/R3(spoke)
> > > are optional) as it enables fast-switched process, which adds
next-hop
> > > reachability to each neighbor in the mroute cache for the frame
relay
> > > interfaces as well as it enables prune-capability over nbma
connection
> so
> > > that each neighbor without member can be pruned by hub.
> > >
> > > Anything missed or wrong?
> > >
> > > JK
> > >
> > > -----Original Message-----
> > > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > > Sent: Tuesday, 10 August, 2004 4:52 PM
> > > To: Edwards, Andrew M; tycampbell@comcast.net; Lord, Chris; Kim,
> Jongsoo;
> > > ccielab@groupstudy.com
> > > Subject: Re: Regarding "ip pim nbma-mode"
> > >
> > >
> > > Andy,
> > >
> > > AS a PS:
> > >
> > > It doesn't matter where the RP is with respect to a nbma network.
> But,
> it
> > > does matter where the MA is if you're using Auto-rp. If your rp's
rp
> > > announce messages don't reach your MA, you've got problems.
> > >
> > > If your MA is located on or upstream of the hub, then the rp's
> > announcement
> > > messages will get to the MA & all will be fine in Cisco lab city.
> > >
> > > HTH, Tim
> > > ----- Original Message -----
> > > From: "Edwards, Andrew M" <andrew.m.edwards@boeing.com>
> > > To: <tycampbell@comcast.net>; "ccie2be" <ccie2be@nyc.rr.com>;
"Lord,
> > Chris"
> > > <chris.lord@lorien.co.uk>; <jongsoo.kim@intelsat.com>;
> > > <ccielab@groupstudy.com>
> > > Sent: Tuesday, August 10, 2004 2:26 PM
> > > Subject: RE: Regarding "ip pim nbma-mode"
> > >
> > >
> > > > The examples all have the hub as the RP, the source of the
multicast
> > > > stream is upstream from the NBMA network and flows traffic to
the RP
> and
> > > > down the shared tree towards the spokes.
> > > >
> > > > When I think about a shared tree it's an efficient and
deterministic
> > > > flow of multicast traffic, so, although unlikely by design, here
is
> what
> > > > I think would happen if the Hub were the RP, all spokes do NOT
have
> NBMA
> > > > mode enabled, and one of the spoke were to become a source.
> > > >
> > > > If the source of the (*,G) were at a spoke, then the spoke
router
> would
> > > > create a (S,G) towards the RP. The RP would in turn pass the
> traffic
> as
> > > > (*,G) towards all requesting members except the source spoke
because
> of
> > > > RPF. If the source spoke no longer wants to be in the group it
> would
> do
> > > > a prune. If the source were to now be a receiver only, then it
> would
> do
> > > > a join and the hub router would add a new next-hop entry under
the
> (*,G)
> > > > mroute.
> > > >
> > > > So I believe the only place it would be required is on the hub.
The
> > > > fact that the hub is also the RP has more to do with efficient
> mutlicast
> > > > flows on a shared tree.
> > > >
> > > > Now, the true question is, would you loose points on the lab for
> > > > enabling NBMA mode on all NBMA interfaces in the multicast
shared
> tree?
> > > >
> > > > Andy
> > > >
> > > > -----Original Message-----
> > > > From: tycampbell@comcast.net [mailto:tycampbell@comcast.net]
> > > > Sent: Tuesday, August 10, 2004 10:55 AM
> > > > To: Edwards, Andrew M; ccie2be; Lord, Chris;
> jongsoo.kim@intelsat.com;
> > > > ccielab@groupstudy.com
> > > > Subject: RE: Regarding "ip pim nbma-mode"
> > > >
> > > >
> > > > The only question I have concerning nbma-mode is, is it just
> configured
> > > > on the hub router in a frame-relay network, or should it be
> configured
> > > > on the spokes also ?
> > > >
> > > >
> > > >
> > > > > Check out Beau Williamson multicast book, page 456 begins the
> > > > > discussion on NBMA mode.
> > > > >
> > > > > Basically using NBMA mode adds next-hop reachability in the
mroute
> > > > > cache for the frame relay interfaces. This is not
pseudobroadcast
> > > > > (e.g. broadcast replication), but instead fast-switched by the
> router.
> > > > >
> > > > > So if you do show ip mroute with NBMA mode, you will see
multiple
> > > > > entries for each spokes next hop addresses on a single (*,G)
> mroute
> > > > > entry.
> > > > >
> > > > > Why not use it for dense mode? The book says that NBMA mode
could
> > > > work
> > > > > for dense mode, but the router doesn't support it... 8)
> > > > >
> > > > > When I think about it though, I wouldn't want dense mode on
NBMA
> with
> > > > > NBMA mode enabled because the router would have to change the
> mroute
> > > > > cache every 3 minutes as a result of a dense mode flooding to
all
> > > > > spokes, and the subsequent pruning of unwanted multicast
traffic.
> But
> > > >
> > > > > for sparse-mode only it works like a champ because the routers
> request
> > > >
> > > > > the traffic.
> > > > >
> > > > > HTH
> > > > > andy
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > > > > Sent: Tuesday, August 10, 2004 10:19 AM
> > > > > To: Lord, Chris; jongsoo.kim@intelsat.com;
ccielab@groupstudy.com
> > > > > Subject: Re: Regarding "ip pim nbma-mode"
> > > > >
> > > > >
> > > > > Chris,
> > > > >
> > > > > I wasn't really talking about the purpose of this command but
> rather
> > > > > why this command is needed with sparse mode but not needed
with
> dense
> > > > > mode.
> > > > >
> > > > > But, you're right about your point about mcast traffic not
going
> to
> a
> > > > > spoke witch doesn't want it.
> > > > >
> > > > > You probably know this already, but just in case, you should
be
> aware
> > > > > of how this command makes mcast work a bit differently on p2m
> > > > > interfaces like F/R and ATM compared with Lan interfaces.
> > > > >
> > > > > With lan interfaces, the oil only has the actual interface,
but
> with
> > > > > p2m interfaces the oil has the interface plus an indicator of
the
> > > > > individual dlci or pvc being used to reach the spoke. The
result
> of
> > > > > this is that when a join or prune is received from a spoke
router,
> the
> > > >
> > > > > mcast flow will only change for the spoke that sent the
meassage.
> > > > > Other spokes will continue or not continue to receive mcast
> traffic
> > > > > without regard for what message was sent by that one spoke.
> > > > >
> > > > > HTH, Tim
> > > > >
> > > > >
> > > > > ----- Original Message -----
> > > > > From: "Lord, Chris" <chris.lord@lorien.co.uk>
> > > > > To: "ccie2be" <ccie2be@nyc.rr.com>;
<jongsoo.kim@intelsat.com>;
> > > > > <ccielab@groupstudy.com>
> > > > > Sent: Tuesday, August 10, 2004 12:30 PM
> > > > > Subject: RE: Regarding "ip pim nbma-mode"
> > > > >
> > > > >
> > > > > > Tim,
> > > > > >
> > > > > > My understanding of its purpose is slightly different - but
I'm
> not
> > > > > > 100%
> > > > > either.....
> > > > > >
> > > > > > Suppose R1, R2 and R3 are all running sparse mode with
static RP
> > > > > > where
> > > > >
> > > > > > the
> > > > > RP is at the hub or upstream of it - simple enough.
> > > > > >
> > > > > > When R1 pushes mcast packets out of its serial nbma
interface
> then
> > > > > > by
> > > > > default they will be sent to both dlcis and hence to both R2
and
> R3,
> > > > > provided "either one of them" has clients. This can result in
> > > > > unnecdessary traffic going to either R2 or R3 if no clients
exist
> on
> > > > > one of them. pim nbma mode changes this default behaviour so
that
> > > > > packets only get sent to R1 or R2 if they have active clients
on
> them.
> > > > > >
> > > > > > Chris.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > > > > > Sent: Tuesday, August 10, 2004 5:13 PM
> > > > > > To: jongsoo.kim@intelsat.com; ccielab@groupstudy.com
> > > > > > Subject: Re: Regarding "ip pim nbma-mode"
> > > > > >
> > > > > >
> > > > > > JK,
> > > > > >
> > > > > > You are correct. Only R1 does need this command.
> > > > > >
> > > > > > RE: your 2nd question, consider this.
> > > > > >
> > > > > > Let's assume that the mcast domain is operating in Dense
mode.
> In
> > > > > > this case, R1 will only prune the mcast stream when the last
> > > > > > downstream mcast receiver sends a prune. If a prune is sent
by
> R2
> > > > to
> > > > > > R1 but R3 still needs to receive mcast traffic, R1 will
ignore
> the
> > > > > > prune and continue to send. So, that's why nbma mode isn't
> needed
> > > > with
> > > > >
> > > > > > dense mode.
> > > > > >
> > > > > > Now, sparse-dense mode might be a different matter. The way
I
> > > > > > understand it, this mode is only needed when running Auto-RP
> because
> > > >
> > > > > > then the auto-rp groups 224.0.0.39 and .40 run in dense mode
but
> the
> > > >
> > > > > > other groups run in sparse mode.
> > > > > >
> > > > > > Now, I'm not 100% positive, but I would use the nbma mode
> command
> in
> > > > > > this situation because I wouldn't want the mcast groups
running
> > > > sparse
> > > > >
> > > > > > mode to have their traffic cut off when the hub gets a prune
> > > > > > message.
> > > > > >
> > > > > > One thing you have to keep in mind is that if you're running
> > > > > > Auto-rp,
> > > > > > the
> > > > > MA
> > > > > > must be either on the hub or upstream of the hub because if
it's
> on
> > > > > > a
> > > > > spoke
> > > > > > then other spokes won't get the group - rp mappings sent out
by
> the
> > > > > > MA.
> > > > > The
> > > > > > RP can be behind a spoke. That's OK as long as the MA is
> reachable
> > > > > > by
> > > > > > the
> > > > > rp
> > > > > > announce messages.
> > > > > >
> > > > > > HTH, Tim
> > > > > > ----- Original Message -----
> > > > > > From: <jongsoo.kim@intelsat.com>
> > > > > > To: <ccielab@groupstudy.com>
> > > > > > Sent: Tuesday, August 10, 2004 11:18 AM
> > > > > > Subject: Regarding "ip pim nbma-mode"
> > > > > >
> > > > > >
> > > > > > > The way I understand this commnad is to enable somewhat
> multicast
> > > > > > capability on NBMA link such as F/R PVC.
> > > > > > >
> > > > > > > This is my interpretation.
> > > > > > > So let's say R1,R2,R3 are PIM neighbor, if R1 connected to
R2
> and
> > > > > > > R3
> > > > >
> > > > > > > via
> > > > > > multipoint PVC using hub and spoke, then by using this
command,
> R1
> > > > > > can
> > > > > send
> > > > > > multicast to R2 and R3, which of course should be two
identical
> > > > > > multicast traffic stream but with different DLCI.
> > > > > > >
> > > > > > > If this is the case, I think only R1 needs this commnad as
R1
> is
> > > > > > > HUB
> > > > >
> > > > > > > and
> > > > > > R2 and R3 are spoke.
> > > > > > >
> > > > > > > Am I in a right track on this??
> > > > > > >
> > > > > > >
> > > > > > > Also, I can't figure out why sparse-dense mode shouldn't
use
> this
> > > > > command.
> > > > > > >
> > > > > > >
> > > > > > > Thanks folks
> > > > > > >
> > > > > > > JK
> > > > > > >
> > > > > > >
> __________________________________________________________________
> > > > > > > __
> > > > > > > ___
> > > > > > > Please help support GroupStudy by purchasing your study
> materials
> > > > > from:
> > > > > > > http://shop.groupstudy.com
> > > > > > >
> > > > > > > Subscription information may be found at:
> > > > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > > >
> > > > > >
> ____________________________________________________________________
> > > > > > __
> > > > > > _
> > > > > > Please help support GroupStudy by purchasing your study
> materials
> > > > > from:
> > > > > > http://shop.groupstudy.com
> > > > > >
> > > > > > Subscription information may be found at:
> > > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > > >
> > > > > >
> > > > > >
> ********************************************************************
> > > > > > **
> > > > > > The information contained in this email is confidential and
is
> > > > > > intended
> > > > > for the recipient only. If you have received it in error,
please
> > > > > notify us immediately by reply email and then delete it from
your
> > > > > system. Please do not copy it or use it for any purposes, or
> disclose
> > > > > its contents to any other person or store or copy this
information
> in
> > > > > any medium. The views contained in this email are those of the
> author
> > > > > and not necessarily those of Lorien plc.
> > > > > >
> > > > > > Thank you for your co-operation.
> > > > > >
> ********************************************************************
> > > > > > **
> > > > > >
> > > > > >
> ____________________________________________________________________
> > > > > > __
> > > > > > _
> > > > > > Please help support GroupStudy by purchasing your study
> materials
> > > > > from:
> > > > > > http://shop.groupstudy.com
> > > > > >
> > > > > > Subscription information may be found at:
> > > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> ______________________________________________________________________
> > > > > _
> > > > > Please help support GroupStudy by purchasing your study
materials
> > > > from:
> > > > > http://shop.groupstudy.com
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > > >
> > > > >
> ______________________________________________________________________
> > > > > _
> > > > > Please help support GroupStudy by purchasing your study
materials
> > > > from:
> > > > > http://shop.groupstudy.com
> > > > >
> > > > > Subscription information may be found at:
> > > > > http://www.groupstudy.com/list/CCIELab.html
> > > >
> > > >
>
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:40 GMT-3