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

MPLS VPN Services of NE40 Do not Communicate because MBGP Uses Physical Interface to Set up Connection

Publication Date:  2012-07-27 Views:  31 Downloads:  0
Issue Description
Topology: 
NE40A-----NE40B------NE40D
      \             |              /
        \           |           /
             NE40C
NE40 is at VRP3.10-2226.
NE40A, NE40B, NE40C and NE40D are in the same AS (AS100); both NE40B and NE40C serve as RR, and NE40A and NE40D serve as client. Both NE40A and NE40D have set up MBGP with NE40B and NE40C. DCN hosts carried by MPLS VPN and under both NE40A and NE40D cannot ping to the peer. 
Alarm Information
Null
Handling Process
1. According to the configurations of both NE40B and NE40C, they are not configured with VPN route filtration. 
2. According to the configurations of both NE40A and NE40D, they are not configured with ACL to filter packets. 
3. Executing "dislay mpls lsp vpn-instance dcn-oa" command helps find that VPN route has not been allocated with tag. 
4. According to Configuration of NE40A (display ip route vpn-instance dcn-oa), it is found that VPN route has been learned, indiicating that MBGP has transmitted the route over successfully. 
5. According to the checkup,  the next hop of VPN route is 10.0.0.1.  The route mask of the public network route of 10.0.0.1 is 30-bit, not 32-bt . The is the root of the problem. 
6. According to the configurations of NE40D, NE40B, and NE40C, it is found that both NE40D and other two RRs use the interface to set up MBGP connection. However, NE40 at Release 2226 could only use the IP address of 32-bit to set up connection in establishment of MP-IBGP, not the IP address of non-32-bit physical interface. 
7. Change the configurations of NE40D, NE40B and NE40C, and they use the loopback interface of 32-bit mask to set up connection. Services of NE40A and NE40D are normal then. 
Root Cause
The common factors for blocked VPN services include: 
1. Public network routes do not communicate. 
2. Public network routes do communicate, but there are no the routes with 32-bit mask from the peer. 
3. LSP of public network does not set up. 
4. VPN route is not learned. 
5. Packets are filtered by ACL. 
Suggestions
After consultation, NE40 issues tag of private network for routes with 32-bit mask, and it ignores the routes with more or less than 32-bit mask. Although the equipment has LSP of public network, LSP for private network is not created. 

END