Транспорт IP-MPLS (1)

Я думаю, что по названию этого слайда вы уже догадываетесь, что речь пройдет про IP. И да, действительно, как я уже говорил в начале предыдущего модуля, большого модуля про транспортные сети на основе 802-х комитетов, что есть два способа перекладывания данных между интерфейсами. Первый способ — мы используем коммутацию, второй способ — мы используем нативные, созданные под это дело маршрутизацию. IP изначально создан как протокол для перекладывания данных между интерфейсами. Ethernet не был создан изначально для перекладывания данных между интерфейсами, в нем эта функция появилась позднее, и как следствие механизм, с помощью которого Ethernet перекладывает данные между интерфейсами, он довольно ущербный и вызывает много проблем. Но он очень простой и очень дешевый. Если мы говорим про IP, то, соответственно, здесь у нас есть много крутилок, вертелок, которые можно реализовать. И, как следствие, контролировать потоки трафика, существенно, более тонко.

Давайте разбираться. Модуль большой, и я думаю, что нам его много хватит. Начнем с того, что в самых первых версиях протокола IP, те, которые еще были престандартные, то есть они еще были до RFC 760, 791, не было вообще нигде сказано, что такое маршрутизация. Да, был протокол IP, да, было перекладывание данных между интерфейсами, но при этом нигде не было написано, как это происходит. То есть был формат пакета, да, был. Да, мы можем отправить IP пакет, он как-то магическим образом дойдет от отправителя до получателя. Но самые первые версии IP исходили из того, что, вы не поверите, пакеты будут перекладываться во все интерфейсы, кроме интерфейса источника. То есть задачей изначально в протоколе IP было просто доставить пакет любой ценой. Опять же, вспоминаем историю, вспоминаем, что IP создавался под нужды бравых ребят из Министерства обороны, которым нужно было в случае, если половина страны лежит в пейдерных руинах,

отправить команды на секретные бункеры, чтобы оттуда орудие возмездия обязательно ни в коем случае не осталось в этих шахтах, а долетело до Советского Союза и нанесло бы ответный удар. Но, соответственно, там не было задачи делать это наиболее эффективно, наиболее оптимально. Там была задача просто донести эту информацию, особенно в случае, когда сети в непредсказуемом состоянии, в непонятном состоянии каналов находятся. Поэтому вот мы отправляем один пакетик, в этом одном пакетике вся жизнь находится, и вот этот пакетик начинает разбегаться по сети. Мы его отправляем в один интерфейс, он доходит до соседнего роутера, дальше роутер следующий распространит вообще во все интерфейсы, копирует просто. Дальше следующий роутер по цепочке начинает его рассылать дальше, и вот он разбегается по всей, всей, всей, всей сети до тех пор, пока не дойдет до сети назначения, и получатель его, соответственно, не получит со всеми вытекающими или вылетающими отсюда последствиями.

Потом, когда IP стал задействоваться уже гражданскими, те стали понимать, что методика передачи пакета, копии пакета вообще во все интерфейсы, она ущербная, и, соответственно, стали пытаться как этот процесс оптимизировать. Поэтому чаще всего мы сегодня взаимодействуем в IP с так называемым Unicast-овым типом взаимодействия, когда мы отправляем один пакет, и этот пакет доходит до только получателя и больше никого. Или, может быть, не доходит вообще ни до кого, потому что где-то по дороге он теряется, ну, не обрабатывается. Для того, чтобы это сделать, нам нужно будет на каждом транзитном роутере, который будет получать пакет на входном интерфейсе, принимать решение, через какой именно выходной интерфейс можно будет этот пакет отправить. В случае с Unicast мы получаем IP-пакет на одном интерфейсе, мы его перекладываем не более чем в один выходной интерфейс. На самом деле в IP есть много разных типов взаимодействия. Можно будет представить себе, что у нас есть, например, Multicast.

Он тоже в IPv4 есть, и про него как бы отдельно будет разговор. Но, тем не менее, в Multicast мы принимаем один IP-пакет на одном интерфейсе, и мы раскладываем копии этого пакета на других интерфейсах, причем получаем один пакет, отправляем, получается, несколько копий этого пакета на разных интерфейсах. Но Multicast в IP — это тема отдельная, большая, и мы его пока сейчас, прямо вот сейчас, трогать не будем. Мы все-таки говорим про Unicast. IPv4 Unicast появился как отдельная сущность довольно поздно по сравнению с штатным IPv4. То есть в IPv4 у нас была штатная процедура предусмотрена перекладывания пакетов между интерфейсами, но механизм ее не был описан. Вот RFC 1812, который появился мне, по-моему, году в 95-м, что ли, вот он только стал фиксировать, как это должно происходить. До того момента каждый производитель маршрутизаторов

делал совершенно, что хотел, то есть там был полный бардак. И вот RFC 1812 зафиксировал то, как должны себя вести хорошие IPv4 роутеры. В принципе, по этому стандарту нигде не сказано, что вы должны, вы прямо обязаны использовать тот механизм маршрутизации, который мы обсуждаем на CCNA. Это табличная маршрутизация на основе адреса назначения или destination-based routing. Естественно, чаще всего используется именно он. Но, в принципе, гипотетически никто вам не мешает использовать другие виды маршрутизации. Я вам в качестве примера могу показать два. Первый, другой способ не табличной маршрутизации – это policy-based routing. Вы отправляете пакет, и у вас на каждом маршрутизаторе просто прописаны некоторые правила. Куда, какие пакеты девать. Вы можете сказать, что все пакеты, которые идут, допустим, на адреса сервера телефонии, они отправляются всегда через один и тот же выходной интерфейс. Вот. Или все пакеты, которые содержат в себе TCP на нечетные порты.

Они отправляются через определенный интерфейс. То есть вот такого рода правила вы можете прописать. И если вам кажется, что это какая-то очень странная штука, нет, это не странная штука. В предприятиях она очень активно используется. В провайдерах она редко используется, потому что железо, которое ее может делать на достаточно серьезных скоростях, стоит очень серьезных денег. А у провайдера люди такие жадные, у которых много денег обычно нету, поэтому policy-based routing в провайдерах не самый частый гость. Вот. Вы можете в policy-based routing использовать правила, которые будут ориентироваться на практически все, что угодно. То есть можно ориентироваться на содержимое пакета, можно ориентироваться на загрузку интерфейсов, можно ориентироваться на то, какой сегодня время, какой сегодня день недели, какое сейчас время суток. То есть, допустим, днем обрабатываем пакеты так, ночью обрабатываем пакеты эдак. По таблице это сделать невозможно таким образом, а вот с помощью политик можно. Еще один механизм, который изначально в RFC был предусмотрен, но, тем не менее, сегодня очень-очень редко используется, я бы сказал настолько редко, что не используется вовсе, это так называемый source routing, когда вы отправляете пакет, и у вас отправитель заказывает, по какой трассе пойдет пакет в сторону получателя.

То есть вы на отправителе заранее прописываете трассу, как транзитные маршрутизаторы должны в каком порядке отправлять пакет до получателя. Когда-то давным-давно, в районе 791 RFC, это был основной способ маршрутизации, если вы не хотели разбрасывать копии пакетов на вообще все интерфейсы. Мы просто указывали на отправителя, что пакет должен пойти по определенной трассе, а если он по этой трассе пройти не может, то дальше включается обычное раскладывание на все интерфейсы. Но сегодня source routing не применяется. Используется для такого взаимодействия IPv4 опция либо strict source route, либо loose source route. Ну и пакеты с IPv4 опциями, как вы знаете, в сети не передаются, поэтому это всего мы в 2019 году, к сожалению, лишены. А может и к счастью. Ну, как бы здесь тонкий философский вопрос. Кто больше права имеет решать, по какой трассе должен пойти пакет?

Либо транзитные узлы все имеют право решать за себя самостоятельно, либо отправитель, если хочет, он может явно видео указать, по какой трассе надо пустить пакет. Если мы используем табличную маршрутизацию, то мы должны будем построить таблицу со всеми-всеми маршрутами, которые у нас есть во всей-все-все сети в мире. При этом эта самая таблица, она должна быть, а, полной, и, б, она должна быть какой-то разумного размера. То есть она должна указывать, на какие шлюзы надо направлять трафик, чтобы достичь определенных сетей. Если мы будем раскладывать, допустим, вообще все узлы в интернете по отдельному маршруту слэш-32, допустим, в IP в четвертом интернете, в таблицу, то у нас получится невероятно большое количество записей. Сейчас в интернете порядка 20 миллиардов узлов. Естественно, ни одна железка просто не вытянет хранить 20 миллиардов узлов одновременно. Для того, чтобы это хоть как-то, хоть приблизительно было достижимо на железе, вы должны будете выделять адреса блоками.

И вы должны будете говорить, что блок адресов с такими вот свойствами находится в таком вот направлении. Блок адресов с другими свойствами находится в другом направлении. И, соответственно, удобно будет, если у вас на этапе выделения IP-адресов вашим узлам будут использоваться вот эти вот блоки с иерархической структурой. То есть у вас есть какая-то глобальная сеть. Ну, глобальная, не знаю. Слово глобальная, наверное, не очень хорошее. Просто сеть. И вы хотите в этой сети использовать некоторое количество IP подсетей. Ну, у вас есть блок адресов. Вы говорите, окей, на всю сеть мы выделяем наш большой блок. Дальше мы его делим условно пополам или на четыре части. И мы на каком-то глобальном уровне разделяем вот эти вот самые сети по блокам. То есть мы говорим, у нас слева будет один большой блок и справа будет один большой блок. При этом мы понимаем, что блок адресов – это просто последовательность чисел от одного числа до другого числа.

Вот дальше там число, например, миллиард. Это IP-адрес. 1-0-0-0-0-0-0. Это вот IP-адрес. 2 миллиарда – это тоже IP-адрес. 2-0-0-0-0-0-0-0-0-0-0-0. Вот это два числа, просто числа. И, соответственно, все числа между ними. Миллиард 1, миллиард 2, миллиард 3 – это все IP-адреса. Все это числа. Если мы хотим сказать, что у нас есть некий блок адресов, то мы говорим, у нас этот блок содержит все адреса, начиная с одного числа до некоторого другого числа. Если мы хотим сказать, что мы хотим разделить этот блок пополам, окей, не проблема. Мы говорим, что все числа до серединки – это один блок, одна половинка блока, все числа до другой половинки – это другая половинка блока. Не очень эстетично получилась картинка, но тем не менее. Если мы берем и назначаем кусочки блоков по некоторому территориальному признаку, то чаще всего мы имеем возможность просто сказать,

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

про те блоки, которые у нас будут, соответственно, непосредственно на нашем уровне находиться. Плюс мы будем знать, что все остальные блоки доступны через наш апплинг, через который доступны все остальные сети. Поэтому мы будем экономить таким образом место в таблицах маршрутизации. Все, что внутри вот этого блока, нас не интересует. Оно все смотрит на какой-то роутер, который распоряжается этим блоком. Если он дальше хочет разделить на 2 части, на 4 части, на 8 частей, он может это делать, но нам про это пусть не говорит. Соответственно, у нас есть интерфейс на него, мы на него смотрим большим куском адресов, и дальше с этим куском адресов ниже стоящий роутер пусть делает, что хочет. То же самое, если мы смотрим каким-то интерфейсом на внешний роутер. Мы не должны будем знать, что происходит в других блоках за спиной у того роутера. Мы говорим, все сети в мире доступны через соседа, который находится выше. В крайнем случае он может рассказать нам, какие еще есть блоки рядышком.

Вот здесь один блок, здесь другой блок, здесь третий блок. То есть он может рассказать таким образом про минимальное количество блоков. У нас в таблице маршрутизации будет небольшое количество сетей, и все эти сети будут плюс-минус километр каким-то удобным образом обрабатываться. Иногда можно будет встретить то, что в какой-то момент вы говорите, окей, мы взяли блок адресов, поделили его на две части, и, допустим, левый кусок, левую часть мы отдали под один район города, правую часть кусок мы отдали под другой район города. Дальше внутри какого-то территориального блока идет разделение по, например, сервисам. Такое тоже бывает. То есть мы говорим, что у нас есть, допустим, сеть 10.0.0.0.8. Вот мы говорим, здесь у нас блок 10.0.1.0.0.0.16, здесь блок 10.2.0.0.0.16,

и там дальше 3, 4, 5 и так далее. То есть этих блоков будет много. Вот мы можем сказать, окей, давайте мы блок 10.1.0.0.0 выделяем под район города такой-то. Дальше внутри этого блока мы говорим, мы тоже делим его на части. 10.1.1.0.0.24, 10.1.2.0.0.24 и так далее. Можно в какой-то момент сказать, давайте мы будем делить не по территориальному признаку, не по улицам, не по районам, а мы будем делить по сервисам. И на каком-то одном уровне мы можем сказать, вот именно на уровне третьего деления мы говорим, давайте все IP-адреса, которые будут в третьем актете иметь число 1, это будет, не знаю, voice over IP. Те сети, которые будут иметь в третьем актете число номер 2, это будет, не знаю, мобильная связь. То есть по сервисам можно тоже таким же образом кодировать. То есть вы все равно испытываете плюшки от того, что у вас на более высоком уровне,

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

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

Самый простой способ — это сказать, давайте мы в определенную сеть будем смотреть интерфейсы. То есть у нас есть роутер, у него есть интерфейс, на этом интерфейсе мы вешаем IP-адрес, мы указываем, что адрес у нас будет 10.1.1.24.24. И что означает вот это вот 24? То, что все адреса, которые начинаются на 10.1.1 на 24 бита, будут находиться в этом канале. Это будет так называемая присоединенная сеть. То есть у нас есть свой собственный адрес 10.1.1.24, и у нас есть присоединенная сеть 10.1.1.0, которая содержит все узлы, которые в одном канале с нами находятся. Вот это вот присоединить маршрут к интерфейсу. Можно будет либо повесить адресный интерфейс, это произойдет автоматическое присоединение, либо вы можете вручную присоединить маршрут, то есть, например, вы можете, если мы говорим про цинскую, использовать команду IP-road. И дальше мы указываем там 10.1.1.0. По маске 0.0.255.255.0.

И дальше мы указываем интерфейс Ethernet 0. Таким образом... Ну, или 0.0. Мы таким образом указываем, что вот вся вот эта вот сеть 10.1.1.0, она будет присоединенной сетью, оттачат сетью на интерфейсе. Это очень часто команда используется ошибочно, когда люди пытаются прописать маршрут по умолчанию, там пишут IP-road 0.0.0.0.0.0.0.0.0. И дальше указывают направление, в котором будет доступен маршрут по умолчанию. Там типа гигабит 0.0. Вот если вы не указываете шлюз вот здесь, а если вы указываете только интерфейс в команде IP-road в CISC, то у вас создается именно присоединенная сеть. И тогда на любые попытки обратиться к этой сети у вас будет работать, ну, в случае с IPv4 протоколом IRP, если мы говорим про Ethernet. Вот. Так что будьте осторожны. Вот такие вот конфигурации имеют право на жизнь, но в очень определенных случаях. То есть в совершенно произвольных случаях прописывать команду IP-road с указанием только интерфейса без указания IP-шника шлюза –

это не очень хорошая идея. В разных операционных системах может быть по-другому. То есть не обязательно команда будет иметь совершенно в любом железе вот такой вот вид. Присоединение маршрута – это просто указание, что вот все узлы в этой сети, которые мы присоединяем, они доступны напрямую через интерфейс. Если доступны напрямую через интерфейс Ethernet, значит, будем IRP-ом до них пытаться достучаться, будем пытаться отправлять трафик на их MAC-адрес напрямую. Вот. Можно будет сказать, что у нас есть какая-то сеть, которая не напрямую подключена к нам, она где-то еще находится. То есть мы должны обратиться к некоторому транзитному узлу, с которым мы находимся в одном канале, и дальше мы должны отправить трафик ему, а он уже доставит этот пакет куда-то в сторону сети получателя. Такой маршрут можно прописать либо статически, то есть мы ручками говорим, что вот, пожалуйста, до вот такой вот сети обращаюсь через такой вот шлюз. Либо использовать автоматический протокол настройки таблицы маршрутизации,

репликации таблицы маршрутизации. Это у нас, ну, чаще всего будут использоваться специализированные протоколы, которые заточены под динамическую маршрутизацию. В курсе у нас рассматривается OSPF, EGRP, ISIS, RIP здесь куда-то делся, ODR — это не совсем протокол, RIP, ну и BGP. BGP — это как бы основной провайдерский протокол, про него будет отдельный большой рассказ. В случае с некоторыми другими протоколами, они тоже могут создавать маршруты в таблице маршрутизации, ну, из таких классических приметов, например, DHCP. Когда вы DHCP-адрес получаете, он вам, как правило, не только адрес и маску дает, он еще и прописывает шлюз по умолчанию. Шлюз по умолчанию — это тоже маршрут. Он просто говорит, что все пакеты до всех сетей в мире отправляй вот на вот этот вот шлюз, дальше он разберется. Это фактически маршрут до сети 0.0.0 по нулевой маске. Может быть такое, что вам ICMP притащат маршрут,

может быть такое, что вам NHRP притащат маршрут. То есть маршрутов, которые вообще-то решают какие-то другие задачи, протоколов, которые решают другие задачи, но притаскивают маршруты, их, в принципе, много. Если говорить вот даже про Cisco в качестве примера, вот у нас есть команда showip.road, она показывает тут вот много чего, связанного с маршрутами, но вот эту вот колбасу ее обычно никто не читает. На самом деле тут много всякого. Маршруты могут быть Skeקt, это вот напрямую присоединенная сеть, но автоматически присоединенная. Могут быть статические маршруты, опять же, могут быть присоединенные статические маршруты, когда указывается интерфейс, или присоединенные маршруты, статические маршруты до внешних сетей, когда указываем адрес шлюза. Можем указать, что у нас есть маршруты риповские, джепишные, днежиртишные IP-шные в различных вариациях, OSPF-овские в различных вариациях, ASAS-овские в различных вариациях, ODR, да, ну, недопротокол такой, NHRP, LISP, ну, то есть LISP тоже недопротокол.

Вот, так что возможных вариантов, как получить маршрут в таблице маршрутизации, их, в принципе, много. Каким образом будет работать роутер с таблицей маршрутизации? Я вам показываю сейчас пример по RFC 1812. Дело в том, что каждый конкретный вендор имеет свое видение на тему того, как ему следует работать с таблицей. Поэтому в разных железках, в разных вендоров можно встретить, будет, разные поведения. Не пугайтесь, пожалуйста, если вы в CISC-е видите какую-то концепцию, видите похожие даже слова в оборудовании других вендоров. Там, допустим, у CISC-ки есть административное расстояние, у других вендоров есть административное расстояние. Вот эти административные расстояния не могут быть совсем разные. То есть это может быть не просто числа разные, они могут быть еще и разные концепции за ними стоять. Поэтому по RFC 1812 вы должны будете пополнить таблицу. Эта таблица будет состоять из отдельных маршрутов, то есть указывается до какой сети, айпишник, там, допустим, маска, условно говоря,

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

при котором он может получить один маршрут. Давайте нарисую прям у роутера BGP. И вот у него есть один сосед тоже по BGP присылает какие-то маршруты. И другой сосед тоже по BGP присылает какие-то маршруты. Вот если один сосед присылает маршрут и другой присылает маршрут по BGP, BGP роутер должен выбрать из двух вариантов, как доставить трафик до одной и той же сети, один. И в таблице маршрутизации BGP всегда будет вбрасывать один маршрут. Он никогда не вбросит два разных. Но, соответственно, вбрасывает он по какому-то принципу свой собственный маршрут, который он присчитал хорошим. Вот он посчитал, получил два маршрута от соседа, посчитал, принял решение, что какой-то маршрут через верхнего соседа он будет, соответственно, получше, через низ похуже, и в таблицу маршрутизации вносит свой один маршрут. Вот, например, 192, 168, 3, 0, по 24 маске BGP-шный маршрут вставил в таблицу маршрутизации. То, что у BGP в свое время были какие-то другие маршруты, которые BGP отбросил, потому что они ему не понравились,

он их не посчитал лучшими, не посчитал возможными, это сугубо проблема BGP. Так таблица маршрутизации не имеет никакого отношения. То есть у BGP есть два маршрута, один и второй. Он среди них взял и один отбросил, а второй выбрал в качестве лучшего. Поставил его в таблицу маршрутизации, в таблице маршрутизации появился один возможный маршрут до некоторой сети. BGP не будет ставить два маршрута, одним из которых можно будет пользоваться, а вторым нельзя будет пользоваться. BGP поставит один и лучший. Дальше. После того, как различные источники носовали в таблицу маршрутизации разные маршруты, дальше происходит процедура обработки пакета. То есть у нас таблица пополнилась, на наш роутер приходит некий пакет. И пакет проверяется по таблице маршрутизации, куда надо его будет девать. Если у вас есть несколько маршрутов, под которые попадает IP-адрес получателя в пакете, а мы сейчас говорим про Destimation-Based Routing, то в этом случае мы все такие маршруты

помечаем как кандидаты. То есть, допустим, у нас есть пакет, который хочет пройти на адрес 192.168.22. В этом случае мы смотрим, первый маршрут может ли быть использован для доставки трафика в сторону адреса 192.168.22. Нет, не может. Второй может, нет, не может. Третий может, да. Третий может. Четвертый может, нет. Пятый может, нет. Вот мы так по всем маршрутам пробегаемся и находим список кандидатов для того, чтобы отправить трафик в сторону сети назначения. Если в процессе выяснилось, что у нас только один такой кандидат образовался, как в нашем случае, то есть вот 112.168.2.0, только он может быть до 192.168.22 использован, то вот в случае с одним кандидатом все легко. Мы просто его и выбираем. Если у нас после построения таблицы маршрутизации, после того, как мы принимаем решение, куда мы хотим девать определенный IP-пакет, образовалось несколько маршрутов кандидатов

для доставки конкретно этого пакета, то мы выбираем соединение один по некоторому алгоритму. Самый простой способ – использовать правила longest prefix match. То есть это значит, что маршрут, у которого маска числово больше, будет более правильный. А маршрут, у которых маска будет числово меньше, будет менее правильный. В ситуации, например, когда у вас есть маршрут по умолчанию 0000-0, вот этот маршрут всегда будет всем проигрывать, потому что у него маска самая маленькая. И любой маршрут на более конкретной сети, он у маршрута по умолчанию будет выигрывать. Может быть такое, что у вас в таблице маршрутизации будет несколько маршрутов с одинаковыми масками, с одинаковыми IP-шниками, с сети одинаковыми масками. Такое гипотетически возможно. Не всегда можно такое будет встретить на конкретном железе, потому что будет такое железо, которое будет запрещать вбрасывать в таблицу маршрутизации несколько маршрутов разных до одной и той же сети. Но иногда такое может происходить.

В этом случае у вас будут использоваться какие-то дополнительные тайбрейки. Ну, то есть можно будет для каждого маршрута задать такой параметр, как метрика. Можно будет задать для каждого маршрута вес. Можно будет задать для каждого маршрута так называемую дистанцию. То есть вот, например, если говорить про те же самые Linux и роутеры на основе Linux, то там есть возможность в таблицу маршрутизации поставить сколько угодно маршрутов. Но они будут выбираться, если вдруг у нас есть два маршрута, которые до одной и той же сети имеют разное так называемое расстояние, то выбираться всегда будет тот, у которого расстояние меньше, дистанция меньше. Это не административное расстояние, это именно дистанция. Вот. Дальше. После того, как мы определили, что у нас есть некий маршрут, который самый-самый лучший, то есть на основании сначала Linux, Prefix, Match, а потом на основании всех остальных критериев, вот определили, что в таблице маршрутизации самый правильный маршрут для обработки трафика на определенный IP-адрес

это будет вот некоторый вот этот вот маршрут. Он должен указывать куда-то, куда нам надо девать трафик. То есть либо это будет какая-то присоединенная сеть, он говорит, это надо отправить там в интерфейс Ethernet 0, напрямую дощупать адрес получателя, канальной, и отправлять. Либо это будет какой-то шлюз, то есть у нас есть шлюз в одной сети с нами, и мы должны отправить данные ему. Обычно эта штука называется NextHop. Вот. Присоединенный шлюз, значит, что у нас есть NextHop, который в одной сети с нами, то есть мы обнаруживаем с помощью какого-то механизма канальный адрес этого шлюза и отправляем данные напрямую ему. Либо может быть такое, что у вас указан рекурсивный IP-адрес шлюза, и в этом случае надо будет повторно задать вопрос таблице маршрутизации, а куда девать трафик до вот IP-шника, который у нас задан в качестве NextHop по некоторому маршруту. Рекурсивный значит, что вы повторно пробегаетесь по таблице маршрутизации, пытаетесь выяснить, как доставить трафик до некоторого адреса, который вы верите, что является адресом шлюза.

При этом по факту этот адрес шлюза может даже не существовать нигде. Вот, например, смотрите, здесь у нас есть некий роутер, у него есть коннект от сетки 112.168.1.0, и в частности она коннект от, потому что у этого роутера есть IP-шник 112.168.1.2 по 24-й маске на интерфейсе Gigabit 0.0. Так вот, этот самый роутер подружился с некоторым соседом по OSPF, и OSPF притащил маршрут 112.168.2.0 по 24-й маске. Дальше. У нас есть некий другой роутер, вот этот 112.168.2.1, с которым мы подружились по BGP, потому что у нас есть 112.168.2.1 адрес через OSPF. Вот мы по OSPF узнали, как добраться до IP-шника 112.168.2.1, подружились с этим соседом по BGP, он нам притащил сетку 112.168.3.0 по 24-й маске. И дальше мы ручками прописали, что сеть 192.168.4.0 доступна через

192.168.3.1. Вот в каком случае, куда будут отправляться какие пакеты? Если у нас приходит какой-то пакет, который мы хотим отправить в сторону сети 192.168.4.0, например, 192.168.4.4, мы попытаемся отобрать все подходящие маршруты для того, чтобы вот по такому вот адресу отправить пакет. Этот не подходит, этот не подходит, этот не подходит, этот не подходит, этот подходит. То есть у нас один кандидат, мы среди одного кандидата выбираем одного, который самый длинный, у которого маска самая большая. В нашем случае это было сделать несложно, потому что кандидат всего один. Ну и говорим, что вот у нас есть статический маршрут, который указывает, что трафик до вот такой сети следует посылать в сторону узла 122.168.3.1. Как доставить трафик до 122.168.3.1? Мы вычеркиваем вот этот вот маршрут и задаем вопрос, как до него достать. И до него достать мы проверяем. Этот подходит, не подходит, этот подходит,

не подходит, этот подходит, не подходит, этот подходит. Значит, вот этот вот маршрут является хорошим для правки трафика на 122.168.3.1. И он указывает на next loop 122.168.2.1. Дальше задаем вопрос, а вот до вот этого узла как добраться? И точно то же самое делаем. Этот подходит? Нет. Этот подходит? Нет. Этот подходит? Да. Что он нам говорит? Что ходи вот через вот такой вот адрес. Окей. Следующий этап. На самом деле следующего этапа нет, потому что здесь у нас показывается, что этот адрес будет attached или подключенный маршрут. И в этом случае мы говорим, трафик уходит через гигабит Ethernet 0.0. Мы резолвим канальный адрес соседа 122.168.1.1 через гигабит 0.0. И говорим, что MAC-адрес, соответствующий вот этому IP-шник, у нас будет там, не знаю, AA, BB, CC. Дветочек проставлю, чтобы на MAC-адрес был похожий 0.0.0.0.1. Вот такой вот у нас есть красивый MAC-адрес. Поэтому по факту

пакеты на 122.168.4.4 будут уходить на MAC-адрес вот такой вот, вот в этом вот интерфейсе, если мы говорим про работу через Ethernet. Не всегда у нас будут именно MAC-адреса, то есть не всегда у нас будут Ethernet-интерфейсы. Вы уже знаете, что там бывает ADS, или бывают самые разные ATMs. Вот, так что не всегда MAC-адрес вообще в интерфейсе есть. Бывают такие интерфейсы, такие канальные среды, в которых канальных адресов нет вообще, или они там кривые другие совсем. Например, в том же самом Frame Relay, они там DLCI называются. Но, тем не менее, идею, я надеюсь, что вы поняли. На каждом шаге мы вычеркиваем маршрут, который был использован на предыдущем шаге, и проверяем по оставшейся таблице, как доставить трафик до NextHop. Вот, это что касается основной задачи таблицы маршрутизации. Выдать интерфейс, через который должен отправляться трафик, и выдать канальный адрес в случае необходимости, куда доставить трафик до

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

должна быть одна и та же. И странно, почему мы должны тратить непредсказуемое время на обработку, в общем-то, визуально совершенно одинаковых пакетов. И если все равно в итоге, надо будет найти выходной интерфейс, найти канальный адрес NextHop. Если вы хотите, вы можете использовать механизмы аппаратного ускорения. Чаще всего они все-таки в конкретных вендорских решениях делаются. И смысл их будет заключаться в том, что у вас есть одна таблица маршрутизации, которая вот как бы маршрутизация по-честному, но маршрутизатор ей по факту не пользуется. А пользуется он, на самом деле, специально отдельной пережеванной табличкой, которая будет называться, как правило, Forwarded Information Base, в которой будет для каждого маршрута уже лежать готовая пара из канального адреса и выходного интерфейса. А иногда, если, например, в случае с той же самой циской, там уже сразу готовый канальный заголовок будет. То есть в этом случае, если пакет приходит, и мы его по такой пережеванной табличке находим, куда его одевать, за один проход по такой таблице маршрутизации

мы находим не просто через какой интерфейс его куда выпустить, а сразу уже прям готовый заголовок канальный вор, который остается только приклеить к, допустим, IP-пакету, и можно сразу отправить по сети. Очень удобная вещь. Так, если мы говорим про какие-то младшенькие устройства, то, ну, например, там младшенькие циски, какие-нибудь там 800-ые линейки, 1800-ые, 1900-ые, 2900-ые, все вот такого плана ISR, Integrated Services Router, у них все это дело происходит в оперативной памяти. И в этом случае мы говорим, что там используется аппаратное ускорение, которое на самом деле не аппаратное, оно, по большому счету, программное. То есть механизм называется Cisco Express Forwarding, если говорить процесски, но он там реализуется на процессоре. В то же время некоторые платформы, особенно специализированные провайдерские платформы, они будут иметь возможность именно вот эту вот штуку делать на аппаратном уровне.

То есть сам чипсет, который встроен в линейную карту, умеет обрабатывать подобные запросы самостоятельно. Приходит какой-то пакет на линейную карту, и эта линейная карта самостоятельно принимает решение, куда такой пакет надо девать. То есть она сама находит выходной интерфейс, сама находит заголовок канального уровня. Все это делается без подключения центрального процессора, без подключения, как называется это, роут-процессора. В этом случае у вас есть роут-процессор. На роут-процессоре хранится таблица маршетизации. Она часто обозначается RIB, и есть линейные карты, которые надо будет программировать. В линейных картах хранится FIBA, Forwarding Information Base. И выглядит это примерно следующим образом. Так, у меня здесь анимашка должна быть. Вот, приходит какой-то пакетик, например, SPF-овский с маршрутом. Роут-процессор генерирует мастер-копию FIBA, и дальше копия этого FIBA разбрасывается на все линейные карты.

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

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

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

как бы надо будет представлять, как вот этот вот товарищ устроен, несмотря на то, что в реальной сети, как бы большую сеть на его основе делать, наверное, не очень хорошая идея, но тем не менее, кое-какие его следы в провайдерских сетях все равно бывают. EJRP, кроме как взаимодействия с кастомерами, вы нигде не увидите. То есть наркоманов, которые провайдерские сети на EJRP строят, я еще не встречал. OSPF сплошь и рядом, ISAS сплошь и рядом, и BGP, ну, здесь не обсуждается, это как бы протокол, без которого ни один провайдер, в общем-то, не выживет. Так что вот такой вот ближайший план действий. Начнем мы с RIP. RIP очень-очень-очень старый протокол. Использует он алгоритм, который создавался еще до появления IP-сетей, то есть алгоритм Беллмана Форда. Он как раз указывает про то, как можно с помощью процедуры пакетной коммутации передать какую-то информацию дальше. И вот он использовал, этот алгоритм использовал одно

из предположений, как можно взять и передать маршрутную информацию между какими-то сетями. Изначально RIP разрабатывался для сети ARPANET, которая специальная тестовая сеть для Американского Министерства обороны, конкретно для Департамента перспективных исследований. Потом в 80-е годы он был адаптирован для IP. Опять же, 80-е, 81-й год — это достаточно бурный рост IP по сравнению с тем, что было до того. Он появился в 78-м году, дальше в 81-м году он начинает распространяться по гражданским сетям. И вот в тот момент как раз и появляется RIP, который помогает работать с IP-сетями, помогает их растаскивать по таблице маршрутизации. Там же рядышком еще другие протоколы динамической маршрутизации были, кроме RIP. Мы до наших дней, в общем, нигде эти протоколы не дожили, поэтому увидеть их сегодня будет нельзя. Но, в принципе, там был протокол, который назывался GGW — это Gateway to Gateway Protocol.

GGP, простите. GGP — Gateway to Gateway Protocol. Очень-очень древний протокол, настолько древний, что вот его вообще сейчас нигде даже не встретишь. Протокол EGP еще такой был. Протокол EGP — это предшественник BGP. И вот хотя бы следы протокола EGP встретить можно в современном мире в том же самом BGP. Там кое-какие следы его есть, их можно даже увидеть. Вот. Но из того, что дожило до наших дней, вот RIP дожил. RIP — очень простой протокол, но в то же время довольно функциональный. Работает он по очень простому критерию, по очень простому принципу. Если он хочет рассказывать про какую-то сеть, которая есть таблица маршрутизации, он про нее рассказывает. Все. По умолчанию это происходит путем рассылки на всех интерфейсах, на которых включен RIP. Каждые 30 секунд у вас рассылается пара. Маршрут и метрика. Маршрут и метрика. Метрика является количество прыжков до удаленной сети, количество каналов. Есть договоренность, что максимум количества каналов,

которые может быть между двумя сетями, это 15. То есть если у нас вот есть 4 роутера, 1, 2, 3, 4, то между ними 1, 2, 3 прыжка. Если один роутер хочет рассказать, что он знает сетку A, значит, он рассказывает, я знаю сеть за один прыжок. Сосед говорит, я знаю сеть за два прыжка. Сосед говорит, я знаю сеть за три прыжка. Роутер говорит, окей, я знаю эту сеть за четыре прыжка. Раз, два, три, четыре. Есть договоренность, как уже было сказано, что максимальное количество прыжков это 15. Если вдруг какой-то роутер заявляет, что знает какую-то сеть за 16 прыжков, за 16 хопов, то значит, эта сеть недоступна. RIP не пытается делать вид, что он заведомо лишен петель моршрутизации. RIP очень медленный протокол. Он по таймеру рассылает раз в 30 секунд свою таблицу, и в нем нету сообщений, я перестал знать какую-то сеть. То есть есть возможность отправить указание, что сеть известна за 16 хопов, но нет возможности, допустим, указать, что у нас сосед больше в принципе недоступен.

То есть либо вы рассылаете эти самые метрики, либо вы не рассылаете метрики. Нет сообщения вида, я ушел из сети. Вот если у вас какой-то роутер просто взял и перестал быть доступен, то вы ожидаете, что он будет присылать вам hello сообщение, не hello, а апдейты. И в этих апдейтах он будет рассказывать про какие сети он знает. Если он просто завис, если он вышел из строя или что-то еще с ним происходит, то вы от него сообщения перестаете получать. Но вы при этом не говорите, что ой, у нас сосед был, а теперь перестал быть. Вы ждете, ждете, ждете, и фактически единственное событие, на которое вы можете отреагировать, это событие вида в течение, например, трех минут не было от соседа никаких новостей про маршрут X. Следовательно, маршрут X через соседа мы не должны будем рассматривать в качестве наивыгоднейшего. РИП будет очень медленно реагировать на изменения по этой причине. Классическое, скажем, время, в течение которого РИП может тормозить, это порядка трех минут. Если у нас произошло изменение, РИП три минуты на каждом

роутере может тупить. Если сеть большая, эти три минуты умножаем на количество прыжков, на количество роутеров и получаем некое непредсказуемое время. Так что с таймерами по умолчанию РИП действительно медленный-медленный. Кроме того, как уже было сказано, он допускает кратковременно петли. Поэтому может быть такое, что у вас петля случится, но РИП про это не прочухает. И, соответственно, он все равно маршруты все поставит. И у вас в течение некоторого времени в таблице маршрутизации роутеры будут играть в волейбол. Один роутер говорит, я знаю сеть, некую через соседа. Т naucga, я знаю сеть через соседа. А третий говорит, я знаю сеть через соседа. И вот они друг к другу рассылают пакеты до этой сети. Естественно, чем более производительные эти роутеры будут, тем более нагружены будут вот эти вот каналы. и тем более будут нагружены роутеры. То есть классическая проблема с петлей, та же самая, которая была в Ethernet. RIP медленно реагирует на изменения, поэтому для того, чтобы понять, что у него случилась вот такая вот беда, ему потребуется, опять же, в определенных ситуациях времени довольно много.

RIP есть разных версий. Самый первый RIP, который появился в 80-х годах, это RIP версии 1. Он классовый, то есть 80-е годы, время тяжелое, и он мог передавать только IP-адреса самих сетей. У него было поле 4-байтовое, и в это 4-байтовое поле могли указывать, соответственно, сколько байт, не сколько байтов, простите, вы указывали, какой адрес сети вы хотите передавать. На самом деле там было все еще более весело. Там было 3-байтовое поле. И вы в этом 3-байтовом поле указывали, собственно говоря, какие адреса сетей вы хотели передавать. Смысла не было передавать 4-байтовое IP-адреса сети. То есть если вы хотели сказать, что вы знаете сеть 10.0.0.0, ну в современном мире мы скажем, что это сеть по восьмой маске, тогда в классовом мире это была просто сеть 10.0.0. То вы вкладывали первые 3 актета 10.0.0. И само собой разумеется, что четвертый актет, он всегда был нулевой, просто он у абсолютно любой сети был нулевой.

Поэтому его типа можно было не писать. Вот рип первой версии, он был такой хитрый. Он экономил по одному байту на каждый IP-адрес. Рассылал он данные на 520-й порт UDP, причем он делал это бродкастом на адрес 255.255.255. Популярный вопрос, почему рип первой версии использовал бродкаст, а не мультикаст? Потому что когда он появился, мультикаста в IPv4 еще не было. Мультикаст в IPv4 это более поздняя конструкция. Если вы помните, изначально, когда появился протокол IP, у нас были классы сетей. А, которые начинались на битовый нолик. Б, которые начинались на битовый один нолик. И С, который начинался на битовый один нолик. 1.0. И вот, соответственно, класс А означал, что у вас к адресу сети относятся первые 8 бит, а оставшиеся 24 к адресу хоста. Класс Б, первые 2 актета, первые 16 бит относятся к адресу сети, оставшиеся 2 к адресу хоста. И класс С, это первые 3 актета адреса сети,

оставшиеся актета адрес хоста. Ну и класс Д, который начинался на 3 битовые единички, был зарезервирован. Потом класс Д разделился на 2. 1.1.1.0. И класс Е. 1.1.1.1. Вот класс Е, это адреса с 240.0.0.0.0 по 255. 255. 255. 255. И, соответственно, класс Е до сих пор зарезервирован. Эти адреса мы нигде не используем. А класс Д отдан под мультикаст. Но это, опять же, как я уже сказал, более поздняя конструкция. Вот. РИП второй версии, когда появился, он уже был бесклассовый. Там протаскивалось 4 байта IP-адреса и 4 байта маски. Он пересылал данные по мультикасту на адрес 224.0.0.9. Хорошо известный РИП. Мультикастовый адрес все РИП роутера в канале. Но использовал точно так же UDP520 порт. Помимо того,

что он начал быть бесклассовым, помимо того, что он начал использовать мультикаст, помимо того, что, соответственно, он был просто более поздний, более хорошо продуманный, в нем появились такие, штуки, как аутентификация. То есть вы можете каждый пакет РИПовский подписать этим паролем и тем самым защититься убер-круто от злоумышленников. И вы можете использовать NextHop. То есть вы можете отправить сообщение по РИПу, сказав, что я знаю, что определенная сеть в нашем сегменте доступна, но она доступна вон через того парня. То есть вы можете сказать, что маршруты надо ставить не на вас, а на вот того, про кого вы говорите. Типа если он сам по РИПу разговаривать не умеет. IPv6 тоже имеет свою собственную вариацию РИПа. И причем, что интересно, РИП для IPv6 появился раньше, чем РИП полноценный для IPv4. То есть РИП-NG это РИП для IPv6. Он RFC 2050, это конец 90-х годов.

Соответственно, РИП-V2 он позже появился. И фактически РИП-V2 и РИП-NG это очень похожие протоколы друг на друга. Они настраиваются более-менее одинаково. Единственное, что все фичи, которые есть в РИП-V2 есть и в РИП-NG, но формат пакета у них как бы заметно отличается. То есть из того, что там есть, например, аутентификация, из того, что есть, например, NextHop. Вот это не следует, что способ, которым NextHop передается в РИПе второй версии и способ, которым NextHop передается в РИП-NG. Это хоть сколько-то похожие способы. Нет, они используют разные способы передачи данных, но при этом результат появляется у них одинаковый. Пересылаются просто по таймеру куски таблицы маршрутизации. Метрика это количество прыжков между роутерами не зависит от скоростей каналов. Если у нас есть, например, вот некая сеть, есть у нас узел А, и вот наш роутер рассказывает,

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

НТВ His WebAs отrors 성이 у него примерно даже в тех cherish вами мы одних Business В Дальше у нас получается, что вот этот вот товарищ узнал, как добраться до сети. Вот этот вот товарищ узнал, как добраться до сети. И вот этот вот товарищ тоже узнал, как добраться до сети. Он только что получил указание от двух соседей, как можно добраться до указанной сети «А». Оба варианта за два прыжка между роутерами. След harp на соседе плюс один прыжок до соседа. Итого получается три. И он начинает рассказывать им уже, что я знаю, как добраться за три прыжка, но, опять же, все роутеры это игнорируют. оригинальный протокол рип предполагал что у вас на абонентах тоже могут быть запущены какие-то рип процесса и абоненты будут знать в какие сети можно будет добраться через маршрут через маршрут рипа типа если они будут знать что у нас есть сеть а вот они будут посылать трафик только в сеть а

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

но вот рип не умеет различать свойства каналов он говорит самое важное что канал там в принципе есть трафик никогда не трафика маршруты которые будут получены через определенный интерфейс никогда не отправляются обратно в тот же самый интерфейс это правило будет называться сплит сплит horizon делается это для того чтобы предотвратить подсчет до бесконечности иллюстрацию подсчет до бесконечности вы видите что какой-то роутер говорит я знаю как добраться за x копеек а в ответ ему что я знаю как добраться за x плюс одну копейку если вдруг изначально роутер теряет маршрут то значит они вот друг другу будут перекладывать указания я знаю как добраться за и x плюс 1 я знаю как добраться за x 20 в рип cuánt и процесс этот может происходить по молчанию не происходит но он может происходить и происходить он будет до бесконечно then бесконечности бесконечности в кавычках с точки зрения рипы до бесконечности это число 16 было который кто-то скажет что он знает сетку за 16 копеек сосед поймет что он эту сеть неизвестно есть механизм с помощью которых вы

можете сразу заявить что сеть вы знаете за 16 копеек и тем самым подчеркнуть что через вас маршруты вообще никогда не при каких условиях до этой сети их одеть не должны то есть если вы получили маршрут какой-то с указания метрики 16 то значит через вас этот маршрут не был доступен смотрите в чем фишка у вас было давайте отмотаю назад у вас была некая сеть известна вот была сетка вы рассказываете про нее знаю за за два прыжка сосед в таблицу маршрутизации указывал соответственно что я вот могу трафик посылать вот по вот этому маршруту дальше сеть перестала быть доступна и роутер который раньше эту сетку знал говорит я теперь больше ее не знаю и в этом случае сосед роутер убирает эту сеть из таблицы маршрутизации сразу то есть если вам ваш next hop присылает указание что сетка известна за 16 копеек next hop больше не как то есть механизм с помощью которых вы можете просочетать split horizon и позин реверс смысл заключается в том что если вы принимаете какой-то

маршрут от соседа обратно в тот же самый интерфейс вы отправляете маршрут с бесконечно большой метрикой штука это по умолчанию выключена но на на некоторых железках может быть включена она требует для того чтобы быть включен и механизм split horizon чтобы был отключен смысл в том что если вдруг у вас была какая-то сетка вы про нее рассказали соседу сосед принял такую сеть чтобы если вдруг у этого соседа не возникло желание через вас трафик направлять куда-то наружу вот если у него вдруг такое желание возникнет чтобы он знал через вас это точно делать плохая идея это механизм предотвращения петли и по умолчанию он не работает на многих реализациях но кое-где его можно будет включить так давайте попробуем с вами включить рип на наших железках пардон у нас же пока теоретические слайды идут давайте быстренько проговорим про все возможные протоколы только после этого будем уже

будем уже настраивать все это дело то что у нас настройка будет в отдельном модуле давайте тогда про следующий протокол поговорим следующий протокол будет и и и grp это протокол основанный на протоколе ай grp фирменном цисковском протоколе конкуренте протокола рип то есть рип первой версии классовый вот с ним дрался ай g rp в 90 втором девяносто третьем году как как раз тогда когда циска сделала большой скачок вперед перевела процедуру управления роутер на консоль перевела роутер свои на бесклассовый режим вот она предложила протокол enhanced i g rp для того чтобы можно было работать с динамической маршрутизации в своем цисковый и и g rp от ай g rp отличался тем что у него была изначально бесклассовая маршрутизация поддерживал поддерживалась то есть вы могли в качестве того про что вы рассказываете указать

ай пишник и маску ай g rp не мог рассказать про маску мог только про и пишнике рассказать ай g rp использовал мультикаст 224 0010 опять же это камень в огород рипы камень в огород и ай g rp которые использовали брат каст если мы используем ipv4 это вот такой вот адрес если мы используем ipv6 это адрес ff02 дальше он заканчивается на десятку десятка десятичный это а 16-ти лично ff02 22.а это тот же самый мультикаст в адрес все ipv6 и g rp роутер и g rp используют не tcp не youtube он вкладывается в ip и у него используется вложение 88 в отличие от ай g rp в отличие от рипа и g rp не расслабляет по таймеру указания что я знаю до такой я знаю как добраться до такой сети он один раз рассказывает про какие сети он знает и дальше молчит ну или говорит у меня все спокойно у меня ничего не изменилось для того чтобы это работало у вас появляется новая

концепция у вас появляется соседство в и g rp то есть если два роутера друг другу рассказывает про какие сети они знают а дальше перестают рассказывать говорят у меня все хорошо у меня все хорошо то все это дело работает только в том случае если вы точно знаете кто из ваших соседей какую информацию о том какие у вас маршруты есть получил поэтому вы ведете учет каждого из подключенных вам соседей вы говорите дорогие соседи у меня для вас никаких новостей нет если вдруг у меня будут какие-то новости для вас я вам про это дело расскажу если появляется какой-то новый роутер вы должны будете ему все равно рассказать про то какие у вас маршрут есть даже если через вы дружите через интерфейс на котором вы с другими роутерами уже подружились и уже им все рассказывали и g rp будет основан на алгоритме который называется diffusion update алгоритм или dual и этот алгоритм будет использовать механизм раз такой массового спама массовой рассылки сообщений которые гарантированно

распространяет некоторую служебную информацию на всю сеть с использованием так называемых diffusion updates просто тупо спамят всех всех всех изначально протокол был фирменный цисковский но потом циска решила его открыть она опубликовала некий набор спецификации g rp в 2013 году и в 2016 году опубликовала рфс которая сказала могут делать любые желающие и в гипотетически да что любой желающий теперь и и g rp может у себя поднять но естественно что если вдруг кто-то захочет у себя в какое-то сетевое оборудование включить и g rp то ему придется конкурировать с иска который и g rp делает уже 30 лет естественно у нее вполне неплохо дел получается поэтому реализации и g rp на циск она заведомо лучше чем любая другая реализация и g rp который может быть и g rp очень быстрый протокол он действительно очень очень быстрый он в подавляющем большинстве сценариев любые изменения в сети отрабатывает быстрее чем любой другой

протокол который есть нашем курсе он быстрее чем о успев он быстрее чем асс он быстрее чем gp быстрее чем рип но он заточен все-таки под работу в сети предприятия у и g rp есть ряд фич в том числе балансировка если есть несколько одинаковых маршрутов до одной и той же сети он может балансировать трафик но это именно цискоспецифика железа и более того и g rp может балансировать трафик по маршрутам с неодинаковыми метриками это опять же особенность циска железа но особенность также и фирменный и g rp шнешь если есть несколько маршрутов которые визуально разные один получше другой похуже вот она может и получше маршрут и похоже маршрут оба поставить таблицу маршрутизации и по обоим балансировать трафик и g rp будет гарантировать защиту от петель маршрутизации звездочка намекает на то что когда есть звездочка какой-то мелкий шрифт есть вот здесь мелкого шрифта нету я его подразумевал если вы очень сильно захотите в g rp можно сделать петлю но это надо прям очень сильно хотите очень сильно вредить

если вы не пытаетесь сильно сами себе навредить эту петлю он вам не сделает он предпочтет никуда не фарвард трафик чем фарвард трафик с петлей в оси си ней мы говорили что и g rp это дистанц-векторный протокол и действительно это так и g rp будет очень продвинутый вектор метрик большая часть из которых он использовать не будет и g rp это протокол фактически как а и g rp второй версии если посмотреть на список модулей в циске которые составляют и g rp то вы увидите что основной модуль который реализует алгоритм dual это модуль который называется aigrp2 и по факту качестве вектора подbramer котрые g rp будет передавать он будет передавать мвс это суммарная полоса минимальная полоса через всей транзитной интерфейс c e dot trafi будет проходить до удалённой сети вот самым самое узкое место в сети он будет передавать суммарную задержку при передаче данных удаленных сети Bun и будет передавать максимальную загрузку среди всех транзитных интерфейсов опять же так как трофик

передается в удаленную сеть, в какой-то момент он проходит через самый загруженный интерфейс. С какой процент загрузки на этом интерфейсе будет? Минимальную надежность опять же через все транзитные интерфейсы, когда трафик проходит, он в какой-то момент будет гипотетически уметь отслеживать, насколько нездорово себя чувствует самый нездоровый интерфейс. Какой МТУ будет при передаче данных в удаленную сеть? То есть он опять же может померить МТУ на трассе от отправителя до получателя. Какой хопкаунт будет, то есть сколько прыжков между роутерами нужно для того, чтобы доставить трафик в удаленную сеть. Какой кумулятивный джиттер может быть? Если мы отправляем, допустим, IP-пакеты в удаленную сеть, он может померить на этапе построения таблицы маршрутизации джиттер, который там может быть использован. Или вы можете использовать энергию, то есть вы можете сказать, что нас интересует отправка трафика по наиболее выгодному маршруту, и мы хотим тратить наименьшее количество энергии. Если, например, у нас есть один способ доставить трафик по оптическим линкам, где требуется для работы

тяжелые энергоемки лазера, а в другом случае мы можем отправить трафик по какому-то DAC-кабелю, где никаких дополнительных потерь энергии нет, то мы будем предпочитать более дешевый способ, более экономичный. Но вот как бы там ни было, из всех вот этих вот вариантов того, чего можно учитывать гипотетически при выборе хорошего или плохого маршрута, по факту все вот эти метрики, они передаются, но некоторые из них считаются некорректно. Они корректно бы считались, если бы ваш EGRP дружил бы с IGRP. И вот тогда, вот если у вас везде в сети IGRP был бы и вот только в одном месте где-то EGRP, у вас можно было бы корректно посчитать вот это, вот это. У вас можно было бы зачем-то гипотетически все это дело включить в расчет метрики и стало бы даже, может быть, даже неплохо. Но если у вас везде в сети EGRP-шные роутеры, вот это вот и вот это вот считаются некорректно.

Оно считает погоду на Марсе, а не задержку, не загрузку, не надежность, простите. Задержку нормально считает. Поэтому в расчет метрики вот эти вот два параметра включать нельзя. Они не соответствуют тому, что там написано. То есть если бы там были IGRP-шные роутеры, да, они бы показывали максимальную загрузку, минимальную надежность. Но IGRP не показывает в этих параметрах то, что по факту в настройках интерфейсов мы будем видеть. То, что IGRP умеет считать MTU и hopcount, по факту никоим образом не влияет на выбор маршрута. То есть hopcount хоть как-то, хоть где-то будет встречаться для защиты от петли, если вы отключаете защитные механизмы. MTU вообще никоим образом не влияет на конечный результат. Дальше. Джиттеры, энергия, опциональные механизмы могут считаться, могут не считаться. Далеко не все роутеры умеют считать. Ну и опять же, да, идея была красивая, гениальная, по факту не взлетела.

Поэтому по факту из всего вот этого вектора метрик IGRP будет считать только два параметра для какой-то дальнейшей работы с ними. Bandwidth и delay. В таблицу соседей мы будем заносить список соседей, с которыми мы провели процедуру установления соседства. В рамках этой процедуры мы убедились, что сосед настроен с нами непротиворечиво, что у нас с ним есть двусторонняя связность, что он видит наши пакеты, а мы видим его пакеты. Для того, чтобы с соседом установить взаимоотношения, вы должны будете настроить с ним одинаково… IP-адреса у вас должны быть в одной и той же сети, у вас должны быть с ним одинаковые МТУ, у вас должны быть с ними одинаковые номера автономных систем, и, в общем-то, все, по-моему. То есть количество настроек, которые требуются для IGRP, чтобы… А, ну, коэффициенты метрики, да. K1, K2, K3, K4, K5, K6 должны у вас будут совпадать. Если совпадают, значит, все хорошо, значит, у вас соседство установится.

Напротив каждого соседа в таблице соседей вы указываете, с какими свойствами вы соседа знаете, с каким bandwidth вы его видите, с каким delay вы его видите, и там же заодно заносится, с каким load, с каким reliability и так далее. Напротив каждого соседа у вас будет писаться. Каждому соседу вы будете отправлять… Не каждому соседу, да. В каждом интерфейсе, на котором у вас будет включен IGRP, вы будете отправлять hello-пакеты. По умолчанию таймер, как часто отправлять hello-пакеты, будет 5 секунд на быстрых каналах и 60 секунд на медленных каналах. Быстрый канал – это 1,5 мегабита. Через сколько сосед признается трупом? По умолчанию 1,5… В смысле, 3-х кратный таймер hello, то есть 15 секунд. Если вы таймеры меняете, то hello-time у вас тоже будет меняться. EGRP не требует совпадения таймеров, если что. То есть ему важно, чтобы совпадали МТУ, чтобы совпадали коэффициенты метрики, а вот таймеры все равно.

Когда вы настраиваете свой hello-таймер, вы указываете, как часто вы посылаете пакеты. Когда вы настраиваете свой hold-time, вы указываете соседу, через сколько он должен признать вас трупом, если вы ему не будете ничего посылать больше. И вот фактически логика как в CDP. То есть вы в CDP можете указать таймер свой, как часто отсылаете пакеты, и hold-time, как скоро сосед должен признать вас трупом. После того, как вы подружились с соседом, вы принимаете маршруты от соседей, соседи принимают все маршруты, которые вы им заявили. Все маршруты складываются в некоторую таблицу с указанием соседа, через который они были получены, и дальше высчитываются среди них наилучшие. Для того, чтобы высчитывать наилучшие маршруты, используется EGRP-шная метрика, которая есть у каждого маршрута. Не путайте с метрикой в таблице маршрутизации. То есть когда мы видим show.ip.road, там есть некая метрика. Это другое.

То есть отдельная метрика в таблице маршрутизации, метрика RIP, и отдельная метрика у EGRP-шного есть. Они зачастую похожи и даже числово совпадают, но они не обязаны совпадать. То есть отдельная метрика EGRP-шная, отдельная метрика RIP-а. EGRP-шная метрика основана на метриках IGRP, у которого они были 24-битные. Соответственно, IGRP-шная метрика была некоторой функцией от четырех параметров метрики. bandwidth, delay, reliability, load. И можно было указать, в каких пропорциях вы должны будете учитывать хорошуюсть или плохую метрики в зависимости от bandwidth, delay, reliability, load. IGRP по-честному считал все эти параметры, поэтому вы могли сказать, я в своей сети хочу минимизировать задержки, поэтому я хочу, чтобы у меня задержка была бы наиболее приоритетна по сравнению со всеми остальными. И я с помощью некоторых коэффициентов метрики K1, K2, K3, K4, K5 влиял на свою формулу в своей сети, так чтобы все роутеры у меня ценили задержку.

Кто-то другой мог сказать, а я не хочу задержку, мне задержка неинтересна, мне bandwidth интересен. А кто-то третий мог сказать, а мне надо, чтобы трафик шел по наименее загруженным интерфейсам, потому что задержки, которые есть, это задержки сериализации, они фиксированы, а вот загрузка интерфейсов, она влияет напрямую на время ожидания пакета в очереди. И если пакеты в очереди сидят долго, потому что интерфейс загруженный, то задержки там будут расти на самом деле существенно сильнее, чем их может посчитать с помощью дилея. Но вот каждый в случае с IGRP мог выбрать себе подстроенную функцию метрики по умолчанию. В IGRP изначально, когда появились роутеры с IGRP, использовалась та же самая функция, что и в протоколе IGRP. То есть это была натурально та же самая функция, только она стала 32-битной, а для того, чтобы сделать 32 бита из 24, просто справа дописали 8-битных нулей. То есть умножили число на 256 и получили точно то же самое, что было в IGRP.

Но очень-очень скоро, буквально через полтора-два года, в IGRP появились так называемые wide-метрики. Эта метрика стала 64-битной. Она при этом адаптирована таким образом, чтобы быть очень похожей на 32-битную метрику. То есть по большому счету все современные роутеры, абсолютно все современные роутеры работают с wide-метриками. Но вы этого можете даже и не знать. Потому что если вы заказываете отображение метрики, делаете show IGRP, topology или что-то в этом духе, вам нигде не показывается, что вы используете wide-метрики. Вам показывают, как будто вы используете классическую метрику. На самом деле это эмуляция классической метрики. Wide-метрика будет функцией от уже большего количества параметров, добавляется энергия jitter. Для того, чтобы учитывать энергию jitter, добавляется параметр k6. Но есть нюанс. По факту в IGRP вот все вот этого вот, все вот этого вот, вот этого все считать не получается нормально.

Поэтому по факту в IGRP эффективно использовать можно только BNVS delay. Если вдруг вы хотите использовать маршруты EGRP, то вы должны будете указать, каким образом вы считаете метрику. Формула по умолчанию принимает во внимание только BNVS delay. Гипотетически, если вдруг у вас ручки чешутся, чего-нибудь такое поделать хитрое, то вы можете взять и поменять параметры k1, k2, k3, k4, k5, и полная формула, которая будет вычитывать классическую метрику для маршрута, она выглядит вот таким образом. То есть вот эта вот часть — это IGRP-шная метрика, а вот эта вот часть — это как из нее сделали IGRP-шная. Просто умножили на 256 тупо. Есть, соответственно, вот эти пять параметров k1, k2, k3, k4, k5. Если вы берете значение по умолчанию, то k1 и k3 равны единице, k2, k4 и k5 равны нулю. Здесь есть нюанс. Если вы возьмете и подставите вот в эту вот множитель значение k5 равное нулю,

то как бы правила математики указывают, что вот весь этот множитель должен обратиться в ноль. Как следствие, вот у нас умножить на ноль что-то в итоге, по идее, должно обращаться в ноль. Но на самом деле спецправило указывает, что если k5 равно нулю, то вот вся вот эта вот часть, весь этот множитель будет равен единице. Это просто отдельное обособленное условие. Если у вас k1, k5 и k4 равны нулю, то вот этот множитель обращается в единицу. Дальше. Если у вас k2 равно нулю, то вот это вот число обращается в ноль. И как следствие у вас формула превращается в k1, равная единице вычеркивается, скейлот бендвиз плюс k3 обращается в единицу, вычеркивается, дилей скейлот бендвиз плюс дилей умноженное на 256. Скейлот бендвиз — это 10 в седьмой степени, деленное на полосу пропускания. Потерялся дробь. То есть 10 в седьмой степени, разделенное на бендвиз. Бендвиз проражается в килобитах в секунду.

В килобитах в секунду. И дилей в десятках микросекунд. То есть вот такая вот формула с настройкой по умолчанию. Трогать ее не надо по той простой причине, что в любом случае, если вы будете ее трогать, ну, в крайнем случае вы можете сказать, что вас интересует больше бендвиз и не интересует дилей. Или вас интересует, напротив, дилей и не интересует бендвиз. То есть вы можете с использованием коэффициентов k1 и k3 указать на то, что среди бендвиз и дилей вас интересуют в какой-то определенной пропорции. k2, k4 и k5 равны нулю трогать не нужно. Результатом работы функции будет по каждому маршруту вычислены некоторые компьютер дистанции. То есть EGRP после того, как он посчитал метрику, он запомнил ее в таблице топологии. Плюс к тому, он по этой же формуле посчитал и то, какая метрика будет у соседа. Потому что сосед, когда присылает нам какой-то маршрут,

он рассказывает, с какими метриками он знает эту сетку, с какими вот этими самыми компонентными метрики. И мы считаем компьютер дистанции на нашем роутере. И мы считаем репорт дистанции на роутере соседа. То, какая метрика итоговой EGRP у маршрута будет со стороны соседа. Компьютер дистанции у него, это репорт дистанции у нас. Делается это для простого критерия, как можно определить, что маршрут точно гарантированно не проходит через нас. Если вы получаете какой-то маршрут от соседа, и его метрика строго меньше, чем наша метрика, то значит он точно гарантированно не может устроить петлю с нами. Маршруты, которые удовлетворяют условия feasibility condition, то есть репорт дистанции строго меньше, чем наша метрика собственная, они будут надежно защищены от петель. Здесь вы видите формулу, которая RD меньше, чем FD. RD — это reported distance, а FD — это на самом деле наша computed distance для какой-то сети.

За всю историю наблюдения самое-самое маленькое. То есть feasible distance — это самая-самая-самая маленькая метрика до указанной сети за всю нашу стабильную историю работы. Вот если сосед говорит, что прямо сейчас знает некоторую сетку, и его метрика прямо сейчас лучше, чем самая маленькая метрика, которую мы у себя сами когда-то давным-давно видели, то в этом случае мы говорим, что этот маршрут точно не содержит петли через нас. Сосед, который присылал такой маршрут, называется словом feasible successor, и маршрут, который feasible successor присылает, можно сразу ставить в таблицу маршрутизации. Successor — это один из feasible successor, который предложил наилучший маршрут. То есть самый-самый-самый выгодный маршрут из тех, которые заведомо не содержат петли. Вот пример того, как работает feasibility condition. У нас есть несколько роутеров. Два роутера присылают третьему некую сетку. Соответственно, первый роутер верхний пересылает некую сетку соседу вот этому.

Этот сосед говорит, я знаю, как добраться до этой сети. Мы не принимаем маршруты от соседа, если он рассказывает нам, что до сети может какой-то добраться, если у него reported distance больше, чем та метрика, которую мы сами когда-то анонсировали. То есть вот мы на нижнем роутере говорим, что у нас есть какая-то сетка А. Мы знаем, как до нее добраться за 10 копеек. Про эту сетку за 10 копеек рассказывает верхний роутер, про эту сетку за 10 копеек рассказывает нижний роутер сам. То есть вот он говорит, я знаю, как добраться за 10 копеек. Правый роутер рассказывает им обоим, а я знаю, как добраться за 20 копеек. Он говорит, я знаю, как добраться за 20 копеек сюда. Я знаю, как добраться за 20 копеек сюда. Вот когда сосед рассказывает, что он знает, как добраться за 20 копеек, мы говорим, что мы не будем верить тому, кто рассказывает, что до сети можно добраться за 20 копеек, если мы сами можем добраться, или когда-либо могли добраться за 10 копеек. То есть мы прямо сейчас или когда-то в прошлом знали, как добраться до этой сети более выгодным образом.

Маршрут потенциально проходит через нас. Поэтому маршруты, которые приходят обратно в направлении сети, они вот с помощью такого простого критерия, соответственно, отбрасываются. Второй вариант, когда действительно есть петля, у нас маршрузатор рассказывает, что знает, как добраться до какой-то сети за 10 копеек. Сосед принимает такой маршрут, рассказывает, что знает, как добраться за 20 копеек. Этот сосед говорит, я знаю, как добраться за 30 копеек. Вот мы, приняв такой маршрут, говорим, у нас есть хороший, выгодный способ добраться до сети за 10 копеек. И другой вариант какой-то, как можно добраться до сети за 30 копеек. Можно ли верить тому маршруту, который идет за 30 копеек? Нельзя, потому что 30 больше, чем 10. Мы не верим такому маршруту, мы говорим, этот маршрут потенциально проходит через нас. Он действительно проходит через нас. Он прошел через роутер, которому мы попытались продать сетку за 10 копеек. Дальше тот роутер, другой пытался продать сетку за 20 копеек. Нам сейчас пытаются вернуть наш же собственный маршрут, но за 30 копеек.

Если у нас какая-то сеть была доступна, но перестает быть доступна, то вот то, что нам сосед рассказывает, что можно доставить трафик в удаленную сеть за 30 копеек, это не означает, что мы сейчас прям вот совсем выкидываем такой маршрут. Мы его все равно складываем в надежное место. И в ситуации аларма, когда у нас NextHop основной боевой отваливается, мы ему можем задать вопрос, а ты точно знаешь, как добраться до указанной сети? Мы ему отправим сообщение по алгоритму Dual. Скажем, если вдруг ты пытаешься доставить трафик через нас, имей, пожалуйста, в виду, что мы не знаем, как добраться до такой сети. И если у вас такое сообщение разбегается по всей сети, то рано или поздно тому, кто пытается ему продать такую сетку, это сообщение тоже дойдет, и он вам перестанет эту самую сеть присылать. Если у вас есть EJRP, то EJRP может получать несколько маршрутов до одной и той же сети,

от нескольких соседей, и в этом случае EJRP будет считать лучшим маршрутом тот, у которого самая маленькая метрика, самая маленькая компьютерная дистанция. Если у вас этот маршрут ставится в таблицу маршрутизации, то с классическими метриками. Маршрут ставится с такой же метрикой, как была в EJRP, то есть в show.ip.road мы будем видеть метрику, ну, допустим, вот у нас есть два маршрута. Сеть 10.00 получена через такого соседа, и 10.00 получена через другого соседа. Вот в одном случае компьютерный дистанция до сетки мы посчитали 300, в другом 2100. В таблицу маршрутизации мы добавляем с аксессора с метрикой 300. И в таблице маршрутизации по умолчанию с классическими метриками метрика маршрутов show.ip.road равна метрике маршрутов show.ip.jpg.topology. Но если вы используете широкие метрики, которые 64-битные, они в 32-битную метрику в таблицу маршрутизации не влезут. Поэтому есть специальный параметр EJRP rib scale,

когда вы берете широкую метрику и делите то, что у вас получилось, на некий параметр. Вот этот параметр по умолчанию 128. Вот. То есть у вас получилось, не знаю, миллиард. Вы миллиард поделили на 128, и в show.ip.road у вас будет 1.128 миллиарда. В EJRP есть алгоритм Dual, как уже было сказано, который рассказывает про то, что есть какие-то сети. То есть это диффузия доступности, появляется сетка, она начинает распространяться на все-все-все роутеры. То есть все роутеры в сети начинают узнавать про то, что какая-то сеть присутствует. Вот они друг другу рассказывают, смотри, какая сетка, смотри, какая сетка. Правильным образом есть такая штука, как диффузия недоступности. Если вдруг у нас была какая-то сеть, но перестала быть, то рассылаются сообщения, я больше не знаю, как добраться до сети, а ты. И вот если все роутеры друг другу позадавали вопрос, я не знаю, как добраться до какой-то сети, а ты знаешь, то значит, они делают логичный вывод,

что если все-все-все соседи сказали, что я не знаю, как добраться до какой-то сети, значит, такой сети в принципе нету. Вот такого рода сообщения они либо распространяют указание, что сетка доступна, либо распространяют указание, что сетка недоступна. Происходит это довольно быстро. Если мы захотим использовать аутентификацию в EJRP, он тоже это позволяет делать, как и RIP, но причем RIP позволяет это делать таким смешным способом, просто позволяет пароль приложить к нему, к пакету. EJRP позволяет использовать хэш от содержимого пакета плюс пароля, и, соответственно, вы можете использовать хэш либо MD5, либо SHA-256. Если приходит какой-то пакет, и он подписан хэшем каким-то, то вы, зная секретный пароль, считаете от открытой части пакета и пароля хэш. Если у вас результат сходится с тем, что написано в пакете, значит пакет действительно подписан тем, кто знал секретный пароль. Если вы проверяете какой-то пароль, и он у вас не сходится, то такой пакет просто выбрасывается. Поэтому, если вдруг у вас на двух роутерах настроены неодинаковые пароли, они не смогут установить соседские взаимоотношения, потому что они будут друг другу посылать hello-пакеты, которые будут просто с соседями игнорироваться.

Так, я предлагаю на сегодня закончить, а завтра поговорить про OSPF.