Tag: ping

Using telnet and it was pointing to a wrong address. Ping was directing to correct IP address

linux was solving hostname to an incorrect IP address when using telnet

root@linux:~ # telnet host24100
telnet: connect to address Connection refused

It was solving to the correct IP address when using ping

root@linux:~ # ping -c1 host24100
PING host099.setaoffice.com ( 56(84) bytes of data.
64 bytes from host27100.setaoffice.com ( icmp_seq=1 ttl=127 time=1.32 ms

— host099.setaoffice.com ping statistics —
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.321/1.321/1.321/0.000 ms

I’ve restarted nscd service

root@linux:~ # service nscd status
Checking for Name Service Cache Daemon: running

root@linux:~ # service nscd stop
Shutting down Name Service Cache Daemon done

root@linux:~ # service nscd start
Starting Name Service Cache Daemon done

After the restart, it started to point to the correct IP address

root@linux:~ # telnet host24100 24100
Connected to host24100.
Escape character is ‘^]’.
telnet> quit
Connection closed.


ping Error: Destination Host Unreachable in a Linux VMware guest

Server was unable to find another server in the same network

root@linux:~ # ping -c1
PING ( 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable

— ping statistics —
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

When I ran traceroute it shows (H!)

root@linux:~ # traceroute
traceroute to (, 30 hops max, 40 byte packets using UDP
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 linux.bkp.setaoffice.com (!) 2983.660 ms (H!) 2982.519 ms (H!) 2981.394 ms

This server is a VMware guest. Check if your physical host doesn’t have a configuration that prevents the connection from working

root@linux:~ # dmidecode –type system
# dmidecode 2.9
SMBIOS 2.4 present.

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: VMware, Inc.
Product Name: VMware Virtual Platform
Version: None
Serial Number: VMware-42 10 66 9e 4f bf f3 14-93 30 e0 66 8f 0c 14 7c
UUID: 4210669E-4FBF-F314-9330-E0668F0C147C
Wake-up Type: Power Switch
SKU Number: Not Specified
Family: Not Specified

Handle 0x0081, DMI type 15, 29 bytes
System Event Log
Area Length: 16 bytes
Header Start Offset: 0x0000
Header Length: 16 bytes
Data Start Offset: 0x0010
Access Method: General-purpose non-volatile data functions
Access Address: 0x0000
Status: Invalid, Full
Change Token: 0x00000036
Header Format: Type 1
Supported Log Type Descriptors: 3
Descriptor 1: POST error
Data Format 1: POST results bitmap
Descriptor 2: Single-bit ECC memory error
Data Format 2: Multiple-event
Descriptor 3: Multi-bit ECC memory error
Data Format 3: Multiple-event

Handle 0x0105, DMI type 23, 13 bytes
System Reset
Status: Enabled
Watchdog Timer: Present
Boot Option: Do Not Reboot
Boot Option On Limit: Do Not Reboot
Reset Count: Unknown
Reset Limit: Unknown
Timer Interval: Unknown
Timeout: Unknown

Handle 0x0108, DMI type 32, 20 bytes
System Boot Information
Status: No errors detected

Failure: The event flow is broken on solaris.setaoffice.com for the last 60min. Please follow the instructions.

ATTENTION, RMC LEVEL 1 AGENT: This ticket will be automatically worked by the Automation Bus. Pls do not take ownership until further notice.
Node : solaris.setaoffice.com
Node Type : Sun SPARC (HTTPS)
Severity : major
OM Server Time: 2015-04-01 14:37:24
Message : Failure: The event flow is broken on solaris.setaoffice.com for the last 60min. Please follow the instructions.
Msg Group : ITO
Application : HealthCheck
Object : OVO-agent
Event Type :

Instance Name :

Instruction : (Please carry out instructions in order and record output in ticket)

1) check if there is any maintenance ongoing for the respective system. Set an scheduled outage if yes.

2) check if the system is reachable – login to the server in question and ping the OVO management server. if not pingable, inform the second line or technical lead

3) if the system is reachable, generate a test alert on the node in question.

4) if the test alert is not received, do opcagt -kill; then remove temp queue files (/var/opt/OV/tmp/OpC/*q on Unix or on windows,
…\tmp\OpC\*q); then do opcagt -start on the system. Generate another test alert on the node in question.

5) if the the test alert is not received, refer the call to OVO monitoring support team.

Check which host is the HPOM manager and try to ping it

root@solaris:/ # /opt/OV/bin/ovconfget | grep OPC_PRIMARY_MGR

root@solaris:/ # ping hpommanager.omc.hp.com
hpommanager.omc.hp.com is alive

Try also to use the tool bbcutil and check the status. If everything is also okay, the manager is having trouble reaching the managed host.

root@solaris:/ # bbcutil -ping https://hpommanager.omc.hp.com

https://hpommanager.omc.hp.com: status=eServiceOK
bbcV=11.14.014 appN=ovbbccb appV=unknown version
conn=9 time=1199 ms