OSPF

Мы продолжаем говорить про динамическую маршрутизацию в рамках нашего курса ICND2. И если предыдущий протокол мы разобрали с вами EGRP, это образцово-показательный протокол класса Distance Vector, который обменивается векторами метрик до маршрутов, и у него единица передачи информации — это маршрут. И для каждого маршрута он сообщает вектор метрик. Дальше мы к маршруту, который прислал сосед, точнее, к его вектору, прикладываем тот вектор, как мы знаем соседа, который прислал нам маршрут, и получаем в итоге результирующий вектор, как мы знаем сеть через определенного соседа. И дальше обмениваемся со своими уже соседями, показанием, что мы знаем сеть, с вот таким вот вектором метрик. Это то, как работают классические Distance Vector протоколы. Есть более сложные протоколы Distance Vector, есть менее сложные. Ну вот EGRP — такой образцово-показательный Distance Vector протокол. Противоположностью Distance Vector протоколам будут являться протоколы класса LinkState.

И наиболее показательный пример этих протоколов — это вот как раз будет OSPF, которым мы будем заниматься сейчас. Как будет работать любой протокол класса LinkState? Любой, в смысле, любой из двух, которые есть. Это LinkState протоколы OSPF и ISIS. Ну вот в рамках нашего курса мы изучаем OSPF. Эти протоколы не обмениваются маршрутами. Они обмениваются кусками топологии, кто на кого какими интерфейсами смотрит. То есть каждый роутер отсылает единицу информации. Это не маршрут, а указание. У меня есть такие-то интерфейсы. Я на них вижу либо конечные абонентские сетки, либо вижу соседние роутеры. И дальше по кускам этой топологии каждый роутер начинает складывать пазл. Кто на кого каким интерфейсом смотрит. Потому что, например, если два роутера есть, которые соединены, первый роутер и второй роутер соединены интерфейсами, которые смотрят друг на друга. Первый говорит «я вижу второго», второй говорит «я вижу первого».

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

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

по сравнению с абстрактным дистанц-векторным протоколом. Они в среднем очень эффективно используют полосопропускания. Здесь надо оговориться, что это неприменимо к EGRP, потому что EGRP достаточно эффективно использует полосопропускания. У него есть механизм установления соседства, механизм определения состояния соседа с помощью hello-пакетов. Ну, link state протоколы нативно, хорошо и эффективно используют полосу, потому что у них, если вдруг происходят какие-то изменения в топологии, они рассылают эти изменения своим соседям. Они говорят, вот раньше я говорил, что у меня сеть устроена вот так, я теперь говорю, что у меня сеть устроена вот эдак. Но любой link state протокол нативным образом поддерживает соседство и нативным образом знает состояние каждого из соседей. Поэтому нет необходимости, как, например, в RIP или в древнем протоколе EGRP периодически просто по таймеру рассылать всю свою таблицу маршрутизации. Вот это вот эффективно использует полосопо по сравнению с древними протоколами distance vector, то есть RIP и EGRP.

Ну, и еще более древние протоколы, которые уже даже аксакалы, наверное, не помнят. Ну, как бы там ни было, да, действительно, link state протоколы, вот они обмениваются кусками топологии. После того, как роутер рассказал, что он смотрит на таких-то соседей, что у него есть вот такие пользовательские сетки, дальше роутер просто ничего не отсылает, ему незачем что-то отсылать. Если у него что-то произойдет, он расскажет, ну, так называемую дельту, что именно изменилось. Он говорит, раньше у меня вот так вот было, а теперь вот эдак. Но это он сделает один раз при возникновении изменений. Если сеть работает стабильно, роутер не занимает сеть вообще. Ну, в крайнем случае, какие-то небольшие будут передаваться там пакеты типа Hello. Если мы говорим про SPF, то он именно Hello пакеты будет передавать, и это будет означать, что с роутером все хорошо, все, что он раньше рассказывал, все это еще актуально, никаких изменений не было. Hello пакеты мелкие и полосу не занимают. Если вдруг в сети произойдут какие-то изменения,

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

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

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

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

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

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

но мне больше нравится регион. Это не area, не группа такая, которая исполняет всякие разные интересные песенки, это вот регионы. Внутри каждого региона у SPF будет просчитывать все маршруты между роутерами по-честному. Соответственно, чем у вас больше количество роутеров в топологии, тем больше нагрузка на центральные процессоры, если все по-честному высчитывать, и тем больше, скажем, потребность в том, чтобы разбивать эту сеть на отдельные кусочки у вас может возникнуть. Если у вас в сети в одном регионе, ну, в одной автономной системе, ну, скажем, например, 200 роутеров, такое умозрительное число приблизительное, то вы вполне возможно захотите взять и разбить такую сеть, такое количество роутеров на отдельные, не связанные между собой кусочки, и, соответственно, в каждом кусочке вы будете просчитывать все маршруты по-честному, а между кусочками, между регионами вы будете передавать маршруты в дистанц-векторном стиле. Дистанц-векторные протоколы,

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

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

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

Потому что может, например, случиться такая штука, что этот роутер захочет добраться до некоторой сети, и дальше он скажет, я смотрю сюда, этот скажет, я смотрю сюда, этот скажет, я смотрю сюда, скажет, я смотрю сюда, и как-то у нас организовалась петля. Как сделать так, чтобы такого не получилось? SPF, и на самом деле практически все link state протоколы, с подобной проблемой борются очень радикальным образом. Они говорят, что если мы разбиваем сеть на отдельные куски, которые не связаны между собой, которые ограничивают зону распространения ошибки, но тем самым заставляют нас работать в дистанц-векторном стиле, то для того, чтобы не формировать петлю, которая проходит через несколько регионов, потому что внутри региона мы защищены от петли гарантированно, чтобы не формировать петлю, которая проходит через несколько регионов, у нас связи между регионами будут немножко специфическими. Мы не разрешаем передавать маршруты между регионами по схеме как попало. Мы выделяем один регион и называем его транзитным,

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

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

Мы сейчас говорили просто про абстрактные link state протоколы, никакие не конкретные. Но пришла пора поговорить уже про OSPF конкретно. OSPF — протокол стандартный. Есть целая пачка RFC, которые его описывают. Есть каркас взаимодействия в OSPF, и есть дополнительные механизмы, которые его улучшают. Плюс он развивается постоянно. Тот OSPF, с которым мы работаем в рамках IPv4, это будет OSPF второй версии. И у него есть целая пачка изменений, которые периодически выполняли, улучшали. Основные RFC, которые есть по OSPF второй версии, это 1583. Он немножко устаревший, но тем не менее используется довольно часто. 2328. Это актуальная версия. И дополнительные всякие улучшалки к нему тоже есть. 1587 про NSSA, 3021.

В общем, их много. Этот протокол стандартный в том смысле, что его все вендоры делают более-менее одинаково. Естественно, делают базовое взаимодействие одинаковое. Дальше в части улучшалок может быть такое, что один вендор улучшалку сделает, а второй вендор улучшалку не сделает. Но это не совсем большая проблема, потому что даже если у вас в сети есть оборудование разных вендоров, которое поддерживает разные фичи OSPF, как правило, это не влияет на какое-то глобальное взаимодействие. Некоторые роутеры при этом смогут какую-то прикольную штучку сделать, некоторые не смогут. Если говорить про OSPF третьей версии, то это протокол специально для IPv6. Он работает поверх IPv6 и нужен для синхронизации маршрутов IPv6. OSPF будет работать именно как классический link state протокол. Будет устанавливать соседство. Дальше будет своим соседям, которые заведомо непротиворечиво настроены,

с которыми заведомо есть двусторонняя связь, после установления соседства обмениваться кусками таблицы топологии и, наконец, по таблице топологии строить кратчайшие маршруты между роутерами. После того как соседство с роутером установлено, после того как всю необходимую топологическую информацию мы ему отослали, дальше с соседом просто идёт нормальное рабочее взаимодействие. Мы отправляем ему указание, что мы живы, что у нас никаких изменений нет, а он отправляет сообщение, что у него всё хорошо, у него никаких изменений нет. Делается это с помощью обмена Hello пакетами, примерно так же, как в EIGRP. Единицей передачи информации в OSPF будет не маршрут, а так называемый LSA. Link State Advertisement. Здесь у меня написано announcement, по-моему, это advertisement всё-таки. Да. В LSA может передаваться различная информация, это в основном указание, какие у нас есть интерфейсы, куда эти интерфейсы смотрят: то ли на пользователей,

и там у нас какая-то пользовательская сетка живёт, то ли на соседние роутеры, и тогда, соответственно, показывается, какие соседи на интерфейсе обнаружены. Или если у нас передаётся информация в дистанц-векторном стиле, то там будут передаваться маршруты. Это как раз между регионами или маршруты, полученные из других автономных систем. Мы про это поговорим чуть дальше. Вот пример. У нас есть четыре роутера в кольце. Первый роутер, второй, третий и четвёртый. Они друг на друга смотрят своими интерфейсами. Каждый роутер возьмёт и скажет, как он со своей стороны видит сеть. R1 скажет: я R1, я вижу R2, я вижу R4. Такой кусочек пазла он сам сформирует и отправит это всем остальным роутерам в топологии. С кем он непосредственно подключён, а они это переправят уже дальше. R2 сделает то же самое. Он скажет: я вижу соседа R1 и я вижу R3.

R1 видит второго и четвёртого. R2 видит R1 и R3. И, соответственно, R3 скажет: я вижу R2 и R4. И R4 скажет: я вижу R1 и R3. Такие четыре кусочка пазла все четыре роутера сделают. Это четыре кусочка пазла. Они все будут собраны в голове у каждого роутера, и дальше каждый роутер будет говорить: ага, у нас есть указание, что R1 видит R2, а R2 видит R1. Это, наверное, потому что R1 связан напрямую с R2. Дальше тоже аналогично. R2 связан с R3, R3 связан с R2. Видимо, здесь есть связь R2–R3. И так по аналогии. Все роутеры собирают все кусочки пазла, дальше смотрят, какие кусочки пазла друг в друга вщёлкиваются, и по этой топологии строят дальше уже кратчайшие маршруты. Начинается всё с того,

что у нас устанавливается соседство, и это соседство поддерживается. Происходит это с помощью так называемого Hello протокола. Название громкое, на самом деле суть очень простая. Каждый роутер периодически во все интерфейсы, где на нём включён OSPF, посылает Hello пакеты. Они отсылаются по таймеру, стандартный таймер 10 секунд, и вы, отправляя эти самые Hello пакеты, рассказываете, как вы настроены. Немножко информации, которая критично важна соседу для того, чтобы понять, противоречиво вы с ним настроены или нет. Используется мультикаст для отправки такого Hello пакета — 224.0.0.5 в IPv4, и, соответственно, вы не должны знать IP-адрес получателя для того, чтобы доставить такой кадр всем OSPF роутерам в канале. Вы отправляете такой мультикастовый пакет, и этот пакет доходит до всех мультикастовых OSPF v2 роутеров. И те роутеры, которые с вами в одном канале находятся, отправляют ответные сообщения тоже на этот же самый мультикастовый адрес.

Поэтому даже несмотря на то, что вы просто подключаетесь к каналу, вы ещё не знаете IP-адресов соседей, вы всё равно обнаруживаете адреса этих соседей с помощью этого мультикаста. Вы, отправляя Hello сообщение, указываете в каждом сообщении свой идентификатор. Этот идентификатор обязан быть уникальным, причём он действительно обязан быть уникальным. Если в EIGRP тоже был router ID, но его можно было, в принципе, сделать какой попало, он не сильно влиял на работу, и действительно учитывался этот router ID в очень редких случаях. То в OSPF router ID — это очень важная вещь. Он обязан быть уникальным. Если он не будет уникальным между двумя роутерами, то будут наблюдаться очень интересные эффекты, очень интересные глюки. Начиная с того, что соседство может просто не установиться, если у вас два роутера прямо соседи, и заканчивая тем, что у вас маршруты будут строиться неправильно, если два не соседних роутера будут иметь одинаковые router ID, то есть произойдёт дублирование.

Так что router ID в OSPF действительно обязан быть уникальным. Дальше. После того как роутер отправляет Hello сообщение с указанием своего router ID, он указывает таймеры. Как часто он отправляет Hello пакеты и в течение какого срока сосед должен будет получить Hello сообщение от нас ещё раз, перед тем как посчитает нас трупом. Сами таймеры передаются в Hello сообщении, причём они обязаны совпадать. Если в EIGRP у нас тоже передаётся таймер, как часто мы отправляем сообщение — там не как часто, там hold time передаётся, через сколько признать нас трупом. Но в EIGRP таймеры не обязаны совпадать. В OSPF таймеры совпадать обязаны. Если не произойдёт совпадение, то соседство не установится. Дальше. Каждый роутер, когда отсылает Hello пакет, указывает, с кем он установил соседские отношения

в этом же самом канале. Этот механизм позволяет проверить двустороннюю связь между двумя роутерами, которые находятся в канале. У нас один роутер проснулся, отправил Hello пакет, сказал: я пока никого не вижу. Я в этом канале просто только что проснулся, Я в этом канале никакого соседа не вижу, но в ответ ему пойдёт сообщение, а я тебя вижу. И после того, как в ответ прошло сообщение, я тебя вижу, следующее сообщение, которое будет отправлять левый роутер, будет говорить, я тебя тоже вижу. И после того, как мы отправили соседу сообщение, я тебя вижу, и получили от него сообщение, я тебя тоже вижу, мы понимаем, что связь двусторонняя. В сообщении от соседа, как минимум в том, которое «я тебя тоже вижу», будет указание, как он настроен, и мы увидим, что настройка непротиворечивая. Поэтому мы понимаем, что сосед настроен непротиворечиво, туда-обратно сообщение проходит. Следовательно, если мы хотим, мы можем с этим соседом установить полные соседские взаимоотношения и обменяться с ним кусками топологии. Когда мы работаем с некоторым соседом по интерфейсу,

мы должны будем договориться о том, какой номер региона мы используем. В OSPF все регионы будут пронумерованы. Регион — это четырёхбайтовое число. Регион центральный, транзитный будет иметь специальный номер 0. Все остальные номера не зарезервированы. Все они свободны для того, чтобы их можно было использовать. Но ненулевые регионы не могут быть транзитными. Если маршрут зародился в таком нетранзитном регионе, он может быть передан только в центральный, только в нулевой регион. Если маршрут зародился где угодно, то только через центральный регион можно передать его в ненулевой регион. В OSPF границы между регионами проходят именно по интерфейсам. Если у нас есть какой-то роутер, он смотрит одним интерфейсом в регион номер 0, другим интерфейсом в регион номер 1, то границы между регионами проходят именно по роутерам, между интерфейсами. Нельзя сделать так, чтобы граница проходила

таким образом, что один роутер видел другого в нулевом регионе, а другой первого — в первом. Так делать нельзя. А вот так можно. Далее. Можно подписать hello-сообщение специальным паролем. Таким образом, кто попало с вами не подружится. Если захотите, можно посылать plain-текстовый пароль, или можно вписывать в каждый hello-пакет хэш от пароля и содержимого этого сообщения. Это намного более безопасная вещь, потому что сам пароль при этом в открытом виде вы передавать не будете. Гипотетически, в лабе, может быть, имеет смысл поднимать и plain-текстовые пароли. Далее. Что у нас ещё есть? Поля, которые помечены звёздочкой, обязаны совпадать. Таймеры обязаны совпадать. Номер региона у соседнего роутера в одном канале с нами обязан совпадать.

Пароли обязаны совпадать. Всё остальное в hello-сообщении совпадать не обязано. Оно может быть любым. После того, как мы установили соседство с помощью hello-сообщений, дальше нужно будет обменяться кусками таблицы топологии. Как уже было сказано, в OSPF единицей передачи информации о топологии будет так называемый LSA. Каждый роутер выпускает свои LSA, кусочки информации, которыми он хочет поделиться с соседями в пределах своего региона. Если у нас роутер смотрит в несколько регионов, он будет участвовать в обмене LSA со всеми роутерами в пределах каждого из своих регионов. Все LSA в пределах региона так или иначе должны быть одинаковые. Если у нас есть роутер, который находится на границе между регионами, допустим, у него есть регион нулевой на одном интерфейсе, регион первый на другом интерфейсе, то здесь есть какие-то роутеры, и здесь есть какие-то роутеры.

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

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

Но при этом надо понимать, что отдельная стоимость на отдельном интерфейсе ни на что особо не влияет, и фактически имеют значение только суммарные стоимости, которые строятся при подсчёте маршрутов через всю топологию. Например, как у нас на картинке нарисовано, если роутер R1 будет строить маршрут до сети, которая находится за спиной роутера R3, есть интерфейс на роутере R3, который стоит 15 копеек, и дальше есть варианты, как добраться до этой сети. R1 будет считать кратчайший маршрут до роутера R3, и у него есть варианты, как добраться. Можно пойти наверх, можно пойти вниз. Наверху 10 плюс 20 стоит 30 копеек транспорт от R1 до R3, и внизу от R1 до R3 через R4 будет стоить 15 копеек. Поэтому 30 плюс 15 получается 45, 15 плюс 15 получается 30. И в этом случае мы выбираем более дешёвый маршрут. Мы говорим, что кратчайший способ добраться до сети, которая находится за роутером R3, это посчитать кратчайший маршрут до R3, который стоит 15 копеек,

и прибавить стоимость этого интерфейса, который на R3 есть, это ещё 15 копеек. И получается, что кратчайший маршрут до этой сети будет стоить 30 копеек. Каждый роутер рассказывает в топологической информации, кто на кого каким интерфейсом смотрит, две вещи. На каких интерфейсах обнаружены соседи, и на каких интерфейсах есть пользовательские сетки. По сути, какой IP-адрес висит на интерфейсе, который смотрит на пользователей. И в этом случае каждый роутер будет выпускать свою LSA. Здесь не написано, но роутер R1 тоже сделает LSA. Своё собственное: он скажет, что я R1, вижу соседа R2 за 10 копеек, и вижу соседа R4 за 5 копеек. У нас будет 4 кусочка пазла, 4 LSA, выпущенные этими роутерами. И R1 скажет, я смотрю на двух своих соседей.

У меня есть два интерфейса. Один смотрит сюда, другой смотрит сюда. R2 скажет, я тоже вижу двух соседей. Я вижу одного R1, вижу другого R3. R4 скажет, я тоже вижу двоих соседей. И R3 скажет, я вижу двоих соседей. И плюс я вижу сетку 10.0.0.0/24 за 15 копеек. Единицей передачи информации будет не отдельная сеть, а целиком LSA. Роутер R3 скажет, я вижу двух соседей, и плюс у меня ещё есть сетка. И когда будет строиться топологическая карта, будет использоваться информация о соседях. И только в самый последний момент, после того, как каждый роутер посчитает кратчайший маршрут до роутера R3, с учётом этих соседских взаимоотношений, будут посчитаны стоимости, как добраться до сети 10.0.0.0/24. Каждый из роутеров будет видеть, что на R3 такая сетка есть, будет строить кратчайший маршрут до R3, будет подсчитывать стоимость маршрута до R3 и прибавлять к этим 15 копейкам,

которые есть в LSA роутера R3. После того, как это будет сделано, в таблице маршрутизации будет установлен маршрут до той сети, которая есть на роутере R3. Каждый роутер это сделает, в том числе, например, сделает роутер R1. И он поставит стоимость этого маршрута 30 копеек. А другой маршрут он не поставит, потому что тот дорогой, и он его просто не посчитает. Дальше. Как уже было сказано, в OSPF в hello-сообщениях передаются эти самые router ID. Уникальные идентификаторы каждого роутера, и они для работы OSPF будут действительно очень важны. Идентификатор — это некое число, которое будет иметь размер 4 байта и часто будет записываться в форме IP-адреса. Это не IP-адрес, но это число, которое имеет такой же размер, и зачастую оно записывается в форме IP-адреса. Например, 0.0.0.1 — это не очень хороший IP-адрес.

Или 255.255.255.0. Тоже не очень хороший IP-адрес. Но как идентификатор — вполне нормальный. Это просто любое число, которое вам нравится, никаких ограничений на router ID нет. Но есть нюанс, заключающийся в том, что этот идентификатор обязан быть уникальным, и если вы его не задаёте никаким специальным образом, то роутер, благо он оперирует IP-адресами, благо у него есть хотя бы один IP-адрес наверняка, он может воспользоваться автоматическим назначением этого самого router ID. Любым способом он может себе этот router ID придумать. Главное, чтобы он был уникальным. Если он возьмёт себе любой IP-адрес, который есть на устройстве, он с большой вероятностью будет уникальным. Поэтому каким образом может router ID получиться? Понятное дело, его может администратор назначить вручную. Можно взять какой-нибудь IP-адрес, например, самый маленький, или самый большой, или самый чётный, или какой-нибудь ещё.

Любой, который хотите. У Cisco, например, есть алгоритм, по какому правилу следует выбирать router ID из имеющихся на устройстве IP-адресов, если этих адресов несколько. Они сначала смотрят на то, есть ли у вас виртуальные loopback-интерфейсы или любые другие виртуальные интерфейсы, которые с меньшей вероятностью окажутся выключены или зависимы от каких-то внешних условий. И берут самый большой IP-адрес с них. А дальше, если это не удалось сделать, если ни одного loopback нет, ни одного виртуального интерфейса нет, или IP-адресов на них нет, они перебирают просто физические интерфейсы, которые есть, и берут самый большой IP-адрес уже с них. Если не удалось взять никакой IP-адрес, потому что IP-адресов вообще нет, тогда роутер Cisco впадает в панику и говорит, я не могу без router ID работать, извините.

Некоторые другие роутеры могут вести себя иначе. По стандарту нигде не указано, как именно выбирать router ID. И вполне может быть такое, что какой-то другой производитель будет выбирать router ID иным способом. Предложенный в качестве образца механизм в RFC заключается в том, чтобы взять самый маленький IP-адрес на устройстве, но просто самый маленький IP-адрес, насколько мне известно, не берёт вообще никто. Дальше. Что ещё здесь может быть интересного? Когда у нас есть роутер, он себе каким-то образом взял router ID, он обнаружил, на каких интерфейсах ему следует включить OSPF, он начинает в эти интерфейсы посылать hello-пакеты и рассказывает, какой у него router ID, как он в этом интерфейсе пока никого не видит, какой у него таймер настроен, скорее всего, таймеры по умолчанию будут. И дальше у нас устанавливаются соседства.

Соседство устанавливается с прохождением нескольких стадий. И по каждой стадии мы будем информацию, которая нам известна о соседе, записывать в табличку соседств. У каждого роутера есть табличка, где он ведёт учёт всех своих соседей. И у каждого соседа есть некая фаза, в которой мы его будем держать. Это именно внутренний наш учёт. Мы никаким образом информацию о том, что мы некого соседа держим в некоторой фазе, не отсылаем. У нас просто будет указание, что если роутер, допустим, R1, видит hello-сообщение от роутера R2, то роутер R2 у нас находится в каком-то состоянии, в какой-то стадии, в какой-то фазе. Самая первая фаза, которая нас интересует на курсе ICND2, это фаза init. Это будет означать, что если мы видим просто hello-сообщение от роутера R2, но роутер R2 в списке соседей на интерфейсе

нас не обнаружил, то мы будем говорить: мы знаем о том, что существует сосед R2, но мы его видим в фазе init. Это значит, что он нас пока не видит. Мы ему, может быть, даже отправляем hello-сообщение с указанием, что мы его видим, но он нам пока присылает hello-сообщение.