As-path access-list default behaviour

[rmaugustus]

Hi

My intial understanding of as-path-access list is if its not created it defaults to permit all.  We were trying to filter a BGP neighbor prefixes by using the 'neighbor ip filter list 1234 in' and 'neighbor ip filter list 1234 out' on the neighbor. The router we were working on did not have a access-list 1234 or an as-path-access-list 1234 created. What will be the working here.

a) all neighbor routes are filtered and the filter list 1234 actually works based on the access-list . Access lists that are not created defaults to a deny all

b) all neighbor prefices are not filtered and we contiunue to receive routes. this will be because filter list will work based off the as-path-access-list and the default behaviour on this is to permit all

[Reza Sharifi]

Hi,

The default behavior is that you permit what you want and everything else is denied.

Have a look at this doc with examples:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094a92.shtml

HTH

[Richard Burts]

Actually the behavior of IOS has changed over time about how to treat assignment of an access list to filter traffic when the access list does not exist. To be quite clear I am talking about this kind of situation:

interface FastEth0/0

ip access-group 101 in

where access list 101 does not exist. While there was a time in the past where the behavior of IOS was to deny all traffic in this situation, the behavior has been consistent for quite a while that in this situation all traffic would be permitted.

I am not positive but I would assume that the same logic would apply with as path list, and if you assign an as path list to filter traffic for a neighbor but that list does not exist then I believe that all routes would be accepted.

HTH

Rick

[rmaugustus]

Thanks for the reply guys.

So we did get a chance to see the working on NX-OS . The box had a filter list 1234 in/out applied for a neighboring bgp device. The device neither had a access-list 1234 or an as-path-access-list 1234 created. The outcome was that the device filtered out all traffic.

One explanation that made sense so far is that the 'filter list policy' itself defaults to deny all when the attribute does not exit.

In my case it searched for an 'as-path access list 1234' and when it could not find the attribute it defaulted to deny all since that is filter policies default behaviour.. I am not sure if this is correct but this explanation make sense when we compare it to the actual working