Bug 1413241

Summary: Adding alias on loopback interface not enable during boot
Product: [Fedora] Fedora Reporter: Davide Lima "Duarte" Daum <infinity.sbn>
Component: NetworkManagerAssignee: Lubomir Rintel <lkundrak>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 27CC: bgalvani, dcbw, fgiudici, gunnar, infinity.sbn, jonathan, lkundrak, lnykryn, thaller, vladimir-csp, zbyszek
Target Milestone: ---   
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-11-30 23:36:18 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:

Description Davide Lima "Duarte" Daum 2017-01-14 03:10:46 UTC
Description of problem:
Moving from a server with fedora 21 to a fedora 25 the configuration 
about the alias on the loopback stopped to enable the alias interface 
on the boot.

on the previous server(fedora 21) i have this file in /etc/sysconfig/network-script/ifcfg-lo:1 with this content:

DEVICE=lo:1
IPADDR=192.168.123.128
NETMASK=255.255.255.255
NETWORK=192.168.123.128
ONBOOT=yes
NAME=loopback-proxy
IPV6INIT=yes
IPV6_AUTOCONF=no
IPV6ADDR=fc05:def2::128/128

and after a boot here the output of the ip addr  show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet 192.168.123.128/32 brd 192.168.123.128 scope global lo:1
       valid_lft forever preferred_lft forever
    inet 192.168.123.129/32 brd 192.168.123.129 scope global lo:2
       valid_lft forever preferred_lft forever
    inet6 fc05:def2::129/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 fc05:def2::128/128 scope global 
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever


The same file on the new server(fedora 25) it doesn't work, after the boot no alias on loopback.


Version-Release number of selected component (if applicable):
NetworkManager (version 1.4.2-2.fc25)

How reproducible:


Steps to Reproduce:
1. Create a valid configuration file /etc/sysconfig/network-script/ifcfg-lo:1 
2. Reboot the server

Actual results:
No alias on the loopback interface after reboot

Expected results:
Configured alias on the loopback interface

Additional info:
The alias interface work perfect with the command ifup/ifdown

Comment 1 Beniamino Galvani 2017-01-16 10:38:49 UTC
AFAIK, NetworkManager has never managed the loopback interface. I think iniscripts are involved in this.

Comment 2 Davide Lima "Duarte" Daum 2017-01-16 10:46:42 UTC
Are You sure ? The only log i can find about the loopback are those from journactl:

Jan 14 02:35:39 central46 NetworkManager[406]: <info>  [1484361339.0752] device (lo): link connected
Jan 14 02:35:39 central46 NetworkManager[406]: <info>  [1484361339.0784] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/0)

Nothing else tell me that the loopback is up except for the Network Manager...

Comment 3 Beniamino Galvani 2017-01-16 10:54:18 UTC
(In reply to Davide Lima "Duarte" Daum from comment #2)
> Are You sure ? The only log i can find about the loopback are those from
> journactl:
> 
> Jan 14 02:35:39 central46 NetworkManager[406]: <info>  [1484361339.0752]
> device (lo): link connected
> Jan 14 02:35:39 central46 NetworkManager[406]: <info>  [1484361339.0784]
> manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/0)
> 
> Nothing else tell me that the loopback is up except for the Network
> Manager...

NM only recognizes that the loopback exists and is up. initscripts configure it:

https://git.fedorahosted.org/cgit/initscripts.git/tree/rc.d/init.d/network#n70

Comment 4 Lukáš Nykrýn 2017-01-16 10:59:11 UTC
If you enable network initscript (disabled by default) it should work. The question is if there is a use-case for this why NM does not handle it.

Comment 5 Davide Lima "Duarte" Daum 2017-01-16 12:00:12 UTC
Ok, enabling the network script now i have the alias working on the loopback.
Just to confirm, if i disable Network Manager isn't a problem right ?
Because to manage the network configuration i prefer only one tool,
and because NM is unable to manage the configuration i have, may i use
only the historical and bullet proof network script ? ;)

Comment 6 Lukáš Nykrýn 2017-01-16 12:13:49 UTC
The network-scripts have drawbacks. There is no hotplug, so all of the devices needs to be present during the boot when the network.service is started. Also there is no support for some wireless connections, *-vlans,...

But if you have an old-fashioned setup you can use just them.

Comment 7 Davide Lima "Duarte" Daum 2017-01-16 12:24:34 UTC
It's a server so no need of wifi. 
For the vlan are You telling me that this doc page isn't right anymore?

https://docs.fedoraproject.org/en-US/Fedora/25/html/Networking_Guide/sec-Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line.html

Comment 8 David Kaspar // Dee'Kej 2017-01-16 12:24:59 UTC
Hello Duarte,

nowadays we prefer people to use NetworkManager where possible. So the question from Lukáš stays:

Why do you need to have aliases on the loopback device? Is there any valid usecase for this, that we can't think of right now? If so, could you please describe that use case?

Without it, it's hard to tell if NetworkManager should support such scenario or not.

Comment 9 Lukáš Nykrýn 2017-01-16 12:49:23 UTC
(In reply to Davide Lima "Duarte" Daum from comment #7)
> It's a server so no need of wifi. 
> For the vlan are You telling me that this doc page isn't right anymore?
> 
> https://docs.fedoraproject.org/en-US/Fedora/25/html/Networking_Guide/sec-
> Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line.html

Plain vlans works just fine, I was mentioning stuff like macvlans.

Comment 10 Davide Lima "Duarte" Daum 2017-01-16 12:50:07 UTC
Example on the use of loopback interface ?

In my case the servers are vpn gateway and every server publish 
some service only on connected on the vpn. 
So because You cannot use the "127.0.0.1" to access the services 
on the server You need to use a network, for example 192.168.200.128/32.
Apache bind on this address and not on 0.0.0.0.
There are a lots of use about an alias in loopback...LVS, or if you want
to bind service on the same port on different local address to avoit
the boring part to put :port like 8080 for a web and so on...

I think that if You want to move on NM all the network configuration,
this tool must give the same configuration option we have from the
old network script...or we will be forced to manage this things 
via rc.local or different messy scripts...

Comment 11 Thomas Haller 2017-01-16 14:18:16 UTC
(1) to have a "lo" interface with 127.0.0.1 you don't need NetworkManager.

(2) having additional IP addresses on "lo" is an uncommon (but useful) scenario.

NM doesn't manage "lo" because (1) works fine without NM and (2) is an uncommon scenario.

But it's really just a missing feature... yes, NM should support this.

Comment 12 Davide Lima "Duarte" Daum 2017-01-17 10:10:11 UTC
Hi Thomas, i don't know what is Your background but in my experience here
in Italy, the use of the loopback isn't so uncommon.
Here we are a lot of debian or ubuntu in production environment and
i never saw that the content of the /etc/network/interface (debian based distros) will be ignored because NM. 

We started to use fedora for the development environment and 
in production because we need some packages to be near the edge.
Maybe a message in the docs that the functionality of the scripts in 
/etc/sysconfig/network-script will be (ignored|modified) by NM, and
that this way to configure will be deprecated in the (near|distant) future,
is a good way to start to implement some solution in different way
to avoid problems like what i encountered with the loopback alias.

Comment 13 Fedora End Of Life 2017-11-16 15:45:22 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 14 vladimir-csp 2017-12-05 08:47:45 UTC
As a system engineer I have seen a lot of cases of lo aliases in use. Primarily it is a way to hand routed or proxied traffic to locally bound daemons and add another point for fine-tuning traffic flows.

"Loopback alias" connection type would be a great feature addition to Network Manager if you wish to expand its use on servers and routers.

Comment 15 Gunnar Guðvarðarson 2018-07-23 21:35:01 UTC
As a network admin and devops i'd like to chime in a bit. Even if this might not be the right place.

With a server where the main network interface is only for outbound connections, we use loopbacks for incoming services. Daemons bind the loopback address for the specific service.

Reasons include but are not limited to:
- ddos protected ip
- anycasted ip
- management ip

note: also affected, Fedora 28.

Comment 16 Ben Cotton 2018-11-27 13:42:22 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 17 Ben Cotton 2018-11-30 23:36:18 UTC
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.