Как не нужно строить сети

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

Сразу оговорюсь, что всё написанное ниже является сугубо моим мнением, которое я никому не навязываю. Так же оговорюсь, что речь идёт преимущественно об ip сетях, куда же мы без ip в современном мире?
Собственно, все проблемы любой организации занимающейся сетями связи можно разделить на несколько групп:

• Физическая структура СКС
• Логическая структура СКС
• Мониторинг
• Контроль доступа, безопасность и удалённый доступ
• Система обработки заявок
• Система бэкапов

Казалось бы, это всё настолько понятно, известно и разжевано, что и говорить не стоит, однако, реальность более сурова.

Начнем с пункта номер один — Физическая структура СКС
Чтобы далеко не ходить за примером, прямо сейчас наблюдаю картину, как безжалостные дорожные рабочие калечат оптику, которая валялась на земле и не была подвешена в течении нескольких месяцев по непонятным мне причинам. Самое интересное в этой ситуации, что оптика рабочая…

Но, вернемся к более приземленным вещам — ЦОД, Серверная, ЦУС и т.д.

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

Думаю, не стоит говорить о том, что нужно покупать органайзеры, аккуратно укладывать провода, приклеивать наклейки, не оставлять километровых «соплей», вести кроссовый журнал. Эти простейшие манипуляции не дадут превратится этому:



В это:



Помню, с коллегами как-то навел порядок в таких «соплях», но так как доступ на узел имели не только мы, через месяц опять выросла паутина. Основная проблема таких «соплей» в том, что все задачи ставятся со сроком «вчера», монтажники не особо заботятся о «красоте» и кидают провода как попало, а из-за отсутствия контроля кто, что и куда кидал, применить карательные меры невозможно и вырастает адская паутина. Если со схемами прокладки и разварки оптических кабелей все не так плохо, то со схемами кроссировки внутри помещений всё печально.

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

Мой самый «больной» пункт — Логическая структура СКС.
Я буду говорить с вами не как абстрактный рассказчик, а как человек, который более года обслуживал немаленькую сеть со статической маршрутизацией, отсутствием адресного плана и полной анархией. Все аргументы на необходимость ввода динамической маршрутизации разбивались об фразу — «статика самая надежная».

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

Хотя, есть и другой печальный пример, когда существовала сеть с IGP — OSPF, с несколькими сотнями маршрутизаторов в одной AREA. Человек просто не подозревал, что нужно разбивать сеть на зоны, не говоря уже о том, что бывают зоны разных типов. На любые вопросы был ответ — «всё же работает».

Descript придумали не просто так, подписывайте порты, vlan, подинтерфейсы, интерфейс vlan — пописывайте всё. Так как человеку, который придёт после вас или вам в помощь, совсем не хочется изучать километры arp и mac таблиц, пройтись по десятку коммутаторов и маршрутизаторов чтобы понять, как же всё устроено. Так же, указывайте bandwidth, даже если он не учитывается в расчете стоимости маршрута, вы всегда сможете узнать пропускную способность канала, к тому же это будет полезно для мониторинга (об этом ниже).

Рисуйте схемы! Ни на одном месте работы у меня не было нормальных схем, не говоря уже о раздельных L2/L3 схемах. Но зато, на каждом предприятии есть самый «ценный» работник, который ценен тем, что помнит как же мы подключали этот проклятый канал. На просьбу предоставить схемы, в лучшем случае из сейфа извлекается древний фолиант на котором изображено облачко с двумя линиями.

Есть и другой пример, когда оператор присылал мне схемы на канал, где все устройства были нарисованы в виде квадратов, схема была совершенна нечитаема. Значки маршрутизатора, коммутатора, спутника итд. придумали не просто так, рисуйте читаемые схемы, господа!

Адресный план — это то, что априори должно быть на стадии зарождения сети. Но в реальности бывает так, что его либо просто нет, либо он «покусан» кусками с разных диапазонов, иногда даже с пересечениями. В сочетании со статикой L3 петля вам гарантирована и не одна.

Помимо адресного плана, неплохо бы вести табличку с vlan'ми, а ещё лучше поднять QinQ, особенно если вы провайдер, и предоставляете услуги связи, так как vlan имеют свойство кончатся и пересекаться.

Так же, есть такое понятие как дизайн сети. Экономия на нём приводит к печальным последствиям. Есть один известный крупный оператор, который предоставляет услугу IP-TV, из-за того что мультикаст бегает в одном vlan, а в качестве последней мили используется ADSL, неправильные настройки vpi, vci на модеме абонента приводят к возникновению L2 петли, телевидение сыпется, интернет работает плохо, страдают все абоненты.

Ещё очень больная тема — vlan1. Почему, ну почему его продолжают использовать для управления, иногда даже для передачи данных и удивляться L2 петлям? Почему нельзя выбрать другой vlan и сделать его native? Особенно «приятно» искать петлю, когда на доступе стоит неуправляемый коммутатор.

Следующий на повестке — Мониторинг
Почему-то многие мелкие провайдеры предпочитают реагировать на проблемы исключительно по звонку от абонентов. У более крупных, в лучшем случае весь мониторинг строится только на icmp.

Существует куча прекрасных открытых систем мониторинга: Zabbix, Cacti, Dude итд. Так же, существе куча платных. Думаю не нужно говорить, как важен мониторинг, что помимо icmp, существует ещё snmp.

Однако, мне всё же попался работодатель, который уверял, что у него есть отличный мониторинг Zabbix, который мониторит абсолютно всё. По факту, человек который его настраивал, не удосужился прочитать документацию, пуллеры были перегружены, соответственно данные терялись, данных собиралось мало, все данные по узлам вносились вручную. Конфигурация MySQL была стандартной.

Сейчас это мониторинг приведен в божеский вид, настроено LLD (низкоуровневое обнаружение), которое автоматически добавляет и удаляет интерфейсы, тоннели, модули, вентиляторы, блоки питания итд. Информация в подписи графиков берется из descript, скорости интерфейсов берутся из bandwitch, вот зачем нужно актуализировать эту информацию. Единственное, что как по мне сделано в Zabbix плохо — housekeeping — для больших инсталляций нужно партиционирование.

Собирайте syslog с оборудования, не с всего, но хотя бы с критических узлов. Возможно делать это через Zabbix, но как мне кажется решение выйдет слишком «тяжелым» (есть соответствующая статья в блоге Zabbix).

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

Не самый маловажный пункт — Контроль доступа, безопасность и удаленный доступ
Как правило, при слове AAA я слышал только — «что это»? — либо — «а, знаю — это батарейка»! Посему, либо используется одна локальная учётная запись на всех, либо у каждого своя. В любом варианте, при увольнении сотрудника, особенно когда он ущёл не сам, все начинают бегать с выпученными глазами, выискивая где же ещё он прописан. У меня есть статья про то, как развернуть Tacacs+, поверьте что он очень облегчит вам жизнь. К тому же, в логах вы будете видеть кто и что делал с оборудованием.

Некоторые используют RADIUS, изобретает что-то ещё. Лично мне нравится Tacaca+, практически всё современное оборудование поддерживает этот протокол.

Так же наставайте ACL на доступ, хотя бы на том оборудовании, которое имеет «белые» адреса, так как наши узкоглазые друзья не дремлют.

Не выпускайте управление наружу, то есть — ssh, telnet, rdp итд. Если уж выпускаете, наставайте хотя бы firewall на определенные ip. Лично я, для доступа всегда разворачивал openvpn, генерируя каждому сотруднику индивидуальный ключ.
Чтобы не ходить за примерами далеко, на текущем месте работы имею сеть на оборудовании Cisco, с кучей локальных учетных записей и разными паролями на привилегированный режим, которые конечно же никто не помнит. Путем нечеловеческого напряжения воли, удалось развернуть Tacacs+ на этой сети — два сервера с резервированием, географически разнесены, синхронизируются. Но, несмотря на это, при настройки нового оборудования продолжают настраивать миллион локальных учетных записей, вместо одной. На утверждение, что локальные записи не работают при запущенном Tacacs+, ответ — «локальные учетные записи это надежно, а вдруг что случится»?

Так же, когда я запустил Tacacs+, в логах авторизации увидел кучу записей — попытки логиниться под «root», «guest» итд. от наших китайских друзей. На вопрос об ACL на доступ получил круглые глаза. Кстати, сейчас речь шла про крупный банк…

Систему обработки заявок, на самом деле я не думал включать в список, но был случай, что в госконторе, занимающейся услугами телекоммуникаций, имеющей несколько тысяч абонентов, заявки принимались по телефону, печатались и предавались исполнителю по, барабанная дробь, факсу! Но в целом, в этом плане все хорошо, за исключением того, что «юзабилити» всех систем, с которыми мне приходилось работать на нуле.

Идём дальше — Система бэкапов
Думаю не нужно объяснять, что оборудование может выйти из строя от скачка напряжения, пожара, наводнения, уборщицы и других стихийных бедствий. Чтобы оперативно его заменить, нам потребуется его конфигурация. Был свидетелем того, как человек «рожал» из памяти конфигурацию сгоревшего маршрутизатора, попутно дымя паром из ушей и других частей тела. Я не призываю поднимать что-то глобальное, например Rancid+SVN (как подсказал господин EvilMause, Rancid можно заставить делать бэкапы с оборудования любых вендоров). Но написать простейший скрипт на bash, либо на другом языке, который будет бегать по маршрутизаторам, давать команду копировать конфигурационный файл на ftp/tftp и сортировать по папкам может каждый, а Tacacs+ позволит создать учетную запись с ограниченными правами.

Кстати, оборудование Cisco поддерживает изменение и копирование конфигурации по snmp в случае RW community, но community нужно обязательно привязывать к ACL, иначе… Особенно если это snmp 1 или v2c. В том же банке много где было настроено RW snmp community без привязки к ACL, причём community было не сложнее «public». Но однажды, как гласят легенды, некий «хакер» проник в сеть банка и выключил ip routing. Как же он это сделал?!

Для серверов можно использовать что-то наподобие Bacula, если уж совсем лень и сервер без RAID контроллера, используйте хотя бы SoftRAID 1, например Linux mdad, но только не встроенный FakeRAID. Будет хоть какое-то резервирование данных. А лучше всего, раз уж мы живем в век современных технологий, использовать виртуализацию. Впрочем, как раз с серверной частью у большинства операторов все не так плохо. Но, с бэкапами беда. В Банках с этим дела обстоят намного лучше, так как вся работа завязана на АС.

Подытожу
Разговор был только про ip сети, если посмотреть в сторону спутниковых сетей SCPS — переводчески страдают от «помех» неустановленного источника. В VSAT «чудесным» образом кончаются тайм-слоты. Лично был свидетелем того, как прекрасно человек настроил HUB iDirect. У данной модели, есть два Protocol Processor, которые могут балансировать нагрузку между собой, соответственно нужна динамика, единственный протокол, который поддерживает данная система — RIPv2. Но связку маршрутизатор — Protocol Processor данный человек сделал статикой, завернув все на один Protocol Processor, даже не удосужившись сделать маршрут на второй, с большей метрикой. Соответственно, половина модемов не работала по «необъяснимой» причине, а в случае переброски нагрузки на второй Protocol Processor не работало всё. Или проектировщик, который пытался всех уверить, что расчет был верный и он не понимает, почему антенна отъюстирована точно в столб одиноко стоящий в поле (реальный случай, кстати). Благо, я никогда не касался PDH и SDH, хотя судя по всему, дела там обстоят несколько веселее. О телефонии говорить не берусь, никогда с ней не работал.

Казалось бы, это всё такие очевидные вещи, о которых даже не стоит говорить, но… Но мы имеем то, что имеем. Возможно, в других регионах ситуация кардинально иная, но верится с трудом.

Мне кажется, все это происходит по следующим причинам:

• Коммерческие компании ориентированы в первую очередь на потребности бизнеса и это правильно, но «высокие» руководители ориентированы не на благо компании, а на благо личное. В следствии чего — нереальные сроки задач, отсутствие оплат за переработки, а затем поиск виноватых. В государственных вычеркнуть слова «бизнес»и «коммерция».
• В следствии первого, формируется определенное отношение работников к своей работе.
• Желание сэкономит на кадрах, вместо штата грамотных специалистов нанять одного и десять вчерашних школьников или гуманитариев, которых больше никуда не взяли.
• Отсутствие грамотных руководителей на местах, которые бы выступали в качестве прослойки между техническими специалистами и директорами. Как правило, руководители либо не компетентны и всё ложится на плечи подчиненных, либо давно на всё забили.
• Желание сэкономить или «попилить» деньги на закупках. Это приводит к тому, что закупается оборудование которое совершенно не справляется с возложенными на него обязанностями, несовместимое, либо просто не нужное.
  


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

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

Спасибо.