So we've recently upgraded all of our v3.x RB333 and RB433 backhaul gear to v4.5. No complaints so far, except that in some cases the devices appear to stop responding on their management IP addresses. They still pass traffic, but can no longer be pinged or managed on any of their Layer 3 addresses.
When we log in from the local network segment via MAC, we find that the (static, manually assigned) default route has failed. We have never had this trouble prior to the upgrade to v4.5, now we have it at random times across the network: most frequently either after a power cycle, or after the default gateway becomes reachable via a different interface. Gateway being visible from different interfaces is SOP on our mesh network.
Disabling and then re-enabling the device's management IP addresses seem to set the default route straight. However, it is a hassle to lose Layer 3 access to the device and have to plug into a switch that allows us Layer 2 access to fix it.
Our simple, static, default routes are configured, and have been since time immortal, in a fashion such as the following:
Code: Select all
/ip route add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=A.B.C.D scope=255 target-scope=10
For some more background, all of the physical interfaces the gateway could be visible via are combined into a bridge named "bridge1", and then we configure the management vlan (not vlan1) across the bridge, and we assign the management IP to the vlan, like so:
Code: Select all
/interface bridge name=bridge1
/interface bridge port add bridge=bridge1 interface=A add bridge=bridge1 interface=B
/interface vlan add interface=bridge1 name=vlanXYZ vlan-id=XYZ
/ip address add address=A.B.C.X/24 broadcast=A.B.C.255 interface=vlan130b network=A.B.C.0
If this were the case, I would appreciate a point in the right direction. I hope we've made our use case here straightforward enough, thank you Gentlemen.
