intel I219-v big problem

[plegrand]

Hello,
We are experiencing major problems on about fifteen workstations equipped with the following network card: Intel I219-V.
We use FOG in many rooms without any problems, but this one is causing us a lot of trouble.
Debian Stable
FOG 1.5.10

The workstations boot PXE with difficulty, and the boot time increases as more workstations are connected.
Subsequently, the deployment happens with a calamitous throughput
The only things I can see are in our DHCP server logs, where dhcp requests from these workstations occur every 2-3 seconds.
The curious thing is that these requests only appear via the switch’s mac address.
…/…
oct. 27 13:52:30 tamtam dhcpd[26231]: DHCPDISCOVER from 2c:fa:a2:1a:eb:b0 via enp2s0
oct. 27 13:52:31 tamtam dhcpd[26231]: DHCPOFFER on 192.168.39.156 to 2c:fa:a2:1a:eb:b0 (vxTarget) via enp2s0
oct. 27 13:52:31 tamtam dhcpd[26231]: DHCPREQUEST for 192.168.39.156 (192.168.39.247) from 2c:fa:a2:1a:eb:b0 (vxTarget) via enp2s0
oct. 27 13:52:31 tamtam dhcpd[26231]: DHCPACK on 192.168.39.156 to 2c:fa:a2:1a:eb:b0 (vxTarget) via enp2s0
…/…
The switch is working properly, as it has already been used in other rooms without any problems.
I could see on the net that this card could cause this kind of problem without really finding a solution.
Have you got any idea about this problem ?

[plegrand]

For information, this is our dhcp configuration:
…/…
option client-architecture code 93 = unsigned integer 16;
…/…

…/…
next-server 192.168.39.243; #FOG
if exists client-architecture {
if option client-architecture = 00:00 { #LEGACY
filename “ipxe.pxe”;
} elsif option client-architecture = 00:02 { #UEFI-32bits
filename “i386-efi/ipxe.efi”;
} elsif option client-architecture = 00:06 { #UEFI-32bits
filename “i386-efi/ipxe.efi”;
} elsif option client-architecture = 00:07 { #UEFI-64bits
filename “ipxe.efi”;
} elsif option client-architecture = 00:08 { #UEFI-64bits
filename “ipxe.efi”;
} elsif option client-architecture = 00:09 { #UEFI-64bits
filename “ipxe.efi”;
}
}
}
…/…

[george1421]

@plegrand Is the dhcp server on the same subnet as the pxe booting computers?

Is the dhcp server running on the fog server?

Is there by chance a second dhcp server on this network?

Does this switch have dhcp snoopling enabled?

Running wireshark or using tcpdump on that network with the capture filter of port 67 or port 68 or us the display filter of bootp should show you the DORA process (Discover, Offer, Request, Ack/nak). The dhcp server might either not be responding in a timely manner or you have more than one dhcp server on your subnet. I haven’t seen this type of error before so there is something unique going on with this network.

[plegrand]

@george1421
Hello george1421 and thanks for your answer

• Our dhcp server is a separate server not running on the fog server
• It’s the only dhcp server on the network.
• It works very fine and we have no problem for all computers of our network.
• We use this switch for other computers without problem
• dhcp snooping is for multicast no ?
  The only problem is for these computers with these kind of NIC

Thanks again

[plegrand]

@george1421
None of our switches are configured with dhcp snooping and everything works fine.
The only problem is this room with these network cards.

[george1421]

@plegrand said in intel I219-v big problem:

The only problem is this room with these network cards.

I find it suspicious why only these network cards have a problem. The problem doesn’t sound specific to FOG, but more on the dhcp layer. The next step I would say is to get a pcap from a witness computer on the same subnet and from the same switch to see what is “flying down the wire” so to speak. It would be interesting to get a pcap of a working and non-working computer in the same lab, off the same switch.

FWIW, dhcp snooping is dhcp specific to limit/restrict the impact of rogue dhcp servers. igmp snooping is related to mulicasting and publishers and subscribers.

[Tom Elliott]

@george1421 This sounds very similar to old old equipment?

Hubs vs Switches and the Hub is literally at capacity

[george1421]

@Tom-Elliott We’ve also seen some strange interaction between green ethernet settings on some switches and these new (at the time) l219-v network adapters too. But I really don’t think that fits here since I can assume they use this switch model across their campus.

[Tom Elliott]

@george1421 Just thinking outside the box as it makes 0 sense for it to be “just these network cards”

I suppose the “real” test would be seeing if outside of this room if the same problem happens?

I know not simple, but if you can move the whole room to an area where we know this issue doesn’t currently exist, and it shows, then it’s likely specific to this equipment. If it doesnt’ show up, it’s likely something specific to that particular room.