[alibek]

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

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

 

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

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

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

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

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

 

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

 

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

 

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

 

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

[mightyscv]

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

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

 

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 минут приведёт к потере миллионов прибыли и судебным искам - обязать инженеров работать минимум в паре, рядом с железом, и иметь резерв на полке.

[rdc]

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

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

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

 

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

 

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

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

 

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

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

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

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

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

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

 

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

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

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

[alibek]

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

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

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

 

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 использую, но все равно бывают иногда ошибки.

[rdc]

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

Ну да, под всё это хозяйство выделена небольшая белая подсеть. Всё остальное на серых 172.16.

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

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

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

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

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

 

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

[alibek]

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

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

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

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

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

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

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

 

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

[remos]

 

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

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

 

 

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

[rdc]

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

 

Пример - в здании три узла, здание находится во внешнем влане 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.

[myst]

http://forum.nag.ru/forum/index.php?showtopic=107029 пишите.

[NikAlexAn]

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

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

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

Адресацию

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

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

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

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

 

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

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

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

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