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

I am working on Linux.

I added a route to a virtual IP say: by running the command:

route -n add gw

It has been redirected to my local loopback. I checked the kernel IP table and it has the path setup correctly. Now, I run a script that binds on the same IP and then try to ping the IP from my machine, it gets the ping reply correctly.

But another computer on the same network cannot ping this virtual IP address. I checked up on the Internet and it does say that I can have multiple IPs on my local loopback and they can be viewed from the peers on the same network.

I tried adding a path on the eth0 interface by replacing the by my eth0 IP address. The information was added to the route table correctly, but then the same thing happened: I was able to ping from my own machine but the peer couldn't.

I Googled up the same thing but none of the solutions helped me out.

The script (it send back ICMP packet replies) is correct (I am sure of that) since I get ping replies from my own machine for the IP which I set up the route for.

Where am I going wrong? Or am I missing out on some configuration?

Any help is much appreciated!


This is the route table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface     localhost.local UGH   0      0        0 lo     *        U     1      0        0 eth0
link-local      *          U     1000   0        0 eth0
default         UG    0      0        0 eth0

and interface config:

eth0     Link encap:Ethernet  HWaddr 00:22:19:ec:ee:50  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::222:19ff:feec:ee50/64 Scope:Link

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
share|improve this question

migrated from Jun 29 '11 at 9:54

This question came from our site for professional and enthusiast programmers.

You're missing the fact that this isn't a programming question: – Raoul Jun 29 '11 at 9:17
Before anyone can do any debugging, they'll need to see the output of ip route show and ip addr show. – sarnold Jun 29 '11 at 9:23
I added the the route table and config info. the commands you said, were not working on my linux mint ( weird) but I guess this should give the same info you wanted. – Sylar Jun 29 '11 at 9:40
Sorry to reply in the answer box, but it wasn't letting me comment. the ifconfig eth0:0 netmask would set me up another interface. I don't want that. If someone connects to the "fake" IP I am redirecting to my machine, I have a script running on it ( as mentioned in first post). I want anyone who connects to it ( ssh) and uses the script would find the "fake" IP address as a separate machine. That is why I was playing around with the route command. I mean, if I want to run this script on 100 "fake" IPs, setting up interface for each of them would not be the ideal solu – user86201 Jun 30 '11 at 9:02

I am unclear why you're mucking about with route commands on the local system in any case. If you have an address configured on one of your local interfaces, you don't need to specify an explicit route; your system will already know how to contact it.

So for example, if you already have eth0 configured as above, you should be able to do this:

ifconfig eth0:0 netmask

And now your local system will be all set.

For other systems on your network to contact your system at that ip address, one of three things will need to be true. Either:

  • they need to have an interface on the same ip network, or
  • they need to have an explicit route to that ip network, or
  • their default gateway needs to have a route to that ip network

So if you have another system with the "real" address is, then you would either do this:

ifconfig eth0:0 netmask

Or this:

route add -net dev eth0
share|improve this answer

Your Answer


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