Because Cisco networking people always blame Microsoft servers and drivers, and the routers and switch's are never the problem you should know that by now. :-)
Did I forget to mention that I was also told that I should be running Linux since it never has to be rebooted? I also like Unix, but I really like Microsoft's Clustering, and I agree, you would think that failing over the database to the other node and disconnecting the clients for a minute or two would be no big deal, but I basically have to prepare a report similar to an RFC to the Internet Engineering Task Force for review and approval before I can do it? Jose -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Thursday, April 27, 2006 5:57 AM To: [email protected] Subject: Re: [ActiveDir] Is there a way to clear the Netstat -p tcp -s statistics with out rebooting Windows? Jose, can you post the details as to why the network team believes it's a bad driver vs. anything else? Al On 4/26/06, Medeiros, Jose <[EMAIL PROTECTED]> wrote: > Yes, however I am not allowed to show it to any one outside the company > unless they sign a NDA. I stripped out any thing that might be confidential, > in the trace done using our Network general sniffer ( It's in the middle of > this email ). > > Jose > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond > Sent: Wednesday, April 26, 2006 3:07 PM > To: [email protected] > Subject: RE: [ActiveDir] Is there a way to clear the Netstat -p tcp -s > statistics with out rebooting Windows? > > 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˽箊 > .BövrzÊryi > .BövrzÊryi [EMAIL PROTECTED] ��V�r�y�&��-�����4���i�b��b��
