I’ve started getting a problem where my routing becomes corrupted/lost to a remote system of my own. It seems to be something to do with a problem outside the server but when everything else comes back this one machine can no longer see the remote system, even though it is there. A ping gives destination host unreachable and the arp cache shows it as incomplete. I can’t remove the arp entry because it also says that the destination is not reachable. If I do a traceroute it completes as soon as at looks at the local host.
I’ve had to reboot the system so no longer have the problem but I would like to try and track it down if/when it happens again.
Look after the ip address of your next router and add this with “route add” again.
Or you can use Yast with Yast -> Network Devices -> Network Card -> Edit -> routing.
Take a backup of the config file /etc/sysconfig/network/routes.
To the OP,
You need to better describe how you configured this “route to a remote system>”
Your routing table on your local machine should not be affected by whatever happens elsewhere(Is why @AdaLovelace suggestion probably won’t do anything).
You may need to better describe how you’re testing your routing, ie
Most *NIX utilities like ping and traceroute do not cache results
Web browsers do cache results. You need to “reload” or “refresh” and if you don’t mind the decreased performance even turn your caching off (all seasoned web developers do this or forever return bad results)
You can always display the routing table on your local system with the following
The TO has written, routing woud be lost or corrupted. It can be, that Yast or an upgrade has removed the old routing table. Or nothing is saved…
We need more informations or he has to create a new routing.
In the OP post,
Doing a trace route always worked but never failed.
Nothing was described that happened on this machine prior to rebooting, and rebooting apparently was all that was required to fix the problem.
So, as I suggested in my original post,
Nothing had happened to the routing table, especially since a trace route worked.
And especially since a reboot fixed the problem, that points to something temporary that was preventing a connection and the most likely cause of that is the method of testing and a cached fail. You can clear the cache with a reboot or if you know this is the problem by manually clearing the cache of that application or resetting the application to not cache.
It must be the way I expressed myself but the traceroute didn’t work to the system in question. It came back showing the route was to the local router when there should have been multiple hops.
In terms of the route output, it showed what I expected, that the local router was the default gateway and the remote system is not directly configured, it relies on normal ISP DNS to get the route.
This has happened a couple more times recently and I have been trying to look further and have discovered that when the system is running normally there is nothing in the arp data about the remote system, even if I’ve just ping’d it. So why is it that when it goes wrong the arp data is saying incomplete.
On 2015-09-03 05:06, davidlwilcox wrote:
>
> This has happened a couple more times recently and I have been trying to
> look further and have discovered that when the system is running
> normally there is nothing in the arp data about the remote system, even
> if I’ve just ping’d it. So why is it that when it goes wrong the arp
> data is saying incomplete.
When a packet is routed via a router, you don’t get its destination MAC
address in the table. Your machine does not use it: it sends to the router.
You only get the MAC addresses of hosts in your same network segment.
So, if the arp table should only have addresses in my local network, why I am getting an entry about a remote system at all, let alone an incomplete entry