route files are not written on SUSE distros

Bug #1812117 reported by Robert Schweikert
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
cloud-init
Fix Released
Undecided
Unassigned

Bug Description

On SUSE distros the routes need to be written to ifroute-* files.

At present the sysconfig renderer does not write the default routes to ifroute-* files, rather the default rout information is set in ifcfg-*. However the values DEFROUTE=yes and IPV6_DEFAULTGW have no meaning in SUSE ifcfg-* files and are ignored. The routes for an interface are loaded from the ifroute-* file.

The file content is expected to be in the format

Destination Gateway Netmask Interface Options

The following config shown at https://pastebin.ubuntu.com/p/jjMKVTSK9v/ should produce 3 ifroute-* files

ifroute-eth1
default 10.80.124.81

ifroute-eth2
default 192.168.1.254

ifroute-eth3
default fe80::10:80:124:81

Related branches

Revision history for this message
Robert Schweikert (rjschwei) wrote :

Examples from the man page

       An example with common network interfaces and some static routes:

       # --- IPv4 routes in CIDR prefix notation:
       # Destination [Gateway] - Interface
       #
       127.0.0.0/8 - - lo
       204.127.235.0/24 - - eth0
       default 204.127.235.41 - eth0
       207.68.156.51/32 207.68.145.45 - eth1
       192.168.0.0/16 207.68.156.51 - eth1

       # --- IPv4 routes in deprecared netmask notation:
       # Destination [Dummy/Gateway] Netmask Interface
       #
       127.0.0.0 0.0.0.0 255.255.255.0 lo
       204.127.235.0 0.0.0.0 255.255.255.0 eth0
       default 204.127.235.41 0.0.0.0 eth0
       207.68.156.51 207.68.145.45 255.255.255.255 eth1
       192.168.0.0 207.68.156.51 255.255.0.0 eth1

       # --- IPv6 routes are always using CIDR notation:
       # Destination [Gateway] - Interface
       #
       2001:DB8:100::/64 - - eth0
       2001:DB8:100::/32 fe80::216:3eff:fe6d:c042 - eth0

Revision history for this message
Robert Schweikert (rjschwei) wrote :
Revision history for this message
Robert Schweikert (rjschwei) wrote :
Revision history for this message
Robert Schweikert (rjschwei) wrote :

And some more fun. We have to know the routes for all the interfaces. For example with the following configuration:

 {'version': 1, 'config': [{'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'static', 'netmask': '255.255.240.0', 'routes': [{'netmask': '0.0.0.0', 'network': '0.0.0.0', 'gateway': '51.68.80.1'}], 'address': '51.68.89.122', 'ipv4': True}], 'mac_address': 'fa:16:3e:25:b4:59', 'name': 'eth0'}, {'type': 'physical', 'mtu': 9000, 'subnets': [{'type': 'dhcp4'}], 'mac_address': 'fa:16:3e:b1:ca:29', 'name': 'eth1'}, {'type': 'nameserver', 'address': '213.186.33.99'}]}

We need to generate ifcfg-eth1 that contains:

DHCLIENT_SET_DEFAULT_ROUTE=no

in order to avoid the dhcpclient to set the default route based on the information received from the dhcp server on eth1.

I have a test case for this already. But I haven't figure out how to make it work as in sysconfig.py _render_subnets() does so on a per interface basis and thus there is no knowledge of the network topology.

Revision history for this message
Robert Schweikert (rjschwei) wrote :

https://code.launchpad.net/~rjschwei/cloud-init/+git/cloud-init/+merge/362020

Addresses the issue with setting DHCLIENT_SET_DEFAULT_ROUTE=no for networks where a default route is configured.

Revision history for this message
Server Team CI bot (server-team-bot) wrote :

This bug is fixed with commit 3acaacc9 to cloud-init on branch master.
To view that commit see the following URL:
https://git.launchpad.net/cloud-init/commit/?id=3acaacc9

Changed in cloud-init:
status: New → Fix Committed
Revision history for this message
Chad Smith (chad.smith) wrote : Fixed in cloud-init version 19.1.

This bug is believed to be fixed in cloud-init in version 19.1. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
Ali Haider (alihaider97) wrote :

Hello, I just tested this with Sles 15 SP2 with cloud-init 19.4 and still do not see the generation of route files in /etc/sysconfig/network.

I'm using a very simple network.cfg file

version: 2
ethernets:
    eth0:
        addresses:
            - 10.20.112.221/22
        gateway4: 10.20.115.254
        routes:
            - to: 0.0.0.0/0
              via: 10.20.115.254

and am able to generate the first part:

cat /etc/sysconfig/network/ifcfg-eth0
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=static
IPADDR=10.20.112.221
NETMASK=255.255.252.0
STARTMODE=auto

But no default route is present

$ ip route
10.20.112.0/22 dev eth0 proto kernel scope link src 10.20.112.221

I don't believe that there are any errors with the network.cfg file itself, as I have tested it on the latest RHEL and Ubuntu distributions without any errors thus far.

I've attached the cloud-init.log file, but don't see any errors that indicate any explicit failures.

Revision history for this message
Robert Schweikert (rjschwei) wrote :

A couple of things, form the documentation:

"Cloud-init’s support for Version 2 network config is a subset of the version 2 format defined for the netplan tool."

SUSE distros do not use netplan, so you need version 1 network configuration. Secondly the code to write route files currently only exists in a patch [1] and there's not been a push to get that upstream that I was involved in.

[1] https://build.opensuse.org/package/view_file/Cloud:Tools/cloud-init/cloud-init-write-routes.patch?expand=1

Revision history for this message
Ali Haider (alihaider97) wrote :

Much obliged, translating the above configuration into the following version 1 equivalent worked immediately.

Here it is for reference:
version: 1
config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: 10.20.112.221/22
          gateway: 10.20.115.254
    - type: route
      destination: 0.0.0.0/0
      gateway: 10.20.115.254

Thank you for your assistance on this matter, I was under the presumption from the above comment that it had been picked up in upstream 19.1 and greater.

Revision history for this message
James Falcon (falcojr) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.