HEDG Опубликовано 6 декабря, 2010 · Жалоба Доброго времени суток всем НАГовцам! Встал вопрос, каким образом будет правильно назначать ип адреса для управляемых свитчей (которые не участвуют в маршрутизации трафика). Свитчи можно разделить на четыре глобальные группы: - уровень агрегации (доступа) абонентов - свитчи ядра сети - внешние свитчи(у вышестоящих провайдеров) - свитчи у клиентов, которые берут интернет. Требования: - Учесть, что сеть не использует VPN. - минимальное использование реальных адресов - область, где используются реальные ip (бгп, свитчи у аплинков, свитчи у клиентов) не должны иметь серых ip адресов - Безопасность. Доступ только с определенных подсетей (ip адресов). Желательно, чтоб ни абоненты ни клиенты не могли получить доступ (причем на уровне маршрутизации, т.к. не на всех свитчах есть возможность ограничить доступ на свитче) - схема доступа к свитчам должна относительно легко меняться при необходимости - Легкая в понимании, реализации и запоминании схема управления и распределения ip адресов свитчей. Итак поделюсь своими соображениями на данный счет: - Уровень агрегации абонентов Зависит конечно от распределения серого адресного пространства. Очень часто встречается подсеть на дом (у меня аналогично). В таком случае можно например зарезервировать часть начальных адресов подсети под свои нужды(например первые /27 или /28). На свитче прописывается ип из этой подсети с маской /28. А на роутере x.x.x.1/24 . Соответственно роутер видит и абонов и свитч, а абоны напрямую не могут получить доступ к свитчу (конечно если абон не поменяет себя адрес на входящий в этот диапазон). Дополнительно можно убрать роут по умолчанию и прописать только несколько нужных роутов. Либо зарезать доступ фаерволом на смомо роутере Есть конечно вариант с выделением отдельного влана Свитчи ядра сети можно прописать ип из той области, которую обслуживает данный свитч. Роут по умолчанию убирается. Прописываются статикой пару нужных, для доступа на него. ма Внешние свитчи (у вышестоящих провайдеров) Выделяется подсеть /30 из рельников и провешивается на BGP роутере. С маршрутами можно поступить аналогично + зарезать доступ к свитче на роутере с BGP. Cвитчи у клиентов, которые берут интернет Даже не знаю как правильно, выдавать отдельно /30 из реальников - слишком большой расход реальников... Выдавать серые подсети нехорошо, т.к. роутер с BGP не должен иметь серых подсетей (внутренняя политика насчет подсетей). Если клиенту выдается например подсеть /29 и больше, то можно конечно забрать один ип под свитч, но это тоже не самое красивое решение. К тому же в этом случае клиентам прийдется выдавать минимум /29. Поделитесь, у кого какие соображения на данный счет, у кого и как реализовано управление и доступ к свичам? Каким образом назначаете ип адреса для управления свитчами в разных частях сети (разного назначения)? Что по этому поводу рекомендует Cisco и другие? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 6 декабря, 2010 · Жалоба белые адреса на управлении - это вы с жиру беситесь явно. если вы нарисуете детализованную карту топологии сети, у вас множество вопросов отпадут сами собой. /30 на управление железками - до поры до времени интересно. пока железок мало - можно, как только их будет поболее сотни - перехочется. расчитывайте оптимальную емкость на сегментах; рассматривайте организацию так, чтоб настройка управления не вставила вам палки в колеса, когда в аварийном режиме потребуется с ноутбуком лазить по узлам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 декабря, 2010 · Жалоба Всё оборудование, которое имеет 1 IP адрес(исключительно для управления) однозначно в L3VPN (но условию задачи это противоречит, очевидно). Держать дешёвый китайские говносвитчи в глобальной таблице, даже с серыми адресами опасно. У многих из них криво реализован acl на vty-сессии, а именно tcp-сессия устанавливается и сразу же завершается, я на 99% уверен, что это закладка. Да и даже запингать до смерти могут, что свитчи начинают тормозить. Проще говоря, нужно добиться того, чтобы пакеты от абонентов не доходили до свитчей. Управление L3-железом на свой вкус - либо серый, либо белый лупбэк в глобальной таблице Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 6 декабря, 2010 · Жалоба однозначно в L3VPNне факт.вся таблица маршрутизации может хранится на ядре, а вот noc например можно вынести в dmz, докуда подвести вланы управления. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 декабря, 2010 · Жалоба darkagent Можно попоконкретнее? Как именно организовываетеся dmz в Вашей схеме? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 6 декабря, 2010 · Жалоба Пошел за пивом и чипсами :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 6 декабря, 2010 · Жалоба darkagent Можно попоконкретнее? Как именно организовываетеся dmz в Вашей схеме? берем отдельный роутер (ту же 28ую циску например), одним бортом смотрим в ядро сети, белыми адресами например, другим бортом цепляемся в коммутатор, к нему отдельным шнурком с ядра заводим управляющие вланы до второго борта циски. отдельными вланами с этого же борта циски и коммутатора рисуем вланы своего офиса (серверы, бухгалтерия, базы и пр.), от "офисного" борта внаружу рисует nat, и красиво зарезаем ацесс-листами весь мусор. в частности - рисуем ацесс-листы чтоб на интерфейсы управляющих вланов можно было стучать только с офисного борта. а дальше развивайте мысль по своему желанию. относительно несложная схема, не требует никаких приблуд аля vrf, при грамотном подходе - отлично живет. при больших масштабах сети можно комбинировать dmz и l3vpn. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 6 декабря, 2010 · Жалоба Я, например, выделил на управление отдельный диапазон серых адресов, подальше от действующих. Все свитчи находятся в managment vlan`e который не участвует в маршрутизации. Соответственно каждому свитчу на управляющий влан вешается айпишник. Собсно все. Причем вне зависимиости где они стоят: в ядре, на агрегации или еще где... А зачем вам белые айпишники на свитчи? Серыми обойтись никак? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 6 декабря, 2010 · Жалоба А зачем вам белые айпишники на свитчи? Серыми обойтись никак? тссс, спугнёшь :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 6 декабря, 2010 · Жалоба тссс, спугнёшь :) судя по тому, что автор темы после своего поста в тему больше не заглядывает - уже :D Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HEDG Опубликовано 6 декабря, 2010 · Жалоба тссс, спугнёшь :)судя по тому, что автор темы после своего поста в тему больше не заглядывает - уже :D Я тут :)Просто есть области сети, где не используются серые ip из идеологических соображений, т.к. их там быть не должно... Вот и борется желание сделать все правильно (согласно идеалогии) и жаба которая говорит, что нельзя столько ip тратить. Плюс паранойя борется за безопасность... Вот и думаю как это лучше все сделать... Да чужой опыт не повредит.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 7 декабря, 2010 · Жалоба "чужой опыт" вам настоятельно рекомендует пересмотреть идеологически соображения - управление не только не должно быть на белых адресов, но и вовсе должно быть изолировано от окружащего мира, чтоб доступ имел только штат административного центра. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Gunner Опубликовано 7 декабря, 2010 · Жалоба "чужой опыт" вам настоятельно рекомендует пересмотреть идеологически соображения - управление не только не должно быть на белых адресов, но и вовсе должно быть изолировано от окружащего мира, чтоб доступ имел только штат административного центра. На край случай Trusted Hosts просписать на свичах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 7 декабря, 2010 · Жалоба На край случай Trusted Hosts просписать на свичах trusted hosts как то не уверенно спасает от пакетного ddos'а. особенно на бюджетных железках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HEDG Опубликовано 7 декабря, 2010 · Жалоба Я так понимаю, наилучшим вариантом будет отдельный тегированный влан для управления свитчами. Т.е. получается что на все порты провешивается дополнительный тегированный влан, на который и вешается ип доступа. и Дальше этот влан можно вывести уже туда, куда необходимо... Преимущества по безопасности очевидны.... Вопрос менеджмента. Заводить на каждый свитч /30, как-то неудобно при наличии нескольких сотен свитчей... Вешать сплошняком в /24 тоже не правильно... Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию... Я правильно понимаю? Есть еще какие-то правильные варианты? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fozz Опубликовано 7 декабря, 2010 · Жалоба а чем вам не нравится /24 ? или даже /18 (ну или сколько вам там надо) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 7 декабря, 2010 (изменено) · Жалоба Вешать сплошняком в /24 тоже не правильно...Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию... Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь. Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028). Изменено 7 декабря, 2010 пользователем terrible Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Gunner Опубликовано 7 декабря, 2010 · Жалоба Вешать сплошняком в /24 тоже не правильно...Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию... Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь. Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028). Пока еще не дошли до такого, но хеш да дает просраться.По делу для л2 - управляющий влан одна сеть, если нужен доступ из других сетей агрегируем его на л3. На л3 прописываем ацлям тотже самый трастет хост, чтоб маршрутизация в этот влан была только с нужных ип - все других вариантов нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HEDG Опубликовано 7 декабря, 2010 (изменено) · Жалоба Влан на дом это конечно замечательно.... По факту это повышает общую безопасность и стабильность,но усложняет управление. В случае чего не сильно усложняет устранение проблем в аварийном режиме, особенно когда придется полазить с ноутом по домам (о чем уже писали выше). А если учесть, что желательно иметь влан для абонентов на дом + еще один влан на дом для управления конкретным свитчем... Получается некоторое нагромождение... Изменено 7 декабря, 2010 пользователем HEDG Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HEDG Опубликовано 7 декабря, 2010 · Жалоба Вешать сплошняком в /24 тоже не правильно...Как вариант - Делать какое-то географическое разбиение и разбиение по умолчанию... Почему неправильно? Ну стоит у вас в райончике 50 свичей - выделите им отдельный управляющий влан, на который повесите /24 и ипы согласно номерам домов (или близко к ним). Другая /24 (или /23 или /22, дело вкуса) - уже другой район. Ну как-то так. И не запутаетесь. Я наверно один такой жахнутый, но иногда встречается и отдельный управляющий влан на 1 дом (особенности применения 3028). Я имел ввиду, что 254 свитча в одной /24 - это как-то перебор не люблю, когда в одном сегменте сети находится слишком много конечных устройств... Тем более устройства с разных уровней - ядро и доступ Что будет с такой сеткой если Свитч глюканул и фактически устраивает ДОС ? Что будет если какая-то падла сделала кольцо в свитче ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 7 декабря, 2010 · Жалоба Вам пищу для размышления дали, до чего-то вы сами уже додумались, выстраивайте себе схему управляющих вланов и внедряйте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
HEDG Опубликовано 7 декабря, 2010 (изменено) · Жалоба Вам пищу для размышления дали, до чего-то вы сами уже додумались, выстраивайте себе схему управляющих вланов и внедряйте.Я ж не против. Наоборот огромное спасибо всем отозвавшимся!!! Для этого тему и создавал! Просто я указываю, что в каждой схеме есть свои + и - ... Возможно кто-то подскажет более совершенные варианты... Изменено 7 декабря, 2010 пользователем HEDG Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fozz Опубликовано 7 декабря, 2010 · Жалоба Подкину еще дровишек.. А вот у зюхелевых железяк есть OOB-management =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
darkagent Опубликовано 7 декабря, 2010 · Жалоба Подкину еще дровишек.. А вот у зюхелевых железяк есть OOB-management =)не только у них.на metro-ethernet решениях от сиськи тоже есть сие добро. на l3 железках той же циски можно сделать нечто подобное засчет vrf. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Andrei Опубликовано 7 декабря, 2010 · Жалоба Управление L3-железом на свой вкус - либо серый, либо белый лупбэк в глобальной таблице В задаче ничего не сказано про L3. Может там L2? Тогда как? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
