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

Certain Routes Fail to Be Advertised by the NE40E Serving as the ASBR in VPN OptionB Because eBGP Multihop Is Configured on VPNv4 Peers Created Through Directly Connected Interfaces

Publication Date:  2012-07-27 Views:  44 Downloads:  0
Issue Description
As shown in the topology diagram, the four routers in the middle are ASBRs. The lower two are made by vendor C and the upper two are NE40Es. The cross-domain VPN OptionB is configured. NE40E-1 serves as both the RR and the PE. After the version of NE40E-1 is upgraded from V300R001C01B052 to V300R002C06B325, NE40E-1, after receiving VPNv4 routes of the ASBRs of C, does not advertise these routes to the S8508 whose IP address is 172.31.8.1. 
Alarm Information
Null
Handling Process
1. Find out why routes fail to be advertised.
According to the routing information provided by field engineers, one of the routes that are not advertised to the S8508 is found:
*>   10.2.1.0/24   xx.53.192.169  1000             0        44237 44237 44237
                              xx.51.254.29    100    150     150    44237
                              xx.51.254.17    100    150     150    44237
It is found that two routes with the ASBRs of C as the next hops are not preferentially chosen because they are not valid, and other routes with long paths are preferentially chosen. As a result, the routes with the ASBRs of C as the next hops are not advertised to the S8508 as expected.
Check the routes on the existing network. The MPLS tunnels corresponding to the routes are not found. Thus, the routes with the ASBRs of C as the next hops are invalid. That is why these routes fail to be advertised.
The reverse MPLS tunnel is created after the adjacency of the eBGP VPNv4 is established.
2. Analyze the logs and configuration.
Troubleshoot the doubtful points through analysis after checking the logs and configuration. Analyze the configuration of peer xx.51.254.17 in the VPNv4 address family. The setting peer xx.51.254.17 group ebgp is found. The VPNv4 address family is configured as follows:
ipv4-family vpnv4
undo policy vpn-target
peer RReflector enable

peer eBGP enable
peer xx.51.254.17 enable
peer xx.51.254.17 group eBGP
peer xx.51.254.17 route-policy CORP-LAN-OUT export
peer xx.51.254.17 route-policy CORP-LAN-IN import
peer xx.51.254.29 enable
peer xx.51.254.29 group eBGP
peer xx.51.254.29 route-policy CORP-LAN-OUT export
peer xx.51.254.29 route-policy CORP-LAN-IN import
View the configuration of group eBGP:
group eBGP external
peer eBGP as-number 44237
peer eBGP description -==C-CRS-IP_Core_BackBone==-
peer eBGP ebgp-max-hop 255
It can be seen that the VPNv4 peers connecting to C’s devices are included in the eBGP group, and the eBGP group is configured with the ebgp-max-hop command.In other words, xx.51.254.17 is configured with eBGP Multihop.
Confirmed by R&D engineers, V300R002C06B325 does not support the creation of MPLS tunnels when directly connected interfaces are configured with eBGP Multihop. To create a tunnel, the device checks whether the peer session is configured with the ebgp-max-hop command. The tunnel can be created only when the ebgp-max-hop command is not configured.
Now, the conclusion can be drawn that the tunnel is not created because the ebgp-max-hop command is configured, and thus leading to the failure to advertise routes.
The verification is as follows:
When the peer 192.168.14.1 is configured with ebgp-max-hop, the tunnel cannot be created.
See Picture 1 and Picture 2.
After running the undo peer 192.168.14.1 ebgp-max-hop command, the tunnel is created,
as shown in Picture 3. 
 
Root Cause
Because the routes cannot be normally advertised, first check the routes in the existing network.
The MPLS tunnels corresponding to the routes are not found. Thus, the routes with the ASBRs of C as the next hops are invalid. That is why these routes fail to be advertised. The reverse MPLS tunnels should be established after the adjacency of eBGP VPNv4 is formed.
Through step-by-step analysis and upon confirmation by R&D engineers, the cause is finally found out. V300R002C06B325 does not support the creation of MPLS tunnels when eBGP Multihop is configured on the peers created through directly connected interfaces. To create a tunnel, the device checks whether the peer session is configured with the ebgp-max-hop command. The tunnel can be created only when the ebgp-max-hop command is not configured.
Now it is believed that the tunnels are not created because the ebgp-max-hop command is configured. Then the routes are invalid and cannot be preferentially advertised to other VPNv4 peers. 
 
Suggestions
Workaround: On the existing network, when VPNv4 peers are created through directly connected interfaces between OptionB ASBRs, run the undo peer *.*.*.* ebgp-max-hop command to disable eBGP Multihop.
Solution:
This problem is caused by the mechanism of V300R002C06B325. It is recommended that you verify the features in advance if the upgrade involves two versions that are not successive. 
 

END