Buy or Renew
Buy or Renew
Join the Catalyst Center Onboarding Ask Me Anything event happening now!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
3942
Views
0
Helpful
26
Replies

Cannot statically route MPLS L3VPN over TE Tunnel

steven.crutchley
Level 3
Level 3

‎07-10-2018 12:13 PM - edited ‎03-05-2019 10:45 AM

I have the following network:

 

MPLS_TE_1.png


ISIS is used as the IGP. Standard L3VPN MPLS setup.

 

CE1 and CE2 are both part of Customer 1. Their ACs on both PE1 and PE2 are in VRF CUST_1. Routes are advertised over VPNv4 MP-BGP via RR1. 

 

I've enabled traffic engineering on all interfaces and have setup a TE tunnel with PE1 as the headend, PE2 as the tail-end and an explicit path via P2-P3-P4-PE2.

PE1#sh run int tu1
Building configuration...

Current configuration : 200 bytes
!
interface Tunnel1
 ip unnumbered Loopback0
 tunnel destination 200.200.200.200
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng path-option 1 explicit name LOWER-PATH
 no routing dynamic
end

PE1#show ip explicit-paths name LOWER-PATH
PATH LOWER-PATH (strict source route, path complete, generation 6)
    1: next-address 2.2.2.2
    2: next-address 3.3.3.3
    3: next-address 4.4.4.4
    4: next-address 200.200.200.200
PE1#


100.100.100.100 = PE1
200.200.200.200 = PE2
1.1.1.1 = P1 etc..

 

I've statically routed traffic to 192.168.70.0/24 over the TE Tunnel using:

 

ip route vrf CUST_1 192.168.70.0 255.255.255.0 Tunnel1

 

If I trace from CE1 to 192.168.80.1 is goes via the upper path - normal MPLS L3VPN

 

CE1#trace 192.168.80.1 source lo1

Type escape sequence to abort.
Tracing the route to 192.168.80.1

1 172.30.1.9 12 msec 12 msec 24 msec
2 10.10.110.1 [AS 500] [MPLS: Labels 50106/52019 Exp 0] 84 msec 72 msec 108 msec
3 10.10.15.5 [AS 500] [MPLS: Labels 50505/52019 Exp 0] 100 msec 140 msec 124 msec
4 10.10.56.6 [AS 500] [MPLS: Labels 50600/52019 Exp 0] 112 msec 112 msec 100 msec
5 172.30.2.9 [AS 500] [MPLS: Label 52019 Exp 0] 76 msec 92 msec 64 msec
6 172.30.2.10 [AS 500] 84 msec 72 msec 92 msec



If I trace to 192.168.70.1 I'd like it go over the TE tunnel via the static route. But I get nothing

 

CE1#trace 192.168.70.1 source lo1

Type escape sequence to abort.
Tracing the route to 192.168.70.1

1 172.30.1.9 24 msec 12 msec 12 msec
2 * * *
3 * * *


When doing a packet capture, I can see the ICMP request going along the lower path (i.e. through the tunnel) but the VPN label is not on the packet.


So P4 PHPs the Tunnel label and it arrives at PE2 as an IP packet. PE2 has not idea what to do with, naturally, and drops it.

 

How can make sure the VPN label (as advertised via MP-BGP from PE2) is pushed onto the IP packet at PE1 before it enters the tunnel?

Labels:
0 Helpful
26 Replies 26

a.alekseev
Level 7
Level 7
In response to steven.crutchley

‎07-18-2018 02:44 PM - edited ‎07-18-2018 02:45 PM

show the outputs from PE1
sh mpls traffic-eng tunnels
sh ip route
sh int tu1
sh ip bgp vpn4 vrf CUST_1

0 Helpful

steven.crutchley
Level 3
Level 3
In response to a.alekseev

‎07-25-2018 10:58 AM

See attached for requested output.

 

Ignore routes for 44.x.x.x 33.x.x.x or 99.x.x.x. I've added to the lab but these are unrelated to the MPLS L3VPN setup.

Preview file
7 KB
0 Helpful

jpl861
Level 4
Level 4
In response to steven.crutchley

‎07-18-2018 12:09 PM

what's the content of 1?

match extcommunity 1
0 Helpful

steven.crutchley
Level 3
Level 3
In response to jpl861

‎07-18-2018 02:33 PM

The content is as follows:

 

ip extcommunity-list 1 permit rt 500:1

However even if I remove all match statements from the route-map (meaning match all) the next hop is still not being set correctly. 

PE1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
PE1(config)#route-map TE_IMPORT permit 10
PE1(config-route-map)#no  match ip address prefix-list TE_IMPORT
PE1(config-route-map)#no match extcommunity 1
PE1(config-route-map)#^Z
PE1#
*Mar  1 00:10:45.167: %SYS-5-CONFIG_I: Configured from console by console
PE1#
PE1#clear ip bgp *
PE1#
*Mar  1 00:11:04.399: %BGP-5-ADJCHANGE: neighbor 77.77.77.77 Down User reset
*Mar  1 00:11:04.399: %BGP-5-ADJCHANGE: neighbor 172.30.1.10 vpn vrf CUST_1 Down User reset
*Mar  1 00:11:04.923: %BGP-5-ADJCHANGE: neighbor 77.77.77.77 Up
PE1#
*Mar  1 00:11:05.603: %BGP-5-ADJCHANGE: neighbor 172.30.1.10 vpn vrf CUST_1 Up
PE1#sh ip ro vrf CUST_1

Routing Table: CUST_1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

B    192.168.60.0/24 [20/0] via 172.30.1.10, 00:00:10
     172.30.0.0/30 is subnetted, 2 subnets
B       172.30.2.8 [200/0] via 200.200.200.200, 00:00:03
C       172.30.1.8 is directly connected, FastEthernet0/1
B    192.168.80.0/24 [200/0] via 200.200.200.200, 00:00:03
B    192.168.70.0/24 [200/0] via 200.200.200.200, 00:00:03
0 Helpful

jpl861
Level 4
Level 4
In response to steven.crutchley

‎07-24-2018 05:03 AM

Change the RD on one end. Try to make it unique and you'll see the set clause would work.

0 Helpful

steven.crutchley
Level 3
Level 3
In response to jpl861

‎07-25-2018 11:32 AM

Hi John,

 

Thanks for that. This seems to have worked. At least in part. I can see the next hop is being set correctly now. But I still cannot ping across the tunnel. When I do a packet capture I cannot see the packet even leaving PE1(the ingress PE for the tunnel).

 

Any advice? Here is what CEF and BGP see:

 

PE1#sh ip cef vrf CUST_1 192.168.70.0 detail
192.168.70.0/24, version 16, epoch 0
0 packets, 0 bytes
  tag information set
    local tag: VPN-route-head
    fast tag rewrite with
        Recursive rewrite via 200.200.200.201/32, tags imposed {52019}
  via 200.200.200.201, 0 dependencies, recursive
    next hop 200.200.200.201, Tunnel1 via 200.200.200.201/32
    valid adjacency
    tag rewrite with
        Recursive rewrite via 200.200.200.201/32, tags imposed {52019}
PE1#sh ip cef vrf CUST_1 192.168.70.0 detail
192.168.70.0/24, version 16, epoch 0
0 packets, 0 bytes
  tag information set
    local tag: VPN-route-head
    fast tag rewrite with
        Recursive rewrite via 200.200.200.201/32, tags imposed {52019}
  via 200.200.200.201, 0 dependencies, recursive
    next hop 200.200.200.201, Tunnel1 via 200.200.200.201/32
    valid adjacency
    tag rewrite with
        Recursive rewrite via 200.200.200.201/32, tags imposed {52019}
PE1#

 

 

0 Helpful

jpl861
Level 4
Level 4
In response to steven.crutchley

‎07-25-2018 11:38 AM

Can you post this output from PE1?

 

show bgp vpnv4 uni vrf Cust_1

show ip route vrf Cust_1

show mpls traffic-eng tunnel

 

What does the trace tell you from CE1?

0 Helpful

steven.crutchley
Level 3
Level 3
In response to jpl861

‎07-26-2018 09:53 AM

See attached for output.

 

From the trace to 192.168.80.1 correctly follows the upper path (not through the TE tunnel)

 

But the trace to 192.168.70.1 doesn't even make it to the first P router according to a traceroute. I think the problem is on PE1. 

 

CE1#traceroute 192.168.80.1 source lo1

Type escape sequence to abort.
Tracing the route to 192.168.80.1

  1 172.30.1.9 16 msec 20 msec 8 msec
  2 10.10.110.1 [AS 500] [MPLS: Labels 50105/52019 Exp 0] 112 msec 152 msec 76 msec
  3 10.10.15.5 [AS 500] [MPLS: Labels 50504/52019 Exp 0] 120 msec 84 msec 124 msec
  4 10.10.56.6 [AS 500] [MPLS: Labels 50600/52019 Exp 0] 88 msec 104 msec 112 msec
  5 172.30.2.9 [AS 500] [MPLS: Label 52019 Exp 0] 132 msec 124 msec 132 msec
  6 172.30.2.10 [AS 500] 112 msec 180 msec 88 msec
CE1#traceroute 192.168.70.1 source lo1

Type escape sequence to abort.
Tracing the route to 192.168.70.1

  1 172.30.1.9 12 msec 12 msec 24 msec
  2  *  *  *
  3  *  *  *
  4  *  *  *
  5  *  *  *
Preview file
3 KB
0 Helpful

jpl861
Level 4
Level 4
In response to steven.crutchley

‎07-26-2018 10:38 AM

Hmmm... So you cannot see any packets going to P2 correct?

 

Can also attach the show mpls forwarding-table output of P2, P3, and P4? I am wondering why yours is not working but we almost have the same lab and it worked for me.

0 Helpful

jpl861
Level 4
Level 4
In response to steven.crutchley

‎07-26-2018 10:51 AM

Hmmm... So you cannot see any packets going to P2 correct?

 

Can also attach the show mpls forwarding-table output of P2, P3, and P4? I am wondering why yours is not working but we almost have the same lab and it worked for me.

0 Helpful

a.alekseev
Level 7
Level 7
In response to steven.crutchley

‎07-25-2018 12:19 PM

PE1#traceroute vrf CUST_1 192.168.70.1
PE1#traceroute vrf CUST_1 192.168.80.1
0 Helpful

steven.crutchley
Level 3
Level 3
In response to a.alekseev

‎07-26-2018 09:51 AM

So from PE1 traceroutes look as follows:

 

PE1#traceroute vrf CUST_1 192.168.70.1

Type escape sequence to abort.
Tracing the route to 192.168.70.1

  1  *  *  *
  2  *  *  *
  3  *  *  *
  4
PE1#traceroute vrf CUST_1 192.168.80.1

Type escape sequence to abort.
Tracing the route to 192.168.80.1

  1 10.10.110.1 [MPLS: Labels 50105/52019 Exp 0] 72 msec 112 msec 84 msec
  2 10.10.15.5 [MPLS: Labels 50504/52019 Exp 0] 80 msec 72 msec 72 msec
  3 10.10.56.6 [MPLS: Labels 50600/52019 Exp 0] 76 msec 88 msec 76 msec
  4 172.30.2.9 [MPLS: Label 52019 Exp 0] 68 msec 68 msec 84 msec
  5 172.30.2.10 28 msec 80 msec 96 msec
PE1#

A wireshark capture of the link between PE1 and the next P router no packets being sent. So I'm not sure the ICMP is even leaving PE1.

0 Helpful
Customers Also Viewed These Support Documents
Review Cisco Networking for a $25 gift card