Cisco asa: ips

H.323

Рисунок 5. Взаимодействие протоколов H.323

Стек протоколов H.323

H.245

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

Кодеки

Рисунок 6. Стек протоколов H.323

Этапы соединения

1. Обнаружение и регистрация.
2. Установление вызова.
3. Сигнальный поток.
4. Медийный поток и поток управления.
5. Завершение вызова.

Внутризоновые вызовы

Рисунок 8. H.323. Установление внутризонового вызова Межзоновые вызовыРисунок 9. H.323. Установление межзонового вызова 

1. Шлюз X запрашивает соединение со шлюзом Y у своего локального гейткипера.
2. Запрос местоположения (LRQ — Location request). Гейткипер шлюза X не знает IP-адрес шлюза Y и запрашивает адрес у гейткипера шлюза Y.
3. Местоположение подтверждено (LCF — Location confirm). Гейткипер шлюза Y отвечает IP-адресом шлюза Y.
4. Гейткипер шлюза X подтверждает его запрос и предоставляет ему IP-адрес шлюза Y.
5. Установление соединения между шлюзами.

Установление соединения

Рисунок 10. Установление соединения 

1. Шлюз X посылает H.225 сообщение установления дозвона для запроса соединения.
2. Шлюз Y посылает обратно H.225 сообщение, заявляя о возможности продолжения процесса.
3. Шлюз Y запрашивает у гейткипера правомерность звонка, посылая ему RAS-сообщение (ARQ) по каналу RAS.
4. Гейткипер подтверждает, что звонок правомерен, посылая шлюзу Y ACF-сообщение.
5. Шлюз Y посылает H.225-сообщение шлюзу X, оповещая его, что соединение установлено.
6. Шлюз Y посылает H.225-сообщение шлюзу X, оповещая его, что вызов установлен.

Установление логических каналов

1. Шлюз X сообщает шлюзу Y, какие возможности он поддерживает, посылая H.245 Terminal Capability Set сообщение.
2. Шлюз Y подтверждает запрос, посылая H.245 Terminal Capability Set Acknowledge сообщение.
3. Аналогичен п.1, но только в обратном направлении.
4. Аналогичен п.2, но только в обратном направлении.
5. Шлюз X открывает медиаканал со шлюзом Y, посылая H.245 сообщение Open Logical Channel, включая адрес RTCP канала.
6. Шлюз Y подтверждает установление логического канала со шлюзом X, посылая H.245-сообщение Open Logical Channel Acknowledge, включая RTP-адрес, выделенный шлюзом Y, и RTCP-адрес, полученный от шлюза X.
7. Аналогичен п.5, но только в обратном направлении.
8. Аналогичен п.6, но только в обратном направлении.

Сигнализация между конечными точками без посредника в H.323

1. Шлюз инициирует H.225.0-сессию со шлюзом назначения.
2. Процедура установления вызова, базирующаяся на Q.931, создает сигнальный канал между конечными точками.
3. Конечные точки открывают канал для функций управления H.245. Происходит обмен возможностями и дескрипторами логических каналов.
4. Открывается RTP-сессия.

Процесс регистрации IP-телефонов

1. Если используется коммутатор Cisco с поддержкой питания, коммутатор посылает специальный FLP (Fast Link Pulse) сигнал. Коммутатор использует этот сигнал, чтобы определить, подключен ли к нему IP-телефон, требующий питания. В обесточенном состоянии IP-телефон Cisco возвращает сигнал, запрашивая тем самым коммутатор подать напряжение 48 вольт постоянного тока.
2. После того как IP-телефон получил питание и загрузился, коммутатор посылает ему CDP (Cisco Discovery Protocol) пакет с информацией виртуальной голосовой локальной сети (если сконфигурировано).
3. IP-телефон посылает широковещательный запрос DHCP-серверу. DHCP-сервер возвращает телефону, как минимум, IP-адрес, маску подсети и IP-адрес Cisco TFTP-сервера.
4. Телефон соединяется с TFTP-сервером и получает с него свою конфигурационную информацию, содержащую перечень CCM (до трех CCM).
5. Телефон пытается зарегистрироваться с первым CCM из перечня, полученного с TFTP-сервера.

MGCP

Понятия MGCP

• вызовы и соединения. Позволяют устанавливать сквозные соединения двух и более конечных точек.
• События и сигналы. Позволяют телефонным агентам инструктировать шлюзы.
• Цифровые карты и пакеты. Позволяют шлюзам определять пункт назначения вызовов.

Рисунок 11. Компоненты MGCP 

Взаимодействие агентов и шлюзов

Рисунок 12. Взаимодействие шлюзов с агентом 

1. Агент направляет сообщение RQNT (Request Notification) каждому шлюзу. Этот запрос дает инструкцию шлюзам ждать события off-hook (когда снимается телефонная трубка) и дать гудок, когда такое событие произойдет. Агент также сообщает о необходимости мониторинга других событий. Предоставляя цифровую карту в запросе, агент позволяет шлюзам собрать цифры перед тем как информировать о событии агента (иначе шлюз не будет «знать», когда набор номера завершается, будет вынужден посылать агенту все цифры набора по одной).
2. Шлюз отвечает на запрос. С этого момента агент и шлюзы ждут событий.
3. Пользователь на шлюзе А поднял трубку. Следуя инструкции, шлюз дает телефонный гудок. Так как у шлюза есть карта номеров, он начинает собирать набираемые цифры, пока не будет получено соответствие (или пока набранные цифры не покажут, что соответствие невозможно).
4. Шлюз А посылает оповещение (NTFY) агенту, сообщая ему, что требуемое событие произошло. Оповещение включает в себя конечную точку, событие и набранные цифры.
5. После подтверждения возможности звонка агент инструктирует шлюз А создать соединение (CRCX) с его конечной точкой.
6. Шлюз отвечает дескриптором сессии. Дескриптор определяет, как минимум, IP-адрес и UDP-порт для последующей RTP-сессии. Шлюз не имеет дескриптора сессии удаленной стороны, и соединение переходит в режим ожидания.
7. Агент отправляет запрос на соединение шлюзу В. В запросе агент предоставляет дескриптор сессии, который он получил от шлюза А. Агент также посылает инструкции о том, какие в данный момент события важны и какие сигналы шлюзу генерировать. В данном случае таким событием является off-hook, сигналом — звонок.
8. Шлюз В отвечает на запрос и сообщает свой дескриптор сессии.
9. Агент передает дескриптор сессии шлюзу А в запросе MDCX (Modify Connection). Теперь шлюзы могут установить RTP-сессии для передачи голоса.
10. В конце вызова одна из конечных точек распознает переход в состояние on-hook (трубка повешена). Допустим, это случилось на шлюзе А. Так как агент проинструктировал сообщить о таком событии, шлюз А посылает агенту уведомление.
11. Агент рассылает сообщение DLCX (Delete Connection) каждому шлюзу.
12. Шлюзы удаляют соединения и отвечают.

Принципы установления соединения

Этапы соединения

Рисунок 3. Этапы соединения   Рисунок 4. Этапы соединения с точки зрения маршрутизаторов. 

1. Звонок с традиционного телефона приходит на R1 и абонентское устройство, инициировавшее вызов, идентифицировано.
2. После ассоциирования входящего вызова с абонентским устройством R1 создает входящий этап соединения и назначает ему идентификатор Call ID (Call Leg 1).
3. R1 использует строку набора с целью определения абонентского устройства для совершения исходящего шага соединения.
4. После определения абонентского устройства, с которым будет устанавливаться соединение, R1 создает исходящий шаг соединения и назначает ему идентификатор (Call Leg 2).
5. Сетевой запрос поступает на маршрутизатор 2 (R2), на котором происходит идентификация вызывающего сетевого абонентского устройства.
6. После определения сетевого абонентского устройства, с которого поступил запрос, R2 создает входящее соединение и назначает ему идентификатор (Call Leg 3). Здесь R1 и R2 согласовывают параметры при необходимости.
7. R2 использует строку набора с целью определения абонентского устройства для совершения исходящего шага соединения.
8. После определения абонентского устройства R2 создает исходящий вызов с назначением ему идентификатора и завершает процесс соединения (Call Leg 4).

Модели развертывания

• с централизованной обработкой вызовов;
• с распределенной однокластерной обработкой вызовов;
• с распределенной многокластерной обработкой вызовов.

Однообъектная модель

Рисунок 14. Однообъектная модель AVVID

• CCM, DSP и приложения находятся в одном месте;
• поддержка приблизительно 36 тыс. IP-телефонов на кластер;
• несколько кластеров могут быть соединены с помощью транков;
• для внешних звонков используется телефонная сеть общего назначения (PSTN).

Модели с распределенной обработкой вызовов

Рисунок 16. Многокластерная модель с распределенной обработкой вызовов. Рисунок 17. Однокластерная модель с распределенной обработкой вызовов. 

Шлюзы

• MGCP-шлюзы. Использует модель клиент-сервер, в которой CCM управляет шлюзом. MGCP-шлюзы поддерживают все дополнительные сервисы CCM, избыточность CCM и бесперебойность вызовов. Дополнительным преимуществом таких шлюзов является их несложное конфигурирование.
• Non-IOS MGCP-шлюзы. Аналогичны MGCP-шлюзам, но не поддерживают бесперебойность вызовов.
• H.323-шлюзы. Используют одноранговую модель. Большая часть конфигурации производится непосредственно на шлюзе. При одноранговой модели CCM не имеет контроля над шлюзом, что приводит к уменьшению количества доступных сервисов CCM при использовании таких шлюзов. Зато H.323-шлюзы поддерживают дополнительную функциональность Cisco IOS — CAC и SRST.

[править] Команды просмотра

Версия

router1#sh ip sla application 
        IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-III

Supported Operation Types:
        icmpEcho, path-echo, path-jitter, udpEcho, tcpConnect, http
        dns, udpJitter, dhcp, ftp, VoIP, rtp, lsp Group, icmpJitter
        lspPing, lspTrace, 802.1agEcho VLAN, Port
        802.1agJitter VLAN, Port, pseudowirePing, udpApp, wspApp

Supported Features:
        IPSLAs Event Publisher

IP SLAs low memory water mark: 20345496
Estimated system max number of entries: 14901

Estimated number of configurable operations: 11582
Number of Entries configured  : 4
Number of active Entries      : 4
Number of pending Entries     : 0
Number of inactive Entries    : 0
Time of last change in whole IP SLAs: *17:12:16.479 UTC Sun Feb 15 2015

Проверка тестов

router1#sh ip sla summary 

IPSLAs Latest Operation Summary
ID          Type       Destination       Stats   Return      Last
                                          (ms)    Code        Run
----------- ---------- ---------------  ------ ---------- ----------------- 
*1          icmp-echo  8.8.8.8          RTT=1    OK         1 second ago       
                                                                               
*2          icmp-echo  8.8.4.4          RTT=1    OK         2 seconds ago      
                                                                               
*3          icmp-echo  4.4.4.4          RTT=1    OK         1 second ago

*55         udp-jitter 12.13.0.13       RTT=1    OK         1 minute, 17 seconds ago

Просмотр статистики

Для теста icmp-echo:

router1#sh ip sla statistics 1 
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
        Latest RTT: 1 milliseconds
Latest operation start time: 17:24:31 UTC Tue Feb 17 2015
Latest operation return code: OK
Number of successes: 749
Number of failures: 0
Operation time to live: Forever

Для теста udp-jitter:

router1#sh ip sla statistics 55
IPSLAs Latest Operation Statistics

IPSLA operation id: 55
Type of operation: udp-jitter
        Latest RTT: 1 milliseconds
Latest operation start time: 17:20:16 UTC Tue Feb 17 2015
Latest operation return code: OK
RTT Values:
        Number Of RTT: 2000             RTT Min/Avg/Max: 1/1/88 milliseconds
Latency one-way time:
        Number of Latency one-way Samples: 1106
        Source to Destination Latency one way Min/Avg/Max: 0/0/87 milliseconds
        Destination to Source Latency one way Min/Avg/Max: 1/0/5 milliseconds
Jitter Time:
        Number of SD Jitter Samples: 1999
        Number of DS Jitter Samples: 1999
        Source to Destination Jitter Min/Avg/Max: 0/1/87 milliseconds
        Destination to Source Jitter Min/Avg/Max: 0/1/5 milliseconds
Packet Loss Values:
        Loss Source to Destination: 0
        Source to Destination Loss Periods Number: 0
        Source to Destination Loss Period Length Min/Max: 0/0
        Source to Destination Inter Loss Period Length Min/Max: 0/0
        Loss Destination to Source: 0
        Destination to Source Loss Periods Number: 0
        Destination to Source Loss Period Length Min/Max: 0/0
        Destination to Source Inter Loss Period Length Min/Max: 0/0
        Out Of Sequence: 0      Tail Drop: 0
        Packet Late Arrival: 0  Packet Skipped: 0
Voice Score Values:
        Calculated Planning Impairment Factor (ICPIF): 0
        Mean Opinion Score (MOS): 0
Number of successes: 5
Number of failures: 0
Operation time to live: Forever

[править] Risk Rating System

Risk Rating ассоциируется с alert, а не с сигнатурой.
Это число которое вычисляется из нескольких компонентов и используется в event action override.

• Attack Severity Rating (ASR) — оценка серьезности атаки. Оценивается по уровню серьезности (severity), который настроен для сигнатуры:
  • Informational (25)
  • Low (50)
  • Medium (75)
  • High (50)
• Target Value Rating (TVR) — оценка значимости ресурса. Ресурс идентифицируется по IP-адресу. По умолчанию используется значение medium:
  • Zero (50)
  • Low (75)
  • Medium (100)
  • High (150)
  • Mission Critical (200)
• Signature Fidelity Rating (SFR) — оценка точности сигнатуры. Этот параметр указывает насколько хорошо сигнатура отрабатывает при отсутствии специфических знаний о цели. Возможные значения от 0 до 100.
• Attack Relevancy Rating (ARR) —
  • Relevant (10)
  • Unknown (0)
  • Not Relevant (-10)
• Promiscuous Delta (PD) —
• Watch List Rating (WLR) —

RR = ASR * TVR * SFR /10000 

[править] Настройка ASA для отправки трафика на анализ IPS

ASA может отправлять трафик на анализ AIP SSM в таких двух режимах:

• Inline режим — в этом режиме AIP SSM находится непосредственно на пути трафика. Если в ASA указано, что трафик должен быть на анализ в модуль AIP SSM, то этот трафик не может пройти сквозь ASA пока он не пройдет через модуль и не пройдет проверку в модуле. Этот режим наиболее безопасный, так как трафик анализирует до того как он попадет в сеть и соответственно может быть заблокирован. Однако этот режим может влиять на пропускную способность.
• Promiscuous режим — в этом режиме ASA отправляет копию трафика на анализ модулю AIP SSM. Этот режим менее безопасный, но меньше влияет на пропускную способность. В этом режиме AIP SSM может блокировать трафик проинструктировав ASA: оборвать соединение или to shun трафик. Кроме того, в то время как AIP SSM анализирует трафик, небольшое его количество может пройти сквозь ASA до того как он будет заблокирован.

Порядок настройки ASA для отправки трафика на анализ AIP SSM:

1. Настроить class-map, которая будет указывать какой трафик отправлять на анализ
2. Настроить policy-map, которая будет указывать в каком режиме будет анализироваться трафик и как обрабатывать трафик в случае недоступности модуля
3. Применить policy-map на интерфейсе

Настройка class-map

Отправить весь трафик на анализ AIP SSM:

ASA(config)# class-map IPS
ASA(config-cmap)# match any

Отправить на анализ AIP SSM трафик предназначенный хосту 192.168.5.1:

ASA(config)# access list IPS_ACL extended permit ip any 192.168.5.1 255.255.255.255
ASA(config)# class-map IPS
ASA(config-cmap)# match access-list IPS_ACL

Настройка policy-map

Настройка policy-map TO_IPS

ASA(config)# policy-map TO_IPS
ASA(config-pmap)# class IPS
ASA(config-pmap-c)# ips {inline | promiscuous} {fail-close | fail-open}

Параметры команды ips:

• inline — анализ трафика в режиме inline
• promiscuous — анализ трафика в режиме promiscuous
• fail-close — если модуль недоступен, то трафику, который должен был быть отправлен на модуль, не разрешено проходить через ASA
• fail-open — если модуль недоступен, то трафику, который должен был быть отправлен на модуль, разрешено проходить через ASA

Отправка трафика на несколько виртуальных сенсоров

Отправка трафика на несколько виртуальных сенсоров:

ASA(config)# policy-map TO_IPS
ASA(config-pmap)# class IPS_1
ASA(config-pmap-c)# ips inline fail-close sensor vs1
ASA(config-pmap)# class IPS_2
ASA(config-pmap-c)# ips inline fail-close sensor vs2

Интерфейс сенсора должен быть присвоен vs0.

Применение policy-map

Применение policy-map на интерфейсе:

ASA(config-pmap-c)# service-policy TO_IPS 

Параметры команды service-policy:

• global — применить политику на всех интерфейсах
• interface — применить политику на конкретном интерфейсе

Проблемы использования сети передачи данных для передачи голоса

1. Потери пакетов. Голосовые кодеки способны восполнять небольшие потери, но если они выше некоторого предела, то возможно прерывание голоса.
2. Задержка. Сквозная задержка — это время, которое требуется для передачи пакета от передающего на принимающее устройство. Задержка складывается из постоянной и переменной составляющих. Постоянная составляющая может быть оценена при проектировании сети. Примеры постоянных задержек — время прохождения сигнала по сети, задержка кодирования, время пакетизации. Перегруженные очереди на интерфейсах и время выкладывания данных на физическую среду передачи данных (Serialization delay) рождают переменные задержки. Время выкладывания данных на физическую среду является функцией от скорости канала и размера пакета — чем больше пакет и меньше скорость канала, тем больше это время. Несмотря на то что это отношение известно, время выкладывания данных на физическую среду отнесено к переменным задержкам, потому что больший пакет может войти в очередь на интерфейсе в любой момент перед голосовым пакетом. В этом случае голосовой пакет будет ждать в очереди на интерфейсе, пока не будет обработан пакет перед ним.
3. Различие времени задержек передачи от пакета к пакету (джиттер) — разница между ожидаемым и фактическим временем прихода очередного пакета. VoIP-устройства используют специальный буфер для установления постоянного темпа обработки пакетов, таким образом достигается плавность звучания голоса.

[править] Параметры

Рекомендации Cisco по настройке параметров (frequency, timeout, threshold) для тестов IP SLA UDP jitter:

• (frequency seconds) > ((timeout milliseconds) + N)
• (timeout milliseconds) > (threshold milliseconds)

где N = (num-packets number-of-packets) * (interval interpacket-interval)

Рекомендации Cisco по настройке параметров (frequency, timeout, threshold) для других тестов IP SLA:

(frequency seconds) > (timeout milliseconds) > (threshold milliseconds)

Threshold

Параметр threshold используется для указания верхнего порогового значения времени.

Значение по умолчанию 5000ms.
Значение threshold не должно превышать значение параметра timeout.

Значение параметра threshold для операции:

• IP SLA UDP jitter:
• для других операций:

IP SLA, соответственно, высчитывает количество раз, когда среднее значение jitter или RTT превышало указанное значение threshold.

Cisco AVVID

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

• интеллектуальная сетевая инфраструктура на базе протокола IP, включающая маршрутизаторы, коммутаторы, шлюзы и другое сетевое оборудование. IP-инфраструктура является основой для дальнейшего внедрения пользовательских приложений и должна обеспечивать поддержку таких жизненно важных для сети сервисов, как безопасность, сетевое управление и механизмы качества обслуживания (QoS). В рамках архитектуры Cisco AVVID интеллектуальная сетевая инфраструктура используется наряду с передачей данных для функционирования корпоративной телефонной и видеотелефонной системы.
• Интеллектуальные клиентские устройства с поддержкой протокола IP, в том числе цифровые IP-телефоны Cisco, видеоустройства, персональные компьютеры со специализированным программным обеспечением для решения различных бизнес-задач, программные эмуляторы телефонов (например, Cisco IP Communicator) и так далее.
• Управление корпоративной системой IP-телефонии, а также видеотелефонии Cisco осуществляется специализированным приложением Cisco CallManager либо кластером Cisco CallManager. Кроме того, в системе могут использоваться дополнительные служебные устройства и приложения, такие как корпоративная служба каталогов, которая служит централизованным хранилищем информации об абонентах в телефонной и видеосистеме, а также служебные устройства для обеспечения аудио- и видеоконференций, H.323-гейткиперы и т.д.
• Современные телефонные приложения, возникшие благодаря развитию интегрированных систем с поддержкой голоса, видео- и данных, например, системa унифицированной обработки сообщений (Unified Messaging), интеллектуальные центры обработки вызовов (Contact Center), мультимедийные системы организации конференций. Внедрение подобных приложений создает дополнительные возможности для пользователей/абонентов корпоративной телекоммуникационной сети, повышает удобство и эффективность использования системы.

• скорость внедрения новых сервисов;
• надежность;
• возможность взаимодействия различных сетей;
• снижение материальных расходов.

1. Инфраструктурный уровень — это фундамент сети.
2. Уровень обработки вызовов, выполняющий функции коммутации вызовов. Его функции схожи с функциями УАТС при использовании традиционных технологий телефонии.
3. Уровень приложений, обеспечивающих дополнительную функциональность.
4. Клиентский уровень, на котором располагаются устройства и приложения, с которыми пользователь непосредственно взаимодействует.

Рисунок 13. Уровни архитектуры AVVID