vCenter raises an uplink redundancy alarm, and one physical port (vmnic) on the host shows down. A down port alone does not say why. When the host logs "Taking down physical NIC vmnic## because the link is flapping." and the port reports "Down by linkflapping", ESXi switched it off itself because the link kept dropping and coming back.
That protection is deliberate. Bringing the port back up, or turning the protection off, would return an unstable link to service. This article records what the host and the switch saw, so the people who own the cable, the switch and the adapter can find the fault.
Scope
ESXi 8.0. The reads below are local to the host or come from the network owner. Not covered: beacon probing, virtual NIC problems, and any change. For network design and MTU, see the published VMware networking design and troubleshooting article.
What ESXi does
KB 324499 (which states it applies to all ESXi versions) says: "When a physical NIC experiences frequent link status flapping (i.e. consecutive link down and link up events), ESXi may turn off the physical NIC to avoid unnecessary link failover and network instability."
The signs it lists:
- vobd.log: "Taking down physical NIC vmnic## because the link is flapping."
- hostd.log: "Taking down physical NIC vmnic## because the link is unstable."
esxcli network nic get -n vmnic#shows "Link Status: Down by linkflapping".
The trigger is the advanced setting Net.LinkFlappingThreshold. KB 411524 says it "defines the maximum number of link-down events allowed per minute before the ESXi host considers the link unstable", with a default of 60, and that "Setting the value to 0 disables the protection mechanism." It also notes "Changes to this parameter take effect immediately; a reboot is not required." The KB does not describe how the minute is counted, and does not say that a new value brings back a port already taken down. This article assumes neither.
KB 324499 lists the usual causes: a hardware fault in the adapter, the driver resetting the adapter after errors such as a "tx Hang", and "Physical layer issues, such as faulty cabling or switch port errors." KB 452470 also names "a failing physical Network Interface Card (pNIC)" among the physical causes, next to the SFP module, cable and switch port.
Step 1: record the event
| Field | What to record |
|---|---|
| A | Host, ESXi version and build, and the time zone of the logs |
| B | The vmnic, its virtual switch or distributed switch, port groups, and the other uplinks in the same team |
| C | vCenter alarms and their times (for example uplink redundancy lost or network connectivity lost) |
| D | The vobd.log and hostd.log lines quoted above, with their times. These lines, or E showing Down by linkflapping, show that the protection acted; a plain down state does not |
| E | Output of esxcli network nic get -n vmnicN: Link Status, Driver, Firmware Version, Version, Transceiver, Cable Type |
Step 2: record the flaps before the shutdown
| Field | What to record |
|---|---|
| F | The vmkernel.log link down and link up lines for this vmnic in the minutes before D. KB 452470 shows the pattern "vmnicX: link down notification" followed by "vmnicX: link up notification" |
| G | Driver lines next to them: resets, hangs, firmware events, and whether the log for that period is complete. Missing reset lines do not rule the driver out. For bnxtnet on ESXi 8.0, KB 452940 shows a firmware hot reset with "evt_data1 = 0x301" |
| H | vobd.log uplink transitions. KB 421352 links "Failed criteria: 128" to the driver reporting link state down |
| I | Error counters: esxcli network nic stats get -n vmnicN (CRC, FIFO, dropped, errors), and the hostd error statistics KB 452470 shows (droppedRx, droppedTx, errorsRx), each read at two or more stated times, so the change and its direction (receive or transmit) are known |
| J | The current Net.LinkFlappingThreshold value and the time it was read (read only, Configure > System > Advanced System Settings). Its value at the time of D, and any change, only from dated evidence; otherwise unknown |
Step 3: record what the other owners see
| Field | What to record |
|---|---|
| K | From the network owner: the vmnic-to-switch-port mapping and how it was confirmed; the time offset between switch and host clocks; switch, port, its event log of link changes, error counters, transceiver readings, and any change or maintenance at the time |
| L | From the hardware owner: the server management console (iLO, iDRAC or similar) state of the adapter. KB 421352 notes it may show "Degraded" or "Unknown" |
| M | The driver and firmware in E, compared by the hardware owner with the Broadcom Compatibility Guide and the server vendor's support matrix. A compatibility finding is a candidate, not proof of cause |
| N | Any host update, driver update or firmware update in the days before |
Step 4: classify
| What the record shows | Candidate explanation | Handed to |
|---|---|---|
| Neither D nor E shows the linkflapping signs | Not this protection; record the down state as is | vSphere owner |
| G shows driver resets or firmware events before each down | Adapter or driver/firmware candidate (KB 452940 pattern for bnxtnet) | Hardware owner |
| M says the driver and firmware pair is not listed as supported | Unsupported combination; a candidate, not proof of cause | Hardware owner |
| I and K, on a confirmed vmnic-to-port mapping with aligned times, show errors rising on that link | Degraded physical path: adapter (pNIC), cable, transceiver or switch port; the failed part is not identified | Network owner and hardware owner |
| K shows the switch port changing state or under maintenance | Switch-side record; it may reflect the same link failure rather than its cause, unless maintenance or a change is recorded | Network owner |
| A and E show an ntg3 driver of version 4.1.3 or later, B shows two such NICs connected directly with no switch, and D to F show the flapping | Candidate for the ntg3 known issue in the ESXi 8.0 U3f release notes. Current driver settings and any mitigation already applied stay unknown unless recorded. Separate from the Energy Efficient Ethernet (EEE) issue the same notes mention | Hardware owner |
| No cause in any field, or fields conflict | Unresolved | vSphere owner, record as is |
More than one row can apply at once.
What this record does not authorise
This record does not authorise bringing the port up (esxcli network nic up), changing or zeroing Net.LinkFlappingThreshold, reinstalling drivers, updating firmware, rebooting the host, moving VMs, or changing cables, transceivers or switch ports. KB 411524 itself advises keeping the default "in most environments".
The owners decide, with at least:
- which candidate to test or replace first, given that the record may leave more than one open;
- whether the host keeps running with reduced redundancy until then, and what that exposes;
- whether the port is brought back only after a repair, and how connectivity and failover are checked afterwards.
Repair, reactivation and those checks are separate work, planned and approved on their own; they are outside this read-only record.
Worked example (fictional)
The values below are invented. Host esx-31, ESXi 8.0 U3, vmnic3 in a team with vmnic2 on dvs-prod. At 02:14 AEDT on 4 November vCenter raises uplink redundancy lost.
| Field | Value |
|---|---|
| D | vobd 02:14:07: Taking down physical NIC vmnic3 because the link is flapping |
| E | Link Status: Down by linkflapping; Cable Type DA |
| F | 70 link down and link up pairs between 02:13:05 and 02:14:06 |
| G | No driver reset or firmware lines; vmkernel.log covers 01:00 to 02:20 without gaps |
| I | vmnic3 receive CRC errors 0 at 01:50 and 18,400 at 02:13; vmnic2 0 at both times |
| J | 60, read at 03:05; value at 02:14 and change history not available |
| K | vmnic3 connects to switch port Eth1/12 (cabling record, confirmed by the network owner); clocks within 1 second; the port logs link changes from 02:12; receive errors rising; no maintenance |
Classification: D and E show the protection acted. I and K show the path between vmnic3 and Eth1/12 is degraded. Which part has failed, the adapter, cable, transceiver or switch port, is not established, and the absence of driver lines does not rule out the adapter. The record goes to the network owner and hardware owner. vmnic3 stays down and nothing is changed; any repair or reactivation is separate approved work.
Acceptance checks
- Fields A to N are recorded, or marked not available with the reason, with times and time zone.
- The exact log lines are quoted, not paraphrased.
- Driver and firmware are compared by the hardware owner, not assumed current.
- Each event ends in a candidate row or as unresolved, with the owner named.
- Nothing was changed. Reading needs no rollback.
Learning notes
- A port shown as "Down by linkflapping" was switched off by ESXi, not by the switch.
- The threshold is a safety setting; raising or disabling it does not fix the link.
- Host and switch counters on a confirmed port mapping show which path is degraded; on their own they do not pick the failed part.
- Driver and firmware need to be a supported pair.
Related articles
Sources
Retrieved 2026-11-03 between 18:35:59 and 18:36:29 UTC (early on 4 November, Australia/Sydney). Dates are each page's own Updated On or Last Updated date.
- Broadcom KB 324499, "A physical NIC may be brought down due to frequent link status flapping", 5 October 2026. https://knowledge.broadcom.com/external/article/324499/a-physical-nic-may-be-brought-down-due-t.html
- Broadcom KB 411524, "The ESXi parameter \"LinkFlappingThreshold\" to adjust the link flap protection mechanism", 4 August 2026. https://knowledge.broadcom.com/external/article/411524/
- Broadcom KB 452470, "Troubleshooting NIC Flapping and Suspected Network Uplink Redundancy Failover Failure", 12 October 2026. https://knowledge.broadcom.com/external/article/452470/troubleshooting-nic-flapping-and-suspect.html
- Broadcom KB 421352, "Error: Network Connectivity Lost alarm on ESXi hosts", 30 June 2026. https://knowledge.broadcom.com/external/article/421352/error-network-connectivity-lost-alarm-on.html
- Broadcom KB 452940, "Error: vmnic link down or flapping due to bnxtnet firmware crash on ESXi 8.0", 28 September 2026. https://knowledge.broadcom.com/external/article/452940/error-vmnic-link-down-or-flapping-due-to.html
- Broadcom TechDocs, "VMware ESXi 8.0 Update 3f Release Notes", 28 October 2026. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/release-notes/esxi-update-and-patch-release-notes/vsphere-esxi-80u3f-release-notes.html