OSPFv2 в Cisco IOS

Мы продолжаем говорить про OSPF, и сейчас будет практический модуль, который будет рассказывать про то, как OSPF можно настроить на оборудовании Cisco. Я надеюсь, что предыдущий модуль зашел сравнительно хорошо, чтобы стало понятно, что OSPF — это протокол, который сильно отличается от EIGRP. Если EIGRP просто берет куски таблиц маршрутизации и, по большому счету, кидает соседям, может быть, не по таймеру, как это делает RIP, а один раз кидает, а дальше говорит «у меня все хорошо», то OSPF никоим образом не занимается репликацией таблиц маршрутизации напрямую. Он рассказывает, как устроена сеть. А дальше, исходя из того, как устроена сеть, соседи воспроизводят таблицу маршрутизации, которая есть на соседних роутерах. Таблица маршрутизации для OSPF вторична, а первична именно топология. Мы сейчас займемся тем, что будем настраивать OSPF на Cisco, и OSPF у нас сначала будет считаться второй версией, а потом про третью версию поговорим отдельно.

И сразу замечу, что OSPF в Cisco имеет ряд особенностей. В принципе, у многих вендоров эти особенности тоже имеются. Не то чтобы какие-то специальные особенные Cisco OSPF. Нет, это просто в стандарте немножко неявно описано, как именно должно происходить то или иное взаимодействие. И в Cisco это решили каким-то образом сделать. Я вам здесь расскажу, как именно Cisco будет выбирать те или иные способы, которые в стандарте не регламентированы. Первый способ — это, соответственно, надо будет выбрать router ID. Как уже было сказано, router ID обязан быть уникальным, и в стандарте не написано, как именно router ID должен назначаться. В Cisco используется следующий алгоритм выбора router ID. Если у вас есть в явном виде заданный администратором router ID, то используется, понятное дело, именно он. Независимо от всего остального. Если router ID ручками администратор не назначил, то тогда берется самый большой IP-шник с loopback-ов.

Если loopback-ов нету или IP-шников на них нету, то берется самый большой адрес с физического интерфейса, который у вас будет. Если ни одного адреса нету, вообще ни одного, ни на loopback-ах, ни на физических интерфейсах, то непонятно, зачем вы вообще тогда IPv4-взаимодействие запустили. В этом случае Cisco отказывается запускать процесс OSPF с криками «мне нужен router ID, а у меня нету способа, которым его можно будет взять». Но вы можете в этом случае, если вы очень сильно хотите запустить процесс OSPF, не имея ни одного IPv4-адреса, сказать просто, что router ID у вас будет прибит ручками. Дальше. В каком случае мы router ID будем хотеть назначить ручками, и в каком случае мы можем положиться на автоматику? Если вы хотите заниматься детальным траблшутингом OSPF, то вы чаще всего будете хотеть, чтобы у вас эти router ID были предсказуемы. Поэтому очень хорошая идея будет сделать следующее.

На каждом устройстве держать loopback-интерфейс с предсказуемым IPv4. Этот loopback-интерфейс с предсказуемым IPv4 вы потом запихнете в OSPF, и у вас IPv4 будет реплицироваться между всеми роутерами. Поэтому вы в любой момент на этот IPv4 можете зайти по телнету, допустим, и получить удаленный доступ к железке. Или попингать удаленный IPv4 на loopback-е, и чтобы у вас все пингалось, чтобы вы понимали, роутер в сети или не в сети. И этот же IPv4 с loopback-ом вы можете ручками прибить гвоздями в качестве router ID, чтобы если вдруг у вас на железке организуется какой-то другой loopback с большим IPv4, чтобы случайно router ID не ускакал на другой адрес. Поэтому мы этот алгоритм, который здесь указан, что сначала Cisco проверяет назначенный вручную адрес, потом она берет самый большой адрес с loopback-интерфейса, а потом самый большой адрес с физического интерфейса, будем немножко хакать. Мы никогда Cisco не позволяем брать самый большой IPv4 с физического интерфейса. Мы говорим, на физических интерфейсах у нас непонятно, какое состояние интерфейса.

Может быть, интерфейс выключен будет из-за того, что соседняя железка в перезагрузке находится, а наша железка поднимается. Поэтому доверия этому пункту никакого нет. И мы не хотим никогда, чтобы у нас самый большой адрес с физического интерфейса брался. В то же время мы хотим, чтобы у нас брался самый большой адрес с loopback-интерфейса. У нас будет на роутере какой-нибудь loopback-интерфейс, на котором висит IPv4. Не знаю, 10.0.0.17. И мы хотим этот адрес с loopback-а взять в качестве router ID. Мы этот loopback-интерфейс заносим в OSPF, и маршрут, который connected на этом интерфейсе будет, 10.0.0.17 по /32 маске, добавляется в OSPF, и любой другой роутер может этот IP-шник попингать. И плюс к тому мы говорим, этот IP-шник должен стать router ID. Поэтому мы вручную назначаем идентификатор, равный самому большому IP-шнику, который у нас есть на loopback-е. Даже если вдруг вы потом сделаете еще один loopback-интерфейс, скажете, что у нас здесь, не знаю, 20.20.20.20 будет адрес по /32 маске,

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

то эта референсная полоса пропускания будет равна 100 Мбит в секунду. Это говорит, что стоимость интерфейса, например, 1,5 Мбит будет равна 64. Стоимость интерфейса 10 Мбит будет равна 10. Стоимость интерфейса 100 Мбит будет равна единичке. И стоимость интерфейса выше, чем 100 Мбит, тоже будет равна единичке. Для современных интерфейсов эта формула всегда дает стоимость единичку. Но вы можете переопределить референсную полосу, или вы можете interface cost, то есть стоимость интерфейса, в явном виде выставить ручками на ту, которая вам понравится. Рекомендуется все-таки пользоваться тем, что стоимость вычисляется по некой формуле, и рекомендуется на всех роутерах задавать какую-то отличную от 100 мегабит reference bandwidth. Вы можете просто задрать reference bandwidth, сказать, что на всех ваших роутерах reference bandwidth будет равна, не знаю, терабиту. И тогда терабит, разделенный на скорость интерфейса, будет для 100 мегабит, гигабит

давать некий interface cost, который будет иметь различные значения для скоростей больших, чем 100 мегабит. Проблема в штатной формуле заключается именно в том, что reference bandwidth 100 мегабит совсем неинтересна, потому что она для 100 мегабит, для гигабита, для 10 гигабит, для 40 гигабит будет давать всегда одну и ту же стоимость. И получается, что OSPF по эффективности выбора канала превращается в RIP, потому что он не разделяет между собой интерфейсы с разными скоростями с настройками по умолчанию. Он мог бы это делать, но за счет того, что все интерфейсы слишком быстрые и reference bandwidth слишком маленькая, он этого по факту не делает. Завышая reference bandwidth, мы можем сделать так, чтобы OSPF действительно различал разные скорости и действительно более быстрым интерфейсам давал более маленькую стоимость. Если мы хотим включить OSPF на интерфейсе, мы можем это сделать двумя способами. Первый способ такой же, как в EIGRP или в RIP — использовать команду network, которая когда-то имела смысл в классовом мире, но теперь этот смысл полностью потеряла.

Поэтому слово network никакого отношения к сетям сейчас не имеет. Фактически это просто какое-то ключевое слово, которое имеет вид, похожий на слово «сеть» в английском языке, но никакого отношения к сетям не имеет. Мы этим словом network задаем условия access-листа. Мы говорим, что некий IP-шник, некая wildcard-маска задают те IP-адреса, которые, будучи повешенными на интерфейсе, указывают, что на этом интерфейсе должен быть включен OSPF. Но OSPF на интерфейсе не просто включается, он включается в определенном регионе. Мы должны каждый раз, когда мы на каком-то интерфейсе включаем OSPF, сказать, в какой именно регион смотрит этот интерфейс. Поэтому команда network имеет вид: network, дальше эталонный IP-шник, wildcard-маска, и слово area, и дальше номер региона. Номер региона можно указывать просто числом, можно указывать в виде четырехзначного числа, как IP-адрес, то есть можно указать area 0.0.0.0. Это ни на что не повлияет, в любом случае имеется в виду число 0. И так же, как и в случае с EIGRP, если мы указываем, что у нас network IP-шник и маска включают OSPF на определенном интерфейсе,

то, во-первых, на этом интерфейсе мы начинаем отсылать hello-пакеты, а во-вторых, connected-сетки с этого интерфейса попадают в анонс OSPF. То есть попадают в LSA первого типа, который роутер будет придумывать сам про себя в этом регионе. Второй способ, более разумный в современном мире, это прийти в явном виде на интерфейс и сказать «включись». Мы заходим на интерфейс и используем ip ospf 1 area 0. Оба способа равнозначны в том смысле, что они дают одинаковый результат: если мы тем или иным способом включили OSPF на интерфейсе, у нас на этом интерфейсе начинают отсылаться hello-пакеты, начинают приниматься hello-пакеты, начинают устанавливаться соседские взаимоотношения, и connected-сетки включаются в LSA первого типа, то есть, говоря русским языком, в анонс того, что анонсируется соседям. Есть маленький нюанс, который заключается в том, что network с wildcard-маской может быть не один на роутере. Мы можем сказать «network — такой IP-шник с такой маской»,

«network с другим IP-шником с другой маской». В EIGRP мы тоже это можем сделать, но в EIGRP нет особой проблемы, что один и тот же IP-шник попадет под несколько команд network одновременно, потому что в EIGRP мы просто говорили «включись, включись, включись». И в EIGRP достаточно было одного попадания «включись», чтобы оно действительно включилось. В OSPF один и тот же адрес может попасть под действие нескольких команд network, и у него будут заданы разные номера регионов. И здесь нужно будет заметить следующий факт: если в OSPF один и тот же IP-шник попадает под действие нескольких команд network, то сработает та команда network, у которой более специфичные условия. А более специфичные условия будут работать точно так же, как это работает в выборе маршрутов таблицы маршрутизации, longest prefix match — у кого сначала больше битиков совпадет. И здесь заключается нюанс, который указывает на то, чем эта штука отличается от обычного access-листа.

В обычном access-листе wildcard-маска может иметь в совершенно перепутанном порядке нолики-единички, она никак не ограничена в том, какие биты мы можем проверять в обычном access-листе. Но если мы задаем условия access-листа в команде network, то эта wildcard-маска обязана иметь сначала все битики нулевые, а потом все битики-единички. Именно потому, чтобы работало правило longest prefix match. У кого больше ноликов в начале, тот и прав. Потому что требуется совпадение большего количества битиков, это значит, что у нас более специфичная сеть. Поэтому, несмотря на то, что здесь используется wildcard-маска, работает это по факту как самая обычная маска. Она не может состоять из разных ноликов и единичек вперемешку. И за счет того, что у нас есть правило longest prefix match, регион будет браться как раз из наиболее специфичного условия. Если у нас есть несколько команд network,

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

Можно легко ошибиться. С этим ошибиться нельзя. Мы просто на интерфейсе в явном виде говорим, этот интерфейс участвует в OSPF. Более разумно, более предсказуемо, более стабильно. Когда мы задаем эту команду, мы должны будем указать номер экземпляра OSPF. Этот экземпляр задается командой router, дальше ospf и дальше число. Это число — это просто номер. Номер уникальный для роутера. Если мы хотим, мы можем запустить 2, 3, 5, 10 экземпляров OSPF, но все они будут работать на одном и том же роутере. У нас будет, условно говоря, роутер, у него будут два интерфейса, смотрящие в один экземпляр, два интерфейса, смотрящие в другой экземпляр, два интерфейса, смотрящие в третий экземпляр. Эти интерфейсы будут все обособлены друг от друга. По всем интерфейсам будут приниматься маршруты, отправляться маршруты, но взаимодействие между разными экземплярами по умолчанию не будет происходить. Маршруты, допустим, которые получены отсюда, они не будут отправляться дальше другим роутерам в

другом экземпляре. Но в ICND1 и в ICND2 это не рассказывается, потому что это действительно очень редкая штука. Обычно запускать больше одного экземпляра нужно в ситуации, когда у вас либо временная какая-то структура, когда ваша компания купила другую компанию, и у вас используется OSPF, и у них используется OSPF. И вы не можете взять и два этих OSPF объединить в один большой домен, потому что там, например, транзитные регионы разные, и стыковать их между собой не получается, и надо их стыковать как-то через одно место. В этом случае вы запускаете два разных экземпляра OSPF на одном роутере и занимаетесь перекладыванием маршрутов между ними. Ничего интересного там нету с нашей точки зрения. И больше геморроя, чем пользы. Иногда это бывает нужно, но бывает это все-таки нужно крайне редко. Если мы дизайним новую сеть, то никогда ни при каких обстоятельствах нам два разных экземпляра OSPF не понадобятся.

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

то у вас везде будет router ospf 1, ip ospf 1 area 0. Или, если вы захотите, вы можете сказать 89: router ospf 89, ip ospf 89 area 0. Тот самый номер экземпляра, который вы используете, он локально значимый, по сети не передается. Если вы хотите, вы можете взять две циски, соединить их между собой, сказать на одном роутере у нас экземпляр 89, на другом 98, они прекрасно между собой подружатся, он не передается по сети. Если вы захотите, вы можете задать router ID в явном виде, команда router-id и дальше четырехзначное число в форме IP-адреса. Опять же, не обязательно это должен быть IP-шник, но будет неплохо, если вы router ID используете равный самому большому IP-шнику, который у вас есть на loopback-ах, который задается на всех ваших роутерах каким-то предсказуемым образом. Например, у вас есть специальная отдельная сеть, 10.17.0.0 по /24 маске,

которая выделена специально под менеджмент. И там 10.17.0.1, 10.17.0.2, 10.17.0.3 Это IP-шники, которые вы вешаете на эти самые лупбеки. Роутер 1 будет иметь один IP-шник, роутер 2 другой, роутер 3 третий и так далее. И роутер ID вы будете прикручивать ручками — те самые, которые совпадают с IP-шниками на ваших лупбеках. Если вы хотите назначить стоимости на интерфейсах, это можно сделать либо с использованием изменения reference bandwidth, когда мы указываем, что базовая референсная полоса пропускания на роутере будет какой-то другой. Это имеет смысл делать на всех роутерах одновременно, и команда будет иметь вид в настройке роутера: auto cost, reference bandwidth, и дальше указываете некое число. Это число задаётся в мегабитах, по умолчанию там 100, 100 мегабит. Но 100 мегабит — это вообще ни о чём, вы можете сказать, что вас интересует либо гигабит, либо лучше — терабит,

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

который имеет меньшую стоимость. И если у вас где-то произошла ошибка, произошла накладка в назначении стоимости интерфейсов, то это может повлиять на то, что трафик у вас пойдёт неоптимально. Если везде используются циски, используйте везде auto cost, reference bandwidth, и дальше одинаковая какая-то референсная полоса, которая будет достаточно большой, чтобы позволить роутерам различать между собой производительные интерфейсы, например, 10-гигабитные. Дальше. Если вы хотите, вы можете на интерфейсе повесить стоимость ручками. Например, это может быть полезно в ситуации, когда вы знаете, что через какой-то интерфейс трафик ходить не должен, потому что этот интерфейс, например, дорогой. Или у вас есть запасной канал через спутник, он в принципе нормальный, быстрый, но задержки очень большие, вы не хотите, чтобы трафик по нему шёл в ситуации, когда есть другой какой-то канал, чтобы трафик лучше шёл по нему. В этом случае вы можете сказать:

у нас есть интерфейс, у него базовая стоимость 1000, но мы хотим сделать, чтобы у него стоимость была 10 000. Тогда трафик пойдёт сначала по более дешёвой трассе, а если там что-то сломается, тогда трафик пойдёт только через более дорогой интерфейс. И сделать это можно командой ip ospf cost и дальше указать стоимость. Стоимость одного интерфейса должна быть двухбайтовой. Итоговая стоимость трассы будет четырёхбайтовой, а стоимость одного интерфейса должна быть двухбайтовой. Альтернативный вариант: у нас есть reference bandwidth, она делится на скорость интерфейса, и хотя физическую скорость интерфейса вы поменять, как правило, не можете — если у вас, например, гигабитный интерфейс, он на гигабите работает, и всё, он не может работать на другой скорости. Вы можете его перевести в 100-мегабитный режим, тогда он работает на 100 мегабитах, и всё. Но мы можем указать команду bandwidth на интерфейсе.

Bandwidth не изменяет реальную скорость передачи данных. Она указывает лишь то, что при расчёте стоимости OSPF, скорости маршрута, или при расчёте стоимости Spanning Tree, или при расчёте bandwidth EIGRP, надо опираться не на физическую скорость, а на эту нарисованную, которую вы задаёте. И вы можете в OSPF сказать, что у вас есть линк, он смотрит на какой-то канал, спутниковый, и вы хотите, чтобы этот линк рассчитывался так, что он имеет существенно меньше полосы пропускания. В этом случае вы можете сказать bandwidth 100, 100 килобит в секунду. И тогда, естественно, стоимость у него будет задрана по самое не могу. На других устройствах других производителей стоимость может рассчитываться совершенно иначе. Имейте, пожалуйста, в виду, что если у вас гетерогенная среда, в которой есть циски и не циски, то как у них стоимость будет назначаться —

одному богу известно. Может быть, стоимость всегда будет единичка. Я видел такие реализации. Может быть, стоимость будет вычисляться по формуле такой же, как у циски. Заранее предсказать то, как у других вендоров это сделано, нельзя. Стандарт не регламентирует никак назначение этих самых стоимостей, поэтому что там будет у других вендоров — одному богу известно. Вот такая штука. Passive interface работает так же, как в EIGRP. Мы, указывая, что какой-то интерфейс будет пассивный, запрещаем отправку и приём hello-пакетов на нём. Точнее говоря, мы не отправляем их, а как следствие, даже если будем их принимать, мы никак не повлияем на ситуацию. Но они там действительно не принимаются. Если вы объявляете интерфейс пассивным, то сосед даже в INIT в списке соседей фигурировать не будет на этом интерфейсе. Так и надо делать. Объявлять интерфейсы

пассивными на тех интерфейсах, где у вас нет и не планируется никаких соседей, например, на тех интерфейсах, которыми вы смотрите на пользователей. Если вас пользователи не пытаются похакать, то у вас интерфейс, на котором вы смотрите на этих пользователей, должен быть включен в OSPF для того, чтобы с этого интерфейса стаб-сетку анонсировать всем остальным соседям в LSA-ке первого типа. Но если мы хотим сказать, что интерфейс точно тупиковый заведомо всегда, то мы на нем не пытаемся подружиться с соседями, и никогда, ни при каких обстоятельствах, там не может быть установлено соседство ни с кем. Эта штука резко повышает безопасность сети и настоятельно рекомендуется, если вы используете OSPF, это использовать на пользовательских интерфейсах. Если таких интерфейсов будет много, то вместо того, чтобы перечислять, что на одном не дружим с соседями, на другом не дружим с соседями, на третьем не дружим с соседями, сказать passive interface default и дальше no passive interface,

перечислять те интерфейсы, на которых с соседями всё-таки дружим. Понятное дело, что в сценарии, например, если мы строим корпоративную сеть, у нас чаще всего OSPF будет запускаться на distribution switch, их будет связывать между собой. Дальше там пачка access switch в реальном интерфейсе, чаще всего она будет работать в режиме L2, поэтому здесь у нас будут треугольники, здесь у нас будет Spanning Tree какой-нибудь, и здесь у нас только будет тот самый OSPF. И дальше куча виланов, которые эти access switch притаскивают. И как следствие, у нас вилан один, вилан второй, вилан третий, вилан десятый, вилан сотый. На всех них надо будет на distribution switch сказать, вот этот интерфейс, рассказываем про него соседям, вот этот интерфейс, рассказываем про него соседям. Не интерфейс, а сетка, да. Что до этой сети пользовательский трафик ходит, до этой ходит. И мы в этом случае говорим passive interface default. На всех виланах выключаем попытки подружиться с соседями, а на интерфейсе, в котором мы смотрим на соседа, и на интерфейсе, в котором мы смотрим на ядро,

мы OSPF, соответственно, включаем. Но их не так много, и указываем no passive interface, и там на одном, на другом, на третьем разрешаем взаимодействие. На всех остальных нельзя. На экзамене наверняка будет вопрос, почему не дружат два роутера между собой. И чаще всего там пытаются вас подловить именно на том, что интерфейс помечен как пассивный. Если вдруг у нас есть OSPF, который мы хотим включить, мы его включаем, и что-то не работает, или оно работало и перестало работать, то алгоритм диагностики OSPF будет примерно очень похож на EIGRP. Сначала проверяем, есть ли у нас сам процесс OSPF, включился ли он, зарегистрировался ли он в качестве легитимного источника маршрутов таблицы маршрутизации. Для этого используется команда show IP protocols. Она показывает, запущен ли сам движок OSPF и показывает краткую информацию, как именно он запущен. В принципе, то же самое можно посмотреть в show IP OSPF. Дальше, после того как мы убедились, что сам OSPF запущен,

он выбрал определённый router ID, проверяем входящие интерфейсы в OSPF, то есть на каких интерфейсах OSPF завёлся. Команда show IP OSPF interfaces. Убедились, что на всех интерфейсах, на которых надо, OSPF завёлся, смотрим соседство. Show IP OSPF neighbors. Здесь не показано, но да, neighbors. Это покажет список соседей, с которыми установлены соседские взаимоотношения, или могут быть установлены соседские взаимоотношения. Даже, например, сосед в Init висит, гипотетически нормальный сосед, но почему-то он не видит hello-пакеты от нас. Но если с соседями всё хорошо, видим, что они в Full, значит, таблица с ними реплицирована. Проверяем то, что там OSPF насчитал. Show IP OSPF route — это просмотр результатов вычислений кратчайших маршрутов до вброса в таблицу маршрутизации. И show IP route OSPF — это после вброса в таблицу маршрутизации, просмотр самой таблицы маршрутизации. Это две разные команды. Show IP OSPF route — это просмотр сырых результатов OSPF,

и show IP route OSPF — это просмотр уже чистого результата, готового в самой таблице маршрутизации. Они на самом деле не совсем похожи, в том смысле, что может быть такое, что show IP OSPF route показывает, что какой-то маршрут есть, OSPF его посчитал, а в таблицу маршрутизации вбросить не смог. Например, потому что там уже было занято. И тогда show IP OSPF route маршрут покажет, а show IP route OSPF — нет. Так. Как мы всё это дело диагностируем? Сначала проверяем, что у нас есть show IP protocols. Здесь… Сейчас оно есть? Нет? Нету. Show IP protocols покажет, что OSPF завёлся, покажет какие команды network и на каких интерфейсах OSPF включился. Здесь нету, но наверняка мы сейчас это посмотрим в реальности. После того как посмотрели, что OSPF завёлся, проверяем show IP OSPF interface. Если просто show IP OSPF interface заказать,

она покажет простыню по каждому отдельному интерфейсу, поэтому чаще её запускают с ключом brief для того, чтобы посмотреть вывод в табличном виде. Это полный аналог show IP EIGRP interfaces. Всё то же самое. Показывается интерфейс, на котором OSPF завёлся, показывается в каком экземпляре, показывается в каком регионе, какой IP-шник с маской. Кстати, IP-шник с маской должны быть в одной сети для двух роутеров, которые пытаются установить соседские взаимоотношения. Стоимость. В нашем случае мы видим, что стоимость единичка, что неудивительно, учитывая, что интерфейс у нас гигабитный. Для гигабитных интерфейсов 100 мегабит, разделённое на гигабит, даст нам стоимость копеечку. Равно как и для Fast Ethernet. Как раз поведение по умолчанию такое, что на все интерфейсы стоимость назначается единичка, и получается, что Cisco не различает гигабитные и 100-мегабитные интерфейсы в настройках по умолчанию. Дальше указывается, какая роль на этом интерфейсе

у нашего роутера есть. Показывается, что мы DR, designated router, то есть мы диспетчер. И показывается, что на этом интерфейсе обнаружен один сосед, и с ним установлены полные соседские взаимоотношения. Первая циферка — это сколько полных соседей, вторая — сколько всего. Соседей было обнаружено, возможно, включая two-way соседей, с которыми в полные взаимоотношения мы не переходим. Но поскольку мы DR, сколько бы соседей ни было, мы со всеми будем дружить, поскольку диспетчер дружит со всеми. Это его работа. Дальше. После того как мы посмотрели список интерфейсов, на которых OSPF завёлся, здесь показываются и пассивные интерфейсы в том числе. Я не уверен, что это будет на CCNA проверяться на экзамене, но на курсе по роутингу, точнее на экзамене по роутингу, точно будет вопрос на тему того, показываются ли пассивные интерфейсы в выводе определённой таблички. В EIGRP пассивные интерфейсы не показываются. Здесь не будет пассивных интерфейсов, если это будет команда show IP EIGRP interface.

А OSPF пассивные интерфейсы, наоборот, показывает. Возможно вполне, что у вас интерфейс показывается, но соседей на нём не обнаружено, именно потому что интерфейс этот пассивный. Это подлость со стороны Cisco, про неё надо просто знать. У Cisco есть такие мелкие подлости, которые она раскладывает, такие грабельки. Если не знаешь, то можно на них наколоться. На экзамене будет вопрос, типа покажите, что интерфейс, который в списке интерфейсов присутствует, что он действительно не может установить соседские отношения с другими роутерами. Да, такое может быть. Если мы видим, что интерфейс у нас в OSPF зажёгся, то есть этот интерфейс через команду network или команду IP OSPF area на этом интерфейсе включился. Дальше мы проверяем, что два роутера, которые друг на друга смотрят этими интерфейсами, которые включились,

что они находятся в одном регионе. В нашем случае мы видим, что регион нулевой, допустим, с этой стороны, значит, нулевой регион должен быть и с другой стороны тоже, иначе соседства не будет. И проверяем, что соседство действительно было установлено. Что show IP OSPF neighbor покажет IP-шник соседа. Вот это — это IP-адрес. ID-шник соседа. Вот это — это ID. Это идентификатор. Это не IP-адрес. В конкретно этом выводе специально показано, что ID-шник зачастую бывает очень похож на IP-шник. 10.0.0.2 в первой колонке, 10.0.0.2 во второй колонке. Они визуально очень похожи. И это может быть в ситуации, когда у вас два роутера в абстрактном вакууме висят и больше ни на что не смотрят. Но ID-шник уникален для роутера, и он на всех интерфейсах, естественно, будет одинаковый, потому что он всего один. ID-шник 10.0.0.2. А может быть, это loopback такой есть на нём. А IP-шник будет совершенно разный.

Если у вас есть только два роутера, которые связаны между собой только этим интерфейсом, никаких loopback нет, то в колонке Neighbor ID и IP-адрес там будет, соответственно, одинаковое, скорее всего, всё. Но если вы взяли и повесили на loopback специальный адрес, прибили его гвоздями с помощью команды router-id, а здесь у вас IP-шники, например, 192.168.0.1, а здесь .2, то у вас получится, что IP-адрес — это именно IP-шник, 192.168.0.2, а Neighbor ID — это 10.0.0.2, это ID-шник, который указывает именно на роутер целиком. Дальше. Показывается в этой колонке, кто сосед и как мы с ним дружим. Первое до дроби указание — это в какой стадии находится сосед. В нашем случае мы видим, что соседство у нас полное, то есть мы с этим соседом прошли все стадии. Init, TwoWay, Start, Exchange, Loading и, наконец, остались Full. Full — это стабильное состояние, которое длится неограниченно долго.

И показывается, почему мы с этим соседом находимся в полном взаимоотношении. Потому что он BDR. Даже несмотря на то, что мы сами DR, и поэтому мы со всеми дружим полностью, мы с ним тоже будем дружить полностью, в том числе и потому, что он запасной диспетчер, а с запасным диспетчером тоже все дружат. Так. Дальше. Показывается таймер, через сколько мы признаем соседа мёртвым, если он нам ничего нового не пришлёт. И показывается, на каком интерфейсе мы обнаружили этого соседа. Далее. После того как мы посмотрели, соседство установлено, по идее всё должно быть хорошо. И смотрим, что сосед накормил нас маршрутами. Show IP route OSPF — это команда, которая покажет таблицу маршрутизации. Маршруты OSPF показываются с буковкой O. Здесь могут быть ещё какие-то другие буковки. На них пока мы не обращаем внимания.

Там может быть, например, буковка IA, может быть буковка E1, E2, N1 или N2. Это всё OSPF маршруты. У них у всех обязательно будет первая буковка O. Дальше показывается префикс, который нам притащил OSPF. Административное расстояние OSPF — 110. Итоговая метрика, которую нам насчитал OSPF. В нашем случае метрика 2, потому что одну копеечку стоит интерфейс, которым наши роутеры связаны между собой. И ещё одну копеечку стоит интерфейс, которым роутер смотрит в эту сеть. Эта копеечка тоже считается. Показывается NextHop, который мы сами посчитали, и показывается, через какой интерфейс такой трафик будет выходить. И время, как давно такой маршрут попал в таблицу маршрутизации. Давайте попробуем это дело понастраивать. Наша задача сейчас будет

включить OSPF второй версии для наших роутеров. У нас сейчас на наших роутерах есть некоторое количество интерфейсов, которые пока что реплицируются, IP-шники с них, с помощью EIGRP. Сейчас давайте проверим, что действительно EIGRP у нас там ещё остался. Enable, show IP route. Да, некоторое количество EIGRP-шных маршрутов есть. Наша задача сделать так, чтобы эти маршруты стали OSPF. EIGRP нам для этого придётся убрать. Указываем, что no router EIGRP 65000. Такой у нас, кажется, был, да? Не такой. 65500. Тоже не такой. А какой? Do show IP router close. 65001. Почти угадал. 65001. Отключаем EIGRP.

На нашем роутере его больше нету. Маршрутов, которые он притаскивает, тоже больше нету. Можно сделать и на центральном то же самое, но это на скорость не повлияет, так что да. Мне лень это делать, поэтому потом сделаю. И вместо EIGRP-шного роутера запускаем OSPF. Router, OSPF и дальше тот самый номер экземпляра OSPF, который мы хотим использовать. Номер экземпляра по сети не передаётся. Абсолютно неважно, какой вы будете использовать, поэтому рекомендую использовать первый, просто потому что почему бы и нет. Когда мы указываем router OSPF и дальше указываем номер экземпляра, одновременно происходит несколько событий. Первое, то, что мы видим глазками, приглашение к вводу изменяется, становится config-router. Мы проваливаемся в субконтекст настройки роутера. На самом деле, в этот момент уже запущен процесс OSPF, новый сервис на роутере поднялся, новый процесс запустился, роутер уже выбрал себе router ID, и мы это можем увидеть

do show IP protocols, что OSPF уже есть. Вот он. OSPF процесс запустился, зарегистрировался в таблице маршрутизации в качестве легитимного источника маршрутов, получил дефолтное административное расстояние 110, он может взять и попытаться вбросить в таблицу маршрутизации чего-нибудь. Здесь у нас, например, есть другой способ вброса маршрутной информации в таблицу, некий application, неважно, что это такое, но оно может вбросить какие-то маршруты в таблицу маршрутизации, и по умолчанию административное расстояние у таких маршрутов будет 4. 4 — это хуже, чем статика с единичкой, 4 — это хуже, чем connected с ноликом, но 4, например, лучше, чем EIGRP, у которого 90, и определённо лучше, чем OSPF, у которого 110. Если вдруг будет драка за попытку вбросить в таблицу маршрутизации маршрут, причём один источник маршрутной информации будет говорить, что он знает, как добраться до этой сети одним образом, а другой будет говорить, что он знает, как добраться до этой сети, ровно до этой же сети,

с ровно этим же IP-шником, с ровно этой же маской, другим способом, через другой next hop, через другой интерфейс, то выиграет тот, у кого административное расстояние будет меньше. В нашем случае у OSPF административное расстояние по умолчанию будет 110. Плюс router ID автоматически выбрался, автоматически router ID был назначен равным самому большому IP-шнику на loopback-ах, которые у нас были. Loopback у нас всего один, поэтому сложности здесь не возникло. И самый большой IP-шник на loopback-ах — 10.2.8.8 в моём случае. Это router ID. Он равен IP-шнику, но гипотетически нам никто не мешает взять и переопределить этот router ID и сделать его любым другим. Никто нам не мешает сказать, что у нас router ID будет, не знаю, 0.0.0.8. Главное, чтобы он был уникальный в пределах всей автономной системы. Дальше показывается, во сколько разных регионов смотрит наш router своими интерфейсами. Поскольку мы вообще ни на одном интерфейсе OSPF пока не включали, никуда он не смотрит,

и количество регионов на нашем роутере нулевое. Если бы у нас был интерфейс, смотрящий в один регион, мы были бы internal router. Если бы у нас были интерфейсы, смотрящие в несколько разных регионов, то мы могли бы либо быть internal роутерами во все эти регионы одновременно, если бы у нас не было нулевого региона среди них, или мы могли бы стать ABR, если бы мы имели нулевой регион в том числе. Для того, чтобы стать ABR, для того, чтобы перекладывать маршруты между регионами в виде LSA type 3, нужно быть ABR. А для того, чтобы стать ABR, нужно иметь нулевой регион. Дальше показывается здесь, какие команды network мы запустили. Следующее, после Routing for Networks, поскольку мы сейчас ничего пока не запустили, показывается, на каких интерфейсах мы OSPF запустили явно, но мы, опять же, ничего не запускали в явном виде, поэтому даже строчки такой нету. Но мы обязательно повключаем и в явном виде, и в неявном OSPF на интерфейсах, поэтому посмотрим,

на что это влияет чуть дальше. У нас есть запущенный экземпляр OSPF. Мы увидели, что router ID назначился. Давайте router ID поменяем. И несмотря на то, что я говорил, что есть best practice, который говорит, что router ID нужно назначать вручную на IP-шник loopback-а, который тоже будет потом попадать в OSPF для того, чтобы на этот IP-шник можно было телнетом зайти, попингать его, я рекомендую сейчас в рамках нашей лабораторной работы сделать не по best practice. Я рекомендую сейчас в рамках нашей лабораторной работы сделать router ID, который не будет похож на IP-адрес. И router ID я предлагаю сделать 0.0.0. номер комплекта. Такой IP-шник быть не может. Он в зарезервированной сети 0.0.0.0/8. И IP-адрес так выглядеть не имеет права. А router ID — пожалуйста, никаких проблем, он таким может быть. Адреса такого, естественно, поскольку IP-адрес таким быть не может, адреса такого

у нас нету. А router ID есть. Дальше. Можем сделать так, чтобы наши интерфейсы имели бы не дефолтные стоимости. Для этого нужно будет поставить AutoCost ReferenceBrandless, но я предлагаю этого не делать. В экзамене вас про это спрашивать вряд ли будут, и команда тоже вряд ли будут заставлять изучать. Но, тем не менее, да. Если что, AutoCost, вот эта вот штука, она как раз указывает, какие стоимости интерфейсы будут получать автоматически. В любом случае можно переопределить ReferenceBandless, и в любом случае можно на интерфейсе назначить стоимость ручками. Кроме того, можно будет сказать, что если мы вычисляем стоимости автоматически, то от какой реальной полосы пропускания будет отталкиваться SPF при расчете коста. Можно будет сказать, что нужно взять Bandless с интерфейса, или можно будет переопределить этот Bandless командой, ну, он так и будет называться Bandless.

Так. Мы включили роутер SPF, и мы можем захотеть включить некоторые интерфейсы в этот самый SPF командой Network. Это один из способов задать участие интерфейса в SPF. И давайте мы включим SPF на том интерфейсе, который смотрит на центральный роутер. Network 10.100. Номер комплекта точка номер комплекта по маске 0.000. Это именно тот самый интерфейс, на котором будет IP-шник 10.188. Я хочу включить в OSPF. У меня такой адрес, у вас другой, ну, соответственно, вы должны будете условия access-листа включить такую, которая захватит хотя бы вот тот IP-шник, который вы захотите, который у вас висит на нужном вам интерфейсе. В принципе, можно сказать, Network 0000 255 255 255 255 и вы включите тем самым OSPF вообще на всех интерфейсах. Никто вас не запрещает вам такое сделать. То есть, пожалуйста, включайте OSPF на всех интерфейсах,

если хотите. Ну, и указываем, что номер региона у нас будет нулевой. То есть, на нашем маленьком роутере мы включили OSPF на интерфейсе, который смотрит на центральный. На центральном надо сделать ответные действия. И пришла пора туда тоже подключаться. enable conft no router egrp 65000 первый. Все-таки заставили меня это сделать. Роутер OSPF один. Network. И здесь мне очень лень писать отдельно включи на том, отдельно на секом, отдельно на пятом, отдельно на десятом. 10, 100, 00, по маске 00, 255, 255. Включи на всех интерфейсах, на которых айпишники начинаются на 10, 100. Включить OSPF на интерфейсе это два действия. Сначала отправить и получать hello-пакеты. И во-вторых, это включить connected сетки в анонс волосейки первого типа.

Ну и, соответственно, номер региона должен будет совпадать. Как только я это сделал, пробежало соответствующее сообщение. Было обнаружено два соседа на центральном роутере. И центральный роутер, соответственно, тоже установил соседские отношения с нашим маленьким роутером. Пробежало сообщение, что сосед с определенным ID-шником на определенном интерфейсе перешел из фазы loading в фазу full. На самом деле, он прошел все стадии init, to way, xstart, exchange, loading, full. Но только нам показывают, что самое важное, что для нас случилось, это что с соседом установлены полные соседские взаимоотношения. И поэтому то, что он в фазу full перешел, это для нас важно. В принципе, если очень захотеть, можно включить дебаг и просмотреть все остальные стадии тоже. Дальше. То, что роутеры у нас установили соседские взаимоотношения, в принципе, нам уже дает

первые плоды. Давайте посмотрим на диагностику того, что у нас OSPF может нам показать. Выходим из конфига и смотрим первое действие. Show IP OSPF protocols. Show IP просто protocols без OSPF, простите. Показывается, что у нас есть OSPF, ну то есть вот это вот мы уже видели, OSPF с номером экземпляра единичка. Роутер ID 0008. Он применился сразу и здесь тонкий момент. Когда вы обычно задаете роутер ID, у вас все лосейки, которые были выпущены со старым роутер ID, они должны быть сброшены и перевыпущены с новым роутер ID, потому что в самих лосейках содержится указание на то, кто их выпустил. Поэтому, если вы хотя бы одну лосейку выпустили и потом поменяли роутер ID, то в этом случае роутер вас предупреждает. Извините, говорит, но до ближайшего ребута я буду использовать все-таки

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

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

SPF. И тогда все LSA-ки, которые были выпущены до того, они сбросятся, оно бы уже перевыпустится с новым роутер-ид. Дальше. Показывается, во сколько разных регионов смотрит наш роутер. Это один нормальный регион. Ну, нормальный это в смысле не какой-то специфический. Нулевой регион, он нормальный. Он, несмотря на то, что имеет свою особенную роль, у него никаких ограничений нет по сравнению с некоторыми другими типами регионов. В частности, вот эти вот два товарища с ТАБ и NSSA. Это регионы уродцы. Вот у нас нету регионов уродцев. У нас один нормальный регион. Более того, он даже привилегированный, не просто нормальный, а регион транзитный. Ну, и в него смотрят вот интерфейс, на котором мы включили OSPF. Включили мы OSPF в команду Network на интерфейсе. И вот она, эта самая команда Network имела вид Network 10.188 по маске 0.000 Area 0. Ну, несложно догадаться, что интерфейс,

который у нас появился, он появился именно в нулевом регионе. И дальше какие у нас есть роутеры в топологии. 0.001 это роутер как раз первого комплекта. Здесь показывается, несложно видеть ID-шник. IP-шник таким быть не может, а ID-шник может. И вот 10.188 это ID-шник центрального роутера. После того, как мы посмотрели на Show IP protocols, можем посмотреть на интерфейсы Show IP OSPF Interface Brief Interface Brief показывается табличный вывод, если я заказал Brief, без Brief будет простыня. И показывается, на каком интерфейсе, в каком экземпляре OSPF, в каком регионе, какой IP-шник с маской, какая стоимость у нас получилась. Мы AutoCost Reference Bandwidth не задавали, поэтому у нас она 100 Мбит, и на 10 Мбитном интерфейсе получается стоимость как раз 10.

На этом интерфейсе я запасной диспетчер, потому что центральный роутер стал диспетчером. У него, то ли приоритет больше, то ли IP-шник больше. Я так догадываюсь, что IP-шник больше. И, соответственно, не IP-шник, а ID-шник. ID-шник у меня 0008, а у него 1088. И один сосед на этом интерфейсе был обнаружен. Можно посмотреть, какой именно это сосед, show ip OSPF neighbors, один сосед, поэтому neighbor. Это айдишник, это айпишник. У меня они совпадают, у вас нет. Это приоритет, который у соседа используется при выборах DR-а, BDR-а. У меня точно такой же приоритет, поэтому при выборах DR-а, BDR-а приоритет не роляет. Но айдишник уже роляет. Состояние FULL означает,

что у нас с этим соседом обеспечено полное соседское взаимоотношение, мы полностью реплицируем таблицы друг с другом, и он DR, а я, соответственно, BDR. Что важно, это у нас интерфейс прямой, мы друг на друга смотрим прямым проводом. Тем не менее, всё равно в этом проводе выбирается диспетчер, всё равно выбирается запасной диспетчер, и всё равно выпускается LSA второго типа. Она там не нужна, по большому счёту. Она только усложняет топологию. В реальности, если бы мы на этом интерфейсе никакую LSA второго типа не делали, и запасного диспетчера не выбирали, топология бы только упростилась. Но наши два роутера не знают, что между ними прямой провод. Они говорят, гипотетически Ethernet — это такая штука, в которой может в любой момент образоваться между двумя роутерами свитч, и его вообще никак не отследить, потому что любой свитч пытается прикинуться толстым жёлтым коаксиалом. Непонятно, это Ethernet 0.1, это толстый жёлтый коаксиал между нами,

прямой, это два медных провода со свитчем между ними или с хабом, непонятно. По внешнему виду непонятно, есть ли там другие роутеры, нет там роутеров, может он просто есть, но выключен сейчас, и он через некоторое время только включится. Поэтому на всякий случай роутеры по умолчанию делают LSA второго типа. Это поведение потом можно отключить. На курсе по роутингу как раз будем отключать, но по умолчанию она там есть. Когда соседи обнаружены, они нам притаскивают LSA. Эти LSA можно посмотреть командой show ip ospf database. Мы сейчас не будем детально изучать, какие там именно LSA есть и что внутри них передаётся, это всё-таки тема для курса по роутингу, но здесь можно просто рамочно посмотреть, что это LSA первого типа, они называются router link states, а это LSA второго типа, это net link states, network LSA. Соответственно, это LSA, которую придумал роутер первого комплекта,

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

и центральным, другая за связь между восьмым и центральным. Link ID — это идентификатор самой LSA, и она числово совпадает с IP-шником DR. А, соответственно, Advertising Router — это ID-шник того, кто её придумал. Это ID-шник DR. Здесь IP-шник DR, а здесь ID-шник. Advertising Router — это всегда роутер ID. И хорошо видно, что в первом комплекте роутер DR — это будет сам первый роутер, а в восьмой паре DR стал центральный роутер. И, соответственно, если вдруг мы захотим добавить ещё интерфейсов, мы это можем сделать с помощью команды уже другой, не команды network, а команды в явном виде на интерфейсе, участвующем в OSPF. И давайте так и сделаем. У нас как раз есть loopback-интерфейс. Мы сейчас на нем повключаем OSPF. Conf.t interface loopback 0. IP OSPF 1.

Area. Давайте другую area сделаем. Area с номером комплекта. У нас получится наш роутер ABR. У него есть интерфейс, смотрящий в нулевой регион, и интерфейс, смотрящий в ненулевой регион. И посмотрим, на что это повлияет. Show IP OSPF interface brief. Появился новый интерфейс в OSPF. Это по-прежнему процесс номер один, но регион номер восемь. Показывается IP-шник и маска. Показывается стоимость этого интерфейса. Наши воображаемые интерфейсы loopback имеют номинальную скорость 4 гигабита. Поэтому у них стоимость получается одна копеечка. Соответственно, состояние на этом интерфейсе не DR, не BDR. Cisco знает, что loopback-интерфейс нарисованный, поэтому на таком интерфейсе она не выбирает

DR, не выбирает BDR. Она говорит, это нарисованный интерфейс. Мы все понимаем, что интерфейс нарисованный, поэтому там нет смысла выбирать диспетчера, запасного диспетчера, выдумывать эластику второго типа. Это не настоящий интерфейс. Поэтому state, где у нормальных интерфейсов показывается DR, BDR, или прочерк, что ни DR, ни BDR не выбираются, здесь показывается, что это loopback. Cisco не пытается нас перехитрить, мы знаем, что это нарисованный интерфейс. И на нем не обнаружены соседи, Cisco даже не пыталась их обнаруживать, она не посылает loopback самой себе hello-пакеты, именно потому, что это loopback. После того, как show IP OSPF interface brief нам показал, что на интерфейсе у нас что-то есть, можно посмотреть опять show IP OSPF database и посмотреть, на что у нас повлияло добавление нового интерфейса. И здесь мы увидим вот что.

Во-первых, в нулевом регионе ничего не изменилось. Количество линков в нулевом регионе на роутерах как было, такое и осталось. Наши роутеры первый и восьмой в нулевой регион по-прежнему смотрят всего одним линком, всего одним интерфейсом. Но они стали ABR-ами. Поэтому у нас sequence-номера выросли, эти LSA-ки изменились. Раньше они говорили, что я просто обычный роутер, а сейчас, что я роутер хитрый, продвинутый. Сейчас отмотаю немножко наверх. Видите, какие у них sequence-номера у этих двух LSA-ек? Заканчиваются на двойку и на пятерку. После того, как мы включили на них интерфейсы, смотрящие в другие регионы, они стали декларировать, что они теперь ABR-ы. И поэтому у них sequence-номера выросли на единичку. Стали вместо двойки пятерки, тройка и шестерка. Эти LSA-ки как были, так и остались. Это то, что первый роутер смотрит на центральный и восьмой смотрит на центральный. Они нам не сильно нужны, но они уже выпущены и есть не просят. И появились

summary net link states. Это LSA-ки-суммарки, LSA-ки-трешки, в которых рассказывается про то, что за пределами нулевого региона есть какие-то другие сети. И мы здесь видим link ID. Это IP-шник сети, про который нам рассказывается. Там в глубине самой LSA-ки рассказывается про то, что маска у этих маршрутов 32-ая. И, соответственно, кто их придумал. Это ID ABR-а. Простите, ID ABR-а. Когда мы видим такую суммарку, в ней внутри написана некая стоимость, например, 10 копеек. ABR рассказывает, что он знает эту сетку за 10 копеек. Дальше мы строим кратчайший маршрут до ID-шника ABR-а, а мы его знаем, потому что у нас есть такая LSA-ка. И после этого мы прибавляем кратчайшую стоимость, как добраться до ABR, которую мы сами посчитали, с той стоимостью, которая написана здесь, внутри этой LSA-ки, и получаем итоговую сумму, как добраться до сети, за сколько копеечек.

Помимо того, что у нас всё происходит в нулевом регионе, за счет того, что наш роутер стал ABR, он теперь смотрит и в ненулевой регион тоже. И эта часть рассказывает про Area 8, в моем случае 8. Всё это было за Area 0, а это всё за Area 8. Здесь показывается, что есть целый один роутер, это я сам. Соответственно, в восьмой регион мой восьмой роутер смотрит одним интерфейсом. И показывается, что есть целая куча сетей, которые известны за пределами восьмого региона. Зачем эта вся штука нужна этому роутеру? Затем, что если вдруг в восьмом регионе появится какой-то другой роутер, то ему придется про всё это рассказать. Соответственно, у нас уже должна быть наготове база готовая, которую мы ему выдадим, если вдруг он появится. Поэтому всё, что мы ему собираемся рассказать в восьмом регионе, всё у нас уже наготове лежит. Понятное дело, что в этой ситуации пользоваться мы по факту будем базой нулевого региона. И восьмой регион

нам при этом не сильно нужен. Но он на всякий случай есть. Так, ну и маршруты, которые в таблице маршрутизации будут строиться. Show ip route. Они будут помечаться буковкой O. Эти маршруты нам прислал центральный роутер. Он говорит: я знаю, как до этих сетей добраться. Я в них смотрю десятикопеечными интерфейсами. Плюс мы посчитали, сколько стоит добраться до него, и посчитали, что кратчайший способ добраться до него — это просто по новому интерфейсу Ethernet-01 пройти, тоже стоит 10 копеек. В итоге два этих маршрута стоят 20 копеек. Второй и первый роутер гипотетически мне тоже могли бы рассказать про эти сети. Получается, что то, что центральный роутер анонсирует эти сети тоже, даёт мне возможность до этих сетей добраться дешевле. А эта сетка — это, соответственно, сетка, которую первый роутер первого комплекта анонсирует мне как ABR, и я строю

кратчайший маршрут до него. Это стоит 20 копеечек. Мне нужно пройти через свой интерфейс Ethernet-01 и пройти до него самого, до этого самого первого роутера, тоже через интерфейс 10-мегабитный. Каждый из интерфейсов стоит 10 копеек. Получается, до ABR мне стоит добраться 20 копеек. И ещё сама LSA-четвёрка, в которой рассказывается про то, что есть сетка 10.201.1 по 32-й маске, стоит 1 копейку. В итоге 20 копеек добраться до ABR плюс 1 копейка — суммарная стоимость за спиной ABR, которую я не вижу, как формируется, — дают нам суммарную стоимость 21 копейку. При этом это маршрут, полученный не совсем по-честному. И Cisco мне показывает буковку IA, это значит Inter-Area маршрут. Часть из стоимости 21 копейку мы посчитали самостоятельно, и мы можем подписаться под тем, что действительно 20 копеек — именно 20 копеек, мы знаем, как они шли, между какими роутерами,

между какими линками, между какими интерфейсами. А часть этой стоимости мы доверились ABR, пусть небольшую, в нашем случае 1 копейку, но тем не менее мы поверили, что за спиной у ABR этот маршрут продолжается, и суммарная стоимость там будет 1 копейка. Мы её уже не проверяем, мы не видим за спиной у ABR, как выглядит сетка. Здесь как раз хорошо видно, что мы знаем, как ABR, как устроен 8 регион, мы знаем, как устроен 0 регион, но как устроен 1 регион, мы не знаем, потому что это скрыто за спиной у ABR 1 региона. И особенность Cisco заключается в том, что если вы берёте loopback интерфейс и включаете на нём OSPF, то неважно, какая у вас сетка висит на самом интерфейсе, у нас она висит 24-я. Cisco всегда анонсирует IP-адрес с loopback по 32-й маске. Это поведение, правда, можно отключить, но по умолчанию оно именно так. Поэтому мы здесь видим 10.201.1 по 32-й маске,

несмотря на то, что на самом интерфейсе вероятно висит 24-я. Это, пожалуй, всё, что я хотел рассказать про IPv4 OSPF. И дальше, наверное, нас ждёт IPv6 OSPF 3-й версии. Добавился в кастом. И в кэше я хотел показать