I just received my new CCR2004 and I couldn’t wait to put it in the grill
For the record, i also tested few other devices :
CCR1009 (7g-1c-1s+) v6.47b60
CCR1016 (12s-1s+) v6.47b60
RB4011 (igs-rm) v6.47b60
The CCR2004 runs its factory version 6.46.3 since there is no other package available to install.
Test protocol :
Four BIRD (v4 only) daemons with 800k+ routes upstreamed from a CCR1072 located into AS57199
Four BGP sessions to each router, no IGP, nothing more than BGP !
I just waited for the VMs to converge, and i configured the 4 bgp peers in the same time and I used “/ip route count print” to monitor the amount of routes.
Here are the results :
BGP Insertion (4xFullviews, ~3,2M routes) :
RB4011 : 3m45s
CCR2004 : 5m38s
CCR1016 : 10m09s
CCR1009 : 10m45s
Impressive results for the RB4011, less for the CCR2004, maybe this is because of the 32bit version of RouterOS on 64bit hardware ?
For the next test, i just deconfigured the 4 peers and waited for the route count to return to almost 0.
BGP Removal (4xFullviews, ~3,2M routes) :
CCR1016 : 3m18s
CCR1009 : 3m25s
RB4011 : 8m25s
CCR2004 : 19m58s
And i have to say that I am a little bit disappointed. Why is the 2004 so bad ? Are some hacks or improvements added to tile version missing ?
i hope that future versions of RouterOS 6 (i’d like to be able to use my router before 2021 ) will fix this
Thanks sir for the update. Mikrotik Datasheet numbers I always look at with a very wary eye.
There tends to be a lot of asterisks and gotchas associated with it.
If it’s possible could you do iperf UDP/TCP tests as well as posting CPU/Memory Resource utilization and latency when doing these tests ? I’d love to know how much CPU you’re using when doing 10+ Gbps routing as sitting at 99% is effectively useless to me.
The community would really appreciate it getting actual results from the equipment.
I simulated a big bgp flap (2 sessions reset + 1 added). It is better than a Tilera, but still miles above a decent router :
it took about 40 minutes to process all the routes to the CCR2004
it took about 1h23 to process all the routes to the CCR1016
It took about 2 minutes to process all the routes to a Cisco ASR9K (with rsp440-se)
To be clear : If you experience a big BGP flap, it is still better to reboot all your BGP Core rather than wait for a MikroTik to converge.
(PS : It could be a workaround to let the user flush the table and reset the sessions with a hidden command)
I’m waiting on my CCR2004 to get here. Then i’m going to benchmark it with our iperf3 and BGP full table performance lab that we’ve used for MUM Presentations in the past.
We maxed out the CCR1072 when it first came out with 80Gbps of traffic, so we should be able to make the CCR1004 fall over
What realistically can you do before you notice issues? I have issues with the 1072’s where they randomly reboot and the watchdog triggers. Maybe 1 time a week or less. No pattern to it and the supout shows nothing.
We have 3 1072’s in a live environment with no reboot issues, albeit with low traffic levels.
However we have run 1-2Gb during testing and they have been fine.
Have you tried with disabled connection tracking?
You will not have stateful firewall without connection tracking, but the performance is way better.
I had the same problems with CCR1036, especially during moderate DDoS attacks. By disabling connection tracking (or using the raw table for the forwarded traffic), the router now forwards 10gbit DDoS traffic without breaking a sweat.
One caveat: even without connection tracking, ROS becomes totally unresponsive during DDoS SYN Flood attacks (even at few Mbps/Kpps).
The only way I found to be able to handle SYN Flood attacks, was to disable Route Cache (which introduces other problems though…)
) will fix this 
