From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Aug 10 2004 - 18:39:02 GMT-3
Yep, it's because of nbma mode that the hub router now keeps track of each
spoke router that allows this work.
The way the hub keeps track of each spoke depends on what type of L2 network
you have - Frame Relay, ATM or Dial.
That's right, don't forget that dial is also a nbma type of network although
since the lab only has 2 isdn routers this isn't really an issue in that
regard. (Also, if dialer profiles are used, it's also not an issue since
dialer profiles are p2p by definition.) However, if those evil lab writers
threw something at you like "make sure Rx forwards mcast traffic and assume
additional remote routers will be added in the future, then ip pim nbma mode
should be added to the hub isdn router.
You can see the effect of the nbma mode command, if you do a show ip mroute
on a hub router when multiple spoke routers exist.
Without nbma mode, you'll only see your f/r multipoint interface listed
only once.
With nbma mode enabled, you'll see your f/r multipoint interface listed once
for each spoke with the ip addr of the spoke shown next to the interface.
For additional info, I can recommend the book, Developing IP Multicst
Networks by Beau Williamson. ISBN 1-57870-077-9
Also, there's a set of mcast slide presentations on cco that are excellent.
I can't tell you where they are since I don't have partner access anymore
and I think that's where I found them originally. But, if you look around,
they might still be there somewhere.
HTH, Tim
----- Original Message -----
From: "Lord, Chris" <chris.lord@lorien.co.uk>
To: "ccie2be" <ccie2be@nyc.rr.com>
Sent: Tuesday, August 10, 2004 4:55 PM
Subject: RE: Regarding "ip pim nbma-mode"
Tim,
Re last paragraph - I wasn't aware in that level of detail.
Thx
Chris
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tuesday, August 10, 2004 6:19 PM
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:40 GMT-3