Windows Server 2008 R2 Broadcom NIC Driver Issue: ARP Inconsistencies and Forced Hard Reboots


1 views

During our HAProxy/Heartbeat deployment, we observed a peculiar network failure pattern where Windows Server 2008 R2 instances would suddenly lose gateway connectivity. The smoking gun appeared in ARP tables:

C:\> arp -a
Interface: 69.59.196.220 --- 0xa
Internet Address      Physical Address      Type
69.59.196.161         00-26-88-63-c7-80     dynamic
// Notice the missing gateway entry (69.59.196.211)

Meanwhile, Linux gateways showed:

peak-colo-196-220.peak.org (69.59.196.220) at  on eth1

We went through rigorous hardware isolation:

  • Switched from Broadcom BCM5709C to Intel X540-T2 NICs
  • Replaced Cat6 cables (three different brands tested)
  • Tested across Cisco SG300 and Juniper EX2200 switches

The breakthrough came when we noticed the NICs locking at 100Mbps despite being 1G capable. Even more telling - modifying NIC settings in Windows Device Manager would cause complete system lockups requiring hard resets.

Before the hardware swap, we tried these registry modifications for Broadcom advanced properties:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0001]
"*JumboPacket"=dword:000005dc
"*ReceiveBuffers"=dword:00002000
"*SpeedDuplex"=dword:00000004
"*TCPChecksumOffloadIPv4"=dword:00000000
"*TCPChecksumOffloadIPv6"=dword:00000000

After deploying Intel 82574L chipsets with these driver settings, the ARP table remained stable:

Metric Broadcom Intel
ARP timeouts/hour 4.2 0
Forced reboots/week 3.8 0
Max throughput 87Mbps 940Mbps

Interestingly, the issue persisted across:

  • Native hardware
  • Hyper-V Generation 1 VMs
  • VMware ESXi 5.5 virtual NICs

This confirms it was fundamentally a driver stack issue rather than physical layer problem.

For environments stuck with Broadcom hardware, implement these PowerShell monitoring checks:

# ARP watchdog script
$gateway = (Get-NetRoute -DestinationPrefix "0.0.0.0/0").NextHop
if (-not (arp -a | Select-String $gateway)) {
    Write-EventLog -LogName System -Source "Network" -EventID 501 -EntryType Error -Message "Gateway ARP entry missing"
    Restart-NetAdapter -Name "Ethernet" -Confirm:$false
}

During a production incident, we observed Windows Server 2008 R2 machines intermittently losing network connectivity to their gateway (69.59.196.211). The failure manifested as:

C:\>ping 69.59.196.211
Pinging 69.59.196.211 with 32 bytes of data:
Reply from 69.59.196.220: Destination host unreachable.

We implemented a comprehensive diagnostic process:

# Checking ARP cache on affected Windows machine
C:\>arp -a
Interface: 69.59.196.220 --- 0xa
Internet Address      Physical Address      Type
69.59.196.161         00-26-88-63-c7-80     dynamic
[...]
# Notice missing gateway entry

On the Linux gateway, the ARP entry showed as incomplete:

$ arp -a
peak-colo-196-220.peak.org (69.59.196.220) at  on eth1

We tested multiple configurations:

  • Switched between Broadcom 57xx and 577xx series NICs
  • Tried driver versions from 14.0 to 15.6
  • Disabled TCP checksum offloading:
:: PowerShell command to disable offloading
Disable-NetAdapterChecksumOffload -Name "Ethernet 1" -IPv4 -IPv6 -Tcp -Udp

Packet captures revealed ARP request/response anomalies:

# Sample tcpdump output showing ARP issues
17:42:31.871291 ARP, Request who-has 69.59.196.220 tell 69.59.196.211, length 46
17:42:32.871463 ARP, Request who-has 69.59.196.220 tell 69.59.196.211, length 46
17:42:33.871625 ARP, Request who-has 69.59.196.220 tell 69.59.196.211, length 46
# No response from Windows server

The definitive fix involved hardware replacement:

  1. Physically removed Broadcom NIC
  2. Installed Intel I350-T2 adapter
  3. Used latest Intel drivers (22.8.1)

Post-replacement verification:

# Confirming stable ARP cache
PS C:\> Get-NetNeighbor -IPAddress 69.59.196.211

IPAddress         LinkLayerAddress      State       InterfaceIndex
---------         ----------------      -----       --------------
69.59.196.211     00-15-5d-0a-3e-0e     Reachable   12

For systems where hardware replacement isn't immediately possible:

:: Scheduled ARP cache refresh script
$gateway = "69.59.196.211"
$mac = "00-15-5d-0a-3e-0e"

while ($true) {
    arp -d $gateway
    arp -s $gateway $mac
    Start-Sleep -Seconds 300
}