MES3124F висит и не перезагрузить удаленно

[pk2016]

SW version 2.5.44[a0025cf1] ( date 12-Jan-2016 time 16:52:13 )

Поставили коммутатор на удаленную площадку, не проработал и недели.
Вот такая вот картина

Escape character is '^]'.




User Name:admin
Password:*********


sw#reload
30-May-2016 20:39:02 %AAA-I-CONNECT: User CLI session for user admin over telnet , source 10.1 destination 10.1 ACCEPTED
30-May-2016 20:44:14 %AAA-I-CONNECT: User CLI session for user admin over telnet , source 10.1 destination 10.1 ACCEPTED


Я так понимаю память закончилась, или что ?

Как его перезагрузить то ?

[Прокопьев Максим]

Здравствуйте.
1. Коммутатор в данный момент доступен по IP?
2. Имеются ли проблемы с прохождением абонентского трафика?
3. Проводился ли мониторинг загрузки CPU до зависания (например, по SNMP)?
4. Имеется ли возможность подключиться через COM?

[pk2016]

1. Был доступен какое-то время, при условии что добавлен был статик арп на его дефолт роутере, и телнет запускался с этого же дефолт роутера. Причем вывод любой команды заканчивался переходом на новую стоку и все.
2. Да, абон. трафик не ходит совсем. Это при том , что там 3 вилана, и 3 правила qinq. Трафик ходил лишь между двумя портами Te1/0/1 и Te1/0/2.
3. Да, график вложу
4. Нет, возможности нет. Еще и установлен на необслуживоемом узле.

Вывод - пользоваться этим невозможно. Какая процедура возврата изделий производителю?

P.s. Из около 50 работающих d-link dgs-3420 ни один вот так не уходил в себя. Лет за 5 уже

[Прокопьев Максим]

1. Был доступен какое-то время, при условии что добавлен был статик арп на его дефолт роутере, и телнет запускался с этого же дефолт роутера. Причем вывод любой команды заканчивался переходом на новую стоку и все.

При этом ping до коммутатора был с потерями?

2. Да, абон. трафик не ходит совсем. Это при том , что там 3 вилана, и 3 правила qinq. Трафик ходил лишь между двумя портами Te1/0/1 и Te1/0/2.

Графиков загрузки портов нет?
Проблему с линией, SFP исключаете?

3. Да, график вложу

CPU не загружен. Максимум 4%.
К сожалению, с подобной проблемой ранее не сталкивались. Поэтому для выяснения причины требуется больше информации.
Просьба подключиться через telnet (если, конечно, имеется доступ и возможность) и из debug режима предоставить следующую информацию:
console# debug
debug
Enter DEBUG Password: *** (Пароль: debug)
print os mem
print os bufs
set tasks utilize
print tasks utilize
Вывести команду:
print os tasks
Затем посмотреть ID для задачи, которая грузит CPU и если такая есть, то вывести несколько раз
print os stack ID

Если же по telnet доступа нет, но все-таки появится возможность подключиться через COM, то прошу снять информацию через консоль по приведенной выше методике. Также, если будет возможность, то предоставьте информацию из CLI по командам:
show tech-support
show fiber-ports optical-transceiver detailed interface <имя интерфейса> //для всех активных портов
show interfaces counters <имя интерфейса> //для всех активных портов

[pk2016]

Сегодня перезагрузили его, поднялся, убрали правила selective-qinq, оставили минимум виланов - три, включая 1.
Понизили софт
SW version 2.5.42 ( date 18-Sep-2015 time 10:37:42 )
Boot version 0.0.1.2 ( date 12-Dec-2012 time 19:10:41 )
HW version 02.07
CPLD version 03

1. Надеюсь , эти шаги помогут избежать проблемы ?

2. Запрошенную информацию (правда после перезагрузки), отправил на techsupp@eltex.nsk.ru ( не хочу тереть вывод, дескрипшны там и остальное, для выкладывания на форум)

[Прокопьев Максим]

1. Надеюсь , эти шаги помогут избежать проблемы ?

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

2. Запрошенную информацию (правда после перезагрузки), отправил на techsupp@eltex.nsk.ru ( не хочу тереть вывод, дескрипшны там и остальное, для выкладывания на форум)

В полученной информации ничего критичного нет.
Конечно, вывод из debug режима хотелось получить до перезагрузки коммутатора.
Пытались ли подключиться через COM к коммутатору до перезагрузки? Был ли доступ?
Прошу предоставить конфигурацию, которая была во время зависания.
Имеются ли графики загрузки портов на тот момент?
Также прошу сообщить через какой порт производился доступ к коммутатору.

Прошу произвести дополнительную настройку.
1. изменить уровень логирования до debugging:
console(config)#logging file debugging
2. включить логирование введенных команд:
console(config)#logging cli-commands