AHV Networking with Active/Standby Switch Ports
A media company is migrating 90 VMs from ESXi to a four-node AHV cluster. Each node has two 10 GbE ports and one 1 GbE IPMI port. The ToR switches are Cisco Nexus configured with one port in active mode and one in standby for each server; the network team does not want to enable LACP. The ESXi hosts currently use a standard vSwitch with a trunk carrying VLANs 10 (production), 20 (development), 30 (DMZ), and 99 (management). One VM runs a network monitoring tool that requires promiscuous mode, and another runs an internal DHCP service. The security team wants the DMZ VLAN isolated so that a compromised DMZ VM cannot reach production. The cluster will use AHV and Prism Element. The team asks whether to use LACP, active-backup, or balance-slb, and how to place management and storage traffic.
1. Recommend a bond mode and explain the trade-offs.
Read the worked answer
With the switch ports active/standby and no LACP, choose active-backup for the AHV host bonds. It is simple, supported, and survives a link failure, but only one 10 GbE link carries traffic at a time. That may be acceptable for 90 VMs if the workload is not bandwidth-heavy.
LACP would use both links and provide better aggregate throughput, but it requires the network team to configure an LACP port-channel on both ToR switches. Do not enable LACP on one side only.
balance-slb can use both links without switch LACP, but it hashes flows and does not guarantee a single flow exceeds 10 GbE; it can also create uneven utilization and is not a substitute for a properly designed uplink. If the customer refuses LACP and needs more than one link's worth of bandwidth, that is a design constraint to document, not something to hide in a bond mode choice.
2. How should VLANs 10, 20, 30, and 99 be implemented on AHV, and how should DMZ risk be reduced?
Read the worked answer
Create VLAN-backed networks in AHV for VLANs 10, 20, 30, and 99, and trunk those VLANs on the host uplinks. Attach each VM NIC to the correct network; the guest OS should not need to tag unless you deliberately pass a trunk to a virtual router or appliance. Keep management on VLAN 99 and do not attach user VMs there.
VLANs are segmentation, not a security boundary by themselves. For the DMZ, enforce policy with Flow microsegmentation or a physical/virtual firewall between VLAN 30 and VLAN 10; default-deny east-west traffic and allow only the required application flows. Place the DMZ VMs on dedicated hosts or at least a dedicated VLAN with no management access. Validate that a compromised DMZ VM cannot reach production by testing, not by assuming the VLAN tag is sufficient.
3. What must be validated for the promiscuous-mode monitoring VM and the DHCP VM?
Read the worked answer
For the monitoring VM:
- Confirm the AHV version and support statement for promiscuous mode; recent releases expose a per-NIC setting, but it should be an explicit security exception.
- Scope it to the minimum VLAN and avoid placing it on management or DMZ if not required.
- If promiscuous mode is not supported or not approved, use a switch mirror/SPAN port or Flow-based traffic inspection instead.
For DHCP:
- Put the DHCP service on the correct VLAN-backed network and confirm the broadcast domain is limited to that VLAN.
- Ensure there is no rogue DHCP server and that the service is authorized by the security team.
- Test client renewal and failover before production cutover.
Document both as exceptions with owners; neither should be enabled broadly across the cluster.