VMware Cloud Community
lpapaleo
Contributor
Contributor

Network problem with Intel - i40en

Hello,

in the last ESXi installation (6.0, 6.5 update 1 and update 2 and 6.7 too) we've found strange problem with this configuration:

HARDWARE

Fujitsu Primergy TX2550M4 with 2 on board Intel X722 1GbE2 NIC seen from vSphere with i40en driver.

VSS CONFIGURATION

1 vSwitch with 1 MGMT kernel port group and 1 VM PG

Both vSwitch and PG (all) has 2 nic in teaming active / active configuration

VSPHERE SOFTWARE VERSION (all with problem)

On vSphere 6.5 update 2 I've already tryed to upgrade the driver with i40en-1.7.17-1OEM.650.0.0.4598673.x86_64.vib.

Then I've tryed to upgrade the host to 6.7 update 1, still got the problem.

Then updated the 6.7 update 1 and still go the problem (witch i40en 6.5 driver)

Then updated via esxcli command line to VMW-ESX-6.7.0-i40en-1.7.17-11283970

THE PROBLEM

from a pc connected to the network I keep ping on ESXi management IP and VM IP

sometimes I lose near to 10 packets just vs the ESXi, while I don't lose any ping to the VM

IF I change the PG management ESXi teaming from active active to active / passive I don't lose any ping

I've seen a lot of forum about i40en, but anyone the has similar problem.

Any help would be appreciate

Thanks

Luca

0 Kudos
8 Replies
zorro0190
Contributor
Contributor

Hello Ipapaleo,

have you solved your problem? We have the same.

What did you do? Have you update the i40n driver?

I found this:

https://my.vmware.com/de/group/vmware/details?downloadGroup=DT-ESXI67-INTEL-I40EN-1717&productId=742...

Thanx for your support

Br Thomas

0 Kudos
mguidini
Enthusiast
Enthusiast

Check if you experience the same issue switching over to the legacy i40e driver:

Be sure that you have the two drivers otherwise you will need to download the i40e from the HCL

#esxcli software vib list | grep -i i40

Then you should disable the i40en module with the following command:

#esxcli system module set --enabled=false --module=i40en

#esxcli system module set --enabled=true --module=i40e

Then reboot the ESXi host.

If you experience the same issue using the i40e driver, isolate it by moving one vmnic at the time to active, and see which one is dropping packets. You might want to have a look at that physical switchport and cable connected to this particular vmnic.

Hope it helps, good luck!

0 Kudos
lpapaleo
Contributor
Contributor

Hello,

in these days I can't test anyway the problem because the server is already installed to the end user.

But I'll try to follow both the solutions

Thanks and keep update

Luca

0 Kudos
Cormite
Contributor
Contributor

Be careful with the legacy i40e driver (KB 2126909): VMware Knowledge Base 

0 Kudos
mguidini
Enthusiast
Enthusiast

I've been there, this step resolved:

Run this command to disable TSO at the host level:

esxcli system settings advanced set -o /Net/UseHwTSO -i 0

0 Kudos
Cormite
Contributor
Contributor

This was a solution for me in the past with version 6.5

Currently I have a case opened with VMware as we have a lot of dropped packages with Intel X710 and driver i40en (latest driver version 1.8.6 and firmware 6.80... looking for 7.00).

I haven't still received any final answer.

0 Kudos
lpapaleo
Contributor
Contributor

Hello, I've a different behavior with similar hardware/software configuration.

Server Fujitsu TX2550M5, with Intel onboard NIC

vSphere 6.7 Update 2 (Fujistu ISO) - any update or upgrade done (it's just a single host)

2 NIC seen as i40en

1 Standard vSwitch

2 Port Group (LAN and ESXi management)

1 VM on PG LAN

Both NIC are connected to the same physical switch (non LAG o similar)

if I ping both ESXi and VM I don't loose any packets but I receive ping (DUP!) answer

I've tryed to leave vSwitch with active/active and the 2 PG active/passive, but this time didn't help me.

I've tryed to use the following command too

esxcli system settings advanced set -o /Net/UseHwTSO -i 0

without any difference

Any help would be appreciated

Thanks

Luca

0 Kudos
lpapaleo
Contributor
Contributor

I've an update.

I've solved specifying the NETWORK FAILOVER DETECTION AS LINK STATUS ONLY.

The strange is that I've always used (in the identical configuration) BEACON ONLY without any problem.

Some information about this situation?

Thanks again

Luca

0 Kudos