- Головна
- /
- Стаття
Локальний шлюз (LGW) - це ексклюзивне рішення для надання локального доступу PSTN клієнтам Cisco Webex Calling. Цей документ допоможе вам налаштувати локальний шлюз за допомогою високої доступності CUBE з активними або резервними CUBE для забезпечення стану відмови активних викликів.
Основи
передумови
Перш ніж розгор Cisco Unified Border Element тати (CUBE) високої доступності (HA) як локального шлю Webex Calling зу для, переконайтеся, що ви добре розумієте наступні концепції:
-
Резервування 2-го рівня від коробки до коробки за допомогою 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 для 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це пропозиція співпраці, яка надає багатоквартирну хмарну альтернативу локальній телефонній службі АТС з кількома параметрами PSTN для клієнтів.
Розгортання локального шлюзу (представлено нижче) є центром цієї статті. Локальний шлю з (PSTN на базі приміщень) Webex Calling забезпечує підключення до служби PSTN, що належить клієнту. Він також забезпечує підключення до локальної розгортання IP АТС, наприклад. Cisco Unified CM Весь зв'язок до хмари та з неї захищений за допомогою транспорту TLS для SIP та SRTP для медіа.
На малюнку нижче показано Webex Calling розгортання без будь-якої існуючої IP АТС і застосовується до розгортання на одному або декількох сайтах. Конфігурація, описана в цій статті, базується на цьому розгортанні.
Надмірність коробки до коробки рівня 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 магістралі.
Інфракомпонент групи резервування
Інфракомпонент групи резервування (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-адрес.
| 1 |
Налаштуйте відстеження інтерфейсу на глобальному рівні для відстеження стану інтерфейсу.
Track CLI використовується в RG для відстеження стану інтерфейсу голосового трафіку, так що активний маршрут відіграє свою активну роль після завершення роботи інтерфейсу трафіку. | ||
| 2 |
Налаштуйте RG для використання з VoIP HA в підрежимі резервування додатків.
Ось пояснення полів, які використовуються в цій конфігурації:
| ||
| 3 |
Увімкнути резервування коробки до коробки для програми CUBE. Налаштуйте RG з попереднього кроку нижче.
redundancy-group 1 — Додавання та видалення цієї команди вимагає перезавантаження, щоб оновлена конфігурація набула чинності. Ми перезавантажимо платформи після того, як буде застосовано всю конфігурацію. | ||
| 4 |
Налаштуйте інтерфейси Gig1 та Gig2 з відповідними віртуальними IP-адресами, як показано нижче, та застосуйте ідентифікатор інтерфейсу резервування (rii)
Ось пояснення полів, які використовуються в цій конфігурації:
| ||
| 5 |
Збережіть конфігурацію першого CUBE і перезавантажте його. Платформа для останнього перезавантаження - це завжди режим очікування.
Після повного завантаження VCUBE-1 збере жіть конфігурацію VCU BE-2 і перезавантажте її.
| ||
| 6 |
Переконайтеся, що конфігурація від коробки до коробки працює належним чином. Відповідний результат виділений жирним ш рифтом. Ми перезавантажили VCUBE-2 останнім і відповідно до міркувань дизайну; платформа для останнього перезавантаження завжди буде в режимі очікування.
Далі перейдіть до конфігурації Локального шлюзу (на основі реєстрації або на основі сертифікатів) на обох HA CUBE. Див. Настроювання локального шлю Cisco IOS зу на XE для Webex Calling. |