Работа с TDX

[ua4frr]

У нас одна корзина TDX, прикупаем оборудование чтобы полностью в дальнейшем с нее уйти.

Что могу сказать - я ни чего не платил (5 корзин), обновлялся регулярно и получил эту лицензию на все шасси за "просто так"...потом датчане решили поднимать на этом гешефт..после "серой" TDX, пошла "черная" версия Black Edition и вот с нее уже это стало платным...увы...
Узнавали почем сиё "счастье" сейчас?

UPD: сам уже узнал - и опупел от ценика...1147+НДС с этого года...не в рублях...и даже не в долларах...

[alexdirty]

Имеется в проде 4 шт. Triax TDX в двух локациях (по 2 шт. в каждой, разные города). Между собой в каждой локации они не объеденены. Каждая TDX сама по себе.

ЛОКАЦИЯ #1 TDX1 - Версия служебной программы TDX: 1.0.38, Используемая версия прошивки:4.8.1.40964
ЛОКАЦИЯ #1 TDX2 - Версия служебной программы TDX: 1.0.38, Используемая версия прошивки:4.8.1.40964
ЛОКАЦИЯ #2 TDX1 - Версия служебной программы TDX: 1.0.38, Используемая версия прошивки:4.8.1.40964 - есть ребуты
ЛОКАЦИЯ #2 TDX2 - Версия служебной программы TDX: 1.0.45, Используемая версия прошивки:6.1.1.42829 - есть ребуты

В одной из локаций (ЛОКАЦИЯ #2) есть проблема: оба TDX стабильно уходят в ребут через 7 недель 17 часов. Если взять и обе TDX перезагрузить в один момент, то через 7 недель и 17 часов они обе одновременно перезагрузятся, а если один из TDX преднамеренно перезагрузить отдельно от второй, то они будут перезагружаться каждая через 7 недель 17 часов от времени последней перезагрузки. В проблемной локации обновили ПО до 6.1.1.42829, не помогло. Ставил трафик с порта управления на дамп, ничего подозрительного перед ребутом нет.

Сразу после ребута скачивал лог, тоже я не увидел ничего, что могло бы помочь найти причину.

Сталкивался ли кто с аналогичной проблемой?

---

PS: мне известна и не раз подтверждена проблема, что станцию лего можно отправить в ребут, выявил я это ещё в 2018 году и сообщал дистрибьютеру и даже производителю писал, но проблема эта так же осталась и на свежем ПО 6.1.1.42829.  Однако сейчас проблема не в  этом, т.к. ещё в 20218 году, все порты на управление кроме 80 были закрыты файерволам даже внутри локалки.

Описание проблемы:

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

На самом деле ситуация критичная для многих пользователей Triax, так как многие из них оставляют станцию доступной в локальной сети, или даже в сети интернет с выделенным IP адресом. На момент обнаружения проблемы в глобальном интернете было доступно по IP около 170 станций Triax по всему миру (это из тех кто открыт "наружу").

Официальный Triax, на тото момент вероятно не стал до конца читать моё письмо и отписался, что необходимо обратиться к региональным представителям.

Если выполнить сканирование TCP порта 943, станции отправляются в ребут.

$ nmap 192.168.100.12 -p 943

Starting Nmap 7.01 ( https://nmap.org ) at 2018-06-15 10:33 MSK
Nmap scan report for 192.168.100.12
Host is up (0.040s latency).
PORT STATE SERVICE
943/tcp open unknown

Проверили это на 6-ти разных станциях, в том числе и у других операторов.

Но есть некоторые нюансы с воспроизведением перезагрузки станции по вышеописанной проблеме. На самом деле утилита NMAP для Windows не вызывает проблемы. Если воспользоваться этой же утилитой из под Linux (проверялось на Nmap верси >=7.01), то проблема есть.

Не на всех TDX эта проблема вопроизводится.

Если кто хочет потестить и увидеть проблему воочию, то могу в ЛС дать IP открытой наружу TDX на которой проблема вопроизводится.

[ua4frr]

Доброго коллега, можем пообщаться в ТГ по поводу Триакса, как бы мне интересно, найдите меня в ТГ по моему нику (форум). У меня в работе 4 шасси в одной ГС, 3-и из которых работают в связке под единым управлением. Перезапуски у меня тоже есть и разобраться с ними я не смог, как и понять логику. В логах последнее что можно уловить - это как запускается ВанчДог отсчитывающий время до рестарта. Мое мнение - это косяк в ПО (намеренный или нет - тут ХЗ), предположу, что где то в самом железе не хватает места в ПЗУ, и оно не может больше туда писать что то, а как очистить - перезапустить шасси для очистки места...примерно также ведут себя модуляторы ПАЛ, когда ошибок нахватают с потока и их память заканчивается - дальше ребут модуля...
Сейчас у меня везде стоит - 4.9.1.41317 (на 5 или 6 не стал уходить, там нет фиксов каких либо по моему). По поводу ребутов шасси ранее неоднократно создавал тикеты у датчан, даже общался с ними по почте, потом они меня забанили черти. А на основе моих наработок написали несколько мануалов для своей Вики, что вообще обидно мне...
Так что пиши в ТГ мне, поделимся опытом так сказать, потом сюда уже обобщенно выложим...заключени е по пациенту)))

[alexdirty]

Списались. Общаемся.

Добавлю сюда часть лога после ребута:

00001: ### LOG CYCLE STARTS HERE ###
00002: [Wed Nov 11 20:38:47 1970] INFO - CLTriosThread: Starting thread WatchDogController task ptr 0x216FE5D0 ID 9
00003: [Wed Nov 11 20:38:47 1970] INFO - CLTdxUnitInitiator: SystemWatchdog callback registered for HWWatchdog
00004: [Wed Nov 11 20:38:47 1970] ERROR - CLTdxUnitInitiator: System was reset by HW watchdog or HW pins

Тут мы видим, что ребут вероятно произошёл благодаря работе внутреннего HW watchdog or HW pins. Причины пока не ясны.

[ua4frr]

Вот про него я и писал выше в своем посте...считаю это багом или софта или самого железа в связи с не хваткой ресурсов типа ОЗУ/ПЗУ....

[alexdirty]

Чего я только не сделал, чего только не оптимизировал. Ребуты  всё равно повторились, всё так же стабильно через 7 недель и 17 часов.

Если бы дело было в нехватке ресурсов ОЗУ/ПЗУ, то я считаю, что ребуты были бы немного рандомнее, чем стабильно через каждые 7 недель и 17 часов.

Можно конечно бы было поэксперементироват ь и поменять проблемный TDX с непроблемным в другой локации, но что то мне уже не вериться в то, что проблему можно решить без вендора, уже сил нет. Пусть пока так стоит.

Остаётся только по ночам самим ребутить, когда абоненты спят.

[sky star]

таймер розетка в 4 утра понедельника