Re: dhcp/bonding interaction question

Chris Friesen [off-list ref] wrote:

Jay Vosburgh wrote:

quoted

Chris Friesen [off-list ref] wrote:

[...]

Yes, the dhcp code in the kernel does this.

	Ah, I didn't know that.

quoted

	I'm guessing your problem is really due to the nature of the
intra-chassis network on the blade system.  If it's like the ones I'm
familiar with (eth0 of all blades to a single switch, eth1 of all blades
to a different switch, etc), then you can't configure the switches into
an etherchannel group as can be done with the usual configuration
(multiple ports on one switch).

This has been handled already.  The two switches are a single etherchannel
group and all blades (except the booting one) have etherchannel enabled.

	Ok, so your problem (if I'm understanding things correctly) is
really a chicken-and-egg type of deal.  Your entire network is all
etherchannel, except for this blade, which needs to connect,
temporarily, in a non-etherchannel manner in order to boot up and become
etherchannel-ified (at which point it'll work).

	One possible problem with hacking the dhcpd to send back out on
the receiving interface is that (because of the etherchannel) there's no
general guarantee that the switch paths are symmetrical, particularly if
a port is down somewhere.

That's not a problem.  We've got an older version, but support for
querying which slave a packet arrived on has been added.

	If you're already rolling your own kernels, would it be easier
to remove the xid interface check from the kernel's dhcp client (i.e.,
accept the DHCP reply as if it had arrived on the proper interface for
its xid)?  You could make it into some kind of "netboot_on_etherchannel"
option.

	-J

---
	-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com