Сделать домашней|Добавить в избранное
 

CCIENetLab - Подготовка к экзаменам
CCNA, CCNP и CCIE

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

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

Автор: Sauron от 9-06-2015, 15:38
Какие только не приходилось читать статьи про композитную метрику EIGRP. В данной статье мы постараемся рассмотреть интересные особенности и хитрости подсчета этой самой композитной метрики. А для этого вспомним кошмарную формулу

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

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

Правило 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,то как и bw/mtu передается самый худший по трассе. Load - суммируется, но пока не упрется в 255.

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

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

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

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

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

Причем MTU вообще не участвует в вычислении метрики. Однако, это один из атрибутов, который мы указываем везде, где нужно вручную указать метрику, например при редистрибуции. Изменение этого атрибута в анонсе префикса от хопа к хопу обрабатывается так же, как и атрибуты, влияющие на метрику.

Отсюда можно сделать интересные выводы. Во-первых, раз композитная метрика не передается, становится предельно ясно, почему K-values должны совпадать для установления соседства. Иначе каждый маршрутизатор будет считать ее по своему, и не далеко до петли.
Во-вторых, если рассмотреть все 5 передаваемых от хопа к хопу параметров, становится понятно, что регулировать мы можем только один – delay, так как bandwidth всегда несет минимальное значение пропускной способности по трассе, reliability и load вовсе не подходят для ручного изменения и имеют ход в сильно узком диапазоне (1-255), ну а MTU вообще не участвует в формировании метрики.

Отсюда вывод, если мы осуществляем 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.

Источник: http://habrahabr.ru/post/176831/скачать dle 10.6фильмы бесплатно
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Комментарии:

Оставить комментарий
 

CCIENetLab (C)