30 second delay before ping command will succeed

In a site-specific networking environment (other sites do not
experience this problem), we consistently observe a 30 second delay
from the time the networking cable is plugged into the system and the
time that the ICMP ping command will succeed.

Requests to ping the server within this 30 second period from initial
network connection will timeout.

It is an important feature of our application to dynamically
connect/disconnect from various networks.

Does anyone have any ideas on how to troubeshoot/eliminate this 30
second delay?

Thanks in advance for your thoughts on this issue.

A. Irish

(E-Mail Removed) wrote:
> In a site-specific networking environment (other sites do not
> experience this problem), we consistently observe a 30 second delay
> from the time the networking cable is plugged into the system and the
> time that the ICMP ping command will succeed.
>
> Requests to ping the server within this 30 second period from initial
> network connection will timeout.
>
> It is an important feature of our application to dynamically
> connect/disconnect from various networks.
>
> Does anyone have any ideas on how to troubeshoot/eliminate this 30
> second delay?
>
> Thanks in advance for your thoughts on this issue.

Imagine if that delay didn't exist. Imagine further that some idiot
connected switch A to switch B with two cables. Now imagine a broadcast
packet being sent over and over between switch A and B and out all live
ports on both switches. Boom. Your network is now useless.

Now, imagine if there's a brief delay after the cable is connected. The
switch sends some probe packets but no live traffic. If it gets its
probe packets back on another port, it knows there is a loop and can
deactivate the port.

Waiting 30 seconds for loop detection is essential in any situation
where a loop is possible.

Your switch may or may not make this optional, but think long and hard
before you shut it off.

DS

On Thu, 28 Dec 2006 10:04:42 -0800, airish wrote:


> In a site-specific networking environment (other sites do not
> experience this problem), we consistently observe a 30 second delay
> from the time the networking cable is plugged into the system and the
> time that the ICMP ping command will succeed.
>
> Requests to ping the server within this 30 second period from initial
> network connection will timeout.
>
> It is an important feature of our application to dynamically
> connect/disconnect from various networks.

I would think so. It sounds like SpanningTree (STP) at work.

> Does anyone have any ideas on how to troubeshoot/eliminate this 30
> second delay?

Why would you want to do this? 30sec. is acceptable in keeping the
network safe.

> Thanks in advance for your thoughts on this issue.

SpanningTree protects your network from a routing loop which can bring
down the network.


--

Regards
Robert

Smile... it increases your face value!


----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

> > It is an important feature of our application to dynamically
> > connect/disconnect from various networks.
>
> I would think so. It sounds like SpanningTree (STP) at work.
>
> > Does anyone have any ideas on how to troubeshoot/eliminate this 30
> > second delay?
>
> Why would you want to do this? 30sec. is acceptable in keeping the
> network safe.
>

If you turn on the PortFast feature on the ports, STP is still active,
but the switch's port will be accessible instantly. This is what you
want on all ports not connected to layer-2 devices
(switches/hubs/bridges). If, for some reason, a loop is created, STP
will pick this up very quickly, although there is the second or two of
a potential broadcast storm.

I think in the case that the OP is talking about, the need to quickly
connect and disconnect from networks outweighs the need for the
30second check. Non-Portfast ports on a switch can also negatively
impact DHCP when a computer is first powered up, if it is very quick in
booting, or requires to be network booted, in which case the system may
fall back to a disk, a potential security risk dependant on the
configuration.