Optimizing EIGRP Implementations

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

Масштабируемость EIGRP в больших сетях

Работа (operation) одной большой flat<ref name="flat">Flat network , </ref> EIGRP is normally not scalable. Некоторые issues, которые необходимо рассмотреть:

• Большие таблицы маршрутизации, которые должны быть обработаны.
• Из-за больших таблиц (маршрутизации, соседей) большие требования к памяти.
• Большие требования к полосе пропускания из-за большого числа обновлений маршрутизации, отправки множества запросов и ответов в пределах домена EIGRP (учитывая наличие медленных каналов и некоторого числа ошибок передачи).

Сетевые администраторы должны понимать способы конструирования и настройки сетей EIGRP для развертывания эффективных масштабируемых сетей.

Некоторые из многих факторов, влияющих на масштабируемость:

• Объем информации о маршрутах (amount of information exchanged between neighbor). Если трафик маршрутизации между EIGRP-соседями потребляет полосу канала выше, чем необходимо для правильного функционирования маршрутизации, то маршрутизаторы медленнее реагируют на изменения в сети.
• Количество маршрутизаторов. Потребление ресурсов протоколом EIGRP при изменениях топологии сети прямо пропорционально количеству маршрутизаторов, которые должны изучить эти изменения.
• Глубина топологии (the topology's depth). Глубина топологии может влиять на время сходимости. Глубина топологии - это число hop-ов, через которые должна пройти информация для того, чтобы достигнуть все маршрутизаторы.

Например, multinational network без суммирования маршрутов, имею большую глубину (depth), что увеличивает время конвергенции.

Трехуровневая структура сети (см. Сетевые_модели) является наиболее рекомендуемой для любого окружения с IP-маршрутизацией. Между любыми двумя маршрутизаторами в сети должно быть не более семи hop-ов. Иначе время конвергенции при изменениях в сети вырастет из-за задержек распространения информации.

• Количество альтернативных маршрутов в сети. Сеть должна предоставлять альтернативные маршруты во избежание появления точек отказа. Однако, слишком большое количество резервных маршрутов может привести к проблемам сходимости, т.к. EIGRP использует запросы для обнаружения всех возможных маршрутов (вместо пропавших). Эта сложность создает идеальные условия для перехода маршрута в режим SIA (stuck in active - застрял в активном режиме) - ждущего ответы на запросы, отправленные им через множество альтернативных путей.

При внедрении протокола маршрутизации EIGRP должны быть решены некоторые проектировочные проблемы. Три основных:

• Размер топологической и таблицы маршрутизации, на которые влияет число соседей.
• Число изменений в сети.
• Загрузка WAN-каналов протоколом EIGRP.

Эти три главных фактора диктуют дизайн EIGRP, требуя ввода границ распространения запросов (использованием суммирования, редистрибуции и т.д.). Без определения границ, запросы будут распространяться через весь домен EIGRP, и очень скоро все маршрутизаторы будут вовлечены в расчёты DUAL, в результате чего вырастет использование п/п и CPU. Частые расчёты будут влиять на все таблицы, используемые маршрутизаторами, включая таблицы EIGRP и кэш процесса пренаправления (caches built during the forwarding process).

EIGRP-запросы и Stuck-in-Active

Будучи усовершенствованным дистанционно-векторным протоколом, EIGRP полагается на своих соседей, предоставляющих информацию о маршрутизации. Если маршрутизатор теряет маршрут и не имеет ни одного возможного преемника, он ищет альтернативные маршруты. Этот процесс называется переходом маршрута в активное состояние (going active). Маршрутизатор рассылает query-пакеты всем соседям по всем интерфейсам, кроме интерфейса, который использовался для достижения предыдущего successor (split horizont - расщепление горизонта). Если маршрутизатор имеет альтернативный маршрут, он отвечает на запрос и не распространяет запрос дальше. Ответ содержит альтернативный маршрут. Если сосед не знает про альтернативный маршрут, он рассылает запросы своим соседям. Таким образом запросы распространяются по сети, образуя и расширяя дерево запросов. Когда маршрутизатор отвечает на запрос, он останавливает рассылку запросов в свои сегменты сети, однако запросы могут продолжать распространяться другими маршрутизаторами, которые пытаются найти альтернативные маршруты.

450px

На рисунке показана сеть, в которой потеря всего одного маршрута приводит к появлению огромного количества запросов. R1 потерял маршрут к 10.1.1.0, он рассылает запросы всем соседям через все интерфейсы кроме интерфейса successor'a (split-horizon). Запросы передаются R2, тот в свою очередь рассылает запросы своим соседям, так как у него инет информации о потерявшемся маршруте, и т.д. Каждый запрос требует ответа от соседа, количество трафика EIGRP возрастает. Никакого толку от запросов нет, потому что в сети нет альтернативного маршрута до 10.1.1.0.

Для оптимизации распространения запросов и ограничения ненужной загрузки каналов протоколом EIGRP, существует несколько подходов, включая суммирование, редистрибуцию и использование функции EIGRP-stub.

SIA соединения в EIGRP

EIGRP использует надежный многоадресный способ доставки для поиска альтернативных маршрутов. Поэтому необходимо, чтобы EIGRP получил ответ на каждый посланный в сеть запрос.

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

SIA-состояния являются одними из самых сложных проблем в EIGRP-сетях. Если запись переходит в режим SIA, маршрутизатор сбрасывает соседские отношения с маршрутизаторами, от которых не был получен ответ. Эта ситуация приводит к тому, что маршрутизатор переводит в активное состояние все записи, содержащие этих соседей, и заново объявляет все маршруты, изученные через них.

Наиболее общие причины появления SIA-записей:

• Маршрутизатор слишком занят, чтобы ответить на запрос, из-за высокой загрузки CPU и проблем с ОЗУ.
• Неисправное соединение между двумя маршрутизаторами. Некоторые пакеты могут быть потеряны.
• Неисправное соединение, вызывающее одностороннюю связь между маршрутизаторами (unidirectional link).
• Большое количество альтернативных маршрутов, создающих проблемы сходимости сети.

Graceful Shutdown

Gracefull Shutdown (дословно: изящное выключение), использующее goodbay-сообщения, призвано улучшить сходимость EIGRP-сети. Gracefull shutdown предотвращает потерю пакетов при выключении маршрутизатора.

На рисунке показано, как маршрутизатор A использует B в качестве преемника для нескольких маршрутов. Маршрутизатор С - является возможным преемником для тех же маршрутов. В обычном режиме B не сообщает A о выключении EIGRP процесса. A вынужден ждать пока истечет hold-таймер, прежде чем он обнаружит изменения и отреагирует на них. Пакеты, посланные в этот период времени будут утеряны.

При использовании gracefull shutdown, маршрутизатор широковещательно рассылает goodbay-сообщения перед выключением EIGRP-процесса, информируя соседей о предстоящем изменении топологии. Эта функция позволяет EIGRP-соседям более эффективно синхронизироваться и пересмотреть соседские отношения.

Goodbay-сообщения поддерживаются IOS 12.3(2), 12.3(3)B, 12.3(2)T и более поздними. Goodbay-сообщение встраивается в hello-пакет. EIGRP посылает goodbay-сообщение устанавливая значения весовых коэффициентов K1 - K5 равными 255. При получении goodbay-сообщения маршрутизатор выводит следующее:

R1#
*Mar  1 00:02:43.331: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.0.2
(FastEthernet0/0) is down: Interface Goodbye received

Маршрутизаторы Cisco, не поддерживающие goodbay-сообщения, не принимают во внимание значения коэффициентов K1-K5=255. В этом случае выводится сообщение о неправильном значении весовых коэффициентов (K-value mismatch). Но это не нарушает сетевые операции. Маршрутизатор закрывает сессию по истечении hold-таймера. Соседские отношения нормально возобновляются после запуска EIGRP на отправителе.

Примечания

<references />