You open WinBox, the device is in the Neighbors tab with its MAC address, and you get in by double-clicking it. On the IP address there is nothing: no ping, no WinBox, no SSH. It is often a switch or an access point, and often right after a change to the VLANs.
What it is not: this is not the same as a device that has vanished. MAC-WinBox working means the device is alive, the cable is fine, and the port you are plugged into shares a broadcast domain with it. MAC-WinBox talks on layer 2, without an IP address, routing or DNS. What does not work is everything that needs a correct IP address.
That makes this a comfortable problem: you have management and you do not have to walk anywhere with a cable. Do the checks below straight away, because the moment you change the wrong thing you lose MAC-WinBox as well.
Work with Safe Mode on, Ctrl+X in the terminal, over MAC-WinBox too. If the session dies, the device rolls your change back by itself. See Safe Mode.
The quick checks, in order
- Does the device have an address?
/ip address print. A good answer: an address on the bridge or on the management VLAN interface, in the network you are coming from. An empty list is your answer right there. - Was there a DHCP client that got nothing?
/ip dhcp-client print. A good answer:status: boundwith an address next to it.searchingmeans the request arrives nowhere. - Which interface holds the address?
/interface printand compare it with the previous step. A good answer: the address sits on the interface the management traffic really passes, so on the management VLAN interface when your management is tagged. - Does your port carry the right VLAN?
/interface bridge vlan print. A good answer: your port is untagged in the VLAN your address falls in, or tagged if your laptop tags. - Are the services on, and from which address?
/ip service print detail. A good answer: winbox and ssh are enabled, and theaddressfield contains the network your laptop is in. - Is layer 2 busy?
/interface print stats. A good answer: normal numbers. Counters climbing absurdly fast, with a full CPU, point at a loop.
The usual causes, most common first
A management address never arrived
A switch or access point behind another router has no WAN and therefore no obvious address. If DHCP was chosen and that request reaches no DHCP server, the device stays without an address. It keeps switching perfectly well, and you can only reach it by MAC.
The management VLAN does not get there
This is the classic one. The address sits on the management VLAN interface, but the cable towards it does not carry that VLAN, or the switch in between does not have it in its trunk. The device is then talking in a VLAN where nobody listens, while MAC-WinBox still works because that does not go over IP.
The DHCP client sits on the bridge while management is tagged
A device that should get its address by DHCP puts that request on the bridge, and therefore on the untagged traffic. If your management network arrives as a tagged VLAN, no answer ever comes. Give such a device a fixed address on the management VLAN interface.
Management is restricted to a network you are not in
The field with allowed management addresses becomes address= on every service. If that network does not match where your laptop sits, nothing answers on IP while the device is healthy.
There is a loop in the network
Two cables between the same devices, or a patch lead joining two wall sockets, sends broadcasts round and round. The bridge fills up, ARP stops working, and with it everything that needs IP. See Loop or broadcast storm.
What the configurator does about it
- In Management access, MAC WinBox defaults to "LAN interfaces only". The help text says why: MAC WinBox on LAN is the lifeline when you make an IP mistake, and you only switch it off if you have physical access. That is precisely why you are getting in right now.
- Next to Management allowed from the tool puts a warning under the field itself. With no management network set, it warns that the services are reachable from any address.
- Bridge & ports holds the offbridge port: one port deliberately kept out of the bridge and out of the VLAN table, with its own address and its own DHCP server. The script states where to plug in. Switch it on before you configure a device remotely.
- In a site with several devices the tool checks that every device carries the management VLAN. If a switch or access point does not, that is an error: the device cannot be managed. It also reports when a VLAN stops at a cable.
- The bridge gets RSTP by default. When an extra cable closes a loop, the tool says RSTP will block one of the paths: it works, but it does not add speed.
- Be clear about what does not happen: the tool never sets loop-protect on a port. Spanning tree protects against a loop between devices that both take part, but not against a cable pushed into a dumb switch or into two wall sockets. Set
loop-protect=onyourself after pasting, on the ports users plug into. - And what it cannot know: which network your laptop is in when you paste. That is why most lockouts get through.
Where the cause lies outside your router
- The switch in between. A managed switch that does not pass the management VLAN gives exactly this picture. Connect a cable directly to rule it out.
- A SwOS switch. It has its own management address and its own management VLAN, separate from RouterOS. See SwOS.
Read on: You cannot reach the router any more, Management access and A management network across devices.