In this post, we will look at a simple BGP confederations.
1st here's my topology;
FGT200A AS#2
cisco 3825 BGP confederation AS#100/65051
cisco 3825 BGP confederation AS#100/65052
FWF60D AS#1
Okay, so we have a AS#100 that's sub-divided into 2 unique ASes ( 65051 and 65052 ). External routes from fortigates devices ( FWF60D & FGT200A ) , will be populated across this bhp-confederation.
So let's start out with the cisco router bp configs for bgp confederations # 650051/650052
router
pe1
router#
pe2
Key points;
- your router bgp "AS#" is your bgp confederation ID
- You must define the other peer members sub-ASes, you can add multiple AS#s to this line as indicated with my type ( 650051 ).
- You define your bgp neighbors like any legacy bgp configurations
For the fortigate devices, we have the following;
FWF60D
NOTE: For the FWF60D , we do a little of metrics additions , to validate if the bhp confederation passes any metrics across the federation and to other bgp-confed-peers or external bgp peers
A simple route-map with a prefix-list;
FGT200A
Similar to the FWF60D, but we will inject 2 prefixes ( 192.0.2.1/32 & 192.0.2.2/32 ) and with no route-map applied.
Both Fortigates are peering to a router in AS#100.
Okay, see how simple that was ?
This took approx all of 10mins to configure & I spent more time putting this post together than the configuration :)
Okay, once all bhp neighbors are up, we can review the individual bgp tables to witness how the AS-PATH will look within this bgp confederation.
1st cisco3825
pe1
NOTE1: As you can see, our AS# is 65051 within the bgp-confederation, but anybody not identified as bgp-confed-peer would see us as AS#100
NOTE2: We have neighborship to a eBGP peer outside of the confederation and one within the bgp confederation
Moving on,
Let's take a look at the 2nd cisco router bgp table for cisco
pe2;
As you can see, it has a local learned router from a eBGP peer at 50.50.50.2 ( FWF60D ) and a neighbor ship to another bhp-confederation peer from AS#65051 ( router1 c3825 ). This neighbor passed the prefixes 192.0.2.{1-2} from AS#2 ( FGT200A )
I want to stop here and point out the obvious;
- bgp confederation peer <AS_PATH> information is always reflected as ( AS##### ) and these sub-AS# are dropped when the path is advertised outside any of the bgp-confederation-peers
- The 2x fortinet devices has no clue they are peering to bgp-confederations members, nor the size of the confederation, since as_path is drop for the outside AS#100. This confederation could have been 4 sub-AS deep, we would never know outside of the sub-ASes
- The metric of #666 is being carried within the bgp-confederation and amongst it's members, but dropped outside of the confederation and parent AS100
So let's see what the fortigates BGP tables show?
FGT200A
Let's stop and look at this closely. The FWF60D prefix that was advertised on the other side.
It came across from AS_PATH
^1_100_2$ --> into the FGT200A (AS2).
The bgp-metric was dropped, as normal expected behavior for any intra-as-metric (
remember the earlier post, "metrics are not carried outside of a AS" and is considered a optional / non-transitive path_attribute ).
My FGT200A is peer'd directly to 60.60.60.1 ( cisco 3825 aka pe2 ) , but that router is really configured in sub-AS#65052. The bgp-confederation, uses it's bgp-confederation-identifier for a non-BGP confederation peers.
In closing, BGP confederations is just an alternate strategy for breaking up a hug he AS into smaller subset. This allows for smaller full meshing of iBGP peers, and scale much better as your network grows in size and number of iBGP peers. Trying to maintain more than 12-20 iBGP in a fullmesh or with route-reflectors, get's to be a major challenge & does not scale well.
If you didn't know;
"BGP has a rule that all bgp routers in a AS, must be fully meshed or connected to a route-reflector(s) that are fully-meshed or use a bgp-confederation as alternative approach".
( quote )
http://tools.ietf.org/html/rfc5065
RFC 5065 August 2007
1. Introduction
As originally defined, BGP requires that all BGP speakers within a
single AS must be fully meshed. The result is that for n BGP
speakers within an AS, n*(n-1)/2 unique Internal BGP (IBGP) sessions
are required. This "full mesh" requirement clearly does not scale
when there are a large number of IBGP speakers within the autonomous
system, as is common in many networks today.
(/quote)
In my example, AS#100 was broken into 2 sub-ASes, but in a true servivce provider network, they might have a few dozen or more sub-ASes and any where from 10, 100 or more bgp-routers installed.
The path in this case, was carried over 2 sub-ASes ( 65051/65052 ). The fortigates, both eBGP peers and non-confederation peers, see them as AS100. BGP confederation in this blog example, was overkill and I would not even consider using a BGP-confederation, unless you had more than 10+ routers.
As a interesting topic, almost all commercial routers has support for BGP confederations. Even the fortigate firewall supports bhp-confederations;
The size of the sub-ASes peers, has to be designed around the memory,cpu and network topology being deployed. And we usually uses private-ASes in the 64512-65535 range. You have to be careful of this range to not overlap with any private-as that's might be used by a client. I myself like to use AS numbers closer to the bottom of this range ( i.e 65412-65499 ) this give you plenty of room and almost never collide with any other private-as usage YMMV
Most ISPs that deploys bgp-confederations, tries to keep the sub-ASes within the same regional area. And run fully meshed links to other subASes.
Take this example of a private bgp network that I worked on back in the early 2000s using junipers. They had a design based similar to this diagram and layout across the US. It scaled well and had very little problems. Management of any part of the confederation was straight forward and simple. Each color semi-circle would be a sub-AS.
I hope this has been helpful for understanding the basic of building bgp confederations.
Ken Felix
Freelance Network / Security Engineer
kfelix ----a---t---socpuppets ---d---o---t---com
^ ^
=( @ @ )=
o
/ \
