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