GNOME Bugzilla – Bug 702773
[enh] add support for bulk IP addresses
Last modified: 2013-07-31 11:48:46 UTC
Some enterprise-type installs add hundreds of IP addresses to an interface, which is quite cumbersome with our current config support. We should add new array properties to the IP4Config and IP6Config settings that accept a range of addresses, perhaps with signature 'a(suu)' (suu=address start, number of addresses, prefix) or something like that.
For references, the RH-style configuration for this is: ifcfg-<device>-range<number> IPADDR_START=<starting ip> (e.g. 1.2.3.4) IPADDR_END=<ending ip> (e.g. 1.2.3.77) CLONENUM_START=<number of starting alias> (e.g. 0) CLONENUM_START is used as the device label, e.g: ip addr add $ip/$prefx brd $broadcast dev $device label $device:$clonenum+offset
Please note this does not work with IPv6 <https://bugzilla.redhat.com/show_bug.cgi?id=969950> and <https://bugzilla.redhat.com/show_bug.cgi?id=970459>. You have to modify routing table instead of assigning addresses.
(In reply to comment #2) > Please note this does not work with IPv6 What are you referring to now? > <https://bugzilla.redhat.com/show_bug.cgi?id=969950> This bug report is unrelated for the following reasons: 1) It is not about adding bulk addresses but about adding a single address. 2) The sideeffect that adding a single address with prefix length causes the machine to be pingable using other addresses from the same subnet is specific to the *loopback* interface. 3) Loopback interface configuration is not supported by NetworkManager anyway (this may warrant a separate bugreport, though). > <https://bugzilla.redhat.com/show_bug.cgi?id=970459> This bug report is about kernel limits that can't be overcome by NetworkManager unless they are settable at runtime (which I don't know). > You have to modify routing table instead of assigning addresses. This workaround is specific to loopback devices. Therefore it doesn't help us in general. (In reply to comment #1) > ip addr add $ip/$prefx brd $broadcast dev $device label > $device:$clonenum+offset Just please note that the offset number is currently not handled in NetworkManager's configuration nor in the nm-platform framework. For the record, I wrote the following to the Fedora mailing list: AFAIK with the current kernels, the only difference between aliased and non-aliased secondary addresses is Netlink's 'label' attribute. If you want to add an address that would be seen through the alias API, you just need to assign it a label. With libnl3 (used by NetworkManager), this is a matter of computing it and assigning it via rtnl_link_set_label(). Currently we don't do that, as this for us this is unnecessary overhead, and as there is no known demand for it and also because the new-style multiple address API have been available for years.
(In reply to comment #1) > For references, the RH-style configuration for this is: > > ifcfg-<device>-range<number> > IPADDR_START=<starting ip> (e.g. 1.2.3.4) > IPADDR_END=<ending ip> (e.g. 1.2.3.77) +1 First/last address sounds more useful to me than prefixes or numbers of addresses.
Sure, either way works. The issue we have is how we're going to handle alias/label interfaces though. Users are used to seeing them as first-class devices, so they'd each be separate NMDevice objects in NM. But that also means that reading one ifcfg file might create multiple connections (one for each alias) and that's going to be complicated to get right when writing the files back out when things change, because multiple connections could refer to the same ifcfg file. Alternatively, it could all go into one connection, but then we'd have multiple devices using the same NMConnection when active, which is something we're trying to get away from in the future because it has other complications...
Note that clearly this isn't a problem when interface aliases *aren't* used, that's dead simple to do. But we're currently discussing this internally, since it turns out that customers get very confused and many still don't know that you can have multiple addresses on the same interface, plus a ton of web pages have guides for using interface aliases and that's what people find when they google. There's clearly a user-education component, but we may end up having to support aliases too.
(In reply to comment #5) > Sure, either way works. OK. > The issue we have is how we're going to handle > alias/label interfaces though. Users are used to seeing them as first-class > devices, so they'd each be separate NMDevice objects in NM. Sounds like a bad idea and rather large amount of work for no real advantage. Don't open Pandora's box unless you're sure you know what you're doing. Users should just get used to the proper object model. (In reply to comment #6) > Note that clearly this isn't a problem when interface aliases *aren't* used, > that's dead simple to do. I didn't think about anything else than bulk address assignment [optionally with labels to please ifconfig users]. > But we're currently discussing this internally, since it turns out that > customers get very confused and many still don't know that you can have > multiple addresses on the same interface, In this case I strogly lobby for documentation/education as opposed to crippling the configuration model. > plus a ton of web pages have guides > for using interface aliases and that's what people find when they google. > There's clearly a user-education component, but we may end up having to support > aliases too. This is where legacy configuration layers (like ifcfg plugin) are handy. If that is only about ifcfg file layout, I don't oppose keeping it as backwards compatible as possible. But even then it's lots of work and it requires label storage in data structures configuration plugins. I hope you will be able to resist ;).
So interface aliases are actually only *ever* shown as first-class interfaces by ifconfig. The addresses on an alias interface are shown by /sbin/ip as addresses on the master interface, but with a label: $ ip addr show 5: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:23:5a:47:1f:71 brd ff:ff:ff:ff:ff:ff inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth0:0 valid_lft forever preferred_lft forever inet 192.168.0.2/24 scope global secondary eth0:4 valid_lft forever preferred_lft forever inet 192.168.0.4/24 scope global secondary eth0:0 valid_lft forever preferred_lft forever $ ifconfig eth0:0 eth0:0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 inet 192.168.0.3 netmask 255.255.255.0 broadcast 192.168.0.255 ether 00:23:5a:47:1f:71 txqueuelen 1000 (Ethernet) device interrupt 22 memory 0xd4800000-d4820000 The alias interfaces do *not* show up in /sys/class/net nor in /proc/net/dev. Netlink events all come in for the master interface. So they are not first-class interfaces at all, and only ifconfig shows them as such. So I think the right thing to do is to: 1) extend/replace the libnm-util IP4 and IP6 address structs with something extendable 2) add a label attribute to each address 3) populate that label attribute from the ifcfg files or keyfiles or wherever 4) continue to only show the master interface like /sbin/ip does, *not* like ifconfig does 5) ifconfig will continue to work as it always has, and will be oblivious to the fact that NM is running, and it will show the alias addresses as first-class interfaces like shown above
> 1) extend/replace the libnm-util IP4 and IP6 address structs with something > extendable > 2) add a label attribute to each address Fair enough. We can then distinguish labeled and unlabeled addresses. > 3) populate that label attribute from the ifcfg files or keyfiles or wherever Like... [ipv4] address1=1#192.168.1.1/24 → 192.168.1.124 label eth0:1 > 4) continue to only show the master interface like /sbin/ip does, *not* like > ifconfig does +1 > 5) ifconfig will continue to work as it always has, and will be oblivious to > the fact that NM is running, and it will show the alias addresses as > first-class interfaces like shown above +1
(In reply to comment #8) > So I think the right thing to do is to: > > 1) extend/replace the libnm-util IP4 and IP6 address structs with something > extendable > 2) add a label attribute to each address Have we figured out if there are actually good reasons to do the aliases rather than ordinary multiple addresses? Because if it's just a legacy thing, we could simplify this by only supporting sequential aliases like the ifcfg files do, and then we only need to add a single new property, rather than one per address.
The "bulk" thing is independent from the actual alias functionality. You can have eth0:4 and eth0:0 and not have eth0:1 and eth0:2 at all. So there should really be two bugs here: 1) support address labels to allow alias interfaces to be shown in ifconfig 2) support bulk aliases so you don't have to manually add them all the problem is that we don't know what kind of legacy configuration people have, and they may well have :0 and :4 and not 1, 2, or 3. I don't know if we want to paint ourselves into a corner by not supporting that out of the gate? I'm assuming that the bulk aliases thing would be a different property whenever it landed, because it doesn't mesh well with a list of addresses. One issue with the ifcfg-rh stuff though is ONBOOT. That's allowed to be different between the parent ifcfg and the alias ifcfg. If we put all the addresses into the same NMConnection, then we can't support individual ONBOOTs.
(In reply to comment #11) > The "bulk" thing is independent from the actual alias functionality. You can > have eth0:4 and eth0:0 and not have eth0:1 and eth0:2 at all. > > So there should really be two bugs here: > > 1) support address labels to allow alias interfaces to be shown in ifconfig > 2) support bulk aliases so you don't have to manually add them all Agreed. Who's going to clean this up in bugzilla? > the problem is that we don't know what kind of legacy configuration people > have, and they may well have :0 and :4 and not 1, 2, or 3. If they use individual configuration files, they certainly have gaps in numbering as administrators not only add new addresses but also remove ones that are no more in use. > I don't know if we > want to paint ourselves into a corner by not supporting that out of the gate? I would just ignore this request for now and let the enterprise world decide whether they want to push for it stronger. > I'm assuming that the bulk aliases thing would be a different property whenever > it landed, because it doesn't mesh well with a list of addresses. I would ignore aliases for bulk addresses unconditionally for now as it doesn't give any benefits to ifcfg configuration. We can revisit it if there's a strong demand for them, but then we just let the user specify the first one. > One issue with the ifcfg-rh stuff though is ONBOOT. That's allowed to be > different between the parent ifcfg and the alias ifcfg. If we put all the > addresses into the same NMConnection, then we can't support individual ONBOOTs. The easiest way is to just ignore ONBOOT for secondaries. If there's a strong demand of ifup/ifdown support and ONBOOT, it's solvable by treating ONBOOT for secondaries as *ignore* (i.e. such a secondary wouldn't be added to the list) and ifup/ifdown would have to handle the secondary files directly by adding/removing the addresses at runtime. That said, I would try to *avoid* supporting aliases as much as possible, just would be prepared to add an attribute to each IP address to mark the label (or rather the second part of the label).