» РЕШЕНО. Заставить dhclient FreeBSD брать в renew или rebind

Теория.
http://docs.pcn.com.ua/book.itep.ru/dhcp.html

Ищу как заставить dhclient FreeBSD посылать широковещательно запрос в положенное время rebind Т2 87,5%
поскольку на запрос (уникастно) DHCPREQUEST в положенное время renew Т1 50%, сервер провайдера не отвечает даже для Windows ,
или посылать запросы через указанный мною интервал времени.

По алгоритму интервал для момента следующего запроса после безответного (уникастно) DHCPREQUEST Т1 50%, формируются по формуле - время аренды умноженное на случайное число в интервале до 1.
Поэтому, продолжая посылать запросы через вычисленный таким образом интервал времени и момент следующего запроса после очередного неполучения ответа на запрос (уникастно) DHCPREQUEST renew Т1 50%-87,4%, очень часто не попадает в интервал времени для запроса широковещательного DHCPREQUEST rebind Т2 87,5%-99%, превышая момент rebind Т2 87,5%-99%, и expire 100%, и сервер остаётся без шлюза и без связи с интернетом на несколько секунд, пока не наступит расчётный момент следующего запроса и dhclient не сформирует широковещательный DHCPDISCOVER запрос уже от IP 0.0.0.0 на 255.255.255.255
А это при просмотре IPTV или в играх задалбывает, если время аренды двенадцать минут(720 сек), то почти каждые двадцать минут на десять секунд затык.
Настройки, dhclient из ядра, опций запросов в dhclient.conf ничего не меняют.
Во многих форумах ещё с 2003 года встречается описание этой проблемы, но решения никто не нашел,
кроме как требовать от провайдера желаемой настройки DHCPсервера, и естественно безрезультатно.
Но:
а. Остальные имеющиеся провайдеры ещё хуже.
Этот вроде нормальный в остальном, но вот этот нюанс.
б. Хочу всё же найти решение на своей стороне используя хвалёную гибкость FreeBSD,
и предполагаю что просто не хватает знаний для осуществления необходимого,
поэтому ищу решение в поисковиках.
Даже роутер D-link DIR-300 rev.A , программное обеспечение которого основано на UNIX системе,
беспроблемно берёт аренду точно в момент rebind (+0 -0 сек)
и Windows берёт аренду в момент rebind (+1 - +4 сек)


Может вы знаете метод самостоятельного решение этого простого вопроса.

Как заставить dhclient:
1. Или заставить посылать широковещательно запрос rebind в положенное время T2, то есть когда истечет 87.5% аренды, а не произвольно в интервалы по алгоритму.
2. Или заставить посылать запросы через установленное мною интервалы времени, а не произвольно в интервалы по алгоритму.
3. Или каждый раз вместо уникастового посылать широковещательный запрос получения аренда.
4. Или в момент expire не терять свой адрес, а продолжать его использовать до получения нового от DHCP сервера, продолжая посылать широковещательный запрос получения аренда.
5. Или Ваши варианты по dhclient

Лучше осуществить п.1.
повторюсь
dhclient в Windows берёт аренду точно в момент rebind (+1 - +4 сек)
значит интервал между запросами идёт 5 секунд.

Роутер D-link DIR-300 rev.A , программное обеспечение которого основано на UNIX системе,
беспроблемно берёт аренду точно в момент rebind (+0 -0 сек)

[more=фрагмент tcpdump подряд с удачной, неудачной, удачной, удачной, неудачной, удачной попыткой получения аренды.]
время аренды 12 минут(720 сек),

renew Т1 50% - 6 минут(360 сек),
rebind Т2 87,5%-10 мин30сек(630 сек),
expire 100% - 12 минут(720 сек),


22:40:08.525687 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:40:54.525813 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:42:32.522790 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:44:13.763467 IP 192.168.0.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
22:44:13.794328 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
22:50:13.818346 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:50:20.003958 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:50:38.179857 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:50:58.371587 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:51:38.405102 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:53:08.966604 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
22:56:15.207231 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
22:56:16.026942 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
22:56:18.011824 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
22:56:18.047433 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
23:02:18.978847 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:02:26.981152 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:02:49.982881 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:03:27.983356 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:04:19.983171 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:05:53.980413 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:06:02.982847 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:06:11.985258 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:06:20.987693 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:06:31.990016 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:07:01.991096 IP 192.168.0.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
23:07:02.043474 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 351
23:13:02.066961 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:13:09.069529 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:13:19.434914 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:13:42.436470 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:13:52.438833 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:14:12.440619 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:14:20.443350 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:14:28.445650 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:14:37.448098 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:14:45.450579 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:15:06.452307 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:15:23.454241 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:15:33.456642 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:15:41.459155 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:15:55.461342 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:16:23.462560 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:16:34.464884 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:16:49.467014 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:16:58.469404 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:17:14.471412 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:17:27.473615 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:17:42.475605 IP 192.168.0.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
23:17:42.506266 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
23:23:42.525479 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:23:47.528164 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:23:57.530560 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:24:10.532719 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:24:39.533951 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:25:49.532649 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:28:03.527385 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:29:44.586757 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
23:29:45.591211 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
23:29:47.014935 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
23:29:47.040242 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
23:35:47.111808 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:35:53.114411 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:36:08.116513 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:36:32.118040 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:36:43.120348 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:37:11.121629 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:37:39.122891 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:37:51.125138 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:38:07.127146 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:38:33.128566 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:38:48.130649 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:39:36.130683 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:40:06.131844 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:40:30.133275 IP 192.168.0.2.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
23:40:30.163693 IP 192.168.100.1.67 > 192.168.0.2.68: BOOTP/DHCP, Reply, length 314
23:46:30.185139 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:46:34.187946 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]
23:46:42.190387 IP 192.168.0.2.68 > 192.168.100.1.67: BOOTP/DHCP, Request [|bootp]

[/more]

man 5 dhclient.conf

tankistua

Цитата:

man 5 dhclient.conf

Содержательно, и как величественно многозначительно !
Один из явных примеров флудерства,
когда человек не знает что ответить
но хочет зарисоваться своей крутизной он посылает в маны.
Это то-же что послать на х.й.

Я уже перелопатил все маны, не только dhclient
и всё с упоминанием слова dhclient, rebind, renew, DHCPREQUEST, и т.п. за 12-15 лет,
о чём сообщил в первом сообщении,
а меня в man 5 dhclient.con послали.
Очень умно, ................................................................. !!!

Здравствуйте!
Хотелось бы узнать уважаемый boaboa, смогли ли Вы найти решение этой проблемы?
Я (возможно) также столкнулся с подобным случаем, хотя у меня установлен Linux. Я пробовал использовать разные DHCP-клиенты - dhclient и dhcpcd, но проблема не исчезла. На одном из Linux-форумов мне максимум, что смогли посоветовать, так это воткнуть маршрутизатор между моим компьютером и провайдерской сетью. Я проверял - это работает, но хотелось бы всё же найти причины проблемы и устранить их.
Не могли бы Вы рассказать поподробнее, что необходимо требовать при обращении в техподдержку провайдера, чтобы решить указанную проблему?

РЕШЕНИЕ:

Сначала хочу сказать, что служба большого провайдера это неповоротливая машина старающаяся не делать ошибки, чтоб не угробить всю сеть, поэтому от момента обращения к ним до момента решения вопросы в глобальных масштабах может пройти много времени и пару сотен жалоб от других абонентов, а поскольку данная проблема на Windows машинах большинства пользователей провайдера не возникает, и роутеры тоже её не имеют, то остальным оставшись в меньшинстве придется самостоятельно решать на своей стороне.


В данном случае проблема была в том что DHCP-сервер провайдера отвечает только на мультикастовые запросы,
которые DHCP-клиент начинает слать только с момента Т2 87,5% времени аренды,
но в соответствии с требованием об интервалах между запросами,
а именно:
T2 по умолчанию равно (0.875 * duration_of_lease)
время T2 должно быть выбрано с некоторым случайным разбросом относительно фиксированных значений.
Клиент должен ждать половину остающегося времени вплоть до T2 (в состоянии RENEWING) и половину остающегося времени действия конфигурационного набора (в состоянии REBINDING), как минимум 60 секунд, прежде чем осуществить повторную отправку сообщения DHCPREQUEST.

Поэтому не всегда удавалось успеть послать мультикастовый запрос DHCPREQUEST до потери аренды.

Решением было выбрано посылать только мультикаст широковещательные запросы,
таким образом DHCP-клиент с момента Т1 в соответствии с требованием об интервалах
вместо уникастового DHCPREQUEST безответного
посылать широковещательно сообщение DHCPREQUEST

Для этого в файл
/usr/local/etc/dhclient.conf
достаточно записать строку "замена DHCP-сервер идентификатор 255.255.255.255"
supersede dhcp-server-identifier 255.255.255.255;

о чём в принципе пишут почти на каждом углу
http://www.google.com.ua/search?q=%22supersede+dhcp-server-identifier+255.255.255.255%22&sugexp=chrome,mod=2&sourceid=chrome&ie=UTF-8

Но.
Никто ж не сказал что половина DHCP-клиентов от разных производителей не обращает внимания на существование этого указания в своей конфигурации, и продолжают слать запросы по стандартному протоколу на уникаст.
что при использовании мониторинга tcpdump сетевой карты eth1
tcpdump -eni eth1 port 67 or port 68
хорошо видно
http://forum.ru-board.com/topic.cgi?forum=65&topic=4463&start=0&limit=1&m=1#1

Поэтому дальнейшим правильным путём был поиск DHCP-клиентов согласных подчиняться командам,
и в последствии был найден isc-dhcp42-client
он как оказалось способен сделать то что требуется,

но возникли проблемы с его запуском из за моей привычки чётко следовать инструкции,
а в своей инструкции компания isc пишет:
**** To setup dhclient, you may need to edit /etc/rc.conf to replace the
base system dhclient as follows:
Для настройки dhclient, вам может потребоваться отредактировать файл /etc/rc.conf, чтобы заменить базовую систему dhclient , следующим образом:

dhcp_program="/usr/local/sbin/dhclient"
dhcp_flags="-q"

что естественно неправильно поскольку dhcp_program это DHCP-сервер,
а мы поставили и желаем запустить DHCP-клиент, а значит
правильным будет в файл /etc/rc.conf

# Путь к программе-клиенту DHCP.
dhclient_program="/usr/local/sbin/dhclient"
# Флаги для программы-клиента DHCP.
dhclient_flags=""

о чём верно написано, здесь
http://www.freebsd.org/doc/ru/books/handbook/network-dhcp.html
только место нового
не
"/sbin/dhclient"
а
"/usr/local/sbin/dhclient"
как указал установщик.


затем в файл
/usr/local/etc/dhclient.conf
записать строку
supersede dhcp-server-identifier 255.255.255.255;

и в завершение перезагрузить машину
reboot
или
shutdown -r now
или как Вы привыкли.

смотрим
tcpdump -eni eth1 port 67 or port 68
видим

00:01:01.381662 MAC сетевой МОЕЙ > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: IP сетевой МОЕЙ.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
00:01:01.508511 MAC сетевой ПРОВАЙДЕРА > MAC сетевой МОЕЙ, ethertype IPv4 (0x0800), length 336: IP сетевой ПРОВАЙДЕРА.67 > IP сетевой МОЕЙ.68: BOOTP/DHCP, Reply, length 294


или короче
tcpdump -ni eth1 port 67 or port 68

00:01:01.068917 IP сетевой МОЕЙ.68 > 255.255.255.255.67: BOOTP/DHCP, Request [|bootp]
00:01:01.102829 IP сетевой ПРОВАЙДЕРА.67 > IP сетевой МОЕЙ.68: BOOTP/DHCP, Reply, length 294

и так повторяется через приблизительно половину времени аренды, в момент Т1.
чего и желали достичь,
dhclient берёт аренду точно в то время, когда и должен изначально брать при положительном стечении всех первичных обстоятельств по стандартному протоколу.
и не флудит кучей запросов.


----------------
На стороне провайдера в последующем тоже произвели перемены
увеличив длительность аренды с 12 минут до 60 минут,
таким образом увеличив время с момента Т2
в который DHCP-клиент начинает слать широковешательные запросы на которые откликается DHCP-сервер провайдера
до момента окончания аренды,
в пять раз,
со 108секунд до 540секунд,
что вполне достаточно для выполнения DHCP-клиентом требований по интервалам запросов, и успешного получения аренды, но флуда кучей безответных уникаст запросов от dhclient не избежать.



Поскольку все UNIX-системы очень похожи, то это dhclient решение надеюсь подойдёт.


Для понимания сути проблемы и направления пути решения очень помогла инструкция,
которую я указал в первом сообщении вверху.

А можно вопрос чайника, зачем нужна такая задача?

[more] Доброе время суток похожая проблема, а что мне делать вот с такой проблемой:

По присланному Вами дампу, видно только "первоначальное" получение клиентом (вашим dhcp) настроек для сетевого интерфейса.
А именно, тут я вижу только последовательность "DHCP Discover"-> "DHCP Offer"-> "DHCP Request" ->"DHCP ACK"
После этого Ваш интерфейс получает и применяет настройки выданные ему от DHCP сервера, на время указанное в ответе.
А именно на 600 сек. В данном случае. При истечении времени аренды, а точнее при половине 50% времени её истечения (300), Клиент доложен прислать запрос unicast-ом серверу о продлении этой сессии. Далее точно такой же запрос по истечении, 87% времени аренды.
И только если после этого если он не получает ответов от сервера при unicast запросах, он отправляет broadcast.
В присланных Вами данных нет процесса продления.
Скорее всего проблема в клиенте. Возможно необходимо правильно настроить Ваш клиент.

Это мне ответил провайдер, я тоже обратился к нему с жалобой на переодические прирывания работы dhclient на FreeBSD 9.2

Пробовал установить isc-dhcp42-client пробовал командой запустить его нехочит получать ip, а у роутера получает! [/more]

fortero
Ну так 2-мя постами выше всё подробно изложено и разжёвано.

Ну так 2-мя постами выше всё подробно изложено и разжёвано.

И нечего не работает...

fortero
Это означает что у Вас работает на машине dhclient с опцией supersede dhcp-server-identifier 255.255.255.255; и при этом в дампе трафика Вы наблюдаете отправленные unicast пакеты на адрес dhcp сервера?

А как должен выглядить unicast? ip:68 to ip_gw:67

У мееня ткое ощущение что он неуспевает иногда так как это случаетса раз в час при оренде ip раз в 10 мин.

fortero
Да, unicast пакет это тот который идёт на один конкретный адрес.

Что значит "не успевает"? Судя по тому что Вы написали, Ваш клиент не обрабатывает опцию lease time. Попробуйте запускать dhclient с опцией -v и посмотреть что он пишет в лог.

[more] Вот что у меня получаетса:

killall dhclient && dhclient -d vlan101
DHCPREQUEST on vlan101 to 255.255.255.255 port 67
DHCPNAK from 95.47.206.1
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 95.47.207.1
DHCPREQUEST on vlan101 to 255.255.255.255 port 67
DHCPACK from 95.47.207.1
bound to 95.47.207.40 -- renewal in 300 seconds.
DHCPREQUEST on vlan101 to 95.47.207.1 port 67
DHCPACK from 95.47.206.1
bound to 95.47.207.40 -- renewal in 300 seconds.
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 255.255.255.255 port 67
DHCPACK from 95.47.206.1
bound to 95.47.207.40 -- renewal in 300 seconds.
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 95.47.206.1 port 67
DHCPREQUEST on vlan101 to 255.255.255.255 port 67
DHCPACK from 95.47.206.1
bound to 95.47.207.40 -- renewal in 300 seconds.


А вот tcpdump:
tcpdump -n -e -i vlan101 dst port 67 or src port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan101, link-type EN10MB (Ethernet), capture size 65535 bytes
09:24:00.965144 00:18:de:7a:c9:93 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 360: 95.47.207.41.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:de:7a:c9:93, length 318
09:24:09.264543 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:25:22.713549 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:26:35.714544 00:01:2e:bc:f6:82 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:31:35.727570 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:31:42.728544 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:32:05.729551 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:32:20.730570 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:32:38.731558 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:32:48.732545 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:32:58.000222 00:18:de:7a:c9:93 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 360: 95.47.207.41.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:18:de:7a:c9:93, length 318
09:33:13.733548 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:33:56.734554 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:34:48.191550 00:01:2e:bc:f6:82 > 08:81:f4:80:b7:f0, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 95.47.206.1.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300
09:35:40.192537 00:01:2e:bc:f6:82 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 95.47.207.40.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:01:2e:bc:f6:82, length 300

Скажу сразу мне дан вилан от прова, в нём у меня 2 сервера, .40 мой , а .41 тоже мой но удалённый, логи сняты с 40-вого [/more]

fortero
Ну так у Вас клиент стучится на unicast адрес, и изредка бродакстит. Это "изредка" Вам как и многим другим не хватает. Судя по всему Ваш клиент либо не воспринял конфиг описанный выше, либо Вы что-то недоделали.

[more] Если я правельно всё понял, то. Довожу конфиг до такого состояния:

#cat /usr/local/etc/dhclient.conf
supersede dhcp-server-identifier 255.255.255.255;

Затем компилю isc-dhcp42-client

И запускаю /usr/local/sbin/dhclient -d -cf /usr/local/etc/dhclient.conf vlan101

Верно?

Но есть 2 но.

Первое isc-dhcp42-client получать ip-шники от провайдера отказался, не получаетса:

]#/usr/local/sbin/dhclient -d -cf /usr/local/etc/dhclient.conf vlan101
Internet Systems Consortium DHCP Client 4.2.6
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on BPF/vlan101/00:01:2e:bc:f6:82
Sending on BPF/vlan101/00:01:2e:bc:f6:82
Sending on Socket/fallback
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 12
DHCPDISCOVER on vlan101 to 255.255.255.255 port 67 interval 16

И так далее..

А если dhclient нативный юзать то результат тот же.

Разьясните пожалуйста, если у меня 10 минут на оренду. То через 5 минут ДХЦП проверяет подлинность, затем через 87% процентов снова. Но наблюдая за ним я вижу что в последнии секунды до кона он начинает слать DHCPREQUEST on vlan101 to 95.47.206.1 port 67. Следовательно он должен раьше это начать? [/more]

fortero
Первое, что меня смущает во всём этом деле это то, что в rfc2131 в секции 4.3.6 сказано, что RENEWING пакет должен быть unicast (алгоритм начинает работать по наступлению времени T1).
Про времена описано в секции 4.4.5. T1 = 0.5 лизы, T2 = 0.875 лизы.

Почему у Вас dhclient42 не работает это надо разбираться отдельно.

Самое интересное не одна из версий из портов isc-dhcp не работает. И на ubunte не работает((( Хотя раньше работала...