Header Shadow Image


Destination Host Unreachable

While testing the NIC connectivity and speed for my HTPC / Home Backup system, I get this unpleasant surprise.  Needles to say the issue was really due to the high transfer speeds on my 1GB/s network that that intel card has appeared to have a bit of difficulty with.  The difficulty has now been resolved with the purchase of a more stable Intel card. 

Either way, here's how to handle this one on a Linux server.  There is a number of solutions to this one some fairly obvious, others not so much:

From 192.168.0.8 icmp_seq=12091 Destination Host Unreachable
From 192.168.0.8 icmp_seq=12092 Destination Host Unreachable

through a resolution on the software side of things of this disconnected NIC:


[ DIAGNOSIS ]

First, let's check the basic things:

[root@mbpc bonding]# ifconfig
bond0     Link encap:Ethernet  HWaddr 00:25:86:F1:65:D0
          inet addr:192.168.0.8  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::225:86ff:fef1:65d0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:63317 errors:0 dropped:0 overruns:0 frame:0
          TX packets:58080 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:54520877 (51.9 MiB)  TX bytes:7657909 (7.3 MiB)

eth0      Link encap:Ethernet  HWaddr 00:25:86:F1:65:D0
          UP BROADCAST SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:1495 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1440 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:286596 (279.8 KiB)  TX bytes:122449 (119.5 KiB)
          Interrupt:26 Base address:0x6000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:9412 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9412 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1030013 (1005.8 KiB)  TX bytes:1030013 (1005.8 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:25:86:F1:65:D0
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:61822 errors:0 dropped:0 overruns:0 frame:0
          TX packets:56640 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:54234281 (51.7 MiB)  TX bytes:7535460 (7.1 MiB)

[root@mbpc bonding]#

Next we check the ARP tables.  :

[root@mbpc bonding]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1              ether   00:0f:66:9d:d1:47   C                     bond0
[root@mbpc bonding]#

A few seconds later:

[root@mbpc bonding]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1                      (incomplete)                              bond0
[root@mbpc bonding]#

and again,

 Destination Host Unreachable

[ SOLUTION (1) ]

After running:

[root@mbpc bonding]# echo -wlan0 > /sys/class/net/bond0/bonding/slaves

The address is back:

[root@mbpc bonding]# arp -n
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.0.1              ether   00:0f:66:9d:d1:47   C                     bond0
[root@mbpc bonding]#

And add the correct hardware address to each line:

[root@mbpc network-scripts]# cat ifcfg-wlan0
DEVICE=wlan0
ONBOOT=yes
BOOTPROTO=none
TYPE=Ethernet
USERCTL=no
IPV6INIT=no
NM_CONTROLLED=no
HWADDR=00:25:86:F1:65:D0   # <<<<<<<<

MASTER=bond0
SLAVE=yes
[root@mbpc network-scripts]#

 

could give you your connection back.  Turned out that in the first case above, the NIC card was dropping the connections at high transfer rates (100MB/s+) and dropping the driver apparently through a kernel panic (see below).

[ SOLUTION (2) ]

In this case, I needed to add the default route through the route command like this. (Note that below I'm testing the wireless and wired parts (bond0 = wlan0 + eth0) in my config. ):

[root@mbpc ~]# ping google.com
PING google.com (74.125.226.51) 56(84) bytes of data.
From 192.168.0.6 icmp_seq=2 Destination Host Unreachable
From 192.168.0.6 icmp_seq=3 Destination Host Unreachable
From 192.168.0.6 icmp_seq=4 Destination Host Unreachable
^C
— google.com ping statistics —
5 packets transmitted, 0 received, +3 errors, 100% packet loss, time 4628ms
pipe 3
[root@mbpc ~]# route del default gw 192.168.0.6
[root@mbpc ~]# route add default gw 192.168.0.1
SIOCADDRT: File exists
[root@mbpc ~]# ping google.com
PING google.com (74.125.226.50) 56(84) bytes of data.
64 bytes from yyz06s06-in-f18.1e100.net (74.125.226.50): icmp_seq=1 ttl=56 time=31.7 ms
64 bytes from yyz06s06-in-f18.1e100.net (74.125.226.50): icmp_seq=2 ttl=56 time=32.5 ms
64 bytes from yyz06s06-in-f18.1e100.net (74.125.226.50): icmp_seq=3 ttl=56 time=32.7 ms
64 bytes from yyz06s06-in-f18.1e100.net (74.125.226.50): icmp_seq=4 ttl=56 time=31.6 ms
^C
— google.com ping statistics —

4 packets transmitted, 4 received, 0% packet loss, time 3569ms
rtt min/avg/max/mdev = 31.660/32.177/32.713/0.503 ms
[root@mbpc ~]# ifdown eth0
[root@mbpc ~]# ping google.com
connect: Network is unreachable
[root@mbpc ~]# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16526 (16.1 KiB)  TX bytes:16526 (16.1 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:25:86:F1:65:D0
          inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::225:86ff:fef1:65d0/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:46 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5616 (5.4 KiB)  TX bytes:4760 (4.6 KiB)

[root@mbpc ~]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.0     *               255.255.255.0   U     0      0        0 wlan0
link-local      *               255.255.0.0     U     1002   0        0 wlan0
[root@mbpc ~]# route add default gw DD-WRT
[root@mbpc ~]# ping google.com
PING google.com (74.125.226.49) 56(84) bytes of data.
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=1 ttl=56 time=17.0 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=2 ttl=56 time=17.2 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=3 ttl=56 time=15.7 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=4 ttl=56 time=15.9 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=5 ttl=56 time=16.0 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=6 ttl=56 time=17.1 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=7 ttl=56 time=30.5 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=8 ttl=56 time=23.6 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=9 ttl=56 time=18.5 ms
64 bytes from yyz06s06-in-f17.1e100.net (74.125.226.49): icmp_seq=10 ttl=56 time=16.1 ms
^C
— google.com ping statistics —
10 packets transmitted, 10 received, 0% packet loss, time 9526ms
rtt min/avg/max/mdev = 15.781/18.821/30.592/4.503 ms
[root@mbpc ~]#

The above one involved a bit more digging to resolve but had the same end results: a working connection.

[ SOLUTION (3) ]

This is the most straight forward solution.  We're running a DHCP server off of eth1.  Coincidently, at some point the cable coming from the router was plugged into the eth1.  This is only for PXE / TFTP Boot so shouldn't be connected unless to another host.  This is easily realized by running the ethtool on both eth0 and eth1. Note the connectivity in RED and GREEN below.  Moving the cable did the trick:

[root@moto network-scripts]# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: d
        Current message level: 0x00000007 (7)
        Link detected: no
[root@moto network-scripts]#
[root@moto network-scripts]#
[root@moto network-scripts]# ethtool eth1
Settings for eth1:
        Supported ports: [ TP MII FIBRE ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pumbags
        Wake-on: pubg
        SecureOn password: 00:00:00:00:00:00
        Current message level: 0x000040c5 (16581)
        Link detected: yes
[root@moto network-scripts]#

 

[ SOLUTION 4 ]

If your server is a VM on VMWare ESXi and you have a private VLAN switch created, the Destination Host Unreachable will occur if you are trying to setup a PrivateSwitch / VLAN between two VM's sitting on different ESXi hosts, the two Private NIC's sitting on each VM cannot see each other.  To resolve this, do one of the following:

1) Ensure the two VM's are sitting on the same ESXi host.
2) Ensure that the PrivateVLAN's are connected between the two ESXi hosts through a physical cable.

Cheers,
TK

Leave a Reply

You must be logged in to post a comment.


     
  Copyright © 2003 - 2013 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License