BGP Path Filtering

Sat May 17 00:00:00 UTC 2003

On Thu, 15 May 2003, Mark Radabaugh wrote:
> I'm having a hard time finding best practices for filtering outbound bgp
> announcements when providing transit to bgp-speaking customers.  While we
> currently multi-home to several providers it appears we will soon need to
> provide transit for customers with their own AS's.

There are several different methods possible, however be careful with
using the same sledge hammer for every sized project.

Small ISPs with only a few eBGP neighbors (i.e. less than a dozen) and
a few network prefixes (i.e. less than a 100) probablly should stick with
hardcoded, explicit prefix and as-path filters.  Coordinate the occasional
updates to the filters with your upstreams (since they should be
filtering your announcements on ingress anyway).  You are less likely to
mess things up, and its simplier to understand if another network
engineer needs to debug things later.  You also tickle fewer software
paths (and potential bugs) through the router code.

Large ISPS (more than 500 eBGP neighbors and 5000 prefixes) are going to
need some automated and dynamic mechanisms.  You should always ingress
filter announcements from downstream neighbors and customers with an
explicit, positive prefix and AS filter (a bogon filter is not
sufficient). ANS was the only major commercial provider I knew which
explicitly configured BGP announcement filters for every network prefix
from every source.  According to studies, about 70% of large ISPs
dynamically tag prefixes with community attributes to distinguish between
different types of prefixes (e.g. customer, peer, internal, etc).

Because community attributes are dynamic, and sometimes subtle, they
have been responsible for some huge network leaks.  Unfortunately, most
vendors' implemenation of eBGP results in the announcement all network
prefixes in the BGP table by default. Its up to you to prevent the
default behaivor.  If you use communities, I would suggest you configure
the default to block the network announcement.  That way if you
accidently misconfigure something else, somewhere else, sometime later,
and forget to set the correct community, the network announcement will get
dropped.

Large ISPs probably also want to use a few insanity filters.  Its not
generally practical to customize hardcoded filters across a large network.
So they tend to be limited to just the perpetually insane.

If you are a medium sized ISP, you are in the awkard stage.  Stick with
the simple stuff until you have a good reason to change to more
complicated methods.