JamesCurtis's Posts

Guys, I probably found the reason. The root of the problem is that all my virtual machines have two network cards. When they get the dhcp information of nsx-t, they specify two default routes. root@ks01:~# ip route default via 172.16.10.1 dev ens192 proto dhcp src 172.16.10.25 metric 100 default via 172.16.10.1 dev ens160 proto dhcp src 172.16.10.101 metric 100 10.10.1.1 via 172.16.10.1 dev ens192 proto dhcp src 172.16.10.25 metric 100 10.10.1.1 via 172.16.10.1 dev ens160 proto dhcp src 172.16.10.101 metric 100 172.16.10.0/24 dev ens192 proto kernel scope link src 172.16.10.25 metric 100 172.16.10.0/24 dev ens160 proto kernel scope link src 172.16.10.101 metric 100 172.16.10.1 dev ens192 proto dhcp scope link src 172.16.10.25 metric 100 172.16.10.1 dev ens160 proto dhcp scope link src 172.16.10.101 metric 100 Now let's test the flow transmission test on the 172.16.10.101 network card of the ens160. The results displayed in the virtual machine are as follows root@ks01:~# iperf3 -s ----------------------------------------------------------- Server listening on 5201 ----------------------------------------------------------- Accepted connection from 10.10.1.2, port 62401 [ 5] local 172.16.10.101 port 5201 connected to 10.10.1.2 port 62402 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 64.3 KBytes 526 Kbits/sec [ 5] 1.00-2.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 2.00-3.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 3.00-4.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 4.00-5.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 5.00-6.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 6.00-7.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec [ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.06 sec 64.3 KBytes 52.3 Kbits/sec receiver   Now, I turn off the ens192 network card, and the test results immediately return to normal. Then turn on the ens192 network card. After testing the ens160, it was found that the traffic bandwidth was still normal. (I don't understand the reason here) However, if the ens192 is tested at this time, the situation of 0bits/s will occur again. Next, close the ens160 network card and test the ens192. The results show that it miraculously restored the normal bandwidth. Next, close the ens160 network card and test the ens192. The result shows that the ens192 magically restores the normal bandwidth. If you open the ens160 network card again, the ens192 is still normal. At this time, the problem shifts to ens160. On the surface, it seems that this fault will always remain on one of the network cards. I mark it as A. The fault will not disappear until other network cards (marked with X) are turned off. However, if the closed network card (X) is opened again, the fault will appear on the network card (X) opened again, and the network card A will not be affected. If you repair network card X according to the idea in the previous paragraph, network card A will fail again after one operation.  

If the vm initiatively initiates the iperf, the connection will be directly disconnected. Otherwise, it will not, but the speed is very slow 0k/s.   My laptop: D:\Users\th>iperf3 -s -p 666 ----------------------------------------------------------- Server listening on 666 ----------------------------------------------------------- iperf3: error - unable to receive parameters from client: Connection reset by peer   The vm: root@ks01:~# iperf3 -c 10.10.1.211 -p 666 iperf3: error - unable to send control message: Broken pipe    

I have the same problem. However, problems still exist after reinstalling NSX-T. And the problem is random. Some virtual machines will exist and some will not. These virtual machines are cloned from an Ubuntu jammy template. And this problem only exists when external traffic is sent to the virtual machine. If the - R parameter is added to iperf3, the virtual machine can send traffic from the internal to the external. I have no way to solve it. Is there any progress?

I also got the problem of tunnel closure. If I delete the switch of esxi and replace it with N-VDS switch, it can work normally. Switching back to the VDS switch again will fail.  NSX Appliance 3.2.2.0.0.20737185 VCenter 7.0.3.01100 VMware ESXi, 7.0.3, 20328353