Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1 2 След.
RSS
Взаимодействие 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.

Код
(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

Код
(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 линке?

Огромное Спасибо!
 
для полноты картины покажите еще   "netadmin -m"  пункт 2
и lanpbxbuild если есть
Изменено: error - 11.08.2015 11:45:35
Пути IP-пакета неисповедимы
 
Тут главное не перепутать - что и когда дергаете. Вообще странно.
А сигналинг у вас в 0-м кристалле какой включен - C1 или Ethernet?
 
Сигналинг включен через Ethernet. Перешли с C1 на Ethernet в связи с тем, что ранее сыпались инциденты о переполнении C1 линка.

Код
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

Код
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

Код
The ethernet redundancy is not supported on this CPU type


Станции не нравится CPU7-2 с 8-м релизом?
Изменено: Vladimir Shushkov - 11.08.2015 17:17:58
 
IO2N есть?
Пути IP-пакета неисповедимы
 
Нет, на данной станции нет. Но есть еще одна станция, на которой тоже запланировали аналогичные работы. Вот на ней установлена IO2N.

P.S. Обратил внимание, что в netadmin есть возможность настройки ethernet redundancy. В документации описание этого функционала что-то найти не смог. Может нужно включить эту опцию?
 
Как выглядит лог перезагрузки резервного процессора, начиная с момента потери им связи с активным процессором ?
Изменено: Андрей - 11.08.2015 21:30:51
 
Мне казалось (может неправ, станцией редко занимаюсь) что "настоящее" Ethernet redundancy предполагалась для AS, GD-3, INT-IP3 - когда из одной платы торчит два Ethernet интерфейса (два порта с одним адресом).
А то, что обсуждается здесь (когда процессора воткнуты в два разных коммутатора, но находятся в одной подсети) это просто более правильное включение.
 
правильно это когда два коммутатора собираются в стек для таких целей
а по сути получается два коммутатора живут сами по себе c одинаковыми настройками

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

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

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

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


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

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

Давать ОДИН адрес main для CPU - это нормальная практика. Не давать ведь разные адреса, понимать DNS для процов стоящих в одной подсети.
 
Цитата
Андрей пишет:
Давать процессорам в дубле разные ролевые адреса, даже если они в одной подсети, что-ли ?
разве изначально xma и xmb имеют один и тот же IP?

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

вы наверное не совсем въежаете в топологию сети как на одном коммутаторе был IP-10.197.133.3 со своим МАС, а потом вдруг всплыл этот же самый IP-10.197.133.3 но уже с другим МАС
Пути IP-пакета неисповедимы
Страницы: 1 2 След.