Local Gateway (LGW) е единственият вариант за предоставяне на помещения базирани PSTN достъп за Cisco Webex Calling клиенти. Целта на този документ е да Ви съдейства при изграждането на конфигурация на Local Gateway с помощта на CUBE висока наличност, активни/в режим на готовност Кубове за състояние отказ на активни повиквания.
Основите
Предварителни изисквания
Преди да разположите CUBE HA като локален шлюз за Webex Calling, уверете се, че имате задълбочено разбиране на следните понятия:
Layer 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 за различни платформи:
CSR 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 опции за клиенти.
Локалното разполагане на Gateway (представено по-долу) е във фокуса на тази статия. Местен шлюз (Помещения базирани PSTN) багажник в Webex Calling позволява свързаност към клиент собственост PSTN услуга. Той също така осигурява свързаност към атентален IP PBX разполагане като Cisco Unified CM. Цялата комуникация от и до облака е обезпечена с помощта на TLS транспорт за SIP и SRTP за медии.
Фигурата по-долу показва разполагане на Webex Calling без никакъв съществуващ IP PBX и е приложимо за разполагане на един или няколко сайта. Конфигурацията, очертана в тази статия, се основава на това разполагане.
Слой 2 Кутия към кутия Съкращения
CUBE HA слой 2 кутия към кутия уволнение използва протокола за инфраструктура на Групата за съкращения (RG) за формиране на активна / в режим на готовност двойка рутери. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните им интерфейси и непрекъснато обменят съобщения за състоянието. CUBE сесия информация е чек-посочи в двойката рутери, даващи възможност на рутера в режим на готовност да вземе всички cube повикване обработка отговорности над веднага, ако активният рутер излиза от експлоатация, което води до състояние запазване на сигнализация и медии.
Посочването на проверка е ограничено до свързани повиквания с мултимедийни пакети. Повикванията при транзит не се проверяват заострени (например състояние на опитване или звънене). В тази статия CUBE HA ще се отнася до CUBE висока наличност (HA) слой 2 Кутия към кутия (B2B) съкращения за състояние запазване на повиквания |
Считано от IOS-XE 16.12.2, CUBE HA може да се разположи като Локален шлюз за Cisco Webex Calling trunk (Premises-based PSTN) разполагания и ще покрием съображения и конфигурации на дизайна в тази статия. Тази фигура показва типичен КУБ HA настройка като Локален шлюз за Cisco Webex Calling багажник разполагане.
Редунданси Група Infra компонент
Компонентът Infra на Групата за съкращения (RG) осигурява подкрепата за комуникационната инфраструктура "кутия към кутия" между двете Кубове и договаря окончателното стабилно състояние на съкращения. Този компонент също така предоставя:
Протокол, подобен на HSRP, който договаря окончателното състояние на съкращения за всеки рутер чрез обмен на keepalive и hello съобщения между двете Кубове (чрез контролния интерфейс)—GigabitEthernet3 на фигурата по-горе.
Транспортен механизъм за контролно определяне на сигнализирането и медийното състояние за всяко обаждане от активния към маршрутизатора за готовност (чрез интерфейса за данни)—GigabitEthernet3 на фигурата по-горе.
Конфигуриране и управление на интерфейса virtual IP (VIP) за интерфейсите за трафик (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) – GigabitEthernet 1 и 2 се считат за интерфейси за трафик.
Този RG компонент трябва да бъде специално конфигуриран да поддържа глас B2B HA.
Управление на виртуален IP (VIP) адрес както за сигнализация, така и за медии
B2B HA разчита на VIP, за да постигне съкращения. VIP и свързаните физически интерфейси и на двата Кубчета в двойката CUBE HA трябва да пребивават на една и съща LAN подмрежа. Конфигурацията на VIP и свързването на VIP интерфейса с определено гласово приложение (SIP) са задължителни за гласова B2B HA поддръжка. Външни устройства като Унифициран CM, Webex Calling access SBC, доставчик на услуги или прокси, използват VIP като ip адрес местоназначение за разговорите, превъртащи през рутерите CUBE HA. Оттук от гледна точка на Webex Calling двойките CUBE HA действат като един-единствен местен шлюз.
Сигналната информация за повикванията и RTP сесийната информация на установените повиквания се проверяват от активния маршрутизатор към маршрутизатора за готовност. Когато Рутерът Active слиза надолу, маршрутизаторът Standby поема и продължава да препраща RTP потока, който преди това е бил насочван от първия рутер.
Обажданията в преходно състояние в момента на отказ няма да бъдат запазени след превключването. Например обажданията, които все още не са напълно установени или са в процес на промяна с функция за прехвърляне или задържане. Установените обаждания могат да бъдат прекъснати след превключването.
Следните изисквания съществуват за използване на CUBE HA като локален шлюз за състояние отказ на повиквания:
CUBE HA не може да има TDM или аналогови интерфейси съвместно разположени
Gig1 и Gig2 са наричани интерфейси трафик (SIP/RTP) и Gig3 е Redundancy Group (RG) Контрол/интерфейс за данни
Не повече от 2 CUBE HA двойки могат да бъдат поставени в един и същ слой 2 домейн, един с група ID 1, а другият с група ID 2. Ако конфигурирането на 2 HA двойки със същия ид на група, интерфейсите RG Control/Data трябва да принадлежат към различни домейни на слой 2 (vlan, отделен превключвател)
Порт канал се поддържа както за RG Control/ данни и трафик интерфейси
Всички сигнализация/носители се произхождат от/към Виртуалния IP адрес
По всяко време платформа е презаредена в CUBE-HA връзка, тя винаги ботуши нагоре като Standby
По-нисък адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
Redundancy Интерфейс Идентификатор, rii трябва да бъде уникален за двойка / интерфейс комбинация на същия Слой 2
Конфигурация на двете Кубове трябва да бъде идентичен включително физическа конфигурация и трябва да се изпълнява на един и същ тип платформа и IOS-XE версия
Интерфейсите за loopback не могат да се използват толкова обвързващи, колкото винаги са нагоре
Няколко интерфейса на трафика (SIP/RTP) (Gig1, Gig2) изискват проследяването на интерфейса да бъде конфигурирано
CUBE-HA не се поддържа през кръстосване кабелна връзка за връзката RG-контрол/данни (Gig3)
И двете платформи трябва да бъдат идентични и да бъдат свързани чрез физически Превключвател във всички по същия начин интерфейси, за да работи CUBE HA, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да се прекрати на един и същ превключвател и така нататък.
Не може WAN да е прекратено на CUBEs директно или Data HA от двете страни
И двете Активни/В режим на готовност трябва да са в един и същ център за данни
Задължително е да се използва отделен L3 интерфейс за съкращения (RG Control/data, Gig3). т.е интерфейс, използван за трафик, не може да се използва за ha keepalives и контролно-пропускателен пункт
При отказ преди това активният КУБ преминава през презареждане по дизайн, запазвайки сигнализацията и носителя
Конфигуриране на съкращаване на двете кубове
Трябва да конфигурирате layer 2 кутия-към-кутия уволнение на двете CUBEs, предназначени да бъдат използвани в HA двойка, за да изведе виртуални IPs.
1 | Конфигуриране на проследяване на интерфейс на глобално ниво за проследяване на състоянието на интерфейса.
Track CLI се използва в RG за проследяване на състоянието на интерфейса за гласово движение, така че активният маршрут да доста активната си роля, след като интерфейсът на трафика е надолу. |
||||||
2 | Конфигуриране на RG за използване с VoIP HA под режим на съкращения на приложението.
Ето обяснение на полетата, използвани в тази конфигурация:
|
||||||
3 | Разрешаване на съкращаване от кутия към кутия за приложението CUBE. Конфигуриране на RG от предишната стъпка под
съкращения-група 1—Добавяне и премахване на тази команда изисква презареждане за актуализираната конфигурация да влезе в сила. Ще презаредим платформите, след като цялата конфигурация е приложена. |
||||||
4 | Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IPs, както е показано по-долу, и прилагайте идентификатора на интерфейса за съкращения (rii)
Ето обяснение на полетата, използвани в тази конфигурация:
|
||||||
5 | Запишете конфигурацията на първия КУБ и я заредете повторно. Платформата за презареждане последно винаги е Режимът на готовност.
След VCUBE-1 ботуши нагоре напълно, запишете конфигурацията на VCUBE-2 и го презареди.
|
||||||
6 | Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход се маркира с получер шрифт. Презаредихме VCUBE-2 последно и както е според съображенията за проектиране; платформата за презареждане последна винаги ще бъде Standby.
|
Конфигуриране на локален шлюз и на двете кубове
В нашата примерна конфигурация използваме следната информация за багажника от Контролния център, за да изградим конфигурацията на Локалния шлюз както на платформите, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са следните:
Потребителско име: Хюсеин1076LGU_
Парола: lOV12MEaZx
1 | Осигурете създаването на конфигурационен ключ за паролата, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 се шифроват с помощта на AES шифър и този дефиниран от потребителя конфигурационен ключ.
Ето конфигурацията на Локалния шлюз, която ще се отнася за двете платформи въз основа на параметрите на контролния център , показани по-горе, запишете и презаредите. Идентификационни данни за SIP Digest от контролния център се открояват с удебелен шрифт.
За да се покаже изходът на командата show, презаредихме VCUBE-2 , последвано от VCUBE-1, което прави VCUBE-1 в режим на готовност CUBE и VCUBE-2 активния КУБ |
2 | Във всеки един момент само една платформа ще поддържа активна регистрация като Локален шлюз с Webex Calling достъп SBC. Разгледайте изхода на следните команди за показване. показват група за кандидатстване за съкращения 1 показване на статут на sip-ua-регистър
От изхода по-горе можете да видите, че VCUBE-2 е активната LGW поддържане на регистрацията с Webex Calling достъп SBC, докато изходът на "покажи sip-ua регистър състояние" е празен в 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 | Погледнете съответния debug регистрационен файл на VCUBE-1 изпращане на SIP РЕГИСТЪР на Webex Calling VIA виртуалния IP и получаване на 200 OK.
|