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 - 18:55:42 ART
This archive was generated by hypermail 2.2.0 : Thu Jan 01 2015 - 10:14:36 ART