- Начало
- /
- Статия
Local Gateway (LGW) е изключителното решение за предоставяне на локален PSTN достъп на Cisco Webex Calling клиенти. Този документ ви насочва при конфигурирането на локален шлюз с помощта на CUBE с висока наличност, с активни или в режим на готовност CUBES, за да се гарантира състоянието на превключване на активните повиквания.
Основи
Предпоставки
Преди да внедрите 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 функции.
Командите и дневниците за показване в тази статия се основават на минимална версия на софтуера на Cisco IOS -XE 17.9.1, внедрена на vCube (CSR 8000v).
Референтен материал
Ето някои подробни ръководства за конфигуриране на CUBE HA за различни платформи:
-
Предпочитана архитектура на 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е предложение за сътрудничество, което предоставя облачна алтернатива за множество наематели на локалната телефонна услуга PBX с множество опции за PSTN за клиенти.
Внедряването на Local Gateway (представено по-долу) е фокусът на тази статия. Локалният шлюз (базиран на помещения PSTN) багажникът Webex Calling позволява свързаност с PSTN услуга, притежавана от клиента. Той също така осигурява свързаност с локално внедряване на IP централа, като например. Cisco Unified CM Цялата комуникация към и от облака е защитена с помощта на TLS транспорт за SIP и SRTP за медии.
Фигурата по-долу показва в Webex Calling недряване без съществуваща IP централа и е приложима за внедряване на един или няколко обекта. Конфигурацията, описана в тази статия, се основава на това внедряване.
Излишаване от кутия към кутия от слой 2
REDUNDANCE от кутия към кутия слой 2 CUBE HA използва инфраструктурния протокол на Redundancy Group (RG), за да образува активна/готовност двойка рутери. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните си интерфейси и непрекъснато обменя съобщения за състоянието. Информацията за сесията на CUBE се проверява в двойката рутери, което позволява на маршрутизатора в режим на готовност да поеме всички отговорности за обработка на повиквания на CUBE незабавно, ако активният рутер излезе от експлоатация, което води до запазване на състоянието на сигнализацията и носителите.
Проверката е ограничена до свързани повиквания с медийни пакети. Обажданията при транзит не са насочени към проверка (например състояние на пробване или звънене).
В тази статия CUBE HA ще се позовава на резервирането на CUBE с висока наличност (HA) от слой 2 от кутията към кутия (B2B) за запазване на повикването в състояние.
От IOS-XE 17.9.1 CUBE HA може да бъде внедрен като локален шлюз за внедряване на магистрални инсталации (PSTN Cisco Webex Calling базиран на помещения). Тази статия ще обсъди дизайнерски съображения и конфигурации. Фигурата показва типична настройка на CUBE HA като Local Gateway за внедряване на Cisco Webex Calling багажника.
Инфракомпонент на групата за съкращаване
Компонентът Infra на Групата за освобождаване (RG) осигурява поддръжка на комуникационната инфраструктура „box to-box“ между двата CUBE и преговаря за окончателното стабилно състояние на съкращаване. Този компонент също така осигурява:
-
Протокол, подобен на HSRP, който договаря окончателното състояние на резервиране за всеки маршрутизатор чрез обмен на Keepalive и hello съобщения между двата CUBE (чрез контролния интерфейс) —GigabiteThernet3 на фигурата по-горе.
-
Транспортен механизъм за проверка на сигнализирането и състоянието на медиите за всяко повикване от активния към маршрутизатора в режим на готовност (чрез интерфейса за данни) —GigabiteThernet3 на фигурата по-горе.
-
Конфигуриране и управление на виртуалния IP (VIP) интерфейс за трафичните интерфейси (множество интерфейси за трафик могат да бъдат конфигурирани с помощта на една и съща RG група) — GigabiteEthernet 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 сесията на установените повиквания се проверяват от активния рутер към маршрутизатора в режим на готовност. Когато Active рутерът се спусне, маршрутизаторът в режим на готовност поема управлението и продължава да препраща RTP потока, който преди това е бил насочен от първия рутер.
Обажданията в преходно състояние по време на превключване няма да бъдат запазени след превключване. Например повиквания, които все още не са напълно установени или са в процес на модифициране с функция за прехвърляне или задържане. Установените повиквания могат да бъдат изключени след превключване.
Съществуват следните изисквания за използване на CUBE HA като локален шлюз за състоятелно превключване на повиквания:
-
CUBE HA не може да има съвместно разположени TDM или аналогови интерфейси
-
Gig1 и Gig2 се наричат интерфейси за трафик (SIP/RTP), а Gig3 е интерфейс за контрол/данни на групата на redundancy Group (RG)
-
Не повече от 2 двойки CUBE HA могат да бъдат поставени в един и същ домейн на слой 2, едната с id на група 1, а другата с идентификатор на група 2. Ако конфигурирате 2 HA двойки със същия идентификатор на групата, интерфейсите RG Control/Data трябва да принадлежат към различни домейни от слой 2 (vlan, отделен превключвател)
-
Портовият канал се поддържа както за RG контрол/данни, така и за интерфейси за трафик
-
Цялата сигнализация/медия се доставя от/до виртуалния IP адрес
-
Всеки път, когато платформата се презарежда във връзка CUBE-HA, тя винаги се стартира като режим на готовност
-
Долният адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа
-
Идентификатор на интерфейса за излишък, rii трябва да бъде уникален за комбинация двойка/интерфейс на същия слой 2
-
Конфигурацията и на двата CUBE трябва да е идентична, включително физическата конфигурация и трябва да работи на един и същ тип платформа и версия на IOS-XE
-
Интерфейсите за обратна връзка не могат да се използват като свързване, тъй като те винаги са нагоре
-
Множество интерфейси за трафик (SIP/RTP) (Gig1, Gig2) изискват конфигуриране на проследяването на интерфейса
-
CUBE-HA не се поддържа чрез кросоувър кабелна връзка за RG-Control/Data Link (Gig3)
-
И двете платформи трябва да са идентични и да бъдат свързани чрез физически превключ вател през всички подобни интерфейси, за да може CUBE HA да работи, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да завършат на един и същ превключвател и т.н.
-
Не може да бъде прекратен WAN директно на CUbes или Data HA от двете страни
-
И двете Active/Standby трябва да са в един и същ център за данни
-
Задължително е да се използва отделен L3 интерфейс за резервиране (RG Control/Data, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за HA папки и контролни показатели
-
При превключване при прекъсване преди това активният CUBE преминава през презареждане по дизайн, запазвайки сигнализацията и носителите
Конфигурирайте излишъка и на двата CUBE
Трябва да конфигурирате излишъка от поле до кутия от слой 2 на двата CUBE, предназначени да се използват в двойка HA, за да се появят виртуални IP адреси.
| 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 последно и според съображенията на дизайна; платформата за последно презареждане винаги ще бъде в режим на готовност.
След това продължете с конфигурацията на Local Gateway (базирана на регистрация или базирана на серти фикат) и на двата HA CUBE. Вижте Кон фигуриране на локален шлю Cisco IOS з на XE за Webex Calling. |