From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Oct 08 2003 - 11:58:59 GMT-3
Antonio,
It depends what you are asking here. In your original post you
said that "When the multicast sender is r4, only r2 replies, whereas if
it is r2
the sender, r3 replies too." You are most likely confusing the term
'sender' with 'RP'. In all practicality, the source of a multicast feed
and the RP are not related. Regardless of the placement of your RP in
this case, multicast traffic cannot be forwarded between the spokes of a
hub and spoke NBMA network.
If you are doing this configuration in a home lab, set up two
hosts, one that will generate multicast traffic and one that will
receive traffic, and see how it works.
HTH
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987
Direct: 708-362-1418 (Outside the US and Canada)
> -----Original Message-----
> From: SANCHEZ-MONGE,ANTONIO (HP-France,ex2) [mailto:antonio.sanchez-
> monge@hp.com]
> Sent: Wednesday, October 08, 2003 2:18 AM
> To: 'Brian McGahan'; 'Alvarez, Rolando [NCSUS]';
'ccielab@groupstudy.com'
> Subject: RE: Multicast in NBMA
>
> Thanks a lot Brian for detailed answer. The workaround proposed by
Rolando
> (setting r2 as RP) works as well (disregarding pim nbma-mode on or
off).
> Maybe RPF rules are applied in a slightly different way by the RP than
> non-RP routers (I don't know).
>
> Cheers,
> Antonio.
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: miircoles, 08 de octubre de 2003 4:02
> To: 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)'; 'Alvarez, Rolando
[NCSUS]';
> ccielab@groupstudy.com
> Subject: RE: Multicast in NBMA
>
>
> This does not relate to PIM running in NBMA mode. PIM NBMA mode
is
> used to cut down on the amount of replicated unicast traffic sent over
a
> non-broadcast circuit, and to avoid mistakenly removing a group from a
> multipoint non-broadcast interface when an explicit leave message is
> received, and there are still clients who want to receive traffic for
said
> group.
>
> The problem you are seeing is due to the fact that your outgoing
> interface and your incoming interface cannot be the same. This
principle
> is
> similar to how IP split-horizon works for distance vector routing
> protocols.
> A router will not forward a multicast packet out the same interface it
is
> received in.
>
> The workaround in this case would be to run point-to-point IP
> subnets, or to tunnel the multicast traffic from R3 to R4 through a
GRE
> tunnel.
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987
> Direct: 708-362-1418 (Outside the US and Canada)
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > SANCHEZ-MONGE,ANTONIO (HP-France,ex2)
> > Sent: Tuesday, October 07, 2003 11:29 AM
> > To: 'Alvarez, Rolando [NCSUS]'; 'ccielab@groupstudy.com'
> > Subject: RE: Multicast in NBMA
> >
> > Hi Rolando, Ozgur,
> >
> > That's it, using sparse mode and setting r2 as RP fixes the issue.
> >
> > Thanks a lot to ALL.
> >
> > Cheers,
> > Antonio.
> >
> > -----Original Message-----
> > From: Alvarez, Rolando [NCSUS] [mailto:RAlvare5@NCSUS.JNJ.COM]
> > Sent: martes, 07 de octubre de 2003 17:55
> > To: 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)'
> > Subject: RE: Multicast in NBMA
> >
> >
> >
> > Antonio,
> >
> > I am not a multicast expert by any means, but I will try to give you
> my
> > opinion. For this topology, I would try using Auto-RP so that the
> > multicast runs on sparse-mode. I think that you may be running into
> > the Reverse Path
> > Forwarding that dense-mode uses. Since the packet came in on
s0/0.30,
> it
> > will not forward that packet out that same interface. Try making r2
> the
> > rp
> > and ma for this group, and your issue may be resolved. Let me know
if
> > that helps.
> >
> > Thanks,
> > Rolando
> > -----Original Message-----
> > From: SANCHEZ-MONGE,ANTONIO (HP-France,ex2)
> > [mailto:antonio.sanchez-monge@hp.com
> <mailto:antonio.sanchez-monge@hp.com>
> > ]
> >
> > Sent: Tuesday, October 07, 2003 8:32 AM
> > To: 'ccielab@groupstudy.com'
> > Subject: Multicast in NBMA
> >
> >
> > Hi All,
> >
> > Nice to meet you. I am beginning to prepare CCIE lab.
> >
> > Could you please help me with this problem?
> >
> > My topology: Frame-relay multipoint
> > r2 192.168.30.2(lo0 = 192.168.2.2)
> > / / \
> > / / \
> > / / \
> > / / \
> > (r4)(r3) (r5)
> > |________|
> >
> >
> > OSPF is running everywhere, every router can ping the others'
> loopbacks.
> > Also PIM Sparse-Dense is running everywhere.
> > The frame-relay maps are all configured for broadcast.
> >
> > The Ethernet interface of r3 (192.168.20.3) and r2 loopback
> (192.168.2.2)
> > are multicast group 225.6.7.8 receivers.
> >
> > When the multicast sender is r4, only r2 replies, whereas if it is
r2
> the
> > sender, r3 replies too.
> >
> > I think this has to do with the multipoint architecture, but I
cannot
> see
> > how to get a reply from r3 r4 (or how to get r2 forwarding the
> multicast
> > packet originated by r4 to r3). Any clues?
> >
> >
> > r2#sh ip mroute
> > IP Multicast Routing Table
> > Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
> > Connected,
> >
> > L - Local, P - Pruned, R - RP-bit set, F - Register flag,
> > T - SPT-bit set, J - Join SPT, M - MSDP created entry,
> > X - Proxy Join Timer Running, A - Candidate for MSDP
> Advertisement,
> > U - URD, I - Received Source Specific Host Report Outgoing
> > interface flags: H - Hardware switched
> > Timers: Uptime/Expires
> > Interface state: Interface, Next-Hop or VCD, State/Mode
> >
> > (*, 224.0.1.40), 00:44:09/00:00:00, RP 0.0.0.0, flags: DCL
> > Incoming interface: Null, RPF nbr 0.0.0.0
> > Outgoing interface list:
> > Serial0/0.30, Forward/Sparse-Dense, 00:44:09/00:00:00
> >
> > (*, 225.6.7.8), 00:15:22/00:00:00, RP 0.0.0.0, flags: DCL
> > Incoming interface: Null, RPF nbr 0.0.0.0
> > Outgoing interface list:
> > Loopback0, Forward/Sparse-Dense, 00:07:56/00:00:00
> > Serial0/0.30, Forward/Sparse-Dense, 00:15:22/00:00:00
> >
> > (192.168.2.2, 225.6.7.8), 00:00:07/00:02:52, flags: CLT
> > Incoming interface: Loopback0, RPF nbr 0.0.0.0
> > Outgoing interface list:
> > Serial0/0.30, Forward/Sparse-Dense, 00:00:10/00:00:00
> >
> > (192.168.30.4, 225.6.7.8), 00:02:57/00:00:03, flags: CLT
> > Incoming interface: Serial0/0.30, RPF nbr 192.168.30.4
> > Outgoing interface list:
> > Loopback0, Forward/Sparse-Dense, 00:02:57/00:00:00
> >
> >
> > r2#i
> > Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B -
> BGP
> > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter
area
> > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type
2
> > E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
> > i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS
> > level-2
> >
> > ia - IS-IS inter area, * - candidate default, U - per-user
> static
> > route
> > o - ODR, P - periodic downloaded static route
> >
> > Gateway of last resort is not set
> >
> > 192.168.30.0/24 is variably subnetted, 4 subnets, 2 masks
> > O 192.168.30.4/32 [110/64] via 192.168.30.4, 00:30:40,
> Serial0/0.30
> > O 192.168.30.5/32 [110/64] via 192.168.30.5, 00:30:40,
> Serial0/0.30
> > O 192.168.30.3/32 [110/64] via 192.168.30.3, 00:30:40,
> Serial0/0.30
> > C 192.168.30.0/28 is directly connected, Serial0/0.30
> > 192.168.4.0/32 is subnetted, 1 subnets
> > O 192.168.4.4 [110/65] via 192.168.30.4, 00:30:40,
Serial0/0.30
> > 192.168.2.0/32 is subnetted, 1 subnets
> > C 192.168.2.2 is directly connected, Loopback0
> > 192.168.3.0/32 is subnetted, 1 subnets
> > O 192.168.3.3 [110/65] via 192.168.30.3, 00:30:41,
Serial0/0.30
> >
> >
> > Thanks & Cheers,
> > Antonio.
> >
> > ***Get your CCIE and a FREE vacation: Shop.GroupStudy.com***
> >
>
This archive was generated by hypermail 2.1.4 : Mon Nov 24 2003 - 07:52:59 GMT-3