No network interfaces found (verifyNetworkConnection)

[Wayne Workman]

@george1421 The most interesting thing happened. I’m going to explain as best I can the exact sequence of events.

I hooked up this little unmanaged 100 Mbps 5 port switch between the buiding network and this Optiplex 7010. The optiplex was connected to port 1, the building connected to port 5 (not that it matters).

I didn’t get the OP error. Things started working!

I thought, OK, I need to get a video of what it looks like when it’s working properly. So I turn off the computer, and get my phone setup and the switch in just the right spot for filming and then I fire the computer back on.

Neither the NIC on the computer nor port 1 on the switch ever lit up… what?

I traded what building port that port 5 was connected to, and then it worked again. I got a video of that:

https://www.youtube.com/embed/SUJPdjvZEPc

Any ideas? Man this is nuts.

[george1421]

As you were getting setup to video, did you restart the switch or plug the wiring going to the building at all?

In the last video, the booting timing, was similar to what I’m seeing on my bench. Its about 2 seconds between stages. Because you have a dumb switch between the computer and the building wiring, the computer going up and down shouldn’t impact the port forwarding state on the building network. Its not clear why transferring between building side port 5 to another port had any impact other than it would have transitioned the link state on the building switch.

Are you guys using any type of nac or nap?

[Sebastian Roth]

@george1421 said:

Are you guys using any type of nac or nap?

Same question came to my mind! Are you somehow able to get a serial connection on that building switch? Would be most interesting to see what it talks about the link going down/up and possible other messages (NAC related maybe).

@Wayne-Workman said:

Turns out, changing switches isn’t the thing that fixes it, changing to any other network port is.

So this issue only occurs on one switch port (building switch)?? As soon as you plug into a different port on the same switch things are fine? Either your network guys should have a close look at the specific port configuration or they better abandon that port altogether (if it’s just that single one!).

[Wayne Workman]

@Sebastian-Roth said:

So this issue only occurs on one switch port (building switch)?? As soon as you plug into a different port on the same switch things are fine? Either your network guys should have a close look at the specific port configuration or they better abandon that port altogether (if it’s just that single one!).

No, not just one port. Once I get the error message in the OP for any port, that port seems to be permanently voo-doo’d.

I don’t know what nac or nap is. If I ask my network people this, will they know what I’m talking about? We are 100% Cisco end-to-end.

[Sebastian Roth]

Hopefully they have an idea what NAC is: https://en.wikipedia.org/wiki/Network_Admission_Control

[george1421]

If you have to register (with some kind of network controller) new out of the box computers before you can use them then you have a NAC/NAP (different name same function) that manages access for your network. Since you don’t know the name you probably don’t have this.

When you say you have cisco throughout. Is that real cisco switches (catalyst series) or cisco small business switches (SG series)? The reason why I ask, is the SG series has a nasty feature that is turned on by default called smart port. That feature will try to determine what device is connected to the port then assign the device to the predefined vlan. This “feature” listens for the connected device to announce what it is. This listening phase is several seconds, much like stp learning phase. I’m not a cisco person, so I don’t know if the catalyst series has this same function. But this smart port has caused me pain several times in that with it on, any vlan I set of a port will get overwritten with the smart port setting.

[Wayne Workman]

@george1421 They are all catalyst switches - varying models but none are over maybe 4 or 5 years old (yay free government money).

[Wayne Workman]

@george1421 said:

As you were getting setup to video, did you restart the switch or plug the wiring going to the building at all?

I don’t think I did, I think I just moved the switch to be on top of the computer. And of course I held the power button on the computer until it turned off.

I’ll repeat this tomorrow and see if it’s repeatable.

[Wayne Workman]

More info on this.

I removed the mini-switch from the equation, and tried to image the computer.

It wouldn’t even get a DHCP lease, but the NIC lights did turn on after a long while… then it failed. PXE-M0F.

Turned it off, turned it back on.

It got DHCP proper, but then got the OP error.

Turned it off, turned it back on.

Same thing, OP error.

I put the switch between the computer and the building network again, imaging works perfectly.

[MRCUR]

@Wayne-Workman I would ask for verification that “spanning-tree bpdufilter enable” is set for the port OR that “spanning-tree portfast (int num) enable” is set.

[george1421]

@Wayne-Workman I agree that something is not configured correctly on the building switch. By putting an unmanaged switch in between it fixes (masks) the issue. Because the building switch is never seeing the port drop as the target computer transitions between phases during booting.

[Tom Elliott]

@george1421 I’ve actually seen this exact issue with our systems as well. Not very often, and the fix is indeed to put a managed switch between. Or, alter the firmware on windows to now put the nic into a “Power-saving” mode.

The latter is not a simple thing and is only good for that instance of the OS, if your image doesn’t have those firmware changes in place, they will not hold.

[Wayne Workman]

@Tom-Elliott Can you elaborate (further) ?

[A Former User]

I know this isn’t going to help, but I had 18 OptiPlex 7010s in a lab, and several had this issue. I noticed that the ones that had the issue had a different BIOS version from the others. After updating the BIOS, the issue was resolved in this case.

In another lab with 7010s, I had the same issue with a couple of machines, but it was unrelated to the BIOS version. Instead, the network connection just wasn’t “good enough” for FOG to see for some reason. In Windows, these machines could connect, but FOG just wasn’t having it for some reason. We replaced the patch cable at the the switch, and it resolved the issue. I figured that if Windows thought the connection was acceptable that FOG would, too, but that is most definitely not the case at all.

[Wayne Workman]

@loosus456 That does help. I’ll update the firmware and see if it has any effect.

[Wayne Workman]

I just updated an Optiplex 7010 from A12 to A21.

Early results don’t look any different.

[Wayne Workman]

I’ve disabled all power saving features in Firmware - still no luck.

[Wayne Workman]

Network team says that “spanning-tree portfast” is set on all client ports in the building.

[Wayne Workman]

Ok…

I’m feeling pretty ignorant at the moment.

I got to messing with this again and was able to try out a new unmanaged 1Gbps Cisco switch with it and I went through several different configurations in my tests and kept getting inconsistent results.

I have finally found out what the issue was. It was a bad patch cable the whole time.

That’s pretty shameful on my part as a technician, but it would be more shameful to conceal my mistake and not report what the issue was.

I do believe I exhausted every single other possible option before I realized it was the patch cable. Checking simple things first is hammered into all of us as troubleshooters, and the lesson has definitely been reinforced in me.

[Sebastian Roth]

@Wayne-Workman Thanks a lot for letting us know!!