From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 10 2004 - 18:52:47 GMT-3
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.
> ############################################################
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:40 GMT-3