Re: Router alert label : Use case

You need to look at LSP ping Echo and Reply from both Control plane and
Data plane point of view. These two could be out of sync for any number of
reasons. When an LSP ping fails, how would you ascertain whether the
failure is in Control plane or Data plane (or) whether the failure was in
Forward path or Return path ?

You can get a Ping Success *with *RA Label and Ping Failure *without *RA
Label. This suggests that failure is in Data plane somewhere in the Path
and one should next use the Traceroute option to further isolate the fault
location. The slide 40 you referred to shows the failure in Data plane (R5
has wrong Label entry in HW LFIB). The slide 41 shows if RA Label was used
it would get correct Outgoing Interface/Next Hop/Label after getting SW
punted and hence Reply packet would get back to Ingress PE R1.

To answer your Qs:

1) Presence of RA Label helped the Reply packet get back to Ingress PE (by
using the correct Labels available in Control plane) when Data plane was
corrupted. Only the Echo requests are testing the LSP, not the Reply
packets.

2) The Return path may or may not be the same depending on how the return
path LSP is setup. For example: Return path could take e-d-*f-g*-c-b-a. The
Reply packet may not even be labelled. None of these is in Sender's
control. The Ping would be called a Success irrespective of how the Reply
packet comes back (Labelled or not). To test Return path LSP failures, try
another LSP ping from Egress PE to Ingress PE.

The RA Label comes into picture only when Reply packet is Labelled and you
see now how it helped the packet reach back the sender. If the return path
is Unlabelled, there is no RA Label either :)

On Sun, Dec 28, 2014 at 5:25 AM, GAURAV MADAN <gauravmadan1177_at_gmail.com>
wrote:

> Great reply Naveen . spot on .. and that solved *almost* all my doubts .
>
> I have referred :
>
> https://www.nanog.org/meetings/nanog33/presentations/moizuddin.pdf
>
> Slide 39 to 41 in this doc confused me a bit ..
>
> slide 40 : in return path they say r5 has wrong label binding .. hence LSP
> ping fail .. this is not true as we are doing a lsp ping from r1 to r6 and
> hence as long as this path is label switched .. we should be fine and we
> should be getting success .,
>
> slide 41 :: does the presence of router alert label in reply option
> enables router to chose the correct path ? I mean can mistake mentioned on
> slide be really undone by this option ?
>
>
> Hence that baseline question that disturbs me is that if a lsp ping goes
> from a-b-c-d-e and reply is enabled for Router Alert Label ; will this
> ensure that
> a) return path is same as e-d-c-b-a
> b) will it ensure that return path is labelled ?
>
> As per me ; if upstream path is labelled and downstream path is unlabelled
> ; still my upstream LSP ping will return me success and I dont see RA label
> doing anything there ( u can correct me here )
>
> Regards
> Gaurav Madan
>
>
> On 28 December 2014 at 15:56, Naveen <navin.ms_at_gmail.com> wrote:
>
>> Gaurav,
>>
>> One of the use cases for MPLS Router Alert Label is in VCCV type-2 pings.
>> VCCV uses a control channel to send/receive MPLS ping packets which aids in
>> Data path failure or fault isolation (OAM operations). A general case for
>> using RA Label is when Control plane is out of sync with Data plane and
>> hence User Traffic is Not delivered to end customer CE device.
>>
>> If control word is enabled and successfully negotiated during PW
>> capability exchange (aka In-band or type-1), then Router-Alert Label is not
>> used. If the control word is absent, then Router-Alert Labels are used (aka
>> Out-of-band or type-2). To answer your Qs:
>>
>> (1) What the control plane punt does on Egress PE is basically a FEC
>> validation against Label Stack and few sanity/error checks. If you are more
>> interested, check RFC 4379 section 4.4.
>>
>> (2) The Reply mode specified in CLI says to Egress PE how the Echo Reply
>> packet should be sent back. Yes, LSPs are Uni-directional; however the
>> sender can indicate in the Echo request whether 'Not to send' (or) 'Send
>> IPv4/UDP reply with/without Router-Alert'. Normal case is to send without
>> Router-Alert. The CLI you specified controls this behavior. And yes, Label
>> for traffic on return path is Not tested.
>>
>> In summary, LSP pings are diagnostic tools for basic connectivity checks.
>> If you need to isolate the fault location, use 'traceroute mpls ..' instead.
>>
>> HTH,
>> Naveen.
>>
>> PS: There is much more to this (in terms of ECMP considerations, Security
>> checks, Inter-AS cases, etc) that its almost impossible to hold in my
>> little wired-head :)
>>
>>
>> On Fri, Dec 26, 2014 at 1:39 AM, GAURAV MADAN <gauravmadan1177_at_gmail.com>
>> wrote:
>>
>>> Hi All
>>>
>>> Is there a practical use case that you guys are running for Router Alert
>>> Label ( label =1) in your network ?
>>>
>>> 1) All the theories indicate that these pkts are punted to s/w for
>>> special
>>> investigation . But not sure what investigation and what are those
>>> special
>>> cases . Can someone please give an example .
>>>
>>> 2) For LSP ping option ; LSP pings are also unidirectional .. i.e LSP
>>> ping
>>> from A to B will check the labelled path from A to B only ( and not from
>>> B
>>> to A ) . Hence i dont understand the usage of option :
>>>
>>> ping mpls ipv4 44.44.44.44 255.255.255.255 reply mode router-alert
>>>
>>> Hence as per me ; for LSP ping from A to B ; if it goes A-C-D-E-B , and I
>>> am getting a reply as success ; this does not mean that
>>> a) return traffic would have taken the B-E-D-C-A path
>>> b) It also do not for sure mean that labelled path from B to A is
>>> intact .
>>>
>>> Can some one please clarify these for me .
>>>
>>> Regards
>>> Gaurav Madan
>>>
>>>
>>> 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 Dec 28 2014 - 13:34:04 ART