Jump to content
Калькуляторы

Доступ к управляемым свитчам У кого как реализовано?

Доброго времени суток всем НАГовцам!

Встал вопрос, каким образом будет правильно назначать ип адреса для управляемых свитчей (которые не участвуют в маршрутизации трафика).

 

Свитчи можно разделить на четыре глобальные группы:

- уровень агрегации (доступа) абонентов

- свитчи ядра сети

- внешние свитчи(у вышестоящих провайдеров)

- свитчи у клиентов, которые берут интернет.

 

Требования:

- Учесть, что сеть не использует VPN.

- минимальное использование реальных адресов

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

- Безопасность. Доступ только с определенных подсетей (ip адресов). Желательно, чтоб ни абоненты ни клиенты не могли получить доступ (причем на уровне маршрутизации, т.к. не на всех свитчах есть возможность ограничить доступ на свитче)

- схема доступа к свитчам должна относительно легко меняться при необходимости

- Легкая в понимании, реализации и запоминании схема управления и распределения ip адресов свитчей.

 

Итак поделюсь своими соображениями на данный счет:

- Уровень агрегации абонентов

Зависит конечно от распределения серого адресного пространства.

Очень часто встречается подсеть на дом (у меня аналогично).

В таком случае можно например зарезервировать часть начальных адресов подсети под свои нужды(например первые /27 или /28).

На свитче прописывается ип из этой подсети с маской /28.

А на роутере x.x.x.1/24 . Соответственно роутер видит и абонов и свитч,

а абоны напрямую не могут получить доступ к свитчу (конечно если абон не поменяет себя адрес на входящий в этот диапазон).

Дополнительно можно убрать роут по умолчанию и прописать только несколько нужных роутов. Либо зарезать доступ фаерволом на смомо роутере

 

Есть конечно вариант с выделением отдельного влана

 

Свитчи ядра сети

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

Роут по умолчанию убирается. Прописываются статикой пару нужных, для доступа на него.

ма

Внешние свитчи (у вышестоящих провайдеров)

Выделяется подсеть /30 из рельников и провешивается на BGP роутере. С маршрутами можно поступить аналогично + зарезать доступ к свитче на роутере с BGP.

 

Cвитчи у клиентов, которые берут интернет

Даже не знаю как правильно, выдавать отдельно /30 из реальников - слишком большой расход реальников...

Выдавать серые подсети нехорошо, т.к. роутер с BGP не должен иметь серых подсетей (внутренняя политика насчет подсетей).

Если клиенту выдается например подсеть /29 и больше, то можно конечно забрать один ип под свитч, но это тоже не самое красивое решение. К тому же в этом случае клиентам прийдется выдавать минимум /29.

 

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

Каким образом назначаете ип адреса для управления свитчами в разных частях сети (разного назначения)?

Что по этому поводу рекомендует Cisco и другие?

Share this post


Link to post
Share on other sites

белые адреса на управлении - это вы с жиру беситесь явно.

если вы нарисуете детализованную карту топологии сети, у вас множество вопросов отпадут сами собой.

/30 на управление железками - до поры до времени интересно. пока железок мало - можно, как только их будет поболее сотни - перехочется.

расчитывайте оптимальную емкость на сегментах; рассматривайте организацию так, чтоб настройка управления не вставила вам палки в колеса,

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

 

Share this post


Link to post
Share on other sites

Всё оборудование, которое имеет 1 IP адрес(исключительно для управления) однозначно в L3VPN (но условию задачи это противоречит, очевидно). Держать дешёвый китайские говносвитчи в глобальной таблице, даже с серыми адресами опасно. У многих из них криво реализован acl на vty-сессии, а именно tcp-сессия устанавливается и сразу же завершается, я на 99% уверен, что это закладка. Да и даже запингать до смерти могут, что свитчи начинают тормозить. Проще говоря, нужно добиться того, чтобы пакеты от абонентов не доходили до свитчей.

 

Управление L3-железом на свой вкус - либо серый, либо белый лупбэк в глобальной таблице

Share this post


Link to post
Share on other sites
однозначно в L3VPN
не факт.

вся таблица маршрутизации может хранится на ядре, а вот noc например можно вынести в dmz, докуда подвести вланы управления.

 

Share this post


Link to post
Share on other sites

darkagent

Можно попоконкретнее? Как именно организовываетеся dmz в Вашей схеме?

Share this post


Link to post
Share on other sites
darkagent

Можно попоконкретнее? Как именно организовываетеся dmz в Вашей схеме?

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

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

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

относительно несложная схема, не требует никаких приблуд аля vrf, при грамотном подходе - отлично живет.

при больших масштабах сети можно комбинировать dmz и l3vpn.

Share this post


Link to post
Share on other sites

Я, например, выделил на управление отдельный диапазон серых адресов, подальше от действующих.

Все свитчи находятся в managment vlan`e который не участвует в маршрутизации. Соответственно каждому свитчу на управляющий влан вешается айпишник. Собсно все. Причем вне зависимиости где они стоят: в ядре, на агрегации или еще где...

 

А зачем вам белые айпишники на свитчи? Серыми обойтись никак?

Share this post


Link to post
Share on other sites

А зачем вам белые айпишники на свитчи? Серыми обойтись никак?

тссс, спугнёшь :)

Share this post


Link to post
Share on other sites

тссс, спугнёшь :)

судя по тому, что автор темы после своего поста в тему больше не заглядывает - уже :D

Share this post


Link to post
Share on other sites
тссс, спугнёшь :)
судя по тому, что автор темы после своего поста в тему больше не заглядывает - уже :D

Я тут :)

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

Вот и борется желание сделать все правильно (согласно идеалогии) и жаба которая говорит, что нельзя столько ip тратить.

Плюс паранойя борется за безопасность...

Вот и думаю как это лучше все сделать...

Да чужой опыт не повредит..

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

На край случай Trusted Hosts просписать на свичах

Share this post


Link to post
Share on other sites

На край случай Trusted Hosts просписать на свичах

trusted hosts как то не уверенно спасает от пакетного ddos'а. особенно на бюджетных железках.

Share this post


Link to post
Share on other sites

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

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

Преимущества по безопасности очевидны....

 

Вопрос менеджмента.

Заводить на каждый свитч /30, как-то неудобно при наличии нескольких сотен свитчей...

Вешать сплошняком в /24 тоже не правильно...

Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию...

 

Я правильно понимаю?

Есть еще какие-то правильные варианты?

Share this post


Link to post
Share on other sites

а чем вам не нравится /24 ? или даже /18 (ну или сколько вам там надо)

Share this post


Link to post
Share on other sites
Вешать сплошняком в /24 тоже не правильно...

Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию...

Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь.

 

Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028).

Edited by terrible

Share this post


Link to post
Share on other sites
Вешать сплошняком в /24 тоже не правильно...

Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию...

Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь.

 

Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028).

Пока еще не дошли до такого, но хеш да дает просраться.

По делу для л2 - управляющий влан одна сеть, если нужен доступ из других сетей агрегируем его на л3. На л3 прописываем ацлям тотже самый трастет хост, чтоб маршрутизация в этот влан была только с нужных ип - все других вариантов нет.

Share this post


Link to post
Share on other sites

Влан на дом это конечно замечательно....

По факту это повышает общую безопасность и стабильность,но усложняет управление.

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

А если учесть, что желательно иметь влан для абонентов на дом + еще один влан на дом для управления конкретным свитчем...

Получается некоторое нагромождение...

Edited by HEDG

Share this post


Link to post
Share on other sites
Вешать сплошняком в /24 тоже не правильно...

Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию...

Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь.

 

Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028).

Я имел ввиду, что 254 свитча в одной /24 - это как-то перебор не люблю, когда в одном сегменте сети находится слишком много конечных устройств... Тем более устройства с разных уровней - ядро и доступ

Что будет с такой сеткой если Свитч глюканул и фактически устраивает ДОС ?

Что будет если какая-то падла сделала кольцо в свитче ?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Вам пищу для размышления дали, до чего-то вы сами уже додумались, выстраивайте себе схему управляющих вланов и внедряйте.
Я ж не против. Наоборот огромное спасибо всем отозвавшимся!!!

Для этого тему и создавал!

Просто я указываю, что в каждой схеме есть свои + и - ...

Возможно кто-то подскажет более совершенные варианты...

Edited by HEDG

Share this post


Link to post
Share on other sites

Подкину еще дровишек.. А вот у зюхелевых железяк есть OOB-management =)

Share this post


Link to post
Share on other sites
Подкину еще дровишек.. А вот у зюхелевых железяк есть OOB-management =)
не только у них.

на metro-ethernet решениях от сиськи тоже есть сие добро.

на l3 железках той же циски можно сделать нечто подобное засчет vrf.

Share this post


Link to post
Share on other sites

Управление L3-железом на свой вкус - либо серый, либо белый лупбэк в глобальной таблице

В задаче ничего не сказано про L3. Может там L2? Тогда как?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this