No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

ME60 V800R010C10SPC500 Feature Description - WAN Access 01

This is ME60 V800R010C10SPC500 Feature Description - WAN Access
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
IS-IS Purge LSP Source Tracing

IS-IS Purge LSP Source Tracing

Background

If network-wide IS-IS LSPs are deleted, purge LSPs are flooded, which adversely affects network stability. In this case, source tracing must be implemented to locate the root cause of the fault immediately to minimize the impact. However, IS-IS itself does not support source tracing. A conventional solution is isolation node by node until the faulty node is located. The solution is complex and time-consuming. Therefore, a fast source tracing method is required.

IS-IS purge LSP source tracing is a Huawei proprietary protocol.

Related Concepts

  • PS-PDU: packets that carry information about the node that floods IS-IS purge LSPs.

  • CAP-PDU: packets used to negotiate the IS-IS purge LSP source tracing capability between IS-IS neighbors.

  • IS-IS purge LSP source tracing port: ID of the UDP port that receives and sends IS-IS purge LSP source tracing packets. The default port ID is 50121, which is configurable.

Implementation

IS-IS purge LSPs do not carry source information. If a device fails on the network, a large number of purge LSPs are flooded. Without a source tracing mechanism, nodes are isolated one by one until the faulty node is located, which is labor-intensive and time-consuming.

IS-IS purge LSPs will trigger route flapping on the network, or even routes become unavailable. In this case, the device that floods the purge LSPs must be located and isolated immediately.

A solution that can address the following issues is required:

  • Information about the source that floods IS-IS purge LSPs can be obtained when network routes are unreachable.

  • The method used to obtain source information must apply to all devices on the network and support incremental deployment, without compromising routing capabilities.

IS-IS purge LSP source tracing helps locate the device that floods purge LSPs. IS-IS purge LSP source tracing uses a new UDP port. Source tracing packets are carried by UDP packets, and the UDP packets also carry the IS-IS purge LSPs sent by the current device and are flooded hop by hop based on the IS-IS topology.

IS-IS purge LSP source tracing forwards packets along UDP channels which are independent of the channels used to transmit IS-IS packets. Therefore, IS-IS purge LSP source tracing supports incremental deployment. In addition, source tracing does not affect the devices with the related UDP port disabled.

After IS-IS purge LSP source tracing packets are flooded to devices on the network, information about the node that floods purge LSPs can be queried on any of the devices, which speeds up fault locating and faulty node isolation.

Capability Negotiation

IS-IS purge LSP source tracing is Huawei proprietary. It uses UDP to carry packets and listens to the UDP port which is used to receive and send source tracing packets. If a source tracing-capable Huawei device sends source tracing packets to a source tracing-incapable Huawei device or non-Huawei device, the source tracing-capable Huawei device may be incorrectly identified as an attacker. Therefore, the source tracing capability need to be negotiated between the devices. In addition, the source tracing-capable device needs to help the source tracing-incapable device to send source tracing information, which also requires negotiation.

Source tracing capability negotiation depends on IS-IS neighbor relationships. Specifically, after an IS-IS neighbor relationship is established, the local device initiates source tracing capability negotiation based on the IP address of the neighbor.

PS-PDU Generation

If a device needs to purge an LSP, it generates and floods a PS-PDU to all its source tracing neighbors.

If a device receives a purge LSP from a source tracing-incapable neighbor, the device generates and floods a PS-PDU to all its neighbors. If a device receives the same purge LSP (with the same LSP ID and sequence number) from more than one source tracing-incapable neighbor, the device generates only one PS-PDU.

PS-PDU flooding is similar to IS-IS LSP flooding.

Security Concern

IS-IS purge LSP source tracing uses a UDP port to receive and send source tracing packets. Therefore, the security of the port must be taken into consideration.

IS-IS purge LSP source tracing inevitably increases packet receiving and sending workload and intensifies bandwidth pressure. To minimize the impact on IS-IS, the number of source tracing packets must be controlled.

  • Authentication

    Source tracing is embedded in IS-IS and uses IS-IS authentication parameters to authenticate packets.

  • Generalized TTL security mechanism (GTSM)

    GTSM is a security mechanism that checks whether the time to live (TTL) value in each received IP packet header is within a pre-defined range.

    IS-IS purge LSP source tracing packets can be flooded as far as one hop. If the TTL of a packet is 255 when it is sent and not 254 when it is received, the packet will be discarded.

  • CPU-CAR

    The NP chip on interface boards can check the packets to be sent to the CPU for processing and prevent the main control board from being overloaded by a large number of packets that are sent to the CPU.

    IS-IS purge LSP source tracing needs to apply for an independent CAR channel and has small committed information rate (CIR) and committed burst size (CBS) values configured.

Typical Scenarios

Scenario where all nodes support source tracing

All nodes on the network support source tracing, and Device A is the faulty source. Figure 8-25 shows the networking.

Figure 8-25 Scenario where all nodes support source tracing

All nodes in the networking support IS-IS purge LSP source tracing, and Device A is the faulty source.

When Device A purges an IS-IS LSP, it floods a source tracing packet that carries Device A information and brief information about the LSP. Then the packet is flooded on the network hop by hop. After the fault occurs, maintenance personnel can log in to any node on the network to locate Device A that keeps sending purge LSPs and isolate Device A from the network.

Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

All nodes on the network except device C support source tracing, and device A is the faulty source. In this case, the PS-LSA can be flooded on the entire network. Figure 8-26 shows the networking.

Figure 8-26 Scenario where source tracing-incapable nodes are not isolated from source tracing-capable nodes

When Device A purges an IS-IS LSP, it floods a source tracing packet that carries Device A information and brief information about the LSP. Then the packet is flooded on the network hop by hop. When Device B and Device E negotiate the source tracing capability with Device C, they find that Device C does not support source tracing. Therefore, after Device B receives the source tracing packet from Device A, Device B sends the packet to Device D, but not to Device C. After receiving the purge LSP from Device C, Device E generates a source tracing packet which carries information about the advertisement source (Device E), purge source (Device C), and the purge LSP, and floods the packet on the network.

After the fault occurs, maintenance personnel can log in to any node on the network except Device C to locate the faulty node. Two possible faulty nodes can be located in this case: Device A and Device C, and they both sends the same purge LSP. In this case, Device A takes precedence over Device C when the maintenance personnel determine the most possible faulty source. After Device A is isolated, the network recovers. Then the possibility that Device C is the faulty node is ruled out.

Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

All nodes on the network except devices C and D support source tracing, and Device A is the faulty source. In this case, the PS-LSA cannot be flooded on the entire network. Figure 8-27 shows the networking.

Figure 8-27 Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

When Device A purges an IS-IS LSP, it floods a source tracing packet that carries Device A information and brief information about the LSP. However, the source tracing packet can reach only Device B because nodes C and Device D do not support IS-IS purge LSP source tracing.

During source tracing capability negotiation, Device E finds that Device C does not support source tracing, and Device F finds that Device D does not support source tracing. After Device E receives the purge LSP from Device C, Device E helps Device E generate and flood a source tracing packet. Similarly, after Device F receives the purge LSP from Device D, Device F helps Device D generate and flood a source tracing packet.

After the fault occurs, if maintenance personnel log in to Device A or Device B, the personnel can locate the faulty source (Device A) directly. After Device A is isolated, the network recovers. If the maintenance personnel log in to Device E, Device F, Device G, or Device H, the personnel will find that Device E claims Device C to be the faulty source and Device F claims Device D to be the faulty source. Then the personnel log in to nodes C and Device D and find that the purge LSP was sent by Device B, not generated by Device C or Device D. Then the personnel log in to Device B, determine that Device A is the faulty node, and isolate Device A. After Device A is isolated, the network recovers.

Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14715

Downloads: 10

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next