Route aggregation in BIRD - how?

[Jérôme Nicolle]

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

Le 15/08/2012 22:04, Ondrej Zajicek a écrit :
> 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.

You're right, the simplier approach would be to agregate only on the
next-hop and strip every other atributes before sending to the
downstream router.

Still, it'd be usefull to try not to strip the originating AS in order
to use NetFlow agregation for trafic statistic per-AS. Obviously this
isn't possible on a 32k maximum route limit, it should still be
possible on a 200k route limit.

Even so, if the route-limit is reached, then stub ASes could be
stripped, leaving only source's transits in the path. A transit ASes
list coul be fed to the algorithm, in order to strip ASes reached via
these transits.

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

Typical switch would be a Cisco 3560G our 3750G : approx 32k routes and
BGP support. Lower end switches (HP, BDCOM) would lack a proper BGP
support (if any), but RIP could be used instead.

Just to clarify : a Cisco SUP32-8GE (intended for a 6500 series chassis)
is approx 650€ from a decent broker. SUP720-3B is 100€ more. It's
basically a castrated SUP720-3BXL (approx 2500€) : same forwarding
capacity, only a smaller TCAM. With 8 integrated GE ports and 225€ for
a 16 GBIC linecard, it gives us a 40 port 32Gbps capable router for
approx 1500€

Foundry's BigIron 4000 with jetcore route processors are still
capable of forwarding 20Gbps but can't stand more than 200k routes
approx. I saw most of them used as door-stops recently, one with a 16x1G
SFP can be found for less than 1000€.

So the goal could be to let small ISPs use these boxes to scale
bandwidth-wise from a software-routed network, without paying a few
extra k€ for up-to-date cisco gear. Discociating data and control plane
is also the only way to protect against DDoS.

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

I see two possible setups, the proper one requiering a specific
configuration from the peer.

The "proper" way would be to establish two interconnexion (at least two
subnets on the same L2) : one for the session to the BIRD router, the
other for actual forwarding to the L3 switch. Most L3 switches are
either L2 on L3 to one port, so it'll require a basic L2 switch between
the peer and the router and L3 switch.

The "dirty" way would be to use a NAPT capable switch/router, to
redirect TCP/179 originating from the peer to the software router. This
should be supported on Cisco 6500 series. I need to get my hands on a
SUP32 to check this.

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

iEYEARECAAYFAlAsEecACgkQbt+nwQamihtgdQCcCaUs4Ws16/OT4HZHhzcxu4Vn
VWIAnjk007ia3GYIp219JNy9FsHm/fLi
=hnUp
-----END PGP SIGNATURE-----