Доброго всем времени суток. У меня возникла следующая проблема 2 станции A(Кристал) и B(Аплианс Сервер) соеденены по гибридному линку. По сути, обе станции находятся в одном помещении, к станции В подключено N количество MG, которые разбросанны по всей стране. Также есть MG(С), который находится в том же помещении, что и обе станции и тоже соединен со станцией В. Теперь непосредственно проблема.
Вот что происходит на станции В при звонке со станции MG"C" на MG(N)
04/07/11 11:12:30 000010M|005/--/-/---|=2:2043=Loss of the 5 CRYSTAL #удаленный MG(N) 04/07/11 11:12:30 000010M|005/00/-/---|=2:2042=Loss of a GD type cpl 04/07/11 11:12:30 000010M|005/01/-/---|=2:2042=Loss of a Z type cpl 04/07/11 11:12:30 000010M|005/02/-/---|=2:2042=Loss of a UA type cpl 04/07/11 11:12:30 000010M|005/27/-/---|=3:2490=Loss of a virtual coupler GPA (5,27) of the associate d coupler GD (5,0) 04/07/11 11:14:40 000010M|005/00/-/---|=4:0740=Beginning of an INT/IP downloading @:00.80.9f.83.bc.c a (binmg) 04/07/11 11:14:40 000010M|005/00/-/---|=5:0741=End of downloading of an INT/IP board @:00.80.9f.83.b c.ca (binmg) 04/07/11 11:15:07 000010M|005/00/-/---|=4:0740=Beginning of an INT/IP downloading @:00.80.9f.83.bc.c a (binmg) 04/07/11 11:15:08 000010M|005/00/-/---|=5:0741=End of downloading of an INT/IP board @:00.80.9f.83.b c.ca (binmg) 04/07/11 11:15:30 000010M|005/00/-/---|=5:0409=The inter-ACT link over IP from (19 1) is up 04/07/11 11:15:31 000010M|005/00/-/---|=0:5857=GD/GA/INTIP/RGD: reason of reboot 2 04/07/11 11:15:40 000010M|005/02/0/002|=5:2053=Terminal 2 in service 04/07/11 11:15:41 000010M|005/02/0/003|=5:2053=Terminal 3 in service 04/07/11 11:16:00 000010M|005/02/0/003|=5:2053=Terminal 3 in service 04/07/11 11:16:00 000010M|005/00/-/---|=5:2019=GD coupler commissioning 04/07/11 11:16:11 000010M|005/02/-/---|=5:2019=UA coupler commissioning 04/07/11 11:16:14 000010M|005/27/-/---|=4:2491=GPA(5,27) virtual coupler commissioning of the associ ated coupler GD(5,0) 04/07/11 11:16:20 000010M|005/01/-/---|=5:2019=Z coupler commissioning
#Это тоже при звонке с MG"C" на MG(N)
04/07/11 11:20:56 000010M|005/00/0/254|=2:0379=Inter ACT link HS: 10,(255,255),172.31.220.82,00:80:9 f:83:bc:ca 04/07/11 11:20:56 000010M|005/--/-/---|=2:2043=Loss of the 5 CRYSTAL 04/07/11 11:20:56 000010M|005/00/-/---|=2:2042=Loss of a GD type cpl 04/07/11 11:20:56 000010M|005/01/-/---|=2:2042=Loss of a Z type cpl 04/07/11 11:20:56 000010M|005/02/-/---|=2:2042=Loss of a UA type cpl 04/07/11 11:20:56 000010M|005/27/-/---|=3:2490=Loss of a virtual coupler GPA (5,27) of the associate d coupler GD (5,0)
#А вот инцидент станции В, при звонки со станции А на станцию В - MG"N"
Не понятно - приводите инциденты 4104, 4108, а по трассировка - звонок проходит (идет звонок на VPN overflow префикс, вплоть до коннекта). По отпадыванию кристаллов - надо смотреть как организован канал, какой толщины. Если задержки колоссальные - канал тонкий, подключены чем-то типа моста (bridge) - переполняется буфер на нем, передача затыкается. Соответственно keep alive сообщения между процом и GD не пробегают - GD соответственно теряет проц и уходит в ребут.
Есди ни голоса, ни гудка - но connected - не пропускает ваша сеть RTP пакеты. А с каналами - для начала спросить тех, кто их предоставляет. Можно так же (из простого) - заслать большой файл и посмотреть на время передачи.
Ее можно заставить пропустить эти пакеты? и могу ли я как либо заказчику это доказать? т.к. сеть не наша, тут будут бодания без вопросов:(
[root@xa000010 mtcl]# ping 172.31.220.82 -c 50 -s 1200 PING 172.31.220.82 (172.31.220.82): 1200 octets data 1208 octets from 172.31.220.82: icmp_seq=0 ttl=253 time=327.1 ms 1208 octets from 172.31.220.82: icmp_seq=1 ttl=253 time=327.0 ms 1208 octets from 172.31.220.82: icmp_seq=2 ttl=253 time=326.8 ms
--- 172.31.220.82 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max = 326.8/326.9/327.1 ms [root@xa000010 mtcl]# ping 172.31.220.82 -c 50 -s 2400 PING 172.31.220.82 (172.31.220.82): 2400 octets data 2408 octets from 172.31.220.82: icmp_seq=0 ttl=253 time=639.4 ms 2408 octets from 172.31.220.82: icmp_seq=1 ttl=253 time=639.3 ms 2408 octets from 172.31.220.82: icmp_seq=2 ttl=253 time=639.3 ms
--- 172.31.220.82 ping statistics --- 4 packets transmitted, 3 packets received, 25% packet loss round-trip min/avg/max = 639.3/639.3/639.4 ms
[root@xa000010 mtcl]# ping 172.31.220.82 -c 50 -s 4800 PING 172.31.220.82 (172.31.220.82): 4800 octets data 4808 octets from 172.31.220.82: icmp_seq=0 ttl=253 time=1263.6 ms wrong data byte #0 should be 0xdb but was 0xdada a5 11 4e ff b5 2 0 8 9 a b c d e f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 38 39 3a 3b
--- 172.31.220.82 ping statistics --- 2 packets transmitted, 1 packets received, 50% packet loss round-trip min/avg/max = 1263.6/1263.6/1263.6 ms
что-то по пингам задержка+потери уж очень большие! чтобы что-то доказать, надо исходить что хотел получить Заказчик + какие были требования к IP сети+ приоритеты пакетов, здесь явно есть проблеммы. Для доказательства можно взять внешний анализатор сети и промониторить сеть - это к сетевикам лучше обратиться
Насколько я понимаю time=639.4 ms и т.д. это время в пути пакетов, для голоса задержка норма до 250, и потери до 3%, оно может и притаких параметрах работать, но при определенных условиях качества,надежности и т.д.
такая задержка характерна для спутникового канала, там как говорится "свои тараканы". Собственно реальная задержка равна половине этого значения (как никак сигнал проходит путь туда и обратно).
Заметил одну странность, когда звоню с локального MG(С) на удаленный MG(N) мой голос до них долго идет. Их голос доходит до меня сразу. Это о чем нибудь вам говорит? Насчет канала, там оптика, не спутник, задержки time=639.4 ms это при 2400 байтном пакете. При обычных пингах тайм едва за 37 ms переходит.
