North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP Filtering

  • From: Mark Mentovai
  • Date: Sat Jan 13 11:08:26 2001

Three ways of filtering BGP, listed in my order of preference, with the most
preferrable first:

1. Prefix lists that specify permitted blocks and prefix lengths.

2. AS path lists that specify permitted AS paths (or AS path suffixes.)

3. AS path lists that specify excluded AS paths (what you're trying to do.)

The problem with specifying paths to exclude is that the neighbor still has
too much leeway to mess things up.  Let's say that your neighbor adds
another carrier.  Your filters won't kill those announcements, and you'll
potentially wind up with 95k routes coming across the wire that hopefully
will be filtered on your side.  This looks like it's what you were trying to
do:

|router bgp 65000
|  neighbor w.x.y.z remote-as n
|  neighbor w.x.y.z route-map XXX out
|ip as-path access-list 20 deny _6347_
|ip as-path access-list 20 deny _1_
|ip as-path access-list 20 permit .*
|route-map XXX permit 10
|  match as-path 20

In the case of BGP, it's probably better practice to say what is permitted
rather than what isn't, whenever feasible.  To that end, if you wanted to
stick with AS path filtering, you would only permit sane paths to advertise,
such as ^$ and ^65001$:

|ip as-path access-list 20 permit ^$
|ip as-path access-list 20 permit ^65001$

That still doesn't cover the case of the neighbor doing silly things like
redistributing 0/0, spewing /30s at you, or /24s along with unnecessary
child /25s.  (Here's a hint: avoid "redistribute static" and "redistribute
connected" wherever possible.)  That's why it helps to have good prefix
filtering at both ends.  You can combine this with AS path filtering, or you
may find that prefix filtering alone is all that you need, and additional AS
path filtering on top of it is overkill.

|router bgp 65000
|  neighbor w.x.y.z remote-as n
|  neighbor w.x.y.z prefix-list XXX out
|ip prefix-list XXX seq 5 permit a.b.c.d/p le 24
|ip prefix-list XXX seq 10 permit e.f.g.h/q le 24
|ip prefix-list XXX seq 15 permit i.j.k.l/r le 24

Mark

Jon Stanley wrote:
>I was assiting a customer the other day who was attempting to act as
>transit to us (we were filtering it thank goodness).  Now my question is
>why the AS_PATH list that I gave him did not work.  His AS is (let's
>say) 65000, and he has a transit AS 65001.  He is multi-homed with AS1 and
>AS6347.  Here is what I gave him:
>
>ip as-path access-list 20 deny ^.*(_6347).*$
>ip as-path access-list 20 deny ^.*(_1).*$
>ip as-path access-list 20 permit .*
>
>and I then applied it as a filter-list outbound on the neighbor.  This
>worked great at filtering out the routes that he was originating.  As for
>the routes that HIS transit customer was advertising, it didn't work at
>all - they weren't getting advertised.  I thought that the access-list may
>have been defective, so i changed the second line to ^.*(_1_).*$ but that
>didn't help either.  What I wound up doing as a bandaid was putting in
>
>ip as-path access-list 20 permit ^65001$
>
>between the second deny and the permit .*.  Now I may not understand Cisco
>regular expressions, but the first access-list the desired effect was to
>deny everything with AS1 or AS6347 in the as-path and permit everything
>else.  Why didn't this work as intended?
>
>AS numbers changed to protect the innocent :).