JamesCurtis
Contributor
Contributor

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.

 

Reply
0 Kudos