Feature #2240

Full Multiple Interface Support

Added by Anonymous over 8 years ago. Updated about 7 years ago.

Target version:
Bugzilla link:
Pull request:
Fixed in Releases:
Found in Releases:


Foreman multiple interface support is currently lacking compared to cobbler. It does not support bonded or subinterfaces in any way, and so far as I can tell there is no way to associate a device name with the interface name in foreman.

Cobbler on the other hand has fields that allow for entering the interface device name, fgqn, ip, netmask, bonding master, opts, mode, etc.

This makes it trivial to tack on this information in an enc script as parameters returned to puppet so you can automate configuration of anything from a single interfaces, to multiple bond interfaces each with multiple slaves (i.e., bond0 with eth0 and eth1 as slaves, and bond1 with eth2 and eth3 as slaves), to sub-interfaces (i.e, eth0:1) and so on.

The values can be printed out as the user prefers based on how they want to split it out so really it's just nice to have it all accessible , but today with cobbler it's easy to print out things like:
- bond0|static|||master||true
- eth1|none|||slave|bond0|true
- eth0|none|||slave|bond0|true
- bond0:1|static|||||true

split it out in a puppet module, and configure your interfaces.

Really all that is needed is to be able to input the additional information and have it available via https://<foreman_url>/hosts/<host>?format=json as what exists today is already available so it can be printed out however the user sees fit.

Interface ===== : eth0
Bonding Mode :
Bonding Master :
Bonding Opts :
DHCP Tag :
DNS Name :
IP Address :
MAC Address :
Static : False
Static Routes : []
Subnet :
Virt Bridge :

Related issues

Related to Foreman - Feature #2156: Be able to set netmask and not mac when using multiple nicsResolved2013-01-24
Related to Foreman - Feature #2089: Expose network configuration via ENCClosed2013-01-02
Related to Foreman - Tracker #2409: NetworkingNew

Related to Foreman - Feature #3695: Add a device name to additional host interfacesResolved2013-11-19
Related to Foreman - Feature #2241: @host.interfaces not populated in templatesResolved2013-02-21

Associated revisions

Revision d455f32c (diff)
Added by Marek Hulán about 7 years ago

Fixes #6444 - add support for virtual NICs

Extend additional interface details refs #2240

NIC facts parsing change and we create interfaces in Foreman according
to facts we recieve.

Subclasses does not define their own attributes and serialize them to
attrs hash. All BMC attributes are extracted to separate columns so it's
possible to search NICs by those attributes. Attrs can still be used for
custom attributes (e.g. coming from facts).

NIC form was ajaxified which means that we redraw the form for
particular interface class. We can easily define custom forms for
various interfaces types.

Added support for virtual and physical interfaces. Initial support for bridges
(to keep tests green). New attributes can be set via UI as well.

IPMI facts parsing and BMC NIC creation based on custom facts that are
present in discovery image.

NIC orchestration is now optional and can be set for every interface.
All created interfaces based on facts (BMC or Managed) are not

Store and update primary interface identifier in host.

Allow subnet selection without domain for NIC so we can use DHCP only.

Suggest IP addresses even without proxy by Foreman itself. Foreman finds
first free IP on a particular Subnet based on records in database.


#1 Updated by Benjamin Papillon over 8 years ago

I add a relation with the feature I asked few days ago. This one express much more clearly the issue than the one I wrote :)

#2 Updated by Anonymous over 8 years ago

I took what an additional host interface looks like in Foreman today:


And kind of mocked up an idea of what I was thinking the interface array might look like (with some spaces just for sanity) so that people could do bonding and sub-interfaces. One thing about this is that it includes the 'primary interface', versus how it is outside of the array created today. I guess that's not too much of an issue as long as it can be made part of bonds, etc.

As far as UI, it might be easier to select whether the interface you are creating is a standard interface, bonding slave, bonding master, or sub-interface and filling out any mandatory or optional fields for each that way. I'm not really too worried about Foreman validating the configs that I enter either, though down the road it may be nice. But I don't believe cobbler is doing that right now, probably because it would be a bit difficult to validate.

Also, after talking to Sam today I realized that people might see value in being able to create bridges and assign interfaces to a bridge, and though it is not something we do today, others might certainly see value in that.

[ {"device":"eth0","bonding-opts":"","bonding-master":"bond0","bonding-mode":"slave","name":"somehost","ip":"","id":3,"subnet_id":1,"updated_at":"2013-02-26T18:21:16Z","mac":"00:11:22:33:44:55","attrs":null,"created_at":"2013-02-26T18:21:16Z","domain_id":1,"host_id":34},


{"device":"bond0","bonding-opts":"mode=1 miimon=500","bonding-master":null,"bonding-mode":"master","name":"somehost","ip":"","id":3,"subnet_id":1,"updated_at":"2013-02-26T18:21:16Z","mac":null,"attrs":null,"created_at":"2013-02-26T18:21:16Z","domain_id":1,"host_id":34},


#3 Updated by Dominic Cleal about 8 years ago

#4 Updated by Dominic Cleal almost 8 years ago

  • Related to Feature #3695: Add a device name to additional host interfaces added

#5 Updated by Jon Shanks over 7 years ago

This is something that i've created a snippet for, ideally this needs to be a plugin really to foreman, which i did want to create but not had time.

So far i have used parameters defined at a host / host group level.

The layout i chose was:

Then for bonding the extras would be:

And for vlans, the extras would be:

i.e. eth1_name, eth1_address , eth1_gateway. eth1_netmask

for bonding it would be

bond0_name="some name of the bond"
bond0_options="mode=1 miimon=100 downdelay=200 primary=eth0"

Or if the bond was to have a specific iP:
bond0_address = ""
bond0_netmask = ""
bond0_gateway = ""
bond0_options = "mode=1 miimon=100 downdelay=200 updelay=200 primary=eth2 use_carrier=1 primary_reselect=2"options
bond0_name = "Some name"

  1. Vlan interface with IP configuration
    vlan123_name = "Some vlan name"
    vlan123_device = "bond1"
    vlan123_address = ""
    vlan123_netmask = ""
    vlan123_gateway = ""
Or if you were using VCS and it was managing the actual vlan to add the ip and such then just creating the vlan to a bond would be
  1. VLAN interface with no IP config
    vlan1234_name = "Some vlan name"
    vlan1234_device = "bond0"

Basically all of the networking is done at build time so this doesn't need to be managed elsewhere with puppet, which can be a bit of a nightmare to do i.e. rejigging interfaces when puppet requires network connectivity is not always the easiest approach.

#6 Updated by Benjamin Papillon over 7 years ago

  • Related to Feature #2241: @host.interfaces not populated in templates added

#7 Updated by Marek Hulán about 7 years ago

  • Description updated (diff)
  • Status changed from New to Closed

Closing this one since it was split into smaller tasks which are being tracked in #2409

Also available in: Atom PDF