Checking the Source Interface of a Static CR-LSP
A device uses the static CR-LSP's source interface check function to check whether the inbound interface of labeled packets is the same as that of a configured static CR-LSP. If the inbound interfaces match, the device forwards the packets. If the inbound interfaces do not match, the device discards the packets.
Background
A static CR-LSP is established using manually configured forwarding and resource information. Signaling protocols and path calculation are not used during the setup of CR-LSPs. Setting up a static CR-LSP consumes a few resources because the two ends of the CR-LSP do not need to exchange MPLS control packets. The static CR-LSP cannot be adjusted dynamically in a changeable network topology. A static CR-LSP configuration error may cause protocol packets of different NEs and statuses interfere one another, which adversely affects services. To address the preceding problem, a device can be enabled to check source interfaces of static CR-LSPs. With this function configured, the device can only forward packets if both labels and inbound interfaces are correct.
Principles
In Figure 1, static CR-LSP1 is configured, with PE1 functioning as the ingress, the P as a transit node, and PE2 as the egress. The P's inbound interface connected to PE1 is Interface1 and the incoming label is Label1. Static CR-LSP2 remains on PE3 that functions as the ingress of CR-LSP2. The P's inbound interface connected to PE3 is Interface2 and the incoming label is Label1. If PE3 sends traffic along CR-LSP2 and Interface2 on the P receives the traffic, the P checks the inbound interface information and finds that the traffic carries Label2 but the inbound interface is not Interface2. Consequently, the P discards the traffic.
