Композитная метрика EIGRP

Какие только не приходилось читать статьи про композитную метрику EIGRP. Как очень полезные, так и откровенно глупые. Давайте еще раз разберем, что к чему. Я постараюсь не жевать то, что уже было 10 раз пережевано, а указать на интересные, на мой взгляд, особенности и хитрости подсчета этой самой композитной метрики, в короткой статье. Вспомним кошмарную формулу:

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

Правило 1: K-values не являются полосой пропускания, задержкой, загрузкой, или еще чем бы то не было как нас учили в треке CCNA или во множестве статей! К-values (K1, K2, K3, K4 и K5), это некие индексы, изменяя которые, мы можем влиять на подсчет композитной метрики. Значение BW – не просто минимальное значение bandwidth, а 10 000 000 (10^7) деленное на минимальное значение bandwidth, а delay не просто сумма всех задержек интерфейсов, а сумма, деленная на 10.

Как мы все знаем для подсчета метрики маршрута используются следующие параметры:

• Минимальное значение bandwidth среди всех интерфейсов на пути следования маршрута
• Сумма значений delay всех интерфейсов на пути следования маршрута
• Reliability
• Load
• MTU

С bandwidth все просто. Мы получили анонс на каком-то интерфейсе. Если на этом интерфейсе bandwidth меньше, чем мы получили в анонсе – подменяем значение в анонсе и шлем дальше. Таким образом, от любой точки до любой, конечная точка получит анонс с минимальным значением bandwidth по всей трассе. То же правило касается MTU. Кстати, учитываются оба значения, и L2 MTU интерфейса, и L3 IP MTU, выбирается меньшее значение. Этого в книгах не писали. Еще интересный факт, что смена MTU на интерфейсе не вызывает update маршрута, и чтобы изменение реально вступило в силу, приходится дернуть интерфейс, или изменить другой параметр, например delay или bandwidth, чтобы вызвать update. Еще один малоизвестный факт.

С delay все еще проще. Получили анонс на интерфейсе – добавили в значение delay свой delay этого интерфейса и анонсируем дальше. Я честно не смог точно понять, как ведут себя от хопа к хопу reliability и load, так как эмулировать их изменение мне не удалось. Буду рад, если кто то дополнит этот пост.

Правило 2: в расчетах учитываются только интерфейсы, на которых мы получили анонс. Интерфейсы куда мы шлем эти анонсы вообще не учитываются, какие бы параметры bandwidth, delay, MTU бы на них не были.

Здесь начинает ломаться голова. Как маршрутизатор, получив анонс, узнает какая минимальная пропускная способность на пути, чтобы вычесть ее из композитной метрики и заменить своей? Как с другими параметрами? Интересно. Откроем книгу Troubleshooting IP Routing Protocols (CCIE® Professional Development), в которой приведена структура пакета EIGRP IP Internal Route TLV:

Где здесь композитная метрика? А нет ее. От хопа к хопу передаются только сами параметры. Выведем:

Правило 3: Композитная метрика не передается между маршрутизаторами. Метрика высчитывается локально на маршрутизаторе, и существует только на нем. Далее маршрутизатор передает только измененные параметры bandwidth, delay, MTU, и т.д.

Отсюда можно сделать интересные выводы. Во-первых, раз композитная метрика не передается, становится предельно ясно, почему K-values должны совпадать для установления соседства. Иначе каждый маршрутизатор будет считать ее по своему, и не далеко до петли. Во-вторых, если рассмотреть все 5 передаваемых от хопа к хопу параметров, становится понятно, что регулировать мы можем только один – delay, так как bandwidth всегда несет минимальное значение пропускной способности по трассе, reliability и load вовсе не подходят для ручного изменения и имеют ход в сильно узком диапазоне (1-255), ну а MTU схож с bandwidth. Отсюда вывод, если мы осуществляем Traffic Engineering и регулируем метрику EIGRP с помощью offset-list’а, мы меняем только значение delay и только его, а не добавляем/отнимаем от всей метрики целиком! Предположим, что мы указали offset-list, корректирующий нашу метрику на +100. Как известно, delay задается в десятках микросекунд, значит сразу помножим на 10, получили 1000. Далее, мы знаем, что формула расчета метрики EIGRP умножает результат вычислений на 256, чтобы улучшить метрику EIGRP по сравнению с метрикой IGRP, имеющею ту же самую формулу расчета. Значит 1000 мы еще поделим на 256, и получим 3,90, сокращаем до трех. Значит, следующий маршрутизатор, получит параметр delay на 3 микросекунды больше, чем должен был без offset-list’а.

Вооружившись этой информацией, встретив на лабе CCIE R+S задачу, требующею дать преимущество одного маршрута над другим, изменением параметра delay, но по тексту задачи вам запрещено менять delay на интерфейсе, смело пишите обычный offset-list.