dual stack IPv4/IPv6 configuration via config drive broken for RHEL7

Bug #1679817 reported by Alain Swanson on 2017-04-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Andreas Karis

Bug Description

Currently, if a network interface has both IPv4 and IPv6 configuration information (via network_data.json), cloud-init creates separate aliases files for IPv4 (i.e. ifcfg-eth0:0) and IPv6 (ifcfg-eth0:1) network configuration information. This results in an error when attempting to ifup eth0:

/etc/sysconfig/network-scripts/ifup-aliases: error in ifcfg-eth0:1: didn't specify device or ipaddr

I believe this error is occurring because RHEL expects/requires an IPv4 address within any aliases file.

Red Hat documentation (https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s2-networkscripts-interfaces-alias.html) seems to indicate that alias files are supported only for IPv4 information and even then secondary addresses within the primary interface file is the preferred method.

Furthermore, it appears that multiple IPv6 addresses on the same interface should use the IPV6ADDR_SECONDARIES parameter in the primary interface file rather than using IP alias files (see here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/s1-networkscripts-interfaces.html).

I believe this issue can be resolved by eliminating the use of alias files and instead configuring IPv4 and IPv6 within the primary interface file (i.e. ifcfg-eth0). Here's an example:

# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=static
DEVICE=eth0
HWADDR=fa:16:3e:b2:4b:d4
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
DEFROUTE=yes
GATEWAY=10.252.197.129
IPADDR=10.252.197.143
NETMASK=255.255.255.224
IPV6ADDR=2620:160:d2ff:1c07::b
IPV6INIT=yes
IPV6_DEFAULTGW=2620:160:d2ff:1c07::1

Related branches

Andreas Karis (akaris) on 2017-04-21
Changed in cloud-init:
assignee: nobody → Andreas Karis (akaris)
Andreas Karis (akaris) wrote :

IPv6 routes are created in route- and handled the same as IPv4 routes. Bad syntax according to /usr/share/doc/initscripts-9.49.37/sysconfig.txt and hence IPv6 routes are not created.

/etc/sysconfig/network-scripts/route-<interface-name>

  Contains lines that specify additional routes that should be added when the
  associated interface is brought up.

  The files are processed by the ifup-routes script and uses the /sbin/ipcalc
  utility for all network masks and numbers. Routes are specified using the
  syntax:

    ADDRESSn=<network>
    NETMASKn=<network/prefix mask>
    GATEWAYn=<next-hop router/gateway IP address>

  The "n" is expected to be consecutive positive integers starting from 0.
  For example:

    ADDRESS0=192.168.2.0
    NETMASK0=255.255.255.0
    GATEWAY0=192.168.1.1

  adds a network route to the 192.168.2.0 network via the gateway at
  192.168.1.1. Since you must already have a route to the network of the
  gateway, there is no need to specify a device.

  Note: The ifup-routes script also supports an older syntax designed to be
  used directly as an argument to "/sbin/ip route add".
  If no "ADDRESSn" lines are found the following will still
  work:

  192.168.2.0/24 dev ppp0

  adds a network route to the 192.168.2.0 network through ppp0.

/etc/sysconfig/network-scripts/route6-<interface-name>

  Contains lines that are arguments to "/sbin/ip -6 route add"
  For example:

  site-local route for network fec0:0:0:2::/64
   via gateway fec0:0:0:1:0:0:0:20 (e.g. on eth0):

  fec0:0:0:2::/64 via fec0:0:0:1:0:0:0:20

  additional prefix configured to be on-link on eth0:

  3ffe:fffe:1:2::/64 dev eth0

  6to4 route for network 3ffe:ffff:1::/48, either:

  3ffe:ffff:1::/48
  3ffe:ffff:1::/48 via ::192.168.1.2

  Note the special case of 6to4 interface: 'via [relay]' is
  automatically added if explicit 'via' wasn't specified.

BOOTPROTO=static should be BOOTPROTO=none according to documentation

    BOOTPROTO=none|bootp|dhcp
      'bootp' or 'dhcp' cause a DHCP client to run on the device. Any other
      value causes any static configuration in the file to be applied.

Scott Moser (smoser) on 2017-05-17
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
Scott Moser (smoser) on 2017-05-23
Changed in cloud-init:
status: Confirmed → Fix Committed

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