What Do You Check First When a Network Starts Acting Unstable?

RouterOS General
1

When a network starts behaving strangely, the difficult part is often figuring out where to start.

A connection might become slower, devices may randomly disconnect, or latency can suddenly increase. At that point, there are usually several possible causes: configuration, routing, DNS, wireless interference, hardware, or simply an overloaded device.

I'm curious how other MikroTik users approach this kind of troubleshooting.

Do you normally start with RouterOS logs and interface statistics, or do you check CPU usage, traffic, connections, and latency first?

I also find it useful to separate the problem into smaller parts:

Is the issue between the client and router?

Is it happening inside the LAN?

Is the WAN connection responsible?

Or is the router itself reaching a performance limit?

For people managing larger or mixed-vendor networks, does your troubleshooting process change when MikroTik is working alongside equipment from other vendors?

What are the first two or three things you normally check before changing the configuration?

Interested to hear how others approach it.

2

Hi,

I would start with:

#0 Try to find a pattern what happens eg. no Internet -> does DNS work?, no Internet -> do PCs get PROPER IPs? Des it happen at the particular period -> to many devices? DHCP oversybscribing? Write it down and try to figure it out.
#1 Check cables
#2 Try to isolate the part of network that could imply problems (could be bad cable from one device to another) by disconnecting it for some time to let the rest settle. I know it could be a problem but if you have no idea, then it is the only way. Simplify the network and look when problems start happen.

#3 Got to #0

3

Depends on if an external or internal issue. If external, my "history" tells me that it's most likely the ISP being an ISP, so I start with the nearest device (router) to it, test, and work back towards the client, avoiding tests across wireless as much as possible to confirm that the backbone is good. Once that is known good, then look at the affected client and it's connectivity. If multiple systems are affected, look for commonalities.

If internal, then some internal tests between endpoint devices/clients, and work back from there.

Myself, I don't really look at logs until I identify where the problem actually occurs.

4
  1. Logs
  2. Resource & Process Monitor
  3. Change Control

In my experience in the IT profession whatever gets past these first three is a damn good problem to solve.

5

I wrote this up 6 years ago when I spent most of my time on the Ubiquiti forums. This isn't MikroTik specific, or even network specific. Troubleshooting is applied problem solving.

Troubleshooting Tips: Strategies and Tactics. Tools and some Examples

The link to the following from the above link farm no longer works. But it's on the internet archive so you can still view it with the following link. George Pólya wrote a book about a general problem solving strategy that applies to many things, it was written with solving math problems in mind, but it is a general guideline that applies to most problems - summary of G. Polya's, How to Solve It from webarchive.org

6