Route aggregation in BIRD - how?

[Jérôme Nicolle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Le 24/01/2012 12:11, Ondrej Zajicek a écrit :
> I guess most users would want either aggregate received BGP routes
> to generate the default (or some more specific) routes for IGP (for
> this usage pattern it would be useful to have option for mandatory
> minimal number of routes to originate aggregate), or aggregate
> their IGP routes for origination to BGP.

I'd have great use of such an agregator, mainly to re-use older
hardware routers with limited FIB/TCAM size.

Beeing too clueless to code it, I'd just give some spec :
- - Take a full BGP table as an input
- - Provides customizable aggregation to a target route count
- - May agregate on the following criterias :
* Same AS-path (with or without stripping prepending)
* Same next-hop
* Every attributes matching (only the prefix lenght differs but the
longer is contained in the shorter, therefore only the less specific
prefix must remain)

Agregation could be destructive or not, meaning it will default to a
lower possible route-count without discarding any routing-policy, but
it could be used to reduce the route-count to less than 32k routes,
and therefore only match on the next-hop attribute, not taking care of
the originating AS (using upstream's), considering the best path
selection already occured in the source table.

BGP feeds -> single BGP RIB -> agregator -> minimized RIB -> iBGP to HWR
         (best paths selected)

The 32k route limit is intended to use a routing switch as a faster
forwarding plane that a small X86 box could have. Session between the
agregated table and the routing switch could be established using
either iBGP, eBGP on private AS, RIP or OSPF (for L3 switches with no
BGP support).

Some other decent hardware (Fondry BigIron or Cisco SUP32) may
accomodate up to 256k routes approx and could really benefit from such
feature, getting them back to usable state for a quarter of their 1M
routes TCAM counterparts' price tag. It looks like a better solution
to me than filtering to /21, adding a few default routes and hoping
for the best.

The major issue with such setup would be to accomodate upstream's
requirements (BGP session is usualy end-to-end, on-band, and this new
setup requires eBHP multihop or NAT on the data-plane to work).

Maybe this could also be a path to using BIRD as an OpenFlow
control-plane ?

best regards,

- -- 
Jérôme Nicolle
+33 (0)6 19 31 27 14
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAr43AACgkQbt+nwQamihunfgCdFPSbmKw9pqwxvFrJ0B4BIUkK
6lYAn3yktirN4ZWazuUaVHyDeFatx0bP
=QBwI
-----END PGP SIGNATURE-----