Tuesday, 31 May 2016

Containers (Docker) - OS Virtualization

Lately I have been looking at some application virtualization stuff. Majority of us are aware of  how server virtualization works however the concept of application virtualization is relatively new.

To understand what it is, let's first see what server virtualization is. In the old days, organizations used to keep physical servers to run their applications. Normally one physical server would be used to run one or two specific applications. Depending on the number of applications, companies had to maintain server farms which meant management of multiple Hardwares and Softwares, paying for CoLo space and electricity bill for all the physical devices.



















Wednesday, 30 March 2016

Migration Methods

In this post, we will discuss various options to migrate customer's network from one service provider to other service provider. 

Let's assume that you work for an enterprise customer with three sites. All the sites are currently connected through a Layer 3 IPVPN solution provided by service provider A.


Sunday, 14 February 2016

MPLS Traffic Engineering

In this post, we will discuss about MPLS Traffic Engineering. To understand where it can be used and what problems it can resolve, let's look at the below topology.

The CE1 and CE2 are customer edge devices with LAN subnet of 1.1.1.1/32 and 7.7.7.7/32 respectively. They are connected with corresponding PE1 and PE2. We are running OSPF and LDP in the service provider core. Both the PE devices exchange VPN labels via MP-BGP and transport label via LDP. 

Sunday, 17 January 2016

BGP PIC EDGE

Continuing from our previous post, we will now see how BGP PIC EDGE works. We will use the same topology. The only difference is that I have removed R4 as route-reflector. All the PEs have full mesh IBGP neighbourship. 

At the moment R2 learns 8.8.8.8/32 from R6 and R7. It prefers the path with the next-hop of 6.6.6.6 over 7.7.7.7.

Friday, 1 January 2016

BGP PIC CORE

Happy New Year Folks!

In one of the previous posts, we looked at EIGRP FRR and OSPF LFA feature which helps achieving fast convergence.

There is a similar feature  in BGP which is called PIC (Prefix Independent Convergence). It speeds up the convergence of the FIB in failover conditions. BGP works differently than any IGP. It is designed to carry hundreds of thousands routes in the routing table hence fast failover works differently in BGP. There are couple of ways to implement PIC in BGP. They are "PIC Core" and "PIC Edge". We will look into both of these options.

Let's look at the below topology.

Wednesday, 16 December 2015

VRF Aware IPSEC VPN

In this post we will see how we can support multiple VRFs in site to site IPSEC VPN implementation.

We will use the below topology. The routers CE1 and CE2 are connected to the Internet. For simplicity, I have used the private IP addressing for the WAN connectivity.



Ok so the first step is to configure required VRFs on both the CPEs.

Saturday, 31 October 2015

EIGRP IP FRR & OSPF LFA

In today's modern networks, fast convergence has become a mandatory requirement.
If we want to achieve fast convergence, each of the steps below need to be optimized

1. Failure Detection
2. Failure Propagation
3. Processing of new information
4. Updating RIB/FIB

1. Failure Detection:- "How long does it take me to detect a failure?"
This normally depends on the Hello/Hold down/Dead timers of the routing protocol. We can either tune these timers or use a mechanism such as "BFD" which we have seen in our earlier post.

2. Failure Propagation:- "How long does it take me to tell everyone else?"
In EIGRP, this is done through Query/Reply packets. We can reduce the Query domain by configuring the routers as "stub".

In OSPF, this depends on the area size and the LSA flooding procedure. We can tune the LSA timers to change this.

Friday, 18 September 2015

Carrier Supporting Carrier (CSC)

In this post we will look at the Carrier Supporting Carrier design where smaller service providers use large service providers as backbone in order to connect parts of their network which eliminates the need to build and maintain their own MPLS network.

From customer's point of view, there is no difference in terms of connectivity and it will still appear as they have a normal Layer 3 MPLS connection from the provider.

Let's look at the below topology to understand how it works.



We have a Tier 2 SP who is providing services to customer sites in two different geographical locations. The service provider have their own network within specific regions but not connected with each other directly hence they are using Tier 1 SP's backbone to connect both of their networks and provide end-to-end connectivity to the customer.

Saturday, 29 August 2015

Inter-AS MPLS VPN - Option C (BGP+Label)

In this post, we will look into the Inter-AS MPLS VPN - Option C which is also known as "BGP + Label". 

Option C uses eBGP IPv4 session between ASBRs to exchange reachability to PE loopbacks. There will be a VPNv4 neighbourship between service providers VPNv4 route-reflectors (RRs).

Option C takes away the heavy reliance on ASBRs. In this case, ASBRs are only used to exchange the loopback prefixes using eBGP IPv4 sessions.

To understand how it works, let's look at our topology below.



We have two service providers. Both are connected through ASBR routers. In this specific instance, we have local VPNv4 route-reflector for each SP. The customer site CE1 is connected to SP1 and CE2 is connected to SP2.

Thursday, 13 August 2015

Inter-AS MPLS VPN - Option B (VPNv4 EBGP between ASBRs)

So far we have seen the Inter-AS MPLS VPN using "back to back VRF" method. Even though it's a relatively easy method to implement, it has few drawbacks.

This procedure doesn't require MPLS enabled on the link between ASBRs however it does not scale very well. 

There is another method in which ASBR's establish VPNv4 neighbourship, exchange MPLS labels and can maintain end-to-end LSP. It is know as "Option B".

Let's see how it works. We are going to use the same topology as we used in last post.



The IP addressing and the core routing remains the same. The only difference is the configuration on ASBR where I have removed the EBGP neighbourship statement and removed the local VRF configuration.