Автор:Сгибнев Михаил
v2010030200
Данная статья чуть менее чем полностью является переводом Cisco IOS IP SLAs Configuration Guide, Release 12.4 и предназначена для выступления в роли простейшего HOW-TO.
Cisco IOS IP Service Level Agreements (SLAs) дает возможность гарантировать клиентам работу business-critical приложений, таких как голос, видео и критичные к задержкам данные. Технология SLAs была разработана для повышения уровня мониторинга IP-инфраструктуры. С помощью Cisco IOS IP SLAs пользователи могут проверить качество предоставляемого сервиса, увеличить надежность сети, подтвердить заявленную поставщиком пропускную способность канала, проактивно идентифицировать сетевые проблемы. Cisco IOS IP SLAs использует активный метод контроля, генерируя трафик непрерывным, надежным, и предсказуемым способом, позволяя таким образом измерить производительность и качество сети.
Принцип действия данной технологии традиционен и прост — маршрутизатор на одной стороне канала генерирует трафик с заданными параметрами, маршрутизатор на второй стороне канала выступает в роли ответчика.
Рассмотрим наиболее часто употребляемые типы генерируемого трафика:
IP SLAs UDP
Механизм определения джиттера IP SLAs UDP был разработан в первую очередь с целью определения пригодности канала для передачи голосовой и видео информации. Как сказано в Википедии, под джиттером часто понимается разброс максимального и минимального времени прохождения пакета от среднего. К примеру, посылается 100 пакетов минимальное время прохождения пакета — 395 мс, среднее — 400 мс, максимальное — 405 мс, в этом случае джиттер можно считать маленьким. Если же посылается 100 пакетов минимальное время прохождения пакета — 1 мс, среднее — 50 мс, максимальное — 100 мс, в этом случае джиттер большой.
В этом (и во всех последующих) случае, ответчик конфигурируется следующим образом:
enable
configure terminal
ip sla monitor responder
Конфигурация генератора определяется следующими параметрами:
Параметр | Значение по умолчанию | Пример использования |
Число пакетов | 10 | type jitter dest-ipaddr command, num-packets option |
Размер пакета | 32 bytes | request-data-size command |
Интервал между пакетами, мс | 20 ms | type jitter dest-ipaddr command, interval option |
Интервал между сериями, сек | 60 | frequency (IP SLA) command |
Простейшая конфигурация выглядит так:
enable
configure terminal
ip sla monitor operation-number
type jitter dest-ipaddr {hostname | ip-address} dest-port port-number [num-packets number-of-packets] [interval inter-packet-interval]
frequency seconds
exit
ip sla monitor schedule operation-number [life {forever | seconds}] [start-time {hh:mm[:ss] [month day | day month] | pending | now | after hh:mm:ss] [ageout seconds] [recurring]
exit
show ip sla monitor configuration [operation-number]
Пример:
ip sla monitor 1
type jitter dest-ipaddr 20.0.10.3 dest-port 65051 num-packets 20
request-data-size 160
tos 128
frequency 30
ip sla monitor schedule 1 start-time after 00:05:00
ip sla monitor 2
type jitter dest-ipaddr 20.0.10.3 dest-port 65052 num-packets 20 interval 10
request-data-size 20
tos 64
frequency 30
ip sla monitor schedule 2 start-time after 00:05:05
Посмотреть результаты можно командой:
show ip sla monitor configuration 1
Для оценки пригодности канала под использование Voice over IP (VoIP) существует IP SLAs VoIP UDP. При этом осуществляется эмуляция кодеков g.711a/m и g.729 и вычисляется voice quality scores (MOS и ICPIF). Конфигурация при этом выглядит так:
ip sla monitor 1
type jitter dest-ipaddr 20.0.10.3 dest-port 16001 codec g729a
tos 184
frequency 60
request-data-size 172
exit
ip sla monitor schedule 1 start-time now life forever
ip sla monitor 2
type jitter dest-ipaddr 209.165.200.225 dest-port 16384 codec g711alaw advantage-factor 2
exit
ip sla monitor schedule 2 start-time now
Аналогично выглядит настройка IP SLAs TCP, которая позволяет определить время, затраченное на операцию TCP Connect между маршрутизатором Cisco и каким-либо другим сетевым устройством. Суть заключается в вычислении времени, прошедшего с отправки пакета TCP request маршрутизатором до получения ответа от удаленного хоста. Точность определения увеличивается в случае использования маршрутизаторов Cisco с обоих сторон и в этом случае можно использовать любой порт назначения. В противном случае необходимо использовать порт, открытый на удаленной стороне, например 21 или 80.
Простейший пример выглядит следующим образом:
ip sla monitor 9
type tcpConnect dest-ipaddr 172.29.139.132 dest-port 5000
frequency 10
!
ip sla monitor schedule 9 life forever start-time now
Для получения более полной информации, обратитесь к справочному руководству, ссылка на которое представлена ниже. Хочу отметить, что Cisco IP SLA является мощным инструментом для определения характеристик канала и рекомендуется для использования в повседневной деятельности сетевого администратора.
Используемая литература:
Cisco IOS IP SLAs Configuration Guide, Release 12.4
[ad name=»Google Adsense»]
Уважайте труд автора, сохраняйте копирайты.
Реклама на сайте висит не просто так и если статья Вам понравилась, с ее помощью Вы можете отблагодарить автора за проделанную работу. Спасибо!
SLA _не дает_ гарантии качаственной работы, например VoIP, как вы пишете, а только мониторинг, результаты которого могут быть проанализированы администратором. После этого можно делать, например, QOS, как раз для гарантии качественной работы.
Не согласен с Вами. Если джиттер на канале слишком велик или высокие задержки, то QoS тут не поможет ни каким боком…
to Mixa.
А что в таком случае можно предпринять?
Менять провайдера 🙂 Если это магистрал, то действительно, договариваться о правилах QoS (какой трафик как красить)
QoS как раз и необходимо настроить для гарантии качества, а IPSLA — это как обратная связь для мониторинга параметров качества.
Эээ… Да, я полностью с Вами согласен — в начале статьи есть предложения: «Технология SLAs была разработана для повышения уровня мониторинга IP-инфраструктуры. С помощью Cisco IOS IP SLAs пользователи могут проверить качество предоставляемого сервиса, увеличить надежность сети, подтвердить заявленную поставщиком пропускную способность канала, проактивно идентифицировать сетевые проблемы.»