We help IT Professionals succeed at work.

Problems with local loopback interface trying to be a route to the net

fruey asked

I have problems with a Cobalt CacheRaq. When I type 'traceroute www.cnn.com' or something, I get:

traceroute: Warning: Multiple interfaces found; using @ lo
traceroute to cnn.com (, 30 hops max, 40 byte packets
 1  * * *

and so on.

However, the output of commands are as follows:
route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
194.xx.xx.xx U     0      0     1744 eth0       U     0      0        1 lo         194.xx.xx.xx         UG    0      0     2598 eth0

and ifconfig :
lo        Link encap:Local Loopback
          inet addr:  Bcast:  Mask:
          UP LOOPBACK RUNNING  MTU:3584  Metric:1
          RX packets:102048 errors:0 dropped:0 overruns:0
          TX packets:102048 errors:0 dropped:0 overruns:0
eth0      Link encap:Ethernet  HWaddr 00:10:E0:00:FF:7C
          inet addr:194.xxx.xxx.xx  Bcast:194.xxx.xxx.xx  Mask:
          RX packets:72257 errors:0 dropped:0 overruns:0
          TX packets:52719 errors:5 dropped:0 overruns:4

This all appears good to me. Does anyone have any ideas please.

There's no ipchains running on the system causing spooky redirects.
Watch Question

up the metric on lo


Yeah OK but on my box here (RH7.1 with KDE and Opera) I don't have that issue ; as for the box above which has problems, all interfaces have metrics of 0 ...

I'd love to know the REAL solution / cause of this problem


In any case, looking at man route:

The  'distance'  to  the targed (usually counted in
hops). It is not used by recent kernels, only routing daemons may use it.

And this does appear to be a kernel issue.
Yeah, not really an answer to the question, but a temp fix maybe

This netstat output is confusing to me since I never had a reason to use a default route from the local loopback interface on 127.x.x.x. I have the suspicion that this is not intended. Then again, it may be...

As far as the multiple interfaces is concerned: traceroute is kind enough to tell you that it has a choice through which interface to proceed in order to find a destination host. And since there are two gateways which are using a static route to the 'world', it chooses over the 192.x.x.x route.

In my mind, this shouldn't work. But then again, it appears to be. I check'ed my RAQ3 to see if it has a smiliar routing table and it doesn't. On my suns, the lo0 interface is not assigned as a default route either.

Just my 2c
try this:

route add -host dev eth0
as a reference, here are results of my box:

route -n:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface UH    0      0        0 eth1   U     0      0        0 eth1   U     0      0        0 eth0       U     0      0        0 lo         UG    0      0        0 eth0

eth0      Link encap:Ethernet  HWaddr 00:50:BA:4B:0A:FC
          inet addr:  Bcast:  Mask:
          RX packets:4870501 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4412511 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0x6000

eth1      Link encap:Ethernet  HWaddr 00:50:BA:4B:0B:07
          inet addr:  Bcast:  Mask:
          RX packets:4161821 errors:10565 dropped:0 overruns:0 frame:0
          TX packets:3482811 errors:0 dropped:0 overruns:0 carrier:0
          collisions:5047 txqueuelen:100
          Interrupt:9 Base address:0x6100

lo        Link encap:Local Loopback
          inet addr:  Mask:
          UP LOOPBACK RUNNING  MTU:3924  Metric:1
          RX packets:190 errors:0 dropped:0 overruns:0 frame:0
          TX packets:190 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0

  hopefully, you don't mind some enquiries of a professional nature.

  I am curious: would you mind sharing the rationale behind this route entry for the broadcast traffic ?

  Also, I am interested in the reasons why the broadcast address for your eth0 interface is instead of the standard (netmask This looks like a deliberate custom setup which I haven't seen before.

  Finally, digging around in documentation, the impression I get from changing the metric setting is that changes are only interesting if the host uses gated or routed in order to do routing (http://www.linuxdoc.org/LDP/nag/node32.html#SECTION004450000). Were you successful using your method in other circumstances ?

  after some more reading, I agree with you that the route and interface configurations are appropriate.

  You may want to go through the trouble of resetting your interfaces by hand using ifconfig. There used to be some bugs which didn't activate the interface settings until a interface reset occured. Reset usually happens when the ip address gets assigned.  

  Or, maybe the problem is somewhere else. Now, this may be a long shot, but can you show an 'dig' from this server to www.cnn.com.  I would like to make sure that www.cnn.com does not somehow point to the

to tell you the truth, i have no idea why it is there.  I just know I read it somewhere and now it works.


I have already tried manually resetting devices with no success.

The problem seems to be limited to traceroute, since the box is now functioning correctly as a Squid cache.

Also, I changed the IP of the eth0 which appeared to help things; the traceroute problem is still there but the box can "see" www.cnn.com no problem now.

This old question needs to be finalized -- accept an answer, split points, or get a refund.  For information on your options, please click here-> http:/help/closing.jsp#1 
Post your closing recommendations!  No comment means you don't care.
Probably pointless to post this here after this amount of time, but what the heck...

I found this question while having an identical problem with my own system.  I'm in the process of building a Gentoo box.  Anyway, after trying various things to resolve this issue (including catching a couple of other minor problems with my setup) *and* fiddling around with the 'Metric' settings as suggested by 'packratt_jk' -- all to no avail -- I resorted to looking through the source code (for traceroute-1.4a12).

Turns out the "Multiple interfaces found" message comes from the file 'findsaddr-generic.c'.  Since I'm on a linux system, and there is a "matching" 'findsaddr-linux.c' which was apparently not compiled into the program, I dug a little deeper.

The ./configure script uses the existence of '/proc/net/route' to decide that we are on a linux system.  Of course, if you do the usual "./configure; make" as a standard user and only switch to root to run "make install", the /proc filesystem will be off limits and you'll end up linking in the "generic" version of "findsaddr" instead.  Obviously, this is *not* correct, and is probably the direct cause of this particular hiccup in the program.  If you switch to root to run the ./configure script, it should correctly identify your system as linux, and all will be well...  (It now works for me without getting confused.)


Never pointless, even after time, to enlighten me to a question I asked in an old job in another country from the one I'm in now, and seem to come up with something spot on. Now the old Cobalt box, if I remember rightly, did work. I don't know if traceroute ever did work, but it would have been precompiled in any case; your explanation sounds dead right though. If I ever hear from the current owner of the box I'll tell him to compile traceroute from scratch if he needs it.

So, have the long forgotten points, they're still in the DB somewhere... hehe the query to take them from my account had better go there with a good vacuum cleaner to get rid of all the dust.
Well, thanks for that :-)  I suspect there are at least a couple of Linux distros that have been caught by that particular 'subtlety' and are distributing broken versions of traceroute.  I passed it on to the authors, so hopefully they'll either document the potential problem or find a fix...

Explore More ContentExplore courses, solutions, and other research materials related to this topic.