Hex S set to bridge mode needs constant rebooting

khtf13 · August 4, 2022, 7:46pm

Have a few mikrotiks deployed but only having issues with ones set to bridge mode, any set up in a router mode with their own DHCP server work fine. The ones in bridge mode will suddenly stop working and will only start working again with a reboot of the hex S. Sometimes it happens a few times a day, for others its once a day, some only have the issue every few weeks but it’s consistently on mikrotik that’s are set to a bridge mode. The SFP which is on bridge 1 will show about 100-200kbps of traffic going through it while any of the ethernet ports also in the bridge less than 500bps going through them

Any advice? have upgrade to the newest OS and hasn’t seemed to made a difference

holvoetn · August 7, 2022, 7:10am

Always on devices with SFP ? Or others as well ?
Not working as in not responding to anything anymore or simply not doing their job anymore ?
Also not able to connect using winbox directly when attached to device (not WAN port) ?

Most likely a config issue.

Can you post export of config for one of those devices ?
/export hide-sensitive file=anynameyouwish
Review export for serial numbers, public keys, public IP, … and hide that info.
Then post file between [__code] quotes (easier to read posts)

It may also help for that device to add a small drawing how it sits in the surrounding network.
How does it go out to internet
Where is router ?
Where is DHCP ?
Different subnets ?
…
Drawing on paper is fine (as long as your writing is readable ), no need to use commercial tools.

chechito · August 7, 2022, 3:00pm

RSTP is enabled by default on any bridge

enable stp logging to discard an issue in that matter

/system logging
add topics=stp

khtf13 · August 8, 2022, 1:34pm

We only run devices with SFP so can’t say for sure if it’s isolated to that, not working as in you suddenly can’t get to the internet at all from any of the bridged ports, remote access to them still works fine while this is happening. These are deployed in a fairly large ISP environment and have had this issue with them in multiple different areas that run through different DHCP servers and routers. Posted a config export below. The firewall rules are in there as we set these up by standard in a NAT mode and then only later convert to bridge mode if needed where they then get disabled along with the nat rule

# jul/19/2022 03:39:21 by RouterOS 6.47.1
# software id = BL4G-A8A1
#
/interface bridge
add name=bridge1
add disabled=yes name=bridge2 protocol-mode=none
/interface ethernet
set [ find default-name=sfp1 ] auto-negotiation=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
add authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys name=WPA \
    supplicant-identity=""
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/ip pool
add name=dhcp_pool0 ranges=192.168.77.100-192.168.77.254
/ip dhcp-server
add address-pool=dhcp_pool0 interface=bridge2 lease-time=1d10m name=dhcp1
/snmp community
set [ find default=yes ] name=4public
/interface bridge port
add bridge=bridge1 interface=sfp1
add bridge=bridge1 interface=ether1
add bridge=bridge2 interface=ether2
add bridge=bridge2 interface=ether3
add bridge=bridge2 interface=ether4
add bridge=bridge2 interface=ether5
/interface bridge settings
set use-ip-firewall=yes
/ip address
add address=192.168.77.1/24 disabled=yes interface=bridge2 network=\
    192.168.77.0
add address=10.70.17.71/24 interface=bridge1 network=10.70.17.0
/ip dhcp-client
add interface=bridge1
/ip dhcp-server network
add address=192.168.77.0/24 dns-server=1.1.1.1,8.8.8.8 gateway=192.168.77.1
/ip firewall filter
add action=accept chain=input disabled=yes protocol=icmp
add action=accept chain=input connection-state=established disabled=yes
add action=accept chain=input connection-state=related disabled=yes
add action=jump chain=forward comment="Filter Window Port" disabled=yes \
    jump-target=Windows_Ports
add action=jump chain=forward comment="Connections and Limits" disabled=yes \
    jump-target=Connections
add action=jump chain=forward comment="Drop Bogon Address" disabled=yes \
    jump-target=Bogons
add action=jump chain=input disabled=yes jump-target="CPE Access Block"
add action=drop chain=Windows_Ports disabled=yes dst-port=135-139 protocol=\
    tcp
add action=drop chain=Windows_Ports disabled=yes dst-port=135-139 protocol=\
    udp
add action=drop chain=Windows_Ports disabled=yes dst-port=445 protocol=tcp
add action=drop chain=Windows_Ports disabled=yes dst-port=445 protocol=udp
add action=drop chain=Windows_Ports disabled=yes dst-port=1512 protocol=tcp
add action=drop chain=Windows_Ports disabled=yes dst-port=1512 protocol=udp
add action=drop chain=Windows_Ports disabled=yes dst-port=1900 protocol=udp
add action=drop chain="Windows _Ports" disabled=yes dst-port=3702 protocol=\
    udp
add action=drop chain=Windows_Ports disabled=yes dst-port=5357-5358 protocol=\
    tcp
add action=return chain=forward disabled=yes
add action=drop chain=Bogons comment="Drop Bogons from Eth1" disabled=yes \
    in-bridge-port=sfp1 src-address-list=Bogons
add action=return chain=Bogons disabled=yes
add action=accept chain=Connections connection-limit=100,32 disabled=yes \
    protocol=tcp
add action=drop chain=Connections connection-state=invalid disabled=yes
add action=accept chain=Connections connection-state=established disabled=yes
add action=accept chain=Connections connection-state=related disabled=yes
add action=return chain=forward disabled=yes
add action=accept chain="CPE Access Block" comment="Allow Winbox" disabled=\
    yes dst-port=8291 protocol=tcp
add action=accept chain="CPE Access Block" comment="Allow Winbox Scan" \
    disabled=yes protocol=udp src-port=!5678
add action=drop chain="CPE Access Block" comment=\
    "drops Eth1 ip's from CPE Access" disabled=yes dst-address=0.0.0.0/0 \
    in-bridge-port=ether1
add action=accept chain=input comment="Allow Winbox" disabled=yes dst-port=\
    8291 protocol=tcp
add action=accept chain=input comment="Allow Winbox Scan" disabled=yes \
    protocol=udp src-port=5678
/ip firewall nat
add action=masquerade chain=srcnat disabled=yes
/ip route
add distance=1 gateway=10.70.17.1
/ip service
set telnet address=10.0.0.0/8 port=2223
set ftp address=10.0.0.0/8 port=2221
set www port=2280
set ssh address=10.0.0.0/8 port=2222
/snmp
set contact="ex. inc" enabled=yes location=ex trap-generators=\
    interfaces trap-version=2
/system clock
set time-zone-name=America/Regina
/system identity
set name="ex"
/system logging
add topics=dhcp
/system ntp client
set enabled=yes primary-ntp=209.115.181.113 secondary-ntp=216.197.156.83

khtf13 · August 8, 2022, 7:22pm

I added the STP logging to a handful of devices we’ve been having this issue on, will update with what it shows next time this problem happens on one of them. Edited to add that there is no STP logs that occur when this happens

Whitehawk29FR · May 5, 2023, 8:58am

Hi all,

I have also this issue on a Hex S with sfp and bridge mode. Still same with v7.6 and v7.8.
I have also replaced the Hex with a newer one (r2 revision), but the issue still here.
The Hex still answer to ping/SNMP etc .. but no more forwarding from internal network, the client resolve it by rebooting the unit.

Does anyone have an idea what cause this ?
Regards

erlinden · May 5, 2023, 9:15am

Single bridge is the preferred way…

For any input, please share the config…

/export file=anynameyoulike

Don’t forget to remove serial and any other personal information.

Whitehawk29FR · May 5, 2023, 12:29pm

Hi,

My config is very basic, only one IP address, one queue, one default route .. :

may/05/2023 14:21:09 by RouterOS 7.8

software id = 0BHT-21V6

model = RB760iGS

/interface bridge
add name=bridge1
/interface ethernet
set [ find default-name=sfp1 ] auto-negotiation=no
/interface lte apn
set [ find default=yes ] ip-type=ipv4 use-network-apn=no
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/queue simple
add max-limit=100M/100M name=queue1 target=sfp1
/interface bridge port
add bridge=bridge1 ingress-filtering=no interface=sfp1
add bridge=bridge1 ingress-filtering=no interface=ether1
add bridge=bridge1 ingress-filtering=no interface=ether2
add bridge=bridge1 ingress-filtering=no interface=ether3
add bridge=bridge1 ingress-filtering=no interface=ether4
add bridge=bridge1 ingress-filtering=no interface=ether5
/interface bridge settings
set use-ip-firewall=yes
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/ip address
add address=10.X.X.X/16 interface=ether1 network=10.X.X.X
/ip dns
set servers=8.8.8.8,1.1.1.1
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=10.X.X.X
/system clock
set time-zone-name=Europe/Paris
/system ntp client
set enabled=yes
/system ntp client servers
add address=fr.pool.ntp.org
/tool romon
set enabled=yes

RcRaCk2k · July 26, 2025, 6:17pm

I found the issue and was able to solve it by disabling HW-Offload Settings. rOS is enabling HW-Offload randomly, not for known reason, and then traffic stops forwarding.

Seems like a firmware bug.
Bug also exists in 7.19.3