i’am having trouble with arp on my ccr1036-12g-4s
some portion of the client computers in our LAN often becomes invisible to the CCR
after quick research i found that on ccr side mac addresses of such clients is wrong
at the same time on windows 2008r2 server connected to the same switch as mikrotik - mac addresses is good and traffic goes without problems.
this issue repeats almost every day
deleting of incorrect arp table entries on CCR helps for a while (usually to the end of a work day)
i dont remember such issues at the time prior CCR installation, at least not so often and annoying
i had same thoughts, and logged MACs of course,
but how can you explain that other devices on LAN having correct MACs in their tables, but mikrotik is not ? even those are on the same switch with CCR
Honestly, it very well could be an issue with ROS on the CCR. I wouldn’t know without sticking my head in your network.
A similar problem I’ve had, is where I would use the ip discovery tool to scan a connected subnet, and had a cisco 3700 send arp replies for every single address. The ARP table on the ROS device would populate based on whichever reply was received first(?). This has caused a TON of problems on our network, leading us to have to completely isolate the 3700.
The 3700 was eventually taken out of service, but I never did discover the reason for the issue.
I’ve also seen a printer, of all things, cause ARP issues. IIRC, it was an HP wireless printer that was somehow attached to the WAN instead of the LAN, and we ended up with a ton of clients report issues. We got the printer off the WAN, enabled end-to-end client isolation, and have not seen this issue since.
In your situation, your ARP table is getting polluted (possibly corrupted). If they are from valid replies, you have a mis-behaving device out there. If it’s from a ROS bug, you need to isolate it and get some help from MT support.
I can attest to your issues as I just encountered this exact same problem today. I’m running ROS 6.7 on the CCR1036-12G-4S. I have yet to figure out how these ARP entries could possibly be mismatched especially when the default timeout found in IP Settings > ARP Timeout is set to 30 seconds. That definitely did not appear to be the case either because I had to manually delete out the bad entries in order to get 3 Mac workstations and a Server 2012 domain controller working again and that was over than span of 4 to 5 hours because I didn’t think the problems were related. I’m going to try to do some packet sniffing but other than that I’m out of ideas at the moment.