Добрый день!Где-то года два назад, мы получили партию 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-шки нельзя ли сменить? Поиск по этому вопросу ничего не дал...
По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не часто, но случается.
> По симптомам похоже, что DSP у вас погибает (PVDM2). Бывает такое не
> часто, но случается.Хмм, не обрадовали :( Ну чтож, будем трясти руководство на предмет замены... Спасибо!
> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1.Здравствуйте. А можно не по теме?
Разве 2821 поддерживает VWIC, там же HWIC ?
>> Где-то года два назад, мы получили партию C2821, укомплектованных PVDM2-32 и VWIC2-2MFT-T1/E1.
> Здравствуйте. А можно не по теме?
> Разве 2821 поддерживает VWIC, там же HWIC ?Извините, ибо HWICs slots can also support WICs, VICs, and VWICs..
Что-то я не пойму проблему - она в отсутствии слышимости или односторонней слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если наблюдается проблема со слышимостью, то она с этим никак не связана.По трейсу - шлюз получает вызов из потока и пытается установить соединение. Время ожидания progress у Вас 20 секунд. Если этого мало - можно увеличить, за это отвечает таймер T310. По моему 20 секунд вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно искать проблему дальше на сети, станция тут никоим образом не виновата, как скорее всего и этот шлюз.
> Что-то я не пойму проблему - она в отсутствии слышимости или односторонней
> слышимости, или в установке соединения? Судя по предоставленному трейсу второе. Если
> наблюдается проблема со слышимостью, то она с этим никак не связана.
> По трейсу - шлюз получает вызов из потока и пытается установить соединение.
> Время ожидания progress у Вас 20 секунд. Если этого мало -
> можно увеличить, за это отвечает таймер T310. По моему 20 секунд
> вполне достаточно чтобы получить какой-нибудь ответ от терминирующей точки, Вам нужно
> искать проблему дальше на сети, станция тут никоим образом не виновата,
> как скорее всего и этот шлюз.В том-то и дело, что баг такой плавающий. То односторонняя слышимость, причем они нас (мы извне) слышат, а мы их нет, то вообще никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается, сигнализация проходит, голосовой тракт проключается.
Еще были мысли в сторону организации канала, ибо там в трассе присутствует радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на ура (только во время пропадания пакетов слышится шум). Так что, как бы тоже не вариант...
А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о чем Вы пишите совершенно другая проблема и дебажить ее надо иначе. Для начала посмотрите sh call hist vo id $id для такого вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить.> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
Об этом пока рано говорить, умирание DSP достаточно редкое явление и в 99% случаев сопровождается руганью в логах.
> Предоставленный трейс к данной проблеме никакого отношения иметь не может, то о
> чем Вы пишите совершенно другая проблема и дебажить ее надо иначе.
> Для начала посмотрите sh call hist vo id $id для такого
> вызова с обоих сторон VoIP участка, дальше будет виднее что дебажить.
>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
> Об этом пока рано говорить, умирание DSP достаточно редкое явление и в
> 99% случаев сопровождается руганью в логах.Хорошо, как опять начнется такое, сниму дебаг...
>[оверквотинг удален]
> они нас (мы извне) слышат, а мы их нет, то вообще
> никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда
> и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается,
> сигнализация проходит, голосовой тракт проключается.
> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
> ура (только во время пропадания пакетов слышится шум). Так что, как
> бы тоже не вариант...
> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!
Тем более если в этот момент на релейках "шумы"...
>[оверквотинг удален]
>> никто никого. Но сигнализация всегда проходит нормально, т.е. звонки и туда
>> и оттуда проходят. По логам станции все обрабатывается нормально, ИКМ занимается,
>> сигнализация проходит, голосовой тракт проключается.
>> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
>> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
>> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
>> ура (только во время пропадания пакетов слышится шум). Так что, как
>> бы тоже не вариант...
>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
> Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!NAT там не используется, а маршрутизация хоть и ospf, но не должна перестраиваться, потому что канал один и балансировки там нет.
>[оверквотинг удален]
>>> сигнализация проходит, голосовой тракт проключается.
>>> Еще были мысли в сторону организации канала, ибо там в трассе присутствует
>>> радиорелейка. Но, опять же, есть подразделения, где также присутсвуют релейки и
>>> связь гораздо хуже, бывает пропадают пакеты, но голос там отрабатывает на
>>> ура (только во время пропадания пакетов слышится шум). Так что, как
>>> бы тоже не вариант...
>>> А вот вариант с умирающим DSP-модулем кажется довольно правдивым...
>> Похоже на перестроение IP маршрутизации, когда что-то начинает бегать через NAT!
> NAT там не используется, а маршрутизация хоть и ospf, но не должна
> перестраиваться, потому что канал один и балансировки там нет.Смотрите логи OSPF-а, вполне может оказаться, что в одном направлении hello теряются, маршрутер сноси маршруты, а в другом направлении hello проскакивают - второй маршрутер считает, что все в норме, вот и получаете одностороннюю слышимость...
Или например коммутатор по вине релейки получает какую-нибудь хрень типа завернутого собственного bpdu и на короткое время блокирует порт...