EIGRP

Протокол RIP Протокол RIP

Протокол RIP Протокол RIP Протокол RIP Это действительно было много полосы, которая отъедалась для самой работы протокола RIP. Мы запускаем RIP не для того, чтобы просто он у нас работал. Мы хотим, чтобы у нас трафик ходил через интерфейсы, которыми соединены роутеры, а по факту RIP эти интерфейсы занимал под свои нужды, и под боевой трафик, который мог пройти теперь уже через цепочку роутеров в правильном направлении, оставалось совсем мало полосы. И если мы говорили, что лучше отправим боевые пакеты вместо RIP-овских пакетов, апдейтов, тогда получалось, что у нас маршруты не построятся и трафик ходить не сможет. Если мы говорим, давайте RIP пропускать в первую очередь, то у нас боевые пакеты перестают ходить. RIP получался такой дурацкий протокол, потому что он действительно ел много-много полосы. Для того чтобы побороть эту проблему, придумывали какие-то механизмы,

как сделать так, чтобы занимать полосу не так сильно. И самое очевидное, что придумалось, — это OSPF. Поэтому вы, наверное, сегодня можете встретить песенку типа «Route your network with OSPF» на мотив Village People. Но тем не менее. Смысл там был тот, что не надо использовать RIP, надо использовать OSPF, потому что он во всех отношениях лучше. Действительно, когда появился OSPF, он был во всех отношениях лучше RIP. Он требовал меньше полосы, он лучше сходился, он быстрее реагировал на изменения, но у него была одна большая-пребольшая проблема. Он был вычислительно сложный. И когда технологии шагнули достаточно вперёд, чтобы запускать экземпляр достаточно сложного протокола OSPF на каждой железке, OSPF начал бурно развиваться. Но это был не единственный протокол, который начал бурно развиваться. Параллельно с RIP другие проблемы, которые были в RIP, решала Cisco с помощью протокола IGRP.

Когда был RIP, у него были проблемы, связанные с полосой, у него были проблемы, связанные с медленным реагированием на изменения, но ещё у него были проблемы, которые не решал OSPF. У него были проблемы, например, что в качестве метрики степени хорошести/плохости маршрута RIP использует просто количество прыжков между роутерами. И даже если мы можем немножко поиграть этими метриками, например, отправлять метрику не такую, как у нас в таблице, а немножко побольше — допустим, у нас в таблице маршрутизации у RIP метрика 4, а вы можете рассказывать своим соседям, что у вас на самом деле не 4, а 6 или 7. Но всё равно вы ограничены будете максимальной метрикой 15, которая в RIP есть. Если вы хотите играть более-менее гранулярно этими метриками, то RIP уже не подходит.

И Cisco предложила решение тех проблем, чтобы можно было гранулярно играть метриками, и она предложила играть даже не одной метрикой, а несколькими, чтобы можно было передавать внутри апдейтов с помощью такого же механизма, как RIP, просто тупо раз в 30 секунд гонять апдейты. Но она сказала, давайте гонять метрики более продвинутые и давайте рассказывать про то, с какими свойствами мы знаем удалённую сеть. Не просто сколько прыжков между роутерами до удалённой сети, а какой bandwidth до неё, какой delay до неё суммарный, какие у неё всякие свойства. И этот механизм позволил решить другие проблемы в RIP, которые OSPF, в свою очередь, никак не решал. И когда появился OSPF, все дружно посмотрели на Cisco и сказали: «Cisco, а что ты сделаешь в ответ?» OSPF, стандартный протокол, решает проблемы, которые были в RIP. Ты для того, чтобы решить другие проблемы в RIP, предложила протокол IGRP, но медленность его работы и полосу пропускания, которую он жрёт,

ты никак не решила, что ты в ответ предложишь? В 92-м году, примерно тогда же, когда появились бесклассовые сети, Cisco выкатила протокол EIGRP, Enhanced IGRP, который во всех отношениях лучше, чем IGRP, который, в свою очередь, в некоторых отношениях лучше, чем RIP. И получается, что EIGRP — фактически конкурент OSPF в некотором смысле, потому что они напрямую не сравниваются. Абсолютно разные протоколы, абсолютно по-разному работают и изначально решали абсолютно разные задачи. Так. Что про EIGRP можно рассказать? EIGRP изначально создавался как бесклассовый протокол. EIGRP изначально использовал мультикаст, в отличие от IGRP, который по образу и подобию RIP, на тот момент существующего RIP первой версии, использовал бродкаст. В EIGRP можно как в IPv4, так и в IPv6

использовать мультикаст, который заканчивается на число 10. 224.0.0.10 или FF02::A, если мы говорим про IPv6. EIGRP использует специальный свой собственный транспортный протокол. Он не использует TCP, не использует UDP. Он складывается напрямую в IP, и номер вложения у него будет 88. У него, в отличие от IGRP, уже не будет такого, что мы просто по таймеру раз в 30 секунд отправляем целиком таблицу. Он будет отправлять дельты относительно предыдущего изменения. Для того чтобы отправлять дельты относительно предыдущего состояния, нужно будет убедиться, что все предыдущие изменения, которые были отосланы соседу, сосед принял. И поэтому в EIGRP появляется концепция соседей. В IGRP, равно как и в RIP, концепции соседства не было. А в EIGRP она необходима, потому что мы должны будем знать,

что сосед знает о нашей таблице топологии, для того чтобы не отсылать ему всю таблицу топологии, а отослать только то, чего он не знает. И для того чтобы отсылать инкрементальные дельты, нужно будет знать, что знает сосед. Здесь появляется сразу вопрос. Если у нас есть несколько соседей на одном и том же интерфейсе, что делать? Отсылать им всем одинаковые дельты? Получится, что мы опять много полосы теряем. Если у нас на одном интерфейсе 10 соседних роутеров, то было бы интереснее им как раз мультикаст отправить. И мы можем отправить мультикаст. EIGRP может использовать мультикаст для доставки дельты. Но возникает опять вопрос: а что делать, если кто-то эту дельту не получил? Все получили, кроме одного. Сразу ответ: придётся ему адресно допослать то, чего не хватает, но уже не мультикастом, чтобы всех не напрягать, а юникастом. Поэтому EIGRP будет часть трафика посылать мультикастом, часть трафика юникастом. И заранее сказать, что конкретно будет отправляться мультикастом,

а что конкретно юникастом, довольно сложно. Там сложные правила. Но в целом, что можно отправить всем сразу и одновременно, то, как правило, отправляется мультикастом. У EIGRP будет использоваться концепция feasible successors, то есть те маршруты, которые заведомо не содержат петлю через нас. Мы с помощью простейшего метода проверки на петлю выясняем, что некоторые маршруты заведомо хорошие для того, чтобы по ним отправлять трафик. Они заведомо не проходят через нас. И если мы предполагаем, что все роутеры выполняют такую проверку на петлю, то мы предполагаем, что мы отправим пакет соседу, сосед отправит своему соседу, тот отправит своему соседу, и ни в какой момент петли не получится. EIGRP будет практически гарантировать защиту от того, что у вас трафик в какой-то момент запетлится. Не то чтобы это была стопроцентная защита, потому что с помощью костылей EIGRP можно заставить устроить петлю маршрутизации, причём даже стабильную петлю,

но это надо действительно умышленно пытаться вредить самому себе и умышленно заставлять роутеры делать действия, которые приведут к петле. В большинстве случаев у EIGRP будет наготове запасной маршрут. Если у вас есть несколько маршрутов, которые не одинаково хорошие, один маршрут вы будете добавлять в таблицу маршрутизации или несколько маршрутов, а остальные маршруты, которые достаточно хорошие для того, чтобы по ним отправлять трафик сразу, вы держите про запас, вы про них помните. RIP не помнит про те маршруты, которые присылают ему какие-то соседи. Он говорит: я держу в таблице маршрутизации только один, и если вдруг он сдохнет, тогда я буду ждать очередной апдейт и буду посылать трафик на тот апдейт, который приходит следующим. А EIGRP сразу говорит: у меня пропал основной маршрут, я сразу со скамейки запасных достаю запасной маршрут, который точно заведомо хороший, по которому точно можно посылать трафик. В большинстве ситуаций эта штука позволяет отреагировать на изменения в топологии практически мгновенно.

Никакому другому протоколу такие скорости, которые может показать EIGRP, не снились. Если говорить про OSPF, он на самом деле далеко не такой быстрый протокол, каким хочет казаться. У него для оптимизации работы есть огромное количество специальных замедляющих таймеров. Если их все выключить, OSPF будет весьма быстро работать, но это приведёт к тому, что он окажется в очень уязвимом положении. Если вдруг в сети начнут где-то что-то глючить, OSPF сразу сдохнет по перегрузке. А у EIGRP таких проблем нет, у него всегда сразу наготове может быть запасной маршрут. А если запасного маршрута хорошего нету, но есть плохой, который потенциально может содержать петлю через нас, то мы можем запустить алгоритм DUAL для того, чтобы выяснить, есть ли действительно маршрут, который не содержит петлю через нас, или такого маршрута нет. DUAL будет называться Diffusing Update Algorithm, то есть алгоритм распространения апдейтов с помощью аналога диффузии.

Когда мы такие Diffusing Update отправляем, и они начинают разбегаться по всей сети. Апдейты можно отправлять про то, что сеть появилась, или апдейт можно отправлять про то, что сети у вас больше нет. Если она есть у кого-то ещё, то это же является запросом: а нет ли у кого-нибудь живого маршрута в эту сеть? У EIGRP за счёт запасного маршрута, который в таблице топологии лежит и ждёт своего часа, есть возможность сделать такую штуку, которой нет ни у кого другого. Это балансировка по нескольким маршрутам, в том числе и с неодинаковой стоимостью. Все остальные протоколы, которые мы с вами изучаем, RIP, OSPF, они не позволяют балансировать трафик по маршрутам с неравной стоимостью. Они говорят, что у нас есть маршрут, у которого наименьшая метрика, и он заведомо не содержит петлю. А все остальные маршруты по определению даже не считаются. Мы не можем даже посчитать маршрут, который будет не такой же хороший, как основной, и тоже не содержать петлю.

OSPF с помощью костылей можно заставить посчитать, но RIP, допустим, никак не посчитаешь. RIP нельзя заставить посчитать такой маршрут, который не содержит петлю через нас. Поэтому в EIGRP за счёт feasibility condition мы можем заранее сказать, что какой-то апдейт, который приходит к нам от соседей, заведомо не содержит петлю. И мы, если знаем, что у нас есть хороший маршрут и несколько маршрутов, которые похожи по степени хорошести, можем в таблицу маршрутизации добавить все, в предположении, что они не проходят через нас. И тогда у нас будет балансировка через несколько неодинаковых маршрутов, неодинаковых по метрике. Эта штука называется UCMP, Unequal Cost Multipath, и она уникальная для EIGRP. Изначально EIGRP, конечно, был фирменный цисковский протокол, но он был опубликован. И сейчас теоретически любой желающий может попробовать его реализовать. В 2013 году Cisco открыла часть спецификаций на этот протокол, и в 2016 году вышел RFC 7868,

который рассказывает, как стандартным образом подходить к построению реализации EIGRP. Но не про всё он рассказывает, а только про некоторые аспекты. А самое вкусное Cisco до сих пор скрывает. Не то чтобы это как-то запрещало тем, кто захочет, реализовать у себя что-то подобное. Например, те же стабы. Они в RFC не описаны никак, а в цисковской реализации они, конечно же, есть. Если вдруг кто-то будет реализовывать EIGRP у себя, то ему предстоит решить для себя большую проблему: как делать аналогичную концепцию, которая не опубликована, но которая есть в Cisco? Сделать ли её по наитию, попытаться реверснуть код и угадать, что там имелось в виду, или как-то иначе? Задача нелёгкая, прямо скажем. Cisco, конечно, сделала очень красиво, что опубликовала этот протокол, но по факту альтернатив на оборудовании других вендоров,

кроме как на Cisco, у EIGRP нет. Есть реализация FRRouting, и это всё. Больше EIGRP ни у кого нет. У EIGRP, как уже говорилось, дистанс-векторная природа. Он основан на протоколе IGRP, который, в свою очередь, основан на протоколе RIP. Иногда Cisco, для того чтобы показать, что RIP — это не то же самое, что EIGRP, прямо совсем не то же самое, старается EIGRP выделить в какую-то отдельную когорту, отдельную категорию. Она говорит, что EIGRP — это протокол, например, гибридный или advanced distance vector. Но от этого суть не меняется. EIGRP — это классический дистанционно-векторный протокол. Напомню суть дистанционно-векторных протоколов. Это такой протокол, который обменивается кусками таблицы маршрутизации, маршрутами. И по каждому маршруту он рассказывает, с какими свойствами, с какими метриками этот маршрут известен. Дальше принимающий роутер, когда видит такое обновление,

пытается понять, с какими свойствами, с какими метриками известен сам сосед, который прислал такой маршрут. И затем складываются два вектора, вектора метрик, и получается результирующий вектор. Например, в RIP у нас есть очень простая метрика — это количество прыжков между роутерами. Каждый сосед, который присылает нам в RIP маршрут, известен по определению за один прыжок. Если он говорит, что знает сетку за пять прыжков, мы складываем 5 и 1 и получаем 6. И ставим себе в таблицу маршрутизации указание, что сетка известна за 6 прыжков. В EIGRP природа вектора метрик намного более сложная. Там вектор будет уже не одномерный, и правило сложения векторов будет уже не просто «берём отдельные компоненты и складываем», а какое-то более сложное. Каждый вектор будет состоять из следующих компонентов. Первый компонент — это bandwidth. Полоса пропускания до удалённой сети. Роутеры, которые будут передавать друг другу указания, как они знают сеть,

они будут говорить, с какой полосой пропускания они знают эту сетку. Дальше принимающий роутер будет сравнивать это значение с тем, с какой полосой пропускания он знает соседа, который прислал этот маршрут. Из этих двух значений будет выбираться минимальное значение. И дальше в таблицу маршрутизации сетка будет добавляться с указанием этого минимального значения. В итоге получится, что передавая указание о том, что какая-то сеть известна, она будет передаваться, передаваться, передаваться. И в этих diffusing апдейтах будет передаваться в том числе и минимальная полоса пропускания среди всех транзитных интерфейсов. Этот компонент будет 24-битный и выражаться он будет в килобитах. 24 бита нам дают возможность вложить туда от единицы до 16 миллионов 777 тысяч 215. Это максимальное значение, которое можно положить в bandwidth.

Но если мы говорим, что выражается это всё в килобитах, то получается, что это максимальная полоса пропускания в битах, которая может быть на интерфейсе. Это 16 гигабит с копейками в секунду. EIGRP классически не различает bandwidth интерфейсов, у которых полоса больше, чем 16 гигабит. Если вы берёте 10-гигабитные интерфейсы, EIGRP сможет понять, что bandwidth у него достаточно большой. Но если вы сравните 10-гигабитный интерфейс и 20-гигабитный или 40-гигабитный интерфейс, с точки зрения EIGRP они будут одинаковые. У них максимально большой bandwidth, потому что просто в 24 бита больше, чем 16 гигабит, вложить не получится. Дальше. Второй компонент — это delay. Суммарная задержка на транзитных интерфейсах.

Когда у нас есть роутеры, которые друг другу передают указание, что сетка доступна, они указывают задержку. И эта задержка называется задержкой сериализации. Они могут указывать любую другую задержку. Логически подходя к вопросу, эта задержка должна быть такой, что если роутер знает, сколько именно времени требуется на то, чтобы обработать пакет, который через него проходит, и отправить его дальше, нужно, конечно, будет указывать эту задержку по-честному. Но роутер, на котором просто запустили EIGRP, он может посчитать среди всех возможных задержек только одну задержку по-честному — эту задержку сериализации. Когда пакет попадает в очередь на отправку на какой-то конкретный интерфейс, он попадает в очередь, дальше доходит его очередь на отправку, и пакет должен так называемую сериализацию пройти. Он должен разделиться на отдельные битики, должны добавиться какие-то служебные биты,

которые нужны для отправки данных по сети, и дальше уже пакет должен отправиться в виде отдельных битиков в сеть. На большинстве устройств задержка этого процесса будет довольно большая. Не то что прям космически большая, но она всё-таки будет заметная. Там будут порядка миллисекунд задержки. Для большинства ситуаций это будет достаточно большая задержка. И по умолчанию delay как раз будет оперировать этими самыми задержками сериализации на транзитных интерфейсах, через которые проходит пакет. Но, естественно, эти самые задержки сериализации — это не самый большой компонент в суммарных задержках, которые пакет будет испытывать при транзите по сети. Естественно, задержки, связанные с очередями QoS, с тем, что мы не можем одновременно отправить несколько пакетов, и пакеты по факту будут складываться в буферы, а дальше из буфера будут забираться по мере опустошения этого самого буфера. Если мы положили пакет сейчас в пустую очередь, он обрабатывается с одной задержкой.

Если мы положили пакет в очередь, которая почти заполнена, это совершенно другая будет задержка. Но здесь по умолчанию считаются только задержки сериализации, которые предсказуемы, которые можно заранее посчитать. На современных роутерах эта самая задержка сериализации будет, в принципе, достаточно маленькой. Если мы говорим даже про 100-мегабитные интерфейсы, если память мне не изменяет, она там что-то типа 100 микросекунд. В общем, немного. Но тогда, когда всё это дело придумывалось, а придумывался этот вектор в протоколе IGRP, это штука конца 80-х, задержки сериализации были большие. Они были там порядка полусекунды. Это было реально много. И поэтому суммарная задержка на все транзитные пути внутри роутера была небольшой, а задержка сериализации была как раз большой. Поэтому в основном считалась именно она. На современных роутерах смысла в этой задержке

в том виде, в котором она сейчас есть, особого нету. И если вы хотите, чтобы задержка считалась прямо по-честному, вам её придётся ручками подкручивать. Вы можете это сделать. Вам доступно редактирование этой самой задержки. Это чисто информационная величина, которая нужна только для EIGRP. Она больше ни на что не влияет. Вы можете, если хотите, сказать, что трафик, который проходит через наш роутер, на самом деле будет испытывать задержку, и дальше вы выставляете любое значение, которое вам больше нравится. Задержка разная на интерфейсах разной природы Разный bandwidth не влияет напрямую на задержку сериализации Но в целом прослеживается, что чем более быстрый интерфейс Тем меньше у него, как правило, задержка сериализации Просто потому, что он, скорее всего, выпущен позже И технологии, которые были на момент его выпуска Уже позволяли сделать более быструю саму процедуру сериализации Так, дальше, что еще?

Этот вектор метрик наследуется, как я уже сказал, от протокола IGRP Так, много нарисовал Вот такой вектор там на самом деле IGRP Древний протокол, классовый, который рассказывал про то, что в сети есть какие-то маршруты Но в IGRP были еще замечательные вещи Можно было посчитать максимальную загрузку среди всех транзитных интерфейсов У вас были роутеры, которые связаны в цепочку между собой И они друг другу рассказывали, что известна какая-то сеть И они рассказывали, через какие интерфейсы проходит маршрут Но не все интерфейсы рассказывали — не то что сначала мы отправляем трафик Васе Потом он Пете, потом тот Коле, потом тот Серёже Они рассказывали про то, что на самом деле важно Потому что транзитному роутеру не сильно важно, что маршрут проходит через Васю, Петю, Колю, Серёжу Маршрутизатору важно, что маршрут проходит, например, через загруженный интерфейс И возможны потери кадров

И IGRP в качестве одного из компонентов метрики передавал максимальную загрузку Среди всех транзитных интерфейсов Если у нас есть роутер, у него есть доступ к какой-то сети Он говорит, я знаю сетку А И он говорит, у меня эта сетка не загружена Здесь 0% загрузки Он передаёт указание 0% Дальше роутер, который принимает такой апдейт Говорит, я принимаю этот апдейт через интерфейс И у меня на этом интерфейсе отправка трафика занимает достаточно большую часть от его полосы Например, 40% И он говорит, среди всех интерфейсов, которые у нас есть в цепочке Максимальная загрузка будет составлять 40% Он дальше отправляет указания Сетка доступна через интерфейсы, самый загруженный из которых будет 40% Дальше этот роутер говорит А у меня этот интерфейс на отправку занимает 20% Но 20% меньше, чем 40% Поэтому самый загруженный интерфейс цепочки будет по-прежнему 40% И так далее

Этот, допустим, через 50% знает Он говорит, сосед знает маршрут через 40% загруженный интерфейс А у меня маршрут на соседа 50% загруженный Поэтому дальше я буду анонсировать за 50% Максимальная загрузка среди всех транзитных интерфейсов Так же минимальный bandwidth считается точно аналогично Когда мы говорим, что у нас сетка доступна с таким-то bandwidth, с таким-то delay Мы выбираем сначала минимальный bandwidth среди того, что прислал сосед И того, через что мы знаем соседа Задержка складывается суммарно Сетка известна за 10 миллисекунд Сосед известен за одну миллисекунду За одну миллисекунду Соответственно, 10 миллисекунд плюс 1 миллисекунда получается 11 Дальше следующий сосед тоже за 10 миллисекунд Он анонсирует 21 миллисекунду Следующий за одну миллисекунду знает Он говорит 22 миллисекунды Просто суммируется всё это Reliability — это тоже IGRP-шная метрика

Которая рассказывала про то, насколько вероятны ошибки на интерфейсе И опять же, не про все интерфейсы отдельно рассказывала А давала наиболее актуальную информацию про самый проблемный интерфейс в цепочке Она говорила У нас есть сетка А И интерфейс, который в неё смотрит, даёт вероятность ошибки 10% Каждый десятый пакет, через этот интерфейс отправляемый Не отправляется На нём есть ошибки И мы анонсируем, что сетка доступна с 90% reliability 90% reliability, 90% reliability Update доходит до соседа Сосед знает того, кто прислал такой маршрут Через 100% надёжный интерфейс Там никаких проблем нету, никаких ошибок нету Но сетка доступна с 90% надёжностью Пусть и через соседа 100% надёжности Мы говорим, мы знаем сетку с 90% надёжностью Следующий сосед сидит через интерфейс, на котором 80% надёжности

Каждый пятый пакет теряется И, соответственно, да Мы знаем сетку с 90% надёжностью Сосед известен с 80% надёжностью Выбираем наименьшее значение Говорим 80% надёжности Сетка известна И так далее по цепочке Минимальная надёжность среди всех транзитных интерфейсов Мы берём вектор того, что прислал сосед И отдельно с компонентами работаем Bandwidth считаем минимальное значение Delay складываем Load считаем максимальное Reliability считаем минимальное MTU, да, MTU в EIGRP тоже передаётся Тоже считается минимальное Опять же, тяжёлое наследие IGRP протокола Заставляет нас считать этот самый MTU Например, этот интерфейс говорит, что у нас есть сетка А И MTU на нём 1500 байт Нормальный обычный MTU Это всё отправляется соседу Сосед говорит, я знаю, что в апдейте пришло 1500 байт Но интерфейс, который у меня на соседа смотрит На нём, например, PPPoE И MTU там 1492 байта

И дальше он говорит, я знаю сетку за 1492 байта MTU Следующий там знает за 1500 Опять же, нормальный обычный интерфейс Но поскольку максимальный допустимый размер пакета Который будет отправляться через транзитную цепочку Не может превышать 1492 байта Потому что дальше он где-то в следующем интерфейсе Иначе застрянет Мы говорим, мы знаем сетку за 1492 байта И этот MTU считается Хотя по факту нигде, вообще нигде Никогда, ни при каких условиях не проверяется Вы просто считаете и всё В IGRP этот самый MTU считался с определённой целью IGRP, так же как и протокол RIP Включался на всех интерфейсах Поэтому если у вас был интерфейс, смотрящий на пользователей Вы на этом интерфейсе включали IGRP И IGRP-шные апдейты у вас доходили до конечных абонентов И в оригинальном протоколе IGRP была красивая логика Вы догоняли апдейты до конечных абонентов

Вы конечному абоненту строили таблицу маршрутизации В которой был не просто дефолтный маршрут Что весь трафик посылай на шлюз А конечный узел, прямо обычный абонент Имел в голове полную таблицу маршрутизации И до каждой сетки он считал отдельный MTU Который был известен через IGRP И он мог в этом случае Кастомный MTU делать для пакетов Отправляемых по разным маршрутам Он говорил, у меня есть интерфейс Который смотрит на соседний роутер И я знаю, что если я буду отправлять пакеты Васе Который находится в одной сети Мне нужно сделать пакеты не больше, чем 1492 байта А если я буду делать пакеты Пете Который тоже через тот же самый шлюз сидит Но он в другой сети, которая по другой трассе идёт Мне нужно делать пакеты до 1500 байт размером Идея, как вы понимаете, не очень взлетела Потому что IGRP сегодня не используется И до обычных хостов мы IGRP апдейты больше не отправляем А дружить полноценно с каждым отдельным соседом Тоже не очень здравая идея

Поэтому MTU до сих пор считается Но считается исключительно по инерции Для того, чтобы вы могли EIGRP-шный роутер Подключить в EIGRP-шную сеть И он бы у вас получил что-то ценное Что-то ценное Поэтому MTU считается в векторе метрик Он передаётся, он считается Но на выбор маршрутов в EIGRP он никак не влияет Не отсюда растут ноги у MTU на маршрут в Linux Там много где растут ноги на самом деле Изначально-то в голове у каждого IP-узла Должна быть полная таблица маршрутизации Это потом придумали халяву Типа, давайте некоторые сетки делать default-нетворками Давайте делать шлюз по умолчанию Маршрут по умолчанию Давайте делать шлюз по умолчанию Маршрут 0.0.0.0 Это уже всё более позднее В оригинале, конечно, у всех узлов должна была быть полная таблица В которой они указывали, кто до кого, как, каким образом смотрит Изначально эту таблицу вообще надо было руками пополнять Вот Ещё из того, что интересно

В EIGRP был такой параметр hopcount Который нужен был в ситуации Когда нужно было сравнить два маршрута И если вдруг вам нужно было EIGRP заставить себя вести как RIP Чтобы он оперировал количеством прыжков между роутерами Чтобы EIGRP мог себя достаточно уверенно чувствовать Он бы выбирал маршрут по хорошести-плохости Так же, как RIP, если вдруг вам это было нужно Но в EIGRP этот параметр, опять же, не влияет на выбор маршрута Никоим образом Хотя он некоторым образом будет влиять На то, будем ли мы признавать маршрут вообще правильным В EIGRP, равно как и в IGRP Есть лимит на значение поля hopcount Если к вам приходит маршрут И в этом маршруте написано, что hopcount будет 99 Это значит, что это бесконечность Hopcount 100, который получится, если вы к 99 прибавите единичку

Будет означать, что маршрут по факту недоступен Опять же, hopcount не влияет на выбор маршрута Из двух одинаковых визуально маршрутов Если все компоненты равны, а hopcount у них отличается Но всё-таки меньше, чем 99 То оба маршрута будут признаны одинаковыми Но тем не менее Считается, передаётся И работает точно так же, как в IGRP работает единственный компонент метрики Эти самые компоненты Они входят в стандартный вектор метрик EIGRP В EIGRP, начиная с Если мне память не изменяет Основного модуля 8.0 То есть с IOS 11.0, по-моему Вот такой старый-старый IOS Появилась возможность ещё два компонента в этот вектор добавить Это уже будет EIGRP-шная часть

И там добавились Jitter и Energy Jitter — если вдруг ваш роутер умеет измерять средний Jitter на интерфейсе Среднее время — вы кладёте кадр в очередь на отправку данных в интерфейс И дальше вы знаете, какой размер этой очереди И вы можете померить Если вы положите пакет в очередь и она окажется пустая И пакет, который вы кладёте в очередь, и она почти полная Сколько времени будет разницы между отправкой этих двух пакетов И Jitter — это как раз максимальный разброс времени Держания пакетов в очереди И Energy — это суммарные затраты энергии на передачу данных по определённому интерфейсу В некоторых ситуациях вы действительно будете весьма озабочены тем, чтобы тратить как можно меньше электричества при отправке пакетов Если у вас данных реально много И вы отправляете данные через какие-то каналы, которые весьма затратные

Понятное дело, что на передачу одного битика вы не будете тратить очень много энергии Но если речь идёт про терабайты данных и энергия у вас достаточно дорогая То вы уже задумаетесь, как бы нам сделать так, чтобы денег потратить поменьше И можно будет заставить EIGRP в качестве метрики хорошести-плохости маршрута Учитывать также то, сколько денег вы затратите на передачу данных от узла А до узла Б И будете выбирать маршрут, например, наиболее дешёвый Вот По умолчанию Jitter и Energy не считаются По очевидной причине Изначально EIGRP, когда работает, работает в IGRP-шных метриках Так, далее, далее, далее Итак, давайте разбираться, как работает EIGRP Краткая реклама, которую я ему дал, должна была вас убедить

Что EIGRP действительно прикольный протокол, он действительно прикольный Но давайте не будем верить мне на слово Давайте изучать, как он работает Чтобы потом понимать, почему он прикольный Чем он отличается от RIP, чем он отличается от OSPF И первое, что приходит нам в голову, когда мы говорим про EIGRP Это как раз необходимость отсылать дельты И, как следствие, необходимость знать, с кем конкретно мы работаем Для того, чтобы понимать то, что мы сейчас будем соседу посылать Что именно мы должны будем ему послать Чего он от нас ещё не знает И что от нас он уже слышал У нас возникает необходимость помнить, с кем мы работаем Более того, у нас возникает необходимость для каждого отдельного соседа Вести учёт того, что мы ему уже отправили и что мы ему ещё не отправили Что мы ему собираемся отправить У нас на отдельном интерфейсе может быть необходимость отправить данные нескольким соседям одновременно Например, у нас есть интерфейс

Мы в одном интерфейсе видим двух или трёх разных соседей Лучше трёх Отправили мультикастом сообщение Ребят, у нас появилось изменение Ловите его, пожалуйста Нам это изменение подтвердил только один сосед Соответственно, мы должны будем доотправить это изменение ещё двум соседям Но уже не мультикастом, а адресно-юникастом Мы должны будем сначала отправить эти данные одному, потом второму И получается, что мы должны каждого отдельного соседа учитывать в табличке Знать, что мы ему уже отправили и что мы ему ещё не отправили Для того, чтобы потом отправить при необходимости EIGRP будет знать всех соседей наперечёт У него будет таблица соседей И в эту таблицу заносить соседей EIGRP будет на основании очень простого критерия Если сосед с нами настроен непротиворечиво И с соседом есть двусторонняя связность Вы делаете это путём обмена hello-сообщениями Мультикастовые сообщения, которые вы отправляете в интерфейс

Они доходят до всех соседей, до всех роутеров Они вам отвечают, да, привет, я тебя вижу Примерно так же, как это было у нас в OSPF Плюс-минус километр И если мы видим, что с соседом у нас есть двусторонняя связность То мы его добавляем в табличку соседей И примерно сразу же запоминаем, с какими свойствами мы знаем этого соседа Допустим, у нас есть на картинке роутер Который дружит с двумя соседними роутерами На одном интерфейсе у него есть роутер R1 Который присылает hello-сообщение ему А мы ему в свою очередь тоже посылаем hello-сообщение И поэтому мы убеждаемся, что есть двусторонняя связность И на другом интерфейсе у нас hello-сообщение бегает между нашим роутером и R2 Давайте назовём его роутер R Hello-сообщение на каждом интерфейсе мы отправляем по таймеру Таймер будет работать следующим образом На интерфейсах, которые достаточно быстрые У которых производительность быстрее, чем T1

Быстрее, чем 1546 килобит в секунду 1544 килобит в секунду Если у вас канал быстрее, чем T1 Быстрее, чем Serial Link То hello-таймер там по умолчанию 5 секунд Если у вас интерфейс медленнее, чем T1 Вы bandwidth на нем подкрутили И выяснилось, что интерфейс у вас там 1000 килобит в секунду Или 1 мегабит в секунду То таймер увеличивается И, соответственно, вы отправляете hello-сообщение Реже на этом интерфейсе Будет 60 секунд Если равен T1, по-моему, быстрее считается Если он ровно T1, ровно Serial Link То 5 секунд Но это надо проверить Я, честно говоря, не помню Эта пограничная ситуация Что именно с Serial Link На всякий случай не помню Но если вы на Serial Link чуть-чуть открутите bandwidth вниз То, соответственно, таймер точно будет 60 секунд

Hello-сообщение мы отправляем И если эти hello-сообщения доходят до соседа То он заносит нас в табличку Проверяя, что есть двусторонняя связность И маршруты, которые от нас приходят Он запоминает в таблице соседей Да, 1544, как уже было написано Есть нюанс То, что мы один раз подтвердили Что с нами есть двусторонняя связность Не означает, что эта двусторонняя связность С нами будет постоянно Поэтому если вдруг у нас сообщение hello В течение некоторого времени не проходит Мы потеряли связь с этим соседом То мы рвем соседство И по умолчанию это происходит спустя время Которое называется hold time По умолчанию он равен трехкратному таймеру hello Если у нас интерфейс быстрый То, соответственно, 5 секунд умножить на 3

Будет 15 секунд Если у нас интерфейс медленный 60 секунд То, соответственно, 180 секунд или 3 минуты Можно подкрутить отдельно hello time Можно подкрутить отдельно hold time Это как раз то, сколько времени мы будем ждать сообщения от соседа Если мы ему даже ничего не отправляли Если он нам присылал hello-пакет, а потом перестал Таймеры назначаются на уровне интерфейса И таймеры указываются отправляющим роутером Мы на роутере R1, допустим, прописываем таймеры Вместо 5/15 мы говорим, у нас будет 4/12 И мы отправляем hello-сообщение Мы это делаем раз в 4 секунды И мы говорим, через 12 секунд считайте меня пропавшим Если я не присылаю никаких новых апдейтов Неважно, какие на роутере R настроены настройки Когда роутер присылает нам hello-пакет Он в этом hello-пакете пишет, сколько секунд нужно ждать Перед тем, как именно этот роутер пришлет еще hello-пакет

На роутере R1 настроены у нас 4/12 На роутере R Могут быть другие настройки, не знаю, 60/180 Они явно не совпадают Более того, hold time на одном роутере явно меньше, чем hello time на другом роутере Никаких проблем не будет Потому что R1 посылает сообщение раз в 4 секунды с указанием Я должен в течение следующих 12 секунд что-то прислать Роутер R присылает сообщение, где говорит Я буду посылать сообщение и через 180 секунд Если я ничего не пришлю, вы отвергаете меня из таблицы соседей Но он при этом посылает раз в 60 секунд Таймеры не обязаны совпадать И логика заключается в том, что отправляющий hello-пакет роутер Указывает, через сколько должно прийти следующее hello-сообщение Самое позднее, скажем Одно может потеряться, второе может потеряться, третье может потеряться Но если уж три потерялось, значит не судьба Значит, надо рвать соседство Эта концепция немножко отличается от, например, таймеров в OSPF

В OSPF таймеры просто должны совпадать Там, если у вас настроены таймеры не одинаково, соседство не получится установить Потому что в hello-сообщениях просто указывается, какие у вас таймеры hello и dead timer Если они не совпадают, соседство не устанавливается Здесь соседство установится и будет работать Даже несмотря на то, что эти таймеры у вас могут сильно не совпадать Очень сильно Забегая немножко вперед, вы можете себе выстрелить в ногу И поставить таймер hello больше, чем hold time На некоторых платформах это допустимо И вы таким образом отправляете hello-пакет У вас устанавливается соседство А потом следующее hello не приходит вовремя И еще следующее не приходит вовремя И еще следующее не приходит вовремя И в течение hold time, который у вас маленький Соответственно, ни одного hello не приходит И вы говорите, у нас все сломалось А потом приходит новое сообщение Если вы выставите, допустим, hello time, не знаю, 10 секунд А hold time 5 секунд У вас отправляется hello-сообщение

Роутер соседа ждет положенные свои 5 секунд Ничего следующего не видит Рвет сессию, рвет соседство И еще через 5 секунд приходит новое hello-сообщение Снова соседство устанавливается Не надо так делать Хотя технически это возможно Поставить hello больше, чем hold time По факту этого делать просто не нужно После того, как соседство устанавливается В табличку соседей мы заносим IP-адрес соседа Мы заносим интерфейс, на котором мы установили соседство И с этого интерфейса берем настройки Какой у него bandwidth, какой у него delay Какой у него reliability, load и прочее На уровне каждого соседа мы эту информацию запоминаем Важное замечание Мы один раз установили соседство И до этого соседа В тот момент, когда мы его добавили в табличку Взяли все свойства Взяли bandwidth, delay и все остальное, что там можно взять Дальше

Роутеры После того, как установлены соседские отношения Присылают нам указания Какие сети у них есть в таблице топологии Они начинают выгружать нам все свои маршруты Например, у нас есть сетка 10.0.0.0/24 И роутер R1 говорит Я знаю, как добраться до этой сети И он присылает нам вектор метрик Bandwidth, delay, load Reliability MTU Hop count Jitter Энергия Все Ничего не забыл Вроде нет Все, что прислал нам R1 И саму сетку И все компоненты метрики Заносим в табличку Что роутер R1 Прислал нам указания Что такая сетка известна И свойства этой сети Соответственно, тоже запоминаются Указания 10.0.0.0/24

С маской Прислал сосед 10.0.0.1 Он сказал, что эта сетка доступна За 100 мегабит в секунду С задержкой 1 мс Это то, что он нам прислал Единственное, что здесь не computed bandwidth Это более правильно сказать reported Не суть важно Мы запомнили, что прислал нам сосед Давайте отдельно здесь напишу reported И здесь тоже reported При этом каждого соседа Мы помним в табличке соседей У нас хранится IP-адрес соседа Интерфейс И все параметры, с которыми мы знаем соседа Те же самые мегабиты Задержка Как мы знаем соседа Задержка сериализации на этом интерфейсе Мы знаем загрузку интерфейса Мы знаем надежность интерфейса Все параметры, с которыми мы знаем соседа Мы точно так же посчитали на момент установления соседства

Когда роутер R2 рассказывает про ту же самую сетку Он говорит, что знает эту сеть Мы запоминаем, как нам известна эта сетка Да, здесь по-хорошему надо, конечно, добавить и computed, и reported distance, ну ладно, окей Смотрите, роутер R1 говорит: я знаю, как добраться до этой сети, я знаю, как добраться за 100 мегабит в секунду, за одну миллисекунду. Интерфейс, которым мы смотрим на роутер R1, имеет 100 мегабит в секунду и задержку тоже одну миллисекунду. Поэтому мы складываем одно с другим. Мегабиты не складываются, там считается наименьшее значение. У нас получается: 100 мегабит анонсировал сосед, 100 мегабит мы знаем соседа, computed bandwidth у нас действительно 100 мегабит в секунду. А вот computed delay у нас будет 2 миллисекунды, здесь не одна миллисекунда, а 2 миллисекунды. Одна миллисекунда, которую знает роутер R1, и одна миллисекунда, как мы знаем роутер R1. Когда роутер R2 присылает нам апдейт, он говорит: я знаю сетку за 100 мегабит, за одну миллисекунду. Но мы знаем его

за 10 мегабит. Мы берем меньшее из этих значений, 100 и 10, говорим: через R2 мы знаем сетку за 10 мегабит в секунду. Плюс он знал сетку за одну миллисекунду, мы знаем его за 10 миллисекунд, складываем одно с другим, получаем 11 миллисекунд. В таблицу мы заносим на самом деле и reported, и computed, мы считаем сначала то, что сосед прислал нам, а потом складываем вектор, который он прислал, с тем, что мы про него знаем, и получаем сумму векторов — сколько мы знаем сетку через него Так, по поводу метрик. У EIGRP есть этот самый вектор метрик. Этот вектор метрик состоит из bandwidth, delay, reliability, load, MTU, hop count, jitter и энергии. И, возможно, какие-то еще другие параметры, которые заранее мне не пришли в голову, но вообще не должны. На основании этих компонентов метрики по специальной формуле вычисляется так называемая метрика computed distance — метрика

EIGRP. Если мы взяли два маршрута, которые у нас есть в таблице через двух разных соседей, эта самая computed distance, метрика EIGRP, будет сравниваться между двумя маршрутами. У кого получится меньше, тот и лучше. Этот инструмент позволяет нам сравнивать два маршрута на хорошесть и плохость. Есть два маршрута через двух разных соседей, мы их сравниваем и говорим: один из маршрутов лучше, чем другой. В оригинальном протоколе IGRP эта метрика тоже была, она считалась от всех этих четырех компонентов, и она там действительно работала, потому что каждые 30 секунд ваши роутеры обновляли информацию о том, как выглядит транзитная цепочка интерфейсов до удаленной сети. Все роутеры, которые были в цепочке между вами и удаленной сеткой, раз в 30 секунд рассказывали про то, какие свойства есть у всех этих интерфейсов. Если какой-то интерфейс начинал

перегружаться, у него начинал расти параметр load, и они раз в 30 секунд обновляли своих соседей информацией о том, какая загрузка на транзитных интерфейсах. Если где-то начинал расти загрузка, все роутеры понимали, что где-то в сети загрузка начала расти. Если загрузка падала, все роутеры понимали, что загрузка где-то в сети начинает падать. В EIGRP нет смысла считать метрику от reliability и load. Эти параметры естественным образом постоянно будут меняться, они не могут не меняться, они более того обязаны меняться в течение работы сети. Вы сеть делаете для того, чтобы по ней транзитный трафик пошел. У вас пошел пакет по транзитной цепочке, у вас увеличился load. EIGRP не будет на каждый чих, на каждое изменение reliability, на каждый потерянный пакет или на каждое изменение load, когда у вас просто пакет пошел по трассе, генерировать изменения. Он не будет отсылать апдейты своим соседям. IGRP это делал, но не потому что происходят какие-то

изменения, а просто по таймеру раз в 30 секунд рассылались апдейты. Он иначе не умел. У EIGRP нет задачи на каждый чих делать новый апдейт, иначе он превратится в IGRP-переросток. Поэтому EIGRP не отсылает апдейты, если у вас меняется reliability или load. Он отсылает изменения только если изменяются bandwidth или delay на интерфейсе. Как следствие, метрика в EIGRP не учитывает по умолчанию reliability и load. Она учитывает только bandwidth и delay. Мы берем значения bandwidth и delay, выкидываем reliability и load, запихиваем их в некоторую формулу и получаем некоторое число. И это число называется метрикой маршрута. Чем меньше, тем лучше. У IGRP было 24 бита метрики. Соответственно, весь вектор метрик засовывался в некоторую формулу и получалось 24-битное некое значение, которое

засовывалось в таблицу маршрутизации в качестве метрики IGRP. И EIGRP, когда придумывался, придумывался таким образом, чтобы быть обратно совместимым с IGRP. Поэтому если вы используете метрику такую же, как в IGRP, то вам приходится использовать плюс-минус такую же функцию. Эта функция будет тоже считаться от всех этих значений, просто reliability и load будут участвовать в этой метрике с нулевым весом. Они, условно говоря, домножаются на ноль, и получается, что формула будет зависеть только от bandwidth и delay. И результат, если вы берете ту же самую формулу, у вас получится тоже 24-битный. Но когда EIGRP создавался, было уже понятно, что это нехорошо, когда у вас метрика получается 24-битная. Поэтому для того, чтобы она получилась больше, чтобы потом можно было адаптировать эту метрику под какие-то более расширенные значения

компонентов вектора, она изначально в девяносто третьем году была дополнена одним байтом. Из 24-битной метрики у вас получилась 32-битная метрика. Но по факту это 24 бита, 3 байта метрики IGRP плюс еще один байт, слева-справа дорисованный, забитый нулями. Фактически это умножение на 256. Вы вычисляете IGRP-шную метрику, домножаете ее на 256, у вас получается EIGRP-шная классическая метрика, 32 бита. Примерно в девяносто четвертом году, практически сразу после появления EIGRP, появились так называемые wide-метрики. Эта штука уже не особенно совместима с IGRP, и по факту, если вы посмотрите Wireshark-ом, что передается по сети в EIGRP, вы увидите, что все современные роутеры используют именно ее. Классическая метрика по сути является адаптацией IGRP-шной метрики для использования в EIGRP.

Wide-метрики уже не зависят от IGRP. Они используют некоторые концепции, которые были в IGRP, но она просто более новая, и задел под то, чтобы увеличить свойства, увеличить возможности этой метрики был заложен изначально в EIGRP, когда было сказано: давайте мы сделаем все-таки 32-битную метрику, а не 24-битную, как было в IGRP. Эти самые wide-метрики будут на самом деле даже более продвинутыми, чем изначально это предполагалось. Сначала сказали: давайте мы сделаем 32-битную метрику, чтобы у нас был задел, куда расти относительно IGRP. А потом сказали: давайте всю эту штуку выкинем, нам не нужно будет использовать обратную совместимость с IGRP.

Поэтому у нас метрика будет нормальная, wide-метрика будет 64 бита. 64 бита дают вам весьма большое пространство для сравнения нескольких маршрутов. Но есть нюанс. Когда у нас был IGRP с 24-битной метрикой или EIGRP классическая метрика с 32 битами, размером этой самой метрики — мы брали какую-то формулу, брали значения свойств маршрута, засовывали значения свойств маршрута в формулу, получали какое-то число. Это число было от 0 до 4 миллиардов с копейками, и мы прямо это число без раздумий пихали в таблицу маршрутизации. В таблице маршрутизации метрика 32-битная, как раз на Cisco. Но в EIGRP с 64-битными метриками возникает вопрос: как посчитать метрику, получить в результате число, которое больше, чем 4 миллиарда, и итоговый результат запихать в таблицу, если у нас в таблице метрика 32-битная? На самом деле там есть некий механизм адаптации, который позволит вам взять

wide-метрику и запихать ее в таблицу с помощью определенных преобразований. В wide-метриках у нас появляются два новых параметра: энергия и jitter. В wide-метриках у нас модифицирующих коэффициентов метрики становится на один больше. В IGRP формула, которая была, зависела от bandwidth, delay, reliability и load. Можно было этой формулой управлять для того, чтобы сказать, что на конкретно нашей автономной системе нас больше интересует, например, чтобы на итоговую метрику влиял, допустим, только bandwidth или только delay, а не reliability. И было пять специальных коэффициентов, которыми можно было рулить этой формулой. В wide-метриках этих коэффициентов будет 6, с K1 по K6. Wide метрика сделана таким образом, чтобы быть обратно совместимой с классической, поэтому вам возможно в книгах не будут рассказывать, что по умолчанию используется именно она.

Вам в книгах говорят: используется классическая метрика, и да, действительно, вы можете не знать про то, что на самом деле там используется wide метрика, до тех пор пока вы в наш RAS не запустите. Как только запустите, вы, конечно, увидите, что используется расширенная метрика, которая работает в режиме совместимости с классической. Cisco даже не показывает, что там используется широкая метрика, а показывает, что всё нормально, всё спокойно, всё хорошо, нормальная классическая метрика у нас. Так, я чувствую, что следующий слайд будет ваш любимый на ближайшее время. Давайте я проверю эту гипотезу. Да, это классическая метрика. Чтобы вам было полегче, я скажу: формула, которая на слайде нарисована, сегодня не используется. Она формула, и мы сейчас будем изучать, откуда она взялась, как она выглядит и на что она будет влиять. Так, сразу вижу уже здесь опечатку. Эта семёрка — это на самом деле показатель степени, это не число.

Метрика, которая вычисляется от вектора метрик, composite metric, она будет вычисляться как раз по этой формуле. Исходная формула будет зависеть от значений коэффициентов метрики. И эти K-числа, K1, K3, K2, K4, K5, имеют значения по умолчанию. K3 и K1 будут равны единице, K2, K4, K5 будут равны нулю. Поэтому, если мы сейчас возьмём и посмотрим, где эти коэффициенты K1, K2, K3, K4, K5 находятся в исходной формуле, то мы увидим значение этой формулы по умолчанию. K1 — объединичиваем, убираем его вообще из этой формулы. Если это число единица, то мы, умножая единицу на что угодно, можем просто вычеркнуть эту единицу, она ни на что влиять не будет. Дальше. K2 — ноль умножается на что-то. На самом деле весь этот компонент уходит в ноль.

Дальше. K3, умноженное на delay. Стираем K3 — это единица. И есть особое правило. Этот множитель, если K5 равен нулю, обращается в единицу. Классические правила математики говорят, что если K5 у нас будет нулём, то соответственно вся дробь обращается в ноль. И любое число, умноженное на ноль, даёт ноль. Но есть специальное ограничение в EIGRP, что правило математики не действует, если K5 равно нулю. Тогда весь множитель обращается в единицу. Это немножко контринтуитивно, но по-дурацки сделали, согласен. И получается, что если значения K1, K2, K3, K4, K5 будут: K1 и K3 — единицы, K2, K4, K5 — нули, то формула превращается в 10 в седьмой степени, разделённое на bandwidth, плюс delay, и всё это умноженное на 256. И в этом случае она не такая уже страшная.

10 в седьмой степени, разделённое на bandwidth, где bandwidth выражается в килобитах в секунду. Соответственно, здесь мы можем посмотреть, что получается, если у нас есть какой-то интерфейс, и этот интерфейс имеет какие-то пограничные значения bandwidth. Например, если у нас есть интерфейс с минимальной полосой пропускания, bandwidth будет равен одному килобиту в секунду. Меньше, чем килобит, подставить просто в вектор метрик нельзя, там значение этого компонента метрики выражается как раз в килобитах. Минимальное значение будет единичка. И получается, что если у нас есть интерфейс, который имеет минимальную полосу пропускания, или такой интерфейс в транзите до удалённой сети будет включён в цепочку, то эта часть у нас превращается в 10 в седьмой степени. Ну и плюс какой-то delay, умноженный на 256. Здесь 256 — это 2, умноженное на 10 во второй степени.

10 в седьмой степени плюс что-то, неважно что там будет, умноженное на 256, это будет 2, умноженное на 10 в девятой степени. 10 в девятой степени — это миллиард. И соответственно, это как раз половинка от максимально возможного значения метрики. Если у нас метрика 4-байтовая, то она принимает значение до 4 миллиардов 295 миллионов. Получается, что даже если у нас будет самый маленький, самый тоненький интерфейс, он всё равно даёт нам метрику, которая позволяет нам ещё delay каким-то образом учитывать. Если же у нас интерфейс будет иметь максимально возможный bandwidth, то он будет у нас, например, те самые 16 гигабит в секунду, это 16, давайте прямо по-честному напишу, 16 777 216 килобит в секунду,

или 16 гигабит в секунду. И, возможно, у него будет какой-то очень маленький delay. Допустим, представим себе, что у него delay обращается в единицу, потому что там десятки микросекунд, и задержка на интерфейсах на всех будет как раз один десяток микросекунд. Получится, что 10 в седьмой степени разделить на 16 777 216. Здесь у нас получится число меньше единицы, но мы его округляем до единицы, получаем единицу, плюс единица здесь, и всё это умножаем на 256. Получается минимальная метрика, которая есть в EIGRP, это 512 с такими стартовыми показателями. И сразу отсюда уже можно сказать, что в принципе, учитывая, что 16 777 216 килобит в секунду мы можем указать в свойствах интерфейса, и это даже будет передаваться по сети, но по факту при расчёте метрики такие быстрые интерфейсы даже работать не смогут. На самом деле при такой формуле,

когда мы 10 в седьмой степени делим на килобиты, в единицу всё это слагаемое будет обращаться уже при bandwidth минимум равном 10 гигабит в секунду. Если у вас есть интерфейс 10-гигабитный или выше, вы уже не сможете посчитать, что эта сетка на самом деле отличается от сетки, например, с производительностью 15 гигабит в секунду. С точки зрения EIGRP, сетка, известная за 10 гигабит, и сетка, известная за 15 гигабит, — абсолютно одинаковые сетки, просто потому что всё слагаемое обращается в единицу. Если у вас есть желание учитывать load и reliability, вы должны будете понимать, что это надо делать с очень большой осторожностью. В EIGRP это делать смысла вообще никакого нет. Несмотря на то, что кажется, что такой крутой протокол может мерить reliability,

может мерить load, на самом деле всё куда грустнее. Проблема в том, что EIGRP не генерирует апдейты на изменение load и reliability. Поэтому они высчитываются на каждом конкретном интерфейсе в момент установления соседства. После того как соседство установилось, получается следующая штука. У нас есть два роутера, они подружились, померили между собой load и reliability, установили соседство, бурно радуются жизни. Потом появляется какой-то новый роутер, они тоже между собой померили load и reliability, бурно радуются жизни, всё хорошо. Потом появился третий роутер, тоже установлены соседские отношения, померили load и reliability, занесли себе в таблицу. Эти значения показывают не то, какое сейчас значение загрузки и надёжности интерфейса между двумя роутерами, а то, которое было когда-то давно, на момент установления соседства. Тут роутер один анонсирует сетку,

говорит: я знаю сетку A. Я её знаю с теми свойствами, которые у меня есть прямо сейчас, в момент генерации этого апдейта. Они, скорее всего, показывают load минимальный, reliability максимальный. Дальше — соседи уже установили соседство. Соседи уже посчитали, как они друг друга знают. Там, скорее всего, load и reliability максимально хорошие. И даже если они не максимально хорошие, они таковыми были на момент установки соседства. Сейчас ситуация могла сто раз поменяться. И этот роутер себе в таблицу маршрутизации заносит, что сетка A известна, но с какими-то load и reliability, которые не отражают значение загрузки и надёжности этого интерфейса, а отражают погоду на Марсе. Он рассылает указания, что у меня эта сетка есть, и load с reliability там показывают погоду на Марсе. Эти два роутера ещё раньше установили соседские отношения. У них там тоже load и reliability показывают что-то своё. И они друг с другом начинают вымерять максимальное-минимальное значение и передают какую-то непонятную ерунду

всё дальше и дальше по сети. Поэтому при работе с метрикой EIGRP хранятся какие-то цифры, которые были посчитаны исходя из отдельных свойств интерфейсов, которые входят в цепочку, но которые ни в коем случае не отображают текущее состояние дел на этих интерфейсах. Поэтому брать их в расчёт при оценке хорошести или плохости маршрута смысла вообще никакого нет. Именно поэтому формула по умолчанию все эти компоненты выбрасывает из подсчёта. Потому что нет смысла их подсчитывать. Но если вдруг вы захотите их подсчитывать, если вдруг у вас где-нибудь будет EIGRP-протокол, вы можете сказать: давайте поменяем эти коэффициенты. И поставим K2, K4, K5 во что-то ненулевое. И тогда у вас метрика будет каким-то образом извращаться. Она не будет принимать в расчёт на самом деле загрузку или надёжность интерфейсов. Она будет принимать в расчёт какие-то случайные показатели, на основе которых, не знаю, звёзды на небе как-то сложились неудачно,

у вас выбрался один маршрут. Потом звёзды на небе по-другому пересложились, у вас выбрался другой маршрут. Не более того. Зачем нужно редактирование этих коэффициентов? По факту нужно будет рулить только коэффициентами K1 и K3. K2, K4 и K5 оставляете в нулях. Это единственное, что с ними стоит делать. Что можно будет сделать с K1 и K3? Этот множитель у нас нулевой, мы договорились. Этот множитель у нас единичка, мы договорились. И по факту мы сравниваем эту и эту часть. 256 тоже можно в расчёт не принимать. Она всегда стабильная, всегда постоянная. 10 в седьмой степени тоже в расчёт можно не принимать. Delay и bandwidth у нас действительно актуальны и действительно посчитаны по-честному. Если вдруг мы хотим сделать так, чтобы метрика не принимала в расчёт bandwidth, а принимала в расчёт только delay,

мы можем сказать: давайте K1 обнулим. Соответственно, весь этот множитель, всё это слагаемое у нас обнуляется. Метрика будет зависеть только от задержки. Если вы выставляете задержку минимальную, например, один десяток микросекунд, то метрика у вас становится числом просто 256. И фактически EIGRP начинает вести себя как hop-count протокол. У него складываются на всех транзитных интерфейсах задержки, и чем больше задержка, тем менее интересный маршрут. Чем меньше задержка, тем более интересный маршрут. Этот подход позволяет траблшутить EIGRP, особенно в лабораторных сценариях он очень удобен, когда вы зачем-то хотите поиграть с метриками, и вы хотите глазками видеть, откуда взялась та или иная метрика. Вы выставляете везде delay единичка, один десяток микросекунд, выставляете K1 — ноль, K3 — единица, K2, K4, K5 — ноль, и у вас в таблице маршрутизации EIGRP притаскивает маршрут, и вы сразу видите, какая у него метрика и откуда она взялась.

Видите метрику, допустим, 768. Сразу понимаете: эта метрика получилась в результате того, что маршрут прошёл через три транзитных интерфейса стоимостью единичка. В таких лабораторных сценариях коэффициенты метрики менять имеет смысл. Если вы хотите, чтобы EIGRP всегда выбирал маршрут с наибольшей шириной полосы, невзирая на задержки, в этой ситуации вы можете K3 обнулить, и соответственно у вас метрика будет всегда рассчитываться только исходя из bandwidth минимум. Но здесь надо будет уже аккуратно смотреть. Она в этом случае не будет видеть разницы между несколькими маршрутами, которые будут иметь, например, такой вид. У нас есть два варианта, как достать до удалённой сети. Вот так или вот так. Если везде все интерфейсы, допустим, 10-гигабитные или 10-мегабитные, не суть важно, то EIGRP не будет видеть разницы между этими маршрутами, он будет посылать трафик всегда в одну и ту же сторону,

всегда вне зависимости от количества прыжков между роутерами. Дальше. Если вдруг вы подумали, что это как-то очень легко, как уже говорилось, на самом деле все EIGRP сегодня используют другую формулу, и эта формула будет иметь такой вид. Вам показалось, что она полегче? На самом деле нет. Здесь просто она становится настолько сложной, что она не помещается на слайде. Метрика будет состоять из трёх частей. Первая часть — это компонент, отвечающий за производительность. Это Net Throughput, который имеет вид: K1, умноженное на 10 в седьмой степени, умноженное на 2 в 16 степени, разделённое на bandwidth минимум, умноженное на слагаемое единица плюс K2, разделённое на 256 минус load.

Эта штука — это Net Throughput. Давайте разбираться, что здесь и откуда растёт. Во-первых, здесь можно будет заметить следующее. K2 будет указывать на то, насколько мы хотим влиять на компонент load. Если load мы не хотим использовать, то мы берём K2, обнуляем. Всё это, два слагаемых у нас обращаются в единицу. А умножить на единицу — фактически ничего не меняется. В случае, если K2 равно 0, то мы просто его выкидываем из уравнения. Поэтому давайте разделим её на две части и оставим Net Throughput в таком состоянии, что у нас есть по умолчанию. K1, умноженное на bandwidth минимальное, то есть на самое узкое место в сети, и 10 в седьмой степени — всё это есть в оригинальной формуле. Bandwidth выражается точно так же в килобитах. K1 — это число, по умолчанию единица, 10 в седьмой степени — знакомые нам 10 миллионов.

И появляется новая штука — 2 в 16 степени. 2 в 16 степени — это 65 536. Фактически мы тот компонент, который был изначально в EIGRP классической формуле, умножили на 65 536 и получили Net Throughput. Далее. Следующее слагаемое — это latency. Это тоже сложная штука, которая считается по такой формуле. Давайте сейчас сотру опять со слайда всё. Это знакомое нам число K3, которое по умолчанию единица. Дальше. Delay, выраженный уже не в десятках микросекунд, а в пикосекундах. Пикосекунды — это триллионные доли секунды.

Милли, микро, нано, пико. Да, триллионные доли секунды. И соответственно вы берёте задержку, суммарную задержку, выраженную в пикосекундах. Умножаете на 2 в 16 степени, уже знакомые нам. И делите на 10 в 6 степени. Потому что этих пикосекунд может получиться довольно много. На самом деле, если разобраться, delay в пикосекундах, разделённый на 10 в 6 степени, получается как раз микросекунды. Милли — это 10 в минус третьей степени, микро — 10 в минус шестой степени. Но формула выглядит таким образом, что мы берём значение именно в пикосекундах, а потом делим его на 10 в 6 степени и умножаем на 2 в 16 степени. Стандарт вот такой. Опять же, если K3 равно 1, то фактически у нас получается 65 536, умноженное на задержку, выраженную в микросекундах.

Это фактически равно тому, что мы берём число 65 000, делим на 10 и получаем десятки микросекунд. Дальше. Net Throughput рассказал, latency рассказал. Extender — третья часть, которая у нас есть. Это хитрым образом заданные внешние атрибуты. Это jitter и энергия. Можно учитывать либо jitter, либо энергию, но не то и другое одновременно. И соответственно мы берём и умножаем всё это дело на K6. У нас есть этот самый K6 коэффициент, который по умолчанию равен нулю, и поэтому jitter и энергия не учитываются. Но если мы хотим их учитывать, мы можем его выставить в какое-нибудь другое значение, и формула начнёт принимать в расчёт внешние показатели. После того как мы взяли Net Throughput, взяли latency, взяли внешние показатели, сложили всё вместе, домножаем всё это дело на некое дополнительное значение.

Это дополнительное значение будет как раз учитывать reliability. Примерно та же самая формула, что была: либо единица, если K5 равна нулю, либо, если K5 не равна нулю, то это K5, разделённый на K4 плюс reliability. Если вдруг вам это надо будет учитывать, то соответственно чем больше у вас reliability, тем меньше эта дробь, и соответственно тем меньше итоговая метрика. Если вдруг метрика начинает расти за счёт того, что reliability начинает падать, то это логично, потому что reliability у нас находится в знаменателе. Запоминать эту формулу не надо. Что здесь я хочу, чтобы вы заметили? Что коэффициенты метрики K1, K3 — единица, K4, K5, K6 — ноль, это значения по умолчанию. Эти коэффициенты ведут себя точно таким же образом, как и в случае с обычной метрикой, с классической метрикой, когда у вас в расчёт принимаются только bandwidth и delay.

Если взять эту самую wide-метрику и подставить в неё параметры с коэффициентами метрики по умолчанию, а также в классическую метрику, то у вас получится на самом деле значение, которое будет различаться на вот эту штуку. В случае с классической метрикой мы умножаем на 256, в случае с расширенной метрикой мы умножаем на 2 в 16 степени, на 65 536. А так всё одно и то же. Поэтому если вдруг вы видите Cisco и вдруг почему-то знаете, что эта Cisco работает в wide-метриках, но вы смотрите вывод show IP route и видите метрику, похожую на классическую, это ничего не означает. Это означает ровно то, что если эта Cisco посчитала на самом деле широкую метрику, а потом она должна прикинуться, что она посчитала классическую метрику, со значениями по умолчанию ей это сделать очень легко.

Она просто берёт и делит то, что у неё получилось, на 256 и получает классическую метрику. Если у вас есть широкая метрика, она обратно совместима с классической. Если вдруг вам кто-то присылает классический вектор метрик, и вы можете посчитать и ту, и другую метрику, и широкую, и классическую, то в любом случае что широкая метрика, что классическая метрика у вас должна получиться одинаково больше или меньше, чем это было у соседа. Не может получиться так, что у вас два роутера присылают друг другу маршруты, и на одном и том же векторе метрик один из роутеров посчитал, допустим, классическую метрику, а второй роутер получил маршрут и посчитал wide-метрику. И так получилось, что на одном роутере классическая метрика меньше, а на другом роутере wide-метрика меньше. Так не бывает. Чтобы всё хорошо было, wide-метрика и классическая метрика одновременно либо растут, либо падают в зависимости от вектора метрик.

Если запутались — я сам чувствую, что уже слегка запутался. Широкая метрика, если вдруг вы её посчитали, превращается в классическую метрику просто путём деления на 256. Со значениями по умолчанию. Wide-метрика была придумана затем, чтобы различать интерфейсы производительностью больше 10 гигабит и чтобы различать задержки меньше, чем 10 микросекунд. Классические метрики не могли различать интерфейсы со скоростью больше 10 гигабит и задержкой меньше, чем 10 микросекунд. У них некуда было положить соответствующие задержки, соответствующие bandwidth. С wide-метриками можно. Очевидно, это проблему полностью не решает, потому что размер поля под bandwidth и размер поля с delay достаточно компактный. Но соответственно в следующий раз проблемы с EIGRP, с метриками EIGRP начнутся на скоростях больше, чем 1 терабит.

Пока что не предвидится технологически такого интерфейса. Мы сейчас упёрлись где-то в 200–400 гигабит в секунду. И пока что в коммерческую эксплуатацию ничего быстрее вроде бы никто не предлагает. Дальше. Wide-метрики получаются большие. И соответственно их надо будет каким-то образом упихивать в EIGRP. Если вдруг вы используете широкую метрику и не прикидываетесь классической метрикой, то вам нужно будет wide-метрики, которые получаются довольно большие, запихать в RIB. И соответственно, если вы будете это делать, у вас результат может не поместиться в 32-битную метрику таблицы маршрутизации. Есть специальный параметр, на который вы можете разделить метрику и сделать так, чтобы результат всё-таки влез в таблицу маршрутизации. По умолчанию для тех роутеров, которые не прикидываются классической метрикой, у нас будет этот самый делитель 128.

Мы берём широкую метрику и делим на 128, и результат в большинстве ситуаций будет влезать в таблицу маршрутизации. Если мы прикидываемся классической метрикой, то мы делим на 256 со значением по умолчанию. Если мы не прикидываемся, мы делим на 128. Если вдруг вы знаете, что у вас после подкручивания коэффициентов K1, K2, K3, K4, K5 результат получился какой-то ужасный, и значение широкой метрики будет сильно больше, чем 128, умноженное на 4 миллиарда, можно этот параметр подкрутить вручную и сказать, что для того, чтобы маршруты вставлять в таблицу маршрутизации, нам надо делить EIGRP широкую метрику на что-то больше, чем 128, больше, чем 2 в седьмой степени. Но тем не менее это в любом случае некий косметический параметр, который нужен, чтобы сравнивать маршруты, которые имеют разную метрику, чтобы понять, какой из них лучше, какой из них хуже.

Если у вас есть роутеры, которые поддерживают wide-метрику, и роутеры, которые её не поддерживают, а я напомню, что это очень старые Cisco, то соответственно за счёт того, что wide-метрики могут прикидываться обычными классическими метриками, вам не обязательно иметь поддержку wide-метрик во всей автономке. Если у вас часть роутеров умеет одно, часть другое, это не проблема. В каком-нибудь условном IS-IS это проблема. Там тоже есть метрики разных типов, но там само поле, которое мы начинаем отправлять, становится другого типа. И если вдруг у вас есть EIGRP именно классический-классический, который не умеет отправлять пакеты с широкими метриками, он умеет отправлять и принимать только пакеты с классическими векторами метрик, где вы действительно задаёте задержки в десятках микросекунд и всё такое, не в пикосекундах, а в десятках микросекунд, то роутер с wide-метриками может это понять и может отправить пакеты действительно с указанием десятков микросекунд, а не с пикосекундами.

И результат всё равно получится достаточно нормальный, потому что всё равно мы указываем время так или иначе. И даже если сосед, которому мы отправили значение метрики в десятках микросекунд, а не в пикосекундах, передаст это другому роутеру, который уже понимает, что такое wide-метрики, он всё равно сможет восстановить плюс-минус похожее оригинальное значение. А в IS-IS у нас не получится: если мы не поддерживаем широкие метрики где-нибудь, тогда использовать эти самые широкие метрики вообще нельзя. В EIGRP можно. Если используются параметры K2, K4, K5, K6 — с K6 проблема сразу, потому что классическая метрика не предполагает использование K6. Если вы по сети передаёте пакеты и в них указываете K6, это по определению означает, что вы используете широкие метрики. И по состоянию на сегодня, даже более того скажу, по состоянию на 20 лет назад,

все роутеры, которые использовались в сетях, они уже обязательно умели поддерживать широкие метрики. Поэтому сегодня вы роутер, который не понимает, что такое K6, или более того, который по сети передаёт пакеты без указания K6, этого самого энергии, джиттера, вы просто такого не найдёте. Я пытался это сделать. Я нашёл самую старую Cisco, до которой смог добраться. Эта Cisco была выпущена в 95 году. Она уже отправляет широкие метрики. По умолчанию. Named mode на ней нету. Переключить её вручную в широкие метрики можно, но даже без переключения она по факту оперирует именно широкими метриками. Если у нас есть метрика, которую мы можем посчитать, мы можем эту формулу запустить на разных векторах. Соответственно, если к нам какой-то роутер присылает какой-то маршрут,

говорит, что он знает, как добраться до какой-то удалённой сети, и показывает, с каким вектором метрик он знает эту сеть, мы запоминаем то, что он нам прислал. И мы запоминаем это как reported metric, reported vector. То, что нам заявил сосед. На старых железках, в старой литературе то, что заявлял сосед, называлось другим словом. Там называлось advertised metric. И соответственно, если вы брали вектор метрик, который вам обозначил сосед, засовывали его в формулу, у вас получалось advertised distance. Это число, которое получается после засовывания вектора метрик в формулу. И у advertised distance была аббревиатура AD, которую очень часто люди путали с administrative distance, которая влияет на то, у какого маршрутного источника больше прав войти в таблицу маршрутизации. Поэтому где-то лет пять назад термин advertised metric, advertised distance

Cisco перестала употреблять. В литературе перестала употреблять, в курсах перестала употреблять, и в документации тоже постаралась его по возможности выпилить. И сейчас то, что присылает нам сосед, будет называться reported metric. И соответственно на ней мы запускаем нашу формулу и получаем некое число. И это число называется reported distance. Сосед не показывает нам то число, с какой метрикой у него в таблице маршрутизации маршрут будет стоять. Но мы берём тот вектор метрик, на основании которого он свою метрику посчитал, мы засовываем этот вектор в формулу, мы считаем по формуле некое число. И это число мы знаем, что если у нас вектор метрик такой же, как у соседа, если у нас формула такая же, как у соседа, если у нас коэффициенты для формулы такие же, как у соседа, то мы вычислили такую же метрику, как у него в таблице маршрутизации. И reported distance — это мы сами посчитали, какая метрика в таблице маршрутизации есть у соседа.

Кроме того, мы взяли тот вектор метрик, с которым мы знаем сетку через соседа, и этот вектор, после того как мы там приложили bandwidth, сложили delay, приложили load, приложили bandwidth, приложили hop count, приложили MTU — в общем, взяли, сложили все векторы, получили результирующий вектор, и дальше запускаем этот вектор опять же в формулу и получаем некое число, которое называется computed distance. Это наша локальная метрика. Если мы этот маршрут поставим в таблицу маршрутизации, то у нас маршрут будет иметь метрику именно такую, которая будет равна computed distance. Давайте посмотрим на то, как будут сравниваться маршруты. Если у нас есть роутер, у него есть два соседа. Оба они прислали сетку 10.0.0.0/24. Один сосед 10.0.0.1, другой 10.0.0.2. Доступны через разные интерфейсы. Один через 100-мегабитный с задержкой в 1 миллисекунду,

другой через 10 мегабит с задержкой в 10 миллисекунд. И дальше оба они рассказывают, что знают сетку 10.0.0.0/24. Один сосед говорит, что знает сетку за 100 мегабит. Второй сосед говорит, что знает сетку за 100 мегабит. Оба говорят, что знают за 1 миллисекунду. И тут мы говорим: окей, давайте посчитаем, какая метрика была в голове у каждого соседа, перед тем как они прислали нам этот маршрут. Мы не видим саму метрику, само число. С какой-то метрикой в таблице маршрутизации у этих соседей этот маршрут был добавлен, но мы можем её посчитать. Delay и bandwidth будут влиять на метрику. Reliability и load показывают погоду на Марсе, поэтому не влияют на эту самую метрику. И дальше мы берём нашу любимую формулу: 10 в седьмой степени, делённое на bandwidth, прибавляем delay, и соответственно всё это дело умножаем на 256. Я предлагаю для красоты это пока что не делать.

Всё равно оно на вычисление не влияет особенно. И сделать вид, что формула у нас имеет такой вид. Bandwidth, тот, который заявил сосед, 100 мегабит в секунду. 100 мегабит в секунду — это 10 в восьмой степени бит в секунду или 10 в пятой степени килобит в секунду. Соответственно bandwidth у нас 10 в пятой степени килобит в секунду. 10 в седьмой степени делим на 10 в пятой, получаем число 100. Дальше delay. Выражается у нас в десятках микросекунд. Задержка здесь у нас 1 миллисекунда. Это 1000 микросекунд, или 100 десятков микросекунд. Delay у нас превращается в число 100. Берём 100 плюс 100, складываем, получаем 200. По-хорошему надо ещё на 256 умножить. Но мы знаем, что у соседа

метрика этого маршрута была 200, умноженная на 256. Можно, конечно, написать, что это 51 200, а можно не писать. Свойства маршрута заявлены одинаковыми обоими роутерами, поэтому reported distance у обоих будет 51 200. Дальше мы взяли и сказали: сосед 10.0.0.1 нам известен через 100 мегабит. И он заявил, что знает сетку за 100 мегабит. Поэтому мы через него можем добраться до этой сети за 100 мегабит в секунду. Мы знаем его за 1 миллисекунду. И он заявил, что сетку знает за 1 миллисекунду. Складываем одно с другим. Получаем суммарную задержку 2 миллисекунды. И дальше мы запихиваем этот вектор метрик уже в новую формулу. Та же самая формула. 10 в седьмой степени, делённая на 10 в пятой степени. В пятой степени, bandwidth не изменился. И плюс, соответственно, 2 миллисекунды. Это у нас 200 десятков миллисекунд.

Плюс 200. Это получается 300. И получается computed distance через этого соседа до удалённой сети. У нас стоит 300 копеечек. Или, опять же, можно на 256 умножить, а можно не умножать. Computed distance по определению будет больше, чем reported distance. Мы добавляем как минимум delay к тому, что прислал нам сосед. Наш компонент bandwidth не может уменьшиться. Если сосед заявляет, что сетку знает за какое-то количество мегабит, а мы знаем соседа через другое количество мегабит, то эта слагаемая не может уменьшиться. Она может только увеличиться. Мы можем соседа знать за скорость меньше, чем сосед знает сетку. И тогда эта слагаемая станет больше. Но она не может стать меньше. И слагаемая с delay тоже не может стать меньше, потому что она может только вырасти за счёт того, что мы соседа знаем за какое-то количество миллисекунд. Поэтому итоговая computed distance по сравнению с reported distance обязательно вырастет. Никогда не может быть такого, что мы знаем сетку через соседа

с метрикой такой же или меньше, чем у соседа. Она может быть только строго больше. Получается, что мы посчитали reported distance через верхнего соседа, computed distance через верхнего соседа. Reported distance на нижнем соседе такой же — 200. Но мы знаем нижнего соседа за 10 мегабит в секунду. Поэтому итоговая результирующая полоса пропускания через нижнего соседа будет тоже 10 мегабит. И суммарная задержка — 10 мс плюс 1 мс. Получается 11 мс. Опять же, берём формулу, подставляем 10 в 7 степени, делённая на производительность в килобитах — 10 в 4 степени, плюс 1100. Это суммарная задержка. Вот эта штука 1000, вот эта штука 1100. Итоговый результат получается: через нижнего соседа до сетки можно добраться за 2100 метрику. Дальше мы должны будем сказать, что у нас есть два варианта,

как можно добраться до сети через двух разных соседей. Через одного можно добраться за 300 копеек, через другого можно добраться за 2100 копеек. Выгоднее тот маршрут, который за меньшее количество копеек, который через 300 копеечек позволяет нам добраться в сеть. Мы его ставим в таблицу маршрутизации, а тот маршрут, который за 2100 копеечек, мы не ставим в таблицу маршрутизации, потому что он невыгодный. Но, возможно, мы его оставим на потом. Нам нужно будет понимать: если мы его оставили на потом, можно ли этим маршрутом воспользоваться, если актуальный маршрут сдох, или нельзя. Хороший ли это маршрут, и может ли быть такое, что этот маршрут по факту проходит через нас. Для того чтобы проверить, проходит ли маршрут через нас или не проходит, или, по крайней мере, для конкретного маршрута дать гарантию того, что он не проходит через нас, или не дать такую гарантию, будет использоваться в EIGRP концепция feasibility condition.

Каждый маршрут может либо удовлетворять условию feasibility condition, либо не удовлетворять ему. И условие это будет заключаться в следующем. Мы будем помнить самую выгодную метрику, которую мы посчитали для определённой сетки за всю историю наблюдений. Если мы когда-то вставляли маршрут в таблицу маршрутизации, мы запоминаем, с какой метрикой мы это делали. Потому что если мы когда-то ставили маршрут с определённой метрикой в таблицу маршрутизации, и дальше анонсировали этот маршрут с некоторой метрикой своим соседям, а они, возможно, анонсировали каким-то другим соседям, а какие-то другие соседи анонсировали третьим, а третьи анонсировали четвёртым, и четвёртые анонсировали этот же маршрут нам, то тогда метрика, которая будет содержаться в маршруте, анонсированном нам со стороны соседа, она, если гипотетически предположить, что маршрут проходит через нас, будет больше, чем наша самая маленькая метрика за всю историю наблюдений,

потому что, возможно, анонс маршрута с маленькой метрикой был некоторое время назад. Даже если сейчас у вас метрика изменилась, вы всё равно помните самую выгодную метрику за всю историю, чтобы помнить, что если вдруг вам придёт какой-то маршрут, который дороже, чем вы когда-либо знали эту сетку, значит, гипотетически этот маршрут может проходить через вас. В то же время, если маршрут, который к вам приходит, анонсируется соседом, и этот сосед анонсирует вам сетку с метрикой строго меньше, чем метрика, которую вы когда-либо сами видели, то в этой ситуации вы говорите: этот маршрут точно ни сейчас через нас не проходит, ни когда-либо через нас не проходил. С такой ценой, которую нам предложил сосед, он гарантированно через нас в принципе теоретически никогда не мог пройти. Эта самая лучшая метрика за всю историю наблюдения будет называться feasible distance. Она будет сохраняться, она никогда не может увеличиться.

Самая выгодная метрика по определению может уменьшаться, может оставаться на том же уровне, но увеличиваться она в принципе не может. И покуда у вас маршрут в таблице маршрутизации есть, эта метрика, соответственно, считается. Если вдруг все маршруты, которые удовлетворяют feasibility condition, пропадают, тогда с feasible distance будет происходить метаморфоза. Она будет сбрасываться. Но до тех пор, пока у вас с маршрутом всё хорошо, она только уменьшается, но никогда не увеличивается. Если кто-то присылает вам маршрут, который удовлетворяет условию feasibility condition, то есть его reported distance меньше, чем ваша feasible distance для присланного префикса, то этот маршрут гарантированно не содержит петли. Его можно сразу ставить в таблицу маршрутизации. А можно не ставить, можно подождать. Если вы ставите маршрут в таблицу маршрутизации, потому что у него метрика самая выгодная, то этот маршрут будет называться маршрутом через successor. Successor — это тот роутер, который предложил вам самый выгодный маршрут,

который удовлетворяет условию feasibility condition. Маршруты, которые можно ставить в таблицу маршрутизации — неважно, ставите вы их по факту или не ставите, но их можно ставить — то есть это сосед, который предложил вам маршрут, удовлетворяющий условию feasibility condition, будет называться, соответственно, feasible successor. Successor и feasible successor — это не маршруты. Это соседи, которые вам предложили маршрут до определённой сети. И feasible successor — это тот, кто прислал вам маршрут, который не содержит петлю через вас. Я не уверен, что все слышали моё объяснение про валенки. У меня есть любимая метафора, как понять концепцию этого самого feasibility condition, откуда у него ноги растут. Представьте себе, что есть компания. Компания занимается очень интересным бизнесом. Она торгует валенками. Но у неё нет своего большого склада. Она не производит эти валенки и не складывает их на склад, а потом продаёт. Она занимается перепродажей валенков.

Её бизнес заключается в том, что она находит поставщиков, получает от них коммерческие предложения, потом ищет клиентов, даёт им коммерческие предложения. И когда клиент соглашается купить валенки, только в этот момент выезжает маленькая газелька, закупается валенками на складе поставщика, привозит их на склад, маленький склад нашей компании. Дальше клиент присылает свою газельку и уносит валенки с нашего склада. Получается, что нам не надо иметь какой-то большой запас этих валенков. У нас под каждого клиента отдельная своя газелька ездит. Представьте себе такую ситуацию, что у нас есть хороший поставщик. Прям хороший. Мы постоянно им пользуемся. У него точно есть валенки, всё с ним в порядке. Он нам предлагает валенки за... Давайте сейчас попробую порисовать немножко. Где бы мне порисовать, чтобы свободно было... Ладно, буду пытаться здесь дорисовать. У нас есть поставщик. Он торгует валенками. Это мы — посредник.

Мы тоже торгуем валенками. У нас есть возможный канал связи. И нам валенки достаются по 100 копеечек. Или 100 рублей. Давайте с рублями всё-таки будем оперировать. 100 рублей за валенок. Трасса, которая между нами, между складом нашим и складом поставщика, тоже, соответственно, довольно большая. Газелька пока едет, тратит бензин и тратит на дорогу туда-обратно 100 рублей. Если мы посчитаем, во что нам обойдётся съездить за валенками и привезти их на склад для того, чтобы клиенты могли забрать, то получается, что 100 рублей — это дорога до склада, плюс 100 рублей, которые надо заплатить за валенок. Получается, валенок у нас в себестоимости имеет 200 рублей. Если мы кому-то пытаемся продать эти валенки, то мы должны объявлять цену как минимум не меньше 200 рублей. И мы отдаём своим клиентам коммерческие предложения. Мы говорим: мы согласны продать валенки за 200 рублей. Эти коммерческие предложения клиенты принимают,

распечатывают, кладут на стол. Дальше начинают выбирать среди них самое выгодное. Может быть, они получают одно предложение от нас, другое предложение от кого-то ещё, третье от кого-то ещё и выбирают самое дешёвое. У них тоже есть какая-то стоимость дороги. Здесь тоже газелька будет стоить каких-то денег. Они выбирают, естественно, из того, сколько на нашем складе стоят валенки, плюс дорога до нашего склада. И в норме предполагается, что конкретный клиент, который купит эти самые валенки, приедет и заберёт валенки со склада из того места, которое будет самое дешёвое. Но есть нюанс. Представим себе, что у нас этот самый поставщик, который за 100 рублей предлагал валенки, обанкротился. И раньше у нас был другой поставщик, который предлагал валенки за 500 рублей. И мы говорили: ты знаешь, за 500 рублей мы твои валенки покупать не будем, потому что у нас нет смысла покупать эти валенки за 500 рублей. Более того, если мы сейчас возьмём и посчитаем стоимость дороги до тебя,

то получается, что ещё 100 рублей мы должны будем заплатить. По факту валенки станут 600 рублей, а здесь у нас есть вариант закупаться за 200. Но когда обанкротился или прекратил работать наш регулярный поставщик, который продавал валенки за 100 плюс 100 рублей дорога — 200 рублей, мы уже начинаем думать: а можем ли мы взять эти валенки по 500? Или не можем? Потому что может же быть такое, что один из наших клиентов оказался тоже посредником. И он в свою очередь выдал коммерческое предложение. Он говорит: я знаю, где достать валенки по 200 плюс 100 рублей дорога. Я готов отдать по 300, там, по 350 рублей. Или по 300 даже, без навара. У нас такая целиком социалистическая страна, все работают без навара. Здесь, соответственно, тоже дорога. Давайте дорога 200 рублей стоит. И, соответственно, этот поставщик валенков говорит: у меня есть коммерческое предложение. Купить валенки по 300 рублей плюс 200 рублей дорога. Я готов отдавать по 500. И он предлагает нам купить у него валенки по 500.

С одной стороны, у нас здесь был раньше вариант, как достать валенки за 200 рублей. Теперь есть другой вариант, как достать валенки за 600 рублей. Но можно ли ему верить? Нельзя, потому что на самом деле это ваше собственное коммерческое предложение, которое прошло круг через несколько роутеров. И по факту, если вы скажете «я хочу купить валенки», в терминах EIGRP вы отправите пакет по этому маршруту. Этот пакет дойдёт до роутера, тот пакет дойдёт до следующего роутера, и пакет вернётся обратно к вам — вы устроите петлю. Так же, как и в EIGRP, здесь у нас по факту распределение маршрутов не означает, что мы по факту будем по этим маршрутам какие-то пакеты пускать. Отдельные коммерческие предложения — это апдейты EIGRP — они не несут в себе никаких обязанностей. Но выбор коммерческих предложений и закупка конкретных валенков уже накладывает обязанности. Мы не должны брать и принимать решение о покупке валенков на основании того, что кто-то нам просто предложил это сделать.

Мы не доверяем кому попало и мы проверяем эти коммерческие предложения. Если у нас сдох актуальный поставщик и нам кто-то предлагает купить за 500 рублей валенки, мы берём и спрашиваем: слушай, а ты у кого его закупаешь? И он говорит: а я закупаю вот там. Дальше мы идём туда: а ты у кого закупаешь? Он говорит: а я закупаюсь вот здесь. А дальше вы ему говорите: ты знаешь, у меня вообще-то раньше эти валенки были, а сейчас перестали быть. Так что ты уверен, что ты мне всё ещё готов их продать? И тут он говорит: ой, извините. Я, оказывается, вам самим собираюсь ваши собственные валенки продать. Поэтому вы не верите никому. Если вы когда-либо покупали валенки задёшево и отдавали коммерческие предложения задёшево, а теперь вынуждены по каким-то причинам обратить внимание на поставщика, который предлагает вам купить валенки дороже, чем вы когда-либо сами их видели, то такому предложению доверять вначале нельзя. Самая маленькая цена, за которую вы сами продавали валенки когда-либо, это и будет feasible distance. Она по определению самая маленькая, она не может расти.

Если у вас сегодня самая маленькая цена была 100 рублей, то завтра самая маленькая цена 200 рублей уже стоять не может. За всю историю она может только падать. Вчера продавали за 100 рублей — сегодня самая маленькая цена, за которую продавали, тоже может быть 100 рублей. Либо если вы сегодня продаёте за 50, она может упасть, но подняться она не может. И если кто-то предлагает вам купить валенки дешевле, чем когда-либо вы сами покупали, то это значит, что это не ваше собственное коммерческое предложение, которое прошло десяток посредников и вернулось к вам обратно. И такому предложению можно верить. Если к нам кто-то другой придёт и скажет: я вам готов отдать валенки по 50 рублей, просто дорога будет стоить тысячу. Этому предложению вы можете верить сразу, потому что если он говорит, что валенки стоят 50 рублей, это точно не ваши валенки. Вы сами эти валенки продавали когда-то по 200. Поэтому дешевле, чем 200, на складе поставщика ваши собственные валенки стоить не могут. Если поставщик готов отдать их по 50, это точно не ваши собственные валенки.

Это точно нормальный живой маршрут. Но, соответственно, он может быть невыгодный. Это другая тема. Но в ситуации, когда у вас есть два варианта, как доставить трафик: либо через заведомо маршрут, который не содержит петлю, либо через маршрут, который может потенциально содержать петлю, хотя гипотетически может быть дешевле, EIGRP будет выбирать маршруты более стабильные — те, которые заведомо не содержат петлю. Если в терминах EIGRP говорить: у нас здесь была сетка, она анонсировалась за 100 копеечек, плюс стоимость 100 копеечек этого интерфейса. И эта сетка перестала существовать. Если к нам приходят два маршрута: один говорит — я знаю за 500 копеек, другой говорит — я знаю за 50 копеек, но суммарная стоимость computed distance здесь получается 600, а здесь получается 1050. Вот этому нижнему маршруту мы верить будем Он у нас будет Feasible с аксессором Потому что он удовлетворяет условия Feasibility Condition Самая маленькая наша метрика 200 Его анонсированная метрика Reported Distance 50

Следовательно, это не маршрут через нас Следовательно, этот маршрут проходит Feasibility Condition Ему можно верить Верхнему маршруту, даже несмотря на то, что он дешевле, чем другой Мы не верим Заявленная стоимость на соседе Reported Distance Больше, чем наш Feasible Distance Поэтому мы ему не верим И мы его не добавляем в таблицу маршрутизации До тех пор, пока не будут произведены дополнительные проверки Нижний маршрут в случае отказа основного поставщика Может быть сразу добавлен в таблицу маршрутизации Верхний не может Мы им пользоваться будем только после того, как все маршруты, удовлетворяющие слове Feasibility Condition, будут Пропадут Так, так, так, так Два примера даже, как работает Feasibility Condition У нас есть сеть Вот она, наша сеть Эту сеть анонсирует два роутера Один роутер говорит, я знаю, как добраться до сети за 10 копеек У него в таблице маршрутизации метрика 10 единиц

Этот роутер принимает такой маршрут, говорит Я знаю, что можно добраться через соседа Сосед анонсировал метрику 10 Я дальше посчитал вектор метрик, сколько стоит добраться до сети Computer Distance у меня получилось 20 Занес в табличку соседей То же самое происходит через нижний роутер Ну, соответственно, он присылает нам указание, что он может добраться за 10 копеек И Computer Distance через него тоже получается 20 Вот этот вот роутер будет говорить Окей, у меня есть два одинаковых маршрута И я трафик буду, например, балансировать Поэтому он ставит Next Hop оба роутера И говорит, трафик, часть пойдет на одного роутера На один роутер, часть пойдет на другой роутер Вот этот вот нижний роутер, он, соответственно, говорит Если вдруг мне по каким-то причинам приходит апдейт с правого роутера Там будет Reported Distance 20 копеек Computer Distance через него будет 30 копеек В обратную сторону мы ни при каких условиях трафик посылать не будем Без дополнительных проверок

Если вдруг сосед заявляет, что он знает эту сетку А мы знали эту сетку за 10 копеек То, соответственно, вот у него получается Reported Distance 20 копеек И мы просто так, если вдруг у нас отвалится связь в сети А без дополнительных проверок не будем пользоваться этим маршрутом Потому что если вдруг мы просто без объявления войны, скажем Мы направляем трафик на вот этого соседа У нас получится петля Мы направляем трафик ему, а он с некой вероятностью отправляет трафик назад Мы отправляем ему, а он отправляет трафик назад Вот, поэтому здесь вот как раз пример, что Наша Reported Distance здесь будет 10 копеек Feasible Distance тоже, соответственно, 10 копеек Вот тут вот 10 И маршруты, которые приходят за 20 копеек, мы им не доверяем Computer Distance там даже не важно какая Главное, что Reported Distance 20 копеек 20 больше, чем 10 Мы такому маршруту не верим Как будет работать Load Balancing?

А вот мы же про Cep говорили, когда Я говорил там, что есть балансировка И там балансировка используется Per Destination на самом деле Вот, и трафик до конкретного вот IPшника Он всегда будет идти в одну и ту же В один и тот же Next Hop Если вы не делаете балансировку Per Packet Да Так, далее Еще один пример Feasibility Condition На самом деле мало кто про это рассказывает Но я вам расскажу Смотрите Если у вас есть Если у вас есть вот это вот самое Feasibility Condition То оно заключается в том, что Feasible Distance Должно быть строго меньше, чем Reported Distance Очень часто Просто Как бы Слушатели запоминают это условие Но не понимают, почему здесь требуется именно Строгое неравенство Строгое Строго меньшее, как называется

Строгое Ну, строгое неравенство, да Окей Почему здесь нельзя сделать меньше либо равно Дело в том, что Если у вас есть Та же самая сеть Только вот немножко в другом виде У нас есть некая сетка Вот А, уже написано Сетка B И роутер один ее анонсирует своим двум соседям Он говорит Я знаю эту сетку за 10 копеек Дальше Каждый интерфейс у нас стоит 10 копеек Не обращайте мне, что здесь написано Он говорит Я знаю, как добраться за 10 копеек Они говорят С учетом транспортной стоимости получается Что здесь у нас метрика 20 копеек 20 здесь 20 тут И они друг другу рассказывают Я знаю, как добраться за 20 копеек Вот если вдруг К вам пришел маршрут Который стоит столько же Сколько Сетка стоит на вас Этот маршрут сейчас Не проходит через вас Но Если вдруг у него Сетка отвалится Он Не может взять тот маршрут

Который стоит столько же Сколько на нем И внезапно отправить по нему пакеты Потому что если вдруг это случилось На одном роутере Возможность случится на другом роутере И если вдруг У них у обоих отвалилась связь со внешним миром Они друг друга Без объявления войны Поставят next hop Поэтому для того, чтобы У нас Вот это вот условие Feasibility condition Что этот маршрут никогда Не проходил через нас И в будущем не пройдет через нас Условие работало Здесь требуется Строгое неравенство Вот Да Это на будущее Скажем так Что если вдруг что-то Произойдет потом Когда-нибудь Нехорошее Еще один пример Который хочется показать Это вот какой У нас есть опять сеть B Роутер за 10 копеек знает сетку Анонсирует ее Через интерфейс Стоимостью 10 копеек Тот роутер говорит Я знаю когда вас за 20 копеек У него в таблице Эта сетка за 20 копеек есть Маршрут приходит

На вот этот вот роутер И если вдруг Вот здесь вот этот анонс По каким-то пришлинам Не прошел То есть этот роутер Говорит Я знаю как добраться За 30 копеек У него в таблице Маршрут Через 30 копеек Вот так вот в обход идет Но например Потому что здесь Hello пакеты Например Как-то не проходят Или что-то еще Ну в общем Странно как-то Апдейт еще не прошел Например Вот Соседство есть А апдейта пока нет И роутер говорит Что я знаю как добраться За 30 копеек Компьютер дистанц 40 копеек И роутер Который знает Что до сетки Можно было добраться За 10 копеек Такой апдейт Принимать уже не будет Он говорит Что репорт Дистанц 30 А у меня Физибл дистанц 10 Такой апдейт Мы не принимаем И через некоторое время Наверняка Он захочет сам рассказать Что вот известно Как добраться до этой сети За 10 копеек И уже нижний роутер Поверит этому маршруту И перестроит Свою таблицу Маршрутизацию Чтобы ходить наверх Если у нас Есть какие-то маршруты

Которые удовлетворяют Физибл дистанц То лучшее из них Добавляется в таблицу Маршрутизации Кроме того Некоторые другие маршруты Тоже могут добавиться В таблицу маршрутизации Если у вас используется Unequal cost multipath Если у вас Есть Один суксессор Который Присылает вам Хороший маршрут Вы держите в таблицу И он помирает Ну не знаю Интерфейс на него падает Или Что-то еще случается Есть другие Физибл саксессоры Вы немедленно Переставляете Маршрут Маршрутизации На Самый выгодный Физибл саксессор Если вдруг У вас вообще Ни одного Физибл саксессора Не осталось То есть Был саксессор И он сдох И физибл саксессоров Не осталось То вы запускаете Алгоритм Dual С помощью которого Вы проверяете Тех, кто присылает Вам маршруты Что сетка доступна Просто за Невыгодную стоимость Те маршруты Которые не удовлетворяют Условия Если вы Вы отправляете Сообщение Через меня До этой сети Добраться нельзя

Соседу Вы проверяете Его на вшивость А не собирается Ли этот милый человек Через вас Добраться до этой сети Если он говорит Это ничего Что через тебя Добраться до этой сети Нельзя Я все равно Знаю хороший маршрут То вы этому верите И вы говорите Окей Тогда я буду ходить Через тебя И вот в ситуации Когда вы запустили Алгоритм дуал Проверили Что сосед Действительно Не содержит Петли через вас У вас сбрасывается Физибл дистанц То есть раньше Она была меньше Этому условию Не удовлетворял Маршрут Который присылал сосед Вы запустили Алгоритм дуал Сосед стал удовлетворять Условия Физибл дистанц Потому что Физибл дистанц У вас выросла Вот она просто Так сама по себе Вырасти не может Но если вы запускаете Дуал И проверяете маршрут На вшивость Она может подрасти Ну и После того Как дуал завершается Физибл дистанц Вырастает У вас появляется Новый саксессор Вы его ставите В таблицу С маршрутизацией Физибл дистанц

Должна быть Строго больше Чем Репортед дистанц Да Да Продон Здесь на слайде Конечно же Опечатка Так Далее Если у нас есть Несколько маршрутов Именно до одного И того же префикса До одной и той же сети Нам нужно будет Во-первых Выбрать Среди них Лучший маршрут А во-вторых Проверить Какие маршруты Удовлетворяют условия Физибл дистанц Соответственно Процедура Выбора Лучшего маршрута Будет Проходить Только Среди тех Кто Удовлетворяет Условия Физибл дистанц Если какие-то Маршруты Не удовлетворяют Условия Физибл дистанц У них Репорт дистанц Больше Чем наша Физибл дистанц Мы их Вообще Не трогаем То есть Мы их Откладываем

В сторону И Рассматриваем Всерьез Только Те маршруты Которые Физибл дистанц Удовлетворяют Но вот Среди них Надо выбрать Тот маршрут Который будет Самый лучший Мы находим Тот маршрут У которого Компьютер дистанц Самая маленькая И соответственно Добавляем его В таблицу Маршрутизации Если мы Используем Классические Метрики То есть Это циски Выпущенные До 94 года Или Классический режим В котором мы Работаем Когда циска Прикидывается Что она работает С классическими Метриками То в таблице Маршрутизации Метрика Маршрута Будет равна Компьютер дистанц То есть Вот мы Приняли Какой-то маршрут Посчитали По формуле Компьютер дистанц И EGRP Метрику Делаем Метрикой В таблице Маршрутизации Если мы Используем Широкие метрики Wide Метрикс То Тогда Метрика EGRP У нас Получится 64-байтовая И она Напрямую В 32 бита Не влезет И по умолчанию ЦИСКИ настроены Таким образом Что они берут Компьютер дистанц

Которая большая Которая больше 4 миллиардов Может быть И делят на EGRP РИБ скейл Это делитель Который по умолчанию Равен 128 То есть Берем Метрику Делим на 128 И полученную запись Заносим в таблицу Маршрутизации Вот пример У нас есть Соседи Два соседа Которые присылают нам Маршруты Опять же Здесь опечатка По-прежнему Копируется Каждый из соседей И прислал нам Сетку 10.000 По 24 Маске Один сосед Сказал, что знает За 100 мегабит За одну миллисекунду И второй сосед Сказал, что знает За 100 мегабит За одну миллисекунду Этих соседей Мы знаем За разные Мегабиты За разные миллисекунды Поэтому Через каждого соседа Мы считаем Вектор Как мы знаем Сетку И получаем Вот такой Вот вектор Это Какой эффективной Метрик Получается Через каждого Соседа Оба числа мы заносим, в смысле, оба вектора мы заносим в формулу И получаем число reported distance и computed distance

Ну, reported distance используется для проверки на feasibility condition У нас здесь все хорошо Оба маршрута удовлетворяют условия feasibility condition Потому что они на самом деле одинаковые свойства заявили Поэтому reported distance у них у всех будет одинаковое Ну, если мне память не изменяет, там 200 200 здесь и 200 здесь Ну и дальше, да, посчитали computed distance на основании того вектора Которого у нас по факту получается Feasible distance для сетки 10.000-24 будет То есть вот эта вот сетка 10.000-24 Она у нас будет иметь feasible distance равную Так, что-то меня ручка не рисует Feasible distance 300 Это самая маленькая метрика наша за всю историю наблюдения Вот это вот, это feasible distance Если вдруг текущий роутер первый вдруг пропадет Вот у нас этой сетки не будет То тогда feasible distance останется все равно 300

Но суксессором станет другой маршрут, который имеет computed distance 2100 То есть feasible distance от того, что текущий суксессор сдохнет Сама по себе не изменяется Но если вдруг оба роутера скажут, что такой сетки больше нету Тогда мы запустим алгоритм dual Если найдем какой-то запасной выход, как можно выйти до этой сети То мы тогда feasible distance поднимем До тех пор, пока мы алгоритм dual не запускали Физible distance не увеличивается Уменьшиться она может Если сосед скажет, что знает эту сетку дешевле Он, например, скажет, что знает эту сетку за гигабит И мы, соседа, тоже начнем за гигабит Вот у нас тогда reported distance станет меньше Computed distance станет меньше И feasible distance тоже станет меньше Но до тех пор, пока это не произошло До тех пор, пока у нас все стабильно работает Здесь у нас два маршрута, которые оба удовлетворяют условия feasibility condition И оба могут быть добавлены в таблицу маршрутизации Но по факту будет добавлен только один, у которого метрика будет меньше Это вот маршрут за 300 копеек

Мы его добавляем в таблицу NextHop того, кто прислал, добавляем в таблицу Административное расстояние EGRP по умолчанию 90 И метрика, которая будет равна computed distance Если у нас всего два роутера и один помер, Dual тоже запустится Да? Да Пример топологии Сейчас здесь будет анимация Если у нас появится некая сетка, мы можем увидеть, как распространяются апдейты по такой сети Для упрощения здесь коэффициент K1 в метрике был выставлен в ноль Поэтому метрика EIGRP учитывает только задержку Для простоты, я не помню, здесь умножалось всё на 256 или нет Метрика будет просто кратна этой самой задержке, которая у нас есть на интерфейсах Задержки каждого интерфейса показаны в квадратиках на каждом интерфейсе

Включаю анимацию Появляется новая сетка Появляется новая сетка Дальше начинают распространяться апдейты Роутер, на котором эта сетка возникла, говорит: я знаю, как добраться до сети И он рассказывает reported distance — что он знает, как добраться до этой сети за 10 миллисекунд Computed distance прибавляет к заявленному reported distance стоимость интерфейса в миллисекундах И получается, что левый роутер знает за 50 миллисекунд Правый роутер знает за 20 миллисекунд Каждый из этих роутеров начинает отсылать сообщение: я знаю, как добраться за 50 миллисекунд, я знаю, как добраться за 20 миллисекунд В том числе и на тех интерфейсах, на которых они только что этот маршрут получили Здесь нет концепции, как в RIP — она может быть, а может и не быть Но здесь нет обязательного требования использовать Split Horizon

Потому что работает правило feasibility condition Если мы отослали что-то соседу и сосед нам это обратно возвращает, то мы такому маршруту по определению доверять не будем Мы его в расчёт принимать не будем Поэтому сосед может обратно в тот же самый интерфейс, в котором он что-то получил, слать всё что угодно Проблемы это не вызовет В RIP это вызовет проблему Потому что если в RIP по умолчанию таким маршрутам доверяли, то мы могли бы словить ситуацию, в которой у нас будет петля А здесь эту петлю заведомо не вызовет Потому что маршрут, который через нас пришёл, заведомо хорошо видно, что он прошёл через нас Он не удовлетворяет условию feasibility condition Начинают распространяться эти апдейты Часть апдейтов идёт в обратную сторону — и там они блокируются Часть апдейтов распространяется вперёд После того как какие-то апдейты прошли вперёд, они возвращаются обратно, и роутеры обратно их блокируют

И это всё приводит к тому, что все роутеры так или иначе про какую-то сетку начинают знать Здесь что может быть интересно Давайте предыдущий слайд У нас есть, например, вот этот роутер, который говорит: я знаю, как добраться за 50 копеек И с учётом того, что этот интерфейс стоит 10 копеек, маршрут стоит 60 копеек на правом роутере Правый роутер начинает рассказывать: я знаю, как добраться за 60 Он рассказывает про это всем, и в том числе вот этому роутеру Этот роутер получает одновременно рядом апдейт от вот этого Он говорит: я знаю, как добраться за 30 копеек И 30 копеек с одной стороны, 60 копеек с другой стороны А computed distance здесь будет вообще 40 Поэтому computed distance 40 через правый роутер означает, что маршрут за 60 копеек, анонсированный соседским роутером, просто будет заблокирован

При этом в обратную сторону пока здесь ещё ничего не шло Мы рассматриваем только этап, при котором маршрут дошёл одним боком вот так, другим боком вот так И здесь пока только в одну сторону прибежали все маршруты Очевидно, что если у нас с одной стороны маршрут был заблокирован, то дальше это продолжаться так долго не может И в обратную сторону уходит маршрут: я знаю, как добраться за 40 копеек И этот роутер говорит: ого, я раньше-то знал, как добраться за 50 копеек, а сейчас знаю, как добраться за 40 копеек Поэтому этот роутер говорит: я теперь буду направлять трафик вот сюда, в эту сторону, чтобы трафик ходил вот так Это получается выгоднее и дешевле Некоторое время назад он отправлял трафик наверх, а сейчас будет отправлять трафик вбок Дальше До того, как этот роутер получил более новый маршрут, он рассказывал, что можно добраться через него до какой-то удалённой сетки

И говорил, что через меня можно добраться до сети, и эта сеть будет стоить 60 копеек на мне, 70 копеек на вас Этот роутер говорил: окей, за 70 копеек я теперь могу добраться до удалённой сети через левый роутер После того как прибегает указание, что можно добраться теперь за более выгодную стоимость — На левом роутере у нас появляется более выгодный маршрут У нас теперь появляется возможность не за 60 копеек добираться, а за 50 И получается, что этот роутер становится более выгодным, чем был раньше Раньше мы заявляли, что знали сетку за 70 копеек Теперь мы становимся обладателями маршрута за 60 копеек Получается, что теперь мы можем анонсировать эту сетку и сказать, что эта сетка будет уже дешевле Раньше анонсировали за 70, теперь анонсируем за 60

Вот она анонсирована за 60 И этот роутер — теперь у него есть два варианта, как можно добраться до удалённой сети Можно ходить вот так, можно ходить вот так И оба из них удовлетворяют условию feasibility condition Поэтому весь трафик будет балансироваться Часть трафика будет направляться по такому маршруту, часть трафика — по такому Левый роутер ставит successor того, кто правее, а верхний — feasible successor Честно говоря, не знаю, что такое FZ Но здесь получается, что вы принимаете маршруты и просто ориентируетесь на метрике для того, чтобы принимать решение — принимаете вы такой маршрут или не принимаете Если маршрут, который приходит к вам сейчас, удовлетворяет условию feasibility condition, вы ему верите, вы его добавляете в топологию И вы готовы, если это самый выгодный маршрут, посылать трафик через него

Как только сосед присылает какой-то другой маршрут, вы говорите: окей, сосед раньше присылал одно, теперь присылает другое Мы ему, допустим, верим или не верим Здесь происходит просто обмен этими самыми маршрутами И на основании обмена этими маршрутами вы будете смотреть, кого куда вы посылаете Левый роутер ставит successor того, кто правее Верхний будет feasible successor Надо посмотреть Если про этот роутер речь — у него этот товарищ, здесь метрика 40, здесь метрика 50, здесь метрика тоже 50 Нет, верхний feasible successor не будет Он заявляет, что знает сетку за 50 копеек, и мы сами на левом роутере тоже заявляем сетку за 50 копеек Поэтому feasible successor он у нас не станет — мы ему не верим У него reported distance в точности равна нашей feasible distance Поэтому, увы, мы его не будем воспринимать всерьёз

Если бы у него reported distance была 49, мы бы его добавили в feasible successor А так нет Это был базовый рассказ про EIGRP Здесь мы вспомнили, как EIGRP выглядит, какие концепции он использует, как формируются таблицы топологии Вспомнили, что у EIGRP есть таблица соседей, есть таблица топологии И результаты подсчёта таблицы топологии показываются в таблице маршрутизации А нам осталось сущий пустяк — проверить это дело на практике Нам придётся посмотреть команды, которыми EIGRP настраивается на цисках И посмотреть некоторые особенности того, как EIGRP может работать с маршрутами Потому что у него есть достаточно богатый арсенал того, как можно с маршрутами поиздеваться Я предлагаю это оставить на следующий модуль

Спасибо за субтитры Алексею Дубровскому!