Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I print routes defined on my computer using route, it takes about 5 to 20 seconds to complete. Why does it take so much time?

With VPN enabled:

$ time sudo route
Kernel IP routing table
real    0m21.423s
user    0m0.000s
sys 0m0.012s

With no VPN, this is about 5 seconds - still, computer can do a lot in this time. I've repeated my measurements few times, getting very similar results each try.

My machine is Ubuntu with 3.0.0 kernel, but as far as I know, route on the other computers works the same way.

share|improve this question
up vote 16 down vote accepted

The typical reason is that route tries to map the IP addresses in the table into their DNS names - and that can be quite slow because of the vagaries of the DNS system and your network.

You can verify that by passing the -n argument to route, asking it to display only numbers without doing any name resolution. If that is super-fast, you know that it is reverse DNS lookup that delays things.

(The time, in that case, is spent waiting on external systems to respond over the network. The local CPU is pretty much idle.)

share|improve this answer
You're right. Thanks! – Rafał Rawicki Jun 10 '12 at 19:28
No problem. Don't forget to accept the answer, so other people can see that too. – Daniel Pittman Jun 10 '12 at 19:29
A similar issue occurs with the netstat commend, with the same solution. As a heads up. – Sirex Jun 10 '12 at 20:00
@Sirex Of course it would. Same with any other system tool that employs DNS lookups. And similar delays probably happen when doing DNS lookups from web browsers too, it's just that other aspects such as file transfer mask the time that it takes to load a page. – Magellan Jun 10 '12 at 23:47
@RafałRawicki Notice in particular that the 'time' display is showing a very long wall-clock time (real) but a very very short compute time (user and sys). That shows that the blocking factor is most likely external to the system itself (or is at least I/O bound). – fluffy Jun 10 '12 at 23:49

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.