Hello, I’m having difficulty displaying the ARP table information, which is showing blank. This issue started after updating the routers from version 6 to version 7. Each version 7 update has presented this type of failure in different production equipment. For example, currently I have two routers with this issue: one is the CCR1009 model, running version 7.8, and the other is the CCR1036, running version 7.11.2. I am a small ISP, and these routers provide access to clients. The configuration used for layer 2 encapsulation for each client connection is the 802.1q protocol (VLAN), and currently, I have an average of 300 to 500 VLANs configured on the equipment.
When the equipment experiences this failure, if restarted, it returns to displaying ARP table information normally, but after some time of use, the failure occurs again. If anyone knows of a solution and can help me, I would be very grateful.
It means your L2 link is dead. A blank MAC address in an ARP entry means the entry is “incomplete”, i.e. there was no reply to the ARP request.
That being said, a difference between v6 and v7 is that v7 never clears the ARP table. So even after an entry is unused for a long time, it still remains in the table. v6 would remove it after some time.
So it may be that you now see more entries and that a lot of them are “blank”, but that does not necessarily mean there is a failure.
It could be there is a client that was online before, and is now offline.
Before declaring it a failure, you need to check if there actually are issues with communication, rather than only a lot of blank ARP entries in the table.
When you want to clean the table without rebooting, you can schedule a script like this:
/ip arp remove [ find where !complete and !published ]
So, it happens that L2 communication is working correctly, but the information in the ARP table is completely blank, without any data whatsoever. Even when I use the Terminal with the ‘ip arp print’ command, it also displays all the information as blank. In the screenshot below, it shows how the ARP information looks even when it was confirmed by the log that the linking of IP addresses with MAC addresses occurred.
#Adding the pool
/ip pool
add name=dhcp-pool-954789 ranges=100.65.61.26
#Adding the DHCP Server
/ip dhcp-server
add add-arp=yes address-pool=dhcp-pool-958347 conflict-detection=no disabled=
no interface=vlan-958347 lease-time=1d name=dhcp-958347
#Adding IP addresses to physical interfaces and VLANs
/ip address
add address=172.16.227.194/27 disabled=yes interface=ether1 network=
172.16.227.192
add address=100.65.61.25/30 interface=vlan-954789 network=100.65.61.24
#Adding network information to the DHCP Server
/ip dhcp-server network
add address=100.65.61.24/30 dns-server=8.8.8.8,8.8.4.4 gateway=
100.65.61.25
When a failure occurs, L3 connectivity works correctly, there are no network communication failures, only ARP does not display any information.
Another issue we have observed is that some of these routers have also been experiencing errors when new configurations are saved to the NAND memory. When new configurations are made, they remain in volatile memory. However, if no backup of the new information is saved, and the router is restarted, it reverts to an older backup. Most of the routers that have shown this error either needed to be reset and a newer backup uploaded, or sent to technical support for investigation. What we haven’t yet identified is whether all routers experiencing this ARP display failure may also be experiencing issues with saving information to the NAND memory.
The latter is usually caused by the flash memory being completely full.
Check System->Resources and look at the HDD space. When it is zero or near zero (e.g. 8K), you are in trouble.