У цій статті
Основи
Налаштуйте резервування на обох CUBEs
Реалізуйте високу доступність CUBE як локальний шлюз
list-menuУ цій статті
list-menuНадіслати відгук?

Локальний шлюз (LGW) - це ексклюзивне рішення для надання локального доступу PSTN клієнтам Cisco Webex Calling. Цей документ допоможе вам налаштувати локальний шлюз за допомогою високої доступності CUBE з активними або резервними CUBE для забезпечення стану відмови активних викликів.

Основи

передумови

Перш ніж розгор Cisco Unified Border Element тати (CUBE) високої доступності (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це пропозиція співпраці, яка надає багатоквартирну хмарну альтернативу локальній телефонній службі АТС з кількома параметрами PSTN для клієнтів.

Розгортання локального шлюзу (представлено нижче) є центром цієї статті. Локальний шлю з (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

Резервування коробки до коробки рівня 2 CUBE HA використовує протокол інфраструктури групи резервування (RG) для формування пари маршрутизаторів активного/резервного режиму. Ця пара поділяє ту саму віртуальну 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 магістралі.

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

Інфракомпонент групи резервування

Інфракомпонент групи резервування (RG) забезпечує підтримку інфраструктури зв'язку від коробки до коробки між двома CUBE та узгоджує остаточний стабільний стан резервування. Цей компонент також передбачає:

  • Протокол, подібний до HSRP, який узгоджує остаточний стан резервування для кожного маршрутизатора шляхом обміну повідомленнями keepalive та hello між двома 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 доступ до SBC, постачальник послуг або проксі, використовують VIP як цільову IP-адресу для дзвінків, що проходять через маршрутизатори CUBE HA. Отже, з Webex Calling точки зору, пари CUBE HA виступають як єдиний локальний шлюз.

Сигналізація викликів та інформація про сеанс RTP встановлених дзвінків перевіряються від активного маршрутизатора до маршрутизатора в режимі очікування. Коли активний маршрутизатор виходить з ладу, маршрутизатор Standby бере верх і продовжує пересилати потік RTP, який раніше був маршрутизований першим маршрутизатором.

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

Існують такі вимоги для використання CUBE HA як локального шлюзу для відмови від стану викликів:

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

  • Gig1 і Gig2 називаються інтерфейсами трафіку (SIP/RTP), а Gig3 - інтерфейс контролю/даних групи резервування (RG)

  • У одному домені рівня 2 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. Якщо налаштовувати 2 пари HA з однаковим ідентифікатором групи, інтерфейси RG Control/Data повинні належати до різних доменів рівня 2 (vlan, окремий комутатор)

  • Канал порту підтримується як для інтерфейсів керування RG/даних, так і трафіку

  • Усі сигнали/медіа надходять з/до віртуальної IP-адреси

  • Щоразу, коли платформа перезавантажується у відносині CUBE-HA, вона завжди завантажується як режим очікування

  • Нижня адреса для всіх інтерфейсів (Gig1, Gig2, Gig3) повинна знаходитися на одній платформі

  • Ідентифікатор інтерфейсу резервування, rii повинен бути унікальним для комбінації пари/інтерфейсу на тому ж рівні 2

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

  • Інтерфейси Loopback не можна використовувати як прив'язку, оскільки вони завжди ввімкнені

  • Багаторазові інтерфейси трафіку (SIP/RTP) (Gig1, Gig2) вимагають налаштування відстеження інтерфейсу

  • CUBE-HA не підтримується через перехресне кабельне з'єднання для зв'язку RG-Control/Data (Gig3)

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

  • Не можна припинити WAN безпосередньо на CUBEs або Data HA з обох сторін

  • Обидва активні/режим очікування повинні знаходитися в одному центрі обробки даних

  • Обов'язковим є використання окремого інтерфейсу L3 для резервування (RG Control/data, Gig3). тобто інтерфейс, який використовується для трафіку, не може бути використаний для зберігання HA та контрольних точок

  • При відмові раніше активний CUBE проходить перезавантаження за проектом, зберігаючи сигналізацію та носій

Налаштуйте резервування на обох CUBEs

Ви повинні налаштувати резервування рівня 2 від коробки до коробки на обох CUBEs, призначених для використання в парі 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)#

Ось пояснення полів, які використовуються в цій конфігурації:

  • резервування — пере ходить у режим резервування

  • резервування додатків —Входить у режим конфігурації резервування додатків

  • group —В ходить у режим конфігурації групи додатків резервування

  • назва локалГатевай-Ха — Визначає назву групи RG

  • пріоритет 100 поріг відмови 75 — Визначає початковий пріоритет і пороги відмови для RG

  • таймери затримки 30 перезавантаження 60 - Н алаштовує два рази для затримки та перезавантаження

    • Таймер затримки, який є кількістю часу для затримки ініціалізації групи RG та узгодження ролей після появи інтерфейсу - за замовчуванням 30 секунд. Діапазон становить 0-10000 секунд

    • Перезавантаження — це кількість часу для затримки ініціалізації групи RG та узгодження ролей після перезавантаження — за замовчуванням 60 секунд. Діапазон становить 0-10000 секунд

    • Рекомендуються таймери за замовчуванням, хоча ці таймери можуть бути налаштовані відповідно до будь-якої додаткової затримки конвергенції мережі, яка може виникнути під час завантаження/перезавантаження маршрутизаторів, щоб гарантувати, що узгодження протоколу RG відбувається після того, як маршрутизація в мережі зійшла до стабільної точки. Наприклад, якщо після відмови видно, що для нового STANDBY потрібно до 20 секунд, щоб побачити перший пакет RG HELLO з нового ACTIVE, то таймери слід налаштувати на «таймери затримки 60 перезавантаження 120», щоб врахувати цю затримку.

  • control GigabiteThernet3 протокол 1 - Налаштовує інтерфейс, який використовується для обміну повідомленнями keepalive та hello між двома CUBE, і визначає екземпляр протоколу, який буде приєднаний до інтерфейсу управління та переходить у режим конфігурації протоколу програми резервування

  • data GigabiteThernet3 — Налаштовує інтерфейс, який використовується для контрольного показу трафіку даних

  • трек —RG групове відстеження інтерфейсів

  • протокол 1 — Визначає екземпляр протоколу, який буде приєднаний до інтерфейсу керування, і переходить у режим конфігурації протоколу програми резервування

  • таймери hellotime 3 holdtime 10 - Налаштовує два таймери для часу очікування та часу очікування:

    • Hellotime— Інтервал між послідовними повідомленнями привітання - за замовчуванням 3 секунди. Діапазон 250 мілікунд-254 секунд

    • Час затримки - інтервал між отриманням повідомлення Hello та припущенням, що маршрутизатор відправлення не вдавався. Ця тривалість повинна бути більшою за час привітання — за замовчуванням 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 має використовуватися в інтерфейсі кожного маршрутизатора (ACTIVE/STANDBY), який має однаковий VIP.

    Якщо в одній локальній мережі існує більше однієї пари B2B, кожна пара ПОВИННА мати унікальні ідентифікат ори rii на відповідних інтерфейсах (щоб запобігти зіткненню). Коман да show redundancy group all повинна вказ увати правильну локальну та однорангову інформацію.

  • група резервування 1 — Пов'язує інтерфейс із гру пою резервування, створеною на кроці 2 вище. Налаштуйте групу RG, а також VIP, призначений для цього фізичного інтерфейсу.

    Обов'язковим є використання окремого інтерфейсу для резервування, тобто інтерфейс, який використовується для голосового трафіку, не може використовуватися як інтерфейс управління та передачі даних, зазначений у кроці 2 вище. У цьому прикладі гігабітний інтерфейс 3 використовується для контролю/даних RG

5

Збережіть конфігурацію першого CUBE і перезавантажте його.

Платформа для останнього перезавантаження - це завжди режим очікування.

VCUBE-1#wr
Building configuration...
[OK]
VCUBE-1#reload
Proceed with reload? [confirm]

Після повного завантаження VCUBE-1 збере жіть конфігурацію VCU BE-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#

Далі перейдіть до конфігурації Локального шлюзу (на основі реєстрації або на основі сертифікатів) на обох HA CUBE. Див. Настроювання локального шлю Cisco IOS зу на XE для Webex Calling.

Чи була ця стаття корисною?
Чи була ця стаття корисною?