Configuring MPLS L3VPNs

Imagine Site A-1 is in Georgia, A-2 is in Illinois and A-3 is in New York. Full connectivity between all Site A-#s is required. What are our options? Well you can do a full mesh VPN and using the formula n(n-1)/2 where n is the # of sites you can see that we would need to build 6 static VPN tunnels -- needless to say static tunnels are time consuming and does not scale well. Or you can set up DMVPN (Cisco proprietary) which would lessen the work. Or as an ISP we can provide MPLS VPN and the customers wont have to do ANYTHING which is just way they usually like it. Customer site Site A-#s and Customer Site B-#s can all be VPN'd together appropriately and transparently using MPLS.


Consider the topology below.

Objective:
Configure R1 and R2 to support MPLS/OSPF/BGP
Configure the appropriate VRFs on R1 and R2
All Site A routers (R3, R4 and R7) should all be able to transparently ping all Site-A#s loopbacks
All Site B routers (R5 and R6) should all be able to transparently ping all Site-B#s loopbacks
Site A routers (R3, R4, R7) should not be able to ping Site B routers (R5 and R6) and vice-versa

Relevant configurations are posted below. So let's jump right into the complex world of MPLS!!

Configuring BGP - Dual Multihomed Design

We've already laid out the ground work in my previous blogtorial "Configuring BGP - Dual Homed Design". So all we are going to have to do is bring up 2 more bgp peers. 1 on R1 and 1 on R2 to connect ISP-B with the ASN 33333.


Here is the topology so let's get going.

Relevant configurations are posted below.

Configuring BGP - Dual Homed Design (Part 2)

In "Configuring BGP - Dual Homed Design (Part 1)" we saw how we can configure R1 and R2, however R3 in the enterprise core still cannot get access to the internet. So let's configure dual NAT on R1 and R2 and learn 'why and how' we redistribute iBGP learned routes into OSPF. 

Configuring BGP - Dual Homed Design (Part 1)

In this blogtorial we will discuss how to implement a Dual Homed BGP design. So let's begin by defining what is a Dual Homed BGP design? Dual Homed BGP means you have 2 local routers (in the same ASN) connected to the 2 different routers from the same ISP. A Dual Homed setup will give you fault tolerant at the router level but not at the ISP level. Consider a Single Multihomed or Dual Multihomed setup for fault tolerant at the ISP level. These are fairly advanced topics so I suggest you familiarize yourself with BGP, BGP path selection, route-maps, prefix-lists, OSPF, route-distribution before continuing. 


Objectives: 

• Configure OSPF as IGP for R1, R2, R3
• Configure iBGP between R1 and R2
• Configure iBGP between R4 and R5
• Configure eBGP between R1 and R4 
• Configure eBGP between R2 and R5

See below for the network diagram to better understand a Dual Homed BGP Design.

Relevant configurations are posted below so let's get started.

Configuring BGP - Single Multihomed Design

This blogtorial is a continuation from my previous "Configuring BGP - Single Homed". The topology now has a new ISP (ISP B) connected to R1. So R1 now has 2 internet connections. Keep in mind that load balancing is not possible in a Single Multihomed configuration because BGP will install only the best route. However load sharing and failover is possible. Load-sharing in this context means you take in a full BGP routing table and set metrics appropriately.


Objectives:

• 5.5.5.0/24 and 6.6.6.0/24 will be advertised by both ISP A and ISP B
• Configure R1 to load share between the 2 ISPs
• R1 will prefer ISP A for 5.5.5.0/24
• R1 will prefer ISP B for 6.6.6.0/24. 
• Advertise 22.22.22.0/24 to both the ISPs so when one of the ISP goes down incoming traffic to 22.22.22.0/24 is not affected. 

Relevant configurations are posted below so let's get started.

Configuring BGP - Single Homed Design

BGP is a highly complex routing protocol -- so complex that there are exams dedicated to just this protocol. Therefore, I will not dwell on the details and the inner workings of BGP, however I will give you a brief how-to implement a "Single Homed" BGP design. 


When it comes to BGP designs they are four basic ones: single homed, dual homed, single multihomed and dual mutihomed. In this blogtorial we are going to see how to implement a "Single homed" BGP design. 


Here is the topology which I will be using and we will be building upon this topology on future BGP blogtorials so let's get started. 

Relevant configurations are posted below.

Configuring IPSEC VPN between Linux and Cisco

In this blogtorial we are going to talk about how to configure a IPSEC VPN between a linux machine (CentOS) and a Cisco router. I  had to do this because we installed a Cisco router at a customer site with a DHCP ip Comcast connection. So in-order to get into the Cisco router to do management I created a ipsec vpn tunnel back to one of my Linux machines. I know I could have done dyndns or something else but it was more fun this way :)


Here is my topology and I will post relevant configuration from the Cisco router and the Linux machine. So let's get started.

Configuring basic OSPFv3

In this blogtorial we are going to talk briefly about OSPFv3. I will not be going into much detail and writing paragraphs explaining the details of OSPFv3 but rather give you a simple "how-to" on configuring OSPFv3. 


We will be using a simple 3 router topology below. So let's get started. 

Objective: 

• Configure ipv6 address on R1, R2, R3. 
• Configure loopbacks so the OSPFv3 process can start. 
• Verify ipv6 connectivity.

Configuring OSPF - NSSA (Not-So-Stubby-Areas)

In this blogtorial we are going to talk about OSPF Not-So-Stubby-Area (NSSA). So we learned from my previous blogtorial that we can turn an Area into a stubby area to reduce the size of the database, but what if that Area is also connected to another domain such as an EIGRP? Well that's where NSSA comes in.


We will be building on this topology. Similar to the topology from my previous blogtorial but slightly different. Note that the topology shows more than what we really need so just pay attention to Area 0, Area 1 and eigrp domain 20. Alright let's get started.

Relevant configurations are posted below. 

Configuring OSPF - Totally Stubby Area

In this blogtorial we are going to talk about OSPF Totally Stubby Areas. If an area does not connect to any other areas or if the area is really a spoke then Totally Stubby Areas are the way to go. It will inject a default route and that's it. 


We will be using the same topology from my previous blogtorials. So let's get started. 

Objective: To configure Area 1 as a Totally Stubby Area and see how it affects the routing table of R5 (in Area 1). 

Configuring OSPF - Stub Area

In this blogtorial we are going to talk about OSPF Stub Areas. We can use stubby areas to limit the size of the OSPF database and when you have 100s of routers and 1000s of routes this can be very useful. 


We will be using the same topology from my previous blogtorials. So let's get started. 

Configuring OSPF inbound route filtering

In this blogtorial we are going to talk about inbound route filtering meaning we will not take a certain "route". We are going to see 4 different ways of doing it -- prefix lists, route-maps, area filtering (LSA type 3), and area summary not-advertise.


We are building on the topology from my previous blogtorials. So let's get started.

Objective: Filter R5 loopback (172.16.5.0/24) from making it into R4 routing table and allow everything else into R4 routing table. Filter R5 loopback (172.16.5.1/32 which is in Area 1) from making it into Area 0.


Relevant configurations are posted below.

Configuring OSPF Virtual Links w/ GRE tunnels

In this blogtorial we are going to discuss on how to link an OSPF area which is not directly connected to Area 0 using GRE tunnels. Why would you ever want to do this? I don't know :) maybe in the CCIE lab exam. I strongly recommend not using GRE or Virtual links but they do exists for a reason. 


We are going to be building on the topology from my previous blogtorials. So let's get started.

Relevant configurations are posted below but basically all we are doing is creating a GRE tunnel between R5 and R4 and putting the tunnel in Area 0.

Configuring Advanced OSPF - Virtual Links

In this blogtorial we are going to talk about OSPF virtual links. As you already know all areas must connect to area 0. However, if you have an area not connected to area 0 it is possible to use virtua links to accomplish this.


We are going to be building on the topology from my previous blogtorial "Configuring Advanced OSPF". So let's get started.

Relevant configurations are posted below.