I have pair of supermicro servers with intel x520-sr2.  With nic teaming getting 1000's of  log events per second stating it received packets on wrong nic.  Being a team I can see this as a posibilty, but does it need to flood me with messages about it ?

No matching TeamNic found for packets received from member NDISIMPLATFORM\Parameters\Adapters\

Received LACPDU on Member {27EF013E-0DD4-497E-90A2-7E5AC30E6E84}. Buffer= 0x0180C2000002C4F57C565A6F880901010114008001E0520000021904008031043D0000000214000090E2BA92F1D80000000001001F0000000310050000000000000000000000000000000...

event id 25,26, 27

drivers are the most current -

boatmn810

environment:

Redhat 7.4

ixgbe, ixgbevf  (82599es ethernet controller)

docker 1.13

requirement:

The docker container had to have a trunk port which is mapped to a VF.

docker guest running in privileged mode.

Problem:

when the container emits the q-in-q packets, the kernel drops as the packets are spoofed.

in the recv direction how can i classify based on the vlan (with no vlan interface in the container)?

Thanks for the help

Hi,

I have a XL710QDA2 40GB NIC and I also have the INTEL Ethernet QSFP+ cable. I have two problems:

1- This NIC does not get IPV4 address automatically. What should I do to force it to get IPV4 address upon boot?

2- I have tried to send packets through this NIC to other devices, but it can not forward any packet (IPV4, IPV6, or even broadcast packets). How can I enable the packet forwarding and receiving of this NIC?

Thanks for your time. I would appreciate it if you could help me out.

Best,

Marjan

Hi,

  We are observing that when Intel NIC I350 AAP (PCIE Endpoint) is used with Nvidia PCIE Root port, PCIE link fails to enter into L2 states in some cases.

Failure Scenario:

The application software initiates lower power sequence to bring the  PCIE link to enter into L2 state by first bringing the endpoint device into D3hot state followed by PME_Turn_Off request from Nvidia Root port to the endpoint device(NIC).

It is observed that  the endpoint device(NIC) does bring the link into L1 and also responds with PME_TO_ACK as expected but it does not initiate L2 entry request. So the PCIE Link (Root port) fails to enter into L2 state.

Details of the failure sequence and observations:

There seems to be some issue with the NIC I350 AAP during the L2 entry using Sequence-1 below, whereas same sequence works for the  NIC -  I350AM4. The Sequence-1 followed for the L2 entry and device details are described below.

Sequence-1 (Failing Sequence): L0 → L1 → L0 → L2/L3 Ready: Intel NIC I350 AAP Failing while   NIC - I350AM4 works fine.
1. Device is in L0 and System software directs all Functions of a Downstream component to D3hot.
2. The Downstream component then initiates the transition of the Link to L1 as required.
3. System software then causes the Root Complex to broadcast the PME_Turn_Off Message in preparation for removing the main power source.
4. This Message causes the subject Link to transition back to L0 in order to send it and to enable the Downstream component to respond with PME_TO_Ack.
5. After sending the PME_TO_Ack, the Downstream component initiates the L2/L3 Ready transition protocol. (Intel NIC I350 AAP fails in this step)

Failing Device Details :

I210T1BLK - Single Port NIC ( I350 AAP)

Date of Manufacture : 05/2014

Device 8086:1533 (rev 03)

Working Device Details :

Dual Port NIC -  I350AM4

Date of Manufacture  :  06/2013

Device 8086:1521 (rev 01)

It is also observed that bothIntel NIC I350 AAP and NIC   I350AM4 enter into L2 without any issue while following sequence-2 below.

Sequence-2 (passing sequence):
1. Device is in L0 and system software causes the Root Complex to broadcast the PME_Turn_Off Message in preparation for removing the main power source.
2. The Downstream components respond with PME_TO_Ack.
3. After sending the PME_TO_Ack, the Downstream component initiates the L2/L3 Ready transition protocol.

I am looking for help from your team if there is any known issue with Intel NIC I350 AAP related to  Link entering into L2 while following Sequence-1 describe above.

Please also suggest how can we proceed further to root cause the issue and avoid the failure for the L2 entry while following the sequence-1.

Thanks & Regards,

Alap

Baltazar

I noticed the XXV710 is part of the Fontville series, which includes the X710 and XL710. Additionally the NVM package is the same for all 3 of these NICs.

Intel® Ethernet Controller XXV710-AM2 Product Specifications

Is it possible to flash the 4-port 10GE X710, or the 1-port 40GE XL710 to function as a XXV710? Even if it can only support 2x25G connections, it would be fine.

Hello Sharon,

I have a Intel Gigabit CT Desktop Adapter, EXPI9301CTBLK schematics received from INTEL.

I have some of the doubts on the data lines Being Used.

PURPOSE OF-

1.NC_SI

2. NVM - Non Volatile Memory.

3. SMBUs.

4.External Power Transistor Options.

5.PCIe differential Data.

PFA files of 82574l section for clarification.

Also I have attached our schematics according to the Reference Design.

Kindly Let I know If there are any errors.

PLEASE DO HELP.

Regards,

Saravana

Hi,

I am trying to work with intel i210 IT NIC interface card on ARM platform for AVB development using modified IGB AVB driver provided by OpenAvnu.

This card is working fine on Linux based PC with modified IGB AVB driver provided by OpenAvnu community. This card has PCIe x1 connecting interface.

Please find the below link for more product description.

Please find the link to modified IGB AVB driver maintained by OpenAvnu.

OpenAvnu/kmod/igb at master · AVnu/OpenAvnu · GitHub

I wanted to know whether this NIC card with IGB AVB driver compatible on ARM platform?

Whether this driver is architecture dependent works only on X86 arch. Basic ping functionality is also not working.

Please find the below link of product:

Amazon.in: Buy Intel 9204CT Chip I210-T1 Single Port PCI-Express x1 Ethernet Desktop Adapter Online at Low Prices in Ind…

Best Regards,

Riyaz

Hello,i have a server with old network driver dated (m-d-2015) , i have downloaded new driver 22.2 (07/06/2017)

then i have installed the new driver but when checking the driver to confirm the update  i still see the old one .

i have ran the .exe and followed the wizard.

can you tell what is the problem please?

Regards

environment:

Redhat 7.4

ixgbe, ixgbevf  (82599es ethernet controller)

is it possible to classify the incoming traffic solely based on vlan than on mac.  (ie from pf to vf only based on vlan and ignoring mac address)

Hi,

For my new project I am designing an Ethernet switch card. For that there is a requirement for PTP and PRP protocols in the module. I am in serious confusion among these two protocols. I need to clarify whether PTP and PRP are purely software protocol or I need to choose an Ethernet switch IC which supports these two protocols. The confusion is whether PTP and PRP are hardware or software dependent.

Regards

Hafiz

I have intel 82579LM network card in my DELL M6700. Windows version 1709 16299.309. Intel PROSet Version: 23.1.100.0. Intel Driver: 12.15.31.4. When I creating VLAN the error occured:

"One or more VLANs could not be created. Please check the adapter status and try again."

Can anybody help me. Thanks.

Hello,

my question is directed to Intel NIC developers - we (CDN77) are using your X520-DA2 cards in thousands of servers - we have discovered that two different X520-DA2 NICs we have in our network do use the SAME MAC address.

The conflicting MAC is 00:1b:21:bc:32:15.

Is this something what 'can happen from time to time'? It would be a real flaw in the design - this makes makes me think the duplicate MAC is caused by some Chinese copy of the genuine Intel NIC.

You can imagine what mess can this cause.

If it helps, I can send more detail information regarding both NICs.

Thank you!

We have Hyper-V Server on which we created VMSwitch (with Switch Embedded Teaming) on two built in Intel722 adapters.

On VMSwitch we have NetAdapter for Management OS with ip assigned(created along with vmswitch). After creation everything works fine until reboot, after which we are observing duplicates of packets ie:

18 bytes from xxx: icmp_seq=1 ttl=128

18 bytes from xxx: icmp_seq=1 ttl=128 (DUP!)

18 bytes from xxx: icmp_seq=2 ttl=128

18 bytes from xxx: icmp_seq=2 ttl=128 (DUP!)

If we remove VMSwitch and create it again, everything works fine until reboot.

MacAddress/IP configuration is always the same and don't change after reboot. We investigated the network, but it seems that those macaddressess exist only on that host and we see (using Wireshark/tcpdump) that duplicates are indeed coming from that server. If we use different network card (Intel x550) to create VMSwitch on that server it all works fine. Also if we use those cards without VMSwitch there are no duplicates.

Mobo: X11SPH-nCTF + built in Intel X722 for 10GBASE-T

Processor: Intel Xeon Silver 4110 2.1GHz

OS: MS Hyper-V Server 2016 Version  10.0.14393 Build 14393 + all updates (also tested on MS Windows Server Standard 2016 + all updates)

Driver: c:\windows\system32\drivers\i40eb65.sys (1.8.94.0, 996.54 KB (1,020,456 bytes), 2/19/2018 11:50 PM) (from latest 23.1 Driver Pack)

We don't see anything in logs. We tried reinstalling, even with different OS, situation seems to be the same.

We have the same OS + VMSwitch configuration on different Motherboards/Network Cards but there we don't observe any problems.

Are there any known bugs related to x722 and Microsoft VMSwitch or do you have any suggestion?

Dear all:

    We have a problem of windows 2008 R2 NIC teaming problem.we use two Intel 82599 10 gigabit dual port network adapters for nic teaming, but recently ,for  unknown reasons,the primary network adapter switch from Primary adapter to secondary adapter.When switching, we can see thousands of switch in the network switch.Please help：

1. how can I find which process or software will cause the teaming switch?

2. we can only see the switch happened one time in windows log, why there were thousands of switch in network switch?

Hi

Could you please explain the difference between the

Firmware Version and the NVM Version (ETRACK) fields in the NVM Image section of lanconf.

The reason I am asking is I just updated an i210 device with the latest Production image Dev_Start_I210_Copper_NOMNG_4Mb_A2_3.25_0.03.hex using eeupdate64e.efi.

After a power cycle using lanconf the NVM Version updated to 3.25 as expected but the Firmware version was not updated from 0.9 to 1.7 as I would have expected.

Is there anothe file I need to program into the i210 to update the firmware.

TIA

Ref: Intel i210IT

When I try to install Centos Linux v7 on this system, I'm getting a flood of errors.

After a lot of time fault finding, there seems to be a recurring PCIe bus error, see extract below.

Base System: Intel Core i7 6820EQ (Skylake) CPU with 16Gb DDR4 RAM

Same issue with Ubuntu 16.04 LTS.

Any driver update?

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

[ 2112.007218] pcieport 0000:00:1d.2: AER: Corrected error received: id=00ea

[ 2112.007224] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.007226] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.007227] pcieport 0000:00:1d.2:    [ 0] Receiver Error       

[ 2112.011256] pcieport 0000:00:1d.2: AER: Corrected error received: id=00ea

[ 2112.011263] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.011266] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.011267] pcieport 0000:00:1d.2:    [ 0] Receiver Error       

[ 2112.013527] pcieport 0000:00:1d.2: AER: Corrected error received: id=00ea

[ 2112.013534] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.013536] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.013538] pcieport 0000:00:1d.2:    [ 0] Receiver Error         (First)

[ 2112.015510] pcieport 0000:00:1d.2: AER: Multiple Corrected error received: id=00ea

[ 2112.015580] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.015582] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.015584] pcieport 0000:00:1d.2:    [ 0] Receiver Error       

[ 2112.015586] pcieport 0000:00:1d.2:   Error of this Agent(00ea) is reported first

[ 2112.015593] pcieport 0000:05:00.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=0500(Transmitter ID)

[ 2112.015595] pcieport 0000:05:00.0:   device [10b5:8605] error status/mask=00001081/0000e000

[ 2112.015596] pcieport 0000:05:00.0:    [ 0] Receiver Error       

[ 2112.015598] pcieport 0000:05:00.0:    [ 7] Bad DLLP             

[ 2112.015600] pcieport 0000:05:00.0:    [12] Replay Timer Timeout 

[ 2112.017189] pcieport 0000:00:1d.2: AER: Corrected error received: id=00ea

[ 2112.017197] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.017201] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.017204] pcieport 0000:00:1d.2:    [ 0] Receiver Error       

[ 2112.022836] pcieport 0000:00:1d.2: AER: Corrected error received: id=00ea

[ 2112.022842] pcieport 0000:00:1d.2: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ea(Receiver ID)

[ 2112.022844] pcieport 0000:00:1d.2:   device [8086:a11a] error status/mask=00000001/00002000

[ 2112.022846] pcieport 0000:00:1d.2:    [ 0] Receiver Error         (First)

When starting cold starting custom pc with intel motherboard running windows 10 onboard network adaptor list as 82579LM and not started if I scan for hardware changes network adaptor changes to Intel 83579V and running and no problem have made sure bios is up to date installed Intel windows 10 driver 23.1 I can also get the wired network to work by reset PC after windows boots just restart and works. I driving me nut you shouldn't have to restart your computer after starting it just to get the onboard wired network adaptor to function.

Hello,

after the update to Windows 10 (x64, Build 10240) the creation of a teaming group (static or IEEE802.3ad) with a I211+I217-V NIC fails.

Drivers have been upgraded to the latest version available and multiple reinstallations with reboots din't help either. Whenever the group creation wizzard is used and a groupname (several tried), the adapters and LACP have been selected, a Windows pop-up appears to tell me group creation has failed.

However the Windows Device Manager shows a newly created "Intel Advanced Network Services Virtual Adapter", so some kind of configuration seems to get done.

Using Windows 7 SP1 x64 the exact same setup worked flawlessly for months, so Win10/the driver are the likely culprit.

Is anyone experiencing similar problems and/or is this a known bug? Feedback on this issue is greatly appreciated.

Thanks in advance!

Kind regards,

Famaku

Hi Sharon and Ninwardspiral,

We are having similar problems with the exact same NIC, and by coincidence with the same breakout cable (although we tested many).

Driver and firmware are updated to the latest versions available (2.4.3 and 6.01 respectively):

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1853.0

First cable that does not work: ( QSFP to 4x10G SFP+, amphenol, 2m)

From the manufacturer website: Each QSFP-SFP+ splitter cable features a single QSFP+ connector (SFF-8436) rated for 40-Gbps on one end and (4) SFP+ connectors (SFF-8431), each rated for 10-Gbps, on the other.

SF-QSFP4SFPPS-002 Amphenol Commercial Products | Cable Assemblies | DigiKey (exact cable we bought)

ethtool -m output:

Identifier : 0x03 (SFP)

Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)

Connector : 0x21 (Copper pigtail)

Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00

Transceiver type : FC: Copper Passive

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 2m

Length (OM3) : 0m

Passive Cu cmplnce. : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]

Vendor name : Amphenol

Vendor OUI : 78:a7:14

Vendor PN : 624400002

Vendor rev : A

Option values : 0x00 0x00

BR margin, max : 0%

BR margin, min : 0%

Vendor SN : APF1718002044N

Date code : 170513

ethtool <intf> output (after bringing interfaces up):

Supported ports: [ ]

Supported link modes: Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes: Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

drv probe link timer

Link detected: no

Second cable that does not work: ( QSFP to 4x10G SFP+, generic brand):

2m(6.6ft) 40G QSFP+ to 4SFP+ Passive Breakout DAC Cable | FS.COM

ethtool -m <intf> output:

Identifier : 0x03 (SFP)

Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)

Connector : 0x21 (Copper pigtail)

Transceiver codes : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00

Transceiver type : FC: Copper Passive

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 2m

Length (OM3) : 0m

Passive Cu cmplnce. : 0x03 (unknown) [SFF-8472 rev10.4 only]

Vendor name : FIBERSTORE

Vendor OUI : 00:00:00

Vendor PN : QSFP-4SFP10G-DAC

Vendor rev :

Third Cable, it does work but its not what we need:

https://www.brack.ch/delock-direct-attach-kabel-330520

As a way to see if the NICs work, we also bought a SFP+ to SFP+ cable that is supposed to support SFP MSA and SFF-8431, but not SFF-8472. What is impressive is that this cable is detected and allows us to bring the link up

and even exchange some data at 10gbps. However, that is not what we need.

Encoding : 0x00 (unspecified)

BR, Nominal : 10300MBd

Rate identifier : 0x00 (unspecified)

Length (SMF,km) : 0km

Length (SMF) : 0m

Length (50um) : 0m

Length (62.5um) : 0m

Length (Copper) : 1m

Length (OM3) : 0m

Active Cu cmplnce. : 0x0c (unknown) [SFF-8472 rev10.4 only]

Vendor name : CISCO-TYCO

Vendor OUI : 00:40:20

Vendor PN : 2127493-1

Vendor rev : A

Option values : 0x00 0x12

Option : RX_LOS implemented

Option : TX_DISABLE implemented

BR margin, max : 0%

BR margin, min : 0%

Vendor SN : 164800277_______

Settings for ens787f3:

Supported ports: [ FIBRE ]

Supported link modes: Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes: Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: 10000Mb/s

Duplex: Full

Port: Direct Attach Copper

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

drv probe link timer

Link detected: yes

Fourth Cable (to be delivered):

Intel X4DACBL3 40G QSFP+ Breakout DAC Cable | FS.COM

We are waiting for a fourth cable (this time is supposed to be intel compatible, but we dont know if it will be compatible with our switch...).

Why is the amphenol cable not working if the output of ethernet says: (SFF-8431 appendix E) [SFF-8472 rev10.4 only] which as stated in : Compatible SFP+ Modules, SFP Modules, and Cables for Intel® Ethernet...  should be enough to be compatible. Why

only SFP+ to SFP+ cables work? What should we do? We spent to many resources and time buying different cables.

And to finish, would this NIC Intel® Ethernet Network Adapter XXV710-DA2 Product Specifications  give us better results?

Thanks.

Edgar

Using an updated driver, I cannot seem to get my interfaces up. Looks like the driver is not allowing the NIC to work due to the SFP+ module type, which worked previously on my Debian Stretch host. Clearly the NIC is detecting and reading the DAC, but I don't understand why it is not working. This is a 40G-breakout cable with 40-to-4x10G SFP+ DAC (TwinAx). I have tried adding the following to work around it, but it still does not work:

root@lab4:~# cat /etc/modprobe.d/i40e.conf

options i40e allow_unsupported_sfp=1

This was also discussed here, but there was no followup:

Intel Ethernet Drivers and Utilities / Mailing Lists

Output from dmesg:

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

[    4.447918] i40e 0000:08:00.3: Features: PF-id[3] VFs: 32 VSIs: 34 QP: 8 RSS FD_ATR FD_SB NTUPLE CloudF DCB VxLAN Geneve NVGRE PTP VEPA

[    4.453414] i40e 0000:08:00.2: Rx/Tx is disabled on this device because an unsupported SFP+ module type was detected.

[    4.465288] i40e 0000:08:00.2: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for a list of supported modules.

Other pertinent output:

root@lab4:~# ethtool -m eth6

Identifier                                : 0x03 (SFP)

Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)

Connector                                 : 0x21 (Copper pigtail)

Transceiver codes                         : 0x00 0x00 0x00 0x00 0x00 0x04 0x00 0x00

Transceiver type                          : FC: Copper Passive

Encoding                                  : 0x00 (unspecified)

BR, Nominal                               : 10300MBd

Rate identifier                           : 0x00 (unspecified)

Length (SMF,km)                           : 0km

Length (SMF)                              : 0m

Length (50um)                             : 0m

Length (62.5um)                           : 0m

Length (Copper)                           : 3m

Length (OM3)                              : 0m

Passive Cu cmplnce.                       : 0x01 (SFF-8431 appendix E) [SFF-8472 rev10.4 only]

Vendor name                               : Amphenol

Vendor OUI                                : 78:a7:14

Vendor PN                                 : 624400003

Vendor rev                                : A

Option values                             : 0x00 0x00

BR margin, max                            : 0%

BR margin, min                            : 0%

Vendor SN                                 : APF13470035GDT

Date code                                 : 131122

root@lab4:~# ethtool -i eth6

driver: i40e

version: 2.4.3

firmware-version: 6.01 0x800034af 1.1747.0

expansion-rom-version:

bus-info: 0000:08:00.0

supports-statistics: yes

supports-test: yes

supports-eeprom-access: yes

supports-register-dump: yes

supports-priv-flags: yes

root@lab4:~# ethtool eth6

Settings for eth6:

Supported ports: [ ]

Supported link modes:   Not reported

Supported pause frame use: Symmetric

Supports auto-negotiation: No

Advertised link modes:  Not reported

Advertised pause frame use: No

Advertised auto-negotiation: No

Speed: Unknown!

Duplex: Unknown! (255)

Port: Other

PHYAD: 0

Transceiver: internal

Auto-negotiation: off

Supports Wake-on: d

Wake-on: d

Current message level: 0x0000000f (15)

       drv probe link timer

Link detected: no

root@lab4:~# ip link show eth6

5: eth6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000

    link/ether 68:05:ca:2f:7c:b0 brd ff:ff:ff:ff:ff:ff