I’m trying to implement an AS PATH filter for networks that have passed through an autonomous system (option 2). I’ve also already implemented a deny AS PATH filter for a different AS (option 3) and I’m stuck as to why I can’t get option 2 to work. My BGP table isn’t changing to the output I get from ‘show ip bgp regexp 65502’ which should be the expected result?
router bgp 65503
bgp router-id 4.4.4.4
bgp log-neighbor-changes
network 4.4.4.4 mask 255.255.255.255
redistribute ospf 1
neighbor 192.168.1.13 remote-as 65503
neighbor 192.168.1.13 next-hop-self
neighbor 192.168.1.17 remote-as 65502
neighbor 192.168.1.17 route-map AS_PATH_FILTER in
neighbor 192.168.1.17 filter-list 1 out
neighbor 192.168.1.33 remote-as 65501
neighbor 192.168.1.33 route-map AS_PATH_FILTER in
neighbor 192.168.1.33 filter-list 1 out
!
ip forward-protocol nd
!
ip as-path access-list 1 permit ^$ // to stop transit. applied with outbound filter-list
ip as-path access-list 2 deny _65504$
ip as-path access-list 2 permit 65502
In your configuration, you have created an access-list 1 with a permit ^$ statement. This statement matches everything. (See the BGP Regular Expressions Examples lesson.) This means that your access list will essentially do nothing, so nothing changes. In order to get “option 2” to work you must first determine which AS you want to include in the filtering, and then put in an expression with the “_” underscore character on either side. This will ensure that the AS you choose is somewhere in the path. For example, if you want to allow only networks that have passed through 65502 for example, your access list should be:
I managed to get the configuration working by removing the ^$ statement. However I’ve now lost my no transit policy into iBGP from my two ISP routers R1 & R2.
I tried using no export-community instead on R3 and R4 but when I added that to the existing route map at either position 5 or 15 it seemed to mess things up and I lost the AS Path filtering
You may want to consider other methods of employing a no transit policy. You can find out more about them here:
No Export is indeed one of them, but you can use distribute-list filtering as well as prefix-list filtering. It may take a little bit of time to troubleshoot and get all the details straightened out, but you can get it in the end.
If your topology is a production network, then it may be useful to implement your network in an emulator like GNS3 so that you can experiment without the fear of affecting the enterprise network.
If there is something more specific that we can help you with, please feel free to let us know!
Hi Laz,
Can you explain this reg exp ^3257_[0-9]*$ please explain it as much as you can so that I can understand, what is this reg exp indicating actually?
^ matches the beginning of a string
_ matches the space between AS numbers or the end of the AS PATH list
* repeats the previous character zero or many times
$ matches the end of a string
So the ^3257_[0-9]*$ string will match:
Any PATH list that starts with 3257 AND
is followed by a single AS
The ^ ensures that the PATH list will begin with 3257
The _ ensures that a space comes after 3257
This results in a match only if the AS PATH list begins with an AS of exactly 3257. All other PATH lists are not matched.
The [0-9] ensures that the next AS path will include any digit
the * indicates that any other number can follow the [0-9] digit any number of times.
This statement matches any AS, since the AS can consist of any number of digits (due to the *) ranging from 0-9.
The $ ensures that only a single AS can follow the 3257 AS since an end of the path list is expected after the second AS.
In other words, this string will match all AS PATH lists that begin with the 3257 AS, and are followed by a single AS of any value.
The following are AS Paths that would match this expression:
3257 1
3257 12
3257 123
3257 1234
3257 12345
The following would not
32578 123 because the first AS does not match 3257 exactly
53257 123 because the first AS does not match 3257 exactly
regexp 3257 also seems to match those prefixes which are originated by AS itself.
So it makes sense when we say any prefix that passes through 3257 but if we think in terms of regular expression then 3257 should not match the prefixes that are originated by 7474 itself.
I wonder how ^3257_[0-9]* works fine if we have a space before 3257 as indicated in the above statement.
Yes, this will work, but it will also match things like 33257 or 32577, simply because the digits 3257 are found within the AS number, which is not what we want. For this reason, we must use the ^3257$ which indicates that it should begin with and end with those exact values so that it matches exactly.
This will match any AS path that begins with 3257 and has at least one more AS that has a first digit between 0 and 9 (in other words, any AS).
For more information about the various regular expression special characters, take a look at the following lesson:
I would also suggest labbing this up so that you can test your various regular expressions practically so you can see the results.
I have a 10 private cloud locations where each cloud needs to interact with other cloud and customer is providing only 2 unique AS numbers-- one for leaf & other for PE router.
and then each cloud will interact with other using customer PE network.
i checked i need to use allow AS to allow same AS number in Dell switches.
The AS Path Filtering feature is used to accept or deny prefixes from certain autonomous systems. If you use AS Path Filtering in your particular topology, you could allow and/or deny any ASes you like. However, there may be an additional issue in your case.
An eBGP router, by default, will not accept any prefix that contains its own AS in the AS Path. This is a loop prevention mechanism that is used by eBGP which you can learn more about in this NetworkLessons Notes.
Now it’s not clear from your diagram what your topology is exactly. For example, in order to communicate between leaves at Cloud 1 (AS41540) and leaves at Cloud 2 (AS41540), do you traverse another AS? If that is the case, then you must use one of two other features:
BGP AS Override
BGP Allow-AS in
These can be further examined in the following lessons:
I tried going to the following site as indicated in the lesson. You must go to the servers towards the end to see the ones that are accessible via Telnet.
I too have found that not all of them work, but I have found that this one does:
which is a Cisco device. Indeed, many don’t work, but you have to try them out. Also, you can do a general search online for BGP looking glass servers, and you should be able to find many that are operational.
“_” This underscore character matches the space between AS numbers or the end of the AS-PATH list. Note this space does not exist at the beginning of an AS PATH list.
“$” The dollar sign matches the end of the string.
So the command in your post would match an AS PATH that ends with 56203. This is done with the use of the $ at the end. Also, using the _ ensures that the AS is not the only AS in the path but is preceded by at least one other AS, since there is a space before the number. This ensures that this particular AS is never matched if it is directly connected.
So this will match any prefixes that originated in AS 56203 (since the last AS in the path is always the originator of the particular prefix), only if that particular prefix is not directly connected.
You would essentially do nothing. What I mean is, such a command will filter nothing. This is because the access-list 1 contains the following full configuration:
ip as-path access-list 1 permit _56203$
ip as-path access-list 1 permit .*
route-map AS_PATH_FILTER permit 10
match as-path 1
router bgp 1
neighbor 213.200.64.93 remote-as 3257
neighbor 213.200.64.93 route-map AS_PATH_FILTER in
This would permit _56203$ and would also permit everything else due to the .* matching below. Therefore, the route map will not filter anything, thus it is as if it is not there.
I’ve been studying about BGP Filtering and I’ve just learned about the option to filter prefixes based off the autonomous systems found in the AS Path field.
However, I didn’t manage to find a real-world use of this AS Path Filtering so far. Could someone please give me some scenarios where filtering using this method would be more useful and appropriate than filtering using prefix lists/route maps?
I know the logic, how AS Path Filtering works and what it can do, I am just not sure where exactly would I want to configure it as a network administrator in the real world.
AS Path Filtering in BGP can be particularly useful in real-world scenarios where you need to control routes from specific autonomous systems, regardless of the actual prefixes involved. This can be important for optimizing network performance, controlling traffic flow and enhancing security. Some specific situations in which you would prefer AS Path Filtering over filtering specific prefexis using prefix lists and route maps are listed below:
When you want to selectively determine a transit provider. If you are an ISP and you have multiple upstream providers and you want to ensure that traffic from certain ASes is always routed through a specific upstream provider, (for cost or performance optimization) you can use AS path filtering to accept only routes from particular ASes.
Suppose there is an AS that is known to originate malicious traffic like DDoS attacks, it would be helpful to filter out any traffic coming from that AS.
Regional Traffic Management can be achieved more appropriately. Let’s say your organization has offices in multiple countries and you want to manage how traffic is routed to these offices. AS path filtering could be used to ensure that traffic to the European office, for example, is routed via an AS in Europe, rather than routing it across the globe.
So, while prefix lists and route maps give you control at the individual route level, AS path filters give you a higher level of control over the BGP decision-making process. Here “higher level” is referring to the level of abstraction in routing decisions. Where prefix filtering delivers more granular lower-level filtering, AS Path filtering delivers routing decisions based on the larger scale structure of the Internet.
