Технология 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 поддерживает следующие тесты:

c2821(config)#ip sla monitor 19
c2821(config-sla-monitor)#type ?
dhcp DHCP Operation
dlsw DLSW Operation
dns DNS Query Operation
echo Echo Operation
frame-relay Perform frame relay operation
ftp FTP Operation
http HTTP Operation
jitter Jitter Operation
pathEcho Path Discovered Echo Operation
pathJitter Path Discovered Jitter Operation
slm SLM Operation
tcpConnect TCP Connect Operation
udpEcho UDP Echo Operation
voip Voice Over IP measurement


Подробно о каждом тесте говорить смысла нет. Способы конфигурирования и что можно получить, используя тот либо иной тест, можно узнать на сайте Cisco. В общем же случае, Cisco умеет:

• выполнять тест
• можно вывести результаты теста с помощью командной строки
• результаты тестов сохраняются и доступ к ним можно получить по SNMP
• можно настроить отправку SNMP trap и syslog сообщений, информирующих о неудовлетворительных и удовлетворительных результатах тестов
• можно сконфигурировать Cisco, так чтобы он принимал решения о маршрутизации на основе результатов тестов.

IP SLA и принятие решений маршрутизации.

На текущий день не редки ситуации, когда у конечного пользователя Интернет существует множество Интернет каналов предоставляемых одним или несколькими провайдерами. Главное преимущество наличия нескольких каналов связи это минимизирование рисков простоя в случае сбоев. В случае наличия нескольких каналов связи решение о том, через какой из них маршрутизировать трафик можно принимать на основе доступности канала. В классической ситуации, без IP SLA тестов, о доступности канала связи можно судить по состоянию интерфейса. Однако состояние интерфейса не всегда однозначно говорит о доступности канала передачи данных. Например, если у вас маршрутизатор подключен к DSL модему по Ethernet, то в случае сбоя связи в DSL вы не сможете его выявить стандартными способами. Наличие различных IP SLA тестов позволяет выявлять подобные ситуации. На текущий, день в IOS существует возможность принимать решения о маршрутизации на основе результатов IP SLA тестов. Описывать, как все настраивается, я не берусь, так как не использовал такие методы. Однако на сайте Cisco все, как всегда, понятно описано. Вот пример для Policy Based Routing with the Multiple Tracking Options Feature

ip sla или как сделать чтобы красиво работал основный\бэкапный каналы без BGP.


Итак, у нас есть маршрутизатор Cisco и 2 канала, основной и бэкапный.

Мы хотим

1. чтобы когда отваливался основной, работал бэкапный (и когда основной
поднялся, маршрут обратно переписывался на него)

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

Оба провайдера у нас через ethernet, и статический маршрут не исчезнет
при падении провайдера.

Настроим IP SLA для проверки доступности провайдеров
(пингуем наши дефолт-гейтвеи)




Метод icmp-echo не очень хорош, т.к. при пропадании одного icmp пакета,
что случается чаще чем я думал (можно глянуть коммандой show track),
идёт переключение маршрута(об этом чуть позже). Лучше использовать, icmp-jitter
(доступен с только с 12.4Т), тк. он пускает несколько пакетов.
Например:




И собственно добавим статические маршруты на провайдеров.



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

При отсутствии AD (Administrative Distance) в ip route у статических маршрутов будет load blancing
(per destanation, при влючённом ip cef. Т.е. на один dst-ip всё поёдет через одного провайдера, на другой dst-ip через другого)

Добавим еще PolicyBasedRouting (если у нас не симметричные каналы, или мы хотим чтобы
некоторые внутренние хосты выходили через конкретного провайдера, а в
случае его падения через бэкапного). В route-map выставляется приоритет
на лучшего провайдера.

рисуем рoут мап




указывем в acl внутренних хостов



И вешаем




На интерфейс который смотрит в локалку.

При такой конфигурации переход на живого провайдера происходит примерно
за время timeout в ip sla, т.е. 2 секунды.