Крупные корпоративные сети, а в последнее время и все большее число операторских сетей базируются на протоколе IP. Без специальных протоколов маршрутизации — OSPF, EIGRP, IS-IS или BGP4 — эксплуатация таких структур, вплоть до «Всемирной паутины», была бы немыслимой. Однако эти методы маршрутизации порождают и проблемы, превращаясь в источники ошибок, от которых, впрочем, можно избавиться при помощи специальных инструментов диагностики и управления.

Маршрутизаторы отвечают за конфигурацию сетей и подсетей и за максимально возможную интеллектуальную коммутацию пакетов. Устройства, предназначенные для крупных сетей, могут, к примеру, независимо определить достижимость имеющихся сетей и самостоятельно решить, следует ли отправлять пакет данных, а при отказе либо недоступности сетевых соединений или сегментов они информируют об этом соседние системы.

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

Поиск ошибок при таких неполадках может оказаться весьма непростым. Первое, что замечает администратор, — повышение активности протоколов маршрутизации: обновление маршрутизации, изменение префикса, потеря связи с соседним устройством, а также избыток специальных типов сообщений и событий, которыми обмениваются маршрутизаторы. Несмотря на неоспоримые преимущества современных протоколов контроля состояния канала, они содержат и скрытые опасности — в особенности для крупных сетей IP. По статистике 30% отказов случаются на первом и втором уровнях модели OSI, а на третий уровень приходится больше половины. При этом протоколы маршрутизации играют решающую роль.

ИСТОЧНИКИ ОШИБОК

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

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

Петлевые структуры в рамках протоколов маршрутизации также являются потенциальными причинами сбоев. Часто они возникают в результате рекурсивного построения маршрутов в процессе выбора обходных путей, когда пограничный межсетевой протокол (Border Gateway Protocol, BGP) в случае ошибки предлагает запасной маршрут, который через промежуточный узел снова ведет на исходный маршрутизатор, потому что для транзитной станции этот путь данных является предпочтительным. Подобные петлевые структуры могут нарушить работу всей сети или сетевого сегмента, причем их трудно предсказать и отследить. Во время тестирования соединения необходимо автоматически проверять и запасные маршруты, поскольку подобное часто случается в сетях с компонентами от различных производителей.

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

ТРАДИЦИОННЫЕ СПОСОБЫ ДИАГНОСТИКИ

Распознавание и анализ ошибок являются критическими факторами, особенно в крупных сетях. Час простоя при соответствующем количестве затронутых пользователей может иметь катастрофические последствия. Большая часть времени в таких случаях уходит на изоляцию и локализацию причин неполадок.

Так, диагностика с консоли (Console Line Interface, CLI) предлагает прагматичный, хотя и кажущийся немного архаичным метод поиска ошибок: посредством консоли telnet эксперт по IP регулярно заходит сразу на несколько центральных или пострадавших маршрутизаторов и пытается прояснить ситуацию путем сравнения конфигураций. Отладочные инструменты помогают выявить и другие взаимосвязи. В основном речь идет о ручной проверке с консоли. Поэтому в сложной сети, к примеру с сотней распределенных маршрутизаторов ядра, этот метод мало перспективен.

Анализ записанных пакетов данных маршрутизации требует экспертных знаний: если специалист по сетям разобрался с ситуацией и знает, какие узлы затронула проблема, он записывает трафик через них при помощи зонда и протокольного анализатора. Это можно сделать либо через зеркальный порт маршрутизатора, либо через отвод для анализа, который при помощи разветвителя передает трафик, не вмешиваясь в него, на отводной порт. Затем при помощи протокольного декодера можно проанализировать аномалии и неточности внутри данных маршрутизации, попытаться выявить и исправить ошибки. Однако запись обмена между маршрутизаторами означает, что за короткое время анализатор получает тысячи пакетов маршрутизации, а декодер протокола должен мгновенно определить причину и ее последствия. Кроме того, запись данных технически накладна, поскольку связи между данными указывают во многих направлениях. Конфигурация зеркального порта и подключение отвода требуют немалого опыта.

Одной из простых на первый взгляд возможностей для поиска ошибок является использование имеющихся систем управления, поскольку они, как правило, способны распознавать и визуализировать соединения третьего уровня. Благодаря опциональным расширениям базы управляющей информации (Managed Information Base, MIB) — к примеру OSPF-MIB/RFC2370 и BGP-MIB/ RFC1657 — системы адаптируют таким образом, чтобы они собирали важные параметры протоколов маршрутизации и реконструировали ситуацию в сети IP на основании деталей MIB. Из этих данных математически выводятся ошибочные ситуации и устанавливаются взаимозависимости.

Проблема в том, что анализируется не фактический трафик третьего уровня, а математически оцениваются сообщения маршрутизатора. Кроме того, для сетевого взаимодействия на третьем уровне фатальные последствия могут иметь события второго уровня. В результате в крупных сетях возникает опасность, что в случае ошибки сообщения о серьезных событиях могут не дойти до администратора. К тому же опрос SNMP происходит не в реальном времени, поскольку механизм централизованного опроса последовательно запрашивает данные из затронутых систем. Между тем автономность и собственная динамика интеллектуальных протоколов маршрутизации часто требуют одновременного и быстрого анализа для выявления взаимозависимостей и причин ошибочной ситуации.

АНАЛИЗ МАРШРУТИЗАЦИИ IP

Компании и операторы используют описанные методы в смешанной форме — все они приносят свою специфическую пользу. Вместе с тем, уже появились технологии, предназначенные для анализа поведения маршрутизации IP в крупных сетях. Одна из них разработана американским предприятием Packet Design. Этот метод базируется на специализированном оборудовании, инсталлируемом в сети и в реальном времени собирающем всю информацию о маршрутизации между отдельными доменами маршрутизации (автономными системами), логическими туннелями маршрутизации (смежностями) и рефлекторами маршрутов, но не принимающем активного участия в протокольном трафике (см. Рисунок 1). Аналитический механизм интерпретирует записанные данные в реальном времени и предоставляет пользователю реальную картину структуры третьего уровня. На Рисунке 2 изображены структуры третьего уровня одного из американских университетов. В зависимости от функции или поддерживаемых протоколов маршрутизации маршрутизаторы обозначены различными цветами и контурами. Из рисунка видно, как отказ двух маршрутизаторов влияет на сеть третьего уровня: затронутые системы отмечены красным цветом, запасные соединения между двумя любыми конечными точками — желтым.

Рисунок 1. Интеграция оборудования для анализа маршрутизации IP в сетевую инфраструктуру.

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

Рисунок 2. Визуализация реальных путей соединений IP. Источник: Packet Design

Кроме того, эта технология пригодна в качестве вспомогательного средства при моделировании, поскольку на основании записанных данных нетрудно восстановить ситуацию в сети, изменить конфигурацию маршрутизаторов и проверить влияние на другие узлы. Изменения выражаются в графическом виде (см. Рисунок 3). Перед вводом в эксплуатацию подобные действия помогут распознать и предотвратить возможные отказы, заметно снизив в итоге их количество.

Рисунок 3. Аналогично видеозаписи, технология позволяет просматривать историю маршрутизации и обрабатывать конфигурацию. Изменения отображаются в форме топологической графики. Источник: Packet Design.

Поскольку эта технология концентрируется исключительно на маршрутизации IP, она подходит в качестве дополнения к существующим системам управления сетями, которые, как правило, ограничиваются вторым уровнем.

ПЕРСПЕКТИВЫ

Рассмотренная нами технология может быть распространена на многопротокольную коммутацию меток (Multi-Protocol Label Switching, MPLS) и сегменты виртуальных частных локальных сетей (Virtual Private LAN Segment, VPLS). Специализированное оборудование анализа маршрутизации IP применимо и для централизованного администрирования во внешних сетях независимых доменов маршрутизации, которые часто конфигурируются посредством протоколов маршрутизации EIGRP, IS-IS или OSPF. И поскольку это смежное оборудование предназначено для сбора информации о маршрутизации, с его помощью администратор сумеет управлять маршрутизаторами во внешних сетях.

Ули Веллер — соучредитель компании Magellan Netzwerke, ответственный за сетевую телеметрию. С ним можно связаться по адресу: db@lanline.awi.de.

? AWi Verlag