Основи

Передумови

Перш ніж розгорнути 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 із кількома параметрами ТМЗК для клієнтів.

Розгортання локального шлюзу (представлено нижче) є основним завданням цієї статті. Транк локального шлюзу (територіальний ТМЗК) у Webex Calling дозволяє підключення до служби ТМЗК, що належить клієнту. Він також забезпечує підключення до локального розгортання IP PBX, наприклад Cisco Unified CM. Увесь зв’язок із хмарою та з неї захищено за допомогою транспорту TLS для SIP та SRTP для медіа.

Розгортання ТМЗК на базі локального шлюзу

На малюнку нижче відображено розгортання Webex Calling без наявних IP PBX і застосовується до окремого або багатосайтового розгортання. Конфігурація, описана в цій статті, базується на цьому розгортанні.

Розгортання Webex Calling без IP PBX

Резервування від коробки до коробки 2

CUBE HA layer 2 box-to-box redundancy використовує протокол інфраструктури групи резервування (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 (територіальний ТМЗК). У цій статті обговорюватимуться проектні міркування та конфігурації. На рисунку відображено типове налаштування CUBE HA як локальний шлюз для розгортання транка Cisco Webex Calling.

Типове налаштування CUBE HA як локальний шлюз для розгортання транка Cisco Webex Calling

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

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

  • Протокол, подібний до HSRP, який узгоджує кінцевий стан резервування для кожного маршрутизатора, обмінюючись повідомленнями "keepalive" та "привітання" між двома CUBE (через інтерфейс керування) — GigabitEthernet3 на малюнку вище.

  • Транспортний механізм для перевірки сигнального та медіастану для кожного виклику від активного до резервного маршрутизатора (через інтерфейс даних) — GigabitEthernet3 на малюнку вище.

  • Конфігурація та керування віртуальним 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 встановлених викликів перевіряються від активного маршрутизатора до маршрутизатора в режимі очікування. Коли активний маршрутизатор спускається, маршрутизатор у режимі очікування переходить і продовжує переадресовувати потік RTP, який раніше був маршрутизований першим маршрутизатором.

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

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

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

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

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

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

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

  • У будь-який час перезавантаження платформи в стосунках CUBE-HA вона завжди завантажується як В режимі очікування.

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

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

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

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

  • Для кількох інтерфейсів трафіку (SIP/RTP) (Gig1, Gig2) потрібно налаштувати відстеження інтерфейсу.

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

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

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

  • Обидва активні/очікування мають бути в одному центрі обробки даних

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

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

Налаштувати резервування на обох 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

Трек 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—Перейде в режим конфігурації групи програм резервування

  • ім’я LocalGateway-HA — визначає ім’я групи RG

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

  • Затримка таймерів 30 перезавантажити 60— Налаштування затримки й перезавантаження двічі

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

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

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

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

  • дані GigabitEthernet3 — налаштування інтерфейсу, що використовується для перевірки трафіку даних

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

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

  • таймери hellotime 3 holdtime 10—Налаштуйте два таймери для hellotime і holdtime:

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

    • Holdtime — інтервал між отриманням повідомлення «Привітання» та презумпцією помилки маршрутизатора. Ця тривалість має бути більшою за час вітання – за замовчуванням 10 секунд. Діапазон становить 750 мілісекунд–255 секунд

      Рекомендовано налаштувати таймер очікування, щоб він був принаймні у 3 рази більшим за значення таймера робочого часу.

3

Увімкніть резервування від box до box для програми 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

група резервування 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 необхідно використовувати в інтерфейсі кожного маршрутизатора (АКТИВНИЙ/ОЧІКУВАННЯ), який має такий самий VIP-код.

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

  • група резервування 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

Переконайтеся, що конфігурація box-to-box працює як очікувалося. Відповідний вивід виділено жирним шрифтом.

Ми перезавантажили 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.