RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1519271 - Write correct BOOTPROTO in sysconfig files with ipv4+ipv6 on same interface
Summary: Write correct BOOTPROTO in sysconfig files with ipv4+ipv6 on same interface
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: cloud-init
Version: 7.4
Hardware: All
OS: All
urgent
urgent
Target Milestone: rc
: ---
Assignee: Ryan McCabe
QA Contact: Vladimir
URL:
Whiteboard:
Depends On: 1492726 1495441 1512530 1539760
Blocks: 1330217 1540093
TreeView+ depends on / blocked
 
Reported: 2017-11-30 14:10 UTC by Ryan McCabe
Modified: 2021-12-10 15:27 UTC (History)
20 users (show)

Fixed In Version: cloud-init-0.7.9-20.el7
Doc Type: Bug Fix
Doc Text:
Under certain circumstances, the cloud-init service incorrectly provided IPv4 configuration to the IPv6 boot protocol of a newly created virtual machine. As a consequence, the guest experienced a variety of network problems. With this update, cloud-init provides the appropriate IPv6 configuration.
Clone Of: 1495441
: 1540093 (view as bug list)
Environment:
Last Closed: 2018-04-10 14:08:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
bootproto contents for various scenarios with cloud-init v. 0.7.9-20-test (55.41 KB, application/pdf)
2017-12-17 13:01 UTC, eraviv 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:0806 0 None None None 2018-04-10 14:08:33 UTC
oVirt gerrit 82208 0 None MERGED restapi: IPv6 boot protocol is assigned the value of IPv4 boot protocol 2020-12-30 07:32:35 UTC

Comment 5 eraviv 2017-12-04 07:04:30 UTC 
yes 'etho' is a typo. 

Regarding sysconfig for both ipv4 and ipv6 dhcp - Thomas can you answer?
Comment 6 Thomas Haller 2017-12-04 09:59:56 UTC 
how about

IPV6INIT=yes
IPV6_AUTOCONF=yes

?
Comment 7 eraviv 2017-12-04 11:11:09 UTC 
as (In reply to Thomas Haller from comment #6)
> how about
> 
> IPV6INIT=yes
> IPV6_AUTOCONF=yes
> 
> ?

As far as we have managed to test on cloud-init 0.7.9-9, 'autoconf' was not supported. 
Ryan?
Comment 8 Ryan McCabe 2017-12-04 13:46:40 UTC 
(In reply to eraviv from comment #7)
> as (In reply to Thomas Haller from comment #6)
> > how about
> > 
> > IPV6INIT=yes
> > IPV6_AUTOCONF=yes
> > 
> > ?
> 
> As far as we have managed to test on cloud-init 0.7.9-9, 'autoconf' was not
> supported. 
> Ryan?

The NM docs (Table 42) at https://developer.gnome.org/NetworkManager/stable/nm-settings-ifcfg-rh.html indicates that IPV6_AUTOCONF should not be set to yes for ipv6 dhcp.
Comment 9 Thomas Haller 2017-12-04 14:32:43 UTC 
you are right, sorry. I think it should be 

IPV6INIT=yes
IPV6_AUTOCONF=no
DHCPV6C=yes

for DHCP.
Comment 10 Ryan McCabe 2017-12-04 14:43:33 UTC 
(In reply to Thomas Haller from comment #9)
> you are right, sorry. I think it should be 
> 
> IPV6INIT=yes
> IPV6_AUTOCONF=no
> DHCPV6C=yes
> 
> for DHCP.

This is what we have now, except for not explicitly setting IPV6_AUTOCONF to no (I believe this is how it defaults):


BOOTPROTO=dhcp
DEVICE=eth0
DHCPV6C=yes
IPV6INIT=yes
ONBOOT=yes
TYPE=Ethernet
USERCTL=no

The intent is to have both ipv4 and ipv6 for the interface.

Eitan, are there any errors logged that may be helpful in figuring out what's going wrong?
Comment 11 Ryan McCabe 2017-12-04 14:44:48 UTC 
reply to Ryan McCabe from comment #10)
> 
> The intent is to have both ipv4 and ipv6 for the interface.

Sorry, meant both ipv4 and ipv6 dhcp for the interface here.
Comment 12 Ryan McCabe 2017-12-04 18:42:06 UTC 
Sorry -- It appears I have misread the table initially and that the default for AUTOCONF is IPV6_AUTOCONF=!IPV6FORWARDING and the default for IPV6FORWARDING is yes, thus autoconf will default to yes. I will make a build that explicitly sets it to no and let's see if that resolves the issue.
Comment 14 eraviv 2017-12-17 13:01:55 UTC 
Created attachment 1369022 [details]
bootproto contents for various scenarios with cloud-init v. 0.7.9-20-test
Comment 15 eraviv 2017-12-17 13:05:14 UTC 
looks like  cloud-init v. 0.7.9-20-test solves the issue:

I tested both static and dhcp (with ipvX_dhcp notation) for:
- only ipv4
- only ipv6
- both

and got expected outcome in eth0 configuration. also had ping + login with expected ip addresses.
Comment 17 Vladimir 2017-12-19 15:23:56 UTC 
Hi, Ryan
I tried ot verify this bug using build 20, but still have same problem
CLoud-init version : 0.7.9-20.el7.x86_64

Network config:
  "availability_zone" : "nova",
  "hostname" : "cloud20",
  "launch_index" : "0",
  "meta" : {
    "role" : "server",
    "dsmode" : "local",
    "essential" : "false"
  },
  "name" : "cloud20",
  "uuid" : "3803da95-f2ea-460a-8b2f-5fd29e215b52"
  "links" : [ {
    "name" : "eth0",
    "id" : "eth0",
    "type" : "vif"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "eth0",
    "id" : "eth0",
    "ip_address" : "10.0.0.1",
    "type" : "ipv4",
    "gateway" : "10.0.0.254"
  }, {
    "link" : "eth0",
    "id" : "eth0",
    "type" : "dhcp6"
  } ]


Actual ifcfg:
BOOTPROTO=dhcp
IPADDR=10.0.0.1
....

So we don't have any mentions of IPv6 here and IPv4 is set to dhcp
Comment 18 Ryan McCabe 2017-12-19 15:35:21 UTC 
(In reply to Vladimir from comment #17)
> Hi, Ryan
> I tried ot verify this bug using build 20, but still have same problem
> CLoud-init version : 0.7.9-20.el7.x86_64
> 
>   }, {
>     "link" : "eth0",
>     "id" : "eth0",
>     "type" : "dhcp6"

This should be "ipv6_dhcp" not "dhcp6." What produced the json?
Comment 19 Ryan McCabe 2017-12-19 15:45:12 UTC 
There is also a missing comma after the uuid.
Comment 20 Vladimir 2017-12-20 08:37:58 UTC 
It's RHEV 4.2.0.2-0.1.el7 (downstream build)
Comment 21 eraviv 2017-12-20 10:55:24 UTC 
(In reply to Vladimir from comment #20)
> It's RHEV 4.2.0.2-0.1.el7 (downstream build)

I am not sure I understand what produced the json.
Is this a RHEVM 4.2.0, i.e. an ovirt-engine rpm? d/s ovirt-engine still does not contains the ipvX_dhcp notation (it is in u/s since yesterday only). also AFAIK, ovirt-engine has never put a 'meta' part in the json, nor a uuid.
Comment 22 Vladimir 2017-12-28 16:27:39 UTC 
Is there downstream build with this ipvX_dhcp notation support?

Meanwhile I tried this with cloud_init 0.7.9-20 on local VM and still had no success

Here is the network_data:
[root@localhost ~]# cat /mnt/latest/network_data.json 
{
  "links" : [ {
    "name" : "eth1",
    "id" : "eth1",
    "type" : "vif"
  } ],
  "services" : [ {
    "address" : "88.8.8.8",
    "type" : "dns-nameserver"
  }, {
    "address" : "search.foo.bar",
    "type" : "dns-search"
  } ],
  "networks" : [ {
    "netmask" : "255.255.255.0",
    "link" : "eth1",
    "id" : "eth1",
    "ip_address" : "10.0.0.1",
    "type" : "ipv4",
    "gateway" : "10.0.0.254"
  }, {
    "link" : "eth1",
    "id" : "eth1",
    "type" : "ipv6_dhcp"
  } ]
}

And here is the resulting ifcfg:
[root@localhost ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1 
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=dhcp
DEFROUTE=yes
DEVICE=eth1
GATEWAY=10.0.0.254
IPADDR=10.0.0.1
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
Comment 23 Ryan McCabe 2018-01-01 18:20:06 UTC 
Are you sure you're using the -20 build, and that it's provided the input you pasted above? If I test it, I get:

# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth1
DHCPV6C=yes
GATEWAY=10.0.0.254
IPADDR=10.0.0.1
IPV6INIT=yes
IPV6_AUTOCONF=no
NETMASK=255.255.255.0
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
Comment 24 eraviv 2018-01-09 06:55:06 UTC 
hi Ryan,
When do you expect this fix to be available downstream?

Thanks
Comment 25 Ryan McCabe 2018-01-09 15:20:15 UTC 
This should be in the -20 build. Is it not working for you?
Comment 26 eraviv 2018-01-10 05:43:59 UTC 
Our QE wants to know if this is incorporated downstream already so they can test downstream.
Comment 27 Ryan McCabe 2018-01-10 18:18:51 UTC 
The package with the fix has not been officially released yet, if that's what you're asking. It will be released with RHEL 7.5, unless somebody requests a z-stream for this issue.

Am I understanding the question correctly?
Comment 28 Vladimir 2018-01-22 12:44:02 UTC 
Verified on RHEVM 4.2.1.1-0.1.el7 with cloud-init-0.7.9-22.el7
User all possible configurations of IPv4 + IPv6 on the same interface + general verification
Comment 34 meital avital 2018-02-13 12:33:53 UTC 
moving to verified according to comment 28
Comment 40 errata-xmlrpc 2018-04-10 14:08:06 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0806
Comment 41 Vladimir 2018-05-16 10:32:15 UTC 
Which build and what exactly should we test?
Comment 42 Ryan McCabe 2018-05-16 19:20:20 UTC 
The current RHEL 7.5 build would be best to test, IMO. It is https://brewweb.engineering.redhat.com/brew/buildinfo?buildID=653899
Comment 43 Vladimir 2018-05-18 10:16:36 UTC 
I've run our scenarios against this build, all tests passed
Note You need to log in before you can comment on or make changes to this bug.