1 of 1 people found this helpful
I will try to help you out here starting with the easy questions.
1. The product came in a see-throught plastic box without any stickers on the box or CDs, just a second bracket. Is this normal for bulk ethernet adapters? Yes, this is normal for bulk adapters.
2. ... What is with the manufacturing date? Is it a problem of the site or the store sent me an old nic? I think the problem is with the verification application and not an old NIC. I suspect your adapter was built in Week 04, 2011. I will send you a private message to get more information on the serial number so I can make sure the issue is resolved.
3. I am sorry to here that the ALB/RLB teaming is not working as expected. Are you running virtual machines on this server? What happens if you disable the RLB on the team? Does the communication continue to work normally without RLB? Do you have SP1 installed? I am not aware of any known issues with using that adapter in an ALB team in Windows Server 2008 R2, but I will do some research to see if I find out about any known issues.
Hi Mark and thanks for the immediate reply!
I sent at the PM the product details.
About the issue:
In my office i have 6 PCs and the fileserver with the Intel nic.
Each pc has 2 Nics, one for LAN and filesharing throught a 3Com OfficeConnect 16 port gigabit unmanaged switch using Cat 6 FTP cabling, and the other Nic is for web access throught a router.
To manage the PCs to access resources on the lan throught the private network only, i have on each pc an eset firewall to allow sharing throught the private network and block theinternet network.. IT experts told me i should keep both networks on the same lan and configure it but i feel safer this way.
Two PCs have Win7 and the others have Xp Pro (all updates installed for all workgroup members)
The server is based on 2008 R2 and is a simple installation with file services roles enabled, no hyper Vs or anything else, and all updates and SP1 installed.
The Intel team is ALB and tested with or without RLB has the same issues which i managed today to narrow down.
The issues appear with all the PCs, when accessing shared files, trying to "ping -t" or when trying to RDP throught the ipv4 ip of the server.. I get some replies and then the communication stops. (Also tested with all firewalls disabled)
Using ipv6 thought or PC name (server), the win7 machines usually have no problem pinging or RDPing or accessing the shared folders for a long time.. But sometimes they aldo lose connectivity and only a reboot fixes the issue temporarilly.
The XP machines since they do not support ipv6, they lose connectivity..
So it seems that the ALB and RLB works ok with ipv6 - thought the file transfer speeds are around 40-50 MB/s but that is a different issue, and the main problem is the ip4 one which is important cause our programs mostly rely on the ip4 protocol..
If i ping the ip4 adress after a reboot i get the first packets replied and the others not returned.
The events on the server are:
Event 13, iANSMiniport: The Intel(R) PRO/1000 PT Dual Port Server Adapter has been deactivated from the team.
Event 11, iANSMiniport: Adapter link down: Intel(R) PRO/1000 PT Dual Port Server Adapter or Intel(R) PRO/1000 PT Dual Port Server Adapter#2
Event 16, iANSMiniport: Team#0: The last adapter lost link. Team network connection has been lost.
Event 27, e1express: TEAM: Team#0 - Intel Pro/1000 PT Dual Server Adapter Link has been disconnected.
Event 22, iANSMiniport: Primary adapter does not sense any probes: Intel Pro/1000 PT Dual Server Adapter #2. Possible reason: partitioned team.
Event56, TermDD: The terminal Server security layer detected an error in the protovol stream and has disconnected the client Client IP: xxx.xxx.x.x - This happens rarelly when trying to access the server from the Win7 machines throught ipv4.
BTW, how should probes be for this comfiguration? Broadcast or multicast?
Sorry for the long post and thanks in advance for any help
Message was edited by: Smyro
How should probes be for this comfiguration? Broadcast or multicast? The default, which is broadcast should work in any situtation. If your switch can handle multicasts, then you could limit broadcast traffic by configuring the probes for multicast, which would reduce the traffic out to the other ports.
I have a couple of ideas about how to collect more information to resolve the issue. You said that the adapter connections work for a long time when you do not configure a team. Therefore, try disabling "Send probes" by unchecking the box in the "Probes" properties. Do the connections still get dropped? Maybe the probe packets are getting blocked somehow. If you do not send probes, then the iANS driver will not expect to see any probes.
If there is a bug in the iANS driver, then the bug is probably something new. The adapter you use has been around for years, so the adapter driver is not updated frequently. You could test with an older iANS driver and the same adapter driver by download version 15.3 software at http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=19059. The title says Windows* 7, but the PROWinx64.exe package also contains the drivers for Windows* Server 2008 R2. You cannot downgrade. If you try the old software, you must first remove all components of the newer Intel(R) Network Connections software using Windows control panel. Then you can make a fresh install of the older software. You should configure the team with the default settings for the team properties. Does a team with the older software work without dropping the connection?
Let me know what you find.
I finally found what is causing the issue, when teaming the nic, the firewalls detect the shared resources access, the ping atempts and the rdp connections as arp poisoning attacks and after that they block the IPs. This is happening on the server and on the client machines. Why is this happening when teaming?
So now after disabling arp poisoning detection, ALB and RLB works ok, thought i still get the errors on the Server's event logger about disconnecting the team ecc..
Is this normal?
Thank you for sharing what you found. I am sure others will run into this issue. Have a great day!
NP Mark, i hope others are helped from this thread..
But you didn't answer my question, why is this happening when teaming with ALB? I don't want to have my firewall open for ARP poisoning attacks, it is not normal for this to happen. When i have the adapters not teamed there is no arp issue..
And also what about the error events on windows logs?
Thanks again for your help, it is appreciated!
I am not sure about the mechanism used by the firewall to determine ARP poisoning attacks, but if the teaming software thinks that one adapter is down, then the other adapter will use ARP to advertise the MAC address of the adapter that is down. Check out the Advanced Network Services Software Whitepaper starting on page 7. The paper is very old, but the description of the mechanisms and how MAC addresses are used by different team modes is correct.
Are you still getting messages about any of the team members going down? If you are, then I have to wonder if the probe packets are being blocked. You could try disabling probe packets for the team so that blocked probes will not cause a failure of one of the NICs.
I hope this information helps you track down a better solution.
After some time and some test i noted some things..
About the errors with Event ID 11 and 13 about the adapter disconnecting:
I get these on every boot of the server just once since they are warnings on the administrative events tab of the event viewer. But at the system tab where the informational events are also displayed, after each warning event, there is an informational event that the adapters are reinitialized, the connection is established ecc (Event IDs 19, 14, 17, 15, 8, 6, 7). So this has something to do with Intel programming the initialization of the team in the os enviroment i think and not with a real problem.
About the arp poisoning attacks and other issues with the firewall, i think it is an Eset Smart Security firewall issue and nothing more..
So after all, i am satisfied with my intel adapter and the support i recieved, thought i must say that i am not getting the optimal speeds..
Trying to copy big files (5GBs) simultaneously from 5 clients from the server, i cannot get the teamed 2 gbps connection of the server to work at more than 50% even if summing the transfer speeds that i get when running the file transfer at each client alone exceds the 1 Gbps limit. (From clients if not downloading simultaneously with others i get these average MB/s: 35, 30, 25, 30, 25 - Sum = ~ 150 MB/s).
Thank you for the update. Performance when copying files is not likely to approach the potential bandwidth available on the network adapters because of other system bottlenecks in the hardware and the OS. Testing performance is outside my expertise, so I checked with one of our engineers. He suggested testing your performance using a program like Microsoft's NTttcp using multiple threads.
I am starting to get frustrated with my firewall and antivirus program..
After uninstalling it (disabling all security options doesn't have the same results) from a client pc, i get with the ntttcp utility double bandwith and transfer speeds with file copying than before..
So the teaming works, i manager to get usage more than 60% from 4 clients, imagine what i could get if i uninstalled it from the server also..
BTW for anyone looking for a similar Nic to buy: The ET dual gigabit server adapter is newer and has newer chip and additional functions than the Dual PT Pro 1000 even if the PT is more expensive!
I just discovered a document from Intel: http://www.intel.com/Assets/PDF/general/linecard_ec.pdf
I wish i knew this before i bought the PT one.