Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1577487

Summary: Default route for VLAN devices is not possible to set via NetworkManager.
Product: Red Hat Enterprise Linux 7 Reporter: Sergei <sergei.popenko>
Component: NetworkManagerAssignee: sushil kulkarni <sukulkar>
Status: CLOSED NOTABUG QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: medium    
Version: 7.4CC: atragler, bgalvani, fgiudici, lrintel, rkhan, sergei.popenko, sukulkar, thaller
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-08-20 13:20:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
journalctl command output none

Description Sergei 2018-05-12 11:29:02 UTC
Description of problem:

NAME             UUID                                  TYPE      DEVICE
team0            b5168cb1-de20-4618-b1a1-f58cf0cec68c  team      team0
team0-enp12s0f0  a171f6fb-9442-4f87-9976-da1ab3bee8bc  ethernet  enp12s0f0
team0-enp12s0f1  82f519eb-ccd5-4a96-a0b9-346afff4ae99  ethernet  enp12s0f1
team0.3891       b18a7bbb-69ca-4e31-990b-742dcddce4b1  vlan      team0.3891
team0.756        aa590f22-2705-4ebe-a1a9-04eb83036fd0  vlan      team0.756


When defining a VLAN connection team0.756 the ipv4.gateway is not beeing set.

ipv4.method:                            manual
ipv4.dns:                               213.153.104.21,213.153.104.22
ipv4.dns-search:                        --
ipv4.dns-options:                       ""
ipv4.dns-priority:                      0
ipv4.addresses:                         172.16.33.80/27
ipv4.gateway:                           --
ipv4.routes:                            --
ipv4.route-metric:                      -1
ipv4.route-table:                       0 (unspec)
ipv4.ignore-auto-routes:                no
ipv4.ignore-auto-dns:                   no
...
IP4.ADDRESS[1]:                         172.16.33.80/27
IP4.GATEWAY:                            172.16.33.65
IP4.ROUTE[1]:                           dst = 172.16.33.64/27, nh = 0.0.0.0, mt = 402
IP4.ROUTE[2]:                           dst = 0.0.0.0/0, nh = 172.16.33.65, mt = 0


Version-Release number of selected component (if applicable):
NetworkManager-1.10.2-13.el7.x86_64
NetworkManager-ppp-1.10.2-13.el7.x86_64
NetworkManager-team-1.10.2-13.el7.x86_64
NetworkManager-libnm-1.10.2-13.el7.x86_64
NetworkManager-tui-1.10.2-13.el7.x86_64
NetworkManager-config-server-1.10.2-13.el7.noarch


How reproducible:


Steps to Reproduce:
1. nmcli com mod team0.756 ipv4.gateway 172.16.33.65 ipv4.never-default no
or
2. nmcli con edit team0.756
> goto ipv4
> set ipv4.gateway 172.16.33.65 
> save persistent
3. nmcli con down team0.756 && nmcli con up team0.756




Actual results:
The default route is not set.

Expected results:
The default route is set.

Additional info:
Nevereless "ip route add default via 172.16.33.65 dev team0.756" is setting the default route.
Tried also to do it via nmtui and/or directly via editing /etc/sysconfig/network--scripts/ifcfg-team0.756.
Didn't help.

Comment 2 Beniamino Galvani 2018-05-12 12:05:56 UTC
Please paste the output of:

 nmcli --version
 nmcli con
 nmcli general logging level TRACE
 nmcli con mod team0.756 ipv4.gateway 172.16.33.65 ipv4.never-default no
 nmcli con down team0.756
 nmcli con up team0.756
 nmcli dev
 ip a
 ip r
 journalctl -u NetworkManager --since="1 minute ago" > log.txt

and attach the log.txt file. Thanks.

Comment 3 Sergei 2018-05-12 12:30:02 UTC
(In reply to Beniamino Galvani from comment #2)
> Please paste the output of:
> 
>  nmcli --version
>  nmcli con
>  nmcli general logging level TRACE
>  nmcli con mod team0.756 ipv4.gateway 172.16.33.65 ipv4.never-default no
>  nmcli con down team0.756
>  nmcli con up team0.756
>  nmcli dev
>  ip a
>  ip r
>  journalctl -u NetworkManager --since="1 minute ago" > log.txt
> 
> and attach the log.txt file. Thanks.

Unfortunately it cannot be done anymore.
The server is in production now. We had only a couple of hours for downtime.
I've set default route by "ip route add" command.

Next opportunity for restarting of team0.756 connection will be the 14th of Juny when we will update the server to RHEL 7.5.

Comment 4 sushil kulkarni 2018-07-17 14:20:32 UTC
Hi Sergei,

Please let us know when you have the logs..

-Sushil

Comment 5 Sergei 2018-08-06 12:50:21 UTC
Created attachment 1473598 [details]
journalctl command output

Comment 6 Beniamino Galvani 2018-08-06 13:03:53 UTC
  <warn>  [1528382655.9660] ifcfg-rh: GATEWAY will be ignored when DEFROUTE is disabled

The connection has ipv4.never-default=yes, which prevents the creation of a default route. Change it to 'no':

 nmcli connection modify team0.764 ipv4.never-default no
 nmcli connection up team0.764

Comment 7 Beniamino Galvani 2018-08-06 13:14:10 UTC
(In reply to Beniamino Galvani from comment #6)
>   <warn>  [1528382655.9660] ifcfg-rh: GATEWAY will be ignored when DEFROUTE
> is disabled
> 
> The connection has ipv4.never-default=yes, which prevents the creation of a
> default route. Change it to 'no':
> 
>  nmcli connection modify team0.764 ipv4.never-default no
>  nmcli connection up team0.764

Re-reading the comments above, I suppose this is what you already it. The log indicates the connection has ipv4.never-default=yes, which contradicts with commands from comment 2.

Comment 8 Sergei 2018-08-06 13:24:07 UTC
(In reply to Beniamino Galvani from comment #7)
> (In reply to Beniamino Galvani from comment #6)
> >   <warn>  [1528382655.9660] ifcfg-rh: GATEWAY will be ignored when DEFROUTE
> > is disabled
> > 
> > The connection has ipv4.never-default=yes, which prevents the creation of a
> > default route. Change it to 'no':
> > 
> >  nmcli connection modify team0.764 ipv4.never-default no
> >  nmcli connection up team0.764
> 
> Re-reading the comments above, I suppose this is what you already it. The
> log indicates the connection has ipv4.never-default=yes, which contradicts
> with commands from comment 2.

This is what this bug about.
It doesn't complain when I run the command 
nmcli connection modify team0.764 ipv4.never-default no

but it doesn't change anything and when I start the Connection it sets back ipv4.never-default back to yes.

Comment 9 Beniamino Galvani 2018-08-06 13:56:06 UTC
Can you please also attach your /etc/sysconfig/network-scripts/ifcfg-team0.764 and /etc/sysconfig/network files?

Comment 10 Sergei 2018-08-07 07:33:32 UTC
(In reply to Beniamino Galvani from comment #9)
> Can you please also attach your
> /etc/sysconfig/network-scripts/ifcfg-team0.764 and /etc/sysconfig/network
> files?

here we go.
I can see the error now.
The server has been reconfigured from bond to team.
Strange that Network Manager didn't fix it during the reconfiguration.

cat /etc/sysconfig/network
NETWORKING=yes
NOZEROCONF=yes
GATEWAY=172.16.36.1
GATEWAYDEV=bond0.764

cat /etc/sysconfig/network-scripts/
VLAN=yes
TYPE=Vlan
DEVICE=team0.764
PHYSDEV=team0
VLAN_ID=764
REORDER_HDR=yes
GVRP=no
MVRP=no
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=team0.764
UUID=d020cf70-bb79-4784-ac02-7b14fd526b15
DEVICE=team0.764
ONBOOT=yes
IPADDR=172.16.36.8
PREFIX=26
DNS1=213.153.104.21
DNS2=213.153.104.22
GATEWAY=172.16.36.1

Comment 11 Sergei 2018-08-07 07:44:46 UTC
Hi Beniamino!
I've now emptied the /etc/sysconfig/network file and run

nmcli connection modify team0.764 ipv4.never-default no ipv4.gateway 172.16.36.1
nmcli con up team.764

And it worked to set the default gateway.
Sorry for this missconfiguration.

Comment 12 Beniamino Galvani 2018-08-20 13:20:57 UTC
(In reply to Sergei from comment #11)
> Hi Beniamino!
> I've now emptied the /etc/sysconfig/network file and run
> 
> nmcli connection modify team0.764 ipv4.never-default no ipv4.gateway
> 172.16.36.1
> nmcli con up team.764
> 
> And it worked to set the default gateway.

Yes, the /etc/sysconfig/network file can interact in bad ways with the profile-based approach of NM. Unfortunately there is no easy way to improve this without breaking backwards compatibility, and thus we can only require that users know what they are doing if they decide to use the global network configuration file.

For these reason, I'm going to close this as NOTABUG.