Route aggregation in BIRD - how?

[Alexander V. Chernikov]

On 16.08.2012 01:17, Jérôme Nicolle wrote:
> -----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.
For 32k or less it seems that several static defaults for outgoing 
traffic balancing is sufficient, since
it is not possible to do fine-grained route selection for all routes.
200k is much more promising:
11:19 [0] bmw# birdc 'show route primary where net.len < 24' | wc -l
   198369

It is possible to fetch RIPE/APNIC/etc (or RADB) database on route 
objects, filter more-specific route object,
and build long Aggregator {} configuration with "save attributes" part.
It will probably fit it less than, say, 150k and the rest can be used 
for IGP and local IX tables.
Some (how much?) of the aggregated routes will have different paths 
resulting in origin AS being hidden in AS_SET attribute.
If this number is significant I can improve AS_PATH merging algorithm to 
save originating AS if possible.

However,
1) it needs testing to determine exact number
2) In future, IPv4 sub-blocks selling between ISPs (and non-ISPs) will 
decrease effectiveness of such approach.

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