Hi Navin
Interesting reply, I just noticed that I unicasted below to Gaurav now
including for benefit of members.
To me it suggests the router-alert label 1 at the RP level holds some sort of
state in RAM to ensure the return path is synchronous, it would be would be
good to understand this better.
-- BR Tony Sent from my iPad > On 26 Dec 2014, at 20:56, Tony Singh <mothafungla_at_gmail.com> wrote: > > > > There's not many technical details in the RFC that defines how MPLS OAM technically handles the alert 1 label apart from suggesting we regain bi-directional control of the ping or trace, further up in the stack were using UDP and port numbers that IOS at a process switching level (RP) would understand. > > Where the path takes an invalid MPLS path is suggesting an incorrect label mapping (assuming static) > > Those slides are basically saying the same thing, I.e the return non default option (reply mode router-alert) is bi directional whilst adding an IPP in the ToS byte of 6 - this is suggesting some sort of state level information is stored in RAM. > > > > >> On 26 Dec 2014, at 15:30, GAURAV MADAN <gauravmadan1177_at_gmail.com> wrote: >> >> Thanks for the reply . >> In fact I have referred this doc before writing the email to group. >> 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 ? >> >> >> >>> On 26 December 2014 at 20:52, Tony Singh <mothafungla_at_gmail.com> wrote: >>> >>> >>> where this would be used is "if" >>> >>> ping mpls ipv4 44.44.44.44 255.255.255.255 [default "reply mode ipv4"] >>> >>> initiator does not received a reply >>> >>> then >>> >>> ping mpls ipv4 44.44.44.44 255.255.255.255 reply mode router-alert >>> >>> sets the IPP to 6 and is process switched by the RP on every hop, described as a more expensive option due to the CPU requests but s recommended action to be used in case Option 1 fails. >>> >>> >>> Reply Mode Options for a Responding Router: >>> >>> Option >>> Description >>> ipv4 >>> >>> Reply with an IPv4 UDP packet (default). This is the most common reply mode selected for use with an MPLS LSP Ping/Traceroute command when you want to periodically poll the integrity of an LSP. >>> >>> With this option, you do not have explicit control over whether the packet traverses IP or MPLS hops to reach the originator of the MPLS echo request. >>> >>> If the headend router fails to receive a reply, select the router-alert option, "Reply with an IPv4 UDP packet with a router alert." >>> >>> The responding router sets the IP precedence of the reply packet to 6. >>> >>> You implement this option using the reply mode ipv4 keywords. >>> >>> router-alert >>> >>> Reply with an IPv4 UDP packet with a router alert. This reply mode adds the router alert option to the IP header. This forces the packet to be special handled by the Cisco router at each intermediate hop as it moves back to the destination. >>> >>> This reply mode is more expensive, so use the router-alert option only if you are unable to get a reply with the ipv4 option, "Reply with an IPv4 UDP packet." >>> >>> You implement this option using the reply mode router-alert keywords >>> >>> >>> >>> Packet Handling Along Return Path with an IP/MPLS Router Alert: >>> >>> Incoming Packet >>> Normal Switching Action >>> Process Switching Action >>> Outgoing Packet >>> IP packetbRouter alert option in IP header >>> >>> Router alert option in IP header causes the packet to be punted to the process switching path. >>> >>> Forwards the packet as is >>> >>> IP packetbRouter alert option in IP header >>> >>> Router alert option in IP header causes the packet to be punted to the process switching path. >>> >>> Adds a router alert as the outermost label and forwards as an MPLS packet >>> >>> MPLS packetb Outermost label contains a router alert >>> >>> MPLS packetb Outermost label contains a router alert >>> >>> If the router alert label is the outermost label, it causes the packet to be punted to the process switching path. >>> >>> Removes the outermost router alert label, adds an IP router alert option to the IP header, and forwards as an IP packet >>> >>> IP packetbRouter alert option in IP header >>> >>> If the router alert label is the outermost label, it causes the packet to be punted to the process switching path. >>> >>> Preserves the outermost router alert label and forwards the MPLS packet >>> >>> MPLS packetb Outermost label contains a router alert >>> >>> >>> >>> >>> >>> Regards point 3 as the LSP as you say is unidirectional reply cannot be guaranteed to take a certain path, initiating a MPLS trace at both head-ends would verify the recorded path against what you would or would not expect. >>> >>> There's a good high-level document with some good diagrams that i'd recommend a browse, it includes L2VPN VCCV information worth reading: >>> >>> https://www.nanog.org/meetings/nanog33/presentations/moizuddin.pdf >>> >>> >>> HTH >>> >>> -- >>> BR >>> >>> Tony >>> >>> >>> >>>> On 26 December 2014 at 09:39, 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.netReceived on Mon Dec 29 2014 - 22:10:04 ART
This archive was generated by hypermail 2.2.0 : Thu Jan 01 2015 - 10:14:36 ART