- Главная
- /
- Статья
Внедрение высокой доступности CUBE в качестве локального шлюза
Локальный шлюз (LGW) является эксклюзивным решением для предоставления локального доступа PSTN клиентам Cisco Webex Calling. В этом документе приводится руководство по настройке локального шлюза с использованием CUBE высокой доступности с активными или резервными CUBE для обеспечения проверки состояния активных вызовов.
Основы
Предварительные условия
Перед развертыванием высокой доступности (HA) Cisco Unified Border Element (CUBE) в качестве локального шлюза для Webex Calling необходимо подробно изучить следующие концепции.
-
Резервирование 2-го уровня подряд в CUBE Enterprise для сохранения вызовов с сохранением состояния
В рекомендациях по настройке, приведенных в этой статье, предполагается выделенная платформа локального шлюза без существующей конфигурации голосовой связи. Если существующее корпоративное развертывание CUBE изменено на использование функции локального шлюза для Cisco Webex Calling, обратите внимание на применяемую конфигурацию, чтобы убедиться в том, что существующие потоки вызовов и функциональные возможности не прерываются, а также убедитесь в соблюдении требований к проектированию CUBE HA.
Компоненты аппаратного и программного обеспечения
Для CUBE HA в качестве локального шлюза требуется IOS-XE версии 17.9.1 или более поздней и платформа, на которой поддерживаются функции CUBE HA и локального шлюза.
Отображение команд и журналов в этой статье основано на минимальном выпуске программного обеспечения Cisco IOS-XE 17.9.1, реализованном на vCUBE (CSR 8000v).
Справочный материал
Ниже приведены подробные руководства по настройке CUBE HA для различных платформ.
-
Cisco ISR 4K и Cisco Catalyst серии 8K: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Предпочтительная архитектура Cisco для Cisco Webex Calling: https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Обзор решения Webex Calling
Cisco Webex Calling – это предложение для совместной работы, которое предоставляет альтернативу на основе облака с несколькими клиентами локальной телефонной связью с УАТС с несколькими вариантами PSTN для клиентов.
В этой статье рассматривается развертывание локального шлюза (представленное ниже). Магистраль локального шлюза (PSTN на базе локальных ресурсов) в Webex Calling позволяет подключаться к службе PSTN, принадлежащей клиенту. Она также обеспечивает подключение к локальному развертыванию IP-УАТС, например Cisco Unified CM. Все входящие и исходящие взаимодействия в облако защищены с помощью транспорта TLS для SIP и SRTP для мультимедиа.
На рисунке ниже показано развертывание Webex Calling без какой-либо существующей IP-УАТС. Оно применимо к развертыванию с одним или несколькими веб-сайтами. Конфигурация, описанная в этой статье, основана на этом развертывании.
Избыточность "Box-to-Box 2 уровня"
Резервирование CUBE HA Layer 2 Box-to-Box использует инфраструктурный протокол группы резервирования (RG) для формирования пары маршрутизаторов. Эта пара использует один и тот же виртуальный IP-адрес (VIP) в соответствующих интерфейсах и постоянно обменивается сообщениями о состоянии. Информация о сеансе CUBE проверяется по паре маршрутизаторов, которые позволяют резервному маршрутизатору немедленно взять на себя все обязанности по обработке вызовов CUBE, если активный маршрутизатор выходит из строя, что приводит к сохранению состояния сигналов и мультимедиа.
Проверка ограничена подключенными вызовами с пакетами мультимедиа. Вызовы, находящиеся в процессе транзита, не проверяются (например, состояние попытки вызова или звонка).
В этой статье CUBE HA будет ссылаться на избыточность CUBE Box-to-Box уровня 2 (B2B) для сохранения вызовов с сохранением состояния.
Начиная с IOS-XE 17.9.1 CUBE HA можно развернуть в качестве локального шлюза для развертываний магистрали Cisco Webex Calling (PSTN на базе локальных ресурсов). В этой статье будут рассмотрены аспекты разработки и конфигурации. На рисунке показана типичная настройка CUBE HA в качестве локального шлюза для развертывания магистрали Cisco Webex Calling.
Компонент инфраструктуры группы избыточности
Компонент инфраструктуры группы избыточности (RG) обеспечивает поддержку инфраструктуры связи между двумя CUBE и согласовывает окончательное стабильное состояние избыточности. Этот компонент также предоставляет:
-
Протокол, подобный HSRP, который согласовывает окончательное состояние избыточности для каждого маршрутизатора путем обмена сообщениями проверки активности и приветствия между двумя CUBE (через интерфейс управления): GigabitEthernet3 на рисунке выше.
-
Транспортный механизм для проверки состояния сигналов и мультимедиа для каждого вызова от активного на резервный маршрутизатор (через интерфейс передачи данных) — GigabitEthernet3 на рисунке выше.
-
Настройка и управление интерфейсом виртуального IP (VIP) для интерфейсов трафика (несколько интерфейсов трафика можно настроить с помощью одной и той же группы RG) – GigabitEthernet 1 и 2 считаются интерфейсами трафика.
Этот компонент RG должен быть специально настроен для поддержки голосовой B2B HA.
Управление виртуальными IP-адресами (VIP) для передачи сигналов и мультимедиа
B2B HA использует VIP для достижения избыточности. VIP-интерфейс и связанные с ним физические интерфейсы в обоих CUBE в паре CUBE HA должны находиться в одной подсети локальной сети. Конфигурация VIP и привязка интерфейса VIP к определенному приложению голосовой связи (SIP) являются обязательными для поддержки B2B HA голосовой связи. Внешние устройства, такие как Unified CM, пограничный контроллер сеансов доступа Webex Calling, поставщик услуг или прокси, используют VIP в качестве IP-адреса назначения для прохождения вызовов через маршрутизаторы CUBE HA. Таким образом, с точки зрения Webex Calling пары CUBE HA действуют как единый локальный шлюз.
Информация о передаче сигналов вызовов и сеансе RTP установленных вызовов проверяется с активного маршрутизатора на резервный маршрутизатор. Когда активный маршрутизатор выходит из строя, маршрутизатор в режиме ожидания переходит и продолжает переадресовывать поток RTP, который ранее маршрутизировался первым маршрутизатором.
Вызовы, находящиеся в переходном состоянии во время отработки отказа, не будут сохранены после переключения. Например, вызовы, которые еще не полностью установлены или находятся в процессе изменения с помощью функции перевода или удержания. Установленные вызовы могут быть отключены после переключения.
Для использования CUBE HA в качестве локального шлюза для проверки состояния вызовов при отказе существуют приведенные ниже требования.
-
CUBE HA не может совместно размещать TDM или аналоговые интерфейсы
-
Gig1 и Gig2 называются интерфейсами трафика (SIP/RTP), а Gig3 — интерфейсом управления/данных группы избыточности (RG).
-
В одном домене 2 уровня можно разместить не более 2 пар CUBE HA, один с идентификатором группы 1 и второй с идентификатором группы 2. При настройке 2 пар высокой доступности с одним идентификатором группы интерфейсы управления/данных RG должны принадлежать разным доменам 2 уровня (VLAN, отдельный коммутатор)
-
Канал портов поддерживается как для интерфейсов управления/данных RG, так и для интерфейса трафика
-
Все сигналы и мультимедиа поступают с виртуального IP-адреса или на него
-
В любой момент, когда платформа перезагружается в отношениях CUBE-HA, она всегда загружается в режиме ожидания
-
Более низкий адрес для всех интерфейсов (Gig1, Gig2, Gig3) должен быть на одной платформе
-
Идентификатор интерфейса избыточности, rii должен быть уникальным для комбинации пары/интерфейса на одном и том же уровне 2
-
Конфигурация обоих CUBE должна быть идентичной, включая физическую конфигурацию, и должна быть запущена на одном типе платформы и версии IOS-XE
-
Интерфейсы петли нельзя использовать в качестве привязки, поскольку они всегда находятся в состоянии "вверх"
-
Несколько интерфейсов трафика (SIP/RTP) (Gig1, Gig2) требуют настройки отслеживания интерфейса
-
CUBE-HA не поддерживается перекрестным кабельным соединением для канала управления/передачи данных RG (Gig3)
-
Обе платформы должны быть идентичны и подключены с помощью физического коммутатора на всех аналогичных интерфейсах для работы CUBE HA, то есть GE0/0/0 из CUBE-1 и CUBE-2 должны прерываться на одном и том же коммутаторе и т. д.
-
Не может быть прекращена работа WAN непосредственно в CUBE или система высокой доступности данных с обеих сторон
-
Активный/ожидающий должны находиться в одном центре обработки данных
-
Для резервирования (управление/данные RG, Gig3) необходимо использовать отдельный интерфейс L3. Например, интерфейс, используемый для трафика, не может использоваться для проверки и проверки высокой доступности.
-
При отработке отказа ранее активный CUBE проходит перезагрузку по дизайну, сохраняя передачу сигналов и мультимедиа
Настройка избыточности в обоих CUBE
Для подключения виртуальных IP-адресов необходимо настроить избыточность Box-to-Box 2 на обоих CUBE, которые предназначены для использования в паре высокой доступности.
1 |
Настройте отслеживание интерфейса на глобальном уровне, чтобы отслеживать состояние интерфейса.
Отслеживание CLI используется в RG для отслеживания состояния интерфейса голосового трафика, чтобы активный маршрут мог полностью выполнять свою активную роль после отключения интерфейса трафика. | ||
2 |
Настройте RG для использования с высокой доступностью передачи голоса по IP в подрежиме избыточности приложения.
Ниже приведено объяснение полей, используемых в этой конфигурации.
| ||
3 |
Включите избыточность box-to-box для приложения CUBE. Настройте RG из предыдущего шага в разделе
Redundancy-group 1. Для добавления и удаления этой команды требуется перезагрузка обновленной конфигурации. Перезагрузка платформ будет выполнена после применения всей конфигурации. | ||
4 |
Настройте интерфейсы Gig1 и Gig2 с их соответствующими виртуальными IP-адресами, как показано ниже, и примените идентификатор интерфейса избыточности (rii)
Ниже приведено объяснение полей, используемых в этой конфигурации.
| ||
5 |
Сохраните конфигурацию первого CUBE и перезагрузите его. Платформа для последней перезагрузки всегда находится в режиме ожидания.
После полной загрузки VCUBE-1 сохраните конфигурацию VCUBE-2 и перезагрузите ее.
| ||
6 |
Убедитесь, что конфигурация box-to-box работает надлежащим образом. Соответствующий вывод выделен полужирным шрифтом. Последняя перезагрузка VCUBE-2 выполнена в соответствии с требованиями дизайна. Последняя перезагрузка платформы всегда будет в режиме ожидания. Затем продолжите работу с конфигурацией локального шлюза (на основе регистрации или сертификата) на обоих CUBE высокой доступности. См. статью Настройка локального шлюза в Cisco IOS XE для Webex Calling. |