pjhtech Tools
MikroTik · RouterOS v7

MikroTik Ethernet Commands: Link, Errors and SFP Status

Quick answer #

Use /interface/ethernet/monitor for physical link information and /interface/print stats-detail for interface counters. Read the negotiated link and the counter changes together: an interface can report running while frames are being lost. This reference answers what to inspect before changing a speed setting or replacing an optic.

Scope: RouterOS v7 on RouterBOARD, CCR, CRS running RouterOS, or CHR where the relevant feature exists. Not SwOS. Output fields depend on release and hardware. Hardware Ethernet and SFP readings do not apply to CHR virtual NICs.

Commands #

Replace ether1 and sfp-sfpplus1 with names from the first command. These commands read state; they do not flap the port.

Commands
RouterOS v7 · RouterOS v7 terminal; absolute menu paths

Read-only
/interface/print
Read-only
/interface/ethernet/print detail
Read-only

Replace these example values: ether1.

/interface/ethernet/monitor ether1 once
Read-only

Replace these example values: sfp-sfpplus1.

/interface/ethernet/monitor sfp-sfpplus1 once
Read-only

Replace these example values: ether1.

/interface/print stats-detail where name="ether1"
Read-only

Replace these example values: ether1.

/interface/ethernet/print stats where name="ether1"
Read-only

Replace these example values: ether1.

/interface/monitor-traffic ether1 once

Read the result #

The Ethernet monitor reports the link state and rate, with additional negotiation and transceiver fields where supported. Compare the reported rate with the intended service speed. The configured maximum is not proof of the active link rate. SFP diagnostic values are meaningful only when the module supplies them; compare optical power against that module's specifications rather than a universal threshold.

Interface statistics distinguish cumulative counts from the current traffic rate. An old nonzero counter is a lead, not a diagnosis. Capture the counters, reproduce the problem, and capture them again. Record the time interval. New receive errors point investigation toward the receive path, while increasing transmit queue drops suggest a different line of enquiry from a disconnected cable.

A practical inspection sequence #

Start by confirming the exact port: match its name, comment, neighbour and cabling record. A renamed WAN port is easy to confuse with its default name. Then record the active rate at both ends. Collect two counter samples during an affected transfer, and compare the change with an unaffected port carrying similar traffic.

If an optic reports poor receive power, keep both ends' readings with the incident record. This gives the next engineer a useful baseline after cleaning connectors or replacing a patch lead. A one-off screenshot without the far-end reading is much less useful for an intermittent fault.

Pitfalls #

Do not run a cable test on a production uplink as a casual read-only check; availability and operating conditions depend on the Ethernet hardware. Do not paste an old forced-speed recipe into a newer router: RouterOS changed link-mode naming in v7.12. This reference intentionally collects evidence without changing negotiation.

A clean physical link does not establish that the bridge, VLAN, route or firewall is correct. Move to the next layer only after you can state what the physical evidence actually proves.

Sources

Documentation reviewed: 8 October 2026