From: Bob Sinclair (bob@bobsinclair.net)
Date: Sun Mar 30 2008 - 10:35:46 ART
Daniel Valle wrote:
> Hi Bob,
>
> This is exactly what's happening (I enabled PIM and mpacket debug)
>
Hi Daniel: It does look you have two sources for 224.3.3.3: 1.1.11.1
and 1.1.123.1
> Notice here that R3 is registering the traffic from 1.1.123.1. This
> is because it is on the directly attached network:
> 00:28:11: PIM(0): Received v2 Register on Serial1/0 from 1.1.123.3
> <http://1.1.123.3>
> 00:28:11: for 1.1.123.1 <http://1.1.123.1>, group 224.3.3.3
> <http://224.3.3.3>
Here R2 gets shared tree prunes from R3 for both sources:
> 00:28:12: PIM(0): Received v2 Join/Prune on Serial1/0 from 1.1.123.3
> <http://1.1.123.3>, to us
> 00:28:12: PIM(0): Prune-list: (1.1.123.1/32 <http://1.1.123.1/32>,
> 224.3.3.3 <http://224.3.3.3>) RPT-bit set
> 00:28:12: PIM(0): Prune Serial1/0/1.1.123.3 from (1.1.123.1/32
> <http://1.1.123.1/32>, 224.3.3.3 <http://224.3.3.3>) - deleted
> 00:28:12: PIM(0): Prune-list: (1.1.11.1/32 <http://1.1.11.1/32>,
> 224.3.3.3 <http://224.3.3.3>) RPT-bit set
> 00:28:12: PIM(0): Prune Serial1/0/1.1.123.3 from (1.1.11.1/32
> <http://1.1.11.1/32>, 224.3.3.3 <http://224.3.3.3>)
> 00:28:12: PIM(0): Insert (1.1.11.1 <http://1.1.11.1>,224.3.3.3
> <http://224.3.3.3>) prune in nbr 1.1.123.1 <http://1.1.123.1>'s queue
> - deleted
Then R2 sends source tree prunes for both groups to R1:
> 00:28:12: PIM(0): Building Join/Prune packet for nbr 1.1.123.1
> <http://1.1.123.1>
> 00:28:12: PIM(0): Adding v2 (1.1.11.1/32 <http://1.1.11.1/32>,
> 224.3.3.3 <http://224.3.3.3>), S-bit Prune
> 00:28:12: PIM(0): Send v2 join/prune to 1.1.123.1 <http://1.1.123.1>
> (Serial1/0)
> 00:28:13: IP(0): s=1.1.123.1 <http://1.1.123.1> (Serial1/0)
> d=224.3.3.3 <http://224.3.3.3> id=27, ttl=254, prot=1, len=104(100),
> mroute olist null
>
> Well. Is this something unfixable ? I mean, there is no way to have
> such requirement with non-broadcast network type in this Multicast
> scenario ?
>
In OSPF network types broadcast and non-broadcast R3 believe that the
shortest path to the source 1.1.123.1 on R1 is directly to R1, since it
is on the directly connected network . I suspect the source-tree join
from R3 is being ignored by R2. You may not be able to fix this. R3
sees the source as directly connected, and it may not be persuaded
otherwise.
It seems to me you should be able to fix the SPT for the source from
1.1.11.1. Could you try this static mroute on R3: ip mroute 1.1.11.1
255.255.255.255 1.1.123.2 ?
If it is working for Shine as he says, then there may be some context
issues. For example: I have seen that with the more recent 12.4 IOS on
some platforms PIM assumes that the upstream neighbor on a link must be
the PIM neighbor, overriding the routing table for the RPF check. For
example: R3 sees R1 as the upstream neighbor for the source, but since
R1 is not a PIM neighbor R3 accepts R2 as the upstream neighbor, since
it is the only PIM neighbor on the link.
I think the root of the issue is the spoke address as the source
address. See if you can fix the SPT for the 1.1.11.1 source with a
static mroute.
The time you spend getting to the root of these issues is
well-invested! If you go into the lab with a solid understanding of how
the protocols work and thorough knowledge of IOS options, then you will
not have to worry about particular scenarios bringing you down.
HTH,
-Bob
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART