We are beginning to get more and more BGP peers in an Internet exchange. It would be really handy if I could have an address list and be able to reference that address list in a route filter. Is there a particular reason why this can’t be done?
Not quite sure what you mean…
we commonly build filters using the match chain to accomplish this..
e.g.
(This Chain is pretty much an address list)
/routing filter
chain=SDF-11280 prefix=68.142.0.0/19 prefix-length=19-24 invert-match=no action=accept set-bgp-prepend-path=“”
chain=SDF-11280 prefix=207.0.204.0/22 prefix-length=22-24 invert-match=no action=accept set-bgp-prepend-path=“”
chain=SDF-11280 prefix=206.61.0.0/23 prefix-length=23-24 invert-match=no action=accept set-bgp-prepend-path=“”
and
(This Chain is the filter)
/routing filter
chain=sdf-in match-chain=SDF-11280 invert-match=no action=accept set-bgp-prepend-path=“” append-bgp-communities=29846:115
chain=sdf-in invert-match=no action=discard set-bgp-prepend-path=“”
I don;t believe this capability exists - it would probably be a feature request
Because the filter list is built almost like an address list, I’m not sure there would be much benefit. You can edit the filter and BGP routes will be updated dynamically. Is there a specific problem you are trying to solve by using address lists instead of defining the prefixes in the filter?
Okay here is another way to approach it. I have an internet exchange where I have 30 peers. Each of those peers needs to receive around 60 advertisements EACH. They are all basically the same prefixes except their own. So I have 30 peers with 60 advertisements each. If I could reference one address list and then deny specific advertisements I would have a much smaller filter list.
See my point?
I see what is being said by the chains. It just seems clunky. Right now I have a chain that includes all the prefixes and I apply that to the peers. But then I have to have to copy that chain per peer to deny certain prefixes to just that peer.
So Right now I have a chain per peer because I have to deny certain prefixes to certain peers. So I have like 900 lines of filters. I have a line per prefix (60 some prefixes to advertise) and 30 peers. So Each peer has around 70 lines of prefixes. The key here is It would be quite handy to advertise everything to each peer referencing a list, then deny specific prefixes to them. So Instead of 60 lines of code I have one line that references the list, and below that specific denies. (actually above that) 
Or am I missing a way to do this?
Gotcha…match chain is really what you’re after. You can build one line of the filter and match another chain that is common to all peers and then add another line to match the peer specific prefixes.
So something like this:
/routing filter
add action=accept chain=Common-Prefixes prefix=1.1.1.0/24
add action=accept chain=Common-Prefixes prefix=2.2.2.0/24
add action=accept chain=Peer-1 match-chain=Common-Prefixes
add action=accept chain=Peer-1 prefix=5.5.5.0/30http://wiki.mikrotik.com/wiki/Manual:Routing/Routing_filters
I thought you could only apply one filter per peer? How do I apply the Common-prefixes and the peer specifics?
So the Peer-1 chain would be your BGP peer filter…it then uses another chain (Common Prefixes) to match on in addition to any other prefixes you list in the chain. That way you can update the Common-Prefixes chain once for all peers
It essentially is the same logic as an address list, but ends up using multiple chains to achieve the same thing.
I see the logic on the prefix lists, but how do they get referenced? I see you can only specify one chain per peer, and any chain I add in prefix lists does not show up as an option.
I am confused on how to reference more than the 1 chain and how to reference a prefix list chain.
Any link to any documentation on prefix chains that is half way up to date to illustrate what you are saying?
Ok let me see if I can clarify a bit…
Step 1. The filter and chain Common-Prefixes will never get applied to any BGP Peer directly - it exists to provide a common set of prefixes that all BGP Peers should match on to allow.
Example:
/routing filter
add action=accept chain=Common-Prefixes prefix=1.1.1.0/24
add action=accept chain=Common-Prefixes prefix=2.2.2.0/24
Step 2
Create another filter which WILL be applied to the Peer (Peer-1) that has a statement under “match-chain” that matches the common prefix list. After the line with ‘match-chain’, you can add as many additional lines to the Peer-1 filter as you need to handle unique prefixes.
/routing filter
add action=accept chain=Peer-1 match-chain=Common-Prefixes
add action=accept chain=Peer-1 prefix=5.5.5.0/30
add action=discard chain=Peer-1Step 3
Apply the Peer-1 filter to the BGP peer in whichever direction you need - I added it to the out filter for this example
/routing bgp peer
add name=Customer-1-peering out-filter=Peer-1 remote-address=15.15.15.2
remote-as=10 ttl=default
Thanks for the help. I will have to dig into this more because the chain I create in prefix lists is not an option under route filter “Match Chain”
Can you post the config? I tried it in 6.11 and the ‘Common-Prefixes’ chain is present in the match-chain drop down list.
EDIT: It looks like you need to copy the content of the prefix list into a route filter (which has prefix and prefix length range fields) then you will be able to reference it.
I am dealing with a similar situation, similar but slightly different…
I am using BGP communities to accomplish this goal…
e.g.
Inbound routes are marked with community 115 eg. 12345:115
Outbound Routes are marked with community 135 eg. 12345:135
as such I build by filters based on above communities… (FYI, one can also use regex with ASN to create filters too)
if you are worried about advertising someone’s own route back to them, you don’t have to worry about it, since bgp, inherently drops those routes… (technically if you are only worried about sending them their own route back, you don’t need to worry about filtering anything, and just can advertise everything to everyone…)
If you are trying to manage everyone’s peering with each other, then you might be better off running a route-reflector on a private as, and using that to manage routing with each other.
One of the benefits of Peering Exchanges, is that each member as can manage their own routing …