ProLiant Servers (ML,DL,SL)
cancel
Showing results for 
Search instead for 
Did you mean: 

Beware of NC31xx NICs

 
Ayman Altounji
Valued Contributor

Beware of NC31xx NICs

Greetings,
This is not the first time I've posted about this subject, but Compaq doesn't seem to believe what I'm saying.. Anyway, I've supported a large Windows Terminal Server/Citrix Metaframe environment on Proliant servers for almost 2 years. All told I've supported NT on Proliant for 5 years. We have Terminal Server running on Proliant 2500, 1600, 6400R, 6500 and DL360's. This server farm serves application across a frame relay WAN to sites across the US.

Ever since we introduced our first 6500 a year and a half ago we've had problems with servers freezing (can't logon, must power cycle) after a WAN outage (common occurence in frame relay networks). After a lot of grey hair and lab testing we found several key contributors to this problem.

Routing protocol. OSPF was our original routing protocol. In the lab environment, we were always able to replicate the server freeze up with this protocol regardless of how the NIC was configured. When we tested using EIGRP routing protocol, we saw a significant dropoff in freeze ups. Note that we configured the NIC (all of them dual port NC3131 or NC3163) for single port, falt tolerant, load balanced and Fast Etherchannel (FEC). The most stable configuration that we found was single port with known EIGRP across the network. We were able to run for a number of months configured for FEC without any problems. We had to make some changes to support a customer through a different network and low and behold, the problems came back. We moved the NIC's back to single port, but still we had the problems.

NC31xx chipset. We have several servers configured with the older Netelligent/Netflex chipset that have NEVER had a server freeze up all the time being exposed to the same network. We've even gone to the point of disabling the onboard NICs in DL360's and configuring one of these older NIC's so that we can sleep at night.

We have the latest Compaq NIC drivers installed on all of our servers. We run Service Pack 5 currently (please don't give me the "you're not on the latest service pack" excuse).

There is truly a problem with this chipset. I don't think Compaq is going to agree with me, but I've got the grey hair to prove it.

Thanks for listening,
Ron
4 REPLIES
Ayman Altounji
Valued Contributor

Re: Beware of NC31xx NICs

Well - having not dealt with that type of configuration I can not say one way or the other. Out of curiousity, have you tried a pure Intel card (as they are the source for the chipset on all of those NC cards)?

Have you tried calling this into support for possible escalation? We do have a dedicated networking support group on the phones but, I don't know where you are (1-800-652-6672 in the US/Canada).
Ayman Altounji
Valued Contributor

Re: Beware of NC31xx NICs

You are not alone. We've had similar problems with the latest DL360, and ML370 servers with the NC3131/63 cards. Running in Smartswitch or load balancing mode, we'd get communication problems between servers in the same subnet! They couldn't ping eachother, but everything outside could ping them! Take the teaming out and run with a single card and everything works fine. This is really irritating, and the network guys don't appreciate being blamed for dodgy Cisco Switches etc. - which of course isn't the case.
Ayman Altounji
Valued Contributor

Re: Beware of NC31xx NICs

Is anyone from Compaq going to investigate this further as there are numerous postings now with people having problems teaming /or as above with these NICS. So far the answers just aren't satisfactory!
Ayman Altounji
Valued Contributor

Re: Beware of NC31xx NICs

I've had similar problems when teaming a pair of NC6134 (fiber) for load balancing. The server just blue screened on me during bootup. I had to remove both NICs and break the team in order to recover.