Сбои в крупных сетях могут потребовать от администраторов максимального напряжения усилий, ведь зачастую ошибки невозможно выявить традиционными методами — в этом случае понадобятся все знания и опыт в области маршрутизации. Однако для поиска неисправностей вручную, как правило, не хватает времени, поэтому нужны эффективные методы и инструменты, позволяющие быстро локализовать проблемы и устранить их.
Ошибки в сети могут иметь различные причины — будь то полный отказ маршрутизатора, сбой на выделенной линии или организация маршрута в неверном направлении. Все эти неполадки объединяет одно: неизбежно приходится нести большие финансовые потери и тратить много времени на устранение сбоя, ведь требуется не только найти ошибку, но и локализовать ее и распознать причину.
ПРИЧИНЫ ОШИБОК
При полном сбое маршрутизатора причина неполадок, как правило, обнаруживается быстро. Выявить нефункционирующую выделенную линию для большинства администраторов не составляет проблем, к тому же обычно имеются резервные системы или линии. Но что делать, если, несмотря на наличие резервного пути и вопреки заранее предпринятым мерам, какие-то системы внезапно становятся недостижимыми?
В такой момент требуется быстрая реакция. Вначале администратор должен попытаться локализовать проблему. Какие системы пострадали? Каким образом с ними можно связаться? Все ли компоненты на этом пути еще доступны? С помощью утилит Traceroute, Ping и различных команд просмотра (Show) ответы на подобные вопросы находятся быстро. Однако если все маршрутизаторы работают и доступны, система мониторинга не обнаруживает никаких сбоев, а сеть, тем не менее, не функционирует надлежащим образом, возникает потребность в глубоких знаниях и опыте в сфере маршрутизации, а также в хорошем обзоре сети.
Многие ошибки не очевидны на первый взгляд. При тех размерах и сложности, которые характерны для современных сетей, порой трудно или даже невозможно получить и сохранить полный контроль за сетью. В такой ситуации могут оказаться полезными планы сети, но далеко не всегда на линии в реальности происходит то, что задокументировано и описано. Лишь анализ позволяет выяснить реальное состояние дел, однако в сложных инфраструктурах задача может оказаться трудно-разрешимой. К тому же, информация о маршрутизации не всегда верна. Многие ошибки становятся заметны только в том случае, если из-за отказа главной системы активируется резервный сценарий. Внезапно исчезают маршруты, поскольку резервная система не распределяет их так, как предусматривалось. Неправильная конфигурация аварийного маршрута выявляется поздно: когда в нем возникает необходимость. А подобные ошибки желательно обнаружить заранее.
Кроме того, как раз преимущества современных протоколов маршрутизации, такие как избыточность, динамическая маршрутизация и балансирование нагрузки, таят в себе многочисленные риски. Ошибочная конфигурация нередко влияет на поведение всей сети. Неправильный ввод (False Injection) у одноранговых партнеров (Peering Partner) может распространиться по всей сети и привести к недоступности целых сетевых участков, если, к примеру, партнер слепо воспользовался ошибочной информацией о маршрутизации. Нередко встречаются маршрутные петли (Routing Loops): в таком случае из-за неправильной настройки маршрутизатор отправляет пакеты в тот сегмент, через который они уже проходили. Часто причиной неполадок становится асимметричная маршрутизация, когда прямой и обратный пути различны, как это происходит, к примеру, при наличии статичных маршрутов, которые когда-то вводились в данную систему для безотлагательного решения возникшей проблемы (см. Рисунок 1). Такое «латание дыр» на пострадавших системах при определенных условиях не распознается как причина и приводит к тупиковым ситуациям (Dead Ends): маршруты ссылаются на систему, не знающую путь к цели, и в результате пакеты никогда не достигнут пункта назначения.
Таким образом, причин возникновения ошибок при маршрутизации множество. Однако способ их выявления всегда одинаков: администратор сравнивает фактическое состояние сети с ожидаемым, ищет различия и выясняет, при каких обстоятельствах они могли возникнуть. В большинстве случаев это осуществляется вручную с помощью анализа идентификационного номера вызывающей линии (Calling Line Identification Number, CLI). Специалист по маршрутизации самостоятельно или с помощью сценариев регистрируется на отдельных устройствах маршрутизации и проверяет информацию о маршрутах и конфигурацию самих устройств, пытаясь выявить причины ошибок и несоответствия. Однако такой способ диагнос-тики ошибок может оказаться ненадежным, к примеру, если нормальная работа сети внезапно восстановится. Это возможно, если основная линия снова окажется доступной и резервный сценарий деактивируется. Однако прекращать поиск ошибки нельзя, иначе при следующем обращении к резервному сценарию она проявится снова.
Для поиска причины администратор может сделать моментальный снимок с помощью инструмента для анализа маршрутов. Специальные программные инструменты собирают всю информацию, доступную на всех устройствах маршрутизации, и делают ее снимки. Это происходит регулярно и параллельно на всех обследуемых устройствах. Инструменты проверяют данные о маршрутизации на предмет возможных ошибок, автоматически выполняя те же самые шаги, которые предпринял бы специалист. После анализа, занимающего всего несколько секунд, программное обеспечение отображает возможные источники ошибок при маршрутизации. Администратору достаточно лишь изучить их, чтобы быстро локализовать проблему.
Кроме того, благодаря сравнению двух снимков, можно понять, какие пути изменились и почему возникла ошибка. Такие инструменты распознают даже промежуточные изменения в настройке отдельных устройств и сразу же их отображают. Асимметричные маршрутные пути могут быть нужны, но если их число меняется, то в сети что-то произошло, и это необходимо проверить. Иначе говоря, всегда действует принцип сравнения фактического состояния с ожидаемым.
САМЫЙ НАДЕЖНЫЙ СПОСОБ — АНАЛИЗ CLI
Многие инструменты управления сетью используют SNMP для сбора информации с устройств, что таит в себе риск ненадежной передачи (по UDP) и высокой нагрузки на сеть. Кроме того, многие производители устройств не сочли нужным осуществить полное и правильное внедрение SNMP, поэтому опасность ошибочной интерпретации довольно велика. Кроме того, рискованно оценивать, к примеру, только один протокол маршрутизации, поскольку он не учитывает не распределенные им маршруты.
На практике сеансы Border Gateway Protocol (BGP) зачастую настраиваются с полной маршрутизацией (Full Routing). При более чем одном сеансе и превышении 200 тыс. записей случается переполнение памяти маршрутизатора, особенно если после сбоя один из сеансов BGP организуется заново. При этом — по сравнению с обычным режимом эксплуатации — может возникнуть кратковременная потребность в большем объеме памяти, поскольку «плохие» маршруты удаляются лишь после обнаружения более предпочтительных. Возникающая при этом ошибка памяти способна вызвать перезагрузку маршрутизатора.
Поэтому лучше пойти традиционным путем CLI и детально проанализировать маршрутные таблицы маршрутизаторов.
Однако собрать в сети все таблицы и заново рассчитать все пути, чтобы обнаружить специфические проблемы маршрутизации, невозможно ни вручную, ни с помощью сценариев. Для этого нужны специальные инструменты для анализа маршрутов, к примеру, Niams от T&A Systeme (см. Таблицу 1).
Тилль Бокенхаймер — руководитель T&A Systeme.