From: Edwards, Andrew M (andrew.m.edwards@boeing.com)
Date: Tue Aug 10 2004 - 14:43:37 GMT-3
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
This archive was generated by hypermail 2.1.4 : Fri Sep 03 2004 - 07:02:36 GMT-3