Version:
Code: Select all
routerboard: yes
model: RB4011iGS+
serial-number:
firmware-type: al2
factory-firmware: 6.45.8
current-firmware: 6.47.2
upgrade-firmware: 7.1
This appears to be zerotier related.
routerboard: yes
model: RB4011iGS+
serial-number:
firmware-type: al2
factory-firmware: 6.45.8
current-firmware: 6.47.2
upgrade-firmware: 7.1
I realize my first post was not clear as I was still discovering the problem. So here is some more information:Might want to also upgrade the firmware. That isn't at 7.1 from your picture.
Not saying related, just noticed...
I did notice seem ZeroTier seems aggressive, but hadn't studied it. So not sure what "normal" would like for it .
ARP may one way it figures out it's paths, it's protocol is bit complex. Nothing should respond, right? It is Layer 2 tunnel, so could be seeing if there is a "shortcut" using ARP to find a host locally. But I can see how that might introduce whole lot of trouble...
routerboard: yes
model: RB4011iGS+
serial-number:
firmware-type: al2
factory-firmware: 6.45.8
current-firmware: 7.1
upgrade-firmware: 7.1
Thanks for the reply.Hi,
I haven't tested for this with ZeroTier, but I know that outside of ZeroTier this type of issue can happen with regular RouterOS 6.x if you use an interface as the "gateway" instead of an IP in the case where an interface must be used. For instance you could use ether1 as a gateway for a connected route only, otherwise if the route is static or something else, an IP must be specified instead of just "ether1" as ethernet interfaces can have many IPs. If you accidentally add a static route that uses "ether1" as the gateway you can end up with the interface trying to do ARPs for internet addresses, and then the ARP table can fill up.
See this thread: viewtopic.php?t=92767
[[REDACT]@router1] > /ip/route/print brief
Flags: D - DYNAMIC; I, A - ACTIVE; c, o, d, v, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
D o 0.0.0.0/0 10.172.2.1%zerotier1 110
DAd 0.0.0.0/0 XXX.XXX.228.1 1 (Public IP)
DAc 10.172.2.0/24 zerotier1 0
DAo 10.172.10.0/24 10.172.2.1%zerotier1 110
DAc 10.172.255.1/32 loopback0 0
DAo 10.172.255.2/32 10.172.2.1%zerotier1 110
DAc 69.248.228.0/23 eth1 0
DIvH 192.168.2.0/24 172.17.2.5 1
DAc 192.168.2.0/24 bri1 0
[[REDACT]@router1] /tool/sniffer> packet/print detail
0 time=33.477 num=1 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
1 time=33.529 num=2 direction=tx src-mac=C4:AD:34:F8:D6:DF
dst-mac=00:01:5C:92:AA:46 interface=eth1 protocol=arp size=42 cpu=3
2 time=33.537 num=3 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=C4:AD:34:F8:D6:DF interface=eth1 protocol=arp size=60 cpu=0
3 time=46.004 num=4 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
4 time=66.935 num=5 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
5 time=75.769 num=6 direction=tx src-mac=C4:AD:34:F8:D6:DF
dst-mac=00:01:5C:92:AA:46 interface=eth1 protocol=arp size=42 cpu=1
6 time=75.78 num=7 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=C4:AD:34:F8:D6:DF interface=eth1 protocol=arp size=60 cpu=0
7 time=96.511 num=8 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
8 time=118.019 num=9 direction=tx src-mac=C4:AD:34:F8:D6:DF
dst-mac=00:01:5C:92:AA:46 interface=eth1 protocol=arp size=42 cpu=2
9 time=118.029 num=10 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=C4:AD:34:F8:D6:DF interface=eth1 protocol=arp size=60 cpu=0
10 time=132.868 num=11 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
11 time=147.604 num=12 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
12 time=160.249 num=13 direction=tx src-mac=C4:AD:34:F8:D6:DF
dst-mac=00:01:5C:92:AA:46 interface=eth1 protocol=arp size=42 cpu=3
13 time=160.256 num=14 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=C4:AD:34:F8:D6:DF interface=eth1 protocol=arp size=60 cpu=0
14 time=184.963 num=15 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
15 time=202.489 num=16 direction=tx src-mac=C4:AD:34:F8:D6:DF
dst-mac=00:01:5C:92:AA:46 interface=eth1 protocol=arp size=42 cpu=0
16 time=202.496 num=17 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=C4:AD:34:F8:D6:DF interface=eth1 protocol=arp size=60 cpu=0
17 time=202.699 num=18 direction=rx src-mac=00:01:5C:92:AA:46
dst-mac=FF:FF:FF:FF:FF:FF interface=eth1 protocol=arp size=60 cpu=0
ARP only works between devices in the same subnet.
See an ARP with a different IP isn't necessary "wrong" from L3 POV – multihoming. It's only wrong from a ROS "packet flow"/policy prospective. And, how the ZeroTier package approaches discovery on the ROS is not document by Mikrotik & ZT only has a high-level overview of how it looks to establish it's tunnel paths.
I am not clear on bug reporting etiquite in this community, but according to this post, The forum is the correct place for beta releases. Is 7.1 still considered beta?You should open a ticket with Mikrotik with the supout.rif, does seem like a bug. Not sure how folks can help if so.
V7.1 isn't beta is all I know. I believe it's at least release candidate, or released if you go by the changelog page. Hard question.I am not clear on bug reporting etiquite in this community, but according to this post, The forum is the correct place for beta releases. Is 7.1 still considered beta?You should open a ticket with Mikrotik with the supout.rif, does seem like a bug. Not sure how folks can help if so.
viewtopic.php?t=152006