Do you have an ethereal trace showing TCP issues? Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Medeiros, Jose > Sent: Wednesday, April 26, 2006 5:04 PM > To: [email protected] > Subject: RE: [ActiveDir] Is there a way to clear the Netstat -p tcp -s > statistics with out rebooting Windows? > > I could not agree with you more, and I am not trying to undermine > Microsoft servers, however I am expected to solve this issue, and in > order to reboot, I am required to gather data to justify why it is > needed. > > I've already ran netstat -s, winmsd, srvinfo, netdiag, and the server > has been up about 130 days, however I can not provide the data that > they want to see that can determine why I need to reboot. > ------------------------------------------------------- > C:\Documents and Settings\Administrator>netstat -s > > IPv4 Statistics > > Packets Received = 1646459205 > Received Header Errors = 0 > Received Address Errors = 116182 > Datagrams Forwarded = 0 > Unknown Protocols Received = 0 > Received Packets Discarded = 0 > Received Packets Delivered = 1646342944 > Output Requests = 1932332448 > Routing Discards = 0 > Discarded Output Packets = 0 > Output Packet No Route = 0 > Reassembly Required = 162 > Reassembly Successful = 81 > Reassembly Failures = 0 > Datagrams Successfully Fragmented = 96 > Datagrams Failing Fragmentation = 0 > Fragments Created = 206 > > ICMPv4 Statistics > > Received Sent > Messages 139403 146858 > Errors 0 0 > Destination Unreachable 268 7708 > Time Exceeded 0 0 > Parameter Problems 0 0 > Source Quenches 0 0 > Redirects 0 0 > Echos 93318 45832 > Echo Replies 45816 93318 > Timestamps 0 0 > Timestamp Replies 0 0 > Address Masks 0 0 > Address Mask Replies 0 0 > > TCP Statistics for IPv4 > > Active Opens = 518972 > Passive Opens = 9060910 > Failed Connection Attempts = 32498 > Reset Connections = 58588 > Current Connections = 22 > Segments Received = 1561177256 > Segments Sent = 1850738357 > Segments Retransmitted = 4936519 > > UDP Statistics for IPv4 > > Datagrams Received = 81338321 > No Ports = 22057795 > Receive Errors = 0 > Datagrams Sent = 76769367 > > ------------------------------------------------------------- > > Summary Format - Seems to also be having TCP/Ip out of sequence timing > issue's. > > > > Frame Status Source Destination Summary > Bytes > Delta Time Abs time > 4967 *******grp *****p01 TCP: D=1331 S=1435 ACK=1695680221 > SEQ=2840954384 LEN=22 WIN=16405 > 76 0.000.166 4/24/2006 9:15:42 AM > 4968 *****p01 *****Clusternode TCP: D=1435 S=1331 > ACK=2840954406 SEQ=1695680221 LEN=68 WIN=16210 > 122 0.000.282 4/24/2006 9:15:42 AM > 4969 *****Clusternode *****p01 TCP: D=1331 S=1435 > ACK=1695680289 SEQ=2840954406 LEN=35 WIN=16337 > 89 0.000.608 4/24/2006 9:15:42 AM > 4970 # *****p01 *****Clusternode Expert: Ack Too LongTCP: D=1435 > S=1331 ACK=2840954441 WIN=16175 > 60 0.192.663 4/24/2006 9:15:42 AM ß----- Next Sequence being > requested is 1695680289 (please see detail format) > > 4971 # 8********App01 *****Clusternode Expert: Window FrozenTCP: > D=1435 S=1331 ACK=2840954441 SEQ=1695680288 LEN=1 WIN=16175 ß----- > Next Sequence being requested is 1695680289 (please see detail format) > 60 29.952.657 4/24/2006 9:16:12 AM > 4972 # *****Clusternode *****p01 Expert: Window FrozenTCP: D=1331 > S=1435 ACK=1695680289 WIN=16337 > 60 0.000.052 4/24/2006 9:16:12 AM > 4973 # *****p01 *****Clusternode Expert: Window FrozenTCP: D=1435 > S=1331 ACK=2840954441 SEQ=1695680288 LEN=1 WIN=16175 > 60 30.202.584 4/24/2006 9:16:42 AM > 4974 # *****Clusternode *****p01 Expert: Window FrozenTCP: D=1331 > S=1435 ACK=1695680289 WIN=16337 > 60 0.000.061 4/24/2006 9:16:42 AM > > > > ----------------------------------------------------------------------- > ----- > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:ActiveDir- > [EMAIL PROTECTED] On Behalf Of Al Mulnick > Sent: Wednesday, April 26, 2006 1:41 PM > To: [email protected] > Subject: Re: [ActiveDir] Is there a way to clear the Netstat -p tcp -s > statistics with out rebooting Windows? > > Jose, now might be a good time to rethink that idea of rebooting. > I've personally been responsible for systems that stay up and running > (when left alone) for years at a time. Used to laugh that the servers > and applications had better uptime than the telephones. > > Regular reboots is something that started in 3.51 when memory > management needed additional help and applications didn't behave nearly > as well. Since then, the OS has become more agressive about protecting > itself from such applications and the issues caused by them. > > Being able to stop or restart a network interface is something you > should plan for. Why? Because the hardware can fail and you may need > to update it. As for software installation, the world around you > changes. For example, VMS goes away ;) That implies that you should > try to somewhat keep up with the world around you to at least be a part > of it. (by you, I refer to the computing platform including layers 8-9 > of the stack). There are many times that a solution that's running > fine is impacted by something new. That requires changes. > Morale: you should plan for downtime on a periodic basis and if you > want high availability on a cheap(er) platform (side note: it's cheap > because of how many variables there are; you can literally build > thousands of combinations of hardware and expect it to be supported vs. > the model of fewer variable but higher cost machines i.e. vax hosts or > Apple Macs, etc. They're not made of as many variable parts that a > Windows machine can be composed of. Generally, the more variables, the > more likely something might not work - Microsoft does a good job of > reducing that problem impact by abstracting the hardware complexities > from you) you need to act like the big iron planners and spend the time > planning it for high availability. That often adds a lot of overhead > to the deployment and aquisition process and is often overlooked, but > truthfully, the processes and architecture of your deployment will make > all the difference. Since you have the proven processes, it only > remains to spend the investment on planning. > > My $0.04 worth. I'm not trying to harp, but to point out that > rebooting weekly/daily/monthly or any regularly scheduled basis is > actually not a "normal" process of ownership when it comes to Microsoft > platforms. There are actually some deterrents to doing that as you wait > for that server to normalize again. If you have issues that cause you > to want to reboot, it's not normal and should be addressed. > > Al > > P.S. that might have been closer to $0.05 worth as I've rambled longer > than normal :) > > On 4/26/06, Medeiros, Jose <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi Brian, > > > > > > > > Thank you for the reply. Unfortunately, these are production database > > clusters and I do not have the luxury of disabling and re-enabling > the > > Nic interface on the servers. Also the standard Support Pak that we > > use is 7.2, and I am not allowed to install the latest and greatest > > drivers, and or patch's on existing servers (However our new builds > > are now using HP Support Pak 7.4). It seems that some one at > > Microsoft's marketing and Sales department told the managers here at > > Intel that the servers can stay up for over a year with out requiring > > a reboot ( We are only allowed to power down the servers once a year > > during new years eve during our site power shutdown ). > > > > > > > > The management here also seems to think that it's okay to push out > MOM > > server monitoring agents & other patch's with out a reboot, or having > > them affect the existing applications such as Oracle and other third > > party applications installed. > > > > ( These systems are replacing our VAX and VMS systems and are > expected > > to have the same uptime ) > > > > > > > > I have been working with NT server since NT 3.51 and have always > found > > that it best to reboot a server every few weeks to clear hung DLL's > > and Memory leaks that may be occurring. > > > > > > > > > > > > But thank you so much for your suggestion, I could not agree with you > more. > > > > > > > > > > > > Jose J > > > > > > > > > > ________________________________ > > > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brian > Desmond > > Sent: Tuesday, April 25, 2006 6:59 PM > > > > To: [email protected] > > Subject: RE: [ActiveDir] Is there a way to clear the Netstat -p tcp - > s > > statistics with out rebooting Windows? > > > > > > To: [email protected] > > Subject: RE: [ActiveDir] Is there a way to clear the Netstat -p tcp - > s > > statistics with out rebooting Windows? > > > > > > > > > > > > Have you tried disabling and reenabling the interface? > > > > > > > > You could also upgrade to the 7.4 support pak and see what happens? > > I'm running 7.3 and 7.4 heavily in production… > > > > > > > > > > Thanks, > > Brian Desmond > > > > [EMAIL PROTECTED] > > > > > > > > c - 312.731.3132 > > > > > > > > > > > > ________________________________ > > > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Medeiros, > > Jose > > Sent: Tuesday, April 25, 2006 6:03 PM > > To: [email protected] > > Subject: [ActiveDir] Is there a way to clear the Netstat -p tcp -s > > statistics with out rebooting Windows? > > > > > > > > Greetings fellow AD Guru's, > > > > I have been trying to trouble shoot some intermittent network > > connectivity issues with our Active Directory domain controllers and > > our SQL database clusters, our network group doing the network packet > > capture, believe that our HP Proliant Dl-380 G3 servers using HP > > support pak 7.2 on 2003 server have a bad network driver. > > > > Is there a way to clear the Netstat -p tcp -s statistics with out > > rebooting a Windows 2003 server? > > > > > > > > Sincerely, > > > > Jose Medeiros > > > > MCP+I, MCSE, NT4 MCT > > > > 408-765-0437 Direct > > > > 408-449-6621 Cell > > > > > > > .BövrzÊryi > .+w֧B+v*rz Vryi˽箊
