Cisco Collaboration Edge, Mobile Remote Access. Полезные ссылки и настройки Firewall Rules
maxalion
Презентация от NetCraftsman и Вильяма Белла:

http://www.netcraftsmen.com/wp-content/uploads/2015/02/02.18.2015_CMUG-UC-Collaboration-Edge-RF01.pdf

Cisco Expressway IP Port Usage for Firewall Traversal с описанием  различных вариантов реализаций и направлений трафика:

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-5/Cisco-Expressway-IP-Port-Usage-for-Firewall-Traversal-Deployment-Guide-X8-5.pdf


Особенности настройки Firewall Rules между Expressway-E, распложенном в DMZ  и Expressway-С (Internal)

Т.к. Expressway-C шлет постоянные keepalives в сторону Expressway-E, то нет необхомости прописывать какие-либо правила доступа от Expressway-E к Expressway-C. Активное соединение всегда поддерживается со стороны Expressway-C!

Настройка Storm Control на интерфейсах коммутатора
maxalion
Хорошая статейка лежит вот здесь:  http://cauew.blogspot.ru/2008/09/storm-control-everything-you-need-to.html

Коротко, по основным пунктам:

1. При задании значения level  в процентах мы задаем уровень загрузки интерфейса данным типом трафика в % от общей пропускной способности порта, в течение traffic-storm-control интервала.

2. При превышении заданного уровня свитч будет отбрасывать трафик данного типа до конца интервала traffic-storm-control.

3. При настройке  Storm Control следует учитывать одну особенность:
Всякий L2 broadcast пакет от носится к мультикасту, но не всякий L2 multicast пакет относится к броадкасту.

Почему так?

Дело в том, что принадлежность пакета к Multicast определяет один бит в MAC адресе, а именно бит I/G (восьмой бит в первом октете). Если он установлен в "1", то пакет считается мультикастовым. L2 репрезентация IP Multicast пакета начинается с 01-00-5E. При переводе в двоичную систему получаем 0000 0001-0000 0000-0101 1110. Соответственно, в каждом мультикаст пакете бит I/G равен "1".
Теперь рассмотрим broadcast пакет. У него MAC адрес выглядит как FF-FF-FF-FF-FF-FF, т.е. все биты установлены в единицу, включая и бит I/G. Т.о. L2 broadcast пакеты, по сути, являются поднабором (subset) L2 multicast пакетов.

Из этой особенности проистекает важное правило:
      При настройке Storm Control на порту необходимо устанавливать значение лимита для мультикаста выше, чем для броадкаста, либо, как минимум, равное ему. В противном случае конфигурация Storm control лимита для broadcast будет бессмысленной из-за влияния на него лимита, настроенного для multicast.

Cisco CUE: настройка IVR для дозвона на внешние номера через голосовой шлюз. Основные моменты
maxalion
В данной статье речь пойдет о CUE версии 8.6, установленном как ПО на платформе Service Ready Engine модуле ISM-SRE-300.
Модуль, соотв., установлен в шасси Cisco ISR G2 2911 через PCX Express слот. Версия софта роутера: 15.2(3)

Задача стояла: средствами функционала IVR (нужна соотв. IVR лицензия на CUE)  обеспечить дозвон до абонента и проиграть ему звуковое оповещение.

Для активации задачи используется http request, отправленный на адрес CUE в формате:

    http(s)://CUE_address:8080/application_name?param1=value1&param2=value2

данный запрос активирует http триггер, созданный на IVR, который запускает привязанный к нему аппликейшен. Более подробно про эту кухню можно прочесть, найдя в сети документ, описывающий работу демо скрипта placecall.aef для CUE IVR. Сдесь же остановлюсь на наиболее значимых моментах в настройке, а также упомяну о граблях, на которые успел наступить в процессе.

Итак:

1) Функционал IVR лицензируется отдельно, без привязки к лицензии Voicemail. Согласно конфиг гайду, CUE IVR  работает либо с CUCM (интеграция через jtapi), либо с CUCME (sip). Т.е. это означает, что без CUCM или CUCME данный функционал работать не будет. В моем случае никакого CUCM нет, а есть только ISR 2911 с установленным в него модулем ISM, на котором крутится CUE, и E1 PRI интерфейс в сторону корпоративной телефонной станции, которая принимает входящие вызовы от шлюза. Если у нас стоит задача генерировать c помощью IVR вызовы, отправляя их на голосовой шлюз 2911, то на самом шлюзе необходимо поднять функционал CUCME,  а для этого там должна быть активирована лицензия UC.

2) на флеше роутера обязательно должны лежать файлы GUI именно для текущей версии CME. проверяем версию командой:

router# show telephony-service
CONFIG (Version=9.5)
=====================
Version 9.5
.

Далее указываем местоположение файлов GUI на флеше (заодно включаем сервис hhtp):

ip http server
ip http authentication local
ip http path flash:/gui


а также задаем минимальный уровень привилегий для операций с файлами:

file privilege 0

если таких файлов на флеше шлюза нет (обычно лежат в директории flash:/gui/ ), то лезем на cisco.com, далее идем по пути:
Downloads Home > Products > Unified Communications > Call Control > Mid-Market Call Control > Unified Communications Manager Express > Unified Communications Manager Express Complete Support File Set s, откуда  скачиваем tar архив для нашей версии CME

Если этот архив большой (cme-153-2Tv1), то распаковываем его с помощью 7-zip, и файлы, лежащие в субдиректории CME GUI, запаковываем снова в tar (кстати, в этой же папке лежит файл CME_GUI_README, который расскажет, к какой версии CUCME применим данный набор файлов). Далее копируем и разворачиваем этот архив по TFTP на флеш шлюза в папку flash:/gui командой:

archive tar /xtract tftp://X.X.X.X/gui.tar flash:/gui

Пункт 2 я выполнил в самую последнюю очередь. При этом сначала залил на флеш GUI файлы для версии CME выше той, что была установлена у меня. Несмотря на то, что вроде как интеграция CUE с CUCME через Web консоль прошла успешна, результа не последовало: SIP Invite, который должен генерироваться CUE в сторону CUCME в результате выполнения команды "Place Call" в скрипте IVR, отсутствовал. Т.е. со стороны CUE не быо даже попыток установить соединение.  Перезагрузка модуля также не помогла.  Наконец, прочитав  CME_GUI_README, я осознал, что данный набор к моей версии неприменим. Удалив старый набор с флеша, я залил туда новый, соответствующий версии CUCME, и только после очередной перезагрузки модуля SIP наконец пошел.

3) на шлюзе:

interface ISM0/0
 ip unnumbered GigabitEthernet0/0                     ! маппим IP процессинг данного интерфейса к существующему IP интерфейсу
 service-module ip address X.X.X.2 255.255.255.0
 !Application: CUE Running on ISM
 service-module ip default-gateway X.X.X.1         ! адрес шлюза, либо адрес другого устройства, который использует шлюз для резолва сети 0.0.0.0 /0


4) задаем CUCME web administrator. потом используем его на CUE для проведения интеграции с CUCME

telephony-service
 web admin system name cisco password cisco


5) заодно не забываем  создать дайл-пиры для обработки вход./исход. вызовов.

dial-peer voice 10 voip
 destination-pattern 9999
 session protocol sipv2 
 session target ipv4:X.X.X.2         ! адрес CUE, указанный как  service-module ip address
 dtmf-relay sip-notify                    ! sip-notify - хорошо)
 codec g711ulaw                          ! помним: CUE понимает только G711 u-law

dial-peer voice 20 pots
 description Internal phones
 destination-pattern ^98..........$
 port 0/0/0:15
 forward-digits all


6) сервер, с которого шлется http request на CUE, должен находиться в IP сегменте, отличном от сегмента, в котором находится CUE. Т.е. между сервером и CUE должен быть как минимум один IP hop. Во всяком случае, у меня заработало только так.

7) проверяем, что CUE установлен  в режим интеграции с CUCME:
CUE# sh call-agent

либо меняем на нужный командой:
CUE# call-agent cme

Учитываем, что после этого потребуется перезагрузка модуля, и все существующие настройки, связанные с интеграцией CUE с CUCM (jtapi) будут удалены. Также эту процедуру можно выполнить из Web консоли (меню Administration)

Важно! Если версия софта CUE ниже 7.1(x) (например, мы говорим о CUE модуле для ISR G1), то команда call-agent там отсутствует, и для изменения типа интеграции потребуется делать как минимум reset to factory default модуля, а как максимум Re-image софта.

8) если для голосового уведомления пользователя требуется проигрывать файлы с разным (заранее не предопределенным) содержимым, то можно заранее положить сгенерированный звуковой файл на сам модуль CUE. Как это сделать? Например, так: сервис, использующий наш IVR для дозвона, перед тем как активировать ЕГО выполнение через http запрос , сначала выполняет свой внутренний скрипт, задача которого - открыть телнет (ssh) сессию на голосовой шлюз , далее из IOS CLI  шлюза провалиться на CLI модуля CUE (CUE не поддерживает ни telnet, ни ssh), и там выполнить команду:

ccn copy url ftp://X.X.X.X/Welcome.wav prompt Welcome.wav

..., скопировав  т.о. новый звуковой файл с  ftp сервера на флеш СUE. Далее уже IVR скрипт сможет проиграть данный файл со своего флеша пользователю.
К сожалению, приходится изголяться таким образом, т.к. IVR сам не умеет забирать звуковые файлы удаленно.


В общем как-то так.
Tags: , , , , ,

Cisco UCCX: запись (чтение) файлов на внешние хранилища
maxalion
Запись/чтение файла на FTP / SFTP:
      https://supportforums.cisco.com/document/140786/uccx-readwrite-fromto-sftpftp

Запись/чтение файла на Windows Share:
      https://supportforums.cisco.com/document/96366/uccx-8x-how-playwrite-file-prompts-fromto-windows-shares


Общий смысл (опробовано для варианта Windows Share):
  1) Скачиваем необходимый файл файл JAR , подгружаем его в UCCX ,
  2) рестартуем сервис UCCX EngIne. После этого UCCX Script Editor перестает ругаться на строчки кода скрипта, необходимые для записи файл. Скорее всего, имеет смысл сразу рестартовать весь сервер (шаг 3). Но я шел именно по такому пути, поэтому упоминаю этот шаг.
  3) рестартуем сервер UCCX полностью. Не сделав этого, получим ошибку на этапе приязывания файл скрипта к аппликейшену
  4) ТУПО ВСТАВЛЯЕМ предложенные строки в код нашего скрипта. В принципе, при соблюдении всех замечаний в документе и перезагрузки сервера у меня все заработало с первого раза.

Запись и мониторинг звонков в Cisco UCCX - уточнения
maxalion

Функционал Call Recording and Silent Monitoring требует наличия лицензии Enhanced или Premium

UCCX предоставляет два подхода к решению вопроса записи и мониторинга звонков:
1) VoIP monitor service - перехват пакетов RTP идет через SPAN порт, поднятый на коммутаторе в сторону выделенного интерфейса сервера UCCX (?? уточнить).
2) Desktop Monitoring Service - перехват пакетов RTP через Cisco CAD. Телефон агента просто дублирует пакеты RTP на рабочую станцию агента с установленным на ней приложением CAD. В данном случае станция агента должна быть подключена к его телефону в PC port, а для самого телефона включена опция "SPAN to PC Port". Когда супервизор захочет промониторить/записать агента, то CSD (Supervisor Desktop) шлет сообщение CAD на переправку RTP на рабочую станцию супервизора. Этот метод требует наличия установленного приложения CAD  у агента, а также телефона, поддерживающего Desktop Monitoring.
(http://wiklunds.wordpress.com/2012/06/03/uccx-8-5-cadcsd-call-recording-and-silent-monitoring/)

Запись/мониторинг медиа потоков возможны только с кодеками g.711 и g.729. Кодек g.722 не поддерживается. Encrypted потоки не поддерживаются.

Сервис агента на телефоне IP Phone Agent поддерживает запись/мониторинг только через SPAN port monitor
Сервис агента на телефоне IP Phone Agent не может быть настроен на автоматическую запись звонков.
(http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_9_0/design/UCCX_BK_UD5B347F_00_uccx-solution-reference-network-design/UCCX_BK_UD5B347F_00_uccx-solution-reference-network-design_chapter_010.html)

Важное замечание касательно использования серверов Cisco UCS в качестве платформы для UCCX и применения функций записи и мониторинга на них:
Span-based silent monitoring and recording are not supported on UCS B-series.
(http://www.uccx.net/wp-content/uploads/2013/06/UCCX-Hardware-and-Software-Compatibility-Guide.pdf)

The agents extension should be Unique on Call Manager, as the lines that are going to be monitored or recorded cannot be shared lines.

телефоны IP Phone 7902, 7905, 7912, 7920 не поддерживает Desktop Monitoring/Recording -  для них недоступна функция "Span to PC Port", либо у них нет порта для подключения PC

7940 and 7960 Cisco IP Phones do not support the span to PC port feature, all data is automatically sent to the PC port.

В случае, если в качестве хранилища записей используется сам UCCX сервер (кластер), действуют следующие ограничения на объем, выделенный под них:
The amount of disk storage allocated for recordings on a single-server non-high-availability deployment of Unified CCX is 2.6 GB.. On a two-server high-availability deployment of Unified CCX, the recordings are alternated between the two servers in a round-robin fashion to provide load balancing and redundancy. Hence the amount of disk storage allocated on each server is 2.6 GB for a combined solution storage of 5.2 GB.

Официальное руководство по настройке периодического сброса записей на некий ресурс:
http://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/crs/express_8_5/troubleshooting/guide/cad85ccxtg-cm.pdf    раздел: Exporting Recordings From CAD
Общий смысл: выполняем набор команд через BAT файл
1) забираем файлы .raw на ftp/sftp сервер
2) конвертируем raw (2 потока) в wav
3) сбрасываем результат в папку
4) задаем периодическое выполнение данного файла

Хорошее руководство по настройке сабжа:
http://wiklunds.wordpress.com/2012/06/03/uccx-8-5-cadcsd-call-recording-and-silent-monitoring/

Хорошее руководство по настройке автоматической записи разговора с момента поднятия трубки агентом CAD
http://dreamforccie.wordpress.com/2010/03/30/automatic-call-recording-at-uccx/

CUCM 10 и телефон 7960: не показывает LABEL для Speed Dial на экране телефона и модуля 7914
maxalion
Тестировал на CUCM версии 10.0.1.10000-24.

Описание проблемы:  При создании  Speed Dial  для телефона 7960 (SCCP)  и его модуля расишрения 7914  экран телефона отображает только номер SD, а не фамилию абонента (поле Label).

Решение:
Проблема возникает из-за версии phone load , которую по умолчанию применяет CUCM для телефона 7960.   В моей версии CUCM  для 7960 имеется прошивка v.7.2(3).
Проблема решилась установкой версии прошивки 8.1.1  (cmterm-7940-7960-sccp.8-1-1.cop.sgn) .  При этом, согласно сопровождающему файлу readme.txt для прошивки, при использовани телефона совместно с модулем расширения 7914 необходимо сначала проапгрейдить firmware модуля до версии S00105000400.

З.Ы. Сначала я попытался накатить на телефон 7960 просто последнюю доступную прошивку с сайта cisco.com. На данный момент это версия 8.1(2)SR2   (cmterm-7940-7960-sccp.8-1-2SR2.cop.sgn).  Такой кавалерийский наскок ожидаемо закончился неудачей. Дальнейшее выяснение причины привело к чтению все того же файла readme.txt, для версии прошивки. В котором черным по белому было указано: перед установкой 8.1(2)SR2 сначала необходимо накатить версию 8.1.1 ()

З.З.Ы.  Да, и не забываем рестартовать сервис tftp после инсталляции файла прошивки на сервер.

Кое-какие аксиомы для EIGRP
maxalion
source http://habrahabr.ru/post/126450/

Для суммарного маршрута EIGRP ставит в качестве метрики минимальную метрику из всех агрегированных маршрутов.


EIGRP автоматически суммирует до полноклассовых только connected сети, полученные по EIGRP маршруты не автосуммируются даже если auto-summary включена (для того, чтобы суммировать такие маршруты нужно использовать ручную суммаризацию на каждом из интерфейсов).


EIGRP не знает о топологии сети ничего, кроме направления, в котором конкретная сеть достижима (next hop) и ее метрику.
Tags:

temas
maxalion
На самом деле не совсем корректно писать об интеграции сервера Presence (или CUPS) с LDAP сервером потому, что  в действительности Presence сервер  никак не интегрируется с LDAP (в отличие, например, от сервера CUCM). Он даже не общается с LDAP серверами. Вместо этого сервер CUPS получает информацию о пользователях LDAP от сервера CAllManager (CUCM) по протоколу AXL.

Настройки же LDAP на сервере CUPS предназначены для того, чтобы клиент Personal Communicator (CUPC, Cisco Jabber) мог искать доменных пользователей в корпоративном каталоге. Предварительно настроенный на Presence сервере профайл с настройками LDAP  спускается на клиентов CUPC, и далее при поиске пользователей клиент отправит в сторону LDAP сервера запрос, используя данные

Различия между MLS и Fast switching
maxalion
Fast Switching

Технология Fast Switching основана на использовании специальной cache таблицы. Когда пакет с неким destination впервые приходит на входящий интерфейс маршрутизатора (L3 коммутатора), то этот пакет будет обработан маршрутизатором как Process Switched, т.е. CPU роутера будет непосредственно вовлечен в п процесс принятия решения о том, куда пакет должен быть отправлен (Forwarding decision making). Идея концепции Fast Switching заключается в следующем: почему бы нам не закэшировать результаты поиска IP Next Hop и L2 Lookup, которые мы сделали при обработке первого пакета, в некоторую таблицу,  и не использовать затем эти данные для коммутации следующих пакетов, предназначенных тому же destination? Таблица эта называется Fast Switchinhg Cache.
Т.о., имея в Fast Switchinhg Cache свежую запись для некоторого destination, мы можем быстро определить исходящий порт для предназначенных ему пакетов, задействуя минимум ресурсов центрального процессора.
Заметим, что на маршрутизаторах такой процесс коммутации происходит in software.
 Fast Swtiching Cache также иногда именуется как Demand-based Switching Cache.

MLS

 - Это, в общем-то, тот же Fast Switching,  с одним отличием: сам метод кеширования реализован хардварно. Например, на супервизорах для платформ 6500/7600 он реализован на уровне Policy Feature Card (PFC). Получается, что  для обработки первого прибывшего пакета в потоке с заданным destination будет задействован центральный процессор (RP) карты MSFC супервизора. Все же последующие пакеты в потоке будут скоммутированы in hardware средствами PFC на нужный исходящий интерфейс. Если destination адрес не найден в кеше, то пакет будет отправлен на MSFC, где процессор попытается создать кеш запись для дальнейшего форвардинга пакетов с данным destination.

К сожалению, при частых изменениях в routing table технология Fast Switching Cache теряет свою эффективность. Дело в том, что если в routing table происходят изменения, то требуется очистка кэша. Каждый раз, когда часть кэша должна быть удалена, часть пакетов будет обработана как Process Switched, Если частота изменений в routing table становится достаточно большой, то число пакетов, коммутируемых как Demand-based Switching/Fast Switching, становится мало, и использование механизма кешинга не добавляет эффективности.

NTP, особенности работы и настройки протокола на Cisco устройствах
maxalion
Оказывается!....
  NTP сервис на cisco устройствах можно отключить командой....no ntp. В общем-то по умолчанию NTP сервис и так отключен. Активируется же он на устройстве введением любой команды с префиксом ntp, будь то ntp master, ntp peer, ntp server и т.д.
Кроме того, весьма важно, что как только сервис ntp на устройстве стартовал, устройство само может раздавать время ниже стоящим устройствам, если они его об этом попросят. Т.е. получается, что совершенно необязательно давать команду ntp master, чтобы устройство начало раздавать время всем желающим. Команда же ntp master предназначена для того, чтобы наш cisco -девайс смог раздавать время, используя в качестве clock source свои встроенные аппаратные часы с батарейкой. Далеко не не все Cisco платформы (в т.ч. и маршрутизаторы) обладают энергонезависимым источником питания типа "батарейка", а соответственно и такой возможностью выступать в роли ntp master. Но, как оказывается, это не повод для расстройства, т.к., получив при помощи команды "тntp server" время от какого-то другого источника, девайс в любом случае сможет поделиться им со всеми желающими.
К-да "ntp update-calendar" , периодески считывает полученное по протоколу NTP время в свои хардварные часы, т.о. синхронизируя их.
К-да "clock update-calendar" - это способ вручную провести синхронизацию аппаратных часов со временем, полученным по NTP.
К-да "clock read-calendar"  - это команда "clock update-calendar" наооборот.  С её помощью мы считываем время из аппаратных часов устройства и "засылаем" его в NTP.

Для чего нужна команда "ntp peer" ?

Вот для чего: допустим, у нас в сети есть два маршрутизатр, R1 и R2, и каждый из них синхронизируется от своего надежного источника точного времени. На обоих маршрутизаторах даны команды "ntp peer", В качестве пира у R1 прописан R2,   а у R2 соотв. R1. В случае, если источник времени, от которого синхронизируется R1, умрет, то R1 синхронизируется от R2, у которого доступ к своему reliable NTP clock source  не пропал.
Tags: ,

?

Log in