From: Daniel Valle (danielfrvalle@gmail.com)
Date: Sun Mar 30 2008 - 14:29:48 ART
I'll try that! anyway, what Bob suggested is to set a ip mroute, not an ip
route ( as you said, static ip routes are usually not allowed in the lab).
I'll try both again and I'll let you guys know...
On Sun, Mar 30, 2008 at 2:06 PM, Alexis Dacquay <alexis.dacquay@gmail.com>
wrote:
> Hi,
> I've got the same problems running with 12.4(13b); using either ospf
> non_broadcast or eigrp.
> I tried the ip mroute without success.
> I also tried BSR; it had the same effect.
> "ip pim spt-threshold infinity" doesn't seems taking effect on the spoke,
> it
> still sends a Prune to the RP.
>
> Upon Bob's suggestion, I tried to override the unicast routing table; I
> wanted to force the spoke to understand that the next hop is not directly
> connected. In your case:
> ip route 1.1.123.1 255.255.255.255 1.1.123.2
>
> It works.
>
> Thanks Bob for the explanations! I've been working on that problem for a
> while.
> Now you need to prove to the proctor that you need the static route (or a
> tunnel)... another story.
>
> Regards,
> Alexis
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Daniel Valle
> Sent: 30 March 2008 15:32
> To: Bob Sinclair
> Cc: groupstudy
> Subject: Re: Multicast and NBMA again...
>
> 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
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART