Picture of NOC

MikroTik Hardware Offloading Troubleshooting: Low Throughput, High CPU, and Missing H Flags

Byadmin
Share
Tweet
Share
Pin
0 Shares

MikroTik hardware offloading is designed to move eligible Layer 2 switching and, on supported platforms, Layer 3 routing work from the main CPU to a dedicated switch chip. When offloading is working, traffic between supported switch ports can move at wire speed without every packet being processed by RouterOS software. When it is not working as expected, the symptoms can include low throughput, high CPU usage, and missing H flags in the bridge port table.

The important troubleshooting detail is that hardware offloading is not one universal feature with one universal indicator. Bridge hardware offloading (L2HW) and Layer 3 hardware offloading (L3HW) are separate capabilities. Their support depends on the exact MikroTik model, switch chip, RouterOS version, topology, and enabled features. This guide shows how to identify the forwarding path, inspect offload status, and isolate common configuration causes without blindly changing production settings.

What MikroTik Hardware Offloading Does

A MikroTik router or switch may contain a dedicated Ethernet switch chip, also called a switch ASIC. Bridge hardware offloading allows that chip to handle supported Layer 2 forwarding tasks, such as switching frames between Ethernet ports. The CPU remains responsible for control-plane work and traffic that must be processed by RouterOS, but eligible switched traffic can stay inside the switch hardware.

Layer 3 hardware offloading extends the concept to supported IP routing functions. On compatible devices, the switch chip can route eligible traffic between directly connected networks or VLAN interfaces. This is distinct from ordinary bridge switching and is not supported by every device that has a switch chip.

Offloading does not mean that every packet bypasses the CPU. Traffic addressed to the router, traffic requiring unsupported features, and traffic that must pass through software firewall, queue, tunnel, or inspection functions may still be sent to the CPU. A device can therefore show active bridge offload while its CPU remains busy with unrelated routed or control-plane traffic.

Separate the forwarding paths

  • Layer 2 switching: frames are bridged between ports in the same Layer 2 domain. Check bridge port hardware offload.
  • Layer 3 routing: packets are routed between IP networks or VLAN interfaces. Check whether the platform supports L3HW and inspect its switch-chip monitor.
  • CPU/software forwarding: packets traverse RouterOS software because the feature, port, or configuration is not eligible for hardware processing.

Before troubleshooting, establish which of these paths is carrying the traffic. A missing bridge-port H flag does not, by itself, explain slow routed traffic, and a route H flag is not the same indicator as the bridge-port H flag.

Understanding the MikroTik H Flag

For Layer 2 bridge ports, run:

/interface/bridge/port/print

The output includes a flags legend. The H flag means hardware offload is active for that bridge port. A typical legend looks like this:

Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload

In the bridge-port table, inspect both the flag and the HW column. The HW column represents the configured hardware-offload preference, while the H flag reports active offloading. A port can have hw=yes configured without actually receiving the H flag if the hardware or configuration cannot offload it.

Use detail output to inspect the port’s configuration:

/interface/bridge/port/print detail

Do not confuse this with the H flag shown in the IP route table. Route flags and L3HW eligibility have their own meaning. MikroTik documents that a route H flag can indicate that the route is eligible to be selected for hardware offloading; it is not, on its own, proof that traffic is currently being routed in hardware. For L3HW, use the switch-chip L3HW monitor and confirm the hardware route counters.

Identify the Switch Chip and Its Capabilities

Hardware offloading is model- and chip-dependent. Two MikroTik products with a similar number of Ethernet ports may use different switch silicon and support different bridge features. Some devices have no switch chip capable of bridge hardware offload at all. Others support basic switching but not a particular VLAN, bonding, filtering, or routing feature in hardware.

Start with the device identity and switch information:

/system/resource/print
/system/routerboard/print
/interface/ethernet/switch/print
/interface/ethernet/switch/port/print

Not every platform exposes every menu or property. If a command is unavailable, do not assume that a similarly named command from another model applies. Check the current MikroTik switch-chip feature table for the exact chip family and RouterOS release.

Important platform differences include:

  • Some platforms support hardware-offloaded bridge VLAN filtering; others require a different VLAN switching method.
  • Some devices support only one hardware-offloaded bridge. CRS1xx/CRS2xx platforms have specific port-isolation capabilities and limits that differ from other families.
  • Features such as bridge horizon, certain bridge filters, unsupported VLAN tag formats, or unsupported bonding modes can prevent offloading on a given chip.
  • L3HW is available only on specifically supported devices and has its own hardware, route-scale, VLAN, and feature constraints.

Baseline Diagnostics: Find the Actual Bottleneck

Collect a baseline before changing configuration. Record the RouterOS version, model, switch-chip type, link speeds, bridge membership, VLAN table, and CPU usage while reproducing the problem.

/system/package/print
/system/resource/print
/system/health/print
/interface/print
/interface/ethernet/monitor [find] once
/interface/bridge/print detail
/interface/bridge/port/print
/interface/bridge/vlan/print

Some hardware does not expose all health sensors or monitor fields; omit unsupported commands rather than treating an empty result as proof of a fault.

Check CPU load while traffic is actually flowing:

/tool/profile

Profile output helps distinguish networking, bridging, firewall, management, and other CPU consumers. A high CPU reading by itself does not prove that bridge hardware offloading is broken. For example, a router can switch LAN-to-LAN traffic in hardware while CPU-heavy firewall, VPN, PPPoE, queues, wireless, or management tasks consume the processor.

Why the Bridge-Port H Flag May Be Missing

1. The port is not eligible for hardware offload

Check that the interface is a supported physical port connected to the relevant switch-chip domain. Software interfaces such as EoIP or VLAN interfaces are not physical switch ports, and setting hw=yes on them does not turn them into hardware switch ports.

2. Hardware offload is disabled on the bridge port

Inspect the HW column and the port detail. If the port should be offloaded and the chip supports the required configuration, the preference can be enabled on that port:

/interface/bridge/port/set [find where interface=ether2] hw=yes

Replace ether2 with the correct interface. This setting requests hardware offload; it does not override hardware limitations or unsupported feature combinations.

3. Multiple bridges compete for a single hardware bridge

Many MikroTik platforms support hardware offloading on only one bridge. If a configuration creates several bridges, one may be hardware-offloaded while the others forward through the CPU. This is a common cause of a missing H flag, low throughput, and high CPU load on the affected bridge.

Inspect all bridge and bridge-port assignments:

/interface/bridge/print
/interface/bridge/port/print

Where the design allows it, use one bridge and separate Layer 2 networks with VLAN filtering instead of creating multiple bridges. Do not merge bridges blindly: first map the VLANs, port membership, isolation requirements, spanning-tree settings, and management path. Some CRS1xx/CRS2xx devices have specific multi-bridge isolation support, so verify the exact platform before applying the one-bridge rule.

4. A feature disables offloading on this switch chip

Bridge horizon is a software split-horizon feature and disables hardware offloading. Other features may be supported on one switch-chip family but not another. Consult the current feature matrix rather than assuming that a feature’s presence in RouterOS means it is hardware-offloaded on every model.

Check for horizon settings:

/interface/bridge/port/print detail

Review the HORIZON field. If split horizon is not required, remove the setting only after confirming that the network does not rely on it to prevent unwanted Layer 2 forwarding or loops.

5. The ports belong to different switch chips

Some MikroTik devices contain more than one switch chip or have ports connected through different internal paths. Ports that look adjacent in the interface list may not share the same hardware switching domain. Traffic between those ports may need to traverse the CPU or an internal CPU-facing link.

Use the switch and port information for the exact model to identify which interfaces belong to which chip. A bridge that mixes ports across switch-chip domains can behave differently from a bridge made entirely of ports on one chip.

6. The port is inactive or not linked

A disabled or inactive interface cannot forward traffic as expected. Check the X and I flags, link state, negotiated speed, duplex, and physical errors before changing offload settings.

/interface/ethernet/monitor ether2 once
/interface/print stats

A 1 Gbps negotiated link, bad cable, optic mismatch, or CRC errors can look like an offload problem even when the H flag is present.

VLAN Filtering and Hardware Compatibility

Enabling vlan-filtering on a bridge is not guaranteed to preserve hardware offloading on every MikroTik model. Current RouterOS documentation lists hardware VLAN-filtering support for specific chip families, including Marvell Prestera and selected 88E, MT7621, MT7531, RTL8367, and EN7523 platforms. Other families, including CRS1xx/CRS2xx, use different VLAN switching methods and do not support the same bridge VLAN-filtering offload model.

Check the chip’s feature matrix before enabling VLAN filtering on an existing switch. An unsupported configuration can move traffic to the CPU or require a different configuration approach. For tagged trunks, access ports, PVIDs, and the bridge VLAN table, see our MikroTik bridge VLAN filtering guide.

For supported bridge VLAN filtering platforms, verify the bridge VLAN table and CPU-facing bridge membership. A basic inspection is: For a wider RouterOS diagnostic workflow when offload indicators and throughput do not agree, see our MikroTik CLI troubleshooting guide.

/interface/bridge/print detail
/interface/bridge/port/print
/interface/bridge/vlan/print

For inter-VLAN routing, the bridge interface itself must be included as a tagged member of each VLAN that needs to reach the CPU or be routed by the device. On RouterOS v7.16 and later, adding a VLAN interface to a vlan-filtering bridge can create a dynamic tagged bridge membership entry automatically. Review the actual VLAN table rather than assuming the entry exists.

Also pay attention to PVID, frame-types, tagged and untagged membership, and ingress filtering. A VLAN mismatch can cause packet loss or unexpected CPU traffic even if the bridge ports display H flags. On some chips, non-default VLAN EtherTypes or tag stacking are not supported with hardware offloading.

Layer 3 Hardware Offloading: A Separate Diagnostic Path

Bridge H flags show Layer 2 bridge-port offload. They do not prove that IP routing is offloaded. L3HW must be supported by the device and enabled on the switch chip and relevant ports. On supported platforms, inspect the switch settings:

/interface/ethernet/switch/print
/interface/ethernet/switch/port/print
/interface/ethernet/switch/l3hw-settings/print

Where supported, the global switch setting uses l3-hw-offloading=yes. Port-level L3HW settings are separate: disabling L3HW on the switch disables hardware routing globally, while disabling it on a particular port affects hardware routing to or from that port.

Check the L3HW monitor for actual hardware route counts:

/interface/ethernet/switch/l3hw-settings/monitor

Compare the total routes with the hardware and CPU route counters. If the hardware count is unexpectedly low, check route eligibility, supported route types, VLAN interface configuration, switch-port L3HW settings, and hardware table capacity.

For inter-VLAN routing, both the ingress and egress VLANs must be eligible for L3HW. On RouterOS 7.21 and later, per-VLAN L3HW can be controlled with the l3-hw-offloading property on VLAN interfaces. Check that the VLAN interface, bridge, and all participating switch ports are configured consistently.

One common configuration mistake is creating routable VLAN interfaces directly on Ethernet or bonding interfaces when the intended design requires them on the hardware-offloaded bridge. MikroTik documents that this can cause packets to be offloaded incorrectly and bypass CPU processing such as firewall or NAT. Follow the device-specific L3HW topology and VLAN examples in the official manual.

Remember that hardware routing and CPU firewall processing are different forwarding choices. On some L3HW designs, eligible routed traffic can bypass the CPU firewall; FastTrack hardware offload is a separate mechanism with its own constraints. Do not enable L3HW globally without understanding which traffic is expected to traverse firewall, NAT, queues, accounting, or policy-routing logic.

Troubleshooting High CPU and Low Throughput

Use the symptoms to narrow the likely cause:

  • Only one bridge is slow and its ports lack H: investigate multiple bridges, switch-chip membership, and unsupported bridge features.
  • All bridged traffic is slow: confirm the model supports bridge offload, check link negotiation and errors, and review whether the active bridge configuration is hardware-compatible.
  • LAN switching is fast but inter-VLAN routing is slow: investigate L3HW support, switch and port settings, VLAN interface placement, route eligibility, and L3HW monitor counters.
  • H flags are present but CPU is high: identify what traffic reaches the CPU. Router-destined packets, broadcast/multicast, firewall, VPN, PPPoE, queues, wireless, and management tasks may still consume CPU.
  • Throughput falls only when Torch or Sniffer is running: packet inspection can change the forwarding path or disable fast-path optimizations. Repeat the test without diagnostic capture tools.
  • Only one direction or one port is slow: inspect physical link speed, duplex, errors, optics, cabling, port configuration, and asymmetric traffic paths.

On a hardware-offloaded switch, unicast frames switched directly between ports may never reach the CPU. As a result, Torch or Sniffer may not display all switched traffic. A low capture rate is not proof that packets are missing. Use interface counters and an external test endpoint or TAP when you need to measure traffic that remains inside the switch chip.

A Repeatable Performance Test Method

  1. Define the traffic path. Test a pair of physical ports in the same VLAN first. Then test inter-VLAN routing separately. Do not mix internet/WAN speed tests with a local switching test.
  2. Confirm link capacity. Verify both endpoints and the MikroTik ports negotiate the expected speed and duplex. Check for errors, drops, and mismatched optics.
  3. Record offload status. Save the output of bridge port print and, if testing L3HW, the L3HW monitor.
  4. Measure CPU during the test. Run the same traffic test while watching /tool/profile and /system/resource/print. Compare idle and loaded readings.
  5. Use a suitable test tool. For local throughput, use two capable endpoints and a controlled traffic generator such as iperf3. Ensure the endpoints, NICs, cables, and test host are not the bottleneck.
  6. Test one direction and then both directions. Use consistent packet sizes and duration. Document TCP/UDP settings, number of streams, and whether the test is single-flow or multi-flow.
  7. Repeat without packet inspection. Stop Torch and Sniffer during the baseline test, then repeat separately if packet visibility is part of the investigation.
  8. Compare the same path after one change. Change one setting at a time and preserve the previous output so you can identify which change altered the forwarding path.

A single TCP speed test is not a definitive hardware-offload test. TCP performance depends on endpoint CPU, NIC drivers, window scaling, packet size, latency, and the number of streams. For switch testing, make sure the test hosts are connected to the ports and VLANs whose offload behaviour you are measuring.

A Safe Remediation Workflow

Use this sequence before making changes on a production MikroTik switch:

  1. Export and back up the current configuration. Confirm you have a management path that will survive the change.
  2. Identify the exact hardware model, switch chip, RouterOS version, and supported offload features.
  3. Determine whether the affected traffic is Layer 2 bridged, Layer 3 routed, or CPU-bound.
  4. Inspect bridge membership, port HW settings, H flags, multiple bridges, VLAN filtering, horizon, bonding, and chip-domain membership.
  5. For routed traffic, inspect L3HW global and per-port settings, VLAN placement, route counters, and the L3HW monitor.
  6. Make one targeted change, then re-check the H flag or L3HW counters and repeat the same throughput test.
  7. Keep the change only if it restores the intended forwarding path without breaking firewall, VLAN isolation, management, monitoring, or routing policy.

Do not set hw=yes on every interface as a generic fix, disable VLAN filtering, remove bridge filters, or turn off firewall features without understanding the impact. A configuration that maximizes raw throughput may also bypass inspection or break segmentation. The correct goal is to offload the traffic the hardware supports while preserving the security and control-plane functions the network requires.

Frequently Asked Questions

What does the H flag mean in MikroTik bridge ports?

In /interface bridge port print, H indicates that hardware offloading is active for that bridge port. The HW column shows the configured preference; hw=yes alone does not guarantee that the port is actually offloaded.

Why is the H flag missing even though hw=yes?

The port may not be connected to a supported switch-chip path, the device may support only one hardware bridge, another bridge may already be using the offload resource, or the configuration may use a feature that the chip cannot offload. Check the exact model’s feature matrix.

Can multiple MikroTik bridges use hardware offloading?

Many platforms support only one hardware-offloaded bridge. Some CRS1xx/CRS2xx devices have specific port-isolation support and different limits. Confirm the platform documentation before redesigning the bridge topology.

Does VLAN filtering disable hardware offloading?

It depends on the switch chip. Selected modern switch chips support hardware-offloaded bridge VLAN filtering, while other devices require a different VLAN switching configuration. Always check the model-specific compatibility table.

Does a bridge H flag prove inter-VLAN routing is hardware-offloaded?

No. The bridge-port H flag reports Layer 2 bridge offload. L3HW has separate requirements and should be verified with the L3HW monitor and its hardware route counters.

Why is CPU usage high when the H flag is present?

Some traffic still reaches the CPU, including traffic addressed to the router, unsupported forwarding features, and control-plane traffic. CPU-intensive firewall, VPN, PPPoE, queue, wireless, or management tasks can also cause high load independently of bridge offloading.

Why does Torch show less traffic than the interface counters?

Frames switched directly by the switch chip may not be sent to the CPU, so software capture tools may not see all hardware-switched unicast traffic. Use counters or an external capture point to validate the complete path.

Conclusion

MikroTik hardware-offload troubleshooting starts with identifying the forwarding path and the switch chip, not with blindly toggling settings. For Layer 2, check bridge-port H flags, bridge topology, port eligibility, and chip-specific feature support. For Layer 3, verify L3HW support and use the switch monitor to confirm hardware route counters. Then test with a controlled traffic path while monitoring CPU and link health. This approach helps isolate missing offload, high CPU, and low throughput while avoiding changes that compromise VLAN isolation, firewall policy, or network stability.

Check our list of MikroTik guides

Similar Posts