Re: Traffic problems under Window 2008

[Eddie Grogan <eddiegrogan () googlemail com>]

Hi Kevin,

Yes, IP6 is disabled on our server. But since we don't use NetBIOS I
am not sure if this is significant.

Thanks
Eddie

On Mon, May 31, 2010 at 2:23 PM, kevin creason <ckevinj () gmail com> wrote:
> 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 () gmail com> 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 () gmail com
> >
> >
> >
> > On Fri, May 28, 2010 at 1:26 AM, Eddie Grogan <eddiegrogan () googlemail com> 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 () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org?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  */
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe