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.
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.
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.
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.
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.
"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).
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.
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.
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.
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.
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
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.
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)
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.
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!!
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.