I211/I217-V Windows 10 LACP teaming fails

[FKurt]

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

[AChar2]

Have confirmed that all works well in Windows Server 2016:

http://www.newegg.com/Product/Product.aspx?Item=1B4-003A-00063&cm_re=windows_server_2016-_-1B4-003A-00063-_-Product Windows Server 2016 Essentials - 1 Server, 2 CPU - OEM-Newegg.com

So, for now we will fork out the $499.00

[JAase]

Carl_Wilson:

RS1 (1607) support sounds REALLY great!

Thank you!

[DCol]

Ok, the new drivers are now available, but teaming and VLAN is still not enabled with RS1 or RS2.

[idata]

No dice here either. I'm running 14393.321, all Microsoft Updates current, I downloaded and installed Ethernet Adapters Connections CD 21.1.30.0 (dated 10/11/16) and it warned that ANS was incompatible with Windows 10. Drivers in device manager were all still stuck on Microsoft's drivers after installing, so I forced them to use a manual driver from the folder, listed as version 12.15.184.0 with a date of 8/4/16, and the teaming features are still grayed out.

[CARL_W_Intel]

Update:

Thus far, the feedback to the MS team is the patch for RS1 looks good. from what I understand, this should be include in the general RS1 update in December. Once it is posted, it will take 2-3 weeks until we can get our re-enabled driver posted for Windows 10 which includes the check for the confirmed RS1 update before re-enabling the feature.

[SMaur3]

For the time beeing i found the asrock intel driver v20.2, used with asrock Z170 extreme7+. The Teaming could be enabled (NIC I219V and I211). Not the newest driver, but it works

[DCol]

Drivers from 20.2 did not work for me. Created the team, but wasn't able to enable it.

Sounds like from Carl Wilson's update that we are looking at January. I won't hold my breath, We have heard this before. RS1 is out now Carl, lets get the driver now. The Insiders Preview is at RS2. Wouldn't this be the time to enable teaming since there are thousands of testers out there who can report any issues before the production release. Makes sense to use testers that know there could be issues. Intel should be following MS lead on testing before public release.

[JMan1]

Hi All,

I have been following this thread closely for many months, as I want to set up LACP on my home network. I have an Intel Pro 1000 PT Quad Nic card in my home server and have been installing different Windows OS (Win2012R2, Win 7, Win 8.1 and Win10) with various degree of success to get NIC Teaming.

My most recent installation is Win10 Pro last night and done all the updates. I have tried to run the New-NetLbfoTeam command before (a couple of weeks ago, this is my 2nd attempt with Win10) without success. However, I have ran the command again this morning through Window Powershell ISE (admin mode) and this seem to have created my Team NIC. I have checked the network status for this teamed adapter and its definitely reporting 4gb.

Do you think Microsoft has re-enabled the feature in the most recent release?

Some basic info about my network:

1x AD server (Win2012 R2) with Intel Pro 1000 PT dual ports - link aggregation works out of the box.

1x Plex server (Win10 Pro) with Intel Pro 1000 PT quad ports - link aggregation "seems" to be working using the Windows Powershell command

1x HP Procurve J9028B 24 ports switch.

I'm a novice with networking and only dabble as a hobby, what I would like to know if it is REALLY running link aggregation on the Plex server. If so, how can I check this please?

Any information would be appreciated.

Thanks,

Jay

[aasd4]

so does it actually work? did you test the speed?

[JMan1]

If you mean does the team Nic works? Yes, and the adaptor reports 4gb connection. Is there anything or software I can try to confirm this? I can provide screenshots if needed.

[CUllr]

> Is there anything or software I can try to confirm this?

Capture a screenshot from the task manager or performance monitor showing that the team transferred significantly more than 1 Gb/s for significantly longer than one second, and include the "winver" dialog.

I'm afraid I cannot help with creating a workload that will actually use link aggregation. A single TCP connection will never do so, however, so simply robocopy'ing massive files is not a useful test. Multiple simultaneous HTTP downloads may work, or one of them plus a file copy.

[JMan1]

Sorry, my networking knowledge is rather limited, I'm more of a software dev.

I have attached a screenshot from the current set up and copied 6 large files (total 16.6gb) from my AD server (with dual NIC) to this server (quad NIC), the transfer speed around 90+MB(ytes)/s and drops to around 20MB/s at 1/2 way, then hover around 50MB/s

Time taken (just using a stop watch, nothing scientific)

6 large file (16.6gb) = 6m21s

1 smallish file (550mb) = 6.1s (around 110MB/s)

As you can see in the TeamPlex adapter, this shows 4gb connection

If anyone else would like me to run other tests, let me know. This is a headless machine, so it's pretty awkward to carry the monitor to set up each time.

Disclaimer. I'm not trying to bring any high hopes, just want to know if this is working correctly. Thanks.

[idata]

No to burst anyone's bubble, but I'm suspecting that you've only found another way to exploit a bug that MS has otherwise patched.

In discussions I've had with MS, they mentioned that early builds of Windows 10 had a (quote) "bug" that allowed people to successfully run the OS-native "New-NetLbfoTeam" command. This gave the appearance that a team was being created, but because the underlying driver support that is included with server SKUs was NOT included with Windows 10, traffic would only travel through one NIC, and thus you would never receive anything higher than a single NIC's worth of bandwidth.

Assuming the other, non-Windows 10, end of your connection is LBFOing properly and the disk devices on either side support the throughput, then you would expect to see transfer rates in excess of 1000Mb/s (little b) or 125MB/s (Big B).

Seeing as how you're topping out in the 90-100MB/s range, it looks to me like that 4-NIC team is operating at 1-NIC's worth of bandwidth.

Sorry dude

[CUllr]

> the transfer speed around 90+MB(ytes)/s

The theoretical maximum for an SMB transfer over a single gigabit link is ~113 MiB/s, which yours is well below.

You can try this:

• Put an HTTP server on the server (IIS will do) and get it to serve static files.
• Download a large file (several GiB) several times in parallel.
  • Rather than a browser, you should use a command line program like curl or wget, so you can throw away the output:curl -o nul: http://whatever/enormous.file
  • This will keep your local storage subsystem out of the picture.
  • Use the same file for all downloads so the server only has to read it once from disk into cache, too (it should fit into the server's memory, of course).
• If this does not get you more speed, play with the switch configuration to make sure it knows to spread the connections across all ports. You could also add listening ports on the server (81, 82, etc.) and point each download at a different one, to give the switch more to work with.

Load sharing works by assigning packets to physical links by some rule. It may be based on the MAC or IP addresses, or the protocol port numbers for TCP and UDP, or other criteria; to get it working, you have to know how your traffic looks and how multiple connections are different from each other. The worst case is SMB, with only a single TCP connection to each server, because a single connection cannot be load-shared at all.

Also, as @jdjulio says, 10 RTM lets you run the New-NetLBFOTeam cmdlet without an error message, it just has no effect on throughput. What exact version is your Windows 10?

[JMan1]

Thank you both for the detail information, really appreciated.

That was my fear that this is nothing more than a smoking mirror .

The Windows version:

OS NameMicrosoft Windows 10 ProVersion10.0.10240 Build 10240

[DCol]

I can confirm that teaming fails on the current Windows 10 release 14955

[JMan1]

Thank you both for the clarity and confirmation. Sorry, didn't mean to bring anyone's hopes up.

I have done all the Windows updates and could not see any further updates. Oh, well, back to drawing board .

[DCol]

Don't hold your breath, Looks like a 3-6 month wait according to Carl Wilson. With a lot of if's in there. Just release the drivers already. Redstone has been out there for months. The current release,19455, seems to be very stable with all the major issues resolved.

[idata]

Far be it for me to speak for Carl_Wilson, but my understanding on why they can't simply release drivers for Redstone 1 is because Redstone 1, as it sits today, needs an MS patch to be able to have it operate properly (basically, whatever they did in Redstone 2, back-ported to Redstone 1).

I would assume they want (need) to wait for that patch to be released so they can add the code within the driver to say, "Check for patch KBXXXXXX, if installed, enable teaming/VLAN features, If not, leave disabled".

Until they know what that specific KB # is, there would be no way for them to code in that check: You can't write code to check for a specific patch that doesn't exist yet for Redstone 1.

[CARL_W_Intel]

Nice work! I couldn't have written it better myself - its exactly the process. We need the KB # to finish the code (takes a couple days) and run it through a fast regression test, then we post to the web.

[MSava3]

Please Carl,

keep us posted as it has been quite a long wait

M