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

Andrew Alston Andrew.Alston at liquidtelecom.com
Thu May 15 06:23:07 UTC 2014


Agreed 100% with Frank on the community option.  It's my preferred option for controlling virtually all BGP.

Communities applied typically:

In the case of exchanges:

One generic community for do-not-announce-to-non-customers
A community applied for every route coming in from exchanges in a particular country

In the case of customers:

Tag them based on the country they are connected in (makes them nice and trackable)
Double tag with a community to indicate it's a customer route.

In the case of our own routes:

Tag them based on the country they are originated from, double tag with a community to indicate an internal route.

A lot of people don't like to disclose the communities they use as it gives information about network engineering, but this is relatively easily solved, match it in your announcement map and then strip it before announcement if you feel the need.

Thanks

Andrew

-----Original Message-----
From: afnog [mailto:afnog-bounces at afnog.org] On Behalf Of Frank Habicht
Sent: Thursday, May 15, 2014 7:19 AM
To: afnog at afnog.org
Subject: Re: [afnog] How to convince providers to take the sane option....

Hi,

On 5/14/2014 7:24 PM, Patrick Okui wrote:
> One reason this has developed in certain cases is partly historical -
> like what we're cleaning up in the UIXP in Uganda.
>
> It starts with everyone peering exchanging all routes, then a few of
> the providers leak the routes cross-border to say the KIXP in Kenya.

without the knowledge/approval of the "owner" ?
bad start....   :-(
(yes, most likely it's a former customer)

> Configuration mistakes mean if that's not controlled these IX
> advertised routes are leaked to the Internet. Depending on how well
> peered a provider is, the Internet may prefer their path (eventually
> via the IX) and while this "free transit" may be interesting to have
> it's not one for which a service agreement exists and in some cases
> may be worse than the egress links the affected party has.

ack. been there.


> To make matters more interesting some people only peer with the route
> server and not bilaterally, so it's difficult to control which peer
> gets what and they decide to either shut down their link or announce
> only aggregates plus very few specifics.

Even if all peers get everything...
... still they should not announce things they get from peering to other peerings or even to upstreams.
static prefix lists are bad because they will become outdated.
I know many of us know this song.

Best solution I see is communities.
- Define one community called "don't advertise to upstreams"
- add this community to all routes learned from upstreams. and to all
  routes learned from peering
- don't advertise these routes to upstreams.
  and don't advertise these routes to other peerings.
  ie first rule in the route-map to upstreams:
     deny anything matching that community

Frank


_______________________________________________
afnog mailing list
http://afnog.org/mailman/listinfo/afnog

DISCLAIMER:  This email contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an addressing or transmission error has misdirected this email, please notify the author by replying to this email. If you are not the intended recipient, you must not use, disclose, copy, print, or rely on this email.  We cannot accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of this company or one of its agents.




More information about the afnog mailing list