Отказы собственно физической сети случаются редко, почти никогда. Но некоторые неисправности выглядят для пользователей как настоящий отказ сети.
Обычно звучит приведенная выше фраза, и ИТ-администратору приходится ломать голову, отыскивая неисправность в ситуациях, вызванных неполадками четырех видов. Как будет показано в статье, внешние проявления неисправностей сети часто обманчивы. Два случая можно ошибочно принять за неполадку сети, хотя в действительности причина неисправности иная. Рассмотрим некоторые досадные проблемы с сетью и способы их устранения.
Загадочные разъединения
ИТ-специалиста просят прийти в комнату пользователя, потерявшего соединение с сетью. Windows показывает, что соединение активно, но кабель отключен. Вздыхая, администратор проверяет Ethernet-кабель пользователя. Он подключен. После замены кабеля связь не восстанавливается. Начиная раздражаться, администратор переносит кабель между коммутационной панелью и коммутатором Ethernet в распределительном шкафу на другой порт коммутатора. Соединение восстановлено. Что произошло?
Многие корпоративные коммутаторы располагают встроенной функциональностью для автоматического отключения порта с подозрительным поведением. Типичная причина — дуплексное рассогласование. Предполагается, что отключенный порт будет немедленно замечен, и это поможет администратору устранить неполадку, которая привела к автоматическому отключению порта.
В документации Cisco эта функция именуется error-disable или errdisable. Другие поставщики могут применять иную терминологию.
Ниже перечислена последовательность шагов, как можно обнаружить и устранить эту проблему. В данной статье используются примеры на основе Cisco CatOS, хотя аналогичная функциональность существует для Cisco IOS.
Итак, необходимые действия:
-
Физически идентифицируйте порт коммутатора, отключенный в результате ошибки.
-
Из активного режима выполните команду show port <номер порта>
-
Если порт действительно отключен в результате ошибки, состояние будет показано как errdisable.
-
Устраните неполадку, которая привела к отключению порта. Не забудьте проверить настройки дуплекса и кабели.
-
Чтобы заново активизировать порт, выполните из активного режима команду set port enable <номер порта>
Существует также функция, позволяющая настроить отключенный в результате ошибки порт коммутатора на автоматическое повторное включение по истечении указанного времени. Можно принудительно задействовать все причины ошибочных отключений или указать определенные причины (например, автоматически выполнять повторное включение после всех ошибок, кроме дуплексного рассогласования). Способы настройки порта коммутатора на автоматическое повторное включение описаны в документации для команды set errdisabletimeout.
Маршрутизация между виртуальными локальными сетями
Многие ИТ-специалисты используют протокол VoIP или внесли соответствующий пункт в свой постоянно растущий список неотложных дел. Поставщики VoIP обычно рекомендуют явно создать отдельную виртуальную локальную сеть, чтобы отделить трафик данных от речевого трафика. Такое разделение в первую очередь сокращает объем широковещательного трафика, поступающий в VoIP-телефоны. Кроме того, упрощается применение более строгих параметров службы обеспечения качества обслуживания (QoS) и достигается качество голосовой связи такое же, как у обычного телефона без VoIP, или лучше.
Ко мне часто обращаются специалисты, находящиеся в процессе организации отдельной виртуальной локальной сети или только что завершившие ее настройку. Для некоторых из них это первый опыт настройки виртуальной локальной сети.
Они пытаются с помощью команды ping проверить связь с устройством, имеющим IP-адрес и размещенным в виртуальной локальной сети данных. В большинстве случаев связь между виртуальными локальными сетями необходима для доступа в Internet и управления инфраструктурой VoIP из виртуальной локальной сети данных. Проверка заканчивается неудачей. Отказывают все соединения. Логично предположить, что причина неисправности — в неверной настройке виртуальной локальной сети.
Это не так. Проблема заключается просто в утере навыков диагностики сетевых неполадок. Коммутация выполняется на уровне 2 модели OSI, а протокол IP принадлежит уровню 3. Невозможно маршрутизировать IP-пакеты без устройства, способного выполнить функцию маршрутизации. Но не волнуйтесь, во многих случаях необязательно покупать маршрутизатор. Существует ряд вариантов.
Модернизация. Компания может располагать одним или несколькими коммутаторами, которые обеспечивают IP-маршрутизацию уровня 3 или могут справиться с задачей после модернизации. Такие коммутаторы выпускает большинство ведущих поставщиков. Приобретая для VoIP новые коммутаторы, обеспечивающие подачу электропитания через Ethernet (PoE), полезно купить коммутатор с функциональностью уровня 3.
Маршрутизатор для малого или домашнего офиса. Маршрутизатор для малого или домашнего офиса — не лучший выбор для масштабирования и технического обслуживания, но, по крайней мере, он может служить отправной точкой.
Брандмауэр. Аппаратный или программный брандмауэр полезен при наличии свободного интерфейса Ethernet. Отметьте интерфейс как соединение с дополнительной внутренней или доверенной сетью, и установите соответствующие политики маршрутизации и безопасности.
Служба маршрутизации и удаленного доступа (RRAS). Можно использовать службу RRAS, доступную в Windows Server, при условии, что она установлена на компьютере с двумя интерфейсами Ethernet. Это удачный вариант, если требуется обеспечить для голосовой виртуальной локальной сети такие службы инфраструктуры, как DHCP и DNS.
Прерванная операция
Распространенная проблема: пользователь вводит URL-указатель в строку адреса Internet Explorer (IE) и нажимает клавишу Enter. Начинается загрузка сайта, но затем появляется диалоговое окно с сообщением Internet Explorer cannot open the Internet site
Поначалу я думал, что причина — в функциональности Web-proxy брандмауэра ISA Server. Но неполадка не исчезла даже после того, как трафик был временно направлен в обход брандмауэра. Затем я предположил, что сеанс TCP был сброшен до завершения загрузки страницы. В результате трассировки сети выяснилось, что это не так.
Наконец, я пришел к мысли, что проблема может быть в самом браузере IE, поэтому провел поиск в Internet и обнаружил статью Microsoft «BUG: Error message when you visit a Web page or interact with a Web application in Internet Explorer: 'Operation aborted'» по адресу support.microsoft.com/kb/927917.
В ней описана та самая проблема, но ее причина (код сценария, который изменяет определенные элементы контейнера) не объясняет, почему неполадка не проявлялась постоянно. Ведь маловероятно, что сайт TechNet был изменен в течение двух секунд, которые требуются, чтобы нажать клавишу F5. Однако дальнейшее исследование показало, что проблема заключается в компоненте синтаксического анализатора IE: точный порядок загрузки и синтаксического анализа страницы чуть меняется от одного обновления к другому. Таким образом, стало понятно, почему я мог обновить страницу, на которой происходили неполадки, десять раз, а проблема проявлялась дважды.
Но мне так и не удалось найти способа обойти эту ситуацию. В статье говорится, что бесперебойное функционирование должен обеспечить автор сайта, изменив программный код. Надеемся, компания Microsoft устранит неполадку в версии IE 8.0.
Просроченные пароли
Ко мне обратился взволнованный бывший коллега: его сеть рушилась. Среди описанных им симптомов была невозможность пользователей обратиться к Exchange Server через Microsoft Office Outlook. Некоторые присоединенные диски тоже были недоступны. Как ни странно, доступ в Internet был возможен.
Пока коллега искал причину неполадки, те же самые проблемы начались у пользователя в соседней комнате. Через пять минут сотрудник с дальнего конца офиса громко всех оповестил, что и он стал жертвой неисправности.
Я спросил коллегу, проверил ли он очевидную причину — возможные неполадки на сервере. Их не было. В последнее время изменения в программное обеспечение или оборудование не вносились. Основные сетевые соединения функционируют исправно.
Поразмыслив, я спросил, проверены ли учетные записи пользователя в Active Directory (AD)? Возможно, пользователи, пострадавшие от неполадок, каким-то образом блокировали себя. Он проверил это предположение, и выяснилось, что пользователи не блокированы. Наконец, меня осенило — а не получали ли в последнее время пользователи извещения о скором истечении срока действия пароля?
Коллега ответил, что все пользователи видели извещение в течение нескольких дней, и сегодня в сообщении говорилось, что срок истекает через один день. Никто не любит менять пароль, поэтому пользователи регулярно нажимали No. В день аварии история повторилась. Однако «один день» в сообщении означает не «в течение 24 часов от настоящего момента», а «когда-нибудь в течение следующих 24 часов». Мой коллега дал пользователям указание завершить сеанс, а потом заново выполнить регистрацию. Естественно, всем им пришлось изменить пароли, и после этого проблем не возникало. Поскольку сотрудники приходили на работу ежедневно примерно в одно и то же время, срок действия их паролей завершался почти одновременно. Теперь мы объясняем пользователям, что «один день» в действительности означает «сегодня».
Майкл Дрегон (mike@mikerochip.com) — редактор Windows IT Pro и системный инженер в Нью-Йорке. Имеет сертификаты MCDST и MCSE: Messaging