cloud-init fails to configure bonding on CentOS 7

Bug #1701417 reported by Lee Trager on 2017-06-30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ryan Harper

Bug Description

When using ppa:raharper/curtin-dev and the cloud-init-curtin yum repo[1] with MAAS configuring the node to use bonding networking never comes up causing the deployment to fail.



  preserve_sources_list: false
  - arches:
    - default
  - arches:
    - default
    content: "#cloud-config\ndatasource:\n MAAS: {consumer_key: 72gtz4EuywxY9wtaTy,\
      \ metadata_url: '',\n token_key: H24Erg25Cx9Q8hHJrp,\
      \ token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS}\n"
    path: /etc/cloud/cloud.cfg.d/90_maas_cloud_config.cfg
    content: 'datasource_list: [ MAAS ]'
    path: /etc/cloud/cloud.cfg.d/90_maas_datasource.cfg
    content: '#cloud-config

      snappy: {email: <email address hidden>}

    path: /etc/cloud/cloud.cfg.d/90_maas_ubuntu_sso.cfg
  maas: 'cloud-init cloud-init/datasources multiselect MAAS

    cloud-init cloud-init/maas-metadata-url string

    cloud-init cloud-init/maas-metadata-credentials string oauth_token_key=H24Erg25Cx9Q8hHJrp&oauth_consumer_key=72gtz4EuywxY9wtaTy&oauth_token_secret=7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS

    cloud-init cloud-init/local-cloud-config string apt:\n preserve_sources_list:
    false\n primary:\n - arches: [default]\n uri:\n proxy:\n security:\n - arches: [default]\n uri:\napt_preserve_sources_list:
    true\napt_proxy:\nmanage_etc_hosts: false\nmanual_cache_clean:
    true\nreporting:\n maas: {consumer_key: 72gtz4EuywxY9wtaTy, endpoint: '''',\n token_key:
    H24Erg25Cx9Q8hHJrp, token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS,\n type:
    webhook}\nsystem_info:\n package_mirrors:\n - arches: [i386, amd64]\n failsafe:
    {primary: '''', security: ''''}\n search:\n primary:
    ['''']\n security: ['''']\n -
    arches: [default]\n failsafe: {primary: '''',
    security: ''''}\n search:\n primary:
    ['''']\n security: ['''']\n

  log_file: /tmp/install.log
  - /tmp/install.log
  - wget
  - --no-proxy
  - --post-data
  - op=netboot_off
  - -O
  - /dev/null
  - id: ens10
    mac_address: 52:54:00:4b:11:ea
    mtu: 1500
    name: ens10
    - type: manual
    type: physical
  - id: ens3
    mac_address: 52:54:00:aa:40:cd
    mtu: 1500
    name: ens3
    - type: manual
    type: physical
  - bond_interfaces:
    - ens10
    - ens3
    id: bond0
    mac_address: 52:54:00:aa:40:cd
    mtu: 1500
    name: bond0
      bond-downdelay: 0
      bond-lacp-rate: slow
      bond-miimon: 100
      bond-mode: active-backup
      bond-updelay: 0
      bond-xmit-hash-policy: layer2
    - address:
      dns_nameservers: []
      type: static
    type: bond
  - address:
    - maas
    type: nameserver
  version: 1
  - curtin
  - net-meta
  - custom
    consumer_key: 72gtz4EuywxY9wtaTy
    token_key: H24Erg25Cx9Q8hHJrp
    token_secret: 7jC2PWsGcrxcvHNPw8yHyz2zf76DcEFS
    type: webhook

Related branches

Lee Trager (ltrager) wrote :
Ryan Harper (raharper) wrote :

Jun 30 02:02:39 localhost kernel: Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Jun 30 02:02:39 localhost kernel: bond0: Setting MII monitoring interval to 100
Jun 30 02:02:39 localhost kernel: bond0: Setting xmit hash policy to layer2 (0)
Jun 30 02:02:39 localhost network: Bringing up interface bond0: ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Device bond0 has different MAC address than expected, ignoring.
Jun 30 02:02:39 localhost /etc/sysconfig/network-scripts/ifup-eth: Device bond0 has different MAC address than expected, ignoring.
Jun 30 02:02:39 localhost network: [FAILED]
Jun 30 02:02:39 localhost systemd: network.service: control process exited, code=exited status=1
Jun 30 02:02:39 localhost systemd: Failed to start LSB: Bring up/down networking.
Jun 30 02:02:39 localhost systemd: Unit network.service entered failed state.
Jun 30 02:02:39 localhost systemd: network.service failed.

In centos7; it doesn't like it when you specify a mac address for the bond itself (rather the bond will pick a mac from the slaves.

MAAS can *not* send a mac for a bond (unless someone is being explicit in the UI that they expect the bond to have a mac of <mac>).

Changed in maas:
milestone: none → 2.3.0
status: New → Triaged
status: Triaged → Incomplete
Mike Pontillo (mpontillo) wrote :

It looks like on CentOS there are two configuration keys for specifying the MAC[1], which have a subtle difference:

where <MAC-address> is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive is useful for machines with multiple NICs to ensure that the interfaces are assigned the correct device names regardless of the configured load order for each NIC's module. This directive should not be used in conjunction with MACADDR.

where <MAC-address> is the hardware address of the Ethernet device in the form AA:BB:CC:DD:EE:FF. This directive is used to assign a MAC address to an interface, overriding the one assigned to the physical NIC. This directive should not be used in conjunction with HWADDR.

HWADDR should be used to *identify* the NIC, such as for physical interfaces, whereas MACADDR is used to *configure* the MAC address, such as if you want a non-default MAC for a bond or bridge (AIUI).

In other words, maybe it isn't working because we're using HWADDR in the bond configuration, when it should be using MACADDR?


Lee Trager (ltrager) wrote :

After the deployment failed I booted into rescue mode and edited the bond configuration file to not define slaves(they already define who the master is) and used MACADDR instead of HWADDR. cloud-init was rewriting the config so I had to disable that as well and created a user manually. After I did that CentOS 7 booted with bonding working using the correct MAC address.

# diff -u ifcfg-bond0.orig ifcfg-bond0
--- ifcfg-bond0.orig 2017-07-05 21:12:58.485061715 +0000
+++ ifcfg-bond0 2017-07-05 21:59:27.827526638 +0000
@@ -2,13 +2,11 @@
 BONDING_OPTS="mode=active-backup xmit_hash_policy=layer2 miimon=100"

Ryan Harper (raharper) wrote :

AFAIK, the BONDING_SLAVE{N}=<slave> is the desired format. Other than s/HWADDR/MACADDR, can you confirm the dropping of the BONDING_SLAVEN is needed?

Ryan Harper (raharper) wrote :

I think this covers it; will test and update the curtin-cloud-init centos repo shortly.

Changed in cloud-init:
importance: Undecided → Medium
status: New → In Progress
Scott Moser (smoser) on 2017-07-21
Changed in cloud-init:
status: In Progress → Fix Committed
assignee: nobody → Ryan Harper (raharper)
no longer affects: maas

This bug is believed to be fixed in cloud-init in 17.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments