Bridge management IP not working

Hello all,

New to Mikrotik I’m having trouble to set up management IP on my swith using bridge, switch CRS326-24G-2S+ RouterOS 6.48.6.
Bridge, acces port, trunk port, vlan are working fine but no way to have a management IP working on the bridge.
It is probably obvious, probably just in front of my nose but I’m stuck on it, help would be apreciated.

My goal: to be able to reach (manage) the switch with IP 192.168.77.250 on VLAN 77. Currently it does not work.
As a workaround I use port 24 which is not in the bridge to manage the switch with IP 192.168.69.250, and this is not what I want.

Here is the config:

# jan/16/1970 07:08:40 by RouterOS 6.48.6
# software id = 6NLR-3YB0
#
# model = CRS326-24G-2S+
# serial number = xxxxxxxxxx
/interface bridge
add admin-mac=xxxxxxxxxx auto-mac=no name=bridge1 vlan-filtering=yes
/interface ethernet
set [ find default-name=ether1 ] name=01_T_bond_forti
set [ find default-name=ether2 ] name=02_T_bond_forti
set [ find default-name=ether3 ] name=03_A_TCapsule
set [ find default-name=ether4 ] name=04_A_forti_69
set [ find default-name=ether5 ] name=05_A_69
set [ find default-name=ether6 ] name=06_T_forti_200
set [ find default-name=ether7 ] name=07_T_bond_S3
set [ find default-name=ether8 ] name=08_T_bond_S3
set [ find default-name=ether9 ] name=09_A_syno_77
set [ find default-name=ether11 ] name=11_A_syno_300
set [ find default-name=ether13 ] name=13_A_apc_77
set [ find default-name=ether24 ] name=24_A_MGT_69
/interface vlan
add interface=bridge1 name=INFRA_77 vlan-id=77
/interface bonding
add name=bond_S3 slaves=07_T_bond_S3,08_T_bond_S3 transmit-hash-policy=layer-2-and-3
add mode=802.3ad name=bond_forti slaves=01_T_bond_forti,02_T_bond_forti transmit-hash-policy=layer-2-and-3
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=bond_forti
add bridge=bridge1 interface=bond_S3
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=03_A_TCapsule pvid=69
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=04_A_forti_69 pvid=69
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=05_A_69 pvid=69
add bridge=bridge1 frame-types=admit-only-vlan-tagged interface=06_T_forti_200
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=09_A_syno_77 pvid=77
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=11_A_syno_300 pvid=300
add bridge=bridge1 frame-types=admit-only-untagged-and-priority-tagged interface=13_A_apc_77 pvid=77
add bridge=bridge1 interface=INFRA_77
/interface bridge vlan
add bridge=bridge1 tagged=bond_S3 untagged=03_A_TCapsule,04_A_forti_69,24_A_MGT_69 vlan-ids=69
add bridge=bridge1 tagged=bond_forti,bond_S3 vlan-ids=22
add bridge=bridge1 tagged=bond_forti,bond_S3,bridge1,01_T_bond_forti,INFRA_77 untagged=09_A_syno_77,13_A_apc_77 vlan-ids=77
add bridge=bridge1 tagged=bond_S3,06_T_forti_200 vlan-ids=200
/interface list member
add interface=02_T_bond_forti list=LAN
add interface=03_A_TCapsule list=LAN
add interface=04_A_forti_69 list=LAN
add interface=05_A_69 list=LAN
add interface=06_T_forti_200 list=LAN
add interface=07_T_bond_S3 list=LAN
add interface=08_T_bond_S3 list=LAN
add interface=09_A_syno_77 list=LAN
add interface=ether10 list=LAN
add interface=11_A_syno_300 list=LAN
add interface=ether12 list=LAN
add interface=13_A_apc_77 list=LAN
add interface=ether14 list=LAN
add interface=ether15 list=LAN
add interface=ether16 list=LAN
add interface=ether17 list=LAN
add interface=ether18 list=LAN
add interface=ether19 list=LAN
add interface=ether20 list=LAN
add interface=ether21 list=LAN
add interface=ether22 list=LAN
add interface=ether23 list=LAN
add interface=24_A_MGT_69 list=LAN
add interface=sfp-sfpplus1 list=LAN
add interface=sfp-sfpplus2 list=LAN
add interface=01_T_bond_forti list=LAN
add interface=INFRA_77 list=LAN
/ip address
add address=192.168.69.250/23 interface=24_A_MGT_69 network=192.168.68.0
add address=192.168.77.250 interface=INFRA_77 network=192.168.77.250
/ip dns
set servers=192.168.45.5
/ip route
add distance=1 gateway=INFRA_77
/system identity
set name=s0.srv.home
/system ntp client
set enabled=yes
/system routerboard settings
set boot-os=router-os enter-setup-on=delete-key
/system routerboard reset-button
set enabled=yes hold-time=0s..10s
/system swos
set address-acquisition-mode=static allow-from-ports=\
    p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20,p21,p22,p23,p24,p25,p26 identity=s0.srv.home \
    static-ip-address=192.168.77.250
/tool romon
set enabled=yes

Thanks for your help.

You need to add bridge1 to the tagged list for vlan 77 in the bridge vlan table.
Setting a subnet mask on the IP address for that would probably help too.

It’s there:

add bridge=bridge1 tagged=bond_forti,bond_S3,> bridge1> ,01_T_bond_forti,INFRA_77 untagged=09_A_syno_77,13_A_apc_77 vlan-ids=77

But this:

is the show stopper. Good work noticing it.
Shown network address verifies that address is assumed with /32 subnet mask which means that device with this setting can’t really talk to the rest of /24 subnet via management interface (it would use default route but it’s botched as well, interface set as gateway … this doesn’t work unless there’s a router in that subnet which is configured to proxy-arp just everything).

Thank you for your help.

I changed this line

add address=192.168.77.250 interface=INFRA_77 network=192.168.77.250

to this line

add address=192.168.77.250/24 interface=INFRA_77 network=192.168.77.250

It did not improve the situation.

But when I disabled interface 24 (temporary management interface) the switch started to ping from network 192.168.77.0/24 and adding a gateway made it reachable from other network as well which is what I want. Here are the changes:

/ip address
add address=192.168.69.250/23 disabled=yes interface=24_A_MGT_69 network=192.168.68.0
add address=192.168.77.250/24 interface=INFRA_77 network=192.168.77.0
/ip route
add distance=1 gateway=192.168.77.254

So, this is good, I do have management IP assigned to the bridge and the switch is reachable. However I’m not totally clear about the reasons it was not working…


And one more question: ping from the LAN to the switch 192.168.77.250 works perfectly:

— 192.168.77.250 ping statistics —
533 packets transmitted, 533 received, 0% packet loss, time 543187ms
rtt min/avg/max/mdev = 0.175/0.367/4.087/0.371 ms

But ping from the switch to the LAN (to be precise ping to the default gateway 192.168.77.254) show packet loss:

sent=20 received=14 packet-loss=30% min-rtt=0ms avg-rtt=0ms max-rtt=0ms

172 192.168.77.254 56 255 0ms
173 192.168.77.254 timeout
174 192.168.77.254 56 255 0ms
175 192.168.77.254 timeout
176 192.168.77.254 timeout
177 192.168.77.254 timeout
178 192.168.77.254 timeout
179 192.168.77.254 56 255 0ms
sent=40 received=32 packet-loss=20% min-rtt=0ms avg-rtt=0ms max-rtt=0ms

Again it seems weird for me, any idea about that ?
Thank you.

The difference is:

network=192.168.77.250

is different from (right):

network=192.168.77.0

Before you had automatically/implicitly a /32 network, limited to a single address 192.168.77.250.
Adding the /24 in address does not automatically change the network from 192.168.77.250 to 192.168.77.0.

If you delete the address and re-add it with:
/ip address
add address=192.168.77.250/24 interface=INFRA_77

the network value is set automatically to the correct ending 0.
But if you edit an existing address, changing its mask, network won’t likely be changed/updated, and will remain with the previous value.

Of course it didn’t because network address (albeit automatically calculated, you left it intact) was wrong. Playing with VLAN 77 interfaces did eventually fix this problem for you …


This may indicate a problem but it may mean nothing. If either party (more probably router) has CPU busy or some buffers full, it may decide not to process ICMP echo request packet or to drop ICMP echo reply packet. Some routers are selective when they need to drop packets and such “useless” packets may be the first selection.

I really wouldn’t worry about it too much as long as normal traffic (via switch and router) seems to flow fine, without any problems.

I really wouldn’t worry about it too much as long as normal traffic (via switch and router) seems to flow fine, without any problems.

I confirm: switch running correctly, traffic is normal even if there are ICMP echo request not successfull.