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 :).
Jon,
What's wrong with the following?
(Customers peering session config for you)
neighnor x.x.x.x remote-as 6347
neighbor x.x.x.x route-map CUSTOMER:ROUTES out
!
ip as-path access-list CUSTOMER:ROUTES permit ^$
ip as-path access-list CUSTOMER:ROUTES permit ^65501$
ip as-path access-list CUSTOMER:ROUTES permit ^65502$
ip as-path access-list CUSTOMER:ROUTES permit ^65503$
!
route-map CUSTOMER:ROUTES permit 10
match as-path CUSTOMER:ROUTES
!
It's easy, it's simple, it's concise. When you add a customer, you add a
line to as-path access-list CUSTOMER:ROUTES and you're set.
You can (and we do) of course prefix-list filter the customer on their
announcements to you, etc but, the as-path access-list filter is very
simple. (Announce US and our customers.)
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: