From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Aug 10 2004 - 18:21:20 GMT-3
But if you said that it doesn't matter where the mapping agent is either
;)
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: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, August 10, 2004 4:20 PM
> To: Brian McGahan; ccielab@groupstudy.com
> Subject: Re: Regarding "ip pim nbma-mode"
>
> Brian,
>
> If I had mentioned "with nbma mode configured on the hub router", then
it
> would be true that it doesn't matter where the RP is, corect?
>
>
> ----- Original Message -----
> From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
> To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
> Sent: Tuesday, August 10, 2004 5:04 PM
> Subject: RE: Regarding "ip pim nbma-mode"
>
>
> Tim,
>
> This isn't necessarily true. When using a shared-tree, the
> traffic must pass through the RP before it gets to the client. For
> example if this transit path takes the packet from a spoke of the NBMA
> network, and the destination is out the same interface, the traffic
will
> be null routed.
>
> NBMA mode can be used to resolve this problem, but it is the
> same case you are mentioning about the mapping agent.
>
> 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 3:52 PM
> > To: Edwards, Andrew M; tycampbell@comcast.net; Lord, Chris;
> > jongsoo.kim@intelsat.com; 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