Bug 1467332 - [RFE][Default Route] [IPv6] - Allow and enable default route network with only ipv6 boot protocol
Summary: [RFE][Default Route] [IPv6] - Allow and enable default route network with onl...
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.2.0
Hardware: x86_64
OS: Linux
Target Milestone: ovirt-4.3.1
: ---
Assignee: eraviv
QA Contact: Michael Burman
: 1571869 (view as bug list)
Depends On:
Blocks: RHEV_IPv6 1200963 1403675 1607118 1618676
TreeView+ depends on / blocked
Reported: 2017-07-03 12:25 UTC by Michael Burman
Modified: 2019-09-04 11:31 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-
Doc Type: Enhancement
Doc Text:
Feature: Support default route role on IPv6-only networks, but only for IPv6 static interface configuration. Reason: oVirt engine should support IPv6 only networks for its existing capabilities. Result: - You can set the default route role on an IPv6-only network provided it has an IPv6 gateway. - For Red Hat Virtualization Manager (RHVM) to correctly report the sync status of the interfaces, configure all of the interfaces with static IPv6 addresses only. Also, configure the IPv6 gateway on the logical network that has the default route role. - IPv6 dynamic configuration is currently not supported. - The IPv6 gateway on the default route role network is applied as the default route for the v6 routing table on the host. - You can set an IPv6 gateway on a non-management network. This was previously possible only on the management network). - If more that one IPv6 gateway is set on the interfaces of a host, the Manager will be in an undefined state: There will be more than one default route entry in the v6 routing table on the host, which causes the host to report that there are no v6 gateways at all (meaning that the interfaces will appear as out of sync in the Manager.)
Clone Of:
Last Closed: 2019-03-01 10:17:50 UTC
oVirt Team: Network
rule-engine: ovirt-4.3?
rule-engine: planning_ack?
rule-engine: devel_ack+
mburman: testing_ack+

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
oVirt gerrit 96753 0 master MERGED webadmin: expose ipv6 gateway on non-mgmt networks 2021-01-08 11:43:53 UTC
oVirt gerrit 96961 0 master MERGED engine: setup single ipv6 gateway for default route role 2021-01-08 11:43:53 UTC
oVirt gerrit 97184 0 master MERGED core: allow default route role on ipv6 only networks 2021-01-08 11:43:53 UTC
oVirt gerrit 97185 0 master MERGED core: sync default route role on both ipv4 and ipv6 2021-01-08 11:43:53 UTC
oVirt gerrit 103018 0 master MERGED tests, net, nmstate: Add default route tests to dynamic ip functional tests 2021-01-08 11:43:53 UTC

Description Michael Burman 2017-07-03 12:25:14 UTC
Description of problem:
[Default Route] [IPv6] - Allow and enable default route network with only ipv6 boot protocol.

Engine currently expect we set an ipv4 bootproto as well. Cannot setup Networks with only ipv6 address for default route network role. 

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Dan Kenigsberg 2017-07-04 20:53:52 UTC
Neither Vdsm not Engine control ipv6 routing. This is a low priority rfe.

Comment 2 Yaniv Lavi 2018-09-03 10:34:52 UTC
*** Bug 1571869 has been marked as a duplicate of this bug. ***

Comment 3 Red Hat Bugzilla Rules Engine 2018-10-17 11:55:39 UTC
This request has been proposed for two releases. This is invalid flag usage. The ovirt-future release flag has been cleared. If you wish to change the release flag, you must clear one release flag and then set the other release flag to ?.

Comment 4 Dan Kenigsberg 2018-11-28 15:18:41 UTC
raising severity because this blocks bug 1607118

Comment 5 eraviv 2019-01-17 11:46:29 UTC
The solution to this issue will be as follows:
- prevent setup networks for a 'default route' role network if it has not been
  configured with an ipv4 configuration.
- prevent move the 'default route' role to a network which is attached to a host
  without an ipv4 configuration.'

This is because the default route role in engine is a mirror for the creation of an ipv4
default route on the host. The default route role is not related to ipv6 configuration or

Michael, pls ack this solution. Thanks

Comment 6 Michael Burman 2019-01-17 12:00:08 UTC
Hi Eitan,
This solutions are already exist)

- "Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: net-1, Nic: enp6s0 on host host1 violates that rule."

We have such validation for a long time now. All roles must be set with bootproto, without it you can't attach the network to a host nor update an attached network with such role, if bootproto wasn't set

Comment 7 Michael Burman 2019-01-17 12:02:31 UTC
Also, how could it be that you added a fixed in version, if the bug is on post state? it's couldn't be)
We already got the build. so this is not correct, please remove.

Comment 8 eraviv 2019-01-17 12:19:33 UTC
This solution exists in the following manner:
if the network is has any role then it should have either ipv4 or ipv6 configuration.

But in the case of only ipv6 configuration on a default route network it causes an out-of-sync on the attachment because in engine the attachment 'has default route' while on the host nic it does not have, because without ipv4 configuration vdsm does not make the nic a default route. so this fix will create a special validation for the default route role - that it must specifically have an ipv4 configuration and not just 'any configuration'. the old validation for the other roles will stay the same.

Comment 9 Michael Burman 2019-01-17 12:30:04 UTC
So you say that, in case of default route role, we will now validate that network has a IPv4 bootproto specifically, so my questions are:

1. Do this gonna cover both flows?
- While attaching the network to a host 
- While network already attached to the host and you set it with default route role

2. Will the validation error messages gonna change?

3. Will this brake our automation for default route feature tests? do we need to adjust our code because of this fix? 


Comment 10 Michael Burman 2019-01-17 12:30:58 UTC
4. Will this fix the out-of-sync issue on add host?

Comment 11 eraviv 2019-01-17 13:13:45 UTC
1. It will cover both flows.

2. There will be two new validation messages for each flow - each message consistent with the existing messages:

any role error messages (existing):
Cannot setup networks. Role (migration/display/gluster) network '${networkName}' has no boot protocol assigned.
Cannot setup networks. IP address has to be set for the NIC that bears a role network. Network\: ${NetworkName}, Nic\: ${nicName} on host ${hostName} violates that rule.

default role error messages (new):
Cannot setup networks. Network '${networkName}' is assigned the 'Default Route' role but has no IPv4 boot protocol assigned.
Cannot setup networks. IPv4 address has to be set for the NIC that bears a 'Default Route' role network. Network\: ${NetworkName}, Nic\: ${nicName} on host ${hostName} violates that rule.

3. Depends on what you test in the automation. If you test existence of an error - there will still be an error. If you test message content - then it will break.

4. No, we have to think some more about this scenario. it is problematic, because if on ovirt-mgmt exists, it automatically receives all roles, but if it has only ipv6 then it will become out-of-sync immediately. any ideas?

Comment 12 eraviv 2019-01-17 13:18:22 UTC
I think point (4) is part of BZ 1403675

Comment 14 Dan Kenigsberg 2019-01-20 09:12:27 UTC
currently default_route role means "set defaultRoute=True".

imho we should modify the meaning to:
- if there is an ipv4 address, set defaultRoute=True
- if there is an ipv6 address, set ipv6gateway=whatever-is-defined-on-engine

Comment 15 eraviv 2019-01-20 09:27:27 UTC
Following an off-line discussion we will go with a different solution:

The Default Route Role (DRR) will be used for both v4 and v6 families:
- On completion of 'add host' ovirtmgmt will be out-of-sync only if the host did not report a gateway at all for it (neither v4 nor v6)
- On setup networks - if a network is DRR it will not be possible to configure it without at least one static gateway or at least one dynamic family addressing.
- On set DRR in the cluster - it will not be possible to set a network as DRR unless it has at least one reported or one configured gateway on either v4 or v6. 
- Of all statically configured v6 gateways a user sets, only the one on which the current DRR is set will be passed to the host.
  corollary: if there is a statically configured v6 gateway on a non-DRR network - no gateway will be reported by getCaps for the interface but the network will nevertheless be in-sync.

Comment 16 eraviv 2019-01-20 15:39:50 UTC
Dan's suggested modification "if there is an ipv4 address, set defaultRoute=True" causes the following behaviour:

For example, if host has ipv4 configured with dhcp before adding it to engine:
1. on 'add host' setup networks does not find an ipv4 gateway in engine configuration of ovirtmgmt and there is no such gateway in the host ifcfg, so engine sends defaultRoute=false
2. vdsm sets defaultRoute=false on ifcfg and reports the same back to engine. 

==> out of sync on ipv4 because ovirtmgmt is configured as the defaultRoute network
==> user has to change the ipv4 configuration on the attachment to static and run setup networks again for the network to be in sync

Dan, am I missing sth?

Comment 17 eraviv 2019-01-22 08:02:09 UTC
Dan's suggestion from above is implemented in the solution as follows:

The meaning of the default route role changes. 
It now signifies a network which provides either v4 or v6 default routes on a host.

According to this meaning the configuration of a  NIC on the host is in sync with the default route role if it is configured in either of the following manners:
- with both a v4 gateway and a DEFROUTE=true flag (aka ipv4defaultRoute in vdsm speak).
- with a v6 gateway.

Engine will consider the network attachment in sync with the host NIC if and only if the network is designated as the default route role in engine and the NIC has one of the corresponding configurations as described above.

Comment 18 Sandro Bonazzola 2019-01-28 09:34:30 UTC
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 19 Michael Burman 2019-02-11 11:54:07 UTC
Eitan , please move to MODIFIED if all relevant patches were merged. Thanks,

Comment 20 Michael Burman 2019-02-26 09:09:58 UTC
Notes for this RFE - 

1. When the default route role is moved away from a network, its ipv6 gateway is automatically removed from the interface.
2. In the main 'Alerts' notification drawer, an alert notification will alert that "On cluster golden_env_mixed_1 the 'Default Route Role' network is no longer network ovirtmgmt. The IPv6 gateway is being removed from this network."
3. After moving the default route role to a new network the user should set a static ipv6 gateway on this network - The network will be shown as out-of-sync(because of the default route property - the tooltip should be addressed and improved in future in BZ 1670341)
4. If the host and engine are not on the same SUBNET, engine will loose connectivity with the host on moving the default route role between networks. This is due to result (1). The user should take precautions to avoid this situation. 

Verified on - and vdsm-4.30.9-1.el7ev.x86_64

Comment 21 Sandro Bonazzola 2019-03-01 10:17:50 UTC
This bugzilla is included in oVirt 4.3.1 release, published on February 28th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.1 release, it has been closed with a resolution of CURRENT RELEASE.

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

Note You need to log in before you can comment on or make changes to this bug.