Bug 1680185

Summary: iPXE fails sometimes fails to configure NIC during ironic introspection
Product: Red Hat Enterprise Linux 7 Reporter: Mircea Vutcovici <mircea.vutcovici>
Component: ipxeAssignee: Neil Horman <nhorman>
ipxe sub component: ipxe-bootimgs QA Contact: Raviv Bar-Tal <rbartal>
Status: CLOSED NOTABUG Docs Contact:
Severity: urgent    
Priority: urgent CC: bfournie, dsneddon, hjensas, ietingof, marjones, mburns, mircea.vutcovici, racedoro
Version: 7.4Flags: nhorman: needinfo? (mircea.vutcovici)
Target Milestone: rc   
Target Release: 7.4   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-07 17:52:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mircea Vutcovici 2019-02-22 23:31:51 UTC
Description of problem:
Running ironic introspect fails from time to time during iPXE network boot.
Recent versions of iPXE seems stable.


Version-Release number of selected component (if applicable):
4e85b27 - broken
272fe32 - working


How reproducible:
20-30%

Steps to Reproduce:
1. run ironic introspection a couple of times
2.
3.

Actual results:
No configuration methods succeeded (http://ipxe.org/040ee119)
No DHCP requests from iPXE. However we can see the DHCP requests from PXE/UNDI see po108-22.pcap.gz file attached to the case)


Expected results:
iPXE to send a DHCP Discover


Additional info:

We compiled iPXE that is working with following command line:
make bin/undionly.kpxe DEBUG=scsi:3,iscsi:3,http:7,undi:7,undirom:7,pci:3

This is the working commit:
commit 272fe32529103dd39875a9fbed5cfdf1a059e294 (HEAD -> master, origin/master, origin/HEAD)
Date:   Thu Feb 21 11:32:25 2019 +0000

Comment 6 Neil Horman 2019-02-25 22:50:15 UTC
there should be plenty of debugging available in ipxe, at least to start work on this problem.  If you rebuild the package with the environment DEBUG=bnx2:8 or DEBUG=net:8, you should get significant output detailing operations on the network card in question

Comment 7 Dan Sneddon 2019-02-27 19:33:18 UTC
The fact that introspection fails intermittently indicates that there might be a race condition. It might be worth reducing the LACP fallback timeout, that way the link will be available as an individual link earlier in the boot cycle. The default is 90 seconds, but 60 seconds might be more likely to succeed. The default LACP reception interval is 30 seconds, and this value needs to be higher than that.

  interface Port-Channel119
  port-channel lacp fallback timeout 60

Comment 8 Mircea Vutcovici 2019-02-28 14:13:31 UTC
Hi,

I do not think the issue is caused by LACP fallback timeout. The reasons are:
- PXE has never problem in doing a DHCP transaction then TFTP doenaload
- if we go into iPXE command line, and run `ifconf` manually, we are not able to obtain an IP no mater how many times we try
- Soft reboot initiated by iPXE solves the problem after a few reboots
- LACP timeout is not variable. The issue would show all the times.

Comment 9 Neil Horman 2019-02-28 15:14:31 UTC
wait, are you running bonding in ipxe?  Does this work if you don't configure bonding?

Comment 10 Mircea Vutcovici 2019-03-01 15:05:52 UTC
iPXE doesn't support bonding. This means it will try to use the links directly not as a LACP member. However the switch is configured for LACP fallback and it will reconfigure the switch ports to behave as normal ports when no LACP frames are received in 60 seconds.

Comment 11 Dan Sneddon 2019-03-01 17:45:10 UTC
(In reply to Mircea Vutcovici from comment #8)
> Hi,
> 
> I do not think the issue is caused by LACP fallback timeout. The reasons are:
> - PXE has never problem in doing a DHCP transaction then TFTP doenaload
> - if we go into iPXE command line, and run `ifconf` manually, we are not
> able to obtain an IP no mater how many times we try
> - Soft reboot initiated by iPXE solves the problem after a few reboots
> - LACP timeout is not variable. The issue would show all the times.

I agree that given the above, LACP timeout is not likely to be the culprit.

Comment 12 Neil Horman 2019-04-10 16:53:51 UTC
ping, mircea, see comment 9?