Hi,
I was performing some latency measurements with Intel XXV710 in 10G mode and HW timestamps were done for test PTP packets correctly.
However, When I switched to 25G mode using ethtoo, HW timestamps are no longer done. I am using DPDK to send PTP packets.
Please let me know if I need to enable something to enable HW timestamping in 25G mode.
Thanks,
Pravein
Hi,
One of the new features in the latest Intel drivers for ESXi 6.5 (1.7.11) should be possibility to control LLDP Agent also for x722 cards.
The only prerequisite should be FW 3.10 and later. However it is not working for me and I'm running FW 4.0 already.
Am I missing something, or Intel did?
See below:
esxcli system module parameters list -m i40en
Name Type Value Description
------- ------------ ------- ----------------------------------------------------------------------------------
LLDP array of int 0,0,0,0 Link Layer Discovery Protocol (LLDP) agent: 0 = disable, 1 = enable, (default = 1)
RxITR int Default RX interrupt interval (0..0xFFF), in microseconds (default = 50)
TxITR int Default TX interrupt interval (0..0xFFF), in microseconds, (default = 100)
VMDQ array of int Number of Virtual Machine Device Queues: 0/1 = disable, 2-16 enable (default =8)
max_vfs array of int Maximum number of VFs to be enabled (0..128)
esxcli network nic get -n vmnic0
Advertised Auto Negotiation: true
Advertised Link Modes: Auto
Auto Negotiation: false
Cable Type: DA
Current Message Level: 0
Driver Info:
Bus Info: 0000:08:00:0
Driver: i40en
Firmware Version: 4.00 0x80001441 1.1937.0
Version: 1.7.11
Link Detected: true
Link Status: Up
Name: vmnic0
PHYAddress: 0
Pause Autonegotiate: true
Pause RX: false
Pause TX: false
Supported Ports: DA
Supports Auto Negotiation: true
Supports Pause: true
Supports Wakeon: true
Transceiver:
Virtual Address: 00:50:56:5a:72:cc
Wakeon: MagicPacket(tm)
cat /var/log/vmkernel.log | grep -i lldp
2018-10-17T12:22:30.057Z cpu35:66169)i40en: i40en_InitAdapterConfig:363: X722 device does not support LLDP setting for FW API version older than version 1.6
2018-10-17T12:22:30.100Z cpu35:66169)i40en: i40en_InitAdapterConfig:363: X722 device does not support LLDP setting for FW API version older than version 1.6
2018-10-17T12:22:30.136Z cpu35:66169)i40en: i40en_InitAdapterConfig:363: X722 device does not support LLDP setting for FW API version older than version 1.6
2018-10-17T12:22:30.171Z cpu35:66169)i40en: i40en_InitAdapterConfig:363: X722 device does not support LLDP setting for FW API version older than version 1.6
2018-10-17T12:22:33.626Z cpu42:66391)Loading module lldp ...
2018-10-17T12:22:33.626Z cpu42:66391)Elf: 2043: module lldp has license VMware
2018-10-17T12:22:33.627Z cpu42:66391)Mod: 4972: Initialization of lldp succeeded with module ID 42.
2018-10-17T12:22:33.627Z cpu42:66391)lldp loaded successfully.
Hello
I'm running Supermicro X11SSL-F motherboard with networking adapter Inter i210-AT
Next issue is faced after updating motherboard BIOS to latest version (2.2) -- with Windows Server 2012 R2 is being used -- network adapter becoming unstable after 10-14 GB of transmitted data. It either stop sending\receiveing data (like buffer overflow) or drops connection at all.
Tried recommendations, described in document TA-201, tried disable TCP offloading, tuning down to lower link speed, disabling power saving features - no luck, until restart system refuses to transmit big amounts of data, while may be still available sometimes via RDP (or sometimes starting to drop packets completely). Disabling\enabling adapter on running system has no effect.
Basically, I'm runned out of ideas. Main suggestion was a faulty BIOS update, but issue does not reproducing on Linux (Debian\Centos\Ubuntu), so this seems to be more driver issue.
OS: Windows Server 2012 R2, build 9600
Driver package version: 23.2
Driver version (from device properties) - 12.14.7.0, date 11/3/2017
Please advice.
Hi, i have a question:
I have windows 10, and when i go to "show network property" , it says Maximum trasmission unit: 1500
my pc is connected with a modem , that is connected to a PPPoE LLC connection, and use MTU = 1492 not 1500
Should i change this setting on my computer? How i have to change it?
Thanks you, and sorry for my bad english
Hi,
I have a Intel(R) I210 Gigabit Network Connection on my system, and I have the problem, that there is a huge (24s) delay between startup and Network link connected.
at 16:54:35:
The Intel(R) PROSet Monitoring Service service entered the running state.
at 16:54:36
Intel(R) 82579LM Gigabit Network Connection Network link is disconnected (this is ok, because there is no cable)
at 16:54:36
Intel(R) I210 Gigabit Network Connection Network link is disconnected. (this is not ok, because there is a cable connected on it)
at 16:54:59:
Intel(R) I210 Gigabit Network Connection Intel SmartSpeed has downgraded the link speed from the maximum advertised.
at 16:54:59:
Intel(R) I210 Gigabit Network Connection Network link has been established at 100Mbps full duplex.
If I plug in the cable on the other network adapter (Intel 825879LM, the network adapter is conneceted instantly).
I'm using the network driver Intel® Network Adapter Driver for Windows 7* Version 23.2 (latest).
Hi Vince,
We have experienced PSOD's in ESXI 6.0 using the i40e 1.5.6 driver, and upgraded to the 1.7.11 driver and latest firmware to resolve. This has introduced the Malicious Driver Event issue, causing us downtime this morning and causing us to remove the X710 NICs from our vSwitch and run on 1GbE NICs. Appreciate any advice.
Kind regards,
Kye
Hi,
We have several HP DL380Gen9 with x520 10Gb NIC, and use CentOS. After Update CentOS 7.2 to 7.4, we found same SFP+ module (HP 10Gb SR SFP+) behave differently:
1, Centos 7.2+ixgbe 5.3.7: SFP+ Module works fine.
2, CentOS 7.4+ixgbe 5.3.7: SFP+ Module doesnot work. The value of comp_codes_10g/comp_codes_1g in ixgbe_identify_sfp_module_generic of ixgbe driver is zero, and cause the SFP+ modules cannot be identified.
By comparison test, we also found:
1, Using allow_unsupported_sfp param cannot fix this problem.
2, Using CentOS 7.4+x520+other SFP+ module(from HPE or other vendor), SFP+ Module can work fine.
These make us very confused and wanna to know:
1, the reason of comp_codes_10g/comp_codes_1g becomes zero.
2, how fix this problem.
3, is it related to kernel or driver.
Any ideas and suggestions will be appreciated, Tks a lot!
Team and VLAN configuration for Microsoft Windows* 10 1809 (RS5) and Microsoft Windows* Server 2019 will be available in SW Release 23.5.
SW Release 23.5 is expected in November of 2018.
Note: Prior to the release of SW 23.5, we will be releasing SW 23.4. Please be aware that 23.4 does not support Microsoft Windows* 10 1809 (RS5) and Microsoft Windows* Server 2019.
The Intel Ethernet team is responsible for validating and submitting new driver packages to Microsoft for inclusion on Windows Update. Microsoft does not support Team and VLAN configuration on Window 10. Team and VLAN configuration for Intel Ethernet Adapters on Windows 10 is supported via our Intel® PROSet software. Intel® PROSet is not included on Microsoft Windows Update.
Intel® PROSet software includes Intel® PROSet for Windows* Device Manager, Intel® PROSet for Windows PowerShell*, and with SW Release 23.5 Intel® PROSet Adapter Configuration Utility (Intel® PROSet ACU).
SW Release 23.5 will support Advanced Network Services (ANS) including Team and VLAN configurations using PROSet for Windows PowerShell* and in a later release will be supported using Intel® PROSet ACU.
Information on using PROSet for Windows PowerShell* is available here: Intel PowerShell IntelNetcmdlets and also available in the Intel® Ethernet Adapter User Guide which is included in each driver download package on Intel Download Center
This community will be updated with a SW Release FAQ when SW Release 23.5 is available for download.
We appreciate your patience while we continue to validate this upcoming SW release.
Thank You,
Intel Ethernet Team.
Hello,
I just received the new Windows 10 Fall Update (RS5 - 1809) and as with every new Windows 10 feature update the Teaming functionality is broken.
Intel please tell us when we can expect a new network driver release?
I my case I am using a dual port Intel x520 DA NIC.
Thanks,
Christian
We added a new node to our cluster and we've got 2 of the Intel X710-T4 cards in the server. Both of our SANs are currently only 1Gb (we have a Tegile T3100 and a Lenovo px12-450r). Whenever i try to setup SAN connections using one of the ports on these NICs it causes all sorts of issues. We have CSVs go offline and report being corrupted and unreadable, we've lost VM configs and VMs stop booting from any volumes that are being hosted by this node (2016 Hyper V cluster). The odd part is that this same node was working fine in our 2012 cluster before we updated/migrated into 2016. I have the latest drivers for the adapter. Here are some things that have happened:
- When I initially brought the node into the cluster I configured all 3 connections to the SANs using the X710-T4 (2 for the tegile for each independent switch/controller and 1 for the lenovo which is directly connected). Right off the bat each time this node took ownership of either volume on the Lenovo the VMs that were on that volume would no longer boot. They would give different weird boot errors and eventually it would even hard lock the Lenovo SAN itself and I'd have to hard boot it. I moved that connection down to the onboard broadcom 1Gb NIC and that solved those issues. The tegile was still connected via the X710-T4 and while it continued to operate, some odd things happened here as well. Sometimes the list of connected iSCSI devices would just be blank on that node even though it was still operating. In the latest case the node took ownership of a LUN from the Tegile and immediately all the VMs on that LUN stopped working and the CSV reported as corrupt and unreadable. I moved the CSV to another node and after a while it finally started working again. Problem is this node insists on taking ownership of storage nodes and there doesnt appear to be a way to stop it (cant set node preferences on CSVs). So right now I'm scared to unpause this node and am contemplating just moving the Tegile connections into the broadcom as well and hopefully avoid all the hassle.... but when we eventually do upgrade our SAN and go 10Gb I dont want to run into this issue again.
I realize this is probably incredibly hard to decipher... at this point I'm just looking for suggestions. Is it one of the adapter properties? The adapters that connect to the SANs have all protocols except IPv4 unchecked, they have jumbo frames set to 9014 and they are set to not allow the OS to turn them off (power saving thing). Aside from that they are basically at default settings. I think I could probably disable SRV-IO on these adapters but is that causing my issue (I doubt it). Let me know what you think!
I an having difficulty in upgrading my NIC drivers from version 17.3.0 to 22.7.1. The workstation I am using is running Windows 10.
Here is what I am trying to install:
When I run the install program, I get the following message:
Ok, it sounds simple enough. I run the Intel utility to uninstall version 17.3.0, then I do the install of 22.7.1.
Doing the uninstall removes the NICs from the Device Manager, and I get an error message that 22.7.1 can't install since it cannot find any NIC in Device Manager.
If I do the uninstall and then reboot, Windows automatically installs the Microsoft drivers.
The install of 22.7.1 gives the same error message about no support for upgrades.
The though has occurred to me that these are Windows 8 drivers, not Windows 10 drivers.
The driver downloads for the 82574L NIC did not show any Windows 10 drivers.
Any assistance would be greatly appreciated.
Hi,
I have an Intel NUC7i3BNH with the I219V ethernet controller which is 802.1AS compliant according to its datasheet.
I am trying to use it with ptp4l and a gPTP profile but I get really high propagation delays in the range of 7μs when connected directly to an I210 device or Extreme x440-48t switch. This is very high for hardware timestamping. For reference, the I210 has a propagation delay of around 20ns when connected to the switch or another I210. The gPTP profile needs a propagation delay below 800ns to be considered AS capable.
I tried updating the e1000e drivers to version 3.4.1.1-NAPI but results were the same.
I am using Ubuntu 18.04.1 LTS and 4.13.0-45-generic kernel.
Why is the propagation delay so high and what can I do to fix it? Is the I219V actually 802.1AS compliant?
Thanx,
Andre.
I have a single board computer with two I210 adapters each connected to a different switch. The adapters are in an ALB team with RLB enabled. Only one adapter is active and connection requests that come to the other adapter from the other switch fail.
Is there a way to make both adapters in the team active?
Thanks.
I had a pair of I210 NICs (a dual-NIC motherboard) teamed via Static Link Aggregation and all was working fine until today when Windows 10 x64 decided to apply the April 2018 cumulative update. The page providing the respective drivers with ANS support (https://downloadcenter.intel.com/download/25016/Intel-Network-Adapter-Driver-for-Windows-10?product=64399) states that the latest version is 23.1 (dated 2018-02-21). Even with this latest driver, however, I can re-create the team, but it cannot be enabled. The only way to keep things in a sort of working state is to disable one of the NICs as well as the virtual team interface and keep only the other NIC active (i.e., not an ideal scenario).
Is there any chance that a new version of the driver will be available soon?
Thanks.
nvx
This issue was covered here but was NOT resolved and mark answered by accident.
VLANs disabled in Windows 10 Build 17133.1 Version 1803
My steps were as follows
In conclusion, the latest Intel NIC driver 23.1 seems fine but there is something wrong with Windows 10 Build 17133.1 Version 1803 Springs Creators Update, aka Redstone 4.
Hi, i have a question:
I have windows 10, and when i go to "show network property" , it says Maximum trasmission unit: 1500
my pc is connected with a modem , that is connected to a PPPoE LLC connection, and use MTU = 1492 not 1500
Should i change this setting on my computer? How i have to change it?
Thanks you, and sorry for my bad english
Hello
I'm running Supermicro X11SSL-F motherboard with networking adapter Inter i210-AT
Next issue is faced after updating motherboard BIOS to latest version (2.2) -- with Windows Server 2012 R2 is being used -- network adapter becoming unstable after 10-14 GB of transmitted data. It either stop sending\receiveing data (like buffer overflow) or drops connection at all.
Tried recommendations, described in document TA-201, tried disable TCP offloading, tuning down to lower link speed, disabling power saving features - no luck, until restart system refuses to transmit big amounts of data, while may be still available sometimes via RDP (or sometimes starting to drop packets completely). Disabling\enabling adapter on running system has no effect.
Basically, I'm runned out of ideas. Main suggestion was a faulty BIOS update, but issue does not reproducing on Linux (Debian\Centos\Ubuntu), so this seems to be more driver issue.
OS: Windows Server 2012 R2, build 9600
Driver package version: 23.2
Driver version (from device properties) - 12.14.7.0, date 11/3/2017
Please advice.
Hi,
I have tried this card on two different computers:
- one with a MSI Z87-G43 motherboard with an integrated Realtek RTL8111E chip
- a Dell EliteDesk 800 G1 PC with an integrated Intel I217-LM Ethernet chip
In each case, it behaved exactly the same, running Windows 10 64bit or Debian
GNU/Linux (4.18.0-1-amd64) : Wake-on-LAN works fine on the integrated
controller, and it does not work on the Intel Gigabit CT Desktop Adapter.
I have tried disabling the integrated controller, I have made sure PCI-E
wake up and S5 wake up options were set properly in the UEFI setup tool, I have
tried multiple BIOS/UEFI firmware versions, including latest available.
I also tried every possible option in the Intel BootUtil tool (made sure WoL
is enabled, tried every available Option ROM (PXE/UEFI/Combo).
And in each case, I have the same result: link goes down on the Gigabit CT
Adapter as soon as the system goes to suspend or shutdown, and cannot be woken
up through this interface, but the other one works (unless disabled, of course).
So, is WoL actually supposed to work ? Is there something I overlooked ?
Something else I could try ?
Thanks in advance,
Alex
Will ver 6.08 be released anytime soon?
The primary issue is after several hours to upwards of a couple weeks a single VF will get into a bad state for a guest and we will see the following errors on the parent and child.
Versions:
Centos = 7.5.1804
Kernel = 4.4.121-1.el7.centos.x86_64 (Current); Tried 3.10.0, 4.4.75, 4.9.52, 4.14.68
IXGBE = 5.3.7 (Current); Tried 5.3.5, 4.2.1-k, ......
IXGBEVF = 4.3.5 (Current); Tried 2.12.1-k, ....
QEMU = 1.5.3 (Current); Tried 2.0.0
Libvirt = 3.9.0 (Current)
On the parent we will see this error:
ixgbe 0000:05:00.0 ethx: 193 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 45 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 3 Spoofed packets detected
ixgbe 0000:05:00.0 ethx: 126 Spoofed packets detected
On the child you will see an increase in dropped packets.
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 52:54:00:5e:a9:f8 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
455429589913 520093667 0 375674 0 375680
TX: bytes packets errors dropped carrier collsns
463147231075 514071570 0 0 0 0
I don't have a way to view the spoofed packets going out, but I can see the incoming packets getting corrupted and dropped by the guest. Best example is an ARP since it will hit every parent, child. (IPs censored)
Parent capture:
10:36:26.492879 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46
10:36:26.540880 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has BBB.BBB.BBB.BBB tell XXX.XXX.XXX.XXX, length 46
10:36:26.553161 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has AAA.AAA.AAA.AAA tell XXX.XXX.XXX.XXX, length 46
10:36:26.559508 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46
Child Capture:
10:36:26.501491 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has ZZZ.ZZZ.ZZZ.ZZZ tell XXX.XXX.XXX.XXX, length 46
10:36:26.549499 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46
0x0000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
10:36:26.561776 00:00:00:00:00:00 > 00:00:00:00:00:00, 802.3, length 0: LLC, dsap Null (0x00) Individual, ssap Null (0x00) Command, ctrl 0x0000: Information, send seq 0, rcv seq 0, Flags [Command], length 46
0x0000: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
10:36:26.568122 02:00:00:00:00:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has YYY.YYY.YYY.YYY tell XXX.XXX.XXX.XXX, length 46
During the time this one VF is in a bad state, all other guests will see the same packets as the parent. The only current solution is to reboot the guest. Sometimes destroy the guest and start it back up.