Clarify conflicts with existing networking in README

[alexellis]

Clarify conflicts with existing networking in README

[ydp]

Hello, as boots only make sure that other machines won't get IP from boots, but how can we make sure our network booting machine does not get IP from existing DHCP server? Do we still need to add dhcp-ignore in existing DHCP server to prevent network booting get IP from existing DHCP server?

[alexellis]

[alexellis]

@nathangoulding who should this be assigned to, to get it resolved? A simple one-liner in the README is enough to disambiguate and reassure testers.

[nathangoulding]

@alexellis is this still valid?

[bingzhangdai]

Yes, the same question with @ydp. Should we modify the existing DHCP server? @alexellis

[bingzhangdai]

Hi @ydp I tried the demo in my local network and carefully checked the logs. You do not need to add the ignore in existing DHCP server. Both existing DHCP and Tinkerbell will respond to DHCP request, and the client will ignore the one without PXE info. Hence only Tinkerbell's DHCP will take effect, which is very handy.

[bingzhangdai]

Definitely, I would recommend adding the explanation in README.

[ydp]

@bingzhangdai Thanks for your reply! I did similar test before but get opposite answer. In my experiment, if client does not get pxe info, it just hangs. Maybe this is client related? related to the pxe version which is Nic related? or I should try more experiments?

[bingzhangdai]

@ydp I am not an expert in this area, but I can tell you what I saw.

First, you should check the boot container (if you run the example by docker compose) log to see if Tinkerbell did recieved the DHCP request. You should get something similar to this,

{"level":"info","ts":1691115288.4517825,"caller":"[email protected]/handler.go:105","msg":"","service":"github.com/tinkerbell/boots","pkg":"dhcp","pkg":"dhcp","event":"recv","mac":"ac:1f:6b:ee:0c:dc","via":"0.0.0.0","iface":"ens192","xid":"\"6c:ee:0c:dc\"","type":"DHCPDISCOVER","secs":4}
{"level":"info","ts":1691115288.451905,"caller":"boots/dhcp.go:88","msg":"parsed option82/circuitid","service":"github.com/tinkerbell/boots","pkg":"main","mac":"ac:1f:6b:ee:0c:dc","circuitID":""}
{"level":"info","ts":1691115288.4522583,"caller":"[email protected]/handler.go:61","msg":"","service":"github.com/tinkerbell/boots","pkg":"dhcp","pkg":"dhcp","event":"send","mac":"ac:1f:6b:ee:0c:dc","dst":"255.255.255.255","iface":"ens192","xid":"\"6c:ee:0c:dc\"","type":"DHCPOFFER","address":"10.3.1.21","next_server":"10.3.1.94","filename":"undionly.kpxe"}

This indicated that the DHCP was recieved and IP address was assigned.

Actually, I did expereince the hanging during IPXE initialising devices... in Hyper-v generation 1 VM, but I still got the above log

I do not know whether it is Tinkerbell's problem or just incompatibility between Tinkerbell and Hyper-v's NIC or PXE. I turned my head to physical machines and then succeeded. By looking carefully at the screeshot, what I can tell for sure is the hanging I encountered had nothing to do with DHCP.

Hope this would help. :)

[ydp]

Thank you @bingzhangdai I will try more experiments!

[ydp]

I did more experiments (20 times pxe boot on 2 machines), only one machine stuck in below status in one time (which could be a potential ipxe or networking issue).

so, looks like the problem does not exist!!
At least, the first phase when Intel boot agent try to get pxe info, it will not hang, unless there is absolutely no pxe info returned by any dhcp servers, which I also did an experiment, it will hang with error like this:

Then, I found that I actually recorded the process when I had the stuck issue several months ago, below is the screenshot:

Indeed, the Intel boot agent works well, it only hangs at ipxe booting phase.

Then I remembered that back then I did not actually use tinkerbell boots, I was using Openstack Ironic to boot machines, the ipxe binary used was 1.21.1+git-20220113, but now, the ipxe version I am using is 1.0.0+ (from the first screenshot), and I checked the code commit used is tinkerbell/ipxedust#76 , which is using ipxe binary from 2023/03/07, which is much newer.
So, I guess the old ipxe binary has issue to ignore the incorrect dhcp server, in my case it is 10.106.62.254 , the correct dhcp server should be 10.106.55.171 .
Anyway, as long as no issue happens like the second screenshot, I would think boots and Intel boot agent work well regarding ignoring other dhcp server.

[bingzhangdai]

Glad to hear. "No boot framework" or "nothing to boot" may also result from missing files from tftp like initramfs-aarch64, initramfs-x86_64, vmlinuz-aarch64, vmlinuz-x86_64 or so. I can see the error from boots log. Anyway, it is merely a minor problem :)

[ydp]

Hi @bingzhangdai Just let you know, I am still not convinced by the experiment result, and asked questions in ipxe/ipxe#1012 , they told me it should be undefined behavior. So for safety reason, even though my several experiments showed success, I will still switch back to "only one DHCP" environment.