Opti 9020s with Intel I217-LM nics causing network issues

Dell's official response to us was that we needed to reconfigure our switches to disable explicit host tracking and spanning tree. Even though no other network cards caused this issue. We just loaded the intel driver and turned off the power options.

This driver resolved my issues once I added it to my boot images and packages.

http://www.dell.com/support/drivers/us/en/04/DriverDetails/Product/latitude-e6440-laptop?driverId=KDTDM&osCode=W764&fileId=3329227212&languageCode=en&categoryId=NI

We are having similar network issues. Any more updates or fixes for this issue?

Hi,

I am having same problem and I tried loading winPE 4.0 cab drivers to SCCM sp1 boot image & no luck

I updated my image with Intel's latest NIC driver and disabled NIC power management. So far no network issues.

Did Dell ever get back to you with a solution to this? We just received over 200 of this model and are experiencing this.

Alan 

Having the same issue.  I don't know how many different drivers i've uploaded to my boot.wm image now and none work.

Have just read some other threads which offer some suggestions, will try this and update if anything works.

http://www.petri.co.il/forums/showthread.php?t=64554

We've had a case open with Dell since Mid last week. We've been asked to turn off Spanning & Explicit Host, now they want us to turn off Power over Ethernet. Been escalated once already and this tech is not any better. Losing hope that they'll find a solution. We have 200+ of this model. Not looking good for Dell at this point.

Alan

Thought I was going crazy  Never had this issue with new models before, it's usually fairly straightforward.

Yeah, we've got them piling up at the moment... need a solution quickly.  Hope you get a good answer, although sounds like they don't know themselves at the moment.

My guys had been blaming my imaging load! I'll let you knwo what we hear from them.

I addded a step to my SCCM task sequence to install the Intel driver package on the 9020s only (used a WMI condition to query for the model) Then added another conditional step to configure the settings. Used Intel driver version 12.6.47. There's a vbscript with the driver that you can use to configure the NIC. You run it on a PC with the configuration you want to export. And save the settings to a text file, then run the import as a program in the package.

http://www.intel.com/support/network/sb/CS-028693.htm

This is what I have in my config file. You can see if it works for you.

*** NCS2 DMiX Save Data ***

*** Date 10/21/2013 Time 3:11:42 PM ***

**********************************************

OEMCustomizeable=

OS=6.1

Adapter Name=Intel(R) Ethernet Connection I217-LM

Adapter PCIDeviceID=VEN_8086&DEV_153a&SUBSYS_102805a4&REV_04&0&c8

Adapter BusDeviceFunction=0:25:0:0

Adapter Index=1

Private Description=

Adapter Capabilities=32,33,34,43,59,42,36,37,60,46,71,61,3,41,47,50,56,37,71,12,5,4

Description=Intel(R) Ethernet Connection I217-LM

setting Name=*FlowControl

setting Current Value=3

setting Description=Flow Control

setting Name=*JumboPacket

setting Current Value=1514

setting Description=Jumbo Packet

setting Name=*PMARPOffload

setting Current Value=0

setting Description=Protocol ARP Offload

setting Name=*PMNSOffload

setting Current Value=0

setting Description=Protocol NS Offload

setting Name=*PriorityVLANTag

setting Current Value=3

setting Description=Priority & VLAN

setting Name=*SpeedDuplex

setting Current Value=0

setting Description=Speed & Duplex

setting Name=*WakeOnMagicPacket

setting Current Value=1

setting Description=Wake on Magic Packet

setting Name=*WakeOnPattern

setting Current Value=1

setting Description=Wake on Pattern Match

setting Name=EEELinkAdvertisement

setting Current Value=0

setting Description=Energy Efficient Ethernet

setting Name=SipsEnabled

setting Current Value=0

setting Description=Reduce link speed during system idle

setting Name=EnableDHCP

setting Current Value=1

setting Description=StaticIP

setting Name=NetbiosOptions

setting Current Value=0

setting Description=StaticIP

setting Name=ConnectionName

setting Current Value=Local Area Connection

setting Description=ConnectionName

setting Name=EnablePME

setting Current Value=1

setting Description=Wake on Magic Packet from power off state

setting Name=ReduceSpeedOnPowerDown

setting Current Value=0

setting Description=Reduce link speed during standby

So this is what worked for us, the REG in this article:

https://communities.intel.com/thread/48210

Which is this:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0007]

"LinkNegotiationProcess"="2"

[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet002\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0007]

"LinkNegotiationProcess"="2"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}\0007]

"LinkNegotiationProcess"="2"

 This is working on our 9020's with i217LM chipset.

Hello, have you tried what I suggested in my earlier post which is to disable AMT in bios? Once we disabled it, everything works fine....power settings enabled, ipv6 enabled no problem. AMT starts multicasting from every pc and causes the traffic. Disabling this is what you nedd.

I'm going to coin this the "NOES (Nightmare on Elm Street)" bug.

I'll tell you what's really interesting about what we have found. Yes, AMT was the first thing that was disabled on all the PCs that were flooding the network; and the problem seemed to be mitigated for as long as "every single computer" had AMT disabled.

However, once we left "one" new computer on the network without disabling AMT (call him Freddy), that computer, once asleep, would enter the dreams of all of the sleeping "AMT Disabled" computers and scare them all into flooding the network again.

So it appears that there is something that AMT does that "triggers" the multicast flooding and then, as another poster put it somewhere else on the internet, "goads" the rest of the hosts to join in the flooding song, thus generating a DOS attack on the entire LAN subnet.

All the packets I've seen so far have a common thread in that they have to do with some sort of zero configuration feature. CAPWAP packets were flooding the network at one point. So this tells me that the bug could be the integration piece between wake on lan, magic packets, and ipv6 auto provisioning features within AMT.

Being that part of vPro architecture is that it acts as an internal switch within the P.C. itself, it seems as if this switch is looping ipv6 internally. One of the other posts i found online in regards to ipv6 looping indicated that some hypervisors running in windows were causing looping with ipv6 multicast because the traffic was bridging through the virtual adapters in the hypervisor.

So one theory I have is that these computers could be internally looping packets of the zero configuration type. The hypervisor technology within the vPro/AMT internal network has to have bridging interfaces for each network/Wi-Fi adapter available to windows in order to perform its duties as an agent. I don't know how many virtual adapters exist in a vPro/AMT v-switch but it's definitely more than one. If each of these or any of these internal interfaces has ipv6 multicast forwarding enabled, even if it’s only allowing certain types of packets through the filter, a looping situation would be immanent. And since there is no IP_ID in the header of ipv6 packets, it's impossible to tell with a packet capture that these are duplicate packets.

Also, since the computers are flooding zero-configuration type traffic, i'm wondering if another workaround would be to setup an ipv6 DHCP scope so these computers never try and configure themselves in such fashion (again I stress the word “workaround”).

Does anyone that has this problem actually have a working ipv6 dhcp server on their LAN?