Implementing an MPLS VPN over TE Tunnels
Document ID: 29828
Contents
Introduction
Prerequisites
Requirements
Components Used
Conventions
Background Theory
Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel
Topology
Configuration
Verification
Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2
Topology
Configuration
Verification
Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2
Topology
Configuration
Verification
Explanation
Solution
Case 3: VPN Between CE1 and CE2 over a TE Tunnel from P1 to P2 When TDP/LDP Is Not Enabled
Topology
Configuration
Verification
Solution
Case 4: VPN over a TE Tunnel Between P1 and P2 with LDP Enabled
Topology
Configuration
Verification
Case 5: MPLS VPN over a Tunnel Between P1 and PE2
Topology
Configuration
Verification
Known Issues
Conclusion
Cisco Support Community - Featured Conversations
Related Information
Introduction
This document provides sample configurations for implementing a Multiprotocol Label Switching (MPLS) VPN over traffic engineering (TE) tunnels in an MPLS network. In order to gain the benefits of an MPLS VPN over TE tunnels, both should coexist in the network. This document illustrates various scenarios that explain why packet forwarding within an MPLS VPN over TE tunnels might fail. It also provides a possible solution.
Prerequisites
Requirements
Readers of this document should have knowledge of these topics:
Components Used
This document is not restricted to specific software and hardware versions.
Conventions
Refer to
Cisco Technical Tips Conventions for more information on document conventions.
Background Theory
As shown in this topology, in a simple MPLS VPN configuration, Provider Edge 1 (PE1) learns the VPN label (Label 1 [L1]) for the VPN prefix 172.16.13.0/24 via multiprotocol Border Gateway Protocol (MPBGP) from PE2 directly, with the next hop as the PE2 loopback address. PE1 also learns the label (L2) for the PE2 loopback address via Label Distribution Protocol (LDP) from its next hop P1.
When forwarding data to the VPN prefix 172.16.13.13, PE1 uses a label stack {L2 L1} with L2 as the outer label. L2 gets swapped by the transit label switch router (LSR), P1. P2 pops the outer L2 and forwards the packet to PE2 with only one L1. To better understand why P2 pops L2, refer to section 3.16 about penultimate hop popping (PHP) in
RFC 3031 . Thus, packets to the VPN IP version 4 (IPv4) prefix 172.16.13.0/24 are label switched over an MPLS network.
The MPLS VPN forwarding operation fails if any P router receives the packet with L1 (VPN label) as the only outer label instead of the {L2 L1} label stack. This occurs because none of the P routers has L1 in its label forwarding information base (LFIB) to switch the packet.
An MPLS TE uses Resource Reservation Protocol (RSVP) to exchange labels. When a router is configured for both TE and Tag Distribution Protocol (TDP)/LDP, the router receives different labels from both LDP and RSVP for a given prefix. The labels from LDP and RSVP do not need to be the same in all situations. The router installs an LDP label in the forwarding table if the prefix is learned through an LDP interface, and it installs the RSVP label in the forwarding table if the prefix is learned over a TE tunnel interface.
In the case of a plain TE tunnel (without LDP/TDP enabled on the tunnel), the ingress LSR (the LSR on the headend of the TE tunnel) uses the same label as is used for reaching the tailend of the TE tunnel for all the routes that are learned through a TE tunnel.
For example, there is a TE tunnel from PE1 to P2 learning the prefix 10.11.11.11/32 over the tunnel. The tunnel tailend on P2 is 10.5.5.5, and the label to reach 10.5.5.5 in PE1 is L3. PE1 then uses L3 to reach the destination 10.11.11.11/32, learned over the TE tunnel.
In the scenario
above, when there is a TE tunnel between PE1 and P2, consider that PE1 forwards data to Customer Edge 2 (CE2). If L4 is the VPN label, PE1 forwards the data with the label stack {L3 L4}. P1 pops L3, and P2 receives the packet with L4. PE2 is the only LSR that can correctly forward the packet with the outer label L4. P2 does not have an MPBGP session with PE2, so it does not receive the L4 from PE2. Therefore, P2 does not have any knowledge of L2, and it drops the packet.
The configurations and
show outputs that follow demonstrate this and illustrate one possible solution to this problem.
Initial VPN Setup Between CE1 and CE2 Without a TE Tunnel
Topology
Configuration
Only the relevant parts of the configuration files are included here:
PE1
hostname PE1
ip cef
!
ip vrf aqua
rd 100:1
route-target export 1:1
route-target import 1:1
!
mpls traffic-eng tunnels
!
interface Loopback0
ip address 10.2.2.2 255.255.255.255
no ip directed-broadcast
!
interface Ethernet2/0/1
ip vrf forwarding aqua
ip address 172.16.1.2 255.255.255.0
!
interface Ethernet2/0/2
ip address 10.7.7.2 255.255.255.0
ip router isis
mpls traffic-eng tunnels
tag-switching ip
!
router isis
passive-interface Loopback0
net 47.1234.2222.2222.2222.00
is-type level-1
metric-style wide
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.11.11.11 remote-as 1
neighbor 10.11.11.11 update-source Loopback0
!
address-family vpnv4
neighbor 10.11.11.11 activate
neighbor 10.11.11.11 send-community extended
exit-address-family
!
address-family ipv4
neighbor 10.11.11.11 activate
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf aqua
redistribute connected
no auto-summary
no synchronization
exit-address-family
PE2
hostname PE2
!
ip vrf aqua
rd 100:1
route-target export 1:1
route-target import 1:1
!
mpls traffic-eng tunnels
!
interface Loopback0
ip address 10.11.11.11 255.255.255.255
!
interface POS0/1
ip address 10.12.12.10 255.255.255.0
ip router isis
mpls traffic-eng tunnels
tag-switching ip
crc 16
clock source internal
!
interface POS5/1
ip vrf forwarding aqua
ip address 172.16.13.11 255.255.255.0
crc 32
clock source internal
!
router isis
passive-interface Loopback0
mpls traffic-eng router-id Loopback0
mpls traffic-eng level-1
net 47.1234.1010.1010.1010.00
is-type level-1
metric-style wide
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.2.2.2 remote-as 1
neighbor 10.2.2.2 update-source Loopback0
no auto-summary
!
address-family vpnv4
neighbor 10.2.2.2 activate
neighbor 10.2.2.2 send-community extended
exit-address-family
!
address-family ipv4 vrf aqua
redistribute connected
no auto-summary
no synchronization
exit-address-family
!
Verification
PE2 learns PE1 VPN IPv4 prefix 172.16.1.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
PE2# show ip route vrf aqua
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
B 172.16.1.0 [200/0] via 10.2.2.2, 16:09:10
C 172.16.13.0 is directly connected, POS5/1
Similarly, PE1 learns PE2 VPN IPv4 prefix 172.16.13.0/24 over MPBGP peering between PE1 and PE2. This is shown here:
PE1# show ip route vrf aqua
Codes: C - connected, S - static, I - IGRP, 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, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
10.0.0.0/24 is subnetted, 2 subnets
B 172.16.13.0 [200/0] via 10.11.11.11, 16:09:49
C 172.16.1.0 is directly connected, Ethernet2/0/1
PE1# show ip route vrf aqua 172.16.13.13
Routing entry for 172.16.13.0/24
Known via "bgp 1", distance 200, metric 0, type internal
Last update from 10.11.11.11 16:13:19 ago
Routing Descriptor Blocks:
* 10.11.11.11 (Default-IP-Routing-Table), from 10.11.11.11, 16:13:19 ago
Route metric is 0, traffic share count is 1
AS Hops 0, BGP network version 0
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 11, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
!--- The label stack used to reach 172.16.13.13 is
!--- {17 12308}, where 17 is the outer label to reach next hop 10.11.11.11
!--- and 12308 is the VPN IPv4 label for 172.16.13.0/24.
PE1# show ip cef 10.11.11.11
10.11.11.11/32, version 31, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
via 10.7.7.7, Ethernet2/0/2, 1 dependency
next hop 10.7.7.7, Ethernet2/0/2
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
!--- Outer label 17 is used to reach next hop 10.11.11.11.
Thus, CE1 can reach 172.16.13.13 on the CE2 network via the VPN routing and forwarding (VRF) instance "aqua", which is configured on PE1 using the label stack {17 12308}, as shown above.
This
ping output confirms the connectivity:
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms
Case 1: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to PE2
Topology
When the TE tunnel is built between the PE routers with autoroute announce used, the egress PE BGP next hop is reachable via the TE tunnel interface. Thus, PE1 uses the TE label to reach PE2.
Note: MPLS TE is independent of LDP, which means that, if you have a full mesh of tunnels from PE to PE, you can effectively disable LDP in the routers and do not need to run LDP on the TE tunnel interfaces. However, you must build all tunnels to the BGP next hop of the VPN version 4 (VPNv4) routes. In the example in this
Configuration, you can see that this BGP next hop is the Loopback0 on PE2, 10.11.11.11. This same loopback is also the tunnel destination for the tunnel from PE1 to PE2. This explains why, in this example, if there is also a tunnel from PE2 to PE1 for the return traffic, you can disable LDP in the core. Then, forwarding from CE to CE works with all VPNv4 traffic carried over the TE tunnels. If the BGP next hop is not the same as the TE tunnel destination, LDP must be run in the core and on the TE tunnel.
Configuration
The additional configuration on PE1 to establish a PE tunnel is shown here:
PE1
PE1#
show run interface tunnel 0
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
tunnel destination 10.11.11.11
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
Verification
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed {19 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.11.11.11, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19 12308}
!--- The label stack to reach 172.16.13.13 is {19 12308}.
!--- BGP next hop for the VPNv4 prefix is 10.11.11.11, which is
!--- the same as the TE tunnel destination.
PE1# show ip route 10.11.11.11
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 40, type level-1
Redistributing via isis
Last update from 10.11.11.11 on Tunnel0, 00:02:09 ago
Routing Descriptor Blocks:
* 10.11.11.11, from 10.11.11.11, via Tunnel0
!--- The route is via Tunnel0.
Route metric is 40, traffic share count is 1
Now, confirm the outer label used to reach the next hop 10.11.11.11 via Tunnel0.
PE1# show mpls traffic-eng tunnels tunnel 0
Name: PE1_t0 (Tunnel0) Destination: 10.11.11.11
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type dynamic (Basis for Setup, path weight 30)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
InLabel : -
OutLabel : Ethernet2/0/2, 19
!--- Label 19 from RSVP is used to reach destination 10.11.11.11/32.
RSVP Signalling Info:
Src 10.2.2.2, Dst 10.11.11.11, Tun_Id 0, Tun_Instance 31
RSVP Path Info:
My Address: 10.7.7.2
Explicit Route: 10.7.7.7 10.8.8.7 10.8.8.5 10.12.12.10
10.11.11.11
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=Inf
Shortest Unconstrained Path Info:
Path Weight: 30 (TE)
Explicit Route: 10.7.7.2 10.7.7.7 10.8.8.7 10.8.8.5
10.12.12.10 10.11.11.11
History:
Tunnel:
Time since created: 17 hours, 17 minutes
Time since path change: 32 minutes, 54 seconds
Current LSP:
Uptime: 32 minutes, 54 seconds
Prior LSP:
ID: path option 10 [14]
Removal Trigger: tunnel shutdown
Another way to view this information quickly is to use the output modifiers in the
show commands, as shown here:
PE1# show mpls traffic-eng tunnels tunnel 0 | include Label
InLabel : -
OutLabel : Ethernet2/0/2, 19
!--- This is the label to reach 10.11.11.11.
Look at the tag stack. It is 19, which is the TE label, used to forward packets to next hop 10.11.11.0 over Tunnel0.
PE1# show tag forwarding-table 10.11.11.11 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 Pop tag 10.11.11.11/32 0 Tu0 point2point
MAC/Encaps=14/18, MTU=1500, Tag Stack{19}, via Et2/0/2
00603E2B02410060835887428847 00013000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE1#
Thus, PE1 sends a packet destined to 172.16.13.13 with the label stack {19 12308}. P1 swaps the label 19. The packet reaches P2, which pops that outer label. Then, the packet is forwarded to PE2 with only the label 12308.
On PE2, the packet with the label 12308 is received and switched according to the information in the forwarding table. This is shown here:
PE2# show tag for tags 12308 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
12308 Aggregate 172.16.13.0/24[V] 12256
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#
Note: No Outgoing interface is shown because the outgoing tag is Aggregate. This is because the prefix associated with the label is the directly connected route.
Pings from CE1 to a host on CE2 confirm the VPN connectivity over the TE tunnel:
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/13/36 ms
CE1#
Case 2: VPN over a TE Tunnel When the TE Tunnel Is from PE1 to P2
Topology
Configuration
The additional TE configuration over the basic configuration on PE1 is shown here:
PE1
PE1#
show run interface tunnel 0
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
Verification
Check the route to prefix 172.16.13.13 on PE1 VRF aqua. It points to the next hop 10.11.11.11/32 (over Tunnel0) using label stack {19 12308}.
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed {19 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.5.5.5, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19 12308}
PE1#
Label 19, the outer label, is used to reach next hop 10.11.11.11/32, as shown here:
PE1# show ip cef 10.11.11.11
10.11.11.11/32, version 37
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Tu0, point2point, tags imposed {19}
via 10.5.5.5, Tunnel0, 1 dependency
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19}
PE1# show mpls traffic-eng tunnels tunnel 0
Name: PE1_t0 (Tunnel0) Destination: 10.5.5.5
Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 10, type dynamic (Basis for Setup, path weight 20)
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
InLabel : -
OutLabel : Ethernet2/0/2, 19
RSVP Signalling Info:
Src 10.2.2.2, Dst 10.5.5.5, Tun_Id 0, Tun_Instance 33
RSVP Path Info:
My Address: 10.7.7.2
Explicit Route: 10.7.7.7 10.8.8.7 10.8.8.5 10.5.5.5
Record Route: NONE
Tspec: ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=0 kbits, burst=1000 bytes, peak rate=Inf
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 10.7.7.2 10.7.7.7 10.8.8.7 10.8.8.5
10.5.5.5
History:
Tunnel:
Time since created: 17 hours, 31 minutes
Time since path change: 8 minutes, 49 seconds
Current LSP:
Uptime: 8 minutes, 49 seconds
Selection: reoptimation
Prior LSP:
ID: path option 10 [31]
Removal Trigger: path verification failed
PE1#
PE1# show mpls traffic-eng tunnels tunnel 0 | i Label
InLabel : -
OutLabel : Ethernet2/0/2, 19
PE1#
The packet from PE1 is sent over the TE tunnel with the label stack {19 12308}. Once P1 receives the packet, it pops (PHP) the tag 19 and sends the packet with label stack {12308}. The
show command confirms this:
P1> show tag for tag 19
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
19 Pop tag 10.2.2.2 0 [33] 2130 Et2/0 10.8.8.5
P1>
P1> show tag for tag 19 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
19 Pop tag 10.2.2.2 0 [33] 2257 Et2/0 10.8.8.5
MAC/Encaps=14/14, MTU=1504, Tag Stack{}
006009E08B0300603E2B02408847
No output feature configured
P1>
When P2 receives the packet with the label stack {12308}, it checks its LFIB and drops the packet because no match exists. This is the
show command output on P2:
P2# show tag forwarding-table tags 12308 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
P2#
P2#
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
7w4d: TAG: Et0/3: recvd: CoS=0, TTL=253, Tag(s)=12308
P2#
P2#
Explanation
The solution to this problem is to enable TDP/LDP on the TE tunnel and to make it a tag-switched interface. In the example shown in the
Solution, TDP is enabled on the Tunnel0 of PE1. P2 is configured for accepting directed hellos and forming directed TDP neighbors. So, PE1 receives the label for 10.11.11.11 from P2 via LDP. Now that Tunnel0 has been made a tag-switched interface and TDP has been enabled for the traffic to 10.11.11.11, PE1 uses both the labels; it uses the RSVP label to reach the TE tailend and the TDP label to reach 10.11.11.11.
In this scenario, PE1 uses the label stack {L2 L3 L1} to forward data to CE2 if these items are true:
- L1 is the VPN label.
- L2 is the RSVP label to reach the TE tailend.
- L3 is the TDP label to reach 10.11.11.11 (received from P2).
Solution
The solution is to enable TDP across the TE tunnel.
Configuration
Shown here is the TE tunnel configuration on PE1 with TDP enabled on it. The additions are in boldface.
PE1
PE1#
show run interface tunnel 0
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
no ip route-cache distributed
tag-switching ip
!--- This enables TDP.
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
This is the additional configuration on the tailend of the TE tunnel to accept directed TDP hellos:
P2# show run | i directed-hello
tag-switching tdp discovery directed-hello accept
!--- This configures P2 to accept directed TDP hellos.
P2#
Verification
PE1# show tag tdp neighbor | i Peer
Peer TDP Ident: 10.7.7.7:0; Local TDP Ident 10.2.2.2:0
Peer TDP Ident: 10.5.5.5:0; Local TDP Ident 10.2.2.2:0
PE1#
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 11
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Tu0, point2point, tags imposed {19 18 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.5.5.5, Tunnel0 via 10.11.11.11/32
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {19 18 12308}
PE1#
PE1# show mpls traffic-eng tunnels tunnel 0 | i Label
InLabel : -
OutLabel : Ethernet2/0/2, 19
!--- This is the TE label learned via RSVP.
PE1#
PE1# show tag tdp bind 10.11.11.11 32
tib entry: 10.11.11.11/32, rev 20
local binding: tag: 21
remote binding: tsr: 10.7.7.7:0, tag: 17
remote binding: tsr: 10.5.5.5:0, tag: 18
!--- This is the TDP label from P2.
When P1 receives the packet with the label stack {19 18 12308}, it pops the tag 19 and sends the packet with the label stack {18 12308} to P2. P2 checks its LFIB for label 18, then pops the tag and sends it over the outgoing interface PO2/0/0 toward PE1. PE1 receives the packet with label 12308 and switches it successfully to CE2.
P2# show tag for tag 18
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
18 Pop tag 10.11.11.11/32 117496 POS2/0/0 point2point
P2# show tag tdp discovery
Local TDP Identifier:
10.5.5.5:0
Discovery Sources:
Interfaces:
Ethernet0/3 (tdp): xmit/recv
TDP Id: 10.7.7.7:0
POS2/0/0 (tdp): xmit/recv
TDP Id: 10.11.11.11:0
Directed Hellos:
10.5.5.5 -> 10.2.2.2 (tdp): passive, xmit/recv
TDP Id: 10.2.2.2:0
P2# show tag tdp neighbor 10.2.2.2
Peer TDP Ident: 10.2.2.2:0; Local TDP Ident 10.5.5.5:0
TCP connection: 10.2.2.2.711 - 10.5.5.5.11690
State: Oper; PIEs sent/rcvd: 469/465; Downstream
Up time: 01:41:08
TDP discovery sources:
Directed Hello 10.5.5.5 -> 10.2.2.2, passive
Addresses bound to peer TDP Ident:
10.7.7.2 172.16.47.166 10.2.2.2
PE1# show tag tdp neighbor 10.5.5.5
Peer TDP Ident: 10.5.5.5:0; Local TDP Ident 10.2.2.2:0
TCP connection: 10.5.5.5.11690 - 10.2.2.2.711
State: Oper; PIEs sent/rcvd: 438/441; Downstream
Up time: 01:35:08
TDP discovery sources:
Directed Hello 10.2.2.2 -> 10.5.5.5, active
!--- This indicates the directed neighbor.
Addresses bound to peer TDP Ident:
10.5.5.5 10.12.12.5 10.8.8.5
PE1# show ip route 10.11.11.11
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 40, type level-1
Redistributing via isis
B Last update from 10.5.5.5 on Tunnel0, 01:52:21 ago
Routing Descriptor Blocks:
* 10.5.5.5, from 10.11.11.11, via Tunnel0
Route metric is 40, traffic share count is 1
A
ping command from CE1 to a host on CE2 confirms the solution.
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
CE1#
Case 3: VPN Between CE1 and CE2 over a TE Tunnel from P1 to P2 When TDP/LDP Is Not Enabled
Topology
Configuration
The tunnel configuration on PE1 is shown here:
PE1
P1#
show run interface tunnel 0
Building configuration...
Current configuration : 255 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
Verification
Verify how packets destined to CE2 172.16.13.13 get switched here. The
show ip cef command output shows that packets to destination 172.16.13.13 are switched with the label stack {17 12308}:
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
When P1 receives this packet, it removes the outer label 17 and switches the packet after looking in the IP routing table to Tunnel0. Notice the implicit-null OutLabel in this output; it means that the outgoing interface is not label switched.
P1# show ip cef 10.11.11.11 detail
10.11.11.11/32, version 52
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Tu0, point2point, tags imposed {}
via 10.5.5.5, Tunnel0, 0 dependencies
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {}
P1# show mpls traffic-eng tunnel tunnel 0 | i Label
InLabel : -
OutLabel : Ethernet2/0, implicit-null
P1# show tag for 10.11.11.11 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 10.11.11.11/32 882 Tu0 point2point
MAC/Encaps=14/14, MTU=1500, Tag Stack{}, via Et2/0
006009E08B0300603E2B02408847
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1# show ip route 10.11.11.11
Routing entry for 10.11.11.11/32
Known via "isis", distance 115, metric 30, type level-1
Redistributing via isis
Last update from 10.5.5.5 on Tunnel0, 00:03:20 ago
Routing Descriptor Blocks:
* 10.5.5.5, from 10.11.11.11, via Tunnel0
Route metric is 30, traffic share count is 1
Once P2 receives the packet with label 12308, it looks at its forwarding table. Because there is no way P2 can be aware of the VPN tag 12308 from CE2, it drops the packet.
P2# show tag for tag 12308 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
This breaks the path of VPN packets destined to CE2. It is confirmed by the
ping to CE2 172.16.13.13/32.
PE1#
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE1#
Solution
The solution is to enable LDP/TDP over the tunnel. The next section discusses this solution.
Case 4: VPN over a TE Tunnel Between P1 and P2 with LDP Enabled
Topology
Configuration
With LDP enabled on the tunnel, the configurations on P1 appear as shown here. Additions are in boldface.
PE1
P1#
show run interface tunnel 0
Building configuration...
Current configuration : 273 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
mpls label protocol ldp
tunnel destination 10.5.5.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
!
Verification
PE1 sends packets to prefix 172.16.13.13/32 with the label stack {17 12308}.
PE1#
PE1# show tag for 10.11.11.11 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
21 17 10.11.11.11/32 0 Et2/0/2 10.7.7.7
MAC/Encaps=14/18, MTU=1500, Tag Stack{17}
00603E2B02410060835887428847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE1#
PE1# show ip cef 10.11.11.11 detail
10.11.11.11/32, version 60, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: 21
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
via 10.7.7.7, Ethernet2/0/2, 1 dependency
next hop 10.7.7.7, Ethernet2/0/2
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17}
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
P1 receives the packet with label stack {17 12308} and looks at its LFIB for label 17.
P1# show tag for tag 17 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 18 10.11.11.11/32 1158 Tu0 point2point
MAC/Encaps=14/18, MTU=1496, Tag Stack{18}, via Et2/0
006009E08B0300603E2B02408847 00012000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1#
P1# show ip cef 10.11.11.11 detail
10.11.11.11/32, version 52
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Tu0, point2point, tags imposed {18}
via 10.5.5.5, Tunnel0, 0 dependencies
next hop 10.5.5.5, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {18}
It shows that label 17 should be swapped to label 18. Therefore, that packet is switched over the tunnel interface with the label stack {18 12308}.
P2 receives the packet over its tunnel interface with label stack {18 12308}. It pops the tag 18 (because it is the penultimate hop router) and switches the packet to PE2 with the label 12308.
P2# show tag for tag 18 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
18 Pop tag 10.11.11.11/32 127645 PO2/0/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
0F008847
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P2#
PE2 receives the packet with label 12308, which switches the packet to CE2 successfully.
PE2# show tag forwarding tags 12308 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
12308 Aggregate 172.16.13.0/24[V] 12256
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
CE1#
Case 5: MPLS VPN over a Tunnel Between P1 and PE2
Topology
Configuration
PE1
P1#
show run interface tunnel 0
Building configuration...
Current configuration : 258 bytes
!
interface Tunnel0
ip unnumbered Loopback0
no ip directed-broadcast
ip route-cache distributed
tunnel destination 10.11.11.11
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 dynamic
end
Verification
PE1 sends a packet destined to 172.16.13.13 to its next hop 10.11.11.11 with the label stack {17 12308}.
PE1# show ip cef vrf aqua 172.16.13.13
172.16.13.0/24, version 18, cached adjacency 10.7.7.7
0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
via 10.11.11.11, 0 dependencies, recursive
next hop 10.7.7.7, Ethernet2/0/2 via 10.11.11.11/32
valid cached adjacency
tag rewrite with Et2/0/2, 10.7.7.7, tags imposed {17 12308}
P1 receives the packet with label stack {17 12308}. P1 looks at its LFIB table and checks the tag stack {17} and switches the packet with label {17} toward P2.
P1# show tag for 10.11.11.11 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 10.11.11.11/32 411 Tu0 point2point
MAC/Encaps=14/18, MTU=1500, Tag Stack{17}, via Et2/0
006009E08B0300603E2B02408847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1# show tag for tag 17 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Untagged 10.11.11.11/32 685 Tu0 point2point
MAC/Encaps=14/18, MTU=1500, Tag Stack{17}, via Et2/0
006009E08B0300603E2B02408847 00011000
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
P1#
P1# show ip cef 10.11.11.11
10.11.11.11/32, version 67
0 packets, 0 bytes
tag information set
local tag: 17
fast tag rewrite with Tu0, point2point, tags imposed {17}
via 10.11.11.11, Tunnel0, 0 dependencies
next hop 10.11.11.11, Tunnel0
valid adjacency
tag rewrite with Tu0, point2point, tags imposed {17}
P2 receives the packet with label stack {17 12308}. P2, being the penultimate hop router, pops label 17.
P2# show tag for tag 17 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
17 Pop tag 10.7.7.7 0 [5] 535 PO2/0/0 point2point
MAC/Encaps=4/4, MTU=4474, Tag Stack{}
0F008847
No output feature configured
P2#
PE2 then receives the packet with the label 12308. P2 is aware that the destination for label 12308 is directly connected. Therefore, the
ping from CE1 to CE2 is 10.
PE2# show tag for tag 12308 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
12308 Aggregate 172.16.13.0/24[V] 12776
MAC/Encaps=0/0, MTU=0, Tag Stack{}
VPN route: aqua
No output feature configured
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
PE2#
Note: No Outgoing interface is shown because the outgoing tag is Aggregate. This is because the prefix associated with the label is the directly connected route.
CE1# ping 172.16.13.13
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.13.13, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms
CE1#
Known Issues
Refer to
Field Notice: MPLS VPN with TE and MPLS InterAS Advisory on Cisco IOS® Software for more details.
Conclusion
When the TE tunnel is terminated on the egress PE, the MPLS VPN and the TE work together without any additional configuration. When the TE tunnel is terminated on any P routers (before the PE in the core), the MPLS VPN traffic forwarding fails because packets arrive with VPN labels as the outer labels, which are not in the LFIBs of these devices. Therefore, these intermediate routers are not able to forward packets to the final destination, the VPN customer network. In such a case, LDP/TDP should be enabled on the TE tunnel to solve the problem.
Cisco Support Community - Featured Conversations
Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers. Below are just some of the most recent and relevant conversations happening right now.
Want to see more? Join us by clicking
here
- Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it21 Replies03.07.2007 05:05 Hi guys, I'm tring to test interoperability between Cisco an Juniper Boxes about pseudowire services. Let assume that I've an MPLS backbone, where the label distribution protocol used is RSVP, then MPLS-TE tunnels, I do not want to enable LDP on my backbone. Well, as far as I know, pseudowires requires LDP as control protocol... then: from Juniper side I've enable a feature that they calling "LDP-Tunneling" in order to connect different LDP "islands" through my RSVP Backbone. Is there a similar feature into IOS? what I've tested is to configure targeted LDP and MPLS-TE tunnels, but seems to do not work fine. What is happening is that Juniper and Cisco established correctly the LDP targeted session, but discarding the FEC into the advertisement... Any ideas? Have anyone already tested it before??? Any suggestions is more than appreciated, Best Regards, G. Subscribe Reply
- Re: Pseudowire over MPLS-TE Tunnelshritter28.06.2007 10:44Graziano, All you need on either side is the targeted LDP session. The JunOS LDP tunneling feature is not needed in this scenario. It is equivalent to enabling LDP on a TE tunnel interface on the IOS side. On the JunOS side, the targeted LDP session is enabled by the following set of commands: protocols { l2circuit { neighbor x.x.x.x {...Reply
- Re: Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it29.06.2007 00:25Hello, thank you for your suggestion but actually I do not have LDP on my backbone and on the JunOS side I've to enable LDP tunneling, just to transport LDP into the RSVP backbone. Forget for a second the pseudowire stuff... we have just to connect two LDP network through and RSVP backbone The LDP tunneling features allow JunOS box to start targeted LDP session toward other boxes with, as source and transport address of...Reply
- Re: Pseudowire over MPLS-TE Tunnelshritter29.06.2007 04:19Graziano, I completely understand the fact that you do not need LDP in the network. LDP is just required between the two PEs in order to succesfully run l2vpn. You absolutely do not need ldp-tunneling for that purpose. The targeted LDP session started by ldp-tunneling on one side and running ldp on the tunnel interface on the other side will not help as l2vpn starts its own targeted LDP session. For the FEC to be...Reply
- Re: Pseudowire over MPLS-TE Tunnelsg.rodegari@lutech.it29.06.2007 05:59 Hello Harold, thank you for your suggestions.Sorry, but, probably I didn't explane well myself. Actually L2vpn is just one application, we should have also L3VPN... The more general stuff is that I need to transport LDP information from one island to an other island through RSVP backbone. Thanks G. Reply
- Re: Pseudowire over MPLS-TE Tunnelshritter29.06.2007 06:34Graziano, Thanks for the additional info. It shouldn't be a problem to get the JunOS ldp-tunneling to work with the IOS ldp over the TE tunnel interface. As I said, for the FEC received from the targeted LDP session to be used, you need routes to be installed in the FIB with a next hop via the tunnel interface (or the LSP on the JunOS side). Then in your case, you need to make sure the LDP peer id (targeted LDP peer...Reply
- Re: Pseudowire over MPLS-TE Tunnelsjiangu30.06.2007 00:54So the question drills down to the following scenario: two routers, Cisco and Juniper, they are on two ends of a RSVP domain, you want to tunnel LDP over this RSVP domain, you have configured "tag switching ip" on Cisco's TE interface and "ldp-tunneling" on Juniper's RSVP-LSP, and targeted LDP session is established between Cisco and Juniper, but LDP is not using prefix-FECs advertised from either side. At this stage, the only reason a...Reply
- Re: Pseudowire over MPLS-TE Tunnelshritter30.06.2007 05:07Jian, Depending on the topology, enabling ospf shortcuts might not be sufficient as this will only impact the BGP learnt routes. If IGP routes need to be resolved via the LSP, the mpls traffic-engineering bgp-igp needs to be configured on the JunOS side. At the end of the day, it largely depends on the topology and whether the TE LSPs are end to end between the PEs. If they are then there is no need to use LDP at all (except for...Reply
- Re: Pseudowire over MPLS-TE Tunnelshritter30.06.2007 05:26 Forget my comment about the bgp-igp since if the tunnel was between the core routers you wouldn't need to install the route in inet.0 anyway. The only route that would matter in the core would be the one in mpls.0. Regards,Reply
- More Replies
- RSVP TE FRRgauravprakash2 Replies18.12.2009 01:41 Hi, I have a ring of 8 routers in a ring runing OSPF , can detect LOS ,so I want to implement RSVP TE with FRR. For Traffic going from R1 to R4, it will use the Primary Tunnel R1--R2 and then r3, and finally arrive r4. If link between R1--R2 fails, will the traffic quickly move to Backup NNhop tunnel ( as shown in diagram) and hence the user traffic which was sourced behind R1 and wanted to reach destination behind r4 will follow this path r1--r8---r7---r6---r5---r4---r3-----r2-----r3---r4 . As I understand that the Primary FRR & Backup TE Tunnel will have same destination ( its mandatory.. right ?). This creates unwanted traffic on R4--R3--R2 segment...as long as the R1--R2 link is down. Is this the design problem with One hop tunnel.. ? My friend say after link failure on R1--R2, IGP convergence will take place and this unwanted upstream movement of user traffic will stop. He couldn't explain why ? Can somebody explain ... Thx, GauravSubscribe Reply
- Re: RSVP TE FRRshivlu17.12.2009 23:56 On failure of R1-R2 link, traffic will follow the backup tunnel. There will not be unwanted traffic on R3-R2 because the backup tunnel is from R4 to R1 via R8. So don't worry about that designers have already taken care about that. regards shivlu jain MPLSVPNReply
- Re: RSVP TE FRRgauravprakash18.12.2009 01:41Hi Shivlu, Thx , perhaps I did not get that ....The primary tunnel is one hop tunnel and my backup tunnel is multi hop away ( may be I shud not use NNHOP earlier )..I guess the backup Tunnel shud have the same destination as Primary , so it will traverse all the ring ( other way) and then reach R2 , then move towards R4. So there is extra traffic from R4----R3---R2 while the traffic ( source behind R1 & destination behind R4 )...Reply
- MPLS TE Tunnelsgalo6 Replies26.02.2005 09:04 If I configure a single tunnel from PE-PE with 1500K specified as the bandwidth and I have multiple simple VPNs configured on both ends am I correct in assuming the bandwidth specified on the headend tunnel would dedicate 1500k to each VPN or is the 1500k shared by all the VPNs? I did try assigning a vrf per tunnel interface but failed to pass any VPN traffic from PE to PE. If anyone can point out a link covering all details surrounding MPLS TE that would be great! Thanks in advance!Subscribe Reply
- Re: MPLS TE Tunnelshritter22.02.2005 20:58 The bandwidth is actually shared by all traffic traversing. You wouldn't get 1500K per VRF but rather 1500K for all. You could try allocating 1 tunnel per VRF but that could easily become a management nightmare. Hope this helps,Reply
- Re: MPLS TE Tunnelsgalo22.02.2005 21:16 Funny I did try assigning vrf forwarding instances to the tunnel interface but failed to pass any traffic. Is there a link? I probably missed a step. Thanks In Advance!Reply
- Re: MPLS TE Tunnelshritter22.02.2005 21:35 You can't assign a VRF to the tunnel interface. You would need to the following: Advertise BGP updates for each VRF with a different BGP next-hop using the following command: ip vrf xxx bgp next-hop looopback (x) On the other PE, point a static route for each BGP nexthop via a different tunnel. Hope this helps,Reply
- Re: MPLS TE Tunnelsgalo24.02.2005 11:22 I tried the above command in my lab. Unfortunately that feature is not available to me. I'm on mainline 12.2.24a. What version have you successfully executed that command with?Reply
- Re: MPLS TE Tunnelshritter24.02.2005 18:57 This command is only available in 12.0S. Alternately, you could configure a route-map that matches on the different route targets and set the next-hop accordingly and apply this route-map to the VPNv4 neighbor(s). Hope this helps,Reply
- Re: MPLS TE Tunnelsgalo26.02.2005 09:04I finally decided on using the MPLS TE tunnels to guarantee the bandwidth and to rate limit each VRF @ the ingress. This way I keep all clients to a 1.5mb pipe per VPN, allow MPLS to maintain the integrity/security between VPNs, and RSVP the bandwidth across the backbone. As for my original idea: “You could try allocating 1 tunnel per VRF but that could easily become a management nightmare.” You were...Reply
- MPLS TE Tunnels configurationp.diaz2 Replies15.01.2009 08:04 Hello. I have the following doubt. What happens if I configure one TE tunnel in both ends. I have read that is enough configure only one side. ThanksSubscribe Reply
- Pseudowire over TE MPLSfrancisco_12 Replies13.05.2009 01:14 Has anyone used Pseudowire over Traffic Enginnering MPLS? What i would like to do is setup the MPLS TE using OSPF, built layer 3 tunnels between sites and then use Pseudowire to extend vlans over the TE MPLS tunnels and isolate the vlans using VRF-Lite. Advice pls.. FranciscoSubscribe Reply
- Re: Pseudowire over TE MPLSlaaubert23.04.2009 10:53 Hi Francisco, You can map a PW to a MPLS-TE tunnel via the PW-class: pseudowire-class TE encapsulation mpls preferred-path interface Tunnel0 ! interface Ethernet0/0 xconnect 1.1.1.1 10 pw-class TE ! HTH Laurent. Reply
- MPLS TE with MPLS VPNmaher@pd.jaring.my4 Replies14.10.2004 18:33 Hi there, I'm looking for some basic configuration to turn on mpls te over existing mpls vpn. Worried to effect mpls vpn customers. Perhaps a link would be great! thanks in advance. maherSubscribe Reply
- Re: MPLS TE with MPLS VPNhritter14.10.2004 13:24There is many scenarios involving TE and MPLS VPN. If you have MPLS TE from ingress to egress PE, the lsp used to go from one PE to the other is signalled using RSVP instead of LDP/TDP. If you configure TE between the core routers then you need to runn LDP/TDP on the tunnel interface for LDP to learn labels via that pseudo interface. This second scenario involves that at some point up to 3 labels (TE lsp label, IGP label, service...Reply
- Re: MPLS TE with MPLS VPNmaher@pd.jaring.my14.10.2004 17:11 Hi Hritter, Thanks for the explaination.Would be grateful to find some of the scenarios in the sample config. Which want would be better to go into MPLS TE with MPLS/VPN. Need to understand some of the basic of MPLS TE. thanks. maherReply
- MPLS over GRE Tunnelsefairbanks4 Replies30.03.2005 23:17 Is there an article anywhere showing a config for MPLS over GRE tunnels? I need to do this with 3725s... Thank you.Subscribe Reply
- Re: MPLS over GRE Tunnelshritter24.02.2005 20:40 You simply need to configure a GRE tunnel and add "mpls ip" on the tunnel. int tunnel 0 ip address 192.168.1.1 tunnel destination 2.2.2.2 tunnel source 1.1.1.1 mpls ip Hope this helps,Reply
- Re: MPLS over GRE Tunnelsefairbanks25.02.2005 07:10 Hritter, Do all routers in the path need to run some kind of IGP to pass label information? I am still having problems with nonadjacent BGP peers not sending MPLS tags. Also, when I type "sho ip bgp label" nothing is returned.Reply
- Re: MPLS over GRE Tunnelshritter25.02.2005 07:35 The routers between the tunnel endpoints need to be able to resolv tunnel endpoints only (no ldp required). Try "show ip bgp v a labels" to see the labels for VRF prefixes. Hope this helps, Reply
- Re: MPLS over GRE Tunnelsq-coelho30.03.2005 23:17 hi, You will need an IGP that knows how to find the remote tunnel end points as well as IGP running over the tunnels to find the BGP neighbours. Reply
- MPLS TE tunnels with DS-TEscytmax1 Reply15.08.2004 21:57 Dear Sir! I'll want to implement such task: I have a few MPLS VPN offices (for example VPN = C1), and I want to make 2 tunnels between any two of this PEs. First of this tunnel Tu10 is for LLQ-traffic (marked for example with ip prec = 5), and second tunnel Tu20 is for all other from this VPN = C1 traffic. I'm imlemented MPLS DS-TE in my core (between P and PE devices) with appropriate CBWFQ on physical ports between P and PE devices. And example of tunnel configuration: interface Tunnel10 description Use it only for LLQ traffic ip unnumbered Loopback0 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng no tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng priority 0 0 tunnel mpls traffic-eng bandwidth sub-pool 4096 tunnel mpls traffic-eng path-option 10 explicit name <name1> tunnel mpls traffic-eng path-option 20 explicit name <name2> tunnel mpls traffic-eng path-option 30 dynamic ! ! interface Tunnel20 description Use it for all other traffic -except LLQ ip unnumbered Loopback0 load-interval 30 tunnel destination 3.3.3.3 tunnel mode mpls traffic-eng tunnel mpls traffic-eng autoroute announce tunnel mpls traffic-eng path-option 10 explicit name <name3> tunnel mpls traffic-eng path-option 20 explicit name <name4> tunnel mpls traffic-eng path-option 30 dynamic tunnel mpls traffic-eng auto-bw frequency 300 Then, because I'm announce Tu20 in IGP, all traffic use this tunnel. But how can I forward all LLQ traffic down Tu10? 1) I cannot use static routing for it, because it cannot to see packet parameters (ip prec 5)? 2) I cannot use PBR, because it not supported on VRF interfaces (only for classification/marking, but it is not my task case)? 3) I cannot to announce Tu10 to IGP, because some other non-LLQ traffic can use it? How can I to solve the above task? Best regards, Maxim DenisovSubscribe Reply
- Re: MPLS TE tunnels with DS-TErajiva15.08.2004 21:57Maxim, One of the ways to solve this problem is to use different BGP next-hops for the prefixes (probably VoIP prefixes) that attract the LLQ-bound traffic . PE1----PE2 Either PE2 would need to change the next-hop from Loo0 to Loo10 (say) and advertise those (VoIP) VPN prefixes (for this VPN) to PE1, or let PE1 change the next-hop for the relevant prefixes via an import-map within that VRF. And then you could use the...Reply
- MPLS over a TE tunnelthedquoc2 Replies24.08.2006 12:45 Hi , I tried to configure MPLS over a TE tunnel by following this link : Implementing an MPLS VPN over TE Tunnels [MPLS] - Cisco Systems . The problem happened in this tunnel interface config : ---- ! interface Tunnel0 ip unnumbered Loopback0 no ip directed−broadcast no ip route−cache distributed tunnel destination 10.5.5.5 tunnel mode mpls traffic−eng tunnel mpls traffic−eng autoroute announce tunnel mpls traffic−eng path−option 10 dynamic end ! ---- The int tunnel 0 is always in "Tunnel0 is up, line protocol is down" state . My PE routers are 7304s(p-mz.122-27.SBC5) Please advice ! Thanks & RegardsSubscribe Reply
- Re: MPLS over a TE tunnelsean@managednetworks.com24.08.2006 11:56 If you do a "sh mpls traffic-engineering tunnels tunnel 0", was is the info that is displayed? Please let me know. Thanks.Reply
- Re: MPLS over a TE tunnelhritter24.08.2006 12:45Did you configure MPLS specific statements under your IGP (either ISIS or OSPF) as follow: OSPF: mpls traffic-eng router-id Loopback0 mpls traffic-eng area 0 ISIS: mpls traffic-eng router-id Loopback0 mpls traffic-eng <level-1|level-2> Also did you configure all interfaces for mpls traffic engineering between the headend and the tailend using the following statements: mpls traffic-eng tunnels ip...Reply
- MPLS VPN and MPLS TEokopp1 Reply07.11.2001 13:15 Hi, is it possible in MPLS network combine VPN and TE ? For example explicitly set path for VPN traffic through MPLS-TE tunnel. Could you recommend me any link or article or can you advise me how to do it ? thanks, OldaSubscribe Reply
Subscribe Start A New Discussion
Related Information
Updated: Aug 10, 2005