- Головна
- /
- Стаття
Впровадити CUBE High Availability як локальний шлюз
Локальний шлюз (LGW) є ексклюзивним рішенням для надання доступу до локальної ТМЗК клієнтам Cisco Webex Calling. У цьому документі наведено вказівки щодо налаштування локального шлюзу за допомогою CUBE high availability з активними або резервними CUBE, щоб забезпечити аварійне перемикання активних викликів у стані.
Основи
Передумови
Перш ніж розгорнути Cisco Unified Border Element (CUBE) High Availability (HA) як локальний шлюз для Webex Calling, переконайтеся, що маєте глибоке розуміння наступних концепцій:
-
Рівень резервування від коробки до коробки з CUBE Enterprise для збереження викликів у стані
Настанови конфігурації, наведені в цій статті, передбачають використання виділеної платформи локального шлюзу без наявної конфігурації голосового зв’язку. Якщо наявне корпоративне розгортання 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 для різних платформ:
-
Серії Cisco ISR 4K і Cisco Catalyst 8K— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE)— https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Бажана архітектура Cisco для Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Огляд рішення Webex Calling
Cisco Webex Calling — це пропозиція для співпраці, яка надає хмарну альтернативу локальній службі телефонії PBX із кількома параметрами ТМЗК для клієнтів.
Розгортання локального шлюзу (представлено нижче) є основним завданням цієї статті. Транк локального шлюзу (територіальний ТМЗК) у Webex Calling дозволяє підключення до служби ТМЗК, що належить клієнту. Він також забезпечує підключення до локального розгортання IP PBX, наприклад Cisco Unified CM. Увесь зв’язок із хмарою та з неї захищено за допомогою транспорту TLS для SIP та SRTP для медіа.
На малюнку нижче відображено розгортання 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.
Інфракомпонент групи резервування
Компонент 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-адрес.
1 |
Налаштуйте відстеження інтерфейсу на глобальному рівні для відстеження стану інтерфейсу.
Трек CLI використовується в RG для відстеження стану голосового інтерфейсу трафіку, щоб активний маршрут вичерпав свою активну роль після того, як інтерфейс трафіку не працює. | ||
2 |
Налаштуйте RG для використання з VoIP HA в підрежимі резервування програми.
Ось пояснення полів, які використовуються в цій конфігурації:
| ||
3 |
Увімкніть резервування від box до box для програми CUBE. Налаштуйте RG на попередньому кроці під
група резервування 1—Щоб додати та видалити цю команду, необхідно перезавантажити оновлену конфігурацію. Платформи буде перезавантажено після застосування всієї конфігурації. | ||
4 |
Налаштуйте інтерфейси Gig1 та Gig2 з відповідними віртуальними IP-адресами, як показано нижче, і застосуйте ідентифікатор інтерфейсу резервування (rii).
Ось пояснення полів, які використовуються в цій конфігурації:
| ||
5 |
Збережіть конфігурацію першого CUBE і перезавантажте її. Платформа для перезавантаження останнього завжди є в режимі Очікування.
Після повного завантаження VCUBE-1 збережіть конфігурацію VCUBE-2 і перезавантажте її.
| ||
6 |
Переконайтеся, що конфігурація box-to-box працює як очікувалося. Відповідний вивід виділено жирним шрифтом. Ми перезавантажили VCUBE-2 останній і відповідно до вимог дизайну. Платформа для перезавантаження останній завжди буде в режимі очікування. Далі перейдіть до конфігурації локального шлюзу (на основі реєстрації або на основі сертифіката) на обох HA CUBE. Див. розділ Налаштування локального шлюзу в Cisco IOS XE для Webex Calling. |