isc-dhcpd: клиенты шлют request без конца

Попробуйте посмотреть вывод

tcpdump -n -i eth1 -s 0 -v -vv port 67

Посмотрел, другого dhcp не видно, вроде. Если посмотреть утилитой dhcp-pool то видно, что разность этих цифр это примерно число айпи в пуле (у меня их 20 зарезервировано под статику).

  Total leases:             235
  Total active leases:      26

Ещё когда смотрел, как вы сказали, tcpdump -n -i eth1 -s 0 -v -vv port 67, видно, что иногда бывает bad udp checksum, но это, наверное, побочное явление - вайфай, наверное, пакеты бьёт.

bad checksum на исходящих пакетах - это норма. Правильная сетевая карта их вычисляет сама перед отправкой пакета в сеть.

Если к этой вайфай-сети другие цепляются нормально - значит проблема в клиенте.

Когда у isc-dhcpd кончаются адреса, он помалкивает на запросы, а в логи пишет что нету свободных адресов. Есть полезная тулза dhcpd-pools - показывает состояние всех пулов.

Как раз этой dhcpd-pools я и вижу:

Total leases:             235
Total active leases:      26

А клиент не слишком далеко ? Если пойти на точку и посмотреть уровень сигнала до этого клиента ? Если клиент далеко, он может не слышать ответа.

Может быть включен dhcp snooping на одном из промежуточных свичей, если поддерживают это.

Тоже бывает что единичные клиенты не получают ip адрес, обычно не разбираюсь, а просто статикой пробиваю.

По поводу dhcp-pool ничего сказать не могу, но могу предположить что Total leases это всего лишь показатель сколько записей обнаружено в файле dhcpd.leases... А так приходят ответы что клиент получил запрошенные параметры, то этот файл очень быстро разрастается и получается общее количество аренд увеличивается по этому файлу... а пул не переполняется потому что запрос идет всегда по одному адресу, а не каждый раз на новый...
Так же как и сказал swelf может мешать данная опция и не правильно настроенный DHCP Relay... Насчет relay должно было тогда показать через tcpdump... что в какой то момент клиент пытается получить ответы с другого ip, и начинает перезапрашивать постоянно данные
Попробуйте отключить из сети все внешние источники, чтобы осталась только локальная сеть и посмотрите как будут вести себя стационарные клиенты...

Всем спасибо за комментарии.

• Клиенты сидят прямо под точкой доступа вайфай;
• Вайфай, похоже, не при чём: когда такое поведение начинается (на пике рабочего дня обычно), эффект сохраняется если подключиться патчкордом напрямую в коммутатор;
• Коммутатор там один, неуправляемый длинк на 48 портов, какой уж там снупинг?
• Пересылкой дхцп там занимаются только три вайфайные точки unifi.

В этой связи у меня две версии, обе про глюки на втором уровне: - коммутатору крышу рвёт. Там длинк вместо норм. железа, от него не знаешь, что ждать. - кто-то или что-то организует шторм в сети?

Есть ещё идеи?

Для уточнения: проблема не постоянная а только в какой то определенный период? у стационарных клиентов такое поведение не наблюдается, только у вай фай? какая точка доступа используется?

Даже втыкая свой ноут напрямую в свитч, без всякого вайфая, я вижу то же поведение: обмен пакетами REQUEST и ACK без конца. «Давай» «бери» и всё про один и тот же адрес, не про разные - иначе бы пул исчерпался быстро. Проблема обычно на пике активности в офисе, но я не уверен, что с этим связано - в другое время, видимо, просто не так замечают. Люди уже привыкли, что регулярно падает инет на ноут. На вайфай почему-то чаще, что интересно. Пока кроме съехавшей крыши у свитча или какого-то шторма не придумаю идей :(

А если попробовать отрубить свич и ноут на прямую в сервер включить и посмотреть как он будет получать адрес, тем самым исключите свич, если конечно проблема останется...
Просто была подобная проблема и так же думал что и настройки сервера и оборудование, но оказалось, что проблема в неправильной настройки DHCP Relay на оборудование провайдера... Правда там была загвоздка что от провайдера по мимо кабеля с интернетом еще приходил кабель с Vlan для объединения офисов... Но там все показал tcpdump... А насчет свича, он конечно может, но за мою практику такого не было, в основном он просто зависал и отрубал час сети...
Поэтому лучшим вариантом думаю это действовать методом исключения... с начало одно устройство на прямую к серверу, потом по одному сетевое оборудование подключать и смотреть поведения сервера, и там уже разбираться...
Но поидеи это проблема не правильной адресации при получание адреса в момент обмена пакетами с dhcp...

Ситуация может быть такая же, но только я клиент и постоянно шлю запросы. Кто виноват? И что делать?

eth1 смотрит на провайдера, адрес получаю, естественно, по dhcp

syslog

Feb 11 10:54:16 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:22 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:23 PC dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67

Feb 11 10:54:23 PC dhclient: DHCPACK from 10.11.7.250

Feb 11 10:54:23 PC dhclient: bound to 10.11.7.202 — renewal in 898 seconds.

Feb 11 10:54:24 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:27 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:30 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:35 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:39 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:45 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:50 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:52 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:54 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:54:59 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:05 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:09 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:09 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:09 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:21 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:21 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:22 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:26 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:28 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:29 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:40 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:41 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:43 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:45 PC dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67

Feb 11 10:55:45 PC dhclient: DHCPACK from 10.11.7.250

Feb 11 10:55:45 PC dhclient: bound to 10.11.7.202 — renewal in 897 seconds.

Feb 11 10:55:52 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:55 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:55:59 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:56:03 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:56:06 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

Feb 11 10:56:13 PC dhclient: DHCPREQUEST on eth1 to 10.11.7.252 port 67

dhclient.conf

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;

send host-name = gethostname();

request subnet-mask, broadcast-address, time-offset, routers,

domain-name, domain-name-servers, domain-search, host-name,

dhcp6.name-servers, dhcp6.domain-search,

netbios-name-servers, netbios-scope, interface-mtu,

rfc3442-classless-static-routes, ntp-servers;

dhclient.leases

lease {

interface «eth1»;

fixed-address 10.11.7.202;

option subnet-mask 255.255.252.0;

option routers 10.11.7.250;

option dhcp-lease-time 1800;

option dhcp-message-type 5;

option domain-name-servers 195.138.80.86;

option dhcp-server-identifier 10.11.7.252;

option broadcast-address 10.11.7.255;

renew 6 2017/02/11 08:51:56;

rebind 6 2017/02/11 09:06:53;

expire 6 2017/02/11 09:10:38;

}

lease {

interface «eth1»;

fixed-address 10.11.7.202;

option subnet-mask 255.255.252.0;

option routers 10.11.7.250;

option dhcp-lease-time 1800;

option dhcp-message-type 5;

option domain-name-servers 195.138.80.86;

option dhcp-server-identifier 10.11.7.252;

option rfc3442-classless-statlease {

interface «eth1»;

fixed-address 10.11.7.202;

option subnet-mask 255.255.252.0;

option routers 10.11.7.250;

option dhcp-lease-time 1800;

option dhcp-message-type 5;

option domain-name-servers 195.138.80.86;

option dhcp-server-identifier 10.11.7.252;

option rfc3442-classless-static-routes 28,195,138,70,208,10,11,7,250,32,195,138,80,24,10,11,7,250,32,195,138,80,40,10,11,7,250,32,$

interface «eth1»;

fixed-address 10.11.7.202;

option subnet-mask 255.255.252.0;

option routers 10.11.7.250;

option dhcp-lease-time 1800;

option dhcp-message-type 5;

option domain-name-servers 195.138.80.86;

option dhcp-server-identifier 10.11.7.252;

option rfc3442-classless-static-routes 28,195,138,70,208,10,11,7,250,32,195,138,80,24,10,11,7,250,32,195,138,80,40,10,11,7,250,32,$

option broadcast-address 10.11.7.255;

renew 6 2017/02/11 09:10:42;

rebind 6 2017/02/11 09:22:00;

expire 6 2017/02/11 09:25:45;

}

ifconfig eth1

eth1 Link encap:Ethernet HWaddr 00:02:2a:e2:f1:1b

inet addr:10.11.7.202 Bcast:10.11.7.255 Mask:255.255.252.0

UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1

RX packets:359996 errors:0 dropped:0 overruns:0 frame:0

TX packets:188889 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:485782986 (463.2 MiB) TX bytes:17541235 (16.7 MiB)

Interrupt:19 Base address:0xc800

Проблема решена на стороне провайдера.