From: Bit Gossip (bit.gossip@chello.nl)
Date: Sat Mar 31 2007 - 16:11:53 ART
Hi Brian,
I understand to to update the documentation can take time. It would be nice
though if Cisco in the meantime can confirm that the behaviour has changed
as described in this thread as from IOS 12.x.y
This will avoid a lot of misunderstanding and configuration errors.
Thanks,
Luca.
----- Original Message -----
From: "Brian Hescock (bhescock)" <bhescock@cisco.com>
To: "Bit Gossip" <bit.gossip@chello.nl>
Cc: "ccielab" <ccielab@groupstudy.com>
Sent: Thursday, March 29, 2007 10:49 PM
Subject: RE: multicast very fundamental
> 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.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 01 2007 - 06:35:53 ART