Архивировано

Эта тема находится в архиве и закрыта для публикации сообщений.

adsi

Ответ на RENEWING DHCPREQUEST

Рекомендованные сообщения

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

Есть dhclient.eth3.leases, который содержит:

renew 5 2008/10/10 18:44:23;
rebind 1 2008/10/13 20:49:01;
expire 2 2008/10/14 17:49:01;

и

option dhcp-server-identifier 83.102.233.202;

хотя

Oct  7 21:49:00 server dhclient: DHCPOFFER from 10.4.41.100
Oct  7 21:49:01 server dhclient: DHCPREQUEST on eth3 to 255.255.255.255 port 67
Oct  7 21:49:01 server dhclient: DHCPACK from 10.4.41.100

В положенное 2008/10/10 18:44:23 UTC начинается:

server:~# zcat /var/log/dhclient.log.1.gz | head -n 3
Oct 10 22:44:23 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67
Oct 10 22:44:28 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67
Oct 10 22:44:42 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67

И продолжается до наступления rebind:

server:~# cat /var/log/dhclient.log | grep -v 83.102.233.202
Oct 14 00:49:08 server dhclient: DHCPREQUEST on eth3 to 255.255.255.255 port 67
Oct 14 00:49:08 server dhclient: DHCPACK from 10.4.41.100

После вывода сообщений от dhclient в отдельный лог оно вроде бы не особо мешает, но вот это:

server:~# zcat /var/log/dhclient.log.1.gz | grep DHCPREQUEST | wc -l
8733
server:~# cat /var/log/dhclient.log | grep DHCPREQUEST | wc -l
10696

на нормальную ситуацию не очень похоже.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не получаем.

Давно создавал тему, описание там, конечно, не такое крутое)

dhcp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Не получаем.

Давно создавал тему, описание там, конечно, не такое крутое)

dhcp

Есть такая фишка...

В положенное 2008/10/10 18:44:23 UTC начинается:

server:~# zcat /var/log/dhclient.log.1.gz | head -n 3
Oct 10 22:44:23 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67
Oct 10 22:44:28 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67
Oct 10 22:44:42 server dhclient: DHCPREQUEST on eth3 to 83.102.233.202 port 67

Вот этот адрес - 83.102.233.202 - не находится в локальном сегменте. Вполне вероятно, что после поднятия VPN маршрут до него уходит в ppp0. Соответственно, сервер оказывается недоступен. Можно попробовать прописать маршрут до него.

 

Если не ошибаюсь, такой адрес приходит от DCHP сервера в качестве адреса "к кому обращаться по всем вопросам". Не уверен, то ли это очередное нарушение стандарта, то ли просто такая кривизна конфигурации DHCP серверов, сделать поддержку которой до сих пор не приходило в голову ни одному из разработчиков DHCP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Вот этот адрес - 83.102.233.202 - не находится в локальном сегменте. Вполне вероятно, что после поднятия VPN маршрут до него уходит в ppp0. Соответственно, сервер оказывается недоступен. Можно попробовать прописать маршрут до него.

Да, трассировка идет через vpn. Попробую добавить маршрут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А похоже у виндуза точно такая же проблема, просто ее не видно, хотя ждать три дня чтобы проверить я не буду ;)

Но адрес DHCP сервера тот же, 83.102.233.202, и на renew ответа тоже нет

C:\>ipconfig /renew
Настройка протокола IP для Windows
Произошла ошибка при обновлении интерфейса "Подключение по локальной сети": нево
зможно связаться  с DHCP сервером. Запрос спрошен по таймауту.

И в эвентлоге

Компьютеру не удалось обновить адрес, полученный от DHCP-cервера, для сетевого адаптера с сетевым адресом 0015F2383C12. Произошла следующая ошибка: 
Превышен таймаут семафора. . Компьютер продолжит попытки получить свой собственный адрес от DHCP-cервера.

Зато ipconfig /release & ipconfig /renew обрабатывается вполне корректно.

 

Если не ошибаюсь, такой адрес приходит от DCHP сервера в качестве адреса "к кому обращаться по всем вопросам". Не уверен, то ли это очередное нарушение стандарта, то ли просто такая кривизна конфигурации DHCP серверов, сделать поддержку которой до сих пор не приходило в голову ни одному из разработчиков DHCP.

Вообще похоже это и есть настоящий адрес сервера, судя по поиску DHCPACK приходит от разных IP и они скорее всего DHCP Relay.

Роутинг к 83.102.233.202 заворачивал себе в eth3, не помогало, и виндуз сейчас проверял без подключения к vpn.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
А похоже у виндуза точно такая же проблема, просто ее не видно, хотя ждать три дня чтобы проверить я не буду :angry:

:angry:

Вообще похоже это и есть настоящий адрес сервера, судя по поиску DHCPACK приходит от разных IP и они скорее всего DHCP Relay.

Роутинг к 83.102.233.202 заворачивал себе в eth3, не помогало, и виндуз сейчас проверял без подключения к vpn.

Надо повнимательнее почитать стандарт - может и вправду надо отправлять запрос на 83.102.233.202 через этот самый Relay, а не гэйтвэй?

В любом случае смысл такой конфигурации мне не понятен...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Надо повнимательнее почитать стандарт - может и вправду надо отправлять запрос на 83.102.233.202 через этот самый Relay, а не гэйтвэй?

В любом случае смысл такой конфигурации мне не понятен...

 

Ну вообще в теории оно вроде бы работает, например:

Oct 14 21:41:41 gwrkvm dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Oct 14 21:41:41 gwrkvm dhclient: DHCPACK from 10.132.7.254
Oct 14 21:41:42 gwrkvm NET[4600]: /sbin/dhclient-script : updated /etc/resolv.conf
Oct 14 21:41:42 gwrkvm dhclient: bound to 10.132.6.3 -- renewal in 116 seconds.
Oct 14 21:45:07 gwrkvm dhclient: DHCPREQUEST on eth0 to 10.132.15.250 port 67
Oct 14 21:45:07 gwrkvm dhclient: DHCPACK from 10.132.15.250
Oct 14 21:45:07 gwrkvm dhclient: bound to 10.132.6.3 -- renewal in 127 seconds.

10.132.7.254 это cisco у которой правда ip dhcp relay information trust-all :rolleyes: , а 10.132.15.250 w2k3 dhcp server.

 

Через релей запрос должен направлять уже роутер, в виндузе например нельзя написать route add 83.102.233.202 mask 255.255.255.255 10.4.41.100, шлюз должен быть в той же сети, а тот кто отвечает DHCPACK находится сразу за шлюзом:

server:~# traceroute 10.4.41.100
traceroute to 10.4.41.100 (10.4.41.100), 30 hops max, 40 byte packets
1  10.237.16.1 (10.237.16.1)  0.977 ms  2.306 ms  8.186 ms
2  10.4.41.100 (10.4.41.100)  2.044 ms  3.701 ms  5.551 ms

Так что похоже на стороне клиента настраивать особо нечего, можно правда пытаться менять renew и rebind time с дефолтных значений в 0.5 и 0.85 от времени аренды, но в dhclient.conf эти параметры зачем-то задаются простой датой и как это автоматизировать не очень понятно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Ну вообще в теории оно вроде бы работает, например:

Oct 14 21:41:41 gwrkvm dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Oct 14 21:41:41 gwrkvm dhclient: DHCPACK from 10.132.7.254
Oct 14 21:41:42 gwrkvm NET[4600]: /sbin/dhclient-script : updated /etc/resolv.conf
Oct 14 21:41:42 gwrkvm dhclient: bound to 10.132.6.3 -- renewal in 116 seconds.
Oct 14 21:45:07 gwrkvm dhclient: DHCPREQUEST on eth0 to 10.132.15.250 port 67
Oct 14 21:45:07 gwrkvm dhclient: DHCPACK from 10.132.15.250
Oct 14 21:45:07 gwrkvm dhclient: bound to 10.132.6.3 -- renewal in 127 seconds.

10.132.7.254 это cisco у которой правда ip dhcp relay information trust-all :) , а 10.132.15.250 w2k3 dhcp server.

Это, видимо, не в Корбине?

По стандарту действительно должен быть бродкаст, хотя допускается и юникаст, если клиент уже знает адрес DHCP сервера.

Через релей запрос должен направлять уже роутер,

Не совсем так - на стадии DHCP-переговоров никаких роутеров нет - есть релей-агенты, которые ловят бродкаст и переправляют его серверу (и обратно). Именно поэтому все клиентские запросы должны бродкаститься.

 

DHCPREQUEST(RENEW) имеет несколько специфичный статус: клиент помнит адрес сервера, и если сервер сидит в той же сети, вполне может обратиться напрямую к серверу (явного условия "той же сети" я в стандарте не видел - возможно, читал не слишком внимательно, но возможно, что его просто не предусмотрели).

а тот кто отвечает DHCPACK находится сразу за шлюзом:

server:~# traceroute 10.4.41.100
traceroute to 10.4.41.100 (10.4.41.100), 30 hops max, 40 byte packets
1  10.237.16.1 (10.237.16.1)  0.977 ms  2.306 ms  8.186 ms
2  10.4.41.100 (10.4.41.100)  2.044 ms  3.701 ms  5.551 ms

Позволю себе усомниться - я с утра провел эксперимент с "dhcpcd -n". Результат первый: у меня (SuSE 10.2) все работает!

Результат второй: tcpdump говорит, что клиент посылает DEHCPREQUEST на IP сервера (83.102.233.202) с мак-адресом, которого в арп-кэше нет! Вероятно, это мак того самого релея, который он запомнил когда-то. Если предположить, что релей сидит в том же сегменте, то это объясняет, почему все работает. Хотя я бы назвал такое поведение клиента несколько извращенным :o

Так что похоже на стороне клиента настраивать особо нечего, можно правда пытаться менять renew и rebind time с дефолтных значений в 0.5 и 0.85 от времени аренды, но в dhclient.conf эти параметры зачем-то задаются простой датой и как это автоматизировать не очень понятно.

Кстати, а сколько он тебе выдает время аренды? Мне Корбина выдает адрес на неделю (604800сек). Может, твой клиент дает серверу основания усомниться в его дееспособности? :P

И любопытно было бы взглянуть tcpdump'ом, что твой клиент посылает/получает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Это, видимо, не в Корбине?

Да, на работе проверил на виртуальном CentOS, но проверил неправильно, вся проблема похоже всетаки в том что при новом адресе идет бродкаст, а при renew запрос идет на конкретный адрес. Позже работу попробую доломать до аналогичного с корбиной состояния, чтобы можно было посмотреть что происходит с двух сторон.

 

Не совсем так - на стадии DHCP-переговоров никаких роутеров нет - есть релей-агенты, которые ловят бродкаст и переправляют его серверу (и обратно). Именно поэтому все клиентские запросы должны бродкаститься.

В корбине получается что бродкаст локального сегмента через шлюз локального сегмента идет дальше на то, что отвечает как DHCP Relay, если бы вместо 10.4.41.100 мне бы отвечал 10.237.16.1 проблем бы не было.

 

Кстати, а сколько он тебе выдает время аренды? Мне Корбина выдает адрес на неделю (604800сек). Может, твой клиент дает серверу основания усомниться в его дееспособности? :angry:

И любопытно было бы взглянуть tcpdump'ом, что твой клиент посылает/получает.

Oct 14 00:49:08 server dhclient: DHCPACK from 10.4.41.100 - MSD, expire 1 2008/10/20 20:49:08 - UTC, тоже неделя.

Завтра вечером у меня должен состояться очередной renew, попробую посмотреть куда же он шлет свой DHCPREQUEST, потом уже можно будет начинать новую сессию. На работе, когда dhcp relay и default gateway это одно и тоже, запрос идет на мак виланового интерфеса циски в котором находится станция и дальше успешно доходит до сервера который прописан первым в ip helper-address.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В корбине получается что бродкаст локального сегмента через шлюз локального сегмента идет дальше на то, что отвечает как DHCP Relay, если бы вместо 10.4.41.100 мне бы отвечал 10.237.16.1 проблем бы не было.

Похоже, что релей все-таки сидит в локальном сегменте, хоть и косит под 10.4.41.100. Иначе до него нельзя было бы достучаться по мак-адресу.

Oct 14 00:49:08 server dhclient: DHCPACK from 10.4.41.100 - MSD, expire 1 2008/10/20 20:49:08 - UTC, тоже неделя.

Завтра вечером у меня должен состояться очередной renew, попробую посмотреть куда же он шлет свой DHCPREQUEST, потом уже можно будет начинать новую сессию.

Можно форсировать процесс командой "dhcpcd -n" (либо "kill -ALRM ..."). Это проще, чем сидеть и ждать с включенным tcpdump-ом :angry:

На работе, когда dhcp relay и default gateway это одно и тоже, запрос идет на мак виланового интерфеса циски в котором находится станция и дальше успешно доходит до сервера который прописан первым в ip helper-address.

Если я скажу, что запрос идет на мак-адрес релея, это тоже не будет противоречить твоим наблюдениям. А IP какой? Сервера?

 

Абсолютно легальных способов два: либо бродкаст (мак и IP), либо (но только если сервер в локальной сети!) юникаст на сервера (мак и IP). Посылать на мак релея с IP адресом сервера мне видится неестественным... А если еще и этот мак (релея) невозможно получить легальным путем, а только запомнить...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Можно форсировать процесс командой "dhcpcd -n" (либо "kill -ALRM ..."). Это проще, чем сидеть и ждать с включенным tcpdump-ом :lol:

у меня dhclient, он так вроде бы не умеет, а в dhcpcd это действительно renew или release&renew?

 

Если я скажу, что запрос идет на мак-адрес релея, это тоже не будет противоречить твоим наблюдениям. А IP какой? Сервера?

вообще у tcpdump вся информация в данных, ее в хексе тяжело разбирать, а по заголовкам

23:04:49.005369 00:0c:29:8b:ef:7d > 00:1a:e2:9b:19:c2, ethertype IPv4 (0x0800),
length 342: 10.132.6.3.bootpc > 10.132.15.250.bootps: BOOTP/DHCP, Request from 00:0c:29:8b:ef:7d, length: 300

23:05:32.011478 00:0c:29:8b:ef:7d > 00:1a:e2:9b:19:c2, ethertype IPv4 (0x0800),
length 342: 10.132.6.3.bootpc > 10.132.15.250.bootps: BOOTP/DHCP, Request from 00:0c:29:8b:ef:7d, length: 300

первое запрос IP, второе renew.

00:0c:29:8b:ef:7d - клиент

00:1a:e2:9b:19:c2 - default gw&dhcp relay

10.132.6.3 - арендованый адрес

10.132.15.250 - адрес сервера

dhcpdump показывает разные запросы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
у меня dhclient, он так вроде бы не умеет,

Только сейчас узнал, что мой dhcpcd имеет другое поисхождение, нежели я предполагал :)

а в dhcpcd это действительно renew или release&renew?

По стандарту DHCPRELEASE посылается не на shutdown, а только, если ты собираешься забрать клиента из данной сети надолго или навсегда. Так что release&renew смысла не имеет по определению. А DHCPREQUEST по случаю загрузки или окончания времени аренды ничем не должны отличаться.

вообще у tcpdump вся информация в данных, ее в хексе тяжело разбирать, а по заголовкам

23:04:49.005369 00:0c:29:8b:ef:7d > 00:1a:e2:9b:19:c2, ethertype IPv4 (0x0800),
length 342: 10.132.6.3.bootpc > 10.132.15.250.bootps: BOOTP/DHCP, Request from 00:0c:29:8b:ef:7d, length: 300

23:05:32.011478 00:0c:29:8b:ef:7d > 00:1a:e2:9b:19:c2, ethertype IPv4 (0x0800),
length 342: 10.132.6.3.bootpc > 10.132.15.250.bootps: BOOTP/DHCP, Request from 00:0c:29:8b:ef:7d, length: 300

Не уловил разницы... Вообще, "tcpdump -vv -xx" вполне адекватен.

первое запрос IP, второе renew.

00:0c:29:8b:ef:7d - клиент

00:1a:e2:9b:19:c2 - default gw&dhcp relay

10.132.6.3 - арендованый адрес

10.132.15.250 - адрес сервера

dhcpdump показывает разные запросы.

Пока он не получил DHCPACK, он не должен ставить сорс-адрес. И DHCPREQUEST на DHCPOFFER должен идти бродкастом.

Но выглядит это так, как будто он по-простому шлет серверу (которого он помнит) по правилам уже сконфигурированной сети (т.е. через известный системе гэйтвэй), хотя и допускаю, что он сам туда подставил мак известного ему релея.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
По стандарту DHCPRELEASE посылается не на shutdown, а только, если ты собираешься забрать клиента из данной сети надолго или навсегда. Так что release&renew смысла не имеет по определению. А DHCPREQUEST по случаю загрузки или окончания времени аренды ничем не должны отличаться.

Некорректно выразился, имел ввиду получение адреса и продление аренды при renew.

 

Пока он не получил DHCPACK, он не должен ставить сорс-адрес. И DHCPREQUEST на DHCPOFFER должен идти бродкастом.

Но выглядит это так, как будто он по-простому шлет серверу (которого он помнит) по правилам уже сконфигурированной сети (т.е. через известный системе гэйтвэй), хотя и допускаю, что он сам туда подставил мак известного ему релея.

 

Не корбина :mellow:

Клиент 10.132.50.1 00:0c:29:8b:ef:7d

Default GW 10.132.50.243 00:07:0E:4D:B4:7F

DHCP Relay 10.32.50.254 00:1A:E2:9B:19:C5

DHCP Server 10.132.15.250 00:04:23:DF:2C:91

 TIME: 10:33:01.834197
   IP: > (00:0c:29:8b:ef:7d) >  (Broadcast)
   OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 0
  XID: 289ba82c
 SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:0c:29:8b:ef:7d:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
OPTION:  54 (  4) Server identifier         10.132.15.250
OPTION:  50 (  4) Request IP address        10.132.50.1
---------------------------------------------------------------------------
10:33:01.834197 00:0c:29:8b:ef:7d > Broadcast, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl  16, id 0, 
offset 0, flags [none], proto: UDP (17), length: 328) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, 
Request from 00:0c:29:8b:ef:7d, length: 300, xid:0x289ba82c, flags: [none] (0x0000)
         Client Ethernet Address: 00:0c:29:8b:ef:7d [|bootp]
       0x0000:  4510 0148 0000 0000 1011 a996 0000 0000
       0x0010:  ffff ffff 0044 0043 0134 107d 0101 0600
       0x0020:  289b a82c 0000 0000 0000 0000 0000 0000
       0x0030:  0000 0000 0000 0000 000c 298b ef7d 0000
       0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
       0x0050:  0000


 TIME: 10:33:01.839054
   IP: > (00:1a:e2:9b:19:c5) >  (00:0c:29:8b:ef:7d)
   OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 0
  XID: 289ba82c
 SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.132.50.1
SIADDR: 0.0.0.0
GIADDR: 10.132.50.254
CHADDR: 00:0c:29:8b:ef:7d:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
OPTION:  58 (  4) T1                        60 (60s)
OPTION:  59 (  4) T2                        105 (1m45s)
OPTION:  51 (  4) IP address leasetime      120 (2m)
OPTION:  54 (  4) Server identifier         10.132.15.250
OPTION:   1 (  4) Subnet mask               255.255.255.0
---------------------------------------------------------------------------
10:33:01.839054 00:1a:e2:9b:19:c5 > 00:0c:29:8b:ef:7d, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 45580, 
offset 0, flags [none], proto: UDP (17),length: 328) 10.132.50.254.bootps > 10.132.50.1.bootpc: BOOTP/DHCP, 
Reply, length: 300, xid:0x289ba82c, flags: [none] (0x0000)
         Your IP: 10.132.50.1
         Gateway IP: 10.132.50.254
         Client Ethernet Address: 00:0c:29:8b:ef:7d [|bootp]
       0x0000:  4500 0148 b20c 0000 ff11 8e91 0a84 32fe
       0x0010:  0a84 3201 0043 0044 0134 7433 0201 0600
       0x0020:  289b a82c 0000 0000 0000 0000 0a84 3201
       0x0030:  0000 0000 0a84 32fe 000c 298b ef7d 0000
       0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
       0x0050:  0000

 

Продление аренды при RENEW

 TIME: 10:50:16.015297
   IP: > (00:0c:29:8b:ef:7d) >  (00:07:0e:4d:b4:7f)
   OP: 1 (BOOTPREQUEST)
HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 0
  XID: d05f4d14
 SECS: 0
FLAGS: 0
CIADDR: 10.132.50.1
YIADDR: 0.0.0.0
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:0c:29:8b:ef:7d:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         3 (DHCPREQUEST)
---------------------------------------------------------------------------
10:50:16.015297 00:0c:29:8b:ef:7d > 00:07:0e:4d:b4:7f, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl  64, id 0, 
offset 0, flags [DF], proto: UDP (17), length: 328) 10.132.50.1.bootpc > 10.132.15.250.bootps: BOOTP/DHCP, 
Request from 00:0c:29:8b:ef:7d, length: 300, xid:0xd05f4d14, flags: [none] (0x0000)
         Client IP: 10.132.50.1
         Client Ethernet Address: 00:0c:29:8b:ef:7d [|bootp]
       0x0000:  4500 0148 0000 4000 4011 e2a2 0a84 3201
       0x0010:  0a84 0ffa 0044 0043 0134 3c07 0101 0600
       0x0020:  d05f 4d14 0000 0000 0a84 3201 0000 0000
       0x0030:  0000 0000 0000 0000 000c 298b ef7d 0000
       0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
       0x0050:  0000


 TIME: 10:50:16.017274
   IP: > (00:1a:e2:9b:19:c5) >  (00:0c:29:8b:ef:7d)
   OP: 2 (BOOTPREPLY)
HTYPE: 1 (Ethernet)
 HLEN: 6
 HOPS: 0
  XID: d05f4d14
 SECS: 0
FLAGS: 0
CIADDR: 0.0.0.0
YIADDR: 10.132.50.1
SIADDR: 0.0.0.0
GIADDR: 0.0.0.0
CHADDR: 00:0c:29:8b:ef:7d:00:00:00:00:00:00:00:00:00:00
SNAME: .
FNAME: .
OPTION:  53 (  1) DHCP message type         5 (DHCPACK)
OPTION:  58 (  4) T1                        60 (60s)
OPTION:  59 (  4) T2                        105 (1m45s)
OPTION:  51 (  4) IP address leasetime      120 (2m)
OPTION:  54 (  4) Server identifier         10.132.15.250
OPTION:   1 (  4) Subnet mask               255.255.255.0
---------------------------------------------------------------------------
10:50:16.017274 00:1a:e2:9b:19:c5 > 00:0c:29:8b:ef:7d, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 127, id 5880, 
offset 0, flags [none], proto: UDP (17), length: 328) 10.132.15.250.bootps > 10.132.50.1.bootpc: BOOTP/DHCP, 
Reply, length: 300, xid:0xd05f4d14, flags: [none] (0x0000)
         Your IP: 10.132.50.1
         Client Ethernet Address: 00:0c:29:8b:ef:7d [|bootp]
       0x0000:  4500 0148 16f8 0000 7f11 ccaa 0a84 0ffa
       0x0010:  0a84 3201 0043 0044 0134 880d 0201 0600
       0x0020:  d05f 4d14 0000 0000 0000 0000 0a84 3201
       0x0030:  0000 0000 0000 0000 000c 298b ef7d 0000
       0x0040:  0000 0000 0000 0000 0000 0000 0000 0000
       0x0050:  0000

 

Т.е. когда релей и шлюз в одной сети новый запрос идет бродкастом, ловится релеем и отвечает он же. При renew идет запрос к серверу на дефолтный шлюз, но отвечает все-равно релей.

Как разместить релей в другой сети так, чтобы он выдавал правильные адреса, пока не знаю.

 

В общем примерно тоже самое в корбине выглядит так:

DHCPDISCOVER на 255.255.255.255

DHCPOFFER от 10.4.41.100 с маком которого действительно нет в кэше arp

DHCPREQUEST на 255.255.255.255 с указанием сервера 83.102.233.202 и желаемого IP

DHCPACK от 10.4.41.100 с тем же неизвестным маком

Шлюз по умолчанию 10.237.16.1 в процессе не принимает участия вообще.

 

Когда клиент входит в состояние RENEW, запрос DHCPREQUEST идет на 83.102.233.202 с указанием мака шлюза по умолчанию, что происходит дальше предположить трудно, но ответ не приходит.

 

После почти трех суток у клиента наступает REBIND, DHCPREQUEST идет на 255.255.255.255 и ловится 10.4.41.100, который в отличии от шлюза по умолчанию вроде бы вполне успешно общается с DHCP сервером 83.102.233.202.

 

Как это все работает понять мне пока что видимо не дано, т.к. если я в некорбинской сети например делаю каскадирование релеев, то DHCPOFFER и DHCPACK приходит от релея доступного по локальной сети источника запроса, и что еще более непонятно, если у меня на DHCP сервере будет отсутствовать зона для подсети первого релея, то сервер адрес не отдаст. Изобразить визуально примерно такое же можно, если завернуть на дефолтном шлюзе путь до DHCP сервера как-нибудь вокруг, и по пути отфильтровать UDP 67 и 68, но получение правильного адреса от релея из другой подсети это не объяснит.

 

Ну и если авторов сети все устраивает, локальных способов борьбы видится два:

1 - пассивный, syslog-ng может перенаправить всю эту кучу сообщений о DHCPREQUEST в отдельный протокол или вообще игнорировать, как похоже делает windows.

2 - активный, если dhcpcd по dhcpcd -n делает фактически REBIND, т.е. успешно запрашивает бродкастом новый адрес не освобождая старый, можно пробовать переходить на него и приближать время rebind’а например по факту большого количества DHCPREQUEST to 83.102.233.202, но оно того наверное не стоит если и так работает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

неужели с 08 года так и не поправили ситуацию???!!! каждые 30 секунд DHCPREQUEST в логе - это выбешивает!!! не хочется кидать в null все эти сообщения, не видится мне это правильным решением.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах