Re: Ping fails across VRF

I would go on to say this type of problem (imho) is very likely to be
one of the things that might crop up in the new lab format - possibly
in the troubleshooting section.

Just my $0.02 worth.

On Sun, Aug 30, 2009 at 12:36 AM, Rick Mur<rmur_at_ipexpert.com> wrote:
> Yes you have a problem if the Loopback has a /24 mask and you advertise the
> /32 in OSPF (like it does by default). That way the router that has the
> loopback on it, would advertise a label for the /24 prefix and the upstream
> router wouldn't know what to do as it only knows a /32 route.
> You solved it by making the interfaces being advertised as /24. Another
> option would be making all loopbacks /32.
>
>
> --
> Regards,
>
> Rick Mur
> CCIE2 #21946 (R&S / Service Provider)
> Sr. Support Engineer IPexpert, Inc.
> URL: http://www.IPexpert.com
>
>
> On Sun, Aug 30, 2009 at 1:27 AM, Christopher Copley
> <copley.chris_at_gmail.com>wrote:
>
>> All,
>>
>> I finally figured it out. It appears to be an issue with the Provider
>> Backbone in the IGP process. I am running ospf on the Provider core, and
>> ospf was the cause of the issue. The /32 route by default on a Loopback
>> interface was the cause. The /24 route of the loopback had IMP-NULL, but
>> the /32 did not. I went to the Lo0 of R3 & R6 and made it a p2p interface,
>> and it corrected the issue.
>>
>> Sorry for the long thread, I guess I had to write out the process for my
>> head to process.
>>
>> Thanks,
>>
>> Chris
>>
>> On Sat, Aug 29, 2009 at 3:43 PM, Christopher Copley
>> <copley.chris_at_gmail.com>wrote:
>>
>> > Bryan,
>> >
>> > I tried to remove the Lo0 from IGP and that did not work. R1/R3 and
>> R5/R6
>> > are LDP peers. I have the MP-BGP peering on R3 and R6 via Lo0. And if I
>> > can not get the Lo0 to be a tagged packet then I think I have an IOS bug
>> or
>> > limitation. would this be correct.
>> >
>> > Chris
>> >
>> >
>> > On Sat, Aug 29, 2009 at 3:34 PM, Bryan Bartik <bbartik_at_ipexpert.com
>> >wrote:
>> >
>> >> Chris,
>> >>
>> >> You are right, you should see "pop" for PHP. If you see untagged this is
>> >> because you have not received a label for it. This is why I said check
>> your
>> >> peerings and make sure CEF is enabled. In some older codes, CEF is not
>> on by
>> >> default. Are R1/R3 and R5/R6 LDP Peers?
>> >>
>> >>
>> >> On Sat, Aug 29, 2009 at 4:17 PM, Christopher Copley <
>> >> copley.chris_at_gmail.com> wrote:
>> >>
>> >>> Bryan,
>> >>>
>> >>> This in my Topo...
>> >>>
>> >>> CE---R3---R1----R5----R6----CE
>> >>>
>> >>> If I look on R1 to see the ldp forwarding table I see...
>> >>>
>> >>> Rack2R1#sho mpls forwarding-table | inc (155.2.6.6/32|155.2.3.3/32<
>> http://155.2.6.6/32%7C155.2.3.3/32>
>> >>> )
>> >>> 16 Untagged 155.2.3.3/32 12288 Se0/1/0 point2point
>> >>> 18 16 155.2.6.6/32 13036 Fa0/0 150.1.15.5
>> >>> Rack2R1#
>> >>>
>> >>>
>> >>> and on R5 I see...
>> >>>
>> >>> Rack2R5#sho mpls forwarding-table | inc (155.2.6.6/32|155.2.3.3/32<
>> http://155.2.6.6/32%7C155.2.3.3/32>
>> >>> )
>> >>> 16 Untagged 155.2.6.6/32 8973 Fa0/1 150.1.56.6
>> >>> 18 16 155.2.3.3/32 16955 Fa0/0 150.1.15.1
>> >>> Rack2R5#
>> >>>
>> >>> If what I have been reading is correct, then R1 and R5 are sending the
>> >>> mpls lable as a ipv4 packet to R3 &R6 respectively.
>> >>> I have my MP-BGP peerings between R3&R6 via the Lo0 interface.
>> >>> I believe that instead of Untagged in the above output I should be
>> seeing
>> >>> "Pop Label" that is the PHP process, right?
>> >>> Then R3 and R6 will untag the packet and direct it to the correct VRF
>> and
>> >>> an IPv4 packet, Correct?
>> >>>
>> >>> If the above logic is correct will taking the Lo0 out of my IGP correct
>> >>> this issue? Or is this some strange IOS bug?
>> >>>
>> >>> Chris
>> >>>
>> >>>
>> >>> On Sat, Aug 29, 2009 at 3:06 PM, Bryan Bartik <bbartik_at_ipexpert.com
>> >wrote:
>> >>>
>> >>>> Chris,
>> >>>>
>> >>>> You don't need to enable mpls on a loopback. Just out the loopback in
>> >>>> your IGP and labels will get advertised. What makes you think PHP is
>> >>>> happening to seen? If you see a "no-label" instead of "pop-label" in
>> the
>> >>>> LFIB, this is not PHP. Make sure you have CEF enabled and your LDP
>> peerings
>> >>>> are UP throughout the cloud. Let me know what you find.
>> >>>>
>> >>>> On Sat, Aug 29, 2009 at 3:57 PM, Christopher Copley <
>> >>>> copley.chris_at_gmail.com> wrote:
>> >>>>
>> >>>>> I think I know what is going on....The PHP process is occurring to
>> >>>>> soon, by
>> >>>>> one router. I tried to enable mpls ip on the Lo0 interface and get
>> an
>> >>>>> error...
>> >>>>>
>> >>>>> % MPLS not supported on interface Loopback0
>> >>>>>
>> >>>>> Is this an IOS version limitation or a default behavior?
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Chris
>> >>>>>
>> >>>>> On Sat, Aug 29, 2009 at 2:33 PM, Christopher Copley
>> >>>>> <copley.chris_at_gmail.com>wrote:
>> >>>>>
>> >>>>> > Sorry all pressed send by mistake WAY to early,
>> >>>>> >
>> >>>>> > Anyway...
>> >>>>> >
>> >>>>> > I have one VPN and at each of the CE routers I can see the routes
>> >>>>> from each
>> >>>>> > other across my MPLS backbone. But ping fails across the Core
>> from
>> >>>>> CE to
>> >>>>> > CE, but the routes are there and look correct.
>> >>>>> >
>> >>>>> > I have MP-BPG between each PE and the router appear in each VPN.
>> >>>>> >
>> >>>>> > Any ideas?
>> >>>>> >
>> >>>>> > Chris
>> >>>>> >
>> >>>>> >
>> >>>>> > On Sat, Aug 29, 2009 at 2:29 PM, Christopher Copley <
>> >>>>> > copley.chris_at_gmail.com> wrote:
>> >>>>> >
>> >>>>> >> Experts,
>> >>>>> >>
>> >>>>> >> I have an interesting problem with my MPLS study. I am new to
>> MPLS
>> >>>>> and
>> >>>>> >> MPLS VPNS and I have got to a place where I am stuck.
>> >>>>>
>> >>>>>
>> >>>>> Blogs and organic groups at http://www.ccie.net
>> >>>>>
>> >>>>>
>> _______________________________________________________________________
>> >>>>> Subscription information may be found at:
>> >>>>> http://www.groupstudy.com/list/CCIELab.html
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>>
>> >>>> --
>> >>>> Bryan Bartik
>> >>>> CCIE #23707 (R&S), CCNP
>> >>>> Sr. Support Engineer - IPexpert, Inc.
>> >>>> URL: http://www.IPexpert.com
>> >>>>
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> Bryan Bartik
>> >> CCIE #23707 (R&S), CCNP
>> >> Sr. Support Engineer - IPexpert, Inc.
>> >> URL: http://www.IPexpert.com
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Aug 30 2009 - 10:25:48 ART