Re: Is there a methodical way to check full reachability?

That's why I responded, you sounded like nowhere in the P cloud you
would have labels, but you will have everywhere but in the previous
to last P (PE).

The IGP route will be a /32 and LDP from all places BUT the originating
one will also be /32. It's only in the originating router that the
connected route is /24.
In the PE-PE traffic, it is mpls framed from the source, not IP.

As to the last comment, P2 just drops the frame because the topmost
label is marked as untagged in the LIB, and vpn frames have the vpn
label still there. I guess that's the difference between "Untagged"
and "POP" in the LIB.

-Carlos

Joe Astorino @ 22/01/2010 20:02 -0300 dixit:
> One more thing -- If the first scenario indeed is happening (PE1 does
> not have the label for PE2, but sends the frame anyways with JUST the
> VPN label) then yes, it is the same thing as the PHP happening early :
> ) Nice.
>
> On Fri, Jan 22, 2010 at 5:56 PM, Joe Astorino <jastorino_at_ipexpert.com> wrote:
>> Hmmmmmm....I'd have to lab it up again but I would expect something a
>> bit different. I would expect that PE1 would NOT have the label to
>> PE2's loopback at all for the same reason -- It's IGP is telling him
>> it is a /32 and LDP from P1 in this case is telling him it is a /24.
>> What I would expect to happen is that CE1 sends traffic destined for
>> CE2 and when it hits PE1, PE1 will not have a label for the BGP
>> next-hop of PE2 and thus can not correctly push 2 labels on to the
>> MPLS stack (inside label for the VPN, outside label for the next-hop).
>>
>> I would however expect that IP traffic would work between PE1 and PE2
>> because as you said if there are no labels it will fallback to IP
>> routing -- and the P routers are also running OSPF and will have
>> routes in the global routing table. The thing that needs
>> clarification is this -- At PE1 does it just NOT send the frame at all
>> because it has no label for the next-hop PE OR does it send the frame,
>> but only with the inner VPN label, which would cause issues when the P
>> router receives the frame (the P router would have no idea what to do
>> with a VPN label)
>>
>> On Fri, Jan 22, 2010 at 5:18 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>>> Joe,
>>> can we go into detail about this ?
>>>
>>>> The issue with the /24 loopbacks is that you will actually not have a
>>>> label for the LER in the MPLS cloud.
>>> And by cloud I guess you mean all P routers ?
>>>
>>> The actual problem happens at the router that is just before the exit P.
>>> If you have CE1 - PE1 - P1 - P2 - PE2 - CE2, the blackhole of traffic
>>> from CE1 to CE2 is seen at P2.
>>> That is because, as you said, PE2 has the /24 in the RIB and it's
>>> sending via LDP a label for it, but P2 has the /32 in its RIB and so
>>> there is no match. P1 will have the /32 and a valid label though, as PE1.
>>>
>>> Interestingly, IP traffic from PE1 to PE2 will work! being mpls framed
>>> from PE1 to P2, and will be IP forwarded to PE2. The "Untagged" tag
>>> in P2's LIB is the "culprit"...
>>>
>>> It behaves just like as if you were doing PHP one hop early, thus my
>>> comment.
>>>
>>> -Carlos
>>>
>>>
>>>
>>>
>>> Joe Astorino @ 22/01/2010 16:22 -0300 dixit:
>>>> The issue with the /24 loopbacks is that you will actually not have a
>>>> label for the LER in the MPLS cloud. What will happen is that by
>>>> default OSPF will advertise that /24 loopback as a /32. LDP on the
>>>> other hand will advertise the /24. Since your LFIB is based in part
>>>> by your existing routing table, and the label you received does not
>>>> match the prefix in your RIB (/24 vs /32) the label will never be
>>>> installed.
>>>>
>>>> On Fri, Jan 22, 2010 at 1:58 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>>>>> The PHP will occur one hop early.
>>>>> That's why I asked if MPLS is present in R&S lab :)
>>>>>
>>>>> Divin Mathew John @ 22/01/2010 15:49 -0300 dixit:
>>>>>> Wht will happen?
>>>>>>
>>>>>> On Sat, Jan 23, 2010 at 12:17 AM, Joe Astorino <jastorino_at_ipexpert.com
>>>>>> <mailto:jastorino_at_ipexpert.com>> wrote:
>>>>>>
>>>>>> Indeed....using MPLS and having a broken LSP somewhere in the middle
>>>>>> can result in having routes but no reachability : ) Try running MPLS
>>>>>> L3 VPN with OSPF over frame-relay in your SP "core" and make your PE
>>>>>> loopbacks /24s and see what happens : )
>>>>>>
>>>>>> On Fri, Jan 22, 2010 at 1:18 PM, Divin Mathew John
>>>>>> <divinjohn_at_gmail.com <mailto:divinjohn_at_gmail.com>> wrote:
>>>>>> > R1--- r2--- R3
>>>>>> > R1 thinks R2 is next hop for R3 Lo0. and R2 Thinks R1 is next hop
>>>>>> for R3'
>>>>>> > Lo0
>>>>>> >
>>>>>> >
>>>>>> > On Fri, Jan 22, 2010 at 10:27 PM, Carlos G Mendioroz
>>>>>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>>>>>> > wrote:
>>>>>> >>
>>>>>> >> Would you please show a simple example where you have routes and
>>>>>> >> not reachability ? Obviously without ACLs blocking traffic.
>>>>>> >>
>>>>>> >> -Carlos
>>>>>> >>
>>>>>> >> Marko Milivojevic @ 22/01/2010 8:54 -0300 dixit:
>>>>>> >> > On Thu, Jan 21, 2010 at 23:51, Carlos G Mendioroz
>>>>>> <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>>>>>> >> > wrote:
>>>>>> >> >> Or you can use the thoughtfull (sp?) way of verifying that all
>>>>>> your
>>>>>> >> >> networks have indeed routes in all your routers, and that you have
>>>>>> >> >> no routing (change) activity (i.e. debug routing).
>>>>>> >> >
>>>>>> >> > Having routes in the routing table does not mean reachability :-).
>>>>>> >> >
>>>>>> >> > Having pings working, doesn't mean full routing convergence :-).
>>>>>> >> >
>>>>>> >> > --
>>>>>> >> > Marko Milivojevic - CCIE #18427
>>>>>> >> > Senior Technical Instructor - IPexpert
>>>>>> >> >
>>>>>> >> > Mailto: markom_at_ipexpert.com <mailto:markom_at_ipexpert.com>
>>>>>> >> > Telephone: +1.810.326.1444
>>>>>> >> > Fax: +1.810.454.0130
>>>>>> >> > Community: http://www.ipexpert.com/communities
>>>>>> >>
>>>>>> >> --
>>>>>> >> Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
>>>>>> LW7 EQI Argentina
>>>>>> >>
>>>>>> >>
>>>>>> >> Blogs and organic groups at http://www.ccie.net
>>>>>> >>
>>>>>> >>
>>>>>> _______________________________________________________________________
>>>>>> >> Subscription information may be found at:
>>>>>> >> http://www.groupstudy.com/list/CCIELab.html
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> >
>>>>>> > Sent from Bengaluru, Karnataka, India
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>> Joe Astorino CCIE #24347 (R&S)
>>>>>> Sr. Technical Instructor - IPexpert
>>>>>> Mailto: jastorino_at_ipexpert.com <mailto:jastorino_at_ipexpert.com>
>>>>>> Telephone: +1.810.326.1444
>>>>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>>>>> <http://www.ipexpert.com/chat>
>>>>>> eFax: +1.810.454.0130
>>>>>>
>>>>>> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
>>>>>> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice,
>>>>>> Security & Service Provider) Certification Training with locations
>>>>>> throughout the United States, Europe and Australia. Be sure to check
>>>>>> out our online communities at www.ipexpert.com/communities
>>>>>> <http://www.ipexpert.com/communities> and our
>>>>>> public website at www.ipexpert.com <http://www.ipexpert.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> Sent from Bengaluru, Karnataka, India
>>>>> --
>>>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>>>
>>>>
>>>>
>>> --
>>> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>>>
>>
>>
>> --
>> Regards,
>>
>> Joe Astorino CCIE #24347 (R&S)
>> Sr. Technical Instructor - IPexpert
>> Mailto: jastorino_at_ipexpert.com
>> Telephone: +1.810.326.1444
>> Live Assistance, Please visit: www.ipexpert.com/chat
>> eFax: +1.810.454.0130
>>
>> IPexpert is a premier provider of Classroom and Self-Study Cisco CCNA
>> (R&S, Voice & Security), CCNP, CCVP, CCSP and CCIE (R&S, Voice,
>> Security & Service Provider) Certification Training with locations
>> throughout the United States, Europe and Australia. Be sure to check
>> out our online communities at www.ipexpert.com/communities and our
>> public website at www.ipexpert.com
>>
>
>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net