Having a little issue with a fibre service for a customer that is being terminated on on a Rb2011.
A little background, The service is 10mbps/10mbps delivered via fibre to the providers NTU then Ethernet to the Rb2011, we are having issue with the upstream traffic not being able to get the full 10mbps.
If we use old faithful speedtest.net the service gets 10mbps down and between 2 - 3.5mbps up.
The provider has said on a cisco device this is what is required to resolve the issue:
policy-map EAS-SHAPE-10MB
class class-default
shape average 9800000 40000
We’ve translated this as best as possible in Queues however the service still isn’t able to achieve the 10mbps from inside the network. We tested FTP directly from a file hosted on their mikrotik and it gets the full 10mbps straight off the bat!
Yes it does however this was the first thing we checked as the services are ordered as the Ntu interface set to 100 full duplex. We tested and with the interface set to auto it is worse.
This post is a fairly significant one in the big picture of network supply/provision within Australia. The largest carrier in the country has recently implemented their MEF certified offering and as a result the EVC performance metrics are extremely ‘strict’. They police the NTU and the ISP ingress aggregation port to ensure that ethernet service metrics are maintained. The result is if you exceed the interface parameters for the EVC the circuit will be clipped and TCP performance suffers greatly.
The service cmurrayis referring to is a 10Mbit/s Fibre access ethernet service that requires the following ‘Cisco’ shaping to adhere to the correct inbound rates etc.
policy-map SHAPE-10MB
class class-default
shape average 9800000 40000 0
This results in perfect performance of a service in both directions when using a Cisco on each end. Obviously there are customers who choose a Mikrotik CPE and as a result the MT shapers/burst parameters need to function within the MEF standards else the service will not perform at the bandwidth levels they have subscribed.
I have tried significant tinkering with simple queues, queue trees, bfifo interface queues to try and emulate the behavior however the Mikrotik configuration does NOT translate directly. The MT queue methods all ‘drop’ traffic, which clips TCP and causes transfer rate issues. Packets need to be delayed/queued in order for them to fit inside the burst time/size increments of the EVC.
Can someone either provide a Queue configuration for a Mikrotik that will function with exactly the same parameters as the Cisco shaping configuration above or someone from Mikrotik comment on whether this is even possible or not.
With the growing prevalence of MEF standards, performance metrics and definitions, this will become increasingly pressing as an issue for the MikroTik community and we would like to work out a way for our customer base to continue using the feature rich RouterOS platform at their edge if they so choose.
The wholesale provider did do this today and set the Ntu port to 10mbps full and we saw the upstream come up to a consistent 5mbps but still not the 10mbps
If a PC that is only connected to the routerboard at 10 Mbps and running speedtest isn’t able to show upload close to 10 Mbps then it seems unlikely that any form of queuing on the routerboard is going to help much. speedtest.net uses TCP so as packets are dropped a proportion of the available bandwidth is given over to retries - that is what needs to be minimized. It would be worth testing right at the provider’s demarc.
The reason I suggested checking at the demarc is that the Cisco shaping described shouldn’t be exceeded significantly by a 10 Mbps source - not significantly enough to kill half the bandwidth.
The Cisco<>Mikrotik interfaces I deal with generally run far faster than that but I can set up a test if the matter isn’t resolved quickly.
Do you happen to know what the round-trip time is the the site that speedtest.net was using? That might help rule some things in/out as regards TCP windowing.
I think the RTT is probably having a significant effect especially if there is any packet loss at all. Trying a UDP test would show what the link is doing without the effects of RTT and TCP windows.
The Cisco settings shown do not permit bursting above the CIR of 9.8 Mbps (less than 10 Mbps to account for overhead). You will see a similar effect on TCP tests with the Cisco settings on a Cisco router. At 3-4ms RTT I would expect to see the throughput at >9 Mbps but every 10s added to the RTT will be noticeable on the upload speed of a speedtest.net test. While 5 Mbps seems a touch low for 80 ms RTT (~7-8 Mbps would have been my guess) it depends on many factors and speedtest.net servers are anything but consistent.
Incidentally, the “shaping” implied by the Cisco config above will drop traffic once the queue buffers are full - as do comparable RouterOS queues. What this shaping can do is buffer a certain amount of traffic and then release it from the queue if the source drops below 9.8 Mbps. RouterOS queues can do the same. However if the source is constantly attempting to drive higher than 9.8 Mbps upload then both systems will be forced to drop traffic once the queue buffers are full.
).