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.

Keeping the query packets close to the source reduces the chance that an isolated failure in another part of the network will restrict the convergence (query/reply) process.

В этом разделе показаны примеры того как управлять query range.

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

450px

• На рисунке выше маршрутизатор B предупреждает о пропаже сети 10.1.8.0 и отсылает запрос маршрутизаторам А, C, D и E.
• Эти маршрутизаторы, в свою очередь, посылают запросы своим соседям, ища маршрут к 10.1.8.0.
• Из-за избыточной топологии по каждому каналу проходят дубликаты (т.е. по нескольку раз) пакета-запроса.
• В результате, не только удаленные маршрутизаторы должны отвечать на запросы от региональных отделений, т.к. они - удалённые маршрутизаторы - продолжат поиск, отражая запросы обратно к другим региональным маршрутизаторам офиса, что делает процесс сходимости (конвергенции) еще более сложным.

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

• Предположим, что на схеме выше EIGRP метрика для Ethernet канала равна 1000, а для последовательных каналов 100000.
• Маршрутизатор B анонсирует подсеть 10.1.8.1/24 всем другим маршрутизаторам.
• Лучший маршрут к 10.1.8.0/24 для маршрутизатора А через канал Ethernet маршрутизатора В.
• Удалённые маршрутизаторы С, D и E имеют маршруты к 10.1.8.0/24 через последовательные каналы маршрутизатора В.
• Топологическая таблица для 10.1.8.0/24 для маршрутизаторов C,D и E выглядит так, как показано в таблице ниже*

Сосед	FD	AD
Router A	102000	2000
Router B	101000	1000

• Топологическая таблица маршрутизатора А для подсети 10.1.8.0/24:

Сосед	FD	AD
Router B	2000	1000
Router C	101,000	1000
Router D	101,000	1000
Router E	201,000	101,000

• Заметим, что маршрутизаторы С, D и E определили, что для достижения подсети 10.1.8.0/24 маршрутизатор B successor, а маршрутизатор А - FS (т.к. через А AD=2000, AD<FD через B).
• Также заметим, что у маршрутизатора A нет FS, т.к. ни один другой маршрут не удовлетворяет условию AD<FD.

Предположим, что маршрутизатор B теряет маршрут к сети 10.1.8.0/24:

• Маршрутизатор B расслает запросы всем свои четырём соседям.
• Когда маршрутизаторы на удалённых площадках получают этот запрос, они автоматически устанавливают в таблицы маршрутизации маршрут через маршрутизатор А (через B маршрут пропал) - резервный FS маршрут - и отвечают маршрутизатору B, что у них есть якобы отличный маршрут через маршрутизатор А, а плохой маршрут через В удаляют из своих топологических таблиц.
• Маршрутизатор B получает ответы от трёх удалённых маршрутизаторов, но должен ждёт ответа от маршрутизатора А.
• Так как у А только successor маршрут и нет ни одного FS, ответ маршрутизатору В занимает некоторое время: А создаёт запрос и рассылает его маршрутизаторам С, D и E, так как знает из своей топологической таблицы, что каждый из них имеет маршрут к пропавшей сети.
• А маршрутизатор В всё ещё ожидает ответа от А.
• Когда удалённые маршрутизаторы получают запрос от А, они понимают, что их маршруты через А не так хороши, как им казалось. Поэтому они ищут в своих топологических таблицах альтернативные маршруты. На этот раз альтернативных путей там нет, так как маршрутизатор В уже оповестил их, что у него нет маршрута к 10.1.8.0/24.
• Удалённым маршрутизаторам С, D и E нечем ответить на запрос от А, поэтому они генерируют запросы и рассылают их своим соседям. Они не шлют запросы А, так как изначальный запрос пришёл от него (правило расщепления горизонта), поэтому остаётся только слать их маршрутизатору В.
• Помним, что маршрутизатор В всё ещё ожидает ответа от А!
• Маршрутизатор B получает запросы от удалённых маршрутизаторов, но не может им ответить, так как ещё не получил ответ от маршрутизатора А.
• Маршрутизатор А с другой стороны ждёт ответ от любого из С, D или E.
• А маршрутизаторы C, D и E ждут ответа от B на свои запросы.
• Маршрутизатор B переходит первым в состояние SIA потому что он первым отправил запрос и его таймер раньше, чем у других.
• Маршрутизатор B сбрасывает соседство с маршрутизатором А.
• Как только отношения сброшены (goes down), маршрутизатор В может немедленно ответить маршрутизаторам C, D и E сообщив им, что он (маршрутизатор B) не имеет маршрута к 10.1.8.0/24.
• Маршрутизаторы C, D и E затем могут ответить маршрутизатору А, что у них нет маршрута.
• Только после сброса, отношения между А и В восстанавливаются. Маршрутизатор B не передаёт (does not pass) сеть 10.1.8.0/24 маршрутизатору А, потому что её больше не существует.
• Маршрутизатор А узнаёт (learns), что удалённые маршрутизаторы не владеют маршрутом к 10.1.8.0/24, поэтому он удаляет эту сеть из своей топологической таблицы.

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

Если удалённые площадки не подразумевается использовать как транзитные транзитные узлы между региональными площадками, то региональные маршрутизаторы можно настроить для анонсирования удалённым площадкам только маршрута по умолчанию. А удалённые маршрутизаторы настроить для анонсирования региональным только напрямую подключённые stub сети. Это снизит сложность (complexity) топологических таблиц и размер таблиц маршрутизации.

Следующая часть описывает другие решения для ограничения EIGRP query range.

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