peer "sanity" filters - best practices?

Mailman List Mirror (Read Only)
1

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.

2

well... everyone has different ways of doing it. basicly we do the
following.

for the larger peers, ie cw, uunet, bbn, sprint, we filter them via
as-path

ie

for uunet, we would filter _1239_ _1_ and _3561_

we set this up after a large internet router company leaked full routes to
^1239_.

for all other peers we filter _701_ _1239_ _1_ and _3561_.

next, we max-prefix all peers. this stops route-leaks. yes, sometimes a
peer gets shutdown because they just got a large new customer but i would
put this at about 1 in 100. the other times are because of poor filtering.

we filter RFC1918, default and reserved blocks. anyone notice that there
are companies using ips from IANA-Reserved? of course we dont see them
anymore. we also filter out things like 64/8. this is due to mis-config on
the isp side. no one should be sending 64/8.

lastly, we filter at the /24 level.

this should be a good start for anyone looking to do filtering.

Christian

3

Hey Christian,

cnielsen@nielsen.net disait :

well... everyone has different ways of doing it. basicly we do the
following.

.....

this should be a good start for anyone looking to do filtering.

We do similar for France Telecom, but we also filter all IX point we are
connected to.
We saw many time some big private peers that announce IX Lan we are both
connected on.

What's about your practice regarding IX Lan filtering ?

We have same "sanity" filters either for BGP customer or peers.

V