Optimizing EIGRP Implementations

Материал из Cisco CCNP
Версия от 12:33, 3 мая 2014; imported>Artem (→‎Limiting Query Range Using a Stub)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к навигации Перейти к поиску

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.

Ограничение EIGRP Query Range

  • Попытайтесь определить количество информации, необходимое для правильной маршрутизации трафика пользователя к корректиному destination. Количество информации, необходимое удалённым маршрутизаторам, требующее некоторых бизнес-решений для оценки того, что может являться подходящим. Зачастую сетевой администратор должен анализировать количество информации, прошедшее через удалённые маршрутизаторы, емкость и полосу пропускания, которой он может управлять.
  • В Правильно разработанной сети, каждая удалённая площадка будет иметь резервирование WAN-каналов к каждой отдельной площадке распределения (to separate distribution sites). Если обе площадки распределения передают удалённым площадкам маршрут по умолчанию, то the remote sites load balance to all networks behind the distribution site routers. Это означает максимальное использование полосы пропускания и меньшее использование памяти и CPU, т.е. требуется меньшие (smaller, наверно по возможностям) и менее дорогие маршрутизаторы.
  • Если удалённые площадки могут получать все маршруты, то маршрутизатор может выбрать наилучший маршрут для любой сети. Однако, в зависимости от числа маршрутов в межсетевом комплексе (internetwork) и пропускной способности каналов между удалённой площадкой и площадками распределения, данный подход может потребовать более широких каналов и более мощных маршрутизаторов, чтобы справиться с дополнительными накладными расходами.

После того, как вы определили минимальные требования к маршрутизации, вы можете сделать EIGRP более масштабируемым, используя такие его опции как:

  • Суммирование маршрутов (команда на интерфейсе ip summary-address eigrp)
  • Настройка удалённых маршрутизаторов как stub-маршрутизаторов.

Другие методы ограничения query range включают фильтрацию маршрутов и фильтрацию пакетов на интерфейсе. Например, если фильтруются определённые обновления протокола EIGRP, и если маршрутизатор получает запрос о таких отфильтрованных (блокированных) сетях, он сообщает (indicates), что сеть не доступна, и дальше не распространяет запрос (query).

Limiting EIGRP Query Range with Summarization

  • Суммирование минимизирует размер таблиц маршрутизации => меньше потребление памяти и CPU, и меньше требуется полосы пропускания.
  • Суммирование сокращает шансы сети стать SIA, because it reduces the number of routers the see each query. Therefore the chances of a query encountering issues is reduced.
Внимание! 
A router extends the query about a network only if it has an exact match in the routing table.
450px

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

  • Плохой дизайн делает суммирование сложной задачей.
  • Суммирование в ручную маршрутов по возможности для поддержки иерархического дизайна сети.
  • Чем больше суммируем сетей, тем меньше запросов будет рассылаться. Что в конечном счёте снижает число SIA ошибок.
450px
  • Эта сеть спроектирована лучше, потому что адреса подсетей из классовых сетей, применяются в пределах одного облака, позволяя применять суммирование маршрутов (команда ip summary-address eigrp) и отдавать их ядру.
  • В качестве дополнительного преимущества, суммирование маршрутов действует как граница (act as a boundary) для запросов, генерируемых при изменении топологии.
450px

На рисунке показана иллюстрация того, как суммирование в EIGRP может ограничить query range.

  • Маршрутизатор B посылает суммированный маршрут к сети 172.30.0.0/16 маршрутизатору А.
  • Когда сеть 172.30.1.0/24 пропадает, маршрутизатор B посылает запрос А, спрашивая его об альтернативном маршруте к 172.30.1.0/24.
  • Так как маршрутизатор А получил только суммированный маршрут 172.30.0.0/16, сети 172.30.1.0/24 в его таблице нет. Он отвечает на запрос сообщением “network 172.30.1.0/24 unreachabel” и дальше query-пакет не распространяется.
450px

На рисунке выше показана та же сеть, что была в разделе EIGRP Query Range, но с одним отличием - в этой сети используется суммирование маршрутов. На выходных интерфейсах маршрутизаторов А и В введена команда ip summary-address eigrp, и оба маршрутизатора теперь анонсируют суммированный маршрут к 10.0.0.0/8 для маршрутизаторов C, D и E. Сеть 10.1.8.0/24 удалённым маршрутизаторам не анонсируется. В результате С, D и E не распространяют дальше (т.е. обратно региональным маршрутизаторам) запрос о 10.1.8.0/24. Конвергентный трафик (запросы и ответы) сокращается

  • На выходных интерфейсах маршрутизаторов А и В введена команда ip summary-address eigrp, и оба маршрутизатора теперь анонсируют суммированный маршрут к 10.0.0.0/8 для маршрутизаторов C, D и E.
  • Сеть 10.1.8.0/24 удалённым маршрутизаторам не анонсируется.
  • Когда пропадает 10.1.8.0/24, маршрутизатор А и В рассылают запросы маршрутизаторам C, D и E, которые сразу же отвечают А и В, что это направление (destination) недоступно (в таблицах маршрутизации удалённых маршрутизаторов попросту нет такого маршрута). Маршрутизаторы на удалённых площадках не распространяют запросы обратно А и В, препятствуя их переходу в состояние SIA (те ждут пока процесс запроса не получит всех ответов).

Limiting Query Range Using a Stub

Функция stub-маршрутизации в EIGRP:

  • улучшает стабильность сети;
  • сокращает использование ресурсов;
  • Опращает конфигурацию удалённых (spoke) маршрутизаторов.
  • Stub-маршрутизации обычно используется в топологии hub-and-spoke.
  • Stub-маршрутизатор рассылает специальный peer information packet всем своим соседям, чтобы оповестить их о том, что он stub.
  • Любой сосед, получивший пакет, сообщающий о stub-статусе смежного с ним маршрутизатора, не запросит никаких маршрутов у stub-маршрутизатора.

Stub routers are not queried and instead, hub routers connected to the stub router answer the query on behalf of the stub router.

  • Только удалённые маршрутизаторы могут быть настроены как stub-маршрутизаторы. Т.е. соседом stub-маршрутизатора должен быть только hub-маршрутизатор.
  • Обычно stub-маршрутизация используется в топологии hub-and-spoke.
  • В hub-and-spoke топологии удалённый маршрутизатор пересылает весь нелокальный трафик центральному маршрутизатору. Удалённому маршрутизатору незачем хранить у себя полную таблицу маршрутизации. Обычно, центральным маршрутизаторам необходимо анонсировать удалённым маршрутизаторам только маршрут по умолчанию.
  • Никакого преимущества от владения удалёнными маршрутизаторами полной таблицей маршрутизации нет, т.к. всё всё равно проходит через центральные маршрутизатор. С другой стороны, полные таблицы на spoke-маршрутизаторах только увеличивают потребление памяти.
  • Суммирование маршрутов и их фильтрация могут также быть использованы на spoke-маршрутизаторах для сокращения использования п/п и памяти. Трафик от центрального маршрутизатора не должен использовать удалённые маршрутизаторы в качестве транзитного пути. Обычно, полоса пропускания канала от hub до spoke имеет существенно меньшую полосу пропускания, чем соединение в ядре. Транзитный трафик приводит к излишней перегрузке удалённых маршрутизаторов.
  • Чтобы избежать этого stub-маршрутизация в EIGRP позволяет ограничить распространение маршрутов spoke одного hub-маршрутизатора обратно другим hub-маршрутизаторам.
    • Например, вернёмся к картинке выше. Если удалённый маршрутизатор получает маршруты от центрального маршрутизатора А, то он не анонсирует их в обратном направлении hub-маршрутизатору В. Поэтому hub-маршрутизаторы и не используют spoke-и как транзитные пути.
  • EIGRP Stub
    • Только удалённые маршрутизаторы настраиваются как stub'ы. Данная функция не препятствует анонсированию маршрутов удалённому маршрутизатору.
    • Stub-маршрутизатор рассылает всем соседям специальный информационный пакет, сообщающий им о своём stub-статусе. Каждый маршрутизатор, получивший такой информационный пакет, перестает посылать запросы stub-маршрутизатору. Вместо этого, hub-маршрутизатор, соединенный со stub-маршрутизатором, отвечает на запросы от его имени. Stub-маршрутизация не предотвращает объявление маршрутов spoke-маршрутизатору.
  • Информацию о том, что маршрутизатор в режиме stub настроен, переносят hello-пакеты.
    • Любой сосед, получивший такой информационный пакет, сообщающий о stub-статусе соседа, перестаёт запрашивать любые маршруты от него. Therefore, a router that has a stub peer does not query the peer.
  • Когда stub-маршрутизация включена на удалённых конфигурациях с двойной привязкой (о линии передачи данных, подключенной как к основному, так и к резервному коммутационному устройству), вам не нужно настраивать фильтрацию на удалённых маршрутизаторах, чтобы препятствовать использованию spoke'ов как транзитных узлов для трафика hub'ов.
Внимание!
Stub-маршрутизация EIGRP должна использоваться только на stub-маршрутизаторах. Stub-маршрутизатор - маршрутизатор,
подключённый к ядру сети или hub-уровню, и через который не должен проходить транзитный трафик уровня ядра. Соседом
stub-маршрутизатора должен быть только hub-маршрутизатор. Нежелательное поведение будет следствием игнорирования этого
правила.

При планировани stub конфигурации EIGRP, выполните следующие шаги:

  • Изучите топологию и существующую конфигурацию EIGRP.
  • Определите требования, содержащие информацию о том, какие маршрутизаторы будут настроены как stub-маршрутизаторы, и будет ли применяться пререраспределение (redistribution) и суммирование.
  • Разработайте план стеи.
  • Создайте план по внедлению.
  • Настройте и проверьте конфигурацию.


Настройка EIGRP Stubs

Для настройки EIGRP-маршрутизатора в качестве stub используется команда 

R(config-router)#eigrp stub [receive-only | connected | static | summary | leak-map leak-map_name]

Данные параметры команды могут использоваться в любых комбинациях, за исключением receive-only, которое используется только индивидуально. По умолчанию: connected и summary. Если любое ключевое слово используется отдельно, то напрямую подключённые маршруты и суммированные маршруты не рассылаются автоматически. (If any of the keywords (except receive-only) is used individually, the connected and summary routes are not sent automatically)

Параметры команды eigrp stub:

Параметр Описание
receive-only Запрещает stub-маршрутизатору анонсировать любые свои маршруты другому маршрутизатору (той же AS). При использовании этого параметра, другие параметры запрещены (т.к. он запрещает отправку любых типов маршрутов). Используйте опцию если маршрутизатор имеет один интерфейс.
connected Разрешает stub-маршрутизатору отправлять connected маршруты, но только для интерфейсов, адреса которых находятся в сетях, указанных командой network. Если команда network не включает connected маршруты, возможно необходимо перераспределить (redistribute) connected маршруты командой redistribute connected. Опция включена по умолчанию, наиболее используемая опция.
static Разрешает stub-маршрутизатору отправлять static маршруты, при том, что перераспределение ('redistribute) статических маршрутов уже настроено.
summary Разрешает stub-маршрутизатору отправлять суммированные маршруты (суммированные автоматически [на граничном маршрутизаторе с вкл. auto-summary] или вручную [команда ip summary-address eigrp]).
redistributed Разрешает stub-маршрутизатору отправлять redistributed маршруты. Требуется настроить перераспределение командой redistribute.

Пример ниже показывает как настроить stub который анонсирует connected и summary маршруты: 

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0
Router(config-router)#eigrp stub

Следующая конфигурация не рассылает connected, summary или static маршруты: 

Router(config)#router eigrp 1
Router(config-router)#network 10.0.0.0 eigrp
Router(config-router)#eigrp stub receive-only
  • Функция stub не включает автоматическое суммирование маршрутов на центральном маршрутизаторе. Если оно требуется, администратор может его настроить. Cisco рекомендует использовать и суммирование маршрутов, и функцию stub для обеспечения лучшей масштабируемости.
  • Если нужна реальная stub сеть, то hub может быть настроен для анонсирования spoke'ам маршрута по умолчанию. Это самый простой поход, чтобы сохранить память и п/п spoke-маршрутизаторам.
NOTE: Although EIGRP is a classless routing protocol, it behaves like a classful protocol, such as having automatic  
summarization on by default. When configuring the hub router to send a default route to the remote router, configure the ip 
classless command. By default, the ip classless command is enabled in all Cisco IOS images that support EIGRP stub routing.
  • Без stub-функции, если маршрут пропал, EIGRP рассылает запрос spoke-маршрутизаторам. Функция stub позволяет администратору предотвратить при любых условиях отправку запросов spoke'ам.

Следующий пример показывает как повлияет использование функции stub в нашей прошлой сети:

450px
  • На рисунке выше, каждый из удалённых маршрутизаторов C,D и E настроен как stub-маршрутизатор. Запросы для 10.1.8.0/24 им не рассылаются, что сокращает использование п/п и шансы, что маршруты перейдут в состояние SIA.
  • В дополнение, центральные (hub) sites (региональные офисы) смогут сразу ответить на запросы, без их распространения (propagating) удалённым маршрутизаторам, т.о. сохраняя CPU и bandwidth, и уменьшая время конвергенции, даже если удалённые площадки использует резервирование (т.е. подключены к двум и более hub-площадкам).
450px

Картинка выше показывает другой пример. Ниже приведена конфигурация маршрутизатора B. 

RouterB#show running-config
<output omitted>
ip route 10.1.4.0 255.255.255.0 10.1.3.10
!
interface ethernet 0
ip address 10.1.2.1 255.255.255.0
!
interface serial 0
ip address 10.2.2.3 255.255.255.254
ip summary-address eigrp 100 10.1.2.0 255.255.254.0
!
interface serial 1
ip address 10.1.3.1 255.255.255.0
!
router eigrp 100
redistribute static 1000 1 255 1 1500
network 10.2.2.2 0.0.0.1
network 10.1.2.0 0.0.0.255
<output omitted>

Используя картинку выше и приведённую конфигурацию, сравним поведение eigrp с разными настройками stub:

  • eigrp stub connected
    • Маршрутизатор B анонсирует только 10.1.2.0/24 маршрутизатору А. Хотя сеть 10.1.3.0/24 также является напрямую подключённой, она не указана в команде network. И connected-маршруты не перераспределены (redistributed).
  • eigrp stub summary
    • Маршрутизатор B will анонсирует только 10.1.2.0/23 (настроен суммированный маршрут) маршрутизатору A.
  • eigrp sub static
    • Маршрутизатор B анонсирует только 10.1.4.0/24 (настроенный статический маршрут) маршрутизатору A.
  • eigrp stub receive-only
    • маршрутизатор B ничего не анонсирует маршрутизатору A.
Внимание!
Без опции static EIGRP не отправит ни одного статического маршрута, включая внутренные (internal) статические
маршруты, которые обычно были бы автоматически перераспределены.

EIGRP stub leak-map

The eigrp stub leak-map <<route-map>> command allows you to specify a route-map to decide whether or not to advertise prefixes learned via EIGRP (not connected or static). 

route-map leak-map permit 10
 match ip address 1
route-map leak-map deny 20
!
access-list 1 permit 1.1.1.1

R4(config-router)#eigrp stub leak-map leak-map

Graceful Shutdown

  • graceful shutdown - функция, позволяющая процессу маршрутизации EIGRP при завершении работы сообщить широковещательным goodbye-сообщением соседям, что маршрутизатор и, соответственно, маршруты доступные через него, более недоступны.
  • Эта функция позволяет EIGRP-соседям более эффективно синхронизироваться и пересмотреть соседские отношения.
  • Без этой функции, сосед не сможет нормально оповестить о том, что его EIGRP процесс going DOWN. Другие маршрутизаторы будут вынуждены ждать истечения hold-таймера, посланные в этот период времени пакеты могут быть утеряны.
  • Goodbye Messages
    • Поддерживаются IOS 12.3(2), 12.3(3)B, и 12.3(2)T и выше.
    • Отправляются в hello-пакетах
    • EIGRP посылает interface goodbye messages устанавливая значения весовых коэффициентов K1 - K5 равными 255.
    • Если версия IOS маршрутизатора не поддерживает goodbye messages он не принимают во внимание значения коэффициентов K1-K5=255. В этом случае выводится сообщение о неправильном значении весовых коэффициентов (K-value mismatch). При этом его работа не нарушается, т.к. сообщение игнорируется.
  • Внимание! Маршрутизатор EIGRP пошлёт goodbye-сообщение через интерфейс, если команда network, включающая сеть этого интерфейса, была удалена (no network <сеть_интерфейса>). Так же маршрутизатор пошлёт goodbye-сообщение через все интерфейсы, если завершить процесс EIGRP (no router eigrp). Однако, никакого сообщения не будет послано, если перевести интерфейс в состояние "выключен" или перезагрузить маршрутизатор.

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

250px

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

При использовании graceful 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#
*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: Interface Goodbye received

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

*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: K-value mismatch

Но это не нарушает сетевые операции. Маршрутизатор закрывает сессию по истечении hold-таймера. Соседские отношения нормально возобновляются после запуска EIGRP на отправителе.

Примечания

<references />

Источник — https://wiki.shibaev.info/index.php?title=Optimizing_EIGRP_Implementations&oldid=900