LET'S GO
The most common complaint is "nothing works for us", and most often this is not true. If the boss does not open an attachment in an email with the subject "you won a million", because it was blocked by an antivirus, then you will hardly have to configure the router on this day. Therefore, one of the most important skills for an admin is the ability to talk to the user and find out exactly what is not working and how. Unfortunately, I can't teach this in the article, so let's go straight to the technical part.
RESOURCES
The first thing that any system administrator pays attention to is resource consumption. Fortunately, WinBox displays this data directly in the main window. And if it doesn't display them yet, add them there right away. This will save a lot of time in the future. You need the Dashboard → Add menu. And by the way, the green square in the upper-right part is not the CPU load. Don't pay any attention to him.
Resources
If the processor is constantly loaded more than 80% (depending on the conditions, this value may change, but on average, let's take this number), then something is wrong. First of all, we look at the local "task manager", Tools → Profile menu. Here we will see what exactly loads the CPU, and understand how to proceed.
INFO
Long-term statistics on CPU load, interface traffic, and other parameters can be found in Tools → Graphing.
Profile
You can find an explanation of the fields in the wiki. The most common types are DNS, Encryption, and Firewall.
And now we look in the log. If our assumptions are correct, we will notice a lot of messages with the DNS prefix. We'll see from which addresses and interfaces requests are sent. Most likely, it will be a WAN interface. But we don't want to process DNS requests that came to us from the Internet. Close UDP port 53 on the WAN interface, place the rule in the right place — and enjoy the reduced load. Congratulations! We just discovered that we were part of a botnet, closed that hole, and made the Internet a little cleaner.
FIREWALL
In general, the ability to work with a firewall is very powerful. A well-constructed rule will indicate how the packet passes through the system, which interface it enters, which one it leaves next, and whether it receives a response packet. You can learn a lot about your network from the tags alone.
Counters
The Bytes and Packets columns show the number of bytes and packets processed by the rule. The Reset Counters buttons reset these counters. Now you can see whether traffic falls into the appropriate rule or not.
The firewall's Connections tab is often useful. Here you can see all the streams passing through the router: their state, the number of bytes that have passed, and the stream flags (just hover the cursor over the value in the column to get a hint). For more clarity, you need to add the Reply Dst fields. Address and Reply Src. Address. In these fields, you can see to which address and from which address the NAT was performed.
Connections
The firewall with all its features allows you to debug all traffic passing through the router in detail. To better understand what is happening in all these tabs, you need to study how packets pass through the router. The image shows a simplified version of the scheme. For more information, see the documentation.
Traffic Flow
OTHER WAYS TO ANALYZE TRAFFIC
It's good to see the status of the stream, its addresses, bytes, and so on. However, the firewall does not allow you to make sure that routing is correct conveniently and from a single location. To find out which interface the packet is sent to, just use the Torch tool.
Torch
Torch can be perceived as a kind of tcpdump. Here you can see the VLAN ID, source/destination address/port, DSCP, bit rate, and packet rate. There are convenient filters that allow you to make accurate selections. If the data in the window changes too quickly, increase the Entry Timeout value. Unfortunately, it can only show traffic on one interface in one window, but no one bothers to click New Window and watch multiple interfaces. If Torch doesn't show the right traffic on the right interface, there are problems with routing.
Torch allows you to monitor traffic flows in real time. But in some cases, you need more detailed traffic data. You can get them using the IP Sniffer tool.
IP Sniffer
You can use it to view traffic parameters and even the contents of the package.
But sometimes a more detailed analysis is required — for example, to make sure that the TCP handshake was successful and the data is transmitted. In this case, the ACK flag must be present in the transmitted packets. But it is inconvenient to search for packages in the meager interface of Winbox.
And then everyone's favorite Wireshark comes to the rescue — a powerful tool for analyzing network traffic. In Filter, specify the necessary parameters so as not to sniff everything in a row, in General, select Filename, click Apply and Start. Now you can find our dump in the Files on the router, transfer it to your computer and open it with a "Sharky". Many articles have been written about it, so I won't even try to write here how to work with it.
But this is just the beginning. You can monitor Wireshark traffic in real time. And without any operations with files! Open "Shark", write in the filterudp.port == 37008, on the RouterOS sniffer in the Streaming tab, check the box Streaming Enabledand enter the IP address of the computer running "Shark". You can check the Filter Stream box to send only selected traffic to Shark, not all of it.
Snif-stream
Shark
You can also send traffic to the sniffer from the firewall. The sniff TZSP action in the Mangle table is responsible for this. This works in the same way as Sniffer Streaming, but in the firewall you can make a more accurate selection of packets for the sniffer.
Mangle-sniff
WIRELESS
The most difficult part of diagnostics is Wi-Fi. It is a very complex technology in itself, besides the data transmission environment is common and all the neighboring routers interfere with your computer, just like it does with them. More than one book has been written about the operation of 802.11, and I will not retell them. Let's just look at the tools that can help with diagnostics.
There aren't many of them in RouterOS. The most important one is the Registration tab in Wireless. Here you can see all the information about connected clients: MAC, signal strength, signal quality.
Registration
Most important fields:
Log
PING, TRACEROUTE
The system administrator's first diagnostic tool has always been ping. But not everyone knows how many opportunities it hides in itself.
Many people have encountered the fact that the text is displayed on the site, but the image is not. Or the scripts didn't load and the site "went down". These are the first signs of MTU inconsistency. You can use ping to check this option. We check the box Dont Fragment, set the desired batch size, and look at the result. If we see packet too large— the MTU in the channel is lower than the specified packet value. Reduce it and check it again. Thus, we identify the maximum packet that passes through the network without fragmentation.
Ping
WWW
The Cisco website provides detailed information about the MTU and its measurement in the channel.
By default, the packet is sent from the router with Src. Address of the interface that it goes to. It happens that you need to change it. For example, when diagnosing routing within a VPN or whether the firewall is working correctly. To do this, fill in the Src field. Address. Don't forget that the address must be an existing one for the response packet to be returned.
For complex routing, select the appropriate Routing Table. However, those who use multiple routing tables already know this.
It is impossible to describe all possible problems and methods of their diagnosis and solution in one article or even in several books. For effective debugging, you need to understand how the network works at each level, its features in a specific implementation — after all, no two networks are the same: recipes that work in one infrastructure will be useless for the other.
To debug, you need to understand how the package runs inside RouterOS, and in particularly difficult cases, you need to know the vendor's features. And this applies not only to MikroTik. The best debugging tool — knowledge and experience!
Setting up a router well is an important task, but sometimes this is not enough and you have to solve problems already during operation. We will talk about what they are and how to deal with them, if you or your client has a MikroTik router, in this article.
The most common complaint is "nothing works for us", and most often this is not true. If the boss does not open an attachment in an email with the subject "you won a million", because it was blocked by an antivirus, then you will hardly have to configure the router on this day. Therefore, one of the most important skills for an admin is the ability to talk to the user and find out exactly what is not working and how. Unfortunately, I can't teach this in the article, so let's go straight to the technical part.
RESOURCES
The first thing that any system administrator pays attention to is resource consumption. Fortunately, WinBox displays this data directly in the main window. And if it doesn't display them yet, add them there right away. This will save a lot of time in the future. You need the Dashboard → Add menu. And by the way, the green square in the upper-right part is not the CPU load. Don't pay any attention to him.
Resources
If the processor is constantly loaded more than 80% (depending on the conditions, this value may change, but on average, let's take this number), then something is wrong. First of all, we look at the local "task manager", Tools → Profile menu. Here we will see what exactly loads the CPU, and understand how to proceed.
INFO
Long-term statistics on CPU load, interface traffic, and other parameters can be found in Tools → Graphing.
Profile
You can find an explanation of the fields in the wiki. The most common types are DNS, Encryption, and Firewall.
- Encryption — the router spends a lot of resources on encryption. Most likely, you have a lot of VPN tunnels and no hardware encryption chip. You need to change to a piece of hardware with a special chip or choose weaker algorithms.
- Firewall — a direct indication that you haven't read my previous articles ? The firewall is configured suboptimally.
- DNS-and here you will find something interesting.
Code:
/ip firewall filter
add action=accept chain=input dst-port=53 log=yes log-prefix=DNS protocol=udpAnd now we look in the log. If our assumptions are correct, we will notice a lot of messages with the DNS prefix. We'll see from which addresses and interfaces requests are sent. Most likely, it will be a WAN interface. But we don't want to process DNS requests that came to us from the Internet. Close UDP port 53 on the WAN interface, place the rule in the right place — and enjoy the reduced load. Congratulations! We just discovered that we were part of a botnet, closed that hole, and made the Internet a little cleaner.
FIREWALL
In general, the ability to work with a firewall is very powerful. A well-constructed rule will indicate how the packet passes through the system, which interface it enters, which one it leaves next, and whether it receives a response packet. You can learn a lot about your network from the tags alone.
Counters
The Bytes and Packets columns show the number of bytes and packets processed by the rule. The Reset Counters buttons reset these counters. Now you can see whether traffic falls into the appropriate rule or not.
The firewall's Connections tab is often useful. Here you can see all the streams passing through the router: their state, the number of bytes that have passed, and the stream flags (just hover the cursor over the value in the column to get a hint). For more clarity, you need to add the Reply Dst fields. Address and Reply Src. Address. In these fields, you can see to which address and from which address the NAT was performed.
Connections
The firewall with all its features allows you to debug all traffic passing through the router in detail. To better understand what is happening in all these tabs, you need to study how packets pass through the router. The image shows a simplified version of the scheme. For more information, see the documentation.
Traffic Flow
OTHER WAYS TO ANALYZE TRAFFIC
It's good to see the status of the stream, its addresses, bytes, and so on. However, the firewall does not allow you to make sure that routing is correct conveniently and from a single location. To find out which interface the packet is sent to, just use the Torch tool.
Torch
Torch can be perceived as a kind of tcpdump. Here you can see the VLAN ID, source/destination address/port, DSCP, bit rate, and packet rate. There are convenient filters that allow you to make accurate selections. If the data in the window changes too quickly, increase the Entry Timeout value. Unfortunately, it can only show traffic on one interface in one window, but no one bothers to click New Window and watch multiple interfaces. If Torch doesn't show the right traffic on the right interface, there are problems with routing.
Torch allows you to monitor traffic flows in real time. But in some cases, you need more detailed traffic data. You can get them using the IP Sniffer tool.
IP Sniffer
You can use it to view traffic parameters and even the contents of the package.
But sometimes a more detailed analysis is required — for example, to make sure that the TCP handshake was successful and the data is transmitted. In this case, the ACK flag must be present in the transmitted packets. But it is inconvenient to search for packages in the meager interface of Winbox.
And then everyone's favorite Wireshark comes to the rescue — a powerful tool for analyzing network traffic. In Filter, specify the necessary parameters so as not to sniff everything in a row, in General, select Filename, click Apply and Start. Now you can find our dump in the Files on the router, transfer it to your computer and open it with a "Sharky". Many articles have been written about it, so I won't even try to write here how to work with it.
But this is just the beginning. You can monitor Wireshark traffic in real time. And without any operations with files! Open "Shark", write in the filterudp.port == 37008, on the RouterOS sniffer in the Streaming tab, check the box Streaming Enabledand enter the IP address of the computer running "Shark". You can check the Filter Stream box to send only selected traffic to Shark, not all of it.
Snif-stream
Shark
You can also send traffic to the sniffer from the firewall. The sniff TZSP action in the Mangle table is responsible for this. This works in the same way as Sniffer Streaming, but in the firewall you can make a more accurate selection of packets for the sniffer.
Mangle-sniff
WIRELESS
The most difficult part of diagnostics is Wi-Fi. It is a very complex technology in itself, besides the data transmission environment is common and all the neighboring routers interfere with your computer, just like it does with them. More than one book has been written about the operation of 802.11, and I will not retell them. Let's just look at the tools that can help with diagnostics.
There aren't many of them in RouterOS. The most important one is the Registration tab in Wireless. Here you can see all the information about connected clients: MAC, signal strength, signal quality.
Registration
Most important fields:
- CCQ — Client Connection Quality. The closer to 100%, the better. Below 60% means poor connectivity;
- TX / RX Signal Strength — signal strength. Excellent value — from 0 to -45, acceptable-from -55 to -75. Everything in between is good. Below -75 can be considered a lack of communication. At least, I focus on such figures.
- Signal to Noise — signal-to-noise ratio. The higher the better.
Log
PING, TRACEROUTE
The system administrator's first diagnostic tool has always been ping. But not everyone knows how many opportunities it hides in itself.
Many people have encountered the fact that the text is displayed on the site, but the image is not. Or the scripts didn't load and the site "went down". These are the first signs of MTU inconsistency. You can use ping to check this option. We check the box Dont Fragment, set the desired batch size, and look at the result. If we see packet too large— the MTU in the channel is lower than the specified packet value. Reduce it and check it again. Thus, we identify the maximum packet that passes through the network without fragmentation.
Ping
WWW
The Cisco website provides detailed information about the MTU and its measurement in the channel.
By default, the packet is sent from the router with Src. Address of the interface that it goes to. It happens that you need to change it. For example, when diagnosing routing within a VPN or whether the firewall is working correctly. To do this, fill in the Src field. Address. Don't forget that the address must be an existing one for the response packet to be returned.
For complex routing, select the appropriate Routing Table. However, those who use multiple routing tables already know this.
It is impossible to describe all possible problems and methods of their diagnosis and solution in one article or even in several books. For effective debugging, you need to understand how the network works at each level, its features in a specific implementation — after all, no two networks are the same: recipes that work in one infrastructure will be useless for the other.
To debug, you need to understand how the package runs inside RouterOS, and in particularly difficult cases, you need to know the vendor's features. And this applies not only to MikroTik. The best debugging tool — knowledge and experience!
