return

Бесчеловечные сети

29 октября 2013, 11:44

Статья опубликована на nag.ru и на habrahabr.ru.
========================
Когда-то управление автомобилем было почти искусством. Во времена славной классики (шестёрок и пятёрок) нужно было знать, как прочистить карбюратор, заменить топливный насос и что такое «подсос».
Когда-то компьютеры были большими и слово «debug» использовалось в самом прямом его смысле. Когда первые ПК начали входить в наши дома, было важно понимать, что такое северный и южный мост, как установить драйвер для видеоплаты, и какое значение поменять в системном реестре, чтобы таки запустить привередливую игру.
Сегодня хоть для личного использования, хоть для бизнеса, вы приходите в магазин, покупаете машину, нажимаете кнопку «ВКЛ» и начинаете пользоваться.
Да есть, нюансы — не пройдёт такой трюк с System p5 595 или Bagger 293 — нужны технические специалисты. Однако в базисе, даже для компании из нескольких филиалов — вы купили газельку, несколько ПК, обеспечили их выходом в Интернет — и можно работать.
Некоторое время назад у меня состоялся спор с человеком от сетей далёким. У него был резонный вопрос: почему нельзя автоматизировать создание и настройку корпоративных сетей небольшого размера. То есть почему он не может купить по одной железке в каждый свой филиал, нажать 5 кнопок на каждой и получить работающую стабильную сеть?
Вопрос был даже более глубокий и затрагивающий личные струны: зачем такой штат техподдержки (у компаний, провайдеров, вендоров). Разве нельзя в автоматическом режиме находить и исправлять бОльшую их часть?
Да, мне известны многие аргументы, которые тотчас всплывают в вашей голове. Такая постановка вопроса и мне сначала показалась утопической. И это логично, что сейчас это кажется невозможным в сфере связи — максимум в рамках одного домашнего маршрутизатора, но и там не всё гладко.
Однако вопрос не лишён рационального начала, и он завладел моим разумом на долгое время. Правда, я абстрагировался от корпоративных SOHO и SMB сетей и посвятил свои мысли сетям провайдерским.
С точки зрения нетехнического специалиста может казаться, что автоматическая настройка важнее и проще в реализации, чем поиск неисправностей. Но любому инженеру должно быть очевидно, что именно траблшутинг выкладывает дорожку из жёлтого кирпича — если мы не знаем, в чём может быть проблема, как мы можем пытаться что-то настроить?
В этой отправной статье под катом я хочу поделиться своими размышлениями на тему различных препятствий на пути к поставленной цели и способах их преодоления

На мой взгляд, первичная задача — это всё-таки научить оборудование автоматически находить проблемы и их причины. Именно об этом я и хотел бы поговорить в первую очередь сегодня.
Далее — научиться их исправлять. То есть зная, в чём причина проблемы, вполне можно решить её без участия человеков в большинстве случаев.
Как вырожденный случай исправления проблемы — настройка по шаблону. У нас есть LLD (Low Level Design — подробный дизайн сети) и на его основе Система Контроля настроит всё оборудование — от коммутаторов доступа до High-End маршрутизаторов в ядре сети: IP-адреса, VLAN, протоколы маршрутизации, политики QoS.
В принципе, в том или ином виде это есть уже сейчас — автонастройка по шаблону — не какая-то невидаль. Просто обычно речь всё-таки не о всей сети, а о каких-то гомогенных сегментах, например, коммутаторы доступа. Тут идёт жёсткая привязка к командному интерфейсу и, соответственно, производителю.
Сейчас это всё реализовано втупую — никакой проверки консистентности скрипт не делает — если в дизайне есть ошибка, она будет и на оборудовании. Есть, конечно, валидаторы конфигурации, но это ещё один «ручной» шаг.
Задача максимум амбициозна — автоматическая генерация топологии, IP-плана, таблиц коммутации и, собственно, настройка всего и вся. Максимум участия человека — утвердить дизайн, расставить оборудование и пробросить кабель.

Автоматический поиск неисправностей

Существует много систем, повышающих отказоустойчивость и понижающих потери/время простоя сервисов при проблеме на сети — IGP, VRRP, Graceful Restart capability, BFD, MPLS TE FRR и многое другое. Но всё это разрозненные куски. Их пытаются слепить в одно целое с переменным успехом, но от этого они не перестают быть разнородными сущностями.
Это напоминает вопрос окончательной теории в науке, согласно которой имеющиеся 4 типа взаимодействия имеют одинаковую природу. Это универсальная, единая теория, объясняющая всё просто и понятно. Но пока картина не складывается.
Вот красивая иллюстрация настроенной взаимосвязи между протоколами:
На такой сети запущен IS-IS, как протокол IGP. Поверх него работает MPLS TE с активированной функцией FRR.
R1 по BFD отслеживает статус R2 и статус TE-туннеля/LSP. Когда на R2 из-за ошибки ПО, перезагружается линейная плата, BFD на R1 мгновенно сообщает об этом всем процессам, которые должны быть в курсе. MPLS TE обращается к FRR и трафик перенаправляется на R3 по временному пути.
При этом на R1 благодаря функционалу GR сохраняются все маршруты R2, все соответствующие записи FIB и даже отношение соседства. В этот время R2 приходит в норму, плата подгружается, поднимаются интерфейсы. А на R1 уже всё готово и в кратчайшие сроки он готов передавать трафик снова на R2. В итоге сервисы возвращаются в своё прежнее русло — все довольны, все счастливы, никто из клиентов не почувствовал на себе кривую руку программиста.
Но представляете ли вы, какой объём конфигурации требуется для организации такого взаимодействия? А как часто конфигурация бывает некорректна, и резервирование отрабатывает совсем не так, как мы этого хотели? А что зачастую у инженеров может не хватить компетенции на настройку таких вещей, и многие корпоративные сети стоят с минимальной настройкой сервисов? Всё пока работает и слава богу! А что огромное количество проблем можно обнаружить на ранних этапах и предотвратить тот момент, когда это выльется в 3 часа простоя и потерю репутации?
Поэтому проведём некоторую классификацию проблем, чтобы понять, какие к ним нужны подходы.

  1. Критические ситуации реального времени
  2. Проблемы, которые имеются в данный момент, но не затрагивают сервисы
  3. Аппаратные проблемы
  4. Потенциальные проблемы ПО
  5. Некорректная конфигурация

 

1. Критические ситуации реального времени

Первый — проблемы, возникшие сейчас всилу обстоятельств — обрыв кабеля, сбой работы ПО или оборудования. Это по сути единственный на данный момент тип, с которым разработчики как-то борятся. Это то, что мы рассмотрели выше. У нас уже не один десяток протоколов, которые отслеживают состояние каналов и сервисов и могут на основе реальной ситуации перестраивать топологию. Но проблема в то, что, как я уже заметил, это всё элементы разных головоломок. Каждый протокол, каждый механизм настраивается индивидуально. И нужны недюжинные способности, чтобы охватить всё это целиком и иметь принципиальное понимание работы крупных сетей.
Ну хорошо, так или иначе, но мы с ними можем справляться — есть для этого средства. Какая здесь есть проблема, помимо собственно сложности? Объясню: после того, как всё случилось, мы либо ничего не заметили (50 мс на глазок не всегда), либо перебираем тонны логов и аварий, пытаясь установить причинно-следственную связь череды событий. А это, знаете ли, дело непростое, потому что поверхностных логов может не хватить, а подробные будут содержать огромное количество малоинформативных данных, например, падение LSP — по записи на каждую, процесс перезагрузки платы итд. Делать это нужно не на одной железке, а на всех по ходу движения трафика и часто даже тех, которые стоят в стороне. Нужно отделить зёрна от плевел — логи, связанные с аварией от тех, которые относятся к другим проблемам. И хорошо, если сеть моновендорная, а если у вас в качестве CE стоит DLink, PE — Huawei, P — cisco, a ASBR — Juniper… Ну что же, тут остаётся посочувствовать.
К чему я, собственно, веду. Логи — это хорошо, это прекрасно, они нужны. Но они не в удобочитаемом виде. Даже, если у вас правильная сеть, с настроенным NTP и SYSLOG-сервером, который позволяет просмотреть в действительно хронологическом порядке все аварии на всех устройствах, на поиск проблемы уйдёт масса времени.
При этом каждое устройство знает, что на нём произошло. Возвращаясь к последнему примеру, PE видит падение туннелей, VPN, перестроение IGP. Он может сообщить Системе Контроля в человеческом виде, что, мол, «В 16:20:12 01.01.2013 у меня упали все туннели и VPN’ы в таком-то направлении, через такой-то интерфейс. Кроме того, перестроилась схема маршрутизации. Что там произошло не уверен, но вот OSPF мне сообщил о пропадании линка между устройствами А и Б. Также о проблеме отчитался RSVP».
Промежуточный P, на котором выгорел SFP-модуль так и говорит: «В 16:20:12 01.01.2013 у меня был повреждён SFP-модуль в порту 1/1/1. Я всё проверил — аппаратная неисправность, нужна замена. По OSPF и RSVP разослал уведомление всем соседям».
Шутки шутками, конечно, но почему бы не разработать стандарт или какой-то протокол, который позволит на самом устройстве провести минимальный анализ и отправить однозначную информацию на Систему Контроля. Получив данные со всех устройств, скомпоновав их и проанализировав, Система Контроля может выдать вполне конкретное сообщение:
«В 16:20:12 на устройстве Б вышел из строя SFP-модуль в порту 1/1/1 (тут ссылочка на тип модуля, серийный номер, аптайм, средний уровень сигнала, количество ошибок на интерфейсе, причина выхода из строя). Это повлекло за собой падение следующих туннелей (список, со ссылками на параметры туннелей), VPN (список, со ссылками на параметры VPN). В 16:20:12 трафик был направлен через временный путь А-С-Е (ссылка на параметры пути: интерфейсы, метки MPLS, VPN итд.). В 16:20:14 был построен новый LSP А-Б»

2. Проблемы, которые имеются в данный момент, но не затрагивают сервисы

Что это за проблемы? Ошибки на интерфейсах, которые пока под слабой нагрузкой, и они не дают о себе знать. Флаппинг интерфейсов или маршрутов на резервных линках, слишком лёгкие пароли, отсутствие ACL на VTY или на внешнем интерфейсе, большое количество широковещательных сообщений, поведение, похожее на атаки (обилие ARP, DHCP запросов), высокая утилизация ЦПУ каким-либо процессом, отсутствие чернодырых маршрутов (blackhole) при настроенной агрегации маршрутов.
Так или иначе сейчас многие такие ситуации отслеживаются и информационные сообщения пишутся в логи. Кто бы их отслеживал? Однако на такие вещи не обращают внимание, пока не вызовут на ковёр в связи с отсутствием связи у тысячи абонентов. И в автоматическом режиме оборудование не пытается найти причину или исправить ситуацию — в лучшем случае настроена отправка на SYSLOG-сервер.
Бывает, конечно, срабатывание чего-либо при определённых действиях — подавление широковещательных пакетов, если их число превышает определённый порог, например. Или отключение порта, на котором наблюдается флаппинг. Но это всё лечение симптомов — оборудование не пытается разобраться, в чём причина такого поведения.
Какие есть мысли по поводу данной ситуации? Разумеется, во-первых, это стандартизация логов и трапов. Стандартизация глобальная, на уровне комитетов. Все производители должны чётко придерживаться их, как, например, стандарта IP.
Да, это гигантский объём работы. Нужно предусмотреть все возможные ситуации и сообщения для всех протоколов. Но так или иначе её проделывает каждый вендор в отдельности, изобретая свои способы сообщить о проблеме. Так, может, лучше один раз собраться и договориться раз и навсегда? В конце концов Martini L2VPN тоже когда-то был личной разработкой Cisco.
Отсылать на систему контроля можно в таком виде, например:
«Message_Number.Parent_Message_Number.Device_ID. Date. Time/Time range.Alarm_ID.Optional parameters»
Message_Number — порядковый номер аварии в сети.
Parent_Message_Number — номер родительской аварии, которая повлекла за собой данную.
Device_ID — уникальный идентификатор устройства в сети.
Date — Дата аварии.
Time/Time range — Время возникновения аварии или период её длительности.
Alarm_ID — уникальный идентификатор аварии в стандарте.
Optional parameters — Дополнительные параметры, характерные для данной аварии.

Во-вторых, оборудование должно уметь само проводить минимальный анализ ситуации и логов. Оно должно знать где причина, где следствие и помимо детализированных логов отсылать также результаты анализа.
Например, если падение BFD, IGP и других протоколов было вызвано физическим отключением интерфейса, то он должен представить это в виде ветки зависимостей: падение порте повлекло за собой то-то и сё-то.
В-третьих, Интеллектуальная Система Контроля Работы Сети должна отразить аварии в человеческом виде.
Пусть после анализа на сервер мониторинга было отправлено стандартизированное сообщение, например:

«2374698214.0.8422. 29.10.2013 09:00:00-10:00:01.65843927456.GE0/0/0»
«2374698219.2374698214.8422. 29.10.2013 10:00:00-10:00:05. 50. 90. R2D2. 70»
«2374698220.2374698214.8422. 29.10.2013 10:00:01. 182. GE0/0/0. Abnormal Power flow. Power treshold is reached. Abnormal power timer is expired»

Система Контроля разбирает данные сообщения на составляющие:
Авария №2374698214. Не является следствием чего-либо. Произошла на устройстве с ID 8422 29.10.2013. Длилась с 09:00:00 до 10:00:05. Универсальный идентификатор аварии 65843927456. Дополнительные параметры: GE0/0/0.
Авария №2374698219. Вызвана аварией «2374698214. Произошла на устройстве с ID 8422 29.10.2013. Длилась с 10:00:00 до 10:00:05. Универсальный идентификатор аварии 50. Дополнительные параметры: 90. 70. R2D2.
Авария №2374698220. Вызвана аварией „2374698214. Произошла на устройстве с ID 8422 29.10.2013 в 10:00:05. Универсальный идентификатор аварии 182. Дополнительные параметры: GE0/0/0. Abnormal Power flow. Power treshold is reached. Abnormal power timer is expired.
Далее он обращается в базу данных сетевых устройств и извлекает описание устройства с номером 8422.
В онлайн или в локальной копии глобальной БД аварий находит описание и значение аварии 65843927456 — аномально высокий поток силы. В качестве параметра — интерфейс-источник GE0/0/0.
50 — Высокая загрузка ЦПУ. Параметры: общая загрузка (90), самый нагружающий процесс (R2D2) и утилизация ЦПУ данным процессом (70).
182 — выключение интерфейса. В параметрах номер интерфейса и причина, по которой интерфейс бы выключен.
Далее Система Контроля формирует понятное и исчерпывающее сообщение:
“К коммутатору C3PO было подключено внешнее устройство к интерфейсу 10GE 0/0/0, генерировавшее аномально высокий поток силы в период с 09:00:00 до 10:00:05.
По этой причине процесс R2D2 утилизировал ЦПУ на 70% в период времени с 10:00 до 10:00:05. Порт был выключен в 10:00:05.
Abnormal Power flow. Power treshold is reached. Abnormal power timer is expired»
.

3. Аппаратные проблемы

Не стоит, думаю, лишний раз говорить о том, что ничто не вечно, никто не идеален — интерфейсные карты выходят из строя, карты памяти обретают битые сектора, платы спонтанно перезагружаются, программисты внезапно исчезают.
Мне видится, что если проблема аппаратная и так или иначе решилась, оборудование однозначно может самостоятельно установить причину — потеря синхронизации, неисправность шины управления или мониторинга, выход из строя блока питания платы.
Одни проблемы имеют накопительный характер, другие внезапный, но, мне кажется, все их можно отследить. Даже, например, полное отключение линейной платы — управляющая плата даже в отсутствие основного питания должна суметь опросить плату и выявить проблему. Если не получается опросить, значит либо сам опрашиватель неисправен — легко проверить, либо плату на замену.
Опять же Система Контроля должна получить сообщение об этом:
«Линейная плата в слоту 4 потеряла синхронизацию с коммутационными фабриками из-за повреждения сетевого чипа L43F. Плату необходимо заменить». И тут же по ссылке сгенерированный шаблон на замену оборудования.

4. Потенциальные проблемы ПО

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

5. Некорректная конфигурация

Пожалуй, это самый сложный аспект. Тут огромное многообразие вариаций. Даже обычный IP вызовет бурю эмоций при попытке реализовать его автоматическую отладку.
Формализовать правила конфигурации, означает создать универсальный язык взаимодействия между Системой Контроля и оборудованием. Ну, нельзя же пытаться разгрести на одном сервере разрозненные данные от Juniper, Cisco, ZTE и Dlink. Нельзя создавать парсер, который будет подстраиваться под данные с разных устройств.
То есть будет необходима стандартизация как минимум хранения конфигурации и передачи её на Систему Контроля.
Как это видится мне: должен быть блок описания возможностей системы: что за тип (коммутатор, маршрутизатор, файрвол итд.), функционал (OSPF, MPLS, BGP). Дальше должны быть секции собственно конфигурации. Такая структура должна поддерживаться любым оборудованием от коммутатора доступа до VoIP шлюза в IMS-ядре.
Тогда с лёгкостью можно находить разнообразные неточности: неконсистентные настройки параметров на оппозитных устройствах (например, дискриминаторы BFD, уровни сетей IS-IS, соседи BGP, IP-адреса), совпадающие Router-ID, неактивированный PIM между двумя мультикастовыми маршрутизаторами итд.
Но, положа руку на сердце, — уже это вещи нетривиальные и реализуемые только должной стандартизации топологий или формализованного LLD (Low Level Design).
Примеры из реальной жизни для всего описанного выше я уже приводил в этой статье.

Техподдержка

На мой взгляд в этой сфере (как и во многих других), сейчас огромное количество лишней работы и перерасход человеческих ресурсов.
Будем говорить о сетях операторского уровня, с SOHO и SMB совсем другие тонкости.
Возьмём для примера процедуру замены неисправной платы.
Сейчас она следующая (с некоторыми вариации для разных вендоров):
1) Плата вышла из строя, перезагрузилась или начала валить странными сообщениями. Заказчик видит в логах ошибки, аварии, но не может однозначно идентифицировать проблему.
2) Заказчик звонит на горячую линию поддержки вендора, описывает проблему на словах, либо заполняет стандартную форму. Предоставляет данные, логи, файлы, собранные рабским трудом или вовсе самостоятельно.
3) Оператор горячей линии открывает запрос назначает его на группу технических специалистов.
4) Ответственный группы назначает запрос инженеру.
5) Инженер анализирует данные и в итоге видит те же аварии. Подключается к оборудованию, проводит ряд тестов, собирает информацию.
6) Зачастую у инженера нет возможности установить истинную причину, и он не может по своей воле рекомендовать замену — эскалация запроса на следующий уровень.
7) В зависимости от компетенции инженеров более высокого уровня, запрос может путешествовать там какое-то время. До тех пор пока путём ввода определённых команд или анализа логов и диагностической информации согласно определённому алгоритму не будет установлена аппаратная неисправность.
8) По цепочке рекомендация доходит до ответственного инженера и далее до заказчика.
9) Затем следует процедура подтверждения закрытия запроса и различная бюрократия.
10) Заказчик открывает новый запрос на замену — снова заполняет форму, снова указывает проблему. Кол-центр переводит заявку на соответствующий отдел, назначаются ответственные и только потом фактически начинается процедура замены.
Это довольно пессимимстичный сценарий, но так или иначе вся эта процедура занимает продолжительно время и на неё необходимы усилия как минимум 4-5 людей — инженер заказчика, оператор кол-центра, Тимлид группы, инженер поддержки, инженеры более высоких уровней, сотрудники отдела запасных частей.
А ведь по сути — есть алгоритмы проверки физических параметров плат. Да их много, но не будем лукавить, их можно ввести в ПО или даже в аппаратную часть плат/шасси.
Оборудование само должно провести этот анализ, и в случае аппаратной проблемы Система Контроля должна выдать однозначную рекомендацию на замену (а, возможно, самостоятельно оформить заявку на замену — по шаблону же). Если ни одна известная аппаратная проблема не подтвердилась, Система Контроля должна предложить открыть запрос в ТП. А лучше опять же самостоятельно заполнить шаблон и зарегистрировать тикет — задача человека — подтвердить заявку.
Аналогично по очень многим другим вопросам.
Я не могу судить о разных вендорах, но часто бывают вопросы о том, какие версии ПО в данный момент актуальны, какие патчи должны быть установлены, какой функционал доступен в них.
Я считаю, что всем этим должна заниматься Система Контроля — подкачивать ПО, патчи, отслеживать текущие известные проблемы по оборудованию, устанавливать патчи, обновлять прошивки. Более подробно опишу в одной из следующих статей то, как я вижу работу такой системы.
Вопросы по конфигурации, неработоспособность каких-то сервисов? Часть таких вещей довольно очевидна и заключается либо в неправильном применении инструкций по настройке, либо несоответствии конфигураций на различных устройствах. Но такие ситуации инженер ТП легко отслеживает, вводя определённые команды. Разве не может то же самое сделать и Система Контроля? Проанализировать конфигурацию и понять проблему и даже исправить её?

Cоциально-психологические аспекты

Да, у многих инженеров и у меня в том числе есть весомый вопрос — а что тогда делать всем нам, если нас можно заменить автоматикой?
Спешу вас успокоить — мы все устареем, как трубочисты и барышни на коммутаторах.
На самом деле это вечный вопрос и повод для стычек. Куда делись кучеры с появлением автомобилей, куда делся огромный штат, обслуживающий первые ЭВМ с появлением компактных ПК?
Современный мир предлагает нам всё больше разнообразных рабочих мест. В конце концов можно устроиться топливным элементом для матрицы.
Но никуда не денется обслуживающий персонал и техническая поддержка — есть масса проблем, которые нельзя решить автоматически в силу тех или иных причин (например, административных). Эти и другие вопросы я рассмотрел в другой статье.
Сети надо проектировать, кабель надо прокладывать, за Системой Контроля следить, проблемы решать.
Просто нашу жизнь нужно сделать несколько более разумной.
Гораздо более важная проблема — поддержка вендоров.
Я полностью согласен с комментариями к статье на наг.ру, такая система, вместо со стандартами и суперпротоколами никому не нужна сейчас.
У вендоров есть свои NMS, которые они продают за большие деньги (огромные, надо сказать). Да и если будут такие стандарты, оборудование одного вендора можно просто менять на другого и никто этого не заметит. А оно им надо?
У крупных операторов (да и не очень крупных) часто есть самописные системы. Это и валидаторы конфигураций, и скрипты по автонастройке, и поверхностные анализаторы проблем.
Инженеры часто инертны и ленивы, либо наоборот гиперактивны и вручную ваяют тысячи строк, которые сгинут при форматировании винчестера следующим поколением админов.
Как бы то ни было, всё это не то. Совершенно не то.
После разговоров с коллегами я понял, что складывается неправильное понимание идеи — мол, я хочу предложить создание какой-то программной Системы Контроля, которая скриптами будет парсить логи, конфигурации и выдавать решение. При этом в ней будет 33 тысячи шаблонов для разных вендоров и разных версий ПО. И это чьё-то проприетарное решение, созданное волей одного предприимчивого человека.
НЕТ. Речь о вещах более масштабных — глобальная стандартизация системы сообщений между устройствами. Не Система Контроля должна заботиться о том, чтобы суметь распознать логи с Huawei, Cisco, Extreme, F5 и Juniper. Это само оборудование должно отсылать логи в строго определённом формате. Не кучка инертных скриптов по разным протоколам (FTP, TFTP, Telnet, SSH) должна собирать информацию о конфигурации, авариях, параметрах — это должна быть единая гибкая вендоронезависимая система.
Другая крайность — парадигма SDN. Это тоже другое. SDN — концентрирует в себе не только функции мониторинга — он забирает на себя практически все задачи оборудования, кроме собственно передачи данных — он принимает все решения о том, как передавать эти данные. Нет канала до мозга SDN — нет сети.
То, о чём веду речь я — всё та же гибкая сеть с самостоятельными устройствами, каждое из которых самодостаточно. А Система Контроля позволяет держать руку на пульсе — знать всё, что происходит в сети, заботиться обо всех проблемах при минимальном участии людей и предоставлять важную информацию в доступном виде.
P.S.
Я не претендую на полноту рассмотрения вопроса — моего уровня знаний явно не хватает, чтобы целиком его объять. Это лишь размышления.
Но я уверен, что это вектор развития сетевых технологий в плане обслуживания и поддержки. Через 50-80 лет всё изменится — сети будут охватывать не только компьютеры, планшетники и телефоны, в сети будет всё. Сплошная конвергенция — WiFi, фиксированные сети, 5G, 6G, телефония, видео, Интернет, M2M. Всё явно идёт не по пути упрощения и на традиционное обслуживание будет уходить всё больше и больше сил и средств.
Самое главное, что такие стандарты должны подойти вовремя. Сейчас не их время, но уже пора говорить об этом.

По ходу написания этой статьи, которая изначально планировалась вовсе как заметка, я пришёл к выводу, что тема для меня слишком интересная и будет ещё серия статей, посвящённых этой проблеме:

  • Система Контроля. Возможности, принципы работы.
  • Протоколы взаимодействия и взаимообмена служебной информацией между устройствами и Интеллектуальной Системой Контроля Работы.
  • Обнаружение и устранение ошибок в конфигурации.
  • Автоматизация настройки оборудования.
like 0 views 16193 message 16

16 коментариев

  • The ability of an application to track a person’s location with the help of GPS technology is also the feature we pay attention to. Installation on the target device is easy and clean, and there is a robust set of configuration options available on the StealthGenie control panel known as MyGenie, Anti spyware software android. Getting the current GPS location, view the latest locates on a map. These are the cell phone spy programs that I have tried and tested and am happy to recommend: Remember your due diligence don just accept what I say, check them out for yourself! Nielsen analyzed the mobile data habits of more than 60,000 mobile subscribers and surveyed more than 3,000 teens during April, May and June of that year, Anti spy phone case. Time your message to be automatically deleted over time without leaving a trace. The ability of an application to track a person’s location with the help of GPS technology is also the feature we pay attention to. Siri Exploited gain: How to Bypass the Lock Screen in iOS 8. 6 Oct 2014 In the past Siri was exploited in iOS 7.0.2 to send messages without higher read below to see how this exploit works and how you can protect yourself.… so every time I tried to text him through Siri you can only guess how Далее. How to Use Siri — Full list of Siri Commands for iPhone iPad Video. These cool and useful Siri Commands can be used on your iPhone 6 iPhone Ask Siri to Read Text Messages (SMS)… Coz Siri can only remember 1 each? Далее, Siri can only read text messages

    16 января 2015, 16:24
  • Målgrupp • Primär målgrupp: de som är verksamma inom området hiv/STI-prevention och sexuell hälsa i länet. Utmaningar • Att utveckla kommunikations- och informationsstrategier i linje med nationella satsningar. Målgrupp Befolkningen i länet, Levitra vs androgel. Viagra receptfritt. Köpa generisk viagra i sverige apotek. Viagra receptfritt på apoteket viagra receptfritt spanien viagra receptfritt europa
    viagra receptfritt frankrike viagra receptfritt tyskland viagra receptfritt i usa viagra . Köpa billig viagra köpa viagra in usa kan man köpa — M/S Linnea, Viagra receptfritt usa. Köpa billig viagra köpa viagra in usa kan man köpa viagra receptfritt i spanien.
    EUR 41.99 — Pris pa apothek. D. För närvarande det finns den inte enkla Det finns emellertid även nackdelar med att kontrollera PSA hos symptomfria män: • Det finns en risk att små, långsamt växande tumörer som aldrig hunnit utvecklas till symtomgivande cancer upptäcks och behandlas i onödan. Utan PSA-provet hade dessa män sluppit både utredning och biverkningar av behandlingen, Viagra Soft och lågt blodtryck.

    16 января 2015, 15:38
  • Несмотря на то, что я веду к тому же — интуитивная простая и, возможно, даже автоматическая настройка, я подразумеваю при этом, что в основе всего этого ещё более сложные технологии, чем сейчас. Кто-то должен будет всё это разрабатывать, траблшутить, интегрировать.
    Да, локальным инженерам надо будет только потыкать галочки да кнопочки, а умная система сама настроит всё, как надо. Но кто-то все эти алгоритмы должен создать 🙂
    И этот кто-то должен будет знать свой огромный пласт протоколов. А архитектор должен иметь общее понимание ВСЕХ технологий и механизмов)

    И, я думаю, вы сильно загнули насчёт «нос к небу». Выскочки бывают в любой сфере. При этом я знаю много очень умных и интересных людей, которые не зазнаются.

    18 ноября 2013, 19:09
  • добавление
    когда на сети сотни а то и тысяча узлов и несколько десятков тысяч абонентов и как то надо аварии устранять и разруливать жаждущих абонентов тебя Убить
    то и вправду подумаешь что Сети делают ТЕ кто никогда их не видел в жизни на уровне ОПЕРАТОРА

    16 ноября 2013, 18:04
  • дорогие ребята
    все что делают люди делают лишь потому чтобы
    — меньше работать
    — чтобы кто то за кого то работал
    — чтобы наслаждаться собственным тщеславием значимости того что ты больше всех знаешь и больше всех можешь
    как это касается Сетей
    в прямом смысле — сеть создали те Кто на них не работает
    значит они меньше приложили усилий а все спихнули на тех кто Сеть купил установил и стал обслуживать
    и инженер работающий на сетях всегда проклинает тех кто Недоизобрел Недоделал Недопрограммировал
    покупают сеть менеджеры финансисты
    ставят подрядчики
    обслуживает Тот Кому Недосказывают Недоучивают Скрывают как надо работать и что делать
    но когда тот Инженер поймет что Надо Делать —-он ВОСКЛИЦАЕТ—Господи какой ИДИОТ так это придумал
    думаете это одна мысль лишь
    таких мыслей МАССА
    PS
    если бы ОБСЛУЖИВАЛИ ТЕ кто Покупает Сети — в миг бы подумали А надо ли такое фуфло покупать

    16 ноября 2013, 17:45
  • eucariot, извиняюсь за оффтоп, не знаю где больше к вам обратиться. Приглашают на работу в хуавей на позицию datacom engineer. Нету там знакомых, у кого можно было бы спросить. Расскажите, пожалуйста, в 2 словах ваши впечатления о работе.

    13 ноября 2013, 22:46
  • Как человек, связанный непосредственно с сетевым мониторингом, внесу свои 5 копеек) Если рассматривать крупного оператора связи, то количество оборудования, установленного на сети просто не сосчитать. Мне порой кажется, что на сети есть железо вообще всех производителей, это касается, конечно, не только оборудования доступа, но транспортное и коммутационное оборудование. Причем внедряя новое — никто не спешит выводить из строя старое, поэтому на сети есть такие динозавры, у которых то системы управления как таковой нет… не говоря о том чтобы посылать куда-то свои данные… Из мультивендорного мониторинга (по крайней мере у того оператора с которым связан я) мне встречалось IBM Tivoli Netcool. Довольно противоречивая штука, хоть она позволяет снимать аварии с различного типа оборудования, но управлять из нее нельзя… Если обратить взгляд на систему HW U2000, которая как бы и должна выполнять подобные функции, то ей до такого функционала еще далеко) Настройка оборудования из нее довольно запутана, и хотя там и есть возможность подготовки шаблонов и автоматической настройки, ни разу от коллег не слышал чтобы кто-то всерьез ей пользовался для этого… Доведут ли ее когда-нибудь до такого уровня?)

    4 ноября 2013, 23:01
  • Действительно интересная штуковина была и список поддерживаемого функционала тоже неплохой. Интересно, почему свернули.

    Но сейчас все они, да, очень неудобны. Словно пишут их не для людей и не люди.

    29 октября 2013, 17:12
  • Частично у Cisco был такой продукт, не знаю как сейчас, назывался гордо CISCO MARS! Но был не поворотлев и чересчур ресурсозатратен!

    29 октября 2013, 14:11
  • Ирония галочек лишь в том, что CLI даёт понимание, а галочек можно по инструкции натыкать.
    В итоге инженеры оператора будут обладать как правило только поверхностными знаниями.

    24 ноября 2013, 18:49
  • как раз про Выскочки говорил о том кто все это и Создал
    Горе от ума—-понятно что много чего надо еще создать по мимо Огромного пласта протоколов когда еще надо Огромный пласт и создать снова
    не понять одно—про галочки и кнопочки==это Ирония или сознательное Против
    если кто то любит CLI то не вопрос===вопрос только тогда чего же те Любящие до сих пор в Досе или истинном Юниксе не работают без графики и интуитивно понятном интерфейсе
    пусть любой файл типа то фильм фотку софт загоняют командной строкой на экран
    пусть Интернет будет у тех до сих пор без браузеров —Фидошники рулят
    Ан НЕТ—те кто могут критиковать про глупые там кнопки как раз сейчас и отвечают не через командную строку а набирают в ОКНЕ здесь же ответ
    Не бывает Локального Инженера
    да и НЕТ Умных людей кто бы ВСЕ ==все ПРОТОКОЛЫ ЗНАЛ без подсказок в ТОМ ЖЕ ОКНЕ где ЕСТЬ КНОПОЧКА И ГАЛОЧКА
    ЧУШЬ
    идите тогда в те времена где были лампы лишь и двухэтажные мейнфреймы с перфораторами —ведь ТЕ БЫЛИ МОЗГИ и как раз когда кнопочки и галочки появились Тогда то они поняли что останутся БЕЗ РАБОТЫ и начался процесс Истинных знатоков и ЛУЗЕРОВ
    Зазнайство приходит к людям даже тогда когда они не понимают что Зазнаются
    — если я верно понял ИРОНИЮ про кнопочки и галочки и локального инженера… понять надо что где то сидит НЕЛОКАЛЬНЫЙ Инженер

    18 ноября 2013, 23:44
  • пусть все что написал будут эмоции
    но порой достало все то снобское когда из каждого инженера делают либо маразматика всех технологий —а их тысячи и все типа надо ЗНАТЬ либо абсолютно многие не понимают одну вещь
    что Невозможно запомнить Тысяча команд с том же CLI чтобы настроить от пункта А в пункт Б все узлы одному —пусть и великознающему но Человеку
    когда один путь еще можно настроить со всякими там полисингами и наворотами то практически Невозможно сделать для сотни тысяч коннектов
    многие вещи делаются чтобы Облегчить эти Долбанные настройки—но даже смешно видеть как инженер нос к небу показывает что ОН Достиг вершин только лишь потому что Настроил ту или иную маршрутизацию
    может быть потому программисты и тщеславны и все делают так чтобы их всегда Звали и Лелеяли боясь потерять свой статус—но все это тогда уйдет в НЕБЫТИЕ когда
    настройки будут делаться исключительно Интуитивно через ГРАФИКУ
    ведь даже сейчас Дошкольник через пиктограммы включает телевизор—значит к этому все и должно сводится любые настройки в будущем

    17 ноября 2013, 22:47
  • Все эти препоны понятны. И всё по-тихоньку меняется.
    Кстати, сегодня записали подкаст как раз на эту тему.

    17 ноября 2013, 16:00
  • Согласен полностью. Но если у оператора идут не из рук вон плохо, периодически на сети идут апгрейды — старое оборудование меняют на новое.
    Ну и как ни крути, а через 15 лет всё поменяется) Хабов же, например, уже не осталось)

    Что касается управления — я не думаю, если честно, что сейчас это необходимо. Как вы себе это представляете? U2000 — крайне неудачный вариант. Пока CLI остаётся самым удобным способом.

    Вообще U2000 — это шаг в нужную сторону, даже не шаг, а взгляд. Но я, конечно, ничего не знаю о планах его развития.

    5 ноября 2013, 10:44
  • Насколько я понял они его тупо раздробили на части по направлениям и оттуда выросли CISCO AIS и тд и тп=)

    29 октября 2013, 17:31

Ещё статьи

Задача №10.2
В зависимости от вендора, могут быть зафиксированы разные значения меток. На оборудовании Huawei метки 16-1023 используются для статических LSP, а всё, что выше — в динамических. В Cisco доступные метки ...
like 0 9424 0
22 декабря 2014
ntcn
like 0 1603 0
14 марта 2014
Let's Lab. IS-IS routing protocol. Часть 2
Концепции и правила! Они окружают нас повсюду. Что употреблять в пищу, как переходить дорогу, почему не стоит облизывать лягушек и как перекладывать пакеты, если ты маршрутизатор. Очень много всяких штук ...
like 0 12796 19
10 марта 2015