Комментарии 64
Приветствую.
Познавательная статья.
Не рассматривали более, скажем так, специализированные решения? Например: Digi CM Всё же для большого количества устройств NM-16A маловато.
Познавательная статья.
Не рассматривали более, скажем так, специализированные решения? Например: Digi CM Всё же для большого количества устройств NM-16A маловато.
Всё же для большого количества устройств NM-16A маловато.
Все-таки не NM-16A, а HWIC-16A. Учитывая, что таких можно в 2901 запихать 4 штуки, получаем 64 консоли на устройство (Digi CM с ее 48-ю портами завидует). А ведь роутеру ничто не мешает заниматься и другими делами помимо предоставления доступа к консолям, т.е. даже потеря одного юнита весьма условна.
Я не оспариваю техническую сторону вопроса, ибо сам несколько лет назад расставлял списанные 3640 набитые асинхронными модулями и воткнутым в aux модемом именно для собирания консольных логов, выводов crashdump'ов и coredump'ов, исправления косяков потери управления и пр. Сам по себе метод универсален и применим в большинстве случаев. практически с любым железом.
Между делом — я дописал в конце п.7 про AUX порт. Как-то забыл про это.
А это не пробовали conserver?
Может работать как с терминальными серверами, так и с множеством SOL IPMI соединений.
Может работать как с терминальными серверами, так и с множеством SOL IPMI соединений.
Он умеет подключаться по ssh к терминальному серверу? Что-то не нашел. А набивать физический сервер десятками COM-портов и сложно, и бессмысленно.
Вот пример конфига на
200 портов.
Сам заходит на терминальный сервер. Дает интерактивный доступ к командной строке на любом из подключенных терминальных серверов на любом порту, ротация логов и всякие другие ништяки.
200 портов.
Сам заходит на терминальный сервер. Дает интерактивный доступ к командной строке на любом из подключенных терминальных серверов на любом порту, ротация логов и всякие другие ништяки.
Стразу видно Ынтерпрайз подход. Много, но бесполезно.
Чего много, и что бесполезно?
Сделано много. А логи через консоль бесполезны.
Вам когда-нибудь доводилось всерьез работать с сетевым оборудованием?
(десяток не считается, речь идет про сотни единиц)
Сразу видно СОХО подход, во всех случаях начинающийся со слова «авось»…
Ну и два скрипта, один на десять строк и другой на семь, написание которых заняло аж сутки (долго разбирался, как ssh в фоне вызвать, не сломав редирект) — это невероятно много :)
(десяток не считается, речь идет про сотни единиц)
Сразу видно СОХО подход, во всех случаях начинающийся со слова «авось»…
Ну и два скрипта, один на десять строк и другой на семь, написание которых заняло аж сутки (долго разбирался, как ssh в фоне вызвать, не сломав редирект) — это невероятно много :)
Доводилось. И счет идет на тысячи. Консоль нужна лишь для бутстрапа или емерженси доступа, когда нет инбанд акцесса. Для логов все это БЕСПОЛЕЗНО!!!
Для логов все это БЕСПОЛЕЗНО!!!
Вы второй абзац топика читали? Если ни разу не сталкивались с написанным там, то «счет идет на тысячи» не соответствует действительности, скорее всего и десятка не наберется (только тогда статистически маловероятно наткнуться на подобную аварию за несколько лет). Да и вроде как все остальные отметившиеся в топике понимают необходимость сбора логов с консоли, хотя могут быть сторонниками разных методов осуществления этого дела.
Читал. Притянуто за уши как и вся статья.
Однако, это вполне реальная история, с которой сталкивался каждый. А если нет сервисного контракта, то даже наличие трейсбеков и crashinfo мало поможет, потому чем больше будет информации, тем лучше.
Хотя да, если политика администрирования звучит как «сеть упала — да и хер с ней», то лог в консоль действительно не нужен. Но по-моему, ITшник, не заинтересованный в максимально полном расследовании любой аварии (даже если она не повлияла на качество сервиса), профнепригоден и ему следует срочно переквалифицироваться в уборщики…
Хотя да, если политика администрирования звучит как «сеть упала — да и хер с ней», то лог в консоль действительно не нужен. Но по-моему, ITшник, не заинтересованный в максимально полном расследовании любой аварии (даже если она не повлияла на качество сервиса), профнепригоден и ему следует срочно переквалифицироваться в уборщики…
Я вам по секрету скажу, что в крэшинфо лог есть. А железок, которые не умеют крэшинфо уже можно сказать и нет.
И в 99% случаев вам эта строчка из лога ничем не поможет.
И в 99% случаев вам эта строчка из лога ничем не поможет.
Я вам по секрету скажу, что в крэшинфо лог есть.
А я по секрету скажу, что cat6500 на моей памяти раз 5 падали, не оставив crashinfo. Опять же, с этим сталкивался каждый, кто администрировал достаточное количество железок.
в 99% случаев вам эта строчка из лога ничем не поможет.
Мне это повысит шансы узнать точный баг. Сотруднику TAC — или бага, или четкую информацию, которую можно передать девелоперам.
Но при этом в консоли было написано «у вас баг номер 12345». Дада. Знакомые такеры уже ржут в голос с этого треда.
Но при этом в консоли было написано «у вас баг номер 12345».
Нет, в консоли будет написано что-то вроде "%SYS-2-BLOCKHUNG: Task hung with blocking disabled, value = 0x1. -Process= «Ethernet Msec Timer CFM», ipl= 0, pid= 112" к примеру. В худшем случае. И уже это дает достаточно информации для TAC, чтобы понять, какой там был баг.
Не ваш ли это тред:
www.anticisco.ru/forum/viewtopic.php?f=2&t=3722&start=0
www.anticisco.ru/forum/viewtopic.php?f=2&t=3722&start=0
Нет (достаточно взглянуть на профиль). Однако, у меня на глазах эта же (или очень похожая) ошибка прилетала в консоль, но в сислоге ее не было.
И в крешинфо тоже, да?
Я уже писал, что крешинфо создается далеко не всегда?
Я данном конкретном случае. Не поверю что не было.
Это лишь один случай из многих. Может, тут crashinfo создавался — я не помню. Однако, речь про то, что крэши, при которых и сислог пустой, и crashinfo отсутствует — вовсе не редкость. «Я не сталкивался» — лишь еще один аргумент в пользу «учись на чужом опыте и заранее планируй реакцию на различные сценарии».
Пишу логи на флеш|сислог, никаких проблем нет. В ЦОДах опять же железки с консолями, но там не бывает что бы было в консоли, и не было в логах.
Вот кстати supportforums.cisco.com/docs/DOC-19727
«What if I don't find two crashinfo files for each crash?»
«While in general the IOS for 6500's and 7600's is very good about generating a crashinfo file upon crash, this doesn't always happen. There are bugs and certain scenarios when one or both processors won't generate a crashinfo file. „
Очень умно, учитывая, какое количество платформ не поддерживает дозапись в файл и каждый раз создает по новому файлу. Небось kron'ом squeeze делаете каждый час, чтобы флеш не переполнило?
«What if I don't find two crashinfo files for each crash?»
«While in general the IOS for 6500's and 7600's is very good about generating a crashinfo file upon crash, this doesn't always happen. There are bugs and certain scenarios when one or both processors won't generate a crashinfo file. „
Пишу логи на флеш
Очень умно, учитывая, какое количество платформ не поддерживает дозапись в файл и каждый раз создает по новому файлу. Небось kron'ом squeeze делаете каждый час, чтобы флеш не переполнило?
Циска, кстати, даже такую базовую вещь как базу DHCP snooping категорически советует хранить где-нибудь на tftp, а не локально. Хотя вроде бы никому кроме самого свитча эта база не интересна.
На шеститонниках это аппаратное ограничение, там и консоль не поможет, если сп навернулся.
Бред про squeeze даже комментировать не хочу.
Бред про squeeze даже комментировать не хочу.
там и консоль не поможет, если сп навернулся.
Речь про crash. Нет, консоль поможет. Как лог с нее, так и доступ к железке через нее. Да и как без доступа к консоли понять, что это именно физическая поломка, причем именно на SP, а не просто вываливание в роммон по вине слетевшего конфрега?
Бред про squeeze даже комментировать не хочу.
То есть вы никогда не слышали про классы файловых систем на цискином железе? Жаль.
Ну и все-таки потрудитесь ответить на два простых вопроса чуть ниже.
На 7600 2 процессора, консоль лочится на один, крэш, если там совсем все плохо до консоли не долетит физически. По этой же причине фигня с крэшинфо.
Какой класс файловой системы на ASR9K например? Или на МЕ3800Х? Или на RSP720?
Какой класс файловой системы на ASR9K например? Или на МЕ3800Х? Или на RSP720?
крэш, если там совсем все плохо до консоли не долетит физически.
Еще раз: на 6500-м все прекрасно долетает.
Какой класс файловой системы на ASR9K например? Или на МЕ3800Х? Или на RSP720?
Не поверите: в мире существуют не только операторские, но и ЦОДовые железки (в первую очередь коммутаторы) :)
Как может долететь сообщение от второго проца, когда консоль залочена на первый и он умер совсем?
На вопрос то хорошо бы ответить, раз тему за классы подняли. Кто мне запрещает ставить в ЦОД rsp720?
Нексус например себе для цода железка. Какой класс там?
На вопрос то хорошо бы ответить, раз тему за классы подняли. Кто мне запрещает ставить в ЦОД rsp720?
Нексус например себе для цода железка. Какой класс там?
Как может долететь сообщение от второго проца, когда консоль залочена на первый и он умер совсем?
Говоря о 6500-м: перед смертью первого супа он что-то выплюнет в консоль. После фейловера второй суп начнет писать в консоль.
Кто мне запрещает ставить в ЦОД rsp720?
Целесообразность? Отсутствие поддержки ряда блейдов вроде NAM, IDSM, FWSM? Отсутствие VSS?
Нексус например себе для цода железка. Какой класс там?
А какой класс у не менее ЦОДового 4900? А у 3750-х, которые очень много кто почему-то использует как ToR?
Для тех кто в танке, 2 проца стоят на одном супе/рсп. И там два разных имиджа в них загружаются. Что ж бы основ то архитектуры 6500 и не знаете?
При чем тут целесообразность? Кто запрещает? Никто. И мне абсолютно поровну дебильное деление железа на ЦОД/неЦОД.
Вопрос про классы был вам адресован. Но видимо ответа не дождаться. Пук в лужу засчитан.
При чем тут целесообразность? Кто запрещает? Никто. И мне абсолютно поровну дебильное деление железа на ЦОД/неЦОД.
Вопрос про классы был вам адресован. Но видимо ответа не дождаться. Пук в лужу засчитан.
Для тех кто в танке, 2 проца стоят на одном супе/рсп.
Впервые слышу, чтобы кто-то называл RP и SP «два проца». Ладно бы под данным научным термином понималось «два супервизора в SSO,» о чем я изначально и подумал, услышав этот термин…
И мне абсолютно поровну дебильное деление железа на ЦОД/неЦОД.
Вы просто не представляете себе специфику работы ЦОДов.
Вопрос про классы был вам адресован. Но видимо ответа не дождаться.
Вам дать ссылку на документ, вкратце раскрывающий различие между «A», «B» и «C», или сами найдете? Я никого с ложечки кормить не нанимался.
В том же 4900 (да и в 4500, и в более младших 37-х) самый что ни на есть «B».
Так что самообразовывайтесь.
А два кого, если не проца? Кто не знает что консоль лочится только на один и думает про 2 супа.
Вы совершенно не понимаете зачем эти классы были придуманы. Почему при всем этом работает лог персист подумайте на досуге.
Вы совершенно не понимаете зачем эти классы были придуманы. Почему при всем этом работает лог персист подумайте на досуге.
А два кого, если не проца?
Узнайте на досуге расшифровку аббревиатуры «RSP»…
Кто не знает что консоль лочится только на один и думает про 2 супа.
" там и консоль не поможет, если сп навернулся."
Кто-то не знает, что консоль на втором этапе запуска лочится вовсе даже на RP — и да, при залипании RP и так, и так нужен ребут по питанию. Однако — во-первых, управляемые PDU — сила, а во-вторых, я встречался с огромным количеством багов и аварий на cat6500, но вот ни разу не было ничего, требовавшего ребута по питанию. Да, бывали креши, не оставляющие следов в сислоге или на флеше в виде crashinfo. Много чего другого бывало. Но ничего такого, для устранения чего надо дернуть питание.
Кстати — вы, конечно, не в курсе, но на Sup2T для 6500-го консоль мультиплексируется на CMP, который продолжит отзываться даже после взрыва MSFC. И на нексусах есть нечто похожее.
Вы совершенно не понимаете зачем эти классы были придуманы.
А может, не я, а вы?
Почему при всем этом работает лог персист подумайте на досуге.
Почитайте на досуге, на каких платформах он может писать на флеш, а на каких — нет ;) Я же говорю, вам надо побольше матчасть изучать.
При чем тут рсп? Что за гнилые отмазки. Нечем оправдаться — так и скажите. Не видели багов — не значит что их нет.
И не надо щас отмазываться супом 2т. вместо того что бы признать что на старых супах в консоль ничего не попадет.
На 4900 пишет во флеш. Не пишет только на сохлом говне мамонта, где и саппорта никакого давно уже нет.
Вы, Дима, в очередной раз обосрались.
Я другого впрочем и не ожидал.
И не надо щас отмазываться супом 2т. вместо того что бы признать что на старых супах в консоль ничего не попадет.
На 4900 пишет во флеш. Не пишет только на сохлом говне мамонта, где и саппорта никакого давно уже нет.
Вы, Дима, в очередной раз обосрались.
Я другого впрочем и не ожидал.
При чем тут рсп? Что за гнилые отмазки.
Да, я виноват, я посчитал Роут Свитч Процессор процессором, хотя на самом деле это не так. Каюсь!
И не надо щас отмазываться супом 2т. вместо того что бы признать что на старых супах в консоль ничего не попадет.
Удобный подход. Когда вам это удобно — вспоминаем старые платформы. Когда нет — забываем. Просто потрясающий пример двоемыслия.
На 4900 пишет во флеш.
Ох, воинствующая некомпетентность…
4948#show ver | in 4948|image
System image file is «bootflash:cat4500-entservicesk9-mz.150-2.SG5.bin»
cisco WS-C4948 (MPC8245) processor (revision 0) with 262144K bytes of memory.
4948#show bootflash:
-#- ED ----type---- --crc--- -seek-- nlen -length- ---------date/time--------- name
1… image C278E691 126889C 38 19040284 Oct 1 2010 00:18:10 +04:00 cat4500-entservicesk9-mz.122-54.SG.bin
…
4948(config)#logging persistent url?
% Unrecognized command
4948(config)#logging persistent url bootflash:log
%No «disk0:/bootflash:log» installed
sw-it-stpv#show disk0:
^
% Invalid input detected at '^' marker.
Но сейчас обязательно выяснится, что 4948 не имеет отношения к 4900-й линейке. Обязательно выяснится.
Не пишет только на сохлом говне мамонта, где и саппорта никакого давно уже нет.
И в очередной раз рекомендую хоть чуточку заняться изучением матчасти — а то полная печалька.
Как можно писать на диск которого нет?
%No «disk0:/bootflash:log» installed
%No «disk0:/bootflash:log» installed
Внимательнее. Будьте внимательнее.
1) Данная платформа не поддерживает ни USB, ни CF накопители.
2) Я сделал «logging persistent url ?», и получил матюки.
3) Я интереса ради набрал «bootflash:log», а заругалось на «disk0:/bootflash:log». Это не «ошибка монтажа» :) У данной платформы отродясь не было disk0, есть только bootflash. Откуда хвост — более-менее понятно, тот же образ ставится на cat4500. Даже если указать «logging persistent url tftp://10.0.0.1» — ругается на «disk0:tftp://10.0.0.1». То есть «logging persistent» тут отсутствует в любом виде.
1) Данная платформа не поддерживает ни USB, ни CF накопители.
2) Я сделал «logging persistent url ?», и получил матюки.
3) Я интереса ради набрал «bootflash:log», а заругалось на «disk0:/bootflash:log». Это не «ошибка монтажа» :) У данной платформы отродясь не было disk0, есть только bootflash. Откуда хвост — более-менее понятно, тот же образ ставится на cat4500. Даже если указать «logging persistent url tftp://10.0.0.1» — ругается на «disk0:tftp://10.0.0.1». То есть «logging persistent» тут отсутствует в любом виде.
На 4900М есть cf. И лог персист соответственно.
Поздравляю.
Итак — 4948 официально объявляем не принадлежащим линейке 4900, верно?
Но есть еще одна странность — саппорт на него будет распространяться еще лет 6, что противоречит «не пишет только на сохлом говне мамонта, где и саппорта никакого давно уже нет». Неужели Циска ошибается, и данная железка на самом деле уже давно не поддерживается, только TAC об этом никто не уведомил?
Итак — 4948 официально объявляем не принадлежащим линейке 4900, верно?
Но есть еще одна странность — саппорт на него будет распространяться еще лет 6, что противоречит «не пишет только на сохлом говне мамонта, где и саппорта никакого давно уже нет». Неужели Циска ошибается, и данная железка на самом деле уже давно не поддерживается, только TAC об этом никто не уведомил?
Не верно. Если цыска забыла развести слот, то это ничего не значит. От какой платформы там стоит суп все знают. И на 4500 все работает. Без оговорок на классы файловых систем.
Если цыска забыла развести слот
И у нее нет встроенного бутфлеша, на который вроде бы ничто не мешает писать файлы?
И на 4500 все работает. Без оговорок на классы файловых систем.
Вы, видимо, в пресейле работаете? Других объяснений такому невежеству абсолютно не вижу.
Скрытый текст
4500(config)#logging persistent url ?
% Unrecognized command
4500(config)#logging persistent url sup-bootdisk:log
Translating "persistent"...domain server (X.X.X.X)
^
% Invalid input detected at '^' marker.
4500#show ver | in image|Supe|4510
System image file is "bootflash:cat4500-entservicesk9-mz.150-2.SG5.bin"
cisco WS-C4510R (MPC8245) processor (revision 4) with 524288K bytes of memory.
MPC8245 CPU at 400Mhz, Supervisor V
Объяснение простое, кто-то не умеет настраивать цыски.
В жизни не слышал более осмысленного и конструктивного замечания :)
Хотя да, с sup-bootdisk я погорячился. Но bootflash не работает. Возможно, если вставить CF в внешний слот, она смонтируется как disk0, и если очень повезет — на нее даже будет что-то писаться. Однако, угадайте с одной попытке, какого класса будет ФС на такой карте :)
Хотя да, с sup-bootdisk я погорячился. Но bootflash не работает. Возможно, если вставить CF в внешний слот, она смонтируется как disk0, и если очень повезет — на нее даже будет что-то писаться. Однако, угадайте с одной попытке, какого класса будет ФС на такой карте :)
Ну а вообще, чтобы прекратить этот бесполезный спор, ответьте на два вопроса.
1) Есть ли сценарии, при которых автоматическая запись логов с консоли позволит получить информацию, недоступную другими средствами?
2) Возможен ли какой-либо вред от записи логов, кидаемых в консоль?
1) Есть ли сценарии, при которых автоматическая запись логов с консоли позволит получить информацию, недоступную другими средствами?
2) Возможен ли какой-либо вред от записи логов, кидаемых в консоль?
Каких только костылей не напишешь, если в компании нет нормальных консольных серверов типа Avocent, Openger или Uplogix. Последнии два наиболее продвинутые, с их помощью даже софт локально можно заливать с консольника на железку (не считая стандартных алертов на конкретные паттерны в логах/автоматическая реакция на нихи буферезация всех логов с консолей, даже когда вы их не открываете). Можно даже вставить вместо сгоревшего свитча новый чистый свитч и консольник автоматически сам обновит софт до актуального, зальет последнюю версию конфига и т.п.
с их помощью даже софт локально можно заливать с консольника на железку
Звучит круто, но зачем это надо? По сравнению с передачей файлов по консоли даже TFTP покажется быстрым. Сейчас любой rommon позволяет качать по tftp. А если ОС завелась — заливка по консоли тем более не требуется. Ну и не забываем правило «всегда хранить на флеше последний и предпоследний образы».
не считая стандартных алертов на конкретные паттерны в логах/автоматическая реакция на них
Уже давно есть и более мощные решения по этому поводу. Тот же HP NNM к примеру, с его весьма серьезной многоэтапной логикой. А если сеть перестала работать, и реданданси по каким-то причинам не отработало (т.е. доступ до боевого железа пропал), то это и так означает неизбежное ручное вмешательство через консоль. Автоматизация может сделать только хуже.
буферезация всех логов с консолей, даже когда вы их не открываете
Вот этого и не хватало. Теперь все есть.
Можно даже вставить вместо сгоревшего свитча новый чистый свитч и консольник автоматически сам обновит софт до актуального, зальет последнюю версию конфига и т.п.
Очень плохая идея. Новое железо должно обкатываться в лабе, причем желательно проверить весь используемый функционал, и отправлять ее на установку уже залитой и сконфигурированной.
А то я уже как-то получал по RMA железку, которая работала значительно хуже заменяемой.
А так спасибо за наводку. Но как-то не люблю я полумеры. А указанные железки почему-то кажутся мне как раз решениями «всё в одном» для небольших компаний, которые не могут позволить себе мощные средства мониторинга.
Турбобут без консоли не сделаешь. А аукс там не работает ужа давно.
Турбобут без консоли не сделаешь.
Да и IOS железку из роммона не вытащить без консоли. И?
А когда она сдохнет то и консоль не поможет. И?
турбобут — необходимость штатной эксплуатации, иос в роммоне — аварийной. От аварий защищаются резервированием, а не консольными серверами.
турбобут — необходимость штатной эксплуатации, иос в роммоне — аварийной. От аварий защищаются резервированием, а не консольными серверами.
А когда она сдохнет то и консоль не поможет. И?
И? Это вообще к чему было?
От аварий защищаются резервированием, а не консольными серверами.
Спасибо, Капитан!
Но мне как-то лень ездить в ЦОД по такому поводу. Так что и для IOS устройства наличие подключенной к терминальному серверу консоли — абсолютная необходимость. А наличие лога с консоли позволит узнать, почему железка свалилась в роммон. То есть необходима не только удаленная консоль, но и лог с нее.
Например, у меня давно вошло в привычку перед ребутом cat6500 посмотреть confreg (допустим, 0х2102), поменять его на другой (скажем, 0х0102), сделать write, а потом вернуть обратно и снова сделать write. Ибо уже пару раз напарывался на связанные с этим баги — во всех выводах пишет одно, но по факту проставлено другое.
Это было к тому, что я пытаюсь донести до вас с самого начала.
КОНСОЛЬ ДЛЯ СБОРА ЛОГОВ НЕНУЖНА!!!
Все остальные случаи решаются в штатном режиме. С консолью или без — не важно.
И что же Вам сказал так на ваши баги с конфрегом? Я не очень понимаю зачем еuо дрочить туда-сюда. УМВР (с)
КОНСОЛЬ ДЛЯ СБОРА ЛОГОВ НЕНУЖНА!!!
Все остальные случаи решаются в штатном режиме. С консолью или без — не важно.
И что же Вам сказал так на ваши баги с конфрегом? Я не очень понимаю зачем еuо дрочить туда-сюда. УМВР (с)
Это было к тому, что я пытаюсь донести до вас с самого начала.
КОНСОЛЬ ДЛЯ СБОРА ЛОГОВ НЕНУЖНА!!!
Чушь. Примеры я уже приводил. Если вам не доводилось с ними сталкиваться — рад за вас, но с ростом опыта вам всякое доведется увидеть.
И что же Вам сказал так на ваши баги с конфрегом?
Сотрудник русского TAC. Когда я после поднятия железки через консоль командой boot, а затем после контрольной перезагрузки и нового выпадения в роммон в некотором недоумении завел кейс, приложив к нему логи своих сессий, в которых было четко видно, что и по sh ver, и по sh bootvar регистр был правильным. Это его рекомендация — на всякий случай дернуть конфрег, потому что не всегда применяется корректно. Дернул — и следующий ребут прошел штатно.
Видите, сколько всего чудного можно встретить? А говорите — лог с консоли не нужен :)
Так это не логи, это просто рабочая ситуация. Железка на этапа ввода в эксплуатацию, контрольный ребут. Бывет. Можно было и не мучать так, а просто исправить самому.
Так это не логи, это просто рабочая ситуация. Железка на этапа ввода в эксплуатацию
А если бы она была не в лабе, а в боевой среде — мне было бы исключительно любопытно узнать, что же она писала за миг до выпадания в роммон. Может, она чексумму неверно посчитала? Это уже серьезнее. Команда boot может корректно загрузить железку, контрольный reload не выловит проблем — но в весьма недалеком будущем неизбежны другие глюки данной железки, так как память работает нестабильно, и устройство подлежит немедленной замене.
Можно было и не мучать так, а просто исправить самому.
Вообще-то любое аномальное поведение устройства в лабе автоматически означает прекращение танцев с бубном и заведение кейса — ибо время терпит, а диагностировать проблему проще, когда она актуальна. TAC владеет кун-фу весьма глубокого сбора данных с железки.
С моей подачи было открыто штук 5 новых дефектов, и еще пару раз обнаруживали известную багу, которой в данной версии софта быть не должно было, но она была.
Так там выше ваше или нет? Dmytro O. Redchuk вы или нет? Что то не видно открытого кейса.
habrahabr.ru/post/152024/#comment_5163561
В мире, наверное, только один Дмитрий, администрирующий сети :)
Когда мое железо работает плохо, я на форумах вопросы не задаю.
В мире, наверное, только один Дмитрий, администрирующий сети :)
Когда мое железо работает плохо, я на форумах вопросы не задаю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Централизованный сбор логов с консолей сетевого оборудования по ssh