Проблема с Netplan и Ubuntu 18.04, отключающими нашу сеть после запуска команды netplan apply

Question

Мы пытаемся добавить дополнительные IP-адреса к нашему серверу OVH, и всякий раз, когда мы применяем команду "netplan apply" после внесения изменений в yaml, сервер полностью отключается. Сеть не работает. Это происходит в течение 10-15 минут, прежде чем оно вернется само по себе.

Когда я запускаю команду для проверки состояния systemd-networkd, я получаю следующее:

● systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2018-12-02 05:10:18 UTC; 26min ago
Docs: man:systemd-networkd.service(8)
Main PID: 40782 (systemd-network)
Status: "Processing requests..."
Tasks: 1 (limit: 8601)
CGroup: /system.slice/systemd-networkd.service
       └─40782 /lib/systemd/systemd-networkd

Dec 02 05:10:18 servername systemd-networkd[40782]: eno1: Gained IPv6LL
Dec 02 05:10:18 servername systemd-networkd[40782]: Enumeration completed
Dec 02 05:10:18 servername systemd[1]: Started Network Service.
Dec 02 05:10:18 servername systemd-networkd[40782]: eno2: Could not find udev device: No such device
Dec 02 05:10:18 servername systemd-networkd[40782]: eno2: Failed
Dec 02 05:10:18 servername systemd-networkd[40782]: Could not add new link, ignoring: No such device
Dec 02 05:10:18 servername systemd-networkd[40782]: lo: Link is not managed by us
Dec 02 05:10:18 servername systemd-networkd[40782]: eno1: DHCPv4 address [ip address]/24 via <my server ip address>    
Dec 02 05:10:18 ns536095 systemd-networkd[40782]: eno1: Configured
Dec 02 05:10:18 ns536095 systemd-networkd[40782]: eth0: Interface name change detected, eth0 has been renamed to eno2.    

Кажется, что он пытается найти eno2, но его не существует, что приводит к полной остановке и отключению нашей сети. Все наши IP-адреса установлены на eno1. Для eno2 ничего нет, хотя на сервере есть эта сетевая карта.

Как я могу решить эту проблему? Я пытался понять это в течение самого долгого времени. Файл yaml подтвержден в следующем формате.

network:
version: 2
ethernets:
    eno1:
        dhcp4: true
        addresses: [<Main IP>, <additional ip>]

любая помощь будет принята с благодарностью.

Answer 1

У меня похожая проблема, но интерфейс не возвращается автоматически через 10-15 минут. У меня проблема с мостовыми интерфейсами...

  bridges:
    br0:
      addresses:
        - 10.0.1.1/16
        - 172.16.0.1/21
      interfaces:
        - enp2s0f0
        - enp2s0f1
        - enp2s0f2
        - enp2s0f3

Answer 2

Мы видели аналогичную проблему и обнаружили, что определение соединений как «критических» решает проблему:

      ethernets:
    eno1:
        dhcp4: false
        addresses: [<Main IP>, <additional ip>]
        critical: true

К сожалению, документация для «критического» флага в настоящее время довольно скудна, поэтому трудно сказать, есть ли какие-либо недостатки у обозначения соединения как «критического», особенно для портов без DHCP.