From: Sila Moni (silamoni@yahoo.com)
Date: Thu Jun 30 2005 - 22:39:56 GMT-3
When source and receiver are on the spoke in
dense-mode, you use tunnel just like you have it here.
The other option to help avoid excess multicast
flooding and pruning is by implimenting multicast
stub.
R5:
interface Serial0
ip pim neighbor-filter 1
!
access-list 1 deny <ip@_of_R3>
access-list 1 permit any
R3:
interface Ethernet0
ip pim dense-mode
ip igmp helper-address <ip@_of_r5>
If this is a sparse mode, we would use nbma-mode just
like Chis had suggest or we would autorp listener. I
hope that I don't get carry away with this.
--- gladston@br.ibm.com wrote:
> Thanks for the reply Chris,
>
> No, not in this case.
>
> It would help to avoid R5 prune R2 or R3 if the
> source was connected
> behind R5 and the receivers were behind R2 and R3.
> Even in this case IOS would complain because it is
> dense-mode.
>
> Cordially,
>
------------------------------------------------------------------
> Gladston
>
>
>
>
> "Chris Lewis \(chrlewis\)" <chrlewis@cisco.com>
> 30/06/2005 18:36
>
> To
> Alaerte Gladston Vidali/Brazil/IBM@IBMBR,
> <ccielab@groupstudy.com>
> cc
>
> Subject
> RE: Multicast
>
>
>
>
>
>
> Does ip pim nbma-mode help?
>
> -----Original Message-----
> From: nobody@groupstudy.com
> [mailto:nobody@groupstudy.com] On Behalf Of
> gladston@br.ibm.com
> Sent: Thursday, June 30, 2005 4:22 PM
> To: ccielab@groupstudy.com
> Subject: Multicast
>
> source-------R2--tunnel---R3-------receiverA
> \ /
> \ /
> \ /
> \ /
> R5
> \
> \
> receiverB
>
> R5 is the hub, connected via serial 0 to R2 and R3.
> Tunnel between R2 and R3 solves the problem of R3
> receiving multicast
> from source (it would not receive via R5) When a
> receiver joines R5, it
> send a join via s0. R2 and R3 receives it. R5 can
> not prune one of the
> routers (R3 or R2), because it is a common serial
> (s0), and both routers
> would receive the prune.
> So, R5 receives duplicate packets.
>
> Would you have a solution for duplicate packets on
> R5?
>
> For me it seems to be a limitation and it would be
> required a topology
> change.
>
>
> Rack2R2#sh ip mroute 239.2.2.2
>
> (148.5.46.1, 239.2.2.2), 00:11:53/00:02:56, flags: T
> Incoming interface: Ethernet0/0, RPF nbr 148.5.26.6,
> Mroute
> Outgoing interface list:
> Tunnel23, Forward/Sparse-Dense, 00:10:06/00:00:00
> Serial0/0.235, Forward/Sparse-Dense,
> 00:07:39/00:00:00
>
>
> Rack2R3#sh ip mroute 239.2.2.2
>
> (148.5.46.1, 239.2.2.2), 00:09:36/00:02:50, flags: T
> Incoming interface: Tunnel23, RPF nbr 148.5.2.1,
> Mroute
> Outgoing interface list:
> Ethernet0/0, Forward/Sparse-Dense, 00:09:37/00:00:00
> Serial1/0.235, Forward/Sparse-Dense,
> 00:09:37/00:00:00
>
>
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:46 GMT-3