IP packets can have a Router Alert option appended to the IP header. This option is an IP option indicating that the router should inspect the packet further when forwarding the packet, even though the packet is not directly addressed to that router. The transit router for the packet should not just forward the packet by doing an IP lookup, but the router should inspect it further before forwarding it. What this inspection means is not defined and is up to the software implementation on the router. The Router Alert option is an IP option like the Timestamp, Loose Source Route, and Strict Source Route options are. The Router Alert option is defined in RFC 2113.

An IP option is encoded as a Type Length Value (TLV). This Router Alert option works only if the packet is an IP packet. If the packet were labeled and as such forwarded by the LFIB on the Label Switch Router, the Label Switch Router would not even know that the packet had the Router Alert option present. Of course, you could program the Label Switch Router to perform deep packet inspection and always look at the IP header information of labeled packets to determine whether the Router Alert option were present. However, that could lead to a serious forwarding performance impact on the Label Switch Router, so it is not the best solution. It might not even be possible to do this in hardware forwarding engines, or it might be too costly. A better solution is to use a special Multiprotocol Label Switching label as the top label in the label stack of the packets that the Label Switch Routers need to examine. This special label is Multiprotocol Label Switching label 1, which is called the Router Alert label.

Router Alert Label

The Router Alert label has a value of 1, and it can be present anywhere in the label stack except at the bottom. When an Label Switch Router receives a packet with label 1 as the top label, it knows that it must further examine the packet. Therefore, the Label Switch Router removes label 1 and examines the packet. The Label Switch Router then looks at the exposed new top label in the label stack and makes a forwarding decision by looking up this label in the LFIB. This forwarding decision makes the Label Switch Router perform a swap, pop, or push operation on the label stack and returns the outgoing interface and next hop for the packet.

Before switching the packet out of the Label Switch Router, the Label Switch Router puts label 1 back as the top label in the label stack and forwards the packet. Therefore, having the Router Alert label as the top label does not influence the forwarding decision made on the packet; it solely indicates that the Label Switch Router must examine the packet. On routers that are running Cisco IOS, packets that have the Router Alert label are forwarded in software, which means the hardware forwarding engines are bypassed. The use of the Router Alert label for labeled packets is analogous to the use of the Router Alert option for IP packets. Because the Router Alert label forces the Label Switch Router to treat a labeled packet in a different manner than when the labeled packet has no Router Alert label as the top label when forwarding the packet, its use is not directly helpful for Multiprotocol Label Switching OAM.

emember that one of the requirements was for the Multiprotocol Label Switching user data traffic and the Multiprotocol Label Switching OAM traffic to be forwarded in the same way. This is clearly not the case for traffic whose top label is the special label 1. Therefore, the Router Alert label is not used to send the Multiprotocol Label Switching OAM packets when testing an Label Switch Routers. It can, however, be used for the return OAM traffic. Because an Label Switch Routers is unidirectional, Multiprotocol Label Switching OAM traffic is verifying the Label Switch Routers in only one direction. This means that the return traffic verifies nothing; it just needs to get back to the source. The return traffic can be sent with the Router Alert option so that it bypasses the hardware forwarding engines and has a better chance of getting back to the source. If the return traffic is labeled, it also has the Router Alert label, so the hardware forwarding engines are bypassed.

OAM Alert Label

This label is specified by the ITU-T Recommendation Y.1711 and RFC 3429. You insert this OAM Alert label in the label stack just below the label(s) of the Label Switch Routers under test. Cisco IOS does not use this special Multiprotocol Label Switching label anywhere. That is because the introduction of a special label in the label stack can influence the treatment of the packet when being forwarded. An example of this is the case of load balancing labeled packets, where the change in the label stack can introduce a different forwarding behavior. As such, the real user data traffic and the OAM traffic can be forwarded in a different way, rendering the OAM testing useless in some cases. A second example is the use of penultimate hop popping (PHP) in a plain IP-over-Multiprotocol Label Switching network. In this case, the packet arrives on the egress Label Switch Router with just the OAM Alert label in the label stack where otherwise it would arrive without a label stack. None of the OAM techniques discussed in this article and used by Cisco IOS uses the OAM Alert label.

Multiprotocol Label Switching Label Switch Routers Ping

Multiprotocol Label Switching Label Switch Routers ping is the name for an Multiprotocol Label Switching echo request and Multiprotocol Label Switching echo reply. Ping is a wellknown troubleshooting tool for IP networks that is used to figure out if the object is there. If it is, you see an echo. It is like using SONAR on a submarine. Ping uses ICMP, which was designed to augment the IP protocol because it can signal error conditions (destination unreachable, time exceeded, and so on) and send informational advertisements (redirect, address mask, and so on). Ping uses ICMP to carry echo request and echo reply packets. The echo request packet is sent toward the destination, which should then reply with an echo reply packet. The source receiving the echo reply indicates that the two hosts can see each other on the network level (Layer 3).

Because Multiprotocol Label Switching cannot work without IP on the network level, you can still use the IP ping when the network is running Multiprotocol Label Switching. The ping packets are labeled and label-switched throughout the network. Why invent Multiprotocol Label Switching Label Switch Routers ping? Well, IP ping is insufficient for verifying the correctness of the Multiprotocol Label Switching Label Switch Routers. Although it can verify whether the connectivity is present on the IP level, it does not verify whether the Label Switch Routers is broken. If you have a plain IP-over-Multiprotocol Label Switching network and Label Distribution Protocol is broken between two Label Switch Routers, ping indicates that there is no problem as the echo request makes it to the destination and the echo reply makes it back to the source. Between the two Label Switch Routers where the Label Distribution Protocol session is broken, the packets are no longer labeled. The ping indicates falsely that everything is okay, when in reality the Label Switch Routers is broken.

If the Label Switch Routers is broken, the AToM traffic becomes unlabeled between Label Switch Routers P2 and P3. Because those two Label Switch Routers do not know how to forward those frames, they are dropped. A ping from PE to PE router across the Label Switch Routers would be successful, but the AToM traffic would fail. To have a similar protocol to the IP ping protocol indicate specific problems with Multiprotocol Label Switching Label Switch Routerss, Multiprotocol Label Switching Label Switch Routers ping was invented. Label Switch Routerss can break for any number of reasons, while the IP connectivity remains fine. Following are some reasons an Label Switch Routers could be broken:

■ The Label Distribution Protocol session is down.
■ Multiprotocol Label Switching is not enabled on an Label Switch Router (or one interface).
■ The LFIB has a wrong entry for that Label Switch Routers (wrong in/out label or wrong outgoing next-hop information).
■ The software and hardware LFIB have a discrepancy.

For some of these problems, the packets become unlabeled; others are label-switched, but in a wrong way. That is why you need a mechanism to test the Label Switch Routers end to end and give some helpful feedback when the Label Switch Routers is broken. When you are troubleshooting the Label Switch Routers, it is good to know where the Label Switch Routers is broken and what the error is. Multiprotocol Label Switching Label Switch Routers ping detects problems in the forwarding plane, but it also checks the control plane against the information in the data plane. Label Switch Routers ping is similar to IP ping in that it also uses an echo request and echo reply. That is where the similarities stop, though. Multiprotocol Label Switching Label Switch Routers ping has different packet formats altogether and returns more troubleshooting information. An Multiprotocol Label Switching echo request is sent by the sender and tests one particular Forwarding Equivalence Class. The echo request holds the Forwarding Equivalence Class stack indicating which Forwarding Equivalence Class is being tested.

The Forwarding Equivalence Class stack can hold one or more labels that the receiver is to verify. The receiver then verifies that the Forwarding Equivalence Class stack on the echo request is the correct one for the Forwarding Equivalence Class. Also, the data plane information for the Forwarding Equivalence Class is verified with the control plane information. An Multiprotocol Label Switching echo request is a UDP packet with a destination port of 3503 and a source port chosen by the sender. It has a Router Alert option. To prevent the packet from switching any further as an IP packet if the Label Switch Routers is broken but the IP path is still fine, the IP TTL of the packet is set to 1 and the destination IP address of the packet is from the range 127.0.0.0/8. The address range 127.0.0.0/ 8 is for local IP addresses to the host; thus, packets that have a destination IP address from this range should never be seen on the network wires. An Label Switch Router never forwards such an IP packet if the Label Switch Routers is broken, and neither does the egress Label Switch Router of the Label Switch Routers. The egress Label Switch Router sends the packet to the UDP software module running on the router listening to UDP port 3503. The source IP address is just a chosen IP address of the sender. The version number is 1. The Global Flags field currently has only one defined bit.

The LSB is the V (Validate Forwarding Equivalence Class Stack) flag. If the V flag is set, the sender wants the receiver to validate the Forwarding Equivalence Class stack. The Message Type is either 1 for an Multiprotocol Label Switching echo request or 2 for an Multiprotocol Label Switching echo reply. The Reply mode indicates how the Multiprotocol Label Switching echo reply should be returned. Reply Mode 1 is to be used only if Echo Replies do not need to be returned. It might be that someone is monitoring the destination by means of a software component to see if the Multiprotocol Label Switching echo requests make it, so returning the Echo Replies is unnecessary. Reply Mode 2 is the regular reply mode. Reply Mode 3 is the same as Reply Mode 2, but the echo reply packets are returned with the Router Alert option. As explained in the previous section, you can use this to ensure that the packet has the highest degree of certainty to get back, in the case of forwarding problems along the return path. Reply Mode 4 is a reply mode out of band. Note that Multiprotocol Label Switching Label Switch Routers ping tests one Label Switch Routers. Because Label Switch Routerss are unidirectional, only the echo requests are testing the Multiprotocol Label Switching Label Switch Routers. The echo reply packets are not testing anything anymore; they are simply required to get the information back to the sender. As such, the network does not need to return the echo reply packets along the same path in the opposite direction. The network also does not need to return them labeled. The network can send them back as IP packets.

The Sender’s Handle is just that: a handle or number indicating who the sender is. The Sequence Number identifies subsequent echo requests and echo replies sent by the same Label Switch Router. The Timestamps are composed of two fields: one in seconds and one in microseconds. The Timestamp Sent indicates the time of day that the sender sent the echo request, and the Timestamp Received indicates the time of day that the receiver received the echo request. For the timestamps to be useful, you need to synchronize the clocks of the sender and receiver. The last fields transport the TLVs.