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>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
Knowledge Base

BGP MPLS VPN Services Are Interrupted on the NE40E

Publication Date:  2018-09-26  |   Views:  431  |   Downloads:  0  |   Document ID:  EKB1001881258

Contents

Issue Description

1. The networking is as follows:


2. PE1 is an NE80E, and PE2 is an NE40E-X8. A BGP peer relationship is set up between the two PEs. Each PE is connected to several CEs. The services on the network segment (10.128.159.128/25) of vpna on CE1 and CE3 are interrupted.

3. The key configurations of PE1 are as follows:

 #
ip vpn-instance vpna
     ipv4-family
  route-distinguisher 100:1
  vpn-target 100:1 export-extcommunity
  vpn-target 100:1 200:1 import-extcommunity
#
ip vpn-instance vpnb
ipv4-family
  route-distinguisher 200:1
  vpn-target 200:1 export-extcommunity
      vpn-target 200:1 import-extcommunity

Handling Process

1. Most services of vpna are normal, and services on only one network segment are interrupted. Therefore, it can be determined that the BGP peer, MPLS, and MPLS LPD between the two PEs are normal. In this case, check the VPN routes of the network segment.

2. On PE1, check the routes of vpna. It turns out that PE1 has learned the route to CE3. On PE2, check the routes of vpna. It turns out that PE2 has learned the route to the service network segment (10.128.159.128/25). The CEs are non-Huawei devices and their networks are complex. As a result, it is difficult to locate the fault on the CE sides. The customer reports that the other service network segment (10.128.159.0/25) is normal. A tracert operation from PE2 to 10.128.159.1 successfully traces the CE network, with PE1 as the first hop, but in the tracert operation from PE2 to 10.128.159.129, even the first hop cannot be traced.

3. Check whether the routes learned in the routing table are correct. On PE1, check the VPN routes of 10.128.159.0/25 and 10.128.159.128/25. The routes are learned from the OSPF neighbor CE1, and the cost values of the two routes are the same.

[PE1]dis ip routing-table vpn-instance vpna
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface
        10.128.159.0/25             O_ASE   150  15           D   1.1.13.2        GigabitEthernet0/0/1
        10.128.159.128/25        O_ASE   150  15           D   1.1.13.2        GigabitEthernet0/0/1

However, the cost values of the two routes queried on PE2 are different.

        [PE2]dis ip routing-table vpn vpna
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
   Destination/Mask       Proto     Pre  Cost      Flags NextHop         Interface
    10.128.159.0/25        IBGP      255  15         RD   1.1.1.1         GigabitEthernet0/0/0
10.128.159.128/25   IBGP       255  0          RD   1.1.1.1         GigabitEthernet0/0/0

The two PEs are directly connected, and the two VPN routes pass through the same path. In this case, the cost values of the two routes learned on PE2 are supposed to be the same. Does PE2 have two routes to the 10.128.159.128/25 network segment? Further check the VPN routes received by PE2.

[PE2]disp bgp vpnv4 vpn-instance vpna routing-table
BGP Local router ID is 2.2.2.2
Status codes: * - valid, > - best, d - damped,
               h - history,  i - internal, s - suppressed, S - Stale
               Origin : i - IGP, e - EGP, ? - incomplete
VPN-Instance vpna, Router ID 2.2.2.2:
Total Number of Routes: 719
      Network            NextHop        MED        LocPrf    PrefVal Path/Ogn
*>i  10.128.159.128/25    1.1.1.1           0          100        0      ?
* i                                         1.1.1.1          15         100        0      ?

It turns out that PE2 indeed has two routes to the 10.128.159.128/25 network segment and that the route with a smaller cost value is preferred in the routing table. Where does this route come from?

Check the configurations of the two PEs. It is found that the routing table of vpna receives the route of vpnb due to an incorrect RT configuration. Is this route learned from vpnb? Check the vpnb routing table on PE1. It is found that the route to this network segment exists.

[PE1]dis ip routing-table vpn-instance vpnb
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Destination/Mask    Proto   Pre  Cost      Flags NextHop         Interface
10.128.159.128/25  Static   60   0          RD   1.1.14.2        GigabitEthernet0/0/2

To further check whether the route is a vpnb route, check the detailed information about the route on PE2. The label value of the route is 1028. According to the label value comparison, it can be determined that the route to the 10.128.159.128/25 network segment learned by PE2 is imported from vpnb rather than a route of vpna.

[PE2]dis ip routing-table vpn-instance vpna 10.128.159.128 verbose
Route Flags: R - relay, D - download to fib
------------------------------------------------------------------------------
Routing Table : vpna
Summary Count : 1
Destination: 4.4.4.0/24
     Protocol: IBGP             Process ID: 0
   Preference: 255                    Cost: 0
      NextHop: 1.1.1.1           Neighbour: 1.1.1.1
        State: Active Adv Relied       Age: 00h12m44s
          Tag: 0                  Priority: low
        Label: 1028                QoSInfo: 0x0
   IndirectID: 0x3             
RelayNextHop: 1.1.12.1          Interface: GigabitEthernet0/0/0
     TunnelID: 0x1                   Flags: RD

On PE1, the label values allocated to vpna and vpnb are as follows:

<PE1>dis mpls lsp verbose
-------------------------------------------------------------------------------
                 LSP Information: BGP  LSP
-------------------------------------------------------------------------------
  No                  :  3
  VrfIndex            :  vpna
  RD Value            :  0:0
  Fec                 :  4.4.4.0/24
  Nexthop             :  -------
  In-Label            :  1026
  Out-Label           :  NULL
  In-Interface        :  ----------
  Out-Interface       :  ----------
  LspIndex            :  4098
  Token               :  0x0
  LsrType             :  Egress
  Outgoing token      :  0x0
  Label Operation     :  POP
  Mpls-Mtu            :  ------
  TimeStamp           :  1475sec
  FrrToken            :  0x0
  FrrOutgoingToken    :  0x0
  BGPKey              :  -------
  BackupBGPKey        :  -------
  FrrOutLabel         :  -------

  No                  :  5
  VrfIndex            :  vpnb
  RD Value            :  0:0
  Fec                 :  4.4.4.0/24
  Nexthop             :  -------
  In-Label            :  1028
  Out-Label           :  NULL
  In-Interface        :  ----------
  Out-Interface       :  ----------
  LspIndex            :  4100
  Token               :  0x0
  LsrType             :  Egress
  Outgoing token      :  0x0
  Label Operation     :  POP
  Mpls-Mtu            :  ------
  TimeStamp           :  1480sec
  FrrToken            :  0x0
  FrrOutgoingToken    :  0x0
  BGPKey              :  -------
  BackupBGPKey        :  -------
 FrrOutLabel         :  -------

Root Cause

The route to the same destination network segment in another VPN is imported because an RT configuration is incorrect.

Solution

1. Delete the export RT of vpnb from the RT of vpna so that vpna does not learn the routes of vpnb.

2. Re-plan the service routes of vpna to ensure that the routing network segments of the two VPNs do not conflict.

Suggestions

In a BGP MPLS VPN scenario, VPN route learning can be flexibly controled based on RT values. RT values can be set as required to implement interworking between different VPNs. However, different VPNs may use the same private network segment. Therefore, exercise caution when planning service network segments on the network where interworking between different VPNs is required, and ensure that the routes of the VPNs are unique. Otherwise, address conflicts may occur.