Основи

Передумови

Перш ніж розгортати CUBE HA як локальний шлюз для Webex Calling, детально розгляньте наведені нижче концепції.

У рекомендаціях щодо конфігурації, наведених у цій статті, припущено, що виділена платформа локального шлюзу не має наявної конфігурації голосового зв’язку. У разі змінювання наявного корпоративного розгортання CUBE з метою використання функції локального шлюзу для Cisco Webex Calling зверніть особливу увагу на застосовану конфігурацію та упевніться, що наявні потоки викликів і функціональність не перериваються, а також переконайтеся в дотриманні вимог щодо проєктування CUBE HA.

Компоненти апаратного й програмного забезпечення

Щоб CUBE HA можна було використовувати як локальний шлюз, потрібна версія IOS-XE 16.12.2 або пізніша, а також платформа, на якій підтримуються функції CUBE HA і локального шлюзу.


 

Команди show й журнали в цій статті базуються на мінімальному випуску програмного забезпечення Cisco IOS-XE 16.12.2, впровадженого на vCUBE (CSR1000v).

Довідковий матеріал

Нижче наведено деякі докладні посібники з налаштування CUBE HA для різних платформ.

Огляд рішення Webex Calling

Cisco Webex Calling — це пропозиція для співпраці, яка надає для клієнтів альтернативне хмарне рішення з використанням кількох клієнтів до служби телефонії локальної внутрішньої мережі з кількома варіантами PSTN.

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

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

Резервування типу Box-to-Box другого рівня

У резервуванні типу Box-to-Box другого рівня CUBE HA для формування пари маршрутизаторів (активний/резервний) використовується протокол інфраструктури групи резервування (RG). Ця пара має одну й ту саму віртуальну IP-адресу (VIP) у своїх відповідних інтерфейсах і постійно обмінюється повідомленнями про стан. Інформація про сеанс CUBE контролюється в межах пари маршрутизаторів, що дозволяє резервному маршрутизатору негайно взяти на себе всі обов’язки щодо обробки викликів CUBE, якщо активний маршрутизатор виходить із ладу. Це призводить до збереження стану передавання сигналів і мультимедіа.


 

Контроль обмежується лише підключеними викликами з пакетами мультимедіа. Виклики, що знаходяться в проміжному стані (як-от стан спроби виклику або дзвінка), не контролюються.

У цій статті під CUBE HA буде матися на увазі CUBE високого рівня доступності (HA) з резервуванням типу Box-to-Box другого рівня для утримання викликів зі збереженням стану

Починаючи з IOS-XE версії 16.12.2 CUBE HA може бути розгорнуто як локальний шлюз для розгортання транку Cisco Webex Calling (PSTN на базі локальних ресурсів). У цій статті буде розглянуто проєктні умови й конфігурації. На цьому малюнку зображено типове налаштування CUBE HA як локального шлюзу для розгортання транку Cisco Webex Calling.

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

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

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

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

  • Налаштування та керування інтерфейсом віртуальних IP-адрес (VIP) для інтерфейсів трафіку (кілька інтерфейсів трафіку можна налаштувати за допомогою однієї групи резервування): GigabitEthernet 1 і 2 вважаються інтерфейсами трафіку.

Цей компонент групи резервування має бути спеціально налаштовано для підтримки B2B HA голосового зв’язку.

Керування віртуальними IP-адресами (VIP) для передавання сигналів і мультимедіа

B2B HA для досягнення резервування покладається на VIP. VIP й пов’язані фізичні інтерфейси на обох CUBE в парі CUBE HA повинні знаходитися в одній підмережі LAN. Конфігурація VIP й прив’язка інтерфейсу VIP до певної програми голосового зв’язку (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 можна розмістити не більше 2 пар CUBE HA, одна з ідентифікатором групи 1, а інша з ідентифікатором групи 2. У разі налаштування 2 пар HA з однаковим ідентифікатором групи інтерфейси керування RG / передавання даних повинні належати до різних доменів рівня 2 (VLAN, роздільний комутатор)

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

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

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

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

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

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

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

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

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

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

  • Не допускається переривання WAN безпосередньо в CUBE або HA даних з обох сторін

  • Як активний, так і резервний екземпляри мають знаходитися в одному центрі обробки даних

  • З метою запровадження резервування (керування RG / передавання даних, Gig3) використання окремого інтерфейсу L3 є обов’язковим. Тобто інтерфейс, який використовується для трафіку, не може бути використано для перевірки активності й контролю стану

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

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

Щоб використовувати віртуальні IP-адреси, необхідно налаштувати резервування типу Box-to-Box другого рівня на обох CUBE, призначених для використання в парі HA.

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 для використання з HA VoIP в межах підрежиму резервування програми.

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)#

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

  • redundancy—Enters redundancy mode

  • application redundancy—Enters application redundancy configuration mode

  • group—Enters redundancy application group configuration mode

  • name LocalGateway-HA—Defines the name of the RG group

  • priority 100 failover threshold 75—Specifies the initial priority and failover thresholds for an RG

  • timers delay 30 reload 60—Configures the two times for delay and reload

    • Таймер затримки (delay) — це час для затримки ініціалізації групи RG й узгодження ролей після увімкнення інтерфейсу. За замовчуванням встановлено 30 секунд. Діапазон: від 0 до 10 000 секунд.

    • Таймер перезавантаження (reload) — це час для затримки ініціалізації групи RG й узгодження ролей після перезавантаження. За замовчуванням встановлено 60 секунд. Діапазон: від 0 до 10 000 секунд.

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

  • control GigabitEthernet3 protocol 1—Configures the interface used to exchange keepalive and hello messages between the two CUBEs, and specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • data GigabitEthernet3—Configures the interface used for checkpointing of data traffic

  • track—RG group tracking of interfaces

  • protocol 1—Specifies the protocol instance that will be attached to a control interface and enters redundancy application protocol configuration mode

  • timers hellotime 3 holdtime 10—Configures the two timers for hellotime and holdtime:

    • Hellotime: інтервал між послідовними повідомленнями hello (за замовчуванням 3 секунди). Діапазон: від 250 мілісекунд до 254 секунд

    • Holdtime: інтервал між отриманням повідомлення hello й припущенням, що на маршрутизаторі, який надсилає повідомлення, сталася помилка. Ця тривалість повинна бути більшою, ніж hellotime. За замовчуванням 10 секунд. Діапазон: від 750 мілісекунд до 255 секунд

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

3

Увімкніть резервування типу Box-to-Box в обох програмах CUBE. Configure the RG from the previous step under 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—Adding and removing this command requires a reload for the updated configuration to take effect. Ми перезавантажимо платформи після застосування всієї конфігурації.

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—Configures the redundancy interface identifier for the redundancy group. Потрібен для створення віртуальної MAC-адреси (VMAC). В інтерфейсі кожного маршрутизатора (ACTIVE/STANDBY), який має однаковий VIP, має використовуватися однакове значення ідентифікатора rii.


     

    If there is more than one B2B pair on the same LAN, each pair MUST have unique rii IDs on their respective interfaces (to prevent collision). ‘show redundancy application group all’ should indicate the correct local and peer information.

  • redundancy group 1—Associates the interface with the redundancy group created in Step 2 above. Налаштуйте групу 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 останньою (відповідно до проєктних умов). Платформа, яку було перезавантажено останньою, завжди буде знаходитися в режимі 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#

Налаштування локального шлюзу на обох CUBE

У нашому прикладі конфігурації використовується наведена нижче інформація про транк, отримана від Control Hub, для створення конфігурації локального шлюзу на обох платформах (VCUBE-1 й VCUBE-2). Ім’я користувача й пароль для цього налаштування наведено нижче.

  • Ім’я користувача: Hussain1076_LGU

  • Пароль: lOV12MEaZx

1

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

 LocalGateway#conf t LocalGateway(config)#key config-key password-encrypt Password123 LocalGateway(config)#password encryption aes

Нижче наведено конфігурацію локального шлюзу, яку буде застосовано до обох платформ на основі вказаних вище параметрів Control Hub. Збережіть її та виконайте перезавантаження. SIP Digest credentials from Control Hub are highlighted in bold.

 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 url http://www.cisco.com/security/pki/trs/ios_core.p7b end configure terminal voice service voip ip address trusted list ipv4 x.x.x.x y.y.y.y exit allow-connections sip to sip media statistics media bulk-stats no supplementary-service sip refer no supplementary-service sip handle-replaces fax protocol pass-through g711ulaw stun stun flowdata agent-id 1 boot-count 4 stun flowdata shared-secret 0 Password123! sip g729 annexb-all early-offer forced end configure terminal voice class sip-profiles 200 rule 9 request ANY sip-header SIP-Req-URI modify "sips:(.*)" "sip:\1" rule 10 request ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 11 request ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 12 request ANY sip-header Contact modify "<sips:(.*)>" "<sip:\1;transport=tls>" rule 13 response ANY sip-header To modify "<sips:(.*)" "<sip:\1" rule 14 response ANY sip-header From modify "<sips:(.*)" "<sip:\1" rule 15 response ANY sip-header Contact modify "<sips:(.*)" "<sip:\1" rule 20 request ANY sip-header From modify ">" ";otg=hussain1076_lgu>" rule 30 request ANY sip-header P-Asserted-Identity modify "sips:(.*)" "sip:\1" voice class codec 99 codec preference 1 g711ulaw codec preference 2 g711ulaw exit voice class srtp-crypto 200 crypto 1 AES_CM_128_HMAC_SHA1_80 exit voice class stun-usage 200 stun usage firewall-traversal flowdata exit voice class tenant 200 registrar dns:40462196.cisco-bcld.com scheme sips expires 240 refresh-ratio 50 tcp tls credentials number Hussain5091_LGU username Hussain1076_LGU password 0 lOV12MEaZx realm Broadworks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm BroadWorks authentication username Hussain5091_LGU password 0 lOV12MEaZx realm 40462196.cisco-bcld.com no remote-party-id sip-server dns:40462196.cisco-bcld.com connection-reuse srtp-crypto 200 session transport tcp tls url sips error-passthru asserted-id pai bind control source-interface GigabitEthernet1 bind media source-interface GigabitEthernet1 no pass-thru content custom-sdp sip-profiles 200 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com privacy-policy passthru voice class tenant 100 session transport udp url sip error-passthru bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class tenant 300 bind control source-interface GigabitEthernet2 bind media source-interface GigabitEthernet2 no pass-thru content custom-sdp voice class uri 100 sip host ipv4:198.18.133.3 voice class uri 200 sip pattern dtg=hussain1076.lgu dial-peer voice 101 voip description Outgoing dial-peer to IP PSTN destination-pattern BAD.BAD session protocol sipv2 session target ipv4:198.18.133.3 voice-class codec 99 voice-class sip tenant 100 dtmf-relay rtp-nte no vad dial-peer voice 201 voip description Outgoing dial-peer to Webex Calling destination-pattern BAD.BAD session protocol sipv2 session target sip-server voice-class codec 99 voice-class stun-usage 200 no voice-class sip localhost voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad voice class dpg 100 description Incoming WebexCalling(DP200) to IP PSTN(DP101) dial-peer 101 preference 1 voice class dpg 200 description Incoming IP PSTN(DP100) to Webex Calling(DP201) dial-peer 201 preference 1 dial-peer voice 100 voip desription Incoming dial-peer from IP PSTN session protocol sipv2 destination dpg 200 incoming uri via 100 voice-class codec 99 voice-class sip tenant 300 dtmf-relay rtp-nte no vad dial-peer voice 200 voip description Incoming dial-peer from Webex Calling session protocol sipv2 destination dpg 100 incoming uri request 200 voice-class codec 99 voice-class stun-usage 200 voice-class sip tenant 200 dtmf-relay rtp-nte srtp no vad end copy run start

Щоб відобразити дані виводу команди show, перезавантажено VCUBE-2, а потім VCUBE-1. Після цього VCUBE-1 стає резервною платформою CUBE, а VCUBE-2 активною платформою CUBE

2

У будь-який окремий момент часу тільки одна платформа буде підтримувати активну реєстрацію як локальний шлюз із SBC доступу Webex Calling. Перегляньте дані виводу наведених нижче команд show.

show redundancy application group 1

show sip-ua register status 

 VCUBE-1#show redundancy application group 1 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: 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

Виконайте імітацію аварійного перемикання: введіть наведену нижче команду на активному локальному шлюзі, у цьому випадку на VCUBE-2.

 VCUBE-2#redundancy application reload group 1 self

Перемикання з локального шлюзу в стані ACTIVE (АКТИВНИЙ) на локальний шлюз у стані STANDBY (РЕЗЕРВНИЙ) відбувається за наведеним далі сценарієм, а також окрім CLI, що наведено вище

  • Коли АКТИВНИЙ маршрутизатор перезавантажується

  • Під час вимкнення/увімкнення живлення АКТИВНОГО маршрутизатора

  • Коли вимикається будь-який налаштований інтерфейс RG АКТИВНОГО маршрутизатора, для якого ввімкнено відстеження

5

Перевірте реєстрацію VCUBE-1 у SBC доступу Webex Calling. 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 наразі є активним локальним шлюзом.

6

Перегляньте відповідний журнал налагодження у VCUBE-1, який надсилає повідомлення SIP REGISTER до Webex Calling ЧЕРЕЗ віртуальну 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