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

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

А там кроется на самом деле много всякого разного интересного. Вот мы с вами будем рассказывать про таймеры в RIP. Мы с вами будем рассказывать про выброс маршрута по умолчанию, потому что это достаточно интересная и полезная тема. Ну, понятное дело, что в RIP в принципе-то с полезностью вопрос очень большой стоит. Но если уж вы используете RIP, то вот, скорее всего, маршрут по умолчанию вы в какой-то момент выбрасывать захотите. Есть и некоторые другие штуки, которые мы будем с вами изучать. Давайте начнем с того, что вот на слайде есть у нас. Это Default Information Resonate. способ вбросить маршрут по умолчанию в протоколе RIP. Что это такое, зачем это нужно и как это работает? Если у вас есть где-то в сети, среди множества роутеров, один, который имеет выход в интернет. Например, вот в него втыкается напрямую хвостик от провайдера. В таблице маршрутизации каким-то образом появляется маршрут по умолчанию на этом роутере.

И вы хотите, чтобы RIP этот маршрут по умолчанию взял из таблицы маршрутизации и вбросил его в таблицу топологии. Так, чтобы все остальные роутеры у себя в таблице маршрутизации маршрут по умолчанию тоже получили. И чтобы они NextHop поставили так, чтобы трафик смотрел в сторону вот этого вбрасывающего роутера. По умолчанию этого не происходит, вы это должны сделать ручками. И делаете это вы немножко забавным образом. В IPv4 RIP, ну то есть RIP второй версии, ну равный первой на самом деле, там примерно так же работает, вы можете указать default information originate в контексте роутера. То есть заходите в router RIP, дальше config router и указываете команду default information originate. Если у вас есть маршрут по умолчанию, то, соответственно, он вбрасывается в анонс и он начинает отсылаться соседям. В IPv6 RIP, который RIP NG, вы это делаете не в настройках самого роутера.

Вы указываете в настройке интерфейса, которым вы смотрите на соседей, что вы хотите на этом интерфейсе соседям отсылать маршрут по умолчанию. И, соответственно, здесь есть два варианта, как можно это сделать. Первый вариант это указать IPv6 RIP, дальше экземпляр RIP, default information originate, второй вариант default information originate only. Разница между ними заключается в том, что если вы на интерфейсе посылаете соседу указание, что маршрут через вас по умолчанию доступен, то в некоторых ситуациях вы не хотите дополнительно отсылать указание, что а еще кроме всех-всех-всех сетей в мире, вот некоторые другие сети в мире тоже есть. Вы можете сказать, что раз мы посылаем default, то никакие другие сети посылать на самом деле по RIP не надо, потому что нет смысла говорить, что я знаю, как добраться до всех сетей в мире, а кроме того я знаю, как добраться до вот этой вот сети, конкретной маленькой. Например, в ситуации, когда у нас вот есть роутер R2,

который смотрит в интернет, и дальше есть роутер R1, который к нему подключен проводом, и за спиной у роутера R1 находится какая-то вот локальная сеть. В такой ситуации вполне возможно, что вы захотите как раз использовать default information originate only, как на картинке сделано в такой вот топологии, default information originate only будет очень полезно. Дело в том, что действительно, если у нас есть вот только один способ от R1 добраться до R2 и до всего остального мира тоже, то, соответственно, если R2 рассказывает, я знаю, как добраться до дефолта, ну, это в IPv6, как бы, ну, в IPv4 примерно такой же смысл был бы, если нам посылают R2 дефолтный маршрут, давайте все-таки по-честному напишу, все-таки, чтобы подчеркнуть, что это IPv6, два двоеточия, слэш ноль. Вот если он такой маршрут посылает, то нет смысла дополнительно говорить, а кроме того, здесь вот еще какая-то сетка есть, про которую я тоже знаю.

Потому что в любом случае R1 поставит маршрут по умолчанию, и R1 рядышком поставит еще указание, что вот такая вот мелкая сетка там тоже имеется. Нет смысла просто в этом. Абсолютно излишне получается отправка такого дополнительного маршрута. В то же время не исключено, что есть какой-нибудь другой роутер, который будет посылать указание, что через него такая вот сетка тоже есть, маленькая. И в такой ситуации нам как раз интересно, чтобы у нас отсылались и отдельный маршрут по умолчанию, и отдельно специфичные маршруты, чтобы в таблице маршрутизации маршрутизатора, который будет получать из нескольких разных мест указание о том, что есть какая-то вот частная сетка, чтобы у него по правилам most-specific root не было ситуации, при которой он от одного роутера ее не получает, и, соответственно, трафик весь идет по второму маршруту через запасной. Так, вот такая вот штука. Вы должны будете понять для себя, что вы хотите. Хотите ли вы отсылать только дефолт,

или хотите отсылать и дефолт, и специфики. И, соответственно, вот либо IPv6.rip, дальше название экземпляра рипа, так, пардон, указываете default information, только originate или originate only. Если указываете просто originate, вбрасывается в дефолт. Если указываете originate only, отправляется только дефолт, и ничего кроме него. Вот. В IPv4 нельзя сказать originate only, то есть можно только default information, originate, у вас в таблицу добавляется дефолт, и он отсылается всем. То есть здесь IPv4, рип немножко по-дурацки устроен. Так. Еще одна штука, которую можно будет использовать в рипе. Это на самом деле частный случай того, что мы только что изучили. Частный случай заключается в следующем. В предыдущем слайде мы рассказывали про то, что в рипе можно взять и отослать маршрут по умолчанию. И маршрут по умолчанию включает в себя вообще все айпишники.

Вот можно рассказывать не про вообще все айпишники, а про некоторый диапазон адресов. Но, соответственно, вы придумаете какую-то вот сетку, которая включает в себя несколько разных сетей, которые у вас есть в таблице маршрутизации, и скажете, а до всех этих сетей можно добраться через меня. Это как раз та самая агрегация, когда у вас есть, вот, например, роутер, и у него есть несколько разных маршрутов. Есть 10.01.0 по 24 маске, 10.02.0 по 24 маске. И мы не хотим рассказывать, что вот есть отдельно такая сетка, отдельно сека, отдельно пятая, отдельно десятая. Мы хотим рассказать про то, что у нас есть си айпишники в сети 10.00.0.16. То есть мы агрегируем кучу мелочевки, начинающиеся на 10.0, в одну большую сетку 10.00. И для того, чтобы это сделать, в рипе есть настройка на уровне интерфейса. То есть когда вы на интерфейсе говорите, мы отправляем маршрут, вот мы можем отправить кучу мелочевки, или можем вместо кучи мелочевки отправить один суммарный маршрут. Ну, соответственно, это надо делать на всех интерфейсах,

на которых вы хотите такой получать. Потому что если вдруг вы скажете, что опять же у нас вот есть интерфейс, на нем мы отправляем кучу мелочевки, а на другом интерфейсе мы не отправляем кучу мелочевки, мы отправляем только суммарку, то трафик будет ходить туда, где есть мелочевка. По правилам Most of the Safe Route у нас будет выбираться маршрут с наибольшей маской. Вот вы, соответственно, должны будете аккуратно посмотреть, на каких интерфейсах вы хотите включить вот такую вот агрегацию и отправить суммарный маршрут тем соседям, которые этого заслуживают. Настройка будет производиться на уровне интерфейса, и команда будет иметь вид. IP Summary Address намекает на то, что мы хотим на этом интерфейсе не отсылать мелочевку, хотим отправить только суммарную сетку. Дальше указываем слово RIP, намекает на то, что мы именно с протоколом RIP будем работать, и указываем, какую суммарную сетку мы хотим анонсировать. Если у вас в этом интерфейсе собирался RIP отправить хотя бы один маршрут, который попадает вот в эту суммарную сетку,

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

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

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

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

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

сколько этому маршруту осталось жить. Вы, как получатель, откладываете таймер, не таймер, откладываете, скажем, диапазон в 180 секунд, в 3 минуты. И эти 3 минуты даются на то, чтобы получить следующий апдейт от того соседа, который у вас является next hop. То есть, если сосед ничего не пришлет через 180 секунд, то вы считаете маршрут трупом и через него уже не ходите. При этом он остается в таблице топологии. Он из таблицы маршрутизации удаляется, поскольку он будет являться неправильным маршрутом, он будет называться invalid. Но, соответственно, он после того, как он стал invalid, он из таблицы маршрутизации удаляется. параллельно работает еще один таймер, который называется hold down. Это таймер, который отдельно от инвалида работает. И hold down таймер имеет очень интересную природу.

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

а он дальше ходит через кого-то, кто ему присылает этот маршрут. На самом деле, такого маршрута по факту в таблице может и не быть. И если вдруг у вас раньше был какой-то маршрут, а теперь он перестал быть, вы, как только у вас заканчивается hold down timer, делаете очень интересную вещь. Вы объявляете, что этот маршрут становится закарантиненным, если хотите. То есть, вы не принимаете этот маршрут больше ни от кого, потому что вы подозреваете, что если вам кто-то будет присылать этот маршрут, что у него на самом деле есть, на самом деле он врет. Вы анонсируете сетку, которая у вас есть, с бесконечной метрикой. Это тот самый road poisoning. То есть, вы говорите, сети такой больше нету, прям совсем нету. Если у вас будет кто-то, кто присылает вам такой маршрут, вы игнорируете эти анонсы, но при этом маршрут у вас остается в... Здесь не RIP, здесь в таблице топологии. Это не RIP, это более правильно, да,

RIP-овская таблица топологии. И в течение некоторого времени маршрут в таблице топологии будет, но он будет одновременно соответственно убран из таблицы маршрутизации, и одновременно же он будет закарантинен в таблице топологии RIP. Вот эти вот таймеры 180 секунд, они как раз удобно, что они совпадают, они там не случайны. hold down timer это отдельный таймер, который будет работать как то, что вот в течение некоторого времени маршрут должен оставаться в таблице топологии, даже после того, как он стал инвалидом. Вы запустили hold down, и вы говорите, что этот маршрут, который в hold down висит, он в общем не должен совсем бесконечно долго жить, правда? Есть отдельный таймер, который указывает, как долго маршрут вообще стоит держать в таблице топологии RIP. Этот таймер называется Flash. То есть вот здесь вот у нас маршрут в первые 180 секунд, с ним все в порядке, он valid. Дальше наступил таймер invalid.

Пошло вот здесь invalid. Invalid. И запускается hold down таймер. Сколько времени маршрут у нас будет считаться вот этим невалидным, сколько мы будем держать в таблице. Это hold down. Таймер hold down. Но маршрут, который у нас в таблице есть, хороший или плохой, или он не должен жить бесконечно, особенно если он плохой, поэтому отдельно работает Flash таймер. Это через сколько после получения апдейта мы удаляем маршрут Flash. Flash таймер в цисках по умолчанию 240 секунд. Это меньше, чем 180 плюс 180. То есть получается, что вы три минуты ждете с момента получения апдейта, запускаете invalid таймер, и еще минуту у вас маршрут находится в таблице, но под карантином. И через эту минуту срабатывает Flash таймер 180 плюс еще минута 240, и удаляет этот маршрут.

Если бы вдруг мы Flash таймер подкрутили и сделали бы его, например, 360, то у нас оба эти таймера, и hold down таймер, и Flash таймер сработали бы одновременно. Но вот по умолчанию, да, цисковский Flash происходит не спустя три минуты после того, как маршрут объявили инвалидом, а спустя минуту. Вот. Там есть некоторые особенности. Flash таймер, он, соответственно, срабатывает всегда через 4 минуты, через 240 секунд, а hold down таймер может запуститься, как только маршрут стал инвалидом. И, например, инвалидом маршрут может стать, если у нас нет ни одного живого NextHop. Если у нас был роутер, который принимал маршрут от другого, то есть другой маршрут, другой роутер присылал нам маршрут, и мы говорили, все хорошо, у нас замечательно, у нас есть живой NextHop, и тут нам приходит метрика 16 от соседа, который говорит, что у нас маршрут таким образом стал недоступен. Вот в этой ситуации мы сразу немедленно понимаем, что NextHop, который прислал нам

метрику 16, он уже больше не NextHop, и других вариантов, как добраться до сети, у нас нету, поэтому мы инвалидом на самом деле можем объявить маршрут, не дожидаясь трех минут с момента получения апдейта. Мы можем его сразу объявить инвалидом. И вот начиная с инвалида, начиная с вот этого самого таймера invalid, у нас начинает тикать три минуты hold down. То есть в случае, если у нас сосед просто перестал присылать апдейт рипа, мы, соответственно, ждем три минуты, объявляем маршрут инвалидом, ждем еще минуту, предполагая, что еще две минуты мы согласны потерпеть этот маршрут саблиться, но дальше наступает флаж, и у нас таймер удаляется. Если сосед прислал нам указание, что он знает определенную сетку, а потом сразу прислал указание, что он знает, что до этой сети больше добраться нельзя, то есть от нулевой отметки у нас проходит, например, 20 секунд, и приходит здесь вот метрика 16, что маршрут больше недоступен, то вот это время до получения

нормального, с момента получения нормального маршрута до получения поизонинга у нас будет маршрут валид, дальше он начинает быть инвалид, инвалид, дальше у нас начинает работать hold down таймер, 180 секунд до 200 отметки, и 40 секунд маршрут у нас, соответственно, еще будет жить в таблице. Смысл здесь в том, что, да, мы не знаем заранее, в каком порядке мы будем маршрут объявлять инвалидом, и в каком порядке у нас что будет срабатывать, поэтому флаж работает от момента получения последнего анонса, а hold down таймер говорит, что вот мы, да, если получаем, что сетка у нас будет недоступна, то мы запускаем таймер с момента того, момента, с момента того, с той секунды, когда мы понимаем, что маршрут стал недоступен. То есть, да, в ситуации, когда сосед просто перестал

нам что-то присылать, мы сначала объявляем маршрут инвалидом, через 3 минуты после получения апдейта, и через еще минуту маршрут удаляем. Если сосед прислал нам штатно сообщение, что он не знает, как добраться до какой-то сети, прислал маршрут с метрикой 16, это значит, что он не ждал перед этим 3 минуты, значит, с момента последнего нормального анонса прошло меньше 30 секунд, и мы инвалидом маршрут объявляем сразу, и hold down таймер мы тоже запускаем сразу. Вот такая вот штука. Таймеры задаются командой timers в настройке роутера rip, то есть, если у нас есть роутер rip, мы в него перешли, дальше команда timers basic, первая цифра это update timer, как часто посылать hello пакеты, вторая 15, через сколько после последнего анонса мы признаем маршрут трупом, если вдруг не приходят анонсы в течение 15 секунд, при том, что они должны приходить раз в 5 секунд, ну, значит, мы говорим, что у нас маршрут инвалид. При этом

инвалидам мы можем объявить маршруты внепланово, если сосед говорит, что он не знает, когда бы нас добраться. Дальше, hold down timer, это сколько маршрут в инвалиде будет сидеть, и 30 секунд это через сколько маршрут надо удалять из таблицы, если вдруг мы не получаем от него апдейты. То есть, вот такая вот штука, да, получается, что если вдруг вы хотите прокачать таймеры рипа, чтобы он почаще посылал пакеты, то примерно вот такие вот таймеры вы в инвалиде захотите поставить. рип может реагировать достаточно долго на изменения в сети. То есть, то, что вы говорите, что маршруты должны присылаться раз в 5 секунд, означает, что да, пока у вас все хорошо, маршруты будут ходить раз в 5 секунд. Но если что-то пойдет не по плану, то реакция рипа может быть довольно длительной. То есть, он может секунд 15-20 просто пытаться понять, что с сетью происходит. Поэтому,

чем меньше таймеры у рипа будут, тем, конечно, быстрее он будет реагировать, но все равно исчисляться единицами, десятками секунд. Если говорить про IPv6, то там точно такая же команда, только слов basic нет. Просто заходим в контекст роутера. IPv6 роутер RIP. Здесь не CISC, а даже CCNA, наверное, или CCNP. И указываем таймеры. И дальше те самые таймеры, которые есть. Там 5, 15, вот здесь 10, 30. Так. Мы сейчас будем с вами делать лабу и как раз на таймеры посмотрим, что в определенных ситуациях RIP будет себя вести интересным образом. Как посмотреть на то, что RIP притащил? Есть команда, ну, во-первых, showiperoad, которая показывает все риповские маршруты. Есть команда showipripdatabase, и она показывает таблицу топологии RIP. Вот это вот showipripdatabase, она как раз будет

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

они не отправляются соседям в той же самой классовой сети, но если сосед будет в другой классовой сети, то вот ему как раз этот autosummary маршрут отправляться и будет. И только они, ничего больше. Если вы выключаете new autosummary, то в таблице топологии они остаются, но при этом уже соседям автоматически не отсылаются. Если вы ручками выполняете суммаризацию командой ip summary address, то у вас появляется вот этот самый нарисованный маршрут 10.0.0.0.16. Помимо того, что в таблице маршрутизации появляется маршрут, вот у RIP в таблице топологии тоже этот маршрут будет. int summary это значит внутренняя суммаризация за счет RIP вот он показывает, что он такой маршрут породил и дальше начинает отсылать его соседям. Соседи уже не будут знать откуда этот маршрут взялся. Для них это просто нормальный маршрут, который пришел от соседа. Маршруты, которые в RIP зародились от того, что вы командой network включили RIP на интерфейсах и все connected сетки попали в анонс в таблицу

топологии показываются, что они directly connected. Вот это вот самый автосаммери сетка очередная. Показывается, что у нас есть сетка прибежавшая от соседа 172.16.1.0 доступна через соседа 192.16.8.1.2. Таймер, как давно мы получали от него апдейты, ну, окей. И маршрут, который показывается, что с ним все хорошо, у него показывается таймер, сколько времени маршрут живет в таблице. Если маршрут переходит в состояние invalid, то показывается, что он после bleeddown. То есть это как раз ситуация, когда в таблице топологии маршрут все еще есть, а в таблице маршрутизации этого маршрута уже нет. Вот те маршруты, которые находятся в карантине, они в showip.rip.database показываются, а в showip.road нет. Вы можете заказывать маршруты риповские, и в таблице маршрутизации

в принципе можно вот увидеть как раз 172.16.2.0 255.255.255.0 показывается, что маршрут как бы есть риповский, он правда в дауне. и вот next hop пользоваться этим маршрутом как бы скорее всего нельзя. Так, и что-то еще из-за... А, да, у таких маршрутов метрика будет максимально большая. 40... Простите, 4 миллиарда 294 миллиона для рипа это не характерная метрика. Очень вот такая подозрительная метрика. 4 миллиарда для рипа, у которого нормальная метрика от 1 до 15. В таблице маршрутизации этот маршрут показываться не будет. Ну, вот в таблице если мы закажем конкретный маршрут, он показывается, что да, действительно маршрут такой есть. У него вот такая вот хитрая риповская метрика. Ихлдаунтаймер у него уже запущен через 123 секунды. Соответственно, маршрут этот перестанет быть инвалидом, но он до этого скорее всего не доживет.

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

или отправили апдейт, б, сработал либо инвалид таймер, либо холдаун таймер, либо флаж таймер. И, ну, да, можно и включить командой дебага IP-RIP вообще все. Ну, или можно сказать, что нас интересуют только конкретные части рипа, то есть, например, нас интересует только изменение маршрутов в таблице. Интересные дебаги в рипе это debug-RIP-Events, debug-RIP-TRIGGER, debug-RIP-DATABASE. Ну, вот можно их все сразу включить одним скопом просто дебага IP-RIP. В нашем случае мы видим, что дебага IP-RIP показывает кусочек дебага, и, ну, здесь очевидно все достаточно, что мы отправляем апдейт, апдейт RIP второй версии, он использует мультикаст, отправляется этот апдейт в гигабит 0-0-ой интерфейс, и в этом апдейте у нас передается несколько маршрутов, то есть, вот раз и два, 10.01, 0-10, 0-2-0,

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

и, соответственно, в компании А используется своя сеть на основе, ну, например, SPF. В компании B используется своя сеть на основе RIP и вот у нас есть два роутера, через которые трафик может ходить из компании А в компанию B. Для того, чтобы организовать передачу данных между двумя сетями, вы делаете взаимную редистрибуцию, то есть трафик может ходить через эти роутеры, но для того, чтобы он ходил через эти роутеры, надо, чтобы RIP маршруты стали известны в SPF и наоборот. Так вот, проблема заключается в том, что если вдруг вы в RIP берете и начинаете рассказывать про какую-то сетку и это становится известно верхнему роутеру, давайте назовем его R1, он порождает USPF-овский маршрут, в этом USPF-е этот маршрут доходит до другого роутера, который будет называться R2 и этот роутер R2 перекладывает маршрут, который в USPF изначально был известен через редистрибуцию обратно в RIP и вот для того,

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

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

после того, как получается этот апдейт, мы на таймеры каким-то образом начинаем реагировать. Вот здесь можно хорошо заметить, что 23 часа 49 минут 19 секунд мы получили апдейт. Все хорошо, маршрут есть, обновились все таймеры и дальше спустя 3 минуты и на самом деле еще 7 секунд, то есть 23, 52, 26. Рип говорит, что что-то давно не было свежих апдейтов и маршрут становится инвалидом. То есть 49, 52. Как раз там 3 минуты разница. Мы говорим, что маршрут через 192.168.02 на сетку 172.16.2.0 стал инвалидом. Мы удаляем маршрут из таблицы маршрутизации. Точнее мы ставим метрику вот такую вот конскую. И дальше через некоторое время еще через минуту запускается флаж то есть garbage collect 172.16.2.0 удаляется из таблицы EIPA.

Обратите внимание пожалуйста на все эти таймеры. 49 минут и 52 минуты это разница как раз в 3 минуты. Это наш любимый таймер. Через сколько признаем соседа инвалидом, если он нам ничего не присылает. И 53 минуты означает, что с момента получения последнего апдейта прошло 4 минуты. Это как раз 240 секунд. То есть с момента получения апдейта мы запустили флаж таймер и если вдруг у нас свежие апдейты не приходят, то маршрут из таблицы мы удалим через 4 минуты через 240 секунд. Если приходит новый свежий апдейт, то таймеры обновляются. Обновляется инвалид таймер, обновляется hold down, ну не hold down, а флаж таймер. Ну вот, да. В нашем случае до, скажем, до срабатывания hold down таймера дело вообще не дошло. То есть мы объявили маршрут инвалидом и не успели дождаться 3 минуты с момента того, как этот самый инвалид перестал бы быть в карантине.

То есть его удалили из таблицы прямо в закарантиненном состоянии. Так, вот, что касается лабы. Давайте попробуем сделать лабу. Итак, давайте с вами настроим рип на наших роутерах так, чтобы можно было обменяться какими-то маршрутами. И сделаем следующие вещи. Для начала включаем контекст роутер рип на наших роутерах R1, R2. enable conft роутер RIP И, соответственно, мы должны будем на некоторых интерфейсах, которыми наши роутеры друг на друга смотрят, включить рип с помощью команды Network. Напоминаю, что команда Network задает фактически условия аксесс-листа, которая перебирает IP-шники на ваших интерфейсах и включает на них рип, включает connect от сетки с них в анонс и отсылает

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

да, иногда с рипом приходится работать. Да, версия 2, но в автосаморе, иначе у нас будет дурацкое поведение на разрывах классовых сетей. И включаем командой network рип на наших интерфейсах. У нас айпишники все начинаются на десятку, поэтому, к сожалению, ничего мы здесь не сможем сделать, кроме как network и указать классовый айпишник 10.0.0.0.0. То есть, здесь не предполагается, что вы будете вводить маску. В OSPF, в EGRP, там команда network задает по честному условию аксесс-листа айпишник и wildcard маску. Здесь, к сожалению, wildcard маску ввести просто нельзя. Вот видите, да, вопросик не предполагает, что вы будете вводить маску, поэтому указывается айпишник классовой сети. Вы можете попытаться с халявить, вы можете сказать 10.1.0.0, 10.2.0.0, там 10, что угодно, но на самом деле будет браться классовый айпишник, поэтому в контексте настройки у нас вот этот

вот network 10.1.0.0 по факту не сработает. Do show run section rip Видите, да, не добавилась строчка 10.1.0.0. Взялся классовый айпишник от нее и получилось, что да, классовая сетка все равно 10.0.0.0. Дальше, мы включили рип на всех интерфейсах, начинающихся на десятку, на первом роутере, дальше рядышком на R2 делаю то же самое, enable conf t, router rip версия 2 no after summary network Давайте для смеха сейчас сделаю network 10.1.1. Вот, и покажу do show run section rip Все равно взял, видите, сетку поставил 10.0.0.0.0.

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

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

связь между первым роутером и кора 2 вот я думаю что нам его наверно придушить потому что не так все красиво получается давайте придушим до линк между первым роутером и кора 2 мы возьмем из задушим так интерфейс ethernet 0 0.102 вот и заодно хорошо будет видно сейчас давайте прям девак включу дебага айпи рип сейчас будет хорошо видно что маршруты которые перестали приходить от этого соседа они будут проходить через какие-то этапы я вижу что апдейт приходят через ethernet 0012 так и тут у нас появляется какой-то inaccessible вот этот вот что эта сетка у нас перестала быть доступна так если у нас

два интерфейса а сейчас но ответа 10 15 13 0 не придет если мы спингуем почему бы не прийти ему так давайте сейчас мы дождемся прохождение трехминутного таймера с момента удаления сети и увидим что действительно там будут какие-то маршруты которые которых мы не видим так r3 еще не в рипе до r3 не в рипе и более того коры 1 и коры 2 тоже не в рипе я сейчас хочу просто увидеть спустя три минуты после того как я выключил интерфейс на роутере r1 смотрящий в сторону r2 что вот поэтому интерфейсу перестанут приходить маршруты и соответственно я дала я ожидаю что я увижу какие-то события в рипе то есть это должно произойти в примерно 16 06 полторы минуты прошло там

как о какая-то активность пошла ну активность да все маршруты которые идут они идут а это мы целая все маршруты которые идут они идут через один интерфейс вот этот вот ethernet 00 102 где у нас ресив вот они ресивы так 5 минут 11 секунд я так думаю что уже почти скоро я сейчас включил связь только между первым и вторым и единственный интерфейс на котором ходят апдейты приходят апдейты на второй роутер от первого это вот как раз связь между первым и вторым 12 вилан вела на читать очень легко то есть если у нас есть номер вела на первая цифра и вторая цифра это вот номера наших роутеров то что мы отсылаем апдейты на кучи разных субинтерфейсах вот например в 14 вилан означает только то что этот

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

next hop живой а второй ну 2 просто пропал то есть специальный таймер там не запустился так да вот по сравнению с тем что было раньше у нас немножко вывод изменился маршрутов по-прежнему всего два до двух сетей но соответственно у каждой есть только один next hop так у вас показали инвалида вот у меня не показал меня есть только вот одна строчка inaccessible инвалид таймера вот я как раз не видел ну вот не видно ладно да видимо заговорился так давайте теперь включу я рип на r1 и r2 и мы обменяемся вообще всеми маршрутами которые у нас есть он в т так кстати 7 комплект проверьте пожалуйста айпишник который вы прописали ваши и пишнике должны заканчиваться на номер вашего роутера то есть . 1 . 2 . 3 . 4 вот 10 . 101 . 7 . 1 у

вас должен быть адреса они 101 101 это центральный роутер 102 это второй центральный роутер рип но автосаммери версия 2 network 10 000 самое на кора 2 так он в т.оутер флип 2 но автосаммери network 10 00 сейчас у нас все роутеры получаются связаны между собой 1 2 центральный 1 2 наши и они должны обменяться всеми маршрутами которые у них есть то есть вот на роутере 2 моем шоу айпи роутрип показывает что маршрутов стало сильно больше в их прям очень много стало некоторые из этих маршрутов доступны через два источника некоторые через один то есть вот получается много всего до в каких случаях

будут у нас сетки доступны через два next hop а вот очевидно что вот эта вот пачка она практически вся доступна через два рак стопа это на роутере r2 сетка между первым центральным и первыми вашими роутерами то есть она равна удалена от от второго роутера и до нее можно дойти как через первый роутер так и через кора 2 вот но соответственно да показывается что у нас действительно есть два next hop а вот это два прыжка между роутерами показывается что у каждого маршрута административное расстояние 120 показывается айпишник next hop а и показывается как давно этот маршрут таблицы есть так что еще есть пассив интерфейса есть интерфейсы на которых мы не хотим отправлять апдейты в отличие от успf и jrp в которых пассив интерфейс не

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

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

транзитный трафик фильтрует а вот входящий access-лист который будет блокировать 520 порт он будет конечно рипу вредить то есть он не позволит принять апдейты через этот интерфейс далее видно хорошо да что на втором роутере большая часть маршрутов которые приходят она приходит из ethernet 002 вилана то есть от 2 кора роутера некоторые маршруты приходят с ethernet 0012 то есть от 1 1 на самом 1 примерно аналогичной ситуации должна быть только маршруты до будет приходить в основном из-под другого источника show ip road до 00101 это центральный корр 1 и 0012 это роутер r2 так давайте попробуем с вами что-нибудь поделать чтобы нам поделать так дайте сейчас на слайды

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

явно все в цех влезает в принципе мы можем забить на то что у нас тут много маршрутов покуда они в цехе всем находятся трафик идет все равно достаточно быстро но с таким количеством маршрутов просто неудобно работать и при этом по факту когда центральный роутер говорит что я могу через себя пропустить трафик до сети 100 там 10 102 10 102 0 10 102 30 и так далее он нам рассказывает про то что он знает фактически все сети то есть вот эта сеть доступны через 101 комплект вот это через 101 комплект вот это через 101 вот это через 101 и вообще практически все сети здесь через центральная роутер идут давайте мы сделаем так чтобы центральный роутер присылал дефолтный маршрут ну и соответственно чтобы можно было просто сказать что трафик до всех сетей можно пустить через центральный роутер здесь конечно было бы здорово сделать default information originate only которая есть в ipv6 а в ipv4 к сожалению я нету то есть нельзя прислать только дефолт и вот не присылать кучу всякой мелочевки но хотя бы просто default появится

для этого я на роутере r1 указываю default information originate default колота и соответственно роутер 2 и дело то же самое вы у себя пока не делайте потому что нет смысла выбрасывать дефолтный маршрут если у вас его нету так и можно кстати заодно проверить вбрасывается ли дефолт если дефолта в таблице нет оператор да бросился нет не бросился кстати к это статик ну тут а я дефолтный маршрут который нам потенциально может прислать рип сейчас он не может быть установлен в таблицу маршрутизации

потому что статик маршрут как команда ip road заданный он будет иметь административное расстояние единичку а маршрут который приходит в рипе он соответственно имеет административное расстояние 120 поэтому статический маршрут я удаляю и даю возможность динамическому маршруту рипа установиться в таблицу сейчас посмотрю получилось или нет только не так так так кстати к directly connected вот я вижу да у василия добавился а вот меня четко как то есть некие сложности с этим причем показывает directly connected что очень очень странно и должно быть directly connected маршрута статика шоу и пи раут 0000 статик интерфейс дилер один

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

первый второй комплект судя по всему прислали это ну ладно окей и 12 пусть так вы метрику на статик поменяли ладно в общем не суть важно смысл в том что до что маршрут статически приходят маршрут этот на r2 давайте на r2 посмотрим на r2 точенники кстати как нет и не был шоу айпи раут да вот здесь ри павский маршрут прибежал как интересная метрика 9 подозрительные то нет у нас подсчета до бесконечности и показывается да что маршрут по умолчанию действительно есть если мы захотим можем воспользоваться пинга 101 101 101 101 ингутся так да народ 3 2 если вдруг вы хотите посмотрите

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

какой маршрут имеет больше блин таблицы когда у нас есть трипп который приходит и говорит я хочу бросить маршрут в таблицу маршрутизации Вот если вдруг точно такой же маршрут да точно такой же сети там уже есть, они будут драться между собой, у кого будет административное расстояние меньше. Если такого маршрута не было, то новый маршрут добавляется. Ну, скажем, если не было в таблице маршрутизации уже маршрута с меньшим административным расстоянием, тогда добавится маршрут наш. А если маршрут такой был, то не добавится. После этого, когда уже есть построена таблица маршрутизации, когда все подрались административным расстоянием и померились, приходит пакет и вот пакет уже будет смотреть таблица most specific route наиболее подходящий маршрут для обработки конкретного пакета там административное состояние не проверяется вот если вдруг мы бы захотели сделать статический маршрут у которого административное расстояние

было бы хуже чем у рипа мы могли бы сделать вот что-то подобие konft ip route 0 0 0 0 0 0 0 0 0 0 0 точке 0 0 0 0 дальше указываем интерфейс dealer до dealer 1 и вот дальше можно указать вот это вот циферку эта циферка как раз будет административное расстояние здесь написано метрик не верьте политруку он лжет это административ дистанции то есть если я сейчас попытаюсь добавить такой маршрут допустим я скажу что административное расстояние у меня будет 2 то в таблице маршрутизации show ip route оператор она там уже за там уже ручками сделан до и писи пишет этот r2 покажу здесь на r2 konft добавляю ручками новый маршрут давайте в никуда сделают 00

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

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

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

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

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

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

но не включайте в анонс сетки такие-то, такие-то, такие-то. А через redistribute connected это сделать можно. Равным образом можно взять redistribute static. У вас в таблице маршрутизации есть статические маршруты, мы их берем и перекладываем в RIP. И, да, если мы захотим, мы можем сделать это, никаких проблем. Connected маршруты, я вот не помню, connected маршруты, по-моему, сразу получают метрику единицу, то есть не обязательно здесь назначать метрику. Они, несмотря на то, что в принципе все перекладываемые маршруты обычно имеют метрику 16, с connected-ами там все проще, потому что роутер точно знает, что до этой сети можно добраться за 0 прыжков. Ну вот, это единственный, пожалуй, случай, когда метрику в явном виде указывать прям совсем не обязательно. Во всех остальных случаях, если вы перекладываете не connected маршруты, статики или протокол другой динамической маршрутизации, OSPF, BGP, неважно что, вы должны будете каким-то образом метрику задать. Метрику можно либо задать в command redistribute сразу, то есть вот метрик 1. Здесь тоже можно метрик задать.

Ну, указываем метрик 1, значит маршруты статические будут вбрасываться в таблицу RIP, и метрика в них будет единичка. Либо можно будет сказать, что мы не указываем эту метрику, но нам понадобится, например, вот такая вот штука типа default metric, что все маршруты redistribuyendo в RIP вбрасываются с метрикой, которая здесь будет указана. Ну, опять же здесь единица. Ну, либо сложный самый способ, когда мы указываем redistribute и указываем roadmap. Указываем roadmap, которая будет матчить нужные маршруты. Все, что не пермитится, все, соответственно, не redistributится. Но вот если мы что-то пермитим, то мы указываем, как именно мы это пермитим, с какой метрикой. И там есть, соответственно, штука set metric. Вот если мы матчами отобрали нужный трафик, мы можем проставить метрику, которую хотим. В этом случае вы можете сказать, например, берем статические маршруты, и часть из них, которые будут с одними IP-шниками, выбрасываем с такой метрикой, а другую часть с другими IP-шниками,

выбрасываясь с сикой метрикой. Ну, или по каким-то еще более сложным условиям можно сделать. Общая идея, я думаю, что вы поняли. Указывается redistribute, указывается, откуда берем маршруты. Connected, static, OSPF, BGP, EGRP, OSPF V2, V3, который умеет работать с IP-4 маршрутами, и Sys. То есть все маршрутные источники, которые нацистские поддерживаются, вот из них и всех можно будет взять маршруты и дальше с этими маршрутами что-то делать. Вот. Соответственно, синтаксис команда redistribute будет. Указываем ключевое слово redistribute, указываем, какие маршруты берем, точнее, откуда маршруты берем. И дальше, если хотим, указываем метрику, если хотим, указываем roadmap, нужно ли пропускать не все маршруты, а только по какому-то условию, и нужно ли, соответственно, с метрикой и с метками играть каким-то образом.

Ну и если мы хотим избавиться от вот этих указаний, что такие-то маршруты берем, выбрасываем с такой метрикой, какие-то маршруты берем, выбрасываем с такой метрикой, если метрика везде одинаковая, можно указать default metric. Очень удобно. Roadmap вы можете разрешать для redistribuции не все маршруты, а только некоторые, которые удовлетворяют вашим условиям. Вот как раз здесь пример. У нас есть три маршрута статических. Они в таблице маршрутизации уже были. IP-road, команда 10011, 10022, 10033, все по 32-й маске. Они смотрят в сторону какого-то внешнего узла. То есть у нас вот здесь есть указания. Там 10, 0, 0, 1. И мы эти маршруты промечаем метками. Статические маршруты тоже могут иметь метки. И вот у нас IP-road с меткой 1, с меткой 2 и с меткой 3. И мы хотим сделать следующую штуку. Хотим сделать так, чтобы roadmap, который забирал статические маршруты в базу RIP,

он бы на эти метки ориентировался. И он бы смотрел. Соответственно, здесь первый блок roadmap. Вот у нас первый блок roadmap. Он разрешает маршруты, которые имеют метку 1, и ставит им метрику 1. Рядышком второй блок roadmap. Говорит, разрешаем маршруты с меткой 2 и ставим им метрику 2. Все остальное, то, что в явном виде мы не запермитили, все будет динаиться. Поэтому, если мы указываем в роутере RIP redistribute static, и указываем, что мы это делаем по условию, по политике static to RIP, которая берет, в свою очередь, метки за основу и говорит, пропускаем маршруты с меткой 1, даем метрику 1, пропускаем маршруты с меткой 2 и даем метрику 2, то, соответственно, маршрут с меткой 1 и меткой 2 RIP получит. Маршрут с меткой 3 RIP не получит, хотя он точно такой же статический,

но метку 3 мы не заперметили. Каково количество меток? Я думаю, что достаточно большое. Никогда не задумывался даже, на самом деле, какого размера они могут быть. Я думаю, что достаточно большое. На самом деле, в работе с метками, с этими тегами обычно нужно достаточно небольшое количество меток. Как правило, речь идет там про единицы, ну, может, десятки. Типичный пример, например, если вы провайдер, и у вас есть провайдерский роутер, PE, который смотрит на абонента. У абонента, соответственно, CPE, Customer Premises Equipment. И вот у вас есть какой-то IP-шник, здесь там, не знаю, 10, 0, 0, 2, 10, 0, 0, 1. И вы вот этому клиенту говорите, ты можешь, дорогой клиент, использовать белую сетку для работы, но она у тебя будет не connected, а вот мы тебе даем в распоряжение сетку, там, не знаю, 190,

пардон, 192, 0, 2, 0, по 24-й маске. Ты эту сетку можешь использовать у себя. И вот в этой ситуации, да, вот если вы здесь вот будете узлы назначать из этой сети, то предполагается, что вы будете отправлять такие пакеты в сторону провайдерского роутера, а он дальше будет их маршрутизировать в интернет. Но трафик, который будет возвращаться, нужно будет промаршрутизировать в сторону этой сети. И в таблице маршрутизации на PE-шке нужно будет вот этот вот статический маршрут задать. 192, 0, 2, 0, по 24-й маске. Это вот эта вот сетка. Клиентская сетка. И чтобы, например, анонсировать эти маршруты в BGP, самый простой способ как раз сказать, что у нас есть статический маршрут, который смотрит в сторону клиента, в сторону вот этой CPE-шки, и на него вешаем метку, например, 1. И дальше есть правило, что маршруты с меткой 1 мы забираем в BGP и дальше анонсируем наружу по BGP. Да, Роман посмотрел вот 4-байтовые метки,

там 4 миллиарда штук. Я думаю, что вам хватит. То есть, ну, обычно их немножко используют, потому что, да, правил, по которому вы будете эти метки читать, все равно все правила будут ручками писаться. Поэтому, да, смысла их делать в 4-х миллиардовых количествах особого нет. Так, далее. Мы видим, что после того, как мы прописали такой роутмап, мы указали, что этот роутмап будет использоваться в качестве политики забора статических маршрутов и перекладывания их в RIP. И видим, что в таблице маршрутизации роутера R2 он действительно получил такие маршруты, и они действительно получили разные метрики. У одного маршрута, который изначально имел метку 1, метрика, анонсировавшаяся соседом, была единичка, плюс один прыжок между роутерами, получилась итоговая метрика 2. А тот маршрут, который имел метку 2, соответственно, 2, он был отправлен с роутера R1, плюс один прыжок между роутерами, итоговая метрика получилась 3. Ну, да, маршруты пришли.

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

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

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

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

какие префиксы вы разрешаете принимать на определенном интерфейсе может висеть на уровне определенного интерфейса вот in gigabit 00 в нашем случае как раз вешает access лист на интерфейс если вдруг придет апдейт на этом интерфейсе то мы соответственно его про про про шерстим через это таксес лист и те маршруты которые на которой access лист сказал permit мы разрешим те маршруты на которых access лист сказал динайл мы просто выбросим и не будем их анализировать дальше вы можете сделать то-же самое с префиксом то есть можно указать префикс дальше указываете префикс лист и указывайте что этот вот анализ будет на вход можно будет дополнительно сказать что вас интересует проверка соседей на при на принадлежность п celebrities то есть если вдруг у вас есть интерфейс на этом интерфейсе к вам приходит это апдейт вы можете сказать что автор этого апдейта или по крайней мере next копы которые прописаны в этих апдейтах должны удовлетворять тоже какому-то

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

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

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

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

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

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

расстояние 180 например чтобы проигрывать и жарби который внешний маршрут и будет притаскивать вот по такому критерию нам соответственно да будет некоторые маршруты не все только necesit а чтобы сделать так чтобы у них административное расстояние было меньше и тогда в дополнение к команде distance и дальше циферка вы должны будете указать какие next копы будут для маршрутов вот это вот условия access листа а цель для gateway и вот здесь вы указываете название или номер access листа на цель префиксы как не знаю roads то есть вы указываете сначала условия access листа который отбирает не соседи шлюзы как который присылает вам маршруты и затем в отдельное условие отдельный access лист указываете какие префиксы вы хотите разрешить так напомните 150

административное расстояние единичка эта метрика количество прыжков между роутерами вот если вы такое сделаете то маршруты которые вот например здесь у нас есть таблица маршрутизации видно что у нас есть маршрут 10 0 1 0 по 24 маски доступны через 10 111 и 10 0 2 0 по 24 маски доступны через 10 122 и вот мы говорим что нас интересуют маршруты которые приходят от соседей ну в кавычках соседи риповских у которых айпишники попадает в диапазон 10 120 по перевернутой 24 маски это wildcard маска фактически да и соответственно мы указываем условиях с листа который отбирает нужный нам нужные нам адреса вот в принципе довольно часто можно встретить синтаксис этой команды следующий distance дальше указываем административное расстояние там не знаю 190 180 неважно дальше указываем 8 нулевку

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

прислал маршрут который попадает под access лист у него айпишник не тот он не попадает под условия 10 120 по 24 маски поэтому административное расстояние у него осталось ну 150 до вот этой команды 180 к нему не применилось так сейчас попробуем сделать все то что с вами мы прошли в лабораторном сценарии я предлагаю делать примерно в следующем порядке сначала мы зародим некоторое количество маршрутов которые порождаются не рипом то есть это будут либо статики либо connected и ну я думаю что интереснее как раз всего будет взять час connected после чего анонсировать только не анонсировать а redistribute только некоторые маршруты в рип так чтобы у нас сработало некое правило то самая политика который мы напишем с помощью род папа и затем мы попытаемся анонсировать

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

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

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

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

из армит 0 дробь 0 . 12 что не так интерфейс раньше зерна от 0101 что мы , не нравится видимо он слабаками так не может ну ладно так ipv6 enable ipv6 rip cc enable я постарался не забыть как у меня называется экземпляр рипа он мне называется ccnp вот на 101 интерфейсе я включил ccnp этот интерфейс который с первого смотрят на центральный 1 дальше то же самое на интерфейсе который смотрит на второй роутер ipv6 enable ipv6 rip ccnp

enable у меня сейчас есть два интерфейса на которых рип работает на которых он отсылает анонса и нет ни одного живого айпишника нет ни одного адреса который собственно говоря можно было бы отсылать но ничего страшного для рипа это не требуется то же самое делаю на втором и был контент интерфейс рейндж не работает я 0 дробь 0 . 6 либл пардон эти 6 и в них раз раутер на сначала запустить экземпляр рипа айпи в 6 раутер рип сиенки уже настройки интерфейса лесть на пивишь есть липп и серпи либо и так это у нас 102 только интерфейс должен быть и был репси сиен пили года это на роутере 2

сторону коры 2 я включаю маршрутизацию ipv6 я включаю обработка пиви шестых пакетов являю появляется link local адрес и включая этот графе из в оси 7 пишет в экземпляр рипа и то же сам интерфейс единор ноль . 12 и 6 иный был и пиви 6 репси 7 пивы и был вроде бы все хорошо все готово теперь со стороны со стороны центральных двух роутеров нужно бы сделать ответные действия я сделаю это немножко попозже я предлагаю сейчас перед тем как подключать центральный роутер и убедиться что в репе у нас будут анонсироваться некоторые лупбек если мы включим в 6 рип мы потом эти лупбеки и зри по уберем пока что давайте их добавим интерфейс лупбек 0 указываем ipv6 адрес

нам нужен будет адрес который начинается на fd а дальше давайте сделаем номер комплекта это будет fd 01 fd 02 fd чего-то там но в моем случае в до 15 два двоеточия и номер роутера вот второй роутер fd 15 комплект второй роутер слышь 128 маска и для того чтобы показать что маршрутизации у нас действительно будет работать я временно включаю этот интерфейс в рип тоже ну и аналогичный лупбек делаю на роутере r1 интерфейс лупбек 0 ipv6 в д 15 2 2 . и добавляю его в риф вот сейчас у меня на роутер и должны обменяться своими лупбеками они должны показаться в таблице маршрутизации я теоретически должен с одного интерфейса одного роутера пингать другой роутер по вот этому лупбеку шоу ipv6 раут вот это мой собственный

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

действительно маршрут который прибежал в рип вот он fd 15 2 2.2 по 128 маски метрика 2 с маршрутом все в порядке он соответственно был получен не так давно и когда мы получили в последний раз апдейт содержащий этот маршрут перезапустился инвалид таймер и показывается да что вот этот инвалид таймер истечет через 164 секунды но каждый 30 секунд приходит новый апдейт каждый раз мы соответственно инвалидный таймер равны с ним и flash таймер перезапускаем если вдруг сейчас со стороны роутера r2 я скажу что этот этот лупбек перестает быть в рипе соответственно на роутере r1 здесь все равно этот маршрут остался то есть то что до той сети мы больше не знаем как добраться не означает что из

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

инвалид таймер маршрут перейдет состояние hold down мы если вдруг нам никто три минуты не присылал апдейты что до определенной сетки можно будет добраться мы предполагаем что он не хотел нам присылать такие маршруты потому что считал нас видимо как бы более близким к сети назначения рип не присылает маршруты тем соответственно кто кого он сам считает next hop am если он нас не считал next hop am то он нам бы присылал маршрут если был бы обходной маневр какой-то как добраться до удаленной сети рип про это маршрутов про этот маршрут видел бы анонсы и он соответственно конкретного соседа добавил бы в таблицу топологии может быть он не выбрал бы на к топам но в таблице топологии он бы был а вот если за три минуты нам никто не присылает никаких новых анонсов и у нас единственные неповторимые next hop перестает быть доступен то мы соответственно объявляем карантин

мы вешаем статус hold down на маршрут и мы некоторое время не отсылаем никому указаний что мы знаем как добраться до сети напротив моцелая метрику недоступный маршрут и соответственно мы не принимаем никакие маршруты от соседей до этой сети 4 3 2 1 0 протух метров маршрут протух мы его в таблице маршрутизации не в таблице либо повесили с метрикой 16 мы его не поставили в таблицу маршрутизации мы его оттуда удалили до того у нас показывалось что маршрут нормально установлен в таблицу маршрутизации сейчас он показывается что он есть только в понимании самого роутера рип он не установлен в таблицу маршрутизации и в шоу операут его уже больше нету он там есть правда и вот туда можно выцепить если очень сильно захотеть шоу операут fd 0 rd 15 2 2 . 2 по 128 маски если очень попросить и вот туда можно

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

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

соответственно на 2 нам никто не генерирует события вида там не знаю отправляем этот маршрут 16 метрикой и такое апдейт не принимается роутером r1 поэтому r1 действительно ждет по-честному считает что вот r2 просто забыл ему прислать определенные маршруты но через три минуты он понимает что нет не забыл это он умышленно сделал перестал присылать поэтому маршрут из таблицы маршрутизации уходят еще через некоторое время из таблицы топологии маршрут удаляется так можно ли глянуть шоуром секцию риф конечно вот это на интерфейсах у нас висит это рип второй версии для пиви 4 это рип 3 рип нг для пиви 6 то есть конфигурация примитивно простая это на роутере r1 на роутере r2 все то же самое только на лупбеки нету ай пиви 6 рип си сиен пины и был я его оттуда удалил я сейчас отсюда удалю интерфейс лупбек 0 и

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

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

чтобы я вбивал все вот это вот руками на все комплекты на 101 102 интерфейсах я включил рип по-хорошему надо бы еще и r1 r2 тоже связать между собой так ну я думаю надо ли это делать дохнар надо из онет 0 дробь и ушеда он в 6 и нибудь и пиви 6 рип сисин и и не был так но шат даун и на перешать все интерфейсы у нас включены везде рип включен и по идее сейчас на наших

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

анонсировать по некоторому правилу например мы можем прописать road map который будет говорить что некоторые connect от сетки мы берем а некоторые конец от сетки мы не берем у нас уже есть лупбеки которые мы хотим анонсировать и это лупбеки как раз вот в нашем случае fd номер комплекта 2 2.1 2 2.2 давайте сделаем еще один лупбек и скажем что у нас есть или даже на этом же лупбеки еще один айпишник повесим благово пиве 6 можно легко повесить много айпишников интерфейс лупбек 0 айпи 6 адрес помимо того что там уже сейчас висит я еще один адрес повешу fd номер комплекта двоеточие допустим какой-нибудь кривой адрес сделаю 128 вот этот айпишник он так что не так а 2 . потерял вот это вот айпишник я повесил и если

я сейчас включу рип на этом интерфейсе обратно у меня будут анонсироваться все айпишники все connected сетки с этих интерфейсов включая вот эту вот кривую которая только что сделал на другом роутере я тоже самое сейчас сделаю либо интерфейс лупбек 0 айпи 6 адрес в д-д-д-15 2 2 . ну какой-то вот кривой адрес я не хочу анонсировать эти кривые адреса я хочу анонсировать только те адреса которые начинаются на fd в моем случае 15 и дальше в седьмом акте у них будет 0 вот я не хочу анонсировать вот это вот кривое хочу анонсировать только то что правильно самым простым способом сделать это мне видится как раз использовать road map и этот road map будет в качестве основа для матча использовать префиксы сты у нас одна лапа лабана free на префикс листы не получилось потому что там их использовал

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

нужно будет указать что 112 сетка сейчас правильно я посчитал 128 минус 16 112 вот сетка fd 15 2 2 112 это указание на то что пермититься будут только те и печники у которых в первых семи актетах fd 15 и куча нулей в последнем актете может быть все что угодно последний актет это вот это вот нет я неправильно посчитал или правильно неправильно не все правильно вот это вот 8 бит вот это еще 8 бит давнин с математикой чё тоже под вечер плохо вот это вот один байт и вот это вот еще один байт каждый байт 8 бит соответственно 16 бит в каждом из вот этих вот блоков 112 бит в первых семи блоках 16 бит в последнем блоке всего

128 бит все правильно вот такой вот простенький префикс лист который у меня есть он будет разрешать ну говорить да на на маршруты и пишнике которых будут fd 15 2 2 . а сетка будет 112 я только что вам продемонстрировал наглядный пример того что при работе с префикс листами очень легко облажаться если вы сейчас нажали enter так же как и я то вы облажались вместе со мной дело в том что вот этот префикс лист будет мать чить префиксы именно по и пишнику именно по маске и соответственно будет сравнивать что айпишник ровно вот такой вот а маска ровно вот такая в connect от сетках у нас немножко другое нас вот такой вот айпишник вот такая маска поэтому чтобы у нас все было хорошо надо к сожалению удалить эту строчку она плохая и добавить слово

л е или га я в нашем случае га я 112 так что-то не получилось что-то что-то не получилось га е 112 так ну да он требует нет не строгого он требует строго и строго больше га е чем длина префикса ну окей сделаем л е или 128 то есть любые префиксы которые будут больше чем 112 но меньше чем 128 нас устроит вот и вот такая вот штука будет говорить да будет говорить да на префиксы у которых в первых семи актетах

ровно и куча нулей если вот мы посмотрим вот на этот вот префикс который у нас будет висеть у него соответственно ситуация другая у него в первых семи актетах уже не вот эта вот штука там что-то иное так теперь исходя из этого префикс листа нам нужно будет сделать road map и этот рот на будет довольно простой road map rip и не говорим permit он и так предполагается мы не говорим соответственно мы не говорим номер последовательности он и так предполагается мы говорим матч айпи в 6 да будет указать что нас интересует префикс лист и мы разрешаем такие маршруты ну давайте их мы с метрикой с каком хитрый сделаем сет все что road map не разрешил он на все скажет динай все на что road map сказал динай не будет

редистрибучена в рип при указании команды redistribute поэтому все у нас готовый road map у нас готовый префикс лист мы можем пойти в настройку роутера рип рип и 6 роутер рип и указать команду redistribute и маршруты которые мы хотим переложить в рип будут connected но соответственно мы хотим не все маршрута перекладывать а только некоторые которые удовлетворяют нашим условия условия прописаны в политике политика задается road map он она же будет задавать и метрику азовым redistribute connected указываем road map rip и в принципе этого достаточно для того чтобы у нас в рипе появились некоторые маршруты айпи в 6 road показывать что у нас есть маршруты прибежавшие по рипу

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

сделал road map out of так или 6 роутер и вот так тоже соответственно сейчас у меня будут анонсироваться лупбеки только хорошие только те которые начинаются на fd15 и 60 не анонсируется connect от сетки которые кривые типа вот этой вот проверьте пожалуйста что у вас ничего лишнего от меня не видно а я сейчас проверю что я сам лишнего ничего не видит вот да все только хорошие лупбеки приходят 3 4 5 11 ну 15 мой собственный от 5

приходит только 2 лупбек почему-то подозрительно от 3 только 1 4 тоже только 1 нет пардон до 5 от 5 приходит оба лупбека вот они 5 оба от остальных нам напротив только один простите так да вот идеальный вариант при котором у нас будут получены лупбеки все еще одна штука которую хочется сделать это сократить количество записей в таблице маршрутизации у нас сейчас в настройке роутера сделано все так что мы отсылаем вот те маршруты которые у нас есть таблица при этом ничего своего мы не придумываем шоу ipv6 здесь показывает что есть достаточно немаленькое количество записей пусть не так много как хотелось бы но тем не менее их немало и вместо всего вот этого множество маршрутов хочется иметь все-таки маршрутов мало во первых хочется чтобы на на центральный роутер нагрузка в части количество

маршрутов было поменьше а во вторых хочется чтобы наши роутеры по факту не получали вот указание что до такой сети можно добраться через тогда другой сети можно добраться через тогда 3 через так и до всех остальных тоже через также поэтому здесь очень сильно хочется взять и включить суммирование маршрутов она будет включаться на уровне интерфейса поэтому нам нужно будет сказать на уровне интерфейса что на центральные роутеры мы не отсылаем сетки вот эти вот по 128 маски fd в моем случае 15 2 2.1 и в до 15 2 2.2 наружу мы хотим отсылать только сетки суммированные и суммироваться они будут как раз до fd 15 2 2 . по 16 маски то есть мы говорим что все что начинается на fd 15 это все наше присылайте нам мы тут разберемся и нам это нужно будет включить на обоих интерфейсах на роутере r1 который смотрит сторону 1 кора и на роутере r2 который смотрит в сторону 2 enable контент интерфейс е 0 дробь 0.101 это

первый роутер и на интерфейсе в сторону коры 1 мы включаем суммирование сетей айпи ве 6 самаре адрес указываем да неужели этого я не ожидал ну ка если так на айпи 6 рип самаре адрес до суммаре адрес указываем что да что мы хотим отсылать не мелкие сетки по 128 маски а fd 15 2 2 . по 16 маски и аналогичную конфигурацию мы делаем на втором роутере на r2 если не сделать на r2 то r2 будет отсылать мелочь когда ради на целая всю большую крупную сетку он не отсылает мелочь r2 будет отсылать мелочь и

трафик до сетей в таблице маршрутизации остальных роутеров которые будут получать и крупняк через r1 и мелочь через r2 он будет матчаться по при по признаку соответственно лонг из префикс матч он будет выбирать маршрут с наибольшей маской и маршрут с наиболее с наибольшей маской будет присылать только роутер 2 поэтому если вы в одном месте сделаете суммирования в другом нет весь трафик по факту пойдет через r2 чтобы этого не происходило на обоих выходах из нашей автономной системы мы должны суммировать сетки одинаково поэтому мы идем к он в т интерфейсе 0 дробь 0 . 102 и здесь указываем что суммирование точно такое же будет происходить мы не посылаем мелкие сетки мы посылаем только крупные сетки и тогда на роутере r1 и r2 вместо двух мелких сеток у нас будет посылаться одна большая крупная просто из двух мест в результате нагрузка на роутер 1 r2 спадет по крайней мере в части количества апдейтов в части

количество маршрутов которые к ним приходят ну и и будет попроще сейчас на r1 шоу и пиве 6 road trip мелкие сетки еще пока не протухли они все еще есть таблицы но они скоро протухнут а вот вот соответственно крупная сетка в 2 15 по 16 маски ну и вот вижу 5 роутер тоже прислал уже суммарку 4 роутер прислал суммарку 3 роутер прислал суммарку 11 прислал суммарку вроде больше никого нет вот вот такая вот штука если мы сейчас немножко подождем она позволит нам вместо куча мелочевки посылать один большой сумма на маршру для того чтобы он посылался надо чтобы хотя бы одна мелочевочка в него попало то есть если мы делаем вот такой суммарный маршрут и вообще ни одного компонента такого суммарного

маршрута нету то ничего не анонсируется и если мне память не изменяет для того чтобы анонсировать маршрут ну да нам достаточно хотя бы одного маршрута если маршрутов таких будет несколько возникает вопрос какую метрику выберет cisco для того чтобы отправить суммарный маршрут то есть нам же для каждого маршрута нужно будет какая-то метрика и вот сейчас я как раз на 1 покажу что вот у нас есть отдельно мелочевка которая посылалась с метрикой 6 и отдельно посылался вот такой же маршрут но здесь выбрать было достаточно легко а вот в ситуации когда у нас был вот прекрасный пример у нас был компонент fd 15 2 2.1 по 128 маски с 6 метрикой fd 15 2 2.2 с метрик который у нас получалось до 7 и соответственно каждый из них по факту превратился вот в такую вот штуку в метрику слышать на самом деле вариант дойти за 7 копеек был известен из двух мест то

есть нам присылал эту сетку вот эту вот и роутер наш первый и роутер коры r2 вот коры r2 то что присылал там заведомо как бы плохо было а вот то что r1 роутер присылал с метрикой 7 это означает что у него в таблице маршрутизации вот эта вот сетка fd 15 2 2.2 была дороже чем своя родная и соответственно когда он делал суммарный маршрут он выбрал из двух вариантов за 6 копеек посылать или за 7 копеек посылать сказал я буду посылать маршрут с минимальной метрикой то который стоит 6 копеек разные протоколы даже в цисках будут вести себя по-разному в части выбора метрики для суммарного маршрута роутера разных производителей тем более будут себя вести по-разному но вот для рипа по крайней мере для пиве 6 рипа актуально именно то что если вдруг есть несколько компонентов метрики компонентов суммарного маршрута из которых мы делаем одну большую са марку то выбирается наименьшая метрика для анонса если

очень захотеть можно сделать опять же кастомную метрику можно будет сказать что мы сделаем суммарный маршрут и это суммарного маршрута метрика должна быть какая-то вот иная если нам очень сильно захочется мы это сделать можем но мы вот нет этого не сделали и он по умолчанию выбрал метрику наименьшую я думаю что можно проверить сейчас вот как раз всякая мелочевка должна пропасть и видно да что 3 комплект прислал только крупную сетку 4 комплект прислал только крупную сетку 5 комплект прислал прислал два варианта причем насколько я вижу да они оба от 1 роутера и хороший и плохой маршрут то есть у нас здесь что-то пошло не по плану 11 прислал суммарку 12 прислал только хороший первый лук до окна без суммарки 15 минут и я прислал суммарку так вот такая вот штука то есть да если вы присылаете суммарку то

вы делаете виртуальный маршрут вы не можете прислать маршрут на то чего у вас нет таблица поэтому если на роутере r1 сейчас я покажу шоу до пиве 6 road здесь будет маршрут на нулевой интерфейс где она есть та 16 сетка вот она нет ни на fd15 а он здесь тоже не показывает похоже то есть маршрут который он сам придумал здесь его не видно в таблице маршрутизации хотя на самом деле он должен быть и это маршрут на интерфейс 00 вот если вы пили 4 сделать циска прямо показывает в этих таблицам маршрутизации посмотрим в таблица репа шоу ай пиве 6 реп дата бейс да там все и здесь тоже не видно

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

суммируются на сегодня пожалуй все спасибо за внимание пока пока