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 1634657 - NetworkManager ignores multiple DHCP router options
Summary: NetworkManager ignores multiple DHCP router options
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: beta
: 8.0
Assignee: NetworkManager Development Team
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-10-01 09:44 UTC by Nux
Modified: 2021-01-08 07:37 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-08 07:37:07 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Nux 2018-10-01 09:44:45 UTC 
Description of problem:
Our DHCP server advertises 2 routers.
(verified with nmap --script broadcast-dhcp-discover -e br0)

NetworkManager ignores the 2nd one, only uses the first one.



Version-Release number of selected component (if applicable):
Name        : NetworkManager
Epoch       : 1
Version     : 1.10.2
Release     : 16.el7_5



How reproducible:
always

Steps to Reproduce:
1. dhcp advertise 2 or more routers



Actual results:
NetworkManager only uses the 1st one, ignores the 2nd

Expected results:
Both routers should be set as default, with different metrics

Additional info:

NM_CONTROLLED=no on the interface, ie returning to the olden ways, fixes the issue, I end up with 2 default routes with different metrics.
Comment 2 Thomas Haller 2018-10-01 10:31:27 UTC 
> Both routers should be set as default, with different metrics

which metric should be used for the secondary?

Can you elaborate what for you need the secondary default-route?
Comment 3 Nux 2018-10-01 11:22:00 UTC 
After disabling NM, the legacy network scripts have set the following, which works for me:

~]$ ip route show
default via 10.16.4.101 dev br0 
default via 10.16.4.111 dev br0 metric 1 

The metrics could have been a bit higher, but it's ok. I think NM usually chooses something around 500 for metrics.

Let me know if you require any more information.
Comment 4 Thomas Haller 2018-10-01 14:36:49 UTC 
> Can you elaborate what for you need the secondary default-route?

What is the value of this additional route? As it won't be used to the worse metric.
Comment 5 Nux 2018-10-01 14:43:33 UTC 
Thomas, what do you mean?
I pasted my current default routes.
The secondary route has a metric of 1, see above.
Comment 6 Thomas Haller 2018-10-01 15:05:16 UTC 
(In reply to Nux from comment #5)
> Thomas, what do you mean?
> I pasted my current default routes.
> The secondary route has a metric of 1, see above.

Hi, sorry for being unclear :)

Could you explain why this issue is important to you? Why do you require the secondary route? It has a lower metric and is effectively not used. Why does it matter then?

I just want to understand why exactly this issue bothers you and whether it causes actual problems for you. I do agree, that the request makes sense, but why exactly?

Thanks.
Comment 7 Nux 2018-10-01 15:18:33 UTC 
In my case it's about a HA implementation at work done by the network department.
I had no say in it, don't know why they did it like they did, but it looks like NetworkManager ought to respect the DHCP options.

I know Linux will not actually use the other router without some extra logic, however Windows does, this being a mixed environment.
Comment 8 Thomas Haller 2018-12-19 15:53:17 UTC 
Some related fixes merged to upstream master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=abe22689bd6d76cfe0f12dd2476b7b02929bc696


But it still requires similar changes to dhclient, and it also requires https://github.com/systemd/systemd/pull/11208.
More to come.
Comment 11 Thomas Haller 2019-05-07 14:48:59 UTC 
(In reply to Thomas Haller from comment #8)
> Some related fixes merged to upstream master:
> 
> https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/
> ?id=abe22689bd6d76cfe0f12dd2476b7b02929bc696
> 
> 
> But it still requires similar changes to dhclient, and it also requires
> https://github.com/systemd/systemd/pull/11208.
> More to come.

This pull request got in the meantime merged with related fixes as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=209ff015e26f295bdb7c396962a4e9b4199398fb


Note that dhclient work is still missing.


> I wrote the test, and it seems to run only with 'dhcp=internal' in '[main]' configuration section. With 'dhcp=dhclient' only one default route is added. Since option 'dhcp=dhclient' is default on RHEL7, this does not seem to be fixed for RHEL7 with default configuration.

Right. As comment 8 says, this is not yet fixed for dhclient.

The bug was wrongly moved to MODIFIED (and wrongly added to errata).

I'll drop it from errata again.

Thanks for catching this!!
Comment 14 Thomas Haller 2020-03-23 16:52:34 UTC 
reassign to RHEL-8.

At this point, it's not planned to fix this issue in RHEL-7. It anyway needs first to get fixed and tested in rhel-8. If need be, this bug should be cloned to fix the issue also on rhel-7.

Also, putting this on the RPL-8.3 (priority list). I think there is not much left to do, mostly figuring out what is actually missing.
Comment 19 RHEL Program Management 2021-01-08 07:37:07 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Note You need to log in before you can comment on or make changes to this bug.