[kevin creason <ckevinj@xxxxxxxxx>]

Martin has a very good point with localhost and os misconfig: I saw no
ip6. Did you exclude it from the capture or turn it off on the host? I
heard recently from a friend that disabling ip6 on 2008 creates issues
with name resolution so that would be something to research. Please
post your findings...

On Sunday, May 30, 2010, Martin Visser <martinvisser99@xxxxxxxxx> wrote:
> Switches do not hold onto packets for 4 seconds. They either forward them within milliseconds or drop them in the event of congestion. (They may have queues but they would not extend to more than a few megabytes of packets, and hence are very quickly emptied into the output interface - you would have evidence of congestion (fully saturated bandwidth) on the ingress or egress interface if this were occuring).
>
>
> I would interpret those delays as there being nothing for the client to send, or it is waiting for some ACKnowledgement from the other end, or a timer (for say a unanswered DNS or name lookup) has expired. It is possible that the first was sent but because of errors was dropped silently. If you are getting packet loss because of errors, this would show up in the device port statistics. Duplex issues can cause similar problems, but not likely to see seconds of delay. Also you would expect to see collision errors on the interface configured as half-duplex if that is the case (usually also best seen in the port statistics on the device).
>
>
> The fact that 172.18.100.18 is doing a Netbios Name Service broadcast query for a loopback (127.0.0.1) based service already worries me that you have a misconfiguration or non-answering name service. So you may have an application or OS config issue.
>
> Regards, Martin
>
> MartinVisser99@xxxxxxxxx
>
>
>
> On Fri, May 28, 2010 at 1:26 AM, Eddie Grogan <eddiegrogan@xxxxxxxxxxxxxx> wrote:
>
> Hello,
>
> I am running traffic between a Windows 2008 server and switch (via a router). While traffic will run perfectly for days, we occasionally see small delays on the network which bring down our software. Typically, we might see a couple of blockages of aprox 5 seconds in duration. We have only starting seeing these problems since we moved to Windows 2008. On Window 2003, everything worked perfectly. Now, I am not sure if this is a problem with the OS or perhaps some type of OS incompatibility issue with our hardware.
>
>
> Here is a quick snippet of where things start to wrong in our logs.
> 16223   0.000456           172.18.100.18    172.18.100.15    TCP      49235 > ddi-tcp-1 [PSH, ACK] Seq=535013 Ack=4164690 Win=253 Len=646
>
> 16224   0.099948           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [ACK] Seq=4164690 Ack=535659 Win=16738 Len=0
>
> 16225   1.179883           172.18.100.15    172.18.100.18    ICMP    Echo (ping) request
> 16226   0.000709           172.18.100.18    172.18.100.15    ICMP    Echo (ping) reply
> 16227   3.052179           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [PSH, ACK] Seq=4164690 Ack=535659 Win=16738 Len=492
>
> 16228   0.019502           172.18.100.18    172.18.100.15    TCP      49235 > ddi-tcp-1 [PSH, ACK] Seq=535659 Ack=4165182 Win=251 Len=32
>
> 16229   0.047537           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [ACK] Seq=4165182 Ack=535691 Win=16706 Len=0
>
> 16230   0.000332           172.18.100.18    172.18.100.15    TCP      49235 > ddi-tcp-1 [PSH, ACK] Seq=535691 Ack=4165182 Win=251 Len=64
>
> 16231   0.099530           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [ACK] Seq=4165182 Ack=535755 Win=16642 Len=0
>
> 16232   1.393205           172.18.100.18    172.18.100.15    TCP      49235 > ddi-tcp-1 [PSH, ACK] Seq=535755 Ack=4165182 Win=251 Len=34
>
> 16233   0.006954           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [ACK] Seq=4165182 Ack=535789 Win=16608 Len=0
>
> Note:  Our switch will ping the server every 6 seconds.
>
> In general, we would not expect to see any communication delays between then switch and the server. The max response time is aprox 300ms but generally response time is much lower.  But at frame 16227, we see that it takes almost 4.2 seconds (3.05 + 1.17) for the switch to send out the next packet. I think this  is interesting because in between the switch was able to ping the server without any delays which suggests to me that the network is still healthy. At frame 16232, we see that the server takes 1.4 seconds to respond to the previous packet (i.e. ACK).
>
>
> A little later in the logs, we see even more delays, only this time they are all originating on the switch side:
> 16293   0.099612           172.18.100.15    172.18.100.18    TCP      ddi-tcp-1 > 49235 [ACK] Seq=4208432 Ack=535915 Win=17491 Len=0
>
> 16294   0.379674           172.18.100.15    172.18.100.18    ICMP    Echo (ping) request___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
>

-- 
-Kevin
/*“ I am looking for a lot of men who have an infinite capacity to not
know what can't be done. ” -- Henry Ford  */