From: Kirby, Ron (Ron.Kirby@xxxxxxxxxxxxx)
Date: Sat Jan 05 2002 - 11:41:34 GMT-3
Steve,
Thanks for the reply, and you're right, not many people weighed in on this
one. The MCAST source was on R3, and the traffic had to flow in R1 on one
PVC associated with s0/0.2 and then back out s0/0.2 on another PVC gping to
R4. In dense mode, this just didn't happen. I suppose the RPF check simply
removed s0/0.2 from the OIL becasue it was the upstream interface. I moved
to sparse-dense mode, and then made R1 the RP. At first traffic didn't flow
to R4, but once I added "ip pim nbma-mode" to the interface, the traffic
flowed with no problem. The mroute entry showed s0/0.2 being both the
incoming interface and the outgoing interface. I plan on moving the RP
around to various locations on the frame cloud to see the effects, maybe
later today. If you're interested, I'll keep you posted.
Thanks
Ron
-----Original Message-----
From: ciscolab@btopenworld.com
To: Kirby, Ron
Sent: 1/4/2002 3:40 PM
Subject: RE: Multicast over NBMA
Ron,
I am no mcast expert and have just had a quick look at your problem and
seen
that there are not many responses.
>From the config info the source of the mcast is attached R4 some how, is
this correct? If so why do you want the stream to flow back from R1 to
R4
again when running dense mode? If you have a client on or near R4 would
it
not have a source based tree to R4 and the attached source?
If you were running PIM SM and R1 is the RP then this may be different,
however in you scenario with the group member near the source SM may
well
build a source based tree as well.
Hope this is a bit of use, I will probably wake up in the morning and
realise that I completly missed the point of your question...
Regards
Steve
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Kirby, Ron
Sent: Friday, January 04, 2002 3:44 PM
To: ccielab@groupstudy.com
Subject: Multicast over NBMA
All,
I am working with multicasting over a frame cloud. R1 has a multipoint
subinterface connected to R3 and R4 which are using physical interfaces
(basic hub and spoke design). I am using EIGRP and have split horizon
turned
off at the hub (R1). The routing table is fine and everything can be
pinged.
Now, Pim is running on all routers and dense mode on all interfaces. I
have
pim neighbor relationships between R1 and R3 and R1 and R4. Here's the
problem. R1 (the hub) has an mroute entry for the multicast source off
of
R3 as shown below:
**********************************************
r1#sh ip mroute 234.5.6.7
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, 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
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 234.5.6.7), 00:12:31/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/0, Forward/Dense, 00:12:09/00:00:00
Serial0/0.2, Forward/Dense, 00:12:31/00:00:00
Serial0/0.1, Forward/Dense, 00:12:31/00:00:00
(192.168.30.2, 234.5.6.7), 00:02:46/00:00:24, flags: PT
Incoming interface: Serial0/0.2, RPF nbr 131.5.20.3
Outgoing interface list:
Serial0/0.1, Prune/Dense, 00:02:46/00:00:19
Ethernet0/0, Prune/Dense, 00:02:46/00:00:19
***************************************************
As you can see, S0/0.2 is not in the outgoing interface list, and I
figure
it is because the router does it's RPF check and finds that the upstream
interface is S0/0.2 and therefore S0/0.2 is not a candidate for flooding
the
multicast data. So how do I get the multicast traffic to a host on R4?
I
believe my possibilities are a tunnel between R1 and R3 and R1 and R4
for
multicast purposes, or moving to frame-relay P-to-P subinterfaces. I
have
also worked with the NBMA mode command, but it doesn't look as if it is
designed for this. Is there a command line solution available?
Thanks
Ron
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:17 GMT-3