A library ESXi host's overlay TEP flaps, and Distributed Firewall realization on that host flaps with it. vmkping to other TEPs drops whenever one member of the physical NIC team errors. What should the administrator inspect first?
Select an answer to reveal the explanation.
Short Explanation
If one copper cable is dying, the TEP looks possessed and DFW realization rides the same roller coaster. Check the pNIC, cable, and switch light before rewriting firewall sections. Physical NIC failure loves to wear an NSX mask.
Full Explanation
When a library ESXi host's overlay TEP flaps and Distributed Firewall realization on that host flaps with it, and vmkping to other TEPs drops whenever one member of the physical NIC team errors, inspect the physical NIC, cable, and switch port in that NIC team first, because a pNIC failure presents as NSX host and DFW instability. Unstable underlay team members make TEPs and realization look like NSX bugs when the root cause is metal. Fixing the civic pNIC path stabilizes overlay and DFW. Only the Distributed Firewall Application section, because TEP flaps are always a DFW publish bug, fails by concept because TEP flaps correlated with NIC team errors are underlay hardware/path issues, not Application section publish bugs. Carbon Black Cloud sensor policy on the library VMs, which renegotiates Geneve when prevention is on, fails by concept because CBC policy does not renegotiate Geneve or cause TEP flaps. Workspace ONE Access connector health, which holds TEP state for identity firewall, fails by concept because Access connectors do not hold TEP state for hosts. Exam caveat: TEP and DFW flaps timed with NIC team errors mean inspect pNIC/cable/switch first—do not start by rewriting DFW, CBC, or Access. Operational check: identify the failing team member, replace cable/pNIC or fix the switch port, confirm stable vmkping between TEPs and stable DFW realization, and record underlay health checks in the library host troubleshooting guide for municipal fabric reliability.