Operating System - Linux
1751860 Members
5442 Online
108782 Solutions
New Discussion

Network timedout in RHEL 2.4.21-27.EL

 
rajesh73
Super Advisor

Network timedout in RHEL 2.4.21-27.EL

i our client their is one RHEL 2.4.21-27.EL

 

some tine request timed out comes. how to identify the fault.

 

 

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Request timed out.

Request timed out.

Request timed out.

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

Reply from 40.50.25.60: bytes=32 time<1ms TTL=64

 

3 REPLIES 3
rajesh73
Super Advisor

Re: Network timedout in RHEL 2.4.21-27.EL

Hi,

 

Please help me :

 

 

this is urgent

rajesh73
Super Advisor

Re: Network timedout in RHEL 2.4.21-27.EL

pls help me !

Matti_Kurkela
Honored Contributor

Re: Network timedout in RHEL 2.4.21-27.EL

The "Request timed out" means your client sent a ping packet to 40.50.25.60, but did not get a response back in a reasonable time.

 

The next step is to find out why the response is not coming in:

  • is the ping packet actually leaving your client at all?
  • is it because the ping packet is dropped on the way to 40.50.25.60?
  • or is it because 40.50.25.60 is too busy to answer?
  • or is the response dropped on the way from 40.50.25.60 to your client?

Can you run (or have someone else run) "tcpdump" or similar network analyzer on 40.50.25.60 while sending pings from your client? If the network analyzer shows an unbroken sequence of incoming ping requests and outgoing responses on 40.50.25.60 while the client shows "Request timed out", then the fault is in the 40.50.25.60 -> client direction; if the analyzer shows no ICMP echo request packets at all on 40.50.25.60 when the client shows "Request timed out", then the fault is in the client -> 40.50.25.60 direction.

 

For further analysis, you'll probably need help from the network administrator of your site. If your network uses enterprise-grade manageable switches, you can probably get port-based statistics from them. If one of the network hops indicates incoming packets with errors and the error count is increasing, it might indicate a bad cable or other hardware problem. If dropped packets are indicated, the switch or a particular port might be overloaded, trying to pass more traffic than it can handle.

MK