From: Daniel Valle (danielfrvalle@gmail.com)
Date: Sun Mar 30 2008 - 11:31:55 ART
Hi Bob, Thank you again to keep helping me. The mroute didn't work and still
the same irrue... 3 pings... then stops... the problem we identified. It's
in the Prune behavior. But with P2M it does not occur....
On Sun, Mar 30, 2008 at 10:35 AM, Bob Sinclair <bob@bobsinclair.net> wrote:
> 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