From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Aug 10 2004 - 18:04:22 GMT-3
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
> > > > >
> > > > >
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:40 GMT-3