ICMP_SEQ delays?

RouterOS Beginner Basics
1

Hi friends. Just picked up a Mikrotik RouterBOARD 750G r3 unit to act as my home router. After futzing through the many, many guides and different suggestions out there I finally got my filter rules set up thanks to some helpful IRC users. So far I’m definitely digging this thing. There’s a few curious things about it yet that I’d like to iron out. The current focal point is regarding what looked to be ping delays at first.

jason@JasT470:~$ ping 10.13.0.200
PING 10.13.0.200 (10.13.0.200) 56(84) bytes of data.
64 bytes from 10.13.0.200: icmp_seq=8 ttl=64 time=1.49 ms
64 bytes from 10.13.0.200: icmp_seq=9 ttl=64 time=1.61 ms
64 bytes from 10.13.0.200: icmp_seq=20 ttl=64 time=2.32 ms
64 bytes from 10.13.0.200: icmp_seq=94 ttl=64 time=4.00 ms
64 bytes from 10.13.0.200: icmp_seq=95 ttl=64 time=4.27 ms
64 bytes from 10.13.0.200: icmp_seq=96 ttl=64 time=2.52 ms
64 bytes from 10.13.0.200: icmp_seq=137 ttl=64 time=4.22 ms

At first when I was doing simple ping tests to make sure all was well, I kept thinking that I did something wrong because pings would fail to show up – but then all of the sudden they did. Looking at the ICMP_SEQ you can see a weird variation in which I receive a ping response that displays on my screen. In this case, it began to show on 8, but other times it didn’t show up until 50, 75, etc., so I sat there for quite a while until I was able to see something. This is a pretty stark contrast to my consumer grade router I just replaced where I could see the responses immediately and they would count sequentially. Everything is running fine and functional though so I’m not having an actual technical problem with this, but I found the behavior interesting and figured I’d ask.

My config is mostly stock with exception to some minor adjustments to my IP scheme and DHCP pool. Beyond that, I just have some NAT rules in place as follows:

/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface=ether1-WAN
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=10.13.0.0/24 src-address=10.13.0.0/24
add action=dst-nat chain=dstnat comment=HTTPS dst-address=!10.13.0.1 dst-address-type=local dst-port=443 protocol=tcp to-addresses=10.13.0.201
add action=dst-nat chain=dstnat comment=HTTP dst-address=!10.13.0.1 dst-address-type=local dst-port=80 protocol=tcp to-addresses=10.13.0.201
add action=dst-nat chain=dstnat comment="Quassel IRC" dst-address=!10.13.0.1 dst-address-type=local dst-port=4242 protocol=tcp to-addresses=10.13.0.201
add action=dst-nat chain=dstnat comment=OpenVPN dst-address=!10.13.0.1 dst-address-type=local dst-port=443 protocol=udp to-addresses=10.13.0.201
add action=dst-nat chain=dstnat comment=Bluecherry dst-address=!10.13.0.1 dst-address-type=local dst-port=7002 protocol=tcp to-addresses=10.13.0.200
add action=dst-nat chain=dstnat comment="Bluecherry UI" dst-address=!10.13.0.1 dst-port=7001 protocol=tcp to-addresses=10.13.0.200

For sake of context:
10.13.0.1 = mikrotik IP/gateway
10.13.0.200 = file server
10.13.0.201 = web server

Not sure if the rules matter in this case but figured I’d add them here in case they were relevant. Thanks for any insight!

EDIT - With some help from the IRC folks I might be on to something… I’ll update the post once I can confirm more. Thanks for looking. :smiley:

2

Well, so far we seem to be in good shape. I explained my setup to the folks in the IRC. As we got deeper into conversation, something I didn’t think would be the issue ended up being the issue. In fact it wasn’t until I looked into my network configs of my server that I remembered I set it up like this years ago.

Two switches. Let’s call them POE and Main. One server. Server is Ubuntu Server 16.04. Server has two NICs (call them 1 and 2). I bridged these two NICs together to have one IP. NIC1 plugged into Main Sw, NIC2 plugged into POE Sw. The Main Sw and POE Sw are not connected in any capacity besides them both going to the same physical server. Before I put the Mikrotik in place, I had no issues. Afterwards, I suddenly had issues. (or the more likely, I was having issues before and didn’t notice until the Mikrotik made them more apparent)

Long story short, the bridged NICs were the issue. I unbridged them and left NIC1 connected to Main Sw set on 10.13.0.200 /24. I adjusted NIC2 to be 10.13.1.200 /24. I changed all camera IPs to be in the 10.13.1.X /24 range. As it stands now, I have two networks subnetted off from each other, but the POE Sw (i.e. “Camera Network”) has no external access whatsoever. That being said, when I fire up my CCTV client it connects to the server just fine. In fact, speeds seem to be quite improved.

Alas, this was not a fault of Mikrotik at all, but given that I had already started this thread I wanted to close the loop in case anybody digs it up in their troubleshooting in the future. Big thanks to the folks in the IRC who provided their insight.