From: Alvarez, Rolando [NCSUS] (RAlvare5@NCSUS.JNJ.COM)
Date: Wed Oct 08 2003 - 13:35:50 GMT-3
Thanks Brian. So the GRE solution would be the only one, if we couldn't
change to a point-to-point sub interface. This clears some things up.
Thanks again.
-----Original Message-----
From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
Sent: Wednesday, October 08, 2003 11:25 AM
To: 'Alvarez, Rolando [NCSUS]'; 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)';
ccielab@groupstudy.com
Subject: RE: Multicast in NBMA
Rolando,
Yes you can use NBMA mode with sparse-dense mode, but it would
only apply to groups that are in sparse mode. NBMA mode uses the
explicit join nature of sparse-mode to keep track of neighbors on a
non-broadcast segment.
Your assumption about auto-RP is also correct. Since auto-RP
uses multicast (224.0.1.39 and 224.0.1.40) to create group to RP
mappings, placement of the candidate RPs and the mapping agent must be
in a manner that every router in the PIM can gain multicast reachability
to them.
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
> Alvarez, Rolando [NCSUS]
> Sent: Wednesday, October 08, 2003 10:08 AM
> To: 'Brian McGahan'; 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)'; Alvarez,
> Rolando [NCSUS]; ccielab@groupstudy.com
> Subject: RE: Multicast in NBMA
>
> Brian,
>
> Staying with the same topic, then this would also hold true if you are
> using
> auto-rp, and the MA happens to be router 4. This would prevent the
other
> spokes from getting the 224.0.1.40 traffic? If so, then how would you
get
> around this? GRE tunnel?
>
> Thanks,
> Rolando
>
> -----Original Message-----
> From: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Sent: Wednesday, October 08, 2003 10:59 AM
> To: 'SANCHEZ-MONGE,ANTONIO (HP-France,ex2)'; 'Alvarez, Rolando
[NCSUS]';
> ccielab@groupstudy.com
> Subject: RE: Multicast in NBMA
>
>
> 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