Hi MikroTik users,
This three-year-old thread: https://forum.mikrotik.com/viewtopic.php?t=121618
.. talked of problems where ARP entries would hang around for too long. There was also a lot in there about placeholder 00:00:00:00:00:00 incomplete/ no-answer ARPs, but I'm focused on the person or a few people who reported that a device's MAC address would change and the ARP entry would stick with the previous MAC address for minutes or longer.
I've lately begun having an issue that might be similar, though I'm still very much in the head-scratching phase:
I recently had to replace the fibre ONT-router (home/small office stuff from a major Spanish ISP) as the old device had begun to get flaky.
After replacing it, I re-jiggered the cables a bit for two reasons:
1. the new device had an unchangeable client isolation setting, which caused problems for some devices on the LAN to see other devices on the LAN if the two devices had to go through that ISP's p.o.s. device.
2. any time that device would reboot (which is under the control of the ISP) it would take down the LAN, if its built-in switch was in use.
So, the new layout has the ISP's fibre ONT-router at the edge of the LAN, where the main part of the LAN is a Mikrotik Routerboard 951Ui-2HnD and a dumb switch.
When I first did this, I noticed that I seemed to have partitioned the network, and after a bunch of farting around I realized that not all of the Routerboard's Ethernet ports were set to ARP at all. Now, all Ethernet ports are set to ARP=enabled.
The network now is not permanently partitioned. Heh...
But:
There are two WiFi Access Points on the network: one on the ISP's router, and the other at the far end of a Powerline Ethernet Controller extension. They have the same SSID.
When my mobile phone connects to one of the two WiFi APs and then roams to the other (basically, I walk from one end of the house to the other), the phone will cease to be able to perform DNS lookups (DNS is on the MikroTik) for "some time". (More than the 30 second ARP timeout, possibly minutes).
[i]This only happens in one direction - roaming from the WiFi AP at the far end of the PLC network to the WiFi AP on the ISP router.[/i]
Momentarily shutting off WiFi on the phone and turning it back on, or manually reconnecting to a WiFi AP will resolve the problem.
What I'll see, when the problem is occurring, in a packet capture on the MikroTik, is a pattern like this:
[quote] 0 time=2.623 num=1 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:31030 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=80 cpu=0 fp=no
ip-packet-size=66 ip-header-size=20 dscp=0 identification=9434 fragment-offset=0 ttl=64
1 time=2.678 num=2 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:31030 protocol=ip ip-protocol=udp size=175 cpu=0 fp=no
ip-packet-size=161 ip-header-size=20 dscp=0 identification=41433 fragment-offset=0 ttl=64
2 time=3.143 num=3 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:43639 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=80 cpu=0 fp=no
ip-packet-size=66 ip-header-size=20 dscp=0 identification=9456 fragment-offset=0 ttl=64
3 time=3.145 num=4 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:43639 protocol=ip ip-protocol=udp size=175 cpu=0 fp=no
ip-packet-size=161 ip-header-size=20 dscp=0 identification=41434 fragment-offset=0 ttl=64
4 time=3.53 num=5 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:52825 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=80 cpu=0 fp=no
ip-packet-size=66 ip-header-size=20 dscp=0 identification=9506 fragment-offset=0 ttl=64
5 time=3.531 num=6 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:52825 protocol=ip ip-protocol=udp size=175 cpu=0 fp=no
ip-packet-size=161 ip-header-size=20 dscp=0 identification=41435 fragment-offset=0 ttl=64
6 time=4.297 num=7 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:4612 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=80 cpu=0 fp=no
ip-packet-size=66 ip-header-size=20 dscp=0 identification=9590 fragment-offset=0 ttl=64
7 time=4.299 num=8 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:4612 protocol=ip ip-protocol=udp size=175 cpu=0 fp=no
ip-packet-size=161 ip-header-size=20 dscp=0 identification=41436 fragment-offset=0 ttl=64
8 time=4.635 num=9 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:52751 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=96 cpu=0 fp=no
ip-packet-size=82 ip-header-size=20 dscp=0 identification=9618 fragment-offset=0 ttl=64
9 time=4.635 num=10 direction=rx src-mac=5C:17:CF:79:A8:29 dst-mac=CC:2D:E0:13:1A:CF interface=bridge
src-address=192.168.254.31:42543 dst-address=192.168.254.3:53 (dns) protocol=ip ip-protocol=udp size=81 cpu=0 fp=no
ip-packet-size=67 ip-header-size=20 dscp=0 identification=9619 fragment-offset=0 ttl=64
10 time=4.636 num=11 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:52751 protocol=ip ip-protocol=udp size=96 cpu=0 fp=no
ip-packet-size=82 ip-header-size=20 dscp=0 identification=41437 fragment-offset=0 ttl=64
11 time=4.679 num=12 direction=tx src-mac=CC:2D:E0:13:1A:CF dst-mac=5C:17:CF:79:A8:29 interface=bridge
src-address=192.168.254.3:53 (dns) dst-address=192.168.254.31:42543 protocol=ip ip-protocol=udp size=229 cpu=0 fp=no
ip-packet-size=215 ip-header-size=20 dscp=0 identification=41438 fragment-offset=0 ttl=64 [/quote]
.. where the mobile phone does successfully get the DNS query to the MikroTik and the MikroTik immediately answers, but apparently the answer doesn't get to the mobile phone.
I realise, just now, as I wrote this, that it's possible that this still is an ARP table issue on the ISP router, being that one of the two WiFi APs is on that router itself.
That ISP router is an Askey RTF8115VW (hardware version "REV5-Mentech-MB374-45-N4-GK-BW-Y", software version "ES_g11.8_RTF_TEF001_V6.28_V008". There are no ARP settings on that ISP router, only the ability to display the current ARP table contents.
BTW the DHCP server is on the MikroTik, and there is a static assignment for my mobile phone, so it will get the same IP address no matter what AP it joins.
On the ISP router the ARP table shows only a correct association between my mobile phone's MAC address and its IP address, and the associated interface as the only interface that the ISP router has towards the rest of my LAN.
On the MikroTik it's the same (correct MAC <-> IP association), and shows the associated Interface as "bridge".
(Ok, so, doesn't seem like it's an ARP-on-ISP-router problem, or even necessarily an ARP problem?
And, the other bridge, which is cabled directly to an Ethernet port on the MikroTik, is dumb - no routing functionality, and no way to view its MAC-to-port association table).
Apologies if I'm being dense (probably I am)...
What could be causing this inability of my mobile phone to reach the MikroTik's DNS server in some interval after the phone has roamed from the WiFi AP at the far end of the PLC network to the WiFi AP on the ISP router?
many thanks,
-Jay