Здравствуйте, коллеги!
В прошлом посте я представил вам своего ученика – Александра Левичева. Теперь же хочу опубликовать материал, который подготовил для вас Александр. Он расскажет о новой технологии, появившейся в 8м релизе CUCM и CME – о сети SAF, с помощью которой можно передавать телефонные маршруты между двумя IP АТС динамически. Материал опубликуем в двух частях: первая будет посвящена обзору SAF / ССD, во второй Вы познакомитесь с настройками устройств SAF-сети.
Итак, передаю слово Александру. 🙂
“Сегодня мы будем говорить о технологии динамической передачи информации о телефонных номерах в сетях, построенных на оборудовании Cisco, также известной под названием SAF / CCD. Это хорошо масштабируемый и эффективный подход к конфигурации маршрутов в Вашей телефонной сети.
В телефонных сетях, насчитывающих 3 и более АТС, администраторам обычно приходится настраивать маршрутизацию звонков между станциями по принципу «каждый с каждым». Такой же принцип ранее и использовался для соединения IP телефонных станций Cisco меджу собой по протоколам H323 или SIP. Это статические записи (dialpeer’ы или Route Pattern’ы), говорящие, как правило, о том, что диапазон номеров ХХХХ контролируется шлюзом/АТС c IP адресом Х.Х.Х.Х. Совершенно очевидно, что для объединения, скажем, 10 станций между собой придется на каждой из них прописывать по 9 маршрутов к соседям, что неудобно.
Данную проблему можно было бы решить, применяя в IP сети гейткиперы (H323) или SIP-сервер (SIP), но опять же была конфигурация маршрутов была бы статической, к тому же появляется единая точка отказа.
Cisco решила пойти другим путем, проверенным в сетях передачи данных – было решено информацию о телефонных маршрутах передавать динамически. В отличие от создания статических маршрутов (dialpeers в CME или route patterns в CUCM) SAF / CCD использует метод динамического обмена шаблонами телефонных номеров (hosted DN), что значительно упрощает работу администратора при конфигурации маршрутов в случае их создания или изменения. Преимущества SAF / CCD перед гейткипером или SIP прокси сервером – отсутствие единой точки отказа и автоматическое извещение всех УАТС об изменениях в плане нумерации той или иной АТС, работающих в сети SAF.
К сожалению, SAF / CCD пока является только вендорным или «проприеритарным» решением. Это значит, что данная технология работает только в телефонных сетях, построенных на оборудовании Cisco (т.е если используются только CUCM, CME и голосовые шлюзы Cisco).
Архитектура сети SAF состоит из клиентов, которые запрашивают и анонсируют шаблоны телефонных номеров, и форвардеров (forwarder), которые получают шаблоны телефонных номеров от клиентов (или от других форвардеров) и пересылают их дальше, точно так же как и маршруты в случае протоколов динамической маршрутизации.
SAF клиент – CUCM или CME:
· регистрируется на форвардере
· анонсирует шаблоны телефонных номеров
· подписывается на шаблоны телефонных номеров
· обменивается кипэлайвами (keepalive) с форвардером
SAF форвардер – шлюз задача которого:
· распространять шаблоны телефонных номеров, полученных от клиентов
· устанавливать и поддерживать соседство (neighbourship) с другими форвардерами
SAF сеть работает по тем же самым принципам, которые используются в протоколе маршрутизации EIGRP. Форвардеры должны установить соседство друг с другом в SAF сети, и только после этого они могут передавать информацию о телефонных номерах друг другу. Если форвардеры находятся в одной подсети, то они могут автоматически обнаружить друг друга и установить соседство с помощью расслылки hello пакетов мультикастом, если в разных подсетях, то нужно вручную указывать IP адрес SAF соседа с помощью команды neighbor.
Идея работы SAF сети состоит в том что SAF клиент К1 (CUCM) посылает информацию о своих телефонных номерах (hosted DN) форвардеру (А), на котором он зарегистрирован. SAF форвардер (А) пересылает эту информацию своему соседу (B), которого он обнаружил автоматически с помощью мультикаста, а тот (B) в свою очередь – соседу, сконфигурированному вручную (С). В конце концов информация доходит до форвардера D, на котором также есть клиент (CME К2). Клиент K2 записывает информацию (hosted DN) от К1. Аналогично, клиент K2 объявляет свои маршруты SAF сети, и та, в свою очередь, доставляет их до клиента К1.
Нужно отметить, что при распространении информации о телефонных номерах, клиенты так же объявляют о том, какой протокол сигнализации (SIP или H323) использовать для звонков на объявляемые номера. Для звонков на номера, полученные с помощью SAF / CCD, используются специально сконфигурированные для этой цели SIP или H323 транки.
В CUCM Вы можете посмотреть на маршруты, которые получил сервер только с помощью утилиты RTMT. Для CME это можно сделать с помощью соответствующей команды. Данная технология появилась с Call Manager (Express) 8.0. На момент написания статьи поддержка есть только для ipv4.
Платформы устройств, поддерживающие SAF:
· 800, 1800, 2800, 2900, 3800, 3900, 7200 (ios 15.0(1)M)
· 7600 (ios 12.2(33) SRE)
· ASR 1000 (ios XE 2.5), CAT 4000 (12.2(54)SG) , 6000 (12.2(33)SXI4)
Продолжение следует….
Добрый день, Дмитрий
Интересная технология. А Вы не знаете, насколько активно она применяется в реальном мире? И есть ли ее аналоги у других вендоров – Avaya, Asterisk и т.п.?
Добрый день, Дамир!
Пока это только циско технология и она закрытая (как до недавнего времени был EIGRP). Не могу сказать, используется ли она у других вендоров тоже – на данный момент не слышал о таком. Но вполне могу предположить, что у других может быть реализовано что-то подобное.
У Cisco CDP – у других вендоров LLDP, у циски свой способ PoE – у других 802.3af итд.