Relay + Snooping + Option 82

[xcme]

Проверил, результат отправил письмом. Такое ощущение, что ничего не поменялось особо. Ответ от сервера есть, но коммутатор его не распознает.
Если же внутрь влана, где включен релей, добавить интерфейс, то все ок. Но нужно то как раз обратное.

[xcme]

Что-то связь по этому вопросу потеряна. Ну это понятно, конец лета, отпуска и т.п.
Предлагаю вернуться к теме. В почту Дмитрию отправил вопросы в конце сентября. Там же и контакты для онлайн-переписки.

Продублирую вопрос тут:

...
Я просмотрел RFC3406, там сказано:
Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response.

If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation.

При этом:
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

То есть, как я понимаю, отправка опции 82 в ответе сервера является _рекомендуемым_ поведением, но не обязательным требованием.

Как я понимаю, по опции 82, вернувшейся коммутатору, коммутатор понимает, что пакет предназначен именно ему, так? То есть для чего она вообще там нужна? Если как раз для этого, то почему бы не считать пакет "своим", если он поступил на IP-адрес, который имеется у данного коммутатора?

Напомню, что в этом вопросе мы остановились на том, что в ответе сервера якобы нужна опция 82 "обратно". В этом случае Eltex должен корректно распознать пакет и выдать адрес. Мой комментарий выше о том, что это поведение не стандартно и его нельзя ожидать от всех серверов.

[Vans]

И еще вопрос про исходный широковещательный DHCP-запрос от клиента.
Я так понимаю, эта проблема в появившейся сегодня 1.1.42 не решена?

[Александр Селезнев]

вопрос про исходный широковещательный DHCP-запрос от клиента

Этот баг стоит в планах на исправление в .44 версии

[Vans]

А когда ожидать то? Он все критичнее и критичнее для нас....

[Александр Селезнев]

Vans, мы об этой проблеме знаем. Постараемся, чтобы к следующему релизу она была решена

[xcme]

Прошел месяц, апну тему. Что изменилось по последним двум вопросам?:
1. DHCP Relay БЕЗ опции 82 в пакете ОТ сервера.
2. Подавление оригинальных DHCP-пакетов после релея.

[Евгений Т]

1. Как и говорили вам изначально, особенностью реализации запрошенной вами фичи заключается в том, что в ответе от сервера обязательно должна присутствовать опция 82. В противном следует использовать настройку релея с ip адресом на клиентском интерфейсе.
2. Ориентировочный срок выхода релиза с данной правкой- первая половина декабря. Можем выслать версию на тест при надобности уже сейчас, если в ЛС напишите свою почту.

[Vans]

Мы, кстати, протестировали. Вроде работает подавление оригинального запроса, но при возврате на старую прошивку, чтоб вновь подтвердить проблему, подтвердить ее уже не получилось. Вот сидим курим бамбук и думаем, что сделали не так...

[xcme]

1. Как и говорили вам изначально, особенностью реализации запрошенной вами фичи заключается в том, что в ответе от сервера обязательно должна присутствовать опция 82. В противном следует использовать настройку релея с ip адресом на клиентском интерфейсе.

Верно, но потом вроде как намекнули, что это поведение может быть пересмотрено. Опция 82, идущая от сервера, это рекомендуемое поведение сервера,а не обязательное. В случае использования коммутаторов Eltex это требование становится обязательным. К сожалению, мы не сможем адаптировать нашу сеть под использование Eltex, и не можем использовать релей через доп. интерфейс.

Скажите, это окончательное решение или поведение в будущем будет исправлено?

[Евгений Т]

К сожалению, мы не сможем адаптировать нашу сеть под использование Eltex, и не можем использовать релей через доп. интерфейс.

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

[xcme]

Какой dhcp сервер вы используете? Если isc-dhcp, то он должен вставлять опцию. Если сервер в составе биллинга, то в чем сложность обратиться к техподдержке биллинга, чтобы они доработали этот момент?

Мы используем FreeRADIUS. Доработать его можно, но это нежелательно, т.к. DHCP критичный сервис, а клиентов несколько десятков тысяч. Практика показывает, что разные клиенты по разному понимают ответы DHCP и предпринимают различные действия. Так, например, есть клиенты которые игнорируют lease time. Есть такие, которые игнорируют DHCP OFFER/ACK больше определенного размера. Windows и некоторые nix игнорируют приоритеты опций 3/33/121/249. Windows XP/Vista/7 по разному поведут себя при добавлении маршрута по умолчанию в опцию бесклассовых маршрутов. Я сейчас не помню, получает ли клиент опцию 82 в ответе (в случае, если сервер ее отправляет) или она срезается релей-агентом, но лишний раз трогать структуру пакета и потом разгадывать связанные с этим разнообразные загадки нет ни желания ни возможностей.

В двух предложениях поясню конкретно нашу ситуацию. В данный момент мы используем D-Link и все прекрасно работает без опции 82 в ответе, в том числе с новыми моделями, которые мы получаем на тест в первый раз. Коммутаторы Eltex мы рассматриваем в качестве альтернативы, на случай изменения цен, введения санкций и иного форс-мажора. То есть мы ищем способ безболезненно интегрировать ваши коммутаторы в нашу уже достаточно не маленькую сеть, а не наоборот. Если бы мы только строились или только переходили на IPoE то ваш вариант с переделыванием DHCP сервера, безусловно, не доставил бы сложностей.

Так что мы не настаиваем на изменении поведения, но, в любом случае, поведение "как у D-Link" упростило бы жизнь всем. Имхо.

[Евгений Т]

Я сейчас не помню, получает ли клиент опцию 82 в ответе (в случае, если сервер ее отправляет) или она срезается релей-агентом, но лишний раз трогать структуру пакета и потом разгадывать связанные с этим разнообразные загадки нет ни желания ни возможностей.

В том-то и дело, что опция 82 срезается dhcp релеем. Поэтому на клиенте добавление опции 82 в ответ от сервера никак не отразится.
Цитата из rfc

The Relay Agent Information option echoed by a server MUST be removed
by either the relay agent or the trusted downstream network element
which added it when forwarding a server-to-client response back to
the client.

Также вопрос по вашей конфигурации. Включен ли у вас dhcp snooping (если отключен, то возможно ли включить?).
Если dhcp snooping включен, то в сколько влан?