3

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

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

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 (облачный 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 ответа2

4

Причиной проблемы является то, что встроенная сетевая конфигурация 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.

|источник
3

Отказ от аренды не сработает. Нет никакого способа, которым 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-адресами, но я настроил ОС для отправки одного и того же идентификатора клиента независимо от того, какой адаптер подключен. Таким образом, я получаю один и тот же адрес через оба.)

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .