Login
- Table of Contents
- Related Documents
-
| Title | Size | Download |
|---|---|---|
| 04-MPLS L3VPN Troubleshooting Guide | 378.88 KB |
Troubleshooting MPLS
MPLS L3VPN issues
L3VPN traffic disrupted
Symptom
Private traffic forwarded through the MPLS L3VPN network gets disrupted.
Common causes
The following are the common causes of this type of issue:
· The next hop in the private network route is unreachable.
· Incorrect routing policy configuration prevents the route from being advertised and received.
· Private routes cannot be advertised because of insufficient label resources.
· The private network route does not point to a tunnel.
· Mismatch between export and import RTs prevents the device from learning routes into the private routing table.
· Incoming routes are discarded because the maximum number of routes has been reached.
Troubleshooting flow
Figure 1 shows the troubleshooting flowchart.
Figure 1 Troubleshooting flowchart for L3VPN traffic disruption
Solution
1. Verify that the route is the optimal one.
Execute the display bgp routing-table vpnv4 or display bgp routing-table vpnv6 command to verify that the BGP route to the VPNv4 or VPNv6 peer is optimal.
A route is optimal if it contains the greater than (>) symbol. The route to 100.1.2.0/24 in the following command output is an example of optimal routes.
<Sysname> display bgp routing-table vpnv4
BGP local router ID is 1.1.1.9
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e - external
a – additional-path
Origin: i - IGP, e - EGP, ? - incomplete
Total number of VPN routes: 8
Total number of routes from all PEs: 8
Route distinguisher: 100:1(vpn1)
Total number of routes: 6
Network NextHop MED LocPrf PrefVal Path/Ogn
* > 1.1.1.0/24 1.1.1.1 0 32768 ?
* 1.1.1.2/32 1.1.1.1 0 32768 ?
* > 100.1.2.0/24 100.1.1.1 0 100 0 400i
Take action depending on the command output.
¡ If the route is not optimal, use the display mpls lsp command to verify that the MPLS LFIB has an entry for the route of interest. If an LFIB entry is not available, enable MPLS and LDP on the public network interface towards the remote PE by executing the mpls enable and mpls ldp enable commands, respectively. This ensures that VPNv4 routes can be pointed to public LSPs. If the entry exists, proceed to step 2.
¡ If the route is optimal, proceed to step 2.
2. Verify the connectivity to the next hop in the private route.
Execute the display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ] command on the local PE check for the private route advertised by the remote PE. Specify the private route prefix for the ipv4-address argument.
¡ If the route does not exist, check for CE route advertisement issues. On the remote PE, execute the display bgp routing-table vpnv4 peer advertised-routes or display bgp routing-table vpnv6 peer advertised-routes command to verify that it has advertised private routes correctly to the local PE.
<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes
Total number of routes: 6
BGP local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e - external
a - additional-path
Origin: i - IGP, e - EGP, ? - incomplete
Route distinguisher: 1:1
Total number of routes: 3
Network NextHop MED LocPrf Path/Ogn
* >e 1.1.1.1/32 10.1.1.2 0 100 20i
* >e 7.7.7.7/32 10.1.1.2 0 100 20?
* >e 10.1.1.0/24 10.1.1.2 0 100 20?
If the private route does not exist, proceed to step 3.
¡ If the private route exists, verify that its next hop is reachable and its state is active.
Check the State field. If its value is valid, the route is active. Check the Original nexthop field. If it contains next hop information, the next hop in the route is reachable.
- If the private route is inactive, use the display ip
routing-table vpn-instance vpn-instance-name ip-address command to check the IP routing table for a route to the BGP next
hop in the Original nexthop field.
If such a route does not exist, the next hop in the private route is
unreachable. Then, check the routing configuration for the public network
between PEs.
If such a route exists, the BGP route next hop is reachable. Proceed to step
(3).
- If the private route is active, proceed to step 3.
<sysname> display bgp routing-table vpnv4 6.0.0.9 32
BGP local router ID: 4.0.0.9
Local AS number: 200
Route distinguisher: 103:1
Total number of routes: 1
Paths: 1 available, 1 best
BGP routing table information of 6.0.0.9/32:
From : 3.0.0.9 (3.0.0.9)
Rely nexthop : 20.0.2.1
Original nexthop: 3.0.0.9
OutLabel : 24128
Ext-Community : <RT: 100:1>
RxPathID : 0x0
TxPathID : 0x0
AS-path : 300 103
Origin : igp
Attribute value : pref-val 0
State : valid, external, best
IP precedence : N/A
QoS local ID : N/A
Traffic index : N/A
Tunnel policy : tp1
Rely tunnel IDs : 2
3. Verify that the routing policy is correct.
Execute the display current-configuration configuration bgp command both the route sender and receiver. Check the BGP configuration for import and export routing policies policies.
<sysname> display current-configuration configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 100
peer 3.3.3.3 as-number 100
peer 3.3.3.3 connect-interface LoopBack1
#
address-family vpnv4
peer 3.3.3.3 enable
peer 3.3.3.3 route-policy in import
peer 3.3.3.3 route-policy out export
#
return
If the devices at both ends have import and export routing policies, check the policies for incorrect settings that filter out the private route.
If the devices do not have import or export routing policies, or if the routing policies do not filter out the private route, proceed to step 4.
4. Verify that the route can recurse to a tunnel.
On the remote PE (the route sender), execute the display bgp routing-table vpnv4 ipv4-address [ mask | mask-length ] command to verify that the VPNv4 route can recurse to the tunnel.
If the command output contains the Rely tunnel IDs, the route can recurse to the tunnel.
¡ If the route cannot recurse to the tunnel, see the troubleshooting procedure for the LDP LSP up failure issues.
¡ If the route recurses to a tunnel, proceed to step 5.
<sysname> display bgp routing-table vpnv4 6.0.0.9 32
BGP local router ID: 4.0.0.9
Local AS number: 200
Route distinguisher: 103:1
Total number of routes: 1
Paths: 1 available, 1 best
BGP routing table information of 6.0.0.9/32:
From : 3.0.0.9 (3.0.0.9)
Rely nexthop : 20.0.2.1
Original nexthop: 3.0.0.9
OutLabel : 24128
Ext-Community : <RT: 100:1>
RxPathID : 0x0
TxPathID : 0x0
AS-path : 300 103
Origin : igp
Attribute value : pref-val 0
State : valid, external, best
IP precedence : N/A
QoS local ID : N/A
Traffic index : N/A
Tunnel policy : tp1
Rely tunnel IDs : 2
5. Check for export RT and import RT mismatches. A mismatch between import and export RTs can prevent routes from being learned into private routing tables.
Execute the display bgp routing-table vpnv4 and display current-configuration configuration vpn-instance commands on the route sender (the local PE) and route receiver (the remote PE). Check for a mismatch between the export RT on the local PE and the import RT on the remote PE for the VPN instance. An RT mismatch can prevent the route from being learned into the remote VPN instance after it is sent to the remote PE.
Execute the display bgp routing-table vpnv4 and display ip extcommunity-list commands on the local PE to verify that the export RT for the VPN instance is not filtered out. If it is filtered out, the PE does not advertise the routes that match the export RT.
¡ If the export and import RTs do not match, execute the vpn-target command to reconfigure their settings for the VPN instance.
¡ If the routing policy filters out the export RT, execute the apply extcommunity rt command in routing policy view to include the export RT to the list of RT attributes set for the matching routes.
¡ If the export and import RTs match, or if the export RT is not filtered out by the routing policy, proceed to step 6.
Verify that the route carries the correct export RT attributes.
<sysname> display bgp routing-table vpnv4 6.0.0.9 32
BGP local router ID: 4.0.0.9
Local AS number: 200
Route distinguisher: 103:1
Total number of routes: 1
Paths: 1 available, 1 best
BGP routing table information of 6.0.0.9/32:
From : 3.0.0.9 (3.0.0.9)
Rely nexthop : 20.0.2.1
Original nexthop: 3.0.0.9
OutLabel : 24128
Ext-Community : <RT: 100:1>
RxPathID : 0x0
TxPathID : 0x0
AS-path : 300 103
Origin : igp
Attribute value : pref-val 0
State : valid, external, best
IP precedence : N/A
QoS local ID : N/A
Traffic index : N/A
Tunnel policy : tp1
Rely tunnel IDs : 2
Verify that the BGP extended community attribute list is correct.
<sysname> display ip extcommunity-list 1
Extended Community List Number 10
Deny rt: 100:1
Extended Community List Number 20
Permit rt: 200:1
Verify that the local device has correct import RT settings.
<sysname> display current-configuration configuration vpn-instance
#
ip vpn-instance vpn1
route-distinguisher 1:1
vpn-target 100:1 import-extcommunity
vpn-target 100:1 export-extcommunity
#
6. Check for insufficient MPLS label resources.
Execute the display mpls interface command on the route sender (the local PE) to verify that MPLS is enabled on the public network interface connected to the remote PE.
¡ If the command output contains the public interface connected to the remote PE, MPLS is enabled on the interface.
¡ If the command output does not contain the public network interface connected to the remote PE, execute the mpls enable command in interface view to enable MPLS on it.
<Sysname> display mpls interface
Interface Status MPLS MTU
GE0/0/1 Up 1500
GE0/0/2 Up 1500
Execute the display bgp routing-table vpnv4 advertise-info command to identify the state of label allocation for advertised routes.
¡ If the Inlabel field in the command output for a route is empty, the system might have failed to allocate a label to the route because of insufficient label resources. To conserve label resources:
- Execute the apply-label per-instance command to enable allocation of one label for the entire VPN instance.
- Use route summarization to reduce the number of routes.
- Execute the mpls max-label command in system view to increase the number of labels that the device can allocate.
¡ If the Inlabel field in the command output has a reasonable value, label resources are sufficient and a label has been allocated to the route. Proceed to step 7.
<Sysname> display bgp routing-table vpnv4 10.1.1.0 24 advertise-info
BGP local router ID: 1.1.1.9
Local AS number: 100
Route distinguisher: 100:1
Total number of routes: 1
Paths: 1 best
BGP routing table information of 10.1.1.0/24(TxPathID:0):
Advertised to VPN peers (1 in total):
3.3.3.9
Inlabel : 1279
7. Check for insufficient route entry resources.
Execute the display bgp peer vpnv4 log-info command to view the log for the BGP peer. If the command output contains the Cease/maximum number of VPNv4 prefixes reached message, the number of IPv4 VPN routes has reached the limit.
<Sysname> display bgp peer vpnv4 1.1.1.1 log-info
Peer : 1.1.1.1
Date Time State Notification
Error/SubError
06-Feb-2013 22:54:42 Down Send notification with error 6/1
Cease/maximum number of VPNv4 prefixes reached
In addition, if the number of routes has exceeded the limit, you would receive log messages similar to the following sample messages:
BGP/4/BGP_EXCEED_ROUTE_LIMIT: BGP default.vpn1: The number of routes (101) from peer 1.1.1.1 (IPv4-UNC) exceeds the limit 100.
BGP/4/BGP_REACHED_THRESHOLD: BGP default.vpn1: The ratio of the number of routes (3) received from peer 1.1.1.1 (IPv4-UNC) to the number of allowed routes (2) has reached the threshold (75%).
¡ If the number of routes exceeds the limit, execute the peer route-limit command in VPNv4 address family view or VPNv6 address family view on the route receiver to increase the maximum number of routes allowed to receive from its peers.
¡ If the number of routes does not exceed the limit, proceed to step 8.
8. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
Module name: BGP4-MIB
· bgpBackwardTransition (1.3.6.1.2.1.15.7.2)
Log messages
· BGP_EXCEED_ROUTE_LIMIT
· BGP_REACHED_THRESHOLD
L3VPN private route flapping
Symptom
The private routes received from a remote PE flap on the local PE.
Common causes
The following are the common causes of this type of issue:
· Public route flapping.
· LDP LSP flapping.
· Interface flapping.
Troubleshooting flow
Figure 2 shows the troubleshooting flowchart.
Figure 2 Troubleshooting flowchart for L3VPN private route flapping issues
Solution
1. Check for public route flapping issues.
a. Identify the route type.
Execute the display ip routing-table command to identify the route type.
Take the following command output for
example.
The Proto field displays IS_L1, indicating that the route type is IS-IS.
The Interface field displays Tun1, indicating that LDP over MPLS TE is
deployed.
<Sysname> display ip routing-table 1.1.1.1
Summary count : 1
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.1/32 IS_L1 15 10 1.1.1.1 Tun1
b. Check for the route flapping issue.
Determine whether the route is flapping based on the route type. Take an IS-IS route for example. Execute the display ip routing-table protocol isis command to view route information. If the route continuously alternates between the visible and invisible states, route flapping has occurred.
- If the route is flapping, see the troubleshooting procedures for the OSPF neighbor down, OSPFv3 neighbor down, or IS-IS route flapping issue.
- If the route is not flapping, proceed to step 2.
2. Check for the LDP LSP flapping issue.
As a best practice, execute the display mpls ldp peer command every second for 5 to 10 times. Examine the State field in the command output. If the value changes between Operational and other states, the LDP session is flapping, causing LDP LSP flapping.
¡ If the LDP LSP is flapping, see the procedure for troubleshooting the LDP LSP flapping issue.
¡ If the LDP LSP is not flapping, proceed to step 3.
<Sysname> display mpls ldp peer
VPN instance: public instance
Total number of peers: 1
Peer LDP ID State Role GR AUT KA Sent/Rcvd
1.1.1.1:0 Operational Active Off None 298/298
3. Check for the interface flapping issue.
Execute the display interface brief command, and then examine the Link and Protocol fields in the command output. If the values in both fields are Up, the interface is up. If otherwise, the interface is down. If the interface state continuously alternates between up and down, the interface is flapping.
¡ If the interface is flapping, see the troubleshooting procedure for the interface not up issue.
¡ If the interface is not flapping, proceed to step 4.
<Sysname> display interface gigabitethernet 0/0/1 brief
Brief information on interfaces in route mode:
Link: ADM - administratively down; Stby - standby
Protocol: (s) – spoofing
Interface Link Protocol Primary IP Description
GE0/0/1 UP UP --
4. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
VPN route exchange failure between PEs
Symptom
PEs cannot exchange VPNv4 or VPNv6 routes.
Common causes
The following are the common causes of this type of issue:
· Public IGP routes are not advertised.
· No public LSPs are available.
· BGP peer relationships are not established.
· VPNv4 or VPNv6 routes are not learned.
Troubleshooting flow
Figure 3 shows the troubleshooting flowchart.
Figure 3 Troubleshooting flowchart for private route exchange failure between PEs
Solution
1. Verify that an IGP route is available.
Execute the display ip routing-table command to verify that the local PE has a subnet route to the LSR ID (typically, the IP address of a Loopback interface) of the remote PE.
<Sysname> display ip routing-table 1.1.1.1
Summary count : 1
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.2/32 IS_L1 15 10 1.1.1.1 LoopBack1
¡ If such a route does not exist, make sure an IGP protocol is enabled on the Loopback interface and the public network interface on each PE. This ensures correct advertisement of subnet routes between them.
¡ If such a route exists, proceed to step 2.
2. Verify that a public LSP is available.
Execute the display mpls lsp command to check for a public LSP to the remote PE's Loopback interface.
¡ If such an LSP is not present, enable MPLS and MPLS LDP on the public network interface to ensure the establishment of a public LSP.
¡ If such an LSP exists, proceed to step 3.
<Sysname> display mpls lsp
FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX
1.1.1.2/32 LDP -/1049 GE0/0/1
<Sysname> display mpls lsp
FEC Proto In/Out Label Out Inter/NHLFE/LSINDEX
1.1.1.1/24 LDP -/1051 GE0/0/1
Execute the display mpls ldp peer verbose command to verify that an LDP session has been successfully established.
¡ If the State field in the command output displays anything other than Operational, the LDP session has not been established. To resolve the issue, see the procedure that troubleshoots the failure of a LDP session to come up.
¡ If the State field in the command output displays Operational, the LDP session has been established. Proceed to step 3.
<Sysname> display mpls ldp peer verbose
VPN instance: public instance
Peer LDP ID : 1.1.1.1:0
Local LDP ID : 2.2.2.2:0
TCP Connection : 2.2.2.2:14080 -> 1.1.1.1:646
Session State : Operational Session Role : Active
Session Up Time : 0000:00:14 (DD:HH:MM)
…
3. Verify that a BGP peer relationship has been established.
Execute the display bgp peer vpnv4 to view the BGP VPNv4 peer relationships between PEs, and execute the display bgp peer ipv4 vpn-instance command to view the BGP peer relationships between PEs and CEs.
¡ If a BGP peer relationship is not present, or if the State field does not display Established, the BGP peer relationship has not been established. See the procedure that troubleshoots BGP neighbor establishment failures to resolve the issue.
¡ If the State field displays Established, the BGP peer relationship has been established. Proceed to step 4.
<Sysname> display bgp peer vpnv4
BGP local router ID: 192.168.100.1
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
1.1.1.2 200 13 16 0 0 00:10:34 Established
<Sysname> display bgp peer ipv4 vpn-instance vpn1
BGP local router ID: 1.1.1.1
Local AS number: 100
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
10.1.1.1 65410 5 4 0 1 00:01:19 Established
4. Verify that the private route is operating correctly.
Execute the display ip routing-table vpn-instance command to check for private route issues.
¡ If the mask for the private route is not 32 bits and the route was discovered by a protocol other than BGP, the IP addresses of the Loopback interfaces on the peer PEs are in the same subnet. The device will prefer the direct route over the private route. To resolve this issue, change the IP address of the Loopback interface on each PE and set their mask to 32 bits.
¡ If the private route has a 32-bit mask and was discovered by BGP, the route is correct. Proceed to step 5.
<Sysname> display ip routing-table vpn-instance vpn1
Summary count : 1
Destination/Mask Proto Pre Cost NextHop Interface
1.1.1.0/24 Direct 0 0 1.1.1.1 LoopBack1
5. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
Communication failure between VPN instances with matching RTs
Symptom
The network shown in Figure 4 deploys MPLS L3VPN services. On this network, CE 1 and CE 3 belong to VPN 1, and CE 2 belongs to VPN 2. To enable connectivity between VPN 1 and VPN 2, matching RTs were configured on them.
Despite this, CE 2 cannot ping CE 3 at IP address 3.3.3.3 in a different VPN, even though CE 1 can successfully ping CE 3.
Common causes
In this scenario, CE 1 can ping CE 3 in the same VPN, indicating that the public tunnel for label forwarding in the MPLS backbone network functions correctly. The failure is most likely caused by the IP conflict between interfaces assigned to different VPN instances.
Troubleshooting flow
Figure 5 shows the troubleshooting flowchart.
Solution
1. Check for IP conflict between interfaces on the PE.
Execute the display ip interface brief command on PE 1 to view the IP addresses of interfaces on it.
<Sysname> display ip interface brief
*down: administratively down
(s): spoofing (l): loopback
Interface Physical Protocol IP Address/Mask VPN instance Description
...
GE0/0/1 up up 10.1.1.1/24 vpn1 --
GE0/0/2 up up 10.1.1.1/24 vpn2 --
...
If the interfaces in different VPN instances are assigned IP addresses from different subnets, proceed to step 2.
If two interfaces in different VPN instances on the PE have the same IP address or IP addresses from the same subnet, re-assign an IP address to one of the interfaces. Make sure their IP addresses are from a different subnet. Then, change the IP address of the CE interface connected to the IP-updated PE interface and reconfigure routing between the PE and the CE.
BGP redistributes RT matching routes between the VPN instances. If you assigned the same IP address to interfaces in different VPN instances, the BGP routing table would have two routes for the same destination address. BGP would select the better one of the two routes. Look at the following sample command output:
<Sysname> display bgp routing-table vpnv4
BGP local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e - external
a - additional-path
Origin: i - IGP, e - EGP, ? - incomplete
Total number of VPN routes: 11
Total number of routes from all PEs: 2
Route distinguisher: 1:1(vpn1)
Total number of routes: 6
Network NextHop MED LocPrf PrefVal Path/Ogn
* >e 1.1.1.1/32 10.1.1.2 0 0 20i
* >e 2.2.2.2/32 10.1.1.2 0 0 30i
* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i
* >e 10.1.1.0/24 10.1.1.2 0 0 20?
* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?
Route distinguisher: 2:2(vpn2)
Total number of routes: 5
Network NextHop MED LocPrf PrefVal Path/Ogn
* >e 1.1.1.1/32 10.1.1.2 0 0 20i
* >e 2.2.2.2/32 10.1.1.2 0 0 30i
* >i 3.3.3.3/32 22.22.22.22 0 100 0 40i
* >e 10.1.1.0/24 10.1.1.2 0 0 20?
* e 10.1.1.2 0 0 30?
* >i 30.1.1.0/24 22.22.22.22 0 100 0 40?
In the BGP routing table for VPN 2 (with an RD of 2:2), the optimal route selected based on the AS_PATH attribute for subnet 10.1.1.0 originates from VPN 1. Then, PE 1 will send the traffic intended to be sent from VPN 1 to VPN 2 out of interface GigabitEthernet0/0/1 in VPN 1 instead of interface GigabitEthernet0/0/2 in VPN 2. This will cause an inter-VPN communication failure.
To ensure correct traffic forwarding between two VPN instances, make sure the PE and CE interfaces in one VPN instance are on a different subnet than the PE and CE interfaces in another VPN instance. For example, PE 1 and its attached CE establishes an EBGP session to exchange routes. Use the following procedure to change the IP address of the CE-attached PE interface on PE 1:
a. In system view, execute the interface command to enter the view of the interface associated with the target VPN instance.
b. Execute the ip address command to change the IP address of the target interface.
c. In system view, execute the bgp command to enter BGP instance view.
d. Execute the ip vpn-instance command to enter BGP-VPN instance view.
e. Execute the undo peer command to delete the BGP peer relationships established with the conflicting IP addresses.
f. Execute the peer as-number command to add the CE as an EBGP peer at its new IP address.
g. Execute the address-family ipv4 unicast command to enter BGP IPv4 unicast address family view.
h. Execute the peer enable command to enable BGP to exchange BGP IPv4 unicast routing information with the CE specified as a BGP peer.
Take IP reassignment only for interfaces in VPN 2 for example. On CE 2, perform the following steps:
i. In system view, execute the interface command to enter the view of the interface connected to PE 1.
j. Execute the ip address command to change the IP address of the target interface.
k. In system view, execute the bgp command to enter BGP instance view.
l. Execute the undo peer command to delete the BGP peer relationships established with the conflicting IP addresses.
m. Execute the peer as-number command to add the PE as an EBGP peer at its new IP address.
n. Execute the address-family ipv4 unicast command to enter BGP IPv4 unicast address family view.
o. Execute the peer enable command to enable BGP to exchange BGP IPv4 unicast routing information with the PE specified as a BGP peer.
p. Execute the import-route or network to advertise routing information for the VPN instance.
If the issue persists, proceed to step 2.
2. Collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
PEs unable to learn routes because of VPN route target filtering on the route reflector (RR)
Symptom
The RR does not reflect the MVPN routes, VPNv4 or VPNv6 routes, BGP L2VPN information, VPN Flowspec routes, or EVPN routes announced by one PE to other PEs, as expected.
Common causes
By default, an RR filters MVPN routes, VPNv4 or VPNv6 routes, BGP L2VPN information, VPN Flowspec routes, and EVPN routes based on VPN route targets. The RR adds a route to the routing table only if one of the export RT attributes in the route matches a local import RT. If no match is found, the RR discards the route, without forwarding the route to remote PEs.
Troubleshooting flow
To resolve this issue, disable VPN route target filtering on the RR. Figure 6 shows the troubleshooting flowchart.
Solution
1. Check the configuration for the affected address family. Make sure route target filtering has been disabled by using the undo policy vpn-target command.
a. In BGP instance view, execute the display this command to check the configuration in each address family view for the undo policy vpn-target command. If the command does not exist, proceed to step b. If the command exists, proceed to step 2.
b. Enter the view of the affected address family and execute the undo policy vpn-target to disable VPN route target filtering, allowing the RR to forward routes with mismatching RTs. If the issue persists, proceed to step 2.
2. Collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
A private IP routing table on a PE does not contain routes announced by a remote PE
Symptom
In an IPv4 or IPv6 MPLS L3VPN network, communication failure occurs between CEs because the IP routing table for a VPN instance on a PE lacks private routes to the site attached to a remote PE.
Common causes
The following are the common causes of this type of issue:
· The BGP session with the remote PE is not in Established state.
· The remote PE has not advertised private routes.
· A public tunnel has not been established.
· The local PE discards the private routes sent by the remote PE.
· The private routes advertised by the remote PE are in the local BGP routing table. However, they are not added to the IP routing table for the VPN instance.
Troubleshooting flow
Figure 7 shows the troubleshooting flowchart.
Figure 7 Troubleshooting flowchart for missing routes from remote PEs in a PE's VPN IP routing table
Solution
1. Verify that a BGP peer relationship has been established.
Execute the display bgp peer vpnv4 or display bgp peer vpnv6 command to verify that the local and remote PEs have established a BGP session in Established.
<Sysname> display bgp peer vpnv4
BGP local router ID: 11.11.11.11
Local AS number: 10
Total number of peers: 1 Peers in established state: 1
* - Dynamically created peer
Peer AS MsgRcvd MsgSent OutQ PrefRcv Up/Down State
22.22.22.22 10 82 69 0 2 01:01:28 Established
¡ If the PEs has established a BGP peer relationship, proceed to step 3.
¡ If the PEs has not established a BGP peer relationship, see the BGP session establishment failure troubleshooting procedure in the part for troubleshooting IP routing issues. If the issue persists after the BGP session changes to the Established state, proceed to step 2.
2. Verify that the remote PE has advertised private routes to the local PE.
On the remote PE, execute the display bgp routing-table vpnv4 peer advertised-routes or display bgp routing-table vpnv6 peer advertised-routes command to verify that it has advertised private routes to the local PE.
<Sysname> display bgp routing-table vpnv4 peer 22.22.22.22 advertised-routes
Total number of routes: 6
BGP local router ID is 11.11.11.11
Status codes: * - valid, > - best, d - dampened, h - history,
s - suppressed, S - stale, i - internal, e - external
a - additional-path
Origin: i - IGP, e - EGP, ? - incomplete
Route distinguisher: 1:1
Total number of routes: 3
Network NextHop MED LocPrf Path/Ogn
* >e 1.1.1.1/32 10.1.1.2 0 100 20i
* >e 7.7.7.7/32 10.1.1.2 0 100 20?
* >e 10.1.1.0/24 10.1.1.2 0 100 20?
Route distinguisher: 2:2
Total number of routes: 3
Network NextHop MED LocPrf Path/Ogn
* >e 2.2.2.2/32 10.1.1.2 0 100 30i
* >e 7.7.7.7/32 10.1.1.2 0 100 30?
* >e 10.1.1.0/24 10.1.1.2 0 100 30?
If the information of interest exists, proceed to step 3. If the information of interest does not exist, proceed with the following checks:
a. Execute the display bgp routing-table vpnv4 or display bgp routing-table vpnv6 command on the remote PE to check for the private routes of interest.
- If the information of interest exists, proceed to step b.
- If the information of interest exists, see the IP routing troubleshooting part to check the routing configuration between the PE and the CE. Many routing protocols are available for PEs and CEs to exchange route information, including static routing, RIP, OSPF, OSPFv3, IS-IS, and BGP. Identify the troubleshooting procedure depending on the routing protocol used between the PE and the CE. If the issue persists after the private route has injected into the BGP routing table on the remote PE, proceed to step b.
b. Execute the display this command in BGP VPNv4 or or BGP VPNv6 address family view on the remote PE. Check for the route filtering misconfiguration that might prevent the private routes from being advertised. The following are the commands for route filtering:
- peer prefix-list export
- peer filter-policy export
- peer as-path-acl export
- filter-policy export
- peer route-policy export
To prevent a route export filtering command from incorrectly filtering private routes to be advertised, execute the undo form of that command. To avoid unexpected impacts on network services, adjust the private route export filtering policy under technical support guidance.
If the issue persists, proceed to step 3.
3. Verify that a public tunnel has been established.
The public tunnel for MPLS L3VPN can be an LSP, MPLS TE, or GRE tunnel. For an LSP or MPLS TE tunnel, the outer tag is an MPLS label. For a GRE public tunnel, the outer tag is GRE encapsulation.
A public tunnel is typically a label forwarding path automatically established by using LDP. The following information uses this type of public tunnel for example to describe the troubleshooting procedure for public tunnel establishment. For tunnels established by using other methods, see their respective troubleshooting procedures or seek help from Technical Support.
Execute the display mpls ldp peer command on each device in the private route advertisement path in the backbone network. Verify that they have established sessions with their LDP peers.
<Sysname> display mpls ldp peer
VPN instance: public instance
Total number of peers: 2
Peer LDP ID State Role GR AUT KA Sent/Rcvd
22.22.22.22:0 Operational Passive Off None 1816/1816
11.11.11.11:0 Operational Passive Off None 1816/1816
If the sessions have been successfully established, proceed to step 4.
If an LDP session is not established, see the LDP session down troubleshooting procedure for MPLS troubleshooting.
If the issue persists after the public tunnel is established, proceed to step 4.
4. Check the BGP routing table on the local PE for private routes advertised by the remote PE.
Execute the display bgp routing-table vpnv4 or display bgp routing-table vpnv6 command on the local PE to check for private routes advertised by the remote PE.
If the information of interest does not exist, perform the following operations:
a. Execute the display ip vpn-instance instance-name command on both the local and remote PEs to check for import and export RT mismatches for the VPN.
<Sysname> display ip vpn-instance instance-name vpn1
VPN-Instance Name and Index : vpn1, 1
Route Distinguisher : 1:1
Interfaces : GigabitEthernet0/0/1
TTL mode: pipe
Address-family IPv4:
Export VPN Targets :
1:1
Import VPN Targets :
1:1
- If an import and export RT mismatch exists, execute the vpn-target command in VPN instance view to change the RT settings on the local or remote PE. If the BGP routing table on the local PE still lacks the private routes advertised by the remote PE, proceed to step b. If the issue persists even if the BGP routing table on the local PE already contains the private routes advertised by the remote PE, proceed to step 5.
- If the import and export RTs match, proceed to step b.
b. Execute the display this command in BGP instance view. Check for the import route filtering misconfiguration that prevents the private routes from being imported. The following are the commands for route filtering:
- peer prefix-list import
- peer filter-policy import
- peer as-path-acl import
- filter-policy import
- peer route-policy import
To prevent a route import filtering command from incorrectly filtering received private routes, execute the undo form of that command. To avoid unexpected impacts on network services, adjust the private route import filtering policy under technical support guidance.
If the issue persists, proceed to step 5.
5. Identify the reason that prevents the BGP routes from being added to the IP routing table for the VPN instance. The following are possible reasons include:
¡ The device is configured with the undo policy vpn-target command. This command enables the device to add VPNv4 or VPNv6 routes to the BGP routing table for the VPN instance and select them as optimal routes, even if they do not match the the VPN instance’s RT attributes. However, these routes cannot be added to the IP routing table for the current VPN instance. To resolve this issue, execute the display this command in BGP instance view to identify the address families configured with the undo policy vpn-target command. If an address family is configured with that command, execute the policy vpn-target command in the view of that address family to resolve the issue.
¡ The device is configured with the routing-table bgp-rib-only command, which prevents BGP routes from being injected into the IP routing table. To resolve this issue, execute the display this command in BGP instance view to identify the address families configured with the routing-table bgp-rib-only command. If an address family is configured with that command, execute the undo routing-table bgp-rib-only command to resolve the issue.
If the issue persists, proceed to step 6.
6. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
Failure to forward large packets between sites
Symptom
On an IPv4 or IPv6 MPLS L3VPN network deploys devices from H3C and other vendors, inter-site access to resources in the same VPN might fail. For example, users in one site cannot access certain websites or download files via FTP in another site. Ping test fails when the payload of ICMP packets is above 1464 bytes. Ping tests succeeds when the payload of ICMP packets is less than 1464 bytes.
Common causes
This type of failure typically occurs when a small MPU is set on one or multiple network interfaces in the traffic forwarding path.
Troubleshooting flow
Figure 8 shows the troubleshooting flowchart.
Figure 8 Troubleshooting flowchart for failures to forward large packets between sites
Procedure
1. Set the MTU on each network interface in the traffic forwarding path to 1508 bytes or higher.
¡ On an H3C device, execute the display interface command to view the MTUs of interfaces.
<Sysname> display interface gigabitethernet 0/0/1
GigabitEthernet0/0/1
Current state: Administratively UP
Line protocol state: UP
Description: GigabitEthernet0/0/1 Interface
Bandwidth: 1000000 kbps
Maximum transmission unit: 1500
...
To change the MTU of an interface, execute the ip mtu or ipv6 mtu command in interface view.
¡ For information about the commands used on a device from a third-party vendor, see the documentation for that device.
If the issue persists, proceed to step 2.
2. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
Failure to ping the subnet attached to a remote CE from a PE
Symptom
On the IPv6 MPLS L3VPN network shown in Figure 9, multiple interfaces on PE 1 are assigned to VPN instance VPN 1. Executing the ping ipv6 2001:db8:3::1 command on both CE 1 and CE 2 successfully pings the subnet attached to remote CE 3. However, executing the ping ipv6 -vpn-instance vpn1 2001:db8:3::1 command on PE 1 cannot ping the subnet attached to CE 3.
Common causes
This issue typically occurs when CE 3 lacks routes to some private IPv6 addresses on PE 1. To resolve this issue, CE 3 must have routes to the IPv6 addresses of all up interfaces in the same VPN as it on PE 1.
Troubleshooting flow
Figure 10 shows the troubleshooting flowchart.
Procedure
1. Make sure CE 3 has routes to all private IPv6 addresses on PE 1.
When you ping a remote CE-attached subnet from PE 1 without specifying a source address, PE 1 sends ICMPv6 requests with a source address automatically selected from the IPv6 addresses on the packet outgoing interface. If CE 3 lacks routing information for this IPv6 address, it cannot return ICMPv6 echo packets.
To resolve this issue:
¡ Configure PE 1 to advertise all its private routes. For example, execute the import-route direct command in BGP-VPN IPv6 unicast address family view.
¡ Execute the ping ipv6 –a source-ipv6 -vpn-instance vpn-instance-name host command to perform a ping operation with a source IP address specified. Make sure this address exists in the IPv6 routing table on CE 3.
If the issue persists, proceed to step 2.
2. If the issue persists, collect the following information and contact Technical Support:
¡ Results of each step.
¡ The configuration file, log messages, and alarm messages.
Related alarm and log messages
Alarm messages
N/A
Log messages
N/A
