Message: 2
Date: Tue, 1 Mar 2011 23:56:27 +0000
From: Matthew Moyle-Croft <mmc@internode.com.au>
To: Cameron Kerr <ckerr@cs.otago.ac.nz>
Cc: nznog <nznog@list.waikato.ac.nz>
Subject: Re: [nznog] How common is unfiltered BGP?
Message-ID: <5AE909E2-8640-4BDD-ABA4-1D88F9E66B7F@internode.com.au>
Content-Type: text/plain; charset="us-ascii"
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<http://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