Bug 1679730 - Warn about host IP addresses outside range
Summary: Warn about host IP addresses outside range
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.8-2
Hardware: x86_64
OS: Linux
low
low
Target Milestone: ovirt-4.4.1
: ---
Assignee: eraviv
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-21 18:05 UTC by Javier Coscia
Modified: 2020-08-04 13:19 UTC (History)
7 users (show)

Fixed In Version: ovirt-engine-4.4.1.2
Doc Type: Enhancement
Doc Text:
This update adds an audit log warning on an out-of-range IPv4 gateway static configuration for a host NIC. The validity of the gateway is assessed compared to the configured IP address and netmask. This gives users better feedback and helps them notice incorrect configurations.
Clone Of:
Environment:
Last Closed: 2020-08-04 13:16:55 UTC
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3927701 0 Troubleshoot None out-of-sync Network in RHV UI 2019-02-21 18:08:47 UTC
Red Hat Product Errata RHSA-2020:3247 0 None None None 2020-08-04 13:19:06 UTC
oVirt gerrit 108842 0 master MERGED core: compute ipv4 subnet addresses 2021-01-19 17:35:09 UTC
oVirt gerrit 108945 0 master MERGED core: audit IPv4 gateway out of range 2021-01-19 17:35:09 UTC

Description Javier Coscia 2019-02-21 18:05:04 UTC
Description of problem:

Currently, engine does not block nor give a warning message while using 
IP addresses outside the defined netmask/subnet range.

This tries to configure the logical network on host with all the variables 
but will fail to add the information in the DB making the UI to show a 
broken network icon, the Out-of-Sync


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

ovirt-engine-4.1.2.3-0.1.el7.noarch
vdsm-4.20.43-1.el7ev.x86_64

How reproducible:

100%

Steps to Reproduce:
1. Create a new Logical Network
2. Configure the network on hypervisor with a gateway IP address outside 
   the range defined on netmask/subnet. Use a /27 prefix for example.


Actual results:

Engine doesn't alert on this event and place the network in an out of sync 
status because the hypervisor has the gateway address information while 
the DB doesn't

Expected results:

Engine should block or give a message regarding the wrong configuration / 
calculation of addresses outside the range defined by the netmask/subnet 
used


Additional info:

Comment 3 Marina Kalinin 2019-05-18 14:58:14 UTC
Why is this RFE and not a bug?

Comment 4 Javier Coscia 2019-05-20 11:36:21 UTC
Feel free to remove the RFE component and make it a bug

Comment 5 Marina Kalinin 2019-07-16 19:57:03 UTC
Michael

This sounds like a bug to me. Can you please check?

Comment 7 Dominik Holler 2019-08-03 19:43:01 UTC
Laura, do you think it is enough to warn or block on UI, or do you think the warning should be on changes by REST API, too?

Comment 8 Laura Wright 2019-08-05 12:24:27 UTC
If it's a behavior thing I would recommend making changes to the REST API as well as giving the user warning or guidance in the UI. I would recommend adding a form error such as the one featured here: https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and-validation/ We could also include an info tip next to the input field that features the input criteria for IP addresses and an example of one that fits the specified criteria.

Comment 9 Dominik Holler 2019-08-05 15:55:37 UTC
(In reply to Laura Wright from comment #8)
> If it's a behavior thing I would recommend making changes to the REST API as


What kind of change do you recommend to the REST API?
Rejecting the change would be not backward compatible. We could create an entry in the audit log (which might annoy the user).
(I have myself no good idea how to handle this case, this is why I am asking. If we have no good idea here, we could just block in UI as you suggested)

> well as giving the user warning or guidance in the UI. I would recommend
> adding a form error such as the one featured here:
> https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and-
> validation/ We could also include an info tip next to the input field that
> features the input criteria for IP addresses and an example of one that fits
> the specified criteria.

Comment 10 Laura Wright 2019-08-05 18:02:40 UTC
(In reply to Dominik Holler from comment #9)
> (In reply to Laura Wright from comment #8)
> > If it's a behavior thing I would recommend making changes to the REST API as
> 
> 
> What kind of change do you recommend to the REST API?
> Rejecting the change would be not backward compatible. We could create an
> entry in the audit log (which might annoy the user).
> (I have myself no good idea how to handle this case, this is why I am
> asking. If we have no good idea here, we could just block in UI as you
> suggested)
> 
> > well as giving the user warning or guidance in the UI. I would recommend
> > adding a form error such as the one featured here:
> > https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and-
> > validation/ We could also include an info tip next to the input field that
> > features the input criteria for IP addresses and an example of one that fits
> > the specified criteria.

In that case I would just recommend adding an inline error if that's easier.

Comment 11 Dominik Holler 2019-08-05 18:10:59 UTC
(In reply to Laura Wright from comment #10)
> (In reply to Dominik Holler from comment #9)
> > (In reply to Laura Wright from comment #8)
> > > If it's a behavior thing I would recommend making changes to the REST API as
> > 
> > 
> > What kind of change do you recommend to the REST API?
> > Rejecting the change would be not backward compatible. We could create an
> > entry in the audit log (which might annoy the user).
> > (I have myself no good idea how to handle this case, this is why I am
> > asking. If we have no good idea here, we could just block in UI as you
> > suggested)
> > 
> > > well as giving the user warning or guidance in the UI. I would recommend
> > > adding a form error such as the one featured here:
> > > https://www.patternfly.org/v3/pattern-library/forms-and-controls/errors-and-
> > > validation/ We could also include an info tip next to the input field that
> > > features the input criteria for IP addresses and an example of one that fits
> > > the specified criteria.
> 
> In that case I would just recommend adding an inline error if that's easier.

I understand that inline means only web UI. If not, please let me know.
Thanks, Laura.

Comment 12 Laura Wright 2019-08-05 18:15:31 UTC
Yup inline for just web UI works for me. No problem! Thank you for bringing it up!

Comment 14 eraviv 2020-05-05 09:05:32 UTC
Hi Javier,

After considering the most practical solution to the above problem, we suggest to implement a warning\info entry in the events tab in the web-admin (and in engine.log) if the user-configured ipv4 gateway is outside the subnet range. This entry will be submitted when the user invokes set-up networks.

Is this acceptable from your point of view?
Thanks

Comment 15 Javier Coscia 2020-05-05 11:37:12 UTC
Hi Eitan,

IMO the warn/info entry make sense in both UI and engine.log
Thanks!

Comment 16 eraviv 2020-05-06 11:44:09 UTC
Javier,

Do I understand you correctly that an entry in the engine.log and an entry in the events tab in web-admin is an acceptable solution and nothing else is required from your point of view?

Thanks

Comment 17 Javier Coscia 2020-05-06 11:59:36 UTC
Eitan,

Yes, I think it would be good. My understanding is that once the user hits the `ok/save` button, which calls the setup networks, if the subnet is not correct, they will get a warning message.

Comment 22 Michael Burman 2020-06-08 09:56:54 UTC
Verified on - rhvm-4.4.1.2-0.10.el8ev.noarch

We added new audit log in the UI notifications:
"IPv4 gateway 5.4.5.254 is out of the subnet range defined by the IP address and netmask specified on ens4f1 in host <host_fqdn> of cluster Cluster1"
Plus the exist out-of-sync event.

Comment 24 errata-xmlrpc 2020-08-04 13:16:55 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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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/RHSA-2020:3247


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