Основни принципи

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

Преди да разположите Cisco Unified Border Element (CUBE) High Availability (HA) като локален шлюз за Webex Calling, се уверете, че имате задълбочено разбиране на следните понятия:

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

Общ преглед на решението за Webex Calling

Cisco Webex Calling е предложение за сътрудничество, което предоставя базирана на облака с множество клиенти алтернатива на локалната PBX телефонна услуга с множество опции за PSTN за клиентите.

Внедряването на локални шлюзове (представено по-долу) е във фокуса на тази статия. Съединителната линия на локалния шлюз (локално базирана PSTN) в Webex Calling позволява свързване към PSTN услуга, притежавана от клиента. Той също така осигурява свързаност към локално разполагане на IP PBX, като например Cisco Unified CM. Цялата комуникация към и от облака е защитена при използване на TLS транспорт за SIP и SRTP за мултимедия.

Локално разполагане на PSTN с локален шлюз

Фигурата по-долу показва разполагане на Webex Calling без съществуваща IP PBX и е приложима за разполагане на един сайт или множество сайтове. Конфигурацията, описана в тази статия, се основава на това разполагане.

Внедряване на Webex Calling без IP PBX

Излишък от кутия към кутия 2

CUBE HA слой 2 кутия към кутия резерв използва инфраструктурния протокол Redundancy Group (RG), за да формира активна/standby двойка маршрутизатори. Тази двойка споделя един и същ виртуален IP адрес (VIP) в съответните си интерфейси и непрекъснато обменя съобщения за статус. Информацията за сесията на CUBE е с отметка в двойката от рутери, които позволяват на рутера в режим на готовност да поеме незабавно всички отговорности за обработка на повиквания CUBE, ако активният рутер излезе от експлоатация, което води до статично запазване на сигнализацията и мултимедията.

Отметката от посочването е ограничена до свързани повиквания с мултимедийни пакети. Транзитните повиквания не са отметнати (например състояние, при което се опитва или звъни).

В тази статия CUBE HA ще се отнася до CUBE High Availability (HA) Layer 2 Box-to-Box (B2B) резерв за статично запазване на повикванията.

От IOS-XE 17.9.1, CUBE HA може да бъде разгърнат като локален шлюз за разполагания на съединителни линии на Cisco Webex Calling (локално базирана PSTN). Тази статия ще обсъди дизайнерски съображения и конфигурации. Фигурата показва типична настройка на CUBE HA като локален шлюз за разполагане на съединителна линия на Cisco Webex Calling.

Типична настройка на CUBE HA като локален шлюз за разполагане на съединителна линия на Cisco Webex Calling

Компонент за група за резерв в infra

Компонентът Redundancy Group (RG) Infra осигурява поддръжка на комуникационната инфраструктура „от кутия до кутия“ между двата КУБ и договаря окончателното стабилно състояние на redundancy. Този компонент осигурява също:

  • HSRP-подобен протокол, който договаря окончателното състояние на излишък за всеки маршрутизатор чрез обмен на поддържани и поздрави съобщения между двата CUBE (чрез контролния интерфейс)—GigabitEthernet3 на фигурата по-горе.

  • Транспортен механизъм за проверка на състоянието на сигнализацията и мултимедията за всяко повикване от активния към режима на готовност маршрутизатор (чрез интерфейса за данни) – GigabitEthernet3 на фигурата по-горе.

  • Конфигуриране и управление на виртуалния IP (VIP) интерфейс за интерфейсите за трафик (няколко интерфейса за трафик могат да бъдат конфигурирани чрез една и съща RG група) – GigabitEthernet 1 и 2 се считат за пътни интерфейси.

Този RG компонент трябва да бъде специално конфигуриран да поддържа глас B2B HA.

Управление на виртуални IP (VIP) адреси както за сигнализация, така и за мултимедия

B2B HA разчита на ВИП, за да постигне излишък. ВИП и свързаните с тях физически интерфейси на двата CUBE в двойката CUBE HA трябва да пребивават на една и съща LAN подмрежа. Конфигурирането на ВИП и обвързването на ВИП интерфейса към конкретно гласово приложение (SIP) са задължителни за гласова поддръжка на B2B HA. Външни устройства, като Unified CM, SBC за достъп до Webex Calling, доставчик на услуги или прокси, използват VIP като целеви IP адрес за повикванията, преминаващи през маршрутизаторите CUBE HA. Следователно, от гледна точка на Webex Calling сдвояването на CUBE HA работи като един локален шлюз.

Информацията за сигнализиране на повикванията и RTP сесията на установените повиквания се проверява от активния маршрутизатор към маршрутизатора в режим на готовност. Когато активният рутер падне, рутерът в режим на готовност поема и продължава да пренасочва потока RTP, който преди това е бил маршрутизиран от първия рутер.

Повикванията в преходно състояние по време на превключване при отказ няма да се запазват след превключването. Например повиквания, които все още не са напълно установени или са в процес на модифициране с функция за прехвърляне или задържане. Възможно е установените повиквания да бъдат прекъснати след превключването.

Съществуват следните изисквания за използването на CUBE HA като локален шлюз за статично преместване на повиквания:

  • CUBE HA не може да има едновременно разположени TDM или аналогови интерфейси

  • Gig1 и Gig2 се наричат интерфейси за трафик (SIP/RTP), а Gig3 е интерфейс за управление/данни на група за резерв (RG)

  • Не повече от 2 двойки CUBE HA могат да бъдат поставени в един и същ домейн от слой 2, една с ИД на група 1, а другият с ИД на група 2. Ако конфигурирането на 2 HA сдвои с един и същ идентификатор на група, интерфейсите за RG контрол/данни трябва да принадлежат към различни домейни от слой 2 (vlan, отделен превключвател)

  • Портовият канал се поддържа както за интерфейси за управление/данни, така и за интерфейси за трафик

  • Всички сигнали/мултимедия се получават от/към виртуалния IP адрес

  • Всеки път, когато една платформа се презареди в отношения CUBE-HA, тя винаги се зарежда като Standby

  • По-ниският адрес за всички интерфейси (Gig1, Gig2, Gig3) трябва да бъде на една и съща платформа

  • Redundancy Interface Identifier, rii трябва да бъде уникален за двойка/интерфейс комбинация на същия слой 2

  • Конфигурацията и на двата CUBE трябва да бъде идентична, включително физическа конфигурация и трябва да се изпълнява на един и същ тип платформа и версия IOS-XE

  • Интерфейсите за обратна връзка не могат да се използват като свързващи, тъй като винаги са обърнати

  • Много интерфейси за трафик (SIP/RTP) (Gig1, Gig2) изискват конфигуриране на проследяване на интерфейси

  • CUBE-HA не се поддържа през кръстосана кабелна връзка за RG-контрол/връзка за данни (Gig3)

  • И двете платформи трябва да бъдат идентични и да бъдат свързани чрез физически превключвател във всички еднакво интерфейси, за да работи CUBE HA, т.е. GE0/0/0 на CUBE-1 и CUBE-2 трябва да завършат на един и същ превключвател и т.н.

  • Не може да има прекратяване на WAN на CUBE директно или Data HA от двете страни

  • И двете активни/в режим на готовност трябва да са в един и същ център за данни

  • Задължително е да се използва отделен L3 интерфейс за резервиране (RG контрол/данни, Gig3). т.е. интерфейсът, използван за трафик, не може да се използва за поддържане на HA и посочване на отметки

  • При отказ предишният активен КУБ преминава през презареждане по дизайн, запазвайки сигнализацията и мултимедията

Конфигуриране на резервиране и на двата CUBE

Трябва да конфигурирате резерв от слой 2 кутия към кутия и на двата CUBE, предназначени да се използват в двойка HA, за да изведат виртуални IP адреси.

Типична настройка на CUBE HA като локален шлюз за разполагане на съединителна линия на Cisco Webex Calling

1

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

conf t
 track 1 interface GigabitEthernet1 line-protocol
 track 2 interface GigabitEthernet2 line-protocol
 exit


VCUBE-1#conf t

VCUBE-1(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-1(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-1(config-track)#exit

VCUBE-2#conf t

VCUBE-2(config)#track 1 interface GigabitEthernet1 line-protocol

VCUBE-2(config-track)#track 2 interface GigabitEthernet2 line-protocol

VCUBE-2(config-track)#exit

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

2

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

redundancy
  application redundancy
   group 1
    name LocalGateway-HA
    priority 100 failover threshold 75
    control GigabitEthernet3 protocol 1
    data GigabitEthernet3
    timers delay 30 reload 60
    track 1 shutdown
    track 2 shutdown
    exit
   protocol 1
    timers hellotime 3 holdtime 10
   exit
  exit
 exit


VCUBE-1(config)#redundancy

VCUBE-1(config-red)#application redundancy

VCUBE-1(config-red-app)#group 1

VCUBE-1(config-red-app-grp)#name LocalGateway-HA

VCUBE-1(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-1(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-1(config-red-app-grp)#timers delay 30 reload 60

VCUBE-1(config-red-app-grp)#track 1 shutdown

VCUBE-1(config-red-app-grp)#track 2 shutdown

VCUBE-1(config-red-app-grp)#exit

VCUBE-1(config-red-app)#protocol 1

VCUBE-1(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-1(config-red-app-prtcl)#exit

VCUBE-1(config-red-app)#exit

VCUBE-1(config-red)#exit

VCUBE-1(config)#

VCUBE-2(config)#redundancy

VCUBE-2(config-red)#application redundancy

VCUBE-2(config-red-app)#group 1

VCUBE-2(config-red-app-grp)#name LocalGateway-HA

VCUBE-2(config-red-app-grp)#priority 100 failover threshold 75

VCUBE-2(config-red-app-grp)#control GigabitEthernet3 protocol 1

VCUBE-1(config-red-app-grp)#data GigabitEthernet3

VCUBE-2(config-red-app-grp)#timers delay 30 reload 60

VCUBE-2(config-red-app-grp)#track 1 shutdown

VCUBE-2(config-red-app-grp)#track 2 shutdown

VCUBE-2(config-red-app-grp)#exit

VCUBE-2(config-red-app)#protocol 1

VCUBE-2(config-red-app-prtcl)#timers hellotime 3 holdtime 10

VCUBE-2(config-red-app-prtcl)#exit

VCUBE-2(config-red-app)#exit

VCUBE-2(config-red)#exit

VCUBE-2(config)#

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3

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

voice service voip
   redundancy-group 1
   exit

VCUBE-1(config)#voice service voip

VCUBE-1(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-1(config-voi-serv)# exit

VCUBE-2(config)#voice service voip

VCUBE-2(config-voi-serv)#redundancy-group 1


                        % Created RG 1 association with Voice B2B HA; reload the router for the new configuration to take effect
                      

VCUBE-2(config-voi-serv)# exit

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

4

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

VCUBE-1(config)#interface GigabitEthernet1

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

VCUBE-1(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-1(config)#

VCUBE-1(config)#interface GigabitEthernet2

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

VCUBE-1(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-1(config-if)# exit

VCUBE-2(config)#interface GigabitEthernet1

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

VCUBE-2(config-if)# redundancy group 1 ip 198.18.1.228 exclusive

VCUBE-2(config-if)# exit

VCUBE-2(config)#

VCUBE-2(config)#interface GigabitEthernet2

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

VCUBE-2(config-if)# redundancy group 1 ip 198.18.133.228 exclusive

VCUBE-v(config-if)# exit

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

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

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

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

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

5

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

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

VCUBE-1#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-1#reload


                        Proceed with reload? [confirm]

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

VCUBE-2#wr


                        Building configuration...
                      


                        [OK]
                      

VCUBE-2#reload


                        Proceed with reload? [confirm]

6

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

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


VCUBE-1#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: ACTIVE
Peer Role: STANDBY
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: Local
        Standby Peer: address 10.1.1.2, priority 100, intf Gi3
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-1#

VCUBE-2#show redundancy application group all
Faults states Group 1 info:
       Runtime priority: [100]
               RG Faults RG State: Up.
                       Total # of switchovers due to faults:           0
                       Total # of down/up state changes due to faults: 0
Group ID:1
Group Name:LocalGateway-HA
  
Administrative State: No Shutdown
Aggregate operational state: Up
My Role: STANDBY
Peer Role: ACTIVE
Peer Presence: Yes
Peer Comm: Yes
Peer Progression Started: Yes

RF Domain: btob-one
         RF state: ACTIVE
         Peer RF state: STANDBY HOT

RG Protocol RG 1
------------------
        Role: Active
        Negotiation: Enabled
        Priority: 100
        Protocol state: Active
        Ctrl Intf(s) state: Up
        Active Peer: address 10.1.1.2, priority 100, intf Gi3
        Standby Peer: Local
        Log counters:
                role change to active: 1
                role change to standby: 1
                disable events: rg down state 0, rg shut 0
                ctrl intf events: up 1, down 0, admin_down 0
                reload events: local request 0, peer request 0

RG Media Context for RG 1
--------------------------
        Ctx State: Active
        Protocol ID: 1
        Media type: Default
        Control Interface: GigabitEthernet3
        Current Hello timer: 3000
        Configured Hello timer: 3000, Hold timer: 10000
        Peer Hello timer: 3000, Peer Hold timer: 10000
        Stats:
            Pkts 1509, Bytes 93558, HA Seq 0, Seq Number 1509, Pkt Loss 0
            Authentication not configured
            Authentication Failure: 0
            Reload Peer: TX 0, RX 0
            Resign: TX 0, RX 0
    Standy Peer: Present. Hold Timer: 10000
            Pkts 61, Bytes 2074, HA Seq 0, Seq Number 69, Pkt Loss 0

VCUBE-2#

След това продължете с конфигурацията на локалния шлюз (базирана на регистрация или базирана на сертификат) и на двата HA CUBE. Вижте Конфигуриране на локален шлюз в Cisco IOS XE за Webex Calling.