Хочется следующее

3526 --(виланы)-- 3627 (DHCP relay) ---- DHCP сервер (192.168.1.1)
Есть 3526, каждый порт выделен в отдельный вилан.
Для теста выбрал себе один vlanid 18.

На 3627 виланы терминируются, для vlanid 18 есть интерфейс if18.
IP Interface : if18
VLAN Name : v18.20
Interface Admin state : Enabled
IPv4 Address : 172.18.254.254/16 (Manual) Primary
Proxy ARP : Disabled (Local : Disabled)
IP MTU : 1500

На порту 3627 к которому подключен DHCP сервер есть свой интерфейс
IP Interface : if23
VLAN Name : v23
Interface Admin state : Enabled
IPv4 Address : 192.168.1.254/24 (Manual) Primary
Proxy ARP : Disabled (Local : Disabled)
IP MTU : 1500

На 3627 настроен DHCP relay
DGS-3627G:5#show dhcp_relay
Command: show dhcp_relay

DHCP/Bootp Relay Status : Enabled
DHCP/Bootp Hops Count Limit : 4
DHCP/Bootp Relay Time Threshold : 0
DHCP Relay Agent Information Option 82 State : Enabled
DHCP Relay Agent Information Option 82 Check : Disabled
DHCP Relay Agent Information Option 82 Policy : Replace

Interface Server 1 Server 2 Server 3 Server 4
------------ --------------- --------------- --------------- ---------------
System 192.168.1.1
if18 192.168.1.1

С узла подключенноого на 3526 в порт соответствующий влану 18 пробую получить адрес, вижу такое (дамп с DHCP сервера)
tcpdump -i eth1 -n -vvv | grep 172.18.254.254
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
23:00:46.908503 IP (tos 0x0, ttl 128, id 41570, offset 0, flags [none], proto: UDP (17), length: 340) 172.18.254.254.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 00:0c:29:aa:81:df, length: 312, hops:1, xid:0x1f5db534, flags: [Broadcast] (0x8000)
Gateway IP: 172.18.254.254
23:00:47.212548 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 317) 192.168.1.1.67 > 172.18.254.254.68: BOOTP/DHCP, Reply, length: 289, hops:1, xid:0x1f5db534, flags: [Broadcast] (0x8000)
Gateway IP: 172.18.254.254
23:00:47.213322 IP (tos 0x0, ttl 30, id 0, offset 0, flags [none], proto: ICMP (1), length: 56) 172.18.254.254 > 192.168.1.1: ICMP 172.18.254.254 udp port 68 unreachable, length 36

Т.е. вижу что DISCOVER от клиента релеется на DHCP, тот отвечает, но ответ до клиента не доходит. На клиенте включаю снифер и вижу только как ушел DISCOVER. Непонятно...

на 3627
Boot PROM Version : Build 1.10-B09
Firmware Version : Build 2.40-B73

на 3526
Boot PROM Version : Build 5.00.009
Firmware Version : Build 5.01.B51

Попробуйте прошивки которые я Вам выслал. Также укажите настройки DHCP-сервера.

смена прошивки не помогла, 3627 упорно дает отлуп ответу с сервера DHCP.
Привести настройки DHCP не могу, ввиду того что он самописный, хочу чтобы данные про адреса брались из БД.
С другой стороны, мне на данном этапе неважно правильные ли данные отдает DHCP, важно что он их отдает и отдает на адрес релея (которым есть 3627). Почему же 3627 ведет себя так непонятно...

Укажите в личку Ваш телефон пожалуйста. Я думаю проблема не в свитче.

Потверждаю некоторые проблемы с DHCP когда 3627 relay.
имеем windows DHCP подключеный к 3627 ( впринцепе не важно ) от 3627 подключены 3526 - к которым уже подключены пользоватили и прочие железки , так вот с пользователями всё ОК а с железками не совсем.
А разница в пакетах отправляемых железками и подобными устройства , как помните существуют 2 типа DHCP запроса это BOOTP и DHCP.
DHCP пакет имеет флаг broadcast
BOOTP пакет имеет флаг unicast
других существеных изменений нет , так вот теже 3526 которые подключены к 3627 получают IP и параметры только в режиме BOOTP.
Соответсвенно и оборудование типа техже DIR100 или DWL2100 не могут получить IP автоматом в режиме DHCP , также и неможет получить IP сетевой тестер Net Runer и некоторые системы *nix.
До этого вместо 3627 стоял 3324SR и точки получали IP как надо.
Какие изменения притерпел 3627 . Т.е получаем что 3627 работает только с unicast пакетами в режиме dhcp relay ?
DGS-3627G Build 2.40-B55 ( также лежит 2.40-B75 но недумаю что будут изменения ).
Будут ли какиенибудь предположения или просто забить на некоторые железки и настраивать их всегда вручную .

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

А разве пакет DHCP Relay не является Unicast-ом?

Описанные настройки на коммутаторе правильные. На тестовом стенде проблема не подтвердилась. Проверяйте настройки DHCP сервера.

_________________
С уважением,
Бигаров Руслан.

сам Relay является а вот до него невсегда , вот тут и грабли ( посидел попробывал еще проанализировать).

DGS 3627 в качестве DHCP Relay
подопатный в виде dhcp клиента des 3526
запускаю в разных режимах.

режим DHCP


режим BOOTP


когда 3526 в BOOTP IP адрес и настройки получает , пакет до dhcp сервера доходит и возращается.
когда 3526 в DHCP нечего уже не получает , пакет до dhcp не доходит.
основные отличия пакето только в значении Flag: 0x8000 (32768) - Broadcast и Flag: 0x0000 (0) - Unicast.
Вывод: 3627 игнорирует пакеты DHCP с Flag: 0x8000 (32768) - Broadcast ( 3324SR вроде не игнорировал и пересылал их дальше как и BOOTP ).
Можно ли както исправить подобное ?

для стенда
DHCP Server <-----> port 1 DGS-3726(DHCP Relay) port 2 <----> port 26 DES-3526 порт 1 <----> port 26 DES-3526(DHCP Client)


DHCP server :


DGS 3627:


DES-3526


DES-3526(DHCP Client):

или

_________________
Люблю писать с ошибками.....
D-Link User: DGS-3627G, DGS-3324SR, DES-3526, DES-1024D, DES-1016D, DWL-2100AP, DEM-310GT,DEM-330, DCS-950.

вообще то это 2 немного разных пакета, они отличаются сообщением которое им высылается в конце, ЕМНИМС, его размер у bootp это 64 октета, а у dhcp где-то в 4 раза больше, ну и в отношении клиент-сервер они отличаются ...
источник

_________________
с уважением, БП

Такая же проблема - DHCP-сервер (на udp 67) получает от длинки (релея) DISCOVER (с udp 68), отправляет в ответ OFFER (с udp 67 на udp 68), но последний до клиента не доходит, вместо этого длинка шлет ICMP Port Unreachable (udp 68).

Кто-нибудь смог решить проблему?

Если кто-то еще с этим столкнется то проблема в следующем:

RADIUS-сервер, который выступал в качестве DHCP-сервера слал ответ на порт 68 длинка (т.е. на тот порт с которого пришел запрос), в то время как надо было слать на порт 67 не смотря ни на что.

В новой версии FreeRADIUS это учли, и проблема исчезла.