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

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

image

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

Правило 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, так как эмулировать их изменение мне не удалось. Буду рад, если кто то дополнит этот пост.
UPD: В комментариях подсказывают, что reliability, как и bw/mtu передается самый худший по трассе. Load, вроде бы как, суммируется, но пока не упрется в 255.

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

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

image

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

Правило 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.

UPD2: Как верно было подмечено в комментариях, MTU вообще не участвует в вычислении метрики. Однако, это один из атрибутов, который мы указываем везде, где нужно вручную указать метрику, например при редистрибуции. Изменение этого атрибута в анонсе префикса от хопа к хопу обрабатывается так же, как и атрибуты, влияющие на метрику.
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 34

    +2
    Отличная статья!

    Я честно не смог точно понять, как ведут себя от хопа к хопу reliability и load, так как эмулировать их изменение мне не удалось.

    Ну load можно манипулировать, установив для удобства небольшой BW и пустив скачку образа с другого роутера в null0. Если совсем небольшой BW ставить, то и TCP 19 можно обойтись.
    Reliability? Можно попробовать сделать duplex mismatch и погнать трафик так, чтобы ошибки начали появляться.
    Но в любом случае никто не рекомендует использовать данные метрики, уж больно трафик штормить будет. Сомневаюсь, что и на лабе RS такое попросят делать.
    Иначе каждый маршрутизатор будет считать ее по своему, и не далеко до петли.

    Петля для EIGRP — это почти что нормальное состояние и при совпадающих K :)

    Можно еще добавить кое-что:
    регулировать мы можем только один – delay, так как bandwidth всегда несет минимальное значение пропускной способности по трассе

    BW можно использовать для манипуляции трафиком. Но очень нежелательно. Типичная ошибка — слишком маленький BW, а так как EIGRP для своего служебного трафика задействует максимум 50% от BW (если мне память не изменяет), это может вызвать серьезные проблемы со сходимостью в сетях с большим числом префиксов. А вот delay ни на что не влияет кроме собственно метрики.
    И во многих топологиях с разношерстными каналами имеет смысл ставить заведомо неправильный (но достаточно высокий, чтобы не мешать обмену между соседями) BW на интерфейс с целью упрощения математики и задействования ECMP.
      0
      Петля для EIGRP — это почти что нормальное состояние и при совпадающих K :)

      Ну, почему так строго? DUAL работает достаточно неплохо. Петля конечно легко может образоваться при неаккуратной редистрибуции, особенно если она идет и в RIP, и в OSPF, и последние два тоже редистрибутят друг в друга. Но в простом eigrp домене создать петлю крайне затруднительно, благодаря feasible distance. Имхо.
        +1
        Но в простом eigrp домене создать петлю крайне затруднительно, благодаря feasible distance. Имхо.

        Да как нефиг делать. Даже без редистрибуции. И даже не используя баги, и не допуская ошибок в конфигурации, с воспроизводимостью где-то 2/3 ;) Особенно забавно это траблшутить: собрать десятки/сотни килобайт дебагов с нескольких железок и попакетно сверять, что же там EIGRP творит, от кого и в каком порядке получает UPDATE, кому шлет QUERY и получает ли REPLY, и все это с точностью до миллисекунд, до полного понимания хронологии событий и до вывода «бага не было, все вели себя корректно, просто протокол такой».

        Хотя и с багами бывает весело. Например, из-за бага в redistribute static четыре железки в кольце могут угодить в SIA, по часовой стрелке ожидая ответа от соседа. Проверено. Симптом забавный: погасил интерфейс, и через какое-то время где-то на другой стороне сети железка сбрасывает соседство, так как принадлежащий тому интерфейсу префикс взял и залип.

        В общем, не верьте бреду вроде «благодаря feasiblity condition даже кратковременные лупы невозможны, в отличие от link-state протоколов». Зато долговременные появляются вплоть до срабатывания active таймера…
          0
          Да, действительно, вы правы, про проблему с SIA я как то и забыл. Мало все же eigrp встречается в практике. SIA и перегруженные процессоры в результате каскадных query в реальной жизни видел может раз или два. Конечно, считаю, что для больших топологий с массой маршрутной информации лучше использовать link state протоколы. Там и с метрикой нет таких заморочек :).
            0
            Ну, все же конечно stub-ы спасают от лавин query, хотя, конечно я вашу топологию не знаю :)
              0
              Без стабов жизни в EIGRP нет вообще. Только как бы стаб на то и стаб, чтобы быть по краю сети.
              0
              Для SIA даже перегруженные процессоры и большая латентность не нужны, и количество префиксов особой роли не играет. Важен порядок распространения сообщений. Я бы, вероятно, смог вогнать EIGRP в SIA в топологии из 4-х железок и одного префикса (не считая линки между железками).

              Link state тоже не одинаково полезны. Я знаю контору, в который выбрали IS-IS в качестве глобального IGP, так как OSPF в их топологии работал хреново. Про EIGRP там и речи быть не могло, с тем зоопарком.
                0
                А вот это интересно. Если вы поделитесь способом вогнать 4 роутера в SIA, это наверное помогло бы мне в учении. Конечно, если это не хитрый секрет :-) поделитесь?

                А про eigrp, link state и т.д., все же согласитесь, все очень сильно зависит от дизайна сети. Конечно, может быть полно факторов, как от зоопарка железа, так до кривых реализаций протоколов. Но, все же каждый IGP надо держать под жестким контролем, иначе прощай секундная сходимость, отказоустойчиовость и масштабируемость. Какой бы не был идеальный алгоритм, границы и диаметр сети нужно ограничивать, как и распространение query/lsa и т.д.
                  0
                  Если вы поделитесь способом вогнать 4 роутера в SIA

                  Надо как-нибудь в лабе воспроизвести. Суть там в соединении двух железок двумя L3 линками и в выставлении неодинаковых delay'ев. Возможно, потребуется 5 железок, сходу не вспомню.
                • UFO just landed and posted this here
                    +1
                    Да почти ничем. В isis нет жесткой backbone зоны, через которую все обязательно должны проходить, ну и еще он независим от маршрутизируемого протокола, т.е. он может распространять маршрутную информацию как IPv4, так и IPv6, и т.д. По сути он работает на L2 поверх CLNS. По этому он немного непривычен в администрировании и обучении.
                    • UFO just landed and posted this here
                        +1
                        Не совсем конечно корректное сравнение, так как isis все же link state IGP. Но если совсем-совсем грубо, то да. Но преимущества в интеграции IPv6 сомнительны, с тем же успехом можно гонять dual stack с OSPFv3 или тем же EIGRP for IPv6. Кстати, что интересно, EIGRP изначально был разработан как протокол, который мог роутить что угодно, как IP, так и AppleTalk и IPX.
                        • UFO just landed and posted this here
                      0
                      Помимо радикальных различий в устройстве бекбона, их эксперименты показали, что и в пределах области, когда сеть широкая и с кучей колец, OSPF может сильно тормозить. Глубже я не вдавался. Сам я знаю IS-IS в рамках полузабытого курса BSCI, то есть слабо знаю :)
                        +1
                        Если коротко и сходу:

                        1. ISIS поддерживает MTR
                        2. ISIS поддерживает IPv6 (в случае с OSPF нужно поднимать отдельный протокол OSPFv3, а это дополнительная нагрузка на control plane телеком оборудования)
                        3. масштабируемость у ISIS выше (сравните ограничение LSP и LSA, которые упираются в MTU для OSPF)
                        4. ISIS использует CLNS пакеты, в то время, как OSPF IPшные. В глобальной сети Интернет, CLNS пакеты не маршрутизируются, а значит такая сеть более безопасна с точки зрения сетевой безопасности (вектор атаки снижается).
                        5. ISIS протокол открытый и для него фичи выходят раньше, чем для OSPF.
                        6. ISIS проще с точки зрения network design (не надо заморачиваться с типом area).
                        7. ISIS поддерживает приоритезацию префиксов :)

                        ну и т.д. и т.п.

                        PS: Проблема в том, что большинство людей не умеют его правильно траблшутить :-)
                          +1
                          Добавлю:

                          к пункту 5:

                          ISIS использует TLV, а OSPF использует LSA. Из реальных примеров, Forwarding Adj для ISIS реализовали раньше, механизм сигнализации BGP Wait on Start и т.д. и т.п. MPLS TE Extensions.

                          В общем для операторов c IP/MPLS бекбоном самое то ;-)
                          • UFO just landed and posted this here
                              +1
                              Я правильно понимаю, можно определённый префикс отдать в определённый линк с меньшим костом, чем на этом линке для всех остальных?

                              Нет, приоритезация префиксов не для этого. Механизм приоритезации префиксов скорее имеет отношение к конвергенции сети. В реальности это фича становится крайне полезной в очень больших сетях с большим объемом маршрутной информации и при наличии критически важных префиксов, где задержка в несколько мс может быть критичной. Например — VoIP, Video Conference, HD Video, Телеметрия и т.д. и т.п.

                              В OSPF для этого придётся с разными областями заморачиваться.

                              Заморочиться можно разными способами. Например опять же с MTR :) Но это противоречит основному принципу keep it simple.

                              Кстати, если я правильно Вас понимаю, то у Вас там IP/MPLS сеть. Хотел бы Вас предупредить, что как только Вы побьетесь на area у Вас могут появиться пролемы с функциональностью MPLS TE. Проблемы возникнут из-за потери ERO. В общем, подумайте 10 раз ;-)

                              Вообще можете посоветовать книжку с адекватным описанием IS-IS?

                              Раз — www.amazon.com/Network-Design-Solutions-Networking-Technology/dp/1578702208
                              Два — www.cisco.com/go/isis
                              • UFO just landed and posted this here
                                  0
                                  В реальности это фича становится крайне полезной в очень больших сетях с большим объемом маршрутной информации и при наличии критически важных префиксов

                                  Самые критические префиксы — это лупбеки, на которые завязан LDP :)
                                  Эта фича действительно крута.
                • UFO just landed and posted this here
                    0
                    Совершенно верно, MTU при подсчете не учитывается никак, это видно и из формулы. Я просто привел его так как это одно из значений передающихся с роутера на роутер вместе с префиксом.
                      0
                      MTU используется в качестве tie-breaker когда кол-во маршрутов с одинаковой метрикой больше значения maximum-path. Выбираются маршруты с лучшим MTU.
                    0
                    Если мне не изменяет память, EIGRP передаёт векторную метрику при изменении BW или delay. При добавлении в расчёт reliability и load это поведение не меняется.
                    То есть EIGRP будет использовать те reliability и load, которые получил когда-то давно, они могут сто раз измениться где-то там в сети, но никто об этом не узнает и метрика не изменится.
                    То есть никаких «штормов» метрики не будет. Будет просто её расчёт исходя из ранее запомненных, неактуальных, уже не нужных никому значений.
                      0
                      Да, но непонятно, будет взято худшее значение на маршруте, или оно как то будет суммироваться?
                        0
                        Reliability is the worst reliability for any interface in the path. Load is cumulative.
                        Что, в принципе, логично, поскольку 100% надёжность — уже 255, больше некуда суммировать. С загрузкой — наоборот.
                          0
                          Ясно, загрузка по ходу суммируется покуда не упрется в 255.
                            0
                            Load берется максимальный на всем пути.

                            Суммировать было бы странно. Если у нас последовательно два 10G интерфейса, и через них идет поток в 5G, то что, выкинуть весь путь из path selection?
                              0
                              • Load (K2) – Cumulative load of all outgoing interfaces in the path, given as a fraction of 255

                              Источник: www.routeralley.com/ra/docs/eigrp.pdf

                              Почему выкинуть? Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.
                                0
                                learningnetwork.cisco.com/docs/DOC-8176
                                If used, enter worst load between source and destination.

                                Оба источника неофициальные. Оба автора могут ошибаться. Надо бы потестить, но лень…

                                Ведь максимума достигла не композитная метрика, а всего лишь одно из её слагаемых.

                                Хотя тоже верно. Но все равно чистое сложение бессмысленно. Вот дробь с 255 — ближе.
                                  0
                                  Пепельняк в своей книге тоже говорит, что худший load выбирается…
                                  Да всем лень тестить, и авторам в том числе. Зачем тестить то, что использоваться точно не будет? :)
                                    0
                                    Ну как бы автор книги (особенно если Cisco Press) должен говорить как есть и отвечать за свои слова :)
                                    Но есть другой нюанс. В какой-то момент поведение Load могли и поменять…

                                    В общем, черт с ним, этим действительно никто не будет пользоваться.
                                      0
                                      Там в каждой книге в начале сказано, что мы конечно хоть и Cisco Press, но вся инфа as is, и нам как бы все равно :-). Вообще в Cisco Press литературе очень много ошибок, практически в каждой книге. От синтаксиса, до базовых понятий, недавно читал в какой то книге по дизайну, что свет распространяется со скоростью несколько миль в секунду.

                    Only users with full accounts can post comments. Log in, please.