From: Alexis Dacquay (alexis.dacquay@gmail.com)
Date: Sun Mar 30 2008 - 17:09:20 ART
Hi,
As I said the ip mroute didn't work.
However that's the other comments Bob made regarding the PIM peering in 12.4
and a directly connected source that have intrigued me.
In the STP mode, the packets are sent from the source directly, which is on
the same link but not a PIM neighbor, thus my attempt to make the source
router not appearing as a directly connected peer in R1's unicast routing
table.
The static route works but I don't like it; I would ne happy to hear about
another solution.
Regards,
Alexis
_____
From: Daniel Valle [mailto:danielfrvalle@gmail.com]
Sent: 30 March 2008 18:30
To: Alexis Dacquay
Cc: Bob Sinclair; groupstudy
Subject: Re: Multicast and NBMA again...
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
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:54 ART