SP L3/L2 VPN – Part II

L3/L2 VPN Part II

Okay – this is a huge section so bear with me – there are a ton of references at the bottom so please cross reference as you feel the need to.

MPLS-VPN: The Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) architecture provides service providers with a peer-to-peer model that combines the best features of overlay and peer-to-peer models. Prior to the introduction of the Inter-Autonomous System (Inter-AS) MPLS VPN feature, customer sites had to be connected to a single service provider AS.

This feature allows a VPN to cross more than one service provider backbone. It enables VPN sites to be connected across multiple service providers using different AS numbers and makes confederations possible within a service provider backbone. This optimizes internal Border Gateway Protocol (iBGP) meshing.

In a normal MPLS VPN scenario, the Customer Edge (CE) routers are connected to the Provider Edge (PE) routers in the same AS. The PE routers exchange VPN routes by using multiprotocol iBGP. This carries the 96-bit VPN version 4 (VPNv4) addresses along with route targets and the associated VPN label.

However, with the Inter-AS MPLS VPN feature, the CE routers are connected to PE routers in a different AS. The PE routers exchange VPN routes with the AS border router in the same AS using multiprotocol iBGP. The AS border routers of the different AS exchange VPN routes using multiprotocol external Border Gateway Protocol (eBGP).

For MPLS VPN to work properly, the VPN label must be allocated by the router. This router is indicated by the next-hop attribute of a route. In BGP, the next-hop attribute of a prefix is changed by a router when it advertises to a neighbor using eBGP. With the Inter-AS MPLS VPN feature, the next-hop address of a VPN route is changed by the AS border router. This occurs when the VPNv4 address is advertised to the border router of the neighboring AS. This is done through multiprotocol eBGP, along with a new label for the route.

The AS border router binds the new label with the label received for the same route. This is done from the PE router that originally advertised the prefix using multiprotocol iBGP and is called Label Switch Path (LSP) stitching. When the AS Boundary Router (ASBR) receives MPLS packets with the specially assigned label, it forwards the packets into the LSP that reaches the final destination. LSP stitching is used in MPLS VPN whenever the BGP next-hop attribute is changed. LSP stitching is done even when next-hop-self is configured for multiprotocol iBGP sessions. The Inter-AS MPLS VPN feature can also be used to divide an individual AS into a multiple sub-AS by using confederations to overcome iBGP full mesh requirements.

Like building a VPN inside one AS, the construction of a VPN that crosses several AS’s also concerns two aspects: one is the transfer of VPN information; the other is the building of VPN tunnel. After a few years practice, three methods are proposed in the industry for VPNs to cross domains. These three methods are Option A, Option B and Option C. Different options use different modes of VPN information transfer and different methods for VPN tunnel construction and are suitable for different scenarios.

Further, MPLS VPNs can be classified to MPLS/BGP L3VPN and MPLS L2VPN. The two types of VPN both support the above three Inter-AS options. However, as MPLS/BGP VPN is earlier and more widely applied, the corresponding Inter-AS methods are standardized. MPLS L2VPN lags behind in standardization, and the corresponding Inter-AS standards are not yet formally released. Mainstream vendors, nevertheless, have supported part or all these methods.

The Option A Inter-AS method is also known as the back-to-back method. Between PE and ASBR of a same AS, VPN route information is transferred over normal MBGP. Between ASBR’s, VPN route information is transferred through normal PE–CE route transfer method. For Option A, VPN tunnel construction is simple. Each AS constructs its own 2-layer LSP from PE to ASBR. The inner layer label indicates VPN information and the outer layer label is the public network label indicating the next hop PE of the VPN route. Like the building of LSP tunnel inside an AS, between ASBR and ASBR, naked IP forwarding is adopted without any LSP. Some Additional Notes ->

• ASBR needs to process VPN route information and requires the configuration of VRF instances.
• ASBR needs to allocate a physical or logical link for each VPN.
• A separate 2-layer LSP is built inside each AS and inter-ASBR transport relies on the IP network.
• Suitable for early stage of VPN service deployment when the number of VPNs is small.
• The downside of this configuration is that there needs to be one BGP session for each sub-interface (and at least one subinterface for each VPN), which causes scalability concerns as this network grows.

The Option B Inter-AS method is also known as the single-hop MP-EBGP method. Inside an AS, normal MPLS/BGP is used to transfer VPN information and construct the LSP tunnel. Between AS’s, the single-hop MP-EBGP is used to transfer VPN information and construct the LSP tunnel. When BGP is used to transfer route information, in the case of EBGP, the next hop will be changed to the local node itself, while in the case of IBGP; the next hop may and may not be changed to the local node itself. For instance, when MP-BGP is used to transfer VPN route information and the next hop is changed, another label must be allocated for the VPN. Some Additional Notes->
ASBR needs to process VPN information but does not need the configuration of VRF instances.

• Between two ASBR’s, one link is used to transfer all VPN information.
• Between two ASBR’s, a single-layer or 2-layer LSP tunnel is built depending on the scenario.
• When VPN service operation develops to a certain scale, inter-ASBR links are limited, and Option B can be adopted.
• The downside of this configuration is that because the traffic is MPLS, QoS mechanisms that can only be applied to IP traffic cannot be applied and the VRFs cannot be isolated.

The Option C Inter-AS method is also known as the multi-hop MP-EBGP method. Because BGP only requires TCP connection to form a BGP neighbor and transfer route information, the Option C method transfers VPN route information between the source and destination PE’s directly over multi-hop MP-EBGP, and constructs public network LSP tunnel between the source and destination PE’s. For Option C, VPN information transfer is simple. The information is transferred between the source and destination PE’s directly over multi-hop MP-EBGP. As shown in the figure above, a multi-hop MP-EBGP connection is established between PE2 and PE1 and VPN information is transferred from PE2 directly to PE1.

ASBR does not need to process VPN information, which best conforms to the VPN requirement that the intermediate equipment is not VPN-aware. Extended BGP is used to transfer the public network label. 3-layer labels appear in AS’s other than the destination AS. Option C can be used when VPN services grow to a large scale.

 For a detailed Inter-AS MPLS VPN Configuration example see the references section below.

Hybrid – Inter-AS Option AB:

The MPLS VPN—Inter-AS Option AB feature combines the best functionality of an Inter-AS Option (10) A and Inter-AS Option (10) B network to allow a Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) service provider to interconnect different autonomous systems to provide VPN services. These networks are defined in RFC 4364 section 10 “Multi-AS Backbones,” option “a” and option “b” respectively.

When different autonomous systems are interconnected in an MPLS VPN—Inter-AS Option AB configuration, the entire network’s configuration is scaled, simplified, and maintains IP Quality of Service (QoS) functions between Autonomous System Boundary Router (ASBR) peers.

• Benefits include Network configuration can be simplified because only one BGP session is configured for each VRF on the ASBR.
• One BGP session reduces CPU utilization.
• Networks can be scaled because a single MP-BGP session, which is enabled globally on the router, reduces the number of sessions required by multiple VPNs, while continuing to keep VPNs isolated and secured from each other.
• IP QoS functions between ASBR peers are maintained for customer SLAs.
• Data-plane traffic is isolated on a per-VRF basis for security purposes.

 Inter_AS/Carrier Supporting Carrier (CSC)

Deployments of Multiprotocol Label Switching (MPLS) have become routine in large-scale global networks, which demand solutions to complex business and network problems. There are two primary components of the Cisco IOS MPLS Inter-Domain Solution: Inter-AS and Carrier Supporting Carrier.

Inter-AS is a peer-to-peer type model that allows extension of VPNs through multiple provider or multi-domain networks. This solution enables Service Providers to peer up with one another and offer end-to-end VPN connectivity over extended geographical locations for those subscribers who may be out of reach for a single provider.

Carrier Supporting Carrier (CSC) is a hierarchical VPN model that allows small Service Providers, or customer carriers, to interconnect their IP or MPLS networks over an MPLS backbone. This eliminates the need for customer carriers to build and maintain their own MPLS backbone.

Both Inter-AS and CSC can construct scalable networks that help maintain network segmentation based on internal organizational or operational boundaries.

 VRF-Lite:

Virtual Private Networks (VPNs) provide a highly secure way for customers to share bandwidth over an ISP backbone network. A VPN is a collection of sites sharing a common routing table. A customer site is connected to the service provider network by one or more interfaces, and the service provider associates each interface with a VPN routing table. A VPN routing table is called a VPN routing/forwarding (VRF) table. VRFs are generally associated with MPLS based VPNs.

With the VRF-lite feature, multiple VPN routing/forwarding instances can be supported in customer edge devices. VRF-lite extends limited PE functionality to a CE device, giving it the ability to maintain separate VRF tables to extend the privacy and security of a VPN to the branch office. This also helps the customer to share the same CE for various internal departments while maintaining separate VRF table for each department.

 

VRF Select:

Otherwise known as VRF Selection – There are two methods – Based on source IP Address or based on policy-based routing

Source IP address  - The VPN Routing and Forwarding (VRF) Selection feature allows a specified interface on a provider edge (PE) router to route packets to different Virtual Private Networks (VPNs) based on the source IP address of the packet. This feature is an improvement over using a policy-based router to route packets to different VPNs.

Prerequisites for MPLS VPN:

• VRF Selection Based on Source IP Address
• MPLS VPNs must be enabled in the provider network.
• Restrictions for MPLS VPN: VRF Selection Based on Source IP Address
• VRF Select is supported only in Service Provider (-p-) images.

The Cisco IOS software must support MPLS VPNs, and the provider network must have MPLS Label Distribution Protocol (LDP) installed and running.

The VRF Selection feature is a unidirectional feature and can only be used from a customer (IP-based) network for a connection to a provider (MPLS-based) network and cannot be used from a provider network to a customer network.

Subnet masks should be kept as short as possible for the VRF Selection criteria for Engine 2 line cards. VRF Selection performance can degrade with longer subnet masks (/24 or /32, for example).

Cisco Express Forwarding (CEF) must be enabled on any interfaces that have the VRF Selection feature enabled. Distributed CEF is enabled by default on Cisco 12000 Series Internet routers.

An IP traceroute command from an MPLS VPN VRF Selection CE router to a typical MPLS VPN VRF CE router works as expected. However, an IP traceroute command from a typical MPLS VPN VRF CE router to an MPLS VPN VRF Selection CE router might fail to show all the relevant hop information across the core.

Information About MPLS VPN:

VRF Selection Based on Source IP Address

The VRF Selection feature allows packets arriving on an interface to be switched into the appropriate VRF table based upon the source IP address of the packets. Once the packets have been “selected” into the correct VRF routing table, they are processed normally, based on the destination address and forwarded through the rest of the Multiprotocol Label Switching (MPLS) VPN.

In most cases, the VRF Selection feature is a “one way” feature; it works on packets coming from the end users to the PE router.

VRF Selection Process

The VRF Selection feature uses the process described in this section to route packets from the customer networks to the PE router and into the provider network.

1. A two-table lookup mechanism is used at the ingress interface of the PE router to determine the routing and forwarding of packets coming from the customer networks, which use IP protocols, to the MPLS VPN networks, which use MPLS protocols.
2. The first table, the VRF Selection table, is used to compare the source IP address of the packet with a list of IP addresses in the table. Each IP address in the table is associated with an MPLS VPN. If a match is found between the source IP address of the packet and an IP address in the VRF Selection table, the packet is routed to the second table (the VRF table) or the routing table for the appropriate VPN.
3. If no match is found in the table for the source IP address of the packet, the packet is either routed via the global routing table used by the PE router (this is the default behavior), or is dropped. See the “Configuring a VRF to Eliminate Unnecessary Packet Forwarding: Example” section for more information.
4. The second table, the VRF table (also known as the VPN routing table), contains the virtual routing and forwarding information for the specified VPN and is used to forward the selected VPN traffic to the correct MPLS label switched path (LSP) based upon the destination IP address of the packet.
5. The VRF Selection process removes the association between the VPN and the interface and allows more than one MPLS VPN to be associated with the interface.

 

Policy-based routing (PBR) mechanism used to classify and forward Virtual Private Network (VPN) traffic based on multiple VPN routing and forwarding (VRF) selection match criteria.

Prerequisites for VRF Selection Using Policy Based Routing

•The router must support PBR to configure this feature. For platforms that do not support PBR, use the VRF Selection Based on Source IP Address feature introduced in Cisco IOS Release 12.0(22)S.

A VRF must be defined prior to the configuration of this feature. An error message is displayed on the console if no VRF exists.

This document assumes that multiprotocol BGP (mBGP), Multiprotocol Label Switching (MPLS), and Cisco Express Forwarding are enabled in your network.

Restrictions for VRF Selection Using Policy Based Routing

• VRF Select is supported only in Service Provider (-p-) images.
• The VRF Selection Using Policy Based Routing feature can coexist with the VRF Selection Based on Source IP address feature on the same router, but these features cannot be configured together on the same interface. This is designed behavior to prevent VRF table selection conflicts that could occur if these features were misconfigured together. An error message is displayed on the console if you attempt to configure the ip vrf select source and the ip vrf policy-map commands on the same interface.
• Protocol Independent Multicast (PIM) and multicast packets do not support PBR and cannot be configured for a source IP address that is match criteria for this feature.
• The set vrf command cannot be configured with the set default interface, set interface, set ip default next-hop, and set ip next-hop PBR commands, because a packet cannot be set to an interface and the next hop cannot be changed when a VRF is specified. This is designed behavior. An error message is displayed if you attempt to configure the set vrf command with any of the four set clauses.
• The VRF Selection Using Policy Based Routing feature cannot be configured with IP prefix lists.

VRF Selection Using Policy Based Routing

The VRF Selection Using Policy Based Routing feature is an extension of the VRF Selection Based on Source IP Address feature. The PBR implementation of the VRF selection feature allows you to policy route VPN traffic based on match criteria. Match criteria is defined in an IP access list or based on packet length. The following match criteria is supported in Cisco IOS software:

• IP Access Lists— Define match criteria based on IP addresses, IP address ranges, and other IP packet access list filtering options. Named, numbered, standard, and extended access lists are supported. All IP access list configuration options in Cisco IOS software can be used to define match criteria.
• Packet Lengths— Define match criteria based on the length of a packet in bytes. The packet length filter is defined in a route map with the match length route map configuration command.
• Policy routing is defined in the route map. The route map is applied to the incoming interface with the ip policy route-map interface configuration command. An IP access list is applied to the route map with the match ip address route map configuration command. Packet length match criteria is applied to the route map with the match length route map configuration command. The set action is defined with the set vrf route map configuration command. The match criteria is evaluated, and the appropriate VRF is selected by the set clause. This combination allows you to define match criteria for incoming VPN traffic and policy route VPN packets out to the appropriate VRF.

Policy Based Routing Set Clauses: Overview

When configuring PBR, the following four set clauses can be used to change normal routing and forwarding behavior:

• set default interface
• set interface  
• set ip default next-hop
• set ip next-hop

Configuring any of the above set clauses will overwrite normal routing forwarding behavior of a packet.

The VRF Selection Using Policy Based Routing feature introduces the fifth set clause that can be used to change normal routing and forwarding behavior. The set vrf command is used to select the appropriate VRF after the successful match occurs in the route map. However, the set vrf command cannot be configured with the above four PBR set clauses. This is designed behavior, as we do not allow a packet to be set to an interface or a specific next hop when it is configured within a VRF. An error message will be displayed in the console if you attempt to configure the set vrf command with any of the above four PBR set clauses within the same route map.

AToM:

Any Transport over MPLS (AToM) transports data link layer (Layer 2) packets over a Multiprotocol Label Switching (MPLS) backbone. AToM enables service providers to connect customer sites with existing Layer 2 networks by using a single, integrated, packet-based network infrastructure—a Cisco MPLS network. Instead of using separate networks with network management environments, service providers can deliver Layer 2 connections over an MPLS backbone. AToM provides a common framework to encapsulate and transport supported Layer 2 traffic types over an MPLS network core.

1. AToM supports the following like-to-like transport types:
2. ATM Adaptation Layer Type-5 (AAL5) over MPLS
3. ATM Cell Relay over MPLS
4. Ethernet over MPLS (VLAN and port modes)
5. Frame Relay over MPLS
6. PPP over MPLS
7. High-Level Data Link Control (HDLC) over MPLS

Benefits of AToM

The following list explains some of the benefits of enabling Layer 2 packets to be sent in the MPLS network:

The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame Relay, across multiple Cisco router platforms, such as the Cisco 7200 and 7500 series routers. This enables the service provider to transport all types of traffic over the backbone and accommodate all types of customers.

AToM adheres to the standards developed for transporting Layer 2 packets over MPLS. (See the “Standards” section for the specific standards that AToM follows.) This benefits the service provider that wants to incorporate industry-standard methodologies in the network. Other Layer 2 solutions are proprietary, which can limit the service provider’s ability to expand the network and can force the service provider to use only one vendor’s equipment.

Upgrading to AToM is transparent to the customer. Because the service provider network is separate from the customer network, the service provider can upgrade to AToM without disruption of service to the customer. The customers assume that they are using a traditional Layer 2 backbone.

 

Note: Topics Multicast MPLS VPN, GRE, Multipoint GRE, L2TPv3 & 802.QinQ to follow in Part III.

 

 

References:

http://supportwiki.cisco.com/ViewWiki/index.php/How_does_the_Inter-AS_MPLS_VPN_feature_work%3F

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_configuration_example09186a0080094472.shtml

http://www.cisco.com/en/US/docs/ios/12_0st/12_0st16/feature/guide/IntrAS16.html#wp1054861

http://www.huawei.com/products/datacomm/catalog.do?id=1495

http://www.cisco.com/en/US/products/ps6651/products_ios_protocol_option_home.html

http://www.cisco.com/en/US/technologies/tk648/tk828/tk363/technologies_white_paper0900aecd8012033f_ps6604_Products_White_Paper.html

http://www.cisco.com/en/US/products/ps6604/products_white_paper09186a00800a3db6.shtml#wp34608

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_optab.html#wp1053023

http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/12_2sr/mp_12_2sr_book.html

http://www.cisco.com/en/US/docs/ios/12_2/12_2sz/feature/guide/122szvrf.html#wp1032902

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/fsatom28.html

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008019d6f7.shtml

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800a43f6.shtml#intro

http://www.cisco.com/en/US/tech/tk583/tk372/tech_configuration_examples_list.html#anchor8