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

L3/L2 VPN Part II – Update

Due to massive commitments to live projects in work recently I have had little time to finalise my L3/L2 VPN Notes. This work is drawing to a close thus the notes for Inter AS MPLS VPN, Carrier Supporting Carrier, VRF-Lite, VRF Select, Multicast MPLS VPN, GRE, multipoint GRE, AToM, L2TPv3, 802.QinQ will hopefully be completed tomorrow.

In addition I have obtained the new Internetworkexpert CCIE SP for Dynamips Lab Workbook and will be publishing my thoughts on it as well!

SP L2/L3 VPN – Part I

CCIE SP Blueprint – L3/L2 VPN – MPLS VPN, MP-iBGP, PE-CE routing, RIPv2, OSPF, EIGRP, Static, ISIS, EBGP, BGP Extended Community, Inter AS MPLS VPN, Carrier Supporting Carrier, VRF-Lite, VRF Select, Multicast MPLS VPN, GRE, multipoint GRE, AToM, L2TPv3, 802.QinQ

This blog covers off most of the 1st line above – the remaining features in future entries due to the sheer volume of material to cover off.

MPLS VPN – As a member of a financial services network team and having first being involved in an implementation of MPLS in 2004, I can really see the shift as most engineers have seen from the traditional Frame-Relay/ATM towards MPLS. The MPLS VPN Solution focuses on provisioning, auditing, and monitoring the links between the customer’s routers through the provider’s network. This product deals only with the provider’s edge routers and the customer’s edge routers. A customer edge router (CE) is connected to a provider edge router (PE) in such a way that the customer’s traffic is encapsulated and transparently sent to other CEs, thus creating a virtual private network. CEs advertise routes to the VPN for all the devices in their site. The MPLS VPN Solution provisioning engine accesses the configuration files on both the CE and PE to compute the necessary changes to those files that are required to support the service on the PE-CE link.

An MPLS VPN consists of a set of sites that are interconnected by means of an MPLS provider core network. At each site, there are one or more CEs, which attach to one or more PEs. PEs use the Border Gateway Protocol-Multiprotocol (MP-BGP) to dynamically communicate with each other.

It is not required that the set of IPv4 addresses used in any two VPNs be mutually exclusive because the PEs translate IPv4 addresses into IPv4 VPN entities by using MP-BGP with extended community attributes.

The set of IP addresses used in a VPN, however, must be exclusive of the set of addresses used in the provider network. Every CE must be able to address the PEs to which it is directly attached. Thus, the IP addresses of the PEs must not be duplicated in any VPN.

From the customer’s point of view, they see their internal routers communicating with their customer edge routers (CEs) from one site to another through a VPN managed by the service provider

This simple view of the customer’s network is the advantage of employing VPNs: the customer experiences direct communication to their sites as though they had their own private network, even though their traffic is traversing a public network infrastructure and they are sharing that infrastructure with other businesses.

At the edge of the provider network are provider edge routers (PEs). Within the provider network are other provider routers as needed (often designated as P routers) that communicate with each other and the PEs via the Border Gateway Protocol-Multiprotocol (MP-BGP). Note that in this model, the service provider need only provision the links between the PEs and CEs.

PEs maintain separate routing tables called VPN routing and forwarding tables (VRFs). The VRFs contain the routes for directly connected VPN sites only.

MPLS-based VPNs Benefits:

1. A platform for rapid deployment of additional value-added IP services, including intranets, extranets, voice, multimedia, and network commerce
2. Privacy and security equal to Layer-2 VPNs by constraining the distribution of a VPN’s routes to only those routers that are members of that VPN, and by using MPLS for forwarding
3. Seamless integration with customer intranets
4. Increased scalability with thousands of sites per VPN and hundreds of thousands of VPNs per service provider
5. IP Class of Service (CoS) with support for multiple classes of service within a VPN, as well as priorities among VPNs
6. Easy management of VPN membership and rapid deployment of new VPNs
7. Scalable any-to-any connectivity for extended intranets and extranets that encompass multiple businesses

A virtual private network (VPN) is a network in which customer connectivity to multiple sites is deployed on a shared infrastructure with the same administrative policies as a private network.The path between two systems in a VPN, and the characteristics of that path, may also be determined (wholly or partially) by policy. Whether a system in a particular VPN is allowed to communicate with systems not in the same VPN is also a matter of policy.

In MPLS VPN, a VPN generally consists of a set of sites that are interconnected by means of an MPLS provider core network, but it is also possible to apply different policies to different systems that are located at the same site. Policies can also be applied to systems that dial in; the chosen policies would be based on the dial-in authentication processes.

A given set of systems can be in one or more VPNs. A VPN can consist of sites (or systems) that are all from the same enterprise (intranet), or from different enterprises (extranet); it may consist of sites (or systems) that all attach to the same service provider backbone, or to different service provider backbones.

MPLS-based VPNs are created in Layer 3 and are based on the peer model, which makes them more scalable and easier to build and manage than conventional VPNs. In addition, value-added services, such as application and data hosting, network commerce, and telephony services, can easily be targeted and deployed to a particular MPLS VPN because the service provider backbone recognizes each MPLS VPN as a secure, connectionless IP network.

The MPLS VPN model is a true peer VPN model that enforces traffic separations by assigning unique VPN route forwarding tables (VRFs) to each customer’s VPN. Thus, users in a specific VPN cannot see traffic outside their VPN. Traffic separation occurs without tunneling or encryption because it is built directly into the network

The service provider’s backbone is comprised of the PE and its provider routers. MPLS VPN provides the ability that the routing information about a particular VPN be present only in those PE routers that attach to that VPN.

MPLS VPN Characteristics:

1. Multiprotocol Border Gateway Protocol-Multiprotocol (MP-BGP) extensions are used to encode customer IPv4 address prefixes into unique VPN-IPv4 Network Layer Reachability Information (NLRI) values.
2. NLRI refers to a destination address in MP-BGP, so NLRI is considered “one routing unit.” In the context of IPv4 MP-BGP, NLRI refers to a network prefix/prefix length pair that is carried in the BGP4 routing updates.
3. Extended MP-BGP community attributes are used to control the distribution of customer routes.
4. Each customer route is associated with an MPLS label, which is assigned by the provider edge router that originates the route. The label is then employed to direct data packets to the correct egress customer edge router.
5. When a data packet is forwarded across the provider backbone, two labels are used. The first label directs the packet to the appropriate egress PE; the second label indicates how that egress PE should forward the packet.
6. Cisco MPLS CoS and QoS mechanisms provide service differentiation among customer data packets.
7. The link between the PE and CE routers uses standard IP forwarding.
8. The PE associates each CE with a per-site forwarding table that contains only the set of routes available to that CE.

There are four principal technologies that make it possible to build MPLS-based VPNs:

1. Multiprotocol Border Gateway Protocol-Multiprotocol (MP-BGP) between PEs carries CE routing information
2. Route filtering based on the VPN route target extended MP-BGP community attribute
3. MPLS forwarding carries packets between PEs (across the service provider backbone)
4. Each PE has multiple VPN routing and forwarding instances (VRFs)

Security in MPLS VPN Solution Networks:

1. MP-BGP
2. IP address resolution
3. VPNs Isolation

VPN Routing and Forwarding Tables (VRFs)

The VPN routing and forwarding table (VRF) is a key element in the MPLS VPN technology. VRFs exist on PEs only. A VRF is a routing table instance, and more than one VRF can exist on a PE. A VPN can contain one or more VRFs on a PE.The VRF contains routes that should be available to a particular set of sites. VRFs use CEF technology, therefore the VPN must be CEF-enabled.

A VRF is associated with the following elements:

• IP routing table
• Derived forwarding table, based on the Cisco Express Forwarding (CEF) technology
• A set of interfaces that use the derived forwarding table
• A set of routing protocols and routing peers that inject information into the VRF

Each PE maintains one or more VRFs. MPLS VPN software looks up a particular packet’s IP destination address in the appropriate VRF only if that packet arrived directly through an interface that is associated with that VRF. The so-called “color” MPLS label tells the destination PE to check the VRF for the appropriate VPN so that it can deliver the packet to the correct CE and finally to the local host machine.

A VRF is named based on the VPN or VPNs it services, and on the role of the CE in the topology. The schemes for the VRF names are as follows:

The VRF name for a hub: ip vrf Vx[VPN_name] <- The x parameter is a number assigned to make the VRF name unique.

For example, if we consider a VPN called Blue, then a VRF for a hub CE would be called:

ip vrf V1:blue - A VRF for a spoke CE in the Blue VPN would be called:  ip vrf V1:blue-s

A VRF for an extranet VPN topology in the Green VPN would be called: ip vrf V1:green-etc

Thus, you can read the VPN name and the topology type directly from the name of the VRF.

VPNs and VRFs Considerations:

• A local VRF interface on a PE is not considered a directly-connected interface in a traditional sense. When you configure, for example, a Fast Ethernet interface on a PE to participate in a particular VRF/VPN, the interface no longer shows up as a directly-connected interface when you issue a show ip route command. To see that interface in a routing table, you must issue a show ip route vrf vrf_name command.
• The global routing table and the per-VRF routing table are independent entities. Cisco IOS commands apply to IP routing in a global routing table context. For example, ip vrf V1:blue, and other EXEC-level show commands—as well as utilities such as ping, traceroute, and telnet—all invoke the services of the Cisco IOS routines that deal with the global IP routing table.
• You can issue a standard Telnet command from a CE router to connect to a PE router. However, from that PE, you must issue the following command to connect from the PE to the CE: telnet CERouterName /vrfip vrf V1:blue-s vrf_name
• Similarly, you can utilize the Traceroute and Ping commands in a VRF context.
• The MPLS VPN backbone relies on the appropriate Interior Gateway Protocol (IGP) that is configured for MPLS, for example, EIGRP or OSPF. When you issue a show ip route command on a PE, you see the IGP-derived routes connecting the PEs together. Contrast that with the show ip route vrf VRF_name command, which displays routes connecting customer sites in a particular VPN.

MPLS-based VPNs employ BGP to communicate between PEs to facilitate customer routes. This is made possible through extensions to BGP that carry addresses other than IPv4 addresses. A notable extension is called the route distinguisher (RD). The purpose of the route distinguisher (RD) is to make the prefix value unique across the backbone. Prefixes should use the same RD if they are associated with the same set of route targets (RTs) and anything else that is used to select routing policy. The community of interest association is based on the route target (RT) extended community attributes distributed with the Network Layer Reachability Information (NLRI).The RD value must be a globally unique value to avoid conflict with other prefixes.

Note: The RT extended community attribute is an eight octet structure value. MPLS VPN uses route-target communities as follows:

When a VPN route is injected into MP-BGP, the route is associated with a list of VPN route-target communities. Typically, this is set through an export list of community values associated with the VRF from which the route was learned.

An import list of route-target communities is associated with each VRF. This list defines the values that should be matched against to decide whether a route is eligible to be imported into this VRF.

For example, if the import list for a particular VRF is {A, B, C}, then any VPN route that carries community value A, B, or C is imported into the VRF.

CE Routing Communities

A VPN can be organized into subsets called CE routing communities, or CERCs. A CERC describes how the CEs in a VPN communicate with each other. Thus, CERCs describe the logical topology of the VPN. MPLS VPN Solution can be employed to form a variety of VPN topologies between CEs by building hub and spoke or full mesh CE routing communities. CERCs are building blocks that allow you to form complex VPN topologies and CE connectivity.

The most common types of VPNs are hub-and-spoke and full mesh.

A hub-and-spoke CERC is one in which one or a few CEs act as hubs, and all spoke CEs talk only to or through the hubs, never directly to each other. In hub-and-spoke MPLS VPN environments, the spoke routers have to have unique Route Distinguishers (RDs). In order to use the hub site as a transit point for connectivity in such an environment, the spoke sites export their routes to the hub. Spokes can talk to hubs, but spokes never have routes to other spokes.

Due to the current MPLS VPN implementation, you must apply a different RD for each spoke VRF. The MP-BGP selection process applies to all the routes that have to be imported into the same VRF plus all routes that have the same RD of such a VRF. Once the selection process is done, only the best routes are imported. In this case this can result in a best route which is not imported. Thus, customers must have different RDs per spoke-VRF

A full mesh CERC is one in which every CE connects to every other CE.

Each CE Routing Community (CERC) has two distinct RTs: a hub RT and a spoke RT. When building a full mesh topology, always use the hub RT. Thus, when a need arises to add a spoke site for the current full mesh topology, you can easily add the spoke site without reconfiguring any of the hub sites. The existing spoke RT can be used for this purpose. This is a strategy to prevent having to do significant reprovisioning of a full mesh topology to a hub-and-spoke topology. Note that these two basic types of VPNs—full mesh and hub and spoke—can be represented with a single CERC.

Configurations: [Completed on the PE Routers]

Cisco IOS Services Pre-Requistites:

• MPLS in provider backbone routers, or GRE tunnel connectivity among all provider edge (PE) routers
• MPLS with VPN code in provider routers with VPN edge service (PE) routers
• BGP in all routers providing a VPN service
• CEF switching in every MPLS-enabled router
• CoS feature (optional)

 Step – Define VPN routing instance

Router(config)# ip vrf vrf-name <- Associate a VRF with an interface or subinterface

Router(config-vrf)# rd route-distinguisher  <- Create routing and forwarding tables

Router(config-vrf)# route-target {import | export | both} route-target-ext-community <- Create a list of import and/or export route target communities for the specified VRF

Router(config-vrf)# import map route-map  <- (Optional) Associate the specified route map with the VRF

Router(config-if)# ip vrf forwarding vrf-name <- Associate a VRF with an interface or subinterface

Step - BGP PE to CE routing sessions

Router(config)# router bgp autonomous-system <- Configures a EBGP routing process with the autonomous system number passed along to other EBGP routers.

Router(config-router)# neighbor {ip-address | peer-group-name} remote-as number <-  Specifies a neighbor’s IP address or EBGP peer group identifying it to the local autonomous system.

Router(config-router)# neighbor ip-address activate <-  Activates the advertisement of the IPv4 address family.

Step - Configure RIP PE to CE Routing

Router(config)# router rip <-  Enables RIP.

Router(config-router)# address-family ipv4 [unicast] vrf vrf-name <-  Defines RIP parameters for PE to CE routing sessions.

Router(config-router-af)# network prefix <-  Enables RIP on the PE to CE link.

Step - Configure static route PE to CE Routing

Router(config)# ip route vrf vrf-name <-  Defines static route parameters for every PE to CE session.

Router(config-router)# address-family ipv4 [unicast] vrf vrf-name <-  Defines static route parameters for every BGP PE to CE routing session.

Router(config-router-af)# redistribute static <-  Redistributes VRF static routes into the VRF BGP table.

Router(config-router-af)# redistribute static connected <-  Redistributes directly connected networks into the VRF BGP table. 

OSPF/BGP Example:
The OSPF VRF process needs to be redistributed into BGP and vice versa. You can configure all the regular OSPF commands for the OSPF VRF process. Make sure you have the subnets keyword on the redistribute bgp command under the router ospf process. Otherwise, only classful routes are redistributed. When you are redistributing OSPF into BGP, make sure to configure the appropriate match parameters on the redistribute command so that you can redistribute the proper OSPF type of routes.

ip vrf cust-one
rd 1:1
route-target export 1:1
route-target import 1:1
!
interface Loopback1
ip vrf forwarding cust-one
ip address 10.99.1.1 255.255.255.255
!
router ospf 42 vrf cust-one
router-id 10.99.1.1
log-adjacency-changes
redistribute bgp 1 metric 10 subnets
network 10.10.2.0 0.0.0.255 area 0
!
router bgp 1
bgp log-neighbor-changes
neighbor 10.200.254.5 remote-as 1
neighbor 10.200.254.5 update-source Loopback0
!
address-family vpnv4
neighbor 10.200.254.5 activate
neighbor 10.200.254.5 send-community extended
exit-address-family
!
address-family ipv4 vrf cust-one
redistribute connected
redistribute ospf 42 vrf cust-one metric 10 match internal external 1 external 2
exit-address-family
!

EIGRP Example:

This example configuration is of one PE router that is configured for two VRFs running EIGRP.
!
router eigrp 1
no auto-summary
!
address-family ipv4 vrf cust-two
redistribute static metric 64 2000 255 1 1500
redistribute bgp 1 metric 300 40000 255 1 1500
network 10.10.0.0 0.0.255.255
no auto-summary
autonomous-system 33
exit-address-family
!
address-family ipv4 vrf cust-one
redistribute bgp 1 metric 300 40000 255 1 1500
network 10.0.0.0
no auto-summary
autonomous-system 42
exit-address-family
!

ISIS Example:

PE Router Information:
!
Interface Loopback0
IP Address 10.10.100.1/32
!
Router ISIS
Net 49.0001.0000.0000.0001.00
Passive-interface Loopback0
!

PE Router Configuration:
!
ip vrf cust-one
rd 1:1
route-target export 1:1
route-target import 1:1
!
interface Ethernet0/1/2
ip vrf forwarding cust-one
ip address 10.10.2.2 255.255.255.0
ip router isis cust-one
isis circuit-type level-2-only
!
router isis cust-one
vrf cust-one
net 49.0001.0000.0000.0003.00
is-type level-2-only
redistribute bgp 1
!
router bgp 1
neighbor 10.200.254.5 remote-as 1
neighbor 10.200.254.5 update-source Loopback0
!
address-family vpnv4
neighbor 10.200.254.5 activate
neighbor 10.200.254.5 send-community extended
exit-address-family
!
address-family ipv4 vrf cust-one
redistribute connected
redistribute isis cust-one level-2
exit-address-family
!

VPN Operation Verification, use the following commands in privileged EXEC mode:

Router# show ip vrf <-  Displays the set of defined VRFs and interfaces.

Router# show ip vrf [{brief | detail | interfaces}] vrf-name <-  Displays information about defined VRFs and associated interfaces.

Router# show ip route vrf vrf-name <-  Displays the IP routing table for a VRF.

Router# show ip protocols vrf vrf-name <-  Displays the routing protocol information for a VRF.

Router# show ip cef vrf vrf-name <-  Displays the CEF forwarding table associated with a VRF.

Router# show ip interface interface-number <-  Displays the VRF table associated with an interface.

Router# show ip bgp vpnv4 all [labels] <- Displays information about all BGP routes.

Router# show mpls forwarding vrf vrf-name[prefix mask/length] [detail] <-  Displays label forwarding entries that correspond to VRF routes advertised by this router.

Conclusion: As always I have used Cisco Documentation as my guide, all the above are my summaries of the text maintained in the below links which further embellish the above information with examples and configurations which should be reviewed. 

References:

http://www.cisco.com/en/US/docs/ios/12_2t/12_2t13/feature/guide/ftvpn13.html#wp1027204

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/VPN.html

http://www.cisco.com/en/US/docs/net_mgmt/vpn_solutions_center/1.1/user/guide/VPN_UG1.html

Cisco Press MPLS Fundamentals – Chapter 7 – MPLS VPN’s.

SP MPLS

Okay, into the breech, these next three topics are where we really veer from the R&S Path.

SP Lab Blueprint: Label distribution, LDP/ TDP, Label filtering, Label merging, Multipath, MPLS COS, MPLS Netflow, MPLS over ATM, MPLS Traffic Engineering

MPLS – Multi Protocol Label Switching is a high-performance packet forwarding technology that integrates the performance and traffic management capabilities of data link layer (Layer 2) switching with the scalability, flexibility, and performance of network-layer (Layer 3) routing. It enables service providers to meet challenges brought about by explosive growth and provides the opportunity for differentiated services without necessitating the sacrifice of existing infrastructure. Sometimes it is referred to Layer 2 ½ as it’s somewhere between Layer 2 and Layer 3 but neither.

MPLS Architecture Flexibility

• Data can be transferred over any combination of Layer 2 technologies
• Support is offered for all Layer 3 protocols
• Scaling is possible well beyond anything offered in today’s networks.

Specifically, MPLS can efficiently enable the delivery of IP services over an ATM switched network. It supports the creation of different routes between a source and a destination on a purely router-based Internet backbone. Service providers who use MPLS can save money and increase revenue and productivity. Remember that Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router.

MPLS Benefits:

Scalable support for SVirtual Private Networks (VPNs)—MPLS enables VPN services to be supported in service provider networks, thereby greatly accelerating Internet growth. Unlike the PVC VPN model, the MPLS VPN model is highly scalable and can accommodate increasing numbers of sites and customers. The MPLS VPN model also supports “any-to-any” communication among VPN sites without requiring a full mesh of PVCs or the backhauling (suboptimal routing) of traffic across the service provider network.

Explicit routing capabilities (also called constraint-based routing or traffic engineering)—Explicit routing employs “constraint-based routing,” in which the path for a traffic flow is the shortest path that meets the resource requirements (constraints) of the traffic flow. In MPLS traffic engineering, factors such as bandwidth requirements, media requirements, and the priority of one traffic flow versus another can be taken into account.

Support for IP routing on ATM switches (also called IP and ATM integration)—MPLS enables an ATM switch to perform virtually all of the functions of an IP router. This capability of an ATM switch stems from the fact that the MPLS forwarding paradigm (namely, label swapping) is exactly the same as the forwarding paradigm provided by ATM switch hardware.

Label Switching Function:

In conventional Layer 3 forwarding mechanisms, as a packet traverses the network, each router extracts all the information relevant to forwarding the packet from the Layer 3 header. This information is then used as an index for a routing table lookup to determine the next hop for the packet.

In the most common case, the only relevant field in the header is the destination address field, but in some cases other header fields might also be relevant. As a result, the header analysis must be done independently at each router through which the packet passes. A complicated table lookup must also be done at each router.

In label switching, the analysis of the Layer 3 header is done only once. The Layer 3 header is then mapped into a fixed length, unstructured value called a label.

Many different headers can map to the same label, as long as those headers always result in the same choice of next hop. In effect, a label represents a forwarding equivalence class—that is, a set of packets that, however different they may be, are indistinguishable by the forwarding function.

Once a label is assigned, a short label header is added at the front of the Layer 3 packet. This header is carried across the network as part of the packet. At subsequent hops through each MPLS router in the network, labels are swapped and forwarding decisions are made by means of MPLS forwarding table lookup for the label carried in the packet header. Hence, the packet header need not be re-evaluated during packet transit through the network. Because the label is of fixed length and unstructured, the MPLS forwarding table lookup process is both straightforward and fast.

Label Bindings Distribution:

Each LSR in the network makes an independent, local decision as to which label value to use to represent a forwarding equivalence class. This association is known as a label binding. Each LSR informs its neighbors of the label bindings it has made. This awareness of label bindings by neighboring routers is facilitated by the following protocols:

TDP—Used to support MPLS forwarding along normally routed paths

Resource Reservation Protocol (RSVP)—Used to support MPLS traffic engineering

Border Gateway Protocol (BGP)—Used to support MPLS VPNs

When a labelled packet is being sent from LSR A to the neighboring LSR B, the label value carried by the IP packet is the label value that LSR B assigned to represent the forwarding equivalence class of the packet. Thus, the label value changes as the IP packet traverses the network.

MPLS Mechanics:

An MPLS network is commonly a backbone network comprised of MPLS-enabled routers called Label Switch Routers (LSR). Generally, the network consists of a core LSR with an edge LSR that applies labels to packets.

This is the setup mechanism of an MPLS network:

1. Routing tables of the different LSRs are computed with an Interior Gateway Protocol (IGP). A link-state protocol, such as Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS), is required if you plan to deploy MPLS TE.

2. A label distribution protocol (LDP) advertises the bindings between routes and labels. These bindings are checked against the routing table. If the route (prefix/mask and next hop) learned from the LDP matches the route learned from IGP in the routing table, an entry is created in the label that forwards information bases (LFIB) on the LSR.

Note regarding LDP\TDP – TDP (Tag Distribution Protocol) & LDP (Label Distribution Protocol), Cisco TDP and LDP (MPLS Label Distribution Protocol) are nearly identical in function, but use incompatible message formats and some different procedures. Cisco is changing from TDP to a fully compliant LDP. Other comparisons include ->

                          LDP             TDP

Hello Address       224.0.0.2     255.255.255.255

Hello Port          UDP 646         UDP 711

Adjacency Port  TCP 646          TCP 711

Proprietary           No                 Cisco

The LSR uses this forwarding mechanism:

1. Once an edge LSR receives an unlabelled packet, the Cisco Express Forwarding table is checked and a label is imposed on the packet if needed. This LSR is called the ingress LSR.

2. Upon the arrival of a labelled packet at the inbound interface of a core LSR, the LFIB provides the outbound interface and the new label that is associated with the outbound packet.

3. The router before the last LSR (the penultimate hop) pops the label and transmits the packet without the label. The last hop is called the egress LSR.

MPLS Configuration:

Use this procedure as a quick configuration guide.

1. Set up your network as usual. MPLS needs a standard IP connection in order to establish forwarding bases.

2. Ensure that the routing protocol (OSPF or IS-IS) works correctly. These commands are italicized in the configurations in the next section.

3. Enable ip cef, for better performances use ip cef distributed when available, in the general configuration mode. This is shown in bold in the configurations in the next section.

4. Enable mpls ip, or tag-switching ip on older Cisco IOS software releases, in the general configuration mode and in each interface, as shown in bold in the configurations in the next section. Even when the mpls ip command is used, the show running output can still show the command as tag-switching ip in some Cisco IOS software releases.

Note: The LSRs must have (up) Loopback interfaces with an address mask of 32 bits and these interfaces must be reachable with the global IP routing table.

Example:

Configure MPLS on Router 4’s Frame Relay Interface

R4:

mpls label protocol ldp

!

interface Serial0/0.1

mpls ip

Configure MPLS on R1’s ATM connection

R1:

interface ATM3/0.1 mpls

mpls label protocol tdp

mpls ip

Label Distribution, configure MPLS on R3

R3:

mpls label protocol ldp

!

interface Ethernet0/0

tag-switching ip

!

interface Serial1/3

tag-switching ip

Verification:

Sh ip route – Used to check the IP route for this destination in the IP routing table

sh mpls fowarding-table – Used to check the MPLS forwarding table, which is the label switching equivalent of the IP routing table for standard IP routing. It contains inbound and outbound labels and descriptions of the packets.

sh mpls forwarding-table detail – Used to see MPLS forwarding table details

sh mpls ldp bindings – Used to see the label bindings associated with a particular destination. Both the local as well as the remote bindings can be seen

sh mpls interfaces

sh ip cef detail – Used to check that Cisco Express Forwarding works properly and that tags are swapped correctly

debug mpls events

debug mpls ldp bindings

Label Filtering – Basically this is where you will be told stuff like not to include certain networks to inject labels into other networks for security or some such reason. You can refer to my previous post on filtering routes in the blog but for example –Stop R5 receiving MPLS from other devices on it’s E0 network segment except from R6 which has the 10.1.6.6 & 10.1.36.6 addresses.

R5:

interface Ethernet0

ip access-group STOP_LDP in

mpls ldp discovery transport-address 10.1.5.5

!

ip access-list extended STOP_LDP

permit udp host 10.1.36.6 eq 646 host 224.0.0.2 eq 646

permit tcp host 10.1.6.6 eq 646 host 10.1.5.5

permit tcp host 10.1.6.6 host 10.1.5.5 eq 646

deny udp any any eq 646

deny tcp any any eq 646

deny tcp any eq 646 any

permit ip any any

MPLS CoS functionality enables network administrators to provide differentiated services across an MPLS network. Network administrators can satisfy a wide range of networking requirements by specifying the class of service applicable to each transmitted IP packet. Different classes of service can be established for IP packets by setting the IP precedence bit in the header of each packet. MPLS CoS supports the following differentiated services in an MPLS network:

Packet classification - CoS Function – Committed access rate (CAR). Packets are classified at the edge of the network before labels are assigned. CAR uses the type of service (ToS) bits in the IP header to classify packets according to input and output transmission rates. CAR is often configured on interfaces at the edge of a network in order to control traffic flowing into or out of the network. You can use CAR classification commands to classify or reclassify a packet

Congestion avoidance - Weighted random early detection (WRED) – Packet classes are differentiated based on drop probability. WRED monitors network traffic to anticipate and prevent congestion at common network and internetwork bottlenecks. WRED can selectively discard lower priority traffic when an interface becomes congested; WRED can also provide differentiated performance characteristics for different classes of service.

Congestion management - Weighted fair queuing (WFQ) for non-GSR platforms. Packet classes are differentiated based on bandwidth requirements and finite delay characteristics. Modified deficit round robin (MDRR) for GSR platforms. WFQ is an automated scheduling system that ensures fair bandwidth allocation to all network traffic. WFQ uses weights (priorities) to determine how much bandwidth each class of traffic is allocated. MDRR, similar in function to WFQ for non-GSR platforms, is a traffic prioritization scheme that maps IP traffic to different classes of service queues, based on the IP precedence value of each packet. The queues are then serviced on a round-robin basis.

Remember this is a high end router IOS component so will only be seen on the 7200’s as the 12000’s and 7500’s are not on the hardware list.

Benefits of MPLS CoS: 

You realize the following benefits when you use MPLS CoS in a backbone consisting of IP routers running MPLS:

Efficient resource allocation—WFQ is used to allocate bandwidth on a per-class and per-link basis, thereby guaranteeing a percentage of link bandwidth for network traffic.

Packet differentiation—When IP packets traverse an MPLS network, packets are differentiated by mapping the IP precedence bits of the IP packets to the MPLS CoS bits in the MPLS EXP field. This mapping of bits enables the service provider to maintain end-to-end network guarantees and meet the provisions of customer service level agreements (SLAs).

Future service enhancements—MPLS CoS provides building blocks for future service enhancements (such as virtual leased lines) by meeting bandwidth requirements.

Example:

!

ip routing

!

hostname R2

!

ip cef

mpls ip

tag-switching advertise-tags

!

interface Loopback0

ip address 10.10.10.10 255.255.255.255

!

interface Ethernet1/3

ip address 90.0.0.2 255.0.0.0

rate-limit input access-group 101 496000 32000 64000 conform-action set-prec-transmit 4

exceed-action set-prec-transmit 0 <- Specifies the action to take on packets during label imposition!

interface POS6/0

ip address 91.0.0.1 255.0.0.0

mpls label protocol ldp

mpls ip

random-detect <- Configures the interface to use WRED/DWREDclock source internal

!

router ospf 100

network 10.0.0.0 0.255.255.255 area 100

network 90.0.0.0 0.255.255.255 area 100

network 91.0.0.0 0.255.255.255 area 100

!

access-list 101 permit ip host 11.11.11.11 any

Verification:

show queuing interface p6/0

show interfaces e1/3 rate-limit

MPLS egress NetFlow accounting allows you to capture IP flow information for packets undergoing MPLS label disposition; that is, packets that arrive on a router as MPLS and are sent as IP.

Previous to the MPLS Egress NetFlow Accounting feature, you captured NetFlow data only for flows that arrived on the packet in IP format. When an edge router performed MPLS label imposition (received an IP packet and sent it as an MPLS packet), NetFlow data was captured when the packet entered the network. Inside the network, the packet was switched based only on MPLS information, and thus NetFlow information was not captured until after the last label was removed.

One common application of the MPLS egress NetFlow accounting feature allows you to capture the MPLS VPN IP flows that are travelling from one site of a VPN to another site of the same VPN through the service provider backbone.

Previous to the MPLS Egress NetFlow Accounting feature, you captured flows only for IP packets on the ingress interface of a router. You could not capture flows for MPLS encapsulated frames, which were switched through CEF from the input port. Therefore, in an MPLS VPN environment you captured flow information as packets were received from a CE router and forwarded to the backbone. However, you could not capture flow information as packets were sent to a CE router because those packets were received as MPLS frames.

The MPLS egress NetFlow accounting feature lets you capture the flows on the outgoing interfaces.

Benefits to MPLS Egress NetFlow Accounting are as follows:

• Enhanced network monitoring for complete billing solution—You can now capture flows on the egress and ingress router interfaces to provide complete end-to-end usage information on network traffic. The accounting server uses the collected data for various levels of aggregation for accounting reports and API accounting information, thus providing a complete billing solution.

• More accurate accounting statistics—NetFlow data statistics now account for all the packets that are dropped in the core of the service provider network, thus providing more accurate traffic statistics and patterns.

MPLS Traffic Engineering enables an MPLS backbone to replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay networks. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2 features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network. WAN connections are an expensive item in an ISP budget. Traffic engineering enables ISPs to route network traffic to offer the best service to their users in terms of throughput and delay. By making the service provider more efficient, traffic engineering reduces the cost of the network.

MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources, such as bandwidth.

Available resources are flooded by means of extensions to a link-state-based Interior Gateway Protocol (IGP).

Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs. Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects the ingress point to the egress point.

MPLS traffic engineering is built on the following Cisco IOS mechanisms:

• IP tunnel interfaces—From a Layer 2 standpoint, an MPLS tunnel interface represents the head of an LSP. It is configured with a set of resource requirements, such as bandwidth and media requirements, and priority.
• From a Layer 3 standpoint, an LSP tunnel interface is the head-end of a unidirectional virtual link to the tunnel destination.
• MPLS traffic engineering path calculation module—This calculation module operates at the LSP head. The module determines a path to use for an LSP. The path calculation uses a link-state database containing flooded topology and resource information.
• RSVP with traffic engineering extensions—RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated path.
• MPLS traffic engineering link management module—This module operates at each LSP hop, does link call admission on the RSVP signalling messages, and does bookkeeping of topology and resource information to be flooded.
• Link-state IGP (Intermediate System-to-Intermediate System (IS-IS) or OSPF—each with traffic engineering extensions)—These IGPs are used to globally flood topology and resource information from the link management module.
• Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)—The IGP automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination. Static routes can also be used to direct traffic onto LSP tunnels.
• Label switching forwarding—This forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across multiple hops of the LSP established by RSVP signalling

 

Conclusion: Phew, quite a bit and these are concise wrap up notes! A multitude of references below that will need to be cross-checked. My sources as usual would be CCO/UniverCD. Hope this has been of help in mapping this vast topic to the blueprint.

References:

http://www.cisco.com/en/US/docs/ios/12_0st/12_0st10/feature/guide/10st_cos.html

http://www.cisco.com/en/US/tech/tk436/tk428/tech_configuration_guides_list.html

http://www.cisco.com/en/US/docs/ios/12_2/switch/configuration/guide/xcftagov_ps1835_TSD_Products_Configuration_Guide_Chapter.html

http://www.cisco.com/en/US/tech/tk436/tk798/tech_configuration_guides_list.html

http://www.cisco.com/en/US/tech/tk436/tk798/tsd_technology_support_protocol_home.html

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

http://www.cisco.com/univercd/cc/td/doc/product/wanbu/bpx8600/mpls/9_3_1/mpls03.htm

SP High Availability Part II

Continuing on this topic – I have been reading through Cisco Press’ Fault Tolerant IP & MPLS Networks by Hussain and some interesting facts in the book. He cites a University of Michigan one-year reliability study of IP core routers conducted in a regional IP service provider network where the main causes of outages are listed as

• 23 percent for router failure (software/hardware faults, denial-of-service attack),
• 32 percent for link failures (fiber cuts, network congestion),
• 36 percent for router maintenance (software and hardware upgrade, configuration errors),
• The remaining 9 percent for other miscellaneous reasons.

He states that for carrier-class routers the following characteristics should apply.

• No single hardware fault should result in a loss or degradation of user traffic or a loss of control-plane and management functions.
• System downtime should be less than 5.256 minutes per year.
• Line cards, switching fabric, and control processor cards should be redundant with capability to monitor standby cards.
• The control-plane software/hardware module should not be a single point of failure, and the service (forwarding plane) should not be disrupted due to failure of the control plane.
• The router should be capable of service recovery from link/node failures.

By the way we suffered a carrier issue during last week when a 34MB SDH tributary card failed causing a number of hours downtime so it feels appropriate to cover this topic now.

NSF – Nonstop Forwarding works with the Stateful Switchover (SSO) feature in Cisco IOS software. NSF works with SSO to minimize the amount of time a network is unavailable to its users following a switchover. The main objective of Cisco NSF is to continue forwarding IP packets following a Route Processor (RP) switchover. It maintains and updates Layer 3 routing and forwarding information in the backup route processor. This ensures that the forwarding of IP packets and routing protocol information are continuous during the switchover and route convergence process. It eliminates router downtime, and increases network availability during scheduled maintenance of a route processor, or a route processor failure.

When a networking device restarts, all routing peers of that device detect that the device went down and then came back up. This transition results in what is called a routing flap, which could spread across multiple routing domains. Routing flaps caused by routing restarts create routing instabilities, which are detrimental to the overall network performance. Cisco NSF helps to suppress routing flaps in SSO-enabled devices, thus reducing network instability. Cisco NSF allows for the forwarding of data packets to continue along known routes while the routing protocol information is being restored following a switchover. With Cisco NSF, peer networking devices do not experience routing flaps. Data traffic is forwarded through intelligent line cards or dual forwarding processors (FPs) while the standby RP assumes control from the failed active RP during a switchover. The ability of line cards and FPs to remain up through a switchover and to be kept current with the Forwarding Information Base (FIB) on the active RP is key to Cisco NSF operation. During switchover, system control and routing protocol execution is transferred from the active processor to the standby processor. The time required by the device to switch over from the active to the standby processor ranges from just a few seconds to approximately 30 seconds, depending on the platform

Pre-requisites include that NSF must be configured on a networking device that has been configured for SSO. On platforms supporting the Route Switch Processor (RSP), and where the CEF switching mode is configurable, configure distributed CEF (dCEF) switching mode using the ip cef distributed command.

There are several restrictions for the various routing protocols such as they must be running an NSF software image, not supported on OSPF virtual links, HSRP does not work with NSF, etc. See the reference links below for more information.

From the CCIE SP Lab perspective it is only supported on the 7200 router on the lab equipment list.

Configuration Example: [For OSPF]

Router# show cef state <- Verifies that router is NSF capable
Router# configure terminal
Router(config)# router ospf 400
Router(config-router)# nsf
Router(config-router)# exit
Router# show running-config <- Verifies NSF for OSPF
!
router ospf 120
log-adjacency-changes
nsf
network 192.168.20.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 1
network 192.168.40.0 0.0.0.255 area 2
!
Router> show ip ospf <- Verifies NSF for OSPF, look for the line “Non-Stop Forwarding enabled”

Note: Both Fast re-route and link/node protection will be covered under MPLS as they are part of the MPLS-TE Section.

References:

http://www.cisco.com/en/US/docs/ios/12_2s/feature/guide/fsnsf20s.html#wp1222831