Настройка OSPFv3 Named Mode в Cisco IOS

Последнее, что хочется рассказать про OSPF, это про механизм конфигурирования OSPF v3, который будет называться IF Mode, Address Family Mode. Да если вспомнить, как мы настраивали с вами EGRP, то у нас там был, соответственно, EGRP для IPv4, EGRP для IPv6, и потом мы посмотрели, что есть EGRP, который как бы соединяет в себе и то и другое. Вот для OSPF есть аналогичная концепция. Мы можем запустить OSPF v3 и дальше сказать, что внутри него будут реплицироваться и IPv4, и IPv6. И эта штука будет называться OSPF v3 IF Mode. Давайте разбираться, что здесь у нас есть. Первое. Если говорить про тот синтаксис классического режима, который мы с вами только что изучали для OSPF v3, где мы делаем IPv6, OSRouter, OSPF, дальше номер экземпляра, то большая часть команд, которые там есть, они на самом деле наследуются для совместимости, чтобы один раз администратор выучил, как настраивать OSPF v2,

и после этого он на v3 перешел бы без каких-либо особых проблем. То есть конфигурация OSPF v3 классического режима сознательно, с иской, сделана похожей на OSPF v2, которая в свою очередь сознательно сделана похожей на протоколы, на конфигурацию протоколов древних типа IGRP. А, соответственно, как получается, да, что у нас OSPF v3 красивый протокол, который умеет реплицировать много всякого разного интересного, он в итоге по конфигурации сознательно сделан похожим на древние-древние протоколы RIP, IGRP и прочее. Настраивается это все в разных частях. То есть есть у нас отдельный контекст настройки роутера, отдельный интерфейс настройка, отдельный там что-то еще. И получается, да, что в некоторых случаях настройки IPv4 и IPv6 имеют разную синтаксис. Ну, типичный пример это, например, агрегация. Там, где у нас для LSA-к пятерок агрегация идет summary address vipv4, summary prefix vipv6.

Или там что еще у нас есть? Отличающиеся в IPv4 и IPv6 OSPF. Summary prefix, да. LSA-ки называются по-разному, да. То есть там, где у нас называлось, допустим, summary LSA. Теперь она называется inter-area prefix. Вот. IFmode это альтернативный синтаксис конфигурации OSPF v3, который позволит нам одинаково работать с репликацией таблицы IPv4 и IPv6. И, соответственно, позволит нам синхронизировать и IPv4, таблицу с маршрутизацией, и IPv6. И на самом деле это будет тот же самый протокол. Так же, как и в случае с EGRP named mode, у нас разница только в том, как мы это все дело настраиваем. И в итоге у нас почти все настройки будут работать в едином месте конфига. Ну, конечно, некоторые все-таки штуки придется настраивать на интерфейсах, но тем не менее все равно общая логика будет видна в контексте роутера.

Вот. Достигается это за счет того, что у нас адресное семейство IPv4 будет работать в инстансе 0, а адресное семейство IPv6 будет в инстансе 0, а адресное семейство IPv4 будет бегать в инстансе 64. В любом случае, сами пакеты будут бегать поверх IPv6, но реплицировать они будут таблицу маршрутизации IPv6 и IPv4 в зависимости от инстанса. Дальше. Если вы хотите, вы можете импортировать конфиг классического режима или вы можете настроить конфигурацию с нуля. Для того, чтобы импортировать конфиг классического режима, достаточно просто обратиться к новому синтаксису. То есть если вы попытаетесь настроить роутер в классическом режиме, а потом попытаетесь обратиться к этой конфигурации в новом синтаксисе, как будто вы уже настроили аевмод то вас вся конфигурация автоматом переедет в аевмод это немножко отличается от того как у нас было в ежерпи где был специальный макрос чтобы из обычного

режима сделать на и бот ноут здесь достаточно просто сказать что вы хотите чтобы у вас появился новый режим и она сама все обновится конфигурация будет иметь следующий вид в отличие от айпи в 6 роутер успев чего-то там здесь у нас будет конфигурация роутер успев вид 3 чего-то там то есть действительно роутер успев и 3 может работать как с таблицей а пир 4 так сапево 6 поэтому здесь у нас приглашение к воду будет просто конфиг роутер и слова ipv6 нету потому что мало ли вдруг вы захотите с помощью успев и 3 реплицировать только ipv4 дальше запускаем адресное семейство также как в ней модно говорили адрес family ipv4 адресаем или ipv6 и в настройках адресного семейства приглашение к Coloraff мы даем какие то настройки которые специфичны для этого адресного семейства для этого инстанса роутер id пассив интерфейсе что там еще у нас полагается делать ну в общем дал то есть то все то что делается в контексте роутер все теперь делается в консексте адресного

семейства и дальше некоторые вещи все-таки придется делать в интерфейсов у нас нет контекста это IF-интерфейс, у нас есть просто интерфейсы. И там на этих интерфейсах мы указываем OSPF V3, номер экземпляра, вот он экземпляр, IPV4 или IPV6, и дальше area, в каком регионе этот интерфейс будет присутствовать в нужном инстанции. Работать это все будет поверх IPV6, но NextHop в LSA-ках, восьмерках будут протаскиваться нужного протокола. В IPV4 будут протаскиваться NextHop, которые у вас на интерфейсах висят, там 10, 0, 0, 1. В IPV6 будет протаскиваться FE80, два двоеточия, там допустим 1. Это все будут считаться link-local адреса, и именно они будут протаскиваться в LSA-ках-восьмерках, в зависимости от того протокола, который вы выберете. Если вы реприцируете базу IPV4, то маршруты передаются в IPV6, LSA-ки, точнее, передаются в IPV6, дальше считаются кратчайшие маршруты,

дальше считается, кто будет адресом link-local для маршрута через соседа, и выбираете просто LSA-ку-восьмерку, соответствующую нужному вам протоколу. Соседство устанавливается независимо в каждом инстанции. В нашем случае мы видим, что у нас есть инстанция IPV4, устанавливано соседство, инстанция IPV6 устанавливано соседство. В каждом инстанции передаются отдельные hello-пакеты. вы можете в разных инстанциях держать интерфейсы в разных регионах, то есть это фактически, да, абсолютно разные, не связанные между собой, ну, как назовем это, сущности. Они работают в рамках одного процесса, но они при этом не связаны между собой. Если у вас есть топология IPV4 и IPV6, они не обязаны совпадать. То есть может быть такое, что у вас есть четыре роутера, на одном из них есть только IPV4, на другом из них есть только IPV6, а на другом, соответственно, 4 на 6 и 4 на 6, на двух других. Есть и то, и другое. Вы в этом случае можете сказать, вот здесь у нас работает IPV4,

здесь у нас работает IPV6, никаких проблем нет. То есть вы можете сказать, да, что у вас на некоторых интерфейсах работает только какой-то один протокол. Можете сказать, что вот на этом проводе работает и то, и другое. Как-то вот так это будет выглядеть. Здесь у нас IPV6, тут у нас IPV4, вот в этой области DualStack. Show IP Protocols покажет, что у вас есть протокол, который притащил в таблицу маршрутизации какие-то маршруты. Для IPV6 там просто покажется то же самое, что в... Ну, вот оно, для IPV6. Покажется, что у нас есть USPF, и вот он чего-то там такое нам соорудил. Для IPV4, show IP Protocols, IPV4, показывает, что у нас есть USPF, но это USPF не обычный, а это USPF V3. То есть если вы закажете привычные вам команды showIP, USPF neighbors, showIP, USPF interfaces, они вам ничего не покажут.

С точки зрения CISC, USPF просто для IPV4 и USPF V3 чего-то там, это совсем разные протоколы. Поэтому старые команды работать с этим не будут. У вас есть интерфейсы, на которых оно завелось, у вас есть шлюзы. То есть все то же самое по большому счету. То есть это тот же самый USPF, который привычным нам образом работает. Но вот что-то здесь он нам показывает. Диагностика протокола страшная, ужасная. Вот showOSPF V3 на одном роутере. Это IPV4 и IPV6. Вот показывает нам отдельно. Вот эту колбасу про IPV4 и вот эту колбасу про IPV6. Здесь на самом деле ничего интересного для нас нет. Мы все это уже знаем. Да, RFC 1583 compatibility enabled намекает на то, что у нас, может быть, да, метрика будет считаться не совсем честно. Но я думаю, что на самом деле должна считаться честно. Так.

Старые команды не работают. ShowIPOSPF interface работать не будет. Вместо этого надо использовать новую команду showOSPF V3, IPV4 или IPV6 interface brief. Для проверки соседств то же самое. ShowOSPF neighbor не работает. ShowOSPF V3 IPV4 neighbor работать будет. Ну, для IPV6, соответственно, здесь IPV6 neighbor. Несмотря на то, что мы заказываем вроде бы IPV4 соседство, здесь показывается ID, здесь показывается интерфейс ID. То есть топология считается по OSPF V3. Это не OSPF V2. Если мы хотим посмотреть таблицу маршрутизации, то вот showIPROAD OSPF V3 нам покажет, что у нас какой-то маршрут есть, который притащил IPV4 экземпляр OSPF V3. Ну и showIPV6 road OSPF тоже показывает, что у OSPF какие-то маршруты есть.

Старая команда showIPROAD OSPF не работает, потому что с точки зрения CISC, OSPF V3 и OSPF просто, это абсолютно разные протоколы. Они имеют разные типы, они имеют разные как бы способы происхождения, поэтому showIPROAD OSPF V3 покажет результат, showIPROAD OSPF не покажет. Дальше. Настройка интерфейсов выглядит, в общем, привычным образом. Мы заходим на интерфейс и говорим там все, что мы хотим сделать. То есть если мы хотим задать стоимость, можно задать стоимость общую для всех инстансов, либо сказать, что вот у нас есть OSPF номер 1, и мы для инстанса IPV4 даем вот какую-то конкретную стоимость. Если хотите reference bandwidth задать, оно делается в настройке адресного семейства для конкретного адресного семейства, либо в общей настройке роутера для всех адресных семейств одновременно. Ну, пассивный интерфейс, опять же, можно в настройке всего роутера, можно в настройке адресного семейства, если хотите настроить по-разному.

Это удобно, что можно в настройке всего роутера сказать пассив интерфейс, потому что, опять же, у вас очень редко будет такая ситуация, что где-то в сети есть одни соседи, где-то в сети есть другие соседи, интерфейсы не совпадают, что IPV4 соседи живут в одной области, IPV6 в другой. Если вы в предприятии разворачиваете IPV6, вы его, ну, скорее всего, разворачиваете везде однотипно, и у вас соседи будут обнаруживаться плюс-минус километр везде одинаково. Настройки, всякие таймеры, тип среды и прочее, все абсолютно будет однотипно. OSPF v3, дальше Priority. Если хотите, можете конкретный инстанс указать. Hello Interval, опять же, можно указать дефолтный для всего интерфейса, можно указать для инстанса. Dead Interval тоже самое. Можно тип среды, можно Neighbor прописать. Вот Neighbor, да, прописывается OSPF v3, Neighbor чего-то там. Ну, или, опять же, для конкретного инстанса Neighbor чего-то там. Так.

Диагностика интерфейса. Show OSPF v3. Номер экземпляра. Адресное семейство. Интерфейс. Соседи. Show OSPF v3. Номер экземпляра. Адресное семейство. Neighbor. Ну, таблицу LSDB. Show OSPF v3. Номер экземпляра. Адресное семейство. Датабейс. Дальше уже привычное нам название LSAT. Если нужно Advertising Router. Если нужно, здесь вот LSID. Пример. Мы, ну, для IPv6, наверное, не будем делать. Это интереснее как раз для IPv4. У нас есть топология. Два роутера. Один из них ABR. Именно R1. Смотрим, чего у нас в таблице будет видно. Мы видим, что у нас есть роутер R1, роутер R2. Каждый из них выпускает LSAT первого типа. Раз LSAT. Два LSAT. Каждый из них говорит, что у нас есть один линк. Вот он линк. Здесь для простоты LSAT второго типа нет. Они смотрят друг на друга напрямую по point-to-point связи. Дальше есть InterArea Link.

Это LSAT 3. Вот она. Она вот отсюда берется и перекладывается. Линк 8. Type 8, точнее, LSAT. Линк local адреса. Каждый из интерфейсов здесь у нас имеет link local адрес. Здесь link local и здесь link local. Они будут подвязаны к определенному интерфейсу. То есть вот здесь вот на этом интерфейсе у нас есть этот link local и этот link local. И link ID на каждом роутере будет какой-то конкретный. Интра-эреа префиксы. Это значит каждый роутер, первый и второй, анонсирует, что у него есть какие-то сетки внутри своего региона. Первый роутер анонсирует вот эту сетку. Второй роутер, ну не знаю, как он здесь. Еще одна сетка есть, которая нам не показывает. Если мы хотим посмотреть отдельную LSAT, ну какую-нибудь, не знаю, восьмерку, например, то синтаксис будет выглядеть вот как. Show OSPFV3. Дальше номер экземпляра. Адресное семейство. Ключевое слово database. Какую LSAT хотим показать. Если это link LSA, на каком интерфейсе она будет жить и кто ее придумал.

И в случае, если мы бы заказывали IPv6 LSA, там было бы все предсказуемо, там был бы link local адрес. А вот для IPv4 здесь как раз интересно. Адресное семейство IPv4 предполагает, что вы в таблицу маршрутизации будете next hop добавлять, естественно, IPv4 IPшник, а не IPv6 link local, по которым вы дружите. Поэтому здесь у вас показывается link local 10.1.2.1. Это то, что на роутере R1 в таблицу маршрутизации будут добавляться маршруты, которые через R2 проходят. Вот там нужно будет, чтобы, соответственно, IPшник в таблицу маршрутизации добавлялся IPv4. И вот он, link local адрес 10.1.2.1 по 24 маске. Так, intra-area префиксы IPv4, то есть внутри своей сети тоже, естественно, будет IPv4. Вот 1.1.1.1 по 32 маске. Показывается сетка, показывается маска, метрика. То есть LSA с адресной информацией могут быть адаптированы как для IPv4, так и для IPv6.

Они гибкие и резиновые. В них можно положить что угодно. Inter-area префиксы – та же самая история. 2.2.2.2.3.2. То есть маршруты, полученные из других источников. Дебаги. Включаются отдельно. Старые дебаги не работают. Соответственно, дебаг OSPFv3 hello покажет вам, что у нас есть вот экземпляр OSPFv3 номер 1 с инстансом для IPv4 получает hello. То же самое для IPv6 получает hello. Если какие-то сообщения есть, какие-то проблемы с hello пакетами, то показывается, что вот проблемы действительно есть. Если хотите посмотреть содержимое пакетов, которые приходят к вам, то вот дебагай OSPFv3 packet показывает, что вот в IPv6 у нас получен пакет. Это у нас link state request. Нет, простите. Это у нас DBD типа 2. Длина у нее 228 байт. Получен от роутера 1.0.0.0.2.

Advertising. Нет. AID. Что это такое? Не знаю. AID подозрительно как-то. Чек-сумма вот такая. Инстанс нулевой, в котором мы это получили. То есть IPv6, да? IPv6. Можно включить дебаг пересчета топологии. Вот. Если у нас маршруты какие-то не приходят, или наоборот приходят, то дебагу OSPFv3 и OSPF каждый раз, когда у вас маршрут какой-то будет меняться, будет показывать на экран нечто. Табы и NSSA абсолютно так же настраиваются, как в классическом режиме. То есть все абсолютно то же самое. Опять же, если вы хотите вбросить какие-то маршруты через редистрибуцию, точно так же вы должны это будет делать. Если вы из одного протокола в OSPFv3 вкладываете какие-то маршруты, которые, в общем-то, скорее connected, чем маршруты, например, EGRP, то вы должны будете сказать include connected. Точно так же можно прогнать маршруты через roadmap.

Ну, то есть все то же самое работает. Virtual link будут характерны для адресного семейства, поэтому прописываются в настройках адресного семейства. Синтексис точно такой же. Если вдруг с дистрибьют-листами будете работать, он в адресном семействе IPv4, будьте внимательны, будет немножко специфически работать. Там нет roadmap. Там можно проверять gateway, там можно проверять маршруты по аксесс-листу, в отличие от классического режима в циске с IPv6, который работает только с префикс-листами и больше ни с чем. Ну вот, соответственно, да, с IPv4 можно проверять gateway, можно проверять аксесс-листы, но нельзя проверять roadmap. Криво-косо сделали. Вот. Ну и далее фильтрация. Да, возможно, так же, как в случае с IPv4, можно смотреть, что вы отдаете из таблицы маршрутизации, BGP-шного, например, или, там, не знаю, static, connect, AD, в OSPF, либо можно смотреть, что из OSPF прибегает таблица маршрутизации,

то есть направление фильтрации. in – это на вход в таблицу маршрутизации, out – это на выход из таблицы маршрутизации. Опять же, если мы говорим, что мы редистрибутим что-нибудь, то мы редистрибутим как бы в сторону нашего OSPF. Если мы говорим, что мы используем distribute list, это вот со стороны таблицы маршрутизации, что мы согласны отдать из таблицы маршрутизации. Настройка агрегации выполняется примерно так же, как она выполнялась в IPv6, в OSPF v3 классическом режиме, area range, но только в настройке адресного семейства. То же самое, соответственно, если мы говорим про IPv6, то адресное семейство IPv6 предполагает, что у нас есть summary prefix, и, соответственно, в IPv4 OSPF v3 тоже суммаризацию будет выполнять команды summary prefix. Уже нету никакого summary address. Административное расстояние. Откуда у меня постоянно берется 170 в OSPF?

Не знаю. Точно так же, как и в случае с классическим режимом, переопределить отдельным маршрутом административное расстояние нельзя. Можно только задать для всех маршрутов, которые у вас есть в OSPF, либо одинаковое значение команды distance, например, 120, либо distance OSPF, там отдельно указать, что такие маршруты такое административное расстояние, другие секое. Но в реальности OSPF достаточно иметь одно административное расстояние, он прекрасно работает совсем с одним. Точно так же, как и в случае с классическим режимом, можно включить authentication trailer, то есть настройка там та же самая. Можно будет на интерфейсе сказать, что OSPF v3 authentication keychain, дальше название ключевой цепочки, либо, если вы хотите, вы можете использовать аутентификацию по IPv6, OSPF чего-то там, что у нас было, превратилось в OSPF v3, чего-то там, что у нас было. Можно отдельно на уровне инстанса сказать,

можно сказать, что на всем интерфейсе у нас одинаково работает. Либо можно использовать authentication trailer на уровне региона. То есть вы во всем регионе говорите, у нас используется authentication trailer, указываете регион, указываете authentication, keychain и ключевая цепочка. Если вы знаете, что у вас все циски новые, например, у вас везде смартнеты есть, iOS и везде обновленные, то вот можно в этом случае сказать, давайте использовать authentication trailer. Эта штука удобная, особенно если вы используете SHA-256, ну то есть ключ, который вы задаете в ключевой цепочке, его менять можно регулярно. Его не надо придумывать каждый раз, вот эту вот дикую колбасу из 1500 символов придумывать. То есть это намного комфортнее, когда у вас ключевые цепочки есть. Но опять же, authentication trailer поддерживает только последние YELTS, поэтому старые YELTS его поддерживать не обязаны. Так, давайте посмотрим, что действительно, если мы попытаемся обратиться к конфигу старому,

который у нас есть в классическом режиме на роутере, и мы просто попытаемся использовать команду router ospfv3 чего-то там, то у нас автоматом конфиг обновится. Вот сейчас на роутере есть show run section router. IPv6 роутер. IPv6 роутер. Routure. Роутер. Вот. Одна-единственная строчка IPv6 роутер ospf1, в котором ничего в общем толком нет. Если мы хотим обновить конфигурацию, то мы можем сказать conft router ospfv3 1. Мы вроде ничего не сделали, но мы выходим из этого контекста и показываем section router. Так. Нет, фокус не удался,

факир был пьян. Conft router ospfv3 1. Простите. Вот. И, соответственно, у нас конфигурация старая, которая была, она переехала в контекст роутера ospfv3 1. Adress family IPv6 Unicast. Если бы у нас там в настройке был какой-нибудь, не знаю, роутер ID или что-то еще, он бы оказался как раз в этом контексте. Дальше. Если мы хотим что-нибудь делать плохого, что мы можем хотеть сделать плохого? Мы можем, например, настройки на интерфейсе посмотреть. Show run interface E0 0.12 Они у нас остались в старом стиле IPv6 OSPF1 и R0. Это ничего, оно работать все равно будет,

даже несмотря на то, что у нас здесь вот указано роутер ospfv3 1, а здесь IPv6 и ospf1 и R0, все равно это нормально работает. То есть, те старые настройки, которые были на интерфейсах, они автоматически не обновляются, но тем не менее, они все равно позволяют железке нормально работать. Если мы захотим сказать, что на этом интерфейсе ospfv3 должен будет работать и реплицировать и IPv4 маршруты тоже, то conft interface E0 0.12 и указываем здесь ospfv3 1 ipv4 area не знаю, пусть будет. И, соответственно, на роутере R1 тоже указываем enable conft interface E0 0.12 ospfv3 1 ipv4 area 0.

Так, и, по-моему, здесь его надо пнуть еще. router ospfv3 1 address family IPv4 здесь тоже. router ospfv3 1 address family IPv4 IPv4 IPv4 Так, вот теперь у нас должно установиться соседство по instance 64 по крайней мере, я на это очень надеюсь. Давайте посмотрим, что он там хочет нам сказать. ospfv3 а, вот установил show ospfv3 1 ipv4 neighbors показывает, что соседство есть. Это соседство по протоколу ospfv3. hello-пакеты бегают через ipv6. Они обнаруживают друг друга эти роутеры. дальше роутеры между собой обмениваются dbd-шками.

В этих dbd-шках они перечисляют таблицу топологии. После чего они в этой таблице топологии обмениваются лосейками. В этой лосейке есть лосейки первого типа, второго и так далее. И среди прочих есть лосейки адресные. То есть лосейки трешки, пятерки, восьмерки и девятки. И в этих лосейках, трешках, пятерках, восьмерках и девятках передается адресная информация IPv4. show ospfv3.1 ipv4 database У нас есть две лосейки первого типа. Первый и второй роутеры друг с другом связаны. Они связаны через лосейку второго типа. Это сугубо топологическая информация. Дальше. Есть две лосейки восьмого типа. То есть это link local адреса. Адреса те, которыми роутеры друг на друга смотрят. Про эти айпишники нет смысла рассказывать всем остальным. Поэтому штуки типа prefix suppression в ospfv3 в принципе не нужны.

И соответственно здесь у нас, если мы закажем отображение этой лосейки восьмого типа. show ospfv3.1 ipv4 database link id-шник. Какой бы мне id-шник запросить? Я вот хочу тринадцатую. Advertising роутер 10-15-1-1. Вот. Соответственно здесь показывается, что роутер 10-15-1-1 будет смотреть на роутер 2 айпишником 10-15-1-1. В отличие от IPv4 от ospfv2, соответственно этот айпишник будет считаться исключительно транзитным. И про него на самом деле не нужно будет рассказывать, что это айпишник, через который можно подключаться к нашим роутерам. То есть вот эти вот транзитные сетки, их можно очень легко скрывать. Так. Да.

Ну, соответственно, да. Вторая лысейка восьмого типа укажут на второй айпишник. И intra-area префикс. Это маршрут в пределах нашего региона. Он как раз 10-15-2-2. Придуманный. Network. 10-15-2-2. Так, нет, пардон. Почему Network? Пишу префикс. Префикс. Advertising роутер 10-15-2-2. Вот это вот маршрут, известный внутри региона. 10-15-2-12-0 по 24-й маске. Это как раз сетка, которую роутеры анонсируют, что они знают, потому что они по этой сети подружились. И, в принципе, для большинства задач этого будет достаточно, чтобы у нас все сетки были бы в таблице маршрутизации. Но если мы захотим включить prefix suppression, роутер ospfv3.1, адрес family ipv4,

prefix suppression. И с другой стороны то же самое делаем. Conf.t. Refix suppression. Сейчас у нас в LSA-ках должна эта сетка будет пропасть. О, мы застали штуку. Смотрите, у нее возраст 3607 секунд. Предыдущая версия этой LSA-ки... Давайте посмотрим, она чуть выше была. Вот. Предыдущая версия этой LSA-ки имела возраст 52, и sequence number у нее был единичка. Соответственно, сейчас у нас выпустилась новая версия LSA-ки с sequence number 2 и с возрастом 3600 плюс немножко. Это означает, что тот, кто придумал такую LSA-ку, хочет, чтобы LSA-ка с ID-шником 10.240 и с advertising router 10.15.2.2 ушла из таблицы топологии.

Он выпускает новую версию LSA-ки и говорит, что у нее будет конский возраст. Эта штука называется flushing. Как смыть воду в унитазе. Вот вы отправляете LSA-ку, которая заведомо портит всем в таблице топологии LSA-ку, которую вы раньше предыдущую выпустили. И, соответственно, вот она заведомо будет свежее, чем любая существующая, потому что у нее sequence number больше. И у нее возраст такой, что ее надо немедленно из таблицы топологии убрать и исключить. Ну, то есть даже если она у нас в таблице есть, она по факту в пересчете принимать участие не будет. 3600 – это слишком большой возраст. И после того, как мы это сделали, вот она убралась из таблицы топологии, и link local адреса у нас известны, а вот эта вот транзитная сетка 10.15.2.2, ну, мы просто перестали генерить такую LSA-ку. И поэтому ее нет в таблице. Все остальные роутеры тогда сетки, которые вот по префиксу suppression вы подавили, видеть не будут. Так, давайте в качестве, скажем, в качестве последнего задания сделаем лабораторную работу на шифрование.

Заставим наши роутеры передавать трафик в сторону роутера центрального. Или давайте, нет, не центрально, вот между первым и вторым как раз настроим связь с использованием аутентификации. ConfT, интерфейс Ethernet 0.0.12, vspfv3.1, ipv4, authentication. И вот здесь вот мы можем сказать, что у нас... Что у нас будет использоваться ключевая цепочка. Так, что-то я не понял. vspfv3.1, authentication. Вот, да, мы можем сказать, что все сообщения, которые у нас будут на этом интерфейсе отправляться, ipsec будет защищать SPI. Нужно придумать какой-то номер, номер фактически как номер ключа. И мы указываем, что у нас будет номер, ну, например, там 500, как на слайде.

Дальше указываем алгоритм цифровой подписи, который мы будем использовать. SHA-1. SHA-1. Дальше указываем, что у нас есть какой-то ключ. И ключ я предлагаю указать 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. Он должен быть 16-ти речный, и он должен быть 40 символов длиной. Вот такой вот ключ. Он хорошо видно, что как раз 40 символов длиной. С одной стороны я это включил. У нас на интерфейсе, да, IPsec начал работать. Hello-пакеты, которые я отправляю, перестали быть валидными для соседа. У соседа через 40 секунд отвалится связь. Можно будет сейчас посмотреть, что сосед тут действительно разваливается. Show uspfv3 neighbors. Вот. 10, 15, 2, 2.

Ему осталось буквально совсем ничего. Dead timer у него прямо тикает на глазах. Чпок. Соседство отвалилось. Отвалилось отдельно в IPv4 и в IPv6. И с другой стороны настраиваем ответные настройки. Интрофейс Ethernet 0.0.12. OSPFv3. Authentication. IPsec. SPI номер 500. Ключ будем SHI1 использовать. И дальше 0.1, 2, 3, 4, 5, 6, 7, 8, 9. 0.1, 2, 3, 4, 5, 6, 7, 8, 9. 0.1, 2, 3, 4, 5, 6, 7, 8, 9. 0.1, 2, 3, 4, 5, 6, 7, 8, 9. Hello сообщения, которые отправляю, начинают отправляться подписанными с использованием заголовка AH. И, соответственно, вот у нас соседство переустанавливается. Отдельно в инстансе для IPv4. Отдельно в инстансе для IPv6. Теперь наши сообщения подписаны.

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