3 ms·
I've reached the point that flushing the ARP cache is part of my network troubleshooting routine. Always gives you the weirdest hardest to trace errors.
by valarauca1 12y ago
I've reached the point that flushing the ARP cache is part of my network troubleshooting routine. Always gives you the weirdest hardest to trace errors.
- js2 12y agoUntil that time when you flush the cache on Solaris[1] and remove the entries for its own interfaces. Then it stops responding to ARP requests for itself. Now you have an even more fun issue to troubleshoot! 1. something silly like: "arp -a | awk '{print $2}' | xargs -n 1 arp -d". It's been a while and I don't think I was the original culprit.
- saganus 12y agoAnd how do you fix that? I'm no Solaris guru obviously, but this looks like a chicken-and-egg problem. How do you actually go about fixing this? It's sounds very... Kafkesque
- valarauca1 12y agore-add it manually # arp -s 192.168.0.1 00:18:4d:f8:a4:6e Wait your working over SSH? Oh ummmm, talk to the data center guy and have him break out his USB to serial dongle and a RS232 cable.
- saganus 12y agoOh...dayum.. that's not good..
- js2 12y agoActually if you think about it, you can reach the server even if it's not replying to ARPs as long as it's initiating connections to other devices on the same network. Say A is the server in question (not responding to ARPs) and it initiates a connection to B. In this case, B will learn A's MAC, and so B will be able to reach A until A's entry times out of B's MAC table. The router for that network also has A's MAC, but you may not have access to the network gear. The intermittent connectivity to server A is what makes this problem so fun to diagnose. :-)