CentOS Machine Sometimes Unreachable

Home » CentOS » CentOS Machine Sometimes Unreachable
CentOS 10 Comments

I have a simple perl script that every few hours pings the handful of machines on my LAN. Lately I’ve sometimes been getting

ping of 192.168.0.1 succeeded ping of 192.168.0.7 succeeded ping of 192.168.0.5 FAILED
ping of 192.168.0.6 succeeded ping of 192.168.0.9 succeeded

This machine in question has been running CentOS faithfully for about six years and no recent changes to it have been made. When I try and ping the machine manually it works. /var/og/messages does not seem irregular. Does anyone know know what might be the problem or what else I might check?

Thanks,

Richard

10 thoughts on - CentOS Machine Sometimes Unreachable

  • Am 22.08.12 15:01, schrieb Richard Reina:

    Recently I was faced with a similar problem (cant ping a device from time to time which was not touched for about two years…). My solution:
    check the lan cabel.

    The system I had problems with had been standing in the sun behind a window and the lan cabel was ‘melting’ and did not fit properly into the adapter.

    my2cents.

  • Richard Reina wrote:
    ping the

    Have you done an ifconfig on 5, and seen if there’s any collisions, etc?
    Another possibility is that *you* haven’t changed, but someone else has put a piece of hardware on the LAN that’s trying to get that IP, or has it configured for that IP.

    mark, who *really* wishes that the network folks would give
    their hardware IPs by MAC, not broadcast

  • Götz Reinicke wrote:

    Good thought! Could someone have moved non-computer hardware, like, say, a desk or chair, or there’s been some utility work, and the cable run’s impacted occasionally… or stepped on?

    mark

  • Look like there are some errors although I am not sure what the mean.

    eth0 Link encap:Ethernet HWaddr 00:D0:B7:5A:C6:FE
    inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
    inet6 addr: fe80::2d0:b7ff:fe5a:c6fe/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:2316067887 errors:0 dropped:0 overruns:1 frame:1
    TX packets:2451037674 errors:3 dropped:0 overruns:0 carrier:3
    collisions:0 txqueuelen:1000
    RX bytes:221599111550 (206.3 GiB) TX bytes:575914174697 (536.3
    GiB)

    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:1197938537 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1197938537 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:109601534433 (102.0 GiB) TX bytes:109601534433 (102.0
    GiB)

    Cable seems fine and machine is in a dark room (no sunlight) although it does run through the ceiling.

    2012/8/22

  • Richard Reina wrote:
    Please stop top posting.

    I’m not sure, but overrun? Frame? Not sure. Cabling goes into the ceiling… was there any wiring or HVAC work done lately, where the cables might run?

    mark

  • What does ethtool say about your duplex setting, and is the connected switch set one way or the other? In the long distant past, cisco switches weren’t very good about negotiating and they recommended configuring full duplex at both ends of the connections. Now the hardware and standards are better and everyone uses auto, but you might have an old switch or an old configuration somewhere in the path. The problem is that if one end of the connection is set to not negotiate, the other end will pick half duplex and the mismatch will cause trouble at random.

  • People in glass houses shouldn’t throw stones. Complaining about top posting and then not trimming everything you’re not replying to
    (like below) is just as bad…

  • 2012/8/22 Les Mikesell

    Here is the output from ethtool

    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 auto-negotiation: Yes
    Speed: 100Mb/s
    Duplex: Full
    Port: MII
    PHYAD: 1
    Transceiver: internal
    Auto-negotiation: on
    Supports Wake-on: g
    Wake-on: g
    Current message level: 0x00000007 (7)
    Link detected: yes

    THe switch is a linksys etherfast 3124 that has worked perfectly for 10
    years. I don’t know anything about it’s settings. This is a LAN with about a dozen machines.

    Thanks

  • Or even vibrated loose.

    As a lesson in ‘vibrational torque’ aka the ‘whimmy diddle effect’ (see https://en.wikipedia.org/wiki/Gee-haw_whammy_diddle ), I’ll relate what happened to a machine in our newly rennovated Research Building Data Center. The machine in question is an EMC Clariion CX3-80 with three 40U racks. Each rack needs two 30A 208V single-phase circuits. Due to the way the electrical was run for this machine, one UPS is powering one side of the three cabinets, and a second, smaller UPS is powering the other side. The secondary feed’s L6-30R’s are mounted to the pedestals of the raised floor; the primary feed’s L6-30R’s are in cast aluminum pendants lying on the subfloor, with the receptacles pointing up.

    An electrician was drilling two 1/4 inch holes for concrete anchors for a conduit run sixteen feet away from the CX3-80 a couple of days ago, and I started getting a bunch of alerts from the CX3-80. I looked at the array, and yellow lights were lit on all three cabinets. Hmm, what’s up with that; power loss to the whole side of the array?

    I lifted the panel over the L6-30R’s in the pendant on the subfloor, and all of the twist-lock plugs were unplugged from their pendant receptacles! No one was in the data center but the electrician, and the power was fine right before he started drilling the two small holes. I personally had plugged in the plugs that morning, and had set the cords to apply the correct torque to maintain the twistlock, and had fully seated and locked the plugs in the receptacles. The vibration of the hammer drill sixteen feet away hit the right resonance, and ‘whimmy diddled’ the plugs out of their receptacles.

    Thermal cycling can also exert torques, and one of my preventive maintenance steps in all of our data center spaces with twist lock plugs is to reseat the twistlock once per quarter.

LEAVE A COMMENT