From: Jongsoo.Kim@Intelsat.com
Date: Tue Aug 10 2004 - 21:44:12 GMT-3
I did some research and found many answers.
(http://www.cisco.com/en/US/partner/tech/tk828/tk363/technologies_white_pape
r09186a00800d6b61.shtml)
Your statement seems basically correct.
F/R multipoint may work without ip pim nbma-mode using pseudobroadcast but
with all kind of problems.
Main issues are
1) the overusage of BW and broadcast queue by pseudobroadcast, which can
result in other important multicast( OSPF) packets to be dropped.
2) Prune Message Override Failure
The reason why Dense mode is not working with ip pim nbma-mode is explained
as well saying this command applies to only PIM sparse mode configurations
because its functionality is dependent on the PIM sparse mode join message.
The reason why we have to put MA in Hub in nbma mode is Auto-RP is not
supported by nbma-mode as it is using dense mode.
So Auto-RP is based on pseudobroadcast, which will create " split-horizon"
issue, meaning if MA is located in spoke, then other spokes except hub
router won't receive Auto-RP flood. I think location of RP is not big issue
as the mcast traffic will be based on nbma-mode.
Now, I am thinking in F/R multipoint environment, sparse-mode + nbma-mode +
MA in HUB are the only solution.
All other combination can have some sort of problems.
I hope this is good conclusion as I am far from multicast expert.
JK
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tuesday, 10 August, 2004 6:47 PM
To: Kim, Jongsoo
Cc: andrew.m.edwards@boeing.com; tycampbell@comcast.net;
chris.lord@lorien.co.uk; ccielab@groupstudy.com
Subject: Re: Regarding "ip pim nbma-mode"
I'm not entirely sure that's true.
I suspect, but know for sure, that nbma mode *should* be used on hub router
even if the multipoint f/r interface is running in sparse-dense mode.
Here's my thinking.
Once Auto-RP has completed it's mission of distributing all mcast group to
RP mappings, (which BTW, I don't think would be affected by whether or not
hub router's interface is running sparse-dense mode or not since the auto-rp
groups always run in dense mode), it's possible to have receivers behind
some spokes and no receivers behind other spokes.
In this situation, I think that if nbma mode isn't running on hub router,
you'll have 2 problems.
1) When a receiver from behind one spoke sends a join up to the hub, once
the hub starts transmitting mcast traffic it will go to all spokes since the
hub's oil only has the multipoint interface as a whole in it's list, not the
individual ip addresses of the routers at each spoke. So, this will result
in the spokes that don't want multicast traffic getting it anyway.
2) When a spoke router that doesn't want mcast traffic sends a prune up to
the hub, since the other routers don't hear that prune message, they don't
override it, so the hub stops sending mcast traffic down to the spokes even
if some spokes want the mcast traffic.
Now, I might be wrong. I haven't tested this. I don't have any first hand
knowledge - only my limited understanding of what I've read in Beau's book
and some other sources. So, take what I say with a huge grain of salt.
HTH, Tim
----- Original Message -----
From: <Jongsoo.Kim@Intelsat.com>
To: <ccie2be@nyc.rr.com>
Cc: <andrew.m.edwards@boeing.com>; <tycampbell@comcast.net>;
<chris.lord@lorien.co.uk>; <ccielab@groupstudy.com>
Sent: Tuesday, August 10, 2004 6:02 PM
Subject: RE: Regarding "ip pim nbma-mode"
> Tim
>
> I think it is subject to lab test. I hope someone do.
> But how can you explain the fact that we shouldn't use ip pim nbma-mode in
> SD mode?
>
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Tuesday, 10 August, 2004 5:53 PM
> To: Kim, Jongsoo; andrew.m.edwards@boeing.com; tycampbell@comcast.net;
> chris.lord@lorien.co.uk; ccielab@groupstudy.com
> Subject: Re: Regarding "ip pim nbma-mode"
>
>
> Number 2 is wrong.
>
> If you're running sparse mode, you MUST have nbma mode on the hub router.
>
>
> ----- Original Message -----
> From: <Jongsoo.Kim@Intelsat.com>
> To: <ccie2be@nyc.rr.com>; <andrew.m.edwards@boeing.com>;
> <tycampbell@comcast.net>; <chris.lord@lorien.co.uk>;
> <ccielab@groupstudy.com>
> Sent: Tuesday, August 10, 2004 5:44 PM
> Subject: RE: Regarding "ip pim nbma-mode"
>
>
> > Thanks Guys
> >
> > If I summarize all the stuff in this thread using the R1 as hub and
R2/R3
> as
> > spoke
> > 1) Only use it in ip pim sparse-mode
> > 2) Multicast will work over nbma with or without "ip pim nbma-mode"
> > 3) Though, ip pim nbma-mode is better to be used on R1(Hub)(but
> R2/R3(spoke)
> > are optional) as it enables fast-switched process, which adds next-hop
> > reachability to each neighbor in the mroute cache for the frame relay
> > interfaces as well as it enables prune-capability over nbma connection
so
> > that each neighbor without member can be pruned by hub.
> >
> > Anything missed or wrong?
> >
> > JK
> >
> > -----Original Message-----
> > From: ccie2be [mailto:ccie2be@nyc.rr.com]
> > Sent: Tuesday, 10 August, 2004 4:52 PM
> > To: Edwards, Andrew M; tycampbell@comcast.net; Lord, Chris; Kim,
Jongsoo;
> > 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