Как померить потери на коммутацию?

При нулевой нагрузке? Делов на две минуты.

Как померить потери на коммутацию?

Можно так. Можно на каждом запустить tcpdump и смотреть разницу во времени между входом пакета и его выходом.

VISIO, EXCEL и Putty

Начальник отдела безопасности, приказывающий хранить логины и пароли в скрытых полях екселя? Слово «дуб» слишком льстит ему.

Логирование фоновых ssh сессий?

Тут два варианта: либо железо совсем говно и подлежит замене

Вообще говоря — есть немного. Особенно SUP720-10G в последнее время подводят. Причем как-то раз полученная по RMA замена, успешно пройдя тестирование, в боевом шасси падала раз в несколько минут. Вторая замена (тот же конфиг, тот же иос) — и проблем нет.

кто-то не соответствует занимаемой должности и также подлежит замене

В последнее время думается мне, что занимаемой должности не соответствуют руководители отделов разработки и тестирования в Cisco Systems, не говоря уже о самих разработчиках и тестировщиках. К сожалению, не удается десятилетиями сидеть на одной версии софта, иногда приходится обновляться… Да и с железячниками не все хорошо. Как-то раз полученный по RMA 720-й суп работал куда хуже заменяемой железки, хотя в лабе вел себя идеально, не обкакавшись ни одним трейсбеком и ни разу не упав. Пришлось еще раз менять.

и совсем другое — сабжевая реализация сбора логов.

А что в этом плохого?
Какие есть профиты:
1) Иногда может предоставить информацию, которую невозможно получить иным образом.
2) Лишнее резервирование централизованного сислога и SNMP, т.е. надежность сервиса «сбор логов» повышается в любом случае.
3) Интересно же. Я не прочь на досуге поговнокодить, да и вообще изучить что-то новое.

А также отсутствие коммерческих решений на эту тему, ну и отсутствие угроз безопасности (соединение шифровано, в консоль боевой железки логиниться не надо, доступ используемой для сбора учетки легко ограничивается коротким перечнем железа и нулевой длины списком команд) либо надежности работы серверной или сетевой инфраструктуры со стороны такого скрипта. Нету рисков.

А какие минусы видит г-н архитектор в логировании с консоли по сравнению с отсутствием логирования с консоли? Наверное, очень серьезные, раз ты так разволновался…

Шепну по секрету: по достоверной информации где-то 5-летней давности от бывшего винадмина ЦБ, существенная часть бекапов виндовой инфраструктуры была построена там на батниках. И ничего, ни разу не подводило. А ведь это — бекапы, штука ну очень критическая, а ЦБ не назовешь конторой, обделенной бюджетом…

Логирование фоновых ssh сессий?

Да я по ссылке на предыдущий уже все понял, что ты сторонник самоделкин-way.

А ты, конечно, сейчас поделишься правильным вариантом…
На самом деле я как раз категорический противник «самоделкин-way» по любым мало-мальски критическим направлениям. Однако, использование роутера с чем-то вроде HWIC-16A является Cisco-approved методом организации подключения к консолям железок. У них даже продается соответственно названный бандл под это дело — CISCO2901-16TS/K9 «2901 w/ HWIC-16A and 2 CAB-HD8-ASYNC Terminal Server Bundle». Любопытная такая самоделка. И кстати, что-то я не видел в продаже ни одного более удобного решения, с аналогичной плотностью — все-таки 64 консоли на юнит, причем железке никто не мешает параллельно заниматься другими делами. Нет, девайсов класса «network serial concentrator» до черта, но выполняют они в точности то же: железка собирает данные с консолей и выплевывает их в сторону сервера, причем вовсе не по syslog…
А еще есть маленькие филиалы, в которых стоят маленькие роутеры вроде 2911 и маленькие свитчи вроде 2960. От роутера до свитча неплохо бы протянуть rollover кабель…
Что до надежности самодельного сборщика логов — от него даже двух девяток никто не требует. Хотя при этом резервировать — как два пальца.

как часто происходят такие вот ужасные сбои?

Где-то в среднем раз в полгода происходит авария одной из сотен железок, полного понимания причин которой нет, т.е. по моим стандартам слишком часто.
А ты правда считаешь, что дополнительная информация — это плохо, даже если она пригодится раз в пару лет?

Сислог, кстати, тоже можно по tcp передавать

Угу. А если в момент генерации сообщения сеть у железки уже отказала — есть ли разница? ;)

Логирование фоновых ssh сессий?

Я пока не понимаю, что за загадочные «логи с линий»

habrahabr.ru/post/112033/
То, куда подключена консоль, зовется line X.

надежность решения с ssh будет ниже, чем с syslog+snmp.

Надежность консоли несравнимо выше надежности syslog/SNMP. Как я уже писал, то, что умирающая железка может не успеть послать в сеть, она точно выплюнет в консоль. Где эти сообщения поймает другая железка. Соединенная с out-of-band management сетью, функционирующей независимо от подключенных к ней консолью устройств. Кроме того, в отличие от сислога, ssh работает поверх TCP. Те несколько секунд, что может отрабатывать реданданси, все отправляемые по сислогу сообщения будут дропаться, а вот ssh будет ждать дольше, и после восстановления сразу все выплюнет на сервер. Это может сильно упростить выявление причин серьезных аварий.
Ну а если сервер сделать не виртуальным, а физическим, и одним портом воткнуть в терминальный сервер — что бы не произошло, ни одно полезное для диагностики сообщение не будет потеряно.
Еще раз, назначение всей схемы — услышать и записать последние слова умирающего, а кроме того собирать лог перезагрузки. Это не заменяет, а дополняет настроенный локально на железках syslog/snmp.

Предлагаю продолжить споры в будущем топике на эту тему. В нем я постараюсь получше разжевать необходимость записи событий с консоли.

Логирование фоновых ssh сессий?

Нет ничего проще, чем собирать логи с цисок и терминальных серверов.

Логи, отправляемые самой циской средствами «logging x.x.x.x», в общем случае годятся, но иногда их мало. Когда циска падает, она не всегда успевает отправить сообщение об аварии в сислог (но в консоль — всегда), она не всегда создает crashinfo, она не всегда дает внятную информацию о причинах падения в show ver. Я на это напарывался уже дважды, на разных железках, в обоих случаях TAC не смог установить причину аварии, как и воспроизвести ее. Инженер TAC рекомендовал озаботиться этим самым централизованным сбором логов конкретно с консоли — он сам так делал на прошлой работе, и это много раз давало бесценную информацию. Правда, скриптами поделиться не смог, ибо потеряны.
А в logging buffer терминальной железки не включаются логи с линий. А если бы и включались — была бы страшная мешанина.

Логирование фоновых ssh сессий?

Откуда слать? Терминальный сервер — цискин роутер. К тому же, их много — на каждом писать TCL скрипты или EEM апплеты, редиректящие сообщения в сислог? Да и я как-то не в курсе, каким образом перехватывать сообщения, приходящие с AUX-образных линий. Да и разделять их, дабы не было каши, непросто.
А на сервере, который как раз собирает логи консолей с терминального сервера, можно сделать с ними что угодно, включая их пересылку на сислог. В принципе, я уже все настроил, и оно работает отлично. Добавление нового устройства на сервере — одна маленькая строчка в конфиге. Учитывая, что всего железок с HWIC-*A или задействованными под соединение с консолью AUX портами сотни, это весьма здорово :)
Скорее всего, я все-таки напишу статью по этому поводу. Или завтра, или на следующих выходных. Все-таки централизованное логирование именно с консолей (не доверяя поднятому на железках сислогу или SNMP) — маст хев.

Логирование фоновых ssh сессий?

expect timeout

Логично. Сам почему-то не догадался.
Спасибо!

Логирование фоновых ssh сессий?

Вот, это было бы хорошо упомянуть в исходном вопросе.

На самом деле боевой скрипт будет слушать вовсе не броадкасты.
Я думал, «установить ssh соединения с несколькими системами — и писать в файлы (по одному на соединение) все, что прилетит от тех систем, ничего не отправляя.» — вполне понятно, но да, задача нетривиальная, понять смысл непросто :)

Заодно: мне не очень нравится expect «impossiblesequence». Как-то это не очень красиво. Есть ли более правильный способ сделать так, чтобы к «sleep 10» и на повторную итерацию цикла оно уходило только после завершения «spawn ssh»?

Логирование фоновых ssh сессий?

Что может прилететь, если на той стороне ничего не происходит в текущей сессии?

Много чего.
Подключение идет к портам терминального сервера, к которому подключены консоли (COM порты) разнообразных железок. Эти железки периодически шлют сообщения в консоль. Надо эти сообщения записывать. В принципе, если руки дойдут, я напишу статью на эту тему — дело важное, а временами и спасительное.
В случае тестовой среды без реального терминального сервера можно просто подключиться к другому линуксу (или даже к 127.0.0.1) и писать в файл все прилетевшие в TTY броадкасты, руками генерируя их. Это полностью воспроизводит ситуацию.
Отметая вопросы: локальные решения на терминальном сервере работать не будут, нужна именно сторонняя система, подключающаяся по ssh и слушающая порты.

Проверил оба — сразу уходят в фон, а в лог пишется.

Учитывая вышесказанное, спрошу — ssh сессия висит ничего не делая и пишет услышанное в файл, или сразу закрывается? Если последнее, то не годится.

Логирование фоновых ssh сессий?

Кстати, все равно буду благодарен за более красивое решение задачи. Только просьба сначала проверить, что оно действительно работает :)

Логирование фоновых ssh сессий?

Если хочется ИМЕННО с амперсандом, то вот так:
sh -c 'ssh [e-mail] «do-smth» > /path/to/output' &

В таком виде сессия мгновенно закрывается после выполнения «do-smth», а если его не указывать, то сессия закрывается сразу. А мне нужно висеть долго и писать в файл все, что прилетит.

Логирование фоновых ssh сессий?

Проверил из шелла — каретка не возвращается. Т.е. и цикл не перейдет на следующую итерацию сразу после запуска, не дожидаясь завершения выполнения.

Логирование фоновых ssh сессий?

Задача — именно фоновый запуск, с амперсентом. Я пробовал screen, но он сразу ругается.

Логирование фоновых ssh сессий?

Я именно с этого и начал. И когда внезапно наступил на грабли — начал упрощать задачу до банального вызова из шелла ssh с амперсентом.

Логирование фоновых ssh сессий?

sh -c 'ssh [e-mail] cmd 2>&1' > /path/to/output & — даже без амперсента не работает.
sh -c 'ssh «[e-mail] cmd 2>&1»' > /path/to/output & — без амперсента работает, с ним нет.

Я и говорю — задача не такая тривиальная, как кажется. Почему-то ssh из бекграунда категорически не хочет слать в srdout. Есть возможность проверить на другой системе? Может, баг какой.

Логирование фоновых ssh сессий?

Тоже проверял.
sh -c 'ssh [e-mail]' & > /path/to/output — файл создается, но не наполняется.
sh -c 'ssh [e-mail]' > /path/to/output — файл создается и наполняется. Но в фоне не работает.
И повторюсь — никаких команд слать не нужно. Только слушать. Слать можно, но только если без этого никак.

Скорость работы оперативной памяти?

Ссылки на исследования вопроса есть выше и ниже. Как раз повод подумать. Попробуйте — вдруг понравится? :)

Какую cisco взять для автономной системы?

Разумеется. Они много чего знают.