Saturday, February 22, 2014

Scaling BGP Part 2 - Using Route Target Constrain To Scale PE

One of the common problem with MPLS based L3 VPN services from Service Provider perspective is PE Scalability. Specially If the Implementation in the Core is using VPNv4 Route Reflector (VPNv4 RR).

When VPNv4 RR receives routes from PEs, It's job is to reflect all different customer routes to another PEs without considering the fact that particular Customer VRF might not exist on specific PE. Which is most likely the case in Real world. Which is certainly a problem from PE Perspective.

One of the way PE get rid of this problem itself is that by Default Automatic Route Filtering (ARF) is enabled on all PEs which suggest a rule that if routes are received for particular VRF and that particular VRF doesn't exist on PE locally, it's gonna filter out those routes automatically. However this logic or rule doesn't apply to VPNv4 Route Reflector itself since it doesn't make sense to put it in Data/Forward Plane. And if it's not in Data Plane than creating and mapping VRFs locally doesn't make any sense.

On the flip side , however ARF is good tool to have in pocket from PE perspective. But problem is that routes are still getting received from Route Reflector (RR) and getting filtering after that which means wastage of local resources and bandwidth.

So the question is, How Do We Fix This ?

The Answer lies in something called Route Target Contrain as defined in RFC-4684. I'll talk about AFI and SAFI in next post. But lets assume that this feature signals the RR from PE perspective about which all VRFs locally exist on that particular PE, resulting RR not Reflecting unnecessary routes towards that PE for VRF that doesn't exist locally on it.

Here is a quick example :

In This Particular Example PE-2 doesn't have VRF-B configured locally. So It doesn't need to receive Reflected Routes from RR for VRF-B.

Before RTC: RR Sending All Routes for All VRFs to PE-2

After RTC: RR Sending Only Routes For VRF-A to PE-2


Further Verification:

Pitfall :

From Planning Perspective, you need to understand that this feature is not only IOS dependent but also would require to be enabled not only on VPNv4 RR but also on PE under consideration.

Deepak Arora

Tuesday, February 18, 2014

Evil Return....Good To See Scott Is Back

Just in case you haven't noticed yet, Evil has returned back to training industry. It's been since Jan 2010 when Scott left INE and joined Nova DataCom and later Copper RiverIT. Since then we didn't see any learning products from him. Though he was quite active on CLN.

Now Scott is returning back as part of CBT Nuggets Team and he will be mainly focusing on Juniper side of entertainment. So I have now absolute no excuse to not to learn Juniper this year and Make changes into my year 2014 Plans :)

Deepak Arora


Saturday, February 15, 2014

Sunday, February 9, 2014

Scaling BGP Part 1 - IPv4 RR Implementation Using Table Map Feature

One of the common challenge with almost every routing protocol is SCALABILITY. When it comes to BGP, one of the key requirement under IBGP Specification was to implement Full Mesh. Which is OK most most of Small Enterprises but the solution doesn't scale very well as the Number of IBGP speakers increases. Particularly in Full Mesh Design you need to have n*(n-1)/2 number of peerings which is potentially an Administrative Nightmare.

So couple of solutions were implemented to overcome this issue namely:

> Route-Reflectors(RR)
> Confederations

Technically you can have Route-Reflectors within confederations also but we will not be discussing that or confederations today.

Now one of the potential Scalability issue with Route-Reflector itself is How Many Number of IBGP sessions it can support before it becomes over loaded and we need to introduce another route reflector.

But also part of equation is to figure out if there are any Inbuilt Features into BGP or IOS to help with this scalability problem.

Now in most design or if we follow best practices, the Router Reflector don't need to be/shouldn't be in Traffic Flow Path (Data Plane).

Which means Route Reflector doesn't need to waste it's memory to download BGP routes into its RIB or Routing Table. Which further means avoiding overhead of programming RIB into Hardware and Populate FIB and Going even further if it's a distributed platform and it's using dCEF or something.

So most of the time Number of BGP routes are pretty large in count under most BGP implementations, specially if it's RR and reflecting Internet Routing Table which is about half a million routes these days. 

So won't it be cool if we can avoid Route-Reflector to download BGP routes into RIB and just keep it in BGP RIB (BGP Table). As now we can use lots of this extra memory to build more IBGP peerings and scale out.

The answer to this is something called "TABLE MAP" in BGP.

Table Map is a flexible tool which offers many cool features and one among those is to help with problem we just talked about - Stopping BGP Routes from installing in RIB at Route Reflector.

Here is a quick example of how to use this cool feature:


Deepak Arora

Saturday, February 1, 2014

How To Change Regular BGP Config Format To Address Family Format

While the World of BGP is keep on changing like any other routing protocol in terms of development, one of the thing that's commonly becoming standard these days or perhaps there is lot of push towards that direction in recent times is adopting the Address Family Structure to keep things neat and clear in terms of configuration review.

Also when it comes to BGP, the configuration lines grow very quickly in Large Enterprise & Data Center environments. And BGP is taking a major place into DMVPN and Large Scale Data Center Environment where Cisco is pushing it under Best Practices in terms of Routing protocol choice.

So one of feature BGP supports to help us with Address Family Structure or it's adoption without creating much pain in butt is - BGP Upgrade CLI.

Here is a quick Example:

Deepak Arora