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 633984 - Problems with IP alias / multiple IP on interface handling
Summary: Problems with IP alias / multiple IP on interface handling
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: initscripts Maintenance Team
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-14 20:13 UTC by Steve Bonneville
Modified: 2018-11-14 15:44 UTC (History)
9 users (show)

Fixed In Version: initscripts-9.03.18-1.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-19 13:51:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Add support for multiple IPs via IPADDRn/PREFIXn (5.30 KB, patch)
2010-10-25 16:51 UTC, Jirka Klimes 		no flags Details | Diff
Add support for multiple IPs via IPADDRn/PREFIXn (5.81 KB, patch)
2010-12-01 02:49 UTC, Bill Nottingham 		no flags Details | Diff
starrting IPADDRn variable adjustment (553 bytes, patch)
2010-12-01 16:05 UTC, Jirka Klimes 		no flags Details | Diff
adjust indexes for IPADDR<n> (571 bytes, patch)
2011-04-12 14:52 UTC, Jirka Klimes 		no flags Details | Diff
Show Obsolete (2) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0647 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2011-05-19 09:37:27 UTC

Description Steve Bonneville 2010-09-14 20:13:54 UTC 
Description of problem:

NetworkManager and IP aliases / multiple IP addresses play awkwardly together.

When using NetworkManager to configure multiple IPv4 addresses through the desktop GUI, the new syntax works and everything works fine, as long as the
NetworkManager service is running.  This puts modern entries with the 
syntax IPADDR=/PREFIX= , IPADDR2=/PREFIX2=, etc. in the ifcfg-eth0 file.
The problems start if people try to not use NetworkManager or try to use old configuration files.

If you then turn off NetworkManager and try to use traditional networking
scripts only, then ifup will only bring up IPADDR/PREFIX, it'll ignore the
IPADDR2/PREFIX2 IP address entirely.

On the other hand, if you keep using NetworkManager and try to use the old
ifcfg-eth0:0 style syntax, NetworkManager apparently will see both a 
"System eth0" and "System eth0:0" interface.  If you select "System eth0"
you will get IPADDR/PREFIX and IPADDR2/PREFIX2, but you won't get the 
settings in ifcfg-eth0:0.  If you attempt to select the "System eth0:0" interface, it'll kill any IPv4 addresses listed in the "System eth0" file
and you'll only get the IPADDR in ifcfg-eth0:0.

I suppose this is expected behavior, but given the number of folks that "just turn off NetworkManager on servers" I see potential support issues here.  Frankly, if the new IPADDR2/PREFIX2 syntax was supported properly by ifup when NetworkManager was stopped, I'd consider that sufficient to close the bug with the old ifcfg-eth0:0 configuration file format understood as deprecated.


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

NetworkManager-0.8.1-5.el6.x86_64
initscripts-9.03.17-1.el6.x86_64


How reproducible:

In the NetworkManager GUI, edit the "System eth0" connection, and under
"IPv4 Settings" set two IP addresses.  Make sure "Available to all users"
is checked.

Create a file /etc/sysconfig/network-scripts/ifcfg-eth0:0 containing
   DEVICE=eth0:0
   IPADDR=192.0.2.1
   NETMASK=255.255.255.0
   ONPARENT=yes

Activate "System eth0".  Run 'ip a'.  
Run 'service NetworkManager stop; ifdown eth0; ifup eth0'.  Run 'ip a'.
Run 'service NetworkManager start; ifdown eth0; ifup eth0'.  Run 'ip a'.
Comment 2 Jirka Klimes 2010-10-25 16:48:39 UTC 
initscripts (i.e. 'network' service) supports IP aliases via ifcfg-eth0:n files. But it doesn't use the new multiple IP configuration by IPADDRn/PREFIXn.
NetworkManager, on the other hand, uses new configuration (IPADDRn/PREFIXn), but misses legacy alias support.

I agree that initscripts and NetworkManager should behave the same way as they read the same configuration. The missing functionality should be implemented by the both packages.

This bug is about adding new multiple IP configuration for 'network' service. So, I re-assign it to initscripts. See patch proposal in the attachment.

There is an RFE for alias support in NetworkManager - bug 443968.
Comment 3 Jirka Klimes 2010-10-25 16:51:51 UTC 
Created attachment 455579 [details]
Add support for multiple IPs via IPADDRn/PREFIXn
Comment 4 Phil Knirsch 2010-11-24 13:40:33 UTC 
Has this been added to Fedora yet so it can be tested by a broader audience?

Thanks & regards, Phil
Comment 5 Jirka Klimes 2010-11-24 15:27:27 UTC 
(In reply to comment #4)
> Has this been added to Fedora yet so it can be tested by a broader audience?
Not yet, it requires a response/review from initscripts developers/maintainers.

Bill, are you for the patch?
Comment 6 Bill Nottingham 2010-11-30 20:38:50 UTC 
Looks OK in general (and pushed for rawhide.) However, how does NM handle this for IPv6 - does it just write IPV6ADDR_SECONDARIES?
Comment 7 Bill Nottingham 2010-11-30 21:37:41 UTC 
... and the answer to that is yes.
Comment 8 Bill Nottingham 2010-11-30 21:39:55 UTC 
Although, I intend to change it to start at 0, to match the static routes.
Comment 9 Bill Nottingham 2010-11-30 21:43:57 UTC 
And also to not use seq, but to just use a bashism.
Comment 10 Bill Nottingham 2010-12-01 02:49:58 UTC 
Created attachment 463876 [details]
Add support for multiple IPs via IPADDRn/PREFIXn

Here's an updated patch. Changes:

- uses bash rather than seq
- allows for zero-indexed IPADDRn, to match the static-routes format
-- while still not bailing with NM-written configs that start at 2
- uses array variables to attempt to cut down on the number of subshells and evals. Only partially successful, but, well, bash is bash.
Comment 11 Jirka Klimes 2010-12-01 09:44:13 UTC 
Yeah, NM uses IPV6ADDR and IPV6ADDR_SECONDARIES. It has been implemented according to sysconfig.txt description.

Thanks for pushing the change!
Your patch looks good; you are obviously better in bash than me :)

Just to summarize:
Initscripts now accept IPADDR and IPADDRn, where n is 0 .. 255. So max. is 256 IP addresses. The indices have to be contiguous, because parsing ends on the first missing variable. The exception to this is that indices 0 and 1 could be omitted to match the current NM behaviour (IPADDR, IPADDR2, IPADDR3,...)

Valid examples:
IPADDR0, IPADDR1, IPADDRD2, ...
IPADDR1, IPADDR2, IPADDRD3, ...
IPADDR, IPADDR1, IPADDRD2, ...
IPADDR25, IPADDR26, IPADDRD27, ...
IPADDR, IPADDR2, IPADDRD3, ...

So, I think we should update NM to allow IPADDR0 and IPADDR1 as well to be consistent.
Comment 12 Jirka Klimes 2010-12-01 16:00:22 UTC 
Obviously "IPADDR25, IPADDR26, IPADDRD27" is not valid example. The address sequence can start just with IPADDR, IPADDR0 and IPADDR1.

I've included patch for NM's ifcfg-rh plugin to match the new initscripts handling. (bug 658907)
So the workaround not to bail when IPADDR0 and IPADDR1 are missing can be removed.
Comment 13 Jirka Klimes 2010-12-01 16:05:08 UTC 
Created attachment 464038 [details]
starrting IPADDRn variable adjustment

Don't allow IPADDR, IPADDR2,...
Comment 14 Bill Nottingham 2010-12-01 20:15:06 UTC 
My concern is existing NM configs now are in the wild that start 2-indexed, so I'd prefer not to break them.
Comment 17 Bill Nottingham 2010-12-06 20:06:26 UTC 
Also requires upstream commit 03927a3bd0a274baacfd79e5bd0747ed877f9988.
Comment 20 Jirka Klimes 2011-04-12 14:52:16 UTC 
Created attachment 491505 [details]
adjust indexes for IPADDR<n>

Small adjustment to indexes. We should bail if IPADDR2 is missing, i.e. IPADDR, IPADDR2, ... is correct. IPADDR, IPADDR3, ... should fail.
Comment 21 Bill Nottingham 2011-04-12 15:05:00 UTC 
Jirka - I think it's too late for 6.1 for that, in which case we should probably just let it go. I've added it to rawhide/F14.
Comment 22 Jirka Klimes 2011-04-13 06:33:09 UTC 
(In reply to comment #21)
> Jirka - I think it's too late for 6.1 for that, in which case we should
> probably just let it go.
Yeah, no problem. I just put it in this bug, because I didn't want to open new.

> I've added it to rawhide/F14.
Thanks.
Comment 23 errata-xmlrpc 2011-05-19 13:51:23 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0647.html
Note You need to log in before you can comment on or make changes to this bug.