sysconfig renders vlan with TYPE=Ethernet

Bug #1788915 reported by Dan Cripe
12
This bug affects 3 people
Affects Status Importance Assigned to Milestone
cloud-init
Medium
Eduardo Otubo

Bug Description

Distribution: Fedora 28
Cloud provider: None
Network content of /etc/cloud/cloud.cfg.d/99_datasource.cfg (omitting users, etc.):
network:
  version: 1
  config:
    - type: physical
      name: lan1
      mac_address: 0c:c4:7a:db:dc:b0
    - type: vlan
      name: lan1.100
      vlan_link: lan1
      vlan_id: 100
      subnets:
        - type: static
          address: 192.168.0.2/24
          gateway: 192.168.0.1
          dns_nameservers:
            - 8.8.8.8
            - 8.8.4.4
    - type: vlan
      name: lan1.3900
      vlan_link: lan1
      vlan_id: 3900
      subnets:
        - type: static
          address: 10.1.0.2/16
          gateway:

I am unable to attach logs (no network connection).

$ cloud-init --version
/usr/bin/cloud-init 17.1

The sysconfig renderer leaves the configured "kind" set to the default (ethernet), which results in a config file with "TYPE=Ethernet", which is incorrect and results in the VLAN interface not being created.

$ cat ifcfg-lan1.100
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=lan1.100
GATEWAY=192.168.0.1
IPADDR=192.168.0.2
NETMASK=255.255.255.0
ONBOOT=yes
PHYSDEV=lan1
TYPE=Ethernet
USERCTL=no
VLAN=yes

$ ifup lan1.100
Error: Connection activation failed: No suitable device found for this connection.

Removing the offending "TYPE=Ethernet" line from the config file resolves the problem (as does changing it to "TYPE=Vlan").

I altered my configuration to use version 2 of the network configuration data with identical results (problem is in renderer).

Related branches

Scott Moser (smoser)
Changed in cloud-init:
status: New → Confirmed
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Christian Roessner (christian-roessner-net) wrote :

I also hit this bug. We have late 2020 and I wonder, why this bug still is open?

In current master branch of cloud-init in file:

net/sysconfig.py:

...
687 @classmethod
688 def _render_vlan_interfaces(cls, network_state, iface_contents, flavor):
689 vlan_filter = renderer.filter_by_type('vlan')
690 for iface in network_state.iter_interfaces(vlan_filter):
691 iface_name = iface['name']
692 iface_cfg = iface_contents[iface_name]
693 if flavor == 'suse':
694 vlan_id = iface.get('vlan_id')
695 if vlan_id:
696 iface_cfg['VLAN_ID'] = vlan_id
697 iface_cfg['ETHERDEVICE'] = iface_name[:iface_name.rfind('.')]
698 else:
699 iface_cfg['VLAN'] = True
700 iface_cfg['PHYSDEV'] = iface_name[:iface_name.rfind('.')]

701 iface_cfg.drop('TYPE')

I think, line 701 should be a fix, right?

Tested it and it works for me:

net.json:
------------------------------------------------------------
network:
  version: 1

  config:
    - type: physical
      name: eth0
      subnets:
        - type: static
          address: "109.230.254.227/28"
          gateway: "109.230.254.225"
          dns_nameservers:
            - "109.230.254.226"
        - type: static
          address: "2a05:bec0:28:1:109:230:254:227/64"
          gateway: "fe80::222:8300:b40e:7c0"
          dns_nameservers: []

    - type: vlan
      name: eth0.100
      vlan_link: eth0
      vlan_id: 100
      subnets:
        - type: static
          address: "192.168.0.9/24"
          dns_nameservers: []
------------------------------------------------------------

python3 ./net_convert.py --network-data /root/vm-setup/gitlab.roessner-net.de-network.cfg --kind yaml --output-kind sysconfig -D centos -d target

cat target/etc/sysconfig/network-scripts/ifcfg-eth0.100
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEVICE=eth0.100
IPADDR=192.168.0.9
NETMASK=255.255.255.0
NM_CONTROLLED=no
ONBOOT=yes
PHYSDEV=eth0
USERCTL=no
VLAN=yes

This way, TYPE is removed and all works as expected.

Kind regards

Christian

Revision history for this message
Quique Llorente (quiquell) wrote :

Same here

with version: 2

networkData
        networkData: |
          ethernets:
            eth0:
              addresses:
              - fd10:0:2::2/120
              dhcp4: true
              gateway6: fd10:0:2::1
              nameservers:
                addresses:
                - 10.96.0.10
                search:
                - default.svc.cluster.local
                - svc.cluster.local
                - cluster.local
          version: 2
          vlans:
            eth0.1:
              addresses:
              - 1.0.0.10/24
              - fe80::ce3d:82ff:fe52:24c0/64
              id: 1
              link: eth0
            eth0.2:
              addresses:
              - 1.0.0.11/24
              - fe80::ce3d:82ff:fe52:24c1/64
              id: 2
              link: eth0

ifcfg
BOOTPROTO=none
DEVICE=eth0.1
IPADDR=1.0.0.10
IPADDR6=fe80::ce3d:82ff:fe52:24c0/64
IPV6ADDR=fe80::ce3d:82ff:fe52:24c0/64
IPV6INIT=yes
NETMASK=255.255.255.0
ONBOOT=yes
PHYSDEV=eth0
STARTMODE=auto
TYPE=Ethernet
USERCTL=no
VLAN=yes

Revision history for this message
Quique Llorente (quiquell) wrote :
Revision history for this message
Scott Moser (smoser) wrote :

This just missed 20.3, but is included in upstream/master and will be included in 20.4.

Fixed in PR #541 https://github.com/canonical/cloud-init/pull/541

Changed in cloud-init:
assignee: nobody → Eduardo Otubo (otubo)
status: Triaged → Fix Committed
Revision history for this message
Chad Smith (chad.smith) wrote : Fixed in cloud-init version 20.4.

This bug is believed to be fixed in cloud-init in version 20.4. 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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers