Pages

Tuesday, October 25, 2011

Enterprise Campus Design - Part 1

In this blogtorial we are going to dive into how to effectively and efficiently design an enterprise network. As I have always said "Networking is an art not science" as there are numerous ways to design and I am merely posting one of many. 

In this topology we will sink our hands into: 
  • STP (802.1d)
  • HSRP
  • OSPF 
    • OSPF route summarization
  • VTP
  • Different layers/modules of Enterprise Campus Design

Check out the topology below and let's get started. 


Relevant configurations are posted below.

Thursday, October 20, 2011

Configuring InterAS MPLS VPNs - CSC (Carriers Supporting Carriers)

In this blogtorial we will take a peek at how to configure InterAS MPLS. InterAS MPLS can be deployed to support customer sites traversing different SPs (Service Providers). 

In this topology we will have 3 customer Sites. 2 of them connection to two different PEs routers in the same AS and another site connected to another PE router in a different AS. 

Topology below and let's get started. 



Relevant configurations are posted below.

Monday, October 10, 2011

How to configure QOS with IPSEC VPN

In this blogtorial we will discuss how to do QOS with IPSec and the challenges that are associated with it. 

Consider the topology below and let's get started. 

Relevant configurations are posted below. 

Wednesday, September 28, 2011

Configuring MPLS FRoMPLS DLCI-To-DLCI

Recently, I have been posting about AToM (Any transport over MPLS) and to continue I will post how to configure Frame Relay DLCI-TO-DLCI in this blogtorial.

Consider this simple topology and let's get started.


Relevant configurations are posted below.

Tuesday, September 27, 2011

Configuring MPLS EoMPLS VLAN Mode - L2VPN

In this blogtorial we will configure EoMPLS VLAN mode so we can preserve the VLAN tagging from one site to another. Consider the simple topology and let's get started. 


Relevant Configurations are posted below.

Tuesday, September 20, 2011

Configuring QEMU (Linux Host) in GNS3

In this blogtorial we are going to see how to configure a Qemu Linux Host. I will keep this simple with screen shots and less words. So let's get started. 

1. Download GNS3 and get it setup. 
2. Download Linux MicroCore image. 

Now follow the screen-shots and you should be good to go.

Wednesday, September 14, 2011

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.

Friday, September 2, 2011

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.

Wednesday, August 24, 2011

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.

Tuesday, August 23, 2011

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!! 

Thursday, August 18, 2011

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.

Tuesday, August 16, 2011

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. 


Monday, August 15, 2011

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.

Thursday, August 11, 2011

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.

Wednesday, August 10, 2011

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.

Tuesday, August 9, 2011

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.

Sunday, August 7, 2011

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.

Friday, August 5, 2011

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.


Thursday, August 4, 2011

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.


Wednesday, August 3, 2011

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. 




Tuesday, August 2, 2011

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.

Configuring Advanced OSPF

In this blogtorial we are going to talk about OSPF redistribution, authentication, ASBR, and default routes.


OSPF redistribution: We can redistribute networks into OSPF from static, connected, or from other protocols such as EIGRP.


Authenticate: We can configure md5 authentication on OSPF to provide security.


ASBR: Autonomous System Boundary Router -- basically a router which connects to networks using a routing protocol other than OSPF and inject routes into OSPF from those routing protocols.


Overview: We have Area 1 connected to Area 0 and EIGRP AS 10 connected to Area 0 through R2. We will take routes learned through EIGRP and inject them into OSPF and we will also take routes learned from Area 1 and inject them into Area 0 and vice-versa.

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

Configuring basic OSPF


Brief tutorial on how to configure a single area OSPF with no authentication. 
Overview: 4 routers configured with 4 loopbacks. 




Relevant configurations for R1, R2, R3, R4 are posted below.