HI Everyone,

We are using XL710 hardware on Linux 4.1.20 kernel.

We have an issue where the following behavior is noticed.

• When we send a simple loop back traffic to the XL710, it works fine.
• When a specific PPPoE packet is sent from an external port to the XL710, on Linux we notice that the XL710 driver has no response. There is no interrupt is raised for this received packet.
• After the above condition, XL710 stops receiving any packet.

Here is the packet contents for a good packet and the failing packet.

I can send any number of good packets, and XL710 is able to received it.

After I send a single failing packet, XL710 stop receiving packets. In fact, it does not receive even the good packets after this.

Good Packet:

Frame 2: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.680293000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.680293000 seconds

    [Time delta from previous captured frame: 0.496532000 seconds]

    [Time delta from previous displayed frame: 0.496532000 seconds]

    [Time since reference or first frame: 0.496532000 seconds]

    Frame Number: 2

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 0.0.0.0

            Type: IP address (3)

            Length: 6

            IP Address: 0.0.0.0

Failing Packet:

Frame 1: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.183761000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.183761000 seconds

    [Time delta from previous captured frame: 0.000000000 seconds]

    [Time delta from previous displayed frame: 0.000000000 seconds]

    [Time since reference or first frame: 0.000000000 seconds]

    Frame Number: 1

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 20.6.0.23

            Type: IP address (3)

            Length: 6

            IP Address: 20.6.0.23

Regards,

Sadashivan

I encountered the same Problem.

Additional Information:

before 23.07.17 the system worked properly with windows 10 64 home.

in the eventlog of the Adapter i can find an update from 23.07.17 22:23.

Since this update windows presents after system start an Intel 82579LM insted of Intel 82579V in the device manger.

A klick on the recongnize changed hardware button solves the Problem for some time, (I didn't test if it reoccures after longer work, e.g. one hour)

But always after a system reboot or cold boot the same problem occures again.

The latest driver is installed,

Cable an router checked.

Any suggestions?

Hello,

I am new to this community. I subscribed to ask a question here because I am really stuck.

My company makes electronic devices that use UDP 100 MB Ethernet communication with a PC (under Windows 7, 8.1 or 10).

It works perfectly with other brands of Ethernet adapters; but there is a strange behavious with the Intel NICs we tried (at least I219-V, I219-LM and I217-LM).

Basically, our electronic devices can be considered as cameras capturing about 150 images per second.

We send a small command on one socket via UDP to tell it to capture an image, then we receive the compressed image as a set of UDP packets on another socket.

Each packet contains up to 1444 bytes of data (to which one can add the data from the different layers of protocols, which in the end does not exceed the standard packet size => no need to use Jumbo packets).

The problem is that, sometimes (this varies from as often as every 5 seconds to as rarely as only once within a 10-mn period), I am waiting forever (until the defined UDP time out) for the data to arrive while it has been sent (I can see it by sniffing the data from another computer connected to the same switch). I could believe that the UDP packet was lost by the Intel NIC, but it has not been lost. If I send a new image capture command, the packets that I was waiting finally arrive, followed by the packets of the new image.

Why are those packets stuck?

Is there any advanced parameter that I could modify from the device driver's configuration window or from a Registry key?

Note that I tried updating the Intel driver to recent versions (last one is 22.4.0.1). It seems to perform a little better that some other versions I tried (like the one installed by default in Windows), but none of the versions I tried work perfectly.

Many thanks in advance if you can help me understand what is wrong (either from me or from the driver). I have been struggling on this problem for months and we have to equip our customers who own a laptop with an Intel NIC with USB adapters with a NIC made by another brand to bypass the problem.

Karl

Hi Sharon and Pratik,

I have the exact same need - I have an 82599ES-based SR-IOV setup using a Mirantis Fuel 9.2 OpenStack deployment where I am trying to pass VLAN-tagged packets out of a KVM VM instance with the VLAN kept intact.  Just like Pratik, I can work with a situation where either the tag applied by the virtual machine is retained with no tag added to it on egress or (preferably) a situation where the inner tag applied by the VM is preserved and an outer tag is added by the network adapter.

I have a full lab environment set up to test this and I will be compiling both drivers. However, I'm curious if there is a specific fix that addresses this issue and if you have any additional information on what behavior I should expect. Will the ixgbe 5.1 driver and the ixgbevf 4.1 driver allow both of the situations I described, i.e. either one tag or double tags leaving the VM?  Thank you for any clarification you can provide,

A.C.

******

I have the same problem with kernel 4.4.77, ixgbe driver version 5.2.1 and ixgbevf 4.2.1. OS ALT Linux.

Spoof cheking was disabled, but no ping in two VM with the same vlan.

dmesg host:

[162311.173561] ixgbe 0000:05:00.1 eth0: 2 Spoofed packets detected

[162313.177679] ixgbe 0000:05:00.1 eth0: 1 Spoofed packets detected

[162315.181748] ixgbe 0000:05:00.1 eth0: 2 Spoofed packets detected

[162333.211099] ixgbe 0000:05:00.1 eth0: 1 Spoofed packets detected

[162337.217085] ixgbe 0000:05:00.1 eth0: 1 Spoofed packets detected

[162339.220074] ixgbe 0000:05:00.1 eth0: 2 Spoofed packets detected

# ip li show eth0

7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq master ovs-system state UP mode DEFAULT group default qlen 1000

    link/ether a0:36:9f:25:80:5e brd ff:ff:ff:ff:ff:ff

    vf 0 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 1 MAC da:55:a4:db:0f:d5, spoof checking off, link-state auto, trust off, query_rss off

    vf 2 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 3 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 4 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 5 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 6 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 7 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 8 MAC 9a:1f:86:df:b1:d8, spoof checking off, link-state auto, trust off, query_rss off

    vf 9 MAC aa:b7:85:e1:1b:06, spoof checking off, link-state auto, trust off, query_rss off

    vf 10 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

    vf 11 MAC 9a:1f:86:df:b1:d8, spoof checking off, link-state auto, trust off, query_rss off

    vf 12 MAC aa:b7:85:e1:1b:06, spoof checking off, link-state auto, trust off, query_rss off

    vf 13 MAC 00:00:00:00:00:00, spoof checking off, link-state auto, trust off, query_rss off

I'm trying to configure Wake on Lan on my Windows 10 Pro 64bit HP Pavilion Elite HPE.  I've configured my "lesser" machines just fine, but this one has the 82567V-2 gigabit card which doesn't show any wake on magic packet options in advanced properties.  I've tried many different options but the card still won't stay awake when powered down.  I have unchecked allow the computer to power it down, enabled wake on lan in bios, disabled fast boot and hibernate.  Driver is up to date from windows update. I also searched for a specific driver on intel's website but there isn't one for Windows 10 64 bit.  Your help is appreciated.  Thank you.

Hi Intel comunity,

We have serious problem with intel cards (X710 and XL170). 

The linux server (Dell Power Edge 630) don’t see them completely under RedHat 7.2. I dont see the interfaces under linux ifconfig -a.

I have installed the last drivers (ixgbe-5.1.3 and i40e-2.0.26) but didnt succedded to update the firmware (if it is the problem).

Here below the output of my server:

• From "modinfo" I get the following output:

[root@TBOS ~]# modinfo i40e

filename: /lib/modules/3.10.0-327.el7.x86_64/updates/drivers/net/ethernet/intel/i40e/i40e.ko

version: 2.0.26

license: GPL

description: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver

author: Intel Corporation, <e1000-devel@lists.sourceforge.net>

rhelversion: 7.2

srcversion: F49696A466EC36F89F8FE86

alias: pci:v00008086d0000158Bsv*sd*bc*sc*i*

alias: pci:v00008086d0000158Asv*sd*bc*sc*i*

alias: pci:v00008086d000037D3sv*sd*bc*sc*i*

alias: pci:v00008086d000037D2sv*sd*bc*sc*i*

alias: pci:v00008086d000037D1sv*sd*bc*sc*i*

alias: pci:v00008086d000037D0sv*sd*bc*sc*i*

alias: pci:v00008086d000037CFsv*sd*bc*sc*i*

alias: pci:v00008086d000037CEsv*sd*bc*sc*i*

alias: pci:v00008086d0000374Csv*sd*bc*sc*i*

alias: pci:v00008086d00001588sv*sd*bc*sc*i*

alias: pci:v00008086d00001587sv*sd*bc*sc*i*

alias: pci:v00008086d00001589sv*sd*bc*sc*i*

alias: pci:v00008086d00001586sv*sd*bc*sc*i*

alias: pci:v00008086d00001585sv*sd*bc*sc*i*

alias: pci:v00008086d00001584sv*sd*bc*sc*i*

alias: pci:v00008086d00001583sv*sd*bc*sc*i*

alias: pci:v00008086d00001581sv*sd*bc*sc*i*

alias: pci:v00008086d00001580sv*sd*bc*sc*i*

alias: pci:v00008086d00001574sv*sd*bc*sc*i*

alias: pci:v00008086d00001572sv*sd*bc*sc*i*

depends: ptp,vxlan

vermagic: 3.10.0-327.el7.x86_64 SMP mod_unload modversions

parm: debug:Debug level (0=none,...,16=all) (int)

[root@TBOS ~]#

• From ifconfig –a, we don’t see the port at all !!!

• When I want to update the firmware, I get
  • [root@TBOS Linux_x64]# ./nvmupdate64e

Intel(R) Ethernet NVM Update Tool

NVMUpdate version 1.28.19.4

Copyright (C) 2013 - 2016 Intel Corporation.

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.

Inventory in progress. Please wait [*|........]

Num Description Ver. DevId S:B    Status

=== ======================================== ===== ===== ====== ===============

01) Intel(R) Ethernet Converged Network 1572 00:004 Access error

Adapter X710

Tool execution completed with the following status: Device not found

Press any key to exit.

• Dmesg output:

[root@TBOS ~]# dmesg| grep i40

[ 3.549403] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 2.0.26

[ 3.549405] i40e: Copyright(c) 2013 - 2017 Intel Corporation.

[ 3.578751] i40e 0000:04:00.0: fw 4.33.31377 api 1.2 nvm 4.41 0x80001869 16.5.10

[ 3.578754] i40e 0000:04:00.0: The driver for the device detected an older version of the NVM image than expected. Please update the NVM image.

[ 3.822134] i40e 0000:04:00.0: MAC address: 3c:fd:fe:0c:cb:e0

[    3.835115] i40e 0000:04:00.0: Query for DCB configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

[ 3.835118] i40e 0000:04:00.0: DCB init failed -53, disabled

[ 3.835166] i40e 0000:04:00.0: irq 91 for MSI/MSI-X

…..

[ 3.836118] i40e 0000:04:00.0: irq 148 for MSI/MSI-X

[ 4.050907] i40e 0000:04:00.0: Added LAN device PF0 bus=0x04 dev=0x00 func=0x00

[ 4.050912] i40e 0000:04:00.0: PCI-Express: Speed 8.0GT/s Width x8

[ 4.080877] i40e 0000:04:00.0: Features: PF-id[0] VFs: 32 VSIs: 34 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN Geneve NVGRE PTP VEPA

[ 4.094861] i40e 0000:04:00.1: fw 4.33.31377 api 1.2 nvm 4.41 0x80001869 16.5.10

[ 4.094864] i40e 0000:04:00.1: The driver for the device detected an older version of the NVM image than expected. Please update the NVM image.

[ 4.339689] i40e 0000:04:00.1: MAC address: 3c:fd:fe:0c:cb:e2

[    4.349612] i40e 0000:04:00.1: Query for DCB configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

[ 4.349615] i40e 0000:04:00.1: DCB init failed -53, disabled

[ 4.349684] i40e 0000:04:00.1: irq 150 for MSI/MSI-X

……

[ 4.350710] i40e 0000:04:00.1: irq 207 for MSI/MSI-X

[ 4.499464] i40e 0000:04:00.1: Added LAN device PF1 bus=0x04 dev=0x00 func=0x01

[ 4.499469] i40e 0000:04:00.1: PCI-Express: Speed 8.0GT/s Width x8

[ 4.529440] i40e 0000:04:00.1: Features: PF-id[1] VFs: 32 VSIs: 34 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN Geneve NVGRE PTP VEPA

[ 4.543425] i40e 0000:04:00.2: fw 4.33.31377 api 1.2 nvm 4.41 0x80001869 16.5.10

[ 4.543427] i40e 0000:04:00.2: The driver for the device detected an older version of the NVM image than expected. Please update the NVM image.

[ 4.989984] i40e 0000:04:00.2: MAC address: 3c:fd:fe:0c:cb:e4

[ 5.000011] i40e 0000:04:00.2: Query for DCB configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

[ 5.000014] i40e 0000:04:00.2: DCB init failed -53, disabled

[ 5.000085] i40e 0000:04:00.2: irq 208 for MSI/MSI-X

…..

[ 5.001379] i40e 0000:04:00.2: irq 265 for MSI/MSI-X

[ 5.228749] i40e 0000:04:00.2: Added LAN device PF2 bus=0x04 dev=0x00 func=0x02

[ 5.228754] i40e 0000:04:00.2: PCI-Express: Speed 8.0GT/s Width x8

[ 5.263716] i40e 0000:04:00.2: Features: PF-id[2] VFs: 32 VSIs: 34 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN Geneve NVGRE PTP VEPA

[ 5.277703] i40e 0000:04:00.3: fw 4.33.31377 api 1.2 nvm 4.41 0x80001869 16.5.10

[ 5.277705] i40e 0000:04:00.3: The driver for the device detected an older version of the NVM image than expected. Please update the NVM image.

[ 5.566417] i40e 0000:04:00.3: MAC address: 3c:fd:fe:0c:cb:e6

[ 5.576408] i40e 0000:04:00.3: Query for DCB configuration failed, err I40E_ERR_ADMIN_QUEUE_ERROR aq_err I40E_AQ_RC_EPERM

[ 5.576411] i40e 0000:04:00.3: DCB init failed -53, disabled

[ 5.576487] i40e 0000:04:00.3: irq 266 for MSI/MSI-X

……

[ 5.577839] i40e 0000:04:00.3: irq 323 for MSI/MSI-X

[ 5.725374] i40e 0000:04:00.3: Added LAN device PF3 bus=0x04 dev=0x00 func=0x03

[ 5.725383] i40e 0000:04:00.3: PCI-Express: Speed 8.0GT/s Width x8

[ 5.755339] i40e 0000:04:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF VxLAN Geneve NVGRE PTP VEPA

[   67.004064] i40e 0000:04:00.0: removed PHC from p2p1

[   67.040316] i40e 0000:04:00.0: Deleted LAN device PF0 bus=0x04 dev=0x00 func=0x00

[   70.039865] i40e 0000:04:00.1: removed PHC from p2p2

[   70.070096] i40e 0000:04:00.1: Deleted LAN device PF1 bus=0x04 dev=0x00 func=0x01

[   73.240777] i40e 0000:04:00.2: removed PHC from p2p3

[   73.279308] i40e 0000:04:00.2: Deleted LAN device PF2 bus=0x04 dev=0x00 func=0x02

[   74.650315] i40e 0000:04:00.3: removed PHC from p2p4

[   74.690215] i40e 0000:04:00.3: Deleted LAN device PF3 bus=0x04 dev=0x00 func=0x03

[root@TBOS ~]#

• From lspci| egrep -i "Network|Ethernet" we see the following output:
  • 04:00.0 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
  • 04:00.1 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
  • 04:00.2 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)
  • 04:00.3 Ethernet controller: Intel Corporation Ethernet Controller X710 for 10GbE SFP+ (rev 01)

Please help ...

Thanks

Hi:

I am using the i40e_4.4.0 driver for XL710 Network Card. Currently, I am trying to loopback the connections.

For this purpose, I had to set the two ports on promiscuous mode. Thus, using my application, I crated custom UDP packets.

For the Rx Queue setting, I have set the flow director as:

ethtool -N ens1f0 flow-type udp4 dst-port 319 action 3 loc

ethtool -N ens1f1 flow-type udp4 dst-port 319 action 3 loc

Essentially, I want all the packets with this dst-port to be forwarded to Queue 3. I can also see the rule has been inserted.

But, as seen in the attached picture, the flow director is not able to match the incoming packet. Thus, it does not forward the incoming packet to my desired queue.

Is this error due to promiscuous mode that I had set on the NIC ports ?

I am not sure what's creating this issue. Also, I have verified that the incoming packet is destined for Port 319.

I will be able to provide other details, if needed !

I would appreciate any help.

Thanks !

Dear Intel Ethernet Driver Experts,

The following is the good news.

In a nutshell, in the field, there was a challenge with MTU and it was blocking progress.

This is with respect to X710 and i40e driver.

Doing ethtool -r interface cleared the MTU block.

Wanted to learn in X710 i40e driver the hooks that we, Intel provided for ethtool -r.

Contact for Driver Expert will helpful.

Who is the expert contact please?

Much appreciated.

Hello,

I am new to this community. I subscribed to ask a question here because I am really stuck.

My company makes electronic devices that use UDP 100 MB Ethernet communication with a PC (under Windows 7, 8.1 or 10).

It works perfectly with other brands of Ethernet adapters; but there is a strange behavious with the Intel NICs we tried (at least I219-V, I219-LM and I217-LM).

Basically, our electronic devices can be considered as cameras capturing about 150 images per second.

We send a small command on one socket via UDP to tell it to capture an image, then we receive the compressed image as a set of UDP packets on another socket.

Each packet contains up to 1444 bytes of data (to which one can add the data from the different layers of protocols, which in the end does not exceed the standard packet size => no need to use Jumbo packets).

The problem is that, sometimes (this varies from as often as every 5 seconds to as rarely as only once within a 10-mn period), I am waiting forever (until the defined UDP time out) for the data to arrive while it has been sent (I can see it by sniffing the data from another computer connected to the same switch). I could believe that the UDP packet was lost by the Intel NIC, but it has not been lost. If I send a new image capture command, the packets that I was waiting finally arrive, followed by the packets of the new image.

Why are those packets stuck?

Is there any advanced parameter that I could modify from the device driver's configuration window or from a Registry key?

Note that I tried updating the Intel driver to recent versions (last one is 22.4.0.1). It seems to perform a little better that some other versions I tried (like the one installed by default in Windows), but none of the versions I tried work perfectly.

Many thanks in advance if you can help me understand what is wrong (either from me or from the driver). I have been struggling on this problem for months and we have to equip our customers who own a laptop with an Intel NIC with USB adapters with a NIC made by another brand to bypass the problem.

Karl

Hi, I have several X710-DA4 that I purchased at different times, and some of them I was able to grab the latest firmware (5.05) and upgrade them. nvmupdate64e and ethool show this on the good ones:

driver: i40e

version: 1.6.42

firmware-version: 5.05 0x8000289d 1.1568.0

bus-info: 0000:85:00.2

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.

Inventory in progress. Please wait [.........*]

Num Description                               Ver. DevId S:B    Status

=== ======================================== ===== ===== ====== ===============

01) Intel(R) Ethernet Converged Network       5.05  1572 00:004 Up to date

    Adapter X710-4

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       5.05  1572 00:133 Up to date

    Adapter X710-4

On the other box, it will not let me upgrade:

driver: i40e

version: 2.0.23

firmware-version: 4.10 0x800011c5 0.0.0

bus-info: 0000:01:00.1

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

WARNING: To avoid damage to your device, do not stop the update or reboot or power off the system during this update.

Inventory in progress. Please wait [|.........]

Num Description                               Ver. DevId S:B    Status

=== ======================================== ===== ===== ====== ===============

01) Intel(R) Ethernet Converged Network       4.10  1572 00:001 Update not

    Adapter X710-4                                              available

02) Intel(R) I350 Gigabit Network Connection  1.99  1521 00:129 Update not

                                                                available

03) Intel(R) Ethernet Converged Network       4.10  1572 00:130 Update not

    Adapter X710-4                                              available

Does anyone know what's wrong?

hi, i would like to report that the new intel nic drivers version 19.3 that just released recently has huge 6000+ dpc latency spike once in a few secs.

my specs

Intel(R) 82579LM Gigabit Network Connection

windows 7 SP1 32bit + lastest windows update

i downgrade to intel nic drivers previous version 19.1 and the problem is just gone.

Hi All,

  We have "Intel Ethernet Converged Network Adapter XL710-QDA2".

  1) Configured in 2x40 mode

  2) The two ports on the board are connected back to back with below SFP:

        MACROREER

        40GBase-CU QSFP+ Cable 1m

      We are able to observe that the link status on both ports is UP. And, we are able to run tests between the ports.

  3) When we use the below Intel SFP's on both ports connected with MTP 24 fibre optical cable, the ports are not coming UP (Link status shows down)

        E40GQSFPSR

        QSFP-40G-SR4  16-26

        Class 1  21CFR1040.10

        LN#50 6/2007

        FTL410QE2C-IT

     Please help us in understanding why the ports are not coming up with the above mentioned Intel SPF's (point 3).

Is the optical cable we are using compatible with the SPF's or need to use some other optical cable or SFP to bring the ports UP?

Should we configure the board in any specific mode ?

Looking ahead for your response

Thanks in advance

-- Anand Prasad

Dear all,

I have a Intel Nic 10 Gb X540-T2 on a Dell R610 with Windows 2012 R2.

It seams that it does not work well, I downloaded the latest drivers (22.4.0.1 - Date 16/06/2017) from Intel website but from Windows Device Manager I see another driver version and date.

In attachment the screenshot shows.

Why? How can I resolve this?

Thanks in advance

Mario

Hello,

I wonder what small-packet throughput is possible with this setup if proper configured:

OS: SLES12-SP2

Kernel: 4.4.74-92.32-default

NIC: Intel X540-T2 Dual Port 10GBaseT

Server: Lenovo System x3550 M5, 12 CPU-Cores „Intel(R) Xeon(R) CPU E5-2643 v3 @ 3.40GHz“

smp_affinity: optimized, all 12 cores are in use by the NICs IRQs

This is a loadbalancer for DNS packets. Mainly small (~80 bytes) UDP packets.

Loadbalancer is "ipvs" in DR mode. This means the kernel does only a re-routing (MAC-rewrite) of the packet and  push it back on the network (same adapter).

With this setup the server is able to process ~700kpps. At this load, all CPU cores are 100% busy (softirq).

My questions to you are, do you think this can be improved? Have we missed something?

If we direct all traffic to one single cpu core, the server is able to process already ~350kpps! Why does the system scale this bad if 12 cores are in use?

I'm grateful for every tip

Thanks

Winfried

How can the transceiver module's serial number be extracted in the pf driver ? Also is it possible to extract the transceiver serial number in the VF driver ?

Hello,
I have a problem connecting a DELL server with the INTEL X710 + SFP Intel FTLX8571D3BCVIT1 with OS Redhat 7.3, and a Junipers MX960, when we cut the port or disconnect the cable, our server says that the link Is always connected! Have you already had this type of problem because I do not understand, if any can help me stay available for more information? thank you

MAx

HI Everyone,

We are using XL710 hardware on Linux 4.1.20 kernel.

We have an issue where the following behavior is noticed.

• When we send a simple loop back traffic to the XL710, it works fine.
• When a specific PPPoE packet is sent from an external port to the XL710, on Linux we notice that the XL710 driver has no response. There is no interrupt is raised for this received packet.
• After the above condition, XL710 stops receiving any packet.

Here is the packet contents for a good packet and the failing packet.

I can send any number of good packets, and XL710 is able to received it.

After I send a single failing packet, XL710 stop receiving packets. In fact, it does not receive even the good packets after this.

Good Packet:

Frame 2: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.680293000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.680293000 seconds

    [Time delta from previous captured frame: 0.496532000 seconds]

    [Time delta from previous displayed frame: 0.496532000 seconds]

    [Time since reference or first frame: 0.496532000 seconds]

    Frame Number: 2

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 0.0.0.0

            Type: IP address (3)

            Length: 6

            IP Address: 0.0.0.0

Failing Packet:

Frame 1: 128 bytes on wire (1024 bits), 124 bytes captured (992 bits) on interface 0

    Interface id: 0 (\\.\pipe\view_capture_172-27-5-51_6_89_07182017_154149)

    Encapsulation type: Ethernet (1)

    Arrival Time: Jul 18, 2017 15:41:13.183761000 India Standard Time

    [Time shift for this packet: 0.000000000 seconds]

    Epoch Time: 1500372673.183761000 seconds

    [Time delta from previous captured frame: 0.000000000 seconds]

    [Time delta from previous displayed frame: 0.000000000 seconds]

    [Time since reference or first frame: 0.000000000 seconds]

    Frame Number: 1

    Frame Length: 128 bytes (1024 bits)

    Capture Length: 124 bytes (992 bits)

    [Frame is marked: False]

    [Frame is ignored: False]

    [Protocols in frame: eth:ethertype:mpls:pwethheuristic:pwethcw:eth:ethertype:vlan:ethertype:vlan:ethertype:pppoes:ppp:ipcp]

Ethernet II, Src: Performa_00:00:02 (00:10:94:00:00:02), Dst: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

    Destination: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        Address: DeltaNet_f9:28:42 (00:30:ab:f9:28:42)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:02 (00:10:94:00:00:02)

        Address: Performa_00:00:02 (00:10:94:00:00:02)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: MPLS label switched packet (0x8847)

MultiProtocol Label Switching Header, Label: 1 (Router Alert), Exp: 0, S: 1, TTL: 64

    0000 0000 0000 0000 0001 .... .... .... = MPLS Label: Router Alert (1)

    .... .... .... .... .... 000. .... .... = MPLS Experimental Bits: 0

    .... .... .... .... .... ...1 .... .... = MPLS Bottom Of Label Stack: 1

    .... .... .... .... .... .... 0100 0000 = MPLS TTL: 64

PW Ethernet Control Word

    Sequence Number: 0

Ethernet II, Src: Performa_00:00:03 (00:10:94:00:00:03), Dst: Superlan_00:00:01 (00:00:01:00:00:01)

    Destination: Superlan_00:00:01 (00:00:01:00:00:01)

        Address: Superlan_00:00:01 (00:00:01:00:00:01)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Source: Performa_00:00:03 (00:10:94:00:00:03)

        Address: Performa_00:00:03 (00:10:94:00:00:03)

        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)

        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: 802.1Q Virtual LAN (0x8100)

802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 100

    000. .... .... .... = Priority: Best Effort (default) (0)

    ...0 .... .... .... = CFI: Canonical (0)

    .... 0000 0110 0100 = ID: 100

    Type: PPPoE Session (0x8864)

PPP-over-Ethernet Session

    0001 .... = Version: 1

    .... 0001 = Type: 1

    Code: Session Data (0x00)

    Session ID: 0x0001

    Payload Length: 74

Point-to-Point Protocol

    Protocol: Internet Protocol Control Protocol (0x8021)

PPP IP Control Protocol

    Code: Configuration Request (1)

    Identifier: 2 (0x02)

    Length: 10

    Options: (6 bytes), IP address

        IP address: 20.6.0.23

            Type: IP address (3)

            Length: 6

            IP Address: 20.6.0.23

Regards,

Sadashivan

Hi All,

I am using RHEL7.3 with Intel-82599ES nic cards to launch VMs with SRIOV enabled nic cards. I am using configuring only one VF per PF. I am configuring this VF with vlan, trust mode on and disabling spoof chk.

But, when I am sending vlan tagged packets from Guest VM, I can see the "spoofed packet detected" message in dmesg for this PF card.

We have also disabled the rx/tx vlan offload using ethtool command.

Here are setup details:

Kernel version

# uname -r

3.10.0-514.el7.x86_64

PF/VF configuration:

# ip link show eth2

4: eth2: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 9192 qdisc mq state UP mode DEFAULT qlen 1000

    link/ether 90:e2:ba:a5:98:7c brd ff:ff:ff:ff:ff:ff

    vf 0 MAC fa:16:3e:73:12:6c, vlan 1500, spoof checking off, link-state auto, trust on

IXGBE version

# ethtool -i eth2

driver: ixgbe

version: 4.4.0-k-rh7.3

firmware-version: 0x61bd0001

expansion-rom-version:

bus-info: 0000:81:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: no

Messages from dmesg

[441100.018278] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441102.022383] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

[441104.026460] ixgbe 0000:81:00.0 eth2: 3 Spoofed packets detected

[441106.030516] ixgbe 0000:81:00.0 eth2: 2 Spoofed packets detected

LSPCI output

# lspci -nn | grep Ether | grep 82599

81:00.0 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:00.1 Ethernet controller [0200]: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)

81:10.0 Ethernet controller [0200]: Intel Corporation 82599 Ethernet Controller Virtual Function [8086:10ed] (rev 01)

Ethtool -k output

# ethtool -k eth2 | grep vlan

rx-vlan-offload: off

tx-vlan-offload: off

rx-vlan-filter: on

vlan-challenged: off [fixed]

tx-vlan-stag-hw-insert: off [fixed]

rx-vlan-stag-hw-parse: off [fixed]

rx-vlan-stag-filter: off [fixed]

Please let me know, if you any need any other information.

Regards

Pratik

Hi Sharon and Pratik,

I have the exact same need - I have an 82599ES-based SR-IOV setup using a Mirantis Fuel 9.2 OpenStack deployment where I am trying to pass VLAN-tagged packets out of a KVM VM instance with the VLAN kept intact.  Just like Pratik, I can work with a situation where either the tag applied by the virtual machine is retained with no tag added to it on egress or (preferably) a situation where the inner tag applied by the VM is preserved and an outer tag is added by the network adapter.

I have a full lab environment set up to test this and I will be compiling both drivers. However, I'm curious if there is a specific fix that addresses this issue and if you have any additional information on what behavior I should expect. Will the ixgbe 5.1 driver and the ixgbevf 4.1 driver allow both of the situations I described, i.e. either one tag or double tags leaving the VM?  Thank you for any clarification you can provide,

A.C.

******