Мониторинг Cisco IOS

Продолжаем говорить про мониторинг сетевых устройств в рамках нашего курса iSind2. И применительно к цискам посмотрим на то, как там настраиваются SNMP, Syslog и NetFlow. Настраивается всё легко. Если у нас есть цисковские устройства, свичи, роутеры, то мы можем заставить их отдавать информацию с помощью SNMP. Штатно в них уже встроен SNMP-агент. И если вы хотите забирать с них информацию о том, как они работают прямо сейчас, то это делается достаточно легко. С точки зрения настройки сетевого устройства, по большому счёту, достаточно сделать две вещи. Первое — сказать, какой тип SNMP-аутентификации вы хотите использовать. Если вам достаточно использовать SNMP с аутентификацией по Community String, то просто указывайте SNMP-сервер, Community. Дальше указывайте тот самый Community String. Здесь используется public как стандартный Community String.

И указывайте доступ. Если мы используем Community String public, то это доступ на чтение, read-only. И хорошая идея будет сказать, из-под каких IP-адресов вы разрешаете менеджерам подключаться к вашему агенту. В нашем случае циферка 99 будет указывать на то, что к этому роутеру вы разрешаете подключаться только тем менеджерам, у которых IP-адреса попадают под Access List 99. А в Access List 99 вы указываете, что IP-адреса должны быть в сети 192.168.1.0 с маской /24. Тем самым вы говорите: у вас есть роутер, у него есть набор IP-адресов, смотрящих в разные стороны, но вы при этом говорите, что вы точно знаете, что сеть управления, где у вас админы сидят, где у вас находится NMS, она 192.168.1.0/24. Вы говорите: из-под этих IP-адресов подключаться можно,

неважно, откуда трафик пришёл. В любом случае мы разрешаем подключаться к нашему SNMP-агенту при предъявлении Community String public только тем, кто попадает под этот Access List. И дальше с некоторого компьютера вы можете отправлять SNMP Get Request-ы и получать на них Response. Самый простой способ, как это можно сделать — использовать утилиту snmpget, которая сравнительно стандартная. Вы должны будете указать в этой утилите, какую версию SNMP вы используете, какой Community String вы используете, указать адрес, к которому вы подключаетесь. Здесь у меня используется адрес switch.network.education.ru. Понятное дело, что это DNS-имя, которое резолвится в 192.168.1.17. Это просто обычное DNS-имя. Можете указывать сразу IP-адрес. И дальше указываете, какой объект вы хотите запросить.

Если мы используем snmpget, то мы должны будем запросить ровно один объект, и нам его результат вернут. В нашем случае мы запрашиваем объект с идентификатором 1.3.6.1.2.1.1.1.0. И нам возвращается... Почему 1.1.1.0? 1.1.5.0 здесь. И нам возвращается 1.3.6.1.2.1.1.5.0. Это hostname или, более строго, system name. Показывается, что результат имеет тип строка, и строка называется switch. Допустим. Далее. Что ещё здесь можно будет посмотреть? Если вы заранее знаете, какой OID вас интересует, то вы прямо в явном виде можете его заказывать. Можете в свою систему NMS сказать: отслеживай на графике состояние определённого счётчика и рисуй красивую картинку, как этот счётчик изменялся. Очень типичное явление для загрузки центрального процессора.

Вы указываете, что вас интересует загрузка процессора, и вы на графике рисуете, что прямо сейчас загрузка 22%, секунду назад было 21%, 2 секунды назад было 23%, и он там плюс-минус в районе 20% ползает. И у вас получается график, как изменяется во времени загрузка процессора. Можно использовать счётчики, которые считают абсолютное значение, допустим, трафика, прошедшего через интерфейс, и дальше вы, зная, с какой частотой вы запрашиваете этот счётчик, делите одно на другое и получаете по разнице показаний счётчиков за разницу во времени среднюю скорость прохождения пакетов через интерфейс. Если вы хотите запросить сразу много различных значений разных объектов, и вы заранее не уверены в том, какой именно объект вы хотите получить, то для этого есть утилита, которая называется snmpwalk. Она перебирает всё дерево.

Мы говорим: нас интересует не 1.3.6.1.2.1.1.1.0, который мы заранее почему-то знаем, что это sysName или что-то ещё, а говорим: перебери нам всё дерево 1.3.6.1.2.1.1, и дальше там будет много различных параметров, которые в этой ветке дерева находятся. Покажи всё. И показывает нам. 1.3.6.1.2.1.1.1.0 — показывает system description. Если бы у нас был словарик, он бы сказал, что это sysDesc.0. Дальше показывает следующий объект: 1.3.6.1.2.1.1.2.0 — это system object ID. Это объект, который имеет тип переменной OID, то есть он ссылается на какой-то другой объект. И если мы посмотрим в словарике, в MIB, что это за объект он нам вернул, мы узнаем, что это расшифровывается как org, 1, дальше dot, 3, internet,

так, 3, здесь ISO 1, 3, 6, 1, 2, 1.3.6.1 — нет, не 2, а 4, дальше 1.9.1.1643. Вот этот OID, который он нам вернул, я пытался расшифровать. И мы видим, что здесь у нас вернулось что-то явно цисковское, что это явно какой-то продукт Cisco, и Catalyst 3850, 48 портов. Видимо, система нам пытается намекнуть, что конкретно этот свич, который мы сейчас пытаемся запросить, это, судя по всему, свич 3850. Окей, пусть будет так. Система нам сказала, что конкретно это устройство является Catalyst 3850, конкретным свичом,

который можно будет взять и посмотреть спеки его. System uptime — понятное дело, uptime. Показывается количество тиков, микросекунд, прошедших с момента запуска системы, 28 тысяч. Что-то для микросекунд маловато будет. Да. 4 минуты, 43 секунды, 79 сотых. Нет, нормально. Дальше показывается некая строчка, которая называется System Contact. Это просто текстовая строчка, и в неё имеет смысл заносить, как правило, контакты человека, который эту циску настраивал, или контакты компании. На случай, если вдруг от этой железки потом потеряются доступы или что-то ещё, можно будет по SNMP понять, что это вообще за устройство, и главное, кто знает, как оно настроено и почему оно настроено именно так. Я рекомендую вам,

если вы настраиваете для кого-то железку целиком полностью, и вы отдаёте её в распоряжение клиента, зная, что клиент не будет в неё залезать, оставьте свой контакт. Тот человек, который будет после вас её настраивать, он вам скажет большое спасибо за то, что сможет к вам обратиться и выяснить, почему вы использовали такую конфигурацию, а не какую-то другую. System name — это обычный hostname. System location — это просто текстовая строчка, которая указывает, где стоит железка. Очень удобно, когда вы перебираете все устройства в сети. Опять же, если мы говорим про то, что это защищено на уровне сети, что не каждый может подключиться к устройству, мы на уровне NMS можем сразу понять, где конкретная железка с конкретным IP-адресом в сети 192.168.1.17 расположена. Опять же, имеет смысл здесь указать просто какую-то текстовую строчку, из которой будет сразу понятно, что это за железка, где она стоит, в какой стойке, в какой комнате, в каком юните, для того чтобы, если мы хотим найти эту железку физически,

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

Поэтому если мы хотим сказать, что дебаги отсылать не надо, то команда logging trap informational как раз позволит нам сказать, что отсылается только хотя бы сколько-то полезная информация, а дебаги полезной информацией не являются. В то же время можно включить и дебаг, если очень сильно хочется. Дальше. Если у нас Cisco генерирует сообщения, которые потом отправляются на syslog, мы уже говорили, что там есть однобайтовый заголовок, сам syslog-овский, в котором есть facility и level. Facility — это подсистема, номер журнала, в который сваливаются сообщения. Level — это важность, которую мы указываем в заголовке syslog. Но само сообщение, которое генерирует Cisco, тоже в себе несёт facility и тоже в себе несёт важность сообщения. И когда у нас пробегает сообщение на консоли, например, вот такого типа, на самом деле внутри этого сообщения закодировано много всякой разной информации.

Во-первых, сначала тут стоит процентик, потом после процентика — LINEPROTO. И LINEPROTO называется в Cisco подсистемой, facility. Это не то, что в facility syslog, когда мы указываем, это журнал FTP, а это журнал сообщений, а это журнал какой-нибудь ещё. Здесь мы просто текстом внутри строчки после процента, но перед первым дефисом пишем, что за подсистема вызвала конкретное сообщение на консоль. Понятно, в нашем случае это LINEPROTO, протокол канального уровня, из битиков у нас собираются кадрики — про кадровый уровень, про канальный уровень система что-то нам хочет рассказать. Дальше. После дефиса показывается циферка. Это severity. Это такая же severity, как в syslog. Cisco проставляет severity и в текстовой строке, и в заголовке проставляет level одинаковым образом. Если у нас сообщение с уровнем 5, мы понимаем, что это notification.

Вроде ничего страшного, но имеет смысл на это обратить внимание. И она пятёрку ставит и в тексте, в этой строке, и в заголовке syslog тоже проставляет пятёрку. Дальше. После очередного дефиса ещё одно мнемоническое сообщение. Это рассказывается уже про то, что конкретно случилось в рамках указанной подсистемы. LINEPROTO — это подсистема, которая вызвала событие. Пятёрка — это важность. UPDOWN — это что за событие. Если вы потом будете хотеть распарсить эту текстовую строчку, то вы как раз можете по предсказуемым признакам определить, где закончилось одно поле, где началось другое. Процент вполне однозначно определяет, что началось facility. Дальше следующий дефис означает, что началось severity. Следующий дефис означает, что началась мнемоника. И потом после двоеточия и пробела идёт уже само текстовое сообщение. Дальше. Текстовое описание.

Понятное дело, что оно полезно для человека, если он будет читать, что произошло. Эту штуку вы распарсите для того, чтобы машина могла понять, что произошло. А эту штуку будет читать, конечно же, человек. И есть смысл в такие сообщения добавить немножко информации, которую Cisco по умолчанию не добавляет. Или добавляют не все. Например, можно будет сказать, что ваша Cisco должна будет пронумеровать все сообщения и отправлять эти порядковые номера в самом сообщении. Если у вас есть сообщение system, чего-то там, configured from console, само сообщение, которое мы отправляем, оно, конечно, очень интересное. Но есть нюанс, который заключается в том, что если мы отправляем сообщения с нашей Cisco в сторону syslog-сервера, которые рассказывают, что её проадминили, есть гипотетический шанс того, что некоторые сообщения не будут доставлены до syslog-сервера. Потому что, может быть, какой-то злобный администратор взял, проадминил железку и отключил возможность syslog вообще.

Потом чего-то там проадминил, потом снова включил syslog. И у нас в журнал, который попал на сервер, не вошли некоторые сообщения, которые злоумышленник решил скрыть. Но в этом случае будет видно, что в сообщениях, которые пришли до syslog-сервера, есть разрыв. Что там идёт, допустим, 21-е сообщение, 22-е, 23-го нету, а 24-е — меня кто-то сконфигурировал. Это намёк на то, что кто-то выключил syslog, чего-то там такое наделал, и включил syslog обратно, и какое-то сообщение пропало. Если вдруг некоторые сообщения не отсылаются на syslog-сервер, то их номера всё равно будут при этом такую ситуацию раскрывать достаточно явно. Есть, правда, нюанс, который заключается в том, что дебаги тоже получают номера, поэтому если вы включаете дебаг, и дебаги у вас не отправляются на syslog, то разрывы будут.

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

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

Всё это делается в контексте Service Timestamps. Указываете Service Timestamps. Log Date Time. Это указывать это самое время. Здесь можно указать таймзону, соответственно, что будет использоваться локальная таймзона. И можно ещё указывать, что метки времени генерируются либо от начала работы системы, либо они будут генерироваться по часам системы. Понятное дело, что если вы используете часы системы, но после ребута, например, у вас батарейка, батарейка, которая на материнской плате стоит, она, допустим, испортилась, то часы будут постоянно сбрасываться, и время будет показываться не совсем корректное. Если у вас нет возможности на устройствах постоянно держать актуальное время, в силу, например, того, что устройства постоянно ребутаются и актуальное время теряют, в этом случае имеет смысл просто сразу сказать,

давайте uptime делать и всё. Так, далее. Про NetFlow. NetFlow на интерфейсах вы должны будете указать, что вы хотите собирать, и после того, как вы собираете статистику пакетов, проходящих через интерфейс, вы должны будете её куда-то отправить. Здесь нас подкарауливают несколько сложностей. Первая сложность заключается в том, что каждый пакет через роутер должен войти и выйти, поэтому он пройдёт фактически через два интерфейса, входящий и исходящий. Вы можете отдельно настраивать интерфейсы, на которых вы отдельно включаете отслеживание входящих и исходящих пакетов. Делается это командами либо IP Flow Ingress, либо IP Flow Egress. Ingress, понятное дело, на вход, и Egress на выход. Вам нужно будет спланировать, на каких интерфейсах вы хотите включить какой режим отслеживания. Дело в том, что если у вас есть, например, роутер, у которого есть один выход в интернет,

и вы, давайте для простоты, на нём не запускаете NAT, то если у вас, например, несколько разных входящих интерфейсов есть, и вы хотите отслеживать, что у вас происходит с интернетом, но не отслеживать трафик, который идёт между интерфейсами, в этом случае вам имеет смысл включить мониторинг на интерфейсе, смотрящем в интернет, и указать там и IP Flow Ingress, и IP Flow Egress. И в этом случае вы получите отслеживание только пакетов, смотрящих в интернет, но не внутреннего трафика между интерфейсами. Но есть нюанс. Чаще всего у нас запускается NAT, и, соответственно, NAT нам будет портить здесь картинку, потому что после того, как NAT перебил IP-шники, на выходе с интерфейса будем видеть только публичный IP-шник, в который, соответственно, наш NAT перебил source-адреса. И в обратную сторону мы тоже будем видеть только IP-адрес назначения, это наш публичный IP-шник. Мы не будем видеть отдельные частные IP-шники, которые уже после NAT не видно.

Поэтому если мы хотим отслеживать, кто куда ходил на роутере, на котором работает и NAT тоже, то, соответственно, мы не должны будем отслеживать интерфейс, который смотрит в интернет. Мы здесь не отслеживаем ничего. Но мы отслеживаем всё на интерфейсах, которые у нас смотрят вовнутрь. На всех внутренних интерфейсах должны будем сказать — отслеживаем то, что приходит, отслеживаем то, что уходит. И опять же есть нюанс. Нюанс заключается в том, что если вы включаете на внутренних интерфейсах, то вы тем самым будете неизбежно отслеживать и трафик, который идёт между интерфейсами. И если у вас один частный узел к другому частному узлу пытается обратиться, то, соответственно, в коллектор информация об этом потоке будет попадать. Ещё одна проблема будет заключаться в том, что если вы включаете мониторинг и на вход, и на выход, то здесь вы говорите, и на вход мониторим, и на выход мониторим, для того чтобы трафик, который идёт в интернет,

у нас и туда, и обратно тоже считался. Если трафик будет идти с одного внутреннего узла на другой внутренний узел, то вы его посчитаете дважды. Один раз, когда он войдёт в роутер, а другой раз, когда он выйдет из роутера. Поэтому вы должны будете очень аккуратно посмотреть, исходя из того, какой паттерн трафика характерен для вас, что конкретно вы хотите считать, соответственно, на каких интерфейсах какой режим отслеживания вы хотите применить. IP Flow Ingress или IP Flow Egress. При этом надо будет знать такой момент, что трафик самого роутера в Egress-потоке попадать не будет. Это специфическая особенность Cisco, что сам роутер свои собственные пакеты посчитать не всегда может. Дальше. После того, как вы указали, на каких интерфейсах вы собираете информацию о потоках, надо будет указать, куда сливать статистику. Команда будет настраиваться,

точнее, две команды нужно будет настроить. Они обе будут находиться в контексте IP Flow Export. И мы указываем IP Flow Export Destination, указываем IP-шник и, соответственно, порт. Стандартный порт 9996. И второй момент, который нужно будет указать, это какую версию NetFlow нужно будет использовать. В NetFlow много разных версий, по факту, с теми, с которыми, скорее всего, вам придётся работать — имеет смысл из всех возможных вариантов рассматривать только эти. Первая версия поддерживает только IPv4, и она откровенно древняя, но она до сих пор ещё поддерживается. Вряд ли вы когда-нибудь столкнётесь с софтом, который поддерживает только первую версию. Она на всех цисках поддерживается, но, соответственно, если есть возможность использовать что-то более свежее, то имеет смысл использовать что-то более свежее. И коллекторы практически все поддерживают хотя бы какую-то версию, кроме первой. Поэтому первую версию использовать совсем не надо, она примитивная.

Пятая версия — это такая основная рабочая лошадка протокола IPv4. Пятая версия поддерживает только IPv4-мониторинг, но зато она поддерживается во многих-многих коллекторах, в том числе и бесплатных. Поэтому если вы хотите использовать NetFlow, если вы смотрите на то, что поддерживает ваша циска, смотрите на то, что поддерживает ваш коллектор, если вам достаточно только IPv4, то можно использовать пятую версию. И она вас удовлетворит, скорее всего. Если вас не устраивает пятая версия, то, скорее всего, вам придётся использовать либо девятую версию, которая работает и с IPv6, и с различными не совсем стандартными вложениями, типа того же самого MPLS. И плюс она там ещё много разных других штук умеет мониторить. Но девятка, к сожалению, поддерживается не всеми коллекторами. Многие коллекторы, особенно бесплатные, испытывают некие сложности

с поддержкой девятой версии. Есть ещё восьмая версия, но она экстремально редкая. Она на некоторых цисках поддерживается, но коллекторов, которые умели бы её использовать, днём с огнём не сыщешь. И есть ещё протокол NetFlow. Cisco его называет NetFlow 10-я версия. На самом деле считается, что это отдельный, самостоятельный протокол, который лишь основан на NetFlow. Он называется IPFIX. Поддерживается он, как правило, на достаточно жирных роутерах, например, провайдерских. И он умеет работать и с IPv6, и с BGP NextHop. Он умеет смотреть, куда трафик идёт. Не просто через какой интерфейс он вышел, а куда он дальше пойдёт. Он много чего умеет, и он стандартный. Поэтому он поддерживается на железках очень многих вендоров. В принципе, если вы работаете не с оборудованием Cisco, то можно ещё рассмотреть вариант с sFlow. По сути своей то же самое, но точно такой же, но другой.

Он абсолютно стандартный, но циски его не умеют. Соответственно, вам нужно будет указать из того множества вариантов NetFlow, который поддерживает ваша циска, тот вариант NetFlow, который также поддерживает ваш коллектор. И, естественно, нужно будет указать максимально возможную версию из тех, которые поддерживаются и роутером, и коллектором. Когда у вас NetFlow сливается, он накапливается в памяти роутера, а потом отправляется на коллектор. Вы можете посмотреть, что конкретно ваш роутер насчитал за последнее некоторое время. Команда будет show ip cache flow. Она покажет именно текущее состояние кэша NetFlow, что в ближайшее время будет сброшено. Здесь есть много всякой разной интересной информации. Во-первых, показывается распределение по размерам пакетов, которые ваш роутер отследил. Здесь показывается,

что совсем мелких пакетов, которые недопустимо маленькие, не было вообще. Пакетов минимального размера было некоторое количество. В нашем случае было 40%. И дальше распределение по размерам пакетов. Следующий размер — 96 байт. Скорее 96 байт. Это оставшиеся 60%. Других пакетов не было вовсе. И общее количество пакетов, которые он насчитал, — 15 штук. Понятное дело, что в реальности вы на такого масштаба нагрузку вряд ли когда-либо попадёте. В реальности у вас всегда будет через роутер проходить сильно больше пакетов. Но просто чем больше пакетов есть, тем больше здесь будет вывод этой команды. Поэтому вывод снят с ненагруженного роутера. Показано, сколько потоков наш роутер насчитал. Показывается, что он один активный поток видит. Этот активный поток

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

Какой порт получателя. Какой порт источника, простите. Какой порт получателя. Destination порт в нашем случае, число 0017. Это 16-ти личное число, которое на самом деле в действительном виде будет 23. Ну, 23-й порт. Хорошо понятно, что это телнет. И, соответственно, source порт здесь 0407. Это 16-ти личное число. Опять же, 1020, сколько там, 1028, 1029, 1029, по-моему. Ну, то есть, опять же, понятно, что здесь динамический порт. Когда мы отправляем пакеты на телнет, они отправляются из-под случайного порта. И вот можно будет, в принципе, если вам интересно просто посмотреть, какая у вас нагрузка бегает в сети, но лень поднимать коллектор, вы можете просто сказать IP flow ingress, IP flow egress на ваших роутерах, накопить все полученные данные в cache netflow, которые у вас сам роутер будет хранить. Он никуда их не будет отсылать, он просто их хранит. И дальше вышел IP cashflow, посмотрите, что там за трафик бегает. То есть, по крайней мере,

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

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

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