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

Дайте советы по организации сети

Планирую масштабную переделку схемы сети ядра.

И хотелось бы получить несколько советов.

 

1. Сейчас у меня на коммутаторе ядра имеются линки с транспортными выделенными VLAN до основных компонентов ядра (бордер, брасы, агрегация).

В транспортных VLAN созданы транспортные подсети /30, через которые маршрутизируется IP-трафик (управление и часть сервисов).

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

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

Кто как обычно делает?

 

2. Есть мысль mgmt-интерфейсы ключевого оборудования вывести на отдельных коммутатор и включить в него маршрутизатор с 3G-модемом, чтобы можно было попасть на основные железки даже в случае серьезных проблем. Или это избыточно? Кто-нибудь так делал, поделитесь возможными граблями? Тут есть некоторая сложность в том, что у меня в качестве BRAS используется Ericsson SE100 и я планировал его mgmt-интерфейс задействовать для связи с RADIUS-сервером, а при вынесении mgmt на отдельный изолированный коммутатор это будет сделать достаточно проблемно.

 

3. Кто как организует удаленный доступ к оборудованию? Вообще блокирует / оставляет шлюзовый сервер, на который заходят по SSH и уже с него заходят на остальные устройства / настраивает VPN-сервер, к которому нужно подключаться, чтобы попасть во внутреннюю подсеть / просто открывает SSH и разрешает вход только с сертификатом?

 

4. Поделитесь планами нумерации ресурсов (VLAN, IP), если это не закрытая информация? У меня план есть, но возможно я упустил какие-нибудь аспекты, такое хорошо вылавливается сравнением с другими решениями.

 

5. Намечается также смена IP-адресации и на оборудовании Cisco мне сильно не хватает транзакционного механизма (чтобы можно было изменять настройки и затем разом применить их). Как бы минимизировать вероятность того, что придется срочно бегать в серверную с ноутбуком и консольным шнурком?

Share this post


Link to post
Share on other sites

Планирую масштабную переделку схемы сети ядра.

Есть веские причины?

 

1. Без графической схемы лично мне ничего не понятно.

 

2. Это разумно, и называется out-of-band management(OOB). Единственное, если у вас это всё в одной комнате стоит то отключение питания вырубит в том числе и ваш OOB.

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

Про эриксон в частности не скажу - не работал - но вообще обычно связь с RADIUS и другими сервисами у устройств идёт inline, так как подразумевается что сеть работает нормально, а OOB применяется только для OOB. Отдельный OOB интерфейс на железе сделан для того, чтобы в случае смерти линейной карты или интерфейса вы могли бы пообщаться с устройством. Какой в этом случае толк от работающей связи с RADIUS, если сервисы оказывать железка не может никому?

 

3. Best practice - выделенный терминальный сервер. Доступ на оборудование возможен только с него. Для резервирования можно сделать таких серверов 2-3.

 

5. В идеале - проводить работы непосредственно рядом с оборудованием в выделенном окне работ. Я обычно ограничивался тем, что консоль цеплялась заранее(был OOB).

В целом это зависит от SLA и ваших личных потерь в случае непредвиденных обстоятельств. Если вы можете без ущерба для себя(штрафа, потери премии, потери работы) поехать на место и всё восстановить(даунтайм несколько часов, выход за пределы окна работ) - даже OOB не нужно. Если вы владелец бизнеса, и даунтайм более согласованного окна в 5 минут приведёт к потере миллионов прибыли и судебным искам - обязать инженеров работать минимум в паре, рядом с железом, и иметь резерв на полке.

Share this post


Link to post
Share on other sites

1. у меня есть общая подсеть между всем оборудованием - там и сервера, и брасы.

брасы зацеплены на бордеры по bgp и анонсят по /32 всех, кто на них.

широковещательный трафик мало волнует, там всё равно клиентов нет.

 

2. в главной серверной примерно так и сделал

 

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

с них уже доступно всё внутри

 

4. сеть построена на QinQ.

адреса оборудования во "внешних" вланах совпадают старшими 12 битами с vlan id.

например, железка 172.16.100.2 - внешний влан 100

младший октет - это уже сама железка, т.е. может быть до 254 железок во "внешнем" влане.

управление untagged в самом "внешнем" влане, клиенты уже во "внутренних" вланах.

получилось очень красиво и удобно.

 

5. можно новые ипы забить алиасами к старым и так постепенно перевести на новые. потом старое посносить

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

(commit confirmed у джунипера, test у убиквити и т.д.)

Share this post


Link to post
Share on other sites

Есть веские причины?

Скажем так, давно назревало.

Сейчас я пришел к выводу, что неудачный дизайн перевешивает затраты на переделку.

 

1. Без графической схемы лично мне ничего не понятно.

Используемая сейчас схема хорошо подходила первоначальному дизайну сети ядра: подключение по топологии "звезда", в центре звезды коммутатор ядра, на лучах звезды брас/бордер, агрегация и сервера; весь трафик проходил через коммутатор ядра.

Сейчас схема немного другая. В центре стоит L3-коммутатотор, он же бордер. К нему подключаются аплинки, агрегация и брасы. Также к нему подключен сервисный L3-коммутатор, в который включены сервера и некоторое другое служебное оборудование. И мне кажется, что тут транспортные сегменты /30 уже не особо нужны.

 

2. Это разумно, и называется out-of-band management(OOB).

Понятно, спасибо. Про питание я конечно подумал, у меня два ИБП и АВР, оборудование под управление подключено к АВР.

Что касается Эриксона, то это связано с его особенностями агрегации линков, наличие разнородных сабинтерфейсов сильно ограничивает способы балансировки трафика. Поэтому я бы хотел сгруппировать линейные интерфейсы и оставить на них только аплинк и клиентов, а управление и радиус вынести на отдельный интерфейс, а в качестве отдельного есть только mgmt.

 

3. Best practice - выделенный терминальный сервер.

Имеется ввиду VPN-подключение или удаленный рабочий стол для десктопа?

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

 

5. В идеале - проводить работы непосредственно рядом с оборудованием в выделенном окне работ.

Да, так было бы неплохо, но объем работ слишком большой.

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

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

Поэтому и хотелось бы послушать про чужой опыт.

 

1. у меня есть общая подсеть между всем оборудованием - там и сервера, и брасы.

брасы зацеплены на бордеры по bgp и анонсят по /32 всех

Но ведь для BGP тоже какая-то линковая сеть нужна.

Или бордеры и брасы друг с другом подключены непосредственно?

 

4. сеть построена на QinQ.

А какая логика в распределении внутренних подсетей?

Или ключевое железо на публичных IP?

 

5. можно новые ипы забить алиасами к старым и так постепенно перевести на новые. потом старое посносить

Это само собой.

Но хоть и перепроверишь все 10 раз, все равно иногда пропустишь добавление маршрута или забудешь дописать secondary для IP-адреса, и все. Плюс иногда альясами не обойдешься, нужно поднимать временный линк, переводить маршруты на него, удалять старые настройки, задавать новые, переводить временный линк на новые настройки, снова менять маршруты, удалять временный линк, и только попробуй где-нибудь ошибиться.

Сейчас я все команды в текстовых файлах заранее составляю и в консоли только copy-paste использую, но все равно бывают иногда ошибки.

Share this post


Link to post
Share on other sites
Но ведь для BGP тоже какая-то линковая сеть нужна.
Ну да, под всё это хозяйство выделена небольшая белая подсеть. Всё остальное на серых 172.16.
А какая логика в распределении внутренних подсетей?

Или ключевое железо на публичных IP?

На публичных только сервера и брасы.

Всё остальное висит на серых 172.16, логика расписана выше - каждому внешнему влану однозначно соответствует /24 серых ипов для свичей, воипа и прочего.

Внешние вланы QinQ выделены на объекты - например, многие бизнес-центры имеют по отдельному внешнему влану.

 

Или я не понял вопроса?

Share this post


Link to post
Share on other sites

Или я не понял вопроса?

Ну да, я чуть про другое.

Например у меня есть узел связи n (пока что в одном экземпляре, n=1), на каждом узле связи есть от 1 до 8 узлов агрегации a.

Узел агрегации это один или несколько коммутаторов, соединенных в стек, номер порта коммутатора или стека p.

Коммутатор доступа будет иметь IP-адрес 10.na.p.xxx, шлюзом ему будет 10.na.0.250.

Есть подсеть для серверов со своим принципом нумерации, есть подсеть для IP-камер со своим принципом нумерации и т.д.

Есть свои правила нумерации VLAN, только я их сейчас на память не помню.

 

Я так понял, что 172.16 - это блок адресов, внутри которого ролевого распределения адресов нет, следующие октеты определяются только туннельным vid, который выделен на группу устройств. Так?

Share this post


Link to post
Share on other sites

 

Да, так было бы неплохо, но объем работ слишком большой.

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

 

 

Могу помочь, если что :)

Share this post


Link to post
Share on other sites

А, в этом смысле. У меня гораздо проще.

 

Пример - в здании три узла, здание находится во внешнем влане 30.

На первом узле коммутаторы будут иметь адреса 172.16.30.11 и 172.16.30.12,

на втором узле коммутатор 172.16.30.21,

на третьем узле 172.16.30.31.

С нулём на конце - умный UPS. Например, UPS второго узла в данном случае будет 172.16.30.20.

Если UPS глупый, то реле контроля питания цепляется на первый порт свича.

По мере добавления свичей, voip шлюзов, радиомостов и т.д. они нумеруются по возрастанию.

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

.1 в каждом влане - центральный сервер управления. В данном случае 172.16.30.1.

Share this post


Link to post
Share on other sites

К большим изменениям заранее готовлю:

Схему соединений

Схему прохождения данных

Адресацию

Порядок работы с контрольными точками

Скрипты изменений к текущим конфигам в текстовом файле + скрипты для отката.

Если есть сомнения в каком либо функционале и есть возможность проверить в лабе - проверяю.

Проверяю всё что подготовил

 

После этого работы можно выполнить достаточно быстро непосредственно на узле с контролем по заранее намеченным точкам.

Если что то не пошло или пошло не так - откатываю изменения, разбираюсь и готовлюсь снова.

Если нигде не ошибся то всё работает с первого раза.

Если ошибся - ну больше 3х подходов пока не было :)

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