Элтекс

Пробую настроить.
А получается вот:


А запросов от тестового абонента нет. Что не так? Почему VLAN inactive ?

Здравствуйте, приведите, пожалуйста полную конфигурацию. Для корректной работы функции необходимо, чтобы на пользовательский VLAN был назначен IP-адрес.

str писал(а):Для корректной работы функции необходимо, чтобы на пользовательский VLAN был назначен IP-адрес.

Это ещё зачем. IP нынче на вес золота. Да и это же будет доп.нагрузка на проц в виде потока арп. Без выделения ip-адреса никак?

На текущий момент DHCP relay реализован таким образом, что подставляет этот IP-адрес в поле giaddr, для того чтобы DHCP-сервер на основании этого поля мог определить пул, из которого будет выдан IP-адрес. Выход версии, в которой DHCP-relay не требует настройки IP-адреса в абонентской VLAN запланирован ориентировочно на конец мая-начало июня.

обещанная версия вышла?

Здравствуйте, на текущий момент версия имеет статус релиз-кандидата (официально релизом станет 05.09), можем выслать для тестов.

str писал(а):можем выслать для тестов.

Скажите есть ли продвижения в направлении DHCP opt82 ?
Взяли на тест у коллег MES2124, исследуем. Но без четкой работы этой функции нам не удаётся его использовать в своей сети.

Кстати, было бы не плохо в выводе sh ver видеть платформу или модель и uptime.

Добрый день.
Версию можете скачать на нашем сайте в разделе Поддержка/Центр загрузки

Вопрос выше задал мой коллега, я продолжу мысль.
Судя по теме, возможность релеить запрос через management-интерфейс появилась всего полгода назад. Этот функционал уже отлажен и работает как надо?
Настраиваем так:


Запрос прилетает, отправляется OFFER и на этом все. Что и где надо подкрутить?

Евгений Т писал(а):Добрый день.
Версию можете скачать на нашем сайте в разделе Поддержка/Центр загрузки

Спасибо за ответ, но я специально выложил вывод #sh ver чтобы вы могли увидеть, что у меня такая же прошивка, как на сайте.

Это самое новое ПО? По прежнему без интерфейса в абонентской сети не работает dhcp relay?

xcme писал(а):Вопрос выше задал мой коллега, я продолжу мысль.
Судя по теме, возможность релеить запрос через management-интерфейс появилась всего полгода назад. Этот функционал уже отлажен и работает как надо?
Настраиваем так:

Код: Выделить всё

ip dhcp relay address 10.2.3.2
ip dhcp relay enable
ip dhcp information option
ip dhcp information option suboption-type custom
ip dhcp snooping
ip dhcp snooping vlan 3381

interface gigabitethernet 1/0/1
 switchport access vlan 3381
 ip dhcp information option format-type remote-id **10.99.192.13
exit

interface gigabitethernet 1/0/25
 ip dhcp snooping trust
 switchport mode trunk
 switchport trunk allowed vlan add 3,3381
exit
!
interface vlan 3
 ip address 10.99.192.13 255.255.255.0
exit
!
interface vlan 3381
 ip dhcp relay enable
exit


Запрос прилетает, отправляется OFFER и на этом все. Что и где надо подкрутить?

Отлажен и работает.
Отправьте мне на почту дамп вайршарка, снятый с аплинка коммутатора.
Также приложите вывод дебага
set ip dhcp trace all
(зайти в дебаг режим можно
console#debug
>debug
Enter DEBUG Password: debug)

Моя почта.
3200@eltex.org

отправил вам

Копирую объяснение из переписки в почте.
В текущей конфигурации настроен dhcp relay + snooping. DHCP discover, попадая на порт коммутатора, попадает первоначально под действие снупинга и ему добавляется опция 82 в формате custom. При это поле remote id перезаписывается
(**10.99.192.13 )
Затем коммутатор релеит запрос на сервер (при этом формат опции 82 сохраняется, т.к. стоит policy keep). Relay работает в режиме custom.
DHCP offer от сервера приходит на коммутатор и relay не понимает формат опции 82, т.к. поле remote id было изменено снупингом и коммутатор считает, что опция 82 не принадлежит ему. Поэтому пакет дропается.
Возможным решением является изменение конфиги dhcp сервера и выдача адреса не по наличию **10.99.192.13, а по маку коммутатора (по дефолту он передается в поле remote id).

Нам снупинг не нужен собственно, мы просто хотим использовать ip коммутатора в качестве remote-id на нашем DHCP-сервере. Звёздочки в поле (**10.99.192.13) нам пришлось вставить из-за отличия в два байта в пакетах с eltex и dlink.
вот пример как мы используем opt82 на dlink

Согласно вышеприложенным объяснениям dhcp relay ожидает в ответе от сервера в поле remote id опции 82 увидеть свой mac (а снупинг это поле подменил на **10.99.192.13). Из-за этого коммутатор считает, что опция принадлежит не ему.

спасибо
получается, что мы не можем использовать произвольный remote-id?
было бы здорово выключить снупинг, но без снупинга не работает relay, верно?

Relay работает без снупинга, но поле remote id в текущей конфигурации не получится изменить по вышеописанным причинам.
Возможно ли в вашей схеме заменить произвольный remote id на mac коммутатора (т.е. дефолтное значение в поле)?