From: tycampbell@comcast.net
Date: Tue Aug 10 2004 - 14:54:43 GMT-3
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:36 GMT-3