A wired port does not reach its speed

You measure over a cable and you do not get past roughly 94 Mbit, while the port and the device at the far end are both gigabit. Or you have joined two SFP+ cages and the link comes up at 1G. Nothing drops out, the connection is stable, you are simply losing a factor of ten.

This chapter is about a link that negotiates below its own speed. If wireless is slow and a cable is fine, go to Wi-Fi is slow, the line is not. If it is only slow in the evening, that is your subscription rather than your port: see Everything is slow at peak hours. And if the router itself sits at a hundred percent, you will never fill the port: see The CPU stays high.

The quick checks, in order

1. What does the port actually negotiate? /interface ethernet monitor ether3 once. A good answer is status: link-ok, rate: 1Gbps, full-duplex: yes. If it says 100Mbps, this is not a measuring problem but a link problem, and there is nothing further to look for in RouterOS.
2. Look at the other end too. A link is negotiated by two parties. The switch, the laptop or the NAS at the far end reports the same speed, or a different one, and that difference is information in itself.
3. Are there errors on the line? /interface ethernet print stats where name=ether3. A good answer has rx-error and tx-error at zero and no rising rx-fcs-error. Counters that climb along with the traffic point at the cable.
4. Measure inside the LAN, not towards the internet. Put two machines on two ports and test between them. If that does give you gigabit, your uplink is the limit, not the port.
5. Is the switch chip still doing the work? /interface bridge port print. A good answer shows an H on the ports, which means the traffic is switched in hardware. Without H everything goes through the CPU.
6. Is the router the brake? /system resource print during the test, and if in doubt /tool profile duration=5. A lot of time in networking or firewall means the port is not your problem.

The usual causes, most common first

A broken pair in the cable

This is by far the most common one. Gigabit uses all four pairs, 100 Mbit uses two. One damaged pair, a badly crimped plug or a wire that is not fully punched down in a patch panel gives you exactly this picture: the link comes up, it is stable, and it runs at 100 Mbit. Swap the patch lead first. It takes a minute and it is usually the answer.

Something slow sits in between

A cheap PoE injector, an old switch in the meter cupboard, a splitter that pinches off two pairs. Everything on the path has to do gigabit, not only the two ends.

The port really cannot do it

Not every port on every model is gigabit, and on some models one port is slower than the rest. Check your model's chapter before you go hunting for cable faults.

A 10G link that stays at 1G

A 1G SFP module in an SFP+ cage simply gives you 1G, and a DAC cable or a module the far end does not accept can fall back. If there is no link at all, go to An SFP module has no link.

The traffic goes through the CPU

Without FastTrack and without hardware offload the CPU does all the routing. On a small device that is the difference between gigabit and a few hundred megabit. Queues (QoS) and PCC load balancing switch FastTrack off, because fasttracked traffic bypasses them.

What the configurator does about it

The important part first: the tool has no field for link speed or duplex anywhere. The script never writes speed= or auto-negotiation=, the ports negotiate for themselves. So the script cannot cause a 100 Mbit link, and there is no setting in the tool that will fix one either. If you want to pin a speed, you do that by hand in RouterOS.

What the tool does know comes from the device catalogue. On the network board every port carries its own speed, and a cable between two ports that differ reports: The speeds differ (1G and 10G): the cable runs at 1G. Draw the internet cloud with a subscription speed on it and the site check works out what is left of that subscription: The internet connection is 1G, but this port only does 100M: speed is lost here, followed by a suggestion for a better port, on this device or on another one. See Checks about speed.

Besides that, the Bridge and ports section has the Hardware offloading toggle, on by default, and Firewall has FastTrack, also on by default. Pick a model with an Atheros8327 or QCA8337 chip and switch VLANs on, and the tool warns that bridge VLAN filtering turns hardware offload off and sends VLAN traffic through the CPU.

Not checked: your cable, your patch panel, the far end, and whether the subscription and the port match as long as you do not use the board. In single-device mode there is no speed check at all.

When it is not your router

The media converter your ISP left behind, the switch at the other end, the network card in the PC and its power saving (Energy Efficient Ethernet drops some combinations back), and the cabling in the wall. That last one cannot be repaired with a setting.

Read on: Checks about speed, Bridge and ports and Cabling and PoE in practice.