Policy Based Routing

Продолжение следует... Продолжение следует...

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

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

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

два канала одновременно использовать чтобы часть трафика пустить в один канал часть другой что будет необходимо сделать если у нас есть цисков которые мы хотим запустить полисе base routing во первых нам понадобится road map road map а мы создаем политику эта политика будет указывать какие пакеты куда мы направляем то есть у нас есть блоки в road map и в каждом блоке мы говорим какие пакеты матчем и куда мы их направляем с помощью команды set соответственно есть несколько вариантов того чего можно матчить можно начать и пищники можно матчить протокол то есть содержимое если мы видим я пишу не источника такой-то мы направляем трафик такой если мы видим там содержимое вложения там тисепишны с таким то там с таким то протоколом таким прям портал это мы направляем trafi к сякта опять же все это можно Можно матчить, матчи можно сочетать друг с другом, можно матчиться аксесс-листами,

можно матчиться хитрой штукой, которая называется N-Bar, Network-Based Application Recognition, которая будет анализировать трафик и понимать, что за протокол используется не на основании того, какие порты задействованы, а на основании именно содержимого, на основании мяса пакета. То есть можно будет взять, пропустить через Cisco пакет, сказать, посмотри внимательно, и не обращая внимания, что там TCP-порт 80, посмотри, пожалуйста, внимательно, что там внутри лежит. И она может, например, сказать, да, вижу 80-й порт, но я чувствую, что это VPN, это не нормальный HTTP. И вот она, соответственно, проклассифицирует этот трафик как VPN. И дальше, в зависимости от этого классификатора, вы можете сделать уже какие-то действия. То есть Cisco такие штуки делать могут. Ну и матчами вы указываете, что вы хотите матчить, и после этого сетами вы указываете, на какой IP-шник вы должны быть это все дело послать. Сетов можно сделать 5 штук. То есть вы должны сделать один, конечно, сет, но выбрать этот один сет вы можете из 5 вариантов.

Первый вариант самый простой. Вы указываете set IP next hop, и дальше IP-шник того узла, который у вас будет next hop. То есть самый простой вариант у нас есть роутер, у него есть два канала в интернет. И вот он говорит, здесь у нас узел там с IP-шником 10.1.1.1. Здесь у нас узел с 10.2.2.2. И вот мы матчами отобрали нужный трафик и говорим set IP next hop и вот тот IP-шник, который у нас используется. Set IP next hop имеет одну особенность. Вы обязаны указывать тот IP-шник, который у вас в connected сразу. То есть если этот адрес у вас просто известен в таблице маршрутизации, но он не connected, то тогда эта команда срабатывать не будет, и у вас этот блок роутмапа просто не сработает. Если хочется задать адрес, который в таблице маршрутизации есть, резолвится, но он не connected, надо добавить слово recursive. Не то чтобы это часто было нужно, но иногда бывает полезно. То есть, например, вы можете сказать, что мы хотим направлять трафик туда же,

куда смотрит определенный IP-шник. В некоторых случаях это может быть интересно, если вы делаете какие-то сложные правила. Если в дальнейшем connected отваливается, ну просто блок перестает работать. То есть вы, если хотите, вы можете сделать два блока, сказать, один блок работает и, соответственно, отправляет трафик у одного соседа. Если этот сосед отвалился, блок не срабатывает, и тогда управление переходит к другому блоку, и уже другой блок отправляет трафик другому соседу. Ну то есть, на самом деле, в большинстве ситуаций достаточно вот этой вот конструкции, она вполне нормальная. Есть хитрая штука, которая называется setIP-default-next-hop. Вот это вот. И это действительно интересная вещь. Давайте я про нее подробно расскажу. Когда у вас есть policy-based routing, у вас приходит пакет на ваш роутер. Этот пакет приходит на интерфейс, на котором вы вешаете policy-based routing. И, соответственно, он, минуя таблицу маршрутизации, отправляется по тому next-hop, который вы policy-based routing указали.

Если у вас policy-based routing, PBR-овская вот эта вот политика, которую вы повесили, не указывает никакой IP-next-hop, то трафик отправляется на таблицу маршрутизации. То есть сначала срабатывает PBR. Если PBR дает нам четкое указание, куда трафик направлять, мы его направляем туда. Если PBR не указывает, куда направлять трафик, то трафик отправляется по таблице так, как будто бы мы просто ничего не делали. Знаете, здесь забавная особенность заключается в том, что если мы в policy-based routing пишем роутмапы, то там мы пишем permit и deny в каждом блоке. И вот permit означает, что мы говорим, как обработать этот трафик. Мы можем указать там, например, сетом next-hop. А если мы пишем deny, то на самом деле ничего не происходит. То есть мы просто говорим, окей, policy-based routing не хочет обрабатывать этот пакет. Тогда он будет обрабатываться по таблице. То есть сначала PBR, а потом таблица маршрутизации.

Но есть небольшая особенность. Особенность заключается в том, что у вас есть такая штука setIP-default-next-hop. Трафик приходит на ваш роутер через интерфейс, на котором вы повесили PBR. Дальше он сразу отправляется на таблицу маршрутизации. Если таблица маршрутизации говорит, мы знаем специфичный маршрут до этой сети. Вот не 8.0, не default, а вот именно конкретный маршрут, который известен, куда направлять трафик вообще. То мы обрабатываем этот трафик по таблице маршрутизации. А вот если у нас маршрут попал 8.0, то тогда вот только в этот момент запускаем движок PBR. Очень полезная вещь в ситуации как раз тогда, когда вам нужно обрабатывать трафик интернета. Чтобы не надо было policy-based роутингом вычленять правила вида, а наша внутренняя сетка вот так обрабатывается, а наша внешняя сетка вот так обрабатывается. Вы указываете setIP-default-next-hop и говорите, трафик, который специфичный, который мы знаем, как обрабатывать, потому что нам его OSPF протащил или что-то еще, обрабатывается по таблице.

Трафик, который попадает под дефолт, обрабатывается по policy-based роутингу. То есть сначала PBR, простите, сначала таблица маршрутизации, потом policy-based роутинг и потом дефолт. Есть разновидности этих пунктов, которые называются setInterface, setDefaultInterface. Если у вас connected интерфейс, в котором IP-шника connected нету, например, туннель или VPN какой-то, или point-to-point протокол, PPP, PPP-OE, неважно что, вот в этом случае вы можете сказать setInterface вместо setIP-next-hop. И тогда трафик уйдет внутрь этого интерфейса, предполагая, что канальный адрес в этом интерфейсе не нужен. Точно так же есть setDefaultInterface. Сначала по таблице, потом, если там специфичный маршрут есть, отправляем сразу. Если там только дефолт под конкретный пакет попал, то тогда запускаем вот setInterface. И вместо дефолта отправляем куда надо.

Так. Не поняли про setIP-default-next-hop. Окей, давайте. Какой-нибудь пример, который был бы приближен к жизни. Мы хотим сделать так, чтобы у нас на наш роутер приходили пакеты из внутренних сетей. Вот здесь у нас есть сетки 10.0.1.0. 10.0.2.0. 10.0.3.0. 10.0.4.0. И кроме того, у нас есть два выхода в интернет. ESP1 и ESP2. У нас есть два провайдера. Оба провайдера присылают нам дефолтные маршруты. И мы в таблицу маршрутизации можем поставить только один. Мы не можем поставить сразу оба дефолта и балансировать трафик между ними. Потому что трафик в интернет мы выпускаем, ну, допустим, только с NAT. Поэтому мы говорим, трафик весь должен ходить либо через одного провайдера, либо через другого, если мы используем классическую маршрутизацию.

Но если мы хотим использовать оба канала одновременно, то мы можем сказать, например, что вот эти два товарища 10.0.1.0.10.0.2.0 ходят через провайдер номер один. А вот эти вот в интернет ходят через провайдера номер два. Мы тем самым утилизируем сразу оба канала. Но для того, чтобы это нам сделать, нам потребуется полиси-бейст роутинг. Нам нужно будет сказать, что трафик матчим мы по IP-шникам. Если мы видим IP-шник источника, и он попадает в сетку 10.0.1.0.10.0.2.0, мы ему set IP next hop должны будем сказать вот этот вот, ESP1. А если мы видим IP-шники вот эти вот, это уже другой блок будет, то мы, соответственно, set IP next hop вот этот вот. Но здесь возникает проблема. Если мы используем просто set IP next hop, то проблема будет вот какая. Трафик между 10.0.1.0 и 10.0.3.0 ходить не будет. Потому что если мы просто матчим, говорим, трафик мы с матчем по IP-шнику источника, весь трафик вот этих IP-шников будет уходить в сторону ESP1. То есть вот этот вот поток трафика, он просто как бы полиси-бейстротингом простым предусмотрен не будет.

А если мы будем предусматривать такой поток трафика, то нам нужно будет сделать ужасающе сложный полиси, ужасающе сложный роутмап, который будет перебирать все возможные варианты. Если 10.0.1.0 идет сюда, сюда или сюда, то мы динаем. А если куда-то еще, то мы permitting, мы set IP next hop делаем. То же самое с вот этой сеткой, и с вот этой сеткой, и с вот этой сеткой. Вместо того, чтобы писать кучу возможных переборов вида, если пакет идет отсюда, сюда, то мы делаем то, если отсюда, туда мы делаем это, можно просто сказать set IP default next hop. Мы говорим, трафик приходит через интерфейс 10.0.1.0. Окей. Мы сначала направляем трафик, этот пакет, на движок маршрутизации. Он по таблице маршрутизации ищет лучший маршрут. Если лучший маршрут не дефолт, он обрабатывает этот пакет. Если лучший маршрут дефолт, то он направляется на полисе base routing. И в этой ситуации мы просто говорим, окей, весь трафик между вот этими нашими сетками будет ходить нормально,

потому что эти все сетки коннекта таблицы маршрутизации, это специфичные маршруты, не дефолтные, и они будут срабатывать перед PBR. Например, если же трафик идет в интернет, он попадает под какой-то из дефолтов от ASP1 или ASP2, то, соответственно, в этой ситуации у нас срабатывает PBR. И мы говорим, если API-шники вот эти, направляем наверх. Если API-шники вот эти, направляем вниз. То есть здесь полисе base routing будет срабатывать не перед движок маршрутизации, а после движка маршрутизации, но только в том случае, если движок маршрутизации сказал, что трафик надо направить по дефолтному маршруту. Вот. Очень удобная вещь. Появилась не сразу, но в 15-х иусах она есть. Если использовать VRF в каждом по дефолту. Можно сделать через VRF, просто это будет жуткая, опять же, конструкция с утечкой маршрутов. Ну, в общем, это будет сложно. А вот через setIbDefaultNextHub это очень просто. Буквально одна команда.

То есть очень простой механизм, но в то же время, да, очень эффективный. Ну и, соответственно, setInterface, setDefaultInterface то же самое. Мы просто не IP-шник назначаем, а выходной интерфейс, который должен иметь тип point-to-point, в котором не нужно резолвить канальные адреса. Если у нас policy-based routing не сказал permit и не задал IP NextHub Interface, либо IP NextHub, либо IP Interface, то, соответственно, пакеты отправляются по обычной таблице маршрутизации. Вот. Что нам нужно будет сделать? Нужно будет написать такой роутмап. Это шаг номер один. Дальше. Надо будет повесить этот роутмап на анализ проходящих пакетов. У CISC есть два варианта, где взять пакеты, которые могут подвергнуться маршрутизации policy-based routing. Первое. Это транзитные пакеты. Транзитные пакеты обладают особенностью. Они через какой-нибудь интерфейс обязательно войдут.

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

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

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

Кондакт от IP-шником, подчеркну. То есть здесь у нас, например, 2.2.2.1 будет IP-шник, чтобы вот эта штука была кондакт. И, соответственно, мы пишем роутмап. Говорим, что у нас есть роутмап, который называется PBR-RM. PBR от слова policy-based routing, RM, потому что роутмап. И в этом роутмапе мы указываем, что мы пермитим определенный трафик, который мы отбираем, match IP-адрес. Мы проверяем адресную информацию с помощью аксесс-листа. И аксесс-лист у нас будет называться laptop. Ну, это просто обычно именованный аксесс-лист. Как-то вот так вот IP, аксесс-лист. Там, не знаю, стандарт. Стандарт и laptop. Здесь что-то типа permit. Какой у нас там IP-шник был бы? Не знаю, 192.168.1.1.

192.168.1.1. Ну, вы поняли, да? Просто обычный аксесс-лист, ничего такого. И, соответственно, в match IP-адрес мы указываем название аксесс-листа. Вот это вот, это аксесс-лист. И для трафика, который попал под этот аксесс-лист, мы немножко модифицируем его свойства и указываем set IP nexthop.2222. То есть трафик, который прошел через интерфейс, на котором висит такой policy-based roadmap, будет анализироваться аксесс-листом. Если аксесс-лист срабатывает, то есть он говорит permit на IP-шник, источник в этом пакете, то мы направляем этот трафик на nexthop.2222. Если там будет какой-то другой трафик, который не матчится этим аксесс-листом, то мы его не permitим, выносится неявный вердикт deny. Как следствие, трафик, который policy-based routing заденил, он не отбрасывается, он направляется на движок маршрутизации. И, соответственно, на движке маршрутизации трафик отправляется уже на IP-шник 1.1.1.1.1.

Понятное дело, здесь можно было бы покрасивее сделать, можно было бы set IP default nexthop сказать, можно было бы там что-то еще сделать. То есть вот эта штука не проверяет работоспособность nexthop.2222. Если он сдохнет, то трафик все равно будет на него пытаться посылаться. Ну, если получится, если не получится, если он прямо из таблицы маршрутизации уйдет, то, конечно, просто roadmap не сработает. А так вот, если вдруг этот IP-шник перестанет быть доступен, но интерфейс все равно будет живой. Например, если у нас здесь какой-нибудь медиаконвертер стоит, то вот в такой ситуации, да, у нас получится, что интерфейс живой, маршрут в таблице есть, connected, а IP-шника живого, соседского нет. И трафик на него все равно направляется. Ну и да, он там погибает. Вот. Такой вот примитивно простенький roadmap. То есть все, что мы захотели, мы в явном виде отобрали, и в явном виде ему перебили IP-шники, перебили nexthop. Всему остальному мы не перебивали ничего, мы его не пермитили, поэтому оно направляется на движок маршрутизации сразу.

И поэтому трафик лаптопа посылается на второго провайдера, все остальное посылается на первого провайдера. И после того, как мы такой policy map сделали, road map, простите, нужно его где-то использовать, потому что сам по себе road map – это просто классификатор. Мы на вход ему что-нибудь даем, он говорит да или нет, и если да, то как. Но мы на вход ему пока ничего не даем. Вот нужно будет сказать каким-то образом, как именно этот road map должен срабатывать, в какой конкретный момент. Если мы хотим обрабатывать локальный трафик, то есть трафик самой циски, например, там пинги, которые мы отправляем с самого роутера, туннели, которые мы строим с самого роутера или что-то еще, то мы должны будем указать команду IP-local-policy-roadmap и дальше вот название road map. Если мы хотим повесить этот road map на интерфейс, чтобы транзитные пакеты обрабатывать, то очень похожая команда IP-policy-roadmap-pbr-rm-настройки интерфейса. Так.

Вот пример, да, что мы такое сделали. И у нас есть некий компьютер. Компьютер, судя по всему, с Windows. И мы пытаемся посмотреть, куда уходят пакеты до IP-шника 8.8.8.8. И вот первый IP-шник – это IP-шник самого роутера. А дальше трафик уходит через 2.2.2.2 куда-то на восьмерке. Вот. В то же время, если мы с сервера попытаемся выполнить ту же самую команду, trace-road-восьмерок, то точно так же пакеты доходят до роутера, но дальше отправляются через провайдер 1. Ну и уже уходят на восьмерки. Если вам интересно, есть команда debug. Как всегда, с debug надо быть очень осторожным, потому что debug могут легко повесить вашу железку. Особенно, если у вас много трафика проходит через ваш роутер, ну, соответственно, много трафика может попасть под policy map. И, как следствие, если вы включаете debug IP-policy, у вас много-много информации будет выводиться в журнал и, как следствие, на консоль.

Поэтому, если у вас точно известно, что трафика мало, то вы можете включить debug IP-policy. Если у вас это боевая железка и на ней висит policy map, policy-based routing, то очень плохая идея будет включать debug IP-policy. Железка почти сразу гарантированно зависнет. В нашем случае мы видим, что здесь вот есть первая строчка debug IP-policy показывает. Трафик пришел на fast-zernet 0.1. Из-под IP-шника 192.168.102 на 8.8.8. Соответственно, fib-policy-match – это значит, что у нас сработал PBR, и трафик отправляется по политике. Показывается, куда именно это произошло. С 8.8.8.8 мы перебили next-hop на 2.2.2.2. Fib-policy-routed – это как раз показывает на то, что у нас сработала маршрутизация по policy-based routing. Следующий пакет, который есть, он идет с IP-шника 192.168.101 на тот же самый IP-шник 8.8.8.8.

Но policy-based routing ничего про него не сказал. Он его deny-нул, он его не permit-нул. Policy rejected – это не проблема. Это значит, что трафик будет отправляться по таблице маршрутизации, и он отправляется на обычный forwarding. Где выполняется PBR? Аксесс-лист у нас в железе. А что будет с PBR-движком, если у нас летит большой PPS? На старших железках PBR делается в железе. То есть это точно так же, на самом деле, как и обычная таблица маршрутизации. Это вот точно так же оно там будет работать. То есть по скорости, что вы включаете PBR, что вы не включаете PBR, это не сильно сказывается на производительности. Все это, в принципе, может обрабатывать с wire rate скоростью, ну, скоростью провода, line rate. Вот. Даже на самом деле здесь вы видите, да, вот эти вот самые строчки в дебаге. Показывается Fib policy match. Вот это вот Fib policy match как раз означает, что трафик пошел по таблице CEF.

Это не такая же таблица CEF, как с обычной маршрутизацией, которая шла IP CEF. Это другая под табличка, но все равно в этой ситуации policy based routing обрабатывается именно CEF. То есть вот что обычный трафик пойдет по таблице маршрутизации, что трафик пойдет по PBR, для CEF по затратам примерно одинаково получается. ТЕК. По поводу проверки роутмапа. Здесь, на самом деле, мы встречаемся с концепцией IPSLA. Это штука, которая позволяет мониторить какие-то внешние объекты. И мы про нее будем говорить достаточно детально на курсе по свечингу. Но здесь вот вкратце мы про нее кое-что посмотрим. И я чуть-чуть про нее расскажу, поскольку отдельной темы про нее пока еще не было. Вообще слово SLA в английском языке означает Service Level Agreement, то есть соглашение о качестве обслуживания. Это штука, которую подписывают, например, клиент и провайдер, к которому приходит клиент, который заключает договор об обслуживании.

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

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

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

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

Это очень полезная вещь, потому что, да, еще раз говорю, если вдруг у нас, например, роутер провайдера перестает работать, но сам IP-шник в Connected остается в таблице, то трафик мы все равно на него продолжим посылать. Поэтому нам нужно будет каким-то образом предусмотреть, что будет, если провайдер подох, а мы про это вот как-то не заметили, не узнали. Вот мы будем его периодически пинать, пингать. Если пинги перестают ходить, мы PolicyMap фактически отключаем. И делается это следующим образом. В настройки роутмапа нужно будет добавить команду setipnexthopverifyavailability. Эта команда указывает, что вы проверяете доступность соседа каким-то известным вам образом. Если вы ничего здесь вот не указываете, то проверяется по CDP. Понятное дело, что CDP-шный сосед, если он присылает вам свои CDP-шные кадры, то значит он в какой-то степени живой. Но, конечно, в реальности вы захотите что-то более сложное здесь добавить, что просто CDP, ну как-то грешновато. Поэтому здесь нужно будет сделать отсылку к объекту отслеживания.

Когда мы хотим использовать вот эти вот самые объекты отслеживания IPSLA, мы их должны создать перед тем, как мы их можем использовать. Создаются они командой IPSLA. Дальше какое-то число. Это число, это номер зонда. Номер зонда. Соответственно, один объект отслеживания может ссылаться на несколько разных зондов. Вы можете одним зондом, например, пингать один роутер, другим зондом пингать другой роутер. Третьим зондом вы можете проверять доступность DNS. Четвертым зондом вы можете проверять, допустим, работоспособность какого-то, не знаю, Яндекса по HTTP. И дальше вы можете сделать правило, при котором интернет считается, например, работающим или не работающим, если у вас все четыре зонда в API или хотя бы один зонд упал. То есть вы можете создать там сложные условия. Фактически это будет типа программирования, когда вы говорите, что вот если там через провайдера мы можем резолвить имена по DNS,

мы можем подключаться к, там, не знаю, к Яндексу по HTTP, он нам отдает код 200, если мы получаем IP-шник по DHCP, вот если все вот это вот работает, то мы считаем, что интернет рабочий. Мы создаем один объект отслеживания, который говорит да или нет, работает провайдер или нет, но в одном объекте отслеживания у нас будет работать сразу целая пачка зондов. Вот. Проверяют ли реально по CDP? Да нет, конечно. Это фирменная цисковская приблуда, которая, ну, может быть, и поможет, если у вас своя внутренняя сеть, и вы внутри сети хотите PBR сделать, но так, чтобы прям реально на стыке с интернетом, очень сомневаюсь. Так. Так вот, да, мы создаем зонд номер один IPS-мин. СЛА1. Внутри зонда мы переходим в контекст IPS-ЛА. Мы указываем, что за тип зонда будет. Мы будем просто пингать соседа. Указываем IP-шник. И указываем, с какого интерфейса мы будем пингать соседа.

Source-интерфейс Gigabit 0.1. Можно будет, после того, как мы создали зонд, можно будет указать, с какой частотой мы хотим пингать соседа. Frequency 10 — это раз в 10 секунд. Здесь есть нюанс, что если сосед перестает пингаться, то есть фактически один пинг пропал, у вас зонд падает, и объект отслеживания тоже падает. Поэтому с ICMP нужно быть очень аккуратным. Я вам не рекомендую в продакшене его использовать. Намного лучше использовать ICMP-джиттер, который отправляет пачку пакетов. И если они все не возвращаются, то в этом случае вы говорите, зонд упал. А вот если хотя бы один там потеряется, но остальные вернутся, то у вас там между ними считается джиттер, среднее время прохождения пакетов туда-обратно. И на основании вот этого джиттера зонд будет говорить, я в API, и результат у меня вот какой-то там определенный. Ну да, в нашем случае мы исключительно в лабораторных условиях делаем ICMP-еха просто из-за простоты. Мы указываем, что нас интересует пингать соседа 2-2-2-2. Если сосед пингается, все хорошо.

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

Вот. Ну и наконец, после того, как мы создали зонд, задали ему расписание, указываем, что нас интересует объект трекинга. Мы создаем объект отслеживания. В этом объекте мы даем свой собственный номер. В нашем случае трек 10. Это вот объект отслеживания номер 10. И в этом объекте отслеживания мы говорим, что мы будем статус объекта держать таким же, как состояние зонда номер один. Трек 10 IPSLA1. Вот если у нас зонд номер один говорит, что он пингается, все хорошо, то, соответственно, объект отслеживания у нас будет в API. Если зонд у нас перестает пингаться, то объект отслеживания тоже падает. Он переходит в down. С этим объектом отслеживания мы можем делать всякие разные интересные штуки. И в частности мы можем на основании объекта отслеживания принимать решение о назначении или не назначении NextHop.

Вот. И в roadmap здесь я внезапно так это как-то сделал. На самом деле внутри самого roadmap, внутри блока, можно будет указывать set IP NextHop, равно как set IP default NextHop, в принципе. И сразу после этого мы можем вместо указания IPшника сказать verify availability, дальше IPшник NextHop. И вот после этого verify availability и IPшник NextHop мы указываем номер объекта отслеживания. Так. Да. И, соответственно... Я не понял, почему у меня здесь объект трекинга 1 указан. Мы указываем, что мы отслеживаем объект отслеживания... Так, сейчас я запутался, что здесь означает что. Трек 1, трек 2. Почему здесь 10, а здесь 1. Смысл здесь в том, что мы назначаем IPшник NextHop 2.2.2.2.

И если он не сработал, то мы переходим и назначаем IPшник NextHop 3.3.3.3. Но вот с синтаксисом этой команды как-то у меня возникли сомнения, и мне кажется, что здесь ошибка на слайде. Давайте сейчас будем делать это в лабе и проверим самостоятельно. Так. Подключайтесь к вашим роутерам, и мы как раз вот Policy Based Routing с IPSLA и будем все сейчас с вами делать. Моя задача сейчас убедиться, что с моего первого роутера пингается и роутер Core R1, и роутер Core R2. Соответственно, пинг 10.101. Это сетка первого роутера Core R1. Дальше номер комплекта. У меня 15-й. Снова 101. Это IPшник центрального роутера. Номер 1, и он пингается. И теперь то же самое, только 102. Так, а вот 102 уже не пингается. У меня тут ушки пошли. У, значит, Unrichable.

Так. Маршрута нет. Он connected должен быть, этот маршрут. Enable show. Да, ну вот я со своей стороны, да, вижу, что у меня просто субинтерфейса нет. Поэтому нужно будет сделать... А, он connected для R2, да, согласен. Давайте сейчас для простоты, для, скажем, частоты эксперимента сделаем на R1 его тоже. То есть, поскольку там одна общая среда, то мы можем сделать соответствующий субинтерфейс в 102-м Вилане, и у нас получится связь между R1 роутером и Core R2. Давайте это сделаем. Повторяйте за мной. Интерфейс. Интерфейс. Ethernet. 0.0.102. IP адрес. 10.102. Номер комплекта.

101. На конце единичка, потому что у нас роутер номер 1. 255, 255, 255. Так. Ну и да. Encarnation.1Q.102. Да, вы тоже у себя на R1, пожалуйста, то же самое сделайте. То есть, у вас будет 102-й Вилан и на роутере R1, и на роутере R2. И, соответственно, у них будут IP-шники заканчиваться на единичку, на двойку, соответственно. На единичку заканчиваются все IP-шники на роутере R1, на двойку заканчиваются все IP-шники на роутере R2. И, по идее, сейчас у нас должна быть связь и с роутером R1, и с роутером R2. Я проверяю. Вот пинги до роутера R1 я уже проверил. Ping 10.102. Номер комплекта 102. Да, у меня пингаются.

У вас тоже пингается, и это замечательно. Так, я сделал все, что необходимо было сделать для лабы. Мы сделали следующую конфигурацию. У нас на роутере R1 наших комплектов есть два субинтерфейса. Один смотрит на Core R1, другой смотрит на Core R2. И на R2 прописан статический маршрут до IP-шника 101.101.101.101. Давайте убедимся, что у нас нет какого-то... Хотя ладно, не надо. Мы полиси-бейс-строутинг будем делать в простом варианте, при котором у нас таблица маршрутизации подключаться не будет, поэтому, в принципе, нам все равно. Если у вас пингается и IP-шник 10, 100, 2, 15, 102... Ну, или не 15, а ваш комплект 102. И 10, 101 ваш комплект 101. Значит, у вас оба субинтерфейса работают. Значит, мы готовы начинать. Что нам сейчас потребуется?

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

Переходим в раздел конфигурации и указываем, что у нас есть желание работать с роутмапом. Роутмап, который пропишет нам политику, что трафик из-под разных IP-шников надо направлять в разные стороны. Роутмап. Дальше даете какое-нибудь название, красивое название. Вот я назову PBR, подчеркивание, RM, чтобы подчеркнуть, что это именно для policy-based routing. Если мы не указываем permit или deny, то предполагается permit. Если мы не указываем номер последовательности, то указывается, ну как бы неявно подразумевается, номер последовательности 10. Здесь вот можно указать либо число, это будет sequence number, либо permit или deny. Вот я просто ничего не делаю. Я предполагаю, что у меня sequence number будет 10. Меня это вполне устроят. И роутмап, который будет, блок роутмапа, который будет что-то permitить. Внутри роутмапа можно делать всякое разное. Соответственно, можно матчить определенные вещи, можно издеваться над объектами,

которые пришли к вам в роутмап. Ну или, соответственно, можно там давать какие-то описания в роутмапе. Description. Так же, как в access-листе, на самом деле, можно вешать description. В роутмапе очень полезно description вешать, потому что, когда вы смотрите на роутмап, который непонятно, что делает, особенно если у вас не совсем говорящее название там access-листов, или не совсем понятная логика самого роутмапа, при первом взгляде на него непонятно, что он делает, очень полезно. в description написать, зачем конкретный блок нужен. Ну, в нашем случае мы description писать не будем. Мы поверим на слово, что действительно роутмап у нас будет направлять трафик в разные стороны в зависимости от IP-шников. И мы указываем match. А вот match можно по многим разным штукам. Вот. То есть здесь показывается, что можно match. Можно match свойства IP-пакета. Можно match свойства IP-6 пакета. Можно длину пакетов match. Можно смотреть на... на...

на... на... на свойства маршрутов, если бы у нас были маршруты. Например, маршруты в... там... в BGP у них есть такое свойство community. У них есть свойство ISPath. Атрибут. У них есть атрибут local preference. У них есть атрибут метрика. В SPF есть метрика. То есть если бы мы изучали маршруты, вот мы бы с вот этими вот штуками всякими имели дело. Мы могли бы даже метки MPLS проверять. То есть маршрут, если пробежал по BGP и притащил нам метку, вот можно было бы ее проверить. Но естественно, что если мы воспользуемся хотя бы одним из этих матчей и попытаемся использовать такой роутмап с policy-based routing, он нам скажет, извините, а что вы такое пытаетесь сделать? То есть вы пытаетесь взять какой-то объект и посмотреть на его свойства, например, local preference. Но проблема в том, что у проходящего пакета, транзитного или даже локально придуманного, нету свойства local preference. Это свойство, характерно для BGP-шных маршрутов. Поэтому наша задача использовать только те матчи, которые будут иметь смысл в нашем конкретном случае. Если мы хотим использовать роутмап для policy-based routing,

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

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

есть возможность немножечко, скажем, поработать также и с префикс-листами. Помимо того, что мы будем с roadmap-ами работать, вот у нас еще и появятся некие, пусть и простенькие, но опыт работы с префикс-листом. Вот. Указываем матч IP-адрес префикс-лист, и дальше называем, как мы хотим назвать наш префикс-лист. Мы будем делать отсылку к новому, еще не созданному аксесс-листу. То есть сейчас мы скажем, что у нас есть какой-то префикс-лист, и этим префикс-листом мы скажем, что все, что отправляется с нашего интерфейса, с нашего собственного адреса, и адрес будет принадлежать интерфейсу, смотрящему на роутер R1, то есть это у нас VLAN 101. Если мы хотим, чтобы отбирались этим матчем только те пакеты, которые идут с IP-источника соответствующего интерфейсу VLAN 101, то тогда вот с такими пакетами мы будем делать следующее.

Set IP next hop. И дальше указываем IP-шник нашего 101 роутера. 10.101. номер комплекта.101. Вот. Такой вот простенький блок роутмапа. То есть мы проверяем на пакеты, которые мы отправляем. Если IP-шник у них попадает под префикс-лист VLAN 101, то мы перебиваем next hop вот на такое. Дальше. Выходим из блока роутмапа обратно в конфиг и снова входим в роутмап PBRRM. Но, соответственно, уже нам нужно будет новый блок создать, поэтому здесь я уже напишу явно permit 20. Снова пишу ту же самую команду match IP address, префикс-лист, только же VLAN 102. Если трафик отправляется с IP-шника, соответствующего VLAN 102, то тогда мы set IP next hop то же самое,

но заканчивающуюся на 102 делаем. Весь трафик, который идет из-под IP-шника 101 VLAN, направляем на 101 интерфейс. Ведь трафик, который идет с IP-шника 102 VLAN, идет на 102 интерфейс. Мы тем самым, поскольку мы в команде трассировки можем выбрать из-под какого IP-шника трафик посылать, сможем указывать, в какую сторону трафик должен пойти. Не по таблице маршрутизации, а по этому самому полису-бейс-роутингу. Теперь нам нужно сделать те самые префикс-листы VLAN 101 и VLAN 102. Выходим из настройки роутмапа и проверяем, что роутмап у нас создан. do show roadmap. Вот такой вот простенький роутмап. Первый блок роутмапа указывает, что мы матчим IP-адрес по префикс-листу VLAN 101, и если все срабатывает, отправляем трафик в сторону 101 роутера. Второй блок то же самое, но в сторону 102 роутера.

Дальше. Нужны будут эти самые префикс-листы. Если у вас роутмап создался, и он создался правильно, то переходим к настройке именно их. IP-префикс-лист VLAN 101. Permit. И дальше указываем всего лишь тот самый IP-шник, который у нас висит на нашем интерфейсе VLAN 101. 10.101.15.1. И то же самое для VLAN 2. Так. Ну, в общем-то и все. Осталось сущий пустяк. Повесить все это дело, связать воедино. То есть мы создали роутмап. Этот роутмап ссылается на два префикс-листа.

И дальше с этими роутмапом и префикс-листами нам нужно взять какие-то пакеты на анализ и пропустить эти пакеты через роутмап. IP. Policy. PBR. RM. Пермит. Так. Policy. Пардон. Local policy. Так. Roadmap. PBR.RM. Мы повесили роутмап на анализ тех пакетов, которые зародились на самом роутере. Вот теоретически сейчас пакеты, которые у меня пойдут из-под IP-шника на 101 интерфейсе,

должны уйти сразу в сторону 101 роутера. Пакеты, которые уходят с IP-шника 102 интерфейса, должны уйти в сторону 102 роутера. Единственное, что... Что-что-что... Мне нужно будет сказать, что все IP-шники, которые начинаются на 102 на роутере R1, они у нас доступны. Вот так сделаю. Ради смеха. Так. И проверяю работоспособность. ping 10.101.15.101 source 10.101.15.1 ping-ца. А теперь ход по нем.

Так. Ну, ход по нем, да, предсказуемый. Он непонятно, куда его девать. Так. Сейчас я... Сейчас на запись на паузу поставлю. Эй, не буду на паузу ставить. Так. IP-роут 10.102.00. По маске 255.255.00. 10.100.1.102. Так. Вот. Я прописал обратный маршрут, и на роутере первом теперь ping-аются пакеты как из-под одного адреса, так и из-под другого. Важное замечание. На самом деле, как нам узнать, что действительно policy-based routing работает в этой ситуации? Нет, ничего проще. Можно заказать трассировку. TraceRoute 10.101.15.101 source 10.102.15.1.

Может? Может. Немножко потормозит, но тем не менее я сейчас ожидаю, что трафик действительно пойдет через 102 роутер. Так. Нет, он пошел через первый. Где-то что-то у нас не пошло не по плану. Show roadmap roadmap. Матчи не матчатся. Когда у нас roadmap работает, должно вот здесь показываться, что пакеты под него попадают, а он не попадает. Тек. Может, я перемудрился с префикс-листами. Show IP префикс-лист. Сейчас быстренько переделаю

через аксесс-листы. Секундочку. Чисто ради проверить. Пакеты. Пакеты. Пакеты. Пакеты. Пакеты. Пакеты. Пакеты. Пакеты. Стандарт. 101. Permit. 10.101. 101. 21. 21. Map. Power. Ren. Permit. Terim. Permit. Entrent. Mapто. Remit. чики кабеты. Зап FPS. М trospard. Uns incanderend for Amen. В значке. RTTP. R. Так, ошибка. Да, здесь вот ошибка, согласен.

Так, сейчас исправим. Так, я удалил указание на префикс листы и переделал на VLAN. И сейчас мне надо ошибочку исправить. Да, вот такая вот. Как прервать трейс? Ctrl-Shift-6. Или ждать. Так, вроде бы сейчас сделал. А, стоп. Здесь тоже ошибка, да. Здесь не двойка на конце должна быть. Эй. Так. я

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

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

которые содержат в себе road map и все их дочерние строчки эта конфигурация которая у нас есть айпи local полисе road map бэрэрэм указывает в конфигурации что нужно трафик направлять который зародился на самом роутере через политику заданную road map of a bar в road map и по барам у нас есть две строчки две два блока первый блок говорит что если айпишник соответствует аксесс-листу вилан 101 направляем через вот это айпишник если трафик проходит через аксесс-лист вилан 102 направляем через вот этот айпишник и соответственно шоу ран вот как выглядят сами access-листы просто обычные обычнейшие access-листы которые просто пермитит один тот же хост префикс не отработал и вот я думаю что не гипотеза есть что префикс листы

проверяют айпишник назначения вообще как бы логически было неверно префикс листы здесь использовать потому что префикс листы нужны для обработки маршрутов здесь у нас не маршрут здесь у нас пакеты и то есть здесь их в принципе не стоило использовать изначально это была моя ошибка гипотеза моя что они проверяют айпишник назначения но гипотезу проверить можно допустим в лабе будет сейчас перерыв проверю если бы мы вдруг делали полисе бы и строитель для транзитных пакетов то у нас было бы вот не вот эта вот команда хотя возможно она тоже была бы но у нас было бы на уровне интерфейса команда айпи полисе road map вот на интерфейсе она будет указывать что весь трафик который приходит через этот интерфейс обрабатывается с помощью полисе бейс троутинга если мы указываем set айпи next hop то тогда трафик обрабатывается полисе base троутингом а все что не пермитнулось road map идет на движок маршрутизации если мы указываем set ip айпи default next hop то сначала трафик обрабатывается с

таблицы маршрутизации кроме дефолтного маршрута если там есть попадание то полисе бы и стоят не срабатывает и это хорошо а если там соответственно не было попадание если там сработал только дефолт то тогда трафик отправляется на политику pbr и вот если уже и она тоже не сработал только тогда когда срабатывает дефолт. Дефолт – таблица маршрутизации, не совсем обычный маршрут. У него есть вот такая своя особенная роль, и он стоит немножко особнячком. На самом деле, в нескольких местах нам еще встретится такое, что вот дефолт действительно себя ведет не так, как обычный маршрут. Итак, у нас сейчас есть... Так, у нас сейчас вот здесь вот есть. Да, у нас есть роутер. На этом роутере есть policy-based routing. Этот policy-based routing даже работает. show roadmap. Показывается, что пакеты через этот PBR проходят. Вот, здесь 42 пакета прошло, здесь 12 пакетов прошло.

Но этот роутмап, он не проверяет жизнеспособность NextHop. То есть он его просто безумно проштамповывает без всяких размышлений, отправляет на NextHop назначение, и все. Вот дальше возникает вопрос, а что будет, если у нас вот этот вот самый узел, там вот этот вот, к примеру, узел сдохнет? То есть мы же все равно, если у нас этот IP-шник будет резолваться в таблице в Connected Marroute, будем направлять туда трафик. И я даже могу показать, что это действительно будет происходить. Что если я со стороны центрального роутера сейчас интерфейс вот с вот этим вот IP-шником подушу, все равно трафик на самом деле туда отправляться будет. Так, 10, 101, 15, 101. Так, интерфейс Ethernet 0.15. Нет, 0.0.

Сейчас, какой же там интерфейс-то? 3.3.3.2. Точка 101. Shutdown. Я выключил на центральном роутере R1 интерфейс, который смотрит в сторону моего маленького 15-го роутера. Я сейчас покажу, что трассировка через первый роутер перестала работать. Пакеты все равно отправляются в сторону первого роутера. То, что у нас субинтерфейс упал, не означает, что сам интерфейс потерял линк. Поэтому, да, линк у нас живой. Да, у нас как бы интерфейс в API. Но вот трассировка не трассируется. Потому что самый первый NextHop по факту недоступен. В реальном мире, если у вас, например, роутеры соединены между собой через прямой патч-корд, чаще всего подыхание соседнего роутера будет вызывать также и отвал линка. И у вас он будет падать по физике. И поэтому Policy Based Routing в этом случае поймет, что если физика-то упала,

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

Вот я только его выключил. Ваши роутеры, они продолжили работать. Так вот, что я сейчас хочу сделать? Я хочу сделать так, чтобы у меня мой маленький роутер проверял, что NextHop хотя бы пингается перед тем, как отправлять на него трафик. А если он не пингается, то, соответственно, чтобы у нас роутмап отрабатывал бы и переходил к следующему блоку. Говорил, окей, у нас не сработал Match, мы... То есть ничего не делаем, мы переходим к следующему блоку. Вот. И для того, чтобы это сделать, нам понадобится кусочек, вот, относящийся к IPSLA. Поскольку мы работаем внутри субинтерфейсов, вариант с CDP нас не спасет, потому что show CDP neighbors нас показывает, что есть физические интерфейсы, за которыми сидит вот роутер 15R2, coreR1, coreR2. Да, за физическими интерфейсами действительно соседи есть, но эти физические интерфейсы нас не спасут, потому что это не те интерфейсы,

на которых мы по факту устанавливаем соседство. Поэтому нам придется сейчас делать все по-честному. Поднимать объект IPSLA, сначала зонд, потом объект отслеживания, и потом внутри полиси BaseRouting в роутмапе мы укажем, что нас интересуют определенные объекты зондов, определенные объекты отслеживания, чтобы если вдруг определенный объект упадет, то полиси BaseRouting в этом блоке бы не работал. Создаем зонд. Зонд у нас будет простейший, пинглка IPSLA1. IPSLA1. Мы указываем, что у нас есть зонд номер один. Мы пока не указали его тип, поэтому мы провалились в субконтекст настройки зонда. Config IPSLA. И здесь мы можем указать, какой тип зонда нас интересует. Вот ICMP Echo – это самый простой зонд, просто попингать соседа. Сосед перестал пингаться, упали. Сосед начал пингаться, поднялись. Но вот я уже говорил, что ICMP Echo – это зонд, который будет довольно часто падать.

Потому что если у вас вдруг где-то один пинг пропадет, ICMP Echo падает тоже. А вот ICMP Jitter отправляет пачку пакетов. Если хотя бы один из них прошел, то, соответственно, зонд находится в апе. И это намного лучше. То есть если у вас внезапно какие-то пинги начали проваливаться, но в целом сосед пингается, лучше на него посылать трафик до тех пор, пока он совсем не сдохнет. Вот. Практика показывает так. Понятное дело, что железки конкретные в зависимости от платформы, в зависимости от способностей, от мощности, могут делать самые разные вещи. Можно, например, зонды настроить, чтобы они там резолвили имена по DNS. Если получается, значит, зонд в апе. Можно пытаться по HTTP запрашивать определенный URL. И если там возвращается хороший код, там 200, 301, 302, ну что-то такое. Это не ошибка, то есть ни 400, ни 500 код, то, значит, HTTP тоже будет находиться в апе. Можно по FTP пытаться скачивать файл. Можно по TCP пытаться подключиться на указанный порт и проверять, что там, по крайней мере, син плюс ак приходит оттуда.

Можно эмулировать наличие голоса. Вот то, что я вам говорил, да, что можно взять и сделать вид, что вы звоните кому-нибудь и отправить UDP-шный поток, который очень похож на голосовой, и померить свойства голосового потока. Роутеры могут вам выдавать оценку, скажем, насколько хорошо слышно собеседника, в зависимости от того, как себя ведет сеть. Но нас все это сейчас, как бы все вот эти вот особенности не очень интересуют. Нас интересует простенькая пингалка. ICMP echo. Дальше указываем параметры, что пингаем. И мы хотим пингать тот самый NextHop, на который мы посылаем трафик. В нашем случае 10.101 роутер. 15-й в моем случае комплект. 101 роутер. Можно указать сразу, с какого интерфейса пакеты должны отправляться и на какой IP-шник. Ну, в нашем случае, да. Наверное, имеет смысл указать source interface.

И мы... source interface у нас Ethernet 0.0.101. Указали тип, указали, кого пинга, указали, через какой интерфейс. Можно указать дополнительные параметры. В частности, здесь имеет смысл указывать frequency. Это как часто отправлять пакеты. Можно указать, что будет внутри ICMP. Но это не сильно полезно. То есть, если захотите, можно это сделать. Ну, так обычно задачи такой нет. И можно сказать, сколько ожидать ответа. Если вдруг вы хотите, чтобы, например, ответы, которые приходят дольше, чем за, не знаю, 2 секунды, означали, что сосед на самом деле недоступен, то вот такая возможность у вас есть. Ну, в принципе, нас все устраивает. Ну, кроме разве frequency, потому что по умолчанию он раз в минуту будет пингать. Поэтому давайте frequency поставим. Какой-нибудь поменьше.

Ну, не знаю, 10. Раз в 10 секунд мы отправляем пинги. Если вдруг пинги перестали пингаться, зонды уходят в down. Exit. Выходим из контекста редактирования зонда номер 1. Если мы потом захотим вернуться в редактирование зонда номер 1, то есть мы снова указываем IP SLA 1. Когда мы создавали зонды, мы проваливались в контекст конфигурации config.ip.sla. Здесь мы сразу провалимся в config.ip.sla.eho. То есть нельзя изменить тип зонда после того, как он уже создан. Можно его только удалить и заново создать уже другой. Так. С созданным зондом можно будет сделать очень простую вещь. Можно его включить. IP SLA schedule. Номер зонда номер 1. Start time now. Life forever. Будет вечно живущий зонда.

И на самом деле он уже начал работать. То есть он уже пошел пингать соседа и он уже выносит нам вердикт. Получается у него это сделать или нет. Давайте я выйду из контекста конфигурации и покажу, что зонт уже пингается. Второй ответ тоже покажи. Я второй пока не создавал. Я только первый создал. Show IP SLA configuration. А, понял. Вот. И это то, что я настроил. Вот эта штука. Это рассказ про то, что у меня известно про зонды номер 1. Показывается, что тайм-аут по умолчанию 5 секунд. Обычная пингалка. Отправляем пакеты на адрес 10.101.15.101 с адреса соответствующего интерфейса Ethernet 0.0.101. Так. Зонт сейчас запущен.

Показывается, что прямо сейчас все хорошо. Status of entry active. То есть он сейчас работает. И будет работать бесконечно долго. Зонт начинает работать и он копит некую статистику. Соответственно, в данный момент он копит статистику за 2 часа и держит среднее значение. Какое нормальное значение будет для пингов туда-обратно. Можно посмотреть show IP SLA statistics. Она же покажет, что с этим зондом прямо сейчас. Показывается, что зонд номер 1. Среднее время прохождения пакетов туда-обратно. Это не среднее, а последнее время. Последний зонд 2 миллисекунды. В последний раз он работал вот в такое вот время. Я думаю, что 10 секунд уже прошло. Я могу перезаказать эту команду. И вот видно, что он с тех пор побольше уже даже отправил. В эту операцию в предыдущие 9 пакетов отправлял. Здесь 11.

И вот один раз он даже, кстати, отвалился. Видимо, самый первый фейл, который был, это как раз когда cf пытался резолвить запись. Ну, в нашем случае, скорее всего, если я буду резолвить, новых фейлов уже не будет появляться. Зонд сейчас в API. Последняя операция – это окей. И к этому зонду мы теперь можем привязать объект отслеживания. Объект отслеживания сделаем очень простой, который только смотрит на зонд, и никакие больше группы из этих зондов не строят. В принципе, можно такое сделать. То есть, если вы захотите, вы можете сделать несколько простых объектов. И дальше сказать, что вы делаете сложный объект, который будет в зависимости от состояния простых объектов как-то себя вести. То есть, например, вы сделаете отдельный объект на DNS, отдельный объект на HTTP, проверяете код ответа. Отдельный объект проверяете DHCP, отдельный объект проверяете что-то еще. И для того, чтобы, например, трафик посылать через провайдера,

вы говорите, через этого провайдера и DNS должен резолваться, и то-се, и пятое-десятое. То есть, вот можно сложные деревья там делать с ветвлениями. Какие зонды должны в каком состоянии находиться. Для нас сейчас это все не очень актуально. Мы хотим сделать зонд, объект отслеживания, который ссылается просто на один зонд. Так, conft track1. Сделаем объект номер 1. И вот он может отсылать нас к либо к свойствам чего-то, что умеет работать с протоколом IP. В частности, можно проверять наличие маршрутов. Можно проверять наличие интерфейса, что интерфейс в IP или в DAW. Но проще всего работать с объектами. Track1. IP SLA. Можно группировать эти объекты. Вот сказать, что если у вас есть уже какие-то созданные объекты, вы можете сделать трек из списка.

И в этом списке указать, какие объекты должны в каком состоянии быть, для того, чтобы все было хорошо. Ну да, вот такая вот простая конфигурация. Она на самом деле нас вполне устроит. У нас есть объект отслеживания 1, который ссылается на зонду номер 1. И этот объект отслеживания, show track, находится в API. State up. Потому что зонда находится в API. Кстати, среднее время, последнее, 3 миллисекунды было. Раньше 2 было. И мы к этому объекту можем привязать теперь наш roadmap. Conf.t. Roadmap. Br. RM. 10. Set. IP. А, пардон. Set. IP.

Оп. Вот. Вот здесь вот штучка такая. Verify availability. Если просто Verify availability без параметров указать, она будет проверять доступность CDP-шного соседа, который вы указали. Но это не то, что нас интересует, потому что мы работаем через интерфейсы, где CDP не бегает. Поэтому вынуждены мы использовать IP-шник соседа. 10.101. Номер комплекта.101. Это next hop, который мы задавали. И дальше указываем номер последовательности. Эти списки next hop можно будет делать из больше, чем одной записи. То есть для конкретного блока roadmap можно сказать, сначала попытаемся такой next hop, если он недоступен, то секой, если он недоступен, то пятый, если он недоступен, будет десятый. И вот как раз здесь, да, меня смутило в прошлый раз на слайде.

Я вам показывал, да, что там 10, трек 1 было. И при этом явно там не билась цифра между собой. Первая цифра – это номер последовательности. То есть номер последовательности – это в каком порядке мы добавляем next hop. Ну вот давайте первую строчку сделаем с номером 10, как это обычно Cisco делает, номер 1. И дальше указываем, что мы добавляем объект отслеживания, объект track 1. Это вот объект трекинга номер 1. Можно здесь добавить и еще, допустим, verify availability, сказать 10, 102, 15, 102, допустим, с треком 2. Ну, у нас просто трека 2 нету. Но этого даже уже будет и не нужно. То есть сейчас в такой конфигурации roadmap будет проверять объект трекинга, который в свою очередь проверяет зонда на то, что он пингает соседа или нет. И если сосед пингается, то next hop у нас вот такой вот ставится. Если сосед перестает пингаться, то мы переходим к другому next hop, который мы сдаем в этом roadmap.

Очень удобная штука и настоятельно рекомендую вам ее делать в боевых ваших развертываниях policy-based routing, если вы будете ее использовать. Show run, естественно. То есть вот у нас вот этот вот IP next hop verify availability, IPшник вот такой вот. И только если пингается. Если нет, то тогда проверяется вот эта штука. Очевидно, что здесь IPшники в нашем случае одинаковые. То есть вот этот вот IPшник и вот этот вот IPшник, они одинаковые. И в этом смысле первая запись немножко теряется. Но в реальном мире у вас, скорее всего, вы захотите сделать так, чтобы основной IPшник проверялся бы с трекингом, а, соответственно, второй провайдер бы здесь вот во втором сете уже писался, ну, можно с трекингом, можно без трекинга.

То есть просто безусловно, например, можно писать. Да. И с помощью вот такого вот механизма вы можете трафик на next hop посылать не безусловно, а только проверив, что он живой. Так. Ну и show roadmap. Вот мап. Да, он действительно там должен показывать отсылку к объекту трекинга. Вот. Да. Объект трекинга в API. Поэтому next hop вот этот вот мы и проставляем. В реальности, да, вы захотите проставить IP next hop verify availability что-нибудь с проверкой, а потом как запасной IPшник уже можно с проверкой, можно без проверки, без разницы. То есть если оба дохлые, то без разницы куда отправлять, все равно не дойдет. Так. Да. Понятное дело, что для второй записи аналогичную надо конфигурацию сделать,

прописать тоже основной next hop с проверкой, запасной next hop без проверки, или тоже с проверкой без разницы. Но мы сейчас это не будем делать просто для экономии времени. Идею, я думаю, что вы поняли, что next hop надо добавлять в правильном порядке. Есть возможность этот порядок менять с помощью вот этого параметра sequence. И есть возможность, соответственно, задавать просто IP next hop без проверки, и он будет срабатывать в последнюю очередь. Так. С roadmap более-менее закончили. Давайте переходить к следующей теме. Субтитры сделал DimaTorzok.