CCR2004-1G-12S+2XS - Strange packet loss

RouterOS General
1

Is anyone observing something similar?

> /tool bandwidth-test [redacted] direction=both protocol=udp local-tx-speed=1000M remote-tx-speed=1000M
                status: running
              duration: 16s
            tx-current: 1000.9Mbps
  tx-10-second-average: 999.0Mbps
      tx-total-average: 998.9Mbps
            rx-current: 983.8Mbps
  rx-10-second-average: 982.6Mbps
      rx-total-average: 979.3Mbps
          lost-packets: 231
           random-data: no
             direction: both
               tx-size: 9000
               rx-size: 9000
      connection-count: 20
        local-cpu-load: 3%
       remote-cpu-load: 2%

Checked between 5 device pairs. Some exhibit this behavior, some don’t. Problem seems to be with receive path only - that’s what “lost-packets” shows anyway, and when starting bandwidth-test on other device from pair, there seem to be no lost packets. I doubt it’s anything external like SFP modules, cables or link quality, since this behavior appears between devices on every SFP port (didn’t test 1000Base-T port), even devices connected locally via 1 meter multimode patchcord. Anyone else noticed something like this?

2

Please see this: http://forum.mikrotik.com/t/bandwidth-test-lost-packets-during-receive-but-not-send/75168/1

Having some number of lost packets is normal for any UDP btest in the receive direction, so I wouldn’t assume that that indicates a fault in the device.

3

0 packets lost is normal. Previous state resulted in effective ~1% packet loss on each interface except ether1 for some reason, even though most of the ports weren’t a part of offending bridge.
Anyway, I managed to track this down.

For reference, here’s some “normal” for you; this btest is running over 5 hops, physical span is about 30kms of fiber. “0” didn’t even flinch for a second:

> /tool bandwidth-test [redacted] direction=both protocol=udp local-tx-speed=17.5G remote-tx-speed=17.5G
                status: running
              duration: 20s
            tx-current: 17.5Gbps
  tx-10-second-average: 17.5Gbps
      tx-total-average: 17.5Gbps
            rx-current: 17.5Gbps
  rx-10-second-average: 17.5Gbps
      rx-total-average: 17.5Gbps
          lost-packets: 0
           random-data: no
             direction: both
               tx-size: 9000
               rx-size: 9000
      connection-count: 20
        local-cpu-load: 61%
       remote-cpu-load: 59%

Cause for that previous ABSOLUTELY ABNORMAL behavior was usage of /interface bridge vlan method of bridging vlans. After switching to “legacy” /interface vlan + /interface bridge port method everything is functioning as expected, albeit with more cumbersome management given the amount of vlans that need to be bridged on this router. I won’t even waste my time reporting this bug, but I’ll leave this post here to potentially save some poor soul time wasted on debugging this, should they fall into this trap too :wink: