RIP в Cisco IOS (часть 1)

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

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

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

то у него эти апдейты занимали достаточно немало так места. И вот в одном апдейте вы могли послать там, допустим, 20 маршрутов, и не так много, казалось бы, да, но эти 20 маршрутов занимали там, например, 500 байт. И 500 байтовый пакет, когда вы начинаете отправлять, он будет занимать канал передачи данных, если он там 1000 бит в секунду, на 4 секунды. То есть раз в 30 секунд вы занимали вот этим пакетом сеть на 4 секунды. Это было дофига, поэтому да, вы не могли слишком часто отсылать апдейты в RIP в те давние времена, потому что вы тем самым фактически бы своими апдейтами загрузили бы сеть на продолжительность, больше, чем вообще говоря можно было передавать по этой сети трафик. Поэтому да, 30 секунд это такой дефолтный компромисс между полосой, которая требуется для работы самого RIP и боевыми данными, которые могут, собственно говоря, по этим маршрутам передаваться.

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

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

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

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

А вот если к вам приходит маршрут, в котором написано, что маршрут стоит 16 копеек, значит, эта сетка недоступна. И если вы соседа держали next hop, и вам сосед прибежал, сказал, что он не знает, как добраться до сети, что у него метрика 16, ну, в этом случае вот вы только понимали, что что-то пошло с этой сетью неправильно. Но если вдруг вам просто перестали приходить анонсы о том, что какая-то сетка доступна через соседа, то вы в течение некоторого времени держите эту сетку в таблице маршрутизации все равно, потому что вы надеетесь и верите, что сосед все равно вам пришлет анонс через некоторое время. RIP будет стараться уложить все маршруты в пакеты с апдейтами. И эти пакеты по умолчанию не превышают размер 500 с небольшим байт. Соответственно, в один пакет может влезть не больше, если мне память не изменяет, 25 апдейтов. 25 маршрутов, простите. Если вы хотите рассказать про количество маршрутов больше, чем 25,

то вы будете разделять все свои маршруты на несколько пакетов, и может сложиться такое, что если вдруг в каком-то пакете определенный маршрут не пришел, то он придет дальше в следующем, потому что он просто не влез в предыдущий. Поэтому из того, что в каком-то апдейте не пришел какой-то маршрут, RIP-получатель не делает никаких выводов. Он просто ждет, что дальше все равно недостающий маршрут придет. Если вдруг сосед рассказал, что знает, как добраться до сети А, и потом перестал вам рассказывать, в течение как минимум некоторого времени вы все еще думаете, что сосед вам все это рассказывает. Но потом, когда достаточно долго сосед не присылает ничего, вы говорите, окей, значит сосед действительно, наверное, больше не знает, как добраться до этой сети. Вот. Вот эта вот логика, она была в RIP-е первой версии, в RIP-е второй версии, в RIP-е NG, которая для IPv6, она тоже есть. То есть RIP очень тупой. Он не отправляет сообщения вида «я не знаю такую сеть». Если про какую-то сетку просто перестали рассказывать,

то эта сетка в таблице маршрутизации держится еще некоторое время. Так. RIP второй версии появился как ответ на бесклассовый мир. Когда появился второй версии RIP, во-первых, придумали SIDR, во-вторых, придумали VLSM, поэтому по внешнему виду айпишника было непонятно, с какой маской он живет. И для того, чтобы как-то адаптироваться под эту вводную, вводную придумали RIP второй версии, в котором изменился формат пакета, в котором в апдейте, кроме айпишника сети, появилась маска. Ну и, соответственно, там немножечко еще всяких штучек навертели. Среди прочих, RIP второй версии стал работать по мультикасту. Вместо бродкаста он теперь шарашит на адрес 224.009. И это, конечно, заметно улучшает производительность сети, потому что такие мультикасты, простите, слушают только рипроутеры. Да, в RIP второй версии появилась возможность указать кастомный next hub для маршрута.

То есть вы отправляете маршрут и говорите, я знаю, как добраться до этой сети, и если вы хотите добраться до этой сети тоже, не надо ходить через меня, ходите через Васю. Вот такая вот штука в RIP второй версии есть. Иногда она бывает полезна, например, в ситуации, если у вас есть общая среда, ну, например, там, как SEAL или SWITCH или не важно что, и вот в сети есть три роутера. Роутер 1, роутер 2 и роутер 3. Вот. И роутер 1 знает, что до сети надо ходить через роутер 2. И он начинает анонсировать эту сетку в RIP. Говорит, ходите, пожалуйста, все через роутер 2. И вот анонс RIP идет от роутера 1. Пойдет он, например, до 3. И когда 3 такой анонс примет, он будет ходить через 2. RIP NG — это более новая версия RIP.

RIP Next Generation. Он не предназначен для замены RIP в 2, поэтому он не RIP третьей версии. Это RIP, который заменяет RIP для IPv4. Поэтому RIP для IPv6 называется RIP NG. По сути своей это тот же самый RIP второй версии, но, соответственно, немножко модифицированный. У него немножко другой формат пакета. У него, тем не менее, все фичи, которые есть у RIP второй версии, тоже остались. Тоже есть аутентификация, тоже есть указание кастомного NextHop. Формат пакета немножко отличается. Не только в смысле IP-шников, потому что IP-шники стали больше, и как следует пакет стал пухлее. Но это довольно очевидно. Но и внутреннее устройство пакета тоже немножко поменялось. И в качестве транспорта RIP NG использует мультикаст FF02.9 на 521 порт. Что RIP первой версии, что второй версии используют 520 порт UDP-шный. Причем используют его в качестве адреса как источника, так и получателя.

То есть они шарашат UDP-шными бродкастами или мультикастами с 520 на 520 порт. RIP NG с 521 на 521. Так, как уже говорилось, RIP использует в качестве мерила хорошести или плохости маршрута количество прыжков между роутерами. Эта метрика никоим образом не зависит от качества каналов, от скоростей, от каких-то их свойств. То есть вы, когда вы выбираете маршрут из нескольких вариантов, вы оперируете только вот количеством прыжков между роутерами. В нашем случае, вот если есть какая-то сетка, сеть A, в которой у нас есть пользователь, и мы хотим на всех роутерах запустить RIP и узнать, что сетка A существует. Что в этом случае будет происходить? А, нет, пардон, наоборот. Сеть A у нас будет с другой стороны. Вот у нас сеть A. Да, вот здесь. Роутер левый, очевидно, знает, что до этой сети можно добраться,

эта сетка у него connected. Дальше он начинает рассылать анонсы. И эти анонсы уходят на соседей. Соседи узнают, что сетка такая присутствует. И до этой сети можно добраться через того, кто прислал анонс. Мы сейчас не рассматриваем варианты с хитрыми next-hop. Дальше они тоже начинают рассылать свои анонсы. Причем рассылают эти анонсы всем, включая и тому, кто прислал такой анонс. В нашем случае мы видим, что роутер, левый верхний, послал анонс с указанием «Я знаю, как добраться до сети за одну копеечку», а ему навстречу пошло указание «Я знаю, как добраться до сети за две копеечки». Учитывая, что сам роутер знает, как добраться за одну копейку, он такой анонс игнорирует. Ну и нижний роутер тоже, соответственно, понимает, что принимает маршрут за одну копейку, отсылает за две копейки и тоже этот анонс игнорируется. Но, тем не менее, на нижний роутер уходит указание, что до сети можно добраться за две копейки. Причем как через верхний роутер, так и через левый.

Ну вот он один из этих маршрутов какой-то выберет, скажет, что я могу добраться через кого-нибудь. Дальше отошлет свои анонсы, что можно за три копейки добраться, и сами эти роутеры скажут «А мы знаем, как добраться за две копейки, зачем нам анонс, что за три можно добраться?». Вот. И вот таким вот образом все роутеры в итоге построили какие-то свои маршруты, как добраться лучше всего до сети, и трафик от абонента до сети А по факту будет ходить, вот так вот. Да, здесь у меня специальная анимашка зелененькая есть. Вот. При этом никто нам не гарантирует, что на самом деле это оптимальный маршрут. И мы не можем на это повлиять, потому что мы не можем сказать, что вот не надо ходить так, вот надо ходить на самом деле вот так вот, потому что здесь будет там производительность больше. Если вот эти вот все интерфейсы, например, 10-гигабитные оптические линки, а вот здесь вот медленный Wi-Fi канал на 54 мегабита, или там, не знаю, на 1 мегабит.

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

он без объявления войны, без ничего просто пропал. Ну и в такой вот ситуации получается, да, что роутеры два оставшихся начинают друг к другу кидаться указаниями. Я знаю, как добраться до такой сети. Эта штука называется подсчет до бесконечности или count to infinity. Count to infinity. И, соответственно, в рипе бесконечность это 16. Ну вот здесь я на девятке остановился, анимашку делал. Ну кто-то из них первый прислал указание, я знаю, как добраться до 16, за 16 копеек. Второй сказал, о, ты, оказывается, не знаешь, как добраться до сети, а я думал, ты знаешь, и тоже вот тогда в этот момент он останавливается. Они досчитали до бесконечности и остановились. Каким образом можно бороться с проблемой подсчета до бесконечности? Простое правило, которое по-русски называется расщепление горизонта, split horizon, заключается в том, что вы не анонсируете маршруты через тот же интерфейс, через который вы их получили.

То есть, если вам сосед Вася рассказал, что вы знаете сетку за 3 копейки, вы в сторону соседа Вася не рассказывайте, что вы знаете сетку за 3 копейки, чтобы Вася через вас ходил за 4 копейки. Вот. Эту штуку иногда нужно будет отключать. Ее можно отключить, это не, скажем, обязательное условие. Но вы должны будете понимать, что если у вас есть два роутера, и они друг другу могут прислать указание, что через них можно добраться до удаленной сети, и вы отключаете split horizon на одном, и вы отключаете split horizon на другом, они вам будут устраивать такую петлю. Но в некоторых случаях это приходится делать. Да, например, вот как раз dmvpn. Если вдруг вы захотите в dmvpn запустить RIP, то вот да, там split horizon надо будет отключить. Еще одна штука, которая есть в RIP, называется road poisoning. Это способ указать, что вы не знаете, как добраться до сети.

Раньше знали, а теперь не знаете. Вот, к примеру, у нас есть стабильно рабочая сеть. Есть роутер, у него есть доступ в сетку, и он посылает всем остальным указаниям, что он может добраться до какой-то сети. Ну, здесь написано, что знает, как добраться за 2 копейки, хотя на самом деле он посылает, по-моему, за 1 копейку. Ну, не суть важна, да. И вдруг у нас сетка эта пропадает. В этот момент мы отправляем уведомление, что мы не знаем, как добраться до сети. Мы отсылаем указание, что сетка доступна за 16 копеек. Так, и еще одна штука, которая заключается в объединении механизмов split horizon и poison reverse, и road poisoning. Если у вас есть какая-то сетка, вот сеть А, и роутер про нее знает, он рассказывает про то, что знает эту сетку, вот рассказывает, что она известна, split horizon говорит, не надо посылать обратно ничего.

Poison reverse говорит, мы можем послать указания про то, что мы эту сетку не знаем в сторону того интерфейса, через который мы получили указание, что эта сетка нам известна. Всем остальным мы будем рассказывать, что известно за 3 копейки эта сетка. А вот в тот интерфейс, через который мы получили эту сетку, мы рассказываем, что сетка доступна за 16 копеек. Делается это специально для того, чтобы если вдруг у этого роутера вдруг что-то с ним случится, какая-то вот нехорошая ситуация, и он будет думать, что через нас до этой сети можно добраться, через нас можно добраться до сети А как-то вот так вот в обход, чтобы у него даже мысль такой не возникла. То есть роутер, который раньше смотрел напрямую в сеть, он никогда через нас в итоге до этой сети добираться уже не будет, даже если очень сильно захочет. Эта штука позволяет в определенных ситуациях, да, если вы выключаете split horizon,

позволяет вам работать, даже если вы выключили split horizon, позволяет вам не устроить петлю. То есть это сочетание двух методов, которые... Пардон. Сочетание двух методов, которые вас защищают от петли. Так, кстати, в цисках, если мне память не изменяет, вот эта вот штука по умолчанию выключена. Я даже не уверен, что ее можно включить. Ну, то есть она точно по умолчанию не работает. Но на некоторых платформах ее включить можно. И вот если вдруг вам она очень сильно понадобится, вы можете ее задействовать. Если вы включаете RIP в цисках, то вам нужно знать некоторые особенности про него. Во-первых, цисковское фирменное административное расстояние для RIP 120. RIP по умолчанию проигрывает EJRP,

у которого нормальные маршруты будут иметь административное расстояние 90. Просто RIP будет по умолчанию проигрывать USPF, у которого административное расстояние 110. Ну, соответственно, он, да, вот со своим 120 будет таким неудачником. Но, тем не менее, RIP будет выигрывать у редистрибьютированных маршрутов EJRP, у которых административное расстояние 170. Будет выигрывать у IBGP-шных маршрутов, у которых 200. Ну, то есть в большинстве случаев, когда RIP будет такой протокол, который среди нормальных IGP-протоколов будет самый неудачник. Но если вы начинаете какие-то маршруты перекладывать между протоколами, то вот у RIP в этой ситуации будет небольшое преимущество. Таймеры по умолчанию раз в 30 секунд отсылаются сообщения, ну, эти самые апдейты. И дополнение, которое есть именно в CISC, это то, что по факту возникновения смены топологии

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

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

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

В классовом мире все работало хорошо. А потом пришли VLSM-овцы и сидровцы и сделали какие-то дурацкие бесклассовые маршруты. И эта команда перестала работать хорошо, потому что то, что команда это сегодня делает, вы указываете по-прежнему классовую сетку, эта команда Network, например, 10.0.0.0, перебирает все IP-шники на интерфейсах, находит среди них те, которые входят в эту классовую сеть, неважно с какой маской, и включает на них RIP. И connected маршруты все с этих интерфейсов включает в анонс RIP. У вас на интерфейсе висела сетка 10.0.1.0 по 24 маски с IP-шником 10.0.1.1. Прекрасно. IP-шник попадает в сетку 10.0.0? Да. Включаем в анонс этот интерфейс. Если RIP второй версии, то включаем в анонс с маской. Если RIP первой версии, включаем в анонс. Просто 10.0.0.0 всю классовую сетку. Соответственно, здесь 10.0.2.0, 10.0.3.0. На всех этих интерфейсах IP-шники попадают в классовую сеть 10.0.0.0.

И в анонс идут connect от сетки по той маске, которая висит на интерфейсе. Если мы хотим включить RIP на интерфейсах, где у нас юзеры сидят, вот здесь, вот мы как раз одной командой на трех интерфейсах включили RIP сразу все. Сразу везде. Если у нас есть интерфейс, которым мы хотим подружиться с соседом, то есть вот здесь вот у нас все-таки есть надежда, чтобы у нас работал RIP и обменивался маршрутами. Для этого, опять же, мы указываем network, классовая сетка 172.16.0.0. И здесь вот у нас в классовой сети 172.16.0.0 будет IP-шник 172.16.1.1. Мы на этом IP-шнике говорим ОК, он попадает в классовую сетку. Интерфейс, на котором этот IP-шник, включаем в RIP. Начинаем на нем посылать апдейты. Начинаем на нем принимать апдейты. И коннектат сетку по той маске, которая висит на интерфейсе, включаем в анонс.

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

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

пользователь вряд ли предположит, что вы будете использовать RIP и вряд ли будет присылать вам какие-то апдейты. Но если вдруг он догадается, то такой апдейт, как ни странно, примется. То есть даже если вы включаете пассив интерфейс, апдейты на интерфейсах, которые помечены как пассивные, все равно принимаются. И, соответственно, все маршруты в этих апдейтах добавляются в топологию. Если вы не хотите принимать от ваших пользователей анонсы RIP, вам следует блокировать их с помощью аксесс-листов. Как объявить интерфейс пассивным? Заходим в Router RIP, в контексте Router указываем Passive Interface и дальше название интерфейса. Если у вас много таких интерфейсов, ну, например, вы на Distribution Switch говорите, что у вас там пачка VLAN есть. Вы включили на пачке VLAN RIP с помощью одной команды Network, потому что они все у вас, например, из одного Distribution Doka. И дальше вы хотите сказать, вот на всех пользовательских интерфейсах мы не хотим отсылать апдейты.

Вы можете указать Passive Interface Default. И после того, как вы это указали, у вас на всех интерфейсах рассылка апдейтов прекратится. Даже на тех, где у вас действительно находятся соседи. Чтобы на отдельных интерфейсах, где у вас соседи все-таки есть анонсы, все равно отправлять, вы укажете No Passive Interface и дальше тот интерфейс, на котором у вас действительно есть соседи. Это удобная штука. Рекомендую к использованию. Опять же, если вдруг зачем-то вы будете использовать RIP, то при разметке Passive Interface делайте Passive Interface Default. И дальше просто в явном виде укажите, где соседи у вас все-таки будут. Ну и не забывайте Аксис-листом заблокировать 520-й порт. Взапишный. Так. Еще одна штука, которая есть в RIP, это та самая автоматическая суммаризация, автоматическая агрегация на границе классовых сетей. Если вы хотите использовать RIP в бесклассовом режиме, вам его надо переключить в режим RIP V2.

Делается это командой Version 2 в настройке роутера. Ну вот после того, как вы это сделаете, вы начинаете отсылать анонсы второй версии. Вы начинаете принимать анонсы второй версии. Но вы по умолчанию делаете автосуммирование. И это будет вот как выглядеть. У вас есть роутер. У него есть интерфейс, который смотрит в сетку 172.16.0.0. Это классовая сеть 172.16.0.0. Если бы она была без классовая, она была бы slash 16. Но она классовая, поэтому маску мы не указываем. При этом на самом деле из этой сети используется только кусочек. 172.16.1.0 по 24 маске. То же самое используется вот здесь. 172.16.2.0 по 24 маске. Это такая же классовая сеть. 172.16.0.0. То есть у нас вот эта классовая сеть получается разрывной. Один кусок в одной части, другой кусок в другой части. А вот тут вот находится какая-то другая классовая сеть. 10.0.0.0.

И вот здесь тоже 10.0.0.0. Вот в такой ситуации роутер, самый левый, будет пытаться прикинуться классовым роутером. Он говорит, у меня с одной стороны вот здесь вот сетка классовая 172.16.0.0. И я ее режу на части. Раз мы ее начали там режеть на части, мы там повесили айпишники. Мы там указали маски. Мы внутри своей сети вольны делать все, что угодно. Но как только мы начинаем выходить наружу, мы не должны показывать, что наружу мы чего-то там порезали. Мы ведем себя в логике RFC 950 1985 года. Что если мы начали какую-то сетку резать, мы это держим в тайне. Потому что во внешнем мире никаких бесклассовых сетей на тот момент все еще не было. Cisco себя ведет как роутер из середины 80-х. И она наружу показывает целиком сетку 172.16.0.0. Ну то есть, если RIP второй версии работает, он будет с маской пересылаться. 172.16.0.0.0.0.0.0.0.0.

И с другой стороны точно такая же ситуация будет. Роутер правый говорит, у меня с одной стороны сетка классовая 172.16. С другой десятка. Соответственно на границе классовых сетей я должен прикидываться, как будто я ничего на части не резал. И целиком всю 16-ю сетку присылает в анонсе. На центральный роутер приходят два указания, что до всей 172.16.0 сети можно добраться через два роутера. Можно через право, можно через лево. Что будет делать роутер? Правильно, балансировать. ECMP. Балансировка между маршрутами равной стоимости. Чтобы такого не было, надо на роутере указать команду noAutosummary. Это поведение с автосуммированием по умолчанию суммируются все разрезанные сетки до классовой сети на границе между двумя классовыми сетями. Если вы отключаете noAutosummary, у вас перестает роутер вести себя таким похабным образом и начинает посылать все анонсы как есть.

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

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

Ну, например, блок 10, 0, 1, 0. Здесь 10, 0, 2, 0. Ну, а вот эти вот линки транзитные, они, как правило, выделяются из другой сети. И далеко не всегда из той же классовой сети. Ну, соответственно, будет здесь какой-нибудь, там, не знаю, 192, 168, чего-то там. Вот здесь вот 192, 168, здесь, здесь, здесь, здесь. Все, вы попали. Это та самая картинка, которая вот здесь вот нарисована. Что аксесс-свечи будут присылать указания, что они знают, как добраться до всей десятки. И вся десятка на уровне дистрибьюшн-а окажется дохлой. Поэтому так делать не надо. Что делать, если RIP вы включили, и он не заработал? Ну, значит, вам потребуется диагностика. Смотрите, что RIP включен, что IP-протоклс показывает, что он зарегистрирован. Смотрите на то, что у вас включена правильная версия. То есть вот здесь показывается, какую версию вы отправляете, какую версию вы принимаете.

Если вы включили версию 2, то вы и то, и другое будете отправлять. Дальше. Следите за тем, чтобы вот эта вот штука у вас была написана. Что автоматическое суммирование вы выключили. Максимум пасс указывает, сколько маршрутов с одинаковой стоимостью, с одинаковой метрикой вы будете добавлять в таблицу маршрутизации. И сколько потом маршрутов CEF возьмет в качестве, скажем, основы для балансировки трафика. По умолчанию 4 можно увеличить до 16. Но я вам не рекомендую это делать. Более того, я вам рекомендую на самом деле даже 4 сокращать. Вероятность того, что у вас будет 4 абсолютно одинаковых маршрута в сторону сети назначения, она очень маленькая. И это, как правило, будет связано с тем, что у вас есть куча филиальных сетей. Вот. И, соответственно, два хаба. Хаб. Хаб. И здесь споуки. Споук 1, споук 2, споук 3, споук 4.

Ну, их тут много может быть. И, соответственно, у вас между всеми этими самыми хабами и споуками протянуты туннели. И, естественно, между двумя хабами тоже тут какой-нибудь жирный туннель есть. И ситуация, при которой у вас один хаб может добраться до какой-то сети через 4 абсолютно разнозначных туннеля, означает, что на самом деле вот этот вот туннель между двумя хабами сдох. И у вас можно добраться до сети другого хаба вот так, вот так, вот так или вот так. Но это вы будете занимать каналы ваших споуков. Вы будете посылать трафик споуку, чтобы он переслал трафик другому хабу. Это бред. Так делать не надо. Поэтому в реальности вот даже 4 одинаковых маршрута, добавляемых в таблицу маршрутизации, это уже как-то очень подозрительно. Так делать плохо. Маршруты, которые RIP добавляет в таблицу, будут помечаться буквой R. Show IP Road RIP показывает, что RIP-овские маршруты есть. Административное расстояние 120. 120, 120, да, не 110. Показывается IP-шник NextHop, время добавления маршрута и интерфейс, через который они были добавлены.

Вот. Routing for networks – это те команды network, которые вы ввели. Routing information sources – это кто вам прислал маршруты. В нашем случае вот NextHop 192.168.1.2 прислал нам какие-то апдейты, и мы эти апдейты обработали и запихали их в таблицу маршрутизации. Так. Что касается RIP-NG. Вы можете включить RIP для обработки IPv6. То есть там команды очень похожи на RIP для IPv4. Единственная разница – команды network нет. То есть если вы работаете с RIP-ом NG, то вы должны будете на каждом интерфейсе в явном виде включить этот интерфейс в экземпляр RIP-а. В отличие от IPv4 RIP-а, ну, первой или второй версии, которых вы можете на железке запустить всего один экземпляр, RIP-NG можно запустить несколько экземпляров. Опять же, вы обычно этого делать не хотите, но если что, это сделать можно. IPv6 Unicast Routing – это просто включаем движок маршрутизации IPv6 пакетов.

IPv6 Router RIP – дальше название экземпляра указываем, с каким названием будет работать наш экземпляр RIP-а. Ну и дальше внутри конфигура роутера мы указываем всякие разные настройки. Можно указать роутер ID. Полезно, если у вас нет ни одного IPv4-го адреса, потому что без роутера ID RIP не может запуститься. А так мы им помогаем. Если хотите указать passive interface, вот, passive interface, там, либо указываем в явном виде интерфейс, либо passive interface default, но passive interface, то, ну, там, ну, то есть привычным нам образом все настраивается. Единственное, минорное достаточно отличие, ну, я уже говорил про него на CCNA, это в IPv4 роутерах у нас приглашение к ководу ConfigRouter показывается в контексте редактирования роутера, а здесь ConfigRtr. И на экзамене на этом может быть вопрос. Как включить RIP на интерфейсе, и раз команды Network нету? IPv6 RIP название экземпляра Enable.

Вам потребуются IPv6-адреса. IPv6 Enable на интерфейсах, которые транзитные, вполне подойдет. В таблицу маршрутизации мы NextHop будем добавлять в любом случае linklocal. Поэтому маршрутизируемые IPшники в IPv6 маршрутизации на транзитных интерфейсах не нужны. В нашем случае вот на гигабите 001 у нас есть linklocal-адрес, и вполне достаточно его будет для того, чтобы R2 на этот linklocal поставил свой маршрут. На интерфейсах, которые у нас будут висеть, на пользователей, смотрящие гигабит 0.1.1, 0.1.2, 0.1.3, нам потребуется иметь, конечно, настоящие адреса, наверное, для того, чтобы включить всякие Slack или что-то еще, но чтобы пользователи могли, в конце концов, пускать трафик в интернет. Ну, это не сказать, чтобы прям обязательно было, но все-таки хорошо, когда у вас там маршрутизируемый адрес есть. Вот. С RIP-NG диагностика, в общем, такая же, как в случае с IPv4 RIP,

showipv6 protocols показывает, на каких интерфейсах вы RIP включили, показывает, что есть какие-то интерфейсы, которые помечены как пассивные, есть специальная команда showipv6 rip, ну, равно showiprip на самом деле есть, показывает именно свойства RIP. Показывает, вот, что у нас порт 521, название экземпляра, мультикастовый адрес, административное расстояние дефолтное, максимум пасс в случае с IPv6 RIP будет 16, и тоже это, на самом деле, перебор, когда у вас 16 одинаковых маршрутов, которые можно одновременно использовать для доставки трафика наилучшим образом. можно увеличить до 64, но не знаю, насколько имеет смысл. На мой взгляд, имеет смысл сокращать. Апдейты в RIP NG идут с такой же частотой и по тому же алгоритму, что и в обычном RIP, то есть раз в 30 секунд вы отправляете апдейты. Если сосед в течение трех минут не продляет вам, скажем, маршрут,

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

что Split Horizon у нас работает по умолчанию. Мы не посылаем обратно маршруты, которые мы получили через интерфейс, а Poison Reverse по умолчанию выключен. Но если вот мы будем выключать Split Horizon, имеет смысл Poison Reverse в обратную сторону в некоторых хотя бы случаях включать. Не всегда это нужно, но иногда бывает полезно. Так. Ну и маршруты, которые RIP добавил в таблице маршрутизации, точно так же помечается буквой R. Точно так же у них административное расстояние 120. И вот Next Hop ставится Link Local. Можно ли оба включить? Я думаю, что можно, только смысла нет. То есть Split Horizon говорит, ничего не посылай обратно. Poison Reverse говорит, посылай обратно бесконечно большую метрику. Они друг другу в некотором смысле противоречат. Есть ли смысл включать их? На мой взгляд, нет. Что будет, если включить их? Ну, на мой взгляд, ничего не будет. Просто Split Horizon будет работать в первую очередь.

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