вторник, 16 июня 2015 г.

Восстановление лицензий CUCM
      
      Если вдруг с вами случилась такая неприятность, что слетели лицензии CUCM, понятное дело - нужно обращаться в Cisco TAC. Первым делом они у вас запросят License Request c License Manager. Но он может отличаться от первоначального, на основании которого вам генерировались лицензии (допустим мигрировали сервера CUCM на другое железо). В таком случае вас попросят предоставить старые файлы лицензий и/или Cisco sales order number/PAK. Но и здесь проблема - их нет и где взять никто не знает (ой, это было так давно...).
      В таком случае, чтоб не терять много времени на безрезультатные поиски, старые файлы лицензий можно скачать с CUCM Publisher, если ELM установлен вместе с ним! Для этого нужен SFTP сервер и доступ по SSH к консоли CUCM Publisher.
1. Логинимся на консоль
2. Смотрим что у нас там есть, в контексте файлов лицензий
    admin:license file diagnose

    Available files include:


1) /common/elm/data/licRequest/lic_req_20141231_115712.txt


2) /common/elm/data/licResponse/a7b1da87e8d0d289ab4b937fe2801d24_201410160155058980.bin


3) /common/elm/data/licResponse/5d36034f4c8f6c65397717d6272f1ab7_2014123102581
27000.bin

q) quit


3. Качаем все файлы, как licRequest так и licResponse

    admin:license file get /common/elm/data/licResponse/5d36034f4c8f6c65397717d6272f1ab7_201412310258127000.bin
Здесь у вас спросит ввести адрес SFTP сервера и учетку для доступа к нему.
4. Собираем архивчик и отправляем в Cisco TAC, получаем новые файлы лицензий, устанавливаем их и радуемся! )))

Всем хорошего дня!

четверг, 16 октября 2014 г.

CUBE High Availability с использованием HSRP
         Допустим,  у вас есть необходимость подключить свой кластер CUCM к провайдеру телефонных услуг с помощью SIP-транка. Как известно, для этого нам необходим IP-IP шлюз - Cisco Unified Border Element (CUBE). Да еще не просто подключить, а обеспечить высоко доступность данного подключения с использованием box-to-box избыточности. Что человеческим языком означает: есть 2 CUBE (один основной, второй резервный), 1 SIP провайдер – нужно сделать так, чтоб во время нормальной работы сети все звонки выходили через основной CUBE, а в случае его сбоя (или его интерфейсов) – через резервный. Все это должно происходить автоматически и с сохранением текущих активных звонков.
         Решить данную задачу мы можем с использованием Hot Standby Routing Protocol (HSRP).
         Что необходимо:
1.    Два идентичных Cisco ISR G2s c лицензией UC Technology Package (SL-29-UC-K9 or SL-39-UC-K9), 1G DRAM памяти и Cisco IOS Software release 15.1.2T или позже.
     Cisco IOS Software release 15.1.2T поддерживает сохранение активных SIP-SIP звонков во время HSRP switchover, но не поддерживает сохранение сигнализации. Поддержка сохранения сигнализации появилась в Cisco IOS Software release 15.2.3T.
2.    Оба маршрутизатора физически должны быть расположены в одной Ethernet LAN.
3.    Конфигурация функционала CUBE должна быть идентична на обоих маршрутизаторах.
4.    Один маршрутизатор явно должен быть определен как HSRP Active, второй – как HSRP Standby
         

вторник, 14 октября 2014 г.

Группа исходящих dial-peer как destination для входящего dial-peer
(Outbound Dial-Peer Group as Inbound Dial-Peer Destination)

Эта функция позволяет в конфигурации входящего dial-peer указать группу исходящих dial-peer как цель маршрутизации входящего звонка. Поддерживается, начиная с IOS 15.4(1)T.
 Если входящий звонок попадает во входящий dial-peer, в котором есть активная группа исходящих dial-peer, то для маршрутизации этого звонка будут выбраны dial-peer из указанной группы. Другие dial-peer никогда не будут использоваться как исходящие для этого звонка. Даже если в указанной группе все dial-peer  в состоянии down.  
В группу можно объединить до 20 dial-peer (как SIP так и H323). Так же, каждому dial-peer можно указать его приоритет в группе, что будет влиять на выбор dial-peer для установления исходящего звонка.
      Пример конфигурации: