Network bridging in Windows Server 2012 killing HP Ethernet Adapter ?

[Server-Support]

Hi People,

Can anyone please help me in troubleshooting the network issue that is currently affecting my HP DL 360p G8 server with 

HP Ethernet 1Gb 4-port 331FLR Adapter which went mysteriously "disconnected" after I accidentally creating network bridging instead of NIC teaming in Windows Server 2012 R2 Std OS ?

Before I install the driver from the HP support portal, the NIC is known as Broadcom in plain WIndows install, and now after I install the driver, it has become the HP Ethernet 1Gb 4-port 331FLR Adapter.

See the attached model.

[Server-Support]

Why is that after selecting the network bridging feature and then reformat the operating system, the network still appears as disconnected in Windows netowrk properties and also on the broadcom utility ?

[waaronb · Accepted solution]

What kind of switch is this server hooked up to? Is it possible that the switch saw a bridge (and thus a possible loop) being created and set those ports admin down?

I'm just imagining it could be related to some STP issues brought about by the accidental creation of a bridge, but that's speculation and really depends on the switch.

If it's not inconvenient, rebooting the switch could help, but if that's not something you can do and it's a managed switch, connect and look at the status of the ports involved.

FYI, these adapters technically *are* broadcom, so on a fresh install from the Windows DVD itself, they'll use generic Broadcom drivers. Upon installing the HP drivers, those INF files have the specific HP model name. In general you'll be better off with the HP specific drivers but as you've seen, the generic Broadcom drivers work just fine too.

And now that Server 2012 has it's own teaming feature, the NCU option is no longer used so you *could* run with the generic drivers and suffer no real loss of functionality, if you really wanted. You'd be missing the reporting through the NIC agents though, if that mattered. Which is why you're generally better off with HP drivers.

[Server-Support]

WaaronB,

Thank you for the reply, maybe that was thecase ? because when i go to Windows Device manager at the OS level and also at the BIOS level, I can see that the NIC ports are all up and running, also from the Broadcom prompt during boot (as can be seen from the screenshot) it is recognizeable.

I was worried that the Windows Server 2012 driver installation could cause this issue same thing like what caused the serious problem with the infamous HP SUM / SPP problem in this blog: http://www.wooditwork.com/2014/04/25/warning-hp-g2-g7-server-nics-killed-firmware-update-hp-spp-2014-02/

[Server-Support]

FYI: the light at the back of the server NICs are all off, eventhough I've changed the ports on the server NIC and also connecting the cable from the patch panel to the other server.

[Server-Support]

Yes, after the port is reopened by the network team, all is good now :-)

[waaronb]

Cool, I'm glad it worked.  If the switch had shut them down or something if it saw a loop, fixing the server configuration and giving the switch time to clear the STP or whatever else it did was probably all it needed to get going again.

I've accidentally created network loops every now and then, and on a less intelligent switch (some old Linksys switches come to mind) it actually brought the whole office network down... no fun.  Cisco switches usually handle it better by finding any loops and will handle things in a way that doesn't flood the whole network with traffic even if it means ignoring particular ports.

Especially if you've modified the switch to tell it certain ports are just computers so that it comes up faster (without doing the CDP phase, if I remember my terminology right... the part where it checks to see if a new connection is a server, router, another switch, etc).  If you disabled that by assigning a specific role, but then it saw traffic from a router or switch, I'm not sure what would happen in that case, but probably nothing good... best case is it *would* shut down the ports until they got reconnected?

[Server-Support]

Yes, that was the case. Thank you for the sharing and the explanation for the behavior of server Network teaming.