Странные подвисания ИКМ, vigogne, 16-Окт-12, 09:21 [смотреть все]Добрый день!Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1. Запустили их в работу по уже отлаженному сценарию, но у всех у них наблюдался такой баг: иногда связь становилась либо односторонней, либо не было вообще, хотя сигнализация проходила всегда. На большинстве из них проблема решилась сменой IOS на 12.4(24)T. Но одной это не помогло и она все также морочит нам голову. Симптомы: не периодически, по неустановленным причинам слышимость становится либо односторонней либо пропадает совсем. Потом может либо также сама собой восстановиться, либо нет, бывает, что помогает только перезагрузка циски, либо станции (но станция очень ненадежная штука, поэтому безопаснее циску). По дебагам в эти моменты видим такое: Oct 16 04:16:39.565: ISDN Se0/1/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0014 Sending Complete Bearer Capability i = 0x9090A3 Standard = CCITT Transfer Capability = 3.1kHz Audio Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98393 Exclusive, Channel 19 Progress Ind i = 0x8283 - Origination address is non-ISDN Calling Party Number i = 0x0183, '34504' Plan:ISDN, Type:Unknown Called Party Number i = 0xC1, '7459487461' Plan:ISDN, Type:Subscriber(local) Oct 16 04:16:39.569: ISDN Se0/1/0:15 Q931: Received SETUP callref = 0x8014 callID = 0x008B switch = primary-net5 interface = User Oct 16 04:16:39.585: ISDN Se0/1/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8014 Channel ID i = 0xA98393 Exclusive, Channel 19 И на этом стоит секунд 5-7, затем отбивается вот так: Oct 16 04:16:54.589: ISDN Se0/1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x8014 Cause i = 0x8092 - No user responding Progress Ind i = 0x8188 - In-band info or appropriate now available Oct 16 04:16:54.597: ISDN Se0/1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x0014 Oct 16 04:16:54.601: ISDN Se0/1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8014 В нормальном состоянии после CALL_PROC с указанием канала должен идти PROGRESS: Oct 16 04:20:00.602: ISDN Se0/1/0:15 Q931: TX -> PROGRESS pd = 8 callref = 0x801C Progress Ind i = 0x8282 - Destination address is non-ISDN Вот часть конфига: interface Serial0/1/0:15 no ip address ip virtual-reassembly max-reassemblies 1024 encapsulation hdlc ip route-cache policy isdn switch-type primary-net5 isdn overlap-receiving isdn incoming-voice voice isdn guard-timer 4000 isdn send-alerting isdn negotiate-bchan resend-setup isdn bchan-number-order ascending round-robin isdn sending-complete isdn outgoing-voice info-transfer-capability 3.1kHz-audio isdn outgoing display-ie no cdp enable ! voice-port 0/1/0:15 cptone RU ! dial-peer voice 804534 pots voice cut-through alert description IK-4 destination-pattern 34T progress_ind setup enable 3 progress_ind progress enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 incoming called-number 34 direct-inward-dial port 0/1/0:15 forward-digits 3 ! dial-peer voice 8045 voip voice cut-through alert description UFSIN destination-pattern 745..T progress_ind setup enable 3 progress_ind progress enable 8 progress_ind connect enable 8 progress_ind disconnect enable 8 translate-outgoing called 745 modem passthrough nse codec g711alaw session target ipv4:10.45.15.205 session transport udp dtmf-relay h245-alphanumeric codec g729br8 bytes 40 fax rate 9600 fax protocol cisco ip qos dscp cs5 media ip qos dscp cs5 signaling ip udp checksum
Пробовали менять блок Е1 в станции, не помогло, запасного 2MFT-T1/E1 к сожалению пока нет, все потуги решить проблему с помощью конфигурации Вы видите в листинге. Мысли что делать - кончились, поэтому обращаюсь к Вам! P.S. А firmware MFT-шки нельзя ли сменить? Поиск по этому вопросу ничего не дал...
|
- Странные подвисания ИКМ, eek, 10:45 , 16-Окт-12 (1)
По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не часто, но случается.
- Странные подвисания ИКМ, vigogne, 10:47 , 16-Окт-12 (2)
> По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не > часто, но случается.Хмм, не обрадовали :( Ну чтож, будем трясти руководство на предмет замены... Спасибо!
- Странные подвисания ИКМ, plohish, 16:59 , 16-Окт-12 (3)
> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1. Здравствуйте. А можно не по теме? Разве 2821 поддерживает VWIC, там же HWIC ?
- Странные подвисания ИКМ, plohish, 17:16 , 16-Окт-12 (5)
>> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1. > Здравствуйте. А можно не по теме? > Разве 2821 поддерживает VWIC, там же HWIC ?Извините, ибо HWICs slots can also support WICs, VICs, and VWICs..
- Странные подвисания ИКМ, mdenisov, 17:11 , 16-Окт-12 (4)
Что-то я не пойму проблему - она в отсутствии слышимости или односторонней слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если наблюдается проблема со слышимостью, то она с этим никак не связана.По трейсу - шлюз получает вызов из потока и пытается установить соединение. Время ожидания progress у Вас 20 секунд. Если этого мало - можно увеличить, за это отвечает таймер T310. По моему 20 секунд вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно искать проблему дальше на сети, станция тут никоим образом не виновата, как скорее всего и этот шлюз.
- Странные подвисания ИКМ, vigogne, 07:58 , 17-Окт-12 (6)
> Что-то я не пойму проблему - она в отсутствии слышимости или односторонней > слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если > наблюдается проблема со слышимостью, то она с этим никак не связана. > По трейсу - шлюз получает вызов из потока и пытается установить соединение. > Время ожидания progress у Вас 20 секунд. Если этого мало - > можно увеличить, за это отвечает таймер T310. По моему 20 секунд > вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно > искать проблему дальше на сети, станция тут никоим образом не виновата, > как скорее всего и этот шлюз.В том-то и дело, что баг такой плавающий. То односторонняя слышимость, причем они нас (мы извне) слышат, а мы их нет, то вообще никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается, сигнализация проходит, голосовой тракт проключается. Еще были мысли в сторону организации канала, ибо там в трассе присутствует радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на ура (только во время пропадания пакетов слышится шум). Так что, как бы тоже не вариант... А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
- Странные подвисания ИКМ, mdenisov, 12:19 , 17-Окт-12 (7)
Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о чем Вы пишите совершенно другая проблема и дебажить ее надо иначе. Для начала посмотрите sh call hist vo id $id для такого вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить.> А вот вариант с умирающим DSP-модулем кажется довольно правдивым... Об этом пока рано говорить, умирание DSP достаточно редкое явление и в 99% случаев сопровождается руганью в логах.
- Странные подвисания ИКМ, vigogne, 12:32 , 17-Окт-12 (8)
> Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о > чем Вы пишите совершенно другая проблема и дебажить ее надо иначе. > Для начала посмотрите sh call hist vo id $id для такого > вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить. >> А вот вариант с умирающим DSP-модулем кажется довольно правдивым... > Об этом пока рано говорить, умирание DSP достаточно редкое явление и в > 99% случаев сопровождается руганью в логах.Хорошо, как опять начнется такое, сниму дебаг...
- Странные подвисания ИКМ, fantom, 13:14 , 17-Окт-12 (9)
>[оверквотинг удален] > они нас (мы извне) слышат, а мы их нет, то вообще > никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда > и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается, > сигнализация проходит, голосовой тракт проключается. > Еще были мысли в сторону организации канала, ибо там в трассе присутствует > радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и > связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на > ура (только во время пропадания пакетов слышится шум). Так что, как > бы тоже не вариант... > А вот вариант с умирающим DSP-модулем кажется довольно правдивым...Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT! Тем более если в этот момент на релейках "шумы"...
- Странные подвисания ИКМ, vigogne, 13:17 , 17-Окт-12 (10)
>[оверквотинг удален] >> никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда >> и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается, >> сигнализация проходит, голосовой тракт проключается. >> Еще были мысли в сторону организации канала, ибо там в трассе присутствует >> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и >> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на >> ура (только во время пропадания пакетов слышится шум). Так что, как >> бы тоже не вариант... >> А вот вариант с умирающим DSP-модулем кажется довольно правдивым... > Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!NAT там не используется, а маршрутизация хоть и ospf, но не должна перестраиваться, потому что канал один и балансировки там нет.
- Странные подвисания ИКМ, fantom, 15:18 , 17-Окт-12 (11)
>[оверквотинг удален] >>> сигнализация проходит, голосовой тракт проключается. >>> Еще были мысли в сторону организации канала, ибо там в трассе присутствует >>> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и >>> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на >>> ура (только во время пропадания пакетов слышится шум). Так что, как >>> бы тоже не вариант... >>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым... >> Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT! > NAT там не используется, а маршрутизация хоть и ospf, но не должна > перестраиваться, потому что канал один и балансировки там нет.Смотрите логи OSPF-а, вполне может оказаться, что в одном направлении hello теряются, маршрутер сноси маршруты, а в другом направлении hello проскакивают - второй маршрутер считает, что все в норме, вот и получаете одностороннюю слышимость... Или например коммутатор по вине релейки получает какую-нибудь хрень типа завернутого собственного bpdu и на короткое время блокирует порт...
|