Relay + Snooping + Option 82

[gorbushka]

Наша база данных содержит ip адреса около 4х тысяч коммутаторов. Переделать всё можно, конечно, путём сбора и обработки маков коммутаторов, переделки процесса добавления и настройки коммутатора, обучением персонала и тп и тд, но мы пытаемся MES2124 адаптировать под сеть, а не сеть под MES2124
Возможно вы подумаете про флаг в прошивке, который бы мог регулировать поведение MES2124?

[Евгений Т]

Рассмотрим внесение подобных изменений.

[xcme]

Relay работает без снупинга, но поле remote id в текущей конфигурации не получится изменить по вышеописанным причинам.

Тогда может надо поправить инструкцию?
Сейчас там написано:

Для использования опции 82 на устройстве должна быть включена функция DHCP relay агента.

По факту же для использования опции 82 нужно включение DHCP Snooping.

Рассмотрим внесение подобных изменений.

Спасибо, пока протестируем модель с опцией 82 но без релея (релеить будем на маршрутизаторе) - так работает.

[xcme]

Рассмотрим внесение подобных изменений.

Можно сравнивать не RID, а Relay Agent IP Address из соответствующего поля в пакете с IP-адресом интерфейса, который этот пакет получил. Если они совпадают, то это "наш пакет", а не транзитный.
Правильнее, наверное, сравнивать по RID, но если для D-Link RID задается глобально, то у коммутатора Eltex его можно задать отдельно для каждого интерфейса, поэтому сравнивать придется уже с таблицей допустимых RID, что сложнее.
Ну это так, мысли вслух были.

[xcme]

Еще вариант - не делать никаких проверок вообще. Раз пакет пришел свичу, значит с ним и надо разбираться. Уникаст-запросы, как я понимаю, не релеятся, значит пройдут транзитом. А если пакет таки пришел, значит он и был отправлен именно этим коммутатором.

И тут же до кучи еще один вопрос: Если уникаст-пакеты не релеятся (а похоже, что так и есть), как тогда продляется аренда у клиента? Опция 82 все равно будет добавлена в пакет?

[Евгений Т]

Юникаст релеится. Опция 82 в Request подставляется.

[xcme]

Юникаст релеится. Опция 82 в Request подставляется.

Всегда релеится? Добавил IP адрес в VLAN абоненту - проблема с RID осталась. Отключил снупинг в абонентском VLAN и при RID=**10.99.192.13 адреса стали выдаваться, т.е. проблема, которую мы решаем, не распространяется на случаи, если IP есть в абонентском VLAN.

Дальше, комп получил адрес. Время аренды 60 секунд. Half-time, соответственно, 30. Выключаю абоненту порт и включаю. смотрю на пакеты и в лог.
Первая странность (есть и в других случаях) - любой пакет дублируется. Это видно в логе ниже - два запроса в одну секунду.
Вторая странность - первая пара запросов релеится, вторая - нет. Как видно, в первых двух запросах мы видим "via 10.137.154.254", а в последующих "via em1". Если посмотреть сам пакет, то в первых двух запросах GIADDR=10.137.154.254 и опция 82 ЕСТЬ, а в остальных GIADDR=0.0.0.0 и опции 82 НЕТ.

Mar 24 14:36:17 dhcp82cloud dhcpd: -------
Mar 24 14:36:17 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:36:17 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via 10.137.154.254
Mar 24 14:36:17 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via 10.137.154.254
Mar 24 14:36:17 dhcp82cloud dhcpd: -------
Mar 24 14:36:17 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:36:17 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via 10.137.154.254
Mar 24 14:36:17 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via 10.137.154.254

Mar 24 14:36:47 dhcp82cloud dhcpd: -------
Mar 24 14:36:47 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:36:47 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:36:47 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:36:47 dhcp82cloud dhcpd: -------
Mar 24 14:36:47 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:36:47 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:36:47 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1

Mar 24 14:37:17 dhcp82cloud dhcpd: -------
Mar 24 14:37:17 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:37:18 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:37:18 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:37:18 dhcp82cloud dhcpd: -------
Mar 24 14:37:18 dhcp82cloud dhcpd: Lease for 10.137.154.8, Switch IP: 10.99.192.13, Switch port: 1
Mar 24 14:37:18 dhcp82cloud dhcpd: DHCPREQUEST for 10.137.154.8 from 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1
Mar 24 14:37:18 dhcp82cloud dhcpd: DHCPACK on 10.137.154.8 to 00:23:5a:ed:f8:88 (Hostname Unsuitable for Printing) via em1

[Евгений Т]

Всегда релеится? Добавил IP адрес в VLAN абоненту - проблема с RID осталась. Отключил снупинг в абонентском VLAN и при RID=**10.99.192.13 адреса стали выдаваться, т.е. проблема, которую мы решаем, не распространяется на случаи, если IP есть в абонентском VLAN.

Конфиги и дампы, снятые вайршарком с аплинка, до/после отправьте на почту.

Вторая странность - первая пара запросов релеится, вторая - нет.

Дамп отправьте на почту

[xcme]

Отправил. Судя по дампу имеем размножение DHCP пакетов и прохождение уникаст пакетов без релея.

[xcme]

Получили письмо?

[Евгений Т]

Из дампа видно, что юникаст релеится. Единственный спорный момент - пропуск броадкастовых оригинальных запросов (т.е. по факту отправка броадкастового запроса в влане клиента и срелеенного в влане сервера). Этот вопрос мы изучим и и в случае подтверждения некорректного поведения исправим.

8. Уникастовый REQUEST без опции 82 на продление аренды.

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

[Vans]

Из дампа видно, что юникаст релеится. Единственный спорный момент - пропуск броадкастовых оригинальных запросов (т.е. по факту отправка броадкастового запроса в влане клиента и срелеенного в влане сервера). Этот вопрос мы изучим и и в случае подтверждения некорректного поведения исправим.

Вот это как раз и надо исправить. Оригинальный запрос при включенном снупинге не релеится, а при выключенном релеится.

[xcme]

Евгений, есть продвижения по теме?

И меняли ли что-либо в отношении релея/снупинга в последних прошивках? Настраиваю так, как приведено в моей посте на 1-й странице, но опция 82 в пакете отсутствует.

Можете написать необходимые и достаточные настройки для получения опции 82 в пакете?

[Vans]

Из дампа видно, что юникаст релеится. Единственный спорный момент - пропуск броадкастовых оригинальных запросов (т.е. по факту отправка броадкастового запроса в влане клиента и срелеенного в влане сервера). Этот вопрос мы изучим и и в случае подтверждения некорректного поведения исправим.

Вот это как раз и надо исправить. Оригинальный запрос при включенном снупинге не релеится, а при выключенном релеится.

Таки запрос релеится всегда похоже и не понятно как избежать его повторной ретрансляции соседними коммутаторами, на которых настроен тот же клиентский влан с релеем.

Есть ли какие-то подвижки в этом направлении?

[Евгений Т]

Евгений, есть продвижения по теме?

И меняли ли что-либо в отношении релея/снупинга в последних прошивках? Настраиваю так, как приведено в моей посте на 1-й странице, но опция 82 в пакете отсутствует.

Можете написать необходимые и достаточные настройки для получения опции 82 в пакете?

Доработка с указанием свободного формата опции 82 реализована. Версия отправлена вам на почту.