Hi
Wondering if somebody could throw some light on an issue we are having. We are delivering a VPLS circuit across 2 CCR1072 routers (in on one, then through a 20km fibre link and out on another).

MTU size is 9100 across the VPLS link and can ping to this packet size, however when our client plugs in a tester on each end of this link and runs a RFC2544 test - this is failing on small packet sizes.

To be more specific, there is a 0.1% frame loss rate on packet sizes of 128bytes - when this link is run at anything above 50% capacity, this frame loss occurs on 128 byte frames and gets progressively worse as more bandwidth is put through this 1G circuit.

We have tried changing the interface queues to no avail - we have even built an EOIP tunnel across the same path which yielded the same results [img][img][/img][/img].Perhaps someone has come across a similar issue in the past and could guide us to a satisfactory solution.

Hi Kazoo,

Have you tried the latest RouterOS 6.37rc ?

It has specific fixes for VPLS out-of-order packets.

No we have not tried 6.37RC
I can try this build tomorrow across these two routers - everything currently on 6.36.2

Hello,
You are getting 0.1% frame loss with 128byte packet size at 500+ mbps traffic or I got it wrong ?
And there are just those two ccr1072 and 20km fiber in between?
Are you using any type of QoS or queues?

Regards,
M.

IIRC, any sort of packet forwarding that requires some form of processing that cannot happen in fastpath (encapsulating, like EoIP, VPLS, GRE...) may not distribute load across all CPUs. Which is why on a CCR1036, an EoIP tunnel will only transport around 550 Mbps with 512-byte packets - only a single CPU core does all the encapsulating, and a single tilera core is just not very powerful. We always use x86/64 processor based hardware for any sort of tunneling because that is the only way we are getting any meaningful throughput.

Hi all
We will run our own test on Friday - upon looking at the stats when our customer was running his test, it seemed to be running fastpath.
I will keep this thread updated - hopefully this is not a hardware limitation

Please test both stable and release candidate versions. Hopefully, you will see similar improvements as we did in our tests.

Which RC did you use - RC32 is the most recent one on the site

This particular fix is available since 6.37rc27, thus 6.37rc32 also has this fix.

Did not get a chance to try 6.37 - but the detailed test results on 6.36.2, both over VPLS and EOIP were terrible
64 byte packets unable to get above 200Meg on a 1Gig link - 128bytes just over 300. with nothing near the gig happening until over 512 in size

This is a protocol performance issue as the tests were also conducted going in on one port and out on another (on the same router) and all results were perfect.

Check the CPU load of the device while testing - you'll probably see a single CPU core stuck at 100% load. If so, there's nothing you can do about this, any sort of tunneling just doesn't distribute across all CPUs... no idea if that will be addressed in RouterOS v7 (or if it's even possible/viable because of synchronization issues).

As it was mentioned before, install v6.37rc. There are performance upgrade especially for VPLS with small packets.