EIGRP Stub Routing

Leave a Comment /

EIGRP Stub Routing — причины введения тупиковой области в EIGRP, механизм запросов EIGRP, SIA, суммаризация, варианты настройки Stub Routing.

Почему суммаризация вместе с тупиковыми областями и механизмом запросов? Эти вещи сильно друг с другом связаны. Рассматривать их логично вместе.

Теория

Сначала нужно освежить в голове сопутствующие понятия EIGRP. В таблицу маршрутизации добавляется только лучший маршрут в подсеть (маршрут с наименьшей метрикой). Для EIGRP роутер, через который идёт такой маршрут, называется Преемник (Successor, S, Upstream Router). Часто под S подразумевают и сам наилучший маршрут в подсеть, он же Successor Route (SR). С подсетью ассоциировано адресное пространство этой сети и чаще вместо самой подсети употребляется термин "префикс".

Остальные маршруты для данного префикса присутствуют в таблице топологии. Возможная замена для S в случае его недоступности по каким-то причинам это Возможный Преемник (Feasible Successor, FS).

Не все роутеры, имеющие маршрут в данную подсеть становятся FS. Должно выполняться условие осуществимости (Feasibility Condition или Feasible Condition, FC): метрика для FS в эту подсеть должна быть меньше метрики исходного роутера через S в эту же подсеть. По сути FC это механизм, защищающий EIGRP от петель.

Посмотреть FS можно командой:

R1# show ip eigrp topology

Посмотреть все маршруты для данного префикса, включая маршруты, которые не удовлетворяют FC:

R1# show ip eigrp topology all-links

Для EIGRP есть второй механизм защиты от петель: правило разделения горизонта (Split Horizon, SH). Суть этого правила заключается в следующем: если роутер что-то выучил или получил через какой-то свой линк, то он оправляет эту информацию своим EIGRP соседям, за исключением линка, через который информация была получена.

Соседи, которым отправляется информация, тут выступают как нижележащие роутеры (Downstream Routers, DR). Рассказал своими словами, подробнее про данные понятия тут.

Механизм распространения запросов

Для того чтобы понять назначение Stub Routing'а, сначала нужно рассмотреть поведение роутера, когда EIGRP маршрут в его таблице маршрутизации становится недоступным. Например сбой соседнего роутера, который S данного маршрута.

Поведение DUAL при отвале маршрута
Есть FS
  • Сначала роутер пытается решить проблему самостоятельно, если есть FS в таблице топологии, то он становится S, а его маршрут сразу помещается в таблицу маршрутизации. Это и обеспечивает невероятно быструю сходимость сети для EIGRP в случае недоступности маршрута;
  • Если есть несколько FS, то S становится FS с наименьшей метрикой до сети назначения;
  • Отсылается пакет с обновлением (Update) всем соседям с новым маршрутом и новой метрикой через нового S;
  • Заодно роутер проверяет наличие альтернативного маршрута по умолчанию

Роутеры, получившие пакет Update, запускают свой собственный алгоритм DUAL для данного префикса и полученной новой метрики для него. В результате этого на этих роутерах могут произойти изменения как S, так и FS для данного префикса.

Нет FS
  • Если FS нет, то маршрут из нормального состояния Passive (P) переводится в Active (A);
  • Далее роутер отравляет запросы (Queries) своим EIGRP соседям (DR) о наличии у них FS в подсеть назначения. Для отвалившегося маршрута метрика указана равной бесконечности (infinite metric)

Здесь есть 3 возможности при получении роутером запроса:

  1. У роутера нет маршрута для данного префикса, тогда сразу отправляется ответ об этом;
  2. Запрос пришёл не от S для данного префикса. Тогда infinite metric из запроса для префикса игнорируется. Роутер отсылает ответ с атрибутами маршрута через своего S для данного префикса;
  3. Запрос пришёл от S, получивший запрос роутер принимает infinite metric и переводит маршрут в активное состояние

Третий пункт разбивается ещё на 2 возможности:

  1. У роутера получившего запрос больше нет соседей. Он отсылает ответ о недоступности маршрута;
  2. Соседи есть (DR), тогда запрос  рассылается им. Образуется расходящееся дерево запросов домену EIGRP. Запрос не отсылается соседу, от которого этот запрос поступил (SH)
Query Boundary

Рассылка запросов продолжается пока запросы не достигают границы (Query Boundary). Как определяется эта граница?

  1. У роутера нет такого префикса в таблице маршрутизации;
  2. Запрос пришёл от S, но нет других соседей;
  3. Запрос пришел не от S и выслана информация о своём S для данного префикса

Как видно Query Boundary совпадает с физической границей EIGRP домена только в случае 2.

Обработка ответов
  • Исходный роутер не обрабатывает информацию, пока не получит ответы от всех соседей, которым был отослан запрос;
  • Каждый запрос требует ответа. Когда какой-то роутер в цепочке получает все ответы на запросы, которые он разослал, то он также отсылает ответ;
  • Маршрут остаётся активным на исходном роутере, пока не придут все ответы по числу отправленных запросов (есть специальный счётчик) или пока не истечёт таймер активного состояния (другой специальный счётчик);
  • Если истёк таймер активного состояния, то соседство с не ответившим на запрос роутером сбрасывается;
  • Если в результате новый S не найден, то исходный маршрут отбрасывается.
Пример
  • R2 обнаруживает отвал линка. Для префикса 10.1.1.0/24 нет FS, R2 переводит префикс в активное состояние и отсылает запросы R3 и R4;
  • R3 получает запрос от R2, обрабатывает поле Delay, видит что оно установлено как бесконечно большое. Поскольку запрос получен от S для 10.1.1.0/24 и у R3 нет других соседей EIGRP, он отправляет ответ R2 о недоступности маршрута;
  • R4 получает запрос от R2, обрабатывает поле Delay, видит что оно установлено как бесконечно большое. Поскольку запрос получен от S, то маршрут помечается как активный и новый запрос отсылается R5;
  • R5 получает запрос от R4, обрабатывает поле Delay, видит что оно установлено как бесконечно большое. Поскольку запрос получен не от S, а S известен через другой интерфейс, то обратно отсылаются новые параметры для маршрута;
  • R4 получает ответ от R5, подтверждает получение ответа. Поскольку R4 отослал 1 запрос и получил на него ответ, то все запросы закрыты ответами. Значит R4 высчитывает новый маршрут для префикса, помечает префикс как пассивный и отсылает ответ R2 с атрибутами маршрута;
  • R2 получает ответ от R4, подтверждает получение ответа. До этого был получен ответ от R3. Все запросы закрыты ответами. R2 высчитывает новый маршрут для префикса, помечает префикс как пассивный

Проблема механизма запросов

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

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

  • Суммаризация маршрутов;
  • Тупиковый роутинг (Stub Routing - SR).

Вторая проблема механизма запросов

Когда роутер распространяет запрос для маршрута, он переводит маршрут в активное состояние и включает таймер активного состояния. Таймер активного состояния равен 180 секундам. Если какой-то сосед не отвечает на запрос в это время, как уже говорилось, соседские отношения EGRP с этим соседом сбрасываются. Маршрут переводится в состояние Stuck In Active (SIA).

При сбросе отношений и SIA, все маршруты, известные через сброшенного соседа, переводятся в активное состояние. Затем роутер отправляет этому соседу Full Update сообщение для восстановления соседских отношений.

Допустим, роутер A посылает запрос роутеру B, роутер B роутеру C. Роутер C не ответил в 3 минуты, роутер B переводит маршрут в SIA и разрывает отношения с C. Но роутер B также не может отправить ответ A, пока B ждёт ответ от C. Таймер активного состояния на роутере A истекает, так как он был запущен раньше таймера активного состояния на B. Роутер A разрывает отношения с роутером B. В результате может возникнуть цепочка сбросов соседских отношений. Домен EIGRP ведёт себя нестабильно. И это всё из-за 1 не ответившего во время соседа.

Для преодоления проблемы SIA был придуман механизм улучшения активного состояния маршрута (Active Process Enhancement, APE). Если таймер активного состояния достиг 90 секунд, то не ответившему соседу отправляется запрос SIA-Query, сосед отвечает с помощью SIA-Reply. Если SIA-Reply получен, то соседские отношения не сбрасываются. Все соседские отношения при этом сохраняются, за исключения 1 роутера, связь с которым действительно была потеряна (роутер C в примере выше).

Влияние суммаризации на механизм запросов

Если на роутер пришел запрос и подсеть в запросе подпадает под имеющийся суммарный маршрут, то запрос далее не распространяется и сразу отправляется ответ о недоступности нового FS для этой подсети.

В отличии от OSPF, для EIGRP суммарный маршрут может быть настроен в любой точке EIGRP домена. Настройка суммаризации зависит от точки, в которой она настраивается.

  • Если у роутера есть несколько подсетей с прямым подключением (Connected, то есть непосредственно на интерфейсах роутера), допустим 172.17.1.0/24, 172.17.2.0/24.., которые подпадают под одну классовую сеть A, B (172.17.0.0/16) или C, эти подсети задействованы в EIGRP с помощью команды network и больше нигде в домене EIGRP эта сеть (172.17.0.0/16) не используется, то достаточно включить авто-суммаризацию для EIGRP:
A(config)# router eigrp 1
network 0.0.0.0 - задействует все подсети с прямым подключением на роутере
... 
auto-summary

Дальше роутер сделает всё сам. Авто-суммаризация для EIGRP выключена по умолчанию для IOS 15, для IOS 12 включена.

  • Если несколько роутеров имеют подсети с прямым подключением, допустим 172.17.1.0/24, 172.17.2.0/24.. 172.17.4.0/24 на одном роутере и 172.17.9.0/24, 172.17.10.0/24.. 172.17.12.0/24 на другом, из одной классовой сети (172.17.0.0/16), то авто-суммаризацию включать нельзя, применяется ручное суммирование на интерфейсе. Сети, получившиеся на разных роутерах в результате суммирования (172.17.0.0/21 и 172.17.8.0/21), не должны пересекаться.
  • Если роутер A получает несколько маршрутов EIGRP от роутера B (для роутера B это подсети с прямым подключением) и от роутера C (для роутера C это тоже подсети с прямым подключением), которые можно суммировать вместе, то суммаризация производится на интерфейсе роутера A вручную. При этом также нужно проверять чтобы в получившееся суммирование не попадали подсети с прямым подключением на других роутерах в домене (кроме B и C).
A# show ip route
...
10.0.0.0/16 is subnetted, 4 subnets
D 10.11.0.0 [90/409600] via 172.16.1.2, 00:23:26, Ethernet0/1
D 10.12.0.0 [90/409600] via 172.16.1.2, 00:23:26, Ethernet0/1
D 10.13.0.0 [90/409600] via 172.16.2.2, 00:22:05, Ethernet0/2
D 10.14.0.0 [90/409600] via 172.16.2.2, 00:22:05, Ethernet0/2

A(config)# interface Ethernet 0/0
A(config-if)# ip summary-address eigrp 1 10.8.0.0/13
Пример

Суммаризация  настраивается на интерфейсе Gi0/0 роутера R2:

EIGRP Stub Routing
R2(config)# interface gi0/0 
R2(config-if)# ip summary-address eigrp 1 192.168.0.0/16

При настройке суммаризации соседские отношения не разрываются, происходит синхронизация:

*Nov 23 18:09:42.732: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.1 (GigabitEthernet0/0) is resync: summary configured
*Nov 23 18:09:42.736: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.1.1 (GigabitEthernet0/0) is resync: summary up, remove components

Для роутера R2 с суммаризацией 192.168.0.0/16 (в данном случае ручная суммаризация на интерфейсе, но для авто тоже справедливо), появится запись в таблице маршрутизации:

192.168.0.0/16 is variably subnetted ...
D 192.168.0.0/16 is a summary, 00:31:38, Null0

Такой маршрут Null0 защищает роутер от петель. Пакеты подпадающие под данный маршрут отбрасываются. Зачем так сделано? Потому что роутер R2 не имеет в своей таблице маршрутизации маршрутов для всего диапазона суммаризации. А только маршруты в конкретные сети 192.168.1.0/24 и 192.168.2.0/24. Роутер R1, получив от R2 суммарный маршрут, может присылать на него любые пакеты из диапазона суммаризации. Например для сети 192.168.3.0/24. Если бы на роутере R2 был бы дополнительно настроен маршрут по умолчанию в сторону R1, то это петля. Пока не закончится TTL пакет бы гулял между роутерами. Поскольку есть маршрут Null0, то это более длинное совпадение, чем маршрут по умолчанию. Пакет уйдёт в Null0 виртуальный интерфейс, то есть будет отброшен.

Может ещё возникнуть вопрос: почему так неаккуратно суммировано по 16 маске? Да, действительно, по 22 будет правильнее, но в данном конкретном примере, который только для наглядности, не имеет значения.

Stub Routing

Теперь непосредственно о SR. Преимущества EIGRP SR:

  • Улучшает стабильность сети;
  • Снижает накладные расходы (CPU, утилизация сети);
  • Упрощает настройку.

Если роутер настроен как тупиковый (Stub), то к нему запросы не отравляются. Сам он тоже отправляет соседям не все маршруты EIGRP. Настройка простая:

R3(config)# router eigrp 1
 ...
eigrp stub

Для команды eigrp stub имеются параметры:

connected - отправляет соседям только маршруты сетей с прямым подключением (connected), для тех интерфейсов, которые соответствуют командам network
summary - отправляет только суммарные маршруты как настроенные вручную, так и полученные автоматически в результате работы команды auto-summary
static - отправляет только статические маршруты перераспределённые (redistributed) в EIGRP с помощью команды redistribute static
redisribute - отправляет все перераспределённые маршруты, предполагается уже выполненной дополнительная настройка EIGRP с помощью команды redistribute
receive-only - не отправляет никакие маршруты
leak-map route-map-name - отправляет маршруты, которые соответствуют роут мапе с именем route-map-name

Опция recieve-only используется крайне редко. Пример использования: граничный для домена EIGRP роутер с 1 EIGRP интерфейсом, на котором настроен PAT и несколькими интерфейсами в локальную сеть. Все хосты маскарадятся 1 внешним IP адресом. Нет смысла передавать какую-либо информацию о сетях через EIGRP. Также предлагаю посмотреть короткое видео по настройке leak-map.

Если ввести команду eigrp stub без параметров, то в конфигурации пропишутся следующие параметры по умолчанию:

...
eigrp stub connected summary
...

Параметры можно  комбинировать (кроме параметра receive-only), таким образом команда:

R3(config)# router eigrp 1 
...
eigrp stub connected static

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

После ввода команды eigrp stub соседские отношения переустанавливаются:

*Nov 23 19:34:12.671: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.3.1 (Ethernet0/0) is down: peer info changed
*Nov 23 19:34:15.962: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 172.16.3.1 (Ethernet0/0) is up: new adjacency

Тупиковый роутер анонсирует свой новый статус в EIGRP hello сообщениях. Теперь если посмотреть статус тупикового соседа:

R2# show ip eigrp neighbors detail
...
Stub Peer Advertising (CONNECTED STATIC ) Routes
Suppressing queries

Применение Stub Routing

Тут всё очевидно, SR применяется на роутерах, которые являются граничными, тупиковыми для EIGRP домена.

eigrp stub

Рассмотрим ещё раз работу EIGRP домена на картинке. Роутеры R3 и R4 настроены тупиковыми. Для R2 настроен суммарный маршрут 192.168.0.0/16 на интерфейсе Gi0/0. Роутер R2 отправляет информацию о суммарном маршруте роутеру R1. Допустим связь между R2 и R3 потеряна. У роутера R2 отвалился маршрут в сеть 192.168.1.0/24. Для R2 FS для 192.168.1.0/24 нет.

Маршрут 192.168.1.0/24 на R2 переводится в активное состояние. Далее, R2 отправляет запросы о новом FS в сеть 192.168.1.0/24 соседям. Запрос к R3 не будет оправлен, так как он S. Да и нельзя это сделать, так как линк упал. Запрос к R4 не будет отправлен, так как R4 тупиковый. Роутер R2 отправляет запрос только к R1. Роутер R1 смотрит свою таблицу маршрутизации и находит суммарный маршрут 192.168.0.0/16, затем сразу отправляет ответ для R2 о недоступности FS для 192.168.1.0/24. Скорость схождения сети мгновенная. Соседские отношения EIGRP между R1 и R2 не пострадают при этом.

Выжимка полезностей про EIGRP тут. Лаба GNS3 на EIGRP Stub здесь.

Leave a Comment

Scroll to Top