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>

Reminder

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

upgrade

The MPLS VPN Could Not Work After Cutover Because the Differences Between the NE80E and NE80 in the VPNv4 Route Handling Mode Were Ignored

Publication Date:  2012-07-27 Views:  2 Downloads:  0
Issue Description
The network of Carrier C used two NE80s of Huawei as the reflectors of VPNv4 routes and as the P devices at the same time. The version of the devices was VRP3.10 2358. The two NE80s were replaced with two NE80Es of V300R002C06B325 as follows: On the first day, NE80-A was replaced. After the replacement, MPLS VPN services were found to proceed normally in the test. On the second day, NE80-B was replaced. After the replacement, all MPLS VPN services on the network could not work normally, but other services proceeded normally and VPN routes of other PEs could not be learned on the PE. The principles for the two replacements were the same.
Networking: Two PEs were attached to two NE80s as follows: 
        NE80-A(P)----NE80-B(P)
                      /         \   /     \   
                     /         /    \       \   
                    /      /            \     \   
                PE1                   PE2

 
Alarm Information
Null
Handling Process
1. The problem arose after the second cutover rather than the first cutover. Therefore, the engineer guessed that there was something wrong with the second cutover. Based on such an assumption, the engineer improved the cost values of IGP routes from PE1/2 to NE80E-B so that the traffic between PE1 and PE2 flowed to only NE80E-A. After the adjustment, VPN services were still unavailable. Then the engineer restarted NE80E-B. In the restart process, VPN services were still unavailable. Therefore, the engineer deduced that the problem was not with only NE80E-B.
2. Checking MBGP peers of PE1/PE2 and NE80E-A/B, the engineer found the peers were normally established.
3. Checking carefully the MBGP routes of VPNv4 of the two NE80Es, the engineer found that no routes were learned from PE1 or PE2.
4. Checking again the ipv4-family vpnv4 configuration of the two NE80Es, the engineer found that policy vpn-target was configured in this view. After this command was changed to undo policy vpn-target, the MPLS VPN services resumed.
Now the cause of the problem was located. When the NE80s of VRP3.10 2358 act as RRs, by default, the VPN route filtering function is disabled. However, this is not displayed in the configuration command. Thus, the installation engineers tend to ignore this during engineering. For the NE80Es of VRP5.3, by default, the VPN route filtering function is enabled. In the case, after the first cutover, NE80E-A could not reflect routes, but NE80-B that had not been replaced could. That explained why VPN services proceeded normally after the first cutover. After NE80-B was replaced in the second cutover, two NE80Es filtered VPN routes. As a result, the MPLS VPN services were unavailable. 

 
Root Cause
1. Because the problem arose after the cutover, the engineer guessed that there was something wrong with NE80E-B. After NE80E-B was isolated, the services were still unavailable. Thus, the problem was not with only NE80E-B.
2. Checking the status of MBGP peers and the establishment of LSPs, the engineer found that both were normal.
3. The engineer then checked whether VPNv4 routers were filtered. 

 
Suggestions
Before the cutover, the engineers must know well the differences between two versions involved in the cutover. 

END