[33850] in North American Network Operators' Group
peer "sanity" filters - best practices?
daemon@ATHENA.MIT.EDU (David P. Maynard)
Wed Jan 24 19:21:46 2001
Message-Id: <200101242206.QAA06486@bajo.flametree.com>
From: "David P. Maynard" <dpm@flametree.com>
To: nanog@merit.edu
Date: Wed, 24 Jan 2001 16:06:25 -0600
Errors-To: owner-nanog-outgoing@merit.edu
Several times over the past few years, the NANOG list has discussed the
topic of if or how non-transit peer BGP announcements should be filtered.
I searched through the archives, but couldn't find where anyone had
published a summary of best practices for filtering announcements from
peers that aren't one of the "top N" (for some debatable value of N)
NSPs.
What I am looking for is a set of filters that implement a sanity check
to catch some of the recurring BGP config problems. For example,
if SmallTime Internet suddenly starts announcing that they provide transit for
UUNET, I don't want there to be any chance that I will start sending my
UUNET-bound traffic to SmallTime.
Some of the "rules" I can think of would be:
- peers should not be announcing transit routes from the top N transit
providers (implemented via AS filter-list blocking the top transit ASNs)
- peers should not be announcing RFC1918 networks (implemented by prefix-list)
- peers should not be announcing the same networks that "I" originate
- peers should not be announcing a default route
- peers should not announce more than n-thousand routes (implemented
using the Cisco 'maximum-prefix' option)
These rules would theoretically be applied to any peers who weren't part of the "top N." In practice, I'm thinking of peers that announce 1 to a few thousand
prefixes.
Is the idea even feasible? If so, what other rules make sense? One other
option would be to limit announcements to /24 and shorter. Is there any
agreement on the "top N" ASNs that "normal" peers shouldn't be announcing?
Thanks.
-dpm
P.S. My interest is not just academic. These filters will get installed
on one of my customers' networks. They have had a fair number of problems
with peers announcing routes that they shouldn't and I am looking for ways
to help reduce the problem.
--
David P. Maynard, Flametree Corporation
Network Infrastructure and Monitoring Solutions
EMail: dpm@flametree.com, Tel: +1 512 670 4090, Fax: +1 512 670 4091
--
