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:[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
