bgp confederation ( cisco with fortigates peers )

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



.  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
       /     \