[afnog] How to convince providers to take the sane option....

[Fredy Kuenzler]

Andrew, all,

Am 13.05.2014 17:18, schrieb Andrew Alston:
> I’m in a little bit of a rant mode in this post and openly admit it,
> but I’m getting REALLY frustrated and hoping someone here might have
> some advise on how to convince providers to actually do what is sane
> rather than what hurts them and hurts everyone else in the industry.

Understood, full ack.

> So, to describe the problem.
> 
> Certain providers in East Africa are announcing aggregate routes to 
> exchange fabrics and then announcing de-aggregate routes to their 
> transit providers who are not on the exchanges, do not peer, and
> have all their traffic going internationally.

This does not only happen in East Africa, but worldwide. Which is not
giving a clean sheet to the polluters, no matter where they are.

> Despite explaining the situation to the relevant providers, over and 
> over again, and concretely demonstrating the negative effects of
> what they are doing, the only answer you get is “We aren’t changing,
> we do traffic control like that”

I was preaching traffic engineering for inbound-heavy (eyeball) networks
in the past but apparently with little effect...
http://www.blogg.ch/uploads/BGP-traffic-engineering-considerations-v0.3.pdf

> Now, that there is a solution, drop the entire AS number from the
> global table on the European transit ingress which will force the
> aggregates coming via the exchange to be used, but that seems to be a
> horrible solution, since an outage at the exchange then causes a
> complete blackhole to that ASN and drastically reduces redundancy.
> But it seems also to be the only solution left when providers choose
> not to take the sensible option.

What we do is filtering on transit on prefix level, for example:

10.20.0.0/16 Prefix learned via exchange and via transit, and several
more-specifics learned via transit only, the config snippet would look
like this (Brocade syntax):

!
ip prefix-list TRANSITFILTER seq 5 permit 10.20.0.0/17 le 24
ip prefix-list TRANSITFILTER seq 10 permit 10.20.128.0/17 le 24
ip prefix-list TRANSITFILTER seq 999999 permit 0.0.0.0/0 ge 8 le 24
!
router bgp
 neighbor x.x.x.x remote-as [TRANSIT-AS]
 neighbor x.x.x.x prefix-filter TRANSITFILTER in
!

which would basically filter away any more-specific from transit, except
the covering /16 prefix. If the peering session fails, there is still a
backup path via transit.

To figure out the relevant prefixes it's useful to do a
'show ip bgp route regexp [_POLLUTING-PEER-AS_]'

This means manual work but after all it works. Init7 AS13030 is
meanwhile filtering around 10k polluting more-specifc prefixes away from
transit.

More info could be found here:
http://www.blogg.ch/uploads/routing-without-collateral-damage.pdf

Hope this helps.

-- 
Fredy Kuenzler

Init7 (Switzerland) Ltd.
AS13030
St. Georgen-Strasse 70
CH-8400 Winterthur
Skype:   flyingpotato
Phone:   +41 44 315 4400
Fax:     +41 44 315 4401
Twitter: @init7 / @kuenzler
http://www.init7.net/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://afnog.org/pipermail/afnog/attachments/20140513/baadfcf9/attachment.sig>