В тази статия
Основи
Конфигурирайте излишъка и на двата CUBE
Внедрете CUBE с висока наличност като локален шлюз
list-menuВ тази статия
list-menuОбратна връзка?

Local Gateway (LGW) е изключителното решение за предоставяне на локален PSTN достъп на Cisco Webex Calling клиенти. Този документ ви насочва при конфигурирането на локален шлюз с помощта на CUBE с висока наличност, с активни или в режим на готовност CUBES, за да се гарантира състоянието на превключване на активните повиквания.

Основи

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

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

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

Local Gateway premises-based PSTN deployment

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

Webex Calling deployment without IP PBX

Излишаване от кутия към кутия от слой 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 багажника.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

Инфракомпонент на групата за съкращаване

Компонентът 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 адреси.

A typical CUBE HA setup as Local Gateway for a Cisco Webex Calling trunk deployment

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 group и договарянето на ролята след появата на интерфейса - по подразбиране 30 секунди. Обхватът е 0-10000 секунди

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

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

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

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

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

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

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

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

    • Задържане — интервалът между получаването на съобщение „Здравей“ и презумпцията, че изпращащият маршрутизатор е неуспешен. Тази продължителност трябва да бъде по-голяма от здраво време - по подразбиране 10 секунди. Обхватът е 750 милисекунди-255 секунди

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

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 — Конфигурира идентификатора на интерфейса за резервиране за групата за резервиране. Изисква се за генериране на виртуален MAC (VMAC) адрес. Същата стойност на rii ID трябва да се използва в интерфейса на всеки рутер (ACTIVE/STANDBY), който има един и същ VIP.

    Ако има повече от една B2B двойка в една и съща LAN, всяка двойка трябва да има уникални rii ID на съответните си интерфейси (за да се предотврати сблъсък). Командата Show redundancy Application group all трябва да показва правилната локална и партньорска информация.

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

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

5

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

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

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 последно и според съображенията на дизайна; платформата за последно презареждане винаги ще бъде в режим на готовност.


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#

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

Беше ли полезна тази статия?
Беше ли полезна тази статия?