From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 10 2004 - 22:31:28 GMT-3
See comments in-line
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <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 8:32 PM
Subject: RE: Regarding "ip pim nbma-mode"
> > 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 :)
Huh??? what does that mean?
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.
>
So, is it fair to say you're confirming what I said below about the 2
problems that will exist if nbma mode isn't enabled on the hub router in the
situation as described earlier?
Thanks, Tim
>
> 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
> > > > >
> > > > >
> >
> _______________________________________________________________________
> > > > > 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
>
> _______________________________________________________________________
> 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:41 GMT-3