- Начало
- /
- Статия
Приложете CUBE висока степен на достъпност като локален шлюз
Local Gateway (LGW) е единствената възможност за предоставяне на PSTN достъп до помещенията за клиентите на Cisco Webex Call. Целта на този документ е да ви помогне при изграждането на конфигурация на локален шлюз, използвайки CUBE с висока степен на достъпност, активни или в режим на готовност CUBE за преминаване на активни повиквания при отказ от състояние на състояние.
Основите
Предпоставки
Преди да разгърнете CUBE HA като локален портал за Webex Calling, уверете се, че имате задълбочено разбиране на следните концепции:
-
Слой 2 кутия до кутия излишък с CUBE Enterprise за запазване на държавни повиквания
Указанията за конфигуриране, предоставени в тази статия, приемат специална локална портална платформа без съществуваща гласова конфигурация. Ако съществуващо внедряване на CUBE предприятие се модифицира, за да се използва и функцията за локален шлюз за Cisco Webex Calling, обърнете специално внимание на конфигурацията, приложена, за да се гарантира, че съществуващите потоци от повиквания и функционалности не се прекъсват и се уверете, че се придържате към изискванията за проектиране на CUBE HA.
Хардуерни и софтуерни компоненти
CUBE HA като локален шлюз изисква IOS-XE версия 16.12.2 или по-нова и платформа, на която се поддържат както функциите CUBE HA, така и LGW.
Командите и дневниците на шоуто в тази статия се основават на минималното софтуерно издание на Cisco IOS-XE 16.12.2, внедрено на vCUBE (CSR1000v).
Референтен материал
Ето някои подробни ръководства за конфигуриране на CUBE HA за различни платформи:
-
Серия ISR 4K — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-ISR4K.html
-
КСО 1000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-high-availability-CSR1000v.html
-
Cisco предпочита архитектура за Cisco Webex призвание - https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Преглед на решението за повикване на Webex
Cisco Webex Calling е предложение за сътрудничество, което предоставя многонаемателна облачна алтернатива на услугата PBX телефонна услуга с множество PSTN опции за клиенти.
Разгръщането на локалния портал (представено по-долу) е във фокуса на тази статия. Багажникът на локалния шлюз (базиран на помещения PSTN) в Webex Calling позволява свързване с PSTN услуга, собственост на клиента. Той също така осигурява свързаност с локално внедряване на IP PBX като Cisco Unified CM. Цялата комуникация до и от облака е осигурена с помощта на TLS транспорт за SIP и SRTP за медии.
Фигурата по-долу показва разгръщане на Webex Calling без съществуващ IP PBX и е приложимо за разполагане на един или няколко сайта. Конфигурацията, очертана в тази статия, се основава на това внедряване.
Слой 2 Резервираност от кутия до кутия
CUBE HA слой 2 резервираност кутия до кутия използва инфраструктурния протокол Redundancy Group (RG), за да образува активна/стендбай двойка рутери. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните си интерфейси и непрекъснато обменя съобщения за състоянието. Информацията за сесията на CUBE се проверява в двойката рутери, което позволява на рутера в режим на готовност да поеме всички отговорности за обработка на повиквания на CUBE незабавно, ако активният рутер излезе от експлоатация, което води до държавно запазване на сигнализацията и медиите.
Проверката на посочването е ограничена до свързани разговори с медийни пакети. Обажданията в транзит не се проверяват (например състояние на опитване или звънене).
В тази статия CUBE HA ще се отнася до CUBE висока наличност (HA) слой 2 кутия до кутия (B2B) съкращения за запазване на държавни повиквания
От IOS-XE 16.12.2, CUBE HA може да бъде разгърната като локален портал за разгръщане на багажника на Cisco Webex Calling (PSTN), базиран на помещения, и ще обхванем дизайнерски съображения и конфигурации в тази статия. Тази цифра показва типична настройка на CUBE HA като локален шлюз за разгръщане на багажника на Cisco Webex.
Група за съкращения Infra компонент
Компонентът Redundancy Group (RG) Infra осигурява поддръжка на комуникационната инфраструктура "кутия до кутия" между двете CUBE и договаря окончателното стабилно състояние на съкращения. Този компонент също така предвижда:
-
Протокол, подобен на HSRP, който договаря окончателното състояние на съкращения за всеки рутер, като обменя поддържани и здравейте съобщения между двете CUBE (чрез контролния интерфейс) - GigabitEthernet3 на фигурата по-горе.
-
Транспортен механизъм за проверка на сигналното и медийното състояние за всяко повикване от активния към маршрутизатора в режим на готовност (чрез интерфейса за данни) – GigabitEthernet3 на фигурата по-горе.
-
Конфигурация и управление на интерфейса Virtual IP (VIP) за интерфейсите на трафика (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран, за да поддържа глас B2B HA.
Виртуално IP (VIP) управление на адреси както за сигнализация, така и за медии
B2B HA разчита на VIP за постигане на съкращения. VIP и свързаните с тях физически интерфейси на двете CUBE в двойката CUBE HA трябва да се намират в една и съща LAN подмрежа. Конфигурацията на VIP и свързването на VIP интерфейса към конкретно гласово приложение (SIP) са задължителни за гласова поддръжка на B2B HA. Външни устройства като Unified CM, Webex Calling access SBC, доставчик на услуги или пълномощник, използват VIP като IP адрес на местоназначението за повикванията, преминаващи през рутерите CUBE HA. Следователно, от гледна точка на Webex Call, двойките CUBE HA действат като един локален шлюз.
Сигнализацията на повикванията и информацията за RTP сесията на установените повиквания се проверяват от активния рутер към рутера в режим на готовност. Когато Активният рутер падне, рутерът Standby поема контрола и продължава да препраща потока RTP, който преди това е бил маршрутизиран от първия рутер.
Обажданията в преходно състояние по време на провала няма да бъдат запазени след превключването. Например, обаждания, които все още не са напълно установени или са в процес на модифициране с функция за прехвърляне или задържане. Установените повиквания могат да бъдат изключени след превключване.
Съществуват следните изисквания за използване на CUBE HA като локален портал за държавно провал на повикванията:
-
CUBE HA не може да има TDM или аналогови интерфейси, разположени съвместно
-
Gig1 и Gig2 се наричат интерфейси за трафик (SIP/RTP), а Gig3 е интерфейс за контрол/данни на групата за съкращения (RG)
-
Не повече от 2 CUBE HA двойки могат да бъдат поставени в един и същ слой 2 домейн, един с група ID 1, а другият с група ID 2. Ако конфигурирането на 2 HA двойки с една и съща група ID, интерфейсите RG Control/Data трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
-
Портовият канал се поддържа както за RG контрол/данни, така и за интерфейси за трафик
-
Цялата сигнализация/медия се получава от/към виртуалния IP адрес
-
Всеки път, когато една платформа се презареди в CUBE-HA връзка, тя винаги се зарежда като Standby
-
Долният адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
-
Идентификатор на интерфейса за резервиране, rii трябва да бъде уникален за комбинация от двойки/интерфейси на един и същ слой 2
-
Конфигурацията на двете CUBE трябва да бъде идентична, включително физическа конфигурация и трябва да се изпълнява на един и същ тип платформа и IOS-XE версия
-
Интерфейсите Loopback не могат да се използват като свързващи, тъй като те винаги са нагоре
-
Интерфейсите за множествен трафик (SIP/RTP) (Gig1, Gig2) изискват конфигуриране на проследяването на интерфейса.
-
CUBE-HA не се поддържа чрез кръстосана кабелна връзка за връзката RG-контрол/данни (Gig3)
-
И двете платформи трябва да са идентични и да бъдат свързани чрез физически превключвател във всички също интерфейси, за да работи CUBE HA, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да се прекрати на един и същ превключвател и т.н.
-
Не може WAN да бъде прекратен директно на CUBE или Data HA от двете страни
-
И двете Active/Standby трябва да бъдат в един и същ център за данни
-
Задължително е да се използва отделен L3 интерфейс за резервиране (RG контрол/данни, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за поддържане на HA и контролно-пропускателен пункт
-
При неуспех предишният активен CUBE преминава през презареждане чрез дизайн, запазване на сигнализацията и медиите
Конфигуриране на съкращенията и на двете кубчета
Трябва да конфигурирате излишък от слой 2 от кутия до кутия на двете кубчета, предназначени да се използват в двойка HA, за да повдигнете виртуални IP адреси.
1 |
Конфигурирайте проследяването на интерфейса на глобално ниво, за да проследите състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса на гласовия трафик, така че активният маршрут да изпълнява активната си роля след като интерфейсът за трафик е надолу. | ||
2 |
Конфигуриране на RG за използване с VoIP HA в подрежим на резервиране на приложението.
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
3 |
Активирайте резервираността от кутия до кутия за приложението CUBE. Конфигурирайте RG от предишната стъпка по-долу
група за съкращения 1 —Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена. | ||
4 |
Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу, и прилагане на идентификатора на интерфейса за резервиране (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
| ||
5 |
Запазете конфигурацията на първия CUBE и го презаредете. Платформата за презареждане на последно винаги е в режим на готовност.
След като VCUBE-1 се зареди напълно, запишете конфигурацията на VCUBE-2 и го презаредите.
| ||
6 |
Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход е подчертан с удебелен шрифт. Презаредихме VCUBE-2 последно и според съображенията за проектиране; платформата за презареждане последно винаги ще бъде Standby. |
Конфигуриране на локален портал на двете кубчета
В нашата примерна конфигурация използваме следната информация за багажника от Control Hub, за да изградим конфигурацията на локалния шлюз на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:
-
Потребителско име: Хюсеин 1076 г_ LGU
-
Парола: Артикул: LOV12MEaZx
1 |
Уверете се, че за паролата е създаден конфигурационен ключ, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 са криптирани с помощта на AES шифър и този потребителски дефиниран конфигурационен ключ.
Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на контролния хъб , показани по-горе, запишете и презаредите. Идентификационните данни за SIP обработване на пълномощията от Control Hub са подчертани в смели .
За да покажем изхода на командата на шоуто, презаредихме VCUBE-2, последван от VCUBE-1, което направи VCUBE-1 готовност CUBE и VCUBE-2 активния CUBE |
2 |
Във всеки един момент само една платформа ще поддържа активна регистрация като локален портал с достъп до Webex Calling SBC. Обърнете внимание на изхода на следните команди на шоуто. Показване на група за кандидатстване за съкращения 1 покажете състоянието на регистъра на sip-ua
From the output above, you can see that VCUBE-2 is the active LGW maintaining the registration with Webex Calling access SBC, whereas the output of the “show sip-ua register status” is blank in VCUBE-1 |
3 |
Сега активирайте следните дебъгове на VCUBE-1
|
4 |
Симулирайте неуспех, като издадете следната команда на активния LGW, VCUBE-2 в този случай.
Преминаването от ACTIVE към STANDBY LGW се извършва в следния сценарий, както и освен CLI, изброени по-горе
|
5 |
Проверете дали VCUBE-1 се е регистрирал в Webex Calling достъп SBC. VCUBE-2 щеше да се презареди досега.
VCUBE-1 вече е активният LGW. |
6 |
Вижте съответния дневник за отстраняване на грешки във VCUBE-1, изпращайки SIP REGISTER на Webex Call VIA виртуалния IP и получавайки 200 OK.
|