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.3FD не совпадает с метрикой! В чём же соль? Внимательный читатель мог заметить разницу между рассматриваемыми случаями помимо разных значений задержек. Рассмотрим, что происходило после изменения метрики щаг за шагом:
Delay 1100 | Delay 110 | |
Шаг 1 | R1 получает обновление о 3.3.3.3/32 | |
Шаг 2 | R1 ищет feasible successor for 3.3.3.3/32 | |
Шаг 3 | R1 не удалось найти FS, что приводит к запуску DUAL | R1 находит FS и устанавливает маршрут в таблицу маршрутизации |
Шаг 4 | По завершении DUAL R1 выбирает наилучший маршрут и устанавливает его в таблицу маршрутизации | |
Ключевое отличие заключается в запуске 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.
Хотя практическая польза этого знания может показаться несущественной, наличие строгих определений позволяет избежать разночтений, что положительно влияет на понимание используемой технологии.
Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.
