LACP on vDS for MLAG
A company operates a three-node vSphere cluster for a critical application. Each ESXi host has two 10GbE physical NICs (vmnic0 and vmnic1) connected to two separate physical switches (Switch A and Switch B) for redundancy. The cluster uses a vSphere Distributed Switch (vDS) with two uplinks per host: uplink1 (vmnic0) connected to Switch A, and uplink2 (vmnic1) connected to Switch B. The teaming policy is set to 'Route based on originating virtual port' with both uplinks active. The physical switches are configured in a multi-chassis link aggregation group (MLAG) that bundles the ports from both switches into a single LAG interface. The LAG is configured with mode 'active' (802.3ad). Recently, the cluster experienced a network outage when one of the physical switch uplinks failed. The VMs on the affected host lost connectivity for several seconds before recovering. The administrator wants to prevent such outages in the future. Which action should the administrator take?
Quick Answer
Configuring the vDS with LACP support and setting the teaming policy to Route based on IP hash is correct because a physical link aggregation group only works when both ends of the link speak the same aggregation protocol and use a compatible hashing method. Here, the physical switches were bundled into a true LACP-negotiated MLAG in 802.3ad active mode, but the virtual side was left on Route based on originating virtual port, a purely virtual-switch load-balancing algorithm with no awareness of the physical LAG at all. Because the two sides weren't actually coordinating, a single uplink failure couldn't be cleanly absorbed by the LAG's failover logic, producing the connectivity gap the VMs experienced. The fix is to make the vDS an active participant in the same LACP negotiation as the physical switches, paired with IP hash, the teaming algorithm designed to match how a LAG distributes and re-routes traffic across member links. Simply adding more uplinks, changing failover order, or tweaking the physical switch alone would not resolve the mismatch, because the root problem is that the virtual and physical link-aggregation configurations were never actually working together as a single logical channel. Whenever a scenario describes physical switches in a LAG or MLAG but the vDS teaming policy is something other than IP hash with LACP enabled, that mismatch is almost always the cause of the failover behavior being tested.
⚠ Common exam trap
Many candidates assume 'Route based on originating virtual port' with two active uplinks provides adequate failover, but they overlook the critical requirement for LACP coordination when the physical switches are configured with an active-mode LAG (802.3ad), leading to a mismatch that causes delayed failover.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure the vDS with LACP support and set the teaming policy to 'Route based on IP hash'.
The current configuration uses a static LAG (MLAG) on the physical switches with 802.3ad active mode, but the vDS is not configured for LACP. This mismatch causes the vDS to send frames based on originating virtual port, which does not coordinate with the physical LAG's hashing algorithm. When a physical uplink fails, the MLAG may not properly redistribute traffic because the vDS is unaware of the LAG state, leading to connectivity loss. Configuring the vDS with LACP support and setting the teaming policy to 'Route based on IP hash' aligns the virtual and physical LAG configurations, ensuring proper load balancing and failover behavior.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Disable LACP on the physical switches and configure the vDS with 'Route based on originating virtual port' only.
Why it's wrong here
Disabling LACP would remove the MLAG benefits.
- ✗
Add a third physical NIC to each host and configure it as a standby uplink.
Why it's wrong here
Does not address the root cause.
- ✗
Change the vDS teaming policy to 'Use explicit failover order' with vmnic0 active and vmnic1 standby.
Why it's wrong here
Would not leverage the MLAG.
- ✓
Configure the vDS with LACP support and set the teaming policy to 'Route based on IP hash'.
Why this is correct
This aligns the vDS with the physical LAG.
Go deeper
Related to this question
About these practice questions
This VCP-DCV question is part of Courseiva's 498-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on VCP-DCV
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. After upgrading the physical switches, the LAG (Link Aggregation Group) on a VDS does not come up. The VDS LAG configuration shows LACP active mode. The physical switch ports are configured with LACP active mode as well. What is the most likely cause?
hard- A.The physical switch uses a different LACP system priority
- ✓ B.The physical switch ports are not in a port-channel
- C.The ESXi hosts have different LAG IDs
- D.The VDS LAG hashing algorithm is set to IP hash
Why B: For a LAG to form, the physical switch ports must be configured as a port-channel or etherchannel. Even if both sides are set to LACP active, the switch ports must first be grouped into a port-channel interface; otherwise, LACP negotiations will not complete. Option A is incorrect because the system priority affects LACP role but does not prevent LAG formation if both sides are active. Option C is incorrect because LAG IDs are not relevant across hosts; each host's LAG is independent. Option D is incorrect because the hashing algorithm does not affect LACP negotiation; it only affects load distribution.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This VCP-DCV practice question is part of Courseiva's free VMware certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the VCP-DCV exam.