support for dummy interfaces

Bug #1774203 reported by Christian
166
This bug affects 33 people
Affects Status Importance Assigned to Milestone
Netplan
Fix Released
Wishlist
Danilo Egea Gondolfo

Bug Description

I am trying to create a dummy interface with the netplan config and it seems that it is not supported yet.

Something like this:

ip link add dev dummy1 type dummy
ip link set dummy1 up
ip addr add dev dummy1 192.0.2.10/32

Please add support for this as I would like to not spread network config in different places. Now I have to use systemd.netdev drop-ins I guess, to get this working.

Revision history for this message
David A. Desrosiers (setuid) wrote :

I have a customer who is migrating their cloud from Xenial/Mitaka to Bionic/Queens, and has begun the exercise of migrating their network topologies to netplan, but found that it does not support creating dummy interfaces (or, apparently support for OVS at this point[0]).

There is a bit of a workaround using a systemd unit, which may close the gap temporarily, but it may not apply to all environments (pseudocode below)

[Unit]
Description=Create dummy interface
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ip li add dummy0 type dummy

I'd like to see native support in netplan for dummy interfaces, if possible.

[0] https://bugs.launchpad.net/netplan/+bug/1728134

tags: added: sts
Revision history for this message
Francois Lafont (francois-lafont) wrote :

Indeed, it would be handy to have support of dummy interfaces.

In the WWW, I have seen _workarounds_ like this:

```
network:
  version: 2
  renderer: networkd
  bridges:
    dummy0:
      interfaces: []
      addresses: ['10.111.222.60/24']
```

but a bridge is not a dummy interface.

Revision history for this message
Vincent JARDIN (vjardin) wrote :

FYI, my workaround is the following:

```
    bridges:
        loop1:
            dhcp4: no
            dhcp6: no
            accept-ra: no
            interfaces: []
            addresses: ['A.B.C.D/32']
```

# ethtool -i loop1
driver: bridge
version: 2.3
firmware-version: N/A
expansion-rom-version:
bus-info: N/A
supports-statistics: no
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

Revision history for this message
Vincent JARDIN (vjardin) wrote :

It is not exactly equivalent to:

sudo ip link add name loop1 type dummy
sudo ip addr add A.B.C.D/32 dev loop1

but it does the job.

That's why a proper fix is not top priority, but it would be a nice to have.

Revision history for this message
Filippo DiNoto (fdinoto) wrote :

Loopback interfaces are important for switches/routers. The Linux dummy interface provides the ability to create interfaces whose function is consistent with loopback interfaces widely used on switches/routers.

Dummy interfaces can be created with both Network Manager and systemd-networkd. Because of their simplicity, adding support to netplan should be easy and will not add debt to the netplan project. The nmstate project already supports dummy interfaces. There is no practical need to match or sync with any existing devices on the system. Netplan should not concern itself with anything but creating the interface and assigning the addresses.

There are very important uses for dummy/loopback interfaces.

- Link-State routing protocols like OSPF/IS-IS, or cluster identifier for iBGP
- Endpoints for systems with multiple tunnels
- Any situation where a layer-3 failover solution is required
- Load balancing with ECMP (equal-cost multipath routing)
- Configuring additional addresses on system which are being routed to the system via a physical interface from an upstream internet/cloud/hosting provider.

A dummy/loopback interface is NOT a bridge. A bridge is a layer-2 solution, a dummy/loopback is a layer-3 solution.

The proper location in the yaml hierarchy should be:

network:
  dummies: # or loopbacks:
    dummy0:
      addresses:
        - n.n.n.n/n

A bridge interface is not a great substitute for a dummy/loopback interface because it can complicate configurations and create confusion for users. In most bridge implementations, the bridge includes a physical interface for connectivity to an external gateway. During troubleshooting, it is very common for users to be misled into thinking they need to add their physical interface to the bridge and migrate the IP configuration to the bridge which solves nothing and usually results in additional problems.

Lukas Märdian (slyon)
tags: added: fr-463
Changed in netplan:
importance: Undecided → Wishlist
status: New → Confirmed
Revision history for this message
John Fleming (jflemingeds) wrote :

FYI a bridge interface will report link state down until the first device is attached to it. At least with FRR this will prevent the IP attached to the bridge interface from being advertised.

Revision history for this message
Yasin CANER (yasincanerulak) wrote :

@Francois Lafont comment says a lot of thing "a bridge is not a dummy interface."

It doesn't work how dummy interface shall work. Somehow it truncates packets and broke struct. I will give a try about "systemd unit"

Lukas Märdian (slyon)
Changed in netplan:
status: Confirmed → Triaged
Revision history for this message
Danilo Egea Gondolfo (danilogondolfo) wrote :

Pull request implementing support for dummy interface for review https://github.com/canonical/netplan/pull/361

Changed in netplan:
status: Triaged → In Progress
assignee: nobody → Danilo Egea Gondolfo (danilogondolfo)
Changed in netplan:
status: In Progress → Fix Committed
Revision history for this message
Lukas Märdian (slyon) wrote :
Changed in netplan:
status: Fix Committed → Fix Released
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.