I would also like to know, I just found out the hard way that going from 6 to 7 has changed so I had to downgrade. I wasn’t getting any aggregates advertised at all. What are we missing?
I just watched a turorial on youtube and it seems that now we create a firewalll list with the networks we want to advertise, then under our BGP filter we set that address list under Output Network.
Is this correct? Also the video made it sound like this is a temporary work around for v7. Can anyone confirm if this will be the way going forward or will it eventually change again?
Ok, I pieced together enough information to figure out that with v7 you have to create an address list for your bgp routes and create a blackhole route for anything less than a /24 and the advertises get sent out properly. What’s the advantage to all this?
As there is no more route aggregation in v7, and also no more advertising of routes that you do not really have (bgp networks with synchronize=no), you need to:
add a “blackhole” route for the network you want to aggregate, e.g. 1.1.1.0/24 in the above (when you don’t have a 1.1.1.0/24 route yet)
add the 1.1.1.0/24 item to the address list you have specified as “output network” (this is named bgp-networks by default when you migrated from v6)
create an output routing filter that has something like: add chain=out disabled=no rule=“if (dst == 1.1.1.0/24 && dst-len in 25-32) { reject; }”
add chain=out disabled=no rule=“accept;”
and configure that for the bgp connection as well.
The filter will make sure that the smaller subnets within the aggregated /24 will not get advertised.
Of course it is still not the same as route aggregation, as the peer will not know about all this (with route aggregation they get a special “aggregator” attribute with the route).
That’s a pretty key feature of BGP unfortunately. Not quite sure how MT have got to a position of only selling hardware that supports 7, with a feature set that is lacking.
I don’t like it either. And even less I like the fact that BFD still is not available.
It seems that MikroTik have been pressed into implementing a multi-threaded BGP implementation, especially because they were selling routers with more and more cores (like the CCR1072 with 72 cores) that were very slow in BGP for multiple full internet tables. They split the work in multiple processes, but lost some important functionality because of that.
And worst of all, it took so long that those many-core routers are now mostly EOL and are being replaced by new models with fewer and faster cores. So maybe it was not absolutely necessary to have this, after all.
However, I don’t think it is going to change. We have to adjust our expectations and maybe find some workarounds. In my network, I will have to do some reconfiguration and maybe renumbering to cope with it.
In JunOS, we create a prefix list containing the aggregates, we then use the route aggregation feature to auto-generate discard routes the moment there’s a contributing route for an aggregate.
In ROSv7, we create a prefix list (address list) containing the aggregates, now simply statically route to blackhole for all aggregates on each edge router on the network, that’s it. In BGP peer config, set output network to the address list, if required you can fine tune using route filters. Some examples below.
if (dst in bgp-networks && dst-len<24) {accept} else {reject}
if (dst in bgp-networks && dst-len>29 && dst-len<32) {accept} else {reject}
There are problems with your config overall, you failed to properly add CPU input/output affinity, this will kill your router’s CPU when deploying large tables. in/out affinity mode should match CPU model of your router for all BGP peers including iBGP.
Here what I will do, I will share my config from production running on a CCR1072, where CPU has massive CPU cores regarding affinity. MikroTik ROSv7 has templates now to autoconfigure certain values when you create a fresh peer. And also some sample route filters will be shared.
We will assume I want to export only aggregates of /21 and /22 size for this example, because in real life you can have /21 aggregate, /22, /23 etc in a single aggregate list.
Thanks - this is currently a POC config - running on a CCR-2116 - Ill take note to review the affinity before deployment.
Thanks for sharing your configuration. The issue I still have is i only want the router to advertise the 100.64.0.0/21 route, when it has a route within that range within its own routing table.
For example, if an upstream router advertises 100.64.0.0/24 to the router, i’d want the router to advertise 10.64.0.0/21 to its peers, and not the /24. Using filters etc its easy enough to remove the /24 - but following the config example (in my case anyway) the aggregate route of 10.64.0.0/21 is always advertised.
I stumbled upon this today trying to set up routing between two MX204s and two CCR2216s. Correct me if I am wrong. It’s similar in the sense that both need to somewhat declare the aggregate, but in the case of junos ‘aggregate’ or ‘announce’ routes, they’d be (a) synchronized with any smaller subnet they would contain and (b) they would go away if no such subnet is in the routing table.
In the case of ROS v7 I couldn’t find a way to have the aggregate withdrawn if the router in question becomes isolated. Risk is the ‘blackhole’ route everyone suggests is kind of becoming an actual blackhole.
Indeed. But of course you can write a script, and run it at the interval you like, that checks if your smaller subnet is reachable in the route table, and when it is not it disables the blackhole route.
That will cause the aggregated route to no longer be advertised.
It was possible to do that without scripting in v6 but in v7 you need the script.