Stops Responding

RouterOS Beginner Basics
1

I’ve had my CRS310-8g+2s+ for about a year now and overall I like it. I’m using it primarily as a VLAN aware managed switch. I currently am not using any of its L3 functionality leaving all of that to my upstream OpnSense router.

I have one problem that I am hoping I can get help with. Whenever a machine (be it the router, or my server) that is connected to the switch via SFP+ reboots causing the link to go down while the machine reboots, the switch stops responding to winbox (via IP or Mac), browser (via IP) or ping until I power cycle the switch. It will keep passing traffic the whole time so it isn’t like it takes the network down, it just means that if I need to make a configuration change I need to restart the switch before I can do so.

I’ve been looking everywhere for an answer and haven’t found anything which leads me to believe it is a “me” issue and that I have something configured wrong and am hoping that I can get some guidance on how to investigate this issue and finally put it to rest.

Thank you,

~Travis

2

So, when you are in that state you have no access whatsoever to the router configuration/cli until you reboot?

You could try a script run periodically to either disable/wait some seconds/reenable the SFP or to change its negotiation mode, some ideas are in this thread:
http://forum.mikrotik.com/t/mikrotik-switch-sfp-port-issue-on-cold-restart/136741/1
but the symptoms here seem different, if I get it right something affecting the SFP causes Winbox connected to OTHER ports to stop responding?

3

Just to rule out everything, can you please share the config?

/export file=anythingyouwant

Remove serial and any other private info, post between code tags by using the </> button.

4

Also I recommend taking one of the unused ports on the switch and make it an OFF BRIDGE access port, but will wait to see the config.

5 
# 2025-04-23 13:42:51 by RouterOS 7.18.2
# software id = WIJH-BGNI
#
# model = CRS310-8G+2S+
# serial number = 
/interface bridge
add admin-mac=78:9A:18:48:17:01 auto-mac=no comment="Network Bridge" name=bridge port-cost-mode=short vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] comment="DS418 Play 1st Connection"
set [ find default-name=ether2 ] comment="Office Desk Switch"
set [ find default-name=ether3 ] disabled=yes
set [ find default-name=ether4 ] comment="LR TV Switch"
set [ find default-name=ether5 ] comment="POE Switch"
set [ find default-name=ether6 ] comment=USSLakota
set [ find default-name=ether7 ] comment="Unifi AP AC Lite"
set [ find default-name=ether8 ] comment="UDMSE VLAN Uplink"
set [ find default-name=sfp-sfpplus1 ] comment="Server DAC"
set [ find default-name=sfp-sfpplus2 ] comment="Uplink from Firewall"
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
/interface bridge port
add bridge=bridge comment=defconf interface=ether2 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether4 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether5 internal-path-cost=10 path-cost=10 pvid=99
add bridge=bridge comment=defconf interface=ether6 internal-path-cost=10 path-cost=10 pvid=10
add bridge=bridge comment=defconf interface=ether7 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether8 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=sfp-sfpplus1 internal-path-cost=10 path-cost=10 pvid=99
add bridge=bridge comment=defconf interface=sfp-sfpplus2 internal-path-cost=10 path-cost=10
add bridge=bridge comment=defconf interface=ether1 pvid=99
add bridge=bridge comment=defconf interface=ether3
/ip firewall connection tracking
set udp-timeout=10s
/interface bridge vlan
add bridge=bridge tagged=bridge untagged=ether2,ether4,sfp-sfpplus2,ether8,ether7,ether5 vlan-ids=1
add bridge=bridge tagged=ether2,ether4,ether5,sfp-sfpplus2,sfp-sfpplus1,ether8,ether7 untagged=ether6 vlan-ids=10
add bridge=bridge tagged=ether2,ether4,ether6,ether8,ether7,sfp-sfpplus2,ether5 vlan-ids=20
add bridge=bridge tagged=ether2,ether4,sfp-sfpplus2,sfp-sfpplus1,ether7,ether8,ether5 vlan-ids=50
add bridge=bridge tagged=ether2,ether4,ether6,sfp-sfpplus2,ether8,ether5,ether7 untagged=sfp-sfpplus1,bridge,ether1 vlan-ids=99
add bridge=bridge comment="IPv6Only Vlan" tagged=sfp-sfpplus2,ether2,sfp-sfpplus1 vlan-ids=365
/interface ovpn-server server
add mac-address=FE:01:7B:28:57:DF name=ovpn-server1
/ip address
add address=172.21.9.10/24 comment=defconf interface=bridge network=172.21.9.0
/ip dns
set servers=172.21.9.1
/ip hotspot profile
set [ find default=yes ] html-directory=hotspot
/ip ipsec profile
set [ find default=yes ] dpd-interval=2m dpd-maximum-failures=5
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=172.21.9.1 routing-table=main suppress-hw-offload=no
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/ip traffic-flow
set enabled=yes
/ipv6 dhcp-client
add interface=bridge pool-name=Bridge request=address,prefix
/system clock
set time-zone-name=America/Chicago
/system note
set show-at-login=no
/tool graphing interface
add
/tool graphing resource
add
6

You need to change this entry


/interface bridge vlan
add bridge=bridge tagged=bridge untagged=ether2,ether4,sfp-sfpplus2,ether8,ether7,ether5 vlan-ids=1

And move “bridge” to be member of the untagged list instead of the tagged list.

Also “bridge” should not be member of the untagged list of VLAN 99! It should be removed from this:


add bridge=bridge tagged=ether2,ether4,ether6,sfp-sfpplus2,ether8,ether5,ether7 untagged=sfp-sfpplus1,bridge,ether1 vlan-ids=99
7

Well that response was fast. I’m not familiar with using the terminal (just haven’t taken the time to learn it) so would you mind telling me how to do that? I can try to figure it out via the gui (and I’m pretty sure I’m looking at the right screen…but I would rather be safe than sorry.)

Thanks for your help.

8

/interface bridge vlan is mapped in WinBox to what you see in the Bridge → VLANs table.

Currently the “bridge” interface (which implicitly is VLAN 1) is the interface that has the management IP address that allows you to reach the switch with the IP address 172.21.9.10. When you use that “bridge” interface like that, then “bridge” must be in the untagged list of the VLAN with the ID 1 in the Bridge → VLANs table, not the tagged list. You open that entry with ID 1 in Bridge → VLANs, click the up triangle button to remove “bridge” from Tagged. Click the down triangle button next to one of the entries of Untagged to add a new entry, and set the value of the new entry to “bridge”.

As for VLAN 99. That VLAN currently has “bridge” in its untagged list, which is also wrong. In the Bridge → VLANs table, open the entry with VLAN ID 99 and click the up triangle button to remove “bridge” from the Untagged list.

9

Thank you very much. That is what I thought you were telling me to do but I wasn’t positive.

Changes made and saved…fingers and toes cross that this will solve the problem. I’m going to test it momentarily by rebooting my server (which is connected via SFP+)…normally that triggers the switch becoming inaccessible.

10

Just wanted to follow up, so far everything seems to be good.

For my own education, can someone help me understand how that misconfiguration caused the issue?

Thanks again,

~T

11

In your configuration, when you turn on “VLAN Filtering” on the bridge, most of the ports of the bridge (for example ether2 or ether4) are access port of the VLAN 1 (reason: they have PVID=1 and Frame-Types is admit-all which are the default value, you’ve also added those ports to the untagged list of the /interface bridge vlan entry for VLAN ID 1).

If you plug a device to ether2, then the untagged ethernet frames it receives will be from VLAN 1, and if the device sends untagged ethernet frames to that ether2 port of the switch, that frame will be associated with VLAN 1 by the switch chip. In short, you plug a device to ether2 then everything untagged that it sends and receives is part of VLAN 1. If you want to manage the switch from this device, then VLAN 1 must be one of the management networks of the switch. Which means the switch main CPU must have access to VLAN 1.

Normally if you want the main CPU to have management access or layer 3 access to a VLAN with ID X you have two choices:

A) Give the “bridge” port tagged access to the VLAN (by adding “bridge” to the tagged list of VLAN ID X in the /interface bridge vlan table) AND add a new VLAN interface entry under /interface vlan with “bridge” as parent interface and X as VLAN ID. You then define IP addresses etc. on this VLAN interface.

B) Give the “bridge” port untagged access to the VLAN (by adding “bridge” to the untagged list of VLAN ID X in the /interface bridge vlan table), but no new VLAN interface needs to be added under /interface vlan because the interface “bridge” itself, the one listed under /interface bridge, will be this implicit VLAN interface, with the condition that its PVID value is set to X and its Frame-Types is either admit-all or admit-only-untagged-and-priority-tagged. You then configure IP addresses etc. on the interface “bridge”.

Back to your original configuration: In your case VLAN ID X is VLAN ID 1, and you have chosen option B), because you’ve assigned the IP address and subnet 172.21.9.10/24 to the interface “bridge”. You haven’t changed the default parameters, so “bridge” has the compatible corresponding PVID=1 and Frame Types admit-all.

However, your config also had “bridge” in the tagged list of VLAN ID 1, which is not the correct setting, if you reread the B) section above, you’ll see that it should be in the “untagged” list. But the reason it “worked” after reboot is because RouterOS has a feature that scan the ports of a bridge, and if they have Frame Types admit-all or admit-only-untagged-and-priority-tagged then RouterOS will dynamically add an entry to the /interface bridge vlan table for VLAN ID matching the PVID value of the port, and put the port in the untagged list of that entry. Which means after reboot, a dynamic entry for VLAN ID 1 is added to the table and “bridge” is added to the “untagged” list of that entry. There exists also the wrong entry for VLAN ID 1 that you’ve added, where “bridge” is in the “tagged” list, but it looks like that after the switch has been rebooted, the dynamic entry temporary “wins”, the “bridge” is put into the untagged list of VLAN 1 and the interface “bridge” has access to VLAN 1.

Afterwards, when ports of the bridge go up or down, the /interface bridge vlan table content will be updated by the router, it might need to add/remove dynamic entries depending on the state of the ports, as well as updates the values of the Current Tagged and Current Untagged fields. It appears that during such updates the entry for VLAN ID 1 that you added “wins” over the dynamic entry for VLAN ID 1, and the “bridge” is classified into the tagged list of VLAN 1, the interface “bridge” no longer has access to VLAN 1, which means devices in VLAN 1 no longer reach 172.21.9.10.

At this point you’ve probably also seen why having “bridge” in the untagged list of VLAN ID 99 is wrong (because PVID of the interface “bridge” is not 99 but 1). And you also don’t need to put “bridge” in the tagged list of VLAN ID 99, because you didn’t define a new VLAN interface under /interface vlan with ID 99.

You only need to put “bridge” in the tagged list of the VLANs if you have intention to define corresponding VLAN interfaces for them under /interface vlan.

You only put “bridge” in the untagged list of at most one VLAN ID, if you want to have the interface “bridge” to be part of that VLAN, and the PVID of bridge must match the ID of that VLAN.