What causes first ping to drop?

Discussion in 'Cisco' started by schulz.brad, Dec 8, 2006.

  1. schulz.brad

    schulz.brad Guest

    We have a high speed DS3 connection to a remote location. One of the
    servers there is for hosting e-mail archiving. After a period of
    inactivity, the archive client reports a "server time-out" error. The
    subsequent tries are successful. We have also noted that the first
    ping after a period of inactivity is dropped but subsequent pings are
    flawless. What causes this?

    I don't think it is an ARP issue because the destination server is a
    member of the domain and is very chatty. The routers are routing other
    traffic continuously to the same subnet so the ARP tables should be
    current.

    I'm not sure what to look at next. Help!

    Thanks!
     
    schulz.brad, Dec 8, 2006
    #1
    1. Advertisements

  2. I only saw this "loss of first packet" with missing arp entries.
     
    Lutz Donnerhacke, Dec 8, 2006
    #2
    1. Advertisements

  3. schulz.brad

    Peter Guest

    Greetings,
    Arp... plain and simple. It is a very common situation. If you think
    the ARP table is being flushed in your case then you may have an ARP
    cache overflow somewhere that might give the appearance of an ARP
    issue.
    It is also worth considerig the MAC table limits within your
    Etherswitches, loading up lower level switches can invite unexpected
    disasters if traffic density is high.

    Cheers...............pk.
     
    Peter, Dec 9, 2006
    #3
  4. schulz.brad

    Merv Guest

    Suggest you post the complete network topology for allnetwork devices
    between the remote server and the archive client

    Is the ping being issued

    check the setting for ARPO timeout ( default is 4 hours)

    CAM table or MAC address table timeout (default os 5 minutes)

    check the size of the ARP table on each device

    check the size of the CAM or MAC address table on each device in the
    path
     
    Merv, Dec 9, 2006
    #4
  5. schulz.brad

    schulz.brad Guest

    Thanks for the reply's. It looks like the consensious is that it is an
    ARP problem. The real problem is that the client is not resilient
    enough to retry, so maybe a static ARP somewhere in the path would fix
    the problem.



    Here are the devices & topology:

    1) Clients on Cisco 6506 distribution switches (IOS code)
    2) Core 6506 switches running IOS with sup. 720's
    3) Cisco 2821 router, 256Mb memory, running 12.3 IOS
    4) AT&T DS3 point-to-point through accu-ring to site 100 miles away -
    5-6ms latency round-trip.
    5) cisco 2821 router identicle to above
    6) Cisco 3750 "stack" operating as combined MLS core and server
    distribution
    7) HP DL360 dual-core server directly connected to 3750 stack.

    We also have 3 other paths (2x MPLS + 1xVPN) to this site routing via
    iBGP & eBGP. However, we currently have everything forced to route
    through the P2P link to keep it simple while troubleshooting.

    Thanks again for your help.
     
    schulz.brad, Dec 9, 2006
    #5
  6. schulz.brad

    Merv Guest

    Not sure if it is an ARP problem

    in the original post you indicated that
    " After a period of inactivity, the archive client reports a "server
    time-out" error"

    what is the duration of the period of inactivity ?
    is the server configured to disconnect inactive sessions ?
    what is the client application - local app or commercial package ?
    what is the client OS
    what is the client to server transport protocol - TCP ?
    is proxy ARP disabled on the 6500 distribution switch facing the client
    ?
    does the client have the correct defautt gateway AND subnet mask
    configured ?
     
    Merv, Dec 9, 2006
    #6
  7. schulz.brad

    Bod43 Guest

    I regard the ARP "problem" that you (OP) describe as normal behaviour.

    http://support.microsoft.com/kb/194881

    First ping packet loss is to me perfectly normal. I see it every week.

    Any reasonable application will recover from this, and any application
    that uses TCP will recover without needing any work by
    the programmer.

    So, look elsewhere for clues relating to your aplpication's
    failure. I would consider loading Ethereal on
    one end of the transaction and having a look at the traffic.
     
    Bod43, Dec 11, 2006
    #7
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.