Tuesday, April 28, 2009

Mpls Lab#5: Frame mode MPLS TE

Hi all,

Here another Mpls Lab I used to troubleshoot TE problems with lab#4 (see previous post: Mpls Lab #4: using Mpls with cell-mode ATM )
The main goal here is configure PE - PE Traffic Eng tunnels with explicit paths.

First let's read the "Implementing an MPLS VPN over TE Tunnels" document on Ciscowiki



It's a simple mpls vpn topology with a single vrf "custA".
P-R1 has no need of MP-BGP, acts only as LSR.
Let's take a look to the TE part:



There are 3 preferred paths, each one with a reserved bw of 10Mbps.
Remind that TE tunnels are UNIDIRECTIONAL, so you need to configure two tunnels each PE router, for a total on 6 tunnels.

some configuration parts:
hostname PE-R2
!
ip vrf custA
rd 100:99
route-target export 100:99
route-target import 100:99
!
!-- igp routing with CE, single area ospf
router ospf 20 vrf custA
router-id 172.16.0.1
log-adjacency-changes
redistribute bgp 65000 subnets
network 172.16.0.1 0.0.0.0 area 0
!
!-- igp routing of ISP core
router ospf 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
router-id 10.10.0.2
log-adjacency-changes
network 10.0.0.2 0.0.0.0 area 0
network 10.0.0.9 0.0.0.0 area 0
network 10.10.0.2 0.0.0.0 area 0
!
!-- MP-BGP
router bgp 65000
bgp log-neighbor-changes
neighbor ISP peer-group
neighbor ISP remote-as 65000
neighbor ISP update-source Loopback0
neighbor ISP next-hop-self
neighbor 10.10.0.3 peer-group ISP
neighbor 10.10.0.5 peer-group ISP
!
address-family vpnv4
neighbor ISP send-community both
neighbor 10.10.0.3 activate
neighbor 10.10.0.5 activate
exit-address-family
!
address-family ipv4 vrf custA
redistribute ospf 20 vrf custA
no synchronization
exit-address-family


Here the most relevant parts of MPLS TE configurations with some comments:
hostname PE-R2
!
mpls traffic-eng tunnels !-- enable RSVP globally
!
interface FastEthernet1/1
description PE-R2 <-> PE-R3
ip address 10.0.0.9 255.255.255.252
mpls ip
mpls traffic-eng tunnels !-- enable RSVP on the interface
ip rsvp bandwidth 100000 !-- specify how many bw can be reserved (Kbps)
!
interface FastEthernet2/0
description PE-R2 <-> P-R1
ip address 10.0.0.2 255.255.255.252
mpls ip
mpls traffic-eng tunnels
ip rsvp bandwidth 100000
!
router ospf 1
mpls traffic-eng router-id Loopback0 !-- it's a GOOD IDEA use the same loopback of MP-BGP
mpls traffic-eng area 0
!
ip explicit-path name R2-R3-R1-R5 enable
next-address 10.0.0.10
next-address 10.0.0.6
next-address 10.0.0.14
!
ip explicit-path name R2-R1-R3 enable
next-address 10.0.0.1
next-address 10.0.0.5
!
interface Tunnel0
description R2 ->> R3 !-- tunnels are unidirectionals (so .. ->> )
ip unnumbered Loopback0 !-- same loopback as TE router-id, just to avoid problems
tunnel destination 10.10.0.3 !-- destination is TE router-id too
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 4 4 !-- mid-priority ,-)
tunnel mpls traffic-eng bandwidth 10000 !-- 10Mbps reserved
tunnel mpls traffic-eng path-option 10 explicit name R2-R1-R3
tunnel mpls traffic-eng path-option 20 dynamic !-- dynamic path, if explicit fails
no routing dynamic
!
interface Tunnel1
description R2 ->> R5 !-- you'll see this as "tunnel name" with "sh mpls traffic-eng tunnels brief"
ip unnumbered Loopback0
tunnel destination 10.10.0.5
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 4 4
tunnel mpls traffic-eng bandwidth 10000
tunnel mpls traffic-eng path-option 10 explicit name R2-R3-R1-R5
tunnel mpls traffic-eng path-option 20 dynamic
no routing dynamic
!

Note that the "mpls traffic-eng router-id Loopback0" under router ospf 1, combined with the bgp next-hop-self is important in order to have the traffic successfully flowing into the TE tunnel.
In fact, if you try to use other loopbacks as TE router-id or as tunnel sources/destinations, you can experience CEF failures (cef drops). [that's why my Mpls Lab #4 failed to work for 15 evenings ;-) ]
eg: a loopback 10 is used as router-id and tunnel source/destination, mp-bgp next-hop-self is not configured you see:
PE-R2#sh ip cef vrf custA 192.168.50.1 detail
192.168.50.1/32, version 17, epoch 0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with
Recursive rewrite via 10.10.0.5/32, tags imposed {26}
via 10.10.0.5, 0 dependencies, recursive
next hop 10.10.0.5, Tunnel1 via 10.10.0.5/32
valid adjacency
tag rewrite with
Recursive rewrite via 10.10.0.5/32, tags imposed {26} !-- that's a sort of l00p?
PE-R2#

Here Cef try to do a recursive resolution of the next hop, but it isn't in the vrf custA cef table, so packets are dropped.
Let's look at the correct cef entry:
PE-R2#sh ip cef vrf custA 192.168.50.1 detail
192.168.50.1/32, version 20, epoch 0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Tu1, point2point, tags imposed: {25 23}
via 10.10.0.5, 0 dependencies, recursive
next hop 10.10.0.5, Tunnel1 via 10.10.0.5/32
valid adjacency
tag rewrite with Tu1, point2point, tags imposed: {25 23}
PE-R2#

Here next-hop is resolved and labels are imposed correctly.

If you try to traceroute CE-R6 prefixes from R0:
CE-R0#traceroute 192.168.50.1

Type escape sequence to abort.
Tracing the route to 192.168.50.1

1 172.16.0.1 12 msec 4 msec 8 msec
2 10.0.0.10 [MPLS: Labels 25/23 Exp 0] 28 msec 28 msec 32 msec
3 10.0.0.6 [MPLS: Labels 21/23 Exp 0] 44 msec 24 msec 36 msec
4 172.16.0.9 [MPLS: Label 23 Exp 0] 20 msec 32 msec 24 msec
5 172.16.0.10 32 msec * 48 msec

Note also that the "autoroute announce" in the interface tunnel configuration doesn't permit to select which traffic must flow into the tunnel, that could be a problem if there are multiple CE connected to the same PE router with different vrfs. With this tunnel configuration, all traffic destined to the othe PE will flow into the TE tunnel.

No comments: