Introduction to MPLS test methods -- Overview

1 Overview

MPLS, as a forwarding technology, has been developing for many years. After years of development, the technology proposed at the beginning to improve forwarding efficiency has given it new vigor due to its excellent scalability. As VPN applications, TE and QoS applications based on MPLS technology are constantly deployed on various networks, MPLS has gradually become a new hot spot in the online world and a selling point for network devices.

Although the MPLS Forwarding technology is located between two and three layers, its implementation must be supported by the routing protocol, LDP and other label assignment protocols and other upper-layer protocols. In order to implement various MPLS-based applications, many upper-layer protocols are also extended. It can be said that the MPLS module covers many related protocols and is a very complex knowledge system. This also puts forward high requirements for us as testers.

Speaking of the test method, there is actually no fixed and static test method for any protocol in any module. Different testers have different testing methods, different concerns, and different ways of thinking. They can form their own unique testing methods, the Protocol, understanding of the entire module, and understanding of its application are also constantly deepened, and the testing methods are constantly enriched and improved. While the test methods are constantly enriched, the test will also become more in-depth.

This article is a rough summary of some of the methods used in testing and some problems encountered during normal times. It can be regarded as a reference. We hope to continuously improve our testing methods and improve our testing level!

It should be pointed out that a MPLS-based important application: TETraffic Engineering) will have a special article to introduce its testing method due to its relatively independent knowledge embodiment and complexity, this article will not discuss it.

2 Description of MPLS basic protocol test method

Basic MPLS protocols are protocols supporting various applications such as mpls vpn, including LDP, MBGP, and multiple instances of various routing protocols. Ensuring that basic protocols are fully functional is a guarantee for other MPLS applications. Therefore, we will first summarize some methods for testing the basic MPLS protocols.

Speaking of protocol testing, this includes basic function testing, protocol consistency testing, interoperability testing, and performance testing. Protocol test methods also include common test methods and test methods specific to different protocols. Common Test methods include command line configuration deletion, boundary value and illegal value setting, interface board connection line hot swapping, etc, I believe everyone has mastered these methods, and this article will not list them in the test method descriptions of each part. Here we mainly discuss the problems that we need to pay attention to when testing relevant protocols, and some testing methods that are often used to test these protocol features.

2.1 LDP Test Method

LDPLabel Distribute Protocol) is a universal label assignment Protocol that can serve all MPLS applications. Due to the complexity of the LDP protocol, different tag allocation modes, tag control modes, and tag persistence modes are defined. devices can be configured to work in multiple modes. At the same time, LDP also supports Loop-Detect and other features, so that its testing networking and testing methods are very complex. Next we will discuss the testing of LDP from several main functional parts of the LDP protocol.

2.1.1 test basic functions

2.1.1.1 establish a neighbor

LDP establishes a neighbor relationship through TCP and directly transmits a tag ing message between neighbors. The Protocol stipulates that only one LDP Session is allowed on two LSR devices. This is also the focus of Session testing. The main test methods include: directly create multiple types of direct connection interfaces on two lsrs, and encapsulate various types of link protocols on physical interfaces, including Ethernet, ATM, and FR subinterfaces, PPP, MP, MFR, and so on. You can also specify the IP addresses used to establish LDP sessions, including the IP addresses of various physical interfaces, subinterfaces, virtual interface IP addresses, and address borrow interface IP addresses, verify whether the LDP session is correctly established and whether the LDP session is unique.

The device supports configuring multiple IP addresses on the same interface, and LDP also supports using these sub-IP addresses to establish session relationships. Sub-IP addresses can be divided into different combinations configured on the master interface, sub-interface, and various virtual interfaces. Combining interfaces with various types of IP addresses is a common method to test LDP. When testing the LDP neighbor, we not only need to verify the establishment of LDP sessions between adjacent devices, but also test the creation of Remote LDP sessions between any two devices.

LDP establishes a session relationship between neighbors over TCP, and also provides a mechanism based on TCP MD5 authentication. Similar to other protocol authentication tests, after LDP authentication is configured, check whether the LDP session establishment is affected, the protocol message transmission is affected, and whether the TCP and LDP statuses are correctly displayed. Note that for TCP neighbors carrying MD5 authentication information, an asterisk (*) is displayed to identify the status. This is also one of the methods to check whether the authentication is successful.

Whether Up/Down interfaces, sub-interfaces, and virtual interfaces affect the LDP session status. I remember a previous online problem: due to poor quality of the photoelectric converter connecting two devices, the LSR interface was repeatedly Up/Down, And the LDP session was established repeatedly, after a certain period of time, the LDP session cannot be established. After the device is restarted, the session returns to normal. In the lab, this problem also encountered a serious problem that the equipment was down due to the constant insertion and removal of physical connections.

Another aspect of LDP session establishment is LDP capability and parameter negotiation. After modifying the interface parameters and LDP operation status parameters, can the LDP session parameters be correctly established and the negotiated parameters and capabilities be correct.

2.1.1.2 tag allocation

LDP is a widely used label assignment protocol. Its main function is to automatically allocate tags for different FEC routes. Therefore, whether tags are correctly allocated is the basic criterion for measuring whether the protocols work correctly. The LDP protocol will assign labels to local direct connection routes and dynamic routes, encapsulate the binding relationship between the labels and routes in the MAP message and pass them to the upstream LSR, so as to generate the corresponding LSP in the MPLS domain. As mentioned above, due to the different combinations of tag allocation mode, tag control mode, and tag retention mode, LDP may work in multiple modes. The most common mode is the DU + free label persistence + independent label control mode, which is also the main method of MPLS applications.

LSP is created by LSR Based on the route hop. The LSP outbound interface should be consistent with the outbound interface. In V5, multiple interfaces of LSP can be created for the equivalent route. Tests on the LSP include the synchronization between the LSP and the route. When the route or next hop changes, the LSP can be synchronized and the switching time should not be too long. The LSP should be completely set up for all routes in the MPLS domain. The corresponding LSP should be created in addition to the default route and aggregation route ). After creating the LSP, you can view table items such as mpls lsp, ILM, and FTNV5 corresponding to FIB) and NHLFE on the LSR. The table items should be consistent and correct. Especially in networks with frequent route changes, the device once experienced LSP deletion and label release, but the underlying ILM and NHLFE table items were not deleted, resulting in forwarding failure.

Because the device supports global tag space, LSR assigns a tag for each route. Different tags correspond to different FEC. Therefore, if the LSR should not assign the same label to different FEC, the global uniqueness of the label on the LSR should be ensured. Similarly, after the FEC route disappears, LSR should release the tag resources allocated to it in time and notify upstream neighbors through the LDP message. The released tags can be assigned to other FEC instances again. Especially when a large number of routes oscillate, check whether labels are unreleased and cannot be re-allocated.

Another common problem with LDP is that when the same route is repeatedly switched over multiple backup links and some egress interfaces of the equivalent route oscillate repeatedly, LDP cannot be synchronized with route changes correctly, repeated creation of some table items makes some expired table items unable to be deleted in time, and inconsistency between ILM, FTN and NHLFE causes MPLS Forwarding failure.

An important test tool for LSP testing is the LSP ping command. Ordinary ping commands can only detect route accessibility, but cannot determine whether the LSP is completely set up on a per-hop basis. In this case, we can use the LSP ping command to find the problematic LSP.

2.1.1.3 loop detection

To prevent MPLS Forwarding loops from being generated at the routing layer, LDP can carry loop detection information in the MAP message, including the Hop-Count attribute and Path-Vector attribute. The maximum number of hops allowed for LSP creation on the device to prevent loop generation. In the lab, it is difficult for a route to generate a loop. Therefore, in the test, the detection loop is usually achieved by setting a small number of LDP hops. The LDP Neighbor Relationship Between the router configured with the loop check and the router not configured with the loop check is established, ldp map message processing that does not carry the loop check, and MAP message processing that does not have the loop check attribute. Processing LDP messages that are about to reach or even exceed the specified number of hops.

2.1.2 protocol consistency test

Currently, many vendors provide test kits for consistency tests on various basic protocols, including RouterTester of Angilent, AX4000 of Sprient, and IxANVL of IXIA. These test kits are automated scripts developed by the instrument manufacturer strictly in accordance with the standard RFC, covering almost every functional point defined in the corresponding RFC. Using these protocol consistency test kits, we can accurately test whether devices are implemented in accordance with the standard protocols. This helps us to discover many deep protocol problems that cannot be found in interoperability test and traversal test. For the MPLS part, the main testers all have LDP protocol test kits, and protocol consistency tests have been widely used in the Platform product test department.

Some manufacturers also provide protocol consistency test kits for BGP, MBGP, L2VPN, VPLS, and other MPLS application modules, for more information about the specific support module, see the documentation of the original instrument concentration group.