GNS3 Topology: MPLS Carrier Supporting Carrier Configuration

"Carrier supporting carrier is a term used to describe a situation where one service provider allows another service provider to use a segment of its backbone network. The service provider that provides the segment of the backbone network to the other provider is called the backbone carrier. The service provider that uses the segment of the backbone network is called the customer carrier. A backbone carrier offers Border Gateway Protocol and Multiprotocol Label Switching (BGP/MPLS) VPN services.

The customer carrier can be either:
• An Internet service provider (ISP)
• A BGP/MPLS VPN service provider"

PART 1 (backbone carrier configuration)



PART 2 (Customer Carrier configuration, Customer Carrier isn't running MPLS)



PART 3 (Customer Carrier running MPLS and Customer Carrier providing MPLS VPN service.)






"Lobo L, Lakshman U, 2005, MPLS Configuration on Cisco IOS Software, Cisco Press"

Cisco IOS MPLS Configuration Guide Release 12.4T, 2005, MPLS VPN Carrier Supporting Carrier Using LDP and an IGP,retrieved from http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/12_4t/mp_12_4t_book.html , jan 2011

GNS3 Topology: MPLS Traffic Engineering Fast ReRoute

Fast Reroute

Fast Reroute (FRR) is a mechanism for protecting MPLS TE LSPs from link and node failures by locally repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the protected LSPs by rerouting them over backup tunnels that bypass failed links or nodes. (1)

Prerequisites MPLS TE Fast ReRoute Link and Node Protection

Network must support the following Cisco IOS features:
• IP Cisco Express Forwarding
• Multiprotocol Label Switching (MPLS)

Network must support at least one of the following protocols:
• Intermediate System-to-Intermediate System (IS-IS)
• Open Shortest Path First (OSPF)

Features of MPLS TE FRR Link and Node Protection
  -Backup Tunnel Support
       -Backup Tunnels can terminate at the Next-Next-Hop to support FRR
       -Multiple Backup Tunnels Can Protect the Same Interface
       -Backup Tunnels can Provide Scalability
  -Backup Bandwidth Protection
       -Bandwidth Protection on Backup Tunnels
       -Bandwidth Pool Specifications for Backup Tunnels
       -Semidynamic Backup Tunnel Paths
       -Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection
  -RSVP Hello





1- Cisco IOS Multiprotocol Label Switching Configuration Guide, Release 12.4T, 2008, retrieved from http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/12_4t/mp_12_4t_book.html , jan 2011

GNS3 Topology: MPLS Traffic Engineering

Traditional IP-forwarding leads to suboptimal use of available bandwidth between pair of routers in the SP network. The suboptimal paths are under-utilized in IP networks. To avoid packet drops because of inefficient use of available bandwidth, TE is employed to steer some of the traffic, and to enable better bandwidth management and utilization between pair of routers

TE tunnels configured on routers are unidirectional, which means we need to configure a pair of TE tunnel between routers if we want to implement bidirectional TE tunnel.

OSPF or IS-IS with extensions for TE is used to carry information pertaining to the tunnel configured on a router.In OSPF, the LSA type 10 provides information about resource and link status. The inspiration behind MPLS TE is Constraint Based Routing (CBR) and CBR requires IGP like IS-IS or OSPF (IGP must be link-state routing protocol) for its operation. Resource availability and link status information are calculated using a constrained SPF (CSPF) calculation in which factors such as the bandwidth, policies, and topology are taken into consideration to define probable paths from a source to destination.

"Lobo L, Lakshman U, 2005, MPLS Configuration on Cisco IOS Software, Cisco Press"



PART 1 (enabling MPLS and configuring routers for TE support)

PART 2 (configuring headend router, verification and unequal cost load balancing using TE)

GNS3 Topology: Inter Provider MPLS VPN (Back to Back VRF Method)

Inter-Provider VPN feature allows the VPN information to be redistributed between adjacent MPLS VPN entities so that client sites belonging to customer which is dispersed across multiple service provider backbones can communicate with each other.

To maintain the continuity of VPN services across multiple service providers, there are four different options to distribute VPNv4 information across the ASBR routers:

1- Back-to-Back VRF Method
2- Multiprotocol eBGP for VPNv4
3- Multi-hop MP-eBGP between Route-Reflectors
4- Non-VPN transit provider


In this approach, ASBRs are interconnected either via a single link consisting of logical subinterfaces or via multiple physical links. VRFs are configured on the ASBRs to collect VPN client routes. Each subinterface or interface connected between the ASBRs is dedicated to a single client VRF. The single client VRF can run eBGP, RIPv2, EIGRP, OSPF, or static routing to distribute the VPN routes to its adjacent peer.

"Lobo L, Lakshman U, 2005, MPLS Configuration on Cisco IOS Software, Cisco Press"

PART 1 (enabling MPLS and PE-PE routing configuration inside SP 1)



PART 2 (enabling MPLS and PE-PE routing configuration inside SP 2)



PART 3 (Configuring VRF instances and PE-CE routing configuration)



PART 4 (Verification of VPN)

GNS3 Topology: MPLS VPN Hub and Spoke Topology Configuration

In certain circumstances, it may be desirable to use a hub-and-spoke topology so that all spoke sites send all their traffic toward a central site location. It can be achieved across MPLS VPN.

All traffic from the spoke sites, destined either for the central site services or for intersite connectivity, will flow via the central hub site. With this type of topology, the spoke sites export their routes to the hub site, and then the hub site re-exports the spoke site routes through a second interface (either physical or logical) using a different route target so that other spoke sites can import the routes. This causes the hub site to become a transit point for interspoke connectivity. (Guichard J, Pepelnjak I, 2001, MPLS and VPN Architectures, Cisco Press)

Here is the HUB and SPOKE MPLS VPN configuration. (this topology and configuration was taken from the book "MPLS Configuration On Cisco IOS Software"

PART 1



PART 2

GNS3 Topology: MPLS VPN (BGP PE-CE Routing)

In an MPLS VPN network, BGP attributes for a VPN site are transparently transported across the service provider backbone to another site in the same VPN. Because there is a single routing protocol used across the VPN between service provider core and customer sites, the concept of redistribution does not apply.

BGP PE-CE peering in an MPLS VPN environment can be performed in two different ways:

1-) BGP PE-CE VPN sites implementing unique AS numbers (in our example, CUSTOMER A between Site 1 and Site 2)

2-) BGP PE-CE VPN sites implementing same AS numbers   (in our example, CUSTOMER B between Site 1 and Site 2)

There will be no issue when implementing BGP PE-CE routing for customers which use unique AS in both VPN sites. However, using same AS number in both VPN sites causes an issue because of the BGP loop prevention mechanism. if both sites have same AS number, routing updates from one site would be dropped at the other site; therefore, connectivity cannot be established between the sites without additional configuration on PE routers.  ("neighbor XX.XX.XX.XX as-override" under bgp address-family configuration)

here is the configuration of MPLS VPN with BGP PE-CE Routing.

PART 1



PART 2