Configuring DMVPN with OSPF (mGRE and IPSEC)

"I can build you any network you want -- fast/cheap/reliable. Just pick any 2" -- Not sure who said that however  it is true on many levels.

In this blogtorial we are going to take a quick tour on how to configure DMVPN (Dynamic Multipoint Virtual Private Network). So what is DMVPN? DMVPN gives you the ability to create VPN tunnels dynamically as needed between spokes in a hub-to-spoke topology. It can also scale very well to support a large number of remote endpoints. Please keep in mind that DMVPN is Cisco proprietary, however there are ways to implement it using Linux (OpenNHRP).

So here is the topology and let's get started.

Relevant configurations are posted below.

Configuring MPLS Traffic Engineering

In this blogtorial we are going to see how we can configure MPLS Traffic Engineering (MPLS TE). With MPLS TE we can achieve SONET (50ms) style failover between links and we can achieve this by creating backup tunnels and using fast re-route.

In this topology we will be configuring both explicit/static tunnels/paths and also dynamic auto-tunnels. 


Consider the simple topology below and let's get started.

Relevant configurations are posted below.

Configuring MPLS L2VPN InterAS VPWS - EoMPLS Port Mode

In this blogtorial I am going to show you a quick how-to on implementing L2VPN and more specifically Virtual Private Wire Service (EoMPLS Port Mode). VPWS can save money thus increasing the revenue for service providers because P2P circuits are usually more expensive. We are going to be configuring EoMPLS (Ethernet Over MPLS - Port Mode). Note: EoMPLS Modes - Port Mode, VLAN mode and VLAN Re-write mode. AToM (Any transport over MPLS) is sort of the umbrella which covers EoMPLS, FRoMPLS, and ATMoMPLS.

Consider the simple topology below.

Relevant configurations are posted below.

Configuring BGP - Redundant Route Reflectors

In my previous blogtorial we saw how we can deploy route reflectors to circumvent the need for iBGP full mesh design. And my good friend "IT GURU" Tom brought up a good point about redundancy. So in this blogtorial we are going to see how we can configure dual route reflectors to avoid single point of failure (SPOF).


Consider the topology below.

Imagine that R3 and R4 in Sparks, R5 and R6 are in Vegas and R1 in Reno and R2 in Wells. If Reno Route reflector goes down all remote locations will still able to get to all other locations. 


Let's get started!! 

Configuring BGP - Route Reflectors

To route reflect, or not to route reflect, that is the question. If a full iBGP mesh is required then consider Route Reflectors. If you had to iBGP full mesh 10 sites you would need 45 iBGP connections (10*(9)/2 or n * (n-1)/2 where n is the # of sites) = NIGHTMARE!!! In this blogtorial I will show you how to deploy a route reflector and drastically reduce the number of connections needed to achieve the same results as a full iBGP mesh design. 


Consider the simple topology and let's get started. 

Relevant configurations are posted below.

Configuring FHRP - IRDP

The less known, the unpopular, the quiet and the secretive protocol of First Hop Redundancy Protocol (FHRP) is ... dun dun dun .. IRDP (ICMP Router Discovery Protocol). In this blogtorial we will configure IRDP which uses 'ICMP' to send the default gateway information to hosts. This will be a short and simple blogtorial so consider the topology below and let's get started.

Objectives:

• Configure R1 and R2 to with IRDP
• R1 should be the primary default gateway and R2 should be the backup default gateway
• R2 should take over when R1 goes down

Relevant configurations are posted below. 

Configuring FHRP - VRRP

Both FHRPs (HSRP & GLBP) are Cisco proprietary so what do you when you have to support a Cisco and a non-Cisco device in a redundant setup? Well you turn to the industry standard Virtual Router Redundancy Protocol (VRRP) RFC 2338. One of the biggest advantages of using VRRP is that you do not need an additional IP for the "Virtual IP". It can be the IP of the actual interface. For example in both HSRP and GLBP blogtorial you can see how my virtual IP was set to 192.168.1.254, however on this blogtorial notice that my virtual IP is the same as R1's interface IP (192.168.1.1). 

Consider the topology and let's get started. 

Objectives: 

• Configure R1 and R2 with VRRP and authentication
• R1 should be the master router and R2 should be the backup router. 

Relevant configurations are posted below. 

Configuring FHRP - GLBP

In my previous blogtorial we saw how we can configure HSRP. One downfall for using HSRP is that you can only use one router at a time. What if you wanted to use both R1 and R4 for load-balancing and failover? This is where Gateway Load Balancing Protocol comes in. Note that GLBP is Cisco proprietary. 

Consider the simple topology below. 

Objectives:

• Configure R1 and R4 in a GLBP group with authentication
• Configure R1 to be Active Virtual Gateway (AVG) and R4 to be Active Virtual Forwarder (AVF)

Relevant configurations are posted below. 

Configuring FHRP - HSRP

In any network, redundancy and high availability should be a top priority especially when it involves mission critical applications. In this blogtorial I am going to walk you through how to configure Hot-Standby Routing Protocol aka. HSRP. HSRP is a one of many First Hop Redundancy Protocol (FHRP). Note that HSRP is Cisco proprietary.

Consider the topology below and let's get started.

Objectives: 

• Configure HSRP on R1 and R2 with authentication.
• Enable failover in less than a second. 
• R1 should be the active router and R2 should be on standby
• If R1 goes offline, then R2 should take over and when R1 comes back online then R1 should take over. 

Relevant configurations are posted below so let's proceed.

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.