From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 10 2004 - 18:48:12 GMT-3
Brian,
I think this may one time you're mistaken (unless Beau Willianson is
mistaken).
Now, here's an interesting question, when it comes to Multicast, between
Brian or Beau, who is more likely to be correct when they disagree?
See bottom of page 459 of Beau's book, "As long as all MA's are inside the
central site network, Auto-RP should function as desired."
To me this sounds like, there'll be problems if the MA is only behind spoke
routers, but I've nver tested this so I speak not with first hand knowledge.
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; <ccielab@groupstudy.com>
Sent: Tuesday, August 10, 2004 5:21 PM
Subject: RE: Regarding "ip pim nbma-mode"
> 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
> > > >
> > > >
> >
> _______________________________________________________________________
> > > > 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