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

Следующий модуль будет посвящен маршрутизации в целом. То есть у нас вообще-то курс посвящен маршрутизации, но мы все к нему как-то подходим к этому процессу с разных сторон. То посмотрели, какие проблемы есть в маршрутизируемых сетях, то посмотрели на то, между чем мы при маршрутизации будем перекладывать пакеты. Ну вот уже почти дошли до самого процесса маршрутизации. Для начала замечу, что изначально IP, который 791 RFC, он указывал, что да, у нас есть процесс принятия, что у нас есть процесс перекладывания пакетов между разными канальными средами, но он не указывал, как именно должен процесс происходить. То есть RFC 760 и его наследник 791, которые появились там в конце 70-х, в начале 80-х годов, он просто говорил, а давайте мы как-нибудь это будем делать. То есть не специфицируя, как именно.

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

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

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

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

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

когда у нас там случилась авария, мы должны пустить пакеты по какой-то другой трассе. Не было даже указания в стандарте, как именно пакеты должны обрабатываться. И вот в конце 80-х появляется стандарт RFC 1812, как именно роутеры в IP должны себя вести. То есть что именно они должны делать для того, чтобы маршрутизировать пакеты в сеть назначения. Было предложено два варианта, ну точнее было предложено много вариантов, но основными фактически стали два. Это destination-based routing и policy-based routing. В destination-based мы смотрим на IP-шник получателя, и мы говорим, все пакеты, идущие до этого IP-шника, мы отправляем по определенной трассе, невзирая ни на какие другие поля. То есть это то, как работает обычная таблица маршрутизации. Берем IP-шник получателя, засовываем в таблицу, находим выходной интерфейс, отправляем в этот интерфейс. Недостатком этой схемы является то, что нужно пополнить таблицу маршрутизации. То есть на всех роутерах у нас должна вот эта таблица быть полной, адекватной, целостной и актуальной.

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

раздаете разным делегатам, дальше делегаты пилят свои блоки на части, раздают их своим делегатам. И все это дело здорово хлопывается, здорово превращается в небольшое количество крупных сетей в таблице маршрутизации у всех. Ну и плюс кучу какой-то мелочевки, которая нужна только в пределах своего блока. Ну, у destination-based routing есть ряд плюсов и ряд минусов. Минусы – это то, что требуется поддерживать таблицу в актуальном состоянии, требуется хороший адресный план, то есть адресация, которая используется в больших сетях, должна быть не анархичной, она должна быть какой-то логической, что если мы берем сначала блоки адресов, раздаем странам, в пределах страны мы раздаем отдельные блоки адресов провайдерам. Дальше провайдеры раздают эти блоки адресов уже своим клиентам, но все клиенты одного и того же провайдера будут получать адреса из одного и того же блока, и поэтому наружу провайдер может анонсировать только весь блок целиком,

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

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

Она, соответственно, появляется тоже в таблице маршрутизации. Вот мы взяли IP-адрес 112.168.1.1, повесили на интерфейс. Ну, какой-то на интерфейс, мы здесь не видим какой. Например, на гигабитный интерфейс. И у нас коннект-от сетка сразу появляется. Вот. IP-адрес 112.168.1.1. Повесили по 24-й маске. И делаем show IP-road. И у нас действительно эта сетка есть. Сетка connected, directly connected на интерфейсе гигабит 0.0. Все как бы честно. Вот. Если вы добавляете статические маршруты, вы их добавляете с помощью команды IP-road. Здесь есть нюанс. Именно цискоспецифический нюанс, заключающийся в том, что когда вы добавляете запись в таблицу маршрутизации с помощью команды IP-road, эта запись не, безусловно, попадает в таблицу. Она попадает в таблицу только если это имеет смысл. То есть, например, нет смысла добавлять таблицу маршрутизации в RIB routing information base.

То есть, вот это вот RIB это, Routing Information Base. Это, по сути, таблица маршрутизации. Вот нет смысла добавлять в нее какие-то записи, которые потом нельзя будет использовать. Например, если вы пытаетесь добавить в таблицу маршрутизации строчку IP-road 100.0.1 по маске 255.255.255.255.100.0.2. Причем, что вы знаете, что вот у вас таблица-то пустая, эта строчка не добавится. Она в конфиге останется, а в таблице маршрутизации она никак не отреагирует. То есть, она не будет добавлена и ничего с ней не случится. Вот рядышком можно еще там 101.1.1 добавить маршрут по 32 маске через 100.0.0.1. Тоже ничего не случится. То есть, вот этого IP-шника в таблице маршрутизации у нас нет. Мы, конечно, добавили маршрут до этого IP-шника, но через несуществующий адрес 100.0.0.2. И как следствие, да, получается, что этого адреса по факту тоже нет.

Поэтому обе эти команды, они примутся, они будут корректно синтаксически, они в конфигурацию попадут. Showrun вам их покажет. А ShowIP-road покажет, что этих записей нет. Вот ShowIP-road действительно так нам и показывает, что там пусто. Только Connected-сетка есть. Но, если вы добавите, например, вот этот вот IP-шник в таблицу маршрутизации, как он будет резолваться, то эти строчки у вас тоже попадут в таблицу маршрутизации. То есть, вот в нашем случае мы сначала добавили 100.0.0.1 доступно через 100.0.2, 101.1.1 доступно через 100.0.1, то есть через вот этот вот. И потом указываем, что сетка 100.0.0, ну, например, по 128-й маске доступна через 112.168.1.2. Вот это вот адрес, который у нас в таблице маршрутизации есть. Он Connected-сетка, Gigabit 0.0.0. Поэтому эта команда отработает. Эта команда будет доступна в таблице маршрутизации. ShowIP-road нам ее покажет, что она действительно сработала.

Она скажет, что все IP-шники, начинающие на 100.0.0 и дальше от 0 до 127, они доступны. У нас уже есть указание, соответственно, что 100.0.1 доступно через 100.0.2. Поэтому вот эти вот команды, да, они по факту останутся в конфигурации. Они не будут добавлены в таблицу маршрутизации, потому что... Где они? Вот эта вот команда не будет добавлена в таблицу маршрутизации. Она бессмысленна. Смотрите. Мы указываем, что все IP-шники, начинающиеся на 100.0.0, доступны вот в этом направлении. Если мы скажем, что IP-шник 100.0.1 доступен через 100.0.2, а где доступен 100.0.2, а там же, где вот эта вот вся сетка 100.0.0. Так получается, что IP-шник 100.0.1 попадает в эту же сетку 100.0.0.

То есть эта строчка просто не имеет смысла. Она говорит, если ты хочешь добраться до 100.0.1, ты не ходи по вот этой вот более общей сетке, ты ходи по более узкой сетке 100.0.1 по 32 маске, но ты по факту попадешь в тот же самый маршрут. Поэтому, что вы добавите в таблицу маршрутизации эту сетку, что вы не добавите в таблицу маршрутизации эту сетку, ничего по факту не изменится. Эта строчка по факту не отработает вот это вот, даже если вы скажете, как добраться до узла 100.0.2. Она не будет иметь смысл. Поэтому мы добавляем сетку 100.0.0 по 25 маске. Она добавляется в таблицу маршрутизации. Вот она. Вот эта вот строчка тоже имеет смысл, потому что это 101.1.1. Это не айпишник вот этой сети 100.0.0 по 25 маске. Поэтому эта строчка тоже срабатывает. Она автоматически добавляется. То есть система поймет, что в конфиге было что-то, чего в таблице маршрутизации не было раньше.

А сейчас оно появилось. Оно теперь имеет смысл. И вот эта вот строчка тоже появляется здесь. Ну и Directly Connected сетка тоже, соответственно, есть. Как бы нам сделать так, чтобы у нас вот эта вот сетка тоже появилась? 100.0.0.1 по 32 маске через 100.0.2. Нам надо каким-то образом сказать, соответственно, что вот эта вот 100.0.0.1 – это не то же самое, что и вся остальная сетка 100.0.0. То есть нам надо сделать так, чтобы 100.0.0.2 был доступен как-то иначе. Чтобы его NextHop отличался от вот этой вот всей сетки 192.168.1.2. И поэтому мы указываем, что у нас есть IP Road. Указываем, как доступен вот этот вот IP-шник 100.0.0.2. И говорим, он доступен через что-то еще. Давайте я попробую нарисовать всю эту схему, потому что я понимаю, что, да, воспринять ее глазками может быть довольно тяжело. У нас есть сеть 192.168.1.0 по 24 маске.

Да. Мы говорим, что если мы хотим дойти... Сейчас здесь сотру все. Вот. Стер. Если мы хотим дойти до IP-шника 100.0.0.1, вот именно до этого IP-шника, надо ходить через 100.0.0.2. Мы пытаемся сказать, что у нас есть 100.0.0.1. Вот. И нам надо куда-то показать, в какую-то сторону, как добраться до этой сети. Вот IP-шника 100.0.0.2 в сети нет. Поэтому мы не добавляем эту строчку в таблицу с маршрутизацией. Мы не можем показать, в какой стороне сидит NextHop. У нас маршрута до NextHop нет. Вторая строчка. 101.1.1. 101.1.1. Соответственно, она доступна через 100.0.0.1. Тоже самая история. Мы не можем добавить этот маршрут, потому что непонятно, в какую сторону NextHop добавить. Вот. У нас вот эти вот NextHop, они не резолвятся в таблице с маршрутизацией, поэтому эти строчки не добавляются в таблицу.

Дальше. Как только мы добавляем вот эту вот строчку IP-ROWD 100.0.0.0 по 25-й маске через 192.168.1.2, мы говорим, у нас есть коннект от вот этого IP-шник 112.168.1.2. Поэтому вся вот эта вот сетка 100.0.0.0. Так, пардон, не вот это. Вот эта вот сетка 100.0.0.0.0. По 25-й маске. Она включает в себя 100.0.0.1. Она доступна через айпишник 192.168.1.2 Мы этот айпишник знаем, где сидит, потому что он у нас connected То есть вся вот эта сетка становится доступна В частности, доступна становится и адрес 100.0.0.1 Который доступен через 100.0.2 В частности, доступна же становится и 100.0.0.2 То есть на любой из этих адресов мы можем направлять пакеты Они будут отправлены в сторону 192.168.1.2

Дальше Если мы добавили вот эту вот строчку Пусть даже раньше мы ее добавили То, соответственно, у нас получается Когда мы хотим доставить трафик до 1.1.1 То мы должны трафик направлять через 10.0.0.1 До него мы теперь можем добраться 100.0.0.1 У нас получается вот эта сетка тоже будет доступна 100.0.0.2 нет смысла добавлять в таблицу маршрутизации Несмотря на то, что команда такая есть Что 100.0.0.1 доступна через 100.0.0.2 Маршрут, который указывает на всю сетку целиком Совпадает с маршрутом на вот отдельную сетку, которую мы хотим добавить Поэтому этот маршрут просто бессмысленен на данный момент Поэтому эта команда в таблице отсутствует А в конфигурации она все равно присутствует Но в таблицу она не добавляется, потому что она на данный момент бессмысленна У нас все равно маршрут есть на более общую сетку Который совпадает по смыслу с более частным маршрутом

Дальше мы указываем вот такую вещь IP-road 100.0.0.2 255.255.255.255.255.100.1.1 Что мы тем самым делаем? Мы говорим, чтобы добраться до сети 100.0.0.2 Надо пойти через 100.1.1.1 То есть вот так вот И, соответственно, оттуда уже вот так Это получается, что маршрут не такой же, как во всю остальную сеть Поэтому как только мы прописали, что до 100.0.2 можно добраться вот таким кремным образом Через внешнюю какую-то сетку Эта команда отработала У нас появляется 100.0.0.2 И у нас заодно появляется маршрут 100.0.1 И в таблице маршрутизации у нас все вот эти вот маршруты уже появляются Они все теперь имеют смысл Они все указывают в разные стороны Наркомания нафиг Я для чего вам это рассказываю? Для того, чтобы показать, что маршрут может добавляться в зависимости от каких-то условий То есть не сразу, как только вы добавляете строчку в конфиг Она попадает в таблицу маршрутизации

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

Они указывают в разные стороны Вы можете получить интересный сценарий Циско не позволит вам сделать маршруты, которые будут содержать в себе рекурсию Да, рекурсия это штука, которой вы говорите, например, что 10.001 доступен через 10.002 10.002 доступно через 10.001 Вот это классическая рекурсия Циско вам такое не даст сделать Она скажет, извините, соответственно, это запрещено Второй маршрут просто не добавится Но если вы будете делать по-хитрому Вы можете заставить вашу циско добавить маршрут, который будет рекурсивный Например, это можно сделать через способ, который я как раз на слайде показал Вы сделаете все маршруты, которые будут необходимы Но с помощью дополнительного служебного маршрута Сделаете время на ситуацию, в которой рекурсии нет

То есть, например, есть сетка 100.00 по 25 маске через 10.002, 168.1.2 100.001, 100.002, 101.1.1 Которые все смотрят, получается, через каких-то соседей А потом вы убираете служебный маршрут Вот этот вот Убираете его И у вас получается классическая рекурсия Вот она То есть, добавить с нуля такие маршруты Циско вам не даст Но ее можно обмануть Ее можно обмануть Циско не проверяет, что если вы маршрут какой-то удаляете Что он не порождает рекурсию Давайте попробуем Я сейчас просто покажу, как это выглядит Так, вот мой роутер Давайте я только другой возьму Не тот, который у меня уже настроен А какой-нибудь другой Например, роутер 2 Откажусь от начальной настройки Нет, роутер не зависнет Роутер просто не будет отправлять пакет, который он поймет, что на самом деле идет через рекурсивный маршрут

И он отдаст сообщение на журнал, на консоль Ну и в системный журнал тоже, что обнаружена рекурсия При этом в таблице маршрутизации эта рекурсия будет Enable Conf T Так, нам понадобится какой-нибудь живой IPшник Интерфейс Ethernet 0.0 IP адрес Так И no shutdown Вот у меня есть сейчас живой IPшник И я сейчас буду делать странные вещи Первое Я пытаюсь указать, что у меня есть какой-то маршрут, который есть в конфигурации, но нет в табличке Сейчас моя табличка show.ip.road содержит только connected маршрут Вот он, connected маршрут, который у меня появился по факту назначения IPшника на интерфейс

Так Указываю IP Road 10 1 1 1 255 255 255 205 255 10 Так 2.2 2.2 IPшник 10.2.2.2 не резолвается в таблице маршрутизации У меня там только 10.00 по 24 маске Поэтому IP Road Ничего не показывает Я строчку вот эту вот в конфигурацию ввел. Вот она. Она там появилась, честное слово. Do show run include road. Вот она там есть. А в конфигурации есть, а в маршрутизацию, в таблицу маршрутизации она не попала. Дальше. Я могу сделать так, чтобы у меня через этот маршрут был известен какая-нибудь другая сетка. IP road 10, 3, 3, 3, 255, 255, 255, 10, 11, 11.

Эта строчка точно так же в конфигурации попадает, а в таблицу маршрутизации нет. Потому что, несмотря на то, что вот эта штука у нас как бы в IP road прописана, в таблице маршрутизации она по-прежнему не резолвится. Вот здесь вот. У нас, соответственно, она не попадает. Поэтому эта строчка тоже, она уходит в пустоту. Вот они в конфиге есть. Таблица маршрутизации по-прежнему пусто. Дальше. Если я хочу, чтобы эти строчки появились, мне надо сделать так, чтобы резолвился IP-шник 10.222. IP road 10.222. 255, 255, 255, 255, 255. 10, например, 0, 0, 2. Я указываю, что 10.222 будет доступен через IP-шник, который в коннект-сетку у меня входит. Поэтому у меня появляется резолвивающийся IP-шник вот этот. Как следствие, у меня начинает резолвиваться IP-шник 10.1.1.1, через который ходит трафик на 10.3.3.3.

Смотрим, что у нас получилось. Все три строчки в итоге добавлены в таблицу маршрутизации. Раньше две из них были недоступны, потому что IP-шник NextHop не резолвился. Сейчас, соответственно, они стали резолвиваться, поэтому в таблицу маршрутизации они все добавились. Нюанс. Нюанс заключается в том, что по факту, если мы будем отправлять трафик на 10.3.3.3 или на 10.2.2.2, или на 10.1.1.1, они все равно все пойдут на один и тот же адрес. Ну, в смысле, в сторону MAC-адреса 10.0.0.2. Смысл в таблице маршрутизации заключается в том, что мы должны найти выходной интерфейс, и мы должны найти канальный адрес того соседа, которому мы должны отправить трафик. В случае с Ethernet это будут MAC-адреса. По факту вот эти IP-шники, они вообще нигде не фигурируют. Мы можем использовать такие адреса, которые вообще нигде никак не присутствуют. Сейчас, если я буду отправлять пакеты на адрес 10.3.3.3, по факту наличие вот этого IP-шника 10.1.1.1 в сети вообще не обязательно.

Потому что, по факту, когда я буду выполнять запрос к таблице маршрутизации, как мне достать 10.3.3.3, что моя таблица маршрутизации будет делать? Она выполнит поиск лучшего маршрута для 10.3.3.3, маршрута с самой хорошей маской, самый большой, самый специфичный, скажем, маршрут. Найдет вот этот вот маршрут и скажет 10.3.3.3 по 32 маске лучше некуда, доступен через 10.1.1.1. Но 10.1.1.1 без интерфейса, а нам нужен выходной интерфейс. Поэтому мы говорим, а где доступен 10.1.1.1.1? И система говорит, окей, давай поищем в таблице маршрутизации во всех строчках, кроме вот этой вот, которая у нас только что получилась, как добраться до 10.1.1.1.1. Находит, соответственно, среди всех оставшихся строчек лучший маршрут для вот того NextHop и говорит, для 10.1.1.1 по 32 маске самый лучший NextHop будет 10.2.2.2. Он опять не обязан быть в таблице в мире. То есть такого IP-шника можно никому его не давать. Это сугубо нарисованный IP-шник, который существует только в представлении в таблице маршрутизации моего роутера.

Дальше я говорю, а вот как добраться до этого-то IP-шника? И система говорит, окей, давай переберем все остальные строчки, за исключением тех, которые вот мы уже только что проверили. Находит, соответственно, лучший маршрут для этого 10.2.2.2 и говорит, лучше всего направить трафик через 10.0.0.2 и опять без выходного интерфейса. Окей, а как до него лучше добраться? И вот тут только мы находим Connected маршрут с указанием интерфейса Ethernet.0. По факту трафик для того, чтобы отправить по IP-шнику в сторону IP-шника 10.3.3.3, будет уходить в сторону интерфейса Ethernet.0.0, в сторону MAC-адреса соответствующего узлу 10.0.0.2. Именно его мы будем резолвить с помощью протокола ARP. Все вот эти вот 10.1.1.1, 10.2.2.2, они никоим образом не проверяются их существование. То есть абсолютно никаким. Можно использовать абсолютно любые адреса. Ну, да. Если вдруг вам это будет зачем-то нужно. Вот если действительно 10.3.3.3 будет доступен через 10.0.0.2,

то трафик до него уйдет и, возможно, даже ответы вернутся. Вот эта вот штука, она как раз и будет называться рекурсивный запрос к таблице маршрутизации, когда мы задали вопрос, где сидит вот этот адрес? Он говорит, а он там. А где сидит этот вон там? А вот здесь. А где сидит этот вот здесь? А вот тут. А вот этот тут вот это где? А вот тут вот этот вот Connected Interface. Мы на курсе будем с вами рассматривать как раз примеры того, как Cisco будет строить такие таблицы. То есть для нее вот это вот, это не какая-то умозрительная головоломка, которую прикольно посмотреть. Вот то, что я вам сейчас показываю, это абсолютно нормальная ситуация, когда у вас протоколы динамической маршрутизации будут добавлять в таблицу маршрутизации маршруты с прописанным IP-шником NextHop, и до этого IP-шника NextHop не будет указан маршрут. Вы должны будете повторный запрос к таблице маршрутизации задать и спросить, а где он? И может быть, вам вернется позитивный результат, а может быть, не вернется. Поэтому да. С Default Road проблема здесь будет такая, что если у вас даже есть маршрут по умолчанию,

и какой-то пакет попал под маршрут по умолчанию, и вам говорят, маршрут по умолчанию доступен через вот такой вот IP-шник, то, соответственно, на самом деле NextHop для маршрута по умолчанию в таблице маршрутизации тоже будет искаться. И он тоже будет искаться по таблице за минусом того маршрута, который изначально самый первый попал. То есть когда вы добавляете маршрут по умолчанию, вы не можете добавить маршрут по умолчанию через IP-шник, который сам по себе резолвится через маршрут по умолчанию. То есть вот IP-road 0.0.0.0 по маске 0.0.0.0 через адрес, не знаю, 3.3.3.3 или 2.2.2.2. Команда сработает, но в таблицу маршрутизации он не добавится. Вот это вот 2.2.2.2.2 не резолвится в таблице маршрутизации. Вот. Do Show IP-road. Если бы этот маршрут добавился, да, тогда бы 2.2.2 через сам дефолт бы резолвился. Но вот он не резолвится на тот момент, когда мы пытаемся добавить такой маршрут.

Еще один момент заключается в том, что нет смысла добавлять маршрут, который ничего не меняет. То есть, например, у меня есть... Что у меня здесь есть? Ну вот этот вот маршрут 10.1.1.1 по 32 маске. Давайте я добавлю IP Road 10.1.1.0 по маске 255.255.0 в сторону того же самого NextHop 10.2.2.2. Этот маршрут уже кое-что изменит. Но получится, что вот этот вот маршрут ничего не меняет. Поэтому маршрут 10.1.1.1 по 32 маске из таблицы маршрутизации уйдет. Он не нужен, он лишний. До шоу IP Road. Так. Надо его удалить. Этого перья передобавить.

Так, где он есть? Есть там. Вот я его удалил. И я сейчас пытаюсь его добавить. И вот, по идее, он сейчас у меня должен проигнорировать его. Не проигнорировать. Собака. Собака страшная. Должен проигнорировать, потому что этот маршрут бессмысленный. То есть он абсолютно полностью совпадает с оригинальным. А, я туплю. Простите. Не то надо показывать. Да, пардон. Так, это надо удалить. Нет смысла добавлять маршрут, который будет доступен через сам себя. Или через какой-то более общий маршрут. То есть вот если я сейчас скажу, что сетка 10.1.1.1 будет доступна, например, через 10.1.1.2. Вот такой вот маршрут не добавится.

To show IP Road. Да, вот его нет. Смотрите. В чем смысл вот этой вот команды? Она говорит, что до IPшника 10.1.1.1 надо ходить через IPшник 10.1.1.2. А как добраться до 10.1.1.2? А вот у нас есть сетка 10.1.1.0 по 24 маске, которая доступна через что-то там. Но смысл в том заключается, что вот эта вот сетка 10.1.1.1, она тоже доступна там же, где и 10.2.2.2. Поэтому вот этот вот маршрут, он вообще ничего не меняет. Вот этот вот маршрут, простите, ничего не меняет. Поэтому мы указываем, что вот эта вот сетка доступна через IPшник, который находится фактически там же, где находится вся вот эта вот сетка. Вот такие вот простые примитивные проверки в CISC есть, которые позволят не добавлять в таблицу маршрутизации те маршруты, которые не имеют смысла. Нет смысла добавлять маршрут, который доступен через NextHop, который находится там же, где и вся основная сеть. Нет смысла добавлять маршрут, который не резолвится. Ну и есть еще несколько других простых правил, которые тоже позволят вам немножко сократить количество мусоров в таблице маршрутизации.

Так. Есть замечательная статья на Хабре. Я рекомендую вам ее прочитать. Она называется «Хорошо ли вы знаете статическую маршрутизацию?» Или «А вы хорошо знаете статическую маршрутизацию?» вопрос. Сейчас я вам на нее ссылку дам. Секунду. Так. Да, вот, соответственно, ссылка. Если вдруг будет желание, прочитайте ее, пожалуйста. Она интересная. Она не про динамическую маршрутизацию, где много своих заморочек, но она именно про особенности построения таблицы маршрутизации в оборудовании ЦИСКО. Там много есть интересных, неочевидных моментов. Она не очень сложная. Читается как такой легкий детектив в каком-то смысле, да. Но я рекомендую вам ее почитать. Так. В BGP вроде часто такое встречается. Да, это абсолютно норма, когда мы работаем с BGP. BGP притаскивает маршруты, у которых NextHop смотрит непонятно куда. И этот NextHop должен в таблице резолвиться. Может быть такое, что этот NextHop будет притащен сам по себе через какой-то другой протокол.

Например, через OSPF. И у вас получится, что BGP притащил маршрут, добавил его в таблицу. И этот маршрут доступен через IPшник, который зависит, соответственно, от OSPF. И может быть такое, что OSPF маршрут не притащил, и тогда BGP притащил что-то, а добавить в таблицу маршрутизации не может. Поэтому вот то, что мы сейчас с вами прошли, это не просто загадки для ума, это действительно суровая реальность того, как Cisco строит таблицу. Так. Если есть маршрут 102-168-00-24 через 1-1-1 и 102-168-01 по 32-й маске через 2-2-2-2, куда пойдет пакет? Выберется Best, этот самый, Most Specific Route. То есть маршрут с наилучшей маской, с наибольшей. Так, да. Таблицу маршрутизации можно пополнить разными способами.

Самый простой – это статический маршрут или повесьте IPшник. Ну, естественно, что наиболее интересно – это использовать динамическую маршрутизацию. OSPF, LingerP, BGP, в общем, это то, что у нас дальше там на курсе будет. Таблицу маршрутизации посмотреть можно ShowIP Road. Там показывается большая легенда, и дальше идут сами маршруты. Так, давайте мы с вами на этом сегодня остановимся. И завтра, с самого начала занятия, будем обсуждать уже детали того, как можно пополнить табличку. На сегодня все. Спасибо за внимание. Пока-пока. Субтитры сделал DimaTorzok