I have a concern with the teaming of an Intel "PRO/1000 GT Quad Ports Server Adapter" running under Windows Vista 64 bits.
- At the beginning, I create and use a 802.3ad TEAM with all 4 ports successfully, using the driver "184.108.40.206".
- Just for testing purpose, I change the "Link Aggregation Join Method" from "Maximum bandwith" to "Maximum adapters". Inside the TEAM, 2 ports on 4 change from "Active" to "Standby" state.
- I don't have test if the TEAM still running properlly, and rollback the "Link Aggregation Join Method" parameter to "Maximum bandwith". But the 2 ports keep the "Standby" state. And the TEAM interface cannot ping nothing.
- I try a reboot, nothing change. And the TEAM cannot ping nothing
- I try to disable (one by one) the 2 active ports, hoping a failback on the 2 "Standby" ports... but nothing.
- I try an upgrade of the Intel software (220.127.116.11)... nothing change...
With the new driver, the "Link Aggregation Join Method" parameter not look to exist anymore.
- I remove the 2 standby ports from the TEAM, and it start to run properlly.
- I create a new "TEAM2" with the 2 "standby" ports. One of them change for "active", but the other one stay "standby".
- I remove from TEAM2 the active port, and the standby port stay "standby".
- I re-add the previously active port of the TEAM2 inside the first TEAM, and it go back in a "standby" state...
Somebody have an idea on how to change the state of a port from standby to active ?
Thanks a lot
- Intel® Pro1000
I have 6 ports in a Link Aggregation Group (LAG) using LACP on my Netgear switch. I am using Windows Vista, x64. I have two Intel(R) PRO/1000 MT Dual Port Adapters that I configured in Windows to assign all 4 ports to an IEEE 802.3ad Dynamic Link Aggregation mode team. When I first enabled the team the ports went from disabled to standby to active. All 4 ports are active.
I did notice that if I configure the team in Windows before I configured the LAG on the switch that only one port showed active and the other ports were in standby. I was not able to communicate through the team until I disabled the team interface in Windows Device Manager and then enabled the team interface again. Then all ports became active and communications was restored.
Because your team is not behaving this way, I think you might have some communication mismatch between the link aggregation group on your switch and the team on your computer. Are you sure that the LAG on your switch is using LACP? If the LAG is a static mode LAG, then you will need to configure your team for Static Link Aggregation.
Some other thoughts: Make sure that the LAG on your switch is configured to use LACP (if available) and make sure your switch has the latest firmware/software. Double check that all the ports on the team are connected to the ports on the switch that are members of the LAG.
Make sure you are using the latest Intel(R) Network Connections software. You can grab the latest version from http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18718 http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18718.
I hope this helps.
Thank for your answer!
I use also a Netgear switch (GS724T) and my OS is also Vista 64 bits.
I have also create my LAG (4 ports using LACP) insid it before to create the team.
At the beginning, everything run flawlessly
The web interface of the Netgear show all ports inside the LAG in a UP state
My trouble start only after a change in the 802.3ad config of the Intel driver (18.104.22.168). I change the "Link Aggregation Join Method" from "Maximum bandwith" to "Maximum adapters".
Since, 2 NIC on 4 stay standby all the time. I switch back to "Maximum bandwith", but nothing change. An update to the latest version of the driver (22.214.171.124) fix nothing and the "Link Aggregation Join Method" don't exist anymore...
At the switch level, only the 2 actives NICs ports are show under the LAG configuration panel.
Thank you again for your input... but if you (or somebody else) have an idea about that...
It is possible to have some "old configs garbage" inside the Registry of Windows?
I am not familiar with the join method option, and as you have observed, this option does not exist anymore. However, something unwanted in the registry settings for the team or for the adapter might be causing the team to malfunction. If you do a full uninstall of the software and the adapter ports, then that should remove any unwanted registry entries.
I suggest these steps:
- Remove the team using the teaming properties. (Do not use the "Remove device" option available when you right click in WIndows Device manager. Go into the properties and make the removal from there.
- Uninstall Intel(R) Network Connections software from add/remove programs. Uninstall all components: drivers, Intel(R) PROSet, and Advanced Network Services.
- Restart Windows so that nothing will be remembered from the old registry settings.
- Install the latest version of Intel(R) Network Connections software.
- Create the 802.3ad team.
The new team should work normally with all ports active.
Thanks for your answer.
I try your "uninstall/install" procedure unsuccessfuly. The 2 same ports stay "Standby" after that.
So I re-apply the original GHOST image of the machine, and restart a new teaming config from scratch. The new team still having the same behavior, with the same 2 ports in a standby mode.
I use, just by curiosity, the hardware diagnostics from INTEL on all ports of the quad card. The 2 standby ports failed the EEPROM test.
I feel a little bit surprise because it's a new card and all ports run properly at the beginning...
I dont take any chance, and replace the card by a new one. Just after the physical install, I use the hardware diagnostics from INTEL and all ports are O.K.
The teaming creation run flawlessly (with all of the 4 ports), everything look good. The Windows Task manager show a bandwith of 4Gb. This is yesterday...
Today, by making some performance tests, the Windows Task manager show a bandwith of only 2 GB on 4. And the EEPROM test are now unsuccesful on all ports (?)
So in fact, I think I have a behavior between the INTEL EEPROMS of my QUAD cards and the machine/OS... Do you have any idea about this phenomenon?
I am not sure what interaction is happening. In theory, something could be overwriting some part of the EEPROM information (or failing to read the information properly.) I do not have any good ideas as to a specific cause.
What is your computer manufacturer and model?
What is your OS?
Is virtualization being used? If yes, what is the host OS and what are the OS for the guests?
You should also check the adapters to make sure they are genuine using the Yottamark sticker explained at http://www.intel.com/support/network/sb/CS-031541.htm http://www.intel.com/support/network/sb/CS-031541.htm. If the adapters are too old, they might not have a sticker. If that is the case with your adapters, please send me a private message with the serial number. The serial number is in 3 parts on the same label and includes the MAC address. The serial number will look something like 000E0FFFFFFF0 256QA D35392-000. You should also have a product name and code label. Please send me the numbers from that label too.
Of course, you might simply have bad adapters, but the failure rate is very low, so I am worried that if you keep placing more adapters in the same system, some interaction might be the cause of the issue. With more information about your system and the sytstem configuration, we might be able to discover a possible cause.
>What is your computer manufacturer and model?
The motherboard is SuperMicro X7DWA-N
>What is your OS?
Vista 64 with driver "126.96.36.199"
>Is virtualization being used?
>You should also check the adapters to make sure they are genuine using the Yottamark sticker
All my cards don't have this sticker... So, because I work remotely, I will send you the serial number later.
We have many machines of this kind, using 1 or 2 Intel PRO/1000 GT QUAD Port Adapters without any trouble. This behavior appear only when we try to make teaming... and after some hours. This is why I don't have the reflex to update the driver before the teaming creation (since now).
Do we have a way to fix/flash the EEPROM ? I think yes, but if you have some details, this will be great.
I do not have anything to send to fix the EEPROM. I am going to ask some other people about the best way to figure out what is happening to your boards.
Added question: Do other hardware tests pass when EEPROM Test fails? FIFO Test, Register Test, Loopback Tests(s)?
Message was edited by: Mark H @ Intel to add question
Ouch ... Don`t take it personnally (you are really kind since the beginning of this thread), but I`m really surprise about this end. The origin of the EEPROM corruption look to be `teaming` related, and it`s quit horrific to have to return all 2 cards only for a software behavior.
No luck to have any other possibilities/options ?
I realize that from your standpoint, replacing the adapters is not an ideal solution. Unfortunately, I do not know of any other work around. Since the adapters no longer function properly in the team, you must replace them to restore full functionality.
The next area of concern would be preventing future EEPROM failures. Based on your past experience, I would make sure you do not use the older software version that had the configuration for different join methods.
I recommend moving to the latest software/driver version. The base driver has not been updated in years, but the ANS driver that controls the teaming gets regular updates.Once you have a stable configuration, I would freeze at that version since the base driver is no longer updated, and you are unlikely to benefit from making future changes to a stable configuration.
I am the person who usually posts the software for the adapters. I keep reusing the same URL at http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18718 http://downloadcenter.intel.com/detail_desc.aspx?agr=Y&DwnldID=18718 for each new version, so whatever you get here will be the latest software package for Windows. The downloads were recently updated with version 16.7. If this version works well for you, I would make back up copies for your use and just stay with that version rather than making future updates.
Many thanks for all your infos.
In a "teaming perspective" (using the latest drivers availables ... of course), do you know if I can have others concerns with the following NIC:
Intel I340 Ethernet Server Adapter Quad Port Copper 1GBIT PCI Express [E1G44HTBLK]
I need to go further in my project, and cannot wait the completion of the "RMA process". So I need to be sure of my next NIC choice ...
If you have a x4 PCI-Express slot available, either the Intel® Ethernet Server Adapter I340-T4 (E1G44HT or E1G44HTBLK) or Intel® Ethernet Server Adapter I350-T4 (I350T4 or I350T4BLK) would make good choices. Either adapter has full teaming support. The I340 family has been around since early 2010 and the I350 family launched recently.