Route aggregation in BIRD - how?

[Ondrej Zajicek]

On Wed, Aug 15, 2012 at 07:59:18PM +0200, Jérôme Nicolle wrote:
> - 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)

Don't really understand this. For that purpose you could aggregate
everything with the same next-hop, other attributes are irrelevant. We
could think about it not as an BGP route aggregation, but as a
generation of completely new table that is more compact but equivalent
w.r.t. packet forwarding.

> 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).

Optimal solution would be iBGP to distribute aggregated table and OSPF
running on these routers/L3 switches as an IGP. OSPF could be probably
also used, but that would have some problems (esp. OSPF does not work
very well with too many LSAs - slow propagation because of simple
send-acknowledge model).

BTW, do you have an idea what capabilities these 'cheaper' L3 switches
usually have? (i.e. how many routes they support, and what routing
protocols they support - i have no experience with them and i heard
that these usually support just static routes)
 
> 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).

This could be probably handled by having BGP X86 router 'outside'
of network (i.e. on L2 network connecting upstream and 'fast'
router), that could be done if your 'fast' router / L3 switch
allows you to bridge ports to upstream and to BGP router.

-- 
Elen sila lumenn' omentielvo

Ondrej 'SanTiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20120815/1e7f4be7/attachment-0001.asc>