Доброго времени. Есть центральная станция с кучей выносов и PCS на каждом выносе.
релиз 8.0.1 патч 17.
уже на втором выносе наблюдается такая картина: PCS стоит, как положено в Inactive, GD пингуется а платы подниматься не желают. По питанию перезапускали вынос - не помогло. До этого стоял с месяц работал без нареканий и тут - на тебе...

А поднималось? Тестировали? Не прописано в GD еще и backup (кроме PCS), чего на GD происходит?

Ну патч 17d накатил бы, было в 17а написано - GD no more operational after CS main cut from network

Все поднималось, работало, в одном случае, около месяца (выслали железку, ждем, чтоб посмотреть), во втором месяц работало.
17b там стоит
17d проблематично немного заливать, пробовал на один залить дешный патч - всю ночь закчивал 8-), какналы не ахти...
25 уже запущенных выносов 8-))))) незнамо где.....

Можно и b, просто написали патч 17, а для меня 17 и 17b - две большие разницы 8-)

А вынос перезапускали - чего писало на GD?
И кстати (не знаю - имеет ли смысл в данном случае) - была проблема - не поднимались INTIPB. Что помогло - на проце в netadmin был дефолтовский шлюз, прописали дополнительно статический роут на адрес INTIPB через ТОТ ЖЕ САМЫЙ шлюз - и все заработало.

Был такой траблешутинг гайд номер 15, он про проблемы с INTIP, но описываемая проблема связана с ICMP redirect, поэтому она нверное общая.

проблематично посмотреть, что на GD писало при перезапуске - в Стамбуле он стоит и посмотреть некому 8-). Жду пока приедет первый вылетевший, дабы посмотреть что он пишет.
по поводу шлюза: недопонял, на самой INTIPB статику указывали (оно ж там вроде и так уакзывается....) или на проце в netadmin статический маршрут прописали плюс к дефолтному?



Редактировано 1 раз. Последний раз 01.04.2009 18:00 пользователем Vsjakov.

На проце прописывали статический роут.

пасиба, попробую сейчас

А вообще на процессоре видно какие-нибудь инциденты на загрузку бинарников?
traceroute на адрес GD показывает что-то доброе - достукиваетесь до GD?

Роут причем именно на адрес GD (host), не на всю network.

Да на GD именно прописываю маршрут.

traceroute на адрес GD доходит до адреса во вне отправляющегося, до самого GD не доходит, что на рабочих выносах, что на заткнувшемся. Сетевики наши, которые маршрутами занимаются утверждают, что так идолжно быть. Там еще железяки стоят шифровальные всякие.
пинг до GD идет.
Обещали шифрование отключить для эксперимента, посмотрим.
Инцидентов не видал. Бинарники-то, в свое время, загрузились нормально...

26/08/08 20:10:27 000002M|01/00/-/---|=4:0740=Beginning of an INT/IP downloading
@:00.80.9f.35.6c.fe (binmg)

Инциденты такого типа все равно должны появляться.
Такое ощущение что у вас чего-то позакрывали, порты какие-нибудь или трафик (типа tftp).
А есть в тех краях IP телефоны привязанные к процеесору? Не ругаются на tftp сервер (не отвечает или файлед) при рестарте?

нет, айпишных нет телефонов
инциденто таких хватает буду сейчас их искать для моего GD, посмотрю

давно было
прикрутили доп.вынос GD от CS, лан шел по оптике в другое здание, по этой же оптике бегал помимо войсового трафика и компомский траффик.
через неделю стали жаловаться что в нутри выноса притензий к качеству голоса нет, а вот когда звониш в город или на другой вынос то частенько появлялось, не так часто но и бывало что голос пропадал, а было что и вынос gd ребутился.
в сему причиной было что вся локальная сеть построена на "бестолковых" коммутаторах, т.е. компомский траффик голос давил

у вас не такая схема?

и еще на GD желательно прописывать статику

на GD везде статика.
Сеть везде нареза на виланы для голоса и для даты. Трафик тоже разделен, голосовой трафик идет с метками, приоритет опять же у голоса. на каждой точке рядом с выносом собственные коммутатор, рутер и шифровалка, настроенные по единому шаблону. Сеть свои же ребята настраивают, так что спросить есть с кого за правильность настройки 8-)

стоит ставить патч 24, по смотрел по логам там много было поправок как к GD так и к PCS

практически нереально, т.к. сначала надо пропатчить все PCS, а залить 200 метров через, по большей части, не достаточно быстрые и стабильные каналы достаточно проблематично. Официальный патч 23, а 24 limited Avalibility был.



Редактировано 1 раз. Последний раз 02.04.2009 14:26 пользователем Vsjakov.

перегружали вынос отключением-включение питания - никаких инцидентов касательно GD на станции вообще не появлялось. Про PCS, как положено, все писалось - отвалилось-поднялось.
Когда заходишь в Ethernet параметры выноса, на GD не видать IP адреса.
МАС, маска, шлюз есть, а самого адреса нет.

А полка с этим GD видится в сервисе? А то, может она от PCS давно работает?

у PCS стоит режим Inactiv, ну а полка out of service
Ну и локальная телефония не работает, так что - исключено

хм... может юзВера на своих компах прописали такой-же IP-ик как на gd?
инцидентов по поводу диблировании ip-адреса не появлялся?

если на GD статика смотрите в разделе dhcp - static adress чтоб присутствовал mac gd

и еще на gd в настройках mgconfig - cristal выбирается динамически или статически?

думаю что надо добиться того чтоб gd поднялась от проца сама без участия pcs и потом пересенхронизировать pcs



Редактировано 1 раз. Последний раз 06.04.2009 21:25 пользователем error.

исключено появление такого же адреса. Там жестко виланами на свичах все разделено. Ну и проверяли уже, на всякий случай.
Адреса стоят статикой, cristal выбирается динамически везде.
GD ни с PCS не поднимается, ни без него.
Появились инциденты, говорящие о коллизиях на INTIP по адресу 2-20 это центральная станция.

Коллизии на INTIP это ерунда, для запуска GD должна достучаться до процессора.
Надо смотреть (особенно если процессора дублированные) lanpbx файл. Если IP адреса процессоров менялись и правили этот файл - изменения возьмутся только после перезагрузки.
И выносе надо смотреть по ком порту что происходит после включения питания на GD. Скидывать в лог и смотреть.

Ну и естественно вопрос менеджмента на тему безопасности - можно на маршрутизаторе на выносе написать - для IP адреса GD разрешено все, выключить/включить GD и посмотреть. Вдруг после того как все уже работало - взяли и закрыли tftp или еще чего.

адреса как в процессе запуска прописал так и не трогал, план адресов утвержден и заверен большой круглой печатью 8-).
с безопасностью второй день уже разбираемся, вроде бы ничего не закрывали, перепроверяют по новой

а ежели действительно, на GD жестко прописать номера шелфов, как центральный проц их искать будет? По идее номер полки должен исключать ввод МАС адреса, судя по описанию...
а lanpbx файл вообще не создан на станции

No previous lanpbx.cfg file.



Редактировано 1 раз. Последний раз 07.04.2009 16:39 пользователем Vsjakov.

Исключает ввод МАС адреса галка в IP/INTIPB параметрах - проверка адреса при загрузке по tftp.