From: Timothy Snow (timsnow@cogeco.ca)
Date: Wed Jun 18 2003 - 08:41:11 GMT-3
Hey all. I'm having too much fun with multicast so I thought i'd share
it. Simple spare setup here.
source----r5--------r6
/
receiver---r4-----/
There is full ip connectivity everywhere. r4/r5/r6 all reside on the
172.16.0.x/24 network but r5 and r4 don't have a direct pvc so they have
to goto r6 who is the RP for the 224.1.1.1 network I wasn't sure if
"ip pim nbma" was the issue so I put it on anyways. It appears that by
the fact that r5 is sending register's with data, and then r6 is sending
register stop's that if might be assuming the "turnaround router" role
as explained on cisco. So I see r6 sending register stops, but I also
see it sending join's to the source.
The issue I also think that's happing is based on the PIM rules that for
a (*,G) entry, the incoming interface cannot be the same as the
outgoing. Anyone know why with the following output, I'd see a "mroute
olist null ps" message?
r6#sh ip mroute
(*, 224.1.1.1), 00:04:07/00:03:09, RP 6.6.6.6, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial0.654, 172.16.0.4, Forward/, 00:03:19/00:03:09
(10.1.1.2, 224.1.1.1), 00:04:07/00:02:58, flags: TXA <----
notice the X
Incoming interface: Serial0.654, RPF nbr 172.16.0.5
Outgoing interface list:
Serial0.654, 172.16.0.4, Forward/Sparse, 00:03:20/00:02:38
r6#debug ip mpacket
IP multicast packets debugging is on
r6#
*Mar 1 03:12:46: IP: s=10.1.1.2 (Serial0.654) d=224.1.1.1 len 104,
mroute olist null
ps
r6#
r4#sh ip pim rp
Group: 224.1.1.1, RP: 6.6.6.6, uptime 00:00:10, expires never
Here's some debugs on the RP to show what it's doing...
r6#
*Mar 1 02:51:29: PIM: Send RP-reachability for 224.1.1.1 on Serial0.654
*Mar 1 02:51:29: PIM: Received v2 Register on Serial0.654 from
172.16.0.5
*Mar 1 02:51:29: (Data-header) for 10.1.1.2, group 224.1.1.1
*Mar 1 02:51:29: PIM: Send v2 Register-Stop to 172.16.0.5 for 10.1.1.2,
group 224.1.
1.1
*Mar 1 02:51:29: PIM: Received v2 Register on Serial0.654 from
172.16.0.5
*Mar 1 02:51:29: PIM: Send v2 Register-Stop to 172.16.0.5 for 0.0.0.0,
group 0.0.0.0
r6#
*Mar 1 02:51:56: PIM: Building Join/Prune message for 224.1.1.1
*Mar 1 02:51:56: PIM: For 172.16.0.5, Join-list: 10.1.1.2/32
*Mar 1 02:51:56: PIM: Send v2 periodic Join/Prune to 172.16.0.5
(Serial0.654)
*Mar 1 02:51:56: PIM: Received v2 Join/Prune on Serial0.654 from
172.16.0.4, to us
*Mar 1 02:51:56: PIM: Join-list: (*, 224.1.1.1) RP 6.6.6.6, RPT-bit
set, WC-bit set,
S-bit set
*Mar 1 02:51:56: PIM: Add Serial0.654/172.16.0.4 to (*, 224.1.1.1),
Forward state
*Mar 1 02:51:56: PIM: Add Serial0.654/172.16.0.4 to (10.1.1.2/32,
224.1.1.1)
*Mar 1 02:53:31: PIM: Received v2 Register on Serial0.654 from
172.16.0.5
*Mar 1 02:53:31: PIM: Send v2 Register-Stop to 172.16.0.5 for 0.0.0.0,
group 0.0.0.0
r6#sh ip mcache
IP Multicast Fast-Switching Cache
(*, 224.1.1.1), Null, Last used: never
(10.1.1.2/32, 224.1.1.1), Serial0.654, Last used: never
r6#sh ip rpf 172.16.4.1
RPF information for ? (172.16.4.1)
RPF interface: Serial0.654
RPF neighbor: ? (172.16.0.4)
RPF route/mask: 172.16.4.0/24
RPF type: unicast (isis)
RPF recursion count: 0
Doing distance-preferred lookups across tables
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:00 GMT-3