How to add a static secondary IP to a DHCP interface using netplan?

Question

My server has a file /etc/netplan/50-cloud-init.yaml with the following content:

# This file is generated from information provided by
# the datasource.  Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
    version: 2
    ethernets:
        ens3:
            dhcp4: true
            match:
                macaddress: fa:**:**:**:**:**
            set-name: ens3

This results in the following interface configuration:

2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc fq_codel state UP group default qlen 1000
    link/ether fa:**:**:**:**:** brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.5/24 brd 10.0.0.255 scope global dynamic ens3
       ...

So far, so good. But now I need to add 10.0.0.250 as an additional secondary static IP to this interface. What is the best way to do that? I created a new file /etc/netplan/60-service-ip.yaml with:

network:
    version: 2
    ethernets:
        ens3:
            addresses:
              - 10.0.0.5/24
              - 10.0.0.250/24

This seems to work, but it re-defines a dynamic IP as a static one.

Solution 1

It's actually way easier, you just add dhcp4: true to your static configuration like this (and disable v6 if you don't need it):

network:
    version: 2
    ethernets:
        ens3:
            dhcp4: yes
            dhcp6: no
            addresses:
              - 10.0.0.250/24

Solution 2

Answered on Ask Ubuntu

Copy:

The solution was quite simple, just set a static IP address and enable DHCP. Basically you just have to add dhcp4: yes to your configuration.

This configuration gave me a primary static IP address and a secondary DHCP assigned IP address:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: yes
      dhcp6: no
      addresses: 
        - 10.1.2.15/24
      gateway4: 10.1.2.1
      nameservers:
        search:
          - example.com
        addresses: [10.1.2.10]

The result of ip address show enp0s3 gave me:

2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:00:27:ab:cd:ef brd ff:ff:ff:ff:ff:ff
    inet 10.1.2.15/24 brd 10.0.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet 10.1.2.96/24 brd 10.0.1.255 scope global secondary dynamic enp0s3
       valid_lft 3224sec preferred_lft 3224sec
    inet6 fe80::a00:27ff:fe20:2c40/64 scope link 
       valid_lft forever preferred_lft forever

The address 10.1.2.96 is the secondary DHCP assigned address as indicated by the secondary dynamic keywords.

Solution 3

I had a same issue where I have dhcp address as secondary and static as primary in Azure. Leaving dhcp address as primary is important because Azure virtual network provides gateway and nameserver information.

I found this workaround:

network:
    version: 2
    ethernets:
        eth0:
          dhcp4: true
          addresses:
              - 10.0.2.6/24 (IP acquired by DHCP)
              - 10.0.2.21/24
          match:
              macaddress: 00:0d:3a:4f:45:f0
          set-name: eth0

In Azure specifically, we assign static ip address on Azure Resource side and normally this is taken to Guest OS by dhcp. Therefore, even though guest os treats it as a dynamic ip, it will always get same static ip from Azure.
Above, I forced to put dhcp IP ahead of secondary IP.
In my case, it worked as expected.

Comments

[Torsten Bronger]

Unfortunately, this results in the DHCP address being the secondary address. However, it needs to be primary in order to make outgoing connections work.

[Lenniey]

Why does it have to be primary? Are you sure you don't just need source routing? or a different gateway per IP?

[Torsten Bronger]

If the DHCP-based address is primary, everything works fine. If it is secondary, outgoing connections hang. See also bugs.launchpad.net/netplan/+bug/1766656, especially comment #2.

[Lenniey]

Outgoing connections don't "hang", they may choose the wrong IP. I presume you got connections to some server/service/whatever which only work with the correct source IP?

[Alexis Wilke]

But that defies using DHCP in the first place if you know which IP address that connection is going to be, doesn't it?!

[ATLief]

@AlexisWilke Pick your poison, I guess. This should work for servers that only ever stay in the same network(s).

[surfingonthenet]

Thanks to gist.github.com/ThomasLeister/640812441505447ba8f19f85314fbf‌​5b