EIGRP

Итак, мы говорим про динамическую маршрутизацию, и в рамках нашего курса ICND2 первый протокол, с которым мы будем работать, это будет протокол EIGRP. Фирменный CISCO, в последнее время стремится открыть для того, чтобы соответствовать требованиям регуляторов, в части того, что в некоторых случаях требуется использование открытых протоколов. CISCO решила, почему бы нам не открыть тот протокол, который всегда считался именно фирменным нашим. Но она его открыла. От того, что она это сделала, количество желающих его реализовать не сильно прибавилось. Поэтому сейчас единственная компания, которая производит оборудование с поддержкой этого открытого протокола, это всё равно та же самая компания CISCO. Если мы говорим про EIGRP, это протокол, который называется Enhanced IGRP, и здесь мы встречаемся с другим протоколом, IGRP. Этот самый IGRP, Interior Gateway Routing Protocol, это древний тоже фирменный CISCO протокол,

который был классовый и который работал очень простым образом. Он во все стороны рассылал указания, какая у него таблица маршрутизации. IGRP работал достаточно примитивным образом, он действительно как RIP во все стороны кидался маршрутами, делал это по расписанию раз в 30 секунд, и был в каком-то смысле протоколом не самым плохим. Он, например, был лучше, чем протокол RIP, но при этом по современным меркам IGRP, конечно, был протокол крайне неудачный. Поэтому, когда в 93-м году CISCO поняла, что бесклассовая маршрутизация победила в интернете, никаких классовых маршрутов уже там нету, EIGRP, вторая версия протокола IGRP, был предложен рынку и, в принципе, был весьма тепло им встречен. Это именно вторая версия протокола IGRP. Если посмотреть на исходные коды IOS или даже на какие-то внутренние структуры данных, которые в IOS используются,

которые можно просто через консоль посмотреть, будет видно, что действительно это протокол, который состоит из отдельных модулей, и некоторые модули там прямо чётко называются IGRP2. В IGRP у нас использовался бродкаст, в EIGRP используется мультикаст, хорошо известные адреса 224.0.0.10 и ff02::a. 16-ричное число a — это тоже 10. Поэтому что в IPv4, что в IPv6 по сути своей мультикастовые адреса очень похожи друг на друга, если не сказать вообще одинаковые. У EIGRP будет вложение в IPv4 или в IPv6, и EIGRP не использует ни TCP, ни UDP. Он использует своё собственное вложение с номером 88. Это фирменный цисковский протокол вложения в IP. Он называется Reliable Transport Protocol. Не путайте с Real-Time Protocol, который используется для передачи голоса и видео в IP-телефонии, например.

Это другое. Там в UDP используется вложение, а это прямо напрямую в IP вкладывается, хотя аббревиатура одна и та же. По сравнению с IGRP и по сравнению, например, с RIP, у EIGRP появилась концепция соседей. Дело в том, что IGRP работал очень просто. Он разбрасывал во все стороны куски таблицы маршрутизации. И соседи, которые слушали такие апдейты, просто сидели и говорили: «О, у нас пришёл новый апдейт, значит сосед всё ещё знает сетку. О, у нас пришёл новый апдейт, значит сосед всё ещё знает сетку. Если в течение некоторого времени апдейты от соседа переставали приходить, значит мы говорили: «О, сосед перестал знать некоторую сетку. Может быть сосед вообще сдох и не присылает нам ничего». Эта концепция предполагала, что вы постоянно должны рассылать всю-всю-всю таблицу маршрутизации. И если она у вас была достаточно большая, то это могло занимать немало трафика. Если говорить про технологии, которые были в начале 90-х годов, даже в конце 80-х,

то типичные скорости передачи данных на тот момент были крайне небольшими. На тот момент везде рулили модемные соединения, и скорости в 33 600 бит в секунду были недостижимо большие. На самом деле большинство узлов, которые связывались по телефонным линиям, они работали на скоростях типа 24 килобита, 14 килобит. Это были очень низкие скорости. И если вы использовали канал с очень маленькой полосой пропускания, и вы должны были каждые 30 секунд рассылать всю свою таблицу маршрутизации в виде этих самых апдейтов IGRP, то чисто работа самого служебного протокола динамической маршрутизации отъедала у вас весьма значительную полосу в этом канале. Получалось, что у вас есть, допустим, 14-килобитный канал, вы в нём работаете, и половина этого канала, 7 килобит в секунду в среднем, отводится

под работу служебного протокола IGRP. А под передачу данных, ради которых, собственно, IGRP работает, остаётся только половина канала, оставшиеся ещё 7 килобит. И ничего хорошего в этом, конечно, не было. Когда Cisco предложила вторую версию протокола IGRP, она сказала: а зачем мы постоянно рассылаем одну и ту же информацию про то, что мы знаем все сети, которые у нас есть в таблице маршрутизации. Давайте сделаем так, что мы разошлём один раз указания, какие сетки у нас есть, а потом будем отсылать указания: у нас ничего не изменилось, у нас ничего не изменилось, у нас ничего не изменилось. И здесь идея, конечно, была красивая, но возникла очередная проблема. Очередная проблема заключается в том, что у нас есть среды с множественным доступом, такие как Ethernet. В Ethernet у нас может быть интерфейс, на котором мы знаем 2, 3, 4, 5, 10, 100 разных соседей. И когда мы с первым соседом начинаем работать, мы ему посылаем сообщение: привет, давай, я тебе буду рассказывать, что у меня есть такие сети,

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

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

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

начинают разбегаться от того источника, где она появилась, волны указаний, что у нас определённая сеть есть. И они по всей сети бегут, бегут, бегут, бегут до тех пор, пока все роутеры в топологии не узнают о том, что какая-то сеть существует. И точно так же, если какая-то сеть перестаёт быть доступна, то как вы берёте краску, краской в стакан с водой капаете, и у вас эта краска начинает расползаться по всему объёму стакана. Вы прямо глазами можете наблюдать. Это не одновременно происходит, это прямо такой волной. Точно так же разбегается информация о том, что сеть перестала быть доступна. И рано или поздно либо все роутеры узнают, что сеть недоступна, либо кто-то скажет: а у меня она доступна, и дальше в обратную сторону пойдёт, опять же, та же самая диффузия доступности. Сегодня EIGRP — протокол стандартный, он был опубликован на сайте CISCO в 2013 году и открыт целиком — не целиком, почти целиком — в виде RFC 7868 в 2016 году. CISCO не всю спецификацию открыла,

есть кое-какие штуки, которые цисковская реализация EIGRP поддерживает, а в стандарте они никак не описаны. Тем не менее, если вдруг кто-то бы захотел реализовать EIGRP, у него бы, наверное, получилось бы сделать эти закрытые, в кавычках, вещи даже без RFC. Проблема в том, что никто из крупных вендоров по факту за EIGRP так и не взялся. Альтернатив самой CISCO фактически только FRRouting, продукт, который open-source, который позволяет с EIGRP работать, хотя и достаточно криво-косо. А так больше альтернатив ему и нет. EIGRP — очень быстрый протокол. В подавляющем большинстве случаев EIGRP работает быстрее, чем любой другой протокол, который у нас в курсе есть, да и даже те протоколы, которых в курсе у нас нет, всё равно EIGRP будет быстрее. У него есть ряд действительно клёвых ускорителей, которые позволяют ему очень быстро принимать решения

о доступности или недоступности маршрута. Поэтому CISCO очень не любит говорить, что EIGRP — это дистанц-векторный протокол, потому что дистанц-векторный протокол с точки зрения CISCO — это, например, RIP или IGRP, который по таймеру рассылает сообщения, который очень медленно реагирует на изменения в сети. А EIGRP работает очень быстро, быстрее, чем любой другой протокол, на изменения реагирует. И поэтому CISCO, когда говорит, к какому бы семейству отнести EIGRP, говорит: это гибридный протокол. Хотя ничего гибридного в нём нет. Он гибридный только в том смысле, что он работает быстрее, чем OSPF, поэтому он в этом смысле лучше, чем OSPF. Но от этого link-state протоколом вообще ни разу не становится. Тогда CISCO говорит: ладно, с гибридным не прокатило. Давайте назовём его advanced distance-вектор. Это уже более интересное решение, но всё равно distance-векторная природа у него осталась полностью. Да, он очень быстрый. Да, в определённых ситуациях EIGRP будет принимать решение действительно быстрее любого другого протокола,

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

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

почему не advanced distance-вектор, не гибридный, не link-state. Потому что обмен информацией у него происходит именно на уровне маршрутов. Он берёт из таблицы маршрутизации маршруты и кидает их в сторону соседей. И говорит, как он именно знает эту сеть, на каком расстоянии. И это расстояние, или, если хотите, вектор, которым он будет обмениваться с соседями, будет достаточно сложный. Он будет, в отличие от RIP, который был тоже дистанц-векторный, но у которого вектор метрик состоял только из одной метрики — количества прыжков между роутерами. Здесь вектор будет состоять из большого количества компонентов. Многих компонентов. Основных, самых важных компонентов метрики будет всего два. Bandwidth и delay. Когда у нас EIGRP рассказывает, как он знает определённую сеть, он будет рассказывать в основном, из того, что нам будет интересно, про миллисекунды, с которыми он знает эту сеть,

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

а мы знаем соседа за одну миллисекунду, то логично предположить, что это можно прямо напрямую взять и сложить. Поэтому итоговый результирующий вектор в компоненте задержки будет иметь 11 миллисекунд. В то же время, если сосед заявляет, что знает сетку за 100 мегабит, а мы знаем соседа за гигабит, то бессмысленно складывать эти два значения. От того, что сосед заявил нам сеть, что он 100 мегабит в него может промаршрутизировать, В принципе, гипотетически, мы знаем гигабит, но это не означает, что мы в удалённую сеть можем послать гигабит и 100 мегабит трафика, правильно? Это значит, что мы больше 100 мегабит в любом случае не должны туда посылать, что там больше не пролезет, чем 100 мегабит. Поэтому своим соседям мы говорим, 100 мегабит — это та скорость, с которой мы знаем эту сеть. Соседа мы знаем быстрее, но больше 100 мегабит смысла в сторону этого соседа посылать нету до этой сети. То же самое происходит на следующем этапе, когда у нас третий роутер в цепочке говорит, я вижу соседа, он мне рассказывает, что знает определённую сетку,

я через него эту сетку тоже знаю. Он мне говорит, я знаю эту сетку за 11 миллисекунд, я знаю соседа за 10 миллисекунд, я знаю эту сеть за 21 миллисекунду через него. И сосед заявляет, что знает сетку за 100 мегабит, а я знаю соседа за 10 мегабит. Сколько я по факту могу трафика отправить в сторону этой сети? Не больше 10 мегабит. И соответственно дальше рассылается вектор. Я знаю эту сеть за 10 мегабит, за 21 мс. То же самое дальше происходит, когда у нас следующий роутер принимает такой апдейт. Он говорит, я знаю соседа за 1 мс, за 100 мбит. Но 21 мс плюс 1 мс получается 22 мс. 100 мбит, который есть за спиной роутера, 10 мбит, который есть за спиной роутера, и 100 мбит, которым мы знаем этот роутер, даёт нам всё равно 10 мбит трафика, через который можно доставить трафик в сторону CTA. Поэтому так оно дальше передаётся. Правило сложения векторов в этом случае будет такое,

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

мультикастовое сообщение hello. У нас роутер R1 говорит, у меня есть интерфейс, на котором EIGRP работает, туда посылаются сообщения на адрес 224.0.0.10, все EIGRP роутеры, привет. И в обратную сторону, соответственно, от другого роутера то же самое. На тот же самый мультикастовый адрес идёт сообщение привет. И все роутеры, которые работают с EIGRP, они такие hello сообщения видят, и они понимают, что сосед на этом интерфейсе есть, если они видят от него hello сообщения. Плюс там проверяется непротиворечивость настройки соседа. В этих hello сообщениях не просто hello пишется, а показывается, как сосед настроен. Поэтому если мы видим сообщение hello от соседа, мы понимаем, настроен ли он противоречиво по отношению к нам или непротиворечиво. Если сосед непротиворечиво настроен, если он декларирует, что он видит нас, то в этом случае мы можем сказать, окей, с этим соседом у нас есть двусторонняя связность, с этим соседом у нас есть непротиворечивая настройка,

мы можем обменяться маршрутами с ним без особых проблем. И дальше, если у нас происходят какие-то изменения, мы ему эти изменения адресно посылаем. По умолчанию на медленных каналах, медленные — это меньше, чем полтора мегабита, таймер hello будет 60 секунд, но на современных роутерах, на всех, где мы будем работать, всегда это будут каналы быстрее, чем полтора мегабита, и соответственно таймер будет 5 секунд. Если в течение некоторого времени hello сообщения от соседа перестают приходить, то соседство стирается, все маршруты, изученные от соседа, стираются, и маршруты, возможно, перестраиваются. Таймер по умолчанию равен трёхкратному таймеру hello, то есть 15 секунд на быстрых каналах и 3 минуты на медленных. У вас есть табличка соседей, в которую вы заносите информацию, с кем вы подружились. Например, у нас есть некий роутер, и он говорит, у меня есть сосед с IP-шником 10.0.1.1, и есть другой сосед на другом интерфейсе с IP-шником 10.0.2.1.

И каждого соседа мы в табличку заносим. Мы заносим указание, какой у него IP-шник, через какой интерфейс мы с ним подружились, и с каким вектором мы его знаем. В тот момент, когда мы подружились с соседом через интерфейс, мы записываем в эту самую табличку соседства bandwidth на этом интерфейсе и delay на этом интерфейсе. Delay берётся из свойств самого интерфейса. Если не задана команда delay, то берётся задержка сериализации, то есть время, которое требуется абсолютно любому пакету для того, чтобы быть отправленным через этот интерфейс. Когда кадр какой-то кладётся в буфер, и дальше этот кадр разбивается на отдельные битики и начинает отправляться по сети. Там есть определённая задержка сериализации, она фиксированная, и ни при каких обстоятельствах меньше, чем это время, вы не сможете потратить для того, чтобы отправить кадр в интерфейс. Но тем не менее в реальности чаще всего эти интерфейсы, которые отправляют кадры,

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

как вы обменялись всеми записями с соседями, дальше вы из этих возможных вариантов, до каких сетей, через какие маршруты, через каких соседей можно будет добраться, вы выбираете лучшие варианты. Вообще всё сохраняется в некой табличке, а потом из этой таблички вы выбираете лучшие маршруты. Каждый роутер, который будет рассказывать, про какие сети он знает в таблице, он рассказывает, какая сеть известна. Вы запоминаете, какой сосед вам эту сетку рассказал. Запоминаете так называемый reported bandwidth и reported delay. Каждый сосед говорит, я знаю эту сетку с указанием bandwidth и с указанием delay. Вы дальше берёте и прибавляете одно к другому, но тем не менее оригинальное значение, которое вам сосед задекларировал, вы всё равно в табличку складываете. И в нашем случае получается, что сосед 10.0.1.1 заявил, что он знает сетку за 100 мегабит за 1 миллисекунду,

и то же самое сделал второй сосед. То же самое сказал, знает эту сетку за 100 мегабит за 1 миллисекунду. Судя по таблице, которая у нас есть, по рисунку, они оба в эту сетку смотрят просто с 100-мегабитным интерфейсом. Плюс к тому, таблицу соседей тоже никто не отменял. У нас есть указание, что сосед вот такой, известен за гигабитом каким-то, и мы одного соседа знаем за 100 мегабит за 1 миллисекунду, а другого соседа мы знаем за 10 мегабит за 10 миллисекунд. Видимо, этот линк какой-то более медленный и менее производительный. Когда у нас есть некий вектор метрик, который указывает на то, как известна определённая сеть, с этим вектором метрик работать можно, если мы хотим вычленить какую-то отдельную его составляющую. Например, у нас есть некая сетка, мы можем посчитать, сколько мегабит мы в неё можем запихать,

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

И делать это достаточно гибко, чтобы можно было адаптировать наш механизм выбора хорошего или плохого маршрута под задачи, под нужды, которые актуальны в данный момент. И для этого у EIGRP есть специальная хитрая формула, которая будет вычислять для каждого вектора некую функцию, некое число. Это число будет называться computed distance. И этот computed distance будет вычисляться по формуле, которая здесь у нас нарисована. Она большая, страшная, ужасная. Вот она вот такая. Запоминать её не надо. Запоминать её не надо ни на CCNA, ни на CCNP. Если пойдёте на CCIE, там можно её получить, но до тех пор не нужно. Если вы хотите понять, что эта формула делает, я вам расскажу на конкретном примере. Для того, чтобы управлять выбором того, какие компоненты нам будут более или менее интересны, здесь есть так называемые коэффициенты.

Коэффициентов будет пять штук. k1, k2, k3, k4 и k5. Эти коэффициенты можно изменять. По умолчанию они будут равны следующему. k1 и k3 будут равны единице. k2, k4 и k5 будут по умолчанию равны нулям. Как следствие, если мы берём настройки по умолчанию, а настройки по умолчанию будут прекрасно работать в 99,99% случаев, то эта страшная и ужасная формула будет превращаться в существенно менее страшную формулу. k5 у нас будет равен нулю. Соответственно, весь этот множитель, если k5 будет равен нулю, он по правилам математики должен обращать в ноль всё число, но на самом деле он будет просто вычёркиваться, потому что он весь будет равен единице. Если k5 у вас равен нулю, то это просто особый специальный случай, всё, что справа, вычёркивается. Поэтому остаётся только то, что в квадратных скобках слева. Если бы k5 не был равен нулю,

он бы позволил нам сделать так, чтобы мы учитывали компонент метрики, который называется reliability. Это чем более надёжно работает канал между двумя сетями, тем лучше у него будет метрика. Reliability больше, следовательно, этот компонент будет меньше, и computed distance будет меньше. И можно будет на него влиять как раз k4 и k5, указывать на то, больше или меньше этот компонент будет влиять на итоговый результат. Учитывая, что k5 равен нулю, reliability не участвует в подсчёте метрики. Дальше. k4 и k5, мы говорим, что они равны нулю, и они отвечают за reliability. k2 будет у нас вот здесь находиться, И он опять же обнуляет всю эту часть. Вся эта часть отвечает за компонент, который называется load. Вы можете сказать, что в EIGRP вы предпочитаете маршруты, менее загруженные по сравнению с другими. Если у вас есть один маршрут, в котором загрузка транзитных интерфейсов больше, а в другом загрузка транзитных интерфейсов меньше, то мы предпочитаем посылать трафик по тому маршруту, в котором загрузка транзитных интерфейсов меньше.

Но если k2 будет равен нулю, то весь этот множитель обращается в ноль. Всё это слагаемое, простите, обращается в ноль. И у нас остается только эта часть и эта часть. Соответственно, мы берем k1 умножить на scaled bandwidth, плюс k3, умноженное на delay, и всё это умножаем на 256. Это на самом деле будет вот что. Число scaled bandwidth — это производительность нашего пути до удаленной сети, только немножко криво записанная. Это 10 в седьмой степени, деленное на килобиты пропускной полосы до удаленной сети. Чем больше у нас полоса пропускания до удаленной сети, тем меньше число scaled bandwidth. И k1, обращенный в единицу, дает нам просто, что это можно не учитывать, можно учитывать просто scaled bandwidth. 10 в седьмой степени, разделенные на полосу пропускания.

k3, умноженный на delay. k3 — это единица, так что мы берем только delay. Delay выражен в десятках микросекунд. Берем эти два параметра, и здесь я забыл записать, но на самом деле это всё надо умножить на 256. Вот такая формула. Она в настройках по умолчанию, если у нас k1, k3 равны единице, k2, k4, k5 равны нулю, превращается в эту штуку. Bandwidth, выраженная в килобитах в секунду, и delay, выраженная в десятках микросекунд. Только два этих параметра по факту влияют на вычисление computed distance. Когда у вас есть какой-то маршрут, который приходит на роутер, и дальше сосед говорит, что знает эту сетку с определенным bandwidth, с определенным delay, мы говорим, окей. Мы знаем, как сосед знает эту сеть, потому что он в явном виде показывает нам свои мегабиты, свои миллисекунды.

Потом мы знаем, как мы знаем эту сетку, потому что мы знаем соседа через определенный вектор, дальше складываем два вектора и получаем то, как мы знаем сеть через соседа. И мы вычисляем это. Сосед нам заявил, что... 10.0.2.1. Сосед 10.0.1.1 заявил, что знает сеть 10.0.0.0, и говорит: я знаю её за 100 мегабит, я знаю её за одну миллисекунду. Мы говорим, окей, 10.0.1.1. Как мы знаем этого соседа? Мы его знаем через GigabitEthernet 0/0 интерфейс, через 100 мегабит, через одну миллисекунду. Поэтому итоговые значения у нас будут 100 мегабит полосы до удаленной сети и 2 миллисекунды. Из этого числа и этого числа мы выбрали поменьше, а это число и это число мы просто сложили и получили 100 мегабит и 2 миллисекунды. Второй сосед 10.0.2.1. Известен нам через GigabitEthernet 0/1 интерфейс за 10 мегабит и за 10 миллисекунд. Поэтому когда сосед говорит, что знает сетку за 100 мегабит, а мы сами знаем соседа за 10 мегабит, мы говорим, окей, сосед знает за 100 мегабит, но через соседа мы трафик до удаленной сети больше 10 мегабит не пропихнем.

Поэтому итоговый bandwidth для этой сети через этого соседа будет 10 мегабит. А то, что мы знаем соседа за 10 миллисекунд, складываем это с одной миллисекундой и получаем, что мы знаем через соседа сетку за 11 миллисекунд. Этот блок — это то, что сосед нам заявил, а этот блок — это то, что мы по факту посчитали через соседа. Эффективную bandwidth и эффективный delay. Дальше срабатывает та самая страшная формула, которую я вам только что показывал. Мы до каждого маршрута считаем computed distance. Мы берем 100 мегабит. Соответственно, 100 мегабит в секунду — 100 миллионов... Так, раз, два, три. Это биты в секунду, 100 мегабит в секунду. Если мы берем биты в секунду, то их 100 миллионов. Если мы берем килобиты в секунду, которые нам нужны для страшной формулы, то надо просто последние три нолика убрать. У нас остается 100 тысяч.

100 тысяч — это 10 в пятой степени. Дальше, если вы помните формулу, она имеет такой вид — 10 в седьмой степени, деленный на bandwidth плюс delay. И всё это нужно умножить на 256. Но 256 я пока опущу. У нас получается bandwidth 10 в пятой степени. Для того чтобы получить 10 в седьмой степени, разделенное на 10 в пятой степени, записываем дробь, получаем число 100. Эта штука обращается в 100. Delay — 2 миллисекунды. 2 миллисекунды — это 200 десятков микросекунд. Соответственно, этот компонент у нас обращается в число 200. 100, здесь 200. Соответственно, мы говорим 100 плюс 200, и всё это, умноженное на 256, — это будет 300, умноженное на 256. Я сейчас не умножаю на 256, я просто пишу, что оно будет умножено на 256, и в итоге там получится 76 800.

Проще здесь не умножать, потому что в любом случае computed distance будет делиться на 256, и можно просто написать его отдельно. Он для всех маршрутов в итоге будет умножаться на 256 просто так, для красоты. Что касается этого маршрута. 10 мегабит и 11 миллисекунд. То же самое. Подставляем его в эту формулу. 10 в седьмой степени, разделенное на 10 в четвертой степени. Это 10 мегабит. Это 10 тысяч килобит в секунду. Плюс 11 миллисекунд. Это у нас 1100. 1100 десятков микросекунд, которые нужны нам в этом компоненте delay. 10 в седьмой, деленное на 10 в четвертой, это 1000. И соответственно, 1000 плюс 1100 дает нам 2100. И всё это умножается на 256. Для чего этот computed distance нам будет нужен? Мы для каждого маршрута по некой хитрой формуле считаем итоговое число.

Это итоговое число указывает на хорошесть или плохость маршрута. Чем лучше маршрут, тем computed distance будет меньше. Мы можем играть с помощью коэффициентов K1, K2, K3, K4, K5. Какие именно компоненты маршрута нас будут особенно сильно интересовать. Но по умолчанию примерно одинаково учитывается bandwidth и учитывается delay. А всё остальное не учитывается вовсе. Поэтому мы взяли два маршрута и посчитали по ним итоговую метрику. И получилось 300 и 2100. На самом деле, умноженное на 256. Нам сейчас для красоты лучше этого не умножать, чтобы не плодить цифры. И у кого меньше, тот и лучше. Чем меньше computed distance, тем лучше маршрут. Очевидно, что маршрут за 10 мегабит и 11 миллисекунд сильно хуже, чем маршрут за 100 мегабит и за 2 миллисекунды. И задержки выше, и производительность меньше у такого маршрута. И поэтому computed distance у него сильно выше. Если у нас есть маршруты, которые можно сравнить между собой, то с помощью computed distance мы можем сказать, да, отдельные компоненты у нас различаются.

По этим компонентам вычисляем некую итоговую метрику. Чем эта метрика меньше, тем маршрут будет лучше. Тот маршрут, у которого computed distance будет самый маленький, устанавливается в таблицу маршрутизации. И тот сосед, который прислал нам такой маршрут, будет next hop в таблице. В нашем случае мы говорим, этот маршрут до сети 10.0.0.0/24 будет лучше. А этот маршрут до такой же сети будет хуже. Поэтому в таблицу маршрутизации мы добавляем маршрут через более выгодного соседа. При этом мы отдельно запоминаем, как мы знаем сетку через соседа, и отдельно запоминаем, как сосед знает эту сетку. И делается это для вполне определенной цели. Дело в том, что если вы знаете, с какими метриками сосед вам прислал определенный маршрут, то вы можете посчитать по той же самой формуле, какая метрика, какой computed distance был посчитан этим самым соседом.

Если вы возьмете reported bandwidth, reported delay, который прислал вам сосед, запихнете в ту же самую формулу, по которой вы считали свой собственный computed distance, то если у соседа такая же формула, то вы получите то, с какой метрикой маршрут у него был известен, с какой метрикой самый выгодный маршрут у него был поставлен в таблицу маршрутизации. Если вы берете и запихиваете его 100 мегабит и его 1 миллисекунду в формулу, 100 мегабит — это у нас 10 в пятой степени, 10 в седьмой степени, деленное на 10 в пятой степени, плюс 1 миллисекунда — это 100 десятков микросекунд, дает вам суммарную reported distance 200. Reported distance — это результат того, что вы посчитали на основе его мегабитов, его микросекунд, какая у него была метрика. А делается это вычисление, какая у него была метрика, для очень хитрой штуки. Давайте разберемся, какая хитрая штука может быть. EIGRP очень боится петель. Он никогда не ставит в таблицу маршрутизации маршрут, если подозревает, что этот маршрут может пройти через вас.

Если все маршрутизаторы никогда не позволяют маршруту пройти через них самих, то у вас все маршруты не содержат петель. Достаточно простая логика. И как защититься от маршрута, который проходит через вас? Сосед рассказывает, что он знает какую-то сетку. Может быть, он знает некоторую сетку, потому что ему эту сетку рассказал кто-то третий. А этому третьему рассказал четвертый. А этому четвертому рассказали, что эту сетку знаете именно вы. Такая штука может произойти. Может быть даже более простой сценарий. У вас есть два роутера R1 и R2. Соответственно, один роутер говорит: я знаю некую сеть A. Рассказывает её своим соседям. R2 говорит: я знаю эту сеть, и отсылает её в ответ роутеру R1 тоже. Можем ли мы верить такому маршруту? Если у нас есть, понятное дело, сам маршрут в эту сеть A, то мы такому маршруту верить не будем, потому что здесь у нас есть более выгодный маршрут, здесь у нас есть менее выгодный маршрут.

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

Если мы кому-то рассказали, что знаем некоторую сетку, например, за 200 копеек, а потом кто-то рассказал кому-то другому, что он знает сетку за 250 копеек, а потом кто-то другой сказал, что знает сетку за 270 копеек, — при передаче маршрутов через соседство композитная метрика, computed distance, никаким образом не может упасть, она может только вырасти. Поэтому если мы принимаем маршрут от соседа и сосед декларирует, что знает эту сетку дороже, чем мы сами знаем, то этот маршрут потенциально может проходить через нас. Он не обязательно проходит через нас, но потенциально может проходить через нас. И этот feasibility condition — если сосед заявил сетку дешевле, чем мы сами знаем эту сетку, — это и будет алгоритм, с помощью которого EIGRP гарантирует отсутствие петель в таблице маршрутизации. EIGRP никогда не будет верить такому маршруту, который декларирует reported distance больше, чем наш собственный computed distance самого выгодного маршрута.

Соответственно, если сосед декларирует, что его reported distance больше, чем наш computed distance, то мы говорим: это потенциально может содержать петлю через нас. Если вдруг мы захотим использовать такой маршрут, то мы должны будем осуществить дополнительные проверки. И мы не верим такому маршруту, мы его запоминаем на всякий случай, но в таблицу маршрутизации без дополнительных проверок его не ставим. Есть нюанс. Заключается он вот в чем. Если вдруг вы когда-нибудь кому-нибудь рассказывали, что у вас некая сетка была доступна, и эта сетка была доступна по какой-то очень выгодной метрике, а потом вы перестали рассказывать, что эта сетка у вас доступна по выгодной метрике, потому что выгодный маршрут у вас у самих пропал, но был какой-то не очень выгодный маршрут, которому вы тем не менее верили. И у вас получается эффективная стоимость этой сети раньше была поменьше, а сейчас стала побольше. Кто-то вам рассказывал, что знает сетку за гигабит, а сейчас рассказывает, что знает сетку за 100 мегабит. Вы ему верите, вы дальше рассказываете всем, насколько хорошо вы знаете эту сеть,

но гипотетически может быть такое, что у вас только что прошло изменение. Раньше вы говорили, что вы знали сетку за гигабит, потому что вам кто-то присылал указание, что знает сетку за гигабит. Теперь он рассказывает, что знает сетку за 100 мегабит, вы начали рассказывать, что знаете сетку за 100 мегабит, вы у себя метрику поменяли, но кто-то вдруг в этот момент вам начинает рассказывать, что знает эту самую сетку всё ещё за гигабит. Можете ли вы этому верить? Не можете. Дело в том, что в этой ситуации вы должны будете помнить не только текущее состояние, за сколько вы прямо сейчас знаете эту сетку, но и вообще самый выгодный computed distance для каждого маршрута, который у вас когда-либо был. Может быть, раньше, давным-давно вы когда-то видели эту сетку за гигабит. Поэтому если сейчас кто-то вам рассказывает, что знает эту сетку за гигабит, это возможно, потому что вы когда-то ему давно эту самую сетку продали за гигабит, пообещали. И сейчас вы по факту не можете уже сказать,

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

чем раньше когда-либо знали. А если у вас сейчас есть какая-то сетка, доступная за одну стоимость, а потом что-то произошло, и вы стали эту сетку знать хуже, за другую стоимость, — самая выгодная метрика — это ваши воспоминания о былой любви, она всё равно хранится для этой сети, и она указывает, за сколько вы эту сетку когда-либо сами знали. Так вот, feasibility condition — это то самое условие: не может ли такого случиться, что маршрут потенциально содержит петлю через нас. Это проверка на то, за сколько знает сосед эту самую сетку. Если его reported distance строго меньше, чем наша feasible distance, его reported distance строго меньше, чем самая выгодная метрика на нашем роутере за всю историю наблюдений, то в этом случае маршрут через нас точно не содержит петлю, и он может быть установлен в таблице маршрутизации немедленно. Маршрутизатор, который прислал маршрут, удовлетворяющий feasibility condition,

будет называться feasible successor. Таких маршрутизаторов, которые присылают вам доверенные маршруты, не содержащие петлю через вас, может быть несколько. Но по умолчанию среди всех feasible successor выбирается тот один маршрутизатор, который прислал самый выгодный маршрут. Не тот, который заявил, что у него самая выгодная метрика, а тот, который среди всех, прошедших условие feasibility condition, прислал маршрут с самой выгодной эффективной стоимостью. Successor — это тот один, который дал самую выгодную стоимость. Я обычно люблю демонстрировать работу этого механизма feasibility condition на примере с торговлей. Если у нас есть, например, компания, которая занимается торговлей чем-нибудь, допустим, валенками. Мы хотим продавать валенки, но эти самые валенки мы не хотим нигде складировать.

Мы хотим иметь поставщика, который нам гарантированно при необходимости продаст определённые валенки, и мы знаем, что если вдруг мы найдём клиента для этих самых валенков, то мы поедем к нашему поставщику, заберём валенки у него, привезём на наш склад и скажем клиенту «забирай», всё хорошо. В этом случае нам не нужен будет большой склад, мы можем просто обходиться даже маленьким офисом и зарабатывать деньги просто на том, что мы ищем клиентов. Таким бизнесом можем заниматься не только мы. У нас есть коммерческое предложение поставщика, и мы периодически можем продавать своим клиентам эти самые валенки, выставляем коммерческие предложения, и рано или поздно клиенты будут у нас действительно что-то покупать. Естественно, если клиент приходит к нам и говорит, за сколько у вас можно купить валенки, то мы ему даём предложение, сколько стоит отгрузка валенков с нашего склада. При этом мы туда включаем нашу себестоимость, наши транспортные расходы, сколько нам стоит забрать эти валенки со склада поставщика.

Просто обычный нормальный бизнес. Может быть, какие-то свои косты заложим, а может быть, и не заложим, если у нас социализм. Если вдруг у вас есть два поставщика, которые присылают вам коммерческое предложение, хотите ли вы купить у нас валенки, мы выбираем среди них того поставщика, который предлагает нам наиболее выгодную цену. Если нам один поставщик говорит, я готов продать вам валенки за 100 рублей, а другой говорит, я готов вам продать валенки за 300 рублей, дальше мы прибавляем стоимость транспорта, и выясняется, что с первого поставщика дополнительно ещё 500 рублей надо потратить на дорогу, и эффективная стоимость получается 600, а с другого поставщика нужно будет потратить только 100 рублей на дорогу, и эффективная стоимость получается 400. Понятное дело, что мы выбираем того, у которого по факту самая маленькая стоимость среди наших поставщиков. Это как раз выбор, что мы для каждого маршрута считаем computed distance и выбираем, насколько хорош или плох конкретный поставщик,

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

которые мы когда-то сами пообещали кому-то продать. И feasibility condition заключается именно в этом: если кто-то reported distance заявляет больше, чем наша самая маленькая метрика за всю историю наблюдения, самый маленький feasible distance, то это маршрут, который гипотетически может содержать петлю. Мы записываем его всё равно, если, опять же, пример с валенками, кто-то нам пообещал валенки по 400 на своём складе, когда мы их сами отгружали по 300, мы говорим, окей, мы вашу визиточку возьмём, мы вам не особенно доверяем, но если у нас все остальные поставщики отвалятся, мы к вам придём и спросим, слушайте, а вы точно уверены, что вы не через нас валенки берёте? А вы у себя проверите и скажете нам, точно это или нет. Такой механизм позволяет вам иметь пул надёжных поставщиков и пул ненадёжных поставщиков. Надёжные — это feasible successors, а среди всех надёжных поставщиков, которые у вас есть, есть один, который даёт самую вкусную цену с доставкой до вашего склада. Это будет successor. Это что касается теории EIGRP.

Давайте попробуем всё это дело сконфигурировать на практике. Продолжение следует...