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

NE20E-S2 V800R010C10SPC500 Feature Description - System Monitor 01

This is NE20E-S2 V800R010C10SPC500 Feature Description - System Monitor
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).
NQA Detection on a VPN

NQA Detection on a VPN

PWE3 Ping Test

An NQA pseudo wire emulation edge-to-edge (PWE3) ping test instance checks the reachability of a pseudo wire (PW) over a Multiprotocol Label Switching (MPLS) network. The PWE3 ping test process is shown in Figure 4-15.

  1. A local device (PE1) selects a specified PW to send an MPLS Echo Request message to a remote device (PE2). After the remote device receives the message, it returns an MPLS Echo Reply message carrying the local device interface address to the local device.

  2. After the local device receives the MPLS Echo Reply message, it forwards data along the PW.

    The local device calculates the difference between the time the MPLS Echo Request message was sent and the time the MPLS Echo Reply packet was received. The length of time reflects PW connectivity.

Figure 4-15 Application scenario of a PWE3 Ping operation

PWE3 Trace Test

After being widely used, PWE3 also needs to provide O&M capabilities. PWE3 tracert, a network maintenance tool, is developed in this context.

Just like PWs are classified as SS-PWs or MS-PWs, PWE3 tracert is classified as PWE3 single-segment tracert or PWE3 multi-segment tracert.

PWE3 single-segment tracert

On the PWE3 network shown in Figure 4-16, CE1 and CE4 belong to VPN1; CE2 and CE3 belong to VPN2. The path is PE1 -> P -> PE4 for the LSP from PE1 to PE4 and PE2 -> P -> PE3 for the LSP from PE2 to PE3.

Figure 4-16 PWE3 single-segment tracert

On PE1, you can start PWE3 tracert of VPN1 by using related commands. PWE3 tracert in this case is the same as LSP tracert on the public network, except that a PW label is added to packets and the local PE checks whether the PW label and VC ID carried in packets received from the remote end are the same as those on the local end.

The source PE of PWE3 tracert sends MPLS Echo Request packets with TTL in the outer label from 1 on and TTL in the inner label as 1. Upon receipt of a packet with TTL in the outer label as 1, an LSR does not forward the packet. Instead, after confirming that the service and label information carried in the packet is correct, the LSR sends an MPLS Echo Reply packet to the source PE. In this manner, the source PE collects information about each LSR and the egress PE along the LSP. Currently, MPLS Echo Reply packets are IP packets that do not carry any label.

The following uses the LSP between PE1 and PE4 as an example to explain how PWE3 tracert collects node information.

By initiating PWE3 tracert, PE1 collects information about nodes along the LSP between PE1 and PE4. By comparing paths obtained through PWE3 tracert, you can determine whether an error exists.

If PE1 collects only information about PE4 with TTL being 2 rather than information about the P with TTL being 1, PE1 regards that the P does not support MPLS ping.

If PE1 collects only information about the P with TTL being 1 rather than information about PE4 with TTL being 2, PE1 regards that PE4 or the link between the P and PE4 is faulty.

If PE1 collects information about PE1, PE2, and PE4, the P may be faulty. A new path has been generated by the protocol.

PWE3 multi-segment tracert

On the network shown in Figure 4-17, a multi-segment PW is established between CE1 and CE2, and the IDs of PW segments are different. The LSP path is UPE1-P1-SPE1-SPE2-P2-UPE2.

Figure 4-17 PWE3 multi-segment tracert

PWE3 tracert started on UPE1 can obtain a correct response only from P1 and SPE1. SPE2 and UPE2 find that the Remote PE Address and VC ID are inconsistent. This means that PWE3 tracert passes through an MS-PW. PW label switching information can be found in the downstream mapping information sent by each device.

SPE1 can start either PWE3 tracert to UPE1 or PWE3 tracert to SPE2 and UPE2. The PWE3 tracert to UPE1 can be regarded as PWE3 single-segment tracert, and the PWE3 tracert to SPE2 and UPE2 can be regarded as PWE3 multi-segment tracert.

The case with PWE3 tracert on other PEs is similar.

VPLS MAC Ping Test

Overview

A VPLS MAC ping test is used to detect whether a specified destination MAC address exists and whether the path across the VPLS network to the specified destination MAC address is reachable. At present, only the peer bridge MAC address can be pinged.

Test Process

On the network shown in Figure 4-18, the general VPLS MAC ping test process is as follows:

  1. The VPLS MAC ping test instance on the local PE constructs an MPLS Echo Request packet and adds network address 127.0.0.0/8 to the IP header as the destination IP address. Then, the test instance searches the MAC address table on the local PE for a MAC forwarding entry corresponding to the destination MAC address. If a MAC forwarding entry learned from the PW side is found, the test instance sends the MPLS Echo Request packet to the corresponding PW. Otherwise, the test instance broadcasts the MPLS Echo Request packet to all PWs in the specified VSI. The VSI and destination MAC address must be specified before a VPLS MAC ping test instance is run. The destination MAC address can be either the remote PE's bridge MAC address or the CE's MAC address.

  2. The remote PE listens to port 3503 for the MPLS Echo Request packet and returns an MPLS Echo Reply packet as the response.

  3. If the destination MAC address is a CE's MAC address, the MPLS Echo Request packet will not be forwarded to the CE. Instead, the destination MAC address will be checked on the PE to which the CE connects. If the destination MAC address can be found in the PE's MAC address table, the VPLS MAC ping test is regarded as successful; otherwise, the test is regarded as unsuccessful.

    The local PE can then calculate the communication time between itself and the remote PE by subtracting the time at which the local PE sends the MPLS Echo Request packet from the time at which the local PE receives the MPLS Echo Reply packet. The communication time clearly reflects VPLS network performance.

Figure 4-18 Network for a VPLS MAC ping test

On the network shown in Figure 4-18, if PE1 initiates the VPLS MAC ping test, the test process is as follows (assume that in the VPLS MAC ping test instance, the specified VSI is a2 and the specified destination MAC address is 0018-826d-4917, CE2's MAC address):

  1. The VPLS MAC ping test instance constructs an MPLS Echo Request packet and searches PE1's MAC address table for a MAC forwarding entry. After failing to find a matching MAC forwarding entry, the test instance broadcasts the MPLS Echo Request packet to all PWs in the specified VSI.

  2. Upon receipt of the MPLS Echo Request packet, PE3 compares the destination MAC address of the packet with its bridge MAC address. After finding that the two MAC addresses are different, PE3 searches its MAC address table for a MAC forwarding entry corresponding to the destination MAC address. After failing to find a matching MAC forwarding entry, PE3 stops forwarding the MPLS Echo Request packet according to the split horizon principle.

  3. Upon receipt of the MPLS Echo Request packet, PE2 also compares the destination MAC address of the packet with its bridge MAC address. After finding that the two MAC addresses are different, PE2 searches its MAC address table for a MAC forwarding entry corresponding to the destination MAC address. After successfully finding a matching MAC forwarding entry, PE2 returns an MPLS Echo Reply packet.

Usage Scenario

VPLS MAC ping tests can be used in both conventional VPLS and HVPLS scenarios.

Benefits

When a link fault occurs, you can perform a VPLS MAC ping test to detect VPLS network connectivity.

VPLS PW Ping/Trace Test

Background

As a main technology for setting up a metropolitan area network (MAN), Virtual Private LAN Service (VPLS) has been widely applied globally. VPLS, however, is poor in terms of service management and monitoring. In this case, an optimized VPLS OAM mechanism is required.

On a VPLS network, the performance of PWs affects the entire network performance. For example, the connectivity of PWs determines whether traffic can be normally forwarded between users, and the forwarding performance of PWs determines whether the forwarding capacity of the network complies with the Service Level Agreement (SLA) signed with users. To monitor PWs on the VPLS network, VPLS PW ping and VPLS PW trace are developed for detecting the connectivity of PWs, collecting performance information about PWs, discovering packet forwarding paths along PWs, and locating faults on PWs.

VPLS PW ping or VPLS PW trace operations initiated through NQA commands are the same as ping or trace operations initiated through common command lines in principle, and additionally provide the scheduling and result collection mechanism and the threshold-exceeding alarm function.

VPLS PW ping and VPLS PW trace comply with standard protocols in implementing PW detection: MPLS echo packets that carry Forwarding Equivalence Class (FEC) fields are encapsulated in tunnel mode and labeled with the Router Alert option; the Router Alert function is enabled on the VPLS network. MPLS echo packets are transmitted between PEs to detect PWs and are not sent to CEs, which means that the NQA test instance can be configured only on PEs. If an NQA test instance is configured on a non-PE device, it cannot be started because there is no VSI used for establishing PWs on the non-PE device and as a result, the test result is "drop."

During the VPLS PW detection through an NQA test instance, threshold monitoring and NQA test instance scheduling can be actively performed based on the specifications defined in the IP SLA.
  • A VPLS PW ping or VPLS PW trace test instance can be configured to actively monitor VPLS services and detect faults in VPLS services. In the case that the round-trip time (RTT) of a packet exceeds the threshold, a connection is interrupted, or the response to a request packet times out, an SNMP trap message in an NQA test instance is sent to the Network Management System (NMS) for notification and collects the statistics (such as the RTT) for users to query.
  • The scheduling function can be enabled to periodically schedule an NQA test instance to detect a specific VPLS PW as required. When multiple NQA test instances are started concurrently to detect multiple PWs, the scheduling function enables these NQA test instances to operate separately and arranges the operation time properly so that as many test instances as possible can be started for PW detection. The maximum number of test instances that the system allows is calculated based on the traffic metric of test instances.
Implementation
On the network shown in Figure 4-19, the procedures for starting a VPLS PW ping test instance are as follows:
  1. PE1 initiates a VPLS PW ping test instance after the virtual switch instance (VSI) and peer IP address are configured on PE1. Then, the NQA module constructs an MPLS Echo Request message carrying the Router Alert option and sends it over the public network based on the forwarding information in the forwarding table.
  2. Upon receipt, PE2 parses the packet and determines whether it is the destination of the packet. If the destination address is PE2's address, PE2 sends the MPLS Echo Request packet to the CPU for processing. Then, it constructs an MPLS Echo Reply packet carrying timestamps indicating the time when the MPLS Echo Request message was received and when the MPLS Echo Reply message was sent. Then PE2 sends the Echo Reply message to PE1.
  3. When the MPLS Echo Reply message reaches PE1, PE1 saves the time information in the message to the test result table. Based on the time information, PE1 calculates the unidirectional delay of the message transmission after the transmit and receive ends have synchronized their clocks. If PE1 does not receive an Echo Reply message after the timeout period relapses, it records an error in the test result table.
On the network shown in Figure 4-19, the procedures for starting a VPLS PW trace test instance are as follows:
  1. PE1 initiates a VPLS PW trace test instance after the VSI and peer IP address are configured on PE1. Then, the NQA module constructs an MPLS Echo Request message in which the Router Alert option is encapsulated and a timestamp is added to the private TLV, and sends it over the public network based on the forwarding information in the forwarding table. The TTL value in the first MPLS Echo Request message is 1 by default, and you can specify an initial TTL value and the maximum TTL value.
  2. Upon receipt, the transit node forwards the MPLS Echo Request message to the next hop when the TTL of the message times out. The transit node obtains next-hop information based on the incoming label and inbound interface index, and encapsulates the DS TLV in an MPLS Echo Reply message. Then the transit node sends the MPLS Echo Reply message to PE1.
  3. Upon receipt, PE1 increases the TTL value by 1 and constructs another MPLS Echo Request message for transmission until the message reaches the destination or the TTL reaches the maximum value.
Figure 4-19 Typical VPLS network

Translation
Download
Updated: 2019-01-02

Document ID: EDOC1100055478

Views: 5712

Downloads: 2

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