Troubleshooting что это за программа

Как запустить мастера устранения неполадок Windows (самодиагностика и лечение системы)

Доброго дня!

Оказывается не все знают, что в Windows есть достаточно эффективная система самодиагностики и «лечения» (исправления ошибок). При возникновении самых разных проблем (например, со звуком, с сетью, Bluetooth, питанием и т.д.) — можно тремя кликами мышки запустить мастер устранения неполадок — и через 2-3 мин. получить работающую систему!

Заранее предупрежу, что если проблема носит аппаратный характер (например, сломался Wi-Fi адаптер) — то никакой мастер в Windows вам не поможет (если только подскажет, что «такое-то устройство не отзывается». Хотя не спорю, даже это может оказать неоценимую помощь диагностике).

Собственно, ниже в заметке приведу парочку способов, как можно запустить мастера самодиагностики в Windows (актуально для ОС Windows 10/11).

Introdução ao Troubleshooting de Computadores Resolução de problemas de hardware e software

Итак.

Средство устранения неполадок: способы запуска

Вариант 1

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

Действия по порядку:

• сначала необходимо открыть панель управления/контрольную панель (сочетание Win+R , команда control );
• перевести режим отображения в «Мелкие значки» ;
• в меню должна появиться ссылка «Устранение неполадок» — необходимо открыть ее;
• далее нажмите ссылку «Просмотр всех категорий» , и укажите свою проблему;
• должен запуститься мастер самодиагностики : он проверит основные настройки, работу служб, и пр. См. пару скринов ниже с примерами.

Панель управления — устранение неполадок

Все категории — выбор мастера (в чем проблема)

Обратите внимание, что перечень проблем, по которым можно запустить самодиагностику достаточно широк:

1. Bluetooth;
2. воспроизведение звука;
3. голосовые функции;
4. питание;
5. принтер;
6. клавиатура;
7. обслуживание системы;
8. подключение к сети Интернет;
9. центр обновления и пр.

Вариант 2

• нажать Win+i чтобы открылись параметры системы (либо воспользоваться меню ПУСК);
• перейти в раздел «Обновление и безопасность» и открыть ссылку «доп. средства устранения неполадок» ;
• затем из предложенного списка выбрать свою проблему и подождать 2-3 мин., пока не появится результат сканирования.

TroubleShooting — O que você precisa saber sobre Resolução de Problemas e Manutenção Preventiva

Устранение неполадок — обновление и безопасность — Windows 10

1. нажать Win+i чтобы открыть параметры системы;
2. далее перейти в раздел «Центр обновления / Восстановление / Устранение проблем, не возвращая ПК в исходное состояние / Другие средства устранения неполадок» ;
3. затем появится список мастеров самодиагностики — останется выбрать нужный.

Центр обновления — восстановление — Windows 11

Другие средства устранения неполадок — Windows 11

Вариант 3

Попробуйте кликнуть по строке поиска (значку с лупой), расположенной рядом с кнопкой ПУСК — далее нужно ввести «troubleshooting» и нажать кнопку «Открыть» (вместо «troubleshooting» можно указать «параметры устранения неполадок») .

troubleshooting — поиск с помощью лупы (Windows 11)

Другие средства — Windows 11

Вариант 4

Универсальный способ! Для начала нужно:

1. запустить командную строку от имени администратора;
2. ввести команду вида msdt.exe/id DeviceDiagnostic и нажать Enter (обратите внимание, что вместо DeviceDiagnostic можно указать ИД того мастера, который вам нужен. Полный их список у меня приведен чуть ниже скриншота ) ;
3. должен появиться мастер диагностики.

Запуск мастера устранения неполадок через командную строку

Список ИД аббревиатур мастеров (вводить в командную строку только то, что выделено зеленым):

• AeroDiagnostic — устраняет проблемы с эффектами Aero;
• AudioRecordingDiagnostic — устраняет проблемы с микрофоном;
• AudioPlaybackDiagnostic — устраняет проблемы со звуком при воспроизв. и медиа-файлов;
• DeviceDiagnostic — устраняет проблемы с оборудованием, подкл. к ПК;
• HomeGroupDiagnostic — устраняет проблемы с лок. сетью: просмотром компьютеров или общих файлов в домашней группе;
• NetworkDiagnosticsInbound — устраняет проблемы с брандмауэром Windows;
• NetworkDiagnosticsWeb — устраняет проблемы с подключением к Интернету (веб-узлу);
• NetworkDiagnosticsNetworkAdapter — устраняет проблемы сетевыми адаптерами;
• NetworkDiagnosticsDA — устраняет проблемы с подключением к Интернет, лок. сетью;
• NetworkDiagnosticsFileShare — устраняет проблемы с общими файлами и папками;
• PerformanceDiagnostic — помогает пользователю повысить производительность ОС;
• PowerDiagnostic — диагностика параметров питания (аккумулятор, режимы сна и пр.);
• PrinterDiagnostic — диагностика принтера, устранение проблем при печати;
• PCWDiagnostic — настройка старых программ для их корректной работы в современной Windows;
• SearchDiagnostic — устраняет проблемы поиска и индексации;
• WindowsMediaPlayerDVDDiagnostic — устраняет проблемы, возникающие при воспроизв. DVD;
• WindowsMediaPlayerConfigurationDiagnostic — сбрасывает настройки проигрывателя Windows Media;
• WindowsUpdateDiagnostic — устраняет проблемы с центром обновления Windows.

Вариант 5

Если все предыдущие способы не помогли — попробуйте стороннее решение: утилиту FixWin (ссылка на офиц. сайт // кнопка загрузки там в самом низу страницы ).

После ее запуска нужно перейти в раздел «troubleshooters» и указать нужный раздел (утилита на англ., но многое понятно из контекста. Также можете воспользоваться спец. переводчиками).

FixWin — утилита для исправления ошибок в Windows

За сим откланяюсь, всем успехов!

Источник: ocomp.info

Средство устранения неполадок в Windows 7

Нередко в ходе активной работы с компьютером или ноутбуком в Windows могут происходить различные ошибки и проблемы. Их причиной становятся необдуманные и неверные действия пользователя, некорректная установка и обновление программ, операционной системы. Для не очень опытных юзеров даже небольшой сбой в работе может оказаться трудноразрешимой задачей, не говоря уже о попытках диагностировать источник нестабильной работы ОС.

Встроенное исправление ошибок Windows 7

В Windows 7 было встроено «Средство устранения неполадок», о котором знают далеко не все. Оно проверяет работу различных системных компонентов и при выявлении ошибки уведомляет пользователя и исправляет ее. К сожалению, в возможности утилиты заложены только основные и распространенные проблемы, с которыми сталкивается большинство человек. Поэтому она рассчитана только на начинающую аудиторию и не может устранить затруднительные ситуации, встречающиеся реже.

Стоит отметить, что данный инструмент запускается только при работающей ОС. Открыть его перед загрузкой Windows или в ходе перезагрузки нельзя. Для восстановления работоспособности системы требуются другие действия.

Компоненты и службы, которые можно исправить

Используя встроенную программу проверки Windows, можно найти и исправить следующие ошибки:

Программы (проблемы с подключением к интернету, запуском старых программ на Windows 7, работой принтера, Internet Explorer, Media Player);

Оборудование и звук (неработающая запись/воспроизведение звука, проблемы с подключенными устройствами, работой принтера, сетевого адаптера, воспроизведением оптических дисков, вставленных в дисковод);

Сеть и интернет (неудачные попытки подключения ПК/ноутбука к сети, создания общих папок, домашней группы, подключения других компьютеров к вашему, проблемы сетевого адаптера, сетевого принтера);

Оформление и персонализация (некорректно работающий Aero, отвечающий за прозрачность окон);

Система и безопасность (безопасность Internet Explorer, очистка ПК от мусорных файлов, проблемы быстродействия, питания Windows, исправление поиска и индексирования, получения обновлений операционной системы).

Принцип работы «Средства исправления ошибок»

Вне зависимости от выбранного типа ошибки, система всегда запускает одну и ту же утилиту диагностики.

Сперва она выполняет поиск проблемы, проверяя все сопутствующие системные компоненты, программы, службы.

Если та была обнаружена, утилита может исправить ее самостоятельно, уведомив пользователя об этом.

Вы можете просмотреть список обработанных найденных и потенциальных проблем. Для этого нажмите на ссылку «Просмотреть дополнительные сведения».

В открывшемся окне отобразится все то, что подлежит диагностике.

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

При отсутствии найденных проблем вы получите соответствующее сообщение.

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

Запуск «Средства исправления ошибок»

Есть два способа запуска инструмента — через «Панель управления» и командную строку. Разберем оба.

1. Откройте «Пуск» и выберите «Панель управления».
2. Переключите просмотр на «Мелкие значки», найдите и нажмите на «Устранение неполадок».
3. Нужная утилита запустится.

1. Откройте «Пуск», напишите cmd и откройте командную строку.
2. Введите команду ниже и нажмите Enter. control.exe /name Microsoft.Troubleshooting
3. Откроется окно со списком распространенных неполадок.

Используя панель слева, вы можете воспользоваться дополнительными возможностями:

• Переключить вид категорий. Отображение категорий будет выведено списком, а не отсортировано, как в варианте по умолчанию.
• Просмотр журнала. Здесь отображается то, что для диагностики вы запускали ранее. Нажав на «Подробности», можно еще раз ознакомиться с результатами проверки и исправления.
• Настройка. Предлагаются всего 3 параметра, которые обычно не нужно менять.

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

Мы рады, что смогли помочь Вам в решении проблемы.

Источник: lumpics.ru

Цифровая трансформация цементного завода (ч. 6): траблшутинг на предприятии

Траблшутинг (англ. troubleshooting — устранение неполадок, работа над проблемой) — форма решения проблем, часто применяемая к ремонту неработающих устройств или процессов. Представляет собой систематический, опосредованный определённой логикой поиск источника проблемы с целью её решения.

Какие у вас возникают ассоциации, когда слышите фразу «при зависании весов сотрудник КИПиА идет на участок автоотгрузки и перезагружает весовой терминал»?

Старая проблема с «зависанием» весовых терминалов Mettler Toledo на участке автоотгрузки цемента

Участок отгрузки навального цемента на заводе представляет собой 2 силоса, под каждым из которых установлены статические автомобильные весы Mettler Toledo для взвешивания цементовозов — до начала и после окончения отгрузки. В третьей части я уже рассказывал об этом.

Периодически я слышал, что на заводе иногда «зависают» автомобильные весы, из-за чего приостанавливается отгрузка. И возобновляется после того, как на место приходит сотрудник КИПиА и «перезагружает» весы.

Слышал я об этом потому что, как правило, звонки или письма от автодиспетчеров сначала поступали в мое подразделение к консультанту 1С. Тот диагностировал проблему, понимал, что «зависание» весов не связано с ERP-системой и передавал задачу в смежное подразделение — отдел автоматизации производства, сотрудники которого находятся непосредственно на заводе. Начальник отдела автоматизации производства считал, что весы «зависают» из-за некорректной интеграции с ERP-системой.

Но многократные проверки контура программной интеграции весов с ERP-системой показывали, что в 1С проблем не возникает и «зависание» происходит на стороне весовых терминалов.

Надоедливые письма и диагностика одного дня

Недавно я получил очередное письмо от начальника отдела автоматизации производства, что из-за ERP ночью «зависли» весы, отгрузка была приостановлена на полчаса, мы не устраняем проблему на стороне 1С, а сотрудникам КИПиА приходится ходить на участок автоотгрузки и «перезагружать» весы. В письме он сослался на то, что «зависания» начались с 2020 года, когда нами была выполнена интеграция весов с ERP.

Мне было лень переписываться и я решил досконально разобраться в проблеме:

• От консультанта 1С я узнал, что в момент «зависания» весов у насыпщика на экране выводится сообщение «Нет связи с сервером».
• От программиста 1С я узнал, ч то в момент «зависания» в базе данных MSSQL весов (подключена к ERP, как внешний источник данных) появляется запись с отрицательным значением взвешивания порожней машины. А после «перезагрузки» весов создается новая запись с корректным весов и отгрузка продолжается в обычном режиме.

• Чтобы исключить возможные ошибки в данных на стороне 1C ERP, я проверил записи в базе данных MSSQL — при «зависании» весов появляется запись с отрицательным значением, а после «перезагрузки» создается новая запись с корректным весом.

• Чтобы убедиться, что запись с отрицательным значением веса при «зависании» весов это не случайность, я проверил наличие подобных занисей в базе данных MSSQL, оказалось, что они были и раньше. Вероятно, в это время также «зависали» весы.

• Дальнейший анализ восстановленной из архива базы данных MSSQL показал, что проблема возникает в самого начала эксплуатации весов — с 2015 года.

• От программиста 1С я получил описание логики интеграции весов с ERP и фрагмент кода (каждые 5 секунд он получает текущее значение веса и отображает в его интерфейсе 1C на рабочем месте автодиспетчера). Маловероятно, что это может быть причиной «зависания» весов. Учитывая, что процедура выполняется каждые 5 секунд, а весы «зависают» всего пару раз в месяц.

Фрагмент кода 1С для получения текущего веса

Процедура вызывается 1 раз в 5 секунд и выполняется команда на javascript для получения значения текущего веса, которое отображается в рабочем месте автодиспетчера в ERP.

До интеграции весов Mettler Toledo с 1C, текущее значение веса выводилось на монитор автодиспетчеру через открытую страницу браузера.

• От системного администратора я узнал, что в помещении насыпщика нет компьютера, а значит, есть какой-то неопознанный экран куда выводится сообщение «Нет связи с сервером».

В телефоне я нашел фотографию экрана монитора автодиспетчера, когда данные с весов выводились через веб-интерфейс на странице в браузера. Эта фотография была сделана во время обследования процесса работы автодиспетчера, еще до начала интеграции весов с ERP.

После диагностики я написал письмо начальнику отдела автоматизации производства о результатах (отсутствие проблем на стороне 1С или интеграции весов с ERP) и попросил проверить кабели, датчики и подключения. На что в ответном письме получил смайлик, который означал, что я написал глупости.

И краткий комментарий, что «Mettler Toledo это промышленные весы, очень надежные, а проблему надо искать на стороне 1С».

Неопознанный экран у насыпщика, отсутствие проблем на стороне 1С и поход в гемба

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

Удивительные фотографии из гемба

Это может показаться банальным, но факт остается фактом. Вот такую картину я увидел, когда системный администратор прислал мне фотографии в вайбер из помещения насыпщика.

Что такое «гемба» (определение из Википедии)

Гэмба (яп. 現場 гэмба), гэнти гэмбуцу (яп. 現地現物, «наличный товар на местах») — обозначения подхода, характерного для японской управленческой практики кайдзен, согласно которому для полноценного понимания ситуации считается необходимым прийти на гэмба — место выполнения рабочего процесса, собрать факты и непосредственно на месте принять решение. В русскоязычной литературе обычно используются написания «гемба» и «генти генбуцу».

Меня заинтересовала стоимость этих интерфейсов и я нашел спецификацию на приобретение — 2800 евро за 1 настольный терминал.

Стало понятно, что проблема «зависания» терминалов Mettler Toledo может быть связана проводами, которые держались на соплях и изоленте.

Чтобы подтвердить это предположение, на следующий день утром мы смоделировали ситуацию: машина заехала на весы, а системный администратор пошевелил провода. На экране появилось сообщение «Нет связи с сервером», а весы сразу «зависли».

Я попросил системного администратора вызвать дежурного сотрудника КИПиА и посмотреть, что именно тот делает для «перезагрузки» весы. Все оказалось намного банальнее, чем я представлял.

Примерно через 30 минут на весовую пришел сотрудник КИПиА, посмотрел на экран весов. Определил кабель, который идет от экрана к бесперебойнику. Подошел к бесперебойнику, вытащил кабель питания и вставил его обратно. «Перезагрузка» весов выполнена, и он ушел. Вот такую важную задачу годами выполнял «киповец».

Так какие у вас возникают ассоциации, когда слышите фразу «при зависании весов сотрудник КИПиА идет на участок автоотгрузки и перезагружает весовой терминал»?

На следующий день с директором завода была согласована остановка автоотгрузки на несколько часов для приведения в порядок проводов и подключений на весовой. Заодно в помещении у насыпщика начался косметический ремонт.

Еще пара фоток терминалов в процессе взвешивания

Проблема 2015 года с периодическим «зависанием» автомобильных весов Mettler Toledo решилась за 2 дня.

Мораль сей басни такова

Когда вы слышите проблему — словам не верьте, господа. Идите в гемба и смотрите, что происходит на местах.

Спасибо, что дочитали до конца!

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

• траблшутинг
• решение проблемы
• гемба
• промышленное оборудование
• кипиа
• пофигизм

Источник: habr.com

Troubleshooting часть 1

Troubleshooting часть 1 — углубляемся в ping и traceroute, разбираем малоизвестные факты об этих популярных инструментах траблшутинга.

Всем знакомые ping и traceroute . Все их используют и не особо обращают внимание. А что там знать? Ведь команды эти крайне простые. Всё ли так просто на самом деле? Проверь себя.

Рассказ как всегда в контексте устройств CISCO.

Для начала неплохо будет ознакомиться с базовыми концепциями траблшутинга из курса CCNA. Вот эта запись и там Урок 9.

Traceroute

Сначала traceroute , здесь поинтереснее. Самое первое тут: traceroute может использовать разные протоколы передачи данных и конкретно в CISCO это не ICMP. Да, вот в CISCO так. Здесь UDP, поэтому в настройках расширенного traceroute есть пункт выбора порта. Порт по умолчанию 33434, его можно поменять.

Тем не менее traceroute всё равно задействует ICMP в своей работе. И механизм этой работы такой: пакеты с UDP начинкой отправляются с различным TTL (от 1 до 30). Для первого пакета TTL равен единице, для второго двум и так далее.

На каждом хопе TTL уменьшается на 1 и когда он обнуляется, то устройство где это произошло, отправляет ICMP собщение отправителю о данном событии ( ICMP Time Exceeded Message, TEM ). Из этого сообщения извлекается информация (IP адрес отправителя) и выводится на экран. Каждый следующий пакет уходит на один хоп дальше. Когда наконец пакет достигает хоста назначения, то оказывается что нет приложения прослушивающего UDP порт, указанный в пакете, и хост отправляет об этом сообщение ( ICMP Port Unreachable Message ). Всё, трассировка завершена.

Пример

Прямо с домашнего компа, у меня Windows, запустим трассировку на адрес 2.2.2.2 и смотрим в Wireshark. Как не трудно увидеть, начнётся пинг адреса 2.2.2.2, с последовательным увеличением TTL в заголовке IP. Не буду выкладывать картинку, ты сам можешь всё это самостоятельно проверить за пару минут. То есть тут именно ICMP. Как трассировка выглядит на устройстве CISCO, будет далее.

Вывод команды traceroute

Теперь подробнее, обращаю внимание что для ping и traceroute есть одинаковые инфомационные сообщения в выводе, только с разным значением. Разберём и вот эти непонятки проясним.

CharacterDescription

U	Port unreachable
H	Host unreachable
N	Network unreachable
P	Protocol Unreachable
T	Timeout
?	Unknown packet type
XX msec	For each node, the round-trip time in milliseconds for the specified number of probes
*	The probe timed out
A	Administratively prohibited (example access-list)
Q	Source quench (destination too busy)
I	User interrupted test

Расшифровка вывода traceroute

Запомним первые два: «крышечка» U недоступен порт, H недоступен хост.

Параметры команды traceroute

R1# traceroute 192.168.3.1 ? dscp Specify DSCP value in ASCII/Numeric ingress LAN source interface for Ingress numeric display numeric address port specify port number probe specify number of probes per hop source specify source address or name timeout specify time out ttl specify minimum and maximum ttl

Тут зависит от модели устройства и IOS, может быть и вот так:

D1# traceroute 192.168.3.1 ?

R1# traceroute 192.168.3.1 ? numeric display numeric address port specify port number probe specify number of probes per hop source specify source address or name timeout specify time out ttl specify minimum and maximum ttl

Описание основных параметров:

• numeric — Displays output only in numeric form instead of trying to resolve by DNS as well;
• port — Allows you to set a different starting port number, which defaults to 33433;
• probe — Allows you to change the default 3 probes per hop;
• source — Allows you to specify a different source address for the probe;
• timeout — Allows you to specify a timeout other than the default of 3 seconds;
• ttl — Allows you to specify a minimum and maximum ttl other than the default 1 and 30

Пример

Расширенная трассировка, адрес 192.168.3.1 находится в двух хопах от нашего роутера R1:

R1# traceroute Protocol [ip]: Target IP address: 192.168.3.1 Ingress traceroute [n]: Source address or interface: Loopback0 DSCP Value [0]: Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 192.168.3.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.10.2.2 1 msec 1 msec 1 msec 2 10.20.3.3 1 msec * 1 msec

Какие здесь моменты?

В пункте Source address or interface имя интерфейса нельзя сокращать. Команда traceroute вываливает все свои параметры, не спрашивая нас (для пинга по-другому). Loose, Strict, Record, Timestamp, Verbose рассмотрим в разделе про пинг. Для второй пробы к 10.20.3.3 превышено время ожидания ответа (*).

Debug команды traceroute

Включим дебаг и будем ещё смотреть с помощью Wireshark:

R1# debug ip icmp ICMP packet debugging is on R1# traceroute 192.168.3.1 Type escape sequence to abort. Tracing the route to 192.168.3.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.2.2 0 msec 1 msec 0 msec 2 10.2.3.3 1 msec *Jul 26 10:35:21.592: ICMP: time exceeded rcvd from 10.1.2.2 *Jul 26 10:35:21.593: ICMP: time exceeded rcvd from 10.1.2.2 *Jul 26 10:35:21.593: ICMP: time exceeded rcvd from 10.1.2.2 *Jul 26 10:35:21.594: ICMP: dst (10.1.2.1) port unreachable rcv from 10.2.3.3 * 1 msec R1# *Jul 26 10:43:03.744: ICMP: dst (10.1.2.1) port unreachable rcv from 10.2.3.3

Посмотрим пакет в Wireshark, очистим вывод с помощью фильтра:

! ospf ! cdp ! loop ! icmpv6

И теперь смотрим:

Что мы здесь видим? Было отправлено 6 пакетов, это имено пакеты UDP, в IP заголовке номер протокола 17. Пакеты высылались на порт 33434 для первого пакета и +1 для каждого следующего. Поэтому для шестого 33439. В ответ получено 5 ICMP ответов, 3 Time exceeded , 2 Port unreachable . Все эти ответы видны в дебаге роутера.

Ping

Служит для проверки доступности узла сети. С успешным пингом всё понятно — узел доступен. С неуспешным сложнее, как правило этого недостаточно чтобы сделать какой-то вывод. Требуются дополнительные инструменты и нужно выяснить что там с устройством случилось. Или ничего не случилось.

Допустим, узел находится где-то в интернете и администратор закрыл ICMP запросы из интернета. Устройство нормально работает, при этом пропинговать его невозможно.

Внутри локальной сети попроще. Если известно что узел должен пинговаться и вот он не пингуется, значит что-то не в порядке. Опять же нужны дополнительные инструменты. Топ 3 причин неудачного пинга: нет элетричества или сбой ИБП/БП устройства, «добрый самаритянин» выдернул провода (сетевые или электрические) или повредили кабель при ремонтных работах (экскаватор перебил оптику), устройство ушло в ребут (в циклический ребут) или вообще вышло из строя.

Вывод команды ping

Ходовой вопрос на собеседованиях: для пинга какой порт используется? Никакой. Почему? Чтобы был порт, должен быть заголовок транспортного уровня (TCP/UDP). Для ICMP такого заголовка просто нет в пакете, ICMP цепляется непосредственно к IP заголовку. При этом в IP заголовке номер протокола 1. Самые ходовые протоколы, на собеседовании бывает спрашивают:

1 — ICMP 2 — IGMP 6 — TCP 17 — UDP 50 — ESP 51 — AH

Список номеров всех протоколов тут. Ну вот, надеюсь что-то полезное рассказал. Не стал специально переводить описание к параметрам, так как лучше прочитать в оригинале, чем мой неточный перевод. Кому сложно в оригинале, переводчик в помощь.

А вообще пора учить английский.

Сетевые инструменты

Пару слов про полезные утилиты. Как уже сказал, пинг не является достаточным инструментом проверки доступности.

Paping

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

• Как выяснить где проблема: в самом приложении, его настройках, сертификатах или именно в сетевой доступности удалённого хоста?
• Как проверить отсутствие блокировок со стороны FWs по пути следования пакета?

Здесь на помощь приходит утилита paping . Её создателю нужно вручить медаль сетевого администрирования. Синтаксис прост:

paping.exe ip_хоста -p порт

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

Кроме paping можно использовать клиент telnet , для него страдает наглядность работы и генерируется малое число пакетов. Ещё для Windows команды powershell :

Test-NetConnection ip_хоста -Port порт tnc ip_хоста -port порт

Наглядность работы лучше, чем у telnet , но пакетов генерится так же мало. Конечно на FW в логе ты ставишь фильтры и видишь пакеты даже когда их мало, но удобно работать с логом, если пакетов проходит много. В общем, paping на мой взгляд the best choice.

А что с Linux? Здесь опять же telnet :

# yum install telnet # telnet ip_хоста порт
# yum install nc # nc -z -v ip_хоста порт

MTR/WinMTR

Вторая мега-полезная утилита. Для Windows WinMTR , а для Linux MTR . Позволяет определить на каком именно хопе происходят потери пакета, на каком хопе большая задержка передачи.

Она предельно простая, но интерпретировать результаты нужно правильно.

Вот интересная ситуация:

Есть тут потери пакетов? Нет, нету. Почему? Потому что на последний хоп отправлено 147 пакетов и получено от него 147. Хопы со 100% потерей понятная ситуация: сами маршрутизаторы закрыты для ответов по ICMP, но транзитный ICMP трафик пропускается при этом нормально.

Интереснее хопы 4 и 5. Что это? На них установлена политика предельного рейта для отдельных видов трафика, предназначенных самому маршрутизатору. Транзитный трафик опять же не режется. Подробнее тут.

Что тогда является признаком потерь? Когда потери начинаются с определённого хопа и для оставшихся хопов они такие же или растут. Кроме этого необходимо смотреть на задержки Avrg (средняя) и Worst (наибольшая). Если они большие, могут достигать 3000 ms (3 sec), то дело плохо. Даже при отсутствии потерь в этом случае нормальной работы не будет.

Какие сетевые задержки считаются нормой? По мнению CISCO не более 150 ms.

Диапазон в миллисекундахОписание

0-150	Приемлемо для большинства пользовательских приложений.
150-400	Допустимо при условии, что администраторы осведомлены о времени передачи и его влиянии на качество передачи в пользовательских приложениях.
Более 400	Неприемлемо для общих целей планирования сетей. Однако признается, что в некоторых исключительных случаях этот предел может превышаться.

Кроме этого (взято тут, если доступ остался):

Эти рекомендации адресованы национальным органам управления связью. Поэтому они накладывают более строгие ограничения, чем те, которые обычно применяются в частных сетях передачи речи. Когда местоположение и коммерческие потребности конечных пользователей хорошо известны проектировщику сети, более высокое значение задержки может оказаться приемлемым. Для частных сетей задержка 200 мс является приемлемой задержкой, а задержка в 250 мс представляет предельное значение.

На сегодня всё, успехов в траблшутинге!

Источник: arny.ru