From: Timothy Snow (timsnow@cogeco.ca)
Date: Wed Jun 18 2003 - 09:12:00 GMT-3
Found a couple of interesting things. First off, in the example below, I can
ping the 224.1.1.1 mcast address from r5 and it works. Yet r5's config
appears to be okay.
I was able to solve the problem via a tunnel interface with a static mroute
between the r4 and r6 interfaces (see below) but was there any other way to
fix this or is that just the rule that an incoming interface cannot be the
same as an outgoing interface, regarding of an pim nbma or likewise.
r6#sh ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
(*, 224.1.1.1), 00:04:51/00:03:28, 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/Sparse, 00:04:01/00:00:00
(10.1.1.2, 224.1.1.1), 00:04:51/00:03:28, flags: TA
Incoming interface: Serial0.654, RPF nbr 172.16.0.5
Outgoing interface list:
Tunnel0, Forward/Sparse, 00:04:51/00:03:28
> ------------------------------------------------------------------------
>
> Subject: Sparse-Mode help - Turnaround Router.
> Date: Wed, 18 Jun 2003 07:41:11 -0400
> From: Timothy Snow <timsnow@cogeco.ca>
> To: ccielab@groupstudy.com, timothy.snow@eds.com
>
> 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
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:00 GMT-3