потому что вес isc dhcp все таки выше чем netup dhcp

Рфц

да блин

там не понятно написано

вендоры говножелеза в сети по своему сделали

а они по своему

Может тебе, а кому-то понятно

но они не правы вот в чем

У нас с дарвином жунипер получилось доказать

И они пофиксили багу

В дхцп

запрос приходит от релея к ним юникастом, а они отвечают броадкастом

вот чо за пидоры?

они не хотят признать что они не правы

зачем отвечать на юникаст запрос броадкастом?

кстати а об этом поподробней

устройство получает адрес 2 раза: сначала загрузчик SoC, потом уже ядро Linux, в результате получаются запросы с разным client-id (кажется, опция 61), или где-то это поле отсутствовало даже, а релей почему-то с новым Client-ID не переправлял запросы на DHCP-сервер. По-моему, такое только со включенным снупингом наблюдалось

они сетуют на то, что там флаг броадкаст стоит

зачем отвечать на юникаст запрос броадкастом?

на какой? На DISCOVER обычно ответ OFFER отдаётся бродкастом

и я не могу ничо им доказаь. может надо больше рфц курить

но у них сервер отдельно от сети стоит

к нему прилетает запрос через релей или от клиента напрямую

Никто не хочет прогуляться?

там другая l2 подсеть

Чет я нажрался опять

зачем в нее отвечать броадкастом

Теряю нить разговора

а, с релеем есть варианты

сервер дхцп стоит в другом месте. ведь в этом смысл релея и есть

что можно пересылать дхцп пакеты куда угодно, хоть на марс

используя релей

а они тупо отвечают в тот же сегмент, где они броадкастом

что можно пересылать дхцп пакеты куда угодно, хоть на марс

Падем бухать

Мммммм

дда я уже, иначе бы тут не флудил так

😂😂😂

по скайпу не бухаю если чо

Я так и подумал

короче я не знаю, нетап уперся и все. странный у них подход

они даже не хотят пытаться разобраться в проблеме

а они тупо отвечают в тот же сегмент, где они броадкастом

Мож у них роута к релею нет

дык. там дефолт

а дефолт в роутер, который знает куда направлять

связность то есть, все норм

isc dhcp работает и все норм. обменивается с релеем

У тебя сервер не л2 конеектед к релею?

нет конечно

Почему конечно?)

ну потому что dhcp сервер в дц стоит, а релей на площадке

между ними вообще тоннель поднят

у меня просто нет сервера на площадке

а они тупо отвечают в тот же сегмент, где они броадкастом

If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff.

если giaddr есть, броадкастом сервер слать не должен релею, и броадкаст бит вообще ирелевантен

релей не выставлял поле giaddr?

об этом же подумал

выставил

ща

https://www.netmanias.com/en/post/techdocs/6000/dhcp-network-protocol/understanding-dhcp-relay-agents

С картинками

а все

не так там

юзеры начинают напрямую обращаться к серверу

а не должны?

и сервер на это отвечает броадкастом

хотя запрос юникаст

ну это их воля, они могут обращаться

но на такие запросы isc dhcp отвечает юникастом

а netup отвечает броадкастом

так relay ip address и your ip address пустые

да

это же giaddr и ciaddr

но это дхцп клиент так отвечает

чо я с ним сделать могу

там зоопарк говножелеза

не понял, это запрос от релея на DHCP-сервер уже?

нет!!

клиенты напрямую начинают ломиться

и это не зависит ни от чего

я раньше думал что проблема в том, что netup выставляет next server ip

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