Динамическая маршрутизация

Финальный рывок. Говорим про динамическую маршрутизацию в рамках нашего курса. Причем хочу заметить, что про динамическую маршрутизацию мы будем говорить достаточно много в рамках курса ICND2. А сейчас будет только затравка и пример работы этой динамической маршрутизации. На примере протокола RIP мы посмотрим, как это всё работает. И начнем мы с того, что динамическая маршрутизация позволяет нам не создавать статические маршруты. Сейчас мы, когда делали лабораторную работу на NAT, мы должны были на свичах создать маршрут по умолчанию, который смотрел бы на наш NAT-роутер. Эти статические маршруты в принципе неплохие, но у них есть ряд фатальных недостатков. Их надо создавать руками — это самый главный недостаток. И есть вероятность того, что вы создадите маршрут руками, и он будет смотреть не в ту сторону, потому что вы ошибетесь. Либо он будет смотреть на железку, которая, например, будет недоступна, и у вас в таблице маршрутизации маршрут будет, а работать этот маршрут не будет.

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

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

Это была компания, у которой были офисы в разных странах, причем в каждой стране было много разных офисов. И эти офисы связывались между собой с помощью VPN-туннелей. И соответственно в каждом отдельном офисе использовалась своя отдельная IP-сеть. Естественно, для того, чтобы это всё связать между собой, должны быть корректно настроены маршруты. И в той компании не использовалась динамическая маршрутизация, использовалась везде статика. И соответственно всё это работало крайне хреново. По очевиднейшей причине, что для того, чтобы держать в актуальном состоянии сеть маршрутов, если сеть состоит хотя бы из 10 различных офисов, это действительно довольно сложно. Количество работы, которое в этом случае придется делать, будет невменяемо большое. Если у вас 10 офисов, в каждом из них хотя бы по нескольку сетей, например, 3 сети, у вас получается, что на каждом роутере должно быть 30 маршрутов, которые бы смотрели в какие-то другие сети. Это просто очень много.

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

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

Динамическая маршрутизация будет по-разному себя вести в разных ситуациях. Если у нас роутеры принадлежат к одной и той же автономной системе или нет. У нас будут работать разные правила. И в рамках нашего курса мы всё-таки рассматриваем более простые сценарии, и более простые сценарии — это у нас будет внутридоменная маршрутизация, маршрутизация внутри автономной системы, и такие протоколы, которые предназначены для работы внутри автономной системы, они будут называться IGP — Interior Gateway Protocol. Не любые, понятное дело, протоколы будут предназначены для работы внутри одной автономной системы. Бывают протоколы, которые предназначены для работы между разными автономными системами, которые позволяют роутерам в разных автономных системах обмениваться маршрутами, и они намного сложнее по сравнению с IGP. И соответственно они будут называться EGP, Exterior Gateway Protocol. И в качестве примера здесь можно вспомнить протокол BGP, Border Gateway Protocol. Это тот самый протокол, на котором основан современный интернет.

Если вдруг вам интересно, как он устроен, мы немножко его рассмотрим на курсе ICND2, и плюс мы его достаточно детально будем изучать на курсе по динамической маршрутизации. И плюс, разумеется, он рассматривается в провайдерском треке, так что если вдруг вам хочется поработать с BGP, то вам прямая дорога в провайдеры. Но в нашем курсе ICND1 его не будет, к счастью, потому что он большой, сложный, а нас интересует сейчас сценарий попроще. Помимо того, что протоколы делятся на те, которые предназначены для работы внутри автономки или соответственно предназначены для работы между автономками, на IGP и EGP, они еще по механизму своей работы, по алгоритму, на котором они будут основаны, будут делиться на два вида. Первый вариант — это так называемые дистанционно-векторные протоколы. И второй вариант — это так называемые link state протоколы, или по-русски совершенно непроизносимая фраза — протоколы с отслеживанием состояния каналов связи. Все их называют link state протоколами.

Это два разных семейства протоколов, они друг на друга совсем не похожи, потому что у них принципы работы разные. Дистанционно-векторные протоколы будут обмениваться кусками таблицы маршрутизации, у них единица передачи информации — это маршрут. И про каждый маршрут они будут говорить, насколько хорошо они этот маршрут знают. Они будут говорить: я знаю сетку такую-то, я знаю ее в том направлении, я знаю ее на таком расстоянии. «В таком направлении» и «на таком расстоянии» как раз указывает на название «дистанционно-векторный». Векторный — это направление, а дистанционно — расстояние. Фактически он будет пальчиком тыкать и говорить: я знаю эту сетку туда, в одном километре. Link state протоколы существенно сложнее. Они будут обмениваться не кусками таблицы маршрутизации, а кусками топологии, того, как сеть устроена.

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

поэтому они гипотетически хорошо адаптируются для крупных сетей. Link state протоколы для крупных сетей плохо адаптируются, потому что большое количество служебных вычислений делает их непригодными для очень крупных сетей. Но если говорить про конкретные протоколы, которые в каждом семействе у нас будут, например, BGP — такой образцово-показательный дистанционно-векторный протокол, он настолько хорошо справляется с большими объемами, что позволяет обслуживать современный интернет. Еще есть, например, протокол EIGRP. Cisco его любит называть гибридным, но на самом деле это классический дистанционно-векторный протокол. Он неплохо адаптируется под большое количество маршрутов, но начиная с определенного уровня у него возникают встроенные болячки, и он начинает хиреть. Есть еще один протокол, такой традиционный дистанционно-векторный — RIP,

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

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

Но если у нас есть несколько соседей, которые прислали нам одну и ту же сетку, мы для каждого из этих соседей повторяем операцию, получаем для каждого из анонсированных соседских вариантов результирующий вектор, сравниваем, какой вектор получился самый вкусный, и в таблицу маршрутизации добавляем этот самый вектор. А дальше начинаем своим соседям рассказывать, как мы знаем эту сеть. Маршрутизация с помощью дистанционно-векторных протоколов может быть сравнима с поездкой на автомобиле не по карте, а по указателям. Вы едете, едете, едете, и вот вы видите указатель, который показывает: в левую сторону поедешь — до такого города доедешь, в правую сторону поедешь — до такого города доедешь, и такой-то город будет доступен в таком-то количестве километров. В этом случае указатель, который говорит «направо», показывает нам вектор движения, что надо ехать именно направо, и указывает нам дистанцию — 20 километров. Дальше мы поворачиваем направо, в какой-то момент нам говорят: поверни налево. Когда мы поворачивали направо в первый раз, мы не знали, что надо будет потом через некоторое время повернуть налево.

Но мы можем ожидать, что суммарное расстояние, которое мы проедем, в любом случае будет 20 километров. Мы не видим всех особенностей дороги за указателем, но итоговую метрику — хорошесть или плохость маршрута, например, выраженную в километрах — получаем, даже видя только один указатель, только один вектор. Если говорить про конкретную реализацию дистанционно-векторного взаимодействия применительно к маршрутам, то выглядеть это может следующим образом. У нас есть некая сеть на маршрутизаторе X. Он хочет рассказать про то, что сеть A у него существует. Он говорит: я знаю, как добраться до сети A. И метрика — насколько хорошо он знает эту сеть. Допустим, у нас каждый интерфейс, которым соединены роутеры, имеет некую стоимость. Он говорит: я знаю сеть A за стоимость 10 копеечек. Это уходит в виде анонса в сторону соседа,

соседнего маршрутизатора. Тот принимает такой анонс, говорит, я вижу от соседа анонс, что сеть А существует, и у него в таблице маршрутизации она есть за 10 копеек. Дальше. Насколько хорошо я знаю соседа X? Я знаю его тоже за 10 копеек. Поэтому 10 копеек плюс 10 копеек будет 20 копеек. Дальше этот маршрутизатор начинает рассылать уже своим соседям анонсы, что знает сеть за 20 копеек. Тут третий маршрутизатор видит анонс за 20 копеек сети А. Дальше он говорит, а за сколько я знаю соседа, который её анонсирует? Тоже за 20 копеек. Окей, я знаю эту сетку за 40 копеек и начинает анонсировать сетку сам. Следующий маршрутизатор в цепочке говорит, я вижу анонс за 40 копеек, что сеть А существует. Как хорошо я знаю этого соседа? Я знаю его за 10 копеек. Следовательно, я знаю эту сеть за 50 копеек. И дальше это всё анонсируется. Очень простой механизм, с помощью которого мы берём анонс от соседа. Дальше в этом анонсе указывается какой-то вектор метрик,

как сосед знает определённую сеть. Мы соседа, который нам прислал такую сеть, тоже с каким-то вектором знаем. Мы складываем два вектора, получаем итоговый результат, что мы сеть знаем на каком-то расстоянии, если хотите. Так, по сравнению с дистанц-векторными протоколами, link-state протоколы устроены сильно сложнее. Link-state протоколы разбивают всю топологию на отдельные кусочки. Каждый роутер рассказывает про то, как он видит топологию вокруг себя. Например, если мы представим себе, что у нас есть роутер, который связан с другим роутером, который связан с третьим, третий — с четвёртым и четвёртый — с первым. В кольце. Роутер номер один говорит, я знаю, как добраться до второго и до четвёртого. Роутер номер один говорит, я вижу второго,

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

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

Как первому роутеру интереснее добраться до четвёртого? Тоже напрямую интереснее. Как первому роутеру до третьего лучше всего добраться? У него есть вариант либо наверх, либо через низ. Он говорит, пойду наверх, наверное, поприкольнее, по каким-то своим причинам принимает решение пойти наверх. И дальше после того, как построил все кратчайшие маршруты в пределах своей топологии, он смотрит на то, что рассказывают о себе эти роутеры. И если третий роутер говорит, я знаю сети X и Y, первый роутер говорит, до сети X и Y можно добраться по наиболее короткой трассе до роутера 3, а дальше он к этим сетям уже подключён. Здесь нет процесса обмена самими маршрутами. Здесь есть процесс обмена кусками таблицы топологии. Роутеры с использованием таблицы топологии строят кратчайшие маршруты до других роутеров. Не до маршрутов, а до именно роутеров. А дальше уже то, что роутеры знают, как добраться в определённую сеть, это скорее следствие того,

что мы сначала посчитали кратчайшие маршруты и только потом по этим кратчайшим маршрутам сказали, что можно добраться до определённых сетей. Это, естественно, намного более сложная вычислительная штука, но если у вас в голове есть полная карта сети, то, естественно, вы можете, зная эту карту сети, намного более тщательно, намного более интересно посчитать маршрут. Это, опять же, сравнимо с поездкой на автомобиле. Когда вы используете дистанц-векторные протоколы, можно это сравнить с поездкой по указателям, когда вы примерно представляете, куда вы хотите доехать, и вы слепо верите тому, что если поехать направо, там будет какой-нибудь город Смоленск, и до него можно добраться через 50 километров. А link-state протоколы — это протоколы, которые дают вам точную уверенность в том, что если пройти по определённой трассе, то можно добраться до удалённой сети. Это сравнимо с поездкой по карте, когда у вас есть точная карта, вы точно знаете, в какой момент надо свернуть, в какой момент надо сколько проехать,

какая там будет дорога, грунтовка, асфальтовое покрытие, шоссе, автострада. Это существенно более, если хотите, комфортная езда будет. И если вдруг вы захотите, допустим, объехать пробку, вы тоже можете это сделать. Отслеживание состояния каналов связи среди прочего гипотетически позволяет нам передавать маршруты также о заторах в сети. И гипотетически есть механизмы, которые позволяют это делать. Как у нас будут работать дистанц-векторные и link-state протоколы, если взять и сравнить их один рядом с другим. У нас есть вот такая топология, и роутер 1 подключён к некой сети А. Если у нас дистанц-векторные протоколы, этот роутер R1 говорит, я знаю сеть А. И дальше он говорит, я знаю её на каком-то расстоянии, на каком-то векторе. R2 получает маршрут от R1 и говорит, я знаю, что R1 знает сеть А, но я тоже, получается, знаю сеть А.

Дальше роутер 3 говорит, я вижу, что R2 знает сеть А, как следствие, если я пойду через него, я тоже буду знать, как добраться до этой сети. И R3 говорит, я знаю, как добраться до сети А через роутер R2. И получается следующее. R4 говорит, я вижу R3, который знает, как добраться до этой сети. Следующий роутер — я тоже знаю, как добраться до этой сети. Каждый роутер, ориентируясь на то, что ему сосед говорит, что он знает, как добраться до определённой сети, говорит, раз ты знаешь, тогда я тоже знаю, и дальше начинает рассказывать это следующим роутерам в цепочке. И они тоже, ориентируясь на слухи о том, что где-то кто-то когда-то видел эту сеть, принимают решение о том, что они тоже знают эту сеть. Иногда дистанц-векторная маршрутизация называется маршрутизацией по слухам. Link-state протоколы в такой ситуации будут вести себя совсем иначе. Link-state протоколы — роутер R1 скажет, я вижу роутер R2, и я вижу, что у меня есть подключённая ко мне сеть А. Дальше R2 скажет, я вижу роутер R1, и я вижу роутер R3.

R3 скажет, я вижу R2, я вижу R4. И R4 скажет, я вижу R3. И когда роутеры построят кратчайшие маршруты друг до друга, они все соберут в голове полную карту топологии, они посчитают, как можно добраться до роутера R1, и R1 как роутер, который подключён к сети А, станет возможным участком маршрута до этой сети А. В любом случае все роутеры, которые получат всю необходимую информацию для построения карты, сначала построят карту, а потом роутер R2 скажет, я вижу, что я могу добраться до роутера R1, к нему подключена сеть А, поэтому я могу, построив маршрут до R1, и прибавив к этому стоимость сети А на роутере R1, получить маршрут до сети А. То же самое сделает R3. Он скажет, я знаю R1, причём я вижу полную карту, как до него можно добраться, и он знает сеть А. И R4 тоже скажет, я знаю, как добраться до роутера R1, и он знает сеть А.

Это не то, что я вижу соседа, который вроде бы знает эту сетку, а именно то, что я точно знаю, как до этой сети можно добраться, через какие роутеры маршруты этой сети будут проходить, и какие свойства каналов, которыми эти все роутеры соединяются, мне будут интересны. Так, давайте это на Синдидвара посмотрим. И то, что у нас осталось, это про сам протокол RIP. Протокол RIP — это такой образцово-показательный дурацкий протокол динамической маршрутизации. Он очень старый, он основан на алгоритме Беллмана — Форда, который был разработан в 1969 году. Он чуть старше, чем модель TCP/IP вообще. Но тогда, естественно, в 1969 году был придуман сам алгоритм, но не конкретная реализация, не конкретный протокол. И RIP изначально разрабатывался для протокола NCP,

Network Control Program, который использовался в ARPANET. А потом, когда ARPANET заменили на IP, RIP тоже для него подпилили. Работает RIP очень просто. Он рассылает пары, что я знаю определённую сетку с определённой метрикой. Эти пары маршрута и метрики RIP рассылает каждые 30 секунд. Про каждую сеть, которую RIP хочет рассказать, он раз в 30 секунд рассылает анонс. Метрика в RIP очень проста. Это количество прыжков между роутерами, то есть количество каналов до удалённой сети. Максимальное расстояние в RIP, если хотите, может быть 15 каналов между роутерами. Если вдруг вы заявляете, что сеть будет доступна на большем расстоянии, например, на 16 прыжках между роутерами, на 16 каналах, то это будет означать, что сеть недоступна в принципе теоретически.

В тот момент, когда RIP разрабатывался, это было разумное ограничение, потому что на тот момент весь интернет состоял из очень небольшого количества систем вообще. И они, как правило, были связаны между собой, если не в full mesh, то достаточно неплохо. На тот момент это было актуально. Сегодня 15 прыжков между роутерами можно встретить только в корпоративной сети. Понятное дело, что в интернете существенно больше роутеров вам придётся пройти. И рассылать вообще все маршруты всем соседям каждые 30 секунд — это не очень хорошая идея. Например, учитывая то, что в интернете сегодня порядка 700 тысяч маршрутов имеется. Если каждые 30 секунд их рассылать, то это будет просто очень много. RIP – очень простой протокол, он очень прост в реализации. И за счёт этого он как раз полюбился авторам первых информационных систем.

Но у него есть и недостаток. Он настолько прост в реализации, что очень медленно реагирует на изменения в сети. Если вдруг в сети произошло какое-то изменение, то RIP на него отреагирует неизвестно когда. В определённых ситуациях RIP допускает возникновение петель маршрутизации. RIP не против того, чтобы устроить петлю, предполагая, что эта петля рано или поздно должна каким-то образом разрешиться. Кратковременно с точки зрения RIP это значит, что не позже, чем через 10 минут она пропадёт. По тем временам, когда это всё создавалось, это было актуально. Сегодня, понятное дело, устроить петлю на 10 минут – это, мягко говоря, перебор. Дальше. RIP оперирует термином количество прыжков между роутерами. И вот пример. Как раз у нас 4 роутера в цепочке. Один роутер рассказывает другому, что он знает некую сеть. Сеть А. И роутер говорит, я знаю сеть за 2 прыжка между роутерами.

Сосед добавляет к себе в таблицу маршрутизации указание, что за 2 прыжка между роутерами эта сеть будет доступна. И дальше говорит, я знаю, как добраться за 3 прыжка. RIP немножко по-дурацки устроен. Он рассказывает про то, что можно добраться через определённый интерфейс до определённой сети и уже сразу прибавляет единичку. И по факту, когда сосед говорит, что он знает, как добраться до какой-то сети, эта метрика сразу добавляется в таблицу маршрутизации. И получается, что рано или поздно, если у вас есть некая сеть, про неё узнают все роутеры в топологии. Если вдруг какая-то сеть перестаёт анонсироваться, то через некоторое время после того, как сосед перестаёт про неё рассказывать — нет сообщений вида «я перестал знать какую-то сеть». Есть только отсутствие сообщений, что я знал определённую сеть. Если вы перестали рассказывать про какую-то сеть, через некоторое, может быть, достаточно большое время, соседи поймут, что вы давно не рассказывали про какую-то сетку,

и из таблицы маршрутизации у себя эту сетку изымут. RIP первой версии — это очень старый протокол. Соответственно, он классовый. Он не умеет рассказывать про маски сетей, умеет рассказывать только про IP-шники. Это протокол, который использует бродкаст. Он рассылает сообщения бродкастом на всех интерфейсах на адрес 255.255.255.255. Используется инкапсуляция в UDP по 520 порту, что источник, что назначение. И все узлы, которые получают такие бродкастовые пакеты, их обрабатывают. Понятное дело, что на бродкаст реагируют не только соседние роутеры, которые действительно интересуются тем, какие маршруты известны или неизвестны, но и конечные абоненты. И когда-то давным-давно идея эта была вполне осмысленная, чтобы конечные абоненты знали, какие сети у вас в таблице топологии присутствуют. Чтобы вы не маршруты по умолчанию на них загоняли, а прямо целиком таблицу маршрутизации.

Но через некоторое время после того, как интернет стал развиваться, стало понятно, что, во-первых, классовая маршрутизация – это как-то не очень здорово, а во-вторых, догонять до конечных абонентов все маршруты – тоже какая-то так себе идея. Поэтому появился RIP второй версии, который уже бесклассовый, он поддерживает маски, он использует мультикаст, взаимодействие идёт тоже по UDP, тоже по 520 порту, но на мультикаст в адрес 224.0.0.9. Все RIP роутеры. У RIP второй версии по сравнению с первой появились улучшения, и эти улучшения довольно заметные. Во-первых, вы уже не просто бродкастом рассылаете указания, я знаю, как добраться до каких-то сетей, но вы можете в эти сообщения вложить какие-то аутентификационные данные. Потому что если кто-то в сети вдруг подбросит какие-то левые маршруты, то это может привести к очень неприятным последствиям. Представьте себе, что у вас есть два роутера, связанные коаксиальным проводом,

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

Если вдруг злоумышленник пытается вбросить какие-то левые маршрутные данные, он, если не знает пароля, не может подписать такое сообщение паролем, и сообщение без пароля будет просто игнорироваться. Плюс к тому есть возможность для некоторых сообщений указать next-hop. Вы отправляете сообщение и говорите, что знаете, как добраться до определённой сети, только до этой сети надо добраться не через меня, а через Васю. И можно это использовать, например, в ситуации, когда у вас есть общая среда передачи данных, в ней два роутера R1 и R2. И какой-то роутер R3. И вы рассказываете, я знаю, как добраться до определённой сети, вы RIP-сообщение посылаете в этот канал, но вы хотите, чтобы R3 поставил маршрут до R2, потому что сам R2, например, послать такое сообщение не может. В этом случае вы R3 отсылаете сообщение и говорите, я знаю, как добраться до некой сети,

для этого поставь маршрут до этой сети, но не на меня, а на роутер R2. Вы можете в явном виде для некоторых маршрутов указать NextHop. Немножко раньше, чем RIP второй версии, появился RIP следующего поколения, RIP-NG. И это RIP для IPv6. Он очень похож на RIP второй версии, но предназначен для IPv6. RIP второй версии предназначен только для IPv4. Он точно так же использует UDP, точно так же использует мультикаст, и точно так же у него мультикаст в адрес заканчивается на кучу нулей и девятку. Но для того, чтобы показать, что формат сообщения немножко другой, капельку отличается, этот RIP вкладывается в 521-й UDP-шный порт. Аутентификация в этом RIP-е есть, NextHop в этом RIP-е есть, он по смыслу очень сильно похож на RIP второй версии. Давайте посмотрим на то, как RIP работает на CISCO-ах.