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:
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:
Dahh...
HTH....
Deepak Arora
Evil CCIE
2 comments:
How do you get the colors in the CLI output in Putty?
That's "terminal color"
Post a Comment