route files are not written on SUSE distros

Bug #1812117 reported by Robert Schweikert on 2019-01-16
This bug affects 2 people
Affects Status Importance Assigned to Milestone

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 should produce 3 ifroute-* files



default fe80::10:80:124:81

Related branches

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
       # - - lo - - eth0
       default - eth0 - eth1 - eth1

       # --- IPv4 routes in deprecared netmask notation:
       # Destination [Dummy/Gateway] Netmask Interface
       # lo eth0
       default eth0 eth1 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

Robert Schweikert (rjschwei) wrote :
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': '', 'routes': [{'netmask': '', 'network': '', 'gateway': ''}], 'address': '', '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': ''}]}

We need to generate ifcfg-eth1 that contains:


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 _render_subnets() does so on a per interface basis and thus there is no knowledge of the network topology.

Robert Schweikert (rjschwei) wrote :

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

This bug is fixed with commit 3acaacc9 to cloud-init on branch master.
To view that commit see the following URL:

Changed in cloud-init:
status: New → Fix Committed

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
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
            - to:

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.

But no default route is present

$ ip route dev eth0 proto kernel scope link src

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.

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.


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
    - type: physical
      name: eth0
        - type: static
    - type: route

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers