Неверный IP-адрес от DHCP-клиента в Ubuntu 18.04

У меня возникла странная проблема, из-за которой моему Ubuntu 18.04 (server) box выдается неправильный IP-адрес во время загрузки с DHCP-сервера. Запуск dhclient после загрузки интерфейса приводит к добавлению к интерфейсу правильного IP-адреса.

DHCP-сервер - это окно Windows, где резервирование было настроено вручную с использованием MAC-адреса, отображаемого ip addr в убунту (без двоеточий):

5: eno4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:26:b9:82:44:27 brd ff:ff:ff:ff:ff:ff
    inet 10.10.11.162/23 brd 10.10.11.255 scope global dynamic eno4
       valid_lft 689861sec preferred_lft 689861sec
    inet6 fe80::226:b9ff:fe82:4427/64 scope link
       valid_lft forever preferred_lft forever

мой 50-courtin-networking.cfg (cloud-init cfg)

network:
  version: 2
  ethernets:

    bcm:
      match:
        name: eno*
      dhcp4: true
      dhcp6: false

Записи Journalctl для DHCP:

#journalctl | grep -Ei 'dhcp'`
Jul 12 10:10:56 skprov2 systemd-networkd[1160]: eno1: DHCP lease lost
Jul 12 10:10:57 skprov2 systemd-networkd[1160]: eno4: DHCP lease lost
Jul 12 10:11:00 skprov2 systemd-networkd[1160]: eno1: DHCPv4 address 10.10.11.157/23 via 10.10.10.254
Jul 12 10:11:02 skprov2 systemd-networkd[1160]: eno4: DHCPv4 address 10.10.11.162/23 via 10.10.10.254

Вызов dhclient вручную после входа в систему (многословно):

# dhclient -v eno4
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/eno4/00:26:b9:82:44:27
Sending on   LPF/eno4/00:26:b9:82:44:27
Sending on   Socket/fallback
DHCPREQUEST of 10.10.10.40 on eno4 to 255.255.255.255 port 67 (xid=0x4cb8a62d)
DHCPACK of 10.10.10.40 from 10.10.10.10
bound to 10.10.10.40 -- renewal in 294538 seconds.

10.10.10.10 правильный сервер DHCP, и 10.10.10.40 настроен ли на нем IP-адрес? В Windows DHCP неправильная аренда (.162) показывает длинный "Уникальный идентификатор", который не содержит MAC-адреса, присутствующего в окне ubuntu: 032e827c00020000ab11d0fc617dced58a43

Как правильно избежать этого? Отказать в аренде на длинный UID? Откуда этот UID в первую очередь? Сетевая карта встроена в сервер Dell PowerEdge R710.

Источник

2 ответа

Решение

Причиной проблемы является то, что встроенная сетевая конфигурация Ubuntu 18.04 больше не использует MAC-адрес сетевой карты в качестве идентификатора по умолчанию для запросов DHCP.

Традиционное (и я считаю "разумным") поведение можно восстановить, добавив dhcp-identifier: mac к конфигурации в файле /etc/netplan/xxx.yaml (cloud-init) следующим образом:

network:
    renderer: networkd
    version: 2
    ethernets:
        nicdevicename:
            dhcp4: true
            dhcp-identifier: mac

Где "nicdevicename" - это имя вашего сетевого устройства.

использование

sudo netplan apply

попробовать новую конфигурацию. Если вы получили какие-либо ошибки, обратите внимание, что точный отступ очень важен в файлах.yaml.

Источник

Отказ от аренды не сработает. Нет никакого способа, которым networkd мог бы знать, почему это отказано, таким образом, он не просто волшебным образом переключится на другой тип идентификатора, если вы сделаете это. Вы должны сделать это вручную.

Если ваша версия systemd достаточно свежая и если вы имеете прямой контроль над файлами конфигурации, записанными в cloud-init, вы можете указать systemd-networkd отправлять идентификатор клиента на основе MAC-адреса через *.network файл:

[DHCP]
ClientIdentifier=mac

Но если вы знаете, что systemd-networkd будет использоваться всегда, вы можете просто назначить правильную аренду идентификатору клиента 032e827c00020000ab11d0fc617dced58a43потому что это то, что systemd-networkd всегда будет отправлять для этой машины. (Он генерирует идентификатор на основе /etc/machine-id.)

Клиенты Mos DHCP, в том числе dhclient, предоставляют поле client-ID типа '01' (на основе MAC). Другой распространенный тип - "00" (доменное имя). Однако по умолчанию systemd-networkd предоставляет "непрозрачный" идентификатор клиента, который был сгенерирован из содержимого /etc/machine-id.

Согласно протоколу DHCP, аренда выбирается сначала по идентификатору клиента (при условии, что клиент предоставляет опцию "идентификатор клиента", которая может быть или не основываться на MAC-адресах), а затем по MAC-адресу, только если клиент этого не сделал. отправить идентификатор.

Поэтому, когда вы настраиваете резервирование, все хорошие DHCP-серверы позволят вам ввести либо идентификатор клиента, либо MAC-адрес. Если вы введете только MAC-адрес, то я предполагаю, что автоматически указывается идентификатор клиента типа "01" (на основе MAC-адреса). Может быть установлен флажок "Игнорировать идентификатор клиента", который удобен для вас, но технически нарушает спецификацию DHCP.

(Например, у меня есть два адаптера Wi-Fi с разными MAC-адресами, но я настроил ОС для отправки одного и того же идентификатора клиента независимо от того, какой адаптер подключен. Таким образом, я получаю один и тот же адрес через оба.)

Источник

В vSphere было отмечено, что если шаблон содержит идентификатор машины, то любые виртуальные машины, клонированные из шаблона, получают тот же IP-адрес, что и DHCP, используют идентификатор машины, а не MAC-адрес. Решение состоит в том, чтобы удалить идентификатор машины из файла /etc/machine-id в шаблоне, чтобы новый идентификатор машины был создан во время клонирования.

echo -n > /etc/machine-id
Источник
Другие вопросы по тегам