Configuration of Frame Mode MPLS

Date: Jul 28, 2010 By David Hucaby and Stephen McQuerry. Sample Chapter is provided courtesy of Cisco Press.

This chapter covers the background and configuration of frame mode Multiprotocol Label Switching (MPLS), discussing common configurations and features such as Configuring Basic MPLS, MPLS Traffic Engineering, and MPLS Virtual Private Networks.

This chapter covers the background and configuration of frame mode Multiprotocol Label Switching (MPLS). The following common configurations and features are discussed:

10-1: Configuring Basic MPLS—MPLS is a high-performance packet forwarding technology that is based on Layer 2 switching instead of relying only on Layer 3 routing. Routers use labels added between the Layer 2 and Layer 3 headers for forwarding decisions.
10-2: MPLS Traffic Engineering—Service providers can use traffic engineering on MPLS-enabled routers to route a customer's network traffic based on throughput and delay. Tunnels are created for label switch paths (LSP) using the Resource Reservation Protocol (RSVP).
10-3: MPLS Virtual Private Networks (VPN)—MPLS VPNs have separate virtual routing and forwarding (VRF) instances for each customer in addition to a global routing table that is used to reach other routers in the provider network. Each VRF has a 64-bit route distinguisher (RD) to keep each customer's IP subnet separate from other routing and forwarding tables. BGP route target communities are used in exchanging route information between routers.

10-1 Configuring Basic MPLS

Multiprotocol Label Switching (MPLS) is a high-performance packet forwarding technology based on Layer 2 switching instead of Layer 3 routing. Routers are configured for MPLS forward frames based on labels instead of traditional Layer 3 IP unicast routing that performs Layer 3 lookups on the destination address at each hop. MPLS labels are inserted between the Layer 2 and Layer 3 headers and can be pushed (added), popped (removed), swapped, or aggregated (removing the top label and performing a Layer 3 lookup).

MPLS is attractive to service providers because of its scalability and features. Providers can scale easier with MPLS than using Asynchronous Transfer Mode (ATM) or Frame Relay permanent virtual circuits (PVC). The traffic engineering features of MPLS enable providers to route traffic not just on a destination address but also on other factors such as bandwidth requirements and quality of service (QoS).
A label switch router (LSR) is any router or switch that implements label distribution and can forward packets based on labels. An edge-LSR is any router that performs label imposition (push) or label disposition (pop). An ATM LSR is an ATM switch that can act as an LSR. With ATM LSRs, cell switching is used for the label forwarding table.
MPLS-enabled routers communicate with each other using the Label Distribution Protocol (LDP). LSRs discover each other using hello packets, and peer relationships are maintained using keepalives. LSRs share label binding information with other LSRs. The label bindings build a forwarding equivalence class (FEC). A forwarding equivalence class is a group of IP packets forwarded in the same manner, over the same path, with the same forwarding treatment.
Routers still rely on Layer 3 routing protocols for determining the path a packet should take. However, routing information, along with VPN, traffic engineering, and QoS information, is sent to the data plane to build a label forwarding information base (LFIB) for optimal forwarding performance.

NOTE

The commands that follow are based on the IETF Label Distribution Protocol (LDP) that uses a different syntax for commands than the older proprietary Tag Distribution Protocol (TDP). Prior to Cisco IOS Software Release 12.4(2)T, LDP-related commands were saved in the configuration in the older syntax. Starting with Cisco IOS Software Release 12.4(2)T, commands are saved in the configuration as they are entered.

Configuration

(Required) Enable Cisco Express Forwarding (CEF):
```
(global) ip cef [distributed]
      
```
CEF must be enabled on all routers running MPLS and on interfaces receiving unlabeled IP packets. Core routers do not perform CEF switching but must have CEF enabled globally to exchange labels. Enter the distributed keyword if your router supports distributed CEF (dCEF). Use dCEF when you want your line cards (for example, VIP cards) to perform the express forwarding so that the route processor (RP) can handle routing protocols.

NOTE

dCEF is not compatible with the RSVP. If you plan on configuring MPLS traffic engineering with RSVP, you must use CEF and not dCEF.
(Required) Start MPLS packet switching:
```
(global and interface) mpls ip
      
```
You must enable MPLS forwarding both globally and on the router interfaces for which you want to participate in MPLS forwarding. This command enables label switching of IPv4 packets according to normally routed paths. (Additional configuration is needed to support traffic engineering, QoS, and VPNs.) When this command is entered, Label Distribution Protocol (LDP) hello and keepalives are sent and received on the interfaces enabled for MPLS.
(Optional) Select the distribution protocol either globally or on a particular interface:
```
(global) mpls label protcol {ldp | tdp}
```
-or-
```
(interface) mpls label protocol {ldp | tdp | both}
```
Starting with Cisco IOS Software Release 12.4(3), the default protocol changed from Cisco Tag Distribution Protocol (TDP) to the IETF LDP. When changing the protocol on an interface, you have the option of enabling both TDP and LDP. LSRs must run the same distribution protocol to establish a peer session and exchange label information.
(Optional) Manually configure the LDP identifier:
```
(global) mpls ldp router-id interface [force]
```
MPLS-enabled routers identify themselves in LDP messages using an identifier. By default, the identifier is the highest IP address of all loopback interfaces. If there are no loopback interfaces, the router uses the highest IP address of all active interfaces. You can manually configure the LDP identifier with this command. The router then uses whatever IP address is configured on the interface you specify. The IP address entered must be reachable by adjacent LSRs. A common symptom of having an unreachable LDP ID IP address is that the forwarding information base (FIB) is populated, but there is no information in the label information forwarding base (LFIB). By default, a router ID is not changed until the interface currently used for the router ID is shut down, the IP address on that interface changes or is removed, or the router is rebooted. You can use the force keyword to force the router to change the router ID.
(Optional) Enable the distribution of labels associated with the IP default route:
```
(global) mpls ip default-route
      
```
By default, Cisco routers will not distribute labels for the IP default route. Enter this command to enable dynamic switching of labels for a router's default route.
(Optional) Enable MD5 authentication between peers:
```
(global) mpls ldp neighbor ip-address password password-string
```
MD5 authentication can be configured to verify TCP communication between two LDP peers. Both peers must be configured to use the same password.
(Optional) Enable the MPLS LDP autoconfiguration feature for OSPF interfaces:
```
(router) mpls ldp autoconfig [area area-id]
```
Normally, you must enter the mpls ip command both globally and on each interface for which you want to send and receive LDP packets. This process might be time-consuming and prone to human errors when configuring a router with many interfaces. The autoconfiguration feature helps with these issues by automatically enabling LDP on every interface associated with an OSPF or IS-IS instance. Note that you still need to enable LDP globally. When configuring LDP autoconfiguration for OSPF, you can choose to only enable LDP for interfaces belonging to a particular area by entering the area keyword followed by the area number.
(Optional) Enable the MPLS LDP autoconfiguration feature for IS-IS interfaces:
```
(router) mpls ldp autoconfig [level-1 | level-2]
```
Like autoconfiguration for OSPF, you must first enter the global mpls ip command before you can allow the autoconfiguration feature. Optionally, you can allow autoconfiguration on interfaces configured for level-1 or level-2 routing by entering the level-1 or level-2 keywords, respectively.

Example

Figure 10-1 is used for this example. The three routers are configured for MPLS with manually configured LDP identifiers and MD5 peer authentication. Additionally, RouterB is configured for OSPF autoconfiguration for Area 0, and LDP is disabled on RouterA's FastEthernet0/0 interface.

Figure 10-1 Basic MPLS Configuration Example

RouterA
hostname RouterA
!
ip cef
mpls ip
mpls ldp router-id 1.1.1.1
mpls ldp neighbor 2.2.2.2 password C1sc0
!
interface fastethernet0/0
 ip address 172.16.0.1 255.255.0.0
 no mpls ip
!
interface fastethernet0/1
 ip address 172.17.0.1 255.255.0.0
 mpls ip
!
interface loopback 0
 ip address 10.1.1.1 255.255.255.255
!
interface loopback 1
 ip address 1.1.1.1 255.255.255.255
!
router ospf 1
 router-id 10.1.1.1
 network 172.16.0.0 0.0.255.255 area 0
 network 172.17.0.0 0.0.255.255 area 0
 network 10.1.1.1 0.0.0.0 area 0
 network 1.1.1.1 0.0.0.0 area 0


RouterB
hostname RouterB
!
mpls ip
mpls ldp router-id 2.2.2.2
mpls ldp neighbor 1.1.1.1 password C1sc0
mpls ldp neighbor 3.3.3.3 password C1sc0
!
interface fastethernet0/0
 ip address 172.17.0.2 255.255.0.0
!
interface fastethernet0/1
 ip address 172.18.0.1 255.255.0.0
!
interface loopback0
 ip address 10.2.2.2 255.255.255.255
!
interface loopback1
 ip address 2.2.2.2 255.255.255.255
!
router ospf 1
 router-id 10.2.2.2
 network 172.17.0.0 0.0.255.255 area 0
 network 172.18.0.0 0.0.255.255 area 0
 network 10.2.2.2 0.0.0.0 area 0
 network 2.2.2.2 0.0.0.0 area 0
 mpls ldp autoconfig area 0


RouterC
hostname RouterC
!
mpls ip
mpls ldp router-id 3.3.3.3
mpls ldp neighbor 2.2.2.2 password C1sc0
!
interface fastethernet0/0
 ip address 172.18.0.2 255.255.0.0
 mpls ip
!
interface fastethernet0/1
 ip address 172.19.0.1 255.255.0.0
 mpls ip
!
interface loopback0
 ip address 10.3.3.3 255.255.255.255
!
interface loopback1
 ip address 3.3.3.3 255.255.255.255
!
router ospf 1
 router-id 10.3.3.3
 network 172.18.0.0 0.0.255.255 area 0
 network 172.19.0.0 0.0.255.255 area 0
 network 10.3.3.3 0.0.0.0 area 0
 network 3.3.3.3 0.0.0.0 area 0

10-2 MPLS Traffic Engineering

Service providers can use traffic engineering on MPLS-enabled routers to route a customer's network traffic based on throughput and delay. Traffic engineering (TE) tunnels are created for label switch paths (LSP) using the RSVP. A tunnel interface represents the head of the LSP and is configured with a set of resource requirements (for example, bandwidth requirements, media requirements, and priority):

Topology and resource information is flooded using either IS-IS or OSPF. Traffic engineering extensions are added to the routing process to enable MPLS traffic engineering.
IS-IS routers must be configured to use the new style of IS-IS metric to support new type, length, and value objects (TLV) for traffic engineering. The new TLVs are 22 and 135 and have sub-TLVs that enable you to add properties to a link for purposes of traffic engineering.
The Shortest Path First (SPF) algorithm used by IS-IS and OSPF chooses the tunnel interface before choosing an alternative path over main interfaces.
Multiple tunnels might be configured to load-share traffic.

Configuration

(Required) Allow CEF and LDP as explained in Section 10-1.
(Required) Allow the MPLS traffic engineering feature:
```
(global) mpls traffic-eng tunnels
      
```
Before you can allow interfaces for traffic engineering, you must first allow traffic engineering globally.
(Required) Allow traffic engineering on interfaces:
```
(interface) mpls traffic-eng tunnels
      
```
When you have allowed MPLS traffic engineering globally, you can then allow it on interfaces. Configuring this command causes its resource information to be flooded into the appropriate interior gateway protocol (IGP) link-state database (either IS-IS or OSPF). This command also enables the interface to accept traffic engineering tunnel signaling requests.
(Required when using CAC with RSVP) Allow RSVP on an interface and specify the amount of bandwidth to reserve:
```
(interface) ip rsvp bandwidth [bandwidth]
```
This command enables the resource reservation protocol (RSVP) on the interface. You must enter this command if you use Call Admission Control (CAC) with RSVP. If you do not specify a bandwidth value, a default bandwidth value of 75 percent will be used.
Configure OSPF for MPLS traffic engineering.
1. (Required) Allow traffic engineering for each area:
```
(router) mpls traffic-eng area area-number
            
```
2. (Required) Set the traffic engineering router identifier:
```
(router) mpls traffic-eng router-id interface
            
```
  Unlike OSPF and MPLS router IDs, MPLS traffic engineering will not automatically set a router ID. The router ID will be the IP address on the interface you enter in this command. It is recommended that you use a loopback interface and that it match that of the interface used for the OSPF process router ID. The router ID is flooded to other routers and is used as the tunnel destination IP address.
Configure IS-IS for MPLS traffic engineering.
1. (Required) Allow traffic engineering:
```
(router) mpls traffic-eng {level-1 | level-2}
```
  You can choose to flood traffic engineering into IS-IS level-1 or level-2.
2. (Required) Set the traffic engineering router identifier:
```
(router) mpls traffic-eng router-id interface
            
```
3. (Required) Configure the router to generate and accept new-style TLVs:
```
(router)metric-style wide
            
```
  The original metric used by IS-IS does not support traffic engineering. You must enter this command to support the new type, length, value objects (TLV), and sub-TLVs used for traffic engineering.
  
  NOTE
  
  See RFC 3784, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)," for more on the new TLVs and sub-TLVs used for traffic engineering.
Create a tunnel interface:
```
(global) interface tunnel number
      
```
This command creates a new tunnel interface.
Assign an IP address to the tunnel interface:
```
(interface) ip unnumbered interface
      
```
Tunnel interfaces should be unnumbered because the tunnel interface represents a unidirectional link. It is recommended that you use a loopback interface for the interface value.
Set the tunnel destination IP address:
```
(interface) tunnel destination ip-address
      
```
The tunnel destination IP address should be set to the far-end router's IP address that was configured with the mpls traffic-eng router-id command under the IS-IS or OSPF router process.
Set the tunnel type to MPLS traffic engineering:
```
(interface) tunnel mode mpls traffic-eng
      
```
There are many types of tunnel interfaces (for example, GRE, 6to4, and so on), so you must manually set the interface type.
Configure the bandwidth for the tunnel:
```
(interface) tunnel mpls traffic-eng bandwidth bandwidth
      
```
The range of valid bandwidth values is 1–4294967295.
Configure a dynamic or explicit path option:
```
(interface) tunnel mpls traffic-eng path-option number { dynamic | explicit
{name path-name | identifier path-number}}
```
You can configure the tunnel to be dynamic, meaning the router will rely on the IS-IS or OSPF routing information to determine the best path for the tunnel. You can also manually define the path using the explicit option. If you choose to explicitly map out the tunnel path, you need to enter either a name or identifier to reference the configured path. The steps for configuring an explicit path follow:
1. Configure the explicit path (if applicable).
  - Enter IP explicit path configuration mode:
```
(global) ip explicit-path {name path-name | identifier path-number}
```
    The path-name or path-number should match what you configured with the tunnel mpls traffic-eng path-option command earlier.
  - Enter the IP addresses for each hop:
```
(explicit-path-configuration) next-address [loose | strict] ip-address
                  
```
  Enter the next IP addresses one at a time for the path you want the tunneled traffic to take. The loose and strict keywords are optional. The loose option tells the router that the previous address in the explicit path does not need to be directly connected to the next address. The router is therefore free to determine the path from the previous address to the next. The strict option tells the router that the previous address must be directly connected to the next address.
  
  NOTE
  
  The next IP address can be either the link (interface) IP address of the next-hop router or the MPLS node address (set with the mpls traffic-eng router-id interface router process command). However, for Cisco IOS releases 12.4(24)T and earlier, you cannot use a link address as the first hop followed by node addresses for subsequent hops. You do not have this restriction for releases after 12.4(24).
Allow the IGP (that is, IS-IS or OSPF) to use the tunnel when performing its SPF route calculation:
```
(interface) tunnel mpls traffic-eng autoroute announce
      
```
The only way to forward traffic onto a tunnel is to allow this feature or to configure a static route to the interface.
(Optional) Manually configure the metric used by the SPF calculation:
```
(interface) tunnel mpls traffic-eng autoroute metric absolute metric
      
```
You can allow the IGP to automatically assign the metric for the tunnel or manually configure the metric value using this command.

Example

Figure 10-2 is used for this example. RouterA is configured for MPLS traffic engineering. An explicit tunnel is configured with a backup dynamic tunnel. The tunnel is configured with a metric of 10 and announced to IS-IS so that IS-IS will consider the tunnel when it performs its SPF calculation.

Figure 10-2 MPLS Traffic Engineering Example

hostname RouterA
!
ip cef
mpls ip
mpls ldp router-id 1.1.1.1
mpls traffic-eng tunnels
!
interface fastethernet0/0
 ip address 10.1.1.5 255.255.255.252
 mpls ip
 ip router isis
 mpls traffic-eng tunnels
 ip rsvp bandwidth 512
!
interface loopback 0
 ip address 1.1.1.1 255.255.255.255
 ip router isis
!
router isis
 net 49.0001.0000.0000.0001.00
 is-type level-1
 metric-style wide
 mpls traffic-eng router-id loopback 0
 mpls traffic-eng level-1
!
interface tunnel 0
 ip unnumbered loopback 0
 tunnel destination 4.4.4.4
 tunnel mpls traffic-eng bandwidth 512
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng autoroute metric absolute 10
 tunnel mpls traffic-eng path-option 1 explicit name TUNNEL
 tunnel mpls traffic-eng path-option 2 dynamic
!
ip explicit-path name TUNNEL
 next-address 2.2.2.2
 next-address 4.4.4.4

10-3 MPLS Virtual Private Networks (VPN)

MPLS virtual private networks (VPN) offer greater scalability than Frame Relay or ATM overlay VPN solutions.
MPLS VPNs have a separate routing and forwarding (VRF) instance for each customer.
Each VRF has a 64-bit route distinguisher (RD) to keep each customer's IP subnet separate from other routing and forwarding tables.
Routers maintain a global routing table that is used to reach other routers in the provider's network.
BGP route target communities are used to exchange route information between routers.
There is a separate CEF and routing table for each VRF.

Configuration

Configure MPLS according to Section 10-1.
Create the VRF and enter into VRF configuration mode:
```
(global) ip vrf name
      
```
Every customer will have their own VRF.

Create a route distinguisher for the VRF:

(vrf) rd route-distinguisher

You must configure a route distinguisher for the VRF to be functional. This command adds an 8-byte value to an IPv4 prefix to create a VPN IPv4 prefix. The RD can be entered in one of the two formats shown in Table 10-1.

Table 10-1. RD Formats

Format	Example
16-bit autonomous system number: a 32-bit number	65501:1
32-bit IP address: a 16-bit number	192.168.0.1:1

Create a route target for import, export, or both import and export:
```
(vrf) route-target {import | export | both} route-target-community-number
      
```
This command creates a list of import and export route target extended communities for the VRF. Learned routes that carry the same extended community number as the route-target-community-number you configure can be either imported into the VRF or exported out of the VRF (or both). Extended communities follow the same format as RDs.
Associate the VRF with an interface facing a customer edge (CE) router:
```
(interface) ip vrf forwarding vrf-name
      
```
This command associates the VRF instance you created earlier in Step 2 with an interface. Configuring this command removes the IP address so you need to reconfigure the IP address after applying this command.
Configure the VRF instance under the BGP process:
1. Enter BGP configuration mode:
```
(global) router bgp autonomous-system-number
            
```
2. Enter the address family configuration mode for the VRF instance:
```
(router) address-family ipv4 vrf vrf-name
            
```
  Enter the VRF name you created earlier in Step 2.
3. Configure the customer edge neighbor:
```
(address-family) neighbor ip-address remote-as autonomous-system-number
            
```
  This command goes on the provider edge (PE) router and associates the VRF created in Step 2 with the BGP neighbor defined here under the VRF address family mode.
4. Activate the CE BGP neighbor:
```
(address-family) neighbor ip-address activate
            
```
Configure the provider edge (PE) to provider edge (PE) routing:
1. Enter BGP configuration mode:
```
(global) router bgp autonomous-system-number
            
```
2. Configure the PE BGP neighbor:
```
(router) neighbor ip-address remote-as autonomous-system-number
            
```
  There is a separate VRF instance for each customer and a global routing table. The global routing is created here by defining the BGP peers within the provider.
3. Activate the PE BGP neighbor:
```
(router) neighbor ip-address activate
            
```
4. Enter the vpn4 unicast address family:
```
(router) address-family vpnv4 unicast
            
```
  This address family configures an IPv4 unicast VPN routing instance that enables the PE routers to exchange BGP information with each other while still remaining separate from the customers' VRF instances.
5. Define and activate the PE BGP neighbors:
```
(address-family) neighbor ip-address remote-as autonomous-system-number
(address-family) neighbor ip-address activate
            
```
6. Allow extended communities for the PE BGP neighbor:
```
(address-family) neighbor ip-address send-community extended
            
```
  Configuring this command activates support for extended communities. Extended communities are necessary for route targets to work with VRFs.
  
  NOTE
  
  For more on BGP configuration, see Chapter 6, "IP Routing Protocols."

Example

Figure 10-3 is used in this example. The configuration that follows shows the configuration on the PE1 router. A VRF instance is created for Customer_A and Customer_B. For Customer_A, the router is configured to both import and export all routes tagged with the extended community 100:1. For Customer_B, the router is configured to both import and export all routes tagged with the extended community 100:2:

hostname PE1
!
ip cef
!
ip vrf Customer_A
 rd 100:1
 route-target both 100:1
!
ip vrf Customer_B
 rd 100:2
 route-target both 100:2
!
interface serial0/0
 ip address 192.168.1.5 255.255.255.252
 mpls ip
 description Link to PE
!
interface serial0/1
 ip address 192.168.1.9 255.255.255.252
 description Link to Customer_A
 ip vrf forwarding Customer_A
!
interface serial0/2
 ip address 192.168.1.13 255.255.255.252
 description Link to Customer_B
 ip vrf forwarding Customer_B
!
router bgp 100
 neighbor 192.168.1.6 remote-as 100
 neighbor 192.168.1.6 activate
 address-family vpnv4 unicast
 neighbor 192.168.1.6 remote-as 100
 neighbor 192.168.1.6 activate
 neighbor 192.168.1.6 send-community extended
 address-family ipv4 unicast vrf Customer_A
 redistribute connected
 neighbor 192.168.1.10 remote-as 65535
 neighbor 192.168.1.10 activate
 address-family ipv4 unicast vrf Customer_B
 redistribute connected
 neighbor 192.168.1.14 remote-as 65534
 neighbor 192.168.1.14 activate

Figure 10-3 MPLS VPN Example

References

Refer to the following recommended sources for further technical information about the MPLS topics covered here:

Definitive MPLS Network Designs, by Jim Guichard, Francois Le Faucheur, and Jean-Philippe Vasseur, Cisco Press, ISBN 1587051869.

MPLS Configuration on Cisco IOS Software, by Umesh Lakshman and Lancy Lobo, Cisco Press, ISBN 1587051990.

MPLS Fundamentals, by Luc DeGhein, Cisco Press, ISBN 1587051974.

MPLS and VPN Architectures, by Ivan Pepelnjak, Cisco Press, ISBN 1487050021.

MPLS and VPN Architectures, Volume II, by Ivan Pepelnjak, Jim Guichard, and Jeff Apcar, Cisco Press, ISBN 1587051125.

RFC 2547, "BGP/MPLS VPNs."

RFC 2702, "Requirements for Traffic Engineering Over MPLS."

RFC 2917, "A Core MPLS IP VPN Architecture."

RFC 3031, "Multiprotocol Label Switching Architecture."

RFC 3034, "Use of Label Switching on Frame Relay Networks Specification."

RFC 3036, "LDP Specification."

RFC 3063, "MPLS Loop Prevention Mechanism."

RFC 3032, "MPLS Label Stack Encoding."

RFC 3209, "RSVP-TE: Extensions to RSVP for LSP Tunnels."

RFC 3784, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering."