CCNA R&S 6.0 Bridging Course часть 4

Сертификации R&S больше нет, но данная информация по-прежнему полезна.

CCNA R&S 6.0 Bridging Course часть 4, содержит урок 4 (вторая половина урока) — для тех, кто готовился на сертификацию версии 3 и будет сдавать экзамены:

Interconnecting Cisco Networking Devices Part 2 exam (ICND2 200-105), which is associated with the CCNA Routing and Switching certification;
CCNA Routing and Switching composite exam (200-125), which can be taken instead of the ICND1 and ICND2 exams.

Четвертая, последняя часть, ну наконец-то, уж думал никогда до конца курса не дойду. Рассматриваются SNMP, SPAN, QoS, виртуализация, Network Programming и SLA.

Общая схема для курса:

4.7: SNMP

Беглое знакомство с SNMP было в 4 части курса.

SNMPv3 Configuration

Simple Network Management Protocol version 3 (SNMPv3) производит проверку подлинности и шифрование пакетов по сети чтобы предоставить безопасный доступ к оборудованию. Добавление проверки подлинности и шифрования в SNMPv3 обращено к уязвимостям более ранних версий протокола SNMPv3.

SNMPv3 можно сделать безопасным всего несколькими командами:

Step 1

Конфигурирование ACL, который разрешает доступ авторизованным SNMP менеджерам.

Router(config)# ip access-list standard acl-name
Router(config-std-nacl)# permit source_net

Step 2

Конфигурирование вида SNMP с помощью команды snmp-server view, для того чтобы определить какие объекты MIB Object Identifiers (OIDs) будут доступны SNMP менеджеру для чтения. Конфигурирование вида требуется чтобы ограничить SNMP сообщения при read-only доступе.

Router(config)# snmp-server view view-name oid-tree {included | excluded}

Step 3

Конфигурирование SNMP фич для группы с помощью команды snmp-server group:

Конфигурирование имени группы;
Установка версии SNMP равной 3 с помощью опции v3;
Установка необходимости аутентификации и шифрования с помощью опции priv;
Связывание настроенного вида с группой и предоставление группе права только на чтение с помощью read команды.
Связывание с ACL, сконфигурированным в Step 1.

Router(config)# snmp-server group group-name v3 priv read view-name access [acl-number | acl-name]

Step 4

Конфигурирование SNMP пользователя группы помощью команды snmp-server user:

Конфигурирование username и связывание его с именем группы, которая была сконфигурирована в Step 3;
Установка SNMP vверсии равной 3 с помощью опции v3;
Установка типа аутентификации или на md5, или на sha и конфигурирование пароля для аутентификации. SHA предпочтительнее и должно хорошо поддерживаться со стороны управляющего SNMP программного обеспечения;
Включение шифрования с помощью опции priv и конфигурирование пароля шифрования.

Router(config)# snmp-server user username group-name v3 auth {md5 | sha} auth-password  priv {des | 3des | aes {128 | 192 | 256}} privpassword

Пример

Используется стандартный ACL с именем PERMIT-ADMIN, сконфигурированный чтобы разрешить доступ только из 192.168.1.0/24 подсети. Все хосты из этой подсети могут получить доступ к SNMP агенту, запущенному на R1.

SNMP вид назван SNMP-RO и он сконфигурирован на получение всего дерева с именем iso из MIB. В сети, которая работает в продакшене, сетевой администратор вероятнее всего сконфигурирует вид, включающий в себя только MIB OIDs необходимые для мониторинга и управления сетью.

SNMP группа сконфигурирована с именем ADMIN, SNMP установлен в версию 3, требующую аутентификации и шифрования. Группе позволен только read-only доступ к виду SNMP-RO. Доступ для группы ограничен PERMIT-ADMIN ACL.

SNMP пользователь BOB сконфигурирован как участник группы ADMIN. SNMP установлен в версию 3. Аутентификация установлена на использование SHA и пароль для аутентификации установлен. Хотя R1 поддерживает AES 256 шифрование, SNMP управляющее программное обеспечение поддерживает только AES 128 шифрование. Таким образом, шифрование установлено в AES 128 и пароль шифрования сконфигурирован.

Полное описание для опций конфигурирования SNMPv3 за пределами этого курса.

Проверка SNMPv3

Используйте ping для проверки связи между агентом и клиентом. Используйте команду:

show snmp group

чтобы отобразить информацию о каждой группе SNMP в сети.

Используете команду:

show snmp user

чтобы отобразить информацию о сконфигурированных характеристиках SNMP пользователя.

Чтобы посмотреть информации о SNMP engine ID, введите команду:

show snmp engineID

4.8: Cisco Switch Port Analyzer (SPAN)

SPAN Overview

Анализатор пакетов - ценный инструмент в наблюдении и устранении ошибок сети. Это обычно программное обеспечение, которое захватывает пакеты исходящие из и поступающие на сетевую карту (NIC). Например, WireShark - это анализатор пакетов, широко используемый для захвата и анализа пакетов на локальном компьютере.

Что если администратор сети захочет захватывать пакеты из многих других ключевых устройств в сети, а не только из локальной NIC? Решение: сконфигурировать сетевые устройства для того чтобы копировать и пересылать трафик интересующего порта в анализатор трафика. Администратор тогда смог бы анализировать трафик из различных источников в сети.

Однако, базовые операции современных переключаемых сетей исключают возможность для анализатора пакетов собирать трафик из других источников. Например, пользователь использующий WireShark может собирать только трафик проходящий через его локальную NIC. Он не может собирать трафик, например, между другим хостом и сервером. Так происходит потому, что коммутатор 2 уровня заполняет свою таблицу MAC адресов на основе MAC источника в Ethernet фрейме и исходящего порта. После того как таблица заполнена, коммутатор отправляет трафик для назначенного MAC сразу на нужный порт. Это препятствует анализатору пакетов, подключённому к другому порту, прослушивать остальной трафик коммутатора.

Для того чтобы решить эту проблему нужно включить зеркалирование портов. Зеркалирование портов (port mirroring) - это опция позволяющая коммутатору копировать и посылать Ethernet пакеты из определённого порта в порт назначения, подключенный к анализатору пакетов. Оригинальный фрейм при этом пересылается как обычно.

На рисунке трафик между PC1 и PC2 также отсылается и на ноутбук, где установлен анализатор пакетов.

Local SPAN

SPAN (The Switched Port Analyzer), опция коммутаторов CISCO - это вариант зеркалирования портов, при котором копия фрейма поступающего на порт пересылается на выход другого порта на том же коммутаторе. Такое часто встречается когда к порту, на который пересылаются копии фреймов, подключён анализатор пакетов, или система обнаружения вторжений Intrusion Detection System (IDS), или система предотвращения вторжений Intrusion Prevention System (IPS).

Терминология SPAN:

Сессия SPAN ассоциирует порт источника (или VLAN) с портом назначения.

Трафик поступающий на порт источника или исходящий из порта источника (или VLAN) реплицируется коммутатором в порт назначения. Хотя SPAN может поддерживать несколько портов источников в одной сессии или даже целый VLAN, SPAN не поддерживает обе опции (порты и VLAN). Как порты уровня 2, так и порты уровня 3 могут быть сконфигурированы в качестве портов источников.

Существует 3 важные вещи для рассмотрения при конфигурировании SPAN:

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

Говорят, что SPAN локальный, когда порты источники и порт назначения находятся на 1 коммутаторе. Эта функция противоположна Remote SPAN (RSPAN).

Remote SPAN

RSPAN позволяет порту источнику и порту назначения находиться на разных коммутаторах. RSPAN полезен в сети кампусного типа, где анализатор пакетов скорее всего находится не на том же самом коммутаторе, на котором нужно захватывать трафик.

Терминология RSPAN:

RSPAN использует 2 сессии, 1 сессию как источник и 2 чтобы копировать или пересылать трафик через VLAN. Для передачи RSPAN VLAN через сеть используется транковый канал (trunk link) между коммутаторами.

Local SPAN Configuration

Используйте следующие команды для выбора порта источника и порта назначения:

S1(config)# monitor session number source {interface | vlans}
S1(config)# monitor session number destination {interface | vlans}

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

На рисунке администратору нужно захватывать весь трафик, который посылается или принимается компьютером PC1. Анализатор пакетов подключён к G0/2. Поскольку PC1 подключён к G0/1, сессия SPAN создаётся используя G0/1 как источник и G0/2 как назначение. Раз все порты принадлежат 1 коммутатору, то это - Local SPAN.

Конфигурирование:

Для проверки конфигурации SPAN сессии нужно использовать команду:

show monitor

Эта команда возвращает тип сессии, порт источника для каждого направления трафика и порт назначения.

Лабораторная работа.

Траблшутинг с помощью SPAN

SPAN позволяет администраторам доставлять трафик специализированным устройствам, таким как анализатор трафика или система защиты от вторжения (IPS). Это предоставляет возможность анализировать трафик и исправлять проблему до пересылки трафика по месту назначения. IPS ищет специфический "узоры" (patterns) в трафике. Так как трафик проходит через IPS, то IPS может в реальном времени предпринимать действия по поиску в трафике предопределённых паттернов. IPS основным образом используется чтобы обнаруживать сетевые атаки, когда они случаются, выдавать предупреждения или даже блокировать вредоносные пакеты как только атака происходит.

Для того, чтобы быть эффективной IPS должна иметь возможность инспектировать весь трафик, проходящий через сеть. Поскольку современные сети построены на коммутаторах, SPAN критичен для эффективной работы IPS.

Некоторые паттерны более сложны, чем остальные. Например, LAND (Local Area Network Denial) атака посылает ложный TCP SYN пакет (пакет инициации соединения) с одним и тем же IP источника и IP назначения - адресом целевого компьютера, с одним и тем же портом источника и портом назначения - открытым портом целевого компьютера. LAND атака заставляет целевой компьютер отвечать самому себе непрерывно. Поскольку только 1 пакет требуется чтобы определить такой тип атаки, то IPS легко защищает от дальнейшего попадания данных пакетов в сеть.

Обзор видов атак (//citforum.ru/nets/semenov/6/table2.shtml )

В дополнение к IPS, другое распространённое устройство это анализатор пакетов конечно же. В то время как IPS сосредоточена на вопросах безопасности, анализатор пакетов широко используется для устранения проблем в сети. Например, если сетевое приложение занимает слишком много времени на выполнение, тогда сетевой администратор может использовать SPAN чтобы дублировать и перенаправлять трафик в анализатор пакетов. Затем администратор анализирует трафик от всех устройств чтобы исправить неоптимальные операции в сетевых приложениях.

4.9: QoS Overview

Quality of Service (QoS) - это постоянно возрастающее требование для сетей сегодня. Новые приложения доступные пользователям, такие как передача голоса и живого видео, создают высокие ожидания в отношении качества предоставленных сервисов.

Затор происходит когда требование в пропускной способности достигает доступного максимума. Когда в 1 момент времени происходит множество соединений в сети, то требование пропускной способности может достигнуть доступного предела, создавая затор в сети.

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

Пропускная способность сети измеряется как количество бит, которые могут быть переданы за 1 секунду или бит в секунду (bps). Сетевые администраторы очень часто говорят о производительности сетевых устройств, описывая пропускную способность интерфейсов. Например, сетевое устройство может быть описано как имеющее производительность в 10 гигабит в секунду (Gbps).

Заторы

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

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

Задержка (delay or latency ) определяется временем, которое нужно пакету чтобы попасть из источника в точку назначения. Существуют как фиксированные задержки, так и изменяющиеся во времени (variable) задержки.

Виды задержек представлены в таблице:

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

Потери пакетов

Без механизмов QoS пакеты обрабатываются в том порядке, в котором они прибывают. Когда случается затор, коммутаторы и маршрутизаторы начинают отбрасывать пакеты. Это означает, что чувствительные к задержкам пакеты, такие как видео и голос в реальном времени, будут отброшены с такой же частотой как и нечувствительные - данные, e-mail и пакеты веб-браузеров.

Например, если маршрутизатор получает цифровой аудио поток Voice over IP (VoIP) по протоколу реального времени (RTP), он должен скомпенсировать джиттер в буфере задержки воспроизведения (playout delay buffer). Такой буфер должен буферизировать пакеты и затем воспроизводить их постоянным потоком.

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

Для небольших потерь, таких как 1 пакет, цифровой сигнальный процессор (DSP) производит интерполяцию и выходном аудио не должно быть никаких разрывов в воспроизведении. Однако, когда джиттер возрастает до такой степени, что DSP не может скомпенсировать отсутствующие пакеты, разрывы в аудио потоке становятся слышны.

Потеря пакетов - это наиболее частая причина проблем с качеством голосовой связи в IP сети. В правильно сконструированной сети потери пакетов должны быть близки к 0. Аудио кодек в DSP может скомпенсировать в некоторой степени потерю пакетов без драматических последствий для качества голоса. Сетевые инженеры используют QoS механизмы чтобы классифицировать голосовые пакеты для нулевых потерь пакетов. Пропускная способность гарантирована для голосовых вызовов с помощью предоставления приоритета для голосового трафика над трафиком, который не является чувствительным к задержкам.

Характеристики трафика

В 2000 году, основным видом трафика были голос и данные. Голосовой трафик использует предсказуемую пропускную способность и известное время, в которое должна укладываться доставка пакетов. Трафик данных не является трафиком реального времени и требует заранее неизвестную полосу пропускания. Трафик данных подвержен всплескам, когда большой файл передаётся по сети. Такой всплеск может занять всю полосу пропускания канала.

Не так давно, видео трафик стал приобретать всё возрастающую важность для бизнеса и работы. В соответствии с Cisco Virtual Networking Index (VNI), видео трафик представляет 67% всего трафика в 2014 году. К 2019 году видео трафик будет составлять 80% всего трафика. В дополнение, мобильный трафик возрастёт на 600%.

Требования голосового, видео и трафика данных к сети - очень различны.

Голос

Голосовой трафик предсказуемый и гладкий. Голосовой трафик щадящий, он не забирает много сетевых ресурсов. Однако, голосовой трафик очень чувствителен к задержкам, потерям пакетов и не может быть передан заново при потерях. Таким образом, голосовой трафик должен иметь высокий приоритет. Например, продукция CISCO использует RTP в диапазоне портов с 16384 до 32767 для приоритизации голосового трафика. Голосовой трафик выдерживает некоторое количество задержек, джиттера и потерь пакетов без каких-либо заметных последствий. Задержка должна быть менее 150 миллисекунд (ms). Джиттер должен быть не более 30 ms и потери пакетов должны быть не более 1%. Голосовой трафик требует по меньшей мере 30Kb/s пропускной способности.

Video

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

Видео трафик имеет тенденцию быть непредсказуемым, несогласованным, пульсирующим по сравнению с голосовым трафиком. В сравнении с голосом, видео менее устойчиво к потерям и имеет больший объем данных на пакет. Голосовой пакет прибывает каждые 20ms и имеет предсказуемый размер - 200 байт каждый. В противовес, размер и количество видео пакетов варьируется каждые 33ms в зависимости от содержимого видео. Например, если видео поток состоит из контента, который мало меняется от фрейма к фрейму, тогда видео фреймы будут меньше размером и реже для поддержания приемлемого качества для пользователя. Однако, если видео поток быстро меняется, как в экшен сценах видео фильмов, тогда видео пакеты будут больше и чаще в пределах 33ms временного слота для поддержания приемлемого качества.

Картинка обобщает характеристики видео трафика. UDP портам, таким как 554 (используется для Real-Time Streaming Protocol (RSTP)), нужно предоставить приоритет перед другим, менее чувствительным к временным задержкам, сетевому трафику. Подобно голосу, видео может допускать некоторое количество задержек, джиттера и потерь без значительного влияния на качество. Задержка не должна быть более 400ms. Джиттер не должен быть более 50ms и потеря видео пакетов должна быть менее 1%. Видео трафик требует минимум 384Kb/s пропускной способности.

Данные

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

Однако, некоторые TCP приложения могут быть очень прожорливыми, потребляя большую часть пропускной способности сети. FTP будет потреблять столько пропускной способности, сколько сможет получить, когда передаётся большой файл. Рисунок обобщает характеристики трафика данных:

Хотя трафик данных относительно нечувствительный к потерям и задержкам в сравнении с голосовым и видео трафиком, сетевому администратору тем не менее нужно учитывать качество работы пользователей (Quality of Experience or QoE). Основные 2 фактора которыми сетевой администратор должен озаботится в отношении сетевого трафика данных это:

Поступают ли данные из интерактивных приложений?
Являются ли данные критическими важными?

Таблица сравнивает эти 2 фактора:

Организация очередей

Политика QoS, применённая сетевым администратором, становится активной, когда на линке случается затор. Организация очереди (Queuing) - это механизм управления затором, которое может буферизировать, приотизировать и если необходимо, менять порядок пакетов перед отправкой к месту назначения. Доступно несколько алгоритмов организации очередей. Для целей этого курса, мы сфокусируемся на следующих:

First-In, First-Out (FIFO);
Weighted Fair Queuing (WFQ);
Class-Based Weighted Fair Queuing (CBWFQ);
Low Latency Queuing (LLQ).

First In First Out (FIFO)

В самой простой форме, механизм очереди FIFO - так же известный как first-come, first-served (FCFS), включает буферизацию и форвардинг пакетов в порядке их прибытия.

FIFO не имеет концепции классов или приоритетов для трафика и следовательно не принимает решений по приоритету пакетов. Существует единственная очередь и все пакеты обрабатываются одинаково. Пакеты отсылаются на выходной интерфейс в том порядке, в котором они прибывают. Хотя некоторый трафик более важный или чувствительный к задержкам, нужно запомнить, что все пакеты отсылаются в порядке их прибытия.

Когда используется FIFO, важный или чувствительный к задержкам трафик может быть отброшен, когда случается затор на интерфейсе коммутатора или маршрутизатора. Когда не сконфигурировано никаких других стратегий QoS, все интерфейсы (за исключением последовательного интерфейса на E1 2.048 Mbit и ниже) используют FIFO (последовательный интерфейс использует WFQ по умолчанию).

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

Weighted Fair Queuing (WFQ)

WFQ - это автоматически спланированный метод, который предоставляет объективное распределение пропускной способности для всего сетевого трафика. WFQ применяет приоритеты или веса (weights) для того, чтобы идентифицировать трафик и классифицировать его в потоки, как показано на рисунке:

Затем WFQ определяет сколько пропускной способности допускается для потока в отношении с остальными потоками. Основанный на потоках алгоритм используется WFQ вместе с планированием интерактивного трафика ближе к началу очереди чтобы уменьшить время отклика. Затем объективно распределяется оставшаяся пропускная способность между high-bandwidth потоками. WFQ позволяет выделить небольшому по объёму, интерактивному трафику, такому как Telnet сессия и голос, приоритет над большим по объёму трафику, такому как FTP сессии. Когда случаются множественные одновременные передачи потоков файлов, каждая передача получает сопоставимую пропускную способность.

WFQ классифицирует трафик на разные потоки основываясь на адресации в заголовке пакета, включая такие характеристики как IP адрес источника и назначения, MAC адреса, номера портов, протокол и значение Type of Service (ToS). Значение ToS в IP заголовке может быть использовано для классификации трафика. ToS будет рассмотрено позже в этой главе.

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

Ограничения

WFQ не поддерживает туннели и шифрование, потому что эти фичи модифицируют информацию заголовка пакета, которая нужна WFQ для классификации;
Хотя WFQ автоматически адаптируется к меняющимся условиям сетевого трафика, этот метод не предлагает точного контроля пропускной способности для распределения трафика, который предлагает CBWFQ.

Class-Based Weighted Fair Queuing (CBWFQ)

CBWFQ расширяет функциональность стандарта WFQ для того, чтобы предоставить определенные пользователем классы. Для CBWFQ, вы определяете классы трафика основываясь на критериях соответствия - включая протоколы, списки контроля доступа (ACL) и входящие интерфейсы. Пакеты, удовлетворяющие критериям соответствия для класса, составляют трафик для этого класса. FIFO очередь зарезервирована для каждого класса, трафик принадлежащий классу направляется в очередь для этого класса, как показано на рисунке:

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

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

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

Low Latency Queuing (LLQ)

LLQ фича привносит строгий приоритет очереди (strict priority queuing (PQ)) в CBWFQ. Strict PQ позволяет чувствительным к задержкам данным, таким как голос, быть обработанными до пакетов в других очередях. LLQ предоставляет строгий приоритет очередей для CBWFQ, уменьшая джиттер в голосовых переговорах.

Без LLQ, CBWFQ предоставляет WFQ основанный на предопределённых классах без строгого приоритета очередей доступного для трафика реального времени. Вес пакета принадлежащего к определённому классу определяется из пропускной способности, которую вы назначили классу, когда конфигурировали классы. Таким образом, пропускная способность, назначенная классу, определяет порядок, в котором пакеты отсылаются. Все пакеты обслуживаются объективно основываясь на весе; никакому классу пакетов не может быть предоставлен строгий приоритет. Эта схема представляет собой проблему для голосового трафика, который в большей степени не допускает задержек, особенно вариаций в задержке. Для голосового трафика вариация в задержке привносит неупорядоченность, проявляющуюся как джиттер в слышимом разговоре.

С LLQ чувствительные к задержкам данные отсылаются первыми, до того как обрабатываются пакеты в других очередях. LLQ позволяет чувствительным к задержкам данным, таким как голос, быть отосланными первыми (до пакетов в других очередях), давая чувствительным данным приоритет в обработке над остальным трафиком. Хотя возможны разные уникальные виды трафика реального времени для очередей строгого приоритета, CISCO рекомендует чтобы только голосовой трафик был направлен в очередь строгого приоритета.

4.10: QoS Mechanisms

QoS Models

Как QoS может быть применён в сети? Существуют 3 модели применения QoS. Таблица обобщает эти 3 модели:

QoS реально применяется в сетях используя или IntServ, или DiffServ. Хотя IntServ предоставляет высокие гарантии для QoS, но эта модель очень ресурсо затратна и поэтому ограничена в масштабировании. DiffServ менее ресурсо затратна и более масштабируема. Иногда обе модели применяются совместно для реализации QoS в сети.

Best-Effort

Базовая архитектура сети обеспечивает Best-effort доставку пакетов и не даёт никаких гарантий. Такой подход тем не менее доминирует сегодня в интернете и подходит для большинства целей. Модель Best-effort обрабатывает все пакеты одинаково, так аварийное голосовое сообщение обрабатывается так же как и цифровая фотография, приложенная к e-mail письму. Без QoS, сеть не может описать разницу между пакетами и как результат, не может обрабатывать пакеты с учётом предпочтений.

Модель Best-effort похожа по концепции с отсылкой обычного почтового письма. Ваше письмо обрабатывается точно также как и каждое другое письмо. Письмо может быть никогда не доставлено и пока у вас с получателем письма разные механизмы оповещения, вы можете никогда не узнать, что письмо не доставлено.

Integrated Services

Потребности приложений реального времени, таких как удаленное видео, мультимедиа конференции, визуализация и виртуальная реальность мотивировали разработку IntServ архитектурной модели в 1994 (RFC 1633, 2211, and 2212). IntServ - это мультисервисная модель, которая может соответствовать множественным требованиям QoS.

IntServ предоставляет способ доставки сквозного (end-to-end) QoS, который требуется приложениям реального времени для явного управления сетевыми ресурсами, чтобы обеспечить QoS для определённых потоков пакетов пользователя, иногда называемых микропотоками (microflows). Он использует резервирование ресурсов и механизм входного контроля в качестве строительных блоков для создания и поддержания QoS. Эта практика аналогична концепции, известной как “Hard QoS”. Hard QoS гарантирует характеристики трафика, такие как пропускная способность, задержка и уровень потери пакетов, через всю сеть. Hard QoS обеспечивает как предсказуемый так и гарантированный уровень обслуживания для критически важных приложений.

Механизм работы IntServ

IntServ использует ориентированный на подключение (connection-oriented) подход, унаследованный от дизайна телефонной сети. Каждое отдельное подключение должно явно указывать свой дескриптор трафика и запрашиваемые ресурсы в сети. Пограничный маршрутизатор обеспечивает входной контроль, чтобы убедиться, что имеющихся ресурсов достаточно в сети. Стандартный IntServ предполагает, что маршрутизаторы вдоль пути следования пакетов устанавливают и поддерживают состояние для каждого отдельного соединения.

В модели IntServ, приложение запрашивает определенный тип сервиса из сети перед отправкой данных. Приложение информирует сеть о своём профиле трафика и о запросе конкретного вида сервиса, который сможет предоставить требуемую пропускную способность и обеспечить требования по задержкам. IntServ использует Resource Reservation Protocol (RSVP), чтобы сигнализировать QoS потребности всего трафика приложения по всем устройствам на пути из конца в конец через сеть. Если сетевые устройства на пути следования могут зарезервировать необходимую пропускную способность, исходное приложение может начинать передачу. Если запрос на резервирование возвращает сбой в какой-то точке по пути следования, исходное приложение не отправляет никаких данных.

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

Differentiated Services

DiffServ модель QoS определяет простой и масштабируемый механизм классификации и управления сетевым трафиком и обеспечения гарантии QoS в современных IP сетях. Например, DiffServ может обеспечить гарантированное обслуживание с низкой задержкой для критического сетевого трафика, такого как голос или видео, обеспечивая простые Best-effort гарантии трафика для некритичных сервисов, таких как веб-трафик или передача файлов.

DiffServ преодолевает ограничения как Best-effort, так и IntServ моделей. DiffServ модель описана в RFC 2474, 2597, 2598, 3246, 4594. DiffServ модель может обеспечить “почти гарантированный” QoS и в то же время оставаясь экономичной и масштабируемой.

Модель DiffServ аналогична концепции для отправки пакета через службу доставки. Вы запрашиваете (и оплачиваете) уровень сервиса при отправке пакета. По всей сети доставки, уровень сервиса (за который вы заплатили) распознаётся и ваш пакет получает либо преференции, либо обычные условия обслуживания в зависимости от того, что вы требовали.

DiffServ - это не сквозная (end to end) стратегия QoS, поскольку она не может реализовать сквозные гарантии. Однако, DiffServ QoS является более эффективным подходом к реализации QoS. В отличие от IntServ и Hard QoS, в которых конечные узлы сигнализируют сети их потребности в QoS, DiffServ не использует такую сигнализацию. Вместо этого, DiffServиспользует Soft QoS подход. Он работает на подготовленной QoS модели, где элементы сети настроены для обслуживания множества классов трафика, каждый с разными требованиями QoS.

Механизм работы DiffServ

Как только узел перенаправляет трафик на маршрутизатор, маршрутизатор классифицирует потоки в агрегации (классы) и обеспечивает соответствующую политику QoS для этих классов. DiffServ внедряет и применяет механизмы QoS на "от узла к узлу" (hop by hop) базисе, равномерно применяя глобальный подход для каждого класса трафика, чтобы обеспечить и гибкость, и масштабируемость. Например, DiffServ группирует все TCP потоки как единый класс и выделяет полосу пропускания для данного класса, а не для отдельных потоков как IntServ. В дополнение к классификации трафика, DiffServ минимизирует сигнализацию и требованиями по поддержанию состояния на каждом узле сети.

В частности, DiffServ делит сетевой трафик на классы на основе бизнес требований. Каждому из классов может быть назначен другой уровень сервиса. Так как пакеты проходят через сеть, каждое сетевое устройство идентифицирует класс пакета и обслуживание для пакета согласно этому классу. Можно выбрать много уровней обслуживания с DiffServ. Например, голосовому трафику IP телефонов, как правило, отдается предпочтение над трафиком всех других приложений, электронной почте, как правило, даётся Best-effort сервис и для нерабочего трафика может быть предоставлен очень плохой сервис или даже такой трафик может быть блокирован целиком.

Примечание. Современные сети в основном используют DiffServ модель. Однако с возрастающими объёмами чувствительного к задержкам и джиттеру трафика, IntServ и RSVP иногда развертываются совместно с DiffServ.

QoS Implementation Techniques

Avoiding Packet Loss

Потеря пакетов обычно является следствием затора на интерфейсе. Большинство приложений, которые используют TCP испытывают замедление при заторе, поскольку TCP автоматически приспосабливается к перегрузке сети. Отбрасывание TCP сегментов принуждает TCP сессию уменьшать размер TCP окна. Некоторые приложения не используют протокол TCP и не могут обрабатывать отбрасывание пакетов - хрупкие потоки (fragile flows).

Следующие подходы могут предотвратить отбрасывание пакетов для чувствительных приложений:

Увеличить пропускную способность, чтобы облегчить или предотвратить заторы;
Гарантировать достаточную пропускную способность и увеличить буферное пространство чтобы разместить трафик при всплесках для fragile flows. Есть несколько доступных механизмов в CISCO IOS QoS программном обеспечении, которые могут гарантировать пропускную способность и обеспечить приоритетность отправки для чувствительных к отбрасыванию пакетов приложений. Примеры: WFQ, CBWFQ и LLQ;
Предотвратить заторы путём отбрасывания пакетов с низким приоритетом, прежде чем произойдёт затор. CISCO IOS QoS обеспечивает механизмы очередей, которые начнут отбрасывать пакеты с более низким приоритетом, прежде чем произойдет затор. Например, Взвешенное произвольное раннее обнаружение (WRED).

QoS Tools

Существуют 3 категории инструментов QoS:

Рисунок поможет понять последовательность применения этих 3 инструментов над потоком пакетов:

Входящие (ingress) пакеты - серые квадраты - классифицируются и их соответствующие IP заголовки помечаются - цветные квадраты. Во избежание заторов, пакетам затем выделяются ресурсы на основе определённых ранее политик. Затем пакеты формируются в очереди и отправляются на выходной (egress) интерфейс, основываясь на определённых для них QoS формах (QoS shaping) и политиках.

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

Classification and Marking

Прежде чем пакет может иметь политику QoS, примененную к нему, пакет должен быть классифицирован. Классификация и маркировка позволяет идентифицировать или “пометить” типы пакетов. Классификация определяет классы трафика, к которому принадлежат пакеты или кадры. Только после того, как трафик идентифицирован, политики могут быть применены к нему.

Как пакет классифицируются зависит от реализации QoS. Методы классификации потоков трафика на уровне 2 и 3 включают использование интерфейсов, ACL и карт класса (class maps). Трафик также может быть классифицирован на уровнях от 4 до 7, используя Network Based Application Recognition (NBAR).

Примечание. NBAR - это фича программного обеспечения CISCO IOS по классификации и обнаружению протокола, которое работает с QoS. NBAR выходит за рамки данного курса.

Маркировка означает, что мы добавляем значение к заголовку пакета. Устройство, получая пакет, смотрит на это поле, чтобы определить, соответствует ли пакет определённой политике. Маркировка должна быть выполнена как можно ближе к источнику. Это устанавливает границу доверия.

Traffic Marking

Как трафик помечается, как правило, зависит от технологии. В таблице приведены некоторые обозначения полей, используемых в различных технологиях. Решение о том, следует ли маркировать трафик на уровнях 2 или 3, или на обоих - задача нетривиальная и должна быть решена после рассмотрения следующих моментов:

Уровень 2: маркировка фреймов может быть выполнена на не IP трафике;
Уровень 2: маркировка фреймов - опция QoS, доступная для коммутаторов, которые не являются IP коммутаторами (IP aware);
Уровень 3 маркировка будет нести сведения о QoS информации от начала и до конца (end-to-end).

802.1Q - это стандарт IEEE, который поддерживает VLAN в сети Ethernet. Стандарт также включает в себя QoS схему приоритезации услуг, известную как IEEE 802.1р.

Marking at Layer 2

Стандарт 802.1Q является спецификацией IEEE для реализации виртуальных локальных сетей на Уровне 2 коммутируемых сетей. Как показано на рисунке, есть два поля вставленных в кадр Ethernet после поля адреса источника.

Tag protocol identifier (TPID) в настоящее время фиксирован и имеет значение 0x8100. Tag control information (TCI) содержит поле PRI (приоритета) из 3 битов, которое идентифицирует отметку Class of Service (CoS). CoS отметка позволяет Уровню 2 кадра Ethernet, быть помеченным 1 из 8 уровней приоритета (значения 0-7).

Marking at Layer 3

IPv4 и IPv6 определяют 8 битное поле в их заголовках пакетов для того чтобы маркировать пакеты. Как показано на рисунке, IPv4 имеет Type of Service (Tos) поле и IPv6 имеет Traffic Class поле.

Эти поля используются чтобы нести маркировку пакета как присвоено инструментом QoS классификации. На это поле затем ссылается принимающее устройство чтобы форвардить пакет, основываясь на соответствующей назначенной политике.

Биты IP Extended Congestion Notification (IP ECN) - расширенного уведомления о перегрузке, используются для определения маркировки Уровня 2 QoS.

Примеры включают биты Ethernet 802.1p Class of Service (CoS), биты MAC bridge 802.1D user priority или Multiprotocol Label Switching Experimental values (MPLS EXP).

Первые 3 значимых верхних левых бита относятся к IP Precedence полю. Все 8 бит предоставляют 8 возможных классов сервиса.

При использовании модели DiffServ, пакет помечается с помощью 6 бит относящихся к битам DiffServ Code Point (DSCP). Эти 6 бит обеспечивает максимум из 64 возможных классов обслуживания. Способные обрабатывать DiffServ маршрутизаторы осуществляют "режимы на переход" - per-hop behaviors (PHBs), которые определяют свойства форвардинга пакетов, связанные с классом трафика. В частности, существуют четыре категории РВН.

Trust Boundaries

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

Надежные конечные точки имеют возможности и сведения, чтобы маркировать трафик приложения на соответствующем Уровне 2 CoS и/или на Уровне 3 DSCP значений. Примеры надёжных конечных точек включают IP телефоны, беспроводные точки доступа, шлюзы и системы видеоконференцсвязи, станции для IP конференций и многое другое;
Безопасные конечные точки могут иметь промаркированный трафик на Уровне 2 коммутатора;
Трафик также может быть промаркирован на Уровне 3 коммутаторов/маршрутизаторов.

Перемаркировка трафика, как правило, необходима. Например, перемаркировка значений CoS к IP Precedent или DSCP.

Congestion Avoidance

Управление заторами включает в себя организацию очередей и методы планирования, где избыточный трафик буферизируется или в отправляется в очередь (а иногда отбрасывается), во время ожидания отправки на выходной (egress) интерфейс. Инструменты предотвращения заторов просты. Они мониторят уровень нагрузки для сетевого трафика, в попытке предсказать затор и избежать его в общей сети и в межсетевых узких местах, до того как затор станет проблемой. Эти методы обеспечивают предпочтительную обработку для премиум (приоритетного) трафика при наличии заторов, одновременно увеличивая пропускную способность сети и её ёмкость с минимизацией потерь пакетов и задержек. Например, CISCO IOS QoS включает взвешенное произвольное раннее обнаружение (WRED) в качестве возможного решения для предотвращения затора.

Алгоритм WRED позволяет избежать затора на сетевом интерфейсе, обеспечивая управление буфером и позволяя TCP трафику уменьшиться или сократить нагрузку до того момента, пока буферы будут заполнены. Использование WRED помогает избежать отбрасывания хвоста очереди и максимизировать использование сети и производительность для базирующихся на TCP приложений. Во WRED нет механизма предотвращения затора для UDP трафика, например, голосового трафика. В случае UDP трафика, методы, такие как очереди и сжатие помогут уменьшить и даже предотвратить потерю пакетов для UDP трафика.

Shaping and Policing

Трафик шейпинг и политики трафика - это 2 механизма, предусмотренных программным обеспечением CISCO IOS QoS для предотвращения заторов.

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

Шейпинг предполагает наличие очереди и достаточного объёма памяти для буфера задержки пакетов, а политики - нет.

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

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

Убедитесь, что имеется достаточно памяти при включении шейпинга. Кроме того, шейпинг требует функции планирования для последующей передачи любого отложенного пакета. Эта функция планирования позволяет организовать формирование очереди в разных очередях. Примеры функции планирования: CBWFQ и LLQ.

4.11: Cloud and Virtualization

Cloud Computing

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

Позволяет доступ к данным организации в любое время в любом месте;
Рационализирует IT операции в организации подпиской только на необходимое обслуживание;
Устраняет или снижает необходимость в локальном IT оборудовании, поддержке и управлении;
Сокращает стоимость оборудования, энергии, установки обрудования и обучения персонала;
Обеспечивает быстрое реагирование на рост требований к объему данных.

Облачные вычисления, со своей моделью “pay-as-you-go”, позволяют организациям обходиться с затратами на компьютеризацию и хранение данных более практично нежели инвестиции в инфраструктуру. Капитальные расходы трансформируются в операционные расходы.

Cloud Services

Облачные сервисы доступны разнообразием опций, адаптированных чтобы соответствовать требованиям пользователей. Основные 3 облачных компьютерных сервиса определены Национальным Институтом Стандартов и Технологий (National Institute of Standards and Technology (NIST)) в специальной публикации 800-145 как следующие:

Software as a Service (SaaS): Поставщик отвечает за доступ к сервису, такому как почта, коммуникации и Офис 365, которые доступны посредством интернета. Пользователю лишь нужно вносить свои данные;
Platform as a Service (PaaS): Поставщик отвечает за доступ к средствам разработки и сервисам, используемым для доставки приложений;
Infrastructure as a Service (IaaS): Поставщик отвечает за доступ к сетевому оборудованию, виртуализированным сетевым сервисам и к поддержке сетевой инфраструктуры.

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

Для бизнеса ITaaS может расширить IT возможности без инвестирования, обучения нового персонала или лицензирования нового ПО. Эти сервисы доступны по требованию и предоставляются экономично для любого устройства в любом месте без ущерба для безопасности или функциональности.

Cloud Models

Существует 4 основных типа Облаков:

Public clouds: Облачные приложения и сервисы, предлагаемые в публичных облаках, сделаны доступными для всех. Сервис может быть бесплатным или иметь модель pay-per-use, как например плата за онлайн дисковое пространство. Публичные облака используют Интернет для предоставления сервисов;
Private clouds: Облачные приложения и сервисы, предлагаемые в приватных облаках, предназначены для некоторой организации или группы людей, например правительства. Приватные облака могут быть созданы на основе приватных сетей организаций, хотя это может быть и дорого для создания и поддержания. Приватные облака могут также обслуживаться сторонней организацией со строгой системой безопасности;
Hybrid clouds: Гибридные облака состоят из 2 или более облаков (например: часть приватная, часть публичная), где каждая часть остаётся отдельным объектом, но они обе связаны с использованием общей архитектуры. Пользователи гибридных облаков получают различную степень доступа к сервисам на основе прав доступа;
Custom clouds: Облака, построенные чтобы соответствовать потребностям специфичной области, такой как здравоохранение или пресса. Кастомные облака могут быть приватными или публичными.

Cloud Computing versus Data Center

Термины Data Center и Cloud computing часто используют неправильно. Вот корректные определения для этих понятий:

Data center: Обычно хранилище данных и обрабатывающая данные серверная, работающая в здании IT департамента или арендованного помещения;
Cloud computing: Обычно удалённый сервис, который предлагает по запросу доступ к разделяемому пулу конфигурируемых компьютерных ресурсов. Эти ресурсы могут быть быстро предоставлены и также быстро освобождены после использования с минимальными усилиями по обслуживанию.

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

Облачные вычисления - это обычно сервис, предоставляемый дата центрами:

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

Virtualization

Термины "облачные вычисления” и “виртуализация” часто используются как синонимы, однако они имеют в виду разные вещи. Виртуализация является основой облачных вычислений. Без неё облачные вычисления, как они сейчас широко распространены, не были бы возможными.

Разница между облачными вычислениями и виртуализацией:

Облачные вычисления отделяет приложения от аппаратного обеспечения;
Виртуализация отделяет ОС от аппаратного обеспечения.

Различные провайдеры предлагают виртуальные облачные услуги, которые могут динамически резервировать сервера под свои задачи по мере необходимости. Например, Amazon Elastic Compute Cloud (Amazon EC2) - это веб-сервис, предоставляющий простой способ для клиентов, чтобы динамически резервировать вычислительные ресурсы, которые им нужны. Эти виртуализованные экземпляры серверов создаются по требованию в Amazon EC2.

Dedicated Servers

Чтобы в полной мере оценить виртуализацию, прежде всего, необходимо понять некоторые моменты в истории серверной технологии. Исторически сложилось так, что корпоративный сервер состоит из серверной операционной системы (ОС), такой как Windows Server или Linux, установленной на специальном оборудовании. Все серверная RAM, CPU и место на жестком диске были выделены предоставляемому сервису (например Web, E-mail и так далее).

Основная проблема при такой конфигурации заключается в том, что когда какой-либо компонент даёт сбой, то сервис, который предоставляется сервером, становится недоступным. Это известно как единая точка отказа. Другая проблема заключалась в том, что сервера были недогружены. Выделенные сервера простаивали без нагрузки долгие периоды времени, ожидая пока не возникнет необходимость предоставить определённый сервис для использования. Эти сервера впустую потребляли энергию и занимали больше места, чем было необходимо для этого объёма сервисов. Это известно как разрастание серверного оборудования (server sprawl).

Server Virtualization

Виртуализация серверов использует простаивающие ресурсы и консолидирует количество необходимых серверов. Это также позволяет существовать нескольким операционным системам на одной аппаратной платформе.

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

Гипервизор - это программа, Firmware или аппаратное обеспечение, которое добавляет уровень абстракции поверх реального физического оборудования. Абстрактный слой используется для создания виртуальных машин, которые имеют доступ ко всей аппаратной части физического компьютера, таких как CPU, RAM, контроллеры дисков и сетевые карты. Каждая из этих виртуальных машин выполняет отдельную операционную систему. Благодаря виртуализации, предприятия теперь могут консолидировать ряд серверов. Например, это не редкость, что 100 физических серверов были консолидированы в виртуальные машины на 10 физических серверах с использованием гипервизоров.

Использование виртуализации обычно включает избыточность для защиты от единой точки отказа. Избыточность может быть реализована различными способами. Если гипервизор отказал, то виртуальная машина может быть перезапущена на другом гипервизоре. Кроме того, одна VM может работать на двух гипервизоров одновременно, копируя содержимое RAM и инструкции процессора между ними. Если один гипервизор выходит из строя, виртуальная машина продолжает работать на другом гипервизоре. Сервис, запущенный на виртуальной машине, также является виртуальным и может динамически устанавливаться и удаляться по мере необходимости.

Advantages of Virtualization

Основным преимуществом виртуализации является общее снижение стоимости:

Нужно меньше оборудования - Виртуализация позволяет консолидировать сервера, поэтому требуется меньше физических серверов, меньше сетевого оборудования и меньше поддерживающей инфраструктуры. Это также означает меньшую стоимость обслуживания;
Потребляется меньше энергии - Консолидация серверов снижает затраты энергии на работу серверов и охлаждениеConsolidating servers lowers the monthly power and cooling costs. Пониженное потребление позволяет снизить выбросы парниковых газов;
Требуется меньше места - Консолидация серверов позволяет снизить общее количество места, необходимого для дата-центра.

Дополнительные преимущества виртуализации:

Облегчённое создание прототипа - Собственные тестовые лаборатории могут быть быстро развёрнуты для тестирования и создания прототипов реальных компьютерных сред - серверов и оборудования. Если в процессе тестирования допущена ошибка, то администратор может просто вернуться к предыдущей версии. Такая тестовая лаборатория может использоваться изолированно от конечного пользователя. Когда тестирование закончено, сервера и системы переводятся в продакшен;
Быстрое обслуживание серверов - Создание виртуального сервера требует меньше времени, чем обслуживание физического;
Увеличенный ап-тайм серверов - Большинство платформ виртуализации сейчас предлагают расширенную избыточность для защиты от падения, такую как live migration, storage migration, high availability и распределенное планирование ресурсов. Также есть возможность в реальном времени переносить работающую виртуальную машину с 1 сервера на другой;
Улучшенное восстановление - Виртуализация предлагает передовые решения для обеспечения непрерывности бизнеса. Она предоставляет возможность аппаратной абстракции, так например восстановление сайта компании не требует идентичного аппаратного обеспечения, которое было использовано для него в продакшене. Большинство корпоративных платформ серверной виртуализации также имеют программное обеспечение, которое поможет в тестировании и автоматизации перехода в виртуальную среду;
Поддержка устаревшего - Виртуализация может продлить жизнь ОС и приложений, предоставляя больше времени для организаций чтобы мигрировать на новые решения.

Abstraction Layers

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

Services;
OS;
Firmware;
Hardware.

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

Пример виртуализации показан на рисунке. Гипервизор установлен между Firmware и ОС. Такой гипервизор может поддерживать множество ОС.

Type 2 Hypervisors

Гипервизор - это программа, которая создает и запускает экземпляры виртуальных машин. Компьютер, на котором гипервизор поддерживает одну или более виртуальных машин, является хостом (host machine). Гипервизоры типа 2 называются также hosted гипервизоры. Это происходит потому, что гипервизор устанавливается на существующую ОС, такую как Mac OSX, Windows или Linux. Затем один или несколько дополнительных экземпляров ОС устанавливается на гипервизор.

Большое преимущество гипервизора типа 2 заключается в том, что программное обеспечение консоли управления не требуется.

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

Virtual PC;
VMware Workstation;
Oracle VM VirtualBox;
VMware Fusion;
Mac OSX Parallels.

Многие из этих гипервизоров бесплатны. Некоторые предлагают дополнительные возможности за дополнительную плату.

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

Virtual Network Infrastructure

Type 1 Hypervisors

Тип 1 гипервизоров также называют "на голое железо” (bare metal) - подход, при котором гипервизор устанавливается непосредственно на Hardware. Тип 1 гипервизоры, как правило, используется на серверах предприятия и сетевых устройствах дата центра.

Тип 1 гипервизор устанавливается непосредственно на сервер или сетевое оборудование. Затем, экземпляры ОС устанавливаются на гипервизор. Тип 1 гипервизоры имеют прямой доступ к аппаратным ресурсам, следовательно, они более эффективны, чем hosted. Тип 1 гипервизоры повышают масштабируемость, надежность и производительность.

Популярные гипервизоры тип 1:

Citrix XenServer;
Microsoft Hyper-V 2008/2012;
Oracle VM Server for x86/SPARC;
VMware ESXi.

Installing a VM on a Hypervisor

При установке типа 1 гипервизора и перезагрузке сервера, отображается только основная информация, такая как версия ОС, объем RAM и IP-адрес. Экземпляр ОС не может быть создан из этого экрана. Тип 1 гипервизоры требуют консоль управления для управления гипервизором. Программа управления используется для управления несколькими хост серверами, использующими один и тот же гипервизор. Консоль управления может автоматически консолидировать серверы и управлять серверами по мере необходимости.

Например, предположим, что Server1 достигает минимума свободных ресурсов. Чтобы высвободить ресурсы, консоль управления перемещает экземпляр Windows в гипервизор на Server2.

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

Некоторые консоли управления также позволяют Over allocation. Over allocation - это когда установлены множественные экземпляры ОС, но их общая память превышает общий объем физической памяти в сервере. Например, сервер имеет 16Gb оперативной памяти, но администратор создает четыре экземпляра ОС с 10Gb оперативной памяти каждый. Этот тип выделения - обычная практика, потому что экземпляры всех четырех ОС редко требуют все 10Gb оперативной памяти в любой момент.

Network Virtualization

Виртуализация скрывает ресурсы серверной системы (например, количество и параметры физических серверов, процессоры и ОС) от пользователей. Эта практика может создать проблемы, если центр обработки данных использует традиционную сетевую архитектуру.

Например, виртуальные локальные сети (VLAN), используемые виртуальными машинами, должны быть назначены на тот же порт коммутатора как и физический сервер под управлением гипервизора. Однако, виртуальные машины являются подвижными, и сетевой администратор должен иметь возможность добавлять, удалять и изменять сетевые ресурсы и профили. Этот процесс сложно сделать с традиционными сетевыми коммутаторами.

Другая проблема заключается в том, что транспортные потоки существенно отличаются от традиционной клиент-серверной модели. Как правило, центр обработки данных имеет значительный объем трафика между виртуальными серверами (именуемый East-West traffic). Эти потоки меняют положение и интенсивность с течением времени, требуя гибкого подхода к сетевому управлению ресурсами.

Существующие сетевые инфраструктуры могут реагировать на изменения требований, связанных с управлением транспортными потоками с использованием качества обслуживания (QoS) и конфигурацией уровня безопасности для отдельных потоков. Однако, на крупных предприятиях с использованием оборудования разных производителей, каждый раз, когда новая виртуальная машина добавлена, необходимая реконфигурация может быть очень трудоемкой.

Может ли сетевая инфраструктура также выиграть от виртуализации? Если да, то как?

Ответ можно найти в том, как сетевое устройство работает с помощью плоскости данных и плоскости управления - Network Programming.

4.12: Network Programming

SDN Control Plane and Data Plane

Сетевое устройство содержит следующие уровни:

Control plane (Уровень управления) - как правило рассматривается как мозг устройства. Этот уровень используется для принятия решения о маршрутизации пакета. Уровень управления содержит механизм перенаправления маршрута (включает в себя механизм на Уровне 2 и 3), туда входят: таблица соседей для протокола маршрутизации, таблица топологии, таблицы маршрутизации для IPv4 и IPv6, таблица STP, таблица ARP. Сведения, отправляемые на уровень управления, обрабатываются процессором;
Data plane (Уровень данных) - также его называют перенаправляющий уровень, этот уровень является, как правило, структурой внутри коммутатора, соединяющей различные сетевые порты на устройстве. Уровень данных каждого устройства используется для перенаправления транспортных потоков. Маршрутизаторы и коммутаторы используют информацию от уровня управления, чтобы направить входящий трафик на соответствующий интерфейс выхода. Информация на уровне данных обычно обрабатываются специальным процессором обработки данных, таким как цифровой процессор сигналов (DSP), без вмешательства центрального процессора на уровне управления.

В примере показано, как Cisco Express Forwarding (CEF) использует уровень управления и уровень данных для обработки пакетов.

CEF - это продвинутая, Уровня 3 технология IP коммутации, которая обеспечивает передачу пакетов только за счёт уровня данных без задействования уровня управления. В CEF, таблица маршрутизации на уровне управления предварительно заполняет CEF Forwarding Information Base (FIB) таблицу на уровне данных. ARP таблица на уровне управления предварительно заполняет таблицу Adjacency (Смежности) на уровне данных. После этого пакеты перенаправляются напрямую на уровне данных, на основании информации, содержащейся в FIB и Adjacency таблицах, без необходимости обращения к информации на уровне управления.

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

Network Virtualization

Более десяти лет назад, компания VMware разработала технологию виртуализации, которая включает для хостовой ОС поддержку одной или более клиентских ОС. Большинство технологий виртуализации сейчас основываются на этой технологии. Преобразование выделенных серверов в виртуальные серверы было широко поддержано и быстро внедряется в дата центрах и корпоративных сетях.

Основные 2 сетевые архитектуры были разработаны для поддержки виртуализации сети:

Software Defined Networking (SDN) - сетевая архитектура, которая виртуализирует сеть;
Cisco Application Centric Infrastructure (ACI) - специальное аппаратное решение для интеграции управления облачными вычислениями и дата центрами.

Также есть ещё несколько других технологий виртуализации сети, некоторые из которых включены как компоненты в SDN и ACI:

OpenFlow - этот протокол был разработан в Stanford University для управления трафиком между коммутаторами, маршрутизаторами, беспроводными точками доступа и контроллером. OpenFlow протокол является базовым элементом для построения решений SDN;
OpenStack - этот подход является платформой для виртуализации и согласования (orchestration), пригодной для создания масштабируемых облачных сред и предоставления решений инфраструктура как сервис (IaS). Openstack часто используется вместе с CISCO ACI. Согласование (orchestration) в области сетевых технологий - это процесс автоматизации подготовки к работе компонентов сети таких как серверы, системы хранения данных, коммутаторы, маршрутизаторы и приложения;
Other components - остальные компоненты включают в себя: Interface to the Routing System (I2RS), Transparent Interconnection of Lots of Links (TRILL), Cisco FabricPath (FP), и IEEE 802.1aq Shortest Path Bridging (SPB).

SDN Architecture

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

Software defined networking (SDN) - это сетевая архитектура, которая была разработана для виртуализации сети. Например, SDN может виртуализировать уровень управления. Также известен Controller-based SDN - SDN переносит уровень управления с каждого сетевого устройства на центральное устройство, являющееся интеллектуальным центром, центром внедрения политик и называемое SDN controller. Обе архитектуры показаны на рисунке:

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

SDN Framework показан на рисунке. Обратите внимание на использование Application Programming Interfaces (APIs) в рамках SDN Framework. API - это набор стандартизированных запросов, которые определяют правильный способ для приложения, как запросить обслуживание от другого приложения. SDN Controller использует APIs "северного направления" для взаимодействия с вышестоящими приложениями. Эти API помогают сетевым администраторам создавать шейпинг трафика и развертывать сервисы. SDN Controller также использует APIs "южного направления", чтобы определить поведение нижестоящих виртуальных коммутаторов и маршрутизаторов. OpenFlow является изначальным и широко внедренным API южного направления. Open Networking Foundation отвечает за поддержку OpenFlow стандарта.

Примечание. Трафик в современном дата центре описывается как North-South (идущий между данными внешних пользователей и серверами дата центра) и East-West (идущий между серверами дата центра).

SDN Controllers

Чтобы узнать больше о SDN, OpenFlow и Open Networking Foundation.

SDN Controller and Operations

SDN Controller определяет потоки данных, возникающие на уровне данных SDN. Поток представляет собой последовательность пакетов, проходящих через сеть, которые объединяет одинаковый набор значений полей заголовков. Например, поток может состоять из всех пакетов с одинаковым значением IP-адреса источника и с одинаковым значением IP-адреса назначения или все пакеты с одинаковым идентификатором VLAN.

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

Все сложные функции выполняет SDN Controller. SDN controller заполняет таблицы потока (flow tables) и коммутаторы затем управляют этими таблицами потока. На рисунке, SDN Controller взаимодействует с OpeFflow совместимым коммутатором, используя OpenFlow протокол. Этот протокол использует Transport Layer Security (TLS), чтобы безопасно переслать сообщения уровня управления по сети. Каждый OpenFlow коммутаторов подключается к другим OpenFlow коммутаторам. Они также могут быть подключены к устройствам конечных пользователей, которые являются частью потока пакетов.

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

Flow Table - выявляет соответствие входящих пакетов конкретному потоку и определяет функции, которые должны быть выполнены над этими пакетами. Может быть несколько таблиц потока, которые работают по принципу конвейера;
Meter Table - инициирует выполнение разнообразных действий, связанных с производительностью на потоке.

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

Application Centric Infrastructure (ACI)

Очень немногие организации на самом деле имеют желание или навыки программировать сети, используя инструменты SDN. Тем не менее, большинство организаций хотят автоматизировать сеть, ускорить развертывание приложений и выстроить свою IT инфраструктуру, чтобы лучше удовлетворять бизнес требованиям. Компания CISCO разработала Application Centric Infrastructure (ACI) для достижения этих целей в более передовой и инновационной манере, чем ранние SDN подходы.

ACI - это архитектура сети центра обработки данных, которая была разработана компанией Insieme, которая приобретена CISCO в 2013 году. CISCO ACI - это специализированное аппаратное решение для интеграции облачных вычислений и управления дата центром. В общих чертах: элементы политики сети удаляется из уровня данных. Это упрощает создание сети дата центра.

Core Components of ACI

Основные 3 компонента архитектуры ACI:

Application Network Profile (ANP) – ANP является коллекцией групп (EPG), которые представляют собой конечные точки, их связей между собой, и политик, определяющих эти связи. Примеры EPG показаны на рисунке: это VLANs, Web Services и приложения. На самом деле ANP обычно гораздо более сложен;
Application Policy Infrastructure Controller (APIC) – APIC рассматривается как мозг архитектуры ACI. APIC представляет собой централизованный программный контроллер, который управляет масштабируемой кластерной структурой ACI. Он предназначен для программирования и централизованного управления. Он транслирует политики приложения в сетевое программирование;
Cisco Nexus 9000 Series switches – эти коммутаторы предоставляют ориентированную на приложения (application-aware) коммутирующую структуру и работают с APIC для управления виртуальной и физической инфраструктурой сети.

Как показано на рисунке, APIC расположен между APN и сетевой инфраструктурой с задействованием ACI. APIC транслирует требования приложений в сетевую конфигурацию, для удовлетворения этих потребностей.

Leaf-Spine Topology

CISCO ACI структура состоит из APIC и коммутаторов серии CISCO Nexus 9000, используя двухуровневую Leaf-Spine (Лист-Ствол) топологию, как показано на рисунке. Коммутаторы уровня Leaf всегда соединены с уровнем Spine, но они никогда не соединены друг с другом. Аналогично, коммутаторы уровня Spine соединены только с коммутаторами уровня Leaf и с коммутаторами уровня ядра (не показаны на рисунке). В этой двухуровневой топологии, все связи являются 1 переходом от другого уровня.

Cisco APICs и все другие устройства в сети физически соединены с коммутаторами уровня Leaf.

По сравнению с SDN, контроллер APIC не воздействует на путь данных напрямую. Вместо этого APIC централизует политики и программирует коммутаторы уровня Leaf для пересылки трафика на основе установленных политик.

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

Microsoft (Hyper-V/SCVMM/Azure Pack);
Red Hat Enterprise Linux OS (KVM OVS/OpenStack);
VMware (ESX/vCenter/vShield).

SDN Types

CISCO Application Policy Infrastructure Controller - Enterprise Module (APIC-EM), расширяющий ACI, нацелен на развертывание в энтерпрайзных и кампусных сетях. Для лучшего понимания APIC-EM будет полезно взглянуть на 3 типа SDN.

Device-based SDN

В этом типе SDN устройства программируются с помощью приложения запущенного на самом устройстве или на сервере в сети, как показано на рисунке. CISCO OnePK является примером устройства на основе device-based SDN. Это позволяет программистам создавать приложения на C, Java и Python, чтобы создавать интеграцию и взаимодействовать с устройствами CISCO.

Controller-based SDN

Это тип SDN использует централизованный контроллер, обладающий знаниями обо всех устройствах в сети, как показано на рисунке. Приложения могут взаимодействовать с контроллером, отвечающим за управление устройствами и управление потоками трафика по всей сети. CISCO Open SDN Controller - это коммерческое решение, основанное на проекте OpenDaylight.

Policy-based SDN

Это типа SDN похож на Controller-based SDN, где централизованный контроллер имеет представление о всех устройствах в сети, как показано на рисунке. Policy-based SDN включает в себя дополнительный уровень политик, который работает на более высоком уровне абстракции. Он использует встроенные приложения, которые автоматизируют расширенные задачи конфигурирования через управляемый рабочий процесс и дружественный GUI, не требующий навыков программирования. CISCO APIC-EM является примером этого типа SDN.

APIC-EM Features

Каждый тип SDN имеет свои фичи и преимущества. Policy-based SDN наиболее надежный, обеспечивающий простой механизм для контроля и управления политиками по всей сети. CISCO APIC-EM обеспечивает следующие функции:

Discovery - поддерживает функции обнаружения, которые используются для заполнения контроллера и базы данных хостов (host inventory database);
Device Inventory - собирает подробную информацию от устройств в сети, включая имя устройства, состояние устройства, MAC-адрес, IPv4/IPv6 адрес, IOS/Firmware, платформу, время с момента включения и конфигурацию;
Host Inventory - собирает подробную информацию от устройств в сети, включая имя устройства, состояние устройства, MAC адрес, IPv4/IPv6 адрес и точку включения в сеть;
Topology - поддерживает графическое представление сети (topology view). CISCO APIC-EM автоматически обнаруживает и заносит устройства в физическую топологию с подробными данными об устройстве. В дополнение, авто визуализация топологии уровня 2 и 3 поверх физической топологии предоставляет детальный просмотр для дизайна, планирования и облегчённого траблшутинга. На рисунке приведен пример топологии сгенерированнной Cisco APIC-EM;
Policy - возможность просмотра и контроля политик в масштабе всей сети, включая QoS;
Policy Analysis - контроль и анализ сетевых политик контроля доступа. Возможность отслеживать специфичные пути приложения между конечными устройствами для быстрого определения ACL, которые используются в проблемных областях. Даёт возможность управления изменениями в ACL с лёгким определением избыточности, конфликтов и неправильного порядка записей в ACL. Некорректные вхождения ACL известны как тени (shadows).

APIC-EM ACL Analysis

Одной из важнейших особенностей CISCO APIC-EM контроллера является возможность управлять политиками сразу во всей сети. Политики работают на более высоком уровне абстракции. Традиционное конфигурирование устройства применяется к одному устройству, а SDN политики распространяются на всю сеть.

APIC-EM ACL Analysis and Path Trace предоставляет средства, позволяющие администратору анализировать и понимать ACL политики и конфигурации. Создание новых или редактирование существующих ACL по всей сети для реализации новой политики безопасности может стать сложным делом. Администраторы не решаются изменять ACL из страха нарушить их работу и создать новые проблемы. ACL Analysis and Path Trace позволяет администратору легко визуализировать потоки трафика и обнаружить любой конфликт, дубликат или тень записей ACL.

APIC-EM предоставляет следующие инструменты для устранения неполадок записей ACL:

ACL Analysis

Этот инструмент проверяет корректность ACL на устройствах, выискивая избыточность, противоречия или теневые записи. ACL Analysis позволяет проводить инспекцию ACL и опрос по всей сети, показывая любые проблемы и конфликты. Скриншот примера работы этого инструмента показана на рисунке:

ACL Path Trace

Этот инструмент инспектирует конкретные списки ACL на пути между двумя конечными узлами, показывая любые потенциальные проблемы. Скриншот примера работы этого инструмента показана на рисунке:

4.13: Using IP SLA

IP Service Level Agreements (SLA - Соглашение об уровне обслуживания) - это опция CISCO IOS, которая позволяет анализировать уровни IP сервиса. IP SLAs использует сгенерированный трафик чтобы измерить производительность сети между 2 сетевыми устройствами, несколькими сетевыми расположениями или через несколько сетевых маршрутов. Сетевые инженеры используют IP SLAs чтобы симулировать сетевой трафик и IP сервисы и в результате получать информацию о производительности сети в реальном времени. Мониторинг производительности может быть выполнен в любое время, в любом месте без внедрения физических устройств для сбора информации (зондирования).

Примечание. Ping и Tracerout это инструменты для зондирования. Физические зонды другие. Это устройства, которые могут быть помещены где-то в сети чтобы собирать и мониторить трафик. Использование физических зондов за рамками этого курса.

Измерения предоставляемые различными IP SLA операциями могут могут быть использованы для траблшутинга сетевых операций посредством предоставления последовательных, надежных измерений, которые немедленно идентифицируют проблему и сохраняют время на устранение проблем сети. Дополнительные 4 преимущества IP SLA перечислены ниже:

Мониторинг, измерение и проверка с использованием SLA;
Мониторинг производительности сети:
- Измерение джиттера, задержки или потери пакетов в сети;
- Обеспечение непрерывных, надёжных и ожидаемых измерений;
Оценка состояния сети для того чтобы убедиться, что существующие QoS достаточны для новых IP сервисов;
Мониторинг доступности сети от края до края (end-to-end) для профилактической (упреждающей) проверки подключённых сетевых ресурсов.

Множественные IP SLAs операции могут быть запущены в сети или на устройстве в любое время. IP SLAs можно использовать через командную строку (CLI) или через Simple Network Management Protocol (SNMP).

Примечание. Сообщения SNMP, базирующиеся на данных, собранных с помощью IP SLA - за рамками этого курса.

Конфигурирование IP SLA

Вместо того чтобы вручную запускать пинг, сетевой инженер может использовать IP SLA ICMP Echo для того чтобы тестировать доступность сетевого оборудования. Сетевым оборудованием при этом может быть любое оборудование с IP адресом (маршрутизатор, коммутатор, PC, сервер и так далее). IP SLA ICMP Echo предоставляет возможность следующих 3 измерений:

Мониторинг доступности (availability monitoring) - статистика потерянных пакетов;
Мониторинг производительности (performance monitoring) - задержка и время ответа;
Работа сети (network operation) - сквозное подключение (end-to-end connectivity).

Используете команду привилегированного EXEC режима:

show ip sla application

чтобы проверить, что желаемый IP SLA функционал (специфичная SLA операция) доступен на устройстве-источнике.

Шаги и команды конфигурирования IP SLA

Основные шаги конфигурирования IP SLA ICMP Echo:

Конфигурирование расписания:

Чтобы запретить IP SLA операции введите команду глобального режима конфигурации:

no ip sla operation-number

Пример IP SLA

IP SLA ICMP Echo конфигурируется на R1.

Команда ip sla создаёт IP SLA операцию с номером 1. Множественные IP SLA операции могут быть сконфигурированы на устройстве, каждая операция должна быть соотнесена с уникальным номером (operation-number).

Команда icmp-echo определяет адрес назначения для мониторинга. В примере интерфейс S1 маршрутизатора R3 выбран для мониторинга.

Команда frequency устанавливает частоту IP SLA на 30 секундный интервал.

Команда ip sla schedule создаёт расписание для IP SLA операции номер 1: стартовать немедленно (now) и продолжаться пока не будет отменено (forever).

Примечание. Используйте команду no ip sla schedule (operation-number) чтобы отменить IP SLA операцию. Конфигурация SLA операции при этом сохранена и может быть запущена с другим расписанием.

Проверка IP SLA

Используйте команду:

show ip sla configuration [operation-number]

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

Просматривайте вывод команды show ip sla configuration для того проверить настройки вашей конфигурации.

Просмотр статистики IP SLA операции

Используйте команду :

show ip sla statistics [operation-number]

чтобы отобразить результаты мониторинга для IP SLA операции.

Пример показывает что последний пинг интерфейса S1 маршрутизатора R3 имел 12 ms задержку (RTT). С того момента как операция стартовала, проверка соединения была проведена 57 раз без сбоев.

В заключение

CISCO расширила свой курс CCNA R&S и добавила туда много интересных вещей, пусть даже в самом общем виде.