eng
Поиск неисправностей в беспроводных сетях – задача, достаточно сильно отличающаяся от аналогичной в традиционных проводных сетях.
DOI: 10.22184/2070-8963.2018.75.6.40.51
DOI: 10.22184/2070-8963.2018.75.6.40.51
Теги: troubleshooting wi-fi networks wi-fi wi-fi networks поиск неисправностей в беспроводных сетях сети wi-fi
КЛАССИФИКАЦИЯ ПРОБЛЕМ
В сравнении с проводными сетями беспроводные характеризуются другим способом доступа к среде и физически иной передачей сигнала, что накладывает свой отпечаток на процесс поиска неисправностей. Помимо этого, беспроводная природа подключения привносит неопределенность в положение клиента в пространстве.
Достаточно удобно проводить процесс поиска неисправностей, относя возникшую проблему к одному из заранее определенных классов, со своими шагами проверок, которые позволят ее сузить и понять. Для сетей WLAN (Wi-Fi) целесообразно выделить следующие классы проблем:
• физическая (аппаратная) неисправность;
• дефект прошивки или устранимый производственный дефект (брак);
• проблемы настройки;
• программный дефект;
• неверно выбранный дизайн решения.
Следует отметить, что в процессе решения может выясниться, что класс проблемы был изначально определен неверно. В идеальной ситуации это не должно приводить к большим задержкам при поиске решения, однако в реальной ситуации, конечно, может замедлить восстановление нормальной работы сети.
Для выбора класса проблемы можно воспользоваться следующей схемой последовательности вопросов:
• Что? (Какое именно устройство; одно, несколько или все имеющиеся);
• Где? (В какой части офиса/здания/производственной зоны проблема наблюдается, а в какой части – нет);
• Когда? (Когда проблема начала проявляться; предшествовала ли ей нормальная работа сети; когда проблема точно не проявлялась);
• Что еще? (Вносились ли какие-либо изменения в сеть, расположение точек доступа; проводились ли в здании ремонтные работы или инсталляции чего-либо; переезжали ли отделы; появлялись ли в близлежащих помещениях новые арендаторы и т.д).
Для более полной информации о схемах начальных опросов следует обратиться к специальной литературе (см., например, методы Кепнера-Трего и "Пяти почему" (5Why)). Если проблема проявляется лишь на одном устройстве при наличии нескольких подобных, имеет смысл предполагать физическую неисправность устройства. В случае если подобие неполно, допустим, при существенном различии в инсталляции (например, одна из точек доступа висит на стене напротив лифтов, а другая – в фальш-потолке офисной зоны), предпочтительно поменять местами заведомо рабочее и потенциально сбойное устройства для проверки: не связана ли неисправность с физическим положением устройства. Понятно, что при этом необходимо по той же схеме провести замену всех соединительных кабелей.
Если проблема проявляется только на определенном типе оборудования (на всех устройствах определенного типа), то физическая неисправность конкретного устройства маловероятна. Однако в случае неверной инсталляции это возможно, например, при нарушении герметичности корпуса у точек доступа, предназначенных для инсталляции вне помещений. В этом случае необходимо проверить, существуют ли отличия в применении потенциально сбойной модели для проверки гипотезы о неверно выбранном дизайне решения. Если таких отличий нет, или если дизайн проверен и соответствует возможностям оборудования (согласно документации производителя, возможности оборудования позволяют использовать его в данной схеме и настройка оборудования также выполнена согласно документации), можно предполагать программный дефект или дефект прошивки. Очевидно, что в процессе проверки дизайна возможно обнаружение ошибок конфигурации и их исправление. При новой инсталляции для конечного пользователя, как правило, достаточно трудно провести грань между программным дефектом и сбоем прошивки/производственным браком. Однако это не критично. В таком случае необходимо работать с поставщиком оборудования для решения проблемы. При новых инсталляциях определенную проблему представляет отсутствие данных о заведомо рабочем режиме сети. Это неудобство можно нивелировать, используя пилотные сети, а также с помощью поставщика решений, который может предоставить дополнительную информацию о тестовых инсталляциях. В случае если сеть в прошлом работала успешно, мы можем исключить вероятность производственных дефектов полностью (при условии, что задействованный функционал не менялся) и полностью сосредоточиться на локализации программного дефекта. При этом следует отметить, что проблемы при производстве встречаются настолько реже проблем с программным обеспечением, что их вероятностью можно в целом пренебречь. В случае проблем со всеми устройствами имеет смысл предположить, что в описании проблемы упущена какая-либо важная деталь, позволяющая сузить описание, либо что проблема не лежит в области беспроводных сетей (например, сбой в проводной сети может привести к потере соединения между контроллером и всеми точками доступа, при этом и контроллер, и точки доступа будут функционировать). Очевидно, что не во всех сетях возможно провести такой анализ, однако чем полнее он будет проведен, тем более будет упрощен процесс устранения неисправности.
Можно резюмировать, что в общем случае, когда рассматривается несколько устройств с достаточно схожими характеристиками, алгоритм проверки идет от физической неисправности к проверке настроек и дизайна в целом, и далее к программной неисправности (и возможному производственному браку).
АЛГОРИТМ ПРОВЕРКИ
Физическая неисправность – это далеко не всегда заметный глазу дефект. Помимо очевидных случаев (допустим, точку доступа уронили при монтаже и ее корпус разбит), возможен выход из строя электронных компонентов. Иногда такое устройство продолжает частично функционировать, что еще больше затрудняет анализ.
Если устройство выглядит совершенно вышедшим из строя и не включается, имеет смысл заменить источник питания (кабель, порт на коммутаторе, розетку) на гарантированно рабочую (не на свободную/резервную). Возможно переключить устройство, которое работало на этом источнике на потенциально сбойный источник, однако это следует делать с осторожностью, так как неисправность может привноситься источником питания (поэтому имеет смысл делать так только в случае, когда потенциально сбойное устройство нормально включается с проверенным рабочим источником питания). Это позволит локализовать проблему – и, возможно, избежать дорогостоящей замены.
Следует отметить, что иногда физическую замену устройства выполняют до прохода всех стадий поиска неисправности – как один из этапов исследования проблемы. Этот подход обоснован в случае критичного простоя, поскольку в идеальном случае приводит к наиболее быстрому восстановлению работоспособности системы. К сожалению, такой вариант решения существенно снижает возможность понять, что вызвало проблему и предотвратить появление аналогичных проблем в будущем.
К возможным осложениям при замене необходимо отнести отсутствие устройства (особенно дорогостоящего) в ЗИПе, срыв сроков замены и отсутствие рабочей конфигурации устройства. Все эти осложнения устраняются лишь превентивно, соблюдением политик по сохранению конфигураций устройств, а также использованием в сети оборудования сетевого управления (с возможностью хранения конфигураций различных версий и т.д.).
Дефект прошивки (или производственный брак, который возможно исправить перепрошивкой устройства) можно выделить в отдельный класс проблем именно потому, что, будучи близким по характеристикам к физической неисправности, такой дефект все же зачастую исправим. То есть если дефект уже известен, возможно его превентивное исправление, и замена оборудования не требуется. Это позволяет сэкономить ресурсы на замене. В случае если дефект трудноустраним (например, необходим консольный доступ в течение достаточно длительного времени, а устройство смонтировано на мачте), возможна аппаратная замена на другое устройство с исправленной прошивкой и проведение работ по устранению неисправности отдельно. Для минимизации проявления таких дефектов необходимо периодически проверять веб-сайт производителей оборудования на наличие новостей о таких производственных дефектах и поддерживать связь с поставщиками оборудования.
Проблемы настройки оборудования – наиболее частая причина сбоев. Здесь основной тактикой должен являться анализ внесенных изменений. К сожалению, зачастую технический персонал не придает должного значения документированию всех проводимых действий или даже пытается скрыть действия, которые могли повлечь за собой возникновение неисправности. Политика хранения версий конфигураций и учет внесения изменений помогут получить исчерпывающую информацию в случае необходимости. Большую услугу здесь может оказать тестовая сеть, где различные варианты конфигурации можно промоделировать – и, таким образом, локализовать проблемный сценарий. Далее можно обратиться к документации на оборудование (или к представителю производителя или к поставщику, если документация отсутствует или неполна), чтобы выяснить, какие изменения нужно внести для исправления проблемы. Это необходимо также для более точного описания проблемы производителю оборудования в случае, если проблема окажется связана с программной ошибкой, и для поиска временного решения. Если моделирование проблемы в тестовой сети невозможно, следует максимально упростить сценарий с целью сделать его рабочим, а далее усложнять его, постепенно доводя до того, который используется в реальной сети, отслеживая, в какой именно момент проблема возникнет снова. Например, в случае проблем с доступом пользователей к беспроводной сети при наличии портала с авторизацией по open id можно предложить:
• сначала создать еще одну, открытую сеть, используя ту же точку доступа;
• если подключение клиента, у которого отмечались проблемы, проходит нормально – настроить аутентификацию с порталом, но используя статические credentials;
• если подключение проходит теперь нормально, настроить аутентификацию по open id;
• если по достижении идентичной конфигурации проблема не воспроизводится (а старое решение по-прежнему не работает), можно использовать новую сеть для временного доступа (workaround) и одновременно продолжать анализ старой конфигурации для поиска ошибок.
Интересным вопросом для проблем, связанных с настройкой оборудования, являются новые сети. В них невозможно провести сравнение с заведомо хорошей конфигурацией. В этом случае нам для сравнения необходима пилотная сеть или хотя бы подробная документация на оборудование (configuration guides, blueprints). В новых сетях мы совершенно не можем исключить вероятность неверного дизайна, и всегда есть вероятность того, что оборудование не сможет работать желательным образом (хотя она, безусловно, невелика в случае построения сети грамотными специалистами). При подозрении проблемы с конфигурацией устройства мы, по сути, вновь проходим тот же цикл вопросов, что и при определении типа проблемы, однако на другом уровне. Мы стараемся локализовать место возникновения проблемы (устройство), а затем собрать диагностическую информацию, которая подтвердит/опровергнет наши выводы.
В случае подозреваемых проблем:
• на стороне клиента – собираем логи клиента и трафик беспроводного соединения, а также в случае наличия контроллера – дебаг-выводы, отражающие состояния клиента (например, для оборудования компании Cisco, debug client <mac-address>), собираем информацию о месте подключения (документацию по обследованию сети, wireless survey);
• на стороне точки доступа – собираем логи точки доступа (если есть) и контроллера (если он присутствует в сети), трафик беспроводного соединения, трафик между точкой доступа и контроллером (если мы используем схему lightweight APs);
• на стороне контроллера – собираем логи контроллера (для контроллеров Сisco начинаем с show msglog, show traplog и show run-config);
• на стороне оборудования мониторинга – собираем логи мониторинговой системы, контроллера, трафик между контроллером и системой мониторинга;
• на стороне аутентифицирующего сервера – собираем логи на сервере аутентификации, на контроллере и, возможно, трафик между ними;
• на стороне сети – собираем сетевой трафик между "нашими" устройствами и анализируем его на предмет возможных сбросов.
Как видно, набор данных, на основании которых мы делаем анализ, частично перекрывается. Это позволяет не тратить лишние ресурсы на разбор заведомо невероятных гипотез и быстрее получать необходимый набор данных для анализа. Проблемы, связанные с программным дефектом – наиболее часто рапортуются в службы технической поддержки, однако зачастую оказываются проблемами другого рода. В случае обнаружения в логах exceptions, kernel panics и прочих подобных сообщений с высоким уровнем важности (severity), мы можем с высокой вероятностью предполагать наличие программного дефекта. В таком случае необходимо проверить, присутствует ли этот дефект в числе известных производителю (в случае Cisco – используя bug toolkit на сайте) и в какой версии программного обеспечения этот дефект исправлен. В случае же неожиданных результатов работы программного обеспечения или зависания устройств рекомендуется вначале проверить другие возможные причины возникновения проблемы. Для сетевого инженера невозможно полностью исправить данную проблему самостоятельно, однако зачастую возможно найти обходной путь, который существенно снизит влияние проблемы на сеть (workaround). Для этого при обнаружении программного дефекта необходимо попытаться понять, какая подсистема оборудования подвержена дефекту, а затем попробовать задействовать аналогичный функционал, не используя ее. Например, при обнаружении бага в режиме FlexConnect можно попробовать перевести точку доступа в режим Local. Этот режим, конечно, создаст дополнительную нагрузку на канал связи между точкой доступа и контроллером, а также на контроллер, однако эта дополнительная нагрузка может оказаться допустимой на время, необходимое производителю для исправления дефекта и предоставления нового ПО. Именно поэтому в случае если проблема неизвестна производителю, имеет смысл смоделировать проблему у себя и стараться максимально участвовать в процессе ее решения. Безусловно, это может оказаться невозможным в случае ограниченных ресурсов или повышенной критичности рабочей сети.
Неверный дизайн – это самая болезненная ошибка, которую допускают инженеры при построении сетей. В случае беспроводных сетей к вопросам capacity (емкость), bandwidth (ширина канала), необходимого функционала добавляются ограничения, накладываемые "материальным" миром (размещение точек доступа и их питание, требования по качеству покрытия), которые меняются в зависимости от желаемого функционала сети, возможной интерференции с другими устройствами заказчика… К счастью, эти проблемы зачастую выявляются и устраняются при пилотных запусках. Для предотвращения проникновения ошибок такого рода в production необходимо тщательное проведение нагрузочных испытаний. Тестированию должен подлежать не только сам факт подключения или использования желаемого функционала, но и качество предоставляемого сервиса, а также возможность работы в случае полной нагрузки некоторого участка сети и поведение сети в случае перегрузки. В общем случае можно предполагать наличие неверного дизайна, если описание проблемы включает в себя упоминание о неработающем изначально функционале или существенном ухудшении сервиса при введении сети в эксплуатацию. В такой ситуации в качестве решения может выступать как полное, так и частичное изменение сети, что зачастую невозможно осуществить в короткие сроки. Поэтому, как это ни грустно, иногда в качестве временного решения приходится ограничивать функционал сети (например, вместо использования всеми сотрудниками только беспроводного подключения переводить стационарные станции на "обычное" проводное подключение).
ТЕСТОВЫЙ СЦЕНАРИЙ
Предположим, что некая компания имеет развернутую в своем офисе беспроводную сеть. Офис расположен в отдельно стоящем малоэтажном здании, на территории бизнес-парка, в окружении подобных построек. На первом этаже здания находится зона приема посетителей, санузлы, хозяйственные помещения, а также небольшое кафе и зона отдыха. Также имеются рабочие помещения и комнаты для переговоров. На более высоких этажах располагаются исключительно рабочие места и санузлы. В здании имеется лифт. Перед вводом в эксплуатацию (до ввоза мебели) было проведено радиообследование, его результаты доступны для анализа. К сожалению, представлены только суммарные результаты по общему покрытию (одновременно и для 5 ГГц, и для 2,4 ГГц). Согласно данным радиообследования, сила сигнала (RSSI) колеблется между –60 и –40, а уровень шума (noise floor) не поднимается выше –75 (в основном колеблется около –90).
Для целей обеспечения беспроводного доступа были сконфигурированы две беспроводные сети – корпоративного пользования и гостевая. Для гостевой сети функционирует портал, данные для подключения к которому гостевые пользователи получают у секретаря (для каждого пользователя генерируется уникальная учетная запись). В корпоративной сети подключение происходит с проверкой машинного сертификата, а также учетной записи пользователя.
Наблюдаются следующие проблемы:
• иногда (с момента запуска сети в эксплуатацию) гостевые пользователи не могут подключиться к сети (чаще всего это происходит во второй половине дня и в пятницу);
• некоторые гостевые пользователи не могут подключиться, так как портал неактивен;
• больше всего нареканий на работу сети поступает в середине дня в зоне кафе (при этом есть пользователи, использующие доступ к сети из зоны кафе без каких-либо проблем в любое время).
Имеет смысл начать решение с более точного определения проблемы и разбиения ее на подзадачи.
В случае проблем с порталом необходимо как можно более точно удостовериться, что имеют в виду пользователи, описывая неработающий портал. Отсутствие IP-адреса, постоянная перезагрузка страницы портала, отсутствующая страница портала, сообщение об ошибке сертификата на портале, повторный вывод формы аутентификации, долгая загрузка формы аутентификации, отсутствие перенаправления после аутентификации – все это может быть смешано пользователями в одном описании: "портал не активен". При получении описания такого вида проблем крайне желательно получать логи и скриншоты наблюдаемой ошибки, а также описание ожидаемого поведения системы.
Очевидно, что две различные беспроводные сети могут иметь как общие, так и различающиеся проблемы. То есть в процессе поиска неисправностей необходимо учитывать, что выдвигаемые гипотезы для одной сети должны удовлетворять симптомам, наблюдаемым в другой сети.
Можно также отметить, что первый пункт описания затрагивает потенциально все устройства, в то время как второй и третий пункты проявляются только на определенных клиентских устройствах.
В качестве временного решения, найденного инженерами компании, используется перезагрузка коммутатора, в который подключены точки доступа первого этажа (используемые гостевыми пользователями). Однако известны случаи, когда и после такой перезагрузки часть гостевых пользователей не могла подключиться к сети.
Удобнее всего, безусловно, исследовать проблему в момент ее проявления в сети. В нашем случае проблема возникает достаточно часто, чтобы "поймать" ее вживую.
Подробную информацию о клиенте, испытывающем проблемы с подключением, можно видеть на скриншоте (рис.1).
Как видно на иллюстрации, клиент пытается получить IP-адрес. В нормальных условиях этот процесс проходит достаточно быстро, и клиент переходит в состояние ожидания веб-аутентификации. Здесь мы можем выдвинуть следующие гипотезы: проблема на стороне клиента, проблема на стороне беспроводного решения, проблема на стороне проводной сети или DHCP-сервера. Поскольку аналогичный сценарий не фиксируется для корпоративной сети, проблема на стороне беспроводной сети маловероятна; проблема на стороне проводной сети также маловероятна до тех пор, пока путь трафика к DHCP-серверам совпадает. Проведя тестовое подключение одного и того же клиента к корпоративной и гостевой сетям, мы можем убедиться в том, что клиент работает нормально (в корпоративной сети, но не в гостевой). Таким образом, основным "подозреваемым" становится DHCP-сервер и его настройки для гостевой сети.
Предположив это, мы проверяем DHCP-сервер (рис.2): налицо сразу несколько ошибок!
В результате быстрого временного и незадокументированного решения в качестве DHCP-сервера для гостевой сети использовался коммутатор первого этажа. Размер пула адресов также не выдерживает критики – он слишком мал для данной компании и одновременно срок выдачи адреса установлен в семь дней (не часов), что приводит к исчерпанию пула. Очевидно, что перезагрузка этого коммутатора приводила к очистке таблицы выданных адресов и некоторому высвобождению адресов. Однако в случае большого количества посетителей адресный пул все равно исчерпывался. Так неверно выбранный дизайн вкупе с ошибкой конфигурации привел к проблеме, негативно влияющей на имидж компании. Эта ошибка хорошо объясняет первую часть тестового сценария. Однако локализация проблемы приема в зоне кафе и "неактивность" портала (при этом устройство получает IP-адрес) требуют отдельного разбирательства.
При уточнении проблемы "неактивности" пришлось использовать метод воспроизведения проблемы, поскольку получить непосредственно устройство, на котором проблема возникала, оказалось невозможно. Такой метод несет в себе некоторую неопределенность – даже если проблема возникает при воспроизведении, мы не можем быть стопроцентно уверены, что это именно та проблема, которая возникла на исходном устройстве и, следовательно, не можем быть уверены в том, что решение воспроизведенной проблемы подойдет для решения проблемы исходной.
В процессе воспроизведения проблемы был получен скриншот (рис.3): HTTPS-reidirect – функциональность, хотя и востребованная рядом заказчиков, но требующая определенных знаний от конечного пользователя, так как всегда вызывает появление предупреждения в окне браузера. В данном тестовом сценарии администратор сети не планировал ее использовать, однако она осталась включенной по ошибке. Поскольку ее наличие не предполагалось, сертификат не обновлялся, а также не использовался корпоративный CA. В результате часть браузеров полностью блокировала возможность перехода на страницу портала (без специальных настроек), а часть – генерировало окно с предупреждением, если при подключении осуществлялся HTTPS, а не HTTP-redirect.
В данном тестовом сценарии предполагается, что заказчик принял решение изменить конфигурацию контроллера, полностью отключив HTTPS-redirect. Безусловно, это может приводить к отсутствию портала в случае, если браузер коммуницирует с использованием HTTPS (такой запрос не будет перенаправлен на портал, а просто будет сброшен контроллером, как и любой другой трафик до аутентификации).
Наконец, пришло время анализа третьей составляющей проблемы – ухудшения приема в зоне кафе. Чем характеризуется зона кафе в данном офисе? Согласно тестовому сценарию, в кафе наличествует открытая терраса. Также мы можем предположить наличие источника помех в диапазоне 2,4 ГГц – микроволновой печи, которая может использоваться для разогрева блюд. Для участков открытой территории с Wi-Fi-покрытием достаточно логично предположить использование диапазона 2,4 ГГц. Безусловно, в случае небольшой террасы покрытие (хотя бы частично) может обеспечиваться за счет точек доступа, установленных внутри помещения и использующих диапазон 5 ГГц. Это может объяснять тот факт, что часть клиентов не испытывает проблем при работе в кафе – они используют 5 ГГц, который не подвержен влиянию работы микроволновой печи.
Для подтверждения этой гипотезы необходимо провести радиообследование во время возникновения проблемы. Важно отметить, что результаты в разных диапазонах должны быть представлены раздельно.
Подводя итоги, отметим, что процесс поиска неисправностей в беспроводных сетях – это не обязательно рутинное занятие, однако он проходит гораздо эффективнее, если проводить его, придерживаясь определенного алгоритма. Использование разделения проблемы на подгруппы и дальнейшее уточнение приводит к достаточно быстрому пониманию проблемы, что, в свою очередь, помогает получить ее быстрое решение. А ведь именно это – правильно работающая сеть – и является конечной целью поиска неисправностей. ■
В сравнении с проводными сетями беспроводные характеризуются другим способом доступа к среде и физически иной передачей сигнала, что накладывает свой отпечаток на процесс поиска неисправностей. Помимо этого, беспроводная природа подключения привносит неопределенность в положение клиента в пространстве.
Достаточно удобно проводить процесс поиска неисправностей, относя возникшую проблему к одному из заранее определенных классов, со своими шагами проверок, которые позволят ее сузить и понять. Для сетей WLAN (Wi-Fi) целесообразно выделить следующие классы проблем:
• физическая (аппаратная) неисправность;
• дефект прошивки или устранимый производственный дефект (брак);
• проблемы настройки;
• программный дефект;
• неверно выбранный дизайн решения.
Следует отметить, что в процессе решения может выясниться, что класс проблемы был изначально определен неверно. В идеальной ситуации это не должно приводить к большим задержкам при поиске решения, однако в реальной ситуации, конечно, может замедлить восстановление нормальной работы сети.
Для выбора класса проблемы можно воспользоваться следующей схемой последовательности вопросов:
• Что? (Какое именно устройство; одно, несколько или все имеющиеся);
• Где? (В какой части офиса/здания/производственной зоны проблема наблюдается, а в какой части – нет);
• Когда? (Когда проблема начала проявляться; предшествовала ли ей нормальная работа сети; когда проблема точно не проявлялась);
• Что еще? (Вносились ли какие-либо изменения в сеть, расположение точек доступа; проводились ли в здании ремонтные работы или инсталляции чего-либо; переезжали ли отделы; появлялись ли в близлежащих помещениях новые арендаторы и т.д).
Для более полной информации о схемах начальных опросов следует обратиться к специальной литературе (см., например, методы Кепнера-Трего и "Пяти почему" (5Why)). Если проблема проявляется лишь на одном устройстве при наличии нескольких подобных, имеет смысл предполагать физическую неисправность устройства. В случае если подобие неполно, допустим, при существенном различии в инсталляции (например, одна из точек доступа висит на стене напротив лифтов, а другая – в фальш-потолке офисной зоны), предпочтительно поменять местами заведомо рабочее и потенциально сбойное устройства для проверки: не связана ли неисправность с физическим положением устройства. Понятно, что при этом необходимо по той же схеме провести замену всех соединительных кабелей.
Если проблема проявляется только на определенном типе оборудования (на всех устройствах определенного типа), то физическая неисправность конкретного устройства маловероятна. Однако в случае неверной инсталляции это возможно, например, при нарушении герметичности корпуса у точек доступа, предназначенных для инсталляции вне помещений. В этом случае необходимо проверить, существуют ли отличия в применении потенциально сбойной модели для проверки гипотезы о неверно выбранном дизайне решения. Если таких отличий нет, или если дизайн проверен и соответствует возможностям оборудования (согласно документации производителя, возможности оборудования позволяют использовать его в данной схеме и настройка оборудования также выполнена согласно документации), можно предполагать программный дефект или дефект прошивки. Очевидно, что в процессе проверки дизайна возможно обнаружение ошибок конфигурации и их исправление. При новой инсталляции для конечного пользователя, как правило, достаточно трудно провести грань между программным дефектом и сбоем прошивки/производственным браком. Однако это не критично. В таком случае необходимо работать с поставщиком оборудования для решения проблемы. При новых инсталляциях определенную проблему представляет отсутствие данных о заведомо рабочем режиме сети. Это неудобство можно нивелировать, используя пилотные сети, а также с помощью поставщика решений, который может предоставить дополнительную информацию о тестовых инсталляциях. В случае если сеть в прошлом работала успешно, мы можем исключить вероятность производственных дефектов полностью (при условии, что задействованный функционал не менялся) и полностью сосредоточиться на локализации программного дефекта. При этом следует отметить, что проблемы при производстве встречаются настолько реже проблем с программным обеспечением, что их вероятностью можно в целом пренебречь. В случае проблем со всеми устройствами имеет смысл предположить, что в описании проблемы упущена какая-либо важная деталь, позволяющая сузить описание, либо что проблема не лежит в области беспроводных сетей (например, сбой в проводной сети может привести к потере соединения между контроллером и всеми точками доступа, при этом и контроллер, и точки доступа будут функционировать). Очевидно, что не во всех сетях возможно провести такой анализ, однако чем полнее он будет проведен, тем более будет упрощен процесс устранения неисправности.
Можно резюмировать, что в общем случае, когда рассматривается несколько устройств с достаточно схожими характеристиками, алгоритм проверки идет от физической неисправности к проверке настроек и дизайна в целом, и далее к программной неисправности (и возможному производственному браку).
АЛГОРИТМ ПРОВЕРКИ
Физическая неисправность – это далеко не всегда заметный глазу дефект. Помимо очевидных случаев (допустим, точку доступа уронили при монтаже и ее корпус разбит), возможен выход из строя электронных компонентов. Иногда такое устройство продолжает частично функционировать, что еще больше затрудняет анализ.
Если устройство выглядит совершенно вышедшим из строя и не включается, имеет смысл заменить источник питания (кабель, порт на коммутаторе, розетку) на гарантированно рабочую (не на свободную/резервную). Возможно переключить устройство, которое работало на этом источнике на потенциально сбойный источник, однако это следует делать с осторожностью, так как неисправность может привноситься источником питания (поэтому имеет смысл делать так только в случае, когда потенциально сбойное устройство нормально включается с проверенным рабочим источником питания). Это позволит локализовать проблему – и, возможно, избежать дорогостоящей замены.
Следует отметить, что иногда физическую замену устройства выполняют до прохода всех стадий поиска неисправности – как один из этапов исследования проблемы. Этот подход обоснован в случае критичного простоя, поскольку в идеальном случае приводит к наиболее быстрому восстановлению работоспособности системы. К сожалению, такой вариант решения существенно снижает возможность понять, что вызвало проблему и предотвратить появление аналогичных проблем в будущем.
К возможным осложениям при замене необходимо отнести отсутствие устройства (особенно дорогостоящего) в ЗИПе, срыв сроков замены и отсутствие рабочей конфигурации устройства. Все эти осложнения устраняются лишь превентивно, соблюдением политик по сохранению конфигураций устройств, а также использованием в сети оборудования сетевого управления (с возможностью хранения конфигураций различных версий и т.д.).
Дефект прошивки (или производственный брак, который возможно исправить перепрошивкой устройства) можно выделить в отдельный класс проблем именно потому, что, будучи близким по характеристикам к физической неисправности, такой дефект все же зачастую исправим. То есть если дефект уже известен, возможно его превентивное исправление, и замена оборудования не требуется. Это позволяет сэкономить ресурсы на замене. В случае если дефект трудноустраним (например, необходим консольный доступ в течение достаточно длительного времени, а устройство смонтировано на мачте), возможна аппаратная замена на другое устройство с исправленной прошивкой и проведение работ по устранению неисправности отдельно. Для минимизации проявления таких дефектов необходимо периодически проверять веб-сайт производителей оборудования на наличие новостей о таких производственных дефектах и поддерживать связь с поставщиками оборудования.
Проблемы настройки оборудования – наиболее частая причина сбоев. Здесь основной тактикой должен являться анализ внесенных изменений. К сожалению, зачастую технический персонал не придает должного значения документированию всех проводимых действий или даже пытается скрыть действия, которые могли повлечь за собой возникновение неисправности. Политика хранения версий конфигураций и учет внесения изменений помогут получить исчерпывающую информацию в случае необходимости. Большую услугу здесь может оказать тестовая сеть, где различные варианты конфигурации можно промоделировать – и, таким образом, локализовать проблемный сценарий. Далее можно обратиться к документации на оборудование (или к представителю производителя или к поставщику, если документация отсутствует или неполна), чтобы выяснить, какие изменения нужно внести для исправления проблемы. Это необходимо также для более точного описания проблемы производителю оборудования в случае, если проблема окажется связана с программной ошибкой, и для поиска временного решения. Если моделирование проблемы в тестовой сети невозможно, следует максимально упростить сценарий с целью сделать его рабочим, а далее усложнять его, постепенно доводя до того, который используется в реальной сети, отслеживая, в какой именно момент проблема возникнет снова. Например, в случае проблем с доступом пользователей к беспроводной сети при наличии портала с авторизацией по open id можно предложить:
• сначала создать еще одну, открытую сеть, используя ту же точку доступа;
• если подключение клиента, у которого отмечались проблемы, проходит нормально – настроить аутентификацию с порталом, но используя статические credentials;
• если подключение проходит теперь нормально, настроить аутентификацию по open id;
• если по достижении идентичной конфигурации проблема не воспроизводится (а старое решение по-прежнему не работает), можно использовать новую сеть для временного доступа (workaround) и одновременно продолжать анализ старой конфигурации для поиска ошибок.
Интересным вопросом для проблем, связанных с настройкой оборудования, являются новые сети. В них невозможно провести сравнение с заведомо хорошей конфигурацией. В этом случае нам для сравнения необходима пилотная сеть или хотя бы подробная документация на оборудование (configuration guides, blueprints). В новых сетях мы совершенно не можем исключить вероятность неверного дизайна, и всегда есть вероятность того, что оборудование не сможет работать желательным образом (хотя она, безусловно, невелика в случае построения сети грамотными специалистами). При подозрении проблемы с конфигурацией устройства мы, по сути, вновь проходим тот же цикл вопросов, что и при определении типа проблемы, однако на другом уровне. Мы стараемся локализовать место возникновения проблемы (устройство), а затем собрать диагностическую информацию, которая подтвердит/опровергнет наши выводы.
В случае подозреваемых проблем:
• на стороне клиента – собираем логи клиента и трафик беспроводного соединения, а также в случае наличия контроллера – дебаг-выводы, отражающие состояния клиента (например, для оборудования компании Cisco, debug client <mac-address>), собираем информацию о месте подключения (документацию по обследованию сети, wireless survey);
• на стороне точки доступа – собираем логи точки доступа (если есть) и контроллера (если он присутствует в сети), трафик беспроводного соединения, трафик между точкой доступа и контроллером (если мы используем схему lightweight APs);
• на стороне контроллера – собираем логи контроллера (для контроллеров Сisco начинаем с show msglog, show traplog и show run-config);
• на стороне оборудования мониторинга – собираем логи мониторинговой системы, контроллера, трафик между контроллером и системой мониторинга;
• на стороне аутентифицирующего сервера – собираем логи на сервере аутентификации, на контроллере и, возможно, трафик между ними;
• на стороне сети – собираем сетевой трафик между "нашими" устройствами и анализируем его на предмет возможных сбросов.
Как видно, набор данных, на основании которых мы делаем анализ, частично перекрывается. Это позволяет не тратить лишние ресурсы на разбор заведомо невероятных гипотез и быстрее получать необходимый набор данных для анализа. Проблемы, связанные с программным дефектом – наиболее часто рапортуются в службы технической поддержки, однако зачастую оказываются проблемами другого рода. В случае обнаружения в логах exceptions, kernel panics и прочих подобных сообщений с высоким уровнем важности (severity), мы можем с высокой вероятностью предполагать наличие программного дефекта. В таком случае необходимо проверить, присутствует ли этот дефект в числе известных производителю (в случае Cisco – используя bug toolkit на сайте) и в какой версии программного обеспечения этот дефект исправлен. В случае же неожиданных результатов работы программного обеспечения или зависания устройств рекомендуется вначале проверить другие возможные причины возникновения проблемы. Для сетевого инженера невозможно полностью исправить данную проблему самостоятельно, однако зачастую возможно найти обходной путь, который существенно снизит влияние проблемы на сеть (workaround). Для этого при обнаружении программного дефекта необходимо попытаться понять, какая подсистема оборудования подвержена дефекту, а затем попробовать задействовать аналогичный функционал, не используя ее. Например, при обнаружении бага в режиме FlexConnect можно попробовать перевести точку доступа в режим Local. Этот режим, конечно, создаст дополнительную нагрузку на канал связи между точкой доступа и контроллером, а также на контроллер, однако эта дополнительная нагрузка может оказаться допустимой на время, необходимое производителю для исправления дефекта и предоставления нового ПО. Именно поэтому в случае если проблема неизвестна производителю, имеет смысл смоделировать проблему у себя и стараться максимально участвовать в процессе ее решения. Безусловно, это может оказаться невозможным в случае ограниченных ресурсов или повышенной критичности рабочей сети.
Неверный дизайн – это самая болезненная ошибка, которую допускают инженеры при построении сетей. В случае беспроводных сетей к вопросам capacity (емкость), bandwidth (ширина канала), необходимого функционала добавляются ограничения, накладываемые "материальным" миром (размещение точек доступа и их питание, требования по качеству покрытия), которые меняются в зависимости от желаемого функционала сети, возможной интерференции с другими устройствами заказчика… К счастью, эти проблемы зачастую выявляются и устраняются при пилотных запусках. Для предотвращения проникновения ошибок такого рода в production необходимо тщательное проведение нагрузочных испытаний. Тестированию должен подлежать не только сам факт подключения или использования желаемого функционала, но и качество предоставляемого сервиса, а также возможность работы в случае полной нагрузки некоторого участка сети и поведение сети в случае перегрузки. В общем случае можно предполагать наличие неверного дизайна, если описание проблемы включает в себя упоминание о неработающем изначально функционале или существенном ухудшении сервиса при введении сети в эксплуатацию. В такой ситуации в качестве решения может выступать как полное, так и частичное изменение сети, что зачастую невозможно осуществить в короткие сроки. Поэтому, как это ни грустно, иногда в качестве временного решения приходится ограничивать функционал сети (например, вместо использования всеми сотрудниками только беспроводного подключения переводить стационарные станции на "обычное" проводное подключение).
ТЕСТОВЫЙ СЦЕНАРИЙ
Предположим, что некая компания имеет развернутую в своем офисе беспроводную сеть. Офис расположен в отдельно стоящем малоэтажном здании, на территории бизнес-парка, в окружении подобных построек. На первом этаже здания находится зона приема посетителей, санузлы, хозяйственные помещения, а также небольшое кафе и зона отдыха. Также имеются рабочие помещения и комнаты для переговоров. На более высоких этажах располагаются исключительно рабочие места и санузлы. В здании имеется лифт. Перед вводом в эксплуатацию (до ввоза мебели) было проведено радиообследование, его результаты доступны для анализа. К сожалению, представлены только суммарные результаты по общему покрытию (одновременно и для 5 ГГц, и для 2,4 ГГц). Согласно данным радиообследования, сила сигнала (RSSI) колеблется между –60 и –40, а уровень шума (noise floor) не поднимается выше –75 (в основном колеблется около –90).
Для целей обеспечения беспроводного доступа были сконфигурированы две беспроводные сети – корпоративного пользования и гостевая. Для гостевой сети функционирует портал, данные для подключения к которому гостевые пользователи получают у секретаря (для каждого пользователя генерируется уникальная учетная запись). В корпоративной сети подключение происходит с проверкой машинного сертификата, а также учетной записи пользователя.
Наблюдаются следующие проблемы:
• иногда (с момента запуска сети в эксплуатацию) гостевые пользователи не могут подключиться к сети (чаще всего это происходит во второй половине дня и в пятницу);
• некоторые гостевые пользователи не могут подключиться, так как портал неактивен;
• больше всего нареканий на работу сети поступает в середине дня в зоне кафе (при этом есть пользователи, использующие доступ к сети из зоны кафе без каких-либо проблем в любое время).
Имеет смысл начать решение с более точного определения проблемы и разбиения ее на подзадачи.
В случае проблем с порталом необходимо как можно более точно удостовериться, что имеют в виду пользователи, описывая неработающий портал. Отсутствие IP-адреса, постоянная перезагрузка страницы портала, отсутствующая страница портала, сообщение об ошибке сертификата на портале, повторный вывод формы аутентификации, долгая загрузка формы аутентификации, отсутствие перенаправления после аутентификации – все это может быть смешано пользователями в одном описании: "портал не активен". При получении описания такого вида проблем крайне желательно получать логи и скриншоты наблюдаемой ошибки, а также описание ожидаемого поведения системы.
Очевидно, что две различные беспроводные сети могут иметь как общие, так и различающиеся проблемы. То есть в процессе поиска неисправностей необходимо учитывать, что выдвигаемые гипотезы для одной сети должны удовлетворять симптомам, наблюдаемым в другой сети.
Можно также отметить, что первый пункт описания затрагивает потенциально все устройства, в то время как второй и третий пункты проявляются только на определенных клиентских устройствах.
В качестве временного решения, найденного инженерами компании, используется перезагрузка коммутатора, в который подключены точки доступа первого этажа (используемые гостевыми пользователями). Однако известны случаи, когда и после такой перезагрузки часть гостевых пользователей не могла подключиться к сети.
Удобнее всего, безусловно, исследовать проблему в момент ее проявления в сети. В нашем случае проблема возникает достаточно часто, чтобы "поймать" ее вживую.
Подробную информацию о клиенте, испытывающем проблемы с подключением, можно видеть на скриншоте (рис.1).
Как видно на иллюстрации, клиент пытается получить IP-адрес. В нормальных условиях этот процесс проходит достаточно быстро, и клиент переходит в состояние ожидания веб-аутентификации. Здесь мы можем выдвинуть следующие гипотезы: проблема на стороне клиента, проблема на стороне беспроводного решения, проблема на стороне проводной сети или DHCP-сервера. Поскольку аналогичный сценарий не фиксируется для корпоративной сети, проблема на стороне беспроводной сети маловероятна; проблема на стороне проводной сети также маловероятна до тех пор, пока путь трафика к DHCP-серверам совпадает. Проведя тестовое подключение одного и того же клиента к корпоративной и гостевой сетям, мы можем убедиться в том, что клиент работает нормально (в корпоративной сети, но не в гостевой). Таким образом, основным "подозреваемым" становится DHCP-сервер и его настройки для гостевой сети.
Предположив это, мы проверяем DHCP-сервер (рис.2): налицо сразу несколько ошибок!
В результате быстрого временного и незадокументированного решения в качестве DHCP-сервера для гостевой сети использовался коммутатор первого этажа. Размер пула адресов также не выдерживает критики – он слишком мал для данной компании и одновременно срок выдачи адреса установлен в семь дней (не часов), что приводит к исчерпанию пула. Очевидно, что перезагрузка этого коммутатора приводила к очистке таблицы выданных адресов и некоторому высвобождению адресов. Однако в случае большого количества посетителей адресный пул все равно исчерпывался. Так неверно выбранный дизайн вкупе с ошибкой конфигурации привел к проблеме, негативно влияющей на имидж компании. Эта ошибка хорошо объясняет первую часть тестового сценария. Однако локализация проблемы приема в зоне кафе и "неактивность" портала (при этом устройство получает IP-адрес) требуют отдельного разбирательства.
При уточнении проблемы "неактивности" пришлось использовать метод воспроизведения проблемы, поскольку получить непосредственно устройство, на котором проблема возникала, оказалось невозможно. Такой метод несет в себе некоторую неопределенность – даже если проблема возникает при воспроизведении, мы не можем быть стопроцентно уверены, что это именно та проблема, которая возникла на исходном устройстве и, следовательно, не можем быть уверены в том, что решение воспроизведенной проблемы подойдет для решения проблемы исходной.
В процессе воспроизведения проблемы был получен скриншот (рис.3): HTTPS-reidirect – функциональность, хотя и востребованная рядом заказчиков, но требующая определенных знаний от конечного пользователя, так как всегда вызывает появление предупреждения в окне браузера. В данном тестовом сценарии администратор сети не планировал ее использовать, однако она осталась включенной по ошибке. Поскольку ее наличие не предполагалось, сертификат не обновлялся, а также не использовался корпоративный CA. В результате часть браузеров полностью блокировала возможность перехода на страницу портала (без специальных настроек), а часть – генерировало окно с предупреждением, если при подключении осуществлялся HTTPS, а не HTTP-redirect.
В данном тестовом сценарии предполагается, что заказчик принял решение изменить конфигурацию контроллера, полностью отключив HTTPS-redirect. Безусловно, это может приводить к отсутствию портала в случае, если браузер коммуницирует с использованием HTTPS (такой запрос не будет перенаправлен на портал, а просто будет сброшен контроллером, как и любой другой трафик до аутентификации).
Наконец, пришло время анализа третьей составляющей проблемы – ухудшения приема в зоне кафе. Чем характеризуется зона кафе в данном офисе? Согласно тестовому сценарию, в кафе наличествует открытая терраса. Также мы можем предположить наличие источника помех в диапазоне 2,4 ГГц – микроволновой печи, которая может использоваться для разогрева блюд. Для участков открытой территории с Wi-Fi-покрытием достаточно логично предположить использование диапазона 2,4 ГГц. Безусловно, в случае небольшой террасы покрытие (хотя бы частично) может обеспечиваться за счет точек доступа, установленных внутри помещения и использующих диапазон 5 ГГц. Это может объяснять тот факт, что часть клиентов не испытывает проблем при работе в кафе – они используют 5 ГГц, который не подвержен влиянию работы микроволновой печи.
Для подтверждения этой гипотезы необходимо провести радиообследование во время возникновения проблемы. Важно отметить, что результаты в разных диапазонах должны быть представлены раздельно.
Подводя итоги, отметим, что процесс поиска неисправностей в беспроводных сетях – это не обязательно рутинное занятие, однако он проходит гораздо эффективнее, если проводить его, придерживаясь определенного алгоритма. Использование разделения проблемы на подгруппы и дальнейшее уточнение приводит к достаточно быстрому пониманию проблемы, что, в свою очередь, помогает получить ее быстрое решение. А ведь именно это – правильно работающая сеть – и является конечной целью поиска неисправностей. ■
Отзывы читателей
