Маршрутизация в Cisco IOS (часть 2)

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

Дальше. Мы на этапе построения таблицы, соответственно, пытаемся скормить в нее маршруты из разных источников. У нас есть connected маршруты, которые появляются автоматически при назначении IP-шника. То есть мы IP-шник повесили, и сразу маршрут породился в таблице маршрутизации. То есть это один из способов пополнить таблицу. Второй способ – это статические маршруты. Тоже достаточно простой способ. Пришел админ, сказал, я хочу сказать тебе, дорогая циска, что маршрут вот такой вот известен в том направлении. Плюс к тому, естественно, есть и другие способы пополнения таблицы. То есть show IP-road, если вы посмотрите, у вас там есть легенда, с которой начинается вывод команды show IP-road. Эта легенда довольно обширная. Сейчас я на предыдущий слайд перелесну. Вот, да, она как раз. И здесь есть маршруты, которые connected. Маршруты, которые L, локальные, это наши собственные IP-шники. Смысл заключается в том, что если мы по таблице маршрутизации находим IP-шник, который принадлежит именно нам,

мы не хотим направлять трафик до какого-то другого хоста, который находится за каким-то интерфейсом. Мы хотим этот трафик сами потребить. Поэтому в таблице маршрутизации добавляется специальная запись с типом локального маршрута, что это наш собственный IP-шник. Обычно такие записи по максимально возможной маске. Slash 32 в IPv4 или Slash 128 в IPv6. Дальше. Connected понятно, static понятно. Есть протоколы динамической маршрутизации, которые могут нам добавить маршруты в таблицу. Часть из них мы уже видели на CCNA. CCNA это, ну, например, RIP, это BGP, буква B, это EGRP, буква D, означает Dynamic. OSPF. Что у нас там еще? Из того, что можно более-менее легально встретить в сетях. ASIS, буква I, маленькая.

Ну, вот разве что и на черпишные шорткаты можно еще встретить. Буква H. Ну, остальное вы, наверное, вряд ли увидите в реальном мире. Да, но тем не менее, вот есть множество способов пополнить таблицу маршрутизации. Может быть такое, что одну и ту же сетку мы получим из разных источников. Из OSPF, из... Чего там еще может быть? Из EGRP, из BGP. Или она может быть static или connected. И возникает вопрос. Как нам выбрать среди нескольких маршрутов, которые указывают в разные стороны, если вдруг они у нас появляются? То есть вот у нас есть роутер. Вот он, буква R. У него есть два интерфейса. Один налево, другой направо. Мы знаем, что где-то в сети есть сетка 10.0.0.0 по 24-й маске. И, соответственно, к нам OSPF, который у нас здесь вот запущен, пришел, сказал, я знаю, как добраться до этой сети, посылай трафик через следующий хоп. И рядом работает какой-нибудь условный EGRP. На другом интерфейсе уже, который говорит, я тоже знаю, как добраться до этой сети, посылай трафик через меня. И тут мы начинаем думать, а как нам справиться с такой ситуацией, когда нам и OSPF, и EGRP, и где-нибудь еще, не знаю, может быть, рядышком static администратор прописал.

Вот. Как нам справиться с ситуацией, когда у нас есть несколько способов получить доступ к сети, и они получены из разных источников. Когда у нас есть, допустим, OSPF, и он внутри себя пытается разобраться, как-то поставить одну с другим, понять, как лучше ходить до какой-то удаленной сети. Внутри OSPF, и понятно, он там берет, метрику считает и говорит, вот в одном направлении метрика была бы 20, в другом 30, 20 лучше, чем 30, поэтому ходи туда. И вот он пытается поставить в таблицу маршрутизации маршрут с метрикой 20. EGRP тоже, если вдруг будет сравнивать между собой маршруты именно с EGRP, он тоже скажет, в одном случае метрика 2 миллиона, в другом случае 3 миллиона. 2 миллиона лучше, чем 3 миллиона. Поэтому в таблицу маршрутизации он пытается поставить маршрут с метрикой 2 миллиона. И статический маршрут, у него вообще метрик нет. У него есть только, да, только указание, что маршрут есть. И вот возникает вопрос. Вот три маршрута OSPF с метрикой 20, EGRP с метрикой 2 миллиона, что из них лучше? Или лучше вообще статический маршрут, которого в метрике нет, в принципе, как класса?

И получается, да, что вот эти вот 20 OSPF и 2 миллиона EGRP сравнивать между собой вообще нельзя. То есть, ну, а как их сравнить? То есть, чем 20 лучше, чем 2 миллиона? Или чем 2 миллиона лучше, чем 20? Непонятно. Поэтому в CISC используется концепция очень простая, что каждому маршруту будет соответствовать так называемое административное расстояние. Это некое свойство маршрута, которое будет характеризовать, насколько этот маршрут имеет, скажем, право вброситься в таблицу маршрутизации. У каждого источника маршрутной информации есть значение по умолчанию, которое получают как раз маршруты в качестве административного расстояния. То есть, эта штука вешается на отдельный маршрут. К нам пришел OSPF, посчитал лучший маршрут до определенной сети, дальше он пытается вбросить маршрут в таблицу маршрутизации, и вот у него есть дефолтное значение административного расстояния. И он пытается его добавить. Если там уже никакого маршрута не было до того,

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

Поэтому если вы добавляете маршрут, вы просто вешаете IP-шник на интерфейс, и по факту повешения IP-шника на интерфейс у вас автоматически добавляется маршрут, который все другие типы маршрутов выкидывает из таблицы. Никакого другого способа пойти в обход до какой-то сети Cisco не примет до тех пор, пока у нее есть способ отправить пакет напрямую в эту сеть. Это вполне логично. То есть если у вас есть роутер, у него есть интерфейс, который смотрит куда-то, и даже если вдруг можно потом как-то пойти в обход и тоже попасть в эту же сетку, то есть здесь у нас типа свитчек, и здесь есть юзеры, то вот мы говорим в обход никогда не пойдем, пойдем только напрямую. Изменить это поведение нельзя, то есть Connected маршрут у них всегда административное расстояние 0. Статические маршруты по умолчанию получают административное расстояние 1, и его можно переопределить. В команде IP-road вы указываете IP-шник, маску, шлюз, и там, среди прочего, можно как раз AD конкретного маршрута определить. И эта штука будет использоваться в ситуации, когда, например, у нас есть роутер, и у нас есть, например, два выхода в интернет.

Один выход в интернет типа основной, другой типа запасной. И вот мы говорим, в одну сторону мы добавляем 0.0.0.0 по какой-нибудь там маске, не знаю, с каким-либо шлюзом, с административным расстоянием 1, и приписываем указание, что этот маршрут не просто через какой-то IP-шник, а вот именно через интерфейс Ethernet 0.0. И дальше мы говорим, что во вторую сторону тоже смотрит 0.0.0.0, но с административным расстоянием, например, двоечка. И он там через Ethernet 0.0.0.0.2, к примеру. И до тех пор, пока у нас живой интерфейс вот этот вот, маршрут в таблице вот этот вот сидит, и с ним все хорошо. Вот этот вот маршрут есть только в конфигурации, но в таблице его по факту не будет, или он даже использоваться не будет. Как только интерфейс дохнет, вот этот вот маршрут удаляется из таблицы, и вот этот вот маршрут уже, соответственно, запасной, которым нельзя было пользоваться, потому что его административное расстояние было больше. Ну вот он поднимает голову и начинает работать.

Вот получается, да, что у нас до тех пор, пока один интерфейс живет, мы ходим через него. Как только через него перестает трафик ходить, интерфейс падает, трафик начинает ходить через запасной интерфейс. Дальше. EJRP-шные маршруты могут иметь несколько разных административных расстояния по умолчанию, причем их можно переопределять. Опять же, у EJRP есть разный тип маршрутов, которые мы с вами еще пока не проходили, но вот на CCNA, к примеру, мы поднимали EJRP, и все маршруты там имели административное расстояние 90. 90 – это обычные нормальные EJRP-шные маршруты. Вот включили на интерфейс EJRP, connected сетки с него попали в таблицу топологии, распространились на все роутеры в топологии, и дальше. Вот нормальные обычные EJRP-шные маршруты получают административное расстояние 90. Опять же, можно переопределить, можно на уровне отдельного маршрута, можно на уровне всего роутера, все обычные нормальные маршруты получить административное расстояние не 90, а какое-то другое. Ну вот по умолчанию именно это.

Если вдруг вы будете выбрасывать в EJRP какие-то другие маршруты, не те, которые из-за команды Network появились в топологии, а вот как-то иначе, через редистрибуцию, например, то такие маршруты будут иметь административное расстояние, опять же, по умолчанию – 170. Опять же, можно переопределить, опять же, потом расскажу как, но вот цифры 90 и 170 надо будет запомнить. И еще, если вдруг у нас есть несколько мелких сеток, которые приходят на EJRP роутер, а дальше он хочет вместо кучи мелких сеток отправить одну, но большую, то есть здесь у нас, например, слэш 24, сетки, которые висят на интерфейсах, которые смотрят напрямую на пользователей. А дальше мы за пределы дистрибьюшн-блока хотим отдать слэш 16 сетку. Вот то, что я вам изначально показывал в модуле про дизайн. Эта штука будет называться агрегацией или суммаризацией. И вот такие суммарные маршруты у EJRP будут иметь по умолчанию административное расстояние пятерку. Опять же, можно переопределить.

Вот. Дальше, дальше, дальше, дальше. Вот у EJRP будет три возможных варианта, какие маршруты могут какое административное расстояние иметь. У SPF по умолчанию все маршруты будут иметь административное расстояние 110. То есть это тоже хорошо известное значение, которое надо запомнить. Но, опять же, можно поменять. Причем поменять можно отдельно для маршрутов, которые посчитаны по-честному. То есть это интроэреа маршруты, получены они через LSA-эки первого типа. Есть, соответственно, интерэреа маршруты. Это маршруты, зародившиеся в другой эре, в другом регионе. Но все-таки сравнительно по-честному посчитаны целиком через SPF. И есть еще external маршруты. Это те, которые появились в результате вбрасывания совсем посторонних маршрутов в SPF. Там уже до удаленной сети посчитана по-честному только та часть, которая в SPF прибежала. Есть какая-то еще часть маршрута, которую SPF вообще в принципе не видел.

Поэтому доверия к этим маршрутам обычно немножко меньше. Ну вот вы можете на уровне отдельного типа маршрутов указать, что административное расстояние будет другое. Либо, опять же, на уровне отдельного прям маршрута. Просто сказать, вот SPF все маршруты выбрасывает вот такие, а этот будет другой. У него будет не 110, а 115, к примеру, административное расстояние. Дальше. ASIS мы в курсе не рассматриваем, но у него 115 по умолчанию. RIP 120. Дальше. BGP. BGP тоже будет интересный протокол, потому что у него тоже два административных расстояния. Для внутренних маршрутов, то есть те, которые прибежали от соседей в своей автономке, административное расстояние будет 200. А для тех соседей, которые прислали маршруты, которые находятся в другой автономке, административное расстояние будет 20. Смысл здесь очень простой. Если у нас есть два роутера, и они смотрят напрямую во внешний мир какой-то. То есть вот это у нас своя автономная система.

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

своего, своему соседу в своей автономке, чтобы он уже откинул эту картофельную там или этот пакет по этому маршруту дальше куда-то во внешний мир. Чем раньше избавимся от трафика в своей автономке, тем лучше. Ну вот маршруты, полученные из своей автономки, мы им, соответственно, мы не хотим им пользоваться, поэтому у них административное расстояние 200. И маршруты, полученные из других источников, из других автономок, у них административное расстояние 20. Опять же, про BGP будем говорить и все это напомним еще раз Есть всякие экзотические источники маршрутной информации Например, старый древний протокол IGRP, предшественник EGRP У него административное расстояние 100 Есть старый древний протокол EGP, предшественник протокола BGP У него административное расстояние 140 Есть прикольнейший протокол, который называется ODR Это фирменный цисковский протокол в кавычках динамической маршрутизации

Который работает через CDP То есть ему вообще ничего не нужно для того, чтобы он работал CDP соседи видят и, соответственно, он же CDP кормит соседей маршрутами Такая наркоманская штука Но у нее есть очень большое ограничение, поэтому в продакшене использовать не надо Тем не менее, да, циски ее поддерживают Административное расстояние у нее будет 160 То есть, да, тоже можно таким образом распространять маршруты Это не совсем честный протокол динамической маршрутизации Потому что у него нет защиты от петель вообще Поэтому его можно использовать только в сетях, в которых петля в принципе невозможна Если два роутера, например, прямым патчкордом соединить одним Вот там ODR можно поднять Если у вас звезда топология, тоже ODR можно поднять А вот если у вас какая-то более-менее реальная сеть В которой есть дублирующиеся линки В которых есть непонятная абстрактная топология, где могут быть кольца Там ODR использовать нельзя И еще один интересный момент заключается в том, что Административное расстояние 255 соответствует недоступной сети

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

В принципе, эту же цель может... Как это сказать? Эту же цель может... Что с целью можно сделать? Эту же задачу можно решить другими способами Например, можно добавить коннектат маршрут, который смотрит в несуществующий интерфейс В CISC есть такой интерфейс, который называется 0.0 Вы можете сказать, что определенная сетка будет коннектат на интерфейсе 0.0 И тем самым, да, получится, что весь трафик до этой сети вы убиваете в любом случае Но вот административное расстояние 255 действует более тонко Оно говорит, что если пакет попал только под 8.0 и под вот такой 255 маршрут То, соответственно, выигрывает 255 маршрут и трафик дропается А если пакет попал под какой-то явно заданный маршрут Эксплисит или конфигурует Ну, соответственно, вот получилось, что у нас в таблице маршрутизации был вот этот 255-й

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

И по факту, если административное расстояние будет 255, то этот маршрут как бы убивает трафик в любом случае Но его можно переопределить Это вот такое вот заметное отличие такого типа маршрутов от маршрутов в сторону 0.0.0 Так, что еще здесь надо было бы заметить? Если вы добавляете маршруты из одного и того же источника То есть, например, OSPF вам сказал, я хочу доставить трафик до определенной сети И я знаю два способа маршрута, два способа доставить трафик до определенной сетки Вот он в этом случае добавит в таблицу с маршрутизацией два разных маршрута И у вас будет использоваться так называемая концепция ECMP Equal Cost Multipath То есть трафик будет балансироваться Часть пакетов пойдет по одной трассе, по одному NextHop и часть по другому В случае с некоторыми типами маршрутов типа EGRP Вы можете использовать UCMP Unequal Cost Multipath

Или UCLB, что по сути свои то же самое Unequal Cost Load Balancing Это ситуация, при которой вы добавляете два NextHop для определенной сетки И трафик между ними распределяется неравномерно Например, очень полезно это в случае, когда у вас EGRP Притаскивает несколько маршрутов, говорит Это все Feasible Successor, а просто метрика у них разная И, соответственно, метрика хорошего саксессора, она вот такая Метрика Feasible Successor, которая чуть похуже, она вот всякая И мы хотим балансировать трафик Допустим, две части трафика направить на похуже Три части трафика направить на получше из пяти Ну и получается, да, что у нас загрузка на роутер, который соседский получше Получается там на 50% побольше То есть такие вот вещи можно будет сделать Если мы строим IPv4 таблицу, то нам нужен будет маршрутизируемый IPшник Ну не обязательно маршрутизируемый, то есть хоть какой-то IPшник, который мы сможем добавить в таблицу И получается, что до тех пор, пока мы в явном виде интерфейс на соседском роутере не пропишем адрес на нем

Мы не сможем добавить такие маршруты То есть для того, чтобы нам динамическую маршрутизацию завести Или для того, чтобы статику прописать Нам IPшник соседа все-таки нужно будет знать В IPv6 у нас всегда есть адрес, который называется link-local-адрес Он автоматически обнаруживается с помощью всяких OSPF-овских мультикастов И джарпишных мультикастов и так далее И вот именно на него как раз удобно ставить маршруты при заполнении таблицы маршрутизации Это не означает, что вы, например, статический маршрут, если будете прописывать, не можете прописать адрес, который вы сами на интерфейс повесили Но все динамические способы выполнения таблицы маршрутизации будут стараться использовать именно link-local Им легко, потому что они эти link-local автоматически распознают Ну а человек, если будет прописывать маршрут, он может прописать как link-local, так и, допустим, какой-нибудь красивый адрес, который он сам повесил Что касается шлюза по умолчанию, она же default-road

Здесь есть, в общем, один момент, который полезно будет запомнить Давным-давно, в очень-очень далекой галактике, была такая штука, как классовая маршрутизация И, соответственно, в этой классовой маршрутизации одну сетку можно было пометить звездочкой Что все остальные сети в мире, которые не перечислены в явном виде, доступны через тот же самый next-hop, что и конкретно указанный префикс до какой-то классовой сети В CISC-ах эта штука помечалась командой default-network То есть вы указывали default-network и указывали IP-шник классовой сети, в которой у вас есть таблица маршрутизации И его next-hop пользовались также и те пакеты, которые шли на адреса, которых в таблице не лукапились никаким другим способом В бесклассовом мире эту штуку использовать бессмысленно, потому что есть маршрут на суперсеть 0.0.0.0 по нулевой маске То есть, в принципе, вы можете объявить сетку default-network, и напротив нее даже галочка поставится, что она действительно default-network И, может быть, даже некоторые реализации будут действительно направлять трафик на эту дефолтную сеть

Но это будет не совсем логично И главное, что сама концепция вот этой самой default-network, когда мы одну классовую сеть помечаем как дефолтную Ну, она какая-то убогая достаточно То есть, если у вас есть полноценная таблица маршрутизации, нет смысла использовать команду default-network Я про нее вам рассказываю, потому что есть такой протокол EGRP И у него эта команда будет во многих руководствах по настройке предлагаться в качестве одного из вариантов бросить дефолтный маршрут Это, скажем, не совсем будет удобно использовать, особенно если у вас 15-ios, там эта команда просто тупо не работает То есть, да, сетку вы пометите звездочкой, да, эта самая звездочка даже будет распространяться с помощью протокола EGRP на другие роутеры То есть, не просто connected-сетку какую-то, которая у нас есть, класс EGRP может распространить Он еще может вот эту звездочку, галочку передать, что там сосед тоже должен использовать именно эту сетку для доставки трафика И NextHop, вот тот, который EGRP передает, он тоже должен использовать

Но по факту, да, бесклассовые роутеры игнорируют передачу этой самой звездочки Поэтому использовать ее по факту не получится Если у вас бесклассовая маршрутизация, используйте обычный RepairRoute 0.000 Ну или какие-то другие способы распространения этого самого 8.0 маршрута Так, что касается концепции VRF, которые у нас есть на этом слайде Здесь я хочу, чтобы вы вспомнили такую штуку, как VLAN То есть, что такое коммутатор? Коммутатор — это штуковина, которая эмулирует толстый-желтый как сел Я это буду вам постоянно повторять Она это эмулирует с помощью концепции Что все, что пришло через один интерфейс, надо отправить на все остальные интерфейсы, кроме некоторых И, соответственно, она, если знает, где сидит конечный получатель Она блокирует передачу копии трафика на все остальные интерфейсы, кроме того, где сидит действительно конечный получатель

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

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

В принципе, то же самое, что делает VLAN на коммутаторе Но здесь вот то, что я вам показал с коммутатором Вот эта вот штука, когда у нас есть интерфейсы, которые принадлежат определенному VLANу Она хорошо работает, пока у нас все интерфейсы аксессовые Как только у нас появляются транки, у нас появляются проблемы Есть провод, который приходит на наш коммутатор И по нему прибегает кадр И часть кадров надо отправить в один VLAN, по одной таблице коммутировать, часть по другой И в этом случае мы говорим, что те пакеты, которые приходят на наш коммутатор по транковым портам Мы должны каким-то образом посмотреть на эти пакеты и проанализировать, к какому VLAN они относятся И, соответственно, если мы видим там, например, метку 802.1Q, то мы отправляем трафик на обработку одной таблицей Если пакет приходит, у него там другая метка VLAN, мы отправляем на таблицу другого VLAN Аналогичная концепция есть при VRF То есть если у нас есть какой-то интерфейс, который не принадлежит никакому кусочку роутера

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

Ну, соответственно, мы прописываем на интерфейсе явно, к какому VLAN он относится Вот аналогичная концепция с VRF-ами будет называться VRF Lite Lite уже намекает на то, что есть другой какой-то сценарий, который уже хардкорный Ну да, действительно хардкорный Этих хардкорных сценариев может быть несколько Первый сценарий – это MPLS-ный сценарий Когда у нас есть интерфейс, на котором приходят MPLS-ные пакеты И в этих MPLS-ных пакетах проставлены метки И мы по этим меткам ориентируемся, соответственно, на какой На какой VRF отправить обработку конкретного пакета Второй сценарий называется EVN – Easy Virtual Network Это фирменная цисковская штука, при которой пакеты на ваш роутер приходят для обработки в разных VRF-ах И они помечены обычным 802.1-кьюшным заголовком То есть на уровне Ethernet к вам приходят IP-пакеты Которые адресованы в разные таблицы маршрутизации В разные VRF-ы

И они помечены просто 802.1-кьюшным заголовком Вы могли бы эти пакеты разбирать с помощью обычных субинтрофейсов Но просто в случае с Easy Virtual Network Это удобно делать с помощью одной простой команды Которую мы сейчас посмотрим на следующем слайде Мы не будем с вами делать Labo на EVN Но просто вы должны с ней быть знакомы Потому что на экзамене может быть вопрос Насколько EVN круче, чем отсутствие EVN И, соответственно, я хочу вам показать, что действительно оно круче В том смысле, что конфигурация будет довольно простая Если мы создаем VRF, то нам нужно сделать несколько подготовительных действий Так же, как в случае с коммутаторами Когда мы создаем VLAN Нам нужно заранее, перед тем, как начнется какая-то боевая работа Создать аналог VLAN в базе VLAN В случае с VRF, это объявить VRF VRF, Definition, дальше говорим Вот у нас есть отдельная таблица маршрутизации для одного кастомера Отдельная таблица маршрутизации для другого кастомера

Это как раз очень полезная штука для провайдеров У которых есть много клиентов И эти клиенты хотят обмениваться маршрутами Или пакетами Например, в случае с провайдерскими VPN-ами И эти маршруты и пакеты могут использовать совпадающую адресацию То есть у нас есть кастомер А Вот кастомер А И у него айпишник 10.0.0.1 Имеет полное право такое сделать? Имеет С другой стороны у нас тоже есть кастомер А Только другой роутер У него айпишник 10.0.1 Давайте, 1.1 И дальше здесь рядышком кастомер Б У него точно такой же айпишник 10.0.1 Имеет право другого кастомер сделать такой же айпишник, как у первого? Ну, абсолютно Потому что они свои адреса назначали Не советуя друг с другом Это вообще абсолютно разные сущности Абсолютно разные люди Абсолютно разные компании Которые пришли к одному и тому же провайдеру И сказали Мы хотим пользоваться твоими услугами

Ну и что, что у них айпишники одинаковые? Провайдеру-то это не означает, что он не может у них деньги взять? Ну и, соответственно, здесь тоже может быть такое, что адрес будет тоже такой же И вот надо будет при фарвардинге таких пакетов не спутать Где здесь кастомер А, а здесь кастомер Б Вот, если мы просто возьмем в таблицу маршрутизации все маршруты эти запихаем То у нас получится, что трафик между кастомером А и кастомером Б будет балансироваться Мы этого не хотим Мы хотим сказать, что у нас есть отдельная таблица маршрутизации для кастомера А И отдельная таблица маршрутизации для кастомера Б Мы их создаем Говорим VRF Definition Customer A VRF Definition Это мы объявляем, что у нас вообще такие таблицы маршрутизации будут Дальше у нас есть роутер Вот этот вот роутер И, соответственно, у нас есть 802.1Q-шные транки Если мы не будем использовать EVN Если мы будем работать с обычными субинтерфейсами Так же, как это мы делали на ACCNA То что мы сделаем? Мы скажем, что у нас есть интерфейс, который смотрит на кастомера А Это интерфейс, допустим, там

Gigabit Ethernet 0.100 и Gigabit Ethernet 0.200 Вот мы говорим Gigabit 0.100 Это субинтерфейс, который смотрит на физическом транке в сторону кастомера А На свече, который принимает этот транк Вот он, серенький свеч У нас создан VLAN сотый И мы говорим, что вот на этом транке Субинтерфейс сотый будет принимать трафик именно сотого VLAN Аналогичная история здесь Мы говорим, что здесь у нас будет 200-ый VLAN 200-ый VLAN И в нем сидит кастомер B На свече мы объявили два VLAN Сотый VLAN для кастомера А 200-ый VLAN для кастомера Б Подняли между роутером и свечом обычный транк Создали два субинтерфейса Gigabit 0.0.100, Gigabit 0.0.200 И в каждом из них объявили свой IP-шник Ну, здесь вот у нас 192.168.0.1 Одинаковый IP-шник для обоих клиентов Обратите внимание, да Что вот в случае с обычной одной таблицей маршрутизации

Мы такую штуку сделать не сможем Мы не сможем сказать, что у нас 192.168.0.1 И 192.168.0.1 На двух разных интерфейсах Циск скажет, извините, такое сделать нельзя Но магия заключается в том, что мы перед тем, как Вешать IP-шник на этот интерфейс Объявили вот эту вот команду IPvrf forwarding customer A IPvrf forwarding customer B Мы сказали, что эти интерфейсы Принадлежат к разным таблицам маршрутизации И, соответственно, мы Когда это сделали У нас в таблице маршрутизации Connected маршруты занеслись именно в разные таблицы Одна 192.168.0.0 По 30-й маске Занеслась в customer A Другая такая же в customer B Оба customer сейчас могут Пингать центральный роутер По одинаковому IP-шнику 192.168.0.1 Ну, соответственно, таблицы маршрутизации на этом роутере При этом две Вот если мы не используем EVN, если мы используем обычный подход с субинтерфейсами То у нас получается на каждом интерфейсе

Надо взять, прописать, какой VLAN он будет использовать Прописать, какой VRF он будет использовать Прописать отдельные IP-шники Если у вас клиентов много, то это превращается в легкий геморрой Если вы хотите, вы можете сделать это проще Соответственно, у вас есть Транк 802.1-киушный Но вы его поднимаете не в виде Транка и отдельные субинтерфейсы к нему А вы указываете, что у вас есть VRF с customer A VRF с customer B И вы говорите, что если мы используем EVN Вот это вот самый Easy Virtual Network То тогда весь трафик customer A будет помечаться VLAN 100 А весь трафик customer B будет помечаться VLAN 200 И затем на интерфейсе физическом, который смотрит на соседа Вы поднимаете VNet Trunk Вот эта вот команда VNet Trunk, она как раз и говорит Что здесь будет передаваться трафик всех VRF одновременно И IP-шник у них на всех VRF будет одинаковый 192.168.1.1

Вот эта штука, она весьма удобная И, соответственно, вот здесь, вот на этом интерфейсе Можно там и OSPF поднять Он будет работать в разных VRF Ну, равно как и здесь тоже можно Но здесь придется на отдельных интерфейсах здесь поднимать, здесь Вот Ну и получится, да, что вот это вот Просто более компактный способ Более удобный способ работать с таблицей С разными таблицами маршрутизации Хитро, да Вот Еще раз, я не прошу вас запомнить, как эта фигня работает Я не прошу вас запоминать команды, которыми это работает Даже я не предлагаю вам это в продакшене внедрять Потому что это предполагает, что у вас везде все подключат по алфавиту Ациски купленную Но это не всегда так Но, по крайней мере, посмотреть на то, как хитро Ациска предложила это сделать И, в связи с тем, что действительно она предложила достаточно компактный способ работы с такой штукой Вот я предлагаю вам восхититься тому, что человеческая мысль дошла до такого Вот Разница между сценарием с EVN и сценарием с обычным транком с 802.1Q-шными VLAN-ами, с субинтерфейсами

Заключается просто в компактности записи Смысл будет одинаковый Что там, что там Мы кадры, которые отправляем, будут помечаться 802.1Q-шной меткой И, соответственно, внутри этих кадров будут передаваться IP-пакеты И разные VRF-ы будут помечаться разными 802.1Q-шными метками Вот и все В экзамене эта штука, к сожалению, есть Не в том смысле, что вас будут спрашивать, какие команды там, что будут Не будут спрашивать именно настройку или специфику работы этой штуки Но, по крайней мере, общие вопросы, типа, вот, насколько EVN лучше, чем не EVN, могут быть И для того, чтобы вы не пугались, я вам про нее рассказываю Замечу сразу, что EVN – это не технология для крупных провайдеров То есть, если вы провайдер, особенно крупный, вы должны будете использовать MPLS И MPLS находится за пределами нашего курса очень сильно Но вот, если у вас маленькая сеть, вы в каком-то маленьком городе работаете Или в предприятии, в достаточно крупном предприятии, чтобы у вас уже необходимость использовать эти VRF-ы назрело

Вот вы можете использовать EVN и получить более компактную запись Более компактную конфигурацию VRF и EVN – это одно и то же? Нет, это не одно и то же VRF – это отдельная обособленная таблица маршрутизации для одного виртуального роутера Который работает среди прочих виртуальных роутеров на одной физической железке EVN – это способ работы с несколькими VRF-ами, которые более компактны, чем традиционные, которые слева В случае, когда у нас слева показано, вот здесь у нас есть виртуальный интерфейс Gigabit Ethernet 00100 В котором трафик приходит помеченной сотой меткой И мы говорим, этот интерфейс, логический интерфейс, относится к кастомеру А Соответственно, другой виртуальный интерфейс, мы говорим, этот интерфейс относится к кастомеру Б и помечается 200 ВИЛАНом Здесь происходит ровно то же самое, просто более компактная запись Когда вы делаете несколько VRF-ов, вы, соответственно, можете добавлять какие-то маршруты в таблицу маршрутизации

Вы можете запускать отдельный протокол динамической маршрутизации, чтобы они пополняли вам таблицу определенного VRF-а То есть, в принципе, можно взять и запустить отдельный экземпляр, например, у SPF-а, который будет работать внутри VRF-а И вы можете сказать, что вот у нас есть отдельный SPF для VRF-а номер один и отдельный SPF для VRF-а номер два В каких сценариях VRF может быть полезен в предприятии? Например, вы хотите сделать так, чтобы у вас был роутер в филиале Соответственно, у него есть какая-то своя филиальная сетка, в которой сидят пользователи И нужно организовать связь со внешним миром для того, чтобы построить по этому внешнему миру через интернет VPN И вы хотите сделать это отказустойчиво То есть, вам нужно иметь два разных способа выйти во внешний мир И, соответственно, вы приходите к одному провайдеру и говорите Дорогой провайдер, мне нужен интернет вот в таком-то офисе И они говорят, не проблема, на тебе провод, банальный интернет, Ethernet

Вешаешь IP-шник 192.168.1.2 и используешь шлюзом 192.168.1.1 Приходите к другому провайдеру, и он вам говорит ровно то же самое Он говорит, на тебе провод, используй IP-шник 192.168.1.2 И шлюзом будет 192.168.1.1 Вот, и что получится? Что вы не можете назначить такие IP-шники Если вы их в одну таблицу будете запихивать, на одном роутере Ну, соответственно, они будут конфликтовать между собой Но решением будет как раз сделать отдельный VRF для одного провайдера Отдельный VRF для другого провайдера И работать с интернетом внутри отдельных VRF У вас будет как бы отдельный интернет через одного провайдера в отдельном VRF Отдельный интернет через другого провайдера в другом VRF И туннели, которые вы будете строить, например, там, горы Ешны или IP-IP Надо будет делать уже с учетом VRF Так что VRF иногда бывает полезны, даже если вы не провайдер Но, естественно, что если у вас такой проблемы нету То вы вполне можете взять и обойтись в большинстве сценариев

Просто одним экземпляром роутера без всяких VRF И, скорее всего, вам так чаще всего приходится делать Если вдруг у вас VRF есть, то, соответственно, для того, чтобы посмотреть таблицу маршрутизации определенного VRF Команда будет showiproadvrf И дальше вы заказываете отображение таблицы вот именно того VRF, который вас интересует Например, вы сделали VRF Customer A Значит, showiproadvrfcustomer A С выводом showiproad на самом деле можно будет поиграть Будете ли вы работать с глобальной таблицей Или будете ли работать с таблицей маршрутизации определенного VRF Можно этот вывод будет определенным образом отфильтровать Во-первых, можно заказать отображение только одного маршрута Если вы указываете IP-шник сети, то, соответственно, ищется в таблице маршрутизации запись Соответствующая ровно тому IP-шнику, который вы ввели, и классовой маске Вот если вдруг такого нету, то система скажет Извините, вот такого вывода, который вы заказали, мы вам дать не можем

Но если вас интересует конкретный маршрут, который вы точно знаете, что есть таблица И маска у него просто не классовая, то вы должны будете ее написать Например, вот если у нас было бы не 100, но с 21685.0, там 24 маска, была бы там 25 маска То мы должны были бы сказать 255, 255, 255, 128 И тогда бы система выдала нам результат того, что есть действительно запись в таблице маршрутизации Соответствующая определенной сетке Можно заказать отображение отдельной конкретной записи И она покажет нам список всего, что известно про эту сетку Соответственно, если есть только один NextHop Вот покажется только этот самый один NextHop Если у нас будет 2 NextHop, 3 NextHop до этой сетки Например, будет использоваться OSPF и балансировка OSPF Либо EGRP и балансировка EGRP-шная по равным или неравным маршрутам То вот по каждому NextHop будет показываться отдельная строчка Отдельный, скажем, отдельный блок

Конкретно этот маршрут явно пришел из EGRP Потому что у нас по этому маршруту он посчитал и совокупную метрику В нашем случае 3072 И суммарную задержку 120 микросекунд И bandwidth 1,5 мегабита Ну, то есть никаким иным способом, кроме как получить маршрут по EGRP Или по EGRP Мы бы это не могли узнать Ну вот в нашем случае, да, это действительно EGRP Причем мы даже номер автономной системы знаем EGRP-1 Вот, если мы хотим посмотреть не прям детали-детали каждого маршрута А просто список Можно отфильтровать вывод по каким-то критериям То есть обычно ShowIP Road показывает нам просто отдельные строчки И вот мы можем заказать вообще все строчки Просто ShowIP Road или ShowIP Road VRF, это не суть важно Можем сказать, что нас интересуют маршруты по определенным критериям Во-первых, можно заказать маршруты, которые были получены из определенных источников То есть вот мы можем сказать ShowIP Road SPF Или ShowIP Road BGP

Или ShowIP Road EGRP Или ShowIP Road Static Или ShowIP Road Connected Это все показывает маршруты, которые в таблице маршрутизации имеют определенную буковку То есть если у нас буковка там, допустим, C, то это Connected маршрут Если буковка D, это EGRP-шный маршрут И вот можно с помощью такого вывода отфильтровать только определенные маршруты Полученные из определенного источника В принципе, это в CCNA есть Чего в CCNA нету? Мы можем фильтровать также по префиксам Мы можем сказать, что нас интересуют маршруты, IP-шники и маски которых попадают под определенный аксесс-лист И, соответственно, это будет ShowIP Road, лист и дальше название аксесс-листа Ну или номер, если у вас номерован аксесс-лист Причем, если вы используете стандартный аксесс-лист, то, соответственно, он указывает на вот именно те маршруты, которые вас интересуют В стандартном аксесс-листе мы указываем IP-шник с перевернутой маской И, соответственно, вот мы тем самым ищем фактически, да, IP-шники и прямые маски Если мы хотим искать нечеткое совпадение, мы можем использовать расширенный аксесс-лист

Который будет нам аксесс-листом отбирать отдельные IP-шники, а аксесс-листом отбирать отдельные маски И, соответственно, вот здесь вот мы будем с помощью расширенных аксесс-листов иметь возможность сказать Нас интересуют такие префиксы в таблице маршрутизации, IP-адреса которых попадают под вот такое условие, а маски под другое И здесь, кстати, вот если вы будете такую штуку использовать, порождаются всякие забавные конструкции, которые людей, которые видели аксесс-листы только на CCNA, немножко будоражат Типа можно сделать строчку, которая будет иметь вид Пермит, пермит, пермит Допустим, 100, ну давайте, 10, 0, 0, 1, 0, 0, 0, 255, 255, 255, 255, 0, 255, 0 И смазка 0, 0, 0, 0, 0 Вот люди, которые говорят, что вот это вот такое, откуда оно вообще взялось в качестве талона Ну вот оно как раз для таких вот задач, когда нам нужно отобрать определенные IP-шники И мы хотим указать, что нас интересует определенные IP-шники, определенные маски

И мы хотим задать условия для них Что маска может быть вот такой или какой-то вот иначе Но мы хотим определенные задания, сравнение И IP-шник тоже может быть вот такой с вот такими вот отклонениями Вот, да, если вдруг вас это заинтересует, вот можно такие штуки сделать Например, вы знаете, что у вас есть сетки определенного филиала, которые попадают под определенный аксесс-лист То есть у вас есть аксесс-лист, в который отбираются с сетки определенного филиала. Вот вы можете сказать show.ip.road.list.филиал1. И у вас сразу все маршруты того филиала отображаются. Так, show.ip.road.ip.address даст вывод только в том случае, если в таблице маршрутизации есть точное соответствие. Да, если вы указываете show.ip.road.1001, а в таблице маршрутизации есть 10000-30, вывод должен быть пуст. По-моему, так. Давайте прям проверим, чтобы далеко не ходить. Меня каждый раз терзают сомнения, когда я это рассказываю, потому что на самом деле это нелогично. Но тем не менее проверить мы это можем.

Так, это мой 15-й роутер. У меня есть show.ip.road. Например, у меня есть сетка 101001.10 по 24-й маске. Вот если я сейчас скажу show.ip.road. 10.0.1.1.1. Да, она ищет айпишник. Да, я вам наврал. Я вам наврал. Он ищет как раз, если вы указываете только айпишник, он ищет лучшее совпадение. Он показывает лучший маршрут. Вот. И как раз он здесь показывает, что вот лучший маршрут для айпишника 10.1.1.1 будет 10.1.1.0, известный через 10.2.2.2. Так. Папапапапам. На самом деле я хотел консольку вам чуть попозже показать, когда хотел показать вот следующую штуку. Show.ip.road. И вы можете указать не то, в какую сетку попадает определенный айпишник, а сделать более интересную вещь. Вы можете указать айпишник и маску сети

и добавить слово longer prefixes. Смысл в том, что если вы указываете айпишник и маску, то он ищет строгое совпадение. А вот если вы укажете longer prefixes, то он показывает все подсети, которые в таблице маршрутизации есть для определенной сети. То есть вот в нашем случае в таблице маршрутизации есть 10.1.1.0 по 24 маске. Если я сейчас покажу show.ip.road.10.1.0.0 по маске 255.255.0.0. То есть по 16 маске прошу показать. Он мне говорит, нет такой сети в таблице, требуется строгое соответствие. Вот если я укажу longer prefixes, то, соответственно, он покажет все дочерние сети для той сетки, которую я указал. Это очень полезная вещь. Как раз один из примеров, если у вас правильно задизайненная сеть, все сети определенного филиала попадают под какую-то одну большую сетку,

то мы вот как раз указываем агрегирующую сетку и нам показывают все отдельные компоненты этой сети. То есть я заказал в команде show.ip.road показать 16 сетку и все ее отдельные компоненты. И мне показали компонент 10.1.1.0 по 24 маске. Так, что здесь еще? А, собственно, все. То есть про show.ip.road можно вот таким вот образом с ней играть. Можно access-листами отбирать те маршруты, которые вас интересуют. Можно указывать longer prefixes и можно работать с VRF-ами.