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).
OSPFv3 Flush

OSPFv3 Flush

Background

If network-wide OSPFv3 LSAs are flushed, network stability will be adversely affected. In this case, source tracing must be implemented to locate the root cause of the fault immediately to minimize the impact. However, OSPFv3 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. In this case, OSPFv3 flush LSA source tracing is introduced, which allows maintenance personnel to locate the faulty source on any device on the network.

Related Concepts

OSPFv3 flush LSA source tracing

A mechanism that helps locate the device that flushes LSAs. The feature has the following characteristics:
  • Uses a new UDP port. Source tracing packets are carried by UDP packets, and the UDP packets also carry the OSPFv3 LSAs flushed by the current device and are flooded hop by hop based on the OSPFv3 topology.
  • Forwards packets along UDP channels which are independent of the channels used to transmit OSPFv3 packets. Therefore, OSPFv3 flush LSA source tracing supports incremental deployment. In addition, source tracing does not affect the devices with the related UDP port disabled.
  • Supports query of the node that flushed LSAs on any of the devices after OSPFv3 flush LSA source tracing packets are flooded on the network, which speeds up fault locating and faulty node isolation.

  • Is Huawei proprietary.

Flush

Network-wide OSPFv3 LSAs are deleted.

PS-Hello packets

Packets used to negotiate the OSPFv3 flush LSA source tracing capability between OSPFv3 neighbors.

PS-LSA

When a device flushes an OSPFv3 LSA, it generates a PS-LSA carrying information about the device and brief information about the OSPFv3 LSA.

PS-LSU packets

OSPFv3 flush LSA source tracing packets that carry PS-LSAs.

PS-LSU ACK packets

Acknowledgment packets used to improve OSPFv3 flush LSA source tracing packets.

OSPFv3 flush LSA source tracing port

ID of the UDP port that receives and sends OSPFv3 flush LSA source tracing packets. The default port ID is 50133, which is configurable.

Implementation

The implementation of OSPFv3 flush LSA source tracing is as follows:
  1. Source tracing capability negotiation

    After an OSPFv3 neighbor relationship is established between two devices, they need to negotiate the source tracing capability through PS-Hello packets.

  2. PS-LSA generation and flooding

    When a device flushes an OSPFv3 LSA, it generates a PS-LSA carrying information about the device and brief information about the OSPFv3 LSA, adds the PS-LSA to a PS-LSU packet, and floods the PS-LSU packet to source tracing-capable neighbors. The PS-LSU packet is used to locate the faulty source.

NOTE:
Only Router-LSAs, Network-LSAs, and Inter-Area-Router-LSAs can be flushed. Therefore, a device generates a PS-LSA only when it flushes a Router-LSA, Network-LSA, or Inter-Area-Router-LSA.

Source Tracing Capability Negotiation

OSPFv3 flush LSA source tracing uses UDP to carry source tracing packets and listens to the UDP port which is used to receive and send source tracing packets. OSPFv3 flush LSA source tracing is Huawei proprietary. 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 OSPFv3 neighbor relationships. Specifically, after an OSPFv3 neighbor relationship is established, the local device initiates source tracing capability negotiation based on the IP address of the neighbor. Figure 7-15 shows the negotiation process.

Figure 7-15 Source tracing capability negotiation
Table 7-9 Source tracing capability negotiation

Whether Source Tracing Is Supported

Source Tracing Capability Negotiation Process

Devices A and B both support source tracing.

  1. Device A sends a PS-Hello packet to notify its source tracing capability to device B.
  2. Upon reception of the PS-Hello packet, device B sets the source tracing field for device A and replies with an ACK packet to notify its source tracing capability to device A.
  3. Upon reception of the ACK packet, device A sets the source tracing field for device B.

Devices A supports source tracing, but device B does not.

  1. Device A sends a PS-Hello packet to notify its source tracing capability to device B.
  2. Device A fails to receive an ACK packet from device B within 10s and retransmits the PS-Hello packet. Device A can retransmit the PS-Hello packet twice at most. After device A fails to receive an ACK packet from device B after the PS-Hello packet is retransmitted twice, device A considers that device B does not support source tracing.

Devices A and B both support source tracing, but source tracing is disabled from device B.

  1. After source tracing is disabled from device B, device B sends a PS-Hello packet to notify its source tracing incapability to device A.
  2. Upon reception of the PS-Hello packet, device A replies with an ACK packet that carries the source tracing capability.
  3. Upon reception of the ACK packet, device B considers the capability negotiation complete and disables the UDP port.

Devices A does not support source tracing, and source tracing is disabled from device B.

  1. After source tracing is disabled from device B, device B sends a PS-Hello packet to notify its source tracing incapability to device A.
  2. Device B fails to receive an ACK packet from device A within 10s and retransmits the PS-Hello packet. Device B can retransmit the PS-Hello packet twice at most. After device B fails to receive an ACK packet from device B after the PS-Hello packet is retransmitted twice, device A considers the capability negotiation complete and disables the UDP port.

PS-LSA Generation and Flooding

PS-LSA: carries information about the node that flushed OSPFv3 LSAs.
  • If a device flushes an OSPFv3 LSA, it generates and floods a PS-LSA to all its neighbors.

  • If a device receives a flush LSA from a source tracing-incapable neighbor, the device generates and floods a PS-LSA to all its neighbors. If a device receives the same flush LSA (with the same LSID and sequence number) from more than one source tracing-incapable neighbor, the device generates only one PS-LSA.

  • If a device flushes a Router-LSA, Network-LSA, or Inter-Area-Router-LSA, it generates a PS-LSA, adds the PS-LSA to a PS-LSU packet, and floods the PS-LSU packet to all source tracing-capable neighbors.

Figure 7-16 PS-LSA generation rules

PS-LSA generation rules

  • When device A flushes a Router-LSA, Network-LSA, or Inter-Area-Router-LSA, it generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is 0, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors.
  • After device A receives the flush LSA from device B (source tracing incapable), device A generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is the router ID of device B, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors.
  • After device A receives the flush LSA from device B, followed by the same flush LSA sent by device C, device A generates a PS-LSA in which the Flush Router field is its router ID and the Neighbor Router field is the router ID of device B, and adds the PS-LSA to the queue where packets are to be sent to all source tracing-capable neighbors. Device A does not generate a PS-LSA in response to the flush LSA sent by device C.

PS-LSU packet sending rules

  • During neighbor relationship establishment, a device initializes the sequence number of the PS-LSU packet of the neighbor. When the device replies with a PS-LSU packet, it adds the sequence number of the PS-LSU packet of the neighbor. During PS-LSU packet retransmission, the sequence number remains unchanged. After the device receives a PS-LSU ACK packet with the same sequence number, it increases the sequence number of the neighbor's PS-LSU packet by 1.
  • The neighbor manages the PS-LSA sending queue. When a PS-LSA is added to the queue which was empty, the neighbor starts a timer. After the timer expires, the neighbor adds the PS-LSAs in the queue to a PS-LSU packet, sends the packet to its neighbor, and starts another timer to wait for a PS-LSU ACK packet.
  • After the PS-LSU ACK timer expires, the PS-LSU packet is retransmitted.
  • When the device receives a PS-LSU ACK packet with a sequence number same as that in the neighbor record, the device clears PS-LSAs from the neighbor queue, and sends another PS-LSU packet after the timer expires.
    • If the sequence number of a received PS-LSU ACK packet is less than that in the neighbor record, the device ignores the packet.
    • If the sequence number of a received PS-LSU ACK packet is greater than that in the neighbor record, the device discards the packet.
NOTE:
PS-LSU packet sending is independent among neighbors.

PS-LSU packet receiving rules

  • When a device receives a PS-LSU packet from a neighbor, the neighbor records the sequence number of the packet and replies with a PS-LSU ACK packet.
  • When the device receives a PS-LSU packet with the sequence number same as that in the neighbor record, the device discards the PS-LSU packet.
  • After the devices parses a PS-LSU packet, it adds the PS-LSA in the packet to the LSDB. The device also checks whether the PS-LSA is newer than the corresponding PS-LSA in the LSDB.
    • If the PS-LSA is newer, the device floods it to other neighbors.
    • If the PS-LSA is the same as the corresponding PS-LSA in the LSDB, the device does not process the received PS-LSA.
    • If the PS-LSA is older, the device floods the corresponding PS-LSA in the LSDB to the neighbor.
  • If the device receives a PS-LSU packet from a neighbor and the neighbor does not support source tracing, the device modifies the neighbor status as source tracing capable.

Source Tracing Security

OSPFv3 flush LSA source tracing uses a UDP port to receive and send source tracing packets. Therefore, the security of the port must be taken into consideration.

OSPFv3 flush LSA source tracing inevitably increases packet receiving and sending workload and intensifies bandwidth pressure. To minimize the impact on OSPFv3, the number of source tracing packets must be controlled.

The following security measures are available:

Table 7-10 Security measures for source tracing

Security Measures for Source Tracing

Principles

Authentication

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

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.

OSPFv3 flush LSA source tracing packets can be flooded as far as one hop.
  • When a device sends a packet, it sets the TTL of the packet to 255.
  • If the TTL is not 254 when the packet is received, the packet will be discarded.

Cpu-car

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. OSPFv3 flush LSA 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 node A is the faulty source. Figure 7-17 shows the networking.

Figure 7-17 Scenario where all nodes support source tracing

When device A flushes an OSPFv3 LSA, it generates a PS-LSA that carries device A information and brief information about the flush LSA. Then the PS-LSA 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 flush LSAs 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 7-18 shows the networking.

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

When device A flushes an OSPFv3 LSA, it generates a PS-LSA that carries device A information and brief information about the flush LSA. Then the PS-LSA is flooded on the network hop by hop. When devices B and 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 PS-LSA from device A, device B sends the PS-LSA to device D, but not to device C. After receiving the flush LSA from device C, device E generates a PS-LSA which carries information about the advertisement source (device E), flush source (device C), and the flush LSA, and floods the PS-LSA on the network.

After the fault occurs, maintenance personnel can log in to any device on the network except device C to locate the faulty node. Two possible faulty nodes can be located in this case: node A and node C, and they both sends the same flush LSA. 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.

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 node A is the faulty source. In this case, the PS-LSA cannot be flooded on the entire network. Figure 7-19 shows the networking.

Figure 7-19 Scenario where source tracing-incapable nodes are isolated from source tracing-capable nodes

When device A flushes an OSPFv3 LSA, it generates a PS-LSA that carries device A information and brief information about the flush LSA. However, the PS-LSA can reach only device B because devices C and D do not support 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 PS-LSA from device C, device E helps device E generate and flood a PS-LSA. Similarly, after device F receives the PS-LSA from device D, device F helps device D generate and flood a PS-LSA.

After the fault occurs:
  • If maintenance personnel log in to device A or 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, F, G, or 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.
  • If the personnel log in to devices C and D and find that the flush LSA was sent by device B, not generated by device C or D.
  • If the personnel log in to device B, determine that device A is the faulty device, and isolate device A. After device A is isolated, the network recovers.
Translation
Download
Updated: 2019-01-04

Document ID: EDOC1100059473

Views: 14601

Downloads: 10

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