Уважаемые коллеги,
подскажите, пожалуйста, может кто сталкивался... Уже всю голову поломал...При попытке регистрации ИП телефона (Cisco 3905) работающего в удаленном офисе через ВПН-тоннель (IPSEC VPN) на CCM-е 9.1 (BE6000) телефон не регистрируется на колл-менеджере. (на телефоне висит статус - "регистрация", в коллменеджере - телефон с данным мак-адресом не зарегистрирован)
При этом с колл-менеджера телефон достижим (пинги ходят в обе стороны).У меня используется такая схема (Дабы не привлекать экстрасенсов ) :
Центральный офис (Cisco 2821) терминирует на себе несколько ВПН тоннелей (через открытый интернет) из удаленных офисов (Cisco 871)
для маршрутизации используем OSPFВ центральном офисе имеется несколько разных подсетей, маршрутизация между ними (тем же оспф-ом) работает отлично, и включив телефон в центральном офисе в подсеть отличную от войсовой (по сути - тоже удаленную подсеть только без использования тоннелей), телефон регистрируется на колл-менеджере без проблем. Из чего делаю вывод что проблема с регистрацией в удаленных офисах не в маршрутизации как таковой...
При попытке копнуть поглубже - появилось предположение, что телефон находясь в удаленном офисе не может скачать по ТФТп некие конфигурационные файлы с колл-менеджера... Последнее сообщение об ошибке в логе на телефоне - 1970/01/01 00:03:19:423 File Not Found : SEP08CC6830F116.cnf.xml
Как выглядят тоннели? Вот кусочки конфига... Вроде бы ничего особенного...:
В центральном офисе:
Код:
crypto isakmp policy 100
encr 3des
authentication pre-share
crypto isakmp key KEY address EXT.OFF.ADD.RES
crypto isakmp keepalive 10 periodiccrypto ipsec transform-set 3DES_SHA esp-3des esp-sha-hmac
crypto ipsec df-bit clearcrypto ipsec profile IPSEC_PROF
set transform-set 3DES_SHAinterface Tunnel6
description -=IPSec tunnel to 225.1 over InterNet=-
bandwidth 50000
ip address 192.168.253.101 255.255.255.252
ip mtu 1420
ip ospf authentication message-digest
ip ospf message-digest-key 5 md5 OSPF_PASS
tunnel source GigabitEthernet0/1.89
tunnel destination EXT.OFF.ADD.RES
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROF sharedrouter ospf 100
router-id 10.205.221.1
log-adjacency-changes
redistribute static
passive-interface default
no passive-interface GigabitEthernet0/0.120
no passive-interface Tunnel0
no passive-interface Tunnel4
no passive-interface Tunnel5
no passive-interface Tunnel6
network 10.205.221.0 0.0.0.255 area 0
network 192.168.5.0 0.0.0.3 area 0
network 192.168.253.0 0.0.0.255 area 0В удаленном офисе соответственно такой конфиг:
Код:
crypto isakmp policy 100
encr 3des
authentication pre-share
crypto isakmp key KEY address IP.ADR.OF.COcrypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10 periodic
crypto ipsec transform-set 3DES_SHA esp-3des esp-sha-hmac
crypto ipsec df-bit clearcrypto ipsec profile IPSEC_PROF
set transform-set 3DES_SHAip dhcp pool 225LAN
network 10.205.225.0 255.255.255.0
default-router 10.205.225.1
dns-server 10.205.221.11 10.205.227.10
option 150 ip 10.205.222.201
interface Tunnel1
description -=IPSec tunnel to CO=-
bandwidth 50000
ip address 192.168.253.102 255.255.255.252
ip mtu 1420
no ip route-cache cef
no ip route-cache
ip ospf authentication message-digest
ip ospf message-digest-key 5 md5 OSPFKEY
tunnel source FastEthernet4
tunnel destination IP.ADR.OF.CO
tunnel mode ipsec ipv4
tunnel protection ipsec profile IPSEC_PROF sharedinterface FastEthernet4
ip address EXT.OFF.ADD.RES 255.255.255.240
no ip unreachables
no ip route-cache cef
no ip route-cache
duplex auto
speed autorouter ospf 100
router-id 10.205.225.1
log-adjacency-changes
passive-interface default
no passive-interface Tunnel1
network 10.205.225.0 0.0.0.255 area 0
network 192.168.253.0 0.0.0.255 area 0Если забыл чего - маякните плиз.
Т.е. весь полностью траффик удаленного офиса заворачивается в ВПН тоннель на Центр.офис. Далее уже работает ОСПФ в ЦО.
Никаких ацесс-листов на внутренних интерфейсах нет... На внешних - не важно, т.к. трафик упакован внутрь тоннелей, которые в свою очередь для обычного траффика работают нормально...Как вариант может что не так с
ip mtu 1420 на тоннельных интерфейсах?В общем что то странное - если есть идеи прошу высказаться...
Заранее спасибо!
>[оверквотинг удален]
> Если забыл чего - маякните плиз.
> Т.е. весь полностью траффик удаленного офиса заворачивается в ВПН тоннель на Центр.офис.
> Далее уже работает ОСПФ в ЦО.
> Никаких ацесс-листов на внутренних интерфейсах нет... На внешних - не важно, т.к.
> трафик упакован внутрь тоннелей, которые в свою очередь для обычного траффика
> работают нормально...
> Как вариант может что не так с
> ip mtu 1420 на тоннельных интерфейсах?
> В общем что то странное - если есть идеи прошу высказаться...
> Заранее спасибо!о чем вы говорите?какой mac? почитайте основы маршрутизации, чтобы узнать, где и когда мас меняется при маршрутизации
> о чем вы говорите?какой mac? почитайте основы маршрутизации, чтобы узнать, где и
> когда мас меняется при маршрутизацииСорри за оффтоп, Ваш ответ предназначался в данную тему? где у меня упоминался MAC?
>> о чем вы говорите?какой mac? почитайте основы маршрутизации, чтобы узнать, где и
>> когда мас меняется при маршрутизации
> Сорри за оффтоп, Ваш ответ предназначался в данную тему? где у меня
> упоминался MAC?в коллменеджере - телефон с данным мак-адресом не зарегистрирован)
Какой протокол используете? SCCP?
> Какой протокол используете? SCCP?А, ок ) точно ))) Сорри не так выразился - с этим идентификатором )
А с кодеками чуть интереснее (как оказалось далее)...
Есть 2 типа телефонов.
SCCP - CP8941
SIP - CP3905
Оба типа в сети колл-менеджера регаются и работают без проблем.
Выношу их за ВПН... Изначально не коннектятся к колл-менеджеру оба апарата.Оставил эту конструкцию на ночь... пришел утром - и о чудо! 8941 зарегистрирован!
Для эксперимента поставил в удаленную сеть еще один 8941 - тоже сначала не регистрировался, часов через несколько - зарегистрировался...
Но ни один СИПовский телефон (3905) так и не поднялся...
Включена ли на UCM авторегистрация (если телефон руками не прописан)? Правильно ли настроен DHCP там где не работает телефон? Там в option 150 должен быть указан адрес UCM, кроме того домен должен совпадать с тем, который прописан в UCM.
> Включена ли на UCM авторегистрация (если телефон руками не прописан)?Да, авторегистрация включена.
Более того, обычно, телефон я сначала включаю в сети колл-менеджера, он регистрируется, все ок.
Только потом выношу его в удаленную сеть.DHCP в удаленной сети работает, 150 есть (конфиг приводил). Прописывал все статикой - эффекта 0.
Думали что то с security profile. Телефон полностью ресетили. Включали в удаленной сети полностью чистый телефон (без предварительной регистрации) - эффект тот же, телефон замер в статусе "регистрация"...Прописывали телефон на ССМ полностью руками - без авторегистрации... в сти колл-менеджера работает, в удаленной нет.
Вопрос скорее где-то в канальном уровне...
Не забывайте про домен. Недавно натыкался - юниксоиды в dhcp сменили отдаваемый домен и телефон не регистрился, он должен соответствовать тому что в UCM. Если на сети трафик нигде не режется - смотрите трейсы callmanager в RTMT.
> Не забывайте про домен.Да, спасибо. Перепроверил на всякий случай еще раз - 3905 телефон получил домен корректно...
SCCP телефон пока откидываю, они начали регаться но с большой задержкой. Голос и видео работают нормально...
Я даже на ДНС сервере прописывал телефон ручаками на прямой и обратный резолвинг с его SEPxxx именем... По имени телефон достижим...
Никаких фильтров/АЦЛов на канале/интерфейсах сети нет... Тоже в первую очередь об этом думал, но нет....
Паралельно открыл TAC в Циске... пока результат практически тот же что и Вы посоветовали:
Packet Capture ON CUCM
https://supportforums.cisco.com/docs/DOC-11599Packet Capture on Cisco IP phone
https://supportforums.cisco.com/docs/DOC-11735Запросил от Циски детально процедуру регистрации телефона - что бы хоть понимать какие пакеты ловить... Будем анализировать что творится в сетке... Отпишусь как что нащупаем...
> Я даже на ДНС сервере прописывал телефон ручаками на прямой и обратный
> резолвинг с его SEPxxx именем... По имени телефон достижим...Это лишнее, в случае если system -> server указан по имени, а не по адресу, важно чтобы домен отдаваемый в DHCP совпадал с доменом из этого поля. Это теория, возможно важен organization top level domain из enterprise параметров, может что-то еще. Глубоко причину не копал, помогло корректное указание в DHCP.
> Паралельно открыл TAC в Циске... пока результат практически тот же что и
> Вы посоветовали:
> Packet Capture ON CUCM
> https://supportforums.cisco.com/docs/DOC-11599
> Packet Capture on Cisco IP phone
> https://supportforums.cisco.com/docs/DOC-11735Снимать трафик на данном этапе считаю излишним, куда проще и информативнее глянуть в RTMT трейсы, и только если там ничего не будет есть смысл снифить.
> Запросил от Циски детально процедуру регистрации телефона - что бы хоть понимать
> какие пакеты ловить... Будем анализировать что творится в сетке... Отпишусь как
> что нащупаем...Дока что конкретно учитывается при регистрации телефона была бы очень интересна, а то вроде как общее понимание что, как и в какой последовательности есть, да деталей нет.
Кстати, на счет сертификатов момент вспомнился - если он вставился, сбросом телефона он не убивается, руками с телефона нужно убивать. Но эту проблему видно в логах телефона.
Как вариант попробуйте на голосовом vlan прописать helper address на UCM.