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

Routing or Service Failure Caused by an Incorrect Routing Policy on the NE80

Publication Date:  2012-07-27 Views:  33 Downloads:  0
Issue Description
1. Network diagram and description
AR28-3
|
NE40-A---------NE40-B
| |
NE80-A---------NE80-B
\ / |
\ / |
AR28-1 AR28-2
In the BGP MPLS VPN, the NE40s and NE80s are PEs and the AR28s are CEs. Multiple OSPF instances are run between AR28-1/AR28-2 and NE80-A/NE80-B. AR28-1 and AR28-2 are both in Area 203.
2. Symptom:
The loopback address on AR28-2 and the address of the attached service network segment cannot be pinged from AR28-3. The business hall connected to AR28-2 cannot carry out services. The ping results show that the IP addresses of the packets arriving at AR28-1 are unreachable. 

 
Alarm Information
 Null 
Handling Process
1. Perform the tracert command for the service network segment address of AR28-2 on AR28-3. It is found that the last reachable hop AR28-1 and the penultimate hop is NE80-A. Thus, it can be confirmed that routing is abnormal.
2. View the service network segment BGP VPNv4 route of AR28-2 from NE80-B. It is found that the route is learned from a BGP peer, and is not locally redistributed and is not advertised to other BGP peers. Thus, it can be confirmed that route learning is abnormal.
Total routes of vpn-instance YH-YYT-VPN: 1
BGP routing table entry information of 10.6.141.0/27:
Label information (Received/Applied): 19577/NULL
From: 10.4.255.254 (10.4.255.254)
Relay Nexthop: 0.0.0.0
Original nexthop: 10.4.255.234
Ext-Community:RT <64512 : 150>, <0 : 0>, <10.4.254.35 : 0>, <0.0.0.203 : 256>
Convergence Priority: 0
AS-path Nil, origin incomplete, MED 152, localpref 100, pref-val 0, valid, internal, pre 255
Originator: 10.4.255.234
Cluster list: 0.0.0.100
Not advertised to any peer yet
3. View the OSPF cost values of all links. It is found that they are all set to the defaults. Therefore, the problem is not related to the settings of the OSPF costs.
4. View the routing policy for OSPF redistribution into BGP on NE80-B. It is found that the inbound interface S5/1/5 on AR28-2 is set to S15/1/5 by mistake. As a result, service routes of AR28-2 cannot be redistributed into BGP VPNv4.
route-policy ospf2bgp permit node 340
if-match interface Serial15/1/5:0
if-match ip-prefix ChangPingHuiLongGuanDaJieyyt
apply local-preference 150
5. After S15/1/5 is changed to S5/1/5 in the routing policy, the failure does not exist. 

 
Root Cause
 1. Judged from the symptom, the address of the service network segment of AR28-2 cannot be pinged because ping packets are incorrectly redirected to AR28-1 and a firewall, which allows only the packets whose source addresses are within the service network segment to pass through, is enabled in the outbound direction of the uplink interface on AR28-1.
2. It can be determined that the service network segment routes of AR28-2 are advertised by NE80-A. Normally, the service network segment routes of AR28-2 should be advertised by NE80-B.
3. The reason why the service network segment routes of AR28-2 are advertised by NE80-A may be:
a. AR28-1, AR28-2, NE80-A, and NE80-B are all in the same area of the same OSPF process. If the OSPF cost between the AR28-2 and the NE80-B is greater than the sum of the OSPF costs between AR28-2 and AR28-1 and between AR28-1 and NE80-A, a failure may occur.
b. If NE80-B fails to redistribute OSPF routes of AR28-2 into BGP VPNv4, NE80-A will redistribute the OSPF routes learned from AR28-2 into BGP. Thus a failure may occur. 
 
Suggestions
 In the case of routing failure, first analyze differences between the routing path in trouble and the one in the normal state, and then find the cause by following the clues. 

END