Bug #13024


Bond0 and eth0 share IP causing duplicate IP conflict when bond0 is created after kickstart and subsequently imported

Added by Brian Imbriani almost 8 years ago. Updated almost 8 years ago.

Target version:
Fixed in Releases:
Found in Releases:


After a discussion with the #theforeman support IRC channel, I was advised to create this ticket. Via kickstart, we assign eth0 an IP address, and after the machine is kickstarted, we (via puppet or manually or both) create a bond0 interface, which takes the IP that was originally on eth0. The bond0 interface then gets imported into foreman, and we're stuck with a duplicate IP address issue where we can't make any changes to the host.

This was "fixed" by not importing bond* interfaces, however that seems like a work-around more than a fix.

My suggestion might be something that if bond0 has a "member" eth0, and they both have the same IP, then that should be "allowed" as a duplicate IP. Exact quote:

--------BeeAyeEye> mhulan: i mean, this is ugly but, if the interface is bonded, and one of it's "members" is the interface it's sharing an ip with, can't we make an exception for that

I understand that in the end, the solution doesn't matter but we would need to be able to kickstart (provision) via the eth0 (or whatever) interface, but have bond0 created / managed after the initial boot / kickstart of a machine.

Related issues 1 (1 open0 closed)

Related to Foreman - Bug #11705: hosts added through fact upload set FQDN to eth instead of bond interfaceNew09/07/2015Actions
Actions #1

Updated by Greg Sutcliffe almost 8 years ago

Cut'n'paste from my part of this discussion around inheritance from bond to slave devices

<gwmngilfen> foreman should be definitive - if the slaves could "inherit" the ip where required, then you could define eth0, eth1 and bond0 in foreman and disable all fact importing
<gwmngilfen> that way it would work for kickstart
<mhulan> gwmngilfen: anaconda can't install system using bond (or at least in older versions)
<mhulan> gwmngilfen: not sure about debian and ubuntu
<gwmngilfen> mhulan: right, i'm saying we could have bond0 => and eth0 blank, but for writing dhcp etc, eth0 could inherit the ip from the bond
<gwmngilfen> then we keep our uniqueness, but we can still kickstart off eth0
<mhulan> gwmngilfen: how would you know which mac to pick? eth1 or eth0?
<gwmngilfen> mhulan: no idea. i didn;t say it was a ready-to-implement idea ;)

Actions #2

Updated by Marek Hulán almost 8 years ago

  • Description updated (diff)

Another approach might be a flag on bond interface with meaning "steal primary flag after provisioning" so user would mark bond that would become new primary interface (stealing also IP, the MAC would have to be fetched from original primary interface)

Actions #3

Updated by Fernando Carolo almost 8 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions #4

Updated by Dominic Cleal almost 8 years ago

  • Status changed from Closed to New
  • % Done changed from 100 to 0

Apologies, that commit should have been for #13042.

Actions #5

Updated by Anonymous over 6 years ago

  • Related to Bug #11705: hosts added through fact upload set FQDN to eth instead of bond interface added

Also available in: Atom PDF