> MultiProtocol Label Switching (MPLS) Support
> This chapter describes the system’s support for Multi Protocol Label Switching (MPLS) and explains how it is configured. The product administration guides provide examples and procedures for configuration of basic services on specific systems. It is recommended that you select the configuration example that best meets your service model and configure the required elements for that model, as described in the respective product administration guide, before using the procedures in this chapter.
> When enabled through a feature license key, the system supports MPLS to provide a VPN from the GGSN/PDSN to the corporate's network. In this VPN, an APN that terminates on one GGSN/PDSN can change and terminate on another.
> MPLS is used to negotiate the routes and segregate the traffic. The GGSN/PDSN learns the default route from the connected Provider Edge (PE), while the PE populates its routing table with the routes provided by the GGSN/PDSN.
> This chapter includes following sections:

> • | Overview

> • | Configuring MPLS with Static Labels

> Overview
> As seen in the following scenario, the chassis can be deployed as a router while supporting MPLS in a network.

> • | Chassis as MPLS-Customer Edge (MPLS-CE) with Provider Edge (PE)

> Chassis as MPLS-CE with PE
> Chassis as MPLS-CE with PE
> The system in this scenario uses static MPLS labels for ingress and egress traffic. For configuration information on static label, refer to the Configuring MPLS over BGP with Static Labels section.
> The system is in a separate autonomous system (AS) from the Provider Edge (PE). It communicates with the PE and routes for all VPNs supported on the PE that are exchanged with the system. Routes belonging to different VPNs are logically separated, using separate virtual route forwarding tables (VRFs).
> Routes for each VPN are advertised as VPN-IPv4 routes, where route distinguishers are prepended to regular IPv4 routes to allow them to be unique within the routing table. Route targets added to the BGP extended community attributes identify different VPN address spaces. The particular upstream BGP peer routing domain (VPN), from which a route is to be imported by the downstream peer into an appropriate VRF, is identified with an extended community in the advertised NLRI, which is in fact an MPLS label.
> The Customer Edge (CE) also advertises routes to the PE using NLRIs that include route distinguishers to differentiate VPNs, and extended community MPLS labels to identify VRFs.
> There is a single MPLS-capable link between the CE and the PE. MP-BGP communicates across this link as a TCP session over IP. Data packets are sent bidirectionally as MPLS encapsulated packets.
> This solution does not use any MPLS routing protocols. The MPLS label corresponding to the immediate upstream neighbor is statically configured on the downstream router, and similarly in the reverse direction.
> When forwarding subscriber packets in the upstream direction to the PE, the CE encapsulates packets with MPLS headers that identify the upstream VRF (the label sent as an extended community with the NLRI) and the immediate next hop. When the PE receives a packet it switches the label to an MPLS-labeled packet.
> The CE does not run any MPLS routing protocol (LDP or RSVP-TE).
> When receiving data packets in the downstream direction from the PE, the label is checked to identify the destination VRF. Then the packet is de-encapsulated into an IP packet and sent to the session subsystem for processing.
> Important: MPLS ping/trace route debugging facilities are not supported.
> Engineering Rules

> • | Up to 100 virtual routing tables per context. This allows up to 100 BGP-VPNs per context.

> • | Up to 5k “host routes” spread across multiple VRFs per BGP process. Limited to 6000 pool routes per chassis.

> • | Up to 1024 VRFs per chassis.

> Benefits
> MPLS provides networks with a more efficient way to manage applications and move information between locations. MPLS prioritizes network traffic, so administrators can specify which applications should move across the network ahead of others.
> Supported RFCs
> The following RFCs related to MPLS are partially supported:

> • | IETF RFC 4364 BGP/MPLS IP VPNs

> • | IETF RFC 3032 MPLS Label Stack Encoding

> Configuring MPLS over BGP with Static Labels
> This section describes the procedures required to configure the system as an MPLS-CE to interact with a PE with static MPLS label support.
> The base configuration, as described in the Routing chapter of the System Enhanced Feature Configuration Guide, must be completed prior to attempt the configuration procedure described below.
> Important: Commands used in the configuration samples in this section provide base functionality to the extent that the most common or likely commands and/or keyword options are presented. In many cases, other optional commands and/or keyword options are available. Refer to the Command Line Interface Reference for complete information regarding all commands.
> To configure the system for MPLS:

> Step 1 | Create a VRF on the router and assign a VRF-ID by applying the example configuration in the Create VRF with Route-distinguisher and Route-target section.

> Step 2 | Set the neighbors and address family to exchange routing information with a peer router by applying the example configuration in the Set Neighbors and Address Family section.

> Step 3 | Redistribute connected routes between routing domains by applying the example configuration in the Redistribute Connected Routes section.

> Step 4 | Establish BGP peering with peer router by applying the example configuration in the Establish BGP Peering with Peer Router section.

> Step 5 | Configure the address family and redistribute the connected routes into BGP by applying the example configuration in the Configure Address Family section. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.

> Step 6 | Configure IP Pools with MPLS labels for input and output by applying the example configuration in the Configure IP Pools with MPLS Labels section.

> Step 7 | Optional. Bind DHCP service to work with MPLS labels for input and output by applying the example configuration in the Bind DHCP Service with MPLS Labels Bind DHCP Service with MPLS Labels section.

> Step 8 | Save your configuration as described in the Verifying and Saving Your Configuration chapter in this guide.

> Create VRF with Route-distinguisher and Route-target
> Use this example to first create a VRF on the router and assign a VRF-ID. The second ip vrf command creates the route-distinguisher and route-target.
> configure
> context <context_name> -noconfirm
> ip vrf <vrf_name>
> router bgp <as_number>
> ip vrf <vrf_name>
> route-distinguisher <as_value>
> route-target export <as_value>
> end
> Set Neighbors and Address Family
> Use this example to set the neighbors and address family to exchange routing information with a peer router.
> configure
> context <context_name>
> ip vrf <vrf_name>
> router bgp <as_number>
> ip vrf <vrf_name>
> neighbor <ip_address> remote-as <AS_num>
> address-family <type>
> neighbor <ip_address> activate
> end
> Redistribute Connected Routes
> Use this example to redistribute connected routes between routing domains.
> configure
> context <context_name>
> ip vrf <vrf_name>
> router bgp <as_number>
> ip vrf <vrf_name>
> address-family <type> vrf <vrf_name>
> redistribute connected
> exit
> redistribute connected
> end
> Establish BGP Peering with Peer Router
> Use this example to establish BGP peering with peer router.
> configure
> context <context_name>
> router bgp <as_number>
> neighbor <ip_address> remote-as <AS_num>
> address-family <type>
> neighbor <ip_address> activate
> end
> Configure Address Family
> Use this example to configure the address-family and to redistribute the connected routes into BGP. This takes any routes from another protocol and redistributes them to BGP neighbors using the BGP protocol.
> configure
> context <context_name>
> router bgp <as_number>
> address-family <type> vrf <vrf_name>
> redistribute connected
> exit
> redistribute connected
> end
> Configure IP Pools with MPLS Labels
> Use this example to configure IP Pools with MPLS labels for input and output.
> configure
> context <context_name> -noconfirm
> ip pool <name> <ip_addr_mask_combo> private vrf <vrf_name> mpls-label input <in_label_value> output <out_label_value1>
> interface <name> loopback
> ip address <ip_addr_mask_combo> srp-activate
> exit
> interface <name>
> ip address <ip_address subnet_mask>
> exit
> interface <name>
> ip address <ip_address subnet_mask>
> exit
> interface <name>
> ip address <ip_address subnet_mask>
> exit
> interface <name>
> ipv6 address <ip_addr_mask_combo>
> end
> Bind DHCP Service with MPLS Labels
> Use this example to bind DHCP service with MPLS labels for input and output.
> configure
> context <dest_ctxt_name>
> dhcp-service <dhcp_svc_name>
> bind address <ip_address> [ nexthop-forwarding-address <nexthop_ip_address> [ mpls-label input <in_mpls_label_value> output <out_mpls_label_value1> [ <out_mpls_label_value2> ]]]
> end
> Notes:

> • | To ensure proper operation, DHCP functionality should be configured within a destination context.

> • | Optional keyword nexthop-forwarding-address <nexthop_ip_address> [ mpls-label input <in_mpls_label_value> output <out_mpls_label_value1> [ out_mpls_label_value2 ]] applies DHCP over MPLS traffic.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883