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.) --- John Fraizer EnterZone, Inc On Sat, 13 Jan 2001, 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 :).