Данная статья специально для тех, кто понимает, что такое IP-адрес, DNS и основной шлюз сети, а также знаком с терминами провайдер, сетевая карта и т.д. Обзор этих терминов, возможно, будет опубликован отдельно.
Поскольку статья написана для большой аудитории от простого пользователя Windows до начинающего администратора UNIX или пользователя MacOS, я решил выделить 2 части. В первой части статьи я расскажу о методах обнаружения и устранения сетевых ошибок средствами операционной системы Windows, во второй части – средствами UNIX-подобных ОС, таких, как Linux, FreeBSD, MacOS. И так, у Вас не работает Интернет, в отличии от Ваших коллег, соседей, жены, которые работают через один и тот же роутер/сервер и т.д. Что делать?
Диагностика и устранение ошибок сети штатными средствами ОС Windows
Для начала нам потребуется рабочий инструмент. Повторюсь, никаких сторонних программ устанавливать мы не будем, используем только то, что есть в составе ОС. Итак, запускаем Командную строку. Для тех, кто не знает, это черное окошко с белыми буковками. Находится она в меню Пуск->Все программы->Стандартные-> Командная строка. Быстро вызвать ее также можно через поиск в Windows7/Windows8 по фразе cmd или Пуск->Выполнить->cmd в WindowsXP.
Мигающий курсор говорит нам о том, что программа готова к вводу команд. Все эти команды мы будем вбивать не обращая внимания на то, что написано до этого курсора.
Шаг 1: проверяем состояние оборудования, наличия подключения(кабеля)
За все это отвечает команда ipconfig. Набираем ipconfig /all и нажимаем Enter. Таким же образом мы будем набирать и остальные команды. Обращаю внимание, что сама команда ipconfig запускается с параметром all, который обязательно отделяется пробелом и знаком косой черты /. Отреагировав на команду ipconfig, система нам вывела несколько экранов информации, в которые нам предстоит вникнуть, чтобы правильно диагностировать и устранить проблему сети.
Как видно на скриншоте, для каждого сетевого адаптера система вернула настройки. Если у Вас выведена только фраза Настройка протокола IP для Windows , значит в системе вообще не обнаружены сетевые адаптеры: здесь возможны варианты выхода из строя оборудования, отсутствия драйверов или аппаратное выключение, например кнопка на ноутбуке, которая выключает беспроводные сети.
Поскольку у меня ноутбук, были обнаружено несколько доступных сетевых адаптеров. Особо я выделю
Если у Вас, как, например, в моем случае, применимо к выделенной проводной сети в строке Состояние среды значится фраза Среда передачи недоступна значит налицо неподключенный или испорченный кабель/розетка/порт коммутатора и т.п. В случае наличия физического подключения, как например у меня в Wi-Fi сети, будут выведены основные настройки (мы рассмотрим только некоторые из них):
- Описание : здесь, как правило, указывается сетевой адаптер, определенный системой (виртуальные адаптеры, типа Microsoft Virtual и т.п. не имеет смысла рассматривать вообще, нам нужны только физические);
- DHCP включен : важный параметр, который указывает, как был получен адрес: автоматически через DHCP(будет значение Да ) или установлен вручную(будет значение Нет );
- IPv4-адрес : IP-адрес в TCP/IP сети – один из трех самых важных параметров, который понадобится нам в дальнейшем;
- Маска подсети : Еще один важный параметр;
- Основной шлюз : 3-й важный параметр – адрес маршрутизатора/шлюза провайдера, как правило совпадает с DHCP-сервером, если настройки получены автоматически;
- DNS-серверы : адреса серверов, которые преобразуют имена хостов в IP-адреса.
Шаг2: проверяем правильность IP-адреса
В случае, если у Вас настройки получаются автоматически (опция DHCP включен - Да), но не заполнен параметр Основной шлюз и DNS-серверы , служба DHCP не работает на роутере или сервере. В этом случае нужно убедиться, что роутер включен (возможно попробовать его перезагрузить), в случае сервера, что служба DHCP работает и назначает адреса.
После перезагрузки роутера, необходимо, обновить настройки. Для этого можно перезагрузить компьютер или просто выполнить 2 команды:
- ipconfig /release – для сброса всех автоматических настроек
- ipconfig /renew – чтобы получить автоматические настройки
В результате обеих команд мы получим вывод, аналогичный выводу команде ipconfig /all. Наша задача добиться того, чтобы были заполнены IPv4-адрес, Маска подсети, Основной шлюз, DNS-серверы. Если настройки назначаются вручную – проверяем, чтобы были заполнены IPv4-адрес, Маска подсети, Основной шлюз, DNS-серверы. В случае домашнего интернета эти настройки могут быть указаны в договоре с провайдером.
Шаг 3: проверяем доступность своего оборудования и оборудования провайдера
После того, как все настройки получены, необходимо проверить работоспособность оборудования. К слову сказать, вся сеть представляет собой цепочку шлюзов. Первый из них и есть тот Основной шлюз , который выдала нам команда ipconfig, следующий – шлюз, являющийся основным для провайдера и так далее до достижения нужного узла в сети Интернет.
И так, для проверки сетевых устройств в Windows служит команда ping и для того, чтобы правильно диагностировать проблему в работе сети необходимо выполнить пинг для следующих адресов в последовательности:
- Свой компьютер (IPv4-адрес). Наличие отклика свидетельствует о работоспособности сетевой карты;
- Роутер или сервер, выполняющий роль Интернет-шлюза (Основной шлюз). Наличие отклика свидетельствует о правильной настройки компьютера для работы в локальной сети и доступности шлюза, отсутствие отклика свидетельствует либо о неверных настройках, либо о неработающем роутере/сервере.
- Ваш IP у провайдера (обычно указан в договоре с провайдером – настройки, IP-адрес). Наличие отклика свидетельствует о правильной настройки Вашего компьютера, роутера/сервера, отсутствие отклика – либо о неверной настройки роутера, либо о недоступном шлюзе провайдера/ неполадках на стороне провайдера.
- DNS (DNS-серверы). Наличие отклика свидетельствует о корректной работе сетевого протокола – если в этом случае не работает Интернет, скорее всего дело в самой операционной системе, вирусном заражении, программных блокировках, как со стороны провайдера, так и самого компьютера/шлюза.
- IP-адрес любого рабочего хоста в сети, например я использую DNS-сервер Google – 8.8.8.8. Отклик свидетельствует о правильной работе сетевого оборудования как с Вашей стороны, так и со стороны провайдера. Отсутствие отклика свидетельствует об ошибках, которые дополнительно диагностируются трассировкой.
- URL любого сайта, например yandex.ru. Отсутствие отклика может свидетельствовать о неработающей службе распознавания адресов, если не удалось преобразовать url в IP-адрес. Это проблема скорее всего службы DNS-клиент, которая отключена в Windows на Вашем ПК, либо работает не правильно.
Для рассматриваемого примера будут выполнены следующие команды.
При положительном тесте будет выведено количество отправленных и полученных пакетов, а также время прохождения пакета до узла сети.
Характерные ошибки выглядят подобным образом.
Шаг 4: Тестирование трассировкой
Также общую картину можно получить, если воспользоваться трассировкой. Суть теста в том, что пакет проходит по всем шлюзам от тестируемого компьютера до узла сети. В качестве узла сети может быть шлюз провайдера, какой-либо сервер или просто url сайта.
Для запуска необходимо применить команду tracert. В примере, я буду тестировать сайт yandex.ru:
На первом шаге хост преобразуется в IP-адрес, что свидетельствует о правильной работе DNS-служб и верной настройке сети. Далее по порядку пакет проходит по всем шлюзам сети до назначения:
- 1-Основной шлюз
- 2,3-Шлюзы провайдера (может быть 1 или несколько)
- 4,6-Промежуточный шлюзы
- 5-Один из шлюзов не доступен
- 7-Нужный нам сайт yandex.ru
Диагностика неисправности сети в этом тесте помогает определить на каком именно узле имеется неисправность. Так, например, если пакет не уходит дальше 1-й строки (Основной шлюз), значит существует проблема с роутером или ограничения на стороне провайдера. 2-я строка – проблема на стороне провайдера и т.д.
Шаг 5: Тестирование отдельных протоколов
При успешном прохождении всех вышеперечисленных тестов можно утверждать о правильной настройке сети и работе провайдера. Однако и в этом случае могут некорректно работать некоторые клиентские программы, например электронная почта или браузер.
Связано это может быть как с проблемами на самом компьютере (например, вирусное заражение или неправильные настройки программы или вовсе ее неработоспособность), так и с ограничительными мерами, применяемыми провайдером (блокирование 25-го порта для отправки почты).
Для диагностики этих проблем применяется программа telnet. По умолчанию в ОС Windows 7 и выше, данный компонент не установлен. Для установки необходимо перейти в Пуск-Панель-Управления->Программы(Программы и компоненты, Установка и удаление программ в зависимости от версии ОС), перейти в Включение и отключение компонентов Windows (для этого требуются права администратора) и установив галочку напротив Клиент Telnet нажать OK.
Теперь мы можем приступать к тестированию сетевых портов. Для примера, проверим работоспособность почтового протокола.
У меня есть корпоративный почтовый ящик, который располагается на хостинге RU-CENTER. Адрес сервера: mail.nic.ru, сообщения перестали поступать по протоколу POP3, стало быть порт 110 (адрес сервера и номер порта я взял из настроек Outlook). Таким образом для того, чтобы проверить, имеет ли мой компьютер доступ к серверу mail.nic.ru по порту 110 в командной строке я запишу:
telnet mail.nic.ru 110
Далее сервер выдал мне статус моего обращения +ОК , что свидетельствует о корректной работе как сети в целом, так и почтовой службы в частности и в неработающей почте скорее всего виноват почтовый клиент.
Убедившись в этом, я набираю команду quit, на что сервер снова ответил мне +ОК и тем самым завершил сеанс работы команды telnet.
Таким образом, с помощью штатных средств операционной системы Windows мы можем диагностировать и устранить проблему сети. В следующей части статьи, я расскажу о штатных средствах диагностики в UNIX-подобных ОС, таких, как Linux, FreeBSD и MacOS.
Основных причин неудовлетворительной работы сети может быть несколько: повреждения кабельной системы, дефекты активного оборудования, перегруженность сетевых ресурсов (канала связи и сервера), ошибки самого прикладного ПО. Часто одни дефекты сети маскируют другие. И чтобы достоверно определить, в чем причина неудовлетворительной работы, локальную сеть требуется подвергнуть комплексной диагностике. Комплексная диагностика предполагает выполнение следующих работ (этапов).
Выявление дефектов физического уровня сети: кабельной системы, системы электропитания активного оборудования; наличия шума от внешних источников.
Измерение текущей загруженности канала связи сети и определение влияния величины загрузки канала связи на время реакции прикладного ПО.
Измерение числа коллизий в сети и выяснение причин их возникновения.
Измерение числа ошибок передачи данных на уровне канала связи и выяснение причин их возникновения.
Выявление дефектов архитектуры сети.
Измерение текущей загруженности сервера и определение влияния степени его загрузки на время реакции прикладного ПО.
Выявление дефектов прикладного ПО, следствием которых является неэффективное использование пропускной способности сервера и сети.
Мы остановимся подробнее на первых четырех этапах комплексной диагностики локальной сети, а именно на диагностике канального уровня сети, так как наиболее легко задача диагностики решается для кабельной системы. Как уже было рассмотрено во втором разделе, кабельная система сети полноценно может быть протестирована только специальными приборами - кабельным сканером или тестером. AUTOTEST на кабельном сканере позволит выполнить полный комплекс тестов на соответствие кабельной системы сети выбранному стандарту. При тестировании кабельной системы хотелось бы обратить внимание на два момента, тем более что о них часто забывают.
Режим AUTOTEST не позволяет проверить уровень шума создаваемого внешним источником в кабеле. Это может быть шум от люминесцентной лампы, силовой электропроводки, сотового телефона, мощного копировального аппарата и др. Для определения уровня шума кабельные сканеры имеют, как правило, специальную функцию. Поскольку кабельная система сети полностью проверяется только на этапе ее инсталляции, а шум в кабеле может возникать непредсказуемо, нет полной гарантии того, что шум проявится именно в период полномасштабной проверки сети на этапе ее инсталляции.
При проверке сети кабельным сканером вместо активного оборудования к кабелю подключаются с одного конца - сканер, с другого - инжектор. После проверки кабеля сканер и инжектор отключаются, и подключается активное оборудование: сетевые платы, концентраторы, коммутаторы. При этом нет полной гарантии того, что контакт между активным оборудованием и кабелем будет столь же хорош, как между оборудованием сканера и кабелем. Неоднократно встречаются случаи, когда незначительный дефект вилки RJ-45 не проявляется при тестировании кабельной системы сканером, но обнаруживался при диагностике сети анализатором протоколов.
Диагностика сетевых устройств (или компонента сети) также имеет свои тонкости. При ее проведении применяют различные подходы. Выбор конкретного подхода зависит от того, что выбирается в качестве критерия хорошей работы устройства. Как правило, можно выделить три типа критериев и, следовательно, три основных подхода.
Первый основан на контроле текущих значений параметров, характеризующих работу диагностируемого устройства. Критериями хорошей работы устройства в этом случае являются рекомендации его производителя, или так называемые промышленные стандарты де-факто. Основными достоинствами указанного подхода являются простота и удобство при решении наиболее распространенных, но, как правило, относительно несложных проблем. Однако бывают случаи, когда даже явный дефект большую часть времени не проявляется, а дает о себе знать лишь при некоторых, относительно редких режимах работы и в непредсказуемые моменты времени. Обнаружить такие дефекты, контролируя только текущие значения параметров, весьма затруднительно.
Второй подход основан на исследовании базовых линий параметров (так называемых трендов), характеризующих работу диагностируемого устройства. Основной принцип второго подхода можно сформулировать следующим образом: “устройство работает хорошо, если оно работает так, как всегда”. На этом принципе основана упреждающая (proactive) диагностика сети, цель которой -- предотвратить наступление ее критических состояний. Противоположной упреждающей является реактивная (reactive) диагностика, цель которой не предотвратить, а локализовать и ликвидировать дефект. В отличие от первого, данный подход позволяет обнаруживать дефекты, проявляющиеся не постоянно, а время от времени. Недостатком второго подхода является предположение, что изначально сеть работала хорошо. Но “как всегда” и “хорошо” не всегда означают одно и то же.
Третий подход осуществляется посредством контроля интегральных показателей качества функционирования диагностируемого устройства (далее -- интегральный подход). Следует подчеркнуть, что с точки зрения методологии диагностики сети между первыми двумя подходами, которые будем называть традиционными, и третьим, интегральным, есть принципиальное различие. При традиционных подходах мы наблюдаем за отдельными характеристиками работы сети и, чтобы увидеть ее “целиком”, должны синтезировать результаты отдельных наблюдений. Однако мы не можем быть уверены, что при этом синтезе не потеряем важную информацию. Интегральный подход, наоборот, дает нам общую картину, которая в ряде случаев бывает недостаточно детальной. Задача интерпретации результатов при интегральном подходе, по существу, обратная: наблюдая целое, выявить, где, в каких частностях заключается проблема.
Из сказанного следует, что наиболее эффективен подход, совмещающий функциональность всех трех описанных выше подходов. Он должен, с одной стороны, основываться на интегральных показателях качества работы сети, но, с другой -- дополняться и конкретизироваться данными, которые получаются при традиционных подходах. Именно такая комбинация позволяет поставить точный диагноз проблемы в сети.
Перед тем как писать "у меня ни чего не работает", постарайтесь выяснить, что конкретно у вас не работает.
В случае если вы решили оставить сообщение на форуме/вконтакте, учтите, что сообщение не считается официальным обращением в службу технической поддержки, контакты службы ТП находятся на главной странице сайта.
Пожалуйста, прочитайте перед написанием хотя бы несколько сообщений темы на последней странице - возможно, что проблема эта уже решена или её уже решают!
Диагностические команды:
*Выполняются в предварительно открытом окне "командной строки". (Пуск -> Все программы -> Стандартные -> Командная строка)
Для Windows Vista/7: Win+R ===> cmd ===> Enter
Для Windows NT/2000/XP/VISTA: "Пуск" - "Выполнить" - "cmd"
Для Windows 95/98: "Пуск" - "Выполнить" - "command".
Копирование текста: правой кнопкой на этом окне - "правка" - "выделить" и "правка" - "копировать".
ipconfig /all
nslookup
ping [адрес хоста(например, ya.ru) ] [-n 20]
pathping [адрес хоста]
tracert [адрес хоста]
ipconfig /all показывает настройки сетевых интерфейсов.
Всё, что там указано, необходимо сверить с памяткой пользователя (если памятка старая, то сверить с теми данными, которые были выданы технической поддержкой). Как настраиваеться подключение смотрите на сайте
ping [-t] показывает время ответа от указаного хоста. Большие задержки косвенно могут служить индикатором медленного ресурса (загруженого канала, слабого железа ресурса и тому подобных проблем). Ключ [-t] служит для выполнения команды до того, как пользователь не прервёт её нажатием "Ctrl+C". По умолчанию, без этого ключа, ping выполнится только четыре раза, чего не всегда достаточно.
pathping Показывает время ответа и количество пропавших пакетов на всём протяжении маршрута до хоста.
tracert
Для графического отображения проблем можно скачать из локальной сети программу PingPlotter
nslookup
Проверить работу DNS.
Алгоритм проверки: Ошибка "Сетевой кабель не подключен"
1. Проверить подключение кабеля в сетевой карте
2. Проверить целостность кабель до щитка.
3. Позвонить в Тех. поддержку.
Сетевой кабель подключен, но входящих пакетов нет.
1. Проверить подключение кабеля в сетевой карте (можно вынуть и вставить кабель в гнездо).
2. Отключить все брандмауэры (файерволы), если они у вас есть.
3. Пропинговать шлюз (адрес взять из настроек соединения или из сведений о соединении в панели управления).
4. Позвонить в Тех. поддержку.
Сетевой кабель подключен, входящие пакеты есть, но не зайти на внтуренние сервисы:
1. Отключить все брандмауэры (файерволы), если они у вас есть.
2. Проверить работу DNS (nslookup ).
3. Проверить связь с этими серверами (ping )
4. Проверить связь с центральными серверами. (ping online.vo, ping 192.168.0.250, ping адрес_вашего_шлюза)
5. Проверить настройки браузера
5.1. Internet Explorer -> меню "Сервис" -> "Свойства Обозревателя" -> "Соединение" -> "Настройка Сети" -> проверить, отключена ли галка "использовать прокси-сервер"
6. Позвонить в Тех. поддержку.
Проверка DNS:
Команда nslookup cервер должна вернуть ip-адрес этого сервера. Например, команда "nslookup vo47.ru" должен вернуть адрес "193.106.108.68"
Команды диагностики
| Команда | Назначение | Формат запуска | Пример |
|---|---|---|---|
| ipconfig | Показывает настройки сетевых интерфейсов | ipconfig /all | |
| netstat | Показывает таблицу маршрутов | netstat -nr | |
| nslookup | Обращается к DNS-серверу (если не указывать, то берётся из настроек Windows) для преобразования DNS-имени компьютера в его IP-адрес или наоборот | nslookup DNS-имя_или_IP-адрес IP-адрес_DNS-сервера | nslookup vo47.ru nslookup ya.ru 193.106.108.67 |
| ping | Проверяет наличие связи с другим компьютером и быстроту ответа. Не является средством для измерения скорости соединения.
|
ping DNS-имя_или_IP-адрес | ping www.vo47.ru ping 193.106.108.97 |
| tracert | То же, что и ping, но с выводом информации для всех промежуточных узлов | tracert -d DNS-имя_или_IP-адрес | tracert -d cs47.ru |
| pathping | То же, что и tracert, но в более подробном виде и с указанием процента потерь | pathping DNS-имя_или_IP-адрес | pathping vk.com |
Сети на базе TCP/IP содержат большое количество удобных утилит и команд, позволяющих наблюдать за статусом сети и диагностировать возникающие проблемы (табл. 7.1).
Утилита pingявляется одним из основных диагностических средств в сетях TCP/IP и входит в поставку всех современных сетевых операционных систем. Функциональность ping также реализована в некоторых встроенных ОС маршрутизаторов, доступ к результатам выполнения ping для таких устройств по протоколу SNMP определяется RFC 2925 (Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations).
Так как программа использует ICMP и создает raw-пакеты, для ее выполнения в unix-системах необходимы права суперпользователя. Чтобы обычные пользователи могли использовать ping, на /bin/ping ставят SUID бит в права доступа (chmod4755 /bin/pingи попросить выполнить эту команду администратора). Пример запуска утилиты ping:
Пример. Запуск ping.
%ping -c 3 fpm2.ami.nstu.ru
PING fpm2.ami.nstu.ru (217.71.130.131): 56 data bytes
64 bytes from 217.71.130.131: icmp_seq=0 ttl=57 time=5.458 ms
64 bytes from 217.71.130.131: icmp_seq=1 ttl=57 time=3.088 ms
64 bytes from 217.71.130.131: icmp_seq=2 ttl=57 time=1.927 ms
Fpm2.ami.nstu.ru ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.927/3.491/5.458/1.469 ms
Таблица 7.1
|
Утилита (команда) |
Назначение |
Примеры использования |
|
|
Используется для отправки ЭХО-запросов на указанный узел сети. Простое, но незаменимое средство диагностики сети |
ping -c 7 saturn |
||
|
Используется для определения маршрута следования пакетов от вашего хоста до указанного хоста |
traceroute -I fpm2.ami.nstu.ru |
||
|
Конфигурирует или отображает параметры сетевых интерфейсов хоста (для протоколов стека TCP/IP) | |||
|
Выводит информацию о сетевых соединениях, статистику по сетевым интерфейсам и т. п. | |||
|
Отображает или модифицирует таблицу протокола ARP (преобразование IP в MAC-адреса) | |||
|
Выводит различную информа-цию о системе | |||
|
То же, что и ifconfig, но для Windows XP | |||
|
То же, что и traceroute, но для Windows XP |
tracert tom.interface.nsk.su |
||
Утилита tracerouteпредназначена для определения маршрутов следования данных в сетях TCP/IP. Она выполняет отправку данных указанному узлу сети, при этом отображая сведения о всех промежуточных маршрутизаторах, через которые прошли данные на пути к целевому узлу. В случае проблем при доставке данных до какого-либо узла программа позволяет определить, на каком именно участке сети возникли неполадки.
tracerouteвходит в поставку большинства современных сетевых операционных систем. В системах Microsoft Windows эта программа носит названиеtracert , а в системах GNU/Linux –traceroute .
Для определения промежуточных маршрутизаторов tracerouteотправляет серию пакетов целевому узлу, при этом каждый раз увеличивая на 1 значение поля TTL («время жизни»). Это поле обычно указывает максимальное количество маршрутизаторов, которое может быть пройдено пакетом. Первый пакет отправляется с TTL, равным 1, и поэтому первый же маршрутизатор возвращает обратно сообщение ICMP, указывающее на невозможность доставки данных.Tracerouteфиксирует адрес маршрутизатора, а также время между отправкой пакета и получением ответа (эти сведения выводятся на монитор компьютера). Затемtracerouteповторяет отправку пакета, но уже с TTL, равным 2, что позволяет первому маршрутизатору пропустить пакет дальше.
Процесс повторяется до тех пор, пока при определенном значении TTL пакет не достигнет целевого узла. При получении ответа от этого узла процесс трассировки считается завершенным.
На оконечном хосте IP-дейтаграмма с TTL = 1 не отбрасывается и не вызывает ICMP-сообщения типа срок истек , а должна быть отдана приложению. Достижение пункта назначения определяется следующим образом: отсылаемыеtracerouteдейтаграммы содержат UDP-пакет с таким номером UDP-порта адресата (превышающим 30000), что он заведомо не используется на адресуемом хосте. В пункте назначения UDP-модуль, получая подобные дейтаграммы, возвращает ICMP-сообщения об ошибке «порт недоступен». Таким образом, чтобы узнать о завершении работы, программеtracerouteдостаточно обнаружить, что поступило ICMP-сообщение об ошибке этого типа.
Примерв Windows:
C:\Documents and Settings\dnl>tracert fpm2.ami.nstu.ru
Пример.Результат выполнения командыtracert
Трассировка маршрута к fpm2.ami.nstu.ru
с максимальным числом прыжков 30:
1 2 ms 1 ms 1 ms ifgate.interface.nsk.su
2 2 ms 1 ms 2 ms cisco.n-sk.ru
3 1 ms 1 ms 1 ms router.n-sk.ru
4 2 ms 1 ms 1 ms nsk-ix.n-sk.ru
5 2 ms 1 ms 1 ms c7120.nstu.ru
6 2 ms 2 ms 1 ms ix-i.nstu.ru
7 2 ms 3 ms 1 ms ami.nstu.ru
8 2 ms 3 ms 1 ms fpm2.ami.nstu.ru
Трассировка завершена.
Запуск программы производится из командной строки. Для этого вы должны войти в нее (Пуск – Выполнить – В графе «Открыть» пишется «cmd», нажимается ОK). В открывшемся окне пишем:
tracert fpm2.ami.nstu.ru
где tracert – обращение к программе, а fpm2.ami.nstu.ru– символьное имя (DNS-имя) или IPv4 адрес.
Примерв Linux:
В Unix/Linux системах существуют режимы, в которых запуск программы возможен только от имени суперпользователя root(администратора). К числу этих режимов относится важный режим трассировки с помощьюICMP (ключ -I).
Во всех остальных случаях (и в том числе в режиме, который используется по умолчанию) traceroute может работать от имени обычного рядового пользователя (на серверахfpm2 иSaturnключ-Iиспользовать запрещено, поэтому информация, выводимая на экран, будет неполной).
Пример. Результат выполнения командыtraceroute
%traceroute -I saturn.ami.nstu.ru
traceroute to saturn.ami.nstu.ru (217.71.130.153), 64 hops max, 60 byte packets
1 ifgate (195.62.2.1) 1.262 ms 1.258 ms 1.138 ms
2 cisco.n-sk.ru (195.62.0.93) 2.798 ms 1.629 ms 1.903 ms
3 router.n-sk.ru (195.62.1.49) 1.232 ms 1.175 ms 1.170 ms
4 nsk-ix.n-sk.ru (195.62.1.80) 1.567 ms 1.446 ms 1.579 ms
5 c7120.nstu.ru (217.71.128.237) 1.771 ms 1.659 ms 1.582 ms
6 ix-i.nstu.ru (217.71.128.70) 2.040 ms 1.593 ms 1.753 ms
7 ami.nstu.ru (217.71.131.2) 2.996 ms 2.718 ms 1.612 ms
8 saturn.ami.nstu.ru (217.71.130.153) 4.268 ms 3.108 ms 2.051 ms
Замечание. Утилитаtracerouteиспользуется в том числе и в познавательных целях, например, чтобы определить, почему внутри одного города между провайдерами так долго проходят пакеты. Оказалось, пакеты передавались не через внутреннюю точку обмена трафиком, а через город на другом континенте. В отчете по лабораторной работе желательно привести подобный случай для Новосибирска.
Утилиту ifconfig мы будем использовать не для конфигурирования сетевых интерфейсов, а в познавательных целях для получения информации о состоянии активных сетевых интерфейсов. Для этого, находясь на определенном хосте, выполняем утилиту ifconfig без параметров (опций) и анализируем полученные результаты.
Утилита netstat служит для определения состояния сетевых структур данных. Вы можете посмотреть таблицы маршрутизатора на вашей машине, детальную информацию о различных используемых протоколах и т. д. C опцией -i эта команда выдает информацию о сетевых интерфейсах на вашей машине.
Примериспользования команды netstat (для операционной системыSunOC):
name MTU Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue
le0 1500 solar sun 7442667 27558 736826 33 125361 0
lo0 536 loopback localhost 1283 0 1283 0 0 0 ,
где name – имя сетевого интерфейса;
lo0 – циклический (loopback) интерфейс (или «заглушка»), используемый для проверки сетевых протоколов;
MTU – (Maximum Transmition Unit) размер в байтах максимального пакета данных, поддерживаемого данным интерфейсом. Для Ethernet MTU=1500, для FDDI – 4428, для lo0 – 536;
Net/Dest – назначение сети. Это имя, значение которого можно получить по номеру сети (Network Number), может быть установлено в файле /etc/networks;
Address – имя машины (опция -n позволяет вывести также IP-адрес);
Ipkts/Ierrs – число пришедших пакетов и число ошибок;
Opkts/Oerrs – то же самое для исходящих пакетов;
Collis – число произошедших коллизий. Величина, называемая коэффициентом коллизий (collision rate), вычисляется как (Collis/Opkts)*100. Хорошим считается коэффициент 0…2 %, при 3…5 % можно начинать беспокоиться, если же он больше 5 %, дела совсем плохи;
Queue – число пакетов, ожидающих прохождения через интерфейс. В большинстве случаев таких пакетов нет.
Пример использования утилиты netstat дляLinux:
Bash-3.2$ netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0 1500 0 173351491 0 0 0 156580779 0 0 0 BMRU
eth1 1500 0 183024 0 0 0 247635 0 0 0 BMRU
lo 16436 0 547246 0 0 0 547246 0 0 0 LRU
И представляет собой осмотр созданной сети на предмет ее соответствия принятым стандартам. Серьезный и грамотный подход к тестированию лвс обеспечивает гарантию длительной, устойчивой и полноценной работы локальной сети и позволяет свести к минимуму работы в соответствии с таким немаловажным этапом, как диагностика сети.
Тестирование ЛВС включает в себя следующие этапы:
- проверка кабель-каналов
- осмотр рабочих узлов
- тестирование коммутационного оборудования
На этапе осмотра кабельных каналов проверяется целостность кабеля, правильность расположения кабельных жгутов, а также расположение кабельных трасс относительно источников помех и соответствие кабельной системы требованиям стандартов. Осмотр рабочих мест выявляет правильность прокладки кабеля вблизи розеточных модулей, а также наличие маркировки. Тестирование коммутационного оборудования определяет текущее состояние сети на предмет ее соответствия документации.
По результатам тестирования составляется отчет - документ, содержащий в себе выводы о техническом состоянии лвс и перечень рекомендаций по устранению выявленных неполадок, текущей эксплуатации и путям развития и модернизации сети в будущем.
Диагностика ЛВС и средства ее осуществления
Диагностика ЛВС является важной составляющей администрирования локальной сети и представляет собой процесс поиска неисправностей, замедляющих работу программного обеспечения и сети в целом. Последние можно условно разделить на три основные группы:
- физические неисправности
- ошибки в работе сетевых протоколов
- перегрузки в сети
Неисправности физического уровня связаны с выходом из строя сетевых устройств и компонентов. Перегрузки возникают вследствие невозможности сетевых устройств справиться с объемом поступающих к нему запросов. Ошибки в работе протоколов ведут к проблемам взаимодействия сетевых устройств друг с другом.
Для осуществления качественной диагностики ЛВС в мире разработано множество различных диагностических средств, позволяющих быстро определять причины сбоев в работе сетей. В области сетевой диагностики применяется, в частности, специализированное оборудование, такое как анализаторы сетевых протоколов, приборы мониторинга функционирования сети, кабельные и сетевые тестеры, а также специализированное тестирующее программное обеспечение. Так, обнаружить физическую неисправность можно с помощью простейших тестеров, проверяющих работу канала, а инструментальная диагностика ошибок, связанных с перегрузками и некорректной работой сетевых протоколов, осуществляется при помощи сетевых тестеров и анализаторов протоколов.
Значительная часть вышеперечисленных приборов имеет достаточно высокую цену, и это является одной из главных причин воспользоваться для проведения диагностики лвс услугами сторонних компаний, уже имеющих в своем распоряжении данное оборудование. Кроме того, даже если Вы решите приобрести такое оборудование и заниматься диагностикой лвс Вашего предприятия, что называется, «не отходя от кассы», совершенно не факт, что Ваш штатный системный администратор успешно справится с подобной задачей: ведь опыт и интуицию, в отличие от кабельных тестеров, не купишь.
Компания «Флайлинк» специализируется на разработке, установке и тестировании ЛВС, а также диагностике и обслуживании не первый год. В нашем распоряжении - самое передовое оборудование и технологии, а многочисленные положительные отзывы Клиентов подтверждают высочайшую квалификацию наших специалистов и качество выполненных работ.