Sunday, January 22, 2012

MPLS Traffic Engineering Configuration


MPLS has been aptly defined as a layer "2.5" protocol. True to its roots, MPLS provides traffic engineering (TE) capabilities usually associated with L2 technologies such as ATM and Frame Relay, to L3 networks. Incorporating MPLS TE into an existing SP or large enterprise network can vastly improve the utilization of WAN links while also spreading out risk over them. In fact, this is the basis of how our largest IP backbones operate today.

In order to configure TE, the first step is to define a /32 TE loopback address on each router that is participating in the TE domain. Here, we have selected 10.88.47.x (clever? 0x8847 is the ether-type associated with MPLS unicast).

interface Loopback8847
description MPLS TE
ip address 10.88.47.1 255.255.255.255
ip ospf 1 area 0
end

Note that we have placed the interface in OSPF area 0 which has been prepared to participate the TE domain as the IGP.

router ospf 1
mpls ldp sync
mpls ldp autoconfig
mpls traffic-eng router-id Loopback8847
mpls traffic-eng area 0

router-id 10.88.47.1
log-adjacency-changes
network 10.4.1.2 0.0.0.0 area 0
!

We have to ensure that RSVP is configured on all interfaces that will participate in the TE domain. RSVP signalling with the use of TE extensions enables the head-end router to provision tunnels to the destination.

interface Gi0/0
ip rsvp bandwidth

Next, we configure the TE tunnel itself:

interface Tunnel9001
description MPLS TE tunnel to R6
ip unnumbered Loopback8847
ip ospf interface-retry 0
tunnel destination 10.88.47.6
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 3 3
tunnel mpls traffic-eng bandwidth 16
tunnel mpls traffic-eng path-option 1 dynamic
tunnel mpls traffic-eng fast-reroute
no routing dynamic
end

Notice the IGP interaction with MPLS TE when you examine the new type 10 "opaque-area" LSAs under OSPF. These LSAs are flooded throughout the area.

Type-10 Opaque Link Area Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Opaque ID
1.0.0.0 10.88.47.1 824 0x8000001F 0x006688 0
1.0.0.0 10.88.47.5 760 0x80000027 0x0007B9 0
1.0.0.0 10.88.47.6 626 0x80000022 0x008EAC 0
1.0.0.1 10.88.47.1 571 0x80000023 0x00A30E 1
1.0.0.1 10.88.47.5 1016 0x8000001F 0x009239 1

The rich texture of the LSAs is revealed here:

LS age: 781
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 10.88.47.5
LS Seq Number: 80000027
Checksum: 0x7B9
Length: 140
Fragment number : 0

MPLS TE router ID : 10.88.47.5

Link connected to Point-to-Point network
Link ID : 10.88.47.6
Interface Address : 10.8.1.5
Neighbor Address : 10.8.1.6
Admin Metric : 1562
Maximum bandwidth : 8000
Maximum reservable bandwidth : 6000
Number of Priority : 8
Priority 0 : 6000 Priority 1 : 6000
Priority 2 : 6000 Priority 3 : 3000
Priority 4 : 2000 Priority 5 : 2000
Priority 6 : 2000 Priority 7 : 2000
Affinity Bit : 0x0
IGP Metric : 1562

Number of Links : 1

You can now verify MPLS - CEF interaction and confirm that the TE tunnels are up:

R1#show ip cef 172.31.254.6 detail
172.31.254.6/32, epoch 0, per-destination sharing
local label info: global/36
nexthop 10.88.47.6 Tunnel9002
nexthop 10.88.47.6 Tunnel9001

Finally, you can view the TE tunnel summary:

R1#show mpls traffic-eng tunnels summ
Signalling Summary:
LSP Tunnels Process: running
Passive LSP Listener: running
RSVP Process: running
Forwarding: enabled
Head: 2 interfaces, 2 active signalling attempts, 2 established
5 activations, 3 deactivations
0 SSO recovery attempts, 0 SSO recovered
Midpoints: 0, Tails: 0
Periodic reoptimization: every 3600 seconds, next in 2972 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: every 300 seconds, next in 273 seconds

Friday, January 20, 2012

Verifying MPLS labels with CEF

Here is a quick and dirty way to verify that the expected labels are being imposed. This is especially useful within the SP core to verify MPLS LDP behavior and assist in troubleshooting, because we often have an inner and an outer label:

R6#show ip cef vrf blue serial 1/1:0 detail
IP CEF with switching (Table Version 23), flags=0x0
10 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 27
14 instant recursive resolutions, 0 used background process
96 leaves, 88 nodes, 95448 bytes, 1498 inserts, 1402 invalidations
0 load sharing elements, 0 bytes, 0 references
universal per-destination load sharing algorithm, id DCD67B0C
6(2) CEF resets, 43 revisions of existing leaves
Resolution Timer: Exponential (currently 1s, peak 2s)
0 in-place/0 aborted modifications
refcounts: 23311 leaf, 23040 node

Table epoch: 0 (10 entries at this epoch)

Adjacency Table has 9 adjacencies
7 IPv4 adjacencies
2 IPv6 adjacencies
10.4.1.2/32, version 20, epoch 0, cached adjacency to Serial1/1:0
0 packets, 0 bytes
via 10.8.1.5, Serial1/1:0, 0 dependencies
next hop 10.8.1.5, Serial1/1:0
valid cached adjacency
172.16.100.0/24, version 22, epoch 0, cached adjacency to Serial1/1:0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Se1/1:0, point2point, tags imposed: {28 41}
via 172.31.254.1, 0 dependencies, recursive
next hop 10.8.1.5, Serial1/1:0 via 172.31.254.1/32
valid cached adjacency
tag rewrite with Se1/1:0, point2point, tags imposed: {28 41}

BGP MPLS VPN Example







I hope to explain to you, curious reader, the essence behind the technique to configure a RFC 2547 BGP/MPLS VPN.

First, we create "loopback" interfaces (Lo1000 used here) on all three routers used in this example.

Next, we enable MPLS forwarding on the interfaces that participate in the forwarding path. Please note that R5 is acting as the "P" router, and R1 and R2 are "PE/CE" routers. The VRF instance "blue" represents the CE network.

R6 interfaces is shown here as an example:

interface Serial1/1:0
bandwidth 64
ip address 10.8.1.6 255.255.255.0
encapsulation ppp
mpls ip
no fair-queue
end

Next, we enable IGP in the "P" core. Here we use OSPF and place the interfaces in Area 0. Notice the special LDP commands included under OSPF to facilitate interaction with MPLS LDP.

router ospf 1
mpls ldp sync
mpls ldp autoconfig
mpls ldp autoconfig area 0

log-adjacency-changes
network 10.4.1.1 0.0.0.0 area 0
network 10.8.1.0 0.0.0.255 area 0

Now, we can verify MPLS LDP operation with the following commands:

show mpls forwarding table

Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
25 Untagged 172.16.100.0/24 4872 Fa0/0 10.7.1.2
26 Untagged 172.30.3.0/24 12615289 Fa0/0 10.7.1.2
27 Pop tag 192.168.200.0/24 5800 Se1/1:0 point2point
28 Pop tag 172.31.254.1/32 10771 Fa0/1 10.4.1.2
30 Untagged 10.8.1.6/32 0 Se1/1:0 point2point
31 Pop tag 10.10.10.10/32 0 Fa0/1 10.4.1.2
32 Pop tag 172.31.254.6/32 9321 Se1/1:0 point2point


We now proceed to configure BGP with multi-protocol extensions as follows:

router bgp 65001
no synchronization
bgp log-neighbor-changes
neighbor 172.31.254.6 remote-as 65001
neighbor 172.31.254.6 update-source Loopback1000
no auto-summary
!
address-family vpnv4
neighbor 172.31.254.6 activate
neighbor 172.31.254.6 send-community extended
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
no synchronization
exit-address-family
!

Let's check that BGP has established a neighbor relationship and is receiving the routes in the VRF (blue):

R1#show ip bgp vpnv4 vrf blue
BGP table version is 5, local router ID is 200.200.200.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:10 (default for vrf blue)
*> 172.16.100.0/24 0.0.0.0 0 32768 ?
*>i172.16.106.0/24 172.31.254.6 0 100 0 ?

Note the RT extended community:

R1#show ip bgp vpnv4 vrf blue 172.16.106.0
BGP routing table entry for 100:10:172.16.106.0/24, version 5
Paths: (1 available, best #1, table blue)
Not advertised to any peer
Local
172.31.254.6 (metric 1564) from 172.31.254.6 (192.168.91.6)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:100:10
mpls labels in/out nolabel/17

Note the MPLS label imposition - there are two labels imposed:

R1#show mpls forwarding-table vrf blue 172.16.106.0 detail
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
None 17 172.16.106.0/24[V] \
0 Gi0/0 10.4.1.1
MAC/Encaps=14/22, MRU=1496, Label Stack{32 17}
00011FBE98010013C32C2CD88847 0002000000011000
VPN route: blue
No output feature configured

Finally, we can verify that we have connectivity:

R1#ping vrf blue 172.16.106.6
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.106.6, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/9/12 ms
R1#
1340399: Jan 20 10:01:36: MPLS les: Gi0/0: rx: Len 118 Stack {41 0 254} - ipv4 data
1340400: Jan 20 10:01:36: ICMP: echo reply rcvd, src 172.16.106.6, dst 172.16.100.1

You may wonder why R1 is receiving label 41. We need to examine R6 for an explanation:

R6#show mpls forwarding-table vrf blue 172.16.100.0 detail
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
None 41 172.16.100.0/24 0 Se1/1:0 point2point
MAC/Encaps=4/12, MRU=1496, Tag Stack{28 41}
FF030281 0001C00000029000
No output feature configured
Per-packet load-sharing

Monday, January 16, 2012

Configuring a basic MPLS VPN

MPLS – basic configuration with IOS

MPLS – sounds overwhelming? Well, it shouldn't be! Here how simple it can be:

Let’s consider a very basic but fully functional RFC 2547 BGP MPLS VPN. Here we have two routers R1 and R5, and both run Cisco IOS (12.4).

R1 [Gi0/0] --- [Fa0/1] R5

The first step is to enable “mpls ip”

Next, it’s a good idea to specify LDP as the label protocol (it is the default, but we do this for “completeness”)

R5#show run | i mpls
mpls label protocol ldp

We also have to enable “mpls ip” under the interfaces that will particpate (Gi0/0 and Fa0/0 in our case).

Now, let’s work on the VRF – we’ll call it “blue” here in our example:

ip vrf blue
rd 100:10
route-target export 100:10
route-target import 100:10

The syntax varies with a 2821 router:

vrf definition blue
rd 100:10
!
address-family ipv4
route-target export 100:10
route-target import 100:10
exit-address-family
!

At this point the LDP adjacency should form, but it didn’t! What happened?

On R5, LDP associated itself with a Loopback address that was not reachable from R1. Therefore we specify a LDP router-id:
R5(config)#mpls ldp router-id fastEthernet 0/1 force

R5#show mpls ldp discovery
Local LDP Identifier:
10.4.1.1:0
Discovery Sources:
Interfaces:
FastEthernet0/0 (ldp): xmit
FastEthernet0/1 (ldp): xmit/recv
LDP Id: 200.200.200.200:0

R5#show mpls ldp neigh
Peer LDP Ident: 10.4.1.2:0; Local LDP Ident 10.4.1.1:0
TCP connection: 10.4.1.2.27911 - 10.4.1.1.646
State: Oper; Msgs sent/rcvd: 40/46; Downstream
Up time: 00:00:14
LDP discovery sources:
FastEthernet0/1, Src IP addr: 10.4.1.2
Addresses bound to peer LDP Ident:
10.4.1.2 10.4.1.4 172.16.1.2 192.168.100.1
10.10.10.254 192.168.254.1 192.168.254.193 10.10.10.10
10.0.0.1 10.200.200.1 13.0.0.1 192.168.10.1
192.168.11.11 12.0.0.1 200.200.200.200 10.5.13.1
16.0.0.1 172.16.50.1 10.4.1.3 10.88.47.1

Ah! We have an adjacency now.

R1#show mpls ldp neighbor
Peer LDP Ident: 10.4.1.1:0; Local LDP Ident 10.4.1.2:0
TCP connection: 10.4.1.1.646 - 10.4.1.2.27911
State: Oper; Msgs sent/rcvd: 46/40; Downstream
Up time: 00:00:07
LDP discovery sources:
GigabitEthernet0/0, Src IP addr: 10.4.1.1
Addresses bound to peer LDP Ident:
10.7.1.1 10.7.1.5 10.4.1.1 172.16.5.5
10.9.1.1 192.168.55.5 55.0.0.55 60.0.0.5
172.16.50.5 1.1.1.1

We can now check LDP bindings:

Show mpls ldp bindings
Show mpls forwarding-table

Next, we configure BPG vpnv4 address-family thusly:

address-family vpnv4
neighbor 10.4.1.1 activate
neighbor 10.4.1.1 send-community extended
exit-address-family
!
address-family ipv4 vrf blue
redistribute connected
no synchronization
network 172.16.100.0 mask 255.255.255.0
exit-address-family
!

Here we verify the BGP speakers are exchanging VRF blue routes:

R1#show ip bgp vpnv4 vrf blue
BGP table version is 7, local router ID is 200.200.200.200
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:10 (default for vrf blue)
*> 172.16.100.0/24 0.0.0.0 0 32768 i
*> 172.16.105.0/24 10.4.1.1 0 0 65005 i

We can examine the labels:
R1#show ip bgp vpnv4 vrf blue labels
Network Next Hop In label/Out label
Route Distinguisher: 100:10 (blue)
172.16.100.0/24 0.0.0.0 22/nolabel(blue)
172.16.105.0/24 10.4.1.1 nolabel/27

Let's debug and observe:

debug mpls packet

R1#
1281051: Jan 16 13:17:27: MPLS les: Gi0/0: rx: Len 118 Stack {22 0 255} - ipv4 data
1281052: Jan 16 13:17:27: MPLS les: Gi0/0: rx: Len 118 Stack {22 0 255} - ipv4 data
1281053: Jan 16 13:17:27: MPLS les: Gi0/0: rx: Len 118 Stack {22 0 255} - ipv4 data
1281054: Jan 16 13:17:27: MPLS les: Gi0/0: rx: Len 118 Stack {22 0 255} - ipv4 data
1281055: Jan 16 13:17:27: MPLS les: Gi0/0: rx: Len 118 Stack {22 0 255} - ipv4 data