From: Brian Hescock \(bhescock\) (bhescock@cisco.com)
Date: Thu Mar 29 2007 - 17:49:31 ART
Luca,
It's possible the behavior may have changed in newer IOS (or it could
be "unexpected behavior") and the documentation might not yet reflect
the newer method of handling the prunes on the hub router; it can be
difficult to keep the documentation up-to-date with all of the constant
change in new / modified features, etc. You could submit feedback on
the documentation and you should get a response within 1-2 months or
less after they've looked into it (it does take awhile).
I've never personally noticed what you're seeing since I always use pim
nbma-mode in that situation. It would be best to use pim nbma-mode
anyway so after the prune-override the multicast isn't replicated to all
spokes on the multipoint interface when at least one of the spokes
doesn't want it. Consider the impact on heavily used circuits, why
transmit mcast across the circuit only to drop it on the spoke that
doesn't want it, as well as the impact on the spoke router having to
drop all that traffic.
Regards,
Brian
-----Original Message-----
From: Bit Gossip [mailto:bit.gossip@chello.nl]
Sent: Thursday, March 29, 2007 4:07 PM
To: Brian Hescock (bhescock)
Cc: ccielab
Subject: RE: multicast very fundamental
Hi Brian,
I am very happy that you picked my request for help.
The doc is very clear about 'ip pim nbma-mode' and I have no doubt
about that.
The problem that I describe is when I have a nbma network, classical
serial physical interface with a bunch of fr pvc's to the spoke routers,
AND 'ip pim nbma-mode' is NOT enable.
Under this circumstance the doc describes very well what should happen:
<snip>
The following example illustrates a specific issue regarding IP
multicast deployment within the partial mesh design of Frame Relay
networks. If a remote site router sends a Protocol Independent Multicast
(PIM) prune message, only the central site router will receive the prune
message (see Figure 3). Consequently, other remote site routers cannot
override this prune message. This situation could prevent members of
multicast groups from receiving multicast traffic that they want.
<snip>
Well in reality, as you can see in the first postings of this thread,
this doesn't happen: one spoke sends a prune and another spoke CAN hear
it and thus overrides it!!!!!
I think that the only possible way a spoke can receive a multicast
packet from another spoke is if it is replicated by the hub.
But I can't find anywhere in the Cisco doc, that a hub replicates pim
prune messages from one spoke to another.
Thanks,
Luca.
On Thu, 2007-03-29 at 15:08 -0400, Brian Hescock (bhescock) wrote:
> Luca,
> Hi, pim nbma-mode is for sparse mode, as indicated in the
referenced
> document further down in this thread.
>
> <snip>
> When using the ip pim nbma-mode command, note the following usage
> guidelines:
>
> This command applies to only PIM sparse mode configurations because
its
> functionality is dependent on the PIM sparse mode join message.
> <snip>
>
> With nbma-mode the router tracks each remote router on the multipoint
> interface by ip address just as if they were on a separate
> subinterfaces. You can prune from a given remote router and have no
> impact on other remote routers off that same multipoint interface.
> There is no need for a prune override per se in that circumstance,
> although if you happen to see one in debugs it may be the IOS way of
> overcoming it using nbma-mode.
>
> I would suggest using the feedback mechanism in the left frame of the
> web page if the documentation isn't clear. I've used it many times
over
> the years and have received a response each time.
>
> Regards,
>
> Brian
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Bit Gossip
> Sent: Wednesday, March 28, 2007 12:38 PM
> To: 'ccielab'
> Subject: Re: multicast very fundamental
>
> Antonio,
> the document that you mention was also my orginal understanding; in
> reality
> though, things seem to work differently.
> I don't know how much one can rely on this undocumented feature. Would
> be
> nice to have a comment from Cisco on this, as it is rather fundamental
> .....
> One approach could be: 'do as if this feature didn't exist'
>
> Let's hope that someone from Cisco pick this up...
> Luca.
>
> ----- Original Message -----
> From: "Antonio Soares" <amsoares@netcabo.pt>
> To: "'Bob Sinclair'" <bob@bobsinclair.net>; "'Bit Gossip'"
> <bit.gossip@chello.nl>
> Cc: "'ccielab'" <ccielab@groupstudy.com>
> Sent: Wednesday, March 28, 2007 5:28 PM
> Subject: RE: multicast very fundamental
>
>
> Hello,
>
> Very interesting discussion.
>
> So may we assume that the Prune Override mechanism works the same way
in
> NBMA as in Broadcast Networks? And that the "ip pim nbma-mode" is only
> an
> optimization feature available with PIM-SM ?
>
> If this is true, at least the document bellow should be updated (see
> figure
> 3):
>
>
http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a0080
> 0d6b
> 61.shtml#xtocid3
>
>
>
> Thanks,
> Antonio
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Bob
> Sinclair
> Sent: terga-feira, 27 de Margo de 2007 21:25
> To: Bit Gossip
> Cc: ccielab
> Subject: Re: multicast very fundamental
>
> Bit Gossip wrote:
> > Happy to hear that I am not the only one to experience this 'behind
> > the curtains' prune override.
> > As a consequence of this behaviour, the only real benifit of 'ip pim
> > nbma-mode' is:
> > - efficiency in sending the group to only PVCs that really want it
> > - performance in that in can be performed in CEF mode instead of
> > process switch
> >
> I would add two additional benefits of nbma-mode: it permits
> spoke-to-spoke
> multicast, and permits a BSR to be on a spoke.
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART