[afnog] Weekly Routing Table Report

[Fredy Kuenzler]

Am 17.10.2011 10:10, schrieb Graham Beneke:
> I thought I'd work out who was responsible for the biggest proportion of
> this de-aggregation. Taking the original data, calculating the
> de-aggregation factor and sorting in descending order gives us the
> following as the top 30 ASNs in Africa:
>
> Factor	ASN	Num	/20s	MaxAgg	Description
>[...]
>
> Is *your* name on there?

I'm not too much into exposing the 'sinners' which are polluting the global 
routing table. What interests me more is: Why is this happening?

We (Init7 / AS13030) did quite some research work by analyzing the 
more-specifics. Fact is that a lot of networks seem to do some kind of 
traffic engineering by advertising the more-specifics on purpose to various 
transit suppliers. Example:

192.168.16.0/20 - aggregate, advertised to all transit providers
192.168.16.0/24 - advertised only to transit provider #1
192.168.17.0/24 - advertised only to transit provider #2
192.168.18.0/24 - advertised only to transit provider #3
etc.

so there is still a covering less specific prefix in case one transit 
provider fails.

This seems to be a common habit by many African networks (which tend to be 
inbound heavy / have mainly eyeball customers). I'm not sure whether there 
is a BGP consultant working in Africa proposing this practice for traffic 
engineering all over the continent ... as many networks do just the same way 
I tend to come to this assumption.

However there are better ways for traffic engineering than just 
deaggregating into more-specifics. I tried to explain a few techniques at 
the AFPIF day in Dar Es Salaam a few months ago:
http://www.blogg.ch/uploads/BGP-traffic-engineering-considerations.pdf

As our (Init7 / AS13030) network has more content than eyeballs, we figured 
that these more specifics are increasing our transit invoice for several 
gigabits by stealing traffic away from our peering. Example (from above):

192.168.16.0/20 - learned via peering - local pref 150 (overwritten)
192.168.16.0/24 - learned via transit - local pref 50  *WINNER*
192.168.17.0/24 - learned via peering - local pref 150
192.168.18.0/24 - learned via transit - local pref 50  *WINNER*

That means we would have the covering prefix by peering and use it normally, 
but the two /24 more specifics we learn by transit will overwrite the 
covering prefix and force traffic to transit.

And, as mentioned, this increases our transit cost by several gigs.

We have started to investigate and are in the process of building an 
automated filtering system to remove these more-specifics from our transit 
BGP feed. First result (needs certainly more fine-tuning): more than 10000 
prefixes less in the BGP table, traffic down to the acceptable level again, 
incease of peering traffic, mission completed.

No complains from customers regarding reachablility, only one BGP customer 
was curious why he gets only 360k routes instead of 370k routes.

Best regards,

Fredy Künzler
Init7 / AS13030