Основите

Предпоставки

Преди да разгърнете 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 интерфейс 1 интерфейс GigabitEthernet1 линия-протокол път 2 интерфейс GigabitEthernet2 изход на линия-протокол 

VCUBE-1#conf t

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

VCUBE-1(config-track)# линия 2 интерфейс GigabitEthernet2 протокол

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

VCUBE-2#conf t

VCUBE-2(config)# линия 1 интерфейс GigabitEthernet1 протокол

VCUBE-2(config-track)# линия 2 интерфейс GigabitEthernet2 протокол

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

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

2

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

приложение за резервиране, група за резервиране 1 име LocalGateway-HA приоритет 100 праг за отказ 75 контрол GigabitEthernet3 протокол 1 данни GigabitEthernet3 таймери забавяне 30 презареждане 60 път 1 изключване път 2 изключване изходен протокол 1 таймери изход hellotime 3 задържане изход hellotime 3 

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

VCUBE-1(config-red)# излишък на приложения

VCUBE-1(config-red-app)# група 1

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

VCUBE-1(config-red-app-grp)# приоритет 100 праг на отказ 75

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

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

VCUBE-1(config-red-app-grp)# таймери забавяне 30 презареждане 60

VCUBE-1(config-red-app-grp)# изключване на песен 1

VCUBE-1(config-red-app-grp)# изключване на канал 2

VCUBE-1(config-red-app-grp)# изход

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

VCUBE-1(config-red-app-prtcl)# таймери hellotime 3 време на задържане 10

VCUBE-1(config-red-app-prtcl)# изход

VCUBE-1(config-red-app)# изход

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

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

VCUBE-2(config)# излишък

VCUBE-2(config-red)# излишък на приложения

VCUBE-2(config-red-app)# група 1

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

VCUBE-2(config-red-app-grp)# приоритет 100 праг на отказ 75

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

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

VCUBE-2(config-red-app-grp)# таймери забавяне 30 презареждане 60

VCUBE-2(config-red-app-grp)# изключване на песен 1

VCUBE-2(config-red-app-grp)# изключване на канал 2

VCUBE-2(config-red-app-grp)# изход

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

VCUBE-2(config-red-app-prtcl)# таймери hellotime 3 време на задържане 10

VCUBE-2(config-red-app-prtcl)# изход

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

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

VCUBE-2(config)#

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

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

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

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

  • име 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 —Конфигурира интерфейса, използван за обмен на съобщения за поддържане на активност и hello между двата CUBE, и посочва екземпляра на протокола, който ще бъде прикачен към контролен интерфейс и влиза в режим на конфигурация на протокола за резервиране на приложения

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

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

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

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

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

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

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

3

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

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

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

VCUBE-1(config-voi-serv)# група за съкращения 1

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

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

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

VCUBE-2(config-voi-serv)# група за съкращения 1

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

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

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

4

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

VCUBE-1(конфигурация)# интерфейс GigabitEthernet1

VCUBE-1(config-if)# съкращения rii 1

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

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

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

VCUBE-1(конфигурация)# интерфейс GigabitEthernet2

VCUBE-1(config-if)# съкращения rii 2

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

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

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

VCUBE-2(config-if)# съкращения rii 1

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

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

VCUBE-2(config)#

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

VCUBE-2(config-if)# съкращения rii 2

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

VCUBE-v(config-if)# изход

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

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

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

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

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

5

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

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

VCUBE-1# wr

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

 [ОК] 

VCUBE-1# презареди

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

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

VCUBE-2# wr

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

 [ОК] 

VCUBE-2# презареди

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

6

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

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

 VCUBE-1# показва всички групи приложения за съкращаване Състояния на неизправности Информация за група 1:        Приоритет по време на изпълнение: [100] RG неизправности RG състояние: нагоре.                        Общ брой превключвания поради неизправности:  0 Общ брой промени в състоянието надолу/горе поради грешки: 0 ИД на групата: 1 Име на групата: LocalGateway-HA Административна държава: Работно състояние на агрегата за изключване: нагоре Моята роля: АКТИВНА партньорска роля: РЕЖИМ НА РЕЖИМ Присъствие на връстници: Да Peer Comm: Да Започна напредъкът на партньорите: Да RF домейн: btob-one RF състояние: АКТИВНО равностойно радиочестотно състояние: STANDBY HOT RG Protocol RG 1 ------------------ Роля: Активни преговори: Активиран приоритет: 100 Протокол състояние: Състояние на Active Ctrl Intf(s): Up Active Peer: Местни Резервен партньор: адрес 10.1.1.2, приоритет 100, intf Gi3 Броячи на регистрационните файлове:                 промяна на ролята на активна: 1 промяна на ролята в режим на готовност: 1 деактивиране на събития: rg down state 0, rg shut 0 ctrl intf събития: нагоре 1, надолу 0,admin_down 0 събития за презареждане: локална заявка 0, равностойна заявка 0 RG медиен контекст за RG 1 -------------------------- Ctx състояние: Активен ИД на протокола: 1 Тип носител: По подразбиране Контролен интерфейс: GigabitEthernet3 Текущ таймер Hello: 3000 конфигуриран Hello таймер: 3000, Таймер за задържане: 10000 Peer Hello таймер: 3000, таймер за задържане на партньори: 10000 статистики:             Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Удостоверяването не е конфигурирано Неуспешно удостоверяване: 0 Презареждане Peer: TX 0, RX 0 Оставка: TX 0, RX 0 Standy Peer: Настояще. Таймер за задържане: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt загуба 0 VCUBE-1#
 VCUBE-2# показва всички групи приложения за съкращаване Състояния на неизправности Информация за група 1:        Приоритет по време на изпълнение: [100] RG неизправности RG състояние: нагоре.                        Общ брой превключвания поради неизправности:  0 Общ брой промени в състоянието надолу/горе поради грешки: 0 ИД на групата: 1 Име на групата: LocalGateway-HA Административна държава: Работно състояние на агрегата за изключване: нагоре Моята роля: Роля на партньорите в режим на готовност: АКТИВЕН Присъствие на връстници: Да Peer Comm: Да Започна напредъкът на партньорите: Да RF домейн: btob-one RF състояние: АКТИВНО равностойно радиочестотно състояние: STANDBY HOT RG Protocol RG 1 ------------------ Роля: Активни преговори: Активиран приоритет: 100 Протокол състояние: Състояние на Active Ctrl Intf(s): нагоре Активен партньор: адрес 10.1.1.2, приоритет 100, intf Gi3 Резервен партньор: Локални регистрационни броячи:                 промяна на ролята на активна: 1 промяна на ролята в режим на готовност: 1 деактивиране на събития: rg down state 0, rg shut 0 ctrl intf събития: нагоре 1, надолу 0,admin_down 0 събития за презареждане: локална заявка 0, равностойна заявка 0 RG медиен контекст за RG 1 -------------------------- Ctx състояние: Активен ИД на протокола: 1 Тип носител: По подразбиране Контролен интерфейс: GigabitEthernet3 Текущ таймер Hello: 3000 конфигуриран Hello таймер: 3000, Таймер за задържане: 10000 Peer Hello таймер: 3000, таймер за задържане на партньори: 10000 статистики:             Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0 Удостоверяването не е конфигурирано Неуспешно удостоверяване: 0 Презареждане Peer: TX 0, RX 0 Оставка: TX 0, RX 0 Standy Peer: Настояще. Таймер за задържане: 10000 Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0 VCUBE-2#

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

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

  • Потребителско име: Хюсеин 1076 г_ LGU

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

1

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

 LocalGateway#conf t LocalGateway(config)# ключ config-key password-encrypt Password123 LocalGateway(config)# криптиране на парола aes

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

 configure terminal crypto pki trustpoint dummyTp revocation-check crl exit sip-ua crypto signaling default trustpoint dummyTp cn-san-validate server transport tcp tls v1.2 end configure terminal crypto pki trustpool import clean urlhttp://www.cisco.com/security/pki/trs/ios_core.p7b край конфигуриране на терминална гласова услуга voip IP адрес доверен списък ipv4 xxxx yyyy изход разреши-връзки sip to sip медийни статистики медия bulk-stats без допълнителна услуга sip препращане без допълнителна услуга sip дръжка-заменя факс протокол pass-through g711ulaw зашеметяване зашеметяване flowdata agent -id 1 boot-count 4 stun flowdata споделена тайна 0 Password123! sip g729 annexb-all ранна оферта принудителен край конфигуриране на терминал гласов клас sip-профили 200 правило 9 заявка ВСЯКАКВА sip-заглавка SIP-Req- URI модифициране на "sips:(.*)" "sip:\1" правило 10 заявка ВСЯКА гл. гл. -заглавка За промяна "  " " " отговор на правило 13 ВСЯКАКВА глътка заглавка За промяна "  " ";otg= hussain1076_lgu >" правило 30 заявка ВСЯКАКВА sip-заглавка P-Asserted-Identity модифицира "sips:(.*)" "sip:\1" гласов клас кодек 99 предпочитание за кодек 1 g711ulaw предпочитание за кодек 2 g711ulaw изход гласов клас srtp-crypto 200 crypto 1 AES_ CM_ 128_ HMAC_ SHA1_ 80 изход гласов клас зашеметяване-използване 200 зашеметяване използване защитна стена-преминаване на поток данни изход гласов клас наемател 200 регистратор dns:40462196.cisco-bcld.com схема глътка изтича 240 съотношение на опресняване 50 tcp tls идентификационен номер Хюсеин5091_ LGU потребителско име Hussain1076_ LGU парола 0 lOV12MEaZx realm потребителско име за удостоверяване на Broadworks Хюсеин5091_ LGU парола 0 lOV12MEaZx потребителско име за удостоверяване на сферата на BroadWorks Хюсеин5091_ LGU парола 0 lOV12MEaZx царство4046219 6.cisco-bcld.com няма sip-сървър с идентификатор на отдалечена страна dns:40462196.cisco-bcld.com връзка-повторна употреба srtp-crypto 200 транспорт на сесия tcp tls url sips error-passthru asserted-id pai bind контрол източник-интерфейс GigabitEthernet1 свързване на медия източник-интерфейс GigabitEthernet1 без преминаване през съдържание персонализирани-sdp sip-профили 200 изходящ-прокси dns:la01.sipconnect-us10.cisco-bcld.com политика за поверителност passthru гласов клас наемател 100 сесия транспорт udp url sip грешка-passthru управление на свързване източник-интерфейс GigabitEthernet2 свързване на медия източник-интерфейс GigabitEthernet2 без преминаване на съдържание custom-sdp гласов клас наемател 300 свързване контрол източник-интерфейс GigabitEthernet-2 bind media source-2 интерфейс GigabitEthernet2 без преминаване през съдържание custom-sdp гласов клас uri 100 sip хост ipv4:198.18.133.3 гласов клас uri 200 sip модел dtg= hussain1076.lgu dial-peer глас 101 voip описание Изходящ dial-peer към IP PSTN дестинация шаблон BAD.BAD сесия протокол sipv2 сесия цел ipv4:198.18.133.3 гласов клас кодек 99 гласов клас sip наемател 100 dtmf-relay no rtp-n -peer voice 201 voip описание Изходяща точка за набиране към Webex Calling BAD.BAD протокол за сесия sipv2 целева сесия sip-сървър гласов клас кодек 99 гласов клас зашеметяване 200 без гласов клас sip sip наемател на гласов клас на локалния хост 200 dtmf-relay rtp-nte srtp no vad гласов клас dpg 100 описание Входящо WebexCalling(DP200) към IP PSTN(DP101) dial-peer 101 предпочитание 1 гласов клас dpg 200 описание Входящо IP PSTN(DP100) към Webex Calling-peer 201 предпочитание 1 dial-peer глас 100 voip описание входящо dial-peer от IP PSTN сесия протокол sipv2 дестинация dpg 200 входящ uri чрез 100 гласов клас кодек 99 гласов клас sip наемател 300 dtmf-relay no rtp din peer voice 200 voip описание Входяща точка за набиране от Webex Calling протокол сесия sipv2 дестинация dpg 100 входяща uri заявка 200 гласов клас кодек 99 гласов клас stun-usage 200 гласов клас sip наемател 200 dtmf-relay rtp-nte srtp no vad end копиране стартиране

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

2

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

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

покажете състоянието на регистъра на sip-ua 

 VCUBE-1# показване на група приложения за съкращаване 1 ИД на групата :1 Име на групата:LocalGateway-HA Административно състояние: Работно състояние на агрегата за изключване: нагоре Моята роля: В режим на готовност Роля на връстниците: АКТИВНО присъствие на партньори: Да Peer Comm: Да Започна напредъкът на партньорите: Yes RF Domain: btob-one RF state: STANDBY HOT Peer RF state: ACTIVE VCUBE-1#show sip-ua register status VCUBE-1#

 VCUBE-2#show redundancy application group 1 Group ID:1 Group Name:LocalGateway-HA Administrative State: No Shutdown Aggregate operational state : Up My Role: ACTIVE Peer Role: STATUS Peer Presence: Yes Peer Comm: Yes Peer Progression Started: Yes RF Domain: btob-one RF state: ACTIVE Peer RF state: STANDBY HOT VCUBE-2#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 48 yes normal VCUBE-2#

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

 VCUBE-1#debug ccsip non-call SIP Out-of-Dialog tracing is enabled VCUBE-1#debug ccsip info SIP Call info tracing is enabled VCUBE-1#debug ccsip message

4

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

 VCUBE-2#redundancy application reload group 1 self

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

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

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

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

5

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

 VCUBE-1#show sip-ua register status Tenant: 200 --------------------Registrar-Index  1 --------------------- Line peer expires(sec) reg survival P-Associ-URI ============================== ========== ============ === ======== ============ Hussain5091_LGU -1 56 yes normal VCUBE-1#

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

6

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

 VCUBE-1#show log Jan 9 18:37:24.769: %RG_MEDIA-3-TIMEREXPIRED: RG id 1 Hello Time Expired. Jan 9 18:37:24.771: %RG_PROTCOL-5-ROLECHANGE: RG id 1 role change from Standby to Active Jan 9 18:37:24.783: %VOICE_HA-2-SWITCHOVER_IND: SWITCHOVER, from STANDBY_HOT to ACTIVE state. Jan 9 18:37:24.783: //-1/xxxxxxxxxxxx/SIP/Info/info/4096/sip_ha_notify_active_role_event: Received notify active role event Jan 9 18:37:25.758: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: REGISTER sip: 40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK0374 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent: Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595044 CSeq: 2 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Content-Length: 0 

Jan 9 18:37:25.995: //-1/000000000000/SIP/Msg/ccsipDisplayMsg: Received: SIP/2.0 401 Unauthorized Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK0374;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1324701502-1578595045969 Date: Thu, 09 Jan 2020 18:37:24 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595044 CSeq: 2 REGISTER 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: Sent: REGISTER sip:40462196.cisco-bcld.com:5061 SIP/2.0 Via: SIP/2.0/TLS 198.18.1.228:5061;branch=z9hG4bK16DC From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com> Date: Thu, 09 Jan 2020 18:37:25 GMT Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 User-Agent:Cisco-SIPGateway/IOS-16.12.02 Max-Forwards: 70 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls> Expires: 240 Supported: path Authorization: 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 Content-Length: 0 

Jan 9 18:37:26.190: //1/000000000000/SIP/Msg/ccsipDisplayMsg:  Received: SIP/2.0 200 OK Via: SIP/2.0/TLS 198.18.1.228:5061;received=173.38.218.1;branch=z9hG4bK16DC;rport=4742 From: <sip:Hussain5091_LGU@40462196.cisco-bcld.com;otg=hussain1076_lgu>;tag=8D573-189 To: <sip:Hussain5091_LGU@40462196.cisco-bcld.com>;tag=SD1u8bd99-1897486570-1578595-46184 Call-ID: FFFFFFFFEA0684EF-324511EA-FFFFFFFF800281CD-FFFFFFFFB5F93B97 Timestamp: 1578595045 CSeq: 3 REGISTER Contact: <sip:Hussain5091_LGU@198.18.1.228:5061;transport=tls>;expires=120;q=0.5 Allow-Events: call-info,line-seize,dialog,message-summary,as-feature-event,x-broadworks-hoteling,x-broadworks-call-center-status,conference Content-Length: 0