Возможности технологии Cisco IOS IP SLA. dark web to buy cc, buy cc with bin

Данная статья, дает представление о возможностях оценки качества, мониторинга сети, а также принятия решений оборудованием Cisco с помощью технологии Cisco IOS IP SLA.
Аннотация
             О необходимости обеспечивать высокое качество, наряду с контролем, передачи данных по сети Интернет сказано много. Появление сервисов, таких как VoIP и IPTV диктуют свои условия. Данная статья, дает представление о возможностях оценки качества, мониторинга сети, а также принятия решений оборудованием Cisco с помощью технологии Cisco IOS IP SLA.
Введение.
            На текущий день существует множество программных и аппаратных решений контроля качества передачи данных по сети Интернет. Я не буду проводить обзор существующих решений. Возможности Cisco IP SLA часто используется для оценки качественных характеристик сети различными программными продуктами, предназначенными для мониторинга состояния сети. Однако не все программные продукты мониторинга сети поддерживают эту технологию. Описываемые методы могут быть использованы как для построения своей системы мониторинга, так и для расширения существующей.
Аббревиатура SLA расшифровывается как Service Level Agreements, что можно перевести как соглашения об уровне обслуживания. Первоначально технология называлась RTR Round Trip Reporter – что можно перевести как агент, информирующий о задержках. В зависимости от версии IOS команды по конфигурированию устройства могут различаться. Подробно об этом можно почитать здесь . Я буду описывать все на примере IOS выше 12.4. Команды конфигурирования могут отличаться в различных версиях IOS-а.
Суть технологии.
            В Cisco IOS встроены программные тесты состояния сети. На текущий момент существует более десятка тестов. Различные IOS поддерживают различные наборы тестов. Например мой Cisco 2821 поддерживает следующие тесты:
Подробно о каждом тесте говорить смысла нет. Способы конфигурирования и что можно получить, используя тот либо иной тест, можно узнать на сайте Cisco. В общем же случае, Cisco умеет:
Одним из самых ценных тестов, на мой взгляд, является jitter тест. На нем стоит остановиться подробно.
Jitter тест.
   Jitter тест особенно ценен в тех случаях, когда вы контролируете систему предоставляющую кроме передачи данных еще и VoIP.Для понимания самого теста, что он дает, необходимо знать что такое jitter-ы и как они влияют на качество голоса.
   Jitter с английского языка можно перевести как дребезжание, в сети Интернет это понятие я бы определил как межпакетную вариацию длин временных задержек при передаче пакетов (сумбурно, но по другому выразиться сложно).
   Как известно, на качество передачи голоса в сети Интернет влияет 3 параметра, это используемый кодек, задержки и потери пакетов. От кодека зависит качество аналогово-цифровых преобразований. Задержки влияют на восприятие человеком качества тем, что при задержках более 300 Миллисекунд в одну сторону, хотя голос передается одновременно в обе стороны, человеку кажется, что его не слышат и надо говорить в режиме односторонней рации, то есть сказал фразу, услышал ответ, сказал следующую. Потери пакетов неизбежно ведут к ухудшению связи, так как не все звуки доходят до собеседника. Вы, наверное, заметили, что при определении качества, Jitter-ы не упоминаются, однако их величина может создавать ситуации аналогичные потерям пакетов.
   Возьмем, к примеру, кодек g729, обычно этот кодек передает голос разбивая его на 50 пакетов в секунду. Интервал посылки пакетов 20 Миллисекунд. Рассмотрим идеальный случай без Jitter-ов, с задержкой 70 Миллисекунд.
В реальном же мире мы часто имеем другую картину.
В идеальных условиях, второй пакет должен был дойти на 90-стой миллисекунде, на самом деле он пришел на 130-той. Это пакет с позитивным jitter-ом, четвертый должен был прийти на 130-ой, а пришел на 115, пакет с негативным jitter-ом. Для сглаживания подобных ситуаций обычно VoIP устройства используют jitter буфер, величина буфера измеряется не в пакетах, но в миллисекундах. Обычно используется адаптивный jitter буфер, величина которого может меняется во время разговора в зависимости от условий сети. Например, на моём Cisco 2821 он по умолчанию установлен с такими параметрами:
Буфер адаптивный, нормальная его величина 60 миллисекунд, может достигать 250 миллисекунд, и минимальная, при очень хорошей сети – 40 миллисекунд. В данном примере, очевидно, что даже наличие буфера не позволит избежать потери пакета под номером 5. Этот пакет будет просто отброшен, и для разговора потерян. Возможно, более понятное описание процесса потери пакетов в результате наличия jitter-ов можно найти здесь 
Jitter тест позволяет получить представление об уровнях задержек, потерь пакетов и jitter-ов, при этом, так как трафик двунаправленный, то можно увидеть что происходит при передаче пакетов в каждую из сторон. Перейдем к конкретному примеру, который у меня настроен и работает.
Ситуация была следующей: у меня по Интернету гоняется голос между тремя филиалами, связь с одним филиалом никаких нареканий не вызывает, работает почти идеально, связь со вторым – не удовлетворительна. Согласно CDR (Call Detail Records) собираемым на Radius Server-е с помощью Cisco VSA (Vendor Specific Attributes) видно, что уровень ICPIF при связи с филиалом c идеальной связью на уровне 11, с другим – примерно 22. Как известно, чем ниже ICPIF, тем лучше связь. В моем случае, как и описано на сайте, связь с одним офисом, немного хуже очень хорошего (при учете ICPIF необходимо делать поправку на ожидания пользователей, так как филиалы географически удалены, а связь между ними практически бесплатна, то ее можно считать очень хорошей в данном случае), во втором, немного хуже адекватного. Необходимо было выяснить, что приводит к таким результатам и после устранения причины – контролировать появление подобных ситуаций. Для этого были сконфигурированы 2 jitter теста с каждым из филиалов вот таким образом
Относительно вариантов конфигурирования рекомендую проконсультироваться на сайте Cisco. В данном конкретном случае запускается 2 jitter теста, первый между маршрутизаторами Cisco с IP ZZZ.ZZZ.ZZZ.ZZZ и XXX.XXX.XXX.XXX, второй – между ZZZ.ZZZ.ZZZ.ZZZ и YYY.YYY.YYY.YYY. Генерируется 1000 пакетов эмулирующих g729 кодек с полезной нагрузкой 20 байт на пакет, тест запускается 1 раз в 5 минут. Другими словами, раз в 5 минут каждый тест эмулирует 20-ти секундный разговор по g729-му кодеку.
Весьма важный момент: jitter тест возможен только между двумя устройствами Cisco поддерживающими IP SLA тесты. Вы не сможете запустить данный тест между маршрутизатором Cisco и, например, компьютером или маршрутизатором другого производителя. Кроме того, по умолчанию, данный тест с произвольным маршрутизатором Cisco не возможен, для того, чтобы все заработало необходимо включить на маршрутизаторах с IP XXX.XXX.XXX.XXX и YYY.YYY.YYY.YYY так называемый responder командой
ip sla monitor responder
В данном случае, маршрутизаторы с включенным responder-ом, выполняют функции ассистентов для тестов.
С помощь командной строки результаты последнего выполнения тестов можно посмотреть командой
sh ip sla monitor operational-state
Можно также посмотреть накопленные за некоторый промежуток времени (по умолчанию час) результаты командой
sh ip sla monitor collection-statistics
И то и другое ценно, однако для того чтобы реально оценить ситуацию в течение длительного промежутка времени не годится. Для адекватной комплексной оценки необходимо периодически опрашивать маршрутизатор, сохранять результаты в базу данных, строить графики. Для опроса маршрутизатора удобней всего использовать протокол SNMP. Можно, конечно использовать SNMP MIB OID-ы для collection-statictics, однако, на мой взгляд, проще использовать результаты последнего теста. Раз в 5 минут проходит тест, раз в 5 минут необходимо опрашивать устройство по результатам. С помощью Cisco SNMP Object Navigator-а можно за 5 минут найти интересующие вас OID-ы, в данном случае вот они 
Обратите внимание, результатом каждого теста является 52 значения, которые можно посмотреть. По названию каждого и его описанию можно представить себе, что означает каждый из параметров. Возникает вопрос, какие из них важны, какие – нет. На самом деле, я думаю, важны почти все.
Распространенными инструментами опроса устройств по SNMP с целью получения статистических графиков являются MRTG и Cacti (Кактус). Однако, в данном случае конфигурирование более 50-ти параметров для каждого теста очень накладно с точки зрения человеческих ресурсов. Поэтому, весьма оправдано использование простейших скриптов.
Скрипты и инструкции по установке представлены в приложении, работают под FreeBSD 5.3. Под другими NIX ОС, возможно, необходимо будет сделать модификацию. Под Windows – в принципе можно портировать. Используются RRDTool, perl с CGI, snmpwalk, cron daemon.
Работу скриптов можно описать в нескольких словах. Принцип такой же как и у MRTG и Кактуса. По cron-у запускается скрипт, который осуществляет snmpwalk по интересующим нас значениям и заполняет базы данных. В качестве базы данных используется Round Robin Database сформированная и обрабатываемая утилитами rrdtool. По запросу пользователя формируются графики на web сервере с помощью perl CGI. Графики можно построить за произвольный период последних 8-ми суток с уровнем детализации равным одному часу.
С помощью незначительных модификаций скриптов можно добавить на рисунки еще несколько SLA Jitter тестов или изменить период, за который необходимо получить графики. Для этого необходимо понимать, как работает rrdtool и иметь базовые знания perl.
 Ниже – скриншоты работы скриптов
Относительно интерпретации графиков величин можно говорить долго, но я всего лишь потрачу свое и ваше время, так как не существенные для одной сети отклонения могут быть существенными в другой. Лучше самому настроить и посмотреть, что происходит на самом деле. Отмечу лишь один момент, Cisco, в jitter тесте вычисляет 2 основных параметра качества голоса это MOS и ICPIF, но вычисляет их не совсем корректно. При оценке этих параметров не учитывается потеря пакетов, которая возникает из-за jitter-ов, в моем случае для двух филиалов MOS и ICPIF были примерно одинаковы, на самом деле качество очень сильно отличалось именно из-за наличия огромных jitter-ов в одном из филиалов.
Что мне дал настроенный мониторинг. Оценив наглядно, почему плох один из каналов, я попросил провайдера поменять мне модем. После смены модема качество улучшилось, однако исходящий канал в филиале работал не очень хорошо, из-за того, что он оказался узким, периодически возникали огромные jitter-ы. Так как мой исходящий канал мне полностью подвластен, то я раскрасил трафик и настроил качество обслуживания в своей сети. После чего проблема была закрыта.
Вообще вариантов использования данного теста может быть много. Например, вы решили проверить, как влияет определенный параметр обеспечения QoS прописанный в пакете на качество передачи данных в вашей сети по сравнению с другим параметром для QoS. Для этого запускаете 2 теста между двумя устройствами, с различными сконфигурированными параметрами QoS (при настройке теста используется поле tos пакета) и смотрите в чем разница. Это я, например, использовал после того, как настроил качество в обслуживании для своей сети и проверял, насколько настроенный QoS улучшил параметры. Или, пытаетесь определить, как влияет последняя миля в удаленном филиале на качество связи с вами, для этого просите провайдера настроить у себя responder и сравниваете значения для тестов между своими Cisco и своим Cisco и Cisco провайдера.
После того, как вы добились для себя приемлемого качества канала можно отключить тесты, но можно и оставить их включенными для ведения статистики либо оперативного выявления неудовлетворительных результатов тестов. На графиках прекрасно видно как в нормальной ситуации ведет себя сеть, поэтому настроить оповещения о ненормальном ее поведении довольно просто. Как я уже упоминал, Cisco умеет сообщать о результатах тестов с помощью SNMP и отсылать syslog сообщения. Вам необходимо настроить агента, получающего сообщение от Cisco SLA мониторов на оперативное оповещение администратора приемлемым для вас способом (например, по электронной почте или popup-ами на рабочем столе администратора). Также необходимо сконфигурировать Cisco на отсылку сообщений по результатам тестов, о которых вас необходимо информировать. Подробно о последнем почитать здесь 
Например, я хочу получать SNMP и syslog сообщения о событиях, когда средний jitter для пакетов идущих ко мне становится больше 10 Миллисекунд и возвращается к значениям меньше 10 Миллисекунд, таким образом, отслеживая ситуации, которые я считаю предельно допустимыми для моей сети. Сконфигурировав вот так:
ip sla monitor reaction-configuration 1 react jitterDSAvg threshold-value 10 10 threshold-type immediate action-type trapAndTrigger
В результате я получаю такие SNMP и syslog сообщения
12:00:02 syslog snmptrapd[479]: 192.168.100.1 [192.168.100.1]: Trap , DISMAN-EVENT-IB::sysUpTimeInstance = Timeticks: (1319928900) 152 days, 18:28:09. 00, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.9.9.41.2.0.1, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.2.33222 = STRING: “RTT”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.3.33222 = INTEGER: 4, SNMPv2-MI::enterprises.9.9.41.1.2.3.1.4.33222 = STRING: “IPSLATHRESHOLD”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.5.33222 = STRING: “IP SLA Monitor(1): Threshold exceeded for jitterDSAvg”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.6.33222 = Timeticks: (1319928899) 152 days, 18:28:08.99
 12:00:02 192.168.100.1 922441: 12:00:03.023: %RTT-3-IPSLATHRESHOLD: IP SLA Monitor(1): Threshold exceeded for jitterDSAvg
12:05:02 syslog snmptrapd[479]: 192.168.100.1 [192.168.100.1]: Trap , DISMAN-EVENT-IB::sysUpTimeInstance = Timeticks: (1319958896) 152 days, 18:33:08.96, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.9.9.41.2.0.1, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.2.33223 = STRING: “RTT”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.3.33223 = INTEGER: 4, SNMPv2-MI::enterprises.9.9.41.1.2.3.1.4.33223 = STRING: “IPSLATHRESHOLD”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.5.33223 = STRING: “IP SLA Monitor(1): Threshold below for jitterDSAvg”, SNMPv2-SMI::enterprises.9.9.41.1.2.3.1.6.33223 = Timeticks: (1319958895) 152 days, 18:33:08.95
12:05:02 192.168.100.1 922442: 12:05:02.981: %RTT-3-IPSLATHRESHOLD: IP SLA Monitor(1): Threshold below for jitterDSAvg
По получению SNMP трапов и syslog сообщений можно автоматически запустить комплексную проверку состояния сети (например, проверить все значения IP SLA теста, проверить объем и тип трафика, который на текущий момент передается, объем занятой памяти и процент использования процессора на маршрутизаторе, либо другие параметры оборудования) и прислать отчет по почте администратору для последующего анализа. При грамотной настройке можно выявлять аномалии, обнаружить причину и устранить ее до того, как ситуация станет критической. Теперь мы подошли к вопросу пассивного мониторинга сети с помощью IP SLA.
         Если вы настраивали систему мониторинга, то наверняка знаете, что мониторинг может быть пассивным и активным. Активный мониторинг заключается в периодическом опросе тем либо иным методом состояния устройств. Пассивный мониторинг подразумевает ожидание сообщения о событиях от устройств, при этом устройства сами сообщают вам о тех либо иных ситуациях. Правильная система мониторинга должна использовать оба эти метода. События от устройств на станцию мониторинга поступают обычно по протоколам SNMP, с помощью trap-ов, и syslog в виде сообщений. Как настраивается отсылка таких сообщений по результатам IP SLA тестов я уже описывал выше. Для различных конфигурации сети можно использовать любой наиболее подходящий из набора тестов. В случае использования IP SLA тестов станция мониторинга пассивно выполняет свои функции, Cisco же, активно выполняет тесты, таким образом, пассивным этот мониторинг можно назвать только в сточки зрения станции мониторинга.
Возникает резонный вопрос, зачем это нужно, ведь проще опрашивать устройства со станции мониторинга, осуществляя активный мониторинг. Мониторинг с помощью IP SLA тестов следует применять в случаях, когда устройство по отношению к станции мониторинга расположено за Firewall-ом, NAT-ом или вообще не маршрутизируется до станции мониторинга.
Рассмотрим такой пример. У вас есть удаленный филиал, сеть которого логически представлена на рисунке.
В данном примере, маршрутизатор Cisco осуществляет функции NAT для внутренней сети, он расположен в серверной, ваш офис на другом этаже. Switch-и A и B вам не принадлежат, вам выделен отдельный VLAN, проключенный до вашего Switch-а C. Switch C имеет свой IP адрес, однако на нем не прописан default gateway, из соображений политики безопасности. Мониторить рабочие станции сотрудников бессмысленно, так как они могут быть произвольно выключены. Однако вам необходимо оперативно выявлять ситуации когда:
1) Пропадет связь с внешним интерфейсом вашего маршрутизатора
2) Пропадет связь между вашей внутренней сетью и маршрутизатором Cisco.
Для этого, на станции мониторинга настраивается активный мониторинг по ICMP состояния связи офиса с Интернетом. Также, настраивается простой IP SLA echo ICMP тест между Cisco и Switch-ем С. Теперь, пассивный мониторинг выявит ситуации сбоев связи во внутренней сети, активный – во внешней.
            Преимущества такого мониторинга очевидны, вы не тратите внешний трафик на мониторинг внутренней сети (опрашивать Switch в связи с этим можно сколь угодно часто, следовательно, проблема будет обнаружена быстрее), и ваша внутренняя сеть более защищенная, чем, если бы вы открывали наружу ваше оборудование.
            Итак, для данного случая необходимо сконфигурировать IP SLA примерно следующим образом
ip sla monitor 3
 type echo protocol ipIcmpEcho 172.17.31.100 source-ipaddr 172.17.31.1
 timeout 2000
 threshold 10
 frequency 10
ip sla monitor reaction-configuration 3 react timeout threshold-type immediate action-type trapAndTrigger
ip sla monitor schedule 3 life forever start-time now
            Однако, в этом случае при timeout-е, мы получим только SNMP trap сообщение, syslog сообщение не генерируется. При этом сами Trap-ы не совсем читабельны. Например, при обнаружении timeout-а для одного из тестов я получаю вот такой trap
15:51:33 syslog snmptrapd[479]: 192.168.100.1 [192.168.100.1]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1329958030) 153 days, 22:19:40.30, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.9.9.42.2.0.2, SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.3 = “”, SNMPv2-SMI::enterprises.9.9.42.1.4.1.1.5.3 = Hex-STRING: C0 A8 46 02 , SNMPv2-SMI::enterprises.9.9.42.1.2.9.1.6.3 = INTEGER: 1
Когда все приходит в норму – вот такой
16:04:43 syslog snmptrapd[479]: 192.168.100.1 [192.168.100.1]: Trap , DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (1330037041) 153 days, 22:32:50.41, SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-SMI::enterprises.9.9.42.2.0.2, SNMPv2-SMI::enterprises.9.9.42.1.2.1.1.3.3 = “”, SNMPv2-SMI::enterprises.9.9.42.1.4.1.1.5.3 = Hex-STRING: C0 A8 46 02 , SNMPv2-SMI::enterprises.9.9.42.1.2.9.1.6.3 = INTEGER: 2
Проблема в том, что как написал в своем посте http://ioshints.blogspot.com/2007/01/log-ip-sla-failures.html Ivan Pepelnjak, технология IP SLA заточена под SNMP (is extremely SNMP-oriented). Однако в том же тесте описано как можно сгенерировать syslog сообщение. Для этого необходимо воспользоваться возможностями EEM (Embedded Event Manager – Встроенный [в IOS] Обработчик событий). EEM умеет периодически опрашивать SNMP переменные и, в зависимости от их состояния, выполнять различные действия, в частности, генерировать syslog сообщения.
Например, если для описанного выше теста сконфигурировать так:
event manager applet Office1_down
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 1 entry-type value exit-comb or exit-op eq exit-val 2 exit-type value exit-time 600 exit-event false poll-interval 5
 action 1.0 syslog msg “Ping to 172.17.1.100 timeout”
 
event manager applet Office1_up
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 2 entry-type value exit-comb or exit-op eq exit-val 1 exit-type value exit-event false poll-interval 5
 action 1.0 syslog msg “Ping to 172.17.1.100 OK”
То мы будем получать такие syslog сообщения каждые 10 минут при отсутствии внутренней связи
15:07:01.034: %HA_EM-6-LOG: Office1_down: Ping to 172.17.1.100 timeout
15:17:01.038: %HA_EM-6-LOG: Office1_down: Ping to 172.17.1.100 timeout
15:27:01.043: %HA_EM-6-LOG: Office1_down: Ping to 172.17.1.100 timeout
И в случае, когда связь восстановится, получим одно сообщение:
15:34:19.033: %HA_EM-6-LOG: Office1_up: Ping to 172.17.1.100 OK
Вариантов использования IP SLA тестов в целях мониторинга может быть огромное количество. Однако только мониторингом возможности тестов не ограничиваются.
На текущий день не редки ситуации, когда у конечного пользователя Интернет существует множество Интернет каналов предоставляемых одним или несколькими провайдерами. Главное преимущество наличия нескольких каналов связи это минимизирование рисков простоя в случае сбоев. В случае наличия нескольких каналов связи решение о том, через какой из них маршрутизировать трафик можно принимать на основе доступности канала. В классической ситуации, без IP SLA тестов, о доступности канала связи можно судить по состоянию интерфейса. Однако состояние интерфейса не всегда однозначно говорит о доступности канала передачи данных. Например, если у вас маршрутизатор подключен к DSL модему по Ethernet, то в случае сбоя связи в DSL вы не сможете его выявить стандартными способами. Наличие различных IP SLA тестов позволяет выявлять подобные ситуации. На текущий, день в IOS существует возможность принимать решения о маршрутизации на основе результатов IP SLA тестов. Описывать, как все настраивается, я не берусь, так как не использовал такие методы. Однако на сайте Cisco все, как всегда, понятно описано. Вот пример для Policy Based Routing with the Multiple Tracking Options Feature
и для IOS NAT Load-balancing for Two ISP Connections 
Я считаю, что подобные фичи могут часто быть полезными. Однако их функционала не всегда хватает для решения задач.
EEM (Embedded Event Manager – Встроенный [в IOS] Обработчик Событий) позиционируется как средство самодиагностики и устранения проблем самим маршрутизатором. Обычно Обработчик Событий расположен не на маршрутизаторе, а на NMS (Network Management Station – Станция Управления Сетью), сами же события могут быть самыми разными от высокой загрузки CPU и памяти, отключения интерфейса до высокой температуры в корпусе маршрутизатора. В классической схеме маршрутизатор сообщает о событиях на NMS, которая может на их основе выполнить различные действия, начиная от оповещения различными способами администраторов до перезагрузки устройства. Необходимость встроенного обработчика событий обусловлена тем, что не всегда при критических событиях у маршрутизатора будет возможность сообщить о них на NMS. Простейший пример этого – отключился интерфейс маршрутизатора и связь у него со всем миром потеряна. Примеров использования EEM на сайте Cisco множество. Весьма интересная презентация возможностей EEM совместно с языком программирования Тиклем (TCL) здесь  
Наличие IP SLA тестов расширяет возможности EEM, так как тесты могут дать маршрутизатору представление не только о том, что происходит непосредственно с ним, но и в сети. Как было неоднократно упомянуто выше результаты тестов записываются в SNMP переменные и могут генерироваться syslog сообщения, EEM же, в свою очередь спроектирован так, что может реагировать именно на такие события. Использование возможностей EEM совместно с IP SLA может дать весьма интересные, с точки зрения минимизирования времени простоя сети, результаты.
Рассмотрим пример представленный на рисунке
Здесь с левой стороны – центральный офис, ресурсами которого пользуются сотрудники удаленного офиса (с правой стороны). Между офисами провайдером поднята связь точка – точка, на входе каждого офиса – провайдер предоставил модемы, cо стороны офисов на демарке – Ethernet. Между офисами поднят IPSec туннель. Центральный офис имеет постоянный доступ в Интернет, доступ к ресурсам Интернет из удаленного офиса осуществляется через центральный офис. У удаленного офиса есть также связь с Интернет по резервному каналу. Использование резервного канала не приемлемо в обычной ситуации из-за его дороговизны и не очень хорошего качества, в нормальной ситуации интерфейс, через который работает резервный канал в состоянии down. В случае сбоя основного канала можно использовать резервный (он для этого и предназначен). Задача – осуществить автоматический переход на резервный канал, в случае сбоя основного, при этом поднять VPN между офисами.
Если вы поднимали IPSec туннель между офисами на Cisco, то знаете, что туннель привязывается к конкретному интерфейсу, кроме того, в этом случае жестко прописывается IP адрес пира, с которым туннель нужно поднять. В примере, в случае сбоя изменяются оба эти параметра. Переконфигурировать все не сложно, и детали изменения конфигурации не суть важны, главное, что этого нельзя сделать одной командой. Нормальный план изменения конфигурации устройств подразумевает наличие заготовленных конфигураций для того либо иного случая (чтобы не терять время). Конфигурации могут храниться на tftp сервере или во flash памяти маршрутизатора. В случае сбоя основного канала можно просто дать команду и скопировать нужную конфигурацию в running-config маршрутизатора.
Если бы изменения конфигурации делал человек, то все выглядело бы примерно следующим образом:
Рассмотрим теперь, как это можно сделать автоматически только средствами Cisco, не прибегая к помощи NMS или системного администратора. Переключение необходимо делать как на маршрутизаторе A, так и на маршрутизаторе B, для примера рассмотрим только маршрутизатор B.
Первым делом необходимо запустить IP SLA echo ICMP тест на маршрутизаторе, выявляющий недоступность маршрутизатора A таким образом
ip sla monitor 3
 type echo protocol ipIcmpEcho 192.168.70.1 source-ipaddr 192.168.70.2
 timeout 2000
 threshold 10
 frequency 5
ip sla monitor reaction-configuration 5 react timeout threshold-type immediate action-type trapAndTrigger
ip sla monitor schedule 5 life forever start-time now
Каждые 5 секунд проверяется доступность IP адреса 192.168.70.1. Теперь необходимо отслеживать состояние недоступности маршрутизатора 192.168.70.1 в течение, допустим минуты. Если это имеет место, то принимаем меры по изменению конфигурации. Если в течение минуты связь появилась, то считаем, что было ложное срабатывание (ведь, на самом деле потери отдельных пакетов в сети Интернет скорее норма, чем нечто неординарное). Для этого настраиваем 3 EEM обработчика событий.
Итак, обработчик первый, отслеживающий потерю одного пакета до 192.168.70.1.
event manager applet OnePacketLost
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 1 entry-type value exit-comb or exit-op eq exit-val 2 exit-type value exit-time 3 exit-event false poll-interval 5
 action 1.0 counter name lost_count op inc value 1
 action 2.0 syslog msg “WARNING Ping to 192.168.70.1 timeout”
Этот обработчик делает 2 вещи, отсылает сообщения, каждые 5 секунд, когда связь с офисом потеряна и в то же время каждые 5 секунд инкрементирует счетчик lost_count.
Следующий обработчик событий
event manager applet LinkOK
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 2 entry-type value exit-comb or exit-op eq exit-val 1 exit-type value exit-event false poll-interval 5
 action 1.0 counter name lost_count op set value 0
 action 2.0 syslog msg “WARNING LINK to 192.168.70.1 is OK NOW”
Также делает 2 вещи, отсылает одно сообщение, когда связь восстановилась и сбрасывает в ноль счетчик потерянных пакетов – lost_count.
Третий обработчик
event manager applet MainLinkLost
 event counter name lost_count entry-val 12 entry-op eq exit-val 12 exit-op eq
 action 1.0 syslog msg “ALARM Link To 192.168.70.1 Down Going to Backup Channel”
Проверяет счетчик потерянных пакетов lost_count и в случае, если его значение равно 12 отсылает сообщение о том, что собирается переключить конфигурацию на резервный канал далее он должен залить новую конфигурацию в runnig-config, об этом ниже.
            Настроив, таким образом, EEM события мы, в случае если основной канал в состоянии down будет больше минуты, получим такие сообщения
12:50:10.927: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:50:15.927: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
…………..
12:51:00.928: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:51:05.928: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:51:05.928: %HA_EM-6-LOG: MainLinkLost: ALARM Link To 192.168.70.1 Down Going to Backup Channel
            Если же связь восстановится раньше чем через минуту, то примерно следующие:
12:52:35.928: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:52:40.928: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:52:45.928: %HA_EM-6-LOG: OnePacketLost: WARNING Ping to 192.168.70.1 timeout
12:52:51.612: %HA_EM-6-LOG: LinkOK: WARNING LINK to  192.168.70.1 is OK NOW
            Осталось только научить Cisco заливать конфигурацию для резервного канала после отсылки сообщения “MainLinkLost: ALARM Link To 192.168.70.1 Down Going to Backup Channel”. Эту конфигурацию лучше всего хранить во flash памяти Cisco, в этом случае у нас будет полностью автономное решение, не зависящее от внешних ftp или tftp серверов.
EEM умеет выполнять с качестве действия (action) команды, как если бы вы давали их в командной строке. Однако есть ограничения в том, что после подачи команды Cisco ждет промпта после ее выполнения и, в случае если интерфейс команды подразумевает дополнительный ввода данных команда не выполняется. Например, если дать команду
c2821#copy flash:testsla running-config
То мы получим следующий вопрос, подразумевающий нажатие клавиши Enter в качестве подтверждения
Destination filename [running-config]?
             Если давать команду с помощью EEM, то мы получим через некоторое время такое syslog сообщение:
14:45:26.037: FH-TTY::No more VTY line
            Сама же команда выполнена не будет. Однако, как всегда можно использовать различные трюки. Все тот же Ivan Pepelnjak предлагает следующий рабочий трюк
Суть в том, что мы в качестве команды выполняем Тикль скрипт, который исполняет нужную нам команду и на промпт отвечает нужным нам образом с помощью функции typeahead
Тикль скрипт для нашего примера будет выглядеть так:
typeahead ”

exec “copy flash:configs/tobackup.cfg running-config”
Сама же команда для выполнения этого скрипта будет выглядеть следующим образом
action 2.0 cli command “tclsh flash:tcl/BackupLink.tcl ”
Итак, делаем 2 директории на flash маршрутизатора
c2821#mkdir configs
c2821#mkdir tcl
Создаем на tftp сервере файл BackupLink.tcl содержащий 2 строки
typeahead ”

exec “copy flash:configs/tobackup.cfg running-config”
Создаем на tftp сервере файл MainLink.tcl
typeahead ”

exec “copy flash:configs/tomain.cfg running-config”
Создаем файл tobackup.cfg на tftp сервере, в котором прописана логика переключения на резервный канал, примерно так:
interface FastEthernet0/1
no shut
exit
no ip route 0.0.0.0 0.0.0.0 192.168.70.1
…….
interface FastEthernet0/1
crypto map ToCentralOf
exit
В конце конфигурационного файла удаляем ненужные при работе на резервном канале аплеты EEM командами
no event manager applet OnePacketLost
no event manager applet LinkOK
no event manager applet MainLinkLost
И создаем новые, для переключения на основной канал в случае его восстановления через 30 секунд если не потерялось ни одного пакета в 6-и последовательных с интервалом 5 секунд тестах, примерно такие:
 event manager applet MainLinkUP
 event counter name up_count entry-val 6 entry-op eq exit-val 6 exit-op eq
 action 1.0 syslog msg “ALARM Link To 192.168.70.1 IS UP Going to Main channel”
 action 2.0 cli command “tclsh flash:tcl/ MainLink.tcl ”
 event manager applet LinkOKCheck
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 2 entry-type value exit-comb or exit-op eq exit-val 1 exit-type value exit-time 3 exit-event false poll-interval 5
 action 1.0 counter name up_count op inc value 1
 action 2.0 syslog msg “WARNING LINK to  192.168.70.1 is OK NOW”
 event manager applet PacketLostNotGood
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.3 get-type exact entry-op eq entry-val 1 entry-type value exit-comb or exit-op eq exit-val 2 exit-type value exit-event false poll-interval 5
 action 1.0 counter name up_count op set value 0
 action 2.0 syslog msg “WARNING Ping to 192.168.70.1 timeout Reset up_count”
            Подобным же образом создаем файл tomain.cfg для переключения на основной канал. Затем заливаем по tftp файлы tcl и cfg в директорию tcl и configs соответственно на flash маршрутизатора.
Процедура переключения готова, осталось сделать примерно то же самое для маршрутизатора A и проверить правильность срабатывания скриптов, зашутдаунив нужный порт switch-а или, на худой конец, выдернув кабель из модема провайдера :).
             Возможно такие методы выглядят несколько заумно и криво, но они работают и сама настройка не вызывает особых сложностей.
Заключение.
На мой взгляд, в целом, технология достойная изучения и применения. При изучении основная сложность в большом объеме информации, который необходимо переварить для того, чтобы добиться нужных результатов, однако это просто следствие высокой степени конфигурируемости тестов. Некоторые неудобства при конфигурировании доставляет то, что для различных версий IOS – ов надо давать различные команды. Это, в свою очередь не позволяет написать качественный tutorial для копипастеров (все мы периодически бываем копипастерами), однако на сайте Cisco, есть огромное количество примеров и вся необходимая информация. Следствием вышесказанного явилось появление этой статьи и именно в таком виде.
Литература.
http://www.cisco.com/ – Пожалуй, лучший ресурс по конфигурированию Cisco 🙂
http://ioshints.blogspot.com/ – Весьма познавательный и полезный блог, который ведет Ivan Pepelnjak.
В статье мы расскажем о наиболее интересных стартапах в области кибербезопасности, на которые следует обратить внимание.
Хотите узнать, что происходит нового в сфере кибербезопасности, – обращайте внимание на стартапы, относящиеся к данной области. Стартапы начинаются с инновационной идеи и не ограничиваются стандартными решениями и основным подходом. Зачастую стартапы справляются с проблемами, которые больше никто не может решить.
Обратной стороной стартапов, конечно же, нехватка ресурсов и зрелости. Выбор продукта или платформы стартапа – это риск, требующий особых отношений между заказчиком и поставщиком . Однако, в случае успеха компания может получить конкурентное преимущество или снизить нагрузку на ресурсы безопасности.
Ниже приведены наиболее интересные стартапы (компании, основанные или вышедшие из «скрытого режима» за последние два года).
Компания Abnormal Security, основанная в 2019 году, предлагает облачную платформу безопасности электронной почты, которая использует анализ поведенческих данных для выявления и предотвращения атак на электронную почту. Платформа на базе искусственного интеллекта анализирует поведение пользовательских данных, организационную структуру, отношения и бизнес-процессы, чтобы выявить аномальную активность, которая может указывать на кибератаку. Платформа защиты электронной почты Abnormal может предотвратить компрометацию корпоративной электронной почты, атаки на цепочку поставок , мошенничество со счетами, фишинг учетных данных и компрометацию учетной записи электронной почты. Компания также предоставляет инструменты для автоматизации реагирования на инциденты, а платформа дает облачный API для интеграции с корпоративными платформами, такими как Microsoft Office 365, G Suite и Slack.
Копания Apiiro вышла из «скрытого режима» в 2020 году. Ее платформа devsecops переводит жизненный цикл безопасной разработки «от ручного и периодического подхода «разработчики в последнюю очередь» к автоматическому подходу, основанному на оценке риска, «разработчики в первую очередь», написал в блоге соучредитель и генеральный директор Идан Плотник . Платформа Apiiro работает, соединяя все локальные и облачные системы управления версиями и билетами через API. Платформа также предоставляет настраиваемые предопределенные правила управления кодом. Со временем платформа создает инвентарь, «изучая» все продукты, проекты и репозитории. Эти данные позволяют лучше идентифицировать рискованные изменения кода.
Axis Security Application Access Cloud – облачное решение для доступа к приложениям , построенное на принципе нулевого доверия. Он не полагается на наличие агентов, установленных на пользовательских устройствах. Поэтому организации могут подключать пользователей – локальных и удаленных – на любом устройстве к частным приложениям, не затрагивая сеть или сами приложения. Axis вышла из «скрытого режима» в 2020 году.
BreachQuest, вышедшая из «скрытого режима» 25 августа 2021 года, предлагает платформу реагирования на инциденты под названием Priori. Платформа обеспечивает большую наглядность за счет постоянного отслеживания вредоносной активности. Компания утверждает, что Priori может предоставить мгновенную информацию об атаке и о том, какие конечные точки скомпрометированы после обнаружения угрозы.
Cloudrise предоставляет услуги управляемой защиты данных и автоматизации безопасности в формате SaaS. Несмотря на свое название, Cloudrise защищает как облачные, так и локальные данные. Компания утверждает, что может интегрировать защиту данных в проекты цифровой трансформации. Cloudrise автоматизирует рабочие процессы с помощью решений для защиты данных и конфиденциальности. Компания Cloudrise была запущена в октябре 2019 года.
Cylentium утверждает, что ее технология кибер-невидимости может «скрыть» корпоративную или домашнюю сеть и любое подключенное к ней устройство от обнаружения злоумышленниками. Компания называет эту концепцию «нулевой идентичностью». Компания продает свою продукцию предприятиям, потребителям и государственному сектору. Cylentium была запущена в 2020 году.
Компания Deduce , основанная в 2019 году, предлагает два продукта для так называемого «интеллектуального анализа личности». Служба оповещений клиентов отправляет клиентам уведомления о потенциальной компрометации учетной записи, а оценка риска идентификации использует агрегированные данные для оценки риска компрометации учетной записи. Компания использует когнитивные алгоритмы для анализа конфиденциальных данных с более чем 150 000 сайтов и приложений для выявления возможного мошенничества. Deduce заявляет, что использование ее продуктов снижает ущерб от захвата аккаунта более чем на 90%.
Автоматизированная платформа безопасности и соответствия Drata ориентирована на готовность к аудиту по таким стандартам, как SOC 2 или ISO 27001. Drata отслеживает и собирает данные о мерах безопасности, чтобы предоставить доказательства их наличия и работы. Платформа также помогает оптимизировать рабочие процессы. Drata была основана в 2020 году.
FYEO – это платформа для мониторинга угроз и управления доступом для потребителей, предприятий и малого и среднего бизнеса. Компания утверждает, что ее решения для управления учетными данными снимают бремя управления цифровой идентификацией. FYEO Domain Intelligence («FYEO DI») предоставляет услуги мониторинга домена, учетных данных и угроз. FYEO Identity будет предоставлять услуги управления паролями и идентификацией, начиная с четвертого квартала 2021 года. FYEO вышла из «скрытого режима» в 2021 году.
Kronos – платформа прогнозирующей аналитики уязвимостей (PVA) от компании Hive Pro , основанная на четырех основных принципах: предотвращение, обнаружение, реагирование и прогнозирование. Hive Pro автоматизирует и координирует устранение уязвимостей с помощью единого представления. Продукт компании Artemis представляет собой платформу и услугу для тестирования на проникновение на основе данных. Компания Hive Pro была основана в 2019 году.
Израильская компания Infinipoint была основана в 2019 году. Свой основной облачный продукт она называет «идентификация устройства как услуга» или DIaaS , который представляет собой решение для идентификации и определения положения устройства. Продукт интегрируется с аутентификацией SSO и действует как единая точка принуждения для всех корпоративных сервисов. DIaaS использует анализ рисков для обеспечения соблюдения политик, предоставляет статус безопасности устройства как утверждается, устраняет уязвимости «одним щелчком».
Компания Kameleon , занимающаяся производством полупроводников, не имеет собственных фабрик и занимает особое место среди поставщиков средств кибербезопасности. Компания разработала «Блок обработки проактивной безопасности» (ProSPU). Он предназначен для защиты систем при загрузке и для использования в центрах обработки данных, управляемых компьютерах, серверах и системах облачных вычислений. Компания Kameleon была основана в 2019 году.
Облачная платформа безопасности данных Open Raven предназначена для обеспечения большей прозрачности облачных ресурсов. Платформа отображает все облачные хранилища данных, включая теневые облачные учетные записи, и идентифицирует данные, которые они хранят. Затем Open Raven в режиме реального времени отслеживает утечки данных и нарушения политик и предупреждает команды о необходимости исправлений. Open Raven также может отслеживать файлы журналов на предмет конфиденциальной информации, которую следует удалить. Компания вышла из «скрытого режима» в 2020 году.
Компания Satori, основанная в 2019 году, называет свой сервис доступа к данным “DataSecOps”. Целью сервиса является отделение элементов управления безопасностью и конфиденциальностью от архитектуры. Сервис отслеживает, классифицирует и контролирует доступ к конфиденциальным данным. Имеется возможность настроить политики на основе таких критериев, как группы, пользователи, типы данных или схема, чтобы предотвратить несанкционированный доступ, замаскировать конфиденциальные данные или запустить рабочий процесс. Сервис предлагает предварительно настроенные политики для общих правил, таких как GDPR , CCPA и HIPAA .
Компания Scope Security недавно вышла из «скрытого режима», будучи основана в 2019 году. Ее продукт Scope OmniSight нацелен на отрасль здравоохранения и обнаруживает атаки на ИТ-инфраструктуру, клинические системы и системы электронных медицинских записей . Компонент анализа угроз может собирать индикаторы угроз из множества внутренних и сторонних источников, представляя данные через единый портал.
Основным продуктом Strata является платформа Maverics Identity Orchestration Platform . Это распределенная мультиоблачная платформа управления идентификацией. Заявленная цель Strata – обеспечить согласованность в распределенных облачных средах для идентификации пользователей для приложений, развернутых в нескольких облаках и локально. Функции включают в себя решение безопасного гибридного доступа для расширения доступа с нулевым доверием к локальным приложениям для облачных пользователей, уровень абстракции идентификации для лучшего управления идентификацией в мультиоблачной среде и каталог коннекторов для интеграции систем идентификации из популярных облачных систем и систем управления идентификацией. Strata была основана в 2019 году.
SynSaber , запущенная 22 июля 2021 года, предлагает решение для мониторинга промышленных активов и сети. Компания обещает обеспечить «постоянное понимание и осведомленность о состоянии, уязвимостях и угрозах во всех точках промышленной экосистемы, включая IIoT, облако и локальную среду». SynSaber была основана бывшими лидерами Dragos и Crowdstrike.
Traceable называет свой основной продукт на основе искусственного интеллекта чем-то средним между брандмауэром веб-приложений и самозащитой приложений во время выполнения. Компания утверждает, что предлагает точное обнаружение и блокирование угроз путем мониторинга активности приложений и непрерывного обучения, чтобы отличать обычную активность от вредоносной. Продукт интегрируется со шлюзами API. Traceable была основана в июле 2020 года.
Компания Wiz, основанная командой облачной безопасности Microsoft, предлагает решение для обеспечения безопасности в нескольких облаках, рассчитанное на масштабную работу. Компания утверждает, что ее продукт может анализировать все уровни облачного стека для выявления векторов атак с высоким риском и обеспечивать понимание, позволяющее лучше расставлять приоритеты. Wiz использует безагентный подход и может сканировать все виртуальные машины и контейнеры. Wiz вышла из «скрытого режима» в 2020 году.
Работает на CMS “1С-Битрикс: Управление сайтом”
dark web to buy cc buy cc with bin