ЗАО "ИНТЕРСИСТ" [тема: Взаимодействие CPU через внешний Ethernet]

Взаимодействие CPU через внешний Ethernet

Thu, 17 Sep 2015 07:17:40 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Что-то странно - дублированные процессора, при отключения Ethernet от основного процессора - на нем перестает работать телефония? Как-то странно описываете.
Про С1 - вы не можете уменьшить нагрузку на межпроцессорный обмен. Есть ли у вас IO2 платы - тогда можно туда перенести сигналинг.
17.09.2015 07:17:40, vad.

Взаимодействие CPU через внешний Ethernet

Thu, 17 Sep 2015 01:00:08 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Коллеги, сообщаю некоторые новости по проблеме.

Перевел режим взаимодействия CPU обратно с Ethernet на C1 (4x64). В этом случае механизм IP redundancy отрабаотывает нормально. При отключении сетевого линка до основного процессора примерно через 20-30 секунд резервный берет работу на себя. При этом бывший основной продолжает работать, не перезагружается, но телефония на нем умирает, так что требуется принудительный рестарт.

Возникает соответственно другая проблема. После того как вернул работу на C1 опять стали сыпаться инциденты о переполнении этого линка. Хотелось бы понять, чем вызвано это переполнение. Конфигурация на станции так часто не меняется, на других узлах ABC сети тоже практически все спокойно. Есть подозрение, что линк переполняется данными тарификации. Если это так, можно ли как-то добиться того, чтобы тарификационные данные не пересылались по C1 линку?
Если все же переполнение связано с чем-то другим, уважительно прошу пояснить чем конкретно и поддается ли это какому-то управлению?

Спасибо!
17.09.2015 01:00:08, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Tue, 25 Aug 2015 11:54:44 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
config 0 у этой АТС как выглядит ?
25.08.2015 11:54:44, Андрей.

Взаимодействие CPU через внешний Ethernet

Tue, 25 Aug 2015 09:48:58 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
cfgUpdate параметр "41 Remanent size" совпадает с PARA_MAO1 из hardware.mao
25.08.2015 09:48:58, error.

Взаимодействие CPU через внешний Ethernet

Mon, 24 Aug 2015 22:40:20 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Проверил сообщения на консоли standby-платы при отключении сетевого линка на основной. Полный вывод приводить не стал, т.к. в основной массе сообщения связаны с перезагрузкой, остановкой сервисов и т.д. В приведенном выводе команду twin давал я сам, до отключения сети на основной плате. Однако следующая команда ioctl cmd UART_OFF была введена не мной.
====code====

(1)gu_20> twin

Thu Aug 20 21:11:02 AST 2015


Usage : twin [Redundancy Cpu Enable (y/n)]

Role and CPU positions:

Role of the CPU : STAND BY

    CPU position      : 20

    CPU address       : 10.197.133.1

    Twin CPU position : 06

    Twin CPU address  : 10.197.133.2

Redundancy State:

    Duplicated configuration    : YES

    Wished sig. transfer mode   : ethernet

    Used sig. transfer mode     : ethernet

    Transmission CPU-CPU    : READY

    monitel redundancy      : READY

    memloader redundancy    : READY

    All applications redundancy : READY

(1)gu_20> ioctl cmd UART_OFF

ioctl cmd UART_OFF

Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
Problem in mailsys : see /DHS3dyn/incid/incpbm file
20/08/15 21:11:41 000001S|000/00/-/---|=1:2347=Reset of stand by CPU
  Broadcast message from root Thu Aug 20 21:11:41 2015...  
The system is going down for reboot NOW !! 
INIT: Switching to runlevel: 6 
INIT: Sending processes the TERM signal Stopping role:  /etc/rc.d/rc(1): Stopping role: 
[  OK  ] Shutting down TEL services :    F S UID        PID  PPID  C PRI  NI ADDR    SZ WCHAN  STIME TTY          TIME CMD
100 S root         1     0  0  69   0    -   263        20:37 ?        00:00:03 init
040 S root         2     1  0  68   0    -     0        20:37 ?        00:00:00 [keventd]
040 S root         3     0  0  78  19    -     0        20:37 ?        00:00:00 [ksoftirqd_CPU0]
040 S root         4     0  0  69   0    -     0        20:37 ?        00:00:00 [kswapd]
040 S root         5     0  0  69   0    -     0        20:37 ?        00:00:00 [bdflush]
040 S root         6     0  0  69   0    -     0        20:37 ?        00:00:00 [kupdated]
040 S root        60     1  0  69   0    -     0        20:37 ?        00:00:00 [khubd]
040 S root       246     1  0  68   0    -   270        20:38 ?        00:00:00 monit -c /etc/monit_oxe.conf -l syslog -d 60
040 D root       377     1  0  60   0    -     0        20:38 ?        00:00:00 [kdb_hpthread]
040 S root       395     1  0  73   0    -   266        20:38 ?        00:00:08 throttled
140 S root       400     1  0  85  -12   -   253        20:38 ?        00:00:00 watchdogd
040 S root       581     1  0  68   0    -   309        20:38 ?        00:00:00 [netadmind]
140 S root       593     1  0  69   0    -  3185        20:38 ?        00:00:00 httpd -DHAVE_PHP5 -DHAVE_PROXY -DHAVE_SSL -DHAVE_ACCESS -DHAVE_ACTIONS -DHAVE_AL
040 S root       602     1  0  69   0    -   288        20:38 ?        00:00:00 syslogd -m 0
140 S root       611     1  0  69   0    -   290        20:38 ?        00:00:00 klogd -k /boot/System.map-2.4.17-ll-dhs3
140 S httpd      620   593  0  69   0    -  3208        20:38 ?        00:00:00 [httpd]
140 S httpd      621   593  0  69   0    -  3208        20:38 ?        00:00:00 [httpd]
040 S daemon     628     1  0  69   0    -   269        20:38 ?        00:00:00 [atd]
140 S root       642     1  0  68   0    -   452        20:38 ?        00:00:00 xinetd -stayalive -reuse -pidfile /var/run/xinetd.pid
040 S root       655     1  0  69   0    -   512        20:38 ?        00:00:00 crond
040 S root       675     1  0  99   0    -     0        20:38 ?        00:00:00 [#__svtimer_]
040 D root       676   675  0  98   0    -     0        20:38 ?        00:00:00 [__svtimer__]
040 D root       677   675  0  99   0    -     0        20:38 ?        00:00:00 [__svtimer__]
100 S root       695     1  0  69   0    -   255        20:38 ?        00:00:00 /usr/bin/teedhs3 -f /tmpd/RUNTEL.log -s 10000 -n 4
140 R root       707     1  0  76  -12   - 65945 -      20:38 ?        00:00:00 /DHS3bin/servers/dhs3_init -m -l /tmpd/DHS3-INIT.log -f /DHS3bin/com/DHS3_SCRIPT
100 S mtcl       924   707  0  99  -12   - 68378        20:38 ?        00:00:00 /DHS3bin/servers/cmisd
100 S mtcl       925   707  0  63  -12   -   471        20:38 ?        00:00:00 /DHS3bin/servers/sqlsrv -f
140 S mtcl       927   924  0  63  -12   - 68378        20:38 ?        00:00:00 /DHS3bin/servers/cmisd
040 S mtcl       928   924  0  63  -12   - 68378        20:38 ?        00:00:00 /DHS3bin/servers/cmisd
100 S mtcl       930   707  0  63  -12   - 73528        20:39 ?        00:00:00 /DHS3bin/servers/remad -nolock
100 S mtcl       943   707  0  99  -12   - 68140        20:39 ?        00:00:00 [#mailsys]
140 S mtcl       944   943  0  65  -11   - 68140        20:39 ?        00:00:00 [mailsys]
040 S mtcl       945   943  0  24  -12   - 68140        20:39 ?        00:00:00 [mailsys]
040 S mtcl       946   943  0  65  -10   - 68140        20:39 ?        00:00:00 [mailsys]
040 S mtcl       947   943  0  63  -12   - 68140        20:39 ?        00:00:00 [mailsys]
100 S mtcl       948   707  0  63  -12   -   336        20:39 ?        00:00:00 /DHS3bin/incid/gwLinux
040 S mtcl       952   943  0  65  -11   - 68140        20:39 ?        00:00:00 [mailsys]
040 S mtcl       953   943  0  63  -12   - 68140        20:39 ?        00:00:00 [mailsys]
040 S mtcl       954   943  0  65  -11   - 68140        20:39 ?        00:00:00 [mailsys]
100 S root      1016   707  0  99  -12   -   680        20:39 ?        00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
140 S root      1018  1016  0  63  -12   -   680        20:39 ?        00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root      1021  1016  0  71   4    -   680        20:39 ?        00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root      1022  1016  0  71   4    -   680        20:39 ?        00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
040 S root      1027  1016  0  71   4    -   680        20:39 ?        00:00:00 /DHS3bin/servers/tunnel -l /tmpd/tunnel.log tun0
140 S root      1036     1  0  99  -12   -     0        20:39 ?        00:00:00 [#MONITELmod]
040 S root      1037  1036  0  99  -12   -     0        20:39 ?        00:00:00 [MONITELmod]
040 S root      1038     1  0  88  -12   -     0        20:39 ?        00:00:00 [MONITELmod]
100 S mtcl      1061   707  0  63  -12   - 67927        20:40 ?        00:00:00 /DHS3bin/servers/btracer
100 S mtcl      1062   707  0  63  -12   -   337        20:40 ?        00:00:00 /DHS3bin/servers/blackbox
100 S mtcl      1063   707  0  63  -12   -   949        20:40 ?        00:00:00 /DHS3bin/oneshot/mtcl/mtracer
100 S root      1064   707  0  99  -12   -   350        20:40 ?        00:00:00 [#io2chd]
100 S root      1065   707  0  63  -12   - 67932        20:40 ?        00:00:00 [servapp]
100 S mtcl      1066   707  0  62  -12   - 67965        20:40 ?        00:00:00 /DHS3bin/servers/dectobsproc
040 S root      1075  1064  0  63  -12   -   350        20:40 ?        00:00:00 [io2chd]
040 S root      1076  1064  0  63  -12   -   350        20:40 ?        00:00:00 [io2chd]
000 S root      1077     1  0  99  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 S root      1080  1077  0  85  -6    - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1081  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1082  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1083  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1084  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1085  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 D root      1086  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 S root      1087  1077  0  86  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 S root      1088  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
040 S root      1089  1077  0  85  -12   - 78163        20:40 ?        00:00:00 /DHS3bin/tel/TEL
100 S mtcl      1098   707  0  99  -12   - 68084        20:40 ?        00:00:00 /DHS3bin/servers/download
100 S root      1099   707  0  99  -12   - 67948        20:40 ?        00:00:00 /DHS3bin/servers/memloader -main
100 S mtcl      1100   707  0  63  -12   -  2414        20:40 ?        00:00:00 /DHS3bin/servers/io1n_mgr -m
100 S root      1101   707  0  99  -12   - 68195        20:40 ?        00:00:00 [#iplink]
100 S root      1102   707  0  99  -12   - 67945        20:40 ?        00:00:00 [#BTlink]
140 S root      1111  1099  0  63  -12   - 67948        20:40 ?        00:00:00 /DHS3bin/servers/memloader -main
140 S mtcl      1112  1098  0  63  -12   - 68084        20:40 ?        00:00:00 /DHS3bin/servers/download
140 S root      1113  1102  0  63  -12   - 67945        20:40 ?        00:00:00 [BTlink]
040 S mtcl      1114  1098  0  63  -12   - 68084        20:40 ?        00:00:00 /DHS3bin/servers/download
140 S root      1115  1101  0  87  -12   - 68195        20:40 ?        00:00:00 [iplink]
040 S root      1117  1101  0  98  -12   - 68195        20:40 ?        00:00:00 [iplink]
040 S mtcl      1120  1098  0  63  -12   - 68084        20:40 ?        00:00:00 /DHS3bin/servers/download
140 S root      1121     1  0  99  -12   -     0        20:40 ?        00:00:00 [#MON25mod]
040 S root      1124  1121  0  80  -12   -     0        20:40 ?        00:00:00 [MON25mod]
040 S root      1125     1  0  81  (020365:000022) Stop all
(020365:000023) SUPERVISOR -- Supervisor_Number=1640 Param0=13 Param1=10121 Param2=68 Param3=-1

(020365:000024) SUPERVISOR --  Stops the applicative actor

(020365:000025) monitel saves blackbox state at shutdown time
20/08/15 21:11:44 000001S|---/--/-/---|=1:2077=CPU was halted due to a shutdown
Thu Aug 20 21:11:43 AST 2015
(020365:000026) ***************************
(020365:000027) ** ACTOR DIS25 SHUTDOWN **
(020365:000028) ***************************
(020365:000029)  Thread Appli shutdown
(020365:000030)  Thread IPrcv shutdown
(020365:000031)  Thread fluxIP shutdown
(020365:000032)  Thread AckIP shutdown
(020365:000033)  Thread Dis25 shutdown
(020365:000034) ***************************
(020365:000035) **  DEMANDE DE STOP X25  **
(020365:000036) ***************************
Command "IP_LINK" (pid 1101) exited with status 1.

=============
24.08.2015 22:40:20, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 21:35:54 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
подключите консоль на standby и intip и смотрите что сыпется когда линк дернулся на main
12.08.2015 21:35:54, error.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 21:28:27 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Вы бы лучше инциденты с неактивного процессора на момент после пропадания активного показали.
12.08.2015 21:28:27, Андрей.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 20:37:26 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Погодите-ка, что-то какая-то путаница в обсуждении началась

====quote====
error пишет:
что мы должны указывать на плате INTIP ролевой адрес который при переключении процов скачет с одного интерфейса на другой а конкретном случае в одного коммутатора на другой. в результате чего получаем ролевой адрес дернулся и плата INTIP перезагрузилась
=============
Как вдруг мы с IP адресов CPU переключились на INTIP. Насколько я понимаю, для INTIP понятия ролевого адреса, который кочует с одной платы на другую, не существует. В нашем случае на каждой INTIP висит свой IP адрес intip1 и intip2, доступы обеих плат добавлены в состав одной транк-группы. После умирания одной из плат INTIP в ходе установления вызовов CPU начинает передавать ip адрес второй CPU платы.

Как правильно подметил vad, у нас используются ABCF через гибридные линки с VPN overflow.

Насчет разных ролевых адресов на процессорах внутри одной полки - данная конфигурация кажется очень сомнительной.
А с ARP таблицами ситуация кажется не такой страшной: возьмем к примеру роутер, через который станция общается, например, с другими узлами. Изначально в его ARP кэше есть запись, что для адреса ipcpu использовать mac aaaa.aaaa.aaaa. Произошел сбой, работа перешла на второй проц. Теперь адресу ipcpu соответствует mac bbbb.bbbb.bbbb, но на роутере пока еще хранится старая запись. В статической среде конфигурации по умолчанию действительно придется ждать долго (насколько я помню, у cisco по дефолту arp записи хранятся 4 часа). Но, во-первых, arp timeout можно уменьшить минут до 5-10. Во-вторых, в том случае если ip-адресом источнка пакетов уходящих со станции является не реальный адрес CPU, а ролевой, то после первого же полученного от станции пакета маршрутизатор обновит свой arp кэш. Именно это поведение arp таблиц лежит в основе атак Man-in-the-middle. Если же, все-таки ролевой адрес используется только на приеме, а все исходящие пакеты уходят с реального адреса CPU, тогда действительно ситуация не очень хорошая, так как придется выжидать весь таймаут. Нарывались на похожую ситуацию с МСЭ Cisco ASA.
12.08.2015 20:37:26, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 17:57:55 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
error пишет:
вы наверное не совсем въежаете в топологию сети как на одном коммутаторе был IP-10.197.133.3 со своим МАС, а потом вдруг всплыл этот же самый IP-10.197.133.3 но уже с другим МАС
=============

Вам, как въезжающему, вопрос: сколько времени займет обновление ARP таблиц на INTIP и CPU?
12.08.2015 17:57:55, Андрей.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 16:53:29 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
vad пишет:
поднимать DNS (а как иначе с 4760 туда стучатся было)
=============
если принципиально имена так важны в винде есть файл hosts
я не думаю что 4760 начнет писать конфиг на проце standby

====quote====
vad пишет:
А это как-то запрещено? Вроде штатная вещь, по жизни всегда работало.
=============
каждому тот или иной подход устраивает
12.08.2015 16:53:29, error.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 16:09:55 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
error пишет:
вы наверное не совсем въежаете в топологию сети как на одном коммутаторе был IP-10.197.133.3 со своим МАС, а потом вдруг всплыл этот же самый IP-10.197.133.3 но уже с другим МАС
=============
А это как-то запрещено? Вроде штатная вещь, по жизни всегда работало.
Делать разные main адреса, поднимать DNS (а как иначе с 4760 туда стучатся было) - а зачем?
12.08.2015 16:09:55, vad.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 13:53:41 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
Андрей пишет:
Давать процессорам в дубле разные ролевые адреса, даже если они в одной подсети, что-ли ?
=============
разве изначально xma и xmb имеют один и тот же IP?

что мы должны указывать на плате INTIP ролевой адрес который при переключении процов скачет с одного интерфейса на другой а конкретном случае в одного коммутатора на другой. в результате чего получаем ролевой адрес дернулся и плата INTIP перезагрузилась

вы наверное не совсем въежаете в топологию сети как на одном коммутаторе был IP-10.197.133.3 со своим МАС, а потом вдруг всплыл этот же самый IP-10.197.133.3 но уже с другим МАС
12.08.2015 13:53:41, error.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 13:38:59 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
error пишет:
ИМХО, я бы не стал при наличии ABCF-IP ролевые IP-адреса сводить к одному IP-адресу ради удобства доступа к АТС
=============
Дкумается что нет там ABC-F-IP, а есть H323 IP и VPN overflow c hybrid link с IP сигнализацией.

Давать ОДИН адрес main для CPU - это нормальная практика. Не давать ведь разные адреса, понимать DNS для процов стоящих в одной подсети.
12.08.2015 13:38:59, vad.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 13:18:48 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
error пишет:

ИМХО, я бы не стал при наличии ABCF-IP ролевые IP-адреса сводить к одному IP-адресу ради удобства доступа к АТС
=============

В каком смысле ? Давать процессорам в дубле разные ролевые адреса, даже если они в одной подсети, что-ли ?
12.08.2015 13:18:48, Андрей.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 12:50:28 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
Vladimir Shushkov пишет:
Не могу согласиться
=============
алькатель не должен описывать топологию сети так как это обыденное дело и Вам конечно видней под каким "соусом" все подавать

ИМХО, я бы не стал при наличии ABCF-IP ролевые IP-адреса сводить к одному IP-адресу ради удобства доступа к АТС
12.08.2015 12:50:28, error.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 10:32:27 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
А что мешает посмотреть прошлые инциденты на процессорах, за время экспериментов ?
12.08.2015 10:32:27, Андрей.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 10:18:38 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.

====quote====
error пишет:
правильно это когда два коммутатора собираются в стек для таких целей а по сути получается два коммутатора живут сами по себе c одинаковыми настройками
=============
Не могу согласиться. Конечно, со стеком всегда проще иметь дело, особенно, когда функционала резервирования не заложено в устройство, подключаемое к сети. Однако не всегда есть техническая возможность использования стека. В нашем случае, есть станция и два нестекируемых коммутатора Cisco 6509 без возможности включения VSS (а-ля стек). Функционал подключения к двум коммутаторам описан (хоть и достаточно скудно) в документации. Есть даже картинка, где процессоры и платы разнесены по разным коммутаторам. Соответственно, не стоит отталкиваться от того, что правильно подключать только в стек. В нашей ситуации физически станция подключена правильно, в соответствии с документацией.

====quote====
Андрей пишет:
Как выглядит лог перезагрузки резервного процессора, начиная с момента потери им связи с активным процессором ?
=============

====quote====
error пишет:
что у вас там показывает excvisu
=============
Не снял эту информацию во время прошлых проверок. В ближайшее время протестирую отработку перехода еще раз и выложу данные сведения.

P.S. Закрались определенные сомнения насчет сигнального линка. Может быть имеет смысл вернуть его на C1? В описании механизма IP Redundancy насторожила фраза что-то вроде того, что когда основной CPU в течение некоторого временного промежутка не видит специальных фреймов от резервного CPU, он дает команду переключения на резерв. Как он дает команду? По какому каналу если сигналинг передается по тому же ethernet?
12.08.2015 10:18:38, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 08:29:08 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
правильно это когда два коммутатора собираются в стек для таких целей
а по сути получается два коммутатора живут сами по себе c одинаковыми настройками

что у вас там показывает excvisu
12.08.2015 08:29:08, error.

Взаимодействие CPU через внешний Ethernet

Wed, 12 Aug 2015 06:43:59 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Мне казалось (может неправ, станцией редко занимаюсь) что "настоящее" Ethernet redundancy предполагалась для AS, GD-3, INT-IP3 - когда из одной платы торчит два Ethernet интерфейса (два порта с одним адресом).
А то, что обсуждается здесь (когда процессора воткнуты в два разных коммутатора, но находятся в одной подсети) это просто более правильное включение.
12.08.2015 06:43:59, vad.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 21:21:53 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Как выглядит лог перезагрузки резервного процессора, начиная с момента потери им связи с активным процессором ?
11.08.2015 21:21:53, Андрей.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 20:50:59 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Нет, на данной станции нет. Но есть еще одна станция, на которой тоже запланировали аналогичные работы. Вот на ней установлена IO2N.

P.S. Обратил внимание, что в netadmin есть возможность настройки ethernet redundancy. В документации описание этого функционала что-то найти не смог. Может нужно включить эту опцию?
11.08.2015 20:50:59, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 20:40:35 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
IO2N есть?
11.08.2015 20:40:35, error.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 17:14:52 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Сигналинг включен через Ethernet. Перешли с C1 на Ethernet в связи с тем, что ранее сыпались инциденты о переполнении C1 линка.

====code====

Usage : twin [Redundancy Cpu Enable (y/n)]

Role and CPU positions:

Role of the CPU : MAIN

    CPU position      : 06

    CPU address       : 10.197.133.2

    Twin CPU position : 20

    Twin CPU address  : 10.197.133.1

Redundancy State:

    Duplicated configuration    : YES

    Wished sig. transfer mode   : ethernet

    Used sig. transfer mode     : ethernet

    Transmission CPU-CPU        : READY

    Telephony redundancy        : READY

    monitel redundancy          : READY

    memloader redundancy        : READY

    All applications redundancy : READY

=============

lanpbxbuild отсутствует

Вывод netadmin -m

====code====

Your system has the private network number 0 and the site number 1.
Private IP addressing space:    no
Restricted internet accesses:   no
Accept ICMP redirect:           no
Low dynamic ports range configuration :  10000 - 10499

There is no VLan configuration. No frame will be 802.1q-tagged.
The ethernet redundancy is not supported on this CPU type
node name :  node000001
internal name resolver activated :  yes


Ethernet interface setup
========================

   Netmask         :  255.255.255.0

==============================================================================
|  Machine type     |  Local interface    |    Name         |   Address      |
==============================================================================
| local             | Ethernet            | gr_06           | 10.197.133.2   |
| local main        | Ethernet            | gr_main         | 10.197.133.3   |
| router            | Ethernet            | router          | 10.197.133.254 |
| local             | IP/X25 tunnel       | x000001_tun     | 172.30.253.1   |
==============================================================================


<return> to continue. 

CPU redundancy setup
====================

   Netmask         :  255.255.255.0

==============================================================================
|  Machine type     |  Local interface    |    Name         |   Address      |
==============================================================================
| local             | Ethernet            | gr_20           | 10.197.133.1   |
| local main        | Ethernet            | gr_main         | 10.197.133.3   |
==============================================================================

=============

Только что обратил внимание на строчку в выводе netadmin

====code====

The ethernet redundancy is not supported on this CPU type

=============

Станции не нравится CPU7-2 с 8-м релизом?
11.08.2015 17:14:52, Vladimir Shushkov.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 12:40:30 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Тут главное не перепутать - что и когда дергаете. Вообще странно.
А сигналинг у вас в 0-м кристалле какой включен - C1 или Ethernet?
11.08.2015 12:40:30, vad.

Взаимодействие CPU через внешний Ethernet

Tue, 11 Aug 2015 11:44:49 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
для полноты картины покажите еще "netadmin -m" пункт 2
и lanpbxbuild если есть
11.08.2015 11:44:49, error.

Взаимодействие CPU через внешний Ethernet

Mon, 10 Aug 2015 22:14:22 +0500

Взаимодействие CPU через внешний Ethernet Странная перезагрузка в форуме Конфигурирование.
Здравствуйте, Коллеги!

С целью повышения отказоустойчивости OXE были выполнены работы по настройке/включению IP Redundancy. Первоначально, имеющиеся в составе станции платы CPU7-2 (2шт) и INTIP2 (2шт) были включены в один неуправляемый коммутатор, который являлся единой точкой отказа.
В ходе работ было проведено раздельное подключение указанных плат в разные коммутаторы ядра Cisco Catalyst 6509 (CPU7-2 и INTIP в один коммутатор, оставшиеся CPU7-2 и INTIP в другой коммутатор)
При этом были выполнены рекомендации документации Alcatel в части отключения embedded Ethernet на платах CPU7-2 с целью корректной отработки Spanning-tree.

====code====

(1)gu_06> ethctl

Thresholds configuration :

  broadcast frames : disabled.

  total frames     : disabled.

  bandwidth        : disabled.

  scan interval    : 500 (ms).

 

Embedded Ethernet configuration :

  jumper           : disabled.

  xilinx           : enabled.

  -> state         : disabled.

 

External Ethernet configuration :

  link config      : auto.

  link state       : 100Mb full.

=============

В состав IP транк-группы, используемой для построения ABC туннелей включены ресурсы обеих плат INTIP
Включен механизм IP Redundancy

====code====

(1)gu_06> cmdcpl 0 13 MNGT

Sat Aug  8 16:46:36 AST 2015
Del  to exit tool

You have selected a board with type : INTIPA

execution from 'MNGT'

 

(00,13)

INTIP Management :

(00,13)    - Board is INTIP-A

(00,13)

   - Crystal number    : 0 (Management)

(00,13)                        : 255 (given by S400/401 switches)

(00,13)    - Coupleur number   : 13 (Management)

(00,13)    - Recovery Mode     : Normal

(00,13)

   - @ MAC :  00 : 80 : 9F : 5C : F7 : A9

(00,13)    - @ IP  : 10.197.133.5

(00,13)

   - Voip port : 32512 [7f00]

(00,13)

   - Default DSCP : 0x0B

(00,13)

   - Ethernet interface is configured to  Auto Negociation (Half and Full duplex)

(00,13)    - Link state is  100MBps /  Full duplex

(00,13)

   - IP Redondancy activated

(00,13)      - @IP CPU1 : 10:197:133:2

(00,13)      - @IP CPU2 : 10:197:133:1

(00,13)      - PING emitted every 20 seconds

(00,13)      - Traffic check every 3x20 seconds

(00,13)

   - Framing G729   = 20ms

(00,13)    - Framing G723.1 = 30ms

(00,13)    - Framing G711   = 20ms

 

(00,13) 000000EB-0030CFA9: End of command execution

Normal exit.

=============

Выполнена проверка переключения сервисов телефонии на резервные компоненты при потере связи с коммутаторами ЛВС:
1. При выключении линка между ЛВС и используемой в заданный момент времени платы INTIP происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. За достаточно короткое время работа переводится на другую плату INTIP, после чего станция готова к отработке межстанционных вызовов. При этом потеря линка основной платы приводит к ее перезагрузке. До тех пор пока линк не поднят, плата находится в состоянии INIT 1 RUN. Резюме: переключение на резерв осуществляется штатно, в приемлемые временные рамки;

2. При выключении линка между ЛВС и используемой в заданный момент времени процессорной платой CPU7-2 происходит разрыв установленных соединений между данной УАТС и другими УАТС Отделения. При этом, резервный процессор, не видя основную плату, уходит в перезагрузку. Так как перезагрузка CPU выполняется достаточно длительное время (порядка 10-15 минут), в течение всего этого времени недоступны никакие телефонные сервисы. Данное поведение кажется весьма странным.

Подскажите пожалуйста, является ли штатным поведение резервного CPU, при котором он перезагружается при отсутствии связи с основным узлом? Почему этого не происходит при работоспособном embedded Ethernet линке?

Огромное Спасибо!
10.08.2015 22:14:22, Vladimir Shushkov.