Перейти к содержимому
Калькуляторы

Странность в DHCP REQUEST (unicast)

Есть схемка

DIR-300 <-> DES3028<-> Foundgry BI(dhcp relay)<-->SE100(dchp proxy)<--->DHCP Server

 

Снифер подключен к DES3028 (иначе никак).

 

 

1) DIR-300 получает IP по DHCP, приходит время подлить лизу через прямой unicast к dhcp серверу (SE100).

2) Вижу как UNICAST-REQ пакет уходит с DES3028, вижу как он приходит в SE100, вижу его же в DHCP Server.

3) Вижу как DHCP Server отвечает UNICAST-ACK, вижу как SE100 отправляет ACK дальше, на DES3028 уже не вижу, как результат ACK не доходит до DIR-300

 

Аналогично с Windows DHCP или DIR-100 все ходит туда обратно как надо. Разницу заметил только в одном DIR-300 ставит DF (don't fragment) на UNICAST-REQUEST.

 

думал сначала что пакет где-то дропается из-за флага DF на пути между SE100 и DES3028, но ping _ip_ df size 1470 полетает нормально. Да и SE100 DHCP-ACK не метит в DF.

 

Вообщем мистика. К сожалению заснифать трафик между SE100 и Foundry нет возможности :(

Изменено пользователем shicoy

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


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

Запускаете дебаг на той железке, где дропается DHCPACK и смотрите причину.

Мне известно 2 нетривиальных случая(отсутсвие команды dhcp trust считаю тривиальным) когда железка со включенным snooping иои relay может дропнуть:

- udp checksum равно 0

- dhcp-сервер заполняет поля в "неправильном" порядке или не заполняет какое-то поле

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


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

где дебаг? на DES3028? А он там есть? на Foundry кроме прокидывания vlan ничего нет.

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


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

ой пардон, просто столько вариаций тестил.

но на фаундри тоже нет дебага dhcp

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


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

вы можете попробовать посмотреть со стороны SmartEdge:

 

1. Создаёте ACL с требуемыми вами параметрами

 

context local
!
ip access-list capture
 seq 10 permit udp any host 100.1.100.1
!
! ** End Context **
!
end

2. Смотрите пакеты:

 

[local]Ericsson#debug packet circuit 13/1 out ip acl capture
[local]Ericsson#e12422f3/0000332879/304200000:13/EPPA/EU00: 13/1:511:63:31/1/1/8
debug packet 0/0 timestamp 332881.691804940 length 84/84 eu 12
ETH     DST_MAC 00:30:88:03:CA:FA SRC_MAC 00:30:88:01:AC:F5 ETHER_TYPE ipv4(0800)
IP      VER  4 HDR_LEN 20 LEN    70 ID 53822 FRAG_OFFS    0 TTL  64 PROTO udp
       CHKSUM 1797 SRC 100.1.100.14 DST 100.1.100.1
UDP     SRC_PORT   646 DST_PORT   646 LEN    50 CHK_SUM 8C18
DATA    00 01 00 26 64 01 64 0E 00 00 01 00 00 1C 00 00 
       AF 55 04 00 00 04 00 00 C0 00 04 01 00 04 64 01 
       64 0E 04 02 00 04 51 97 7F F4 

Изменено пользователем shefys

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


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

Посмотрите пакет от DIR-300. Видимо там стоит флаг BROADCAST (в unicast запросе).

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


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

Убедитесь что ответ от сервера умещается в MTU и его не нужно фрагементировать, в идеале полностью пакет (с IP заголовкми) меньше 578 байт.

 

 

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


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

Посмотрите пакет от DIR-300. Видимо там стоит флаг BROADCAST (в unicast запросе).

Да действительно DIR-300 выставляет флаг broadcast на unicastовый пакет к DHCP. Сервер так же отвечает с broadcast флагом. Ну и видимо он где-то затем успешно дропается.

Собственно, не понятно что с этим делать. :(

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


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

Пришлось поправить код DHCP сервера, что бы на такие запросы отвечал всегда с bootp flag = unicast

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


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

Пришлось поправить код DHCP сервера, что бы на такие запросы отвечал всегда с bootp flag = unicast

DHCP сервер какой?

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


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

Пришлось поправить код DHCP сервера, что бы на такие запросы отвечал всегда с bootp flag = unicast

DHCP сервер какой?

Freeradius 2.1.xx-DHCP

 

Правда для меня так и осталось загадкой почему ACK дропался.

Изменено пользователем shicoy

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


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

Freeradius 2.1.xx-DHCP

 

Правда для меня так и осталось загадкой почему ACK дропался.

Не знаю как в freeradius'е, а в isc сделано так: если в запросе стоит флаг broadcast, то сервер посылает ответ броадкастом. Естественно что такой ответ через релеи не пойдет.

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


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

Аналогично.

Хотя честно не думал, что relay смотрит на содержимое всех bootp-пакетов, а не только широковещательных и/или уникастовых на IP релея.

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


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

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

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


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

Ну вот почему-то релеить последние не хотели, ни фаундри, ни длинки.

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


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

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

Ошибка в коде клиента - он посылает unicast запрос на dhcp сервер минуя релеи с установленным флагом BROADCAST. В таком варианте ACK не дойдёт до устройства, запросившего адрес.

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


Ссылка на сообщение
Поделиться на других сайтах
Ошибка в коде клиента - он посылает unicast запрос на dhcp сервер минуя релеи с установленным флагом BROADCAST. В таком варианте ACK не дойдёт до устройства, запросившего адрес.

 

Нет!!!

 

Клиент про релеи ничего не знает и знать не может, и не должен. У меня была такая проблема когда клиент и дхцп сервер были в одном влане: релей агент не перехватывал пакет и не релеел его - в инструкции к этому (который был у меня) длинку про это было написано.

 

 

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


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

Нет!!!

Ключевое слово - клиент отправляет unicast запрос на нужный сервер, а не broadcast, с установленным флагом broadcast (в dhcp запросе).

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


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

Ключевое слово - клиент отправляет unicast запрос на нужный сервер, а не broadcast, с установленным флагом broadcast (в dhcp запросе).

И DHCP-сервер должен ответить релею так же юникастом, но с установленным флагом broadcast, а уже релей (самый крайний, смотрящий на клиента непосредственно) клиенту отвечает броадкастом. Таким образом у меня заработали "чумные" коробки

 

Но судя по симптомам у автора кто-то по пути броадкасты не пропускает и в этом проблема.

А если отвечать юникастом, то такие вот "чумные" клиенты юникаст не воспринимают и долбят запросами renew до окончания лизы, после чего посылают броадкастовый Rеquest и получают броадкастовый ответ (по стандарту так) потому и воспринимают его. Далее всё продолжается в цикле.

 

1) Discover broadcast, ответ Offer broadcast

2) Rеquest broadcast, ответ Ack broadcast

 

3) Renew unicast, ответ unicast не воспринимает

3.1) Renew unicast, ответ unicast не воспринимает

3.2) Renew unicast, ответ unicast не воспринимает

...

3.x) Renew unicast, ответ unicast не воспринимает

 

Перед самым окончанием аренды клиент полагает что сервер "умер" (поскольку юникастовые ответы не воспринимает сам) и пытается получить тот же IP от любого откликнувшегося DHCP-сервера

4) Rеquest broadcast, получает ответ Ack broadcast

далее общение продолжается по циклу 3 + 4 пункт

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


Ссылка на сообщение
Поделиться на других сайтах
Ключевое слово - клиент отправляет unicast запрос на нужный сервер, а не broadcast, с установленным флагом broadcast (в dhcp запросе).

 

У меня на стенде любой запрос не мог никак дойти до сервера минуя релей агента. И релей агенты и юникастные запросы точно также пересылали серверу и обратно. А сам сервер (фрирадиус, потом на перле) в принципе не мог получить/отправить ничего броадкастом.

 

Кроме того, есть момент когда делается юникаст на мак клиента, но IP клиента 0.0.0.0 - это момент до получения клиентом адреса - за это у меня тоже отвечали релей агенты.

 

Был момент когда казалось что релейагент не работает, но чтение мануала всё прояснило: клиент и сервер должны быть в разных вланах, тогда релей агент отрабатывает всегда. Остальные тонкости уже не помню. :(

 

 

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


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

Но суть проблемы в том, что есть кривые клиенты dhcp, есть кривые релеи (DLINK например) и черт знает как со всем этим жить. Особенно если выдавать короткие лизы.

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


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

option dhcp-server-identifier ip-address;

Вроде как это заставляет ёблинк слать без броадкаста.

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


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

option dhcp-server-identifier ip-address;

Вроде как это заставляет ёблинк слать без броадкаста.

Это есть, но не всегда помогает, да и клиенты dhcp бывают такие что ух.... чаще от тогоже Б.ялинка

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


Ссылка на сообщение
Поделиться на других сайтах
Это есть, но не всегда помогает, да и клиенты dhcp бывают такие что ух.... чаще от тогоже Б.ялинка

Бывают, особенно SOHO роутеры с дефолтными прошивками. После обновления лечится почти у всех.Совсем кривые в вендор ид вставляют своё название и версию, не спрашивают класслессроутес.

 

 

 

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


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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас