Маршрутизация с использованием протокола RIP

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

Каждому маршруту сопоставляется некоторое число. Чем это число меньше, тем более доверенный будет маршрут. И те маршруты, которые добавляются автоматически, как только вывешиваете адрес на интерфейс, то есть connected маршруты, у них административное расстояние будет ноль. И меньше, чем ноль, сделать нельзя ничего. Поэтому все маршруты, которые connected, они будут самые доверенные. Любые другие маршруты, которые не connected, у них административное расстояние будет больше, чем ноль. Поэтому если вдруг вы в какую-то сетку напрямую интерфейсом смотрите и вы знаете, что до этой сети можно добраться как-то иначе, вы никогда как-то иначе ходить в эту сеть не будете. Вы всегда будете направлять трафик в интерфейс, который смотрит напрямую в сеть. Затем, если у вас есть... Давайте прям буду писать. Connected маршруты. Это, соответственно, административное расстояние будет ноль. Маршруты статические.

Это те, которые вы ручками вбили, команда ip route. Эти маршруты будут иметь административное расстояние единичку. Они чуточку менее доверенные, чем connected, но все равно достаточно сильно доверенные. RIP, если мы будем говорить про RIP, имеет административное расстояние 120. И понятное дело, что если у нас одновременно есть маршрут статический и маршрут RIP-овский, то статический маршрут, который администратор задал, будет существенно более приоритетным, чем RIP-овский. Чем меньше административное расстояние, тем лучше. Если забегать немножко вперед, есть другие протоколы динамической маршрутизации, например, OSPF — у него будет административное расстояние 110. И 110 — это немножко меньше, чем 120, поэтому RIP проиграет OSPF. Если забегать еще немножко вперед, есть такой протокол EIGRP. Когда-то бывший фирменный цисковский, теперь стандартный, условно-стандартный протокол. У него административное расстояние 90. Он будет круче, чем и OSPF, и чем RIP. С помощью этого административного расстояния можно сравнивать между собой степень доверия к нескольким разным маршрутам.

Административное расстояние у маршрута RIP-овского будет по умолчанию 120. Если вдруг до одной и той же сети у нас есть маршрут RIP-овский и маршрут какой-то другой, мы сравниваем их административное расстояние и понимаем, какой маршрут по факту добавится в таблицу маршрутизации. Таймеры в Циске сравнительно стандартные. Раз в 30 секунд у вас рассылаются сообщения. И еще один нюанс: если вдруг у вас меняется топология, то Циска внепланово рассылает сообщения о том, что что-то произошло. Если вдруг она хочет рассказать про то, что добавилась какая-то новая сеть из-за того, что вы интерфейс включили, то как только интерфейс включился, Циска понимает, что добавился новый маршрут, и немедленно начинает рассылать сообщения соседям. У меня есть новый маршрут. Не любой роутер будет делать так. Некоторые реализации RIP-а могли вполне сказать, что у нас есть таймер раз в 30 секунд срабатывающий. Ровно раз в 30 секунд мы отправляем сообщение. Если вдруг сейчас что-то произошло, это не повод менять установленный распорядок.

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

Через некоторое время они, правда, догадаются, что происходит, потому что у них есть метрика, и эта метрика каждый раз будет увеличиваться. У нас роутер R1 изначально знал сетку за 1 копеечку, он сначала говорит: я знаю за 2 копейки, R2 будет говорить: а я знаю за 3 копейки, R1 говорит: ах, ты знаешь за 3, тогда я знаю за 4 копейки, потом R2 говорит: а я знаю тогда за 5 копеек. Они так будут считать до бесконечности, то есть до 16. Кто первый досчитает, тот проиграет. По умолчанию Split Horizon, это механизм так называемого расщепленного горизонта, запрещает отправлять обратно маршрут в тот интерфейс, через который этот маршрут был получен. Тем самым запрещается подсчет до бесконечности. Еще одна особенность цисковского RIP-а заключается в том, что по умолчанию работает RIP первой версии. Если вы просто включаете RIP, у вас работает RIP первой версии.

Вы отправляете пакеты RIP первой версии и принимаете RIP любой версии — первой, второй. Это не то, что вы хотите, на самом деле. Скорее всего, если вы включаете динамическую маршрутизацию в 2019 году, маловероятно, что вы при этом хотите использовать RIP, но если даже вдруг вы используете RIP, вы, скорее всего, хотите использовать RIP второй версии. Но даже если вы переключаете RIP первой версии во вторую версию, по умолчанию в RIP второй версии работает так называемая автоматическая агрегация на границе классовых сетей. Мы сейчас разберем дальше, что это такое и зачем это нужно. Для того, чтобы RIP включить, нам нужно будет запустить контекст router rip. Мы в глобальном конфиге находимся и запускаем router rip. Как только мы это делаем, у нас меняется приглашение к вводу, оно становится config-router, запускается процесс RIP. Но он запускается просто так абстрактно, он ничего еще пока не рассылает.

Мы должны в явном виде сказать, на каких интерфейсах мы работаем с протоколом RIP. Эти интерфейсы задаются с помощью команды network. Эта команда network задает классовую сеть. Если у вас на каком-то интерфейсе есть IP-адрес, попадающий в эту классовую сеть, то на этом интерфейсе включается RIP. Вы начинаете отсылать анонсы RIP, вы начинаете принимать анонсы RIP, и вы все connected сетки на этих интерфейсах включаете во все анонсы. Просто включая RIP, вы ничего никому не рассказываете. Но если вы указываете, например, network 10.0.0.0, это классовая сеть, видите? Вы не можете указать здесь не классовую сеть, вы должны указать классовую сеть. Здесь у нас есть три интерфейса: FastEthernet 0/0, FastEthernet 0/1, FastEthernet 0/2. Безусловно, классовая сеть включает на всех трех интерфейсах RIP. Вы начинаете отсылать анонсы RIP на всех трех интерфейсах.

Вы начинаете принимать анонсы RIP на всех трех интерфейсах. И все три сетки 10.0.1.0, 10.0.2.0 и 10.0.3.0, которые у вас висят по /24 маске, вы включаете в анонс. Обратите внимание на то, что вы командой network задаете классовую сеть, а в анонс, если вы включили RIP второй версии, включаются именно бесклассовые сети с масками. Дальше. Вторая команда network 172.16.0.0. У нас интерфейс 172.16.1.1 по /24 маске. IP-адрес попадает в эту классовую сеть, поэтому на этом интерфейсе тоже RIP включается, и connected сетка 172.16.1.0 по /24 маске включается в анонс. В анонс попадает то, что висит на интерфейсе, с той маской, которая висит на интерфейсе. А включаем команду network мы классовую. Если вдруг вы захотите, вы можете сказать: давайте network мы сделаем 10.0.0.1 или 10.0.1.1.

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

Если, например, у вас есть роутер, и у него есть три интерфейса, у которых IP-адреса из одной и той же классовой сети. И вы хотите сказать, что здесь нам анонсы нужно отправлять, а здесь не нужно, и здесь тоже не нужно. В этом случае вы можете интерфейсы, на которых connected сетки в анонс все равно включаются, но анонсы посылать не нужно, объявить как пассивные. Команда будет passive-interface, дальше указываете название интерфейса в контексте router. Если таких интерфейсов много, а это довольно типичная ситуация, например, если у вас distribution свичи и на них куча SVI-ек висит, то в этом случае проще, чем указывать на каждом интерфейсе, что мы не хотим анонсы посылать, указать команду passive-interface default. Она указывает, что вообще ни на одном интерфейсе не надо посылать никакие анонсы. Но поскольку дружить по RIP вам на каких-то интерфейсах все-таки нужно, то вы можете в явном виде сказать, на каких именно интерфейсах вы анонсы посылать будете.

No passive-interface, и дальше в явном виде указываете название интерфейса. Почему эта штука лучше в ситуации, когда у вас много интерфейсов? Потому что если у вас 50 интерфейсов всего, на них надо включить RIP, и только на одном или на двух интерфейсах надо дружить с соседями, проще, чем указывать, что на 48 дружить не надо, сказать, что вообще нигде дружить не надо, а вот на этих двух надо. Как правило, passive-interface вы указываете на тех интерфейсах, которые смотрят в сторону конечных пользователей. Мы про эти сети, в которых сидят конечные пользователи, должны будем рассказать нашим соседям, но для того, чтобы с этими соседями случайно не подружиться по RIP, указываем passive-interface. Есть любопытная особенность у цисковского RIP, заключающаяся в том, что если вы объявляете интерфейс пассивным, то вы скрываете, что вы на этом интерфейсе работаете в RIP, вы не отсылаете анонсы в эти интерфейсы, но при этом вы продолжаете обрабатывать чужие анонсы, которые в этот интерфейс будут приходить.

Поэтому если вдруг вы хотите, чтобы на интерфейсе кто-то вас не похакал и не сбросил вам какую-то левую лишнюю маршрутную информацию, вам нужно будет тогда закрыть на уровне пакетного фильтра UDP 520-й порт на этом интерфейсе. У RIP есть некоторое количество классовых рудиментов. Часть из них можно выключить, часть из них в любом случае останется. Самый главный классовый рудимент — это RIP первая версия, которая по умолчанию работает. Вы его должны будете перевести в RIP второй версии, указать version 2. И после того, как вы переводите RIP в режим второй версии, у него начинает работать автоматическая агрегация на границе классовых сетей. И это приводит к очень любопытному явлению. Если вдруг у вас есть так называемая разрывная классовая сеть, это явление, как примерно на картинке нарисовано, где у нас есть один кусочек классовой сети — 172.16, и другой кусочек классовой сети — той же самой — 172.16.

Это одна и та же классовая сеть — 172.16.0.0. Но посередине между этими двумя кусочками какая-то другая классовая сеть, не 172.16.0.0. В нашем случае — десятка. В этом случае роутер, который с одной стороны видит классовую сеть 172.16.0.0, и с другой стороны 10.0.0.0 — разные классовые сети. Он будет посылать маршрут фактически на классовую сеть. Он будет указывать, что я знаю сетку, и автоматически не ту сетку, которую он по факту хотел рассказать, будет рассказывать, а классовую сеть с классовой маской. В такой ситуации, когда у нас есть разрывная классовая сеть, левый роутер будет рассказывать, что он знает всю сетку 172.16.0.0, хотя он ее всю не знает. Он знает только 172.16.1.0 по /24 маске. И правый роутер то же самое будет делать. Он будет скрывать, что он знает кусочек классовой сети. Он будет рассказывать про всю классовую сетку целиком — 172.16.0.0 по /16 маске.

Центральный роутер цисковский будет принимать два анонса до одной и той же сети, 172.16.0.0 по /16 маске. Это анонс фактически классовой сетки. И он будет оба этих анонса добавлять в таблицу маршрутизации, и часть трафика будет посылать до этой сети налево, часть направо. Будет балансировать трафик. В итоге, как вы понимаете, трафик до конечного потребителя совершенно не факт, что будет доходить, а даже если будет доходить, то будет доходить в лучшем случае половина. Поэтому это поведение абсолютно дурацкое. Оно нужно для ситуации, когда у вас часть роутеров поддерживает классовую маршрутизацию, часть не поддерживает. Но, к сожалению, оно работает по умолчанию. И для того, чтобы в 2019 году как-то с RIP-ом существовать, вы должны будете это поведение отключать. Команда будет называться no auto-summary. Если вы эту команду указываете, то анонсы будут рассылаться ровно по тем сетям, про которые у нас есть запись в таблице маршрутизации.

Если у нас запись в таблице маршрутизации про /24 сетку, значит анонс будет идти про /24 сетку. Никакого автосуммирования происходить при этом не будет. Как посмотреть, что RIP включился? Вы можете выполнить команду show ip protocols, и она покажет все маршрутные источники, которые у вас есть на железке. Среди прочего, она покажет про RIP. RIP рассылает маршруты раз в 30 секунд. Ближайший 30-секундный таймер сработает через 3 секунды. Посылается та версия, которую мы просили, вторую. Принимаются маршруты второй версии. Команду network мы ввели для классовых сетей 10.00, 10.00, 10.00, 10.00, 168.00. Соседи, которые присылают нам маршруты, 192, 168, 1, 2. В последний раз присылал маршруты 13 секунд назад. Маршруты, которые он нам присылает, мы в таблицу маршрутизации добавляем с административным расстоянием 120. Все маршруты, которые RIP присылает,

если они удовлетворяют каким-то базовым разумным свойствам, добавляются в таблицу маршрутизации. RIP-овские маршруты помечаются в таблице маршрутизации буковкой R. И здесь 0.1, 0.2, 0.3, 0. И 120 — административное расстояние, здесь неправильно нарисовано. Это как раз маршруты, которые RIP нам присылает. У них будет буковка R, у них будет IP-шник сети, и у них здесь два числа. Первое число — это административное расстояние. Второе число через дробь — это метрика, количество прыжков между роутерами, которые нужно пройти для того, чтобы попасть в целевую сеть. В нашем случае два прыжка между роутерами намекают на то, что сосед в эту сеть смотрит напрямую. Что-то типа вот такого у нас будет наблюдаться. Здесь одна сетка, здесь другая сетка, здесь третья сетка. RIP для IPv6 работает примерно так же.

RIPng и RIP второй версии очень похожи друг на друга. Но RIPng никогда не был даже гипотетически связан с классовой адресацией. Поэтому все эти auto-summary для него будут неприменимы. Ещё один момент заключается в том, что в RIPng нет команды network. Если вы хотите включить RIP на интерфейсе, не надо включать командой network какую-то классовую сеть, которая накроет интерфейс, на котором есть свой IP-шник. Вы должны просто зайти на интерфейс и сказать, что на этом интерфейсе работает RIP для IPv6. Команда IPv6 Unicast Routing в глобальном конфиге указывает на то, что мы хотим запустить движок маршрутизации IPv6. Дальше запускаем движок RIP-а. В отличие от IPv4 RIP-а, где у нас была команда router rip просто без параметров, в IPv6 это будет команда ipv6 router rip, и дальше требуется название экземпляра. Вы можете запустить несколько экземпляров RIP-а для IPv6,

в отличие от IPv4, где можно запустить только один экземпляр, и он будет неименованный. Если у вас есть на железке IPv4-адреса, вам больше ничего специального делать не надо. Если у вас на железке нет вообще ни одного IPv4-адреса, вам может понадобиться такая штука, как router ID. Это просто 32-битное число, которое записывается в форме IP-адреса, и хотя бы одно какое-то нужно для того, чтобы экземпляр RIP-а получил идентификатор. Например, число 1 — это вполне себе неплохой идентификатор. Router ID и дальше 32-битное число в формате IP-адреса. Если у вас хотя бы один IPv4-адрес есть, железка выберет любой из этих IP-адресов и назначит его в качестве идентификатора, так что этот router ID по факту назначать нужно не всегда. Дальше заходим на конкретные интерфейсы, которые нам нравятся, на которых мы хотим включить IPv6 RIP, и указываем команду ipv6 rip,

дальше название нашего экземпляра CCNA и слово enable. Для работы IPv6 RIP вам потребуется link-local-адрес. Если у вас не настроена IPv6, потребуется ещё команда ipv6 enable. Но если у вас уже есть IPv6 link-local-адрес или вы уже полноценный IPv6-адрес прописали, эта команда не требуется. Так же, как и в случае с IPv4 RIP, если вы включаете RIP на IPv6-интерфейсе, connected маршрутизируемые сетки попадают в анонс, на этом интерфейсе вы начинаете отсылать анонсы RIP-а и принимать анонсы RIP-а. Как проверить, что RIP завёлся? Та же самая история, что для IPv4. Show IP protocols была для IPv4, show IPv6 protocols для IPv6. Покажут название экземпляра, покажут, на каких интерфейсах вы включили RIP. Если вдруг захотите, можете ещё show ipv6 rip посмотреть,

там тоже самое расскажут. В IPv6 таблице маршрутизации show ip route, show ipv6 route. Всё то же самое. Если хотите показать только RIP-овские маршруты, show ipv6 route rip. Оно отфильтрует только маршруты, полученные из RIP-а. Буковка R, административное расстояние, метрика. Всё то же самое. RIP, так же как и все остальные протоколы динамической маршрутизации, NextHop-адрес для каждого маршрута будет добавлять link-local. Это нормально, ничего плохого в этом нет. Как следствие, у вас опять же может быть ситуация вида: несколько маршрутизаторов находятся в цепочке между собой. На них маршрутизируемых адресов на транзитных интерфейсах нигде нет. Есть только конечные сетки, конечные пользователи. Здесь сетка А, здесь сетка Б. Запускаем везде RIP. Тут, тут, тут, тут, тут, тут, тут и тут. И на всех роутерах у вас будет две сети — А и Б. И больше ничего. Это нормально, это логично.

Единственное, что трассировка будет немножко странно работать. Если очень сильно хочется, можно для того, чтобы трассировка как-то работала, добавить по одному IP-шнику здесь. IP-шник x1, x2, x3 и так далее. Это уже детали. Вот таким образом RIP работает. Лабораторную работу делать на него считаю немножко излишним, потому что, во-первых, на RIP будет вопросов очень ограниченное количество, и если даже и будут, то они будут, скорее всего, теоретические. А в реальной практике вы с RIP-ом очень маловероятно, что когда-либо встретитесь. Протокол этот дурацкий. Использовать его в продакшене абсолютно нецелесообразно в 2019 году. Если у вас есть альтернативы в виде протокола OSPF, будет очень странно использовать RIP. Поэтому, наверное, на этом наш курс сегодня завершён. Спасибо за внимание.

И до встречи на курсе ICND2. До встречи на курсе.