An administrator is experiencing network connectivity issues between virtual machines. The virtual machines and hosts are configured as follows:
VM1 is running on Host1
VM2 is running on Host2
Both Host1 and Host2 are attached to the vSphere Distributed Switch dvSwitch1
Both Host1 and Host2 are using vmnic0 and vmnic1 on dvSwitch1
Both virtual machines are using the default portgroup for network traffic
What are three settings the administrator should investigate while troubleshooting the connectivity issue? (Choose three.)
A.
VLANs of the physical NICs
B.
Failover order of the uplinks
C.
Virtual NIC connectivity to the dvSwitch
D.
Security policy of the portgroup
E.
Traffic shaping on the portgroup
Explanation:
Why not E as well?
0
0
Traffic shaping does not provoke network connectivity issues. It could affect network performance, but not connectivity
https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.hostclient.doc/GUID-D3A091C0-0D0D-480D-ACE3-62524E2E0D0A.html
1
0
Correct Answers: A, C, E
0
0
Meant to say A, C, D
0
0
I have to agree with RC. I do not see how Failover order can impact you in such a way unless someone changed them all to “unused”, while Security policies can definitely cause blockages.
Anyone have any insight?
0
0
For me it’s A,C,E
0
1
A, B, C
Failover order can affect connectivity.
https://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.troubleshooting.doc%2FGUID-437CA0A2-CB4C-4CF6-B019-4C17FCC8EECC.html
1
0
I also think A, B, C. The Failover Order can bite people like me who choose to put all of our uplinks under one vDS. If I accidently set my vMotion Uplink as Active for my Management port group, I might be in for a bad day. That’s why a lot of people just choose to create separate vDS for each type of traffic. VMware supports both as best practices though. So B is definitely a possible answer.
D could possibly cause a network issue if a VM was trying to forge it’s MAC but the Security Policy wasn’t set to allow it. That makes me a bit torn but this doesn’t seem as likely to occur as the others.
0
0
Exactly, I’d like to see this question to have a little more information. D seems like a long shot.
0
0
Of course there’s always a possibility to do smth silly. That’s why VMware introduced the roll-back feature for DVS in 5.x.
I dare to say the arguments for ‘C’ are mostly based on knowing that it’s the “correct” answer from the exam dumps. However, objectively, ‘D’ (forged transmits as you reasonably note) makes far more sense.
0
0
it is correct A, B, C
check this link from VMware documentation
https://pubs.vmware.com/vsphere-60/index.jsp#com.vmware.vsphere.hostclient.doc/GUID-D3A091C0-0D0D-480D-ACE3-62524E2E0D0A.html
1
0
This is the link
https://pubs.vmware.com/vsphere-60/topic/com.vmware.vsphere.troubleshooting.doc/GUID-5324A0E4-AA7B-40CC-A975-D45328B5C434.html
0
0
Here is where Answer C can come into play:
vSphere 4-distributed virtual switches used a static quantity of virtual ports. When you ran out of virtual ports, you’d have to increase the quantity using the graphical user interface (GUI) or a script. It was not fun!
With version 5.x of vSphere, however, the distributed virtual ports are now elastic ports by default. Elastic means that the virtual switch will manage the quantity of virtual ports automatically – creating and deleting them as needed – without user intervention.
1
0
default port group in dvs have policy reject for all 3 security policy (proc, mac, forged).
therefore I go with ABD
0
0