From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 10 2004 - 17:31:48 GMT-3
I recall seeing a discussion that included Scott Morris on this question.
What I recall him saying is that nbma-mode is not required on the spokes,
however, because this mode makes the router operate more efficiently (fast
switched vs process switched), it's a good idea in a production network.
RE: the lab, I don't think one would lose points whether or not nbma mode is
configured on spokes or not, however, if in doubt, ask the proctor.
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