Основите

Предварителни изисквания

Преди да разгърнете CUBE HA като локален портал за Webex Calling, уверете се, че имате задълбочено разбиране на следните концепции:

Указанията за конфигуриране, предоставени в тази статия, приемат специална локална портална платформа без съществуваща гласова конфигурация. Ако съществуващо внедряване на 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 за различни платформи:

Преглед на решението за повикване на 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

Конфигурирайте проследяването на интерфейса на глобално ниво, за да проследите състоянието на интерфейса.

conf t track 1 интерфейс GigabitEthernet1 line-protocol track 2 интерфейс GigabitEthernet2 line-protocol exit 

VCUBE-1#conf

VCUBE-1(config)#track 1 интерфейс GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 интерфейс GigabitEthernet2 line-protocol

VCUBE-1( конфигурация-писта)#изход

VCUBE-2

VCUBE-2(config)#track 1 интерфейс GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 интерфейс GigabitEthernet2 line-protocol

VCUBE-2(config-track)#изход

Track CLI се използва в RG за проследяване на състоянието на интерфейса на гласовия трафик, така че активният маршрут да изпълнява активната си роля след като интерфейсът за трафик е надолу.

2

Конфигуриране на RG за използване с VoIP HA в подрежим на резервиране на приложението.

резервиране на приложение съкращаване група 1 име LocalGateway-HA приоритет 100 праг за преместване 75 контрол GigabitEthernet3 протокол 1 данни GigabitEthernet3 таймери забавяне 30 презареждане 60 писта 1 таймер 1 таймер hellotime 3 holdtime 10 exit exit exit 

VCUBE-1( конфигурация)#резервиране

VCUBE-1(конфигурационно червено)#резервиране на приложения

VCUBE-1(конфигуриране-червено-приложение)#група 1

VCUBE-1(config-red-app-grp)#име LocalGateway-HA

VCUBE-1(конфигурация-red-app-grp)#приоритет 100 праг за преместване при отказ 75

VCUBE-1(config-red-app-grp)#контрол на GigabitEthernet3 протокол 1

VCUBE-1(config-red-app-grp)#данни GigabitEthernet3

VCUBE-1(конфигурация-red-app-grp)#закъснение на таймера 30 презареждане 60

VCUBE-1(конфигурация-red-app-grp)#изключване на 1 запис

VCUBE-1(конфигурация-red-app-grp)#изключване на песен 2

VCUBE-1(конфигурация-red-app-grp)#изход

VCUBE-1(конфигурация-red-приложение)#протокол 1

VCUBE-1(конфигурация-red-app-prtcl)#таймери hellotime 3 holdtime 10

VCUBE-1(конфигурация-red-app-prtcl)#изход

VCUBE-1(конфигуриране-червено-приложение)#изход

VCUBE-1(конфигурационно червено)#изход

VCUBE-1( конфигурация)#

VCUBE-2(config)#redundancy

VCUBE-2(конфигурационно червено)#резервиране на приложения

VCUBE-2(конфигуриране-червено-приложение)#група 1

VCUBE-2(config-red-app-grp)#име LocalGateway-HA

VCUBE-2(конфигурация-red-app-grp)#приоритет 100 праг за преместване при отказ 75

VCUBE-2(config-red-app-grp)#контрол на GigabitEthernet3 протокол 1

VCUBE-1(config-red-app-grp)#данни GigabitEthernet3

VCUBE-2(конфигурация-red-app-grp)#закъснение на таймера 30 презареждане 60

VCUBE-2(конфигурация-red-app-grp)#изключване на песен 1

VCUBE-2(конфигурация-red-app-grp)#изключване на песен 2

VCUBE-2(конфигурация-red-app-grp)#изход

VCUBE-2(config-red-app)#протокол 1

VCUBE-2(конфигурация-red-app-prtcl)#таймер hellotime 3 holdtime 10

VCUBE-2(конфигурация-red-app-prtcl)#изход

VCUBE-2(конфигуриране-червено-приложение)#изход

VCUBE-2(конфигурационно червено)#изход

VCUBE-2(конфигурация)#

Ето обяснение на полетата, използвани в тази конфигурация:

  • излишък—Влиза в режим на излишък

  • резерв на приложения—Влиза в конфигурационен режим на резерв на приложения

  • група—Влиза в режим на конфигуриране на група приложения за резервиране

  • име LocalGateway-HA – Определя името на RG групата

  • приоритет 100 праг за отказ 75—Посочва праговете за първоначален приоритет и за отказ за RG

  • Закъснение на таймера 30 презареждане 60– Конфигурира двата пъти за закъснение и презареждане

    • Таймер за забавяне, който е времето, за да забави инициализацията на RG групата и преговорите за роля, след като интерфейсът се появи – по подразбиране 30 секунди. Диапазонът е 0-10000 секунди

    • Презареждане – Това е времето, за да забавите инициализацията на RG групата и договарянето на роли след презареждане – по подразбиране 60 секунди. Диапазонът е 0-10000 секунди

    • Препоръчват се таймери по подразбиране, въпреки че тези таймери могат да бъдат коригирани, за да се настанят всяко допълнително забавяне на конвергенцията на мрежата, което може да възникне по време на стартирането/презареждането на рутерите, за да се гарантира, че преговорите по протокола RG се провеждат след маршрутизиране в мрежата се е сближило до стабилна точка. Например, ако след неуспех се види, че са необходими до 20 сек за новия STANDBY, за да се види първият пакет RG HELLO от новия ACTIVE, таймерите трябва да бъдат коригирани до "таймери забавят 60 презареждане 120", за да се вземе предвид това забавяне.

  • управление на GigabitEthernet3 протокол 1 – Конфигурира интерфейса, използван за обмен на поддържащи и здравейте съобщения между двата CUBE, и указва екземпляра на протокола, който ще бъде прикачен към контролен интерфейс и влиза в режим на конфигуриране на протокол на приложение на излишък

  • данни GigabitEthernet3 – конфигурира интерфейса, използван за проверка на трафика на данни

  • запис – проследяване на групи в RG на интерфейси

  • протокол 1 – Указва екземпляра на протокола, който ще бъде прикачен към контролен интерфейс и влиза в режим на конфигуриране на приложен протокол за излишък

  • таймери за hellotime 3 holdtime 10— Конфигурира двата таймера за hellotime и holdtime:

    • Hellotime – Интервал между последователни съобщения за здравей – По подразбиране 3 секунди. Диапазонът е 250 милисекунди-254 секунди

    • Holdtime – Интервалът между получаването на съобщение Hello и презумпцията, че изпращащият рутер се е провалил. Тази продължителност трябва да бъде по-голяма от времето за здравей – по подразбиране 10 секунди. Диапазонът е 750 милисекунди-255 секунди

      Препоръчваме ви да конфигурирате таймера за изчакване да бъде най-малко 3 пъти стойността на таймера hellotime.

3

Активирайте резервираността от кутия до кутия за приложението CUBE. Конфигурирайте RG от предишната стъпка под voip за гласова услуга. Това позволява на приложението CUBE да контролира процеса на съкращения.

гласова услуга voip резервиране-група 1 изход

VCUBE-1(config)#voip на гласовата услуга

VCUBE-1( config-voi-serv)#redundancy-група 1

 % създаде асоциация на RG 1 с Voice B2B HA; презаредете маршрутизатора, за да влезе в сила новата конфигурация 

VCUBE-1(config-voi-serv)# изход

VCUBE-2(config)#voip на гласовата услуга

VCUBE-2( config-voi-serv)#redundancy-група 1

 % създаде асоциация на RG 1 с Voice B2B HA; презаредете маршрутизатора, за да влезе в сила новата конфигурация 

VCUBE-2(config-voi-serv)# изход

redundancy-group 1 – Добавянето и премахването на тази команда изисква презареждане, за да влезе в сила актуализираната конфигурация. Ще презаредим платформите, след като цялата конфигурация бъде приложена.

4

Конфигуриране на интерфейсите Gig1 и Gig2 със съответните им виртуални IP адреси, както е показано по-долу, и прилагане на идентификатора на интерфейса за резервиране (rii)

VCUBE-1(config)#интерфейс GigabitEthernet1

VCUBE-1(config-if)# redundancy rii 1

VCUBE-1(config-if)# група за резервиране 1 ip 198.18.1.228 изключителен

VCUBE-1(конфигурация-ако)# изход

VCUBE-1( конфигурация)#

VCUBE-1(config)#интерфейс GigabitEthernet2

VCUBE-1(конфигурация-ако)# резерв rii 2

VCUBE-1(config-if)# група за резервиране 1 ip 198.18.133.228 изключителен

VCUBE-1(конфигурация-ако)# изход

VCUBE-2(config)#интерфейс GigabitEthernet1

VCUBE-2(config-if)# резерв rii 1

VCUBE-2(config-if)# група за резервиране 1 ip 198.18.1.228 изключителен

VCUBE-2(конфигурация-ако)# изход

VCUBE-2(конфигурация)#

VCUBE-2(config)#интерфейс GigabitEthernet2

VCUBE-2(config-if)# резерв rii 2

VCUBE-2(config-if)# група за резервиране 1 ip 198.18.133.228 изключителен

VCUBE-v(конфигурация-ако)# изход

Ето обяснение на полетата, използвани в тази конфигурация:

  • redundancy rii—Конфигурира идентификатора на интерфейса за redundancy за групата за redundancy. Необходимо е за генериране на виртуален MAC (VMAC) адрес. Същата стойност на rii ID трябва да се използва в интерфейса на всеки рутер (ACTIVE/STANDBY), който има един и същ VIP.

    Ако има повече от една двойка B2B в една и съща LAN, всяка двойка ТРЯБВА да има уникални ИД на rii на съответните си интерфейси (за да се предотврати сблъсък). „Показване на всички групи приложения за резервиране“ трябва да показва правилната локална и партньорска информация.

  • група за резервиране 1 – Свързва интерфейса с групата за резервиране, създадена в стъпка 2 по-горе. Конфигурирайте RG групата, както и VIP, присвоен на този физически интерфейс.

    Задължително е да се използва отделен интерфейс за съкращения, т.е. интерфейсът, използван за гласов трафик, не може да се използва като интерфейс за управление и данни, посочен в стъпка 2 по-горе. В този пример Gigabit интерфейс 3 се използва за RG контрол/данни

5

Запазете конфигурацията на първия CUBE и го презаредете.

Платформата за презареждане на последно винаги е в режим на готовност.

VCUBE-1#wr

 Конфигуриране на сграда... 

 [ok] 

VCUBE-1#презареждане

 Да продължите с презареждане? [потвърждаване]

След като VCUBE-1 се зареди напълно, запишете конфигурацията на VCUBE-2 и го презаредите.

VCUBE-2#wr

 Конфигуриране на сграда... 

 [ok] 

VCUBE-2#презареждане

 Да продължите с презареждане? [потвърждаване]

6

Проверете дали конфигурацията "кутия към кутия" работи според очакванията. Съответният изход е подчертан с удебелен шрифт.

Презаредихме VCUBE-2 последно и според съображенията за проектиране; платформата за презареждане последно винаги ще бъде Standby. 

 VCUBE-1#показване на група приложения за резервиране на всички състояния на грешки за група 1 информация:        Приоритет по време на изпълнение: [100] Грешки в RG Състояние на RG: Нагоре.                        Общ брой превключвания поради грешки:  0 Общ брой промени в състоянието надолу/нагоре поради грешки: 0 ИД на група:1 Име на група:LocalGateway-HA Административно състояние: Няма Общо Оперативно Състояние На изключване: Нагоре Моята роля: Активна РОЛЯ На Равнопоставен: Присъствие НА връстник в режим на готовност : Да Връстник Comm: Да Стартирана Прогресия На Връстника: Да RF домейн: btob-one RF състояние: Активно СЪСТОЯНИЕ На RF на равноправна страна: Standby HOT RG протокол RG 1 ------------------ Роля: Активни преговори: Активиран приоритет: 100 Състояние на протокола: Активно състояние На Ctrl Intf(и): Активен връстник нагоре: Локален равнопоставен режим на готовност: адрес 10.1.1.2, приоритет 100, intf Gi3 Броячи на регистрационни файлове:                 промяна на ролята на „активна“: 1 роля се променя на режим на готовност: 1 деактивиране на събития: rg в състояние надолу 0, rg затвори 0 ctrl intf събития: нагоре 1, надолу 0, admin_down 0 презареждане на събития: локално искане 0, партньорска заявка 0 RG Media Context for RG 1 -------------------------- Ctx State: ИД на активен протокол: 1 Тип мултимедия: Интерфейс за управление по подразбиране: GigabitEthernet3 Текущ таймер за здравейте: 3000 Конфигуриран таймер за здравейте: 3000, таймер за задържане: 10000 Peer Здравейте таймер: 3000, таймер за задържане на връстник: 10000 статистика:             Pkts 1509, байтове 93558, HA seq 0, Seq Номер 1509, Загуба На Pkt 0 Не е конфигурирано удостоверяване Неуспешно удостоверяване: 0 Презареждане на връстник: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Подарък. Таймер за задържане: 10000 Pkts 61, байтове 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-1#
 VCUBE-2#показване на група приложения за резервиране на всички Състояния на грешка Група 1 информация:        Приоритет по време на изпълнение: [100] Грешки в RG Състояние на RG: Нагоре.                        Общ брой превключвания поради грешки:  0 Общ брой промени в състоянието надолу/нагоре поради грешки: 0 ИД на група:1 Име на група:LocalGateway-HA Административно състояние: Няма Общо Оперативно Състояние На изключване: Нагоре Моята роля: Роля НА ВРЪСТНИК В режим на готовност: Активно ПРИСЪСТВИЕ На Връстник: Да Връстник Comm: Да Стартирана Прогресия На Връстника: Да RF домейн: btob-one RF състояние: Активно СЪСТОЯНИЕ На RF на равноправна страна: Standby HOT RG протокол RG 1 ------------------ Роля: Активни преговори: Активиран приоритет: 100 Състояние на протокола: Активно състояние На Ctrl Intf(и): Активен връстник нагоре: адрес 10.1.1.2, приоритет 100, intf Gi3 Равнопоставен в режим на готовност: Броячи на локални регистрационни файлове:                 промяна на ролята на „активна“: 1 роля се променя на режим на готовност: 1 деактивиране на събития: rg в състояние надолу 0, rg затвори 0 ctrl intf събития: нагоре 1, надолу 0, admin_down 0 презареждане на събития: локално искане 0, партньорска заявка 0 RG Media Context for RG 1 -------------------------- Ctx State: ИД на активен протокол: 1 Тип мултимедия: Интерфейс за управление по подразбиране: GigabitEthernet3 Текущ таймер за здравейте: 3000 Конфигуриран таймер за здравейте: 3000, таймер за задържане: 10000 Peer Здравейте таймер: 3000, таймер за задържане на връстник: 10000 статистика:             Pkts 1509, байтове 93558, HA seq 0, Seq Номер 1509, Загуба На Pkt 0 Не е конфигурирано удостоверяване Неуспешно удостоверяване: 0 Презареждане на връстник: TX 0, RX 0 Resign: TX 0, RX 0 Standy Peer: Подарък. Таймер за задържане: 10000 Pkts 61, байтове 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-2#

Конфигуриране на локален портал на двете кубчета

В нашата примерна конфигурация използваме следната информация за багажника от Control Hub, за да изградим конфигурацията на локалния шлюз на двете платформи, VCUBE-1 и VCUBE-2. Потребителското име и паролата за тази настройка са както следва:

  • Потребителско име: Hussain1076_ЛГУ

  • Парола: Артикул: LOV12MEaZx

1

Уверете се, че за паролата е създаден конфигурационен ключ, като командите са показани по-долу, преди да може да се използва в идентификационните данни или споделените тайни. Паролите тип 6 са криптирани с помощта на AES шифър и този потребителски дефиниран конфигурационен ключ. 

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#encryption aes

Ето конфигурацията на локалния шлюз, която ще се прилага и за двете платформи въз основа на параметрите на контролния хъб , показани по-горе, запишете и презаредите. Идентификационните данни за SIP Digest от Control Hub се открояват в получер.

 конфигуриране на терминал крипто pki trustpoint dummyTp анулиране-проверка crl изход sip-ua crypto сигнализация по подразбиране trustpoint dummyTp cn-san-валидиране сървър транспорт tcp tls v1.2 край конфигуриране терминал крипто pki trustpool импортиране чист URL http://www.cisco.com/security/pki/trs/ios_core.p7b край конфигуриране на терминалната гласова услуга VOIP IP адрес списък с надеждни IPV4 x.x.x.x y.y.y.y.y.y.y.y.exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-substitutes fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 13 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 13 response ANY sip-headerкосмати1076_lgu>" правило 30 изисква всяка SIP-заглавка P-Asserted-Identity модифициране "sips:(.*)" "sip:\1" гласов клас кодек 99 предпочитания за кодек 1 g711ulaw предпочитания за кодек 2 g711ulaw изход гласов клас srtp-crypto 200 crypto 1 AES_см_128_hmac_Sha1_80 изход от гласов клас stun-използване 200 stun използване защитна стена-traversal flowdata изход от гласов клас клиент 200 регистратор dns:40462196.cisco-bcld.com схема sips изтича 240 опресняване съотношение 50 tcp tls идентификационни данни номер Униформа7091_LGU потребителско име Hussain1076_Парола за ЛГУ 0 OV12MEaZx област Broadworks удостоверяване потребителско име Униформа7091_LGU парола 0 OV12MEaZx област на удостоверяване на BroadWorks Униформа7091_LGU парола 0 OV12MEaZx област 40462196.cisco-bcld.com няма SIP-сървър на отдалечената страна-ИД dns:40462196.cisco-bcld.com връзка-повторно използване srtp-crypto 200 сесия транспорт tcp tls url sips грешка-passthru asserted-id pai обвързване контрол източник-интерфейс GigabitEthernet1 обвързване мултимедиен източник-интерфейс GigabitEthernet1 без съдържание pass-thru персонализиран-sdp sip-профили 200 изходящ прокси dns:la01.sipconnect-us10.cisco-bcld.com поверителност-правила passthru гласов клас клиент 100 сесия транспорт udp url адрес sip грешка-passthru обвързване на контрола източник-интерфейс GigabitEthernet2 обвързване на мултимедиен източник-интерфейс GigabitEthernet2 без съдържание pass-thru персонализиран-sdp гласов клас клиент 300 обвързване на контрола източник-интерфейс GigabitEthernet2 обвързване на мултимедиен източник-интерфейс GigabitEthernet2 обвързване на мултимедиен източник-интерфейс GigabitEthernet2 без съдържание pass-thru персонализиран-sdp гласов клас uri 100 sip хост ipv4:198.18.133.3 гласов клас uri 200 sip модел dtg=космати1076.lgu набиране-равнопоставен глас 101 voip описание Изходящ набиране-равнопоставен към IP PSTN местоназначение-модел BAD.BAD протокол за сесия sipv2 цел на сесия ipv4:198.18.133.3 кодек за гласов клас 99 гласов клас sip клиент 100 dtmf-relay rtp-nte без vad набиране-равнопоставен глас 201 voip описание Изходящ набиране-равнопоставен към Webex Calling местоназначение-модел BAD.BAD протокол за сесия sipv2 целева сесия sip-сървър гласов клас кодек 99 гласов клас stun-използване 200 без гласов клас sip локалхост гласов клас sip клиент 200 dtmf-relay rtp-nte srtp без vad край копие изпълнение

За да покажем изхода на командата на шоуто, презаредихме VCUBE-2, последван от VCUBE-1, което направи VCUBE-1 готовност CUBE и VCUBE-2 активния CUBE

2

Във всеки един момент само една платформа ще поддържа активна регистрация като локален портал с достъп до Webex Calling SBC. Обърнете внимание на изхода на следните команди на шоуто.

Показване на група за кандидатстване за съкращения 1

показване на статус нарегистриране на sip-ua 

 VCUBE-1#показване на група на приложението за резервиране 1 Група ИД:1 Име на група:LocalGateway-HA Административно състояние: Няма Общо Оперативно Състояние На изключване: Нагоре Моята роля: Роля на равнопоставена в режим на готовност: Активно ПРИСЪСТВИЕ На Връстник: Да Връстник Comm: Да Стартирана Прогресия На Връстника: Да RF домейн: btob-one RF състояние: Състояние на ГОТОВНОСТ ЗА ГОРЕЩА Равноправна РАДИОЧЕСТОТНА лента: ACTIVE VCUBE-1#показване на статуса на регистриране на sip-ua VCUBE-1#

 VCUBE-2#показване на група на приложението за резервиране 1 Група ИД:1 Име на група:LocalGateway-HA Административно състояние: Без изключване на агрегирано състояние на работа: Нагоре Моята роля: Активна РОЛЯ На Равнопоставен: Присъствие НА ВРЪСТНИК За Статус: Да Връстник Comm: Да Стартирана Прогресия На Връстника: Да RF домейн: btob-one RF състояние: Активно СЪСТОЯНИЕ На RF на равноправна страна: Standby HOT VCUBE-2#показване на статуса на регистриране на sip-ua Клиент: 200 --------------------Регистратор-индекс  1 --------------------- линия връстник изтича (сек) рег преживяемост P-Associ-URI ============================== ===========================================================================================================================================================================================================================================================================================_LGU -1 48 да нормално VCUBE-2#

От изхода по-горе можете да видите, че VCUBE-2 е активната LGW, поддържаща регистрацията с SBC за достъп до Webex Calling, докато изхода от „показване на състоянието на регистриране на sip-ua“ е празен в VCUBE-1

3

Сега активирайте следните дебъгове на VCUBE-1

 VCUBE-1#debug ccsip без повикване SIP проследяването извън диалоговия прозорец е активирано VCUBE-1#debug ccsip информация SIP Проследяването на информацията за повикването е активирано VCUBE-1#debug ccsip съобщение

4

Симулирайте неуспех, като издадете следната команда на активния LGW, VCUBE-2 в този случай.

 VCUBE-2#резервиране на приложение за презареждане на самостоятелно група 1

Преминаването от ACTIVE към STANDBY LGW се извършва в следния сценарий, както и освен CLI, изброени по-горе

  • Когато АКТИВНИЯТ рутер се презареди

  • Когато ACTIVE рутер мощност цикли

  • Когато всеки RG конфигуриран интерфейс на ACTIVE рутера е изключен, за който е разрешено проследяване

5

Проверете дали VCUBE-1 се е регистрирал в Webex Calling достъп SBC. VCUBE-2 щеше да се презареди досега.

 VCUBE-1#показване на статус на регистриране на sip-ua Клиент: 200 --------------------Регистратор-индекс  1 --------------------- линия връстник expires (сек) reg survival P-Associ-URI ============================== ========== =========================================================================================================================================================================Hussain5091_LGU -1 56 да нормално VCUBE-1#

VCUBE-1 вече е активният LGW.

6

Вижте съответния дневник за отстраняване на грешки във VCUBE-1, изпращайки SIP REGISTER на Webex Call VIA виртуалния IP и получавайки 200 OK.

 VCUBE-1#показване на регистрационния файл на 9 януари 18:37:24.769: %RG_MEDIA-3-TIMERИЗТЕКЪЛ СРОК: RG id 1 Здравейте, времето Изтече. 9 януари 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: Промяна на ролята на RG id 1 от режим на готовност на активен 9 януари 18:37:24.783: %VOICE_HA-2-ПРЕВКЛЮЧВАНЕ_IND: Превключване ОТ РЕЖИМ НА ГОТОВНОСТ_ГОРЕЩО към АКТИВНО състояние. 9 януари 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Получено известие за активно събитие за роля 9 януари 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Изпратено: Регистриране НА SIP: 40462196.cisco-bcld.com:5061 SIP/2.0 Чрез: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 От: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 До: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Дата: Чет, 09 Ян. 2020 18:37:24 GMT ИД на повикване: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFB5F93B97 Потребителски агент: Cisco-SIPGateway/IOS-16.12.02 Макс. пренасочвания: 70 Времево клеймо: 1578595044 CSeq: 2 Контакт ЗА РЕГИСТРИРАНЕ: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Изтича: 240 Поддържани: път съдържание – дължина на пътя: 0 

9 януари 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Получени: SIP/2.0 401 Неупълномощен Чрез: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 От: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 До: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Дата: Чет, 09 Ян. 2020 18:37:24 GMT ИД на повикване: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFB5F93B97 Времево клеймо: 1578595044 CSeq: 2 Регистриране НА WWW-Authenticate; DIGEST realm="BroadWorks",qop="auth",nonce="BroadWorksXk572qd01Ti58zliBW",algorithm=MD5 Content-Length: 0 

Jan 9 18:37:26.000: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Изпратено: Регистриране SIP:40462196.cisco-bcld.com:5061 SIP/2.0 Чрез: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC От: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 До: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Дата: Чет, 09 Ян. 2020 18:37:25 GMT ИД на повикване: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFB5F93B97 Потребителски агент:Cisco-SIPGateway/IOS-16.12.02 Макс. пренасочвания: 70 Времево клеймо: 1578595045 CSeq: 3 Контакт ЗА РЕГИСТРИРАНЕ: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Изтича: 240 Поддържани: път Упълномощаване: Digest username="Hussain1076_LGU",realm="BroadWorks",uri="sips:40462196.cisco-bcld.com:5061",response="b6145274056437b9c07f7ecc08ebdb02",nonce="BroadWorksXk572qd01Ti58z1iBW",cnonce="3E0E2C4D",qop=auth,algorithm=MD5,nc=00000001 Дължина на съдържанието: 0 

9 януари 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Получени: SIP/2.0 200 OK Чрез: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 От: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 До: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 ИД на повикване: FFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFB5F93B97 Времево клеймо: 1578595045 CSeq: 3 Контакт ЗА РЕГИСТРИРАНЕ: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Позволяване-събития: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Съдържание-Дължина: 0