rsfeller

I've got a win2k server sp 4 with the latest and greatest updates running on a older Dell twin P3. Has been running well but as of late there have been a few hickups I cannot pin down. Only THIS server shows these results.

Anyways in my research I've determined that the system now has crazy ping results as shown below. This occurs inside and outside the network and I am showing know signs of latency on the LAN or WAN, what causes these crazy results even after reboots?

Reply from 12.168.32.116: bytes=32 time=3373190ms TTL=114
Reply from 12.168.32.116: bytes=32 time=61ms TTL=114
Reply from 12.168.32.116: bytes=32 time=80ms TTL=114
Reply from 12.168.32.116: bytes=32 time=77ms TTL=114
Reply from 12.168.32.116: bytes=32 time=80ms TTL=114
Reply from 12.168.32.116: bytes=32 time=-3374391ms TTL=114
Reply from 12.168.32.116: bytes=32 time=3374547ms TTL=114
Reply from 12.168.32.116: bytes=32 time=-3374431ms TTL=114
Reply from 12.168.32.116: bytes=32 time=-3374452ms TTL=114
Reply from 12.168.32.116: bytes=32 time=3374622ms TTL=114
Reply from 12.168.32.116: bytes=32 time=-3374504ms TTL=114
Reply from 12.168.32.116: bytes=32 time=57ms TTL=114
Reply from 12.168.32.116: bytes=32 time=77ms TTL=114
Reply from 12.168.32.116: bytes=32 time=57ms TTL=114
Reply from 12.168.32.116: bytes=32 time=83ms TTL=114
Reply from 12.168.32.116: bytes=32 time=3376040ms TTL=114
Reply from 12.168.32.116: bytes=32 time=78ms
Ping statistics for 12.168.32.116:
Packets: Sent = 134, Received = 133, Lost = 1 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 56ms, Maximum = -3352557ms, Average = 31324048ms

Thanks!

Cellus

That is an incredibly perplexing ping test. Having negative latency is not possible.

What happens when you try pinging the loopback address (127.0.0.1)? If you're getting the same result then there is definitely something wrong with the NIC.

rsfeller

Thanks for the quick response. I have read very useless info on negative latency numbers before. Theories have included voltage issues to battery/clock concerns.

Pinging to 127.0.0.1 produces the same results. Does the loopback address bypass the NIC? as I like your funky NIC idea.

I've had two bluescreen in the last 30 days and that is the first ones I"ve had in 5 years this server has been running for me. I do recall replacing a NIC several years ago for some reason. The only other "odd" symptom I've been trying to figure out is the LSASS.EXE process (for AD) has maxed out the CPU on two occasions thus causing clients to not be able to access shared resources on the server.

Shawn

Cellus

I would definitely re-install the NIC drivers first and see if that solves it - if not I would recommend replacing the NIC.

One of the major uses for the loopback address is to diagnose problems with the NIC itself. Anything you do through the NIC using the address will go down the network stack but will never actually leave the computer. The fact that the problem persists while using the loopback address proves that it's not something to do with your network but with the NIC or system.

lsass.exe is the "Local Security Authentication Service" which basically handles local logins and security. It is possible that the CPU usage is due to a Denial of Service attack (either malevolent or even accidental) - check your event log for any discrepencies during those times. Either someone may be trying to break in, or the system is handling too many requests simultaneously from legitimate users.

And as always, make sure you have the latest patches.

rsfeller

Will swap card this week to check.

I doubt any DOS attacks on that machine as it's not our web/mail server and is behind one serious firewall. I did check info on DOS and Sasser and nothing points to that direction. The reading I did on LSASS.exe did mention the over use of siultanious legit users but our system is almost a ghost town the weekends. So I am scratching my head on that one.

I'll check for DOS attacks from within our network and make a client is causing the issues.

Thanks.

Cellus

No problem. I look forward to seeing what you find out.

rsfeller

We'll the NIC theory didn't pan out. We tried two differnt NICs and still got long and even negative ping values...although differnt numbers on average!

The only other theory is that something may be out of sync with the two processesors (intel P3 500). There have been threads around about AMD duel cores showing this issue if improper drivers are loaded. Someone else suggested it has to be a clock issue and most likly always exsisted after installing the 2nd processor three years ago. I doubt I wouldn't have noticed the funky ping numbers for three years till this month!

Any other theories of things that are testable would be appricated!

Shawn

Bayangan

I cannot consider about the NIC (after you said that you have tried 2 NIC).
Could you have might be miss checked the slot? I think the slot could be a problem(either dirty or shortcircuited).
I never actually have negative ping result. Usually only flat RTO result.

rsfeller

should have included the info but we tried the 2nd card in a completely different slot!

rsfeller

A piece of additional info!

I ran a report on this system and although I'm running twin P3 450mhz processors the report software says I'm running 2833 Megahertz P3!

I don't know much but this sound slike a clock issue!

DaMCT

Interesting reading here. I would try flashing the bios on the server as well as ensuring that you have the latest drivers for the NIC. Next instead of using the regular "ping" command I would try using "pathping".

pathping ipaddress

Pathping is "ping" on steroids. I haven't used ping in a long long time because pathping is more reliable.

Syntax
PATHPING [-n] [-h max_hops] [-g host_list] [-p period]
[-q num_queries] [-w timeout] [-t] [-R] [-r] target_name

Key
-n Don't resolve addresses to hostnames
-h max_hops Max number of hops to search, default=30
-g host_list Loose source route along host-list
up to 9 hosts in dotted decimal notation, separated by
spaces.
-p period Wait between pings, default=250 (milliseconds)
-q num_queries Number of queries per hop, default=100
-w timeout Wait timeout for each reply, default is 3000 (milliseconds)
-T Test each hop with Layer-2 priority tags (QoS
connectivity)
-R Test if each hop is Resource Reservation Protocol (RSVP)
aware

All parameters are Case-Sensitive

Pathping is invaluable for determining which routers or subnets may be having network problems - it displays the degree of packet loss at any given router or link.

Pathping sends multiple Echo Request messages to each router between a source and destination over a period of time and computes aggregate results based on the packets returned from each router.

Pathping performs the equivalent of the tracert command by identifying which routers are on the path.

To avoid network congestion and to minimize the effect of burst losses, pings should be sent at a sufficiently slow pace (not too frequently.)

When -p is specified, pings are sent individually to each intermediate hop. When -w is specified, multiple pings can be sent in parallel. It's therefore possible to choose a Timeout parameter that is less than the wait Period * Number of hops.

Firewalls
Like tracert PathPing uses Internet Control Message Protocol (ICMP) over TCP/IP. Many firewalls will block ICMP traffic by default. If an attacker is able to forge ICMP redirect packets, he or she can alter the routing tables on the host and possibly subvert the security of the host by causing traffic to flow via a path you didn't intend.

Fr4665

first take a screenshot of ur 2.8ghz p3 cause i dont think that exists yet.
second i had this problem on a amd athlon server and noticed that the clock speed of the cpu was totaly off like sometimes not even showing and msometimes showing like 5 ghz ...

i solved this by reseating the cpu and reinstalling windows 2k server and replacing the nic. so i just did everything at once but try maybe reseating the cpu or reinstalling server if u can. not sure what caused my error but thats how i fixed it.

rsfeller

thanks for the comments.

The AMD issue is a well document issue related to improper drivers for the motherboard or CPU. Seen quite a bit on that over the next but nothing related to Intel processors and long ping results.

Since this is a mission critical server and there are no major issues (yet) I doubt I'm going to flash the bios or reinstall the OS from scratch. It's a 10 year old Dell and the last one we flashed (SCSI bios on a exchange server) didn't recover, so I'm not going to to take that chance.

I've had three NICs tested (two intel) and one (off brand) with new drivers included the latest from MS update. Other then OS service packs nothing has changed on this system, so I'm guessing my issue is hardware. I will try to reseat the processors next chance I get.

Lastly, I did try the pathping command and got the same results of long pings and no packet loss.

DaMCT

Replace the cable with a new one. We are using the OSI Model to solve the problem here.

rsfeller

Not a trained tech so I need some more clarification.

Which cable? The cat5?
OSI model?

that last one could be funny, I"m guessing!

Cellus

CAT5e or above is most likely the kind you are using - read the specification on the cable's sheath to double-check.

The OSI Model is a guideline that easily defines how networking works by using a "stacked" model, separating different aspects of the communication process by separating them into seven layers (Physical to Application layer). If you ever heard of a router being called a "Layer 3 Device", that's where it comes from. DaMCT is simply trying to break up the problem to make it easier to deal with. You can find out more information about the OSI Model by using your friendly neighbourhood Wikipedia, or any networking book worth its salt.

By the way, I would also check the NIC's configuration and see if it could be a problem with them due to offloading. Those added functionalities are, while useful, can on some occasions mess things up if they don't work properly or play nice.

rsfeller

regardless of if it's cat5 or cat5e we swapped the cable with the same results. Again remember from reading the original posts on this topic that the issue (wrong ping times) occured even when the loop back was pinged and nothing has changed in the hardware of the system.

Nothing in the NIC config has changed and the new card doesn't mention OFFLOADING in the advanced config area. This is a simple data server.

I really don't see how the OSI model for troubleshooting has anything to do with this when the ping errors are replicated with the loopback. Either I'm not understanding something or you guys are going off the deep end and being to obstract with recommendations. Best I can tell is saying "use the OSI model" is like stating to use logic and common sense to remove varibles to the anomoly.

Mixmaster

Ran a virus scan lately? You might have a memory residential.

rsfeller

It has 100% updates from Symantec Corporate and a very impressive Astero Firewall (great as a virus filters). So doubt that is an issue.

Can you provide any information on how a memory resident virus affects clock speeds or ping results? I cannot google anything related on those topics.

Cellus

Some older viruses screwed up with timing, but I seriously doubt you have one of those. For one it would affect your entire system, not just your ping results.

Offloading just means the NIC card is doing some of the processing without getting the CPU to do it. As for the OSI Model it is just that, a model. It can on occasion be useful for breaking down tricky networking questions. Knowing, for example, that there are no problems with the cabling means there is no problem with the Physical Layer. This means one of the seven layers is just fine right off the bat. And so on and so forth...

Anyways this problem is unusual. It could be a problem with how the ping utility works with those two processors (you were getting strange reports on the CPUs), the clock, etc. The important question to ask is, does this adversely affect the performance of your server or your network? Is the latency issue due to a problem relating to this, or something else?