From: Wei Zhu (zhuwei1231@yahoo.ca)
Date: Tue Aug 10 2004 - 21:07:28 GMT-3
This is helpful
http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/mcst_sol/frm_rlay.htm
Wei
----- Original Message -----
From: "ccie2be" <ccie2be@nyc.rr.com>
To: <Jongsoo.Kim@Intelsat.com>
Cc: <andrew.m.edwards@boeing.com>; <tycampbell@comcast.net>;
<chris.lord@lorien.co.uk>; <ccielab@groupstudy.com>
Sent: Tuesday, August 10, 2004 6:47 PM
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
> > > >
> > > >
> _______________________________________________________________________
> > > > 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
> > >
> > > ############################################################
> > >
> > > Building on 40 Years of Leadership - As a global communications leader
> > with 40 years of experience, Intelsat helps service providers,
> > > broadcasters, corporations and governments deliver information and
> > entertainment anywhere in the world, instantly, securely and reliably.
> > >
> > > ############################################################
> > > This email message is for the sole use of the intended
> > > recipient(s) and may contain confidential and privileged
> > > information. Any unauthorized review, use, disclosure or
> > > distribution is prohibited. If you are not the intended
> > > recipient, please contact the sender by reply email and
> > > destroy all copies of the original message. Any views
> > > expressed in this message are those of the individual
> > > sender, except where the sender specifically states them
> > > to be the views of Intelsat, Ltd. and its subsidiaries.
> > > ############################################################
> >
> > ############################################################
> >
> > Building on 40 Years of Leadership - As a global communications leader
> with 40 years of experience, Intelsat helps service providers,
> > broadcasters, corporations and governments deliver information and
> entertainment anywhere in the world, instantly, securely and reliably.
> >
> > ############################################################
> > This email message is for the sole use of the intended
> > recipient(s) and may contain confidential and privileged
> > information. Any unauthorized review, use, disclosure or
> > distribution is prohibited. If you are not the intended
> > recipient, please contact the sender by reply email and
> > destroy all copies of the original message. Any views
> > expressed in this message are those of the individual
> > sender, except where the sender specifically states them
> > to be the views of Intelsat, Ltd. and its subsidiaries.
> > ############################################################
> >
> > _______________________________________________________________________
> > 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