Dual NIC Network Drop outs

[goal]

On a particular machine I have XP Pro operating with dual on-board nic's, one listens on a real world IP address (nic #1) and one listens on a private network address (nic #2).

Randomly, but frequently, I'm getting drop outs of connectivity on the real world nic (#1) lasting anything from a second to 20-30 seconds, when connectivity does come back, there is a huge latency spike - then it settles down. The local network nic (#2) remains with full connectivity during this. The problem only occurs when both nic's are enabled. The real world nic works flawlessly on it's own. However.. If I have both nic's enabled and the problem occurs, then I disable the internal nic (#2) the problem does not go away until I clear the routing table (route -f) and disable/re-enable the real world nic (#1) to get it's default routes back into the table. The default gateway showing in the routing table is always the correct one for the real world nic, this never changes. There are no persistent routes defined.

Both nic's have the appropriate netmasks and gateways set.

What I have done: Reinstalled both nic's. Set the provider preference order in network connections>advanced>advanced settings. I have set metric's appropriately on the nic's to indicate that the real world nic (#1) should have priority.

I am completely at a loss with this and it's about to drive me insane, so I can't over estimate how appreciated any help you can offer would be.

Some additional info:

board is Asus A7N8X-E Deluxe
nic #1 is Marvell Yukon GigE
nic #2 is Nvidia 10/100
running the latest drivers for both nic's

An example showing ping responses when this occurs:

Reply from xx.xx.xx.206: bytes=32 time<1ms TTL=64
Timestamp: xx.xx.xx.206 : 32555812
Reply from xx.xx.xx.206: bytes=32 time<1ms TTL=64
Timestamp: xx.xx.xx.206 : 32556812
Reply from xx.xx.xx.206: bytes=32 time<1ms TTL=64
Timestamp: xx.xx.xx.206 : 32557804
Request timed out.
Request timed out.
Reply from xx.xx.xx.206: bytes=32 time=1338ms TTL=64
Timestamp: xx.xx.xx.206 : 32569425
Reply from xx.xx.xx.206: bytes=32 time=1410ms TTL=64
Timestamp: xx.xx.xx.206 : 32570765
Reply from xx.xx.xx.206: bytes=32 time=3304ms TTL=64
Timestamp: xx.xx.xx.206 : 32572176
Reply from xx.xx.xx.206: bytes=32 time=863ms TTL=64
Timestamp: xx.xx.xx.206 : 32575483
Reply from xx.xx.xx.206: bytes=32 time=2169ms TTL=64
Timestamp: xx.xx.xx.206 : 32576482
Reply from xx.xx.xx.206: bytes=32 time=201ms TTL=64
Timestamp: xx.xx.xx.206 : 32578653

 

[bcastner]

If you have Service Pack 2 installed, disable DPE.

 

[tf1]

You seem to have pretty much checked everything you can. Only thing I would check is the Hosts file to make sure there's nothing in there (unlikely); otherwise it must be a conflict with those particular NICs. Maybe replacing them with a dual NIC card is the best answer. At least that won't conflict!

Regards: tf1

 

[goal]

No service pack 2.

Nothing in the hosts file to cause this unfortunately.

I seriously can't imagine this would be a conflict between the NIC's. This motherboard won mobo of the year last year I believe, there's an awful lot of them in use (including some people I've recommended it to) who have no such problems at all. So I can only conclude it's either a dodgy mobo (which I don't see how it can be, they work fine on their own) or it's some stupid idiosyncrasy of windows (my money is heavily on the latter).

Since I wrote the original messages I've been playing some more. There are no events relating to this in any of the windows event logs. When I disable nic #2 after the problem occurs, it STILL occurs with only nic #1 enabled, this is until I 'route -f' and disable/re-enable nic #1 (as I said above). I tried just 'route -f' then re-inserting the default routes manually - it didn't help. I then 'route -f' and disabled/re-enabled nic #1 - and it STILL didn't help. So currently I'm not able to prevent the problem from occuring at all.. looks like a reboot will be needed

Thanks for your replies folks - anyone have any more suggestions?

(forgot to mention - nothing in the event logs).

 

[bcastner]

Can you identify the NIC chipset manufacturer? All I see from a casual look is NVIDIA.

If the ethernet part is OEM'ed from RealTek or AMD or someone else, use their drivers. I have had much better luck going to the source than using the motherboard OEM or the Windows Update driver sets.

If it was my box, I would disable both onboard NICs, and replace them with Intel or 3Com add-in boards.

 

[goal]

I believe Nvidia make the nic's - it's all part of their nForce2 Chipset. It uses the unified nForce driver.

I am on the verge of replacing the nic's with add-in cards, but I still seem to think this is windows related and I'll get the same problem with PCI cards.

 

[bcastner]

Make the registry changes suggested here:

http://support.microsoft.com/?kbid=315237

 

[schnook9]

Howdy,

Has there been a resolution to this thread?

We have seen the exact same symptoms on our server running win2k adv. server but I have yet to figure out what is causing it.

The server has two built-in nics also, but in our case they are Intel. The problem in our case seems to be that the default gateway in the routing table switches from our private lan to the public one. When it is set to the private lan gateway, you can still connect to the server, but making connections out of it are spotty at best. This does not always happen however. This is an occasional occurence. If we reset our private lan nic, everything is usually fine at least for a week or so.

Additionally, we have tried opening a web browser, waiting for it to try to connect, close it, and then open another and it connects right away. This works to fix the problem 50% of the time.

It almost looks like there is some process that attempts to connect on the private lan, and then some process requires the network for something else so it wrenches control of everything over to the other nic.

If anyone has figured anything out on this, would love to know what to do. thanks!

 

[goal]

Sadly not. I gave up on the situation.