- Главная
- /
- Статья
Local Gateway (LGW) — это эксклюзивное решение для предоставления локального доступа к PSTN клиентам Cisco Webex Calling. В этом документе описывается настройка локального шлюза с использованием высокой доступности CUBE с использованием активных или резервных CUB для обеспечения аварийного переключения активных вызовов с сохранением состояния.
Основы
Предварительные условия
Прежде чем развертывать Cisco Unified Border Element (CUBE) High Availability (HA) в качестве локального шлюза дляWebex Calling, убедитесь, что вы хорошо разбираетесь в следующих понятиях:
-
Резервирование на уровне 2 «от коробки до коробки» с помощью CUBE Enterprise для сохранения вызовов с сохранением состояния
Рекомендации по настройке, приведенные в этой статье, предполагают использование выделенной платформы локального шлюза без существующей конфигурации голосовой связи. Если в существующем корпоративном развертывании CUBE планируется также использовать функцию локального шлюзаCisco Webex Calling, обратите особое внимание на применяемую конфигурацию, чтобы обеспечить бесперебойную работу существующих потоков вызовов и функций и убедиться, что вы соблюдаете проектные требования CUBE HA.
Аппаратные и программные компоненты
В качестве локального шлюза CUBE HA требуется версия IOS-XE 17.9.1 или более поздняя, а также платформа, поддерживающая функции CUBE HA и LGW.
Команды и журналы show в этой статье основаны на минимальной версии программного обеспечения Cisco IOS -XE 17.9.1, реализованной на vCube (CSR 8000v).
Справочный материал
Вот несколько подробных руководств по настройке CUBE HA для различных платформ:
Webex CallingОбзор решения
Cisco Webex Callingэто предложение для совместной работы, которое представляет собой многопользовательскую облачную альтернативу локальной телефонной услуге PBX с несколькими вариантами PSTN для клиентов.
В этой статье основное внимание уделяется развертыванию локального шлюза (представленному ниже). Магистраль локального шлюза (локальной сети PSTN) обеспечивает подключение к принадлежащей клиенту службе PSTN. Webex Calling Он также обеспечивает подключение к локальной IP-УАТС, например. Cisco Unified CM Вся передача данных в облако и из облака защищена с помощью транспорта TLS для SIP и SRTP для мультимедиа.
На рисунке ниже показано Webex Calling развертывание без существующей IP-УАТС. Оно применимо к развертыванию на одном или нескольких узлах. Конфигурация, описанная в этой статье, основана на этом развертывании.
Резервирование «от коробки к коробке» уровня 2
При резервировании CUBE HA уровня 2 «по схеме «от коробки к коробке» используется инфраструктурный протокол группы резервирования (RG) для формирования пары маршрутизаторов «активный/резервный». Эти пары используют один и тот же виртуальный IP-адрес (VIP) на всех интерфейсах и постоянно обмениваются статусными сообщениями. Информация о сеансе CUBE проверяется на всех двух маршрутизаторах, что позволяет резервному маршрутизатору немедленно взять на себя все обязанности по обработке вызовов CUBE в случае выхода активного маршрутизатора из строя, в результате чего сигналы и медиафайлы сохраняются в рабочем состоянии.
Указывание чеков ограничено подключенными вызовами с медиапакетами. Вызовы, находящиеся в пути, не отмечены галочкой (например, в состоянии вызова или вызова).
В этой статье компания CUBE HA обратит внимание на резервирование CUBE на уровне 2 уровня «от одного устройства к коробке» (B2B) для сохранения вызовов с сохранением состояния вызовов.
Начиная с версии IOS-XE 17.9.1, CUBE HA можно развертывать в качестве локального шлюза для магистральных развертываний (локальная сеть PSTN). Cisco Webex Calling В этой статье будут рассмотрены аспекты проектирования и конфигурации. На рисунке показана типичная конфигурация CUBE HA в качестве локального шлюза для Cisco Webex Calling магистрального развертывания.
Инфраструктурный компонент «Группа резервирования»
Компонент Redundancy Group (RG) Infra обеспечивает поддержку коммуникационной инфраструктуры «от коробки к коробке» между двумя CUB и согласовывает окончательное стабильное состояние резервирования. Этот компонент также обеспечивает:
-
Протокол, похожий на HSRP, который согласовывает окончательное состояние резервирования каждого маршрутизатора путем обмена сообщениями keepalive и hello между двумя CUB (через интерфейс управления) — GigabitEthernet3 на рисунке выше.
-
Транспортный механизм для проверки состояния сигналов и мультимедиа при каждом вызове от активного маршрутизатора к резервному (через интерфейс передачи данных) — GigabitEthernet3 на рисунке выше.
-
Настройка интерфейса Virtual IP (VIP) и управление им для интерфейсов трафика (можно настроить несколько интерфейсов трафика с использованием одной и той же группы RG) — GigabiEthernet 1 и 2 считаются интерфейсами трафика.
Этот компонент RG должен быть специально настроен для поддержки голосовой связи B2B HA.
Управление виртуальными IP-адресами (VIP) для сигнализации и мультимедиа
B2B HA полагается на VIP для обеспечения резервирования. VIP и связанные с ним физические интерфейсы обоих CUBE в паре CUBE HA должны находиться в одной и той же подсети LAN. Конфигурация VIP и привязка VIP-интерфейса к определенному голосовому приложению (SIP) являются обязательными для поддержки голосовой связи B2B HA. Внешние устройстваUnified CM, такие как Webex Calling SBC, поставщик услуг или прокси-сервер, используют VIP в качестве IP-адреса назначения для вызовов, проходящих через маршрутизаторы CUBE HA. Таким образом, с Webex Calling точки зрения пары CUBE HA действуют как единый локальный шлюз.
Сигнализация вызовов и информация о сеансе RTP установленных вызовов передаются от активного маршрутизатора к резервному маршрутизатору. Когда активный маршрутизатор выходит из строя, резервный маршрутизатор берет на себя управление и продолжает пересылать поток RTP, который ранее был маршрутизирован первым маршрутизатором.
Вызовы, находившиеся в переходном состоянии во время переключения на резервный ресурс, не будут сохранены после переключения. Например, вызовы, которые еще не полностью установлены или находятся в процессе модификации с помощью функции передачи или удержания. Постоянные вызовы могут быть отключены после переключения.
Для использования CUBE HA в качестве локального шлюза для аварийного переключения вызовов с отслеживанием состояния существуют следующие требования:
-
CUBE HA не может совместно размещать TDM или аналоговые интерфейсы
-
Gig1 и Gig2 называются интерфейсами трафика (SIP/RTP), а Gig3 — интерфейсом управления и данными групп резервирования (RG)
-
В одном домене уровня 2 можно разместить не более двух пар CUBE HA: одну с идентификатором группы 1, а другую — с идентификатором группы 2. При настройке двух пар HA с одинаковым идентификатором группы интерфейсы RG Control/Data должны принадлежать разным доменам уровня 2 (vlan, отдельный коммутатор)
-
Портовый канал поддерживается как интерфейсами RG Control/Data, так и интерфейсами трафика
-
Все сигналы/медиафайлы поступают с виртуального IP-адреса или на него
-
Каждый раз, когда платформа перезагружается в рамках отношений между CUBE-HA, она всегда загружается в режиме ожидания
-
Нижние адреса всех интерфейсов (Gig1, Gig2, Gig3) должны быть на одной платформе
-
Идентификатор интерфейса резервирования (rii) должен быть уникальным для комбинации пар и интерфейсов на одном уровне 2
-
Конфигурация обоих CUB должна быть идентичной, включая физическую конфигурацию, и работать на платформе одного типа и версии IOS-XE
-
Интерфейсы Loopback нельзя использовать в качестве привязки, так как они всегда работают
-
Интерфейсы с несколькими трафиками (SIP/RTP) (Gig1, Gig2) требуют настройки отслеживания интерфейсов
-
CUBE-HA не поддерживается через перекрестное кабельное соединение для канала RG-Control/Data (Gig3)
-
Для работы CUBE HA обе платформы должны быть идентичны и подключены через физический коммутатор ко всем аналогичным интерфейсам, т.е. GE0/0/0 CUBE-1 и CUBE-2 должны работать на одном и том же коммутаторе и так далее.
-
Невозможно обеспечить прямую терминацию глобальной сети на CUBE или передачу данных HA на обеих сторонах
-
Как активный, так и резервный центр обработки данных должны находиться в одном и том же центре обработки данных
-
Для резервирования необходимо использовать отдельный интерфейс L3 (RG Control/Data, Gig3). То есть интерфейс, используемый для трафика, нельзя использовать для поддержания работоспособности высокой доступности и контрольных точек
-
При отказоустойчивом переключении ранее активный CUBE автоматически перезагружается, сохраняя сигналы и носители
Настройте избыточность на обоих CUB
На обоих кубах, предназначенных для использования в паре HA для получения виртуальных IP-адресов, необходимо настроить избыточность уровня 2 «от одного устройства к коробке».
| 1 |
Настройте отслеживание интерфейса на глобальном уровне для отслеживания состояния интерфейса.
Track CLI используется в RG для отслеживания состояния интерфейса голосового трафика, чтобы активный маршрут продолжал играть активную роль после отключения интерфейса трафика. | ||
| 2 |
Настройте RG для использования с VoIP HA в подрежиме резервирования приложений.
Ниже приведено описание полей, используемых в этой конфигурации:
| ||
| 3 |
Включите пакетное резервирование для приложения CUBE. Настройте RG, как описано в предыдущем шаге в разделе
redundancy-group 1 — добавление и удаление этой команды требует перезагрузки, чтобы обновленная конфигурация вступила в силу. Мы перезагрузим платформы после того, как все настройки будут применены. | ||
| 4 |
Настройте интерфейсы Gig1 и Gig2 с соответствующими виртуальными IP-адресами, как показано ниже, и примените идентификатор интерфейса резервирования (rii)
Ниже приведено описание полей, используемых в этой конфигурации:
| ||
| 5 |
Сохраните конфигурацию первого CUBE и перезагрузите его. Платформа, которую нужно перезагрузить последней, всегда находится в режиме ожидания.
После полной загрузки VCUBE-1 сохраните конфигурацию VCUBE-2 и перезагрузите ее.
| ||
| 6 |
Убедитесь, что конфигурация «от коробки до коробки» работает должным образом. Соответствующие выходные данные выделены жирным шрифтом. Мы перезагрузили VCUBE-2 в последнюю очередь, и в соответствии с конструктивными соображениями платформа, которая будет перезагружаться последней, всегда будет находиться в режиме ожидания.
Затем выполните настройку локального шлюза (на основе регистрации или сертификата) на обоих кубах HA. См. раздел Настройка локального шлюза на XE. Cisco IOS Webex Calling |