[afnog] Weekly Routing Table Report

[Mark Tinka]

On Monday, October 17, 2011 09:16:40 PM Fredy Kuenzler 
wrote:

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

The reason is always the same - traffic engineering.

However, I think that reason has somewhat degenerated a 
little into "best practice", especially so if offending 
operators haven't had a chance to attend industry meetings 
such as AfNOG.

> This seems to be a common habit by many African networks
> (which tend to be inbound heavy / have mainly eyeball
> customers).

South Asia and South East Asia are just as bad.

We have as many as 1,500 routes from a peer who could simply 
aggregate into a couple of routes. Amazing!

We also see it at our local peering exchange - folk 
literally take a block and break it up into sequential 
/24's, and have no shame in posting said blocks on the 
exchange point list to ask for filters to be opened.

We've warned members on the exchange point not to come 
complaining when our peering routers run out of FIB slots 
and we can't forward any traffic to those de-aggregates 
anymore, because there's simply no way we're upgrading our 
routers just to support someone else's bad habits.

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

Maybe that consultant is roaming the Asian streets too :-).

I've seen networks with only one or two upstreams that still 
de-aggregate to /24's. I posit that for up-and-coming 
operators, there is a misunderstood association between high 
traffic generation and /24's.

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

Yep, that crazy "longest match wins" rule - really pisses 
all over LOCAL_PREF :-). Gotta love it!

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

Well, I know many ISP's around the world are filtering out 
more-specifics in order to keep their FIB's alive. But if 
you're doing so move $$ around (which makes sense, and 
doubtful you aren't the only one), then we should all be 
scared. But that's reality, and I don't necessarily disagree 
with it :-). Folk are running a business, after all.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://afnog.org/pipermail/afnog/attachments/20111018/c8e578ed/attachment.pgp>