As of 6.44.3, the Traffic Generator feature does not measure Out-of-Order packets on the CCR1009. The exact some config on a RB800 detects OoO packets without any issue.
I assume that means that all the CCRs would have the same problem, since they use multi-core Tilera CPUs.
Here’s my problem: I need to be able to measure OoO packets for certain clients with extremely sensitive real-time traffic, and I’m familiar with Mikrotik so I’d prefer to use this system, but I don’t want to use the single-core ones since they can’t relaibly generate and calculate all the garbage that I need to send and recieve at the speeds that I need.
So has anyone tried the ARM multi-core CPUs? Are they able to detect and report OoO packets?
I’ll bump my own post with some content. I’m not sure how many people use the traffic-generator regularly but it’s a great feature. Unlike the Bandwidth Test it can be used with any other vendor.
Here’s a sample config that could be used to measure a layer 2 link:
Just put the MAC address of the next-hop device in the ‘mac-dst’ template field and fire away. Since the destination IP is the IP of the generator, the packets will bounce off the opposite router and back into the generator. That tests the layer 2 link in between, whether it’s a wireless link or a transparent layer 2 service from another carrier. The other side doesn’t need to run a bandwidth server, be a Mikrotik or even be managed by you.
The wiki now shows that there is a CLI-only command that forces multi-core Mikrotiks to use one core for the traffic-generator: ‘measure-out-of-order=yes’
So it turns out it was always there, but only for the CLI.