Hello!
I need to filter prefixes on both prefix and as-path. Is this possible? I tried:
add chain=pl-i-XXX action=accept prefix=X.X.120.0/21 prefix-length=21-24 bgp-as-path=“^XXX”
with no luck.
Regards,
Boris
The rule seems correct to me.
It should accept any prefix from /21 to /24 within X.X.120.0/21 that its BGP AS Path begins with XXX.
I presume there was another rule below that in your filter that drops everything?
Default action is to accept everything so you always have to place an action=discard rule at the end.
No, I found that as-path MUST not be quoted.
add chain=pl-i-XXX action=accept prefix=X.X.120.0/21 prefix-length=21-24 bgp-as-path=^XXX works as expected.
I just tested it and I don’t see any difference with or without quotes.
Quotes are useful when you want to have spaces for example and not parsed as another argument on the command. They don’t make any difference in your specific example.
First I run:
/routing filter add chain=lala action=accept prefix=1.1.1.0/21 prefix-length=21-24 bgp-as-path=^2331
/routing filter add chain=lala action=accept prefix=1.1.1.0/21 prefix-length=21-24 bgp-as-path="^2331"
And then export shows the exact same filter
/routing filter
add action=accept bgp-as-path=^2331 chain=lala prefix=1.1.0.0/21 prefix-length=21-24
add action=accept bgp-as-path=^2331 chain=lala prefix=1.1.0.0/21 prefix-length=21-24
Winbox also shows the exact same rule with or without quotes.
Let me guess - this filter is being used on an upstream/IX peer to permit a customer’s prefix, but only if the path actually goes directly to the customer… am I right?
Your method should work, but the most scalable solution is to implement some communities in your BGP.
Choose a community that means “learned from customer”, one that means “originated locally”, one that means “learned from peer”, and one that means “transit”
Make all border routers add the appropriate community to routes they learn from their peers - so a customer peering should apply the “customer” community to all learned routes, and an ISP peering should apply the “transit” community.
If your ASN is 112 for instance, you could use:
112:100 = transit
112:200 = peer
112:300 = local
112:400 = customer
Then on your output filters, you can simply allow the routes based on their community.
ZeroByte - You are absolutely righ! And yes, communities is the only right way to implement such tasks. But this device is migrated from old Cisco 7201 where the community policy was not yet implemented. So I tried to do 1:1 migration. Certanly I’ll implement communities ASAP. Unfortunatelly ROS does not have “delete-community-by-regex”, so my internal communities will go to internet 
Chaos - what ROS do You have? I’m at 6.36. And I tested again - with quotes does not work, without - no problem.
since communities consist of two # (ASN:XXXX) having your internal communities being sent to your upstream has no affect.
Additionally, if you want you can override them in our out-bound acl filter.(bgo out)