Налаштування локального шлюзу в Cisco IOS XE для Webex Calling
Після настроювання Webex Calling для своєї організації можна настроїти магістральне підключення локального шлюзу до служби Webex Calling. Транспорт SIP TLS захищає багажник між місцевим шлюзом і хмарою Webex. Засоби масової інформації між локальним шлюзом і дзвінком Webex використовують SRTP.
Огляд
Зараз Webex Calling підтримує дві версії локального шлюзу:
-
Локальний шлюз
-
Локальний шлюз для Webex для державних установ
-
Перш ніж почати, ознайомтеся з вимогами до локальної комутованої телефонної мережі загального користування (ТМЗК) і локального шлюзу (LGW) для Webex Calling. Дивіться Бажана архітектура Cisco для Webex Закликаючи до отримання додаткової інформації.
-
У цій статті припускається, що існує спеціальна платформа локального шлюзу без існуючої конфігурації голосу. Якщо ви змінюєте наявний шлюз ТМЗК або розгортання CUBE Enterprise, щоб використовувати його як функцію локального шлюзу для Webex Calling, зверніть увагу на конфігурацію. Переконайтеся, що ви не переривали наявні потоки викликів і функції через внесені вами зміни.
Інформацію про підтримувані сторонні SBC див. у відповідній довідковій документації продукту.
Існує два варіанти настроювання локального шлюзу для вашого транка Webex Calling :
-
Реєстрація на основі багажника
-
Магістраль на основі сертифікатів
Використовуйте потік завдань або під Локальний шлюз на основі реєстрації або Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling.
Див Почніть роботу з локальним шлюзом для отримання додаткової інформації про різні типи транків. Виконайте наступні дії на самому локальному шлюзі, використовуючи інтерфейс командного рядка (CLI). Ми використовуємо протокол ініціації сеансу (SIP) і транспортування безпеки транспортного рівня (TLS) для захисту транка, а протокол Secure Real Time Protocol (SRTP) для захисту медіа між локальним шлюзом і Webex Calling.
-
Виберіть CUBE як локальний шлюз. Webex для державних установ наразі не підтримує сторонні контролери кордону сеансів (SBC). Щоб переглянути останній список, див Почніть роботу з локальним шлюзом .
- Установіть Cisco IOS XE Dublin 17.12.1a або пізнішої версії для всіх локальних шлюзів Webex для державних установ.
-
Щоб переглянути список кореневих центрів сертифікації (CA), які підтримує Webex for Government, див Кореневі центри сертифікатів для Webex для державних установ .
-
Докладніше про діапазони зовнішніх портів для локального шлюзу у Webex для державних установ див Вимоги до мережі для Webex for Government (FedRAMP) .
Локальний шлюз для Webex для державних установ не підтримує такі можливості:
-
STUN/ICE-Lite для оптимізації шляху медіа
-
Факс (T.38)
Щоб налаштувати локальний шлюз для транка Webex Calling у Webex для державних установ, використовуйте такий параметр:
-
Магістраль на основі сертифікатів
Використовуйте потік завдань у розділі Локальний шлюз на основі сертифікатів щоб налаштувати локальний шлюз для транка Webex Calling. Докладніше про налаштування локального шлюзу на основі сертифіката див Налаштуйте транк Webex Calling на основі сертифіката .
Обов’язково потрібно налаштувати шифри GCM, що відповідають вимогам FIPS, для підтримки локального шлюзу для Webex для державних установ. Якщо ні, налаштування виклику не вдасться. Детальнішу інформацію про конфігурацію див Налаштуйте транк Webex Calling на основі сертифіката .
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling, використовуючи реєстраційний SIP-транк. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На зображенні нижче показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
-
клієнти голосового класу: Використовується для створення конкретних конфігурацій транка.
-
URI класу голосу: Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
-
вхідний вузол набору: Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
-
група абонентів: Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
-
вихідний вузол набору: Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Хоча IP і SIP стали протоколами за замовчуванням для транків ТМЗК, канали ISDN TDM (мультиплексування з часовим розділенням) все ще широко використовуються і підтримуються транками Webex Calling. Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати процес маршрутизації викликів із двох етапів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх вузлів набору з зворотним циклом між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
-
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
-
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
-
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
-
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
-
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
-
Для всіх розгортань локального шлюзу на основі реєстрації потрібні Cisco IOS XE 17.6.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
-
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Advantage. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
-
-
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
-
NTP
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа для Webex Calling має використовувати адресу IPv4.
-
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1 |
Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
|
| 2 |
Захистіть облікові дані реєстрації та STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче.
|
| 3 |
Створіть точку довіри PKI-заповнювач. Ця точка довіри вимагає, щоб пізніше налаштувати TLS. Для транків на основі реєстрації ця точка довіри не вимагає сертифіката, як це потрібно для транка на основі сертифіката. |
| 4 |
Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою наведених далі команд конфігурації. Параметри транспортування також слід оновити, щоб забезпечити надійне безпечне з’єднання для реєстрації: Команда сервера cn-san-validate гарантує, що локальний шлюз дозволить підключення, якщо ім’я хоста, налаштованого в осередку 200, включено в поля CN або SAN сертифіката, отриманого від вихідного проксі-сервера.
|
| 5 |
Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA: ip http клієнт проксі-сервер вашproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі реєстрації для наявного розташування в Control Hub. Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику. Додаткову інформацію див Налаштуйте транки, групи маршрутів і абонентські групи для Webex Calling .  |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. статистику медіаЗабезпечує моніторинг медіафайлів на локальному шлюзі. медіа bulk-statsДозволяє площині управління опитувати площину даних для статистики масових викликів. Додаткову інформацію про ці команди див Медіа . дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP back-to-back. Додаткову інформацію див Дозволити підключення . За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) . Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Додаткову інформацію про цю команду див асиметричне корисне навантаження . вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Додаткову інформацію про цю команду див рання пропозиція . |
| 3 |
Налаштувати кодек голосового класу 100 фільтр для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див кодек голосового класу . Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації. |
| 4 |
Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. Ось пояснення полів для конфігурації: оглушення використання ice liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Додаткову інформацію див використання оглушення класу голосу і оглушення використання ice lite . Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC |
| 5 |
Налаштуйте політику шифрування медіа для трафіку Webex. Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_ 80. Додаткову інформацію див голосовий клас srtp-crypto . |
| 6 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі параметра транка призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте dtg=, а потім значення транка OTG/DTG, надане в Control Hub під час створення транка. Додаткову інформацію див uri класу голосу . |
| 7 |
Налаштувати профіль sip 100 , який буде використовуватися для зміни повідомлень SIP перед їх надсиланням у Webex Calling.
Ось пояснення полів для конфігурації:
|
| 8 |
Налаштувати транк Webex Calling: |
Після визначення клієнта 100 і налаштувати абонентську точку SIP VoIP, шлюз ініціює підключення TLS до Webex Calling. На цьому етапі SBC доступу представляє свій сертифікат локальному шлюзу. Локальний шлюз перевіряє сертифікат SBC для доступу до Webex Calling за допомогою кореневого пакета CA, який було оновлено раніше. Якщо сертифікат розпізнано, між локальним шлюзом і SBC для доступу до Webex Calling буде встановлено постійний сеанс TLS. Після цього локальний шлюз зможе використовувати це безпечне з’єднання для реєстрації в SBC для доступу до Webex. Коли реєстрацію оскаржують для автентифікації:
-
, ім’я користувача, пароль, і області параметри з облікові дані конфігурація використовується у відповіді.
-
Правила модифікації в профілі 100 sip використовуються для перетворення SIPS URL назад у SIP.
Реєстрація буде успішною після отримання 200 OK від SBC доступу.
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів.
Якщо ви використовуєте транк ТМЗК TDM/ISDN, перейдіть до наступного розділу Налаштуйте локальний шлюз із транком ТМЗК TDM .
Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI .
| 1 |
Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2 |
Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP з тегом 200 і містить змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузла виклику) . ціль сеансу ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Додаткову інформацію див кодек голосового класу . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3 |
Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після створення транка для Webex Calling скористайтеся наведеною далі конфігурацією, щоб створити транк TDM для служби ТМЗК із зворотною маршрутизацією виклику, щоб оптимізувати медіа на гілці виклику Webex.
| 1 |
Конфігурація зворотного набору абонентів використовує групи абонентів і теги маршрутизації викликів, щоб забезпечити коректну передачу викликів між Webex і ТМЗК без створення петель маршрутизації викликів. Налаштуйте такі правила перекладу, які використовуватимуться для додавання та видалення тегів маршрутизації викликів: Ось пояснення полів для конфігурації: правило перекладу голосуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Для наочності під час виправлення неполадок використовуються цифри, що перевищують десяток ("A"). У цій конфігурації тег, доданий профілем трансляції 100, використовується для спрямування викликів із Webex Calling до ТМЗК через точки зворотного набору. Аналогічно, тег, доданий профілем 200 перекладу, використовується для спрямування викликів із ТМЗК до Webex Calling. Профілі перекладу 11 і 12 видаляють ці теги перед доставкою викликів до транків Webex і ТМЗК відповідно. У цьому прикладі передбачається, що номери, на які набирається виклик із Webex Calling, представлені у форматі +E.164. Правило 100 видаляє + на початку, щоб зберегти дійсний номер виклику. Правило 12 потім додає національну або міжнародну цифру маршрутизації під час видалення тега. Використовуйте цифри, які відповідають вашій місцевій національній абонентській групі ISDN. Якщо Webex Calling надає номери в національному форматі, відкоригуйте правила 100 і 12, щоб просто додати або видалити тег маршрутизації відповідно. Додаткову інформацію див голосовий переклад-профіль і правило перекладу голосу . |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до типу транка та використовуваного протоколу. Додаткову інформацію див Налаштування ISDN PRI . Наприклад, базова конфігурація інтерфейсу ISDN з основною швидкістю, установленого в гніздо NIM 2 на пристрої, може включати таке: |
| 3 |
Налаштуйте таку абонентську точку TDM PSTN: Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP з тегом 200 і надає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . вхідний профіль перекладу 200Призначає профіль перекладу, який додасть тег маршрутизації виклику до номера вхідних викликів. прямий набір всерединуМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див прямий набір всередину . порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цією точкою набору. |
| 4 |
Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, запровадивши набір внутрішніх точок набору зворотного набору між Webex Calling і транками ТМЗК. Налаштуйте такі точки зворотного набору. У цьому випадку всі вхідні виклики будуть спочатку маршрутизуватися на одноранговий комутатор 10, а звідти на вузол набору 11 або 12 залежно від застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизуватися до вихідного транка за допомогою груп однорангового набору. Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP та дає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . вхідний профіль перекладу 11Застосовує профіль перекладу, визначений раніше, щоб видалити тег маршрутизації виклику перед передачею до вихідного транка. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Указує, що цей вузол набору обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузла виклику) . ціль сеансу 192.168.80.14Задає адресу інтерфейсу локального маршрутизатора як ціль виклику для повернення. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих через петлю. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються через петлю. Додаткову інформацію див прив’язати . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . кодек g711alaw Примусово використовувати всі виклики ТМЗК G.711. Виберіть a-law або u-law, щоб відповідати методу компандування, який використовується вашою службою ISDN. немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 – до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
Під час створення транка Webex Calling в Unified CM переконайтеся, що ви налаштували вхідний порт у параметрах профілю безпеки транка SIP на 5065. Це дозволяє вхідні повідомлення через порт 5065 і заповнювати заголовок VIA цим значенням під час надсилання повідомлень до локального шлюзу.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. За допомогою цієї конфігурації не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com: Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису A. 192.168.80.65: IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі точки набору: |
| 4 |
Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) проактивно виявляють проблеми, які часто спостерігаються в локальному шлюзі на основі IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. Можна також установити DS для автоматизації збору діагностичних даних і передавання зібраних даних до справи Cisco TAC, щоб прискорити час вирішення.
Діагностичні підписи (DS) - це XML-файли, які містять інформацію про тригерні події та дії, які слід виконати для інформування, усунення несправностей та усунення проблеми. Можна визначити логіку виявлення проблем за допомогою повідомлень системного журналу, подій SNMP і за допомогою періодичного моніторингу конкретних виводів команд show.
Типи дій включають збір результатів команд показу:
-
Створення об'єднаного файлу журналу
-
Передавання файлу в надане користувачем мережеве розташування, як-от HTTPS, SCP, FTP-сервер.
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, призначений системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку застосовних підписів для моніторингу та усунення несправностей різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз під керуванням IOS XE 17.6.1a або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте захищений сервер електронної пошти для надсилання проактивних сповіщень, якщо на пристрої встановлено Cisco IOS XE 17.6.1a або новішої версії.
налаштувати термінальний виклик-сервер пошти додому : @ безпечний кінець tls з пріоритетом 1 -
Налаштуйте змінну середовищаds_email з адресою електронної пошти адміністратора, щоб сповістити вас.
налаштуйте середовище діагностики підпису виклику додомуds_email кінець
Далі наведено приклад конфігурації локального шлюзу, що працює на Cisco IOS XE 17.6.1a або пізнішої версії для надсилання проактивних сповіщень на tacfaststart@gmail.com використання Gmail як захищеного сервера SMTP:
Ми рекомендуємо використовувати Cisco IOS XE Bengaluru 17.6.x або пізнішої версії.
call-home mail-server tacfaststart:password@smtp.gmail.com пріоритет 1 безпечне середовище діагностики-підпису TLSds_email "tacfaststart@gmail.com"Локальний шлюз, запущений на програмному забезпеченні Cisco IOS XE, не є типовим веб-клієнтом Gmail, який підтримує OAuth, тому ми повинні налаштувати певні налаштування облікового запису Gmail і надати конкретний дозвіл на правильну обробку електронної пошти з пристрою:
-
Перейти до і ввімкніть Менш безпечний доступ до програми налаштування.
-
Дайте відповідь "Так, це був я", коли ви отримаєте електронний лист від Gmail із написом "Google заборонив комусь увійти у ваш обліковий запис за допомогою додатка, відмінного від Google".
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує використання ЦП протягом п’яти секунд за допомогою OID SNMP 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, встановлені в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Використовуйте показати snmp команду, щоб увімкнути SNMP. Якщо не ввімкнути, налаштуйте диспетчер snmp-сервера команду.
показати snmp %Агент SNMP не ввімкнено конфігурація t диспетчер snmp-сервера кінець показати snmp корпус: ABCDEFGHIGK 149655 Введення пакетів SNMP 0 Помилки поганої версії SNMP 1 Невідома назва спільноти 0 Надано незаконну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитуваних змінних 2 Кількість змінених змінних 34560 PDU для отримання запиту 138 PDU для отримання наступного 2 PDU з запитом на встановлення 0 Падіння пакетів вхідної черги (максимальний розмір черги 1000) Вивід пакетів SNMP 158277 0 Занадто великі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імен 0 Помилки неправильних значень 0 Загальні помилки 7998 PDU для відповіді 10280 Trap PDU Пакети, які зараз перебувають у черзі введення процесу SNMP: 0 Глобальна пастка SNMP: увімкнено -
Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco серії 4300, 4400 ISR або Cisco CSR серії 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
Локальнийшлюз# копія ftp://ім’я користувача:пароль@ /DS_ 64224.xml завантажувальна пам’ять:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_ 64224.xml завантажувальна пам’ять: Доступ до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0,064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 64224.xml Завантажити файл DS_ 64224.xml успішно -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. У стовпці стану має бути значення «Зареєстровано».
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. За потреби перевстановіть DS 64224, щоб продовжити моніторинг високого рівня використання ЦП на локальному шлюзі.
Моніторинг реєстрації SIP-транка
Ця DS перевіряє на зняття реєстрації локального шлюзового SIP-транка з хмарою викликів Webex кожні 60 секунд. Після виявлення події скасування реєстрації створюється сповіщення електронною поштою й системним журналом, а також видаляється після двох повторень скасування реєстрації. Щоб установити підпис, виконайте наведені нижче дії.
-
Завантажте DS 64117 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
SIP-SIP
Тип проблеми
SIP Trunk Unregistration з повідомленням електронною поштою.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 64117.xml завантажувальна пам’ять: -
Установіть файл XML DS на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 64117.xml Завантажити файл DS_ 64117.xml успішно локальнийшлюз# -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Моніторинг аномальних відключень дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення ненормального відключення виклику з помилками SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 від останнього опитування, він створює системний журнал і сповіщення електронною поштою. Виконайте наведені нижче дії, щоб установити підпис.
-
Використовуйте показати snmp команду, щоб перевірити, чи ввімкнено SNMP. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
показати snmp %Агент SNMP не ввімкнено конфігурація t диспетчер snmp-сервера кінець показати snmp корпус: ABCDEFGHIGK 149655 Введення пакетів SNMP 0 Помилки поганої версії SNMP 1 Невідома назва спільноти 0 Надано незаконну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитуваних змінних 2 Кількість змінених змінних 34560 PDU для отримання запиту 138 PDU для отримання наступного 2 PDU з запитом на встановлення 0 Падіння пакетів вхідної черги (максимальний розмір черги 1000) Вивід пакетів SNMP 158277 0 Занадто великі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імен 0 Помилки неправильних значень 0 Загальні помилки 7998 PDU для відповіді 10280 Trap PDU Пакети, які зараз перебувають у черзі введення процесу SNMP: 0 Глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 65221.xml завантажувальна пам’ять: -
Установіть файл XML DS на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 65221.xml Завантажити файл DS_ 65221.xml успішно -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
Інсталяція діагностичних сигнатур для виправлення неполадок
Використовуйте діагностичні підписи (DS), щоб швидко вирішувати проблеми. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Діагностичні підписи (DS) усувають необхідність вручну перевіряти виникнення проблеми та значно спрощують усунення періодичних і тимчасових проблем.
Ви можете використовувати інструмент пошуку діагностичних підписів, щоб знайти відповідні підписи та встановити їх, щоб самостійно вирішити дану проблему, або ви можете встановити підпис, який рекомендується інженером TAC як частину підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
-
Налаштуйте додаткову змінну середовища DSds_fsurl_prefix який є шляхом файлового сервера Cisco TAC (cxd.cisco.com), до якого передаються зібрані діагностичні дані. Ім’я користувача в шляху до файлу є номером запиту, а пароль є маркером передавання файлу, який можна отримати з Диспетчер запитів підтримки у такій команді. Маркер передавання файлу можна створити в Вкладення розділ диспетчера запитів підтримки, якщо потрібно.
налаштувати середовище LocalGateway(cfg-call-home-diag-sign)підпис діагностики-підпису виклику додомуds_fsurl_prefix "scp:// : @cxd.cisco.com" кінецьПриклад:
середовище діагностики підпису виклику додомуds_fsurl_prefix «довкілляds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com" -
Переконайтеся, що SNMP ввімкнено за допомогою показати snmp команду. Якщо його не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
показати snmp %SNMP оператор не ввімкнено конфігурація t кінець диспетчера snmp-server -
Переконайтеся, що встановіть моніторинг високого процесора DS 64224 як проактивний захід для вимкнення всіх налагоджувальних та діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Серія Cisco 4300, 4400 ISR або серія Cisco CSR 1000V
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 64224.xml завантажувальна пам’ять: копіювати ftp://ім’я користувача:пароль@ /DS_ 65095.xml завантажувальна Flash: -
Установіть DS 64224 моніторингу високого рівня використання ЦП, а потім файл XML DS 65095 на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 64224.xml Завантажити файл DS_ 64224.xml успішне завантаження DS діагностики-підпису виклику додому_ 65095.xml Завантажити файл DS_ 65095.xml успішно -
Переконайтеся, що підпис успішно встановлено за допомогою показати підпис діагностики виклику додому команду. Стовпець стану повинен мати значення "зареєстровано".
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08
65095
00:12:53
DS_ LGW_ IEC_ Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08
Перевірка виконання діагностичних підписів
У наведеній далі команді стовпець "Стан" показати підпис діагностики виклику додому команда змінюється на "виконується", поки локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи виявляє діагностичний підпис подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено /Макс/Видалити |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
1 /20/Р |
23.053 |
23.053 |
Повідомлення електронної пошти, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення результатів команд, які мають відношення до усунення цієї проблеми.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблеми. Якщо потрібно видалити підпис вручну, отримайте ідентифікатор DS із виводу файлу показати підпис діагностики виклику додому і виконайте таку команду:
Видалення діагностики-підпису виклику додому Приклад:
Видалення діагностики-підпису виклику додому 64224 До засобу пошуку сигнатур діагностики періодично додаються нові сигнатури на основі проблем, які зазвичай спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
Для кращого керування шлюзами Cisco IOS XE ми рекомендуємо зареєструвати шлюзи та керувати ними через Control Hub. Це необов’язкова конфігурація. Після реєстрації ви можете використовувати параметр перевірки конфігурації в Control Hub, щоб перевірити конфігурацію локального шлюзу та виявити будь-які проблеми з конфігурацією. Наразі цю функцію підтримують лише транки на основі реєстрації.
Додаткові відомості див. тут:
У цьому розділі описано, як налаштувати Cisco Unified Border Element (CUBE) як локальний шлюз для Webex Calling за допомогою SIP-транка взаємного TLS (mTLS) на основі сертифіката. У першій частині цього документа показано, як налаштувати простий шлюз ТМЗК. У цьому випадку всі виклики з ТМЗК маршрутизуються до Webex Calling, а всі виклики з Webex Calling — до ТМЗК. На наведеному нижче зображенні показано це рішення та конфігурація високорівневої маршрутизації викликів, яка буде використана.
У цьому дизайні використовуються такі основні конфігурації:
-
клієнти голосового класу : використовується для створення конкретних конфігурацій транка.
-
uri класу голосу : Використовується для класифікації повідомлень SIP для вибору вхідної точки набору.
-
вхідний вузол набору : Забезпечує обробку вхідних повідомлень SIP та визначає вихідний маршрут із групою однорангового набору.
-
однорангова група : Визначає вихідні вузли набору, що використовуються для подальшої маршрутизації викликів.
-
вихідний вузол набору : Забезпечує обробку вихідних повідомлень SIP та маршрутизує їх до необхідної цілі.
Хоча IP і SIP стали протоколами за замовчуванням для транків ТМЗК, канали ISDN TDM (мультиплексування з часовим розділенням) все ще широко використовуються і підтримуються транками Webex Calling. Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, наразі необхідно використовувати процес маршрутизації викликів із двох етапів. Цей підхід змінює конфігурацію маршрутизації викликів, показану вище, шляхом введення набору внутрішніх вузлів набору з зворотним циклом між Webex Calling і транками ТМЗК, як показано на зображенні нижче.
Під час підключення локального рішення Cisco Unified Communications Manager за допомогою Webex Calling можна використовувати просту конфігурацію шлюзу ТМЗК як базову для створення рішення, показаного на наступній діаграмі. У цьому випадку Unified Communications Manager забезпечує централізовану маршрутизацію та обробку всіх викликів ТМЗК і Webex Calling.
У цьому документі використовуються імена хостів, IP-адреси та інтерфейси, показані на наведеному нижче зображенні. Надаються параметри для публічної або приватної (за NAT) адресації. Записи DNS SRV є необов’язковими, за винятком випадків балансування навантаження між кількома екземплярами CUBE.
Використовуйте інструкції з налаштування, наведені в решті цього документа, щоб завершити конфігурацію локального шлюзу таким чином:
-
Крок 1. Налаштуйте базове підключення та безпеку маршрутизатора
-
Крок 2. Налаштуйте транк Webex Calling
Залежно від необхідної архітектури виконайте одну з наведених нижче дій.
-
Крок 3: Налаштуйте локальний шлюз із транком SIP ТМЗК
-
Крок 4: Налаштуйте локальний шлюз із наявним середовищем Unified CM
Або:
-
Крок 3: Налаштуйте локальний шлюз із транком ТМЗК TDM
Конфігурація базової лінії
Першим кроком у підготовці маршрутизатора Cisco як локального шлюзу для Webex Calling є створення базової конфігурації, яка захищає вашу платформу та встановлює зв’язок.
-
Для всіх розгортань локального шлюзу на основі сертифікатів потрібні Cisco IOS XE 17.9.1a або пізніших версій. Рекомендовані версії див Дослідження програмного забезпечення Cisco сторінка. Знайдіть платформу та виберіть одну з запропоновано випусків.
-
Маршрутизатори серії ISR4000 повинні бути налаштовані з ліцензіями на технології Unified Communications і Security.
-
Маршрутизатори Catalyst Edge серії 8000, оснащені голосовими картами або DSP, потребують ліцензії DNA Essentials. Маршрутизатори без голосових карт або DSP вимагають мінімального ліцензування DNA Essentials.
-
Для вимог до високої пропускної здатності також може знадобитися ліцензія високої безпеки (HSEC) і права на додаткову пропускну здатність.
Див Коди авторизації для отримання додаткової інформації.
-
-
Створіть базову конфігурацію для своєї платформи, яка відповідає вашим бізнес-політикам. Зокрема, налаштуйте таке та перевірте роботу:
-
NTP
-
ACLs
-
Автентифікація користувача та віддалений доступ
-
DNS
-
IP-маршрутизація
-
IP-адреси
-
-
Мережа для Webex Calling має використовувати адресу IPv4. Повні доменні імена локального шлюзу (FQDN) або адреси записів служби (SRV) повинні перетворюватися на загальнодоступну адресу IPv4 в інтернеті.
-
Усі порти SIP та медіа-порти на інтерфейсі локального шлюзу, зверненому до Webex, повинні бути доступні з інтернету безпосередньо або через статичний NAT. Переконайтеся, що ви відповідно оновили свій брандмауер.
-
Установіть підписаний сертифікат на локальний шлюз (нижче наведено докладні кроки налаштування).
-
Загальнодоступний центр сертифікації (CA), як детально описано в Які кореневі центри сертифікації підтримуються для викликів до аудіо- та відеоплатформ Cisco Webex? має підписати сертифікат пристрою.
-
Повне доменне ім’я, яке налаштовано в Control Hub під час створення транка, має бути сертифікатом Common Name (CN) або альтернативного імені суб’єкта (SAN) маршрутизатора. Наприклад:
-
Якщо налаштований транк у Control Hub вашої організації має cube1.lgw.com:5061 як повне доменне ім’я локального шлюзу, тоді CN або SAN у сертифікаті маршрутизатора має містити cube1.lgw.com.
-
Якщо налаштований транк у Control Hub вашої організації має lgws.lgw.com як адресу SRV локальних шлюзів, доступних із транка, тоді CN або SAN у сертифікаті маршрутизатора має містити lgws.lgw.com. Записи, до яких вирішується адреса SRV (CNAME, A Record або IP-адреса), не є обов'язковими в SAN.
-
Незалежно від того, чи використовуєте ви FQDN або SRV для транка, адреса контакту для всіх нових діалогових вікон SIP з вашого локального шлюзу використовує ім’я, налаштовану в Control Hub.
-
-
-
Переконайтеся, що сертифікати підписано для використання клієнта та сервера.
-
Передайте пакет кореневого CA Cisco на локальний шлюз.
Конфігурація
| 1 |
Переконайтеся, що ви призначили допустимі та маршрутизовані IP-адреси будь-якому інтерфейсу рівня 3, наприклад:
|
| 2 |
Захист облікових даних STUN на маршрутизаторі за допомогою симетричного шифрування. Налаштуйте основний ключ шифрування та тип шифрування, як показано нижче. |
| 3 |
Створіть точку довіри шифрування за допомогою сертифіката, підписаного вашим бажаним центром сертифікації (CA). |
| 4 |
Автентифікуйте новий сертифікат за допомогою проміжного (або кореневого) сертифіката CA, а потім імпортуйте сертифікат (крок 4). Введіть таку команду exec або конфігурацію:
|
| 5 |
Імпортуйте підписаний сертифікат організатора за допомогою такої команди exec або конфігурації:
|
| 6 |
Увімкніть ексклюзивність TLS1.2 і вкажіть точку довіри за замовчуванням за допомогою таких команд конфігурації:
|
| 7 |
Установіть пакет кореневого CA Cisco, який включає сертифікат CA DigiCert, що використовується Webex Calling. Використовуйте чиста URL-адреса імпорту пулу довіри crypto PKI команду, щоб завантажити кореневий пакет CA за вказаною URL-адресою та очистити поточний пул довіри CA, а потім установіть новий пакет сертифікатів: Якщо вам потрібно використовувати проксі для доступу до інтернету за допомогою HTTPS, додайте таку конфігурацію перед імпортом пакета CA: ip http клієнт проксі-сервер вашproxy.com проксі-порт 80 |
| 1 |
Створіть транк ТМЗК на основі сертифіката CUBE для наявного розташування в Control Hub. Додаткову інформацію див Налаштуйте транки, групи маршрутів і абонентські групи для Webex Calling . Запишіть інформацію про транк, що надається після створення транка. Ці відомості, як показано на наступній ілюстрації, будуть використані під час кроків налаштування в цьому посібнику.  |
| 2 |
Введіть такі команди, щоб налаштувати CUBE як локальний шлюз Webex Calling: Ось пояснення полів для конфігурації:
Вмикає функції Cisco Unified Border Element (CUBE) на платформі. дозволити-з’єднання sip до sipУвімкніть функціонал CUBE Basic SIP Back to Back. Додаткову інформацію див Дозволити підключення . За замовчуванням транспортування факсів T.38 ввімкнено. Додаткову інформацію див протокол факсу t38 (голосова служба) . Вмикає STUN (обхід сеансу UDP через NAT) у всьому світі. Ці глобальні команди зупинки потрібні лише під час розгортання локального шлюзу за NAT.
Додаткову інформацію див ідентифікатор оператора stun flowdata і stun flowdata shared-secret . асиметричне корисне навантаження повнеНалаштовує підтримку асиметричного корисного навантаження SIP для корисних даних DTMF і динамічних кодеків. Додаткову інформацію про цю команду див асиметричне корисне навантаження . вимушена рання пропозиціяПримушує локальний шлюз надсилати інформацію SDP у початковому повідомленні ЗАПРОСИТИ замість очікування підтвердження від сусіднього однорангового вузла. Додаткову інформацію про цю команду див рання пропозиція . вхідні sip-профіліДозволяє CUBE використовувати профілі SIP для зміни повідомлень у міру їх отримання. Профілі застосовуються через вузли набору або клієнтів. |
| 3 |
Налаштувати кодек голосового класу 100 фільтр кодеків для транка. У цьому прикладі той самий фільтр кодеків використовується для всіх транків. Для точного керування можна налаштувати фільтри для кожного транка. Ось пояснення полів для конфігурації: кодек голосового класу 100Використовується для дозволу лише бажаних кодеків для викликів через SIP-транки. Додаткову інформацію див кодек голосового класу . Кодек Opus підтримується лише для транків ТМЗК на основі SIP. Якщо транк ТМЗК використовує голосове підключення T1/E1 або аналогове FXO, виключити бажаний параметр кодека 1 опус з кодек голосового класу 100 конфігурації. |
| 4 |
Налаштувати голосовий клас stun-usage 100 щоб увімкнути ICE для транка Webex Calling. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: оглушення використання ice liteВикористовується для ввімкнення ICE-Lite для всіх вузлів набору Webex Calling, що дозволяють оптимізувати медіа, коли це можливо. Додаткову інформацію див використання оглушення класу голосу і оглушення використання ice lite . , дані потоку обходу використання брандмауера stun команда потрібна лише під час розгортання локального шлюзу за NAT. Для потоків викликів із використанням оптимізації медіа-шляхів потрібне зупинене використання ICE-lite. Щоб забезпечити оптимізацію медіа для шлюзу SIP до TDM, налаштуйте одноранговий комутатор із зворотним зв’язком із ввімкненим ICE-Lite на ділянці IP-IP. Щоб отримати додаткові технічні відомості, зверніться до відділу облікового запису або команди TAC. |
| 5 |
Налаштуйте політику шифрування медіа для трафіку Webex. (Цей крок не застосовується до Webex для державних установ) Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Визначає SHA1_ 80 як єдиний набір шифрів SRTP, який пропонує CUBE в SDP у повідомленнях пропозицій і відповідей. Webex Calling підтримує лише SHA1_ 80. Додаткову інформацію див голосовий клас srtp-crypto . |
| 6 |
Налаштуйте FIPS-сумісні шифри GCM (Цей крок застосовується лише для Webex для державних установ) . Ось пояснення полів для конфігурації: голосовий клас srtp-crypto 100Задає GCM як набір шифрів, який пропонує CUBE. Налаштування шифрів GCM для локального шлюзу для Webex для державних установ є обов’язковим. |
| 7 |
Налаштуйте шаблон для унікальної ідентифікації викликів до транка локального шлюзу на основі його повного домену або SRV призначення: Ось пояснення полів для конфігурації: голос класу uri 100 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте повне доменне ім’я LGW або SRV, налаштовані в Control Hub, під час створення транка. |
| 8 |
Налаштуйте профілі маніпулювання повідомленнями SIP. Якщо ваш шлюз налаштовано з загальнодоступною IP-адресою, налаштуйте профіль, як описано нижче, або перейдіть до наступного кроку, якщо ви використовуєте NAT. У цьому прикладі cube1.lgw.com є FQDN, налаштованим для локального шлюзу, а «198.51.100.1» — це загальнодоступна IP-адреса інтерфейсу локального шлюзу, що звернена до Webex Calling: Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. Пропустіть наступний крок, якщо ви налаштували локальний шлюз із загальнодоступними IP-адресами. |
| 9 |
Якщо ваш шлюз налаштовано з приватною IP-адресою за статичним NAT, налаштуйте вхідні та вихідні профілі SIP наступним чином. У цьому прикладі cube1.lgw.com є повним доменом, налаштованим для локального шлюзу, «10.80.13.12» — це IP-адреса інтерфейсу, що звернена до Webex Calling, а «192.65.79.20» — це загальнодоступна IP-адреса NAT. Профілі SIP для вихідних повідомлень у Webex Calling
Ось пояснення полів для конфігурації: правила 10 і 20Щоб дозволити Webex автентифікувати повідомлення з локального шлюзу, заголовок "Контакт" у повідомленнях із запитами SIP і відповідями має містити значення, надане для транка в Control Hub. Це буде або повне доменне ім’я одного хоста, або ім’я домену SRV, що використовується для кластера пристроїв. правила з 30 по 81Перетворіть посилання на приватні адреси на зовнішню загальнодоступну адресу для вебсайту, що дозволить Webex правильно інтерпретувати та маршрутизувати наступні повідомлення. Профіль SIP для вхідних повідомлень із Webex CallingОсь пояснення полів для конфігурації: правила з 10 по 80Перетворіть посилання на публічні адреси на налаштовану приватну адресу, дозволяючи CUBE правильно обробляти повідомлення з Webex. Додаткову інформацію див sip-профілі класу голосу . |
| 10 |
Налаштуйте параметри SIP для підтримки активності за допомогою профілю зміни заголовка. Ось пояснення полів для конфігурації: голосовий клас sip-options-keepalive 100Налаштовує профіль підтримки активності та переходить у режим конфігурації голосового класу. Можна налаштувати час (у секундах), протягом якого SIP-відповідь «За межами діалогового вікна параметрів» надсилається об’єкту набору, коли контрольне підключення до кінцевої точки перебуває в стані UP або Down. Цей профіль підтримання активності запускається з точки набору, налаштованої на Webex. Щоб переконатися, що заголовки контактів включають повне доменне ім’я SBC, використовується профіль SIP 115. Правила 30, 40 і 50 є обов’язковими, лише якщо SBC налаштовано за статичним NAT. У цьому прикладі cube1.lgw.com є FQDN, вибраним для локального шлюзу. Якщо використовується статичний NAT, "10.80.13.12" є IP-адресою інтерфейсу SBC для Webex Calling, а "192.65.79.20" є загальнодоступною IP-адресою NAT. . |
| 11 |
Налаштувати транк Webex Calling: |
Створивши транк для Webex Calling вище, використовуйте наведену далі конфігурацію, щоб створити незашифрований транк до постачальника ТМЗК на основі SIP:
Якщо ваш постачальник послуг пропонує захищений транк ТМЗК, ви можете використати конфігурацію, подібну до якої описано вище, для транка Webex Calling. CUBE підтримує безпечну маршрутизацію викликів.
Якщо ви використовуєте транк ТМЗК TDM/ISDN, перейдіть до наступного розділу Налаштуйте локальний шлюз із транком ТМЗК TDM .
Щоб налаштувати інтерфейси TDM для гілок виклику ТМЗК на шлюзах Cisco TDM-SIP, див. Налаштування ISDN PRI .
| 1 |
Налаштуйте uri такого класу голосу, щоб ідентифікувати вхідні виклики з транка ТМЗК: Ось пояснення полів для конфігурації: голос класу uri 200 sipВизначає шаблон для зіставлення вхідного запрошення SIP з вхідним транковим вузлом набору. Під час введення цього шаблону використовуйте IP-адресу свого шлюзу IP ТМЗК. Додаткову інформацію див uri класу голосу . |
| 2 |
Налаштуйте таку точку набору IP ТМЗК: Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP з тегом 200 і містить змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Визначає вузол набору 200 обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузла виклику) . ціль сеансу ipv4:192.168.80.13Указує цільову адресу IPv4 пункту призначення для надсилання виклику. Метою сесії тут є IP-адреса ITSP. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . вхідні URI через 200Визначає критерій відповідності заголовка VIA IP-адресі IP-сервера. Звіряє всі вхідні гілки виклику IP ТМЗК на локальному шлюзі з однорангом набору номера 200. Додаткову інформацію див вхідна URL-адреса . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих до ТМЗК. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, надісланих до ТМЗК. Додаткову інформацію див прив’язати . кодек голосового класу 100Налаштовує абонентську точку на використання списку загальних фільтрів кодеків 100 . Додаткову інформацію див кодек голосового класу . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 3 |
Якщо ви налаштовуєте локальний шлюз на маршрутизацію лише викликів між Webex Calling і ТМЗК, додайте наведену далі конфігурацію маршрутизації викликів. Якщо ви налаштовуєте локальний шлюз за допомогою платформи Unified Communications Manager, перейдіть до наступного розділу. |
Після створення транка для Webex Calling скористайтеся наведеною далі конфігурацією, щоб створити транк TDM для служби ТМЗК із зворотною маршрутизацією виклику, щоб оптимізувати медіа на гілці виклику Webex.
| 1 |
Конфігурація зворотного набору абонентів використовує групи абонентів і теги маршрутизації викликів, щоб забезпечити коректну передачу викликів між Webex і ТМЗК без створення петель маршрутизації викликів. Налаштуйте такі правила перекладу, які використовуватимуться для додавання та видалення тегів маршрутизації викликів: Ось пояснення полів для конфігурації: правило перекладу голосуВикористовує регулярні вирази, визначені в правилах, для додавання або видалення тегів маршрутизації викликів. Для наочності під час виправлення неполадок використовуються цифри, що перевищують десяток ("A"). У цій конфігурації тег, доданий профілем трансляції 100, використовується для спрямування викликів із Webex Calling до ТМЗК через точки зворотного набору. Аналогічно, тег, доданий профілем 200 перекладу, використовується для спрямування викликів із ТМЗК до Webex Calling. Профілі перекладу 11 і 12 видаляють ці теги перед доставкою викликів до транків Webex і ТМЗК відповідно. У цьому прикладі передбачається, що номери, на які набирається виклик із Webex Calling, представлені у форматі +E.164. Правило 100 видаляє + на початку, щоб зберегти дійсний номер виклику. Правило 12 потім додає національну або міжнародну цифру маршрутизації під час видалення тега. Використовуйте цифри, які відповідають вашій місцевій національній абонентській групі ISDN. Якщо Webex Calling надає номери в національному форматі, відкоригуйте правила 100 і 12, щоб просто додати або видалити тег маршрутизації відповідно. Додаткову інформацію див голосовий переклад-профіль і правило перекладу голосу . |
| 2 |
Налаштуйте порти голосового інтерфейсу TDM відповідно до типу транка та використовуваного протоколу. Додаткову інформацію див Налаштування ISDN PRI . Наприклад, базова конфігурація інтерфейсу ISDN з основною швидкістю, установленого в гніздо NIM 2 на пристрої, може включати таке: |
| 3 |
Налаштуйте таку абонентську точку TDM PSTN: Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP з тегом 200 і надає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . вхідний профіль перекладу 200Призначає профіль перекладу, який додасть тег маршрутизації виклику до номера вхідних викликів. прямий набір всерединуМаршрутизує виклик без надання додаткового сигналу набору. Додаткову інформацію див прямий набір всередину . порт 0/2/0:15Фізичний голосовий порт, пов’язаний із цією точкою набору. |
| 4 |
Щоб увімкнути оптимізацію медіа-шляхів IP для локальних шлюзів із потоками викликів TDM-IP, можна змінити маршрутизацію виклику, запровадивши набір внутрішніх точок набору зворотного набору між Webex Calling і транками ТМЗК. Налаштуйте такі точки зворотного набору. У цьому випадку всі вхідні виклики будуть спочатку маршрутизуватися на одноранговий комутатор 10, а звідти на вузол набору 11 або 12 залежно від застосованого тега маршрутизації. Після видалення тега маршрутизації виклики будуть маршрутизуватися до вихідного транка за допомогою груп однорангового набору. Ось пояснення полів для конфігурації: Визначає абонентську точку VoIP та дає змістовний опис для спрощення керування та усунення несправностей. Додаткову інформацію див голос однорангового виклику . вхідний профіль перекладу 11Застосовує профіль перекладу, визначений раніше, щоб видалити тег маршрутизації виклику перед передачею до вихідного транка. шаблон призначення BAD.BADФіктивний шаблон призначення потрібен для маршрутизації вихідних викликів із використанням вхідної групи однорангового набору. Додаткову інформацію див шаблон призначення (інтерфейс) . протокол сеансу sipv2Указує, що цей вузол набору обробляє гілки виклику SIP. Додаткову інформацію див протокол сеансу (вузла виклику) . ціль сеансу 192.168.80.14Задає адресу інтерфейсу локального маршрутизатора як ціль виклику для повернення. Додаткову інформацію див ціль сеансу (вузла набору VoIP) . джерело-інтерфейс керування прив’язкою GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для повідомлень, надісланих через петлю. Додаткову інформацію див прив’язати . прив’язати інтерфейс джерела медіа GigabitEthernet0/0/0Налаштовує інтерфейс джерела та пов’язану IP-адресу для медіафайлів, що надсилаються через петлю. Додаткову інформацію див прив’язати . dtmf-relay rtp-nteВизначає RTP-NTE (RFC2833) як можливість DTMF, очікувану на нозі виклику. Додаткову інформацію див Ретрансляція DTMF (голос через IP) . кодек g711alaw Примусово використовувати всі виклики ТМЗК G.711. Виберіть a-law або u-law, щоб відповідати методу компандування, який використовується вашою службою ISDN. немає vadВимикання виявлення голосової активності. Додаткову інформацію див vad (абонентський вузол) . |
| 5 |
Додайте таку конфігурацію маршрутизації викликів: На цьому налаштування вашого локального шлюзу завершено. Збережіть конфігурацію та перезавантажте платформу, якщо функції CUBE налаштовуються вперше.
|
Конфігурацію ТМЗК-Webex Calling у попередніх розділах можна змінити, щоб включити додаткові транки до кластера Cisco Unified Communications Manager (UCM). У цьому випадку всі виклики маршрутизуються через Unified CM. Виклики з UCM через порт 5060 маршрутизуються до ТМЗК, а виклики з порту 5065 – до Webex Calling. Для включення цього сценарію викликів можуть бути додані наступні додаткові конфігурації.
| 1 |
Налаштуйте наведені нижче URI класу голосових викликів. |
| 2 |
Налаштуйте такі записи DNS, щоб задати маршрутизацію SRV до хостів Unified CM: IOS XE використовує ці записи для локального визначення цільових хостів і портів UCM. За допомогою цієї конфігурації не потрібно налаштовувати записи в системі DNS. Якщо ви надаєте перевагу використанню DNS, ці локальні конфігурації не потрібні. Ось пояснення полів для конфігурації: Наведена далі команда створює ресурсний запис DNS SRV. Створіть запис для кожного хоста та транка UCM: хост ip_sip ._udp .pstntocucm.io srv 2 1 5060 ucmsub5.mydomain.com _sip._udp.pstntocucm.io: Ім’я ресурсного запису SRV 2: Пріоритет ресурсного запису SRV 1: Вага ресурсного запису SRV 5060: Номер порту, який буде використовуватися для цільового хоста в цьому ресурсному записі ucmsub5.mydomain.com: Цільовий хост ресурсного запису Щоб усунути імена цільових хостів ресурсного запису, створіть локальні записи A DNS. Наприклад: ip-хост ucmsub5.mydomain.com 192.168.80.65 хост ip : Створює запис у локальній базі даних IOS XE. ucmsub5.mydomain.com: Ім’я організатора запису A. 192.168.80.65: IP-адреса організатора. Створіть ресурсні записи SRV та записи A, щоб відобразити ваше середовище UCM та бажану стратегію розподілу викликів. |
| 3 |
Налаштуйте такі точки набору: |
| 4 |
Додайте маршрутизацію виклику, використовуючи такі конфігурації: |
Діагностичні підписи (DS) проактивно виявляють проблеми, що часто спостерігаються в локальному шлюзі на базі Cisco IOS XE, і генерують повідомлення електронної пошти, системного або термінального повідомлення про подію. DS також можна встановити з метою автоматизації збору діагностичних даних і передавання отриманих даних до Cisco TAC для прискорення часу вирішення проблеми.
Діагностичні підписи (DS) – це XML-файли, які містять відомості про події тригера проблеми та дії для інформування, виправлення неполадок і усунення проблеми. Використовуйте повідомлення syslog, події SNMP і за допомогою періодичного моніторингу конкретних виходів команд show для визначення логіки виявлення проблеми. До типів дій відносяться:
-
Збирання показаних командних виходів
-
Створення об'єднаного файлу журналу
-
Завантаження файлу на вказане користувачем мережеве розташування, таке як HTTPS, SCP, FTP-сервер
Інженери TAC створюють файли DS і підписують їх цифровим підписом для захисту цілісності. Кожен файл DS має унікальний числовий ідентифікатор, присвоєний системою. Інструмент пошуку діагностичних підписів (DSLT) є єдиним джерелом для пошуку застосовних підписів для моніторингу та усунення несправностей різних проблем.
Перш ніж почати.
-
Не редагуйте файл DS, який ви завантажуєте з DSLT. Файли, які ви змінюєте, не вдається інсталювати через помилку перевірки цілісності.
-
Сервер простого протоколу передавання пошти (SMTP), який потрібен локальному шлюзу для надсилання сповіщень електронною поштою.
-
Переконайтеся, що локальний шлюз працює під керуванням IOS XE 17.6.1 або новішої версії, якщо ви хочете використовувати захищений сервер SMTP для сповіщень електронною поштою.
Передумови
Локальний шлюз, що працює під керуванням IOS XE 17.6.1 або новішої версії
-
Діагностичні підписи ввімкнено за замовчуванням.
-
Налаштуйте захищений сервер електронної пошти, який використовується для надсилання проактивних сповіщень, якщо на пристрої встановлено IOS XE 17.6.1 або пізнішої версії.
налаштувати термінальний виклик-сервер пошти додому : @ безпечний кінець tls з пріоритетом 1 -
Налаштуйте змінну ds_email середовища з адресою електронної пошти адміністратора, про яку ви сповіщаєте.
налаштувати середовище LocalGateway(cfg-call-home-diag-sign)підпис діагностики-підпису виклику додомуds_email кінець
Інсталяція діагностичних сигнатур для проактивного моніторингу
Моніторинг високої завантаженості ЦП
Цей DS відстежує 5-секундне використання процесора за допомогою SNMP OID 1.3.6.1.4.1.9.2.1.56. Коли використання досягає 75% або більше, він вимикає всі налагодження та видаляє всі діагностичні сигнатури, які ви встановлюєте в локальному шлюзі. Щоб установити підпис, виконайте наведені нижче дії.
-
Переконайтеся, що ви ввімкнули SNMP за допомогою команди показати snmp. Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
показати snmp %Агент SNMP не ввімкнено конфігурація t диспетчер snmp-сервера кінець показати snmp корпус: ABCDEFGHIGK 149655 Введення пакетів SNMP 0 Помилки поганої версії SNMP 1 Невідома назва спільноти 0 Надано незаконну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитуваних змінних 2 Кількість змінених змінних 34560 PDU для отримання запиту 138 PDU для отримання наступного 2 PDU з запитом на встановлення 0 Падіння пакетів вхідної черги (максимальний розмір черги 1000) Вивід пакетів SNMP 158277 0 Занадто великі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імен 0 Помилки неправильних значень 0 Загальні помилки 7998 PDU для відповіді 10280 Trap PDU Пакети, які зараз перебувають у черзі введення процесу SNMP: 0 Глобальна пастка SNMP: увімкнено Завантажте DS 64224 за допомогою наведених нижче параметрів розкривного списку в засобі пошуку діагностичних підписів.
копіювати ftp://ім’я користувача:пароль@ /DS_ 64224.xml завантажувальна пам’ять:Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
CUBE Enterprise у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП зі сповіщенням електронною поштою
-
Скопіюйте файл XML DS до флешпам’яті локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 64224.xml завантажувальна пам’ять:У наведеному нижче прикладі показано копіювання файлу з FTP-сервера до локального шлюзу.
копіювати ftp://user:pwd@192.0.2.12/DS_ 64224.xml завантажувальна пам’ять: Доступ до ftp://*:*@ 192.0.2.12/DS_ 64224.xml...! [OK — 3571/4096 байт] 3571 байт скопійовано за 0,064 с (55797 байт/с) -
Установіть файл XML DS на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 64224.xml Завантажити файл DS_ 64224.xml успішно -
Скористайтеся командою відображення діагностичного підпису виклику додому, щоб переконатися, що підпис успішно інстальовано. Стовпець стану повинен мати значення "зареєстровано".
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : username@gmail.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-07 22:05:33
У разі запуску цей підпис видалить усі запущені DS, а також видалить себе. Якщо необхідно, будь ласка, перевстановіть DS 64224, щоб продовжити моніторинг високого використання ЦП на локальному шлюзі.
Моніторинг ненормальних роз 'єднань дзвінків
Цей DS використовує опитування SNMP кожні 10 хвилин для виявлення ненормального відключення виклику з помилками SIP 403, 488 і 503. Якщо приріст кількості помилок більше або дорівнює 5 від останнього опитування, він створює системний журнал і сповіщення електронною поштою. Виконайте наведені нижче дії, щоб установити підпис.
-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
показати snmp %Агент SNMP не ввімкнено конфігурація t диспетчер snmp-сервера кінець показати snmp корпус: ABCDEFGHIGK 149655 Введення пакетів SNMP 0 Помилки поганої версії SNMP 1 Невідома назва спільноти 0 Надано незаконну операцію для імені спільноти 0 Помилки кодування 37763 Кількість запитуваних змінних 2 Кількість змінених змінних 34560 PDU для отримання запиту 138 PDU для отримання наступного 2 PDU з запитом на встановлення 0 Падіння пакетів вхідної черги (максимальний розмір черги 1000) Вивід пакетів SNMP 158277 0 Занадто великі помилки (максимальний розмір пакета 1500) 20 Немає таких помилок імен 0 Помилки неправильних значень 0 Загальні помилки 7998 PDU для відповіді 10280 Trap PDU Пакети, які зараз перебувають у черзі введення процесу SNMP: 0 Глобальна пастка SNMP: увімкнено -
Завантажте DS 65221 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
SIP аномальне виявлення відключення виклику за допомогою сповіщення електронної пошти та Syslog.
-
Скопіюйте файл XML DS до локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 65221.xml завантажувальна пам’ять: -
Установіть файл XML DS на локальному шлюзі.
Завантаження DS діагностики-підпису виклику додому_ 65221.xml Завантажити файл DS_ 65221.xml успішно -
Використовуйте команду показати підпис діагностики виклику додому щоб переконатися, що підпис успішно встановлено. У стовпці стану має бути значення «Зареєстровано».
Встановлення діагностичних підписів для усунення несправностей
Діагностичні підписи (DS) також можна використовувати для швидкого вирішення проблем. Інженери Cisco TAC є авторами декількох підписів, які дозволяють проводити необхідні налагодження, необхідні для усунення заданої проблеми, виявлення виникнення проблеми, збору потрібного набору діагностичних даних і автоматичної передачі даних в корпус Cisco TAC. Це усуває необхідність перевірки виникнення проблеми вручну й робить виправлення неполадок переривчастих і тимчасових проблем набагато простішим.
За допомогою засобу пошуку діагностичних підписів можна знайти відповідні підписи та інсталювати їх для самостійного вирішення певної проблеми, або інсталювати підпис, рекомендований інженером TAC як частину підтримки підтримки.
Нижче наведено приклад того, як знайти й встановити DS для виявлення екземпляра системного журналу «%VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0" слогуйте та автоматизуйте збір діагностичних даних, виконавши такі дії:
Налаштуйте іншу змінну середовища DSds_fsurl_prefix як шлях до файлового сервера Cisco TAC (cxd.cisco.com), щоб передати дані діагностики. Ім’я користувача в шляху до файлу є номером запиту, а пароль є маркером передавання файлу, який можна отримати з Диспетчер запитів підтримки як показано далі. Маркер передавання файлу можна створити в Вкладення розділ диспетчера запитів підтримки (якщо потрібно).
налаштувати середовище LocalGateway(cfg-call-home-diag-sign)підпис діагностики-підпису виклику додомуds_fsurl_prefix "scp:// : @cxd.cisco.com" кінецьПриклад:
середовище діагностики підпису виклику додомуds_fsurl_prefix «довкілляds_fsurl_prefix "scp://612345678:abcdefghijklmnop@cxd.cisco.com"-
Переконайтеся, що SNMP включений за допомогою команди show snmp. Якщо SNMP не ввімкнено, налаштуйте диспетчер snmp-сервера команду.
показати snmp %SNMP оператор не ввімкнено конфігурація t кінець диспетчера snmp-server -
Ми рекомендуємо встановити High CPU monitoring DS 64224 як проактивний захід для відключення всіх налагоджувальних і діагностичних сигнатур під час високого використання ЦП. Завантажте DS 64224 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Продуктивність
Тип проблеми
Високе використання ЦП із сповіщенням електронною поштою.
-
Завантажте DS 65095 за допомогою наведених нижче параметрів у засобі пошуку діагностичних підписів.
Назва поля
Значення поля
Платформа
Cisco 4300, 4400 ISR Series або Catalyst 8000V Edge Software
Продукт
Корпоративна версія CUBE у рішенні Webex Calling
Область проблеми
Системні журнали
Тип проблеми
Системний журнал — %VOICE_IEC-3-GW: CCAPI: Внутрішня помилка (порогове значення підвищення кількості викликів): IEC=1.1.181.1.29.0
-
Скопіюйте файли XML DS до локального шлюзу.
копіювати ftp://ім’я користувача:пароль@ /DS_ 64224.xml завантажувальна пам’ять: копіювати ftp://ім’я користувача:пароль@ /DS_ 65095.xml завантажувальна Flash: -
Установіть XML-файл DS 64224, а потім DS 65095 моніторингу ЦП із високим рівнем ЦП на локальний шлюз.
Завантаження DS діагностики-підпису виклику додому_ 64224.xml Завантажити файл DS_ 64224.xml успішне завантаження DS діагностики-підпису виклику додому_ 65095.xml Завантажити файл DS_ 65095.xml успішно -
Перевірте, чи успішно встановлено підпис, за допомогою команди show call-home diagnostic-signature. У стовпці стану має бути значення «Зареєстровано».
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : username@gmail.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.comЗавантажені DS:
Ідентифікатор DS
Ім’я DS
Редакція
Стан
Останнє оновлення (GMT+00:00)
64224
00:07:45
DS_LGW_CPU_MON75
0.0.10
Зареєстровано
2020-11-08:00:07:45
65095
00:12:53
DS_ LGW_ IEC_ Call_spike_threshold
0.0.12
Зареєстровано
2020-11-08:00:12:53
Перевірка виконання діагностичних підписів
У наступній команді стовпець "Стан" команди показує діагностичний підпис виклику додому змінюється на "запущений", поки Локальний шлюз виконує дію, визначену в підписі. Висновок відображення статистики діагностичного підпису виклику є найкращим способом перевірити, чи діагностичний підпис виявляє подію, що цікавить, і виконує дію. У стовпці "Спрацьовування/Макс/Деінсталяція" вказується кількість разів, коли даний підпис ініціював подію, максимальна кількість разів, коли вона визначається для виявлення події, і чи деінсталюється підпис після виявлення максимальної кількості тригерних подій.
показати підпис діагностики виклику додому Поточні налаштування діагностичного підпису: Діагностика-підпис: активований профіль: CiscoTAC-1 (стан: АКТИВНО) URL-адреси завантаження: https://tools.cisco.com/its/service/oddce/services/DDCEService Змінна середовища:ds_email : carunach@cisco.com ds_fsurl_prefix: scp://612345678:abcdefghijklmnop@cxd.cisco.com Завантажені DS:
|
Ідентифікатор DS |
Ім’я DS |
Редакція |
Стан |
Останнє оновлення (GMT+00:00) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0.0.10 |
Зареєстровано |
2020-11-08 00:07:45 |
|
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
0.0.12 |
Виконується |
2020-11-08 00:12:53 |
Відображення статистики діагностичних підписів «Виклик додому»
|
Ідентифікатор DS |
Ім’я DS |
Запущено /Макс/Видалити |
Середній час виконання (секунди) |
Максимальний час виконання (секунди) |
|---|---|---|---|---|
| 64224 |
DS_LGW_CPU_MON75 |
0/0/N |
0.000 |
0.000 |
|
65095 |
DS_ LGW_ IEC_ Call_spike_threshold |
1 /20/Р |
23.053 |
23.053 |
Повідомлення електронної пошти зі сповіщенням, надіслане під час виконання діагностичного підпису, містить ключову інформацію, таку як тип проблеми, відомості про пристрій, версію програмного забезпечення, запущену конфігурацію та відображення вихідних команд, які мають відношення до усунення несправностей із цією проблемою.
Видалення діагностичних сигнатур
Використання діагностичних сигнатур для виправлення неполадок, як правило, визначається для видалення після виявлення деяких випадків проблем. Якщо ви хочете видалити підпис вручну, отримайте ідентифікатор DS з виводу показу діагностичного підпису виклику додому та запустіть таку команду:
Видалення діагностики-підпису виклику додому Приклад:
Видалення діагностики-підпису виклику додому 64224 До засобу пошуку діагностичних сигнатур періодично додаються нові підписи на основі проблем, які спостерігаються під час розгортання. Наразі TAC не підтримує запити на створення нових користувацьких підписів.
