Динамическая маршрутизация

Продолжаем наш курс iSindi 2. Все предыдущие темы, которые мы с вами разбирали, про VLAN, Trunk, Spanning Tree, FHRP, это всё касалось коммутируемых сетей. И в какой-то момент мы сказали, что мы научились строить коммутируемые сети, надёжные, устойчивые, и если у нас есть способ передать кадр Ethernet от одного абонента до другого в пределах одного широковещательного домена, мы можем это сделать хорошо и приятно. Но в какой-то момент мы отказываемся от возможности сделать вообще всё на коммутации Ethernet, потому что иногда у нас есть какие-то среды, которые не позволяют нам взять и запихать всё в один огромный VLAN. И, соответственно, нам надо будет либо перекладывать данные между VLAN-ами, либо перекладывать данные между какими-то интерфейсами, которые вообще не имеют Ethernet-овскую природу. Например, тот же самый ADSL какой-нибудь

или PPP-линки. И, соответственно, нам нужно будет решать вопросы, как промаршрутизировать трафик, который у нас будет идти между разными каналами, между разными линками. И динамическая маршрутизация — это механизм, который позволяет нам решить эту задачу в масштабе сети небольшого или даже среднего предприятия, когда у нас появляется много маршрутизаторов. И на этих маршрутизаторах нужно будет решать задачу синхронизации таблиц маршрутизации. Какая задача вообще будет у динамической маршрутизации? Зачем мы вообще про неё говорим? Во-первых, если у нас есть какие-то маршрутизаторы, на каждом из них, конечно же, есть таблица маршрутизации, и эта таблица маршрутизации должна быть плюс-минус совпадающей на всех маршрутизаторах, потому что если у нас есть какая-то сеть, то про неё должны знать все узлы в топологии.

Если вдруг эти узлы будут посылать трафик в сторону этой сети, то на любом маршрутизаторе у нас должен быть маршрут в сторону этой сети. Поэтому в сети предприятия, так или иначе, маршруты в каждой таблице маршрутизации должны быть плюс-минус одни и те же. Если у нас какого-то маршрута не хватает, и на маршрутизатор приходит пакет, который адресован в сеть, до которой маршрута нету, то пакет у нас будет отброшен или направлен не в том направлении. У меня был случай, когда я работал в компании на проекте, и там было достаточно много маршрутизаторов. Эти маршрутизаторы были подключены друг к другу через туннели. По сути, как провода. Маршрутизаторов было много, сетей за спинами у этих маршрутизаторов тоже было много, туннели друг на друга строились достаточно хаотично, и всё это дело настраивалось вручную. Мы на CCNA1 с вами уже делали статическую маршрутизацию с помощью команды IP route.

И если у вас маршрутизаторов много, за спиной у этих маршрутизаторов сетей много, то вы на каждом маршрутизаторе должны прописать актуальный маршрут до каждой сети в предприятии. И это может превратиться в очень сомнительное удовольствие, особенно если этими маршрутизаторами управляют люди из разных команд. У вас может быть такое, что одним маршрутизатором управляет один администратор, другим — другой, и вы на свои маршрутизаторы хотите сказать, что у вас появилась новая сеть. Вы со своей стороны должны прописать маршруты на все сети, которые у вас есть, и вообще на всех остальных маршрутизаторах вы должны будете прописать обратный маршрут до вашей сети, которую вы только что добавили. Если вы идёте к одному администратору и говорите, пропиши на меня маршрут, он, может быть, даже и пропишет этот маршрут, но надо будет убедиться, что на всех маршрутизаторах в топологии маршрут тоже будет прописан. И причём он будет прописан именно в правильную сторону. Если делать это вручную, это крайне сомнительное удовольствие,

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

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

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

мы в рамках нашего курса будем рассматривать очень обзорно. Это будут протоколы класса EGP, Exterior Gateway Protocol. Там среди этих протоколов аж целый один, который в природе вообще сейчас существует. Раньше были другие, но сегодня остался только один. В зависимости от того, как будут работать эти самые протоколы, мы их будем делить на два больших семейства, на два вида. Это протоколы на основе алгоритма Distance Vector. Это будут протоколы RIP, EIGRP, BGP. Последние два иногда называют специальными страшными ругательными словами. Например, про EIGRP говорят, что это гибридный протокол или Advanced Distance Vector Protocol. У Cisco есть на то свои маркетинговые соображения, но по большому счёту EIGRP — это абсолютно классический Distance Vector протокол. И BGP тоже протокол, который принято называть Path Vector, но он от этого менее Distance Vector не становится. Да, он действительно будет передавать информацию не совсем про маршрут,

он будет передавать информацию про пути, а дальше будет говорить, что по этому пути доступны определённые маршруты. Единица передачи информации для него будет не маршрут, а путь. Поэтому, когда мы говорим про то, что какая-то сетка доступна, классический Distance Vector протокол говорит: такая-то сеть доступна на таком расстоянии и даёт нам вектор, направление, в котором доступна сеть. У BGP проблема, почему его называют Path Vector протоколом, в том, что он говорит не про сети, а про пути доставки трафика. Но по сути своей, если мы вспомним, что BGP всё-таки нужен для того, чтобы синхронизировать маршруты, и посмотрим на то, как он работает, выяснится, что это всё-таки Distance Vector протокол. Противоположностью им будут протоколы с отслеживанием состояния каналов связи. Это протоколы, основанные на алгоритме Link State. Здесь будет целых два протокола — OSPF и IS-IS, а других-то особо и нету. И в рамках нашего курса мы будем рассматривать только один из них — OSPF.

Это протокол, который не передаёт маршруты. У него единица передачи информации — не маршрут. У него единица передачи информации — это кусочек таблицы топологии, то есть то, как устроена сеть. И когда все роутеры поделятся со всеми своими соседями всеми кусочками таблицы топологии, они смогут построить полную карту топологии, по этой топологии просчитать кратчайшие маршруты между роутерами. И дальше только в этот момент они скажут: после того как просчитали все кратчайшие маршруты, мы можем в таблицу маршрутизации, на основе этой самой таблицы топологии, на основе кратчайших маршрутов, поставить указания, какие сети существуют в топологии и как до них лучше всего добраться. Разница между дистанц-векторными протоколами и Link State протоколами заключается именно в том, чем обмениваются маршрутизаторы. Дистанц-векторные протоколы обмениваются маршрутами. Link State протоколы обмениваются кусками карты сети. Начнём, пожалуй, с первых. Дистанц-векторные протоколы периодически, как правило, по таймеру, но здесь возможны варианты,

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

Например, вы можете сказать: я знаю эту сеть за 10 копеечек и за 10 мегабит. И у вас вектор будет состоять из двух частей. Это стоимость в копеечках и скорость, с которой вы знаете этот маршрут. Дальше вы передаёте соседу указание, как вы знаете эту сеть. Сосед говорит: я принял указание, что мой сосед знает эту сетку, следовательно, я тоже знаю через него эту сетку. Если я вижу, что он знает эту сеть за 10 копеечек, и я знаю его самого за 10 копеечек, я беру и складываю два этих вектора. То, за сколько он знает эту сетку, и то, за сколько я знаю его. Я складываю два вектора по правилу сложения векторов и получаю результирующий вектор. Я знаю эту сетку, в нашем случае, за 10 плюс 10 копеек — за 20 копеек. Дальше это всё рассылается уже следующим соседям. Опять же, каждый маршрутизатор рассылает вектор, как он знает сетку лучше всего. Если вектор рассылался в виде просто одной метрики, значит, будем рассказывать про копеечки. Если нам сосед рассказал, что знает за 10 копеечек, за 10 мегабит,

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

но указываем в качестве метрики результирующий вектор, как мы знаем сеть через соседа. В результирующем векторе не видно, через кого вы ходите. Если мы показываем только метрику, сколько копеечек стоит доставить трафик в удалённую сеть, то показывается просто монолитное число: я знаю сеть за 40 копеек, я знаю сеть за 50 копеек. Там не видно, сколько прыжков между роутерами, там не видно, какие каналы связи между ними, насколько они загружены. Просто 50 копеек — и всё. Если мы говорим про Link State протоколы, то Link State роутеры обмениваются не маршрутами, они обмениваются тем, условно говоря, какие у них есть интерфейсы, каких соседей они обнаружили на этих интерфейсах и какие IP-адреса на этих интерфейсах висят. Если у нас есть, например, два роутера, которые запустили на себе Link State протокол, один роутер скажет: я вот так устроен, у меня есть два интерфейса, на одном у меня висит IP-шник 10.0.0.1 по 24 маске,

а на другом интерфейсе я вижу второго соседа, второй роутер. Это роутер R1, а это роутер R2. Роутер R2 скажет: а у меня есть интерфейс, на котором висит IP-шник 10.2.2.2 по 24 маске, и у меня есть связь с роутером R1. Здесь у нас роутер R2, здесь у нас роутер R1. Вот эти два кусочка карты, Если они разрозненные, они показывают только то, как сеть устроена с точки зрения отдельного роутера. Но если все роутеры рассказывают, каких соседей они видят и какие IP-адреса у них на интерфейсах висят, то этой информации достаточно для того, чтобы построить, во-первых, карту, как роутеры между собой соединяются, а во-вторых, какие IP-адреса на них присутствуют, какие connected-сетки на них присутствуют, и это даст нам понимание того, какие сети вообще есть в топологии. В случае с Link-State протоколами

каждый маршрутизатор на основании этих кусочков карты строит общую топологию сети. Из всех независимых кусочков, которые есть, он собирает пазл и строит в итоге общую карту. Все маршрутизаторы из одинаковых кусочков карты с использованием одинакового алгоритма строят в итоге одинаковую топологию. Дальше по этой карте строят карту связи между маршрутизаторами и просчитывают кратчайшие маршруты. В нашем случае роутер R1 знает, что есть роутер R2, он строит до него кратчайший маршрут, говорит: кратчайший маршрут — это через тот интерфейс, на котором мы на него смотрим, и считает стоимость этого маршрута. После того как суммарная стоимость маршрута посчитана, он у себя запоминает: до R2 добраться стоит, допустим, 20 копеечек. После чего, когда он видит, что на R2 есть определённый IP-адрес 10.2.2.2 с маской /24, он говорит: как следствие того, что есть этот IP-адрес 10.2.2.2 с маской /24, connected-сетка — 10.2.2.0/24.

И до этой сетки он говорит: я могу добраться через роутер R2. Интерфейс, которым роутер R2 смотрит в эту сеть, стоит, допустим, 10 копеечек. Маршрут до R2 имеет суммарную стоимость 20 копеечек. Поэтому для того, чтобы добраться до этой сети, я могу сложить суммарный маршрут до R2 плюс столько, сколько стоит сетка на самом R2, и получить итоговую стоимость этой сети. Указание про то, что у кого-то в таблице маршрутизации есть такая сеть, не передаётся нигде. Это есть только в кусочке карты, и этот кусочек карты проверяется в самый последний момент, после того как уже топология сети вся построена. Если говорить про конкретные протоколы, с которыми мы будем работать, мы будем чаще всего сталкиваться с протоколом OSPF. И у OSPF есть одна небольшая особенность. Особенность заключается в том,

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

Но при этом за счёт того, что не вся автономная система будет включена в один регион, она будет разбита на отдельные, не связанные между собой части. Соответственно, каждый роутер будет нагружаться поменьше по сравнению с тем, как он мог бы нагружаться, если бы все роутеры входили в один большой пересчёт. Но для того, чтобы просчитать кратчайшие маршруты внутри маленького региона, ресурсов будет тратиться меньше. А для того, чтобы передавать информацию между этими регионами, будет использоваться фактически distance-vector алгоритм передачи маршрутов. И для того, чтобы не устроить петлю, в такой ситуации Link-State протоколы будут использовать грязные хаки. Грязный хак заключается в следующем. Внутри такого региона, в котором всё считается по-честному, петля нигде не может возникнуть. Кратчайший маршрут по определению не содержит петли. А вот между регионами маршруты никогда не сформируют петлю по одной простой причине.

Регионы между собой, эти по-честному считающиеся куски, соединяются всегда по схеме звезда. Соответственно, один регион имеет специальную особенную роль. Он будет называться backbone, или позвоночник. И к нему будут подключаться все остальные регионы. И трафик между регионами может ходить только через этот регион-позвоночник. И обмен маршрутами тоже может идти только через регион-позвоночник. А между разными регионами напрямую трафик ходить не будет. Это одна из особенностей протокола OSPF. Мы сейчас с ней будем разбираться. Просто надо знать, что OSPF так устроен. И в определённых ситуациях этим механизмом, этой возможностью можно будет пользоваться для решения задачи снижения нагрузки OSPF в очень крупной сети. Впрочем, если у вас очень крупная сеть, возможно, OSPF будет не самым лучшим выбором,

просто потому что он не предназначен для очень крупных сетей. Если у вас очень много маршрутов, очень много сетей, очень много пересчётов топологии между ними, возможно, вам имеет смысл обратить внимание на какой-то протокол, который лучше адаптирован для большого количества маршрутов. Я непрозрачно намекаю на протокол BGP. Это что касалось теоретической части про динамическую маршрутизацию. Мы обсудили, что динамическая маршрутизация нужна, важна, и не мешало бы поговорить про какую-то конкретику. Конкретика будет уже связана непосредственно с протоколами. Мы сейчас будем брать отдельные протоколы и смотреть, как они устроены. Будем брать EIGRP, OSPF и немножко BGP.