Exam 2V0-21.19 topic 1 question 70 discussion

with no doubt the correct answer is A & B as per VMware docs it CLEARLY says "If packets are not being dropped, check the size of the network packets and the data receive and transfer rates." You can confirm this from the below link under CHART ANALYSIS, the second paragraph. https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-07EBECDB-7242-4C50-95CB-C672D939019C.html D is an answer if it says in the questions that the packet sizes are small, which means more transfer will occur which will consume more CPU.

I think the keyword in the question is what you'd need to check from WITHIN esxtop. You can't check packet size in esxtop. You CAN however, check CPU contention on the host and network received rate.

A, B should be right

It is A and B for sure. Performance issue on the network, obviously nothing related with IPV6 support. Then we have A B and D. D can be but it can be because of A or/& B. And with esxtop you can see the Size of the packets and the Receibe rate by packets or bytes. Check this video: https://www.youtube.com/watch?v=__TbrDwMGss

It is A and B for sure. Performance issue on the network, obviously nothing related with IPV6 support. Then we have A B and D. D can be but it can be because of A or/& B. And with esxtop you can see the Size of the packets and the Receibe rate by packets or bytes. Check this video: https://www.youtube.com/watch?v=__TbrDwMGss

Here we needs to focus on troubleshoot using ESXTOP utility and the utility reveals no dropped packets. For network related paramater in esxtop, you can see transfer rate (Tx/Rx) and PKT Drop details. I don't think you can see the packet size there. So the answer can be B and D.

i think the answer is A and B, The first answer be dropped since there is no any relevant with IPV6 support will impact network performance. the rest is A,B and D. Esxtop can reveal network performance use dropped receive packages, is there is no dropped packets, means, CPU resources is enough, no contention so D is dropped.

I believe the Answers are : A , B They have not mentioned that data receive rate is slow, so C it can be chosen only after checking the data received rate. Notes: If packets are being dropped, adjust the virtual machine shares. If packets are not being dropped, check the size of the network packets and the data receive and transfer rates. If packets are not being dropped and the data receive rate is slow, the host is probably lacking the CPU resources required to handle the load. https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-41B7E742-B387-4638-A150-CB58E2ADD89F.html

No packet be dropped but still experiencing network performance problem. choose two conditions, Bigger packet size will result in network latency, and data receive rate or transfer rate will also impact on network performance. So A&B is right answer.

B&D seems to correct as DATA receive & transmit rate will itself indicate packet size i think.As transfer rate is faster means big pkt size means less CPU needed. transfer rate is slow means more pkts to process means less pkt size and more CPU needed for that. Its a tricky Question

On VMWARE 6.7 Networking Guide https://docs.vmware.com/en/VMware-vSphere/6.7/vsphere-esxi-vcenter-server-671-networking-guide.pdf Answer Should be A and B When a Windows virtual machine transmits UDP packets larger than 1024 bytes, you experience lower than expected or oscillating throughput even when other traffic is negligible. In case of a video streaming server, video playback pauses

A =! packets bigger then 1500MTU are reffered as jumbo frames. if receiving host MTU is lower than sender MTU it will either drop package (we are told it is not the case) or it will fragment it into multiple packages. C != not relevant B = correct. In ethernet if sender is sending more data then receiver can process it will start filling up receiver stack. Once receiving stack overflow it will start discarding packages. You can either enable data flow or use fibre channel over ethernet to mitigate it. D = correct. if network card is not using TOE offloading (tcp offload engine) all package assembling (network iso model) in is relying on cpu resources.

https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-41B7E742-B387-4638-A150-CB58E2ADD89F.html "If packets are not being dropped, check the size of the network packets and the data receive and transfer rates."

Answer : A & B Network performance depends on the application workload and network configuration. Dropped network packets indicate a bottleneck in the network. To determine whether packets are being dropped, use esxtop or the advanced performance charts to examine the droppedTx and droppedRx network counter values. If packets are being dropped, adjust the virtual machine shares. If packets are not being dropped, check the size of the network packets and the data receive and transfer rates. https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-41B7E742-B387-4638-A150-CB58E2ADD89F.html

If packets are not being dropped and the data receive rate is slow, the host is probably lacking the CPU resources required to handle the load. reference : https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-07EBECDB-7242-4C50-95CB-C672D939019C.html ANS: BD

If packets are being dropped, adjust the virtual machine shares. If packets are not being dropped, check the size of the network packets and the data receive and transfer rates. In general, the larger the network packets, the faster the network speed. When the packet size is large, fewer packets are transferred, which reduces the amount of CPU required to process the data. When network packets are small, more packets are transferred but the network speed is slower because more CPU is required to process the data. https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-41B7E742-B387-4638-A150-CB58E2ADD89F.html

I think A , D https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.monitoring.doc/GUID-41B7E742-B387-4638-A150-CB58E2ADD89F.html