Небольшая преамбула, чтобы объяснить для чего все это надо.
Пару месяцев уже используем в сети IMPB на DES-3200. Сеть неоднородная. Есть места, где все построено красиво, звездами с несколькими уровнями агрегации, на доступе - DES-3200. 3200 изначально идет на узел преднастроенным с включенным IMPB + DHCP Snooping. Абоненты изначально настраиваются на получение настроек автоматически. Никаких проблем нет.
Есть места, где все построено в лучших традициях "пионер-нетов", то есть абы как, лишь бы включить абонентов. Такие места перестраиваются, перестраиваются микрорайонами. В таких местах изначально абоненты работают через статические настройки. Как только микрорайон перестроен, нам нем вводят автоматическое получение настроек, и через какое-то время IMPB + DHCP Snooping. Через какое-то время для того, чтобы абоненты сами переходили на dhcp, и сам переход был плавным, и абоненты страдали как можно меньше. С вводом на свитче IMPB начинается головная боль на всех уровнях (абонент что-то не понял, что-то не так сделал, у него не работает DHCP клиент, стоит какая-то сборка Windows в которой сборщики что-то убрали и прочее, прочее). И проблема собственно в том, что пока абонент не сделает все правильно, работать у него ничего не будет. Сам абонент делать ничего не хочет пока доступ у него есть.

Чего хочется? Хочется, чтобы процесс перехода на IMPB + DHCP Snooping был плавным, а не резким: включили - и нет доступа.
У IMPB есть два режима работы - strict и loose. Хотелось бы, чтобы появился третий режим - learn. В котором коммутатор запоминал бы связки ip+mac, но не блокировал бы все остальное, что не удовлетворяет условию, а пропускал бы.
show address_binding blocked - в таком режиме показывал бы mac адреса для которых связки ip+mac на коммутаторе нет. То есть те mac адреса, которые были бы заблокированы в случае использования режимов strict и loose.
Таким образом можно было бы включать IMPB в режимах strict/loose тогда, когда большее количество абонентов уже точно работает через dhcp, и включение IMPB+DHCP Snooping будет в таком случае для них прозрачным.

С технической точки зрения трудностей больших вроде бы быть не должно, если представить, что IMPB - это ACL (а по сути так и есть), то в режимах strict/loose он будет deny, а в режиме learn - permit.

Категорически поддерживаю! И в DES-3028 тоже.

А кто мешает сначала задействовать ACL режим и прописать на DHCP сервере, чтобы клиент получал этот IP, если перешёл на динамический режим, а потом уже включать DHCP Snooping!?

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

Хочу прояснить один момент. Сначала делаем статическую связку ip+mac. Включаем dhcp snooping, после создания связки, абонент (при условии что он не получал настройки от dhcp сервера, а продолжает работать через статику) не будет заблокирован на свитче?

Вся суть в том, что без кнута в виде лишения доступа на dhcp переходит 1% от общего количества. Как только пропадает доступ - переходить начинают все, причем одновременно и через одного какая-то проблема. С таким количеством звонков, жалоб, заявок справится довольно проблематично. Решение вопросов затягивается, и имеем сплошной негатив со всех сторон.
Если бы можно было бы сделать так. Включили привязку, никого не блокируем, видим что два мака в blocked, значит еще через статику работают. Названиваем им, убеждаем, помогаем. В blocked никого нет - включаем IMPB+Snooping.

А Вы пробовали заранее предупредить клиентом письмом и выслать подробную пошаговую инструкцию что и как делать после перехода на новую систему безопасности сети!?

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

Для доступа к сети абоненту требуется запустить программу-авторизатор, в нем есть система сообщений. Абонент не может попасть в сеть, не запустив эту программу, запустив авторизатор, абонент не может не видеть сообщений. Это эффективнее любой почты, звонков и прочего. Мы не то, что предупреждаем, мы уже фактически спамим абонентом этими предупреждениями, инструкциями, настройками. Эффект очень и очень мал, не шевелятся.

Я не думаю, что если это реализовать, то клиенты зашевелятся. Только жёсткий переход поможет. Будет трудно и будут проблемы, но только на время перехода на новую систему.

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

Хорошо, зайдем к проблеме с другой стороны. Ранее функционал "режима learn" я просил в контексте ввода в эксплуатацию IMPB. Теперь прошу его в контексте эксплуатации IMPB.

Есть свитч 3200, включен IMPB + DHCP Snooping.
Свитч перегружается - все связки теряются. Пока абоненты не догадаются что им надо самим инициировать запрос настроек от dhcp сервера, они работать не будут.
Если бы был режим learn, процесс перезагрузки свитча для конечного потребителя услуг был бы прозрачным, ну или по крайней мере не таким болезненным.
А в условиях проблемной работы 3200 с ssh перезагружаются они особенно часто.
Если бы свитч запоминал динамические связки ipmb+mac, которые у него были до перезагрузки, это было бы решением проблемы.
Если бы свитч стартовал и какое-то время пропускал бы трафик и учил связки ip+mac, это тоже было бы решением проблемы.

Вообще-то когда коммутатор перезагружается, то соотственно физический линк к абоненту падает, когда линк появляется, идет запрос по DHCP, так что проблемы особо нет.
Если только конечно у вас между коммутатором и клиентом стоит какое-то активное оборудование которое этот линк поддерживает в up. Но это как-то не правильно.

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

медиаконвертор между свитчем доступа и абонентом?.. прикольно, конечно, но LLCF =)

а у вас что, нет статистики, когда и какой адрес получил абонент на DHCP-сервере? правильнее всего было бы смотреть именно на сервере, а не на свитче...

_________________
Это текст, который можно добавлять к размещаемым вами сообщениям. Длина его ограничена 255 символами.

Так не везде конечно, но такие места есть, и их не мало. Других вариантов последней мили там просто нет.


Все это есть, но включается IMPB где? На свитче. Вот и хотелось бы видеть, что вот сейчас, когда это будет включено, 100% абонент заработает и ничего не заметит, а не возьмет в руки телефон, и начнет наяривать в тех. поддержку.
Да и вопрос больше в эксплуатации, чем в переводе на IMPB. Перевод уж ладно, переведем как-то.

Зачем тиранить коммутатор ssh-ом!? Можно же использовать Management VLAN + telnet или SNMP.

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

Затем, что управление не всегда происходит с рабочих мест. и Управляющий влан для решения проблем приходится выкидывать туда, куда бы его лучше никогда не выкидывать, например, на сети других операторов.
И как-то у меня пару сотен 3028 живет с ssh и проблем не возникает.


Я, конечно, извиняюсь, но ситуация со свитчами Длинка напоминает ситуацию "висит груша - нельзя скушать". У нас есть свитчи, но если вы "не правильно" будете строить сети - они будут хабами в лучшем случае. У нас есть ssh server в свитчах, но пользоваться им не надо, для управления есть telnet и snmp. У нас есть ssl, но это тоже лучше не использовать, так как получите мегаудобное повышение прав в случае использования AAA через web-интерфейс. Или тут мне следует приготовится к совету о том, что web-интерфейс тоже лучше не использовать, так как есть cli? А до 131B005 его и не возможно было использовать, так как java-аплет просто крашился при попытки сохранения под линуксом. Или использование линукса тоже противоречит догмам Длинка?
Как-то это все это не совсем правильно, не находите?

Также хотелось бы услышать комментарии по теме в контексте эксплуатации IMPB на 3200.

Bigarov Ruslan, когда на серии 3200 будет вменяемый биндинг, аналогичный новому на 3028? То, что сейчас там есть - не айс, и вы это понимаете.

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

Если конечно вы противник подобной схемы в виде прокладки sshd - ваше право, однако вы сами можете понять, что данная схема гораздо эффективнее обеспечивает безопасность оборудования, нежели открытый интерфейс ssh сервера на свиче.