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: <6323.1222188151@death.nxdomain.ibm.com>
Date:	Tue, 23 Sep 2008 09:42:31 -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:

>We've got a boot server configured with two bonded links using the XOR tx
>mode.  Another board comes up.  It's got two links which will eventually
>be bonded.  It issues a DHCP request to the server over one of the links,
>which arrives on one of the bonded slaves.  The server sends a reply, but
>the XOR results in the packet being sent back via the other slave.  On the
>booting blade the xid in the packet doesn't match the xid for the device
>on which the packet was received, so the packet is dropped.

	Presumably the blade is matching xid on a per-interface basis.

	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).  If the other blades in the chassis
aren't also configured for etherchannel (balance-xor is an etherchannel
compatible mode), then they'll see the same MAC arriving on multiple
interfaces and not really be prepared to deal with it.

>What's the proper solution here?  Should dhcpd be forcing reply packets
>out the slave on which the packet was received?

	Why is the blade issuing DHCP before the bond is configured?

	I'm unsure as to whether dhcpd should force replies as
suggested, but recent changes to bonding/net core would probably permit
dhcpd to run directly on the slave (it might need tweaking, I'm not
sure) and accomplish that result.  I don't think it would work on older
versions of bonding, since there's no way to tell which slave a packet
arrived on.

	In that case, dhcpd would have to run on all slaves, since a
bond that uses DHCP for its address assignment might use any of its
interfaces to issue the request, and it would accept a response on any
interface.

	-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