Jump to content
Калькуляторы

Странность в 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 нет возможности :(

Edited by shicoy

Share this post


Link to post
Share on other sites

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

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

- udp checksum равно 0

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

вы можете попробовать посмотреть со стороны 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 

Edited by shefys

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Freeradius 2.1.xx-DHCP

 

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

Edited by shicoy

Share this post


Link to post
Share on other sites

Freeradius 2.1.xx-DHCP

 

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

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

Share this post


Link to post
Share on other sites

Аналогично.

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

 

Нет!!!

 

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

 

 

Share this post


Link to post
Share on other sites

Нет!!!

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

Share this post


Link to post
Share on other sites

Ключевое слово - клиент отправляет 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 пункт

Share this post


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

 

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

 

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

option dhcp-server-identifier ip-address;

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

Share this post


Link to post
Share on other sites

option dhcp-server-identifier ip-address;

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

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

Share this post


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

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

 

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this