Иванов Денис Опубликовано 8 февраля, 2013 · Жалоба Cisco SCE 2020 против SIP телефонов Имеется Cisco SCE 2020 3.8.0-classic Build 127 в режиме full functionality, через который подключена сеть из нескольких ПК и аппаратных SIP телефонов. (inline topology) Для каждого ПК и телефона в SCE добавлены подписчики. Всё работает, но если любому из подписчиков сменить package на тот, в котором установлено действие block the flow для default rule, а затем сменить package на тот, в котором нет никаких ограничений (например default package), то SCE не пропускает UDP пакеты от подписчика с портом назначения 5060 (SIP), но при этом пропускает все остальные. (в т.ч. UDP) Это видно в WireShark, которым я собирал трафик до и после SCE. В результате, если подписчик является телефоном, то он больше не работает. А если подписчик является ПК, то всё что касается сети работает, кроме программных телефонов. (twinkle например) Даже спустя сутки SCE продолжает блокировать SIP пакеты от упомянутых выше подписчиков. Однако, если с ПК попинговать АТС, то через некоторое время SCE перестаёт блокировать SIP пакеты от этого ПК. Также, сли в ethernet розетку аппартного телефона подключить ноутбук и с него попинговать АТС, то и этот телефон через некоторое время начинает работать. Если выключить и включить интерфейс LineCard 0, то SCE перестаёт блокировать SIP пакеты от проблемных подписчиков. SCE2000(config if)#>shutdown SCE2000(config if)#>no shutdown Даже если в Service Configuration Editor -> Policies -> Filtered Traffic добавить Bypass правило для любых пакетов проблемного подписчика в обе стороны, то как и задумано SCE пропускает любые пакеты этого подписчика, но всёравно блокирует его SIP пакеты. От отчаяния начал пробовать всё, что по моему может быть связано с работой SIP пакетов: В Service Configuration Editor -> Policies -> Service Security выключил All atack filter, Anomaly detection, Spam detection and mitigation - не помогло. Попробовал убрать SIP порты 5060 и 5061 из Service Configuration Editor -> Classification -> Configuartion -> Policies -> System Settings -> Advanced Options -> CLassification -> UDP ports for which flow should be opened on first packet Не помогло. Отключил flow filter SCE2000(config if)#>no flow-filter partition all Не помогло. Переключил Flow Open Mode c Enhanced на Classical SCE2000(config if)#>shutdown SCE2000(config if)#>flow-open-mode classical SCE2000(config if)#>no shutdown Не помогло. Активировал Subscriber Operation Log Messages (config)#> management-agent sce-api logging Воспроизвёл "смерть" телефона и посмотрел все логи SCE2000#>more user-log Ничего криминального по IP телефона, его подписчику, SIP, 5060 и UDP SCE2000#>more line-attack-log Никаких записей после того как отключил All atack filter, Anomaly detection, Spam detection and mitigation (cм. ывше) SCE2000#>logger get debug-log file-name debug.log SCE2000#>more debug.log Ничего криминального по IP телефона, его подписчику, SIP, 5060 и UDP Удалил все упоминания о VoIp из Service Configuration Editor -> Policies -> Global Policies и всех Package - не помогло. Текущий конфиг: SCE2000#>show running-config #This is a general configuration file (running-config). #Created on 08:06:19 UTC FRI February 8 2013 #cli-type 1 #version 1 access-list 1 permit 10.1.2.8 no service telnetd ip access-class 1 ip ssh no ip ssh SSHv1 no management-agent notifications notification-list 1417,1418,804,815,1404,1405,1406,1407,1408,400 no management-agent notifications notification-list 402,421,440,441,444,445,446,450,437,457 no management-agent notifications notification-list 3593,3594,3595,10040 interface LineCard 0 aggregative-global-controllers aggregative-global-controller-dynamic mode suspend aggregative-global-controller-dynamic mode active connection-mode inline on-failure bypass no silent no shutdown flow-open-mode classical service-bandwidth-prioritization-mode global protocol-pack version 3.8.0PP32 flow-filter partition name "ignore_filter" first-rule 4 num-rules 32 flow-filter partition name "udpPortsToOpenBySw" first-rule 40 num-rules 21 no attack-filter protocol TCP no attack-filter protocol UDP no attack-filter protocol ICMP attack-direction single-side-both no attack-filter protocol other attack-direction single-side-both attack-filter subscriber-notification ports 80 replace spare-memory code bytes 3145728 interface FastEthernet 0/0 ip address 10.1.2.119 255.255.255.0 interface FastEthernet 0/1 ip address 10.1.2.119 255.255.255.0 interface GigabitEthernet 0/1 interface GigabitEthernet 0/2 interface GigabitEthernet 0/3 interface GigabitEthernet 0/4 exit ip default-gateway 10.1.2.254 line vty 0 4 exit interface Mng 0/1 exit interface Mng 0/2 exit username sce secret 5 ******** aaa authentication login default local aaa authentication enable default none interface LineCard 0 subscriber anonymous-group name "Anonymous Group" IP-range 0.0.0.0:0x00000000 exit no subscriber LEG dhcp-lease-query subscriber LEG dhcp-lease-query servers 127.0.0.1 logger device SCE-agent-Statistics-Log max-file-size 204800 management-agent property "com.pcube.management.framework.install.activation.operation" "Install" management-agent property "com.pcube.management.framework.install.activated.version" "3.5.5 build 262" management-agent property "com.pcube.management.framework.install.activated.package" "SCA BB" management-agent property "com.pcube.management.framework.install.activation.date" "Fri Nov 30 06:52:50 GMT+00:00 2012" management-agent sce-api logging Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Иванов Денис Опубликовано 12 февраля, 2013 · Жалоба Попробовал "поиграться" с определениями протокола SIP в Subscriber Configuration Editor -> Classification -> Configuration -> Classification -> Protocols -> SIP В Protocol Elements попробовал убрать сигнатуру SIP, оставив сигнатуры Generic - не помогло. Затем наоборот: убрал Generic, оставил SIP - не помогло. И наконец вообще удалил протокол SIP - не помогло. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
necrozz Опубликовано 12 февраля, 2013 · Жалоба Есть такая проблема. Шасси 8000, софт 3.7.2, pp 3.7.2PP31. Наблюдается только у части сабов. Со временем, как показала практика, проблема самопроизвольно пропадает. Причину найти не удалось ( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Иванов Денис Опубликовано 15 февраля, 2013 · Жалоба Т.к. не помогает даже добавление Bypass правил для подписчиков-телефонистов в Service Configuration Editor -> Policies -> Filtered Traffic, решил попробовать еще что нибудь: В Service Configuration Editor -> Classification -> Configuration -> Classification -> Zones добавил зону SIP Servers, в которую добавил несколько IP наших SIP серверов. В Service Configuration Editor -> Classification добавил службу SIP Servers (протокол - любой, инициирующая сторона - любая, зона - SIP Servers, flavor - любой). И в каждом Package добавил правило c действием Control the flow's characteristics для службы SIP Servers. В результате телефоны больше не отключаются. Но как понимаете, доступны только перечисленные в зоне SIP сервера. :( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Иванов Денис Опубликовано 15 февраля, 2013 · Жалоба Т.к. не помогает даже добавление Bypass правил для подписчиков-телефонистов в Service Configuration Editor -> Policies -> Filtered Traffic, решил попробовать еще что нибудь: Фантастика... Сработало следующее Bypass правило: transport type: UDP, arrive from either side, subscriber-side IP: any, network-side IP: any, subscriber-side port: 5060-5061, network-side port: 5060-5061 Что странно, т.к. до этого пробовал добавить Bypass правило для любого трафика подписчика-телефониста: transport type: any, arrive from either side, subscriber-side IP: IP подписчика, network-side IP: any, subscriber-side port: any, network-side port: any и оно не работало. В результате добился того, что SCE тупо пропускает SIP пакеты. Хоть что-то... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
apes Опубликовано 16 июня, 2014 · Жалоба Подниму тему. На SCE 8k кто как решал проблему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
catalist Опубликовано 16 июня, 2014 · Жалоба у нас на 2020 тоже есть такая проблема причём у одного конкретного саба, решили путём выноса саба на железку перед сце Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
necrozz Опубликовано 20 июня, 2014 · Жалоба Подниму тему. На SCE 8k кто как решал проблему? Да никак ( Контракта нет, проблема ползет из версии в версию... Пролечить до конца у нас не получилось никак. Так они и всплывают периодически. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
raveren Опубликовано 28 октября, 2014 · Жалоба На шасси 8K, софт 3.7.5, pp PP28B12 проблем с SIP не фиксировали за всё время. По крайней мере жалоб не было. Не так давно обновил софт до 4.2.0, pp PP43B7. Сразу появился один абонент, у которого перестал работать SIP (udp 5060). Никто так и не поборол проблему? Только через Bypass? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...