netdev - Re: dhcp/bonding interaction question

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <21694.1222193834@death.nxdomain.ibm.com>
Date:	Tue, 23 Sep 2008 11:17:14 -0700
From:	Jay Vosburgh <fubar@...ibm.com>
To:	"Chris Friesen" <cfriesen@...tel.com>
cc:	netdev@...r.kernel.org
Subject: Re: dhcp/bonding interaction question

Chris Friesen <cfriesen@...tel.com> wrote:

>Jay Vosburgh wrote:
>> Chris Friesen <cfriesen@...tel.com> wrote:
[...]
>Yes, the dhcp code in the kernel does this.

	Ah, I didn't know that.

>> 	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@...ibm.com
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html