> BGP is still atrocious on the CCRs, but that's because the route > update process isn't multithreaded. I recently took a close look at this, and that the update process is single-threaded is not the major problem so long as churn is not too great. The problem is that due to a deeper problem the entire forwarding table needs to be recalculated for *each* update. This means that even with the usual background noise in the DFZ the daemon is constantly updating everything. There are other bugs as well such as not supporting recursive next hop (e.g. via OSPF) lookup for IPv6 which means that if you have any iBGP sessions and more than one internal path you're out of luck with no obvious workaround. The stock answer from Mikrotik is that "everything will be fixed in the next major release of the OS". When that happens, and how long it takes to shake out the inevitable new bugs is an open question. Personally I give it at least a year before we would even try to use these seriously for BGP. Until then, it's FreeBSD and BIRD. Best, -w -- William Waites <wwaites@tardis.ed.ac.uk> | School of Informatics http://tardis.ed.ac.uk/~wwaites/ | University of Edinburgh https://hubs.net.uk/ | HUBS AS60241 The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.