[afnog] bgp communities - please

[Mark Tinka]

On Wednesday, October 13, 2010 12:41:43 pm Frank Habicht 
wrote:

> to explain more:
> peers at IXP get prefixes with NO_EXPORT.

So this is a classic scenario where your exchange point 
peers' downstream BGP customers would potentially lose out 
on receiving your prefix announcements via their provider as 
the session between them and their provider (your peer) is 
normally eBGP.

> and some prefixes, of former or inactive customers are
> getting out to upstream.
> Causing pain to _my_ customers who's prefix I announce at
> IXP and it gets leaked out (and blackholed)  :-(     
> [1]
> 
> through 3 different peers leaking already (not
> continuously). getting close to a) naming them in public
> and b) asking their upstreams on Nanog to filter them
> more.

This is a problem I've identified and described numerous 
times to a few friends and colleagues. It is very difficult 
to trust that your exchange point and private peers will NOT 
re-announce your prefixes out their transit providers when 
they shouldn't. It is almost always the case that this 
happens by mistake, but even this is as damaging as doing it 
on purpose (for the paranoid).

This is one of the reasons I've found it very, very 
difficult to implement strict (or even loose) mode uRPF on 
public and private peering links because when your peers re-
announce your prefixes out to their transit providers by 
mistake or otherwise, traffic will always get blackholed in 
the case where you use dedicated public and private peering 
routers, i.e., those routers do not have a full view, and 
any traffic your peers would be attracting to you by leaking 
your routes out where they shouldn't would get dropped 
instantly because the reverse-path check would fail.

If you peered with your private and public peers on routers 
that you use for transit, i.e., they contain the full BGP 
routing table, loose mode uRPF would work fine since the 
routing table has a route back to the source of the traffic. 
But of course, several networks prefer to have dedicated 
boxes for non-transit peerings.

It is a real problem!

In the realms of detection, I've found BGPmon to help a lot 
here. When any of your non-transit peers begin announcing 
your prefixes to the Internet, BGPmon will sound an alarm 
and that's your cue to pick up the phone or drive over with 
a baseball bat. Plus, it's free :-).

Implementing BCP 38 + RFC 1918 filtering + RFC 3330 
filtering is always best practice on peering links - public, 
private and transit.

> at $dayjob I recently started to use communities here and
> told ISP customers:
> put this (37084:999) and we won't announce to upstream.
> First most useful community. Still advertised to peers
> and customers.

This is a useful type of community for many reasons. Some of 
the typical ones are:

	- your customers who also have a link to one of your
	  own upstreams, and find it redundant to have their
	  routes appear in that upstream's routers twice
	  (the problem with this is your high-end customers
	  could end up loading one or more of your links
	  with more traffic than you can handle, especially
	  if you both choose the same provider you consider
	  to be the best).

	- blackholing of DoS traffic.

> everyone: you can do that too!
> 
> Frank
> 
> [1] and yes..... if it wasn't multilateral peering
> .......

It might be time to have a sit-down with your peering 
partner(s).

Cheers,

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/20101014/864bf078/attachment.pgp>