faq обучение настройка
Текущее время: Вс авг 03, 2025 00:55

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: Переход с 3526 на 3528
СообщениеДобавлено: Вт янв 17, 2012 01:21 
Не в сети

Зарегистрирован: Ср окт 13, 2004 14:22
Сообщений: 21
Откуда: Ухта
Приветствую!

В связи с тем, что 3526 больше не выпускается, приходится переходить на 3528. Возникло несколько вопросов при использовании dhcp relay + option 82 на новых свитчах. Пока настройки следующие:

Код:
enable dhcp_relay
config dhcp_relay hops 4 time 0
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check disable
config dhcp_relay option_82 policy replace
config dhcp_relay option_82 remote_id default
config dhcp_relay option_60 state disable
config dhcp_relay option_61 state disable
config dhcp_relay option_60 default mode drop
config dhcp_relay option_61 default drop
config dhcp_relay add vlanid 99 192.168.xx.xx


Здесь 99 - клиентский влан. Вопросы следующие:

1. Иногда попадаются выделенные VLAN для корп. клиентов - например, для объединения нескольких филиалов. Каким образом обеспечить правильное прохождение их внутренних корпоративных DHCP-запросов до своих серверов - в неприкосновенности - внутри таких вланов? В 3526 для этого требуется создавать acl на транковых и оконечных портах. Будет ли это работать 3528, и требуется ли вообще?

2. Будет ли вставляться option 82 в юникастовые запросы (dhcp-renew)?

3. При подключении нескольких свитчей по цепочке - не будут ли размножаться отрелеенные запросы в транковых портах?

4. Планируем со временем раздавать реальники по dhcp из динамического пула с открытым доступом в интернет, с защитой через IPMB. Однако требуется продолжение работы старых устройств. К сожалению, с доисторических времен в сети осталось множество роутеров, приставок, sip-адаптеров и телефонов и просто компов с установленными статическими серыми IP. Исправить их все на dhcp не представляется возможным - потребуется физический обход всех клиентов на предмет выявления наличия у них таких устройств.

Так как новый диапазон, который требуется защищать через IPMB, совершенно другой, проблему мог бы решить permit_ip_pool на 3526. Но на 3528 такой функции нет. Возможно ли решить проблему через ACL? Скажем, если задать permit для подсети 192.168.0.0/16 с profile id меньше чем у System - будет ли это работать? Если нет, что еще можно сделать, или ipmb нам не светит совсем?

Спасибо за ответы! Сейчас имеется только один тестовый 3528 и все это тщательно проверить не получается.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Переход с 3526 на 3528
СообщениеДобавлено: Вт янв 17, 2012 10:12 
Не в сети
Сотрудник D-LINK
Сотрудник D-LINK

Зарегистрирован: Ср май 10, 2006 16:40
Сообщений: 12251
Откуда: D-Link, Moscow
Цитата:
1. Иногда попадаются выделенные VLAN для корп. клиентов - например, для объединения нескольких филиалов. Каким образом обеспечить правильное прохождение их внутренних корпоративных DHCP-запросов до своих серверов - в неприкосновенности - внутри таких вланов? В 3526 для этого требуется создавать acl на транковых и оконечных портах. Будет ли это работать 3528, и требуется ли вообще?

Просто не включайте релей в этих виланах. Создание ACL не требуется.

Цитата:
2. Будет ли вставляться option 82 в юникастовые запросы (dhcp-renew)?

Да

Цитата:
3. При подключении нескольких свитчей по цепочке - не будут ли размножаться отрелеенные запросы в транковых портах?

Нет

Цитата:
4. Планируем со временем раздавать реальники по dhcp из динамического пула с открытым доступом в интернет, с защитой через IPMB. Однако требуется продолжение работы старых устройств. К сожалению, с доисторических времен в сети осталось множество роутеров, приставок, sip-адаптеров и телефонов и просто компов с установленными статическими серыми IP. Исправить их все на dhcp не представляется возможным - потребуется физический обход всех клиентов на предмет выявления наличия у них таких устройств.

Так как новый диапазон, который требуется защищать через IPMB, совершенно другой, проблему мог бы решить permit_ip_pool на 3526. Но на 3528 такой функции нет. Возможно ли решить проблему через ACL? Скажем, если задать permit для подсети 192.168.0.0/16 с profile id меньше чем у System - будет ли это работать? Если нет, что еще можно сделать, или ipmb нам не светит совсем?


А что мешает просто не включать IMPB на таких портах?


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Переход с 3526 на 3528
СообщениеДобавлено: Вт янв 17, 2012 11:08 
Не в сети

Зарегистрирован: Ср окт 13, 2004 14:22
Сообщений: 21
Откуда: Ухта
Alexandr Zaitsev писал(а):
Просто не включайте релей в этих виланах. Создание ACL не требуется.


Спасибо, просто на 3526 надо было еще и acl создавать.

Цитата:
Цитата:
Так как новый диапазон, который требуется защищать через IPMB, совершенно другой, проблему мог бы решить permit_ip_pool на 3526. Но на 3528 такой функции нет. Возможно ли решить проблему через ACL? Скажем, если задать permit для подсети 192.168.0.0/16 с profile id меньше чем у System - будет ли это работать? Если нет, что еще можно сделать, или ipmb нам не светит совсем?

А что мешает просто не включать IMPB на таких портах?


Мешать может только то, что хотелось бы запустить эту функцию на всей сети сразу. При желании пользоваться инетом без авторизации, пользователь проходит регистрацию на специальной страничке, у него на dhcp создается новая связка mac+port+switch, и начинает выдаваться реальник. При этом в его же порту могут быть подключены такая приставка или еще один абонент со старыми настройками. Если включить на нем impb то они перестанут работать.

Так возможно ли решить проблему через acl? Просто на всех свитчах разрешить пакеты с src ip 192.168.0.0/16 - было бы идеально.


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Переход с 3526 на 3528
СообщениеДобавлено: Вт янв 17, 2012 23:35 
Не в сети

Зарегистрирован: Ср окт 13, 2004 14:22
Сообщений: 21
Откуда: Ухта
Alexandr Zaitsev писал(а):
Цитата:
2. Будет ли вставляться option 82 в юникастовые запросы (dhcp-renew)?

Да


Только что провели тест - юникастовые запросы не релеятся. По схеме сейчас включено: dhcp -> router -> 3526 -> 3528 -> клиент

При первоначальном получении IP до dhcp-сервера доходит запрос со свитча 3528 (это видно по IP, с которого пришел запрос). Option 82 заполнен правильно. После того, как клиент получил адрес, начинают приходить запросы на продление аренды уже с 3526, с указанием его транкового порта в Option 82, что как бы неправильно.

Причем, если вместо 3528 подключить второй 3526, то все доходит корректно. В чем может быть дело? Вот необходимые настройки обоих свитчей, клиентский влан - 99, управление - 96:

3526, прошивка 6.20.B08:

Код:
enable dhcp_relay
disable dhcp_local_relay
config dhcp_relay hops 4 time 0
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check disable
config dhcp_relay option_82 policy replace                                     
config dhcp_relay option_82 remote_id default
config dhcp_relay option_60 state disable
config dhcp_relay option_60 default mode drop
config dhcp_relay option_61 state disable
config dhcp_relay option_61 default drop
config dhcp_relay add vlanid 99-100 192.168.6.11


3528, прошивка 2.80.B042:

Цитата:
disable dhcp_local_relay
enable dhcp_relay
config dhcp_relay hops 4 time 0
config dhcp_relay option_82 state enable
config dhcp_relay option_82 check disable
config dhcp_relay option_82 policy replace
config dhcp_relay option_82 remote_id default
config dhcp_relay option_60 state disable
config dhcp_relay option_61 state disable
config dhcp_relay option_60 default mode drop
config dhcp_relay option_61 default drop
config dhcp_relay add vlanid 99 192.168.6.11


Вернуться наверх
 Профиль  
 
 Заголовок сообщения: Re: Переход с 3526 на 3528
СообщениеДобавлено: Ср янв 18, 2012 15:22 
Не в сети

Зарегистрирован: Ср окт 13, 2004 14:22
Сообщений: 21
Откуда: Ухта
Alexandr Zaitsev писал(а):
Цитата:
2. Будет ли вставляться option 82 в юникастовые запросы (dhcp-renew)?

Да


Когда можно будет получить комментарий по этой неработающей функции (см сообщение выше)? Поставили коммутатор в тест на дом, понадеялись на ваш ответ, что юникастовые запросы будут релеится. В результате ничего не работает. Его снимать, или неправильные настройки у нас?


Вернуться наверх
 Профиль  
 
Показать сообщения за:  Сортировать по:  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 6


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
Русская поддержка phpBB