Manual

Checks about speed

The messages about MTU, offload, queues and throughput, and what each one costs you.

These are the messages about a network that works but is slower than it should be, or that works until something sends a large packet. Almost none of them stop you from generating a script. They tell you what you are paying, so you can decide whether the price is right.

An error means it will not work. A warning is a decision. A note explains a consequence of something you picked.

A different MTU at the two ends of a cable

The cable gw-01 ether5 to sw-01 ether1 has a different MTU at each end (1500 and 9000). Packets larger than 1500 do not get through at gw-01 ether5 and are dropped without an error. Set the same MTU at both ends.

A warning, and the nastiest kind of fault to find later. Ping works, web pages load, and a file copy or a backup stalls. There is no error message anywhere. Make both ends equal.

A different MTU inside one network

Devices joined by cables use a different MTU on their bridge: 9000 on sw-01; 1500 on sw-02, ap-01. Within one network the MTU has to be the same everywhere, or large packets are dropped along the way.

A warning about the same problem one level up: the ports agree, the bridges do not. Jumbo frames only help when every device on the path carries them. Either raise the MTU everywhere, or leave it at 1500 everywhere.

The bridge MTU is above the port MTU

The bridge has MTU 9000, but the ports have 1500. Packets larger than 1500 are dropped at the ports. Set the L2 MTU on the ports at least as high, or lower the bridge MTU.

A warning about one device on its own. The bridge hands packets to its ports, so a bridge that accepts more than its ports do produces packets that die on the way out. Raise the port MTU, which the tool does for you when you fill it in.

No MSS clamping on a line below 1500

The MTU towards the internet is below 1500 (PPPoE or a lower WAN MTU), but TCP MSS clamping is off. Many servers and firewalls block the ICMP messages that would otherwise find the MTU, and then some websites hang while loading. Turn TCP MSS clamping on.

A warning, and the cause of the half loading web page that everyone with PPPoE has seen. Switch clamping on. It costs nothing and removes an evening of searching.

PPPoE with an MTU above 1492

PPPoE with MTU 1500: that is more than the usual 1492 and only works if your provider supports RFC 4638 (baby jumbo frames). Port ether1 gets MTU 1508 for it. If the provider does not support it, leave the MTU empty or set 1492.

A note about a deliberate choice. It gives you the full 1500 bytes over PPPoE, which several Dutch providers do support. If yours does not, the line comes up and large packets vanish, which looks exactly like the problem above.

WireGuard over PPPoE

WireGuard over PPPoE: the default MTU of 1420 fits over IPv4 (1480 of the 1492 bytes), but not when a peer connects over IPv6 (1500). If peers connect over IPv6, set mtu=1412 on the WireGuard interface and MTU = 1412 in the client configuration.

A note. The tunnel comes up either way, and over IPv6 the large packets inside it disappear. It is the reason a VPN works on one phone and not on another, on the same connection.

VXLAN needs a path of 1550

VXLAN branch carries 1500-byte frames with 50 bytes on top, so the path to 203.0.113.9 has to carry 1550 bytes. Over the internet that is usually 1500: large packets are then fragmented or, with the DF flag set, dropped. Give the path a larger MTU (jumbo frames on the ports, for example) or set the MTU of the devices behind the tunnel to 1450.

A warning. VXLAN puts a whole ethernet frame inside a packet, so the road underneath has to be wider than the road on top. Give the path jumbo frames, or set the devices behind the tunnel to 1450.

VLAN filtering costs the hardware offload

The switch chip on this model (Atheros8327/QCA8337 family) keeps its VLAN table in /interface ethernet switch. This configuration uses bridge VLAN filtering, which works but turns hardware offload off, so VLAN traffic is forwarded by the CPU instead of the switch chip. For full throughput on this board the switch-chip configuration is the right route.

A note on a specific family of chips, among them the hEX and several hAP models. The configuration is correct and your VLANs work. On a gigabit line you will notice the CPU. For full throughput on these boards the switch chip menu is the right route, which the tool does not generate.

QoS switches FastTrack off

QoS active: FastTrack is disabled in the firewall, which raises CPU load. On small routers (hAP/hEX) this costs throughput.

A warning, and an unavoidable one. FastTrack skips the firewall and the queues for known connections, which is exactly what makes it fast and exactly why a queue cannot see that traffic. You cannot have both. Decide whether the priorities matter more than the peak speed.

This router cannot shape this line

This router shapes in software; with FastTrack off it manages an estimated 200-300 Mbit/s. You entered 1000 Mbit/s, so the CPU will most likely be the bottleneck and the priorities stop holding. Consider "Fair share per host" with CAKE or fq_codel instead: one queue, no mangle rules, far less CPU.

A warning worth taking seriously. A queue tree that cannot keep up does not prioritise, it drops at random. On a fast line and a small router, one fair queue does more good than a tree of priorities.

What load balancing does not cover

Queue tree: the upload queue hangs on the first WAN interface; the second WAN is not shaped., PCC load balancing is generated for exactly two uplinks. and PCC: fasttrack is incompatible with mangle marks; it is switched off in the firewall while this method is active.

Warnings about the edges of these two features. With a second uplink, part of your traffic leaves unshaped, and with three uplinks PCC is not generated the way you might expect. Check which line your priorities actually apply to.

The port is slower than the subscription

The internet connection is 1 Gbit/s, but gw-01 ether5 only does 100 Mbit/s: speed is lost here. and Better: connect the internet to gw-01 ether1, which gets 1 Gbit/s.

A warning followed by concrete advice. The tool knows the speed of every port on every model, so it can see that the modem is in the wrong socket. Moving one cable is usually the whole fix, and the advice names the port.

A repeater halves the speed

A repeater at least halves throughput: the radio alternates between talking to the router and to the clients. A network cable to this device is always faster. and One radio does both the uplink and the broadcasting here; expect roughly a quarter of the throughput the router gives.

Notes, not mistakes. This is how repeating works, on every brand. With a second radio for the uplink you lose half, with one radio about three quarters. A cable or a pair of powerline adapters beats it every time.

IPTV is on but no uplink is selected.

An error. The IGMP proxy has to know on which interface the television stream comes in, and there is nothing to pick: no WAN is defined on this device, or the uplink field is empty. Nothing is generated for IPTV until it is filled in. Add the internet connection in the WAN section, or choose the uplink in the IPTV settings.

IPTV needs more than a route

Turn on IGMP snooping on the bridge, otherwise the TV stream is flooded to every port and swamps the network. and IPTV needs firewall rules to let multicast in from WAN; the Firewall section is off.

A note and a warning. Without snooping the switch sends every television stream to every port, including the Wi-Fi, which fills the air with traffic nobody asked for. Switch snooping on and leave the firewall section enabled.

A board with little memory

This device has 32 MB of memory. RouterOS v7 runs on it, but there is not much room: keep the configuration small, do not install packages you are not using, and check what is left with /system resource print after applying it. If it runs out, v6 is often calmer on a board like this.

A note on models with 64 MB of RAM or less, such as the hAP lite and the hEX PoE lite. It is a fact with a consequence, not advice to buy something else: the script works and the device runs.

What you have little of is room. A long firewall, a queue tree, a big DHCP lease table and a second package all take memory, and a board that runs out does not say so. It becomes slow, drops connections or reboots. Keep the configuration to what this device actually has to do, and read /system resource print after applying to see what is left.

Virtual machines bigger than their host

The VMs on esx-01 get 96 GB of memory together, the host has 64 GB., The VMs on esx-01 get 4000 GB of disk together, the host has 2000 GB. and The VMs on esx-01 have 40 vCPUs together on 8 cores: more than 4 to 1, which gets tight under load.

Two warnings and a note about the plan you drew on the board, not about RouterOS. Memory and disk cannot be oversubscribed the way processors can. Correct the plan here, where it costs nothing.

Related: MTU, QoS and Checks about cabling.

Want to try it right away? Open the configurator