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
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.

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

Other bug subscribers