Cameron,

People filter in different ways and for different reasons:

eg.

At a small scale people filter based on prefixes.   At a larger scale people will filter based from, say, an AS-MACRO which turns into prefixes.   At a very large scale it might be ASPATH only as the number of prefixes from a customer might be too hard to deal with (ie. just sheer size of the configs on a router).

At a certain size it's just too hard to filter.  Some of our peers we can't successfully filter as their AS-MACRO alone is too large to successfully process and place on a router.  (These are peers where we see 40k+ prefixes).  

Then you're down to max-prefix "filtering" which might allow you to stop really dumb things - ie. full table leak, but doesn't stop the insidious things like leaking other people's prefixes where they may only have to send a few prefixes.

Some people make a deal out of having "unfiltered" transit - I guess it's okay if you have no systems in place for updating the filters automagically, but typically you can't get advanced features such as remote triggered blackholes unless you are filtered.

There are some hybrid approaches people use - eg.  they filter customers/peers from sending "largenets" (eg. Tier1 ASes such as 3356, 3549, 1239 etc as well as things like 15169 (Google) and 22822 (Limelight) etc).

At a larger scale you might end up with a mishmash of various things:

eg.

- We have strict filtering on customers and ask them to tell us their prefixes.
- We register all our prefixes with a registry (AS-4739 on rr.ntt.net - historical reasons) so our transit is filtered plus we have a good idea of what prefixes we're meant to carry.
- We filter by AS-MACRO as much as we can with peers
- We filter outbound our own routes against our own internal registry amongst other techniques.

But some places are hard:

eg. we're at some MLPA based exchanges where there's no useable filter.   Some bilateral peers don't register their routes.   There are places where ugliness happens.  Every now and again we have issues with peers leaking routes - either ours or someone elses and you need to have an operational technique to fix this.

My big issue with going for "unfiltered" transit is you can't have remote triggered blackholes, which are a useful technique for protecting you against DDoS by getting your transit to sink the traffic.   It's not to hard to figure out a system that allows your own filtered customers to go and announce prefixes to black hole and then back-to-back it with your transit.

MMC



On 02/03/2011, at 8:00 AM, Cameron Kerr wrote:

Hi everyone, I'm just updating my lecture on exteriour routing for this year, and am wanting to know more about the current state of unfiltered BGP, whereby a customer can advertise a prefix they don't have, their service provider didn't suitably filter the advertisement, and it disrupts other networks in the internet.

My previous impression, based on discussions around incidents such as the YouTube/Pakistan incident, lead to me believe "Most people don't filter", and I'm just wanting to see if that is [still] the case now.

(Also, thanks to Andy for the NRO nudge)

Cheers,
Cameron

_______________________________________________
NZNOG mailing list
NZNOG@list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog

-- 
Matthew Moyle-Croft
Peering Manager and Team Lead - Commercial and DSLAMs
Internode /Agile
Level 5, 150 Grenfell Street, Adelaide, SA 5000 Australia
Email: mmc@internode.com.au    Web: http://www.on.net
Direct: +61-8-8228-2909      Mobile: +61-419-900-366
Reception: +61-8-8228-2999        Fax: +61-8-8235-6909