Тонкость определения EIGRP Feasible Distance

EIGRP – это дистанционно-векторный протокол маршрутизации, изначально разработанный Cisco. Одним из ключевых отличий от предшественника, IGRP, является использование DUAL – алгоритма, который позволяет исключить появление постоянных петель маршрутизации в топологии. Однако найти корректное определение одного из основных параметров DUAL, feasible distance (FD), оказывается подчас непростой задачей. Обратимся к определению на официальном сайте:

“Feasible distance is the best metric along a path to a destination network, including the metric to the neighbor advertising that path.“

Перевод: feasible distance – это наилучшее значение метрики до сети назначения, включающее значение метрики до соседа, который анонсирует соответствующий маршрут.

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

На каждом из маршрутизаторов настроен соответствующий loopback (например, на R1 – с адресом 1.1.1.1/32). В сети, очевидно, используется EIGRP в качестве протокола маршрутизации без каких-либо изысков в настройке:

R3#sho run | section router eigrp router eigrp 1  network 0.0.0.0

В рамках данной статьи основной интерес представляет маршрут до 3.3.3.3/32 с точки зрения R1:

R1#deb eigrp fsm EIGRP Finite State Machine debugging is on  R1#sho ip eigrp topology 3.3.3.3/32 EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720   Descriptor Blocks:   192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0       Composite metric is (158720/156160), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5200 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 2         Originating router is 3.3.3.3

По умолчанию существуют 2 способа повлиять на значение метрики EIGRP: изменить пропускную способность канала или же его задержку. В нашем случае изменение пропускной способности позволяет получить более предсказуемые результаты. Изменим метрику соединения между R2 и R3:

R2(config-if)#delay 100

Как и следовало ожидать, R1 теряет единственный маршрут до 3.3.3.3/32 и переводит префикс в состояние Active:

R1# *Mar  2 20:17:07.655: EIGRP-IPv4(1): rcvupdate: 3.3.3.3/32 via 192.168.12.2 metric 181760/179200 on tid 0 *Mar  2 20:17:07.659: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 158720, RD is 158720 on tid 0 *Mar  2 20:17:07.659: EIGRP-IPv4(1): 	192.168.12.2 metric 181760/179200 not found Dmin is 181760 *Mar  2 20:17:07.659: DUAL: AS(1) Peer total 1 stub 0 template 1 for tid 0 *Mar  2 20:17:07.659: DUAL: AS(1) Dest 3.3.3.3/32 entering active state for tid 0. *Mar  2 20:17:07.659: EIGRP-IPv4(1): Set reply-status table. Count is 1. *Mar  2 20:17:07.659: EIGRP-IPv4(1): Not doing split horizon *Mar  2 20:17:07.759: EIGRP-IPv4(1): rcvreply: 3.3.3.3/32 via 192.168.12.2 metric 181760/179200 for tid 0 *Mar  2 20:17:07.759: EIGRP-IPv4(1): reply count is 1 *Mar  2 20:17:07.759: DUAL: AS(1) Clearing handle 0, count now 0 *Mar  2 20:17:07.759: DUAL: AS(1) Freeing reply status table *Mar  2 20:17:07.759: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 72057594037927935, RD is 181760 on tid 0 found *Mar  2 20:17:07.759: DUAL: AS(1) RT installed 3.3.3.3/32 via 192.168.12.2

Значение FD также изменилось – теперь оно соответствует значению метрики до 3.3.3.3/32:

R1#sho ip eigrp topology 3.3.3.3/32 EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 181760   Descriptor Blocks:   192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0       Composite metric is (181760/179200), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 6100 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 2         Originating router is 3.3.3.3

Попробуем теперь другое значение, предварительно сбросив предыдущие изменения. Задержка для интерфейса f0/1 на R2:

R2#sho int f0/1 FastEthernet0/1 is up, line protocol is up    Hardware is i82543 (Livengood), address is ca02.0ebd.0006 (bia ca02.0ebd.0006)   Internet address is 192.168.23.2/24   MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec, <output omitted>

В прошлый раз мы назначили задержку, равную 1000 мкс (значение указывает в десятках микросекунд), что значительно больше значения по умолчанию. Теперь используем минимально настраиваемое значение в 110 мкс:

R2(config-if)#delay ?        <1-16777215>  Throughput delay (tens of microseconds)  R2(config-if)#delay 11

Известен небольшой трюк, позволяющий не ошибиться с единицами измерения значений в командах: перед вводом значения символ ‘?’ вызывает контекстную подсказку, которая среди прочего указывает и ожидаемые единицы измерения; такая привычка подчас экономит массу времени, исключая ошибки по невнимательности (в конце концов десятки микросекунд – не самая очевидная единица измерения на мой взгляд). Проверим, что происходит в этот момент на R1:

R1# *Mar  2 20:25:40.227: EIGRP-IPv4(1): rcvupdate: 3.3.3.3/32 via 192.168.12.2 metric 158976/156416 on tid 0 *Mar  2 20:25:40.231: EIGRP-IPv4(1): Find FS for dest 3.3.3.3/32. FD is 158720, RD is 158720 on tid 0 *Mar  2 20:25:40.231: EIGRP-IPv4(1): 	192.168.12.2 metric 158976/156416 found Dmin is 158976 *Mar  2 20:25:40.239: DUAL: AS(1) RT installed 3.3.3.3/32 via 192.168.12.2

Отладочный вывод в этот раз существенно меньше. Что насчёт значения FD?

R1#sho ip eigrp topology 3.3.3.3/32 EIGRP-IPv4 Topology Entry for AS(1)/ID(1.1.1.1) for 3.3.3.3/32   State is Passive, Query origin flag is 1, 1 Successor(s), FD is 158720   Descriptor Blocks:   192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0       Composite metric is (158976/156416), route is Internal       Vector metric:         Minimum bandwidth is 100000 Kbit         Total delay is 5210 microseconds         Reliability is 255/255         Load is 1/255         Minimum MTU is 1500         Hop count is 2         Originating router is 3.3.3.3

FD не совпадает с метрикой! В чём же соль? Внимательный читатель мог заметить разницу между рассматриваемыми случаями помимо разных значений задержек. Рассмотрим, что происходило после изменения метрики щаг за шагом:

Ключевое отличие заключается в запуске R1 процесса DUAL. Большая задержка на R2 (100) изменяет метрику таким образом, что результирующий маршрут не удовлетворяет условию feasibility condition, что, в свою очередь, вынуждает R1 инициировать DUAL. Малое же изменение задержки позволяет префиксу соответствовать feasibility condition (изменение задержки меньше задержки канала R1-R2), что даёт возможность избежать времязатратного DUAL. Отладочный вывод включает в себя значение FD, используемое для поиска feasible successor в определённый момент; значение FD после окончания DUAL равно бесконечности. Получается, что FD – исторически минимальное значение метрики; оно сбрасывается, как только маршрут переходит в состояние Active.

В обсуждениях Cisco Community можно найти точное определение FD:

“Feasible Distance is the lowest distance to the destination experienced since the last time the route went from Active to Passive state”

Перевод: FD – это минимальное значение метрики до сети назначения с момента последнего перехода префикса из состояния Active в Passive.

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

Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.