Date
1 - 4 of 4
Bonding support for PXE Boot
Michael Brown
On 06/02/2021 04:36, UdayS via groups.io wrote:
Network booting requires only a few seconds of data transfer that can trivially be retried if the link happens to be disrupted. iPXE therefore includes only a very simple LACP responder: any time it receives an LACP packet it will send a reply with some sane default values. For switch ports that have been configured to use port bonding with LACP, this is sufficient to convince the switch that the port is active.
I don't see any reference to port bonding within the EDK2 source code, so it doesn't look as though it's supported yet by standard UEFI PXE boot, sorry.
Hope that helps,
Michael
How can I support Bonding of ports and use new Virtual interface for PXE Boot in Hot-Standby mode in UEFI.Not sure if this would work in your boot scenario, but iPXE already allows you to PXE boot from a switch port that requires the use of port bonding via LACP (also known as IEEE 802.3ad or 802.1AX).
Is their any limitation on why it is NOT already supported yet.
Network booting requires only a few seconds of data transfer that can trivially be retried if the link happens to be disrupted. iPXE therefore includes only a very simple LACP responder: any time it receives an LACP packet it will send a reply with some sane default values. For switch ports that have been configured to use port bonding with LACP, this is sufficient to convince the switch that the port is active.
I don't see any reference to port bonding within the EDK2 source code, so it doesn't look as though it's supported yet by standard UEFI PXE boot, sorry.
Hope that helps,
Michael
UdayS
Thanks Michael.
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.
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.
Michael Brown
On 08/02/2021 10:59, UdayS via groups.io wrote:
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
We may have to see if we can implement something similar in UEFI driver.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.
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.
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