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 Core Routers of the MAN Failed to Advertise BGP Routes Normally Due to the Improper AS Configuration in the Routing Policy

Publication Date:  2012-07-27 Views:  61 Downloads:  2
Issue Description
For the networking of a certain province, see the appendix.
Version of the device: V300R002C01B599
The neighborship was established between the core network of City A and the provincial network and between the core network of City B and the provincial network through EBGP. The traffic models of the two core routers, NE80s, in the two cities adopted the master/slave mode respectively.
Incoming traffic control: AS is configured as follows for the advertisement of MAN routes on the slave core router:
route-policy sec_route permit node 10
apply as-path 64693
bgp 64693
peer 219.158.2.168 as-number 4837
peer 219.158.2.168 next-hop-local
peer 219.158.2.168 route-policy sec_route export
Outgoing traffic control: Controlled on the provincial network devices with the MED value.
The MAN users in City B reported network disconnection. On the provincial network device, it was found that the network segments of the users in City B were advertised by the slave core router in City A. 

 
Alarm Information
Null
Handling Process
When analyzing the device configuration, the engineer found that the slave NE80 in City A adopted the outbound policy to advertise the BGP routes to the provincial backbone router. In the outbound policy, the apply as-path command ending with digits indicates replacement. If additive follows the digits in the command, an AS number is added to the existing AS-Path. Currently, the MAN in City A adopts the replacement policy.
Routing after the preceding policy is configured: The AS number of the MAN routes in City A advertised to the provincial backbone is 64697. After the provincial backbone advertises the routes to City B, the AS-Path changes to (4837, 64697). After receiving the routes, the master NE80 in City B advertises the routes to its own IBGP peer, the slave NE80 in City B, which then preferentially selects the routes because of the small MED value. In addition, according to the BGP route advertisement principle, the routes received from IBGP, if preferentially selected, are sent to the EBGP peer, the provincial backbone router directly connected to the slave NE80 in City B. Because AS-Path replacement is configured on the outbound interface, the original (4837, 64697) path changes to (64693, 64693). After learning this route, the provincial backbone cannot find its own AS number in the AS-Path. Then it directly advertises the route. That is why the preceding problem arises.
Solution: Change apply as-path 64693 in the policy to apply as-path 64693 additive. 

 
Root Cause
The normal routing is as follows: the master core router of City B advertises routes--------provincial backbone-------provincial backbone----------master core router of City A--------slave core router in City A-----------provincial backbone. The slave NE80 in City A learns the MAN routes in City B from the provincial backbone (its EBGP peer) and the master core router in City A. This slave NE80 in City A preferentially selects the MAN routes in City B advertised by the master NE80 in City A because the MED value control is implemented on the provincial backbone. In this case, the slave NE80 of City A advertises the MAN routes in City B to the provincial backbone again (its EBGP peer). In normal circumstances, the provincial backbone finds its own AS number within the AS-Path and refuses to accept the MAN routes in City B. Thus, it discards the routes and accepts only MAN routes in City A. 

 
Suggestions
Null

END