DHCP разное

DHCP client

Проверка на то, что DHCP делает renew и посмотреть время аренды можно по логам dhcpclient.

sudo grep dhclient /var/log/syslog
2019 Feb  9 13:42:27 info dhclient[12271]: DHCPREQUEST on eth0 to 172.2.2.2 port 67 (xid=0x1111111111)
2019 Feb  9 13:42:27 info dhclient[12271]: DHCPACK from 172.2.2.2 (xid=0x1111111111)
2019 Feb  9 13:42:30 info dhclient[12271]: bound to 172.1.1.1 -- renewal in 38785 seconds.
2019 Feb 10 00:28:55 info dhclient[12271]: DHCPREQUEST on eth0 to 172.2.2.2 port 67 (xid=0x1111111111)
2019 Feb 10 00:29:03 info dhclient[12271]: DHCPREQUEST on eth0 to 172.2.2.2 port 67 (xid=0x1111111111)
2019 Feb 10 00:29:03 info dhclient[12271]: DHCPACK from 172.2.2.2 (xid=0x1111111111)
2019 Feb 10 00:29:05 info dhclient[12271]: bound to 172.1.1.1 -- renewal in 34413 seconds.
2019 Feb 10 10:02:38 info dhclient[12271]: DHCPREQUEST on eth0 to 172.2.2.2 port 67 (xid=0x1111111111)
2019 Feb 10 10:02:43 info dhclient[12271]: DHCPREQUEST on eth0 to 172.2.2.2 port 67 (xid=0x1111111111)
2020 Feb 10 10:02:43 info dhclient[12271]: DHCPACK from 172.2.2.2 (xid=0x1111111111)
2020 Feb 10 10:02:45 info dhclient[12271]: bound to 172.1.1.1 -- renewal in 38382 seconds.

 

DHCP options

Опции DHCP используются для авто-провижнинга. Это могут быть разные устройства – VOIP телефоны (option 150 с указанием адреса TFTP сервера для IP phones), точки доступа и даже коммутаторы на базе Linux.

Первая загрузка в Cumulus Linux, определяется наличие скриптов настройки через опцию 239 DHCP. Если в ответ получается URL адрес, то по нему запрашивается скрипт, в нем разыскивается CUMULUS-AUTOPROVISIONING и скрипт запускается от root. Поддерживаются Bash, Ruby, Perl, Python.
DHCP использует ARP для защиты от конфликта IP

Как минимум два использования ARP для защиты от конфликта:

  • сервер предварительно делает arp request с попыткой резолва IP, который собирается выдать. Делается, если сервер находится в одной подсети с клиентом, которому лизу выдает.
  • клиент делает три garp после получения IP

Пример дампа:

Cisco CNR особенности

Узнал пару новых вещей, расширяя забитый пул для одного из сегментов сети:

  • в случае CNR (или по крайнем мере нашей реализацией взаимодействия с ним) нельзя просто увеличить маску сети для сегмента, несмотря на то, что следующая сеть свободна. Если изменить маску, на DHCP дропаются все старые лизы и DHCP пул просто пересоздастся. Поэтому проще работать по стандартной схеме – вынести текущую сеть как secondary, а новую, с большой маской, настроить как primary (разумеется, предварительно добавив на сервер). В таком случае прерывания нет или оно минимально – при перевешивании primary -> secondary у меня не прервался даже telnet.
  • 10% пула по умолчанию уходит в резерв, поэтому выдача IP идет не с 1-го адреса. Нужно это для failover сервера, в случае падения основного. Основной с failover синхронизятся раз в час и чтобы избежать конфликтов для лиз, которые выдались после синхронизации, failover сначала выдает IP из этого резервного пула. Для многих сетей это удобно и тем, что первые адреса диапазона зачастую занимаются под сервера/юр. лиц.
Дамп трафика

flow-graph-1.pcapng

Leave a Reply