- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: multicast very fundamental posted 03/29/2007
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

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:

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.

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.

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@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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@xxxxxxxxxx>
> To: "'Bob Sinclair'" <bob@xxxxxxxxxxxxxxx>; "'Bit Gossip'"
> <bit.gossip@xxxxxxxxx>
> Cc: "'ccielab'" <ccielab@xxxxxxxxxxxxxx>
> 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):
> 0d6b
> 61.shtml#xtocid3
> Thanks,
> Antonio
> -----Original Message-----
> From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] 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.