On 08/02/2021 10:59, UdayS via groups.io wrote:
We may have to see if we can implement something similar in UEFI driver.
One problem I see right away is : Incase port goes down and driver can add a capability to retry on other UP port, how to let UEFI SNP know of the change in MAC of new port. As PXE already has the address older interface.
If you were to choose to adopt iPXE's simple conceptual model then this would not be necessary. The boot firmware doesn't need to know or care that ports are participating in a bond: it just needs to be able to convince the switch to forward packets.
To illustrate: suppose that there are two physical interfaces on the host, connected to a switch that treats them as a bonded pair. Without any explicit configuration, an iPXE boot would go like this:
- iPXE opens the first interface ("net0") and starts sending DHCPDISCOVER
- The switch refuses to forward the DHCPDISCOVER packets and instead sends back LACP packets to check that the host is LACP-capable
- iPXE sees the LACP packet and sends back a response (which basically just says "yes, I can speak LACP, and this port is alive")
- iPXE defers timing out DHCP discovery while it waits for LACP to complete
- The switch sees the LACP response and starts forwarding packets
- Boot continues as expected
If there is a problem with the first port then iPXE would simply proceed to perform exactly the same process on the second port.
One major advantage of this scheme from the end-user perspective is that there is no need to configure anything bonding-related for the boot stage. It all Just Works with no user input required.
Michael