It's Windows 10 2016 LTSB 1607, build 14393 using PRO Set version 22.4
The VLAN configuration tab tells me to update Windows 10, I'm using the version specified here: https://www.intel.nl/content/www/nl/nl/support/network-and-i-o/000022282.html
This is for embedded devices that won't have an internet connection, so if I need a Windows update I'd like to know which update(s).
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!
I a have Intel s2600wt motherboard this two X540-AT2 ehernet adapters. Link speed in auto negatiation is only 100mbps, then i set 1000mbps on switch or in ethernet adapter properties - link lost. My os is Windows Server 2012 R2 and my switch is Cisco 6509 running on ios version 15.1(2)SY9. Also i tried Cisco 2960G with ios Version 15.0(2)SE8 this same result.
What installs it and is it relevant with Intel Network Connections 21.1.30.0? We are very security conscience and want to remove this software if it has no purpose. I am wondering if this was installed by an older version of Intel Network Connections and is no longer needed. Is this just a registry file that can be removed?
HI Everyone,
We are using XL710 hardware on Linux 4.1.20 kernel.
We have an issue where the following behavior is noticed.
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
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 ?
Hi!
There is a dual E5-2690v3 box based on Supermicro SYS-2028GR-TR/X10DRG-H, BIOS 1.0c, running Ubuntu 16.04.1, w. all current updates.
It has a XL710-QDA2 card, fw 5.0.40043 api 1.5 nvm 5.04 0x80002537, driver 1.5.25 (the stock Ubuntu i40e driver 1.4.25 resulted in a crash), that is planned to be used as an iSCSI initiator endpoint. But there seems to be a problem: the log file fills up with "RX driver issue detected" messages and occasionally the iSCSI link resets as ping times out. This is critical error, as the mounted device becomes unusable!
So, Question 1: Is there something that can be done to fix the iSCSI behaviour of the XL710 card? When testing the card with iperf (2 concurrent sessions, the other end had a 10G NIC), there were no problems. The problems started when the iSCSI connection was established.
Question 2: Is there a way to force the card to work in PCI Express 2.0 mode? The server downgraded the card once after several previous failures and then it became surprisingly stable. I cannot find a way to make it persist though.
Some excerpts from log files (there are also occasional TX driver issues, but much less frequently than RX problems):
[ 263.116057] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)
[ 321.030246] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 332.512601] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
..lots of the above messages...
[ 481.001787] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 487.183237] NOHZ: local_softirq_pending 08
[ 491.151322] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
..lots of the above messages...
[ 1181.099046] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 1199.852665] connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4295189627, last ping 4295190878, now 4295192132
[ 1199.852694] connection1:0: detected conn error (1022)
[ 1320.412312] session1: session recovery timed out after 120 secs
[ 1320.412325] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412331] sd 10:0:0:0: [sdk] killing request
[ 1320.412347] sd 10:0:0:0: [sdk] FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 1320.412352] sd 10:0:0:0: [sdk] CDB: Write Same(10) 41 00 6b 40 69 00 00 08 00 00
[ 1320.412356] blk_update_request: I/O error, dev sdk, sector 1799383296
[ 1320.412411] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412423] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412428] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412433] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412438] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412442] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412446] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412451] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412455] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412460] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412464] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412469] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412473] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412477] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412482] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412486] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412555] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412566] Aborting journal on device sdk-8.
[ 1320.412571] sd 10:0:0:0: rejecting I/O to offline device
[ 1320.412576] JBD2: Error -5 detected when updating journal superblock for sdk-8.
[ 1332.831851] sd 10:0:0:0: rejecting I/O to offline device
[ 1332.831864] EXT4-fs error (device sdk): ext4_journal_check_start:56: Detected aborted journal
[ 1332.831869] EXT4-fs (sdk): Remounting filesystem read-only
[ 1332.831873] EXT4-fs (sdk): previous I/O error to superblock detected
Unloading the kernel module and modprobe-ing it again:
[ 1380.970732] i40e: Intel(R) 40-10 Gigabit Ethernet Connection Network Driver - version 1.5.25
[ 1380.970737] i40e: Copyright(c) 2013 - 2016 Intel Corporation.
[ 1380.987563] i40e 0000:81:00.0: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0
[ 1381.127289] i40e 0000:81:00.0: MAC address: 3c:xx:xx:xx:xx:xx
[ 1381.246815] i40e 0000:81:00.0 p5p1: renamed from eth0
[ 1381.358723] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None
[ 1381.416135] i40e 0000:81:00.0: PCI-Express: Speed 8.0GT/s Width x8
[ 1381.454729] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA
[ 1381.471584] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0
[ 1381.605866] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xy
[ 1381.712287] i40e 0000:81:00.1 p5p2: renamed from eth0
[ 1381.751417] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready
[ 1381.810607] IPv6: ADDRCONF(NETDEV_UP): p5p2: link is not ready
[ 1381.820095] i40e 0000:81:00.1: PCI-Express: Speed 8.0GT/s Width x8
[ 1381.826141] i40e 0000:81:00.1: Features: PF-id[1] VFs: 64 VSIs: 66 QP: 48 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA
[ 1647.123056] EXT4-fs (sdk): recovery complete
[ 1647.123414] EXT4-fs (sdk): mounted filesystem with ordered data mode. Opts: (null)
[ 1668.179234] NOHZ: local_softirq_pending 08
[ 1673.994586] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 1676.871805] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 1692.833097] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 1735.179086] NOHZ: local_softirq_pending 08
[ 1767.357902] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
[ 1803.828762] i40e 0000:81:00.0: RX driver issue detected, PF reset issued
After several failures, the card loaded in PCI-Express 2.0 mode. It became stable then:
Jan 1 18:44:35 systemd[1]: Started ifup for p5p1.
Jan 1 18:44:35 systemd[1]: Found device Ethernet Controller XL710 for 40GbE QSFP+ (Ethernet Converged Network Adapter XL710-Q2).
Jan 1 18:44:35 NetworkManager[1911]: <info> [1483289075.5028] devices added (path: /sys/devices/pci0000:80/0000:80:01.0/0000:81:00.0/net/p5p1, iface: p5p1)
Jan 1 18:44:35 NetworkManager[1911]: <info> [1483289075.5029] locking wired connection setting
Jan 1 18:44:35 NetworkManager[1911]: <info> [1483289075.5029] get unmanaged devices count: 3
Jan 1 18:44:35 avahi-daemon[1741]: Joining mDNS multicast group on interface p5p1.IPv4 with address xx.xx.xx.xx.
Jan 1 18:44:35 avahi-daemon[1741]: New relevant interface p5p1.IPv4 for mDNS.
Jan 1 18:44:35 NetworkManager[1911]: <info> [1483289075.5577] device (p5p1): link connected
Jan 1 18:44:35 avahi-daemon[1741]: Registering new address record for xx.xx.xx.xx on p5p1.IPv4.
Jan 1 18:44:35 kernel: [11572.541797] i40e 0000:81:00.0 p5p1: NIC Link is Up 40 Gbps Full Duplex, Flow Control: None
Jan 1 18:44:35 kernel: [11572.579303] i40e 0000:81:00.0: PCI-Express: Speed 5.0GT/s Width x8
Jan 1 18:44:35 kernel: [11572.579309] i40e 0000:81:00.0: PCI-Express bandwidth available for this device may be insufficient for optimal performance.
Jan 1 18:44:35 kernel: [11572.579312] i40e 0000:81:00.0: Please move the device to a different PCI-e link with more lanes and/or higher transfer rate.
Jan 1 18:44:35 kernel: [11572.617328] i40e 0000:81:00.0: Features: PF-id[0] VFs: 64 VSIs: 66 QP: 48 RX: 1BUF RSS FD_ATR FD_SB NTUPLE DCB VxLAN Geneve PTP VEPA
Jan 1 18:44:35 kernel: [11572.635294] i40e 0000:81:00.1: fw 5.0.40043 api 1.5 nvm 5.04 0x80002537 0.0.0
Jan 1 18:44:35 kernel: [11572.917343] i40e 0000:81:00.1: MAC address: 3c:xx:xx:xx:xx:xx
Jan 1 18:44:35 systemd[1]: Reloading OpenBSD Secure Shell server.
Jan 1 18:44:35 systemd[1]: Reloaded OpenBSD Secure Shell server.
Jan 1 18:44:35 kernel: [11572.921344] i40e 0000:81:00.1: SAN MAC: 3c:xx:xx:xx:xx:xx
Jan 1 18:44:35 NetworkManager[1911]: <warn> [1483289075.9656] device (eth0): failed to find device 14 'eth0' with udev
Jan 1 18:44:35 NetworkManager[1911]: <info> [1483289075.9671] manager: (eth0): new Ethernet device (/org/freedesktop/NetworkManager/Devices/13)
Jan 1 18:44:35 kernel: [11572.976596] i40e 0000:81:00.1 p5p2: renamed from eth0
Kind regards,
jpe
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?
Hello All,
We have been trying to make Unicast promiscuous mode work with RHEL7.3 with latest native ixgbe driver (ixgbe-5.1.3), but it seems that unicast promiscuous mode is not enabled for 82599 series nic cards in the native driver.
I can see an explicit check in ixgbe_sriov.c code, where before enabling promiscuous mode, it checks if NIC card is equal(or lower) than 82599EB, it returns.
Adding snippet below:
case IXGBEVF_XCAST_MODE_PROMISC:
if (hw->mac.type <= ixgbe_mac_82599EB)
return -EOPNOTSUPP;
fctrl = IXGBE_READ_REG(hw, IXGBE_FCTRL);
if (!(fctrl & IXGBE_FCTRL_UPE)) {
/* VF promisc requires PF in promisc */
e_warn(drv,
"Enabling VF promisc requires PF in promisc\n");
return -EPERM;
}
disable = 0;
enable = IXGBE_VMOLR_BAM | IXGBE_VMOLR_ROMPE |
IXGBE_VMOLR_MPE | IXGBE_VMOLR_UPE | IXGBE_VMOLR_VPE;
break;
But, when I see the corresponding code in DPDK16.11 version, I can see the support has been added for 82599 NICs family. The feature seems to have implemented using IXGBE_VMOLR_ROPE flag.
Relevant snippet from DPDK code:
uint32_t
ixgbe_convert_vm_rx_mask_to_val(uint16_t rx_mask, uint32_t orig_val)
{
uint32_t new_val = orig_val;
if (rx_mask & ETH_VMDQ_ACCEPT_UNTAG)
new_val |= IXGBE_VMOLR_AUPE;
if (rx_mask & ETH_VMDQ_ACCEPT_HASH_MC)
new_val |= IXGBE_VMOLR_ROMPE;
if (rx_mask & ETH_VMDQ_ACCEPT_HASH_UC)
new_val |= IXGBE_VMOLR_ROPE;
if (rx_mask & ETH_VMDQ_ACCEPT_BROADCAST)
new_val |= IXGBE_VMOLR_BAM;
if (rx_mask & ETH_VMDQ_ACCEPT_MULTICAST)
new_val |= IXGBE_VMOLR_MPE;
return new_val;
}
So, can you please let us know, why such difference between supported NIC ? and can we also have similar functionality ported to the native ixgbe driver?
Other setup details
Kernel version
# uname -r
3.10.0-514.el7.x86_64
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 -i eth2
driver: ixgbe
version: 5.1.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: yes
Regards
Pratik
I was trying to install an intel pro/1000 pt dual-port card into a Ubuntu linux server computer and ran into the "NVM Checksum is Invalid" message. I tried to run the bootutil utility on the card, but now only ports 1 & 2 show and the mac addresses are gone. Is this card salvageable or is it bricked? I ordered another single-port card, but does anyone know the proper way to handle this issue?
Brian
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 !
Hi,
I have some Windows 10 1607 Pro mobile computers using the i211 ethernet adapter. The checkbox for Register this connection's address in DNS will not stay checked like every other computer we have and the DNS will not register unless I do it manually using ipconfig /registerdns. I am using the latest Intel drivers .Has anyone seen this behavior?
Thanks,
Steve
HI
I set 4000-4049 vlan filter to a vf:
for(vlanindex = 4000;vlanindex<=4049;vlanindex++)
{
diag = rte_eth_dev_vlan_filter(dev->port_id,vlanindex,1);
if (diag) {
VLOG_INFO("Interface %s vlan(%d) setup error: %s",
dev->up.name, vlanindex, rte_strerror(-diag));
return diag;
}
}
2017-07-24T04:48:34.260Z|00076|dpdk|ERR|PMD: ixgbevf_vlan_filter_set(): Unable to set VF vlan
2017-07-24T04:48:34.260Z|00077|netdev_dpdk|INFO|Interface dpdk-trunk-0000.01.10.2 vlan(4003) setup error: Network is down
The error is in a random vlan filter set
dpdk version: 16.11
Same issue as seen elsewhere with the i218-V on a dozen Lenovo e550. Rather than going to two remote locations and popping the cmos on the lot, I'd like to give the ULP enable/disable utility a try.
Hi,
I am using a Dell PowerEdge R730 with Dual Xeon, each 22 cores, with 6 ixgbe compatible cards, on which I am running Linux with ixgbe driver version 4.4.0-k, using kernel versions both 4.7.10 and 4.9.6.
I am loading the ixgbe modules at boot time, bringing up the interfaces and setting smp_affinity to the cards, using the set_irq_affinity script, so all the possible RxTx IRQs are distributed between all the available cores.
The problem is that it happens, random, but quite often that the smp_affinity setting fails, and I need manually to re-run the script one or more times in order desired settings to be applied. There were also several occasions when the settings were not applied at all, and it took me several reboots to script to start working again.
The problem appears not only randomly as occurrence, but also at random NIC controllers, so I am excluding the possibility of failed HW, since I also changed NICs.
I added some debug messages to track the affinity setting in Linux kernel, and it turns out that most of the times when the setting fails the error that affinity setting function irq_do_set_affinity returns is EBUSY, but also sometimes it returns ENOSPC.
More investigation on the topic showed whenever EBUSY was returned the problem could be overcome with re-running the script. But if the error returned was ENOSPC, it takes several reboots for the problem to disappear.
In order to provide some more details on the system I am attaching two text files with the output of the modinfo of the ixgbe and lspci on the machine.
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
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 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 !
I have an Asus Z170 Pro Gaming motherboard with the I219-V LAN port but even on a fresh Windows 7 or Windows 10 installation, the port always shows up as having the (2) prefix even though its the only LAN port available and its the first time drivers have been installed for it (for that OS installation after formatting the HDD). The driver version I'm currently using is 12.15.25.6 from earlier this year.
I'm pretty sure that at some stage I've seen it as simply Intel(R) Ethernet Connection I219-V and I'd like to get back to that but how? FWIW the hardware is working fine, I'm just fussy about my system configuration and would like this to be as originally intended.
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.