OSPFv3 в Cisco IOS

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

В принципе, по большому счёту, всё в OSPF третьей версии так же работает, как в IPv4, в OSPF второй версии. Различия там на самом деле косметические. Немножко другие LSA-ки. Разделили, например, адресную и топологическую информацию в LSA-ках первого типа. Топологию оставили в LSA-ке первого типа, а адресную информацию вынесли в 8-й, 9-й тип. Дальше. Некоторые вещи, которые в OSPF2 были наследием тяжёлых старых классовых времён, в OSPF3 выпилили. Такую как команду network. Если вы помните, когда-то давным-давно команда network имела смысл. Там действительно вы включали протокол динамической маршрутизации на интерфейсах командой network. И ровно эта команда когда-то давным-давно включала классовую сеть в анонс нужного протокола. И на том единственном интерфейсе, который смотрел в эту классовую сеть, включала указанный протокол. Но в бесклассовом мире, примерно с начала 90-х годов, команда network смысл потеряла, потому что она фактически задаёт условия access list, который перебирает все интерфейсы, которые у вас есть в системе, и включает нужный протокол только на тех интерфейсах, первичные IP-адреса которых попадают под указанный access list.

Поэтому, когда мы говорим, что в IPv4 протоколах динамической маршрутизации есть команда network, мы понимаем, что ничего связанного с сетями эта команда не делает. Она не указывает сеть для того, чтобы анонсировать соседям, она никак вообще ни с какими префиксами не работает напрямую. Она лишь включает OSPF на тех интерфейсах, которые попадают под указанные условия. А дальше уже connected-сетки с этих интерфейсов, которые, опять же, ничего общего могут не иметь с действием команды network, попадают в анонс. В OSPF третьей версии никакой команды network нету, к счастью. Можно единственным образом включить OSPFv3 на интерфейсе — если вы идёте на интерфейс и включаете его в явном виде. Синтаксис такой же, как был для IPv4 OSPF. Если там было ip ospf 1 area 0, то здесь у нас ipv6 ospf 1 area 0. При этом цифра 1 будет означать номер экземпляра OSPF. И точно так же, как в IPv4, этот номер не передаётся по сети, никоим образом не влияет на взаимодействие устройств.

Единственная задача этого номера — быть консистентным в пределах одной железки. При этом в литературе иногда встречается фраза типа «OSPF третьей версии оперирует так называемым instance ID». И этот instance ID должен совпадать на соседних устройствах. Пожалуйста, не путайте. Номер экземпляра, который мы задаём в команде ipv6 router ospf, — это именно номер экземпляра. Мы, конечно, можем называть это словом instance, но более корректно будет сказать именно номер экземпляра. А instance — это штука, которая автоматически циской вычисляется, и она естественным образом будет совпадать тогда, когда вы будете включать OSPF на разных железках. Она не будет никак зависеть от этой цифры 1. Это не instance, это другое. А instance — это фактически указание, какой тип протокола вы будете использовать. Либо IPv4 unicast, multicast, либо IPv6 unicast, multicast. В случае если вы выбираете какой-то конкретный протокол, то instance там автоматически выбирается.

И смысл того, что в литературе пишут под фразой «instance должен совпадать», — что когда у вас с одной стороны OSPFv3 перетаскивает IPv4-маршруты, с другой стороны тоже железка должна быть готова эти самые IPv4-маршруты принимать. Если у вас с одной стороны IPv4-маршруты отправляются, они не должны попадать в базу IPv6-маршрутов на соседях. Так что это не instance, это номер экземпляра, и он не обязан совпадать на соседних железках. Единственное, что нужно, — чтобы везде, где вы ссылаетесь на этот номер экземпляра в пределах своей железки, вы ссылались на него правильно. Но опять же, если вы работаете с одним экземпляром, самый правильный вариант будет назначить всегда номер 0, и этого будет более чем достаточно. Так же, как в IPv4, вы можете назначить router ID. И на самом деле имеет прямой смысл задавать этот router ID ручками. Дело в том, что если у вас нет ни одного IPv4-адреса, то автоматически назначить себе router ID маршрутизатор не сможет.

Он использует точно тот же самый алгоритм, который используется в IPv4 OSPF. Берёт сначала самый большой IPv4-адрес с loopback. Если loopback-ов нет или на них нет IPv4-адресов, просто берёт самый большой IP-адрес, который у вас есть на железке. Но router ID — это 32-битное число, которое записывается в формате IPv4-адреса. OSPF третьей версии — это протокол синхронизации таблицы IPv6. У вас может быть роутер, который IPv6 only, и на нём нет ни одного IPv4-адреса. И router ID автоматически выбрать роутер не сможет, если у него IPv4-адресов нет. Вы должны будете в этом случае задать такой router ID, который будет уникальный и который позволит самому процессу запуститься. Мы указываем ipv6 router ospf. Дальше номер. Переходим в контекст config-rtr. Обратите внимание на то, что в IPv4 у нас приглашение к вводу — это config-router.

В IPv6 — это config-rtr. Дальше надо на интерфейсе зайти и сказать, что на интерфейсе IPv6 OSPF будет работать. Заходим на интерфейс, и то, что у нас было ip ospf 1 area 0, здесь ipv6 ospf 1 area 0. Так же, как и для EIGRP, так же, как и для RIP, для работы OSPFv3 не требуется маршрутизируемых IPv6-адресов на интерфейсах. Достаточно иметь link-local адреса. Этого более чем достаточно. Далее. В нашем случае у нас есть два роутера, связанные между собой интерфейсами GigabitEthernet 0/0 с обеих сторон. Мы заходим на GigabitEthernet 0/0 с одной стороны, на GigabitEthernet 0/0 с другой стороны, и там указываем ipv6 ospf 1 area 0. Если там нету никаких других IPv6-адресов, то имеет смысл включить взаимодействие IPv6 на этих интерфейсах командой ipv6 enable.

Там появится link-local адрес, и дальше из-под этого link-local адреса будут отправляться hello-пакеты, и приниматься hello-пакеты тоже будут из-под link-local адреса соседа. Далее. Если у нас есть пользовательские интерфейсы, в нашем случае там FastEthernet 0/0, FastEthernet 0/1, 0/2 по /64 маске, разные FastEthernet-ы. На роутере может быть действительно много FastEthernet-ов. На distribution-свитчах, скорее всего, будут и SVI, VLAN-ные интерфейсы. Но в любом случае на каждом из них тоже нужно будет зайти и сказать: на этом интерфейсе работаем, на этом интерфейсе работаем, на этом интерфейсе тоже работаем. Немножко, конечно, неудобно по сравнению с IPv4 OSPF, где можно было одной командой повключать OSPF сразу на многих разных интерфейсах, если правильно, корректно задать действие команды network. Но тем не менее команды network больше нету, поэтому приходится всё делать ручками.

После того как мы запустили OSPF на нужных нам интерфейсах, будет дальше возникать вопрос: у нас всё хорошо или нехорошо? В принципе, по большому счёту, всё должно быть сразу хорошо, но если где-то что-то у нас не получилось, то надо будет смотреть диагностику. Так же, как для IPv4, у нас есть команда show ip protocols, а здесь — show ipv6 protocols. Show ipv6 protocols показывает нам, что у нас тут есть OSPF, номер экземпляра единичка, router ID — наверное, ручками задали. И судя по тому, что это 0.0.0.1, это не может быть адрес с loopback, значит, он ручками задан. Опять же, так же, как в IPv4, у нас может быть несколько разных интерфейсов, которые перекладывают маршруты между разными регионами. В нашем случае именно этот роутер, у него один регион, в который он смотрит всеми своими интерфейсами. И показывается, в каком регионе интерфейс есть.

В нулевом регионе у нас GigabitEthernet 0/0. Можно посмотреть на то, как выглядит настройка, как выглядит каждый конкретный интерфейс в части диагностики, в части настроек. Есть специфическая команда show ipv6 ospf. Здесь показано, что у нас есть OSPF с номером 1, экземпляр номер 1, router ID 0.0.0.1. И показываются всякие разные специфические для OSPF вещи, типа reference bandwidth. Та самая, от которой косты считаются. Показано, какие именно у нас есть регионы. Показано, что есть нулевой регион, специальный транзитный. Что в нём есть один интерфейс. Что в этом регионе пересчитывалась топология за последнее время два раза. И количество LSA — 5 штук. Далее. Есть команды, которые привычны нам с OSPF для IPv4.

Это команда show ip ospf interface, которая стала show ipv6 ospf interface. Опять же, так же, как и в случае с IPv4, есть show ipv6 ospf interface brief. Brief показывает в табличном виде, если вам неинтересно читать большую простыню по каждому интерфейсу. Show ipv6 ospf interface brief покажет, в каких процессах OSPF какие интерфейсы присутствуют. В нашем случае все интерфейсы в процессе ID 1 в нулевом регионе. Показано, соответственно, состояние наше на интерфейсе — DR мы или не DR, или DR other. Показана стоимость интерфейса. И показано количество соседей. Это neighbors F/C — сколько соседей в принципе есть и со сколькими из них мы установили полные соседские взаимоотношения. В отличие от IPv4, где в этой колонке показывался IP-адрес, здесь IP не показывается, потому что нам не нужны маршрутизируемые IP-адреса для установления соседства.

А link-local адреса тоже не сильно кому-то интересны, потому что они в любом случае действительны только в пределах канала. Пользователи их не видят, и поэтому информацию про IPv6-адреса здесь не показывают вовсе. После того как мы посмотрели на интерфейсы, которые у нас есть, показывается, что у нас есть соседи на каких-то интерфейсах. Этих соседей можно будет отобразить. Show ip ospf neighbor превратилось в show ipv6 ospf neighbor. Так же, как в случае с IPv4, показывается, что у нас есть некий сосед, показывается его ID. Показывается интерфейс, на котором мы его нашли. Показывается приоритет, который у него задан при выборах DR, BDR, если они выбираются. Показывается, в каком состоянии и почему мы находимся с этим соседом. Hold time. И ещё одна штука, которая здесь будет важна.

В IPv4 в этой колонке показывался IP-адрес. Опять же, IP-адрес в IPv6 не сильно интересен — не столько потому, что IPv6-адреса ни у кого не используются, а потому что это будут link-local адреса. И поэтому interface ID заменил IP-адрес. У нас есть роутер и, соответственно, есть роутер соседа. У нас показывается, каким интерфейсом мы на него смотрим. У нас interface ID — это номер нашего интерфейса. Мы на роутере R1 смотрим на него интерфейсом с номером 2. И показывается, каким интерфейсом он на нас смотрит. Здесь будет показано, например, 4, что он на нас смотрит интерфейсом номер 4. И это будет означать, что когда роутеры R1 и R2 друг друга видят и посылают друг другу информацию в LSA-ке первого типа о том, что они дружат между собой, они будут указывать, с какими номерами интерфейсов они дружат между собой. Раньше указывались IP-адреса, теперь указываются номера интерфейсов.

Что мы своим вторым интерфейсом видим четвёртый интерфейс роутера R2. После того как роутеры обменялись hello-пакетами, установили соседство, обменялись LSA-ками в LSDB — процесс обмена LSA-ками точно тот же самый. Дальше у нас показывается, что OSPF отработал, что show ipv6 route ospf, если вы хотите отфильтровать только OSPF-маршруты, показывает, что есть маршруты, которые притащились по OSPF. Буква O намекает на то, что это маршруты OSPF, всё то же самое, как в IPv4. Дополнительные буквы, которые могут быть там, — это OI, OE1 или OE2, или ON1, ON2. Это будет указывать на специфический тип OSPF-маршрута. Так же, как и в случае с IPv4, показывается сам маршрут, показывается административное расстояние, которое у OSPFv3 такое же — 110, показывается суммарная стоимость этого маршрута.

Если мы говорим про чистые, нативные маршруты, просто с буквой O, это так называемые intra-area маршруты, то вся стоимость посчитана роутером самостоятельно. Если это маршрут OI — маршрут, полученный через LSA типа 3 из другого региона, или inter-area маршрут, — то, соответственно, часть этой стоимости роутер посчитал несамостоятельно. Он получил LSA типа 3 от ABR, посмотрел, сколько стоимости в ней написано, посчитал кратчайший маршрут до ABR, добавил к тому, что написано в LSA типа 3, стоимость, сколько будет стоить добраться до ABR, и получил суммарную стоимость маршрута. С внешними маршрутами на курсе route разберёмся, там всё немножко сложнее. Так же, как и в случае с EIGRP для IPv6, next hop для каждого маршрута будет служить link-local адрес соседа, нам не нужны маршрутизируемые адреса для того, чтобы маршруты ставить на соседа в IPv6.

Если у нас есть два роутера, нам не нужно здесь иметь какой-то маршрутизируемый IP-адрес, мы можем на link-local адрес соседа пакеты по определённому маршруту отправлять, даже не имея маршрутизируемых адресов на транзитных интерфейсах. Это здорово экономит IP-адреса. Давайте попробуем это сделать. Попробуем на наших роутерах сейчас включить OSPF третьей версии, посмотреть, к чему это приведёт. Мы сейчас попробуем выключить сначала EIGRP, потому что я сильно подозреваю, что здесь у нас IPv6 остался с предыдущей лабораторной работы. И, соответственно, show ipv6 protocols. Да, точно, EGRP остался с предыдущей лабы. Соответственно, нам его сейчас надо будет выпилить, сказать, что EGRP нам не нужен, вместо него нужен OSPF. Привычное уже действие. No IPv6 router EGRP 65.001.

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

и дальше какой-то номер экземпляра. Приглашение к вводу изменяется, становится config.rtr. И если мы сейчас запустим show ipv6 protocols, do show ipv6 protocols, мы увидим, что OSPF у нас уже поджёгся. Здесь не густо, конечно, но конфигурация кое-какая показывается. Он автоматически хапнул себе router ID. Этот router ID у него взят по той же самой схеме, которая использовалась для IPv4 OSPF. Сначала берётся IPv4-адрес, самый большой на loopback. Если ни одного IPv4-адреса на loopback не оказалось, или самих loopback нет, то берётся просто самый большой IPv4-адрес. И важно то, что это router ID, не IP-адрес. Он берётся в качестве router ID, IP-адрес, если не сказано иное, просто потому, что он каким-то образом должен выбраться уникальным. И если вы хотите, вы можете его переназначить, назначить его каким угодно, как захотите.

Router ID 0.0.0. номер комплекта меняется той же самой командой, что в IPv4. Дальше. Router ID назначили. Если мы захотим, мы здесь же в этом контексте можем всякие разные штуки делать, passive interface назначить или что-то ещё. Но сейчас пока не будем это делать. Идём на интерфейсы, на которых мы хотим включить OSPF-взаимодействие, и включаем там IPv6 OSPF 1 Area 0. Интерфейс Ethernet 0.1. Тот интерфейс, которым наш роутер смотрит на центральный, IPv6 OSPF 1 Area 0. В IPv4 OSPF мы точно то же самое могли делать. Разница только в том, что здесь у нас используется команда IPv6, а там IPv4.

На центральном роутере надо сделать ответные действия, no router EGRP 65.0.1. Да, no IPv6. Они оба могут работать одновременно, но нам незачем держать неиспользуемый сервис на нашем роутере. Хорошая идея — вычищать все следы, если вы знаете, что они вам больше уже не понадобятся. Запускаем IPv6 router OSPF 1. Указываем router ID. Давайте для красоты я назначу 0.0.0.100. Router ID. И на интерфейсы: interface range

Ethernet 0/0-3, Ethernet 1/0-3, указываю IPv6 OSPF 1 Area 0. На всех интерфейсах, которые смотрят на маленькие роутеры, я повключал OSPF. Раньше можно было командой network повключать это всё, теперь только interface range. И мы видим, что действительно у нас обнаружилось два соседа на центральном роутере. На маленьких роутерах тоже есть сосед, вот он обнаружился. Показывается, что ID 0.0.0.100 был обнаружен на интерфейсе Ethernet 0/1. Причём он не просто был обнаружен, а он перешёл из фазы loading в фазу full. У нас полноценное взаимодействие с ним идёт, и мы можем посмотреть на всю диагностику, которую мы с вами уже проходили. Show IPv6 protocols. Показывается, что у нас есть интерфейс, который смотрит в нулевой регион. Show IPv6 OSPF показывает много всякой диагностики про OSPF.

Раньше всё это было совокупно. Была команда show IP protocols в IPv4, и оно всё более-менее одновременно показывалось. Сейчас в show IPv6 protocols очень мало информации. Все детали настройки OSPF вылезли в show IPv6 OSPF. Видно, что router ID у нас вот такой. Видно всякие плюшки, которые есть у нашей циски, потому что она поддерживает и NSSA, который является дополнительным механизмом. Он не входит в стандартную поставку OSPF, он дополнительный. Показываются всякие таймеры, которые есть в OSPF. Таймеров в OSPF много. Показывается количество регионов на нашем роутере. Показывается референсная полоса. Если мы захотим, мы можем в настройке IPv6 router OSPF 1 поставить auto-cost reference-bandwidth какую-то конкретную. И показывается, какой регион у нас есть.

В нашем случае нулевой регион. В этом регионе один интерфейс. В этом регионе три раза запускался пересчёт топологии. И общее количество LSA — семь штук. Я догадываюсь, что это два маленьких наших роутера и один центральный выпустили по одной LSA первого типа. Всего три LSA. Дальше между ними Ethernet-линки, в которых выпущены LSA второго типа. По умолчанию, так же как в IPv4, они выпускаются. Итого пять. И для того чтобы работать с link-local-адресами, каждый link-local-адрес у нас хранится в отдельной LSA. И здесь показано, что ещё две LSA. Тут как раз адресация. При этом не четыре и не три адреса link-local используются, потому что они link-local, и, как следствие, они не передаются за пределы провода. Все, кто к этому проводу подключены, эти LSA будут видеть. Все, кто к этому проводу не подключены, их не видят. Show IPv6 OSPF interfaces

interface brief. Показывает тот интерфейс, который у нас есть. Интерфейс Ethernet 0/1 в первом процессе, в нулевом регионе, имеет номер 4. Этот номер будет фигурировать в самих LSA. Стоимость интерфейса — 10. Состояние наше на интерфейсе — DR. Обнаружен один сосед, с которым установлены полные соседские взаимоотношения. Show IPv6 OSPF neighbor покажет, что это за сосед. ID соседа — 0.0.0.100. Приоритет для выбора DR и BDR у соседа никто не трогал, он по умолчанию единичка. Строим ли мы с ним полные соседские взаимоотношения? Да, строим. Потому что мы DR, мы со всеми строим соседские взаимоотношения. Кто он? Он BDR. В том числе и поэтому мы строим соседские взаимоотношения, что с BDR все дружат. Через 31 секунду, если он не пришлёт нам что-нибудь ценное, мы его выкинем из списка соседей. Но я думаю, что пришлёт. Можно взять

и выполнить эту команду ещё раз. И видно, что таймеры, которые используются в OSPF по умолчанию, они дефолтные — 10 секунд на 40. Раз в 10 секунд приходит новый Hello-пакет, в котором говорится: если я не пришлю тебе через следующие 40 секунд ничего, считай меня выбывшим. И вот мы считаем: 39, 38, 37, 36, 35, 34, 33, 32, 31, 30. Приходит новый Hello-пакет, и заново начинаем считать с 39. Номер интерфейса, которым сосед на нас смотрит, — 10. И да, мы его нашли на интерфейсе Ethernet 0/1, который у нас имеет номер 4. Мы своим четвёртым интерфейсом смотрим на его десятый. Можно посмотреть, что OSPF там напритаскивал. Show IPv6 OSPF Database — тоже есть такая команда. Она показывает,

какие LSA у нас есть. Три LSA первого типа, как я вам и обещал. Одна LSA первого роутера, одна LSA восьмого роутера. Каждая из них имеет указание, что есть один линк, который смотрит куда-то. В нашем случае — на центральный. И есть одна LSA центрального роутера 0.0.0.100, которая смотрит на два интерфейса. И они смотрят на самом деле друг на друга не напрямую, а через LSA второго типа. Эти две LSA — это LSA второго типа, которые выпущены нашими маленькими роутерами. Оба они выбраны DR-ами. Здесь показывается, что эта LSA выпущена DR-ом в линке между первым и центральным. А эта LSA выпущена DR-ом между восьмым и центральным роутерами. К каждой LSA второго типа подключено два роутера. Вполне очевидно, что DR сказал, что он видит самого себя и видит соседа — центральный роутер.

И наконец, это новая по сравнению с IPv4 и OSPFv2 концепция: вся адресная информация из OSPFv3 LSA первого типа выпилена. И информация про то, какой адрес будет у соседа, всё равно при этом нужна. Потому что как минимум мы должны будем в таблице маршрутизации его адрес использовать в качестве next hop. Поскольку в таблицах маршрутизации next hop-ами используются link-local-адреса, эти link-local-адреса выносятся в LSA восьмого типа. В OSPF второй версии восьмой тип не использовался, в OSPF третьей версии восьмой тип используется под хранение link-local-адресов. И никаких боевых адресов у нас здесь нету, Поэтому, если посмотреть на вывод show ipv6 route, у нас здесь будет отсутствовать какие-либо следы OSPF, поэтому мы сейчас захотим

их добавить. Так же, как и в случае с EIGRP, мы сейчас сделаем следующую вещь. Мы возьмём loopback-интерфейс, на котором у нас уже есть fd08, два двоеточия по 64-й маске сетка, fd плюс номер комплекта, и включим этот интерфейс в OSPF, заставим его тем самым проанонсироваться всем своим соседям. Так, conf t, интерфейс loopback 0, и на этом интерфейсе говорим ipv6, OSPF 1, area 0. Включаем его в нулевой регион для того, чтобы посмотреть сначала, как в IPv6 OSPF выглядят LSA-ки с адресной информацией. Раньше, если бы мы включили какой-то интерфейс в тот же регион, через который у нас идёт обмен маршрутной информацией, то эти адреса просто вошли бы в LSA-ку первого типа или второго типа,

в зависимости от ситуации, и специальные отдельные LSA-ки для маршрута, который у нас есть в том же регионе, где у нас есть соседи, не получились бы. Но в IPv6 OSPF немножко другая концепция используется. IPv6 OSPF database покажет, что у нас появились новые LSA-ки. Вот такие intra-area-prefix-link-states. Каждый роутер 0001 и 0008 рассказал, что у него есть некие сетки, которые к нему подключены. Он в отдельных LSA-ках девятого типа рассказал про то, что у него вот такая штуковина присутствует. И соответственно, в таблице маршрутизации у нас сейчас появятся маршруты. show ipv6 route, вот он маршрут, который прибежал через такую LSA-ку-девятку. Показывается сетка, которая прибежала. Так же, как и в случае с OSPF второй версии,

Cisco понимает, что интерфейс loopback нарисованный, поэтому, несмотря на то, что адрес там висит по 64-й маске, она присылает его со 128-й маской. Мы можем это поведение изменить, сказав, что Cisco не надо пытаться придумывать то, чего на самом деле нету, и надо анонсировать те маски, которые по факту есть на интерфейсе. Но это мы делаем на курсе по роутингу. Административное расстояние у OSPF 110, метрика маршрута 20, link-local адрес соседа, который прислал нам такой маршрут, FE80, два двоеточия, чего-то там. Запоминать нам его не надо, но соответственно, с этим адресом пакеты в сторону вот такой сети могут быть обработаны. Это адрес центрального роутера, и мы на него будем отправлять все наши пакеты до FD01, два двоеточия. Можно взять и попингать. Пинг, FD, что у нас там, FD01, два двоеточия, и вот оно пингается. При этом автоматически в качестве адреса источника выбирается вот этот товарищ,

FD08, два двоеточия. Никакого другого маршрутизируемого адреса на этой железке нету, поэтому ей было достаточно несложно взять и выбрать тот, который подходит. Если вдруг мы захотим, мы можем сделать так, чтобы этот маршрут был бы не intra-area, не в одном регионе с нами, чтобы вместо девятого типа LSA эти маршруты прибегали бы в LSA-ках-тройках, и наши роутеры при этом станут ABR-ами. Нет ничего проще. Интерфейс loopback 0. У нас сейчас этот интерфейс находится в нулевом регионе, поэтому в пределах своего нулевого региона все маршруты нам известны. Но мы сейчас можем сказать ipv6, OSPF 1, area, и дальше уже не ноль, как сейчас у нас настроено, а какой-нибудь другой регион, например, восьмой. В принципе, неважно, какой он будет, главное, чтобы не нулевой. И сейчас,

если мы сделали вот такую штуку, поведение нашего роутера изменилось. Он теперь имеет два разных интерфейса, смотрящих в два разных региона. Loopback у него смотрит в один регион, а связь идёт через другой. Поэтому в тот регион, в котором у нас роутеры дружат между собой, в нулевой регион, маршрут с loopback-а вбрасывается в виде LSA-ки-тройки, не в виде LSA-ки-девятки. И соответственно, show ipv6 OSPF database нам покажет, что вот оно, inter-area prefix link state в восьмом регионе. Лучше вот сюда смотреть. Inter-area, это LSA-ки-тройки. Каждый роутер рассказал, что он знает некую сетку, которая у него за спиной находится. Это бывшие LSA-ки, которые назывались summary net link states. Бывшие LSA-ки-summary. Они по-прежнему LSA-ки типа 3, но называются немножко по-другому. И каждый роутер рассказал, что к нему подключена вот такая сеть. FD01, два двоеточия,

по 128-й маске. Поскольку это ABR, он знает некоторые LSA-ки в нулевом регионе и знает некоторые LSA-ки в восьмом регионе. В восьмом регионе у нас есть один роутер. Он знает одну сетку в пределах своего региона. В пределах своего региона это intra-area. Вот эта сетка. А вот эта сетка это из чужого региона, inter-area прибежала, соответственно, сетка FD01, два двоеточия по 128-й маске. В таблице маршрутизации у нас сейчас будет всё то же самое по большому счёту, но маршрут стал I. Вот это I означает inter-area маршрут. Маршрут из другого региона. Зародился он, например, в первом регионе, дальше через нулевой регион прибежал к нам в виде LSA-ки-тройки, и мы его у себя добавили как inter-area маршрут. Пинги при этом все равно будут пингаться, то есть на скорость это не влияет.

Вот. Такой вот у SPF третьей версии протокольчик, который позволяет синхронизировать таблицы IP вешистых адресов. В принципе, по большому счету все настройки, которые в нем есть, очень похожи на IPv4. Если вы разобрались с тем, как настраивается IPv4 и SPF, то настроить IPv6 и SPF у вас тоже с трудностей составить не должно. Больше мы про него говорим на курсе по роутингу. Опять же, подчеркну, что в принципе отличия у IPv4 и IPv6 и SPF, они есть. Они в принципе довольно заметны внутри, под капотом. Но эти различия мы разбираем детально уже на профессиональном треке. А в рамках такого обзорного трека ICND 1.2 вот этого объема информации знать вполне достаточно для того, чтобы успешно сдать экзамен и для того, чтобы при необходимости разобраться с имеющейся проблемой в SPF и 3 в своей реальной сети. Так что, наверное, на этом все. Переходим к следующей теме. Субтитры создавал DimaTorzok