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 eigrprouter eigrp 1 network 0.0.0.0
В рамках данной статьи основной интерес представляет маршрут до 3.3.3.3/32 с точки зрения R1:
R1#deb eigrp fsmEIGRP Finite State Machine debugging is onR1#sho ip eigrp topology 3.3.3.3/32EIGRP-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/32EIGRP-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/1FastEthernet0/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/32EIGRP-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 не совпадает с метрикой! В чём же соль? Внимательный читатель мог заметить разницу между рассматриваемыми случаями помимо разных значений задержек. Рассмотрим, что происходило после изменения метрики щаг за шагом:
|
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.
Хотя практическая польза этого знания может показаться несущественной, наличие строгих определений позволяет избежать разночтений, что положительно влияет на понимание используемой технологии.
Помогали редактировать статью: Анастасия Куралёва, Максим Климанов.
