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

• Several solutions exist to optimize the query propagation process and to limit the amount of unnecessary EIGRP load on the links, including:
  • Summarization
  • Redistribution
  • EIGRP stub routing feature.

---

Будучи усовершенствованным дистанционно-векторным протоколом, 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

• If a router does not receive a reply to all the outstanding queries within default 3 minutes (180 seconds), the route goes into Stuck-in-Active (SIA) state.
• Common SIA reasons:
  • A router is too busy to answer the query.
  • A router cannot allocate the memory to process the query.
  • The circuit between the two routers is not reliable.
  • The router has unidirectional links.
• SIA solutions:
  • Redesign the network to limit the query range by route summarization and the ip summary-address eigrp command.
  • Сonfigure the remote routers as stub EIGRP routers.

---

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

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

Внимание!
Вы можете изменить таймер активного состояния командой в режиме конфигурирования 
timers active-time [time-limit | disabled]. time-limit указывается в минутах.

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

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

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

Неверным подходом для сокращения шансов маршрута перейти в состояние SIA является использование нескольких автономных систем для ограничения распространения запросов. Многие сети спроектированы с использованием нескольких AS (по подобию зон в OSPF), которые обмениваются маршрутами через редистрибуцию. Хотя этот подход и меняет поведение сети, он не всегда позволяет достичь ожидаемого результата. Если запрос достиг границы автономной системы (где маршруты перераспределяются (redistribution) в другую AS), the original query is answered. Однако, пограничный маршрутизатор затем инициирует новый запрос в другой автономной системе. Таким образом, процесс запросов продолжается в другой автономной системе(он не остановлен), где маршрут может потенциально перейти в SIA.

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

Оригинал: Another misconception about autonomous system boundaries is that implementing multiple autonomous systems protects one AS from route flaps in another AS. However, if routes are redistributed between AS, route transitions form one AS are detected in another.

Предотвращение SIA

SIA-Query и SIA-Reply - это два новых дополнения к тройке TLV (Type, Length, Value - тип, длина, значение) в заголовке EIGRP-пакета. Эти поля формируются автоматически без каких либо настроек, начиная с IOS 12.1(5). Данная функция, называемая расширением active-процесса (active process enhancement feature), включена в EIGRP для мониторинга поиска преемника и гарантии, что сосед всё еще доступен. Уменьшение количества непреднамеренных сбрасываний соседских отношений приводит к увеличению надежности сети.

450px

Левая часть рисунка демонстрирует поведение сети без расширения active-процесса. Маршрутизатор A посылает запрос о сети 10.1.1.0/24 соседу B, когда теряет соединение с ней. Тот, не найдя информации об этой сети у себя, передает запрос маршрутизатору C. Если существуют проблемы соединения между B и C, reply-пакет от С к B может быть задержан или утерян. Маршрутизатор A не может увидеть, наличие проблем на следующем соединении и предполагает, что отсутствие ответа на запрос указывает на проблему в маршрутизаторе B. После истечения трех минут, соседские отношения с B сбрасываются вместе с маршрутами, изученными через В.

На правой части рисунка демонстрируется использование расширения active-процесса. Маршрутизатор A запрашивает B (SIA-Query) с половиной таймера активности (1,5 минуты по умолчанию) о статусе маршрутизатора. B отвечает (SIA-Reply), что он занят поиском маршрута к потерянной сети. Получив пакет SIA-Reply, маршрутизатор A подтверждает статус B и не сбрасывает соседские отношения.

Между тем, B посылает до трех SIA-Query маршрутизатору C. Если тот не отвечает, B сбрасывает соседские отношения с С. Маршрутизатор B объявляет A о недоступности запрашиваемой сети. A и B удаляют active-запись из своих таблиц топологии. Соседские отношения между A и B остаются нетронутыми.

EIGRP Query Range

Ограничение объёма распространяемых через сеть запросов (query range), также известное как query scoping, помогает сократить количество случаев SIA.

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 />