CCNP Route Шпаргалки - EIGRP: Query/Reply-сообщения. Stub-router in EIGRP

Итак, когда протокол EIGRP сошелся и все необходимые маршруты были найдены, в таблице топологии можно увидеть следующую картину для маршрутов-successor'ров:

R2#sh ip eigrp topology

IP-EIGRP Topology Table for AS(100)/ID(10.1.2.9)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status

P 10.1.3.8/30, 1 successors, FD is 40640000
        via 10.1.203.3 (40640000/128256), Serial0/1

Состояние P (Passive) означает, что данный маршрут активен и работает, алгоритм DUAL не предпринимает никаких попыток по поиску каких-либо замен для маршрута.

Что же происходит, если EIGRP по каким-либо причинам удаляет имеющийся маршрут-successor, при этом Feasible Successor (FS) отсутствует?

В этом случае маршрут переходит в состояние Active.Далее происходит поиск нового Successor'а:

 - EIGRP начинает рассылку Query-сообщений всем соседям, кроме того, маршрут до которого является нерабочим. Соседи опрашиваются на предмет наличия loop-free маршрута для требуемого списка сетей.

 - Сосед считает, что он имеет loop-free маршрут в случае, если его маршрут в необходимые сети находится в состоянии Passive. В этом случае маршрутизатор посылает EIGRP Reply-сообщение в ответ, сообщая, что у него есть требуемый маршрут. И далее Query-сообщения не пересылаются.

 - В противном случае маршрутизатор-сосед посылает Query своим соседям, продолжая цепочку поиска. И не отсылает инициатору данного процесса Reply до тех пор, пока сам не получит от своих соседей Reply-сообщения.

 - Как только маршрутизатор-получает Reply от всех своих соседей, которым он послал Query, он высылает Reply-сообщение инициатору.

 - После того, как маршрутизатор-инициатор процесса получил все Reply-сообщения от тех соседей, которым он послал Query, маршрутизатор может выбрать маршрут, являющийся loop-free.

В случае, если сеть достаточно крупная, может возникнуть "шторм" из Query/Reply-сообщений. Пример такой ситуации - ниже.

Пусть маршрутизатор WAN_1 потерял путь до сетей маршрутизатора Branch1 (на рисунке LAN на маршрутизаторах BranchX не показана). При этом у WAN_1 отсутствует FS-маршрут в эту сеть. WAN_1 начинает процесс поиска маршрута, рассылая Query-сообщения всем соседям, кроме Branch1. В конечном  итоге сеть сойдется и маршрут будет найден, но до этого момента может пройти много времени.
  Если посмотреть на схему, то можно понять, что в результате поиска маршрутизатор WAN_1 может выбрать длинный маршрут в локальную сеть на Branch1 (например через Branch4: WAN_1-->Branch4-->WAN_2-->Branch1). Выбор такого маршрута приведет к излишней загрузке линии связи между Branch2 и WAN_2, что отразится на пользователях как Branch1, так и Branch2. Для того, чтобы WAN_1 не смог изучить такой маршрут, можно назначить всем маршрутизаторам BranchX роль stub-router (SR) в EIGRP.
SR не анонсирует соседям маршруты, которые он изучил по протоколу EIGRP. В свою очередь соседи знают, какие маршрутизаторы являются SR, и, при возникновении ситуации, описанной выше, не отправляют таким маршрутизаторам Query-сообщения.
Настроить роль stub-router можно следующим образом:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub <options> 
Команда может быть применена со следующими опциями:
connected   - анонс маршрутов со статусом Connected, причем только на интерфейсах, которые попадают под команду network
receive-only     - не анонсировать маршруты
redistributed     - анонсировать только маршруты, полученные с помощью редистрибьюции (т.е. в результате применения команды redistribute)
static                - анонс статических маршрутов (требует применения redistribute static)
summary          - анонсировать маршруты, полученные в результате автоматического и ручного суммирования.

Во всех режимах, кроме receive-only, маршрутизаторы формируют соседство.