Hello,
we need to advertise +500 prefixes to 4 BGP providers.
That means that we need to create 2000 filters?
There is any option to create a address-list? then we will be able to reduce to only 4 filters.
Thanks!
Re: Filters for +500 prefixes
You can use a chain in common for all the upstreams, i.e. ACCEPT-OWN-PREFIXES and then in the 4 separate upstreams chains do a jump.
Re: Filters for +500 prefixes
Cisco, Juniper, Huawei, Alcatel, etc... all have the option to create a "prefix-list" for filters. I'm surprised Mikrotik doesn't offer this option...
Re: Filters for +500 prefixes
/routing filter ?Cisco, Juniper, Huawei, Alcatel, etc... all have the option to create a "prefix-list" for filters. I'm surprised Mikrotik doesn't offer this option...
what's your problem?
Re: Filters for +500 prefixes
No option for prefix-list filters/routing filter ?Cisco, Juniper, Huawei, Alcatel, etc... all have the option to create a "prefix-list" for filters. I'm surprised Mikrotik doesn't offer this option...
what's your problem?
Re: Filters for +500 prefixes
Similar feature is currently in development.
Re: Filters for +500 prefixes
Similar feature is currently in development.
Thanks, something like this is what I expect:
Code: Select all
/routing filter add action=accept chain=Upstream-OUT prefix-list=MyPrefix
/routing filter prefix-list
add prefix=1.1.1.0/24 list=MyPrefix
add prefix=2.2.2.0/24 list=MyPrefix
add prefix=3.3.3.0/24 list=MyPrefix
add prefix=4.4.4.0/24 list=MyPrefix-
-
StubArea51
Trainer
- Posts: 1739
- Joined:
- Location: stubarea51.net
- Contact:
Re: Filters for +500 prefixes
The option to do this is there, you just have to build more than one filter.
First build the prefixes common to multiple peers
Then build the filter for the peering which references the other filter
And finally apply it to the peer in the direction that you want
The routes will then be filtered and you can reuse the filter/prefixes on another peer
First build the prefixes common to multiple peers
Code: Select all
/routing filter
add action=accept chain=as-65000-prefixes prefix=203.0.113.0/29 prefix-length=29-32
add action=accept chain=as-65000-prefixes prefix=203.0.113.8/29 prefix-length=29-32
add action=accept chain=as-65000-prefixes prefix=203.0.113.16/29 prefix-length=29-32
add action=accept chain=as-65000-prefixes prefix=203.0.113.24/29 prefix-length=29-32
add action=accept chain=as-65000-prefixes prefix=203.0.113.32/29 prefix-length=29-32
Then build the filter for the peering which references the other filter
Code: Select all
/routing filter
add action=accept chain=peering-to-r2-out match-chain=as-65000-prefixes
add action=discard chain=peering-to-r2-out
And finally apply it to the peer in the direction that you want
Code: Select all
/routing bgp peer
add name=R2 out-filter=peering-to-r2-out remote-address=100.126.0.2 remote-as=65001
The routes will then be filtered and you can reuse the filter/prefixes on another peer
Code: Select all
[admin@R1] > routing bgp advertisements print
PEER PREFIX NEXTHOP AS-PATH ORIGIN LOCAL-PREF
R2 203.0.113.32/29 100.126.0.1 incomplete
R2 203.0.113.24/29 100.126.0.1 incomplete
R2 203.0.113.16/29 100.126.0.1 incomplete
R2 203.0.113.8/29 100.126.0.1 incomplete
R2 203.0.113.0/29 100.126.0.1 incomplete
[admin@R1] >
Re: Filters for +500 prefixes
Thanks a lot, I do it and is working very fine.The option to do this is there, you just have to build more than one filter.
But, perhaps if instead of adding prefixes as a new filter, they were added in a separate table, it would be more efficient at the CPU consumption level.
The same as the firewall, it is not the same to create 1 rule and 5000 address-list, than to create 5000 rules. In the second case the CPU consumption is much higher.
-
-
StubArea51
Trainer
- Posts: 1739
- Joined:
- Location: stubarea51.net
- Contact:
Re: Filters for +500 prefixes
It definitely would be nice to reference a prefix list directly and MikroTik has stated they are working on it.
However, from a CPU standpoint, Cisco and Juniper do the same thing mostly
Cisco has a route-map that references a prefix list for BGP peers - which requires two different constructs
Juniper has import/export which reference policy-options and that can reference a prefix list - also two different constructs.
If you want your BGP policies to be modular, you need more than one object for efficiency.
However, from a CPU standpoint, Cisco and Juniper do the same thing mostly
Cisco has a route-map that references a prefix list for BGP peers - which requires two different constructs
Juniper has import/export which reference policy-options and that can reference a prefix list - also two different constructs.
If you want your BGP policies to be modular, you need more than one object for efficiency.
Who is online
Users browsing this forum: Amazon [Bot], PLJ020 and 65 guests