LINUX.ORG.RU
ФорумAdmin

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

 ,


0

1

Добрый день! Помогите разобраться: почему-то клиенты не получают адреса, в логе (grep сделал по одному из хостов) вот такая картина без конца:

Mar 26 17:15:30 MyServerName1 dhcpd: DHCPDISCOVER from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:30 MyServerName1 dhcpd: DHCPOFFER on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:30 MyServerName1 dhcpd: DHCPDISCOVER from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:30 MyServerName1 dhcpd: DHCPOFFER on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:31 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:31 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:31 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:31 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:32 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:32 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:32 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:32 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:34 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:34 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:34 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:34 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:38 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:38 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:38 MyServerName1 dhcpd: DHCPREQUEST for 10.10.10.63 (10.10.10.1) from b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Mar 26 17:15:38 MyServerName1 dhcpd: DHCPACK on 10.10.10.63 to b8:78:2e:61:c7:e6 (iPhone-123) via eth0
Куда смотреть-то? Не пойму :(



Последнее исправление: gregg128 (всего исправлений: 1)

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

tcpdump -n -i eth1 -s 0 -v -vv port 67
может там какая странность... Например вмешивается еще один DHCP сервер

operatornk
()
Ответ на: комментарий от operatornk

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

  Total leases:             235
  Total active leases:      26
Как будто он весь занят, хотя тотал это вместе с state: free считается? В связи с этим куча вопросов: почему лизы в состоянии free не используются по-новой, почему вдруг на каждый отлуп (в первом сообщении видно, что отлупы всё время идут) выдаётся лиз, и почему, если пул исчерпан, не выдается DHCPNAK?

gregg128
() автор топика
Ответ на: комментарий от operatornk

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

gregg128
() автор топика
Ответ на: комментарий от gregg128

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

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

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

Total leases:             235
Total active leases:      26
В том-то и странность, что на запросы он отвечает, но почему-то, получается, DHCPACK куча клиентов не принимает и шлёт сразу опять DHCPREQUEST. То есть первые 20-30 клиентов он нормально обслуживает, а дальше ведёт себя странно.

gregg128
() автор топика
Ответ на: комментарий от gregg128

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

vel ★★★★★
()

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

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

swelf
()
Ответ на: комментарий от gregg128

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

operatornk
()
Ответ на: комментарий от operatornk

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

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

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

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

gregg128
() автор топика
Ответ на: комментарий от gregg128

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

operatornk
()
Ответ на: комментарий от operatornk

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

gregg128
() автор топика
Ответ на: комментарий от gregg128

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

operatornk
()
11 февраля 2017 г.

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

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

LamerLinux
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.