Мониторинг

Продолжаем разговор по курсу ICND2. И мы всю техническую часть, которая была предложена в курсе, уже закрыли. Мы посмотрели все протоколы, которые нам предлагалось изучать, посмотрели на то, как настраиваются коммутируемые сети, как настраиваются маршрутизируемые сети, разобрали стык между коммутацией, маршрутизацией протоколами FHRP, разобрали Spanning Tree, OSPF, EIGRP, даже BGP немножко смотрели. И теперь с этими знаниями надо идти куда-то в продакшн. А продакшн — это такая штука, где наши настройки, наше оборудование будет уже влиять на бизнес. И бизнес платит деньги за то, чтобы это оборудование работало корректно, приносило бы пользу компании. И в случае, если оно перестает работать корректно, пользу оно перестает приносить, и бизнес начинает терять деньги. Для того чтобы не оказаться в ситуации,

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

если мы говорим про сетевые устройства. Для начала, самый, наверное, очевидный вариант того, что если мы хотим отслеживать состояние устройства, это мы можем использовать протокол SNMP, Simple Network Management Protocol. Это де-факто стандартный протокол, фактически, если вы хотите использовать мониторинг, то в основном будет, скорее всего, использоваться именно он. SNMP будет состоять из отдельных компонентов. Компоненты будут — агент и менеджер. Агент — это некий процесс, который запущен на том устройстве, которое вы хотите отслеживать. Это управляемое устройство, например, роутер или свитч, и агент SNMP, который на нем запущен, он понимает, как работает управляемое устройство. Иногда этот агент запущен прямо внутри контекста того устройства, которое мы хотим отслеживать. Иногда агент может дополнительно своего рода пристегиваться к управляемому устройству.

Бывает такое, что вы, например, ставите какую-то железку, и она сама, в принципе, не умеет отслеживать свое состояние. Но вы ставите отдельно к ней дополнительный механизм, который умеет отслеживать ее состояние с помощью какого-то out-of-band механизма, и по SNMP умеет это состояние отдавать на менеджера. Один из наиболее, наверное, классических примеров — это устройство бесперебойного питания, APC. Там можно купить просто бесперебойник, а можно купить в него отдельную карточку. Эта отдельная карточка — это фактически маленький компьютер, который умеет опрашивать состояние APC, и к этому компьютеру можно подключиться и посмотреть, насколько хорошо бесперебойник у вас работает. Какой там оставшийся заряд батареи, какое состояние аккумуляторов и всякое разное такое. Отдельно у нас есть своего рода микрокомпьютер, который работает на плате мониторинга, и отдельно управляющая система

управляет самим бесперебойником. Так что агент — это то, к чему можно подключиться по SNMP, а managed device — это то, про что этот самый агент будет рассказывать. Это не обязано быть одно и то же. Могут быть разные вещи. Далее. Когда у нас SNMP-агент работает, отдает какую-то информацию, то, чему он отдает эту самую информацию, будет называться менеджером. SNMP-менеджер — это некий процесс, который запущен у вас в сети, например, на каком-то сервере. Запущен сервис, и он бегает периодически по агентам и собирает с них информацию того, как у вас все работает. Этот самый менеджер — это просто процесс, он просто собирает информацию. Если вы хотите эту информацию как-то обрабатывать, например, красивые графики строить, или в случае, если вы видите какое-то нехорошее отклонение от стандартных показателей,

поднимать тревогу, менеджер сам этого не делает. Менеджер — это просто такая штука, которая собирает информацию с агентов. Так же, как сам агент ничего не делает, он не форвардит никуда пакеты. Мы можем подключить агента к роутеру, и когда роутер будет передавать пакеты, мы с помощью агента можем смотреть на то, как это происходит. С помощью менеджера мы можем забрать информацию с агента. И дальше, когда менеджер накопил информацию, это нужно будет куда-то дальше передать, для того чтобы информация, накопленная менеджером, была проанализирована, сложена в базу, и при необходимости каким-то образом была на нее реакция. И реакцию на информацию, собранную менеджером, будет осуществлять некая система сетевого управления, Network Management System. Еще раз: агент — это своего рода софт, управляемое устройство — это то, что агент умеет мониторить, менеджер — это то, что умеет взаимодействовать с агентом, и NMS — это то, что умеет взаимодействовать с менеджером.

Получается вот такая цепочка. Когда мы хотим, чтобы у нас в графиках показывалась загрузка процессора на некоем роутере, мы на роутере запускаем агента, мы дальше говорим, что некий менеджер должен с этого агента собирать информацию, и дальше мы Network Management System заставляем собирать информацию с менеджера и реагировать на то, что там будет видно. SNMP будет оперировать показаниями неких сущностей. У SNMP обычная задача — это периодически сообщать то, как работает устройство. И единица измерения того, как работает устройство, у нас будет объект. Объект — это своего рода переменная. У нее есть имя, и у нее есть значение. И мы можем сослаться на эту переменную, сказать: покажи нам то, что у тебя хранится в определенной переменной

с определенным именем. И он скажет: у меня хранится там такое-то число. Эти объекты будут выстроены в некую структуру, поэтому названия у этих объектов будут не случайные, они будут зависеть от положения объекта в общей иерархии, в общей структуре. Название этих объектов, название переменных, будет выстраиваться в дерево. Каждый объект будет иметь собственное название, которое будет называться OID, Object Identifier. И этот OID будет состоять из цифр. Например, 1.3.6.1.2.1.3. Эта совокупность цифр, разделенных точками, будет являться Object Identifier, который нас будет интересовать. И если посмотреть на то, что это за цифры, как они организуют структуру этого самого OID, выяснится, что у нас есть некое дерево, у этого дерева есть корень,

и дальше от этого корня начинается проход по дереву. И эти цифры — это как раз указывается маршрут в общем дереве всех объектов, которые существуют, которые поддерживаются железкой, для того чтобы найти нужный нам объект. Мы видим, что у нас есть объект 1, 3, 6, 1, 2, 3. Прекрасно. Первая единичка означает, что нам из всех дочерних элементов корня нужно будет найти объект с глобальным номером 1. Дальше точка 3. Значит, нам у этого дочернего корневого объекта 1 нужно будет найти еще дочерний объект с номером 3. Точно так же 6. Находим шестой объект у объекта номер 3, который мы нашли на предыдущем этапе. И так далее. Здесь у нас 1, здесь у нас 3, здесь у нас 6, здесь у нас снова 1, дальше здесь у нас 2, здесь у нас 1, здесь тоже будет какое-то ветвление. Думаю, что идея примерно понятна.

Фактически этот идентификатор, Object Identifier, OID, он указывает на положение некоторого объекта в общей иерархии вообще всех возможных объектов. И из конкретного идентификатора явно следует, что конкретно и где конкретно, в какой области конкретно нас будет интересовать указанный объект. Если вас будет интересовать, что конкретно делает объект с номером 1, 3, 6, 1, 2, 1, 3, то можно будет как раз по этому дереву пройтись. У каждого элемента есть некое название, текстовая метка. И по этой текстовой метке можно будет догадаться, про что идет речь. Допустим, если мы говорим, что у нас есть корневой элемент с номером 1, это все, что касается ISO-стандартного взаимодействия. Дальше точка 3, то есть 1.3 — это ветка, отвечающая за работу с организациями. Это не какие-то управляющие организации

в межсетевом взаимодействии сетевых устройств. Это просто какое-то обычное частное взаимодействие. Дальше 6 означает, что эта работа идет в рамках концепции, предложенной Американским Министерством Обороны, Department of Defense. Не просто 1.3.6, какой-то абстрактный Department of Defense, а 1.3.6.1 — это взаимодействие в интернете. Сегодня Американское Министерство Обороны напрямую к интернету отношений не имеет и напрямую им не распоряжается. Но если вам интересно, по факту сегодня интернет находится в управлении американского правительственного департамента, забыл название, Минпром, короче, то, что у нас называется Министерство Промышленности. Так что, когда Владимир Владимирович говорит,

что интернет — это задумка американских военных, и управляют им американцы, не так уж и далеко от истины. Дальше, в интернете у нас 1.3.6.1.2 — это какое-то управление межсетевым взаимодействием, и дальше там тоже какие-то объекты нас будут интересовать, которые все время будут спускаться по дереву, и так будет выглядеть путь к конкретному объекту. Понятное дело, что вам нужно будет иметь некий словарик, как из внешнего вида объекта понять, что точка 1 — это про ISO-взаимодействие, 1.3 — это про предприятие, 1.3.6 — про Department of Defense, 1.3.6.1 — это про интернет. Нам где-то нужно иметь это самое однозначное соответствие, какие цифры каким текстовым меткам будут соответствовать. И словарик, который будет переводить цифры в текст и наоборот, будет называться специальным словом MIB —

Management Information Base. Этот самый словарик будет указывать, во-первых, какие объекты есть, какие объекты поддерживаются конкретной железкой, и, во-вторых, он будет указывать на то, какой объект с каким номером за что будет отвечать. Например, если мы хотим найти хостнейм железки, мы можем сказать: давайте запросим значение переменной, которая хранит хостнейм железки. Это будет переменная с OID 1.3.6.1.2.1.1. Здесь еще будет 1. И потом, если мне память не изменяет, пятерка — SystemName. Это то, что в Cisco будут отдавать хостнейм. Если вы знаете, какой именно объект вы хотите запросить, например, вы знаете, что вас интересует хостнейм железки, вы в этом случае можете по словарику посмотреть, какой именно идентификатор объекта вас будет интересовать,

находите этот самый OID, и менеджер говорит агенту: покажи мне значение своей переменной 1.3.6.1.2.1.1.1. Можно сказать: а покажи мне вообще все дерево. Покажи мне все дерево, начиная, допустим, с пункта «интернет», или покажи мне все дерево, начиная с пункта «менеджмент». И дальше все дочерние элементы тоже можно будет перебрать. Так тоже можно, если вам это очень сильно хочется. Единственное, что дерево может оказаться достаточно большое, и перебор всех его элементов может занять некоторое время. Если говорить про SNMP, тот, который используется сегодня, то мы будем встречать SNMP трех разных версий. Версия первая была очень простая, она очень древняя, в ней есть 5 сообщений. Get Request — когда вы идете на агента и говорите: я менеджер, я хочу с тебя, дорогой агент, получить значение определенной переменной.

Response — это ответ на то, что запросил менеджер. Также SNMP может и управлять удаленной железкой. Изначально его придумывали как протокол для управления, Simple Network Management Protocol. Поэтому, если вы хотите, вы можете заставить железку перезаписать значение переменной. Например, тот же самый хостнейм — гипотетически можно отправить сообщение: теперь тебя зовут не то, что у тебя хранится в переменной, а как-то иначе. Вы в переменную записываете значение, и железка у вас от этого переименовывается. Для этого используется пакет, который называется Set Request. С этим Set Request есть очевидная проблема, заключающаяся в том, что не любую переменную можно изменить на запись. Так же, как и переменные бывают просто константами, или переменные только для чтения, какие-то свойства объектов могут быть, например. Так же и в SNMP. Есть такие вещи, которые нельзя setRequestить,

можно только getRequest. Например, загрузка центрального процессора. Классический пример. Вы можете считать состояние процессора, но вы не можете отправить сообщение, дорогая железка, у тебя сейчас будет загрузка процессора 100%. Это лишено смысла. Во второй версии, которая появилась чуть попозже, добавили сообщение getBulkRequest. Вы можете отправить сообщение и запросить одновременно несколько разных объектов в одном пакете. Связано это было с тем, что getRequest, если вы хотели перебрать достаточно много элементов дерева, вы это делали очень долго. Вы должны были сначала запросить один объект, получить на него ответ. Потом запросить другой объект, получить ответ. Запросить третий, получить ответ. И это действительно происходило крайне медленно. Если вы хотели этот процесс ускорить, то вы могли переключиться на вторую версию. Там было дополнительное сообщение getBulkRequest, которое как раз и позволяло сказать, дай мне объекты этот, этот, этот, этот сразу. И вам приходило, соответственно,

уже не сто пятьсот разных ответов, а один ответ на то, что вы просили. Плюс к тому, во второй версии добавили сложную модель аутентификации пользователей. Когда менеджер приходил на агента и говорил, я хочу запросить с тебя определённую информацию, агент мог сказать, а покажи, кто ты. И там можно было использовать хитрую парольную защиту, можно было использовать отдельные права доступа. Но всё это работало существенно сложнее, чем та система аутентификации, которая была в первой версии. В первой версии её фактически не было. У вас был своего рода пароль, то, что называлось community string, и этот пароль просто открытым текстом посылался в каждом сообщении. То есть это не пароль как таковой. В версии 2 сделали сложную систему аутентификации пользователей, которая не понравилась этим самым пользователям. И поэтому по факту, после того, как появилась просто версия 2,

через некоторое время выкатили версию 2C, в которой фактически осталось сообщение getBulkRequest, но в части аутентификации произошёл откат к community string. Вы посылали сообщение и говорили, не я, Вася, мой пароль 1, 2, 3, а вы просто говорили, мой пароль 1, 2, 3, и вы этот пароль посылали plaintext. Понятное дело, что защита у такого механизма околонулевая, потому что любой злоумышленник перехватит ваш community string и узнает, что за пароль вы используете, и сможет с этим паролем точно так же подключаться. Поэтому рассчитывать на то, что вы поставите какой-то community string и никто вас не взломает, не стоит. Community string — это не какой-то механизм обеспечения ультрабезопасности, это скорее механизм просто для того, чтобы проконтролировать, что вы подключились именно к своей железке, а не к какой-то ещё. Тем более что community string есть стандартные, у вас есть пароль по умолчанию, который все используют.

Если говорить про те пароли, которые действительно есть, про community string, это public. Public и private, соответственно. Public на чтение, private на запись. В третьей версии вернулись обратно к аутентификации с пользователями, добавили криптографию, то есть можно сообщение, передаваемое в SNMP, шифровать. Но единственное, что криптографическая защита, которую добавили в SNMP третьей версии, она не совсем полноценная. Она, конечно, есть и как-то худо-бедно функционирует, но при этом она всё равно уязвима к некоторым атакам. Поэтому из-за того, что SNMP третьей версии не обеспечивает должный уровень безопасности, но при этом намного сложнее в настройке, чем SNMP первой и 2C версий, использовать его в реальном продакшене мало кто решается.

В любом случае, если вы хотите использовать SNMP, то вы должны будете использовать SNMP поверх каких-то доверенных сетей. А если вы используете SNMP поверх недоверенных сетей, то вам следует использовать SNMP версии 2C, поскольку в нём есть getBulkRequest, и просто завернуть всё это дело в IPsec, потому что ему всё равно, что конкретно шифровать. Он вам всё и зашифрует, и убедится, что это именно вы. Как правило, у вас все железки, которыми ваш менеджер должен будет рулить, они хорошо известны. Просто вы на уровне IP-адресов указываете, что менеджер приходит с вот такого IP-шника. Всё, что приходит с этого IP-шника, должно быть зашифровано. А всё, что приходит с других IP-шников, представляется менеджером, мы просто отстреливаем сразу. Так, SNMP — это важный механизм проверки того, как у вас всё работает. Из того, что нужно будет обязательно отслеживать на ваших сетевых устройствах, это, очевидно, загрузка процессора,

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

значение счётчика, сколько пакетов вообще прошло через интерфейс, или сколько байт прошло через интерфейс за всю историю существования этого интерфейса. И дальше вы будете просто смотреть, с какой частотой вы опрашиваете эту железку. Условно говоря, если вы раз в две секунды опрашиваете железку, и она сказала, что сейчас, прямо сейчас, через неё прошёл один гигабайт данных, а через две секунды она сказала, через меня прошёл один гигабайт 100 мегабайт данных, и вы получаете информацию, что за последние две секунды трафика прошло через интерфейс 100 мегабайт. Значит, средняя скорость — 50 мегабайт в секунду. Это делает сам... Это даже не менеджер делает, это делает NMS, то есть та штука, которая собирает информацию с менеджера. И очень часто можно встретить именно такой механизм подсчёта средней скорости на интерфейсе.

При этом, естественно, мы не знаем, может быть, на самом деле, через интерфейс прошло 100 мегабайт не за две секунды, а за одну десятую секунды. И на самом деле у нас загрузка интерфейса практически в 100% была в течение этой одной десятой секунды. А всё остальное время интерфейс лежал свободный. По средней скорости не видно, сколько конкретно трафика было потеряно. Может быть такое, что у нас в сети случилась короткая перегрузка, микроберст, а дальше интерфейс лежит свободный. Номинальная полоса пропускания, которая на интерфейсе есть, она сильно выше, чем средняя скорость, но всё равно у нас потери при этом происходят. Вам следует отслеживать количество потерянных пакетов. Мало смотреть на среднюю скорость, именно по той причине, что средняя скорость показывает, на самом деле, погоду на Марсе. Нужно будет смотреть на потери пакетов, на то, сколько данных вам пришлось дропнуть, либо tail-дропнуть, либо, если у нас есть, WRED-нуть.

В любом случае, все потери — это неприятно. Вам нужно будет отслеживать, если есть какая-то система хранения информации на вашем сетевом устройстве, например, логи, куда складываются, вам нужно будет отслеживать количество места в этом хранилище. Какая-то флешка, например. Вы, естественно, должны будете знать, насколько хорошо у вас работает устройство в нормальном состоянии. Вы знаете, что в некоторый момент времени у вас сеть работает стабильно. Поэтому вы должны будете взять и отследить, пока сеть работает стабильно, как конкретно ваше устройство себя ведёт. Какая у него средняя загрузка процессора, какая у него средняя загрузка оперативки. Именно для того, чтобы если что-то пойдёт не по плану, чтобы вы понимали, из-за чего оно, скорее всего, идёт не по плану. Что относительно бейзлайна выбивается на конкретном устройстве, которое себя ведёт некорректно. У вас должен быть этот самый бейзлайн,

должно быть какое-то эталонное состояние, с которым нужно будет сравнивать текущее состояние. И когда вы смотрите на железку и говорите, да, у нас железка начинает терять пакеты, и относительно нормального состояния мы видим, что у неё загрузка процессора 100%. Мы можем сделать вывод, что, скорее всего, это из-за перегрузки по процессору. И мы знаем, что это не нормальное состояние, потому что мы знаем, что в нормальном состоянии загрузка процессора 20%. Для того чтобы мониторить состояние, вот такого рода вещи вы должны будете снимать. Понятное дело, что для конкретного сетевого устройства иногда приходится снимать еще дополнительные показатели, потому что, да, именно вот на конкретном этом устройстве нужно будет отслеживать и что-нибудь еще, не знаю, количество сессий, количество трансляций над, ну, мало ли. Вот. Но, соответственно, SNMP, он показывает то, как у вас железка работает сейчас. Он не позволяет вам, если железка, например,

перезагрузилась, понять, почему она перезагрузилась. И для того, чтобы понимать, какие события на устройстве происходили, SNMP вас не, вам не поможет решить такую задачу. Для того, чтобы понимать, что происходит с устройством, почему оно себя ведет таким или иным образом, кроме SNMP, нам нужно будет еще ввести журналы. И эти журналы принято куда-то централизованно складывать. Есть стандарт, который предполагает, что все ваши сетевые устройства будут складывать все свои журналы, все свои логи на некий центральный сервер. И они будут для этого использовать протокол Syslog. Syslog просто, очень просто устроен. У него аж однобайтовый заголовок. То есть, когда мы посылаем какое-то сообщение о том, что у нас случилось что-то в журнале, вот оно посылается на сервер, и там используется UDP-шное вложение в IP на 514-й порт, чаще всего. И дальше идет однобайтовый заголовок.

Этот однобайтовый заголовок состоит из двух полей. Первые 5 бит — это биты facility, и потом 3 бита — это бит важности, level. Вот, например, вы видели наверняка на консолях CISC вот такие вот штуки пробегают, что у нас там интерфейс поднялся, упал. Вот это вот сообщение, оно как раз сообщение системного журнала, и здесь вот все вот это вот, это как раз нечто, что должно быть сохранено на центральном сервере. По умолчанию CISC запоминает все, что происходит с ней в оперативной памяти. Соответственно, если вдруг у вас устройство перезагружается по питанию или по почему-нибудь еще, то все, что в оперативке хранилось, оно все потеряется. Поэтому для того, чтобы, если вдруг у нас что-то происходит, ничего не потерять, имеет смысл все логи складывать на центральном сервере. Более того, в принципе, неплохо было бы еще эти логи складывать и где-то локально, чтобы если вдруг ваше устройство

сначала теряет связь, а потом там, не знаю, перезагружается, чтобы можно было откуда-то вытащить часть логов и посмотреть на то, что с железкой происходит. Но обычно, если у вас просто обычная нормальная стабильная работа сети происходит, все равно какие-то логи генерятся на железке, и если говорить, допустим, про те же самые CISC, то за время нормальной работы системы этих логов может накопиться столько, что у вас просто произойдет переполнение флешки. Флешка не такая большая, чтобы на нее можно было складывать сколько угодно логов. Я видел своими глазами CISC, которая имела аптайм 10 лет. То есть за 10 лет, понятное дело, там логов накопилось бы реально много. Что касается вот этих вот параметров level и facility. Level, 3 бита, это насколько важные у вас есть сообщения. в 3 бита можно вписать 8 разных значений. Эти значения нужно будет запомнить. То есть здесь логика будет, чем меньше число

мы вкладываем в эти 3 бита, тем более важные сообщения. Самый неважный уровень сообщений это дебаг. То есть дебаг, это, ну, включили дебаг, и у нас начинает валиться на консоль какая-то фигня. Вот эту вот фигню можно, в принципе, тоже отсылать на CISLog сервер, но обычно не нужно. Поэтому сообщения с 7 уровня это такие скорее мусорные сообщения. Обычно их анализируют, только если вот прям в явном виде это требуется. А так по-хорошему даже анализировать их не зачем. Шестой уровень это уровень informational. Это что-то произошло, и в принципе это может быть не безинтересно, но никакого, никаких последствий за таким сообщением не будет. Ну, то есть что-то произошло. Окей, произошло. Пятый уровень это notification. что-то произошло, и это что-то достаточно важное для того, чтобы это могло повлиять на работоспособность устройства. Например, вот как раз сообщение типа

line protocol changes day to down, интерфейс упал. Это штука, которая достаточно неприятная может быть, если у вас в сети внезапно упал какой-то интерфейс. Поэтому в принципе, по большому счету, это не является ошибкой, то, что интерфейс упал. Но все-таки это достаточно важное сообщение, которое просто так игнорировать не стоит. Мы, если видим, что интерфейс просто внезапно как-то упал, когда мы этого не ожидаем, мы должны будем как-то напрячься и разобраться, почему такое произошло, почему интерфейс упал, и предотвратить подобное падение в дальнейшем, если мы не были заинтересованы в этом падении. Warning. Warning. Это уже что-то важное происходит. То есть, не просто у нас интерфейс упал, а это у нас прям какая-то штука, которая может являться ошибкой потенциально. То есть, требуется, по крайней мере, анализ нашей страны, нет ли какого-то криминала в том, что там написано. Предупреждение.

Очевидно, что если вы не проанализируете, что система вас предупреждает о чем-то, то дальше система может перейти в состояние ошибки. И уровень 3 это как раз уровень ошибки. То есть, у нас произошло что-то, и система деградировала. Состояние системы не такое хорошее, как оно было раньше. Двоечка — это критическое состояние. То есть, это существенно более важная вещь, чем просто у нас там какая-то ошибка случилась. Например, просто ошибка — это то, что сосед присылает нам LSA, в которой указан наш собственный Router ID. Вот это вот явно какая-то ошибка, террор. Но если мы видим, что у нас OSPF вообще сдох от того, что кто-то там нам LSA киносовал, то это будет, конечно, уже critical. Это у нас какой-то сервис есть, который повлияет на работоспособность сети, и он находится под угрозой. То есть, система не совсем стабильно работает. Единичка — это крупный сбой.

Система работает откровенно нестабильно. Мы не можем, допустим, перезапустить OSPF. Вот у нас процесс OSPF и есть. Понятное дело, что без OSPF сеть не будет работать стабильно. И вот мы пытаемся его перезапустить, и нам не удается. У нас просто не получается запустить сам процесс. Ну и нолик — это emergency, это kernel panic. То есть, это последнее сообщение перед смертью, когда железка в принципе не может быть, не может работать, не может обслужить администратора, который пытается зайти и помочь такому устройству. Ну, kernel panic, он и есть kernel panic. То есть, начиная с седьмого уровня и заканчивая нулевым уровнем, это вот уровни важности. Debug information, notification warning, error, critical alert, emergency. Запомнить это все дело можно с помощью мнемонической фразы face wind, то есть, ветер в лицо, face wind. Здесь есть нюанс. Нюанс заключается в том, что

e, a, c, e, w, n, e, d, то есть, i и n будут меняться местами. Здесь вот f. Но, тем не менее, все равно фразы похожи. Нужно будет запомнить, что в этом самом face wind перепутаны две буквы. Ну и дальше вы уже просто, если вспомните, как это должна выглядеть, эта самая фраза face wind с перепутанными буквами, вы сможете восстановить оригинальные названия этих самых важностей. На экзамене будут вопросы, которые будут содержать в себе вопрос, типа, что важнее, что криминальнее, critical или там warning. В принципе, можно догадаться зачастую, то есть, понятно, что там notification это что-то неважное, warning это что-то уже такое предупредительное, error это явно какой-то криминал. Ну, допустим, вспомнить однозначно critical или alert, в каком порядке они идут, это не всегда может быть легко. И вот такая аббревиатура, она позволит вам приблизительно хотя бы прикинуть,

кто из них важнее. Ну и понятно, да, что informational notification это тоже разные вещи, informational просто что-то, какое-то информационное сообщение, которое можно пропустить мимо мучей, а notification это явно именно в вас тыкают палочки, говорят, смотри, смотри, здесь что-то происходит. Что касается трех бит важности, я уже рассказал, это чем важнее, тем меньше туда вписывается, а вот эти вот пять бит facility, они, как правило, фиксированы, то есть у нас, если мы говорим про циску, мы отправляем сообщения журналу, и мы говорим, эти сообщения надо сложить в некую пачечку. И вот этих пачечек стандарт предусматривает 24 штуки, от нуля до 23. Понятное дело, что в 5 бит можно вписать 32 разных значения, но вот последние 8 не используются, они зарезервированы. Эти все пачечки пронумерованы, и мы, отправляя сообщения вот в этом самом 5 битов facility, говорим, например, сложи нам все в пачечку с номером 16.

Номера этих пачечек вот мы видим здесь, здесь и здесь, и, соответственно, у каждой пачечки есть свое название. В принципе, никто нам не мешает сказать, а давайте мы будем складывать цисковские сообщения в, например, журнал номер 7, в пачку номер 7. Это специальный журнал для новостей, если хотите, да, для того, чтобы туда складывались именно какие-то оповещения о том, что происходит в мире. Или вы можете сказать, у нас есть, например, журнал FTP, вот FTP-сервер, по идее, туда должен складывать свои журналы. Но если говорить про то, что в реальности происходит, в реальности цисковские сообщения почти всегда складываются в журнал номер 23. Журналы с 16 по 23 имеют название Local 0, Local 1, Local 2 и так далее до Local 7, и это просто журналы для того, чтобы можно было туда чего-то кастомное впихивать. Если хотите, можете поменять. То есть никто вас не обязывает складывать только в номер 23, но просто смысла

этого делать особо нету, менять журнал с 23 на какой-либо еще. Ну и, соответственно, C-Slog Server, когда будет видеть ваши сообщения, он их будет складывать, и дальше вы, складывая сообщения в разные журналы или, допустим, в один и тот же журнал, можете их потом проанализировать. Чаще всего, если говорить про Windows, используется что-то вот такого вот плана, здесь конкретно нарисован Kiwi C-Slog, но, в принципе, есть TFTPD32, который умеет работать с C-Slog, есть всякие другие софтинки, которые умеют с ним работать, и чаще всего под C-Slog Server выделяется отдельная машинка, отдельная машинка, ну, скорее всего, на Linux, и дальше штатный просто демон Linux может эти самые C-Slog-овские сообщения принимать и складывать в свои журналы. Есть еще один нюанс, заключающийся в том,

что штатные вот эти вот самые все механизмы Linux, они не очень удобны, и искать по ним тоже не очень удобно. Если вам хочется, чтобы по журналам можно было легко искать, а вам чаще всего хочется, потому что, если у вас есть журнал, в котором навален миллион сообщений за последние сутки, вот разобраться, что происходит с какой-то конкретной железкой в какое-то определенное время, ну, может быть, довольно тяжело. Вот в этом случае имеет смысл использовать какой-то софт, который умеет быстро искать по большой базе сообщений. Чаще всего, если говорить про, опять же, реальный мир, используется стек Elastic, Elastic, Logstash, Kibana. Logstash принимает сислоговские сообщения, складывает в базу Elastic, и потом Kibana по этим сообщениям умеет искать и находить нужный вам результат. Так, еще один механизм, который полезен для траблшутинга того, что у вас в сети происходит, для мониторинга того, что в сети происходит, для ответа на вопрос, а что происходило

в прошлом, будет механизм NetFlow. Этот механизм позволяет именно смотреть, что было с боевым трафиком. То есть, что SNMP, что сислог позволяет посмотреть на то, что было с железкой. А железка может работать нормально. То есть, никаких проблем с самой железкой, может быть, и не было, но была проблема в активности сетевой, которая нас не устроила. Например, кто-то взял и выжрал весь сетевой трафик. У нас был там куплен, не знаю, 50 гигабайт трафика при тарифном плане, который предусматривает оплату за трафик. И вот некто в компании взял и сожрал весь этот трафик. И для того, чтобы отследить, кто это был, может быть использован как раз механизм NetFlow. Когда-то это был исторический проприетарный цисковский механизм. Сегодня либо его, либо протоколы на его основе или с той же самой логикой используют практически все вендоры.

Ну и работает он следующим образом. Когда у вас роутер пропускает через себя пакеты, то есть он занимается фарвардингом, у него с одной стороны пакет приходит, с другой стороны пакет уходит. Этот роутер запоминает, какие пакеты проходили через него. То есть он не запоминает само содержимое пакетов, он запоминает информацию, которая в этих пакетах была, в частности, в заголовках. Вот он может посмотреть на то, соответственно, какой протокол там использовался на IP-вложении, там TCP, UDP, ICMP. Может посмотреть на IP-адреса отправителя и получателя. Может посмотреть, если там TCP, UDP, на номера портов. Может посмотреть на то, какого размера пакет идет. И дальше он эту информацию в себя усасывает. Он не хранит информацию по отдельным пакете, он, как правило, хранит информацию про потоки. А поток — это некая последовательность пакетов, которые идут от одного и того же отправителя до одного и того же получателя с одинаковыми свойствами. То есть, например, мы берем

и запускаем с узла А на некий сервер, FTP, сессию, и начинаем скачивать большой файл. У всех этих пакетов, которые несут в себе кусочки файла, одинаковые IP-шники, одинаковые номера портов, одинаковое все. Разница только будет в размере вложения, которое там передается. Вот. И, соответственно, этот роутер, который пропускает через себя такие пакеты, он будет вести учет, сколько пакетов с определенными свойствами прошло через него. Сколько пакетов, сколько суммарно байт. И эту информацию, которую он накапливает, можно с помощью NetFlow с него забирать и дальше анализировать с помощью какого-то механизма, с помощью какого-то построителя отчетов, что конкретно в сети происходило в определенный момент времени. Он не хранит сами пакеты, он не хранит информацию о том, что внутри передавалось, но при этом он хранит именно статистическую информацию про них. Эта штука фактически похожа

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

кто, куда, чего, зачем. И дальше там на основании этих показателей NetFlow можете выставлять счет. Можно будет запустить NetFlow не для того, чтобы как-то карать своих пользователей или брать с них деньги или что-то еще, а для того, чтобы просто понимать, что у вас в сети происходит, какие приложения используются. Если вы, например, хотите обновить вашу сеть, хотите спроектировать правильно переход со старой сети на новую, вы должны будете знать, какие у вас там приложения есть. Вы должны будете при принятии решений запланировать какие-то моменты, которые связаны именно с конкретными приложениями. И без NetFlow это сделать крайне сложно. Вот. NetFlow будет состоять из отдельных компонентов. Первый компонент это тот маршрутизатор, который будет собирать статистику потоков, проходящих через него. Единица измерения от NetFlow это именно поток. Это совокупность пакетов с определенными свойствами. Дальше. После того,

как маршрутизатор накопил некую статистику, эту статистику он должен отправить на узел, на сервер, который ее сможет принять. Соответственно, маршрутизатор у нас будет называться FlowExperter. а некая база, в которой будут храниться отчеты этого самого NetFlow будет называться FlowCollector. Сам коллектор это просто база, куда складываются отчеты, если хотите, чтобы определенное время определенный роутер слил на коллектор отчет с определенными характеристиками. А дальше эти отчеты надо анализировать, строить на их основе какие-то графики, строить, не знаю, указания, кто сколько скачал и что-то проанализировать те отчеты, которые хранятся в коллекторе. Это делается, как правило, с помощью отдельного приложения. То есть, никто вам, в принципе, не мешает сказать, что давайте мы объединим коллектор

и приложение для анализа конструктивно на одном сервере, в одном даже процессе системном. Но все-таки логически это две разные вещи. Одна вещь, которая собирает данные коллектор, и другая, которая анализирует эти данные и дальше по ним строит какие-то уже отчеты, отчеты, графики. Коллектор, как правило, работает на 9996 порту, то есть, это такой принятый в индустрии порт. Никакого стандартного порта нету, вы можете запускать NetFlow на любых портах, которые захотите, но вот обычно используется 9996. И вы при настройке NetFlow должны будете указать соответственно на каждом роутере, что вам а. требуется собирать статистику, б. требуется отправлять собранную статистику на коллектор, ц. вы должны будете указать, как часто ваш роутер, ваш экспортер будет отсылать данные на коллектор. То есть, какая гранулярность

отчетов у вас должна быть. Чем более гранулярные отчеты, тем лучше вы будете видеть, соответственно, кто у вас сколько скачал, в какой момент времени, но тем больше места вам потребуется под хранение базы. В зависимости от того, насколько гранулярные отчеты вы хотите, база, соответственно, может расти очень и очень сильно. Я не рекомендую вам в предприятии использовать какие-то там отчеты с гранулярностью в одну секунду или там в 10 секунд. Да, это гипотетически вам позволит посмотреть, что в определенный момент времени у вас какая-то активность была с точностью до секунды или до 10 секунд. Но это порождает совершенно неразумное расходование места на диске, во-первых. А во-вторых, природа нетфлоу заключается в том, что он в любом случае хранит информацию по потоку в целом. Если у вас открылся какой-то поток, вот он до тех пор, пока не закроется, он на коллекторе, как правило, накапливается, накапливается, накапливается. Если у вас есть

один узел и дальше тут роутер и другой узел, и вот вы говорите, этот роутер посылает статистику на некий коллектор там раз в секунду. Но у вас начинается работать вот здесь, допустим, FTP-соединение, и это FTP-соединение это один поток. Он пока работает, он работает, работает, работает, работает, работает, он накапливает статистику, и он в этот момент не сливается на внешний сервер. И как только здесь в FTP произошла команда на закрытие соединения, поток считается закрывшимся, и, соответственно, сливается информация на коллектор. И у вас получится, что если вы будете слишком гранулярные отчеты снимать, у вас это давать будет очень странную картинку, что никакой активности не было, не было, не было, не было, а потом хоба, и там 100 гигабайт в секунду получите, распишитесь. Поэтому нет флоу, нет смысла, на самом деле, чаще всего на большинстве сетевых узлов снимать слишком гранулярно. 30 секунд, минуту,

это минимальное разумное значение, которое вообще имеет смысл. Я обычно ставлю порядка 10 минут. Это все равно достаточно для того, чтобы понимать, что за активность сети происходит, это все равно достаточно для того, чтобы понять, кто у вас сожрал весь интернет, но, соответственно, это, во-первых, не требует какого-то колоссального объема дискового пространства, а, во-вторых, оно все равно дает более-менее красивую усреденную картинку по тому, как загружены наши роутеры, чем они загружены. И задачи, которые возникают в сети предприятия, эта штука решает целиком и полностью. NetFlow будет оперировать термином поток, и потоком будет называться совокупность пакетов с одинаковыми свойствами. То есть, если мы говорим про NetFlow версии 5, их там было много разных версий, то, во-первых, у потока все пакеты будут с одинаковым IP-адресом отправителя-получателя. Само собой, разумеется, что если через роутер проходят пакеты,

и мы говорим, что вот эти пакеты несут в себе там их типичную сессию с одного узла на другой, то IP-шники там, естественно, будут одинаковые. Одинаковые будут указания, что внутри лежит, одинаковые будут порты, если мы говорим про TCP, UDP, если там будет ICMP, например, то тип и код должны быть одинаковые. Одинаковый Type of Service и одинаковый логический интерфейс входа. То есть, если у нас приходят одни и те же, как бы, приходят пакеты сначала с одного интерфейса с одинаковыми IP-шниками, потом с другого интерфейса с такими же IP-шниками, то они будут направляться в сеть назначения, неважно как, но они при этом будут относиться к разным потокам. Потому что интерфейсы, через которые вошел один поток, интерфейс, в которой вошел другой поток, они будут различаться. Вот эти вот семь пунктов нужно будет запомнить. То есть сначала входящий логический интерфейс, IP-шник отправителя, IP-шник получатель, указание еще внутри, порт отправителя для TCP, UDP,

порт получатель для TCP, UDP или тип плюс код для ACMP и, соответственно, type of service. Вот эти семь элементов для экзамена нужно будет примерно представлять. Давайте попробуем посмотреть, как настраивается все это дело на цисках. То есть то, что настраивать это надо, я думаю, догадываются все. Но в реальности очень немногие решаются отслеживать в сети состояние устройств. Ну, типа, потому что, а что расстраиваться? Ну, будет оно ругаться, что там интерфейс сдох на роутере. Типа, кто эти логи все равно читать будет? Никто не будет читать. Ну, по-хорошему, конечно же, нужно собирать информацию с железок, нужно понимать, когда у вас сеть работает корректно, когда она деградировала. У меня был замечательный пример. В моей практике, когда я работал в компании, у нас была специальная комната, в которой сидели дежурные, и эти дежурные реагировали на какие-то инциденты в сети. И у нас там был светофор. То есть мы купили списанный светофор,

и у него был красный, желтый и зеленый светофор. И, соответственно, если у нас в сети происходила какая-то авария, в комнате дежурного этот красный светофор загорался, и начинала работать сирена. И дежурные разбирались, что там такое случилось. Если просто сеть деградировала, но сервис при этом продолжал работать, значит, у нас там загорался желтый свет. Ну и обычно зеленый свет не горел, потому что он слишком яркий был. Но там такая лампочка стояла маленькая-маленькая. Она просто едва-едва подсвечила зеленый свет. И вот система мониторинга, она как раз отслеживала, насколько хорошо, насколько корректно у нас все работает в сети. И если вдруг она отслеживала, что что-то происходит некорректное, что что-то отличается от бейзлайна, она на этот самый светофор подавала команду «включайся». Пора загореться красным. Вот. Так что мы должны будем на всех сетевых устройствах отслеживать их состояние, должны будем отслеживать интерфейсы, через которые ходит трафик, не перегружены ли они.

Должны будем знать, как в норме загружены эти интерфейсы и как они загружены прямо сейчас. Мы должны будем собирать все логи. И сейчас некоторые команды, которые на CISC можно будет использовать для настройки мониторинга, мы с вами посмотрим.