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

Abnormality in Advertising and Removing Routes When the NE40 Is Used to Deploy CE Dual Homing on the HoVPN

Publication Date:  2012-07-27 Views:  41 Downloads:  2
Issue Description
For the networking diagram, see the appendix. In the dual homing of the HoVPN, the same RD number is configured on the UPE and the SPE and the SPE works as the route reflector. The next-hop attributes of the routes advertised by the SPE to PE are modified so that all routes lead to the same next hop.
Fault 1: There shall be two next hops (111 and 110) at PE109. But the BGP private routing table of the PE109 shows that there is only one BGP private route with 111 as the next hop.
Fault 2: When the private route on the SPE111 is removed, the service cannot be switched to the SPE110 and thus interrupted. 
 
Alarm Information
Null
Handling Process
For fault 1:
There are two private routes on the PE110. One is the BGP private route learnt form the UPE111, and the other is the direct route coming from CE. The BGP private routing table is as follows:
[110]disp bgp vpnv4 all routing-table 110.111.1.0 24
Total routes of Route Distinguisher(500:1): 1
BGP routing table entry information of 110.111.1.0/24:
Label information (Received/Applied): 19456/19458
From: 111.111.111.111 (111.111.111.111)
Original nexthop: 111.111.111.111
Ext-Community: <1 : 1>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, intern
al, best, pre 255
Advertised to such 1 peers:
109.109.109.109 (the BGP private route that the SPE110 learns from the UPE111 is advertised to the PE109)

Total routes of vpn-instance vpna: 2
BGP routing table entry information of 110.111.1.0/24:
Imported route.
Label information (Received/Applied): NULL/19456
From: 0.0.0.0 (0.0.0.0)
Original nexthop: 110.111.1.1
Ext-Community: <1 : 1>
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, pre 0
Advertised to such 1 vpnv4 peers:
109.109.109.109 (the SPE110 advertises its direct route to the PE109)

BGP routing table entry information of 110.111.1.0/24:
Label information (Received/Applied): 19456/NULL
From: 111.111.111.111 (111.111.111.111)
Relay Nexthop: 0.0.0.0 (the next hop is the router itself)
Original nexthop: 111.111.111.111
Ext-Community: <1 : 1>
AS-path Nil, origin incomplete, MED 0, localpref 100, pref-val 0, valid, intern
al, pre 255
Not advertised to any peer yet
[110]
For fault 2:
(1) The VPN-bound interface on the UPE111 is shut down.
[111-Ethernet7/0/2] shutdown
(2) View the BGP private routing table on the SPE110:
[110]disp bgp vpnv4 all routing-table 110.111.1.0 24
Total routes of vpn-instance vpna: 1
BGP routing table entry information of 110.111.1.0/24:
Imported route.
Label information (Received/Applied): NULL/19456
From: 0.0.0.0 (0.0.0.0)
Original nexthop: 110.111.1.1
Ext-Community: <1 : 1>
AS-path Nil, origin incomplete, MED 0, pref-val 0, valid, local, best, pre 0
Advertised to such 1 vpnv4 peers:
109.109.109.109
(3): View the BGP private routing table on the PE109:
[109]disp bgp vpnv4 all routing-table 110.111.1.0 24

You can find the solution based on the cause analysis and the fault-location process. Because the VPNV4 routes are distinguished from the RD numbers in the VPN, destination addresses, or masks, the private routes can be distinguished by changing the RD numbers in the VPN. The relevant networking tests in the lab prove that the fault can be fixed. 
 
Root Cause
For fault 1:
When the SPE110 sends the BGP private route to the PE109, the SPE110 sends the direct routes first to the PE109 because the cost is less. Later the BGP private route learnt from the UPE111 is sent from the UPE111 to the PE109 (the SPE110 may spend some time on learning the route from the UPE111). When the SPE110 sends the private routes to the PE109, it modifies the next-hop attributes to the same. The destination addresses, masks, and RD numbers of the two private routes are the same, but we need to distinguish the BGP private routes from the RD numbers, destination addresses, masks, and peer information. That is why the fault occurs: the BGP private route later learnt from the UPE111 covers the direct route earlier coming from CE, and thus the routing table of the PE109 shows that the SPE110 sends one BGP private route learned from the UPE111 only.
For fault 2:
When the VPN-bound interface is shut down on the UPE111, the UPE111 sends a message immediately to inform the SPE110 to remove the BGP private route learnt form the UPE111. Receiving the message, the SPE110 removes the he BGP private route learnt form the UPE111 and views the routing information from the PE rather than the route information from each VPN. Therefore, although there is still one direct route on the SPE110, the SPE110 informs the PE109 to remove the BGP private route from the SPE110 to the PE109 because the SPE110 fails to perform the cross-table query. There is still one direct route from CE on the SPE110, but the direct route is not re-advertised to the PE109, and thus the routing table of the PE109 shows that the BGP private route of the PE109 is null. 
 
Suggestions
In the common CE dual homing, the RD number does not matter. The RD number matters when there is a route reflector (SPE is a special route reflector) and Option B. The VPN route structure of the VRP3 temporarily constitutes the routing table based on the specific VPN of the RD number. The VPN route structure of the VRP5 temporarily constitutes the routing table based on the VPNV4 and the local VPN-instance. Pay attention to the RD planning and take the features of the devices into consideration for the similar networking. 

END