Протокол OSPFv3

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

Поэтому когда IPv6 вышел, индустрия стала задумываться о том, чтобы OSPF адаптировать под новую версию протокола IP. И, соответственно, OSPF начал модифицироваться для работы с IPv6. И плюс к тому избавляться от некоторых проблем, которые были в IPv4. В частности, авторы протокола OSPF v3 серьезно ставили себе задачу отказаться от того, чтобы топологическая и адресная информация передавались бы в одних и тех же LSA. То есть сейчас для того, чтобы в OSPF v2, чтобы получить маршруты, которые у нас используются внутри региона, мы передаем только LSA первого и второго типов. В OSPF v3 у нас LSA первого и второго типов нужны только для того, чтобы собрать пазл. Там нет адресов, а адреса переехали в другие LSA, которые несут в себе именно адресную информацию. Получается более логичная и более, скажем так, более адаптивная штука.

То есть OSPF v3 — это протокол, который может адаптироваться под любую адресную информацию, именно потому что в LSA топологических у нас адресной информации нет. ОСПF v3 — это стандартный протокол. Опять же, есть RFC, которые его описывают. Это RFC 2740, 5340 и некоторое количество дополнений. Опять же, как и в случае с OSPF v2, у нас есть базовый скелет, и дальше к нему костыли, костыли, костыли, костыли. Использует OSPF v3 точно тот же самый алгоритм для работы с топологической информацией. То есть у него тоже есть LSA, тоже есть LSA первого типа. И в этих LSA первого типа роутеры говорят, кто на кого как смотрит. LSA второго типа точно так же используются для упрощения сборки паззла в мультиаксесс-средах. LSA первого типа будут указывать, соответственно, на кого мы смотрим либо напрямую, либо через LSA второго типа. Карта собирается с топологией точно так же. По карте, этой самой топологической, кратчайшей маршруты посчитываются точно так же.

Используется точно тот же самый алгоритм DXTRA. Но есть и отличия. Отличия в первую очередь то, что OSPF v3 изначально создавался для протокола IPv6. То есть он использует IPv6 для обмена сообщениями. Он использует IPv6 flow пакеты, IPv6 апдейты, IPv6 дбдшки. То есть все передается по IPv6. Изначально создавался он для того, чтобы IPv6 маршруты притаскивать. Но потом его немножко подпилили и сделали так, чтобы он мог перетаскивать вообще любые маршруты любой природы. Например, он может перетаскивать маршруты IPv4. Это иногда вызывает легкое непонимание у людей, которые смотрят на OSPF v3. Говорят, как же так? Он использует IPv6 пакеты, но реплицирует IPv4 маршруты. Но тем не менее, да, он такое делать может. Дальше. Изначально в OSPF v3 не используется механизм аутентификации, когда у вас каждый пакет подписывается отдельной цифровой подписью.

Дело в том, что учитывая то, что OSPF v3 работает по IPv6, и учитывая, что на момент, когда OSPF v3 создавался, требование поддержки IPsec было обязательным для любого IPv6 устройства. Сейчас это не так. То в этом случае авторы OSPF v3 сказали, давайте использовать штатные фичи протокола IPv6 для удостоверения корректности отправляемых пакетов. То есть мы будем использовать IPsec, более точно протокол AH, Authentication Header. То есть у нас не используются никакие поля внутри самого OSPF для того, чтобы подписывать, скажем, цифровой подписью пакеты. Мы будем использовать штатный заголовок H, который будет подписывать IP пакет в целом. Сами пакеты по логике остались те же самые. Hello, DBD, LinkState Request, LinkState Update, LinkState Acknowledge. Обмениваются роутерами по той же самой схеме. Точно так же обнаруживаются соседи. Точно так же будут после перехода соседей в 2-way, дальше они переходить в Xstart, Exchange, Loading и Full.

Ну и, соответственно, да, логика обмена пакетами абсолютно та же самая. В OSPF v3 есть небольшие изменения в заголовке. То есть, в принципе, протокол остался тот же. И, в принципе, если посмотреть на заголовок OSPF v2 и OSPF v3, они будут очень похожи. То есть сначала идет поле версии. В OSPF v2 там была двойка, в OSPF v3 там внезапно тройка. Дальше идет поле тип. Что мы передаем? Какого типа пакет? Точно так же. Hello, DBD, LinkState Request, LinkState Update, LinkState Acknowledge. Точно так же мы передаем 4-байтовый роутер ID. Здесь нюанс. В IPv4 роутере мы могли сказать, этот роутер обменивается IP-пакетами. Он нужен для того, чтобы перетаскивать пользовательские пакеты. Поэтому на нем хотя бы один IP-шник наверняка есть IPv4. В IPv4 OSPF и IPv4 IP-шники наверняка есть. И мы можем для того, чтобы роутер ID получить, взять какой-нибудь IP-шник с какого-нибудь интерфейса, который у нас на роутере прописан.

В IPv6 вы обмениваетесь IPv6 пакетами. Если вы запускаете OSPF v3, не факт, что у вас есть IPv4 интерфейсы. Не факт, что у вас есть хотя бы один IPv4 IP-шник. Поэтому вопрос, как вы возьмете роутер ID, будет открытый. Если у вас есть IPv4 адреса, вы можете взять заимствовать роутер ID с какого-нибудь IPv4 интерфейса для работы IPv6 OSPF. Но если нет, вы должны будете указать ручками. Чексумма. Та же самая интернет-чексам. У нас есть одна чексумма в самом пакете для того, чтобы удостовериться, что пакет целый. И другая чексумма для того, чтобы убедиться, что LSA, которые будут в базе пользователей находиться, в базе роутеров, что они будут одинаковые. То есть вот эта чексумма интернет-чексам нужна при передаче пакетов, чтобы убедиться, что они не поломались. Здесь вот не хватает поля аутентификации. И вот это вот, соответственно, тут было authentication и authentication data.

Аутх data. А здесь был тип аутентикации. Вот это вот. Authentication type. Ну, соответственно, authentication type сейчас не нужно. Authentication, authentication data не нужно. И по факту вот здесь просто нули. Заголовок остался тот же самый, по сути своей. У него только вот одно поле, которое было authentication type, выпилили. И authentication и authentication data выпилили тоже. То есть, да, заголовок просто сократили на длину ненужных полей. Hello-пакеты тоже остались очень похожи. Немножечко они изменились в том смысле, что раньше у нас в Hello-пакете передавались, во-первых, маска. Начинался Hello-пакет с маски. И мы этим самым подтверждали, что когда мы отправляем IP-пакет с какого-то интерфейса, он уходит. И мы указываем в качестве IP-шника, источника в самом IP-пакете наш адрес, primary address на интерфейсе. И в Hello-пакете мы указывали маску для того, чтобы сказать, с какой маской мы настроены.

В IPv6 у нас OSPF v3 работает, как вы помните, по link local адреса. Маску там писать бессмысленно. Она всегда 64-я. Поэтому первое поле, которое у нас было, соответственно, маска сети, оно больше не нужно. Адресные информации с Hello убрали. И IP-шник из заголовка IP-пакета, естественно, он маршрутизируемый раньше был, сейчас он стал link local. И вот маска сети. Это все не нужно. Это все адресная информация, от которой OSPF v3 стремится отказываться. Но возникает вопрос. Когда мы отправляем Hello-пакет, мы должны указать, каким, каким, чем мы это отправили. То есть, помните, да, как это в анекдоте. Чем, чем ты это сказал. Ну вот, да. Вы должны будете указать как-то, что это отправляет Hello. Потому что может быть, например, ситуация, когда у нас есть два роутера, и, соответственно, у нас два интерфейса. И вот мы говорим, мы отправляем одним интерфейсом Hello и другим интерфейсом Hello.

И здесь вот мы будем получать эти самые Hello. На двух разных интерфейсах мы видим два разных Hello-пакета. Или вот, например, другой сценарий, когда у нас один роутер точно так же двумя интерфейсами смотрит, но здесь вот, соответственно, стоит свитч или хап или что-то еще. И у нас здесь один интерфейс, и мы одно Hello посылаем и два разных Hello получаем. Это два разных сценария, и, соответственно, роутер получателя, он должен их различать между собой. Если мы будем отправлять Hello-пакеты и не будем указывать, чем мы это отправили, то только по IP-шнику это будет непонятно. IP-шники на разных интерфейсах имеют полное право быть одинаковыми. Поэтому для того, чтобы различать Hello-пакеты, отправленные на разных интерфейсах, OSPFV3 использует схему примерно такую же, как была в Spanning 3. Он просто в исходящих пакетах пишет, каким номером интерфейса он это отправил. И на разных интерфейсах мы, соответственно, будем видеть разный интерфейс ID. Каждый интерфейс у вас будет пронумерован. Есть роутер, у него есть один интерфейс, второй интерфейс, третий интерфейс, и вот они все пронумерованы. Первый, второй, третий и так далее.

Вы в каждом Hello указываете, каким номером интерфейса вы это отправляете. Дальше очень похожие все вещи. Priority. Было такое поле, кто будет DRM, BDRM, если что. Hello интервал 16-битный, dead интервал. Уменьшено поле до 16 бит, потому что нет смысла указывать, что у вас там будет какой-то конский dead интервал, который не влезет в 16 бит 65 тысяч секунд. Ну, то есть смысла нет, правда? Поэтому да, dead интервал уменьшен. На целый байт сократили мы тем самым размер этого поля. Кого мы считаем DRM, BDRM, кого мы считаем соседями, это все было в заголовке OSPFV2. Ну, единственное, что вот поле опций, оно было однобайтовое, а сейчас оно стало трехбайтовое. И в OSPFV3 действительно этих самых опций будет несколько больше. Дальше. В DBD-шках, в общем-то, никаких изменений особых не произошло.

Добавили поле опций, которое стало, точнее, не добавили, изменили его. Оно стало трехбайтовое, так же, как и в заголовке Hello. Ну и оставшиеся добили нулями. То есть здесь вот у нас нули, здесь нули. Раньше поле опций было маленькое, однобайтовое. И, соответственно, здесь вот были нули, а тут вот было опции. Сейчас вот его сделали больше, и для того, чтобы размер пакета был выровнен по границам 4 байт, все остальное добавили нулями. Мту точно так же передается. Флаги, инициализация на этапе к старт, more, есть еще DBD-шки, EMS, что мы хотим быть мастером. Это все то же самое, как в OSPFV2, оно сохранилось. Точно так же sequence number у вас будет указывать на то, с какого номера вы будете номеровать эти самые DBD-шки. И, ну, когда вы передаете DBD, вы указываете, что у вас там внутри передается. То есть само мясо. Мясо вы передаете только заголовки LSEIC, естественно, в DBD-шках.

Само содержимое LSEIC передается уже отдельно по запросу. Сами LSEIC у нас будут немножечко, опять же, изменяться. У нас поле опций... Да, поле опций в LSEIC уже больше не нужно. Когда мы указываем, что у нас есть какие-то... Когда у нас есть какие-то опции, оно приехало в тело LSEIC, то есть в само мясо. Заголовок LSEIC уже поле опций не требует. То есть при понимании, какие LSEIC есть у соседа, необязательно ему каждый раз передавать опции. Вот эта вот штука, это заголовок LSEIC абсолютно любого типа, что у нас первая, вторая, третья, четвертая, пятая LSEIC, седьмая LSEIC. И здесь вот, соответственно, дальше идут данные. Данные самой LSEIC. Вот там же уже теперь будут передаваться и опции. Раньше они передавались тоже в заголовке. И, соответственно, поле LSEIC-type немножко увеличили.

Раньше оно было однобайтовое, и у нас там было вот первая, вторая, третья, четвертая, пятая, седьмая, и шестая, восьмая у нас, соответственно, были зарезервированы. Шестая под мультикасту SPF, восьмая уже не помню, куда что. И девятая, десятая и одиннадцатая были APACU LSEIC. Использовались, например, для MPLS Traffic Engineering. Сейчас у нас LSEIC-type изменилась, стало двухбайтовое. На самом деле двухбайтовое, оно как бы только частично. Это два поля по одному байту, два подполя. И сейчас посмотрим, как они там будут выглядеть. В остальном заголовок LSEIC остался тот же самый. У нас есть, кто придумал LSEIC, LSEID, Sequence Number, опять же, и Cheeksuma. Ну или на LSEIC. Про тип LSEIC. В OSPF V2 у нас было очень ограниченное количество LSEI, и в синеме было все просто.

В OSPF V3 LSEIC стало больше. То есть, во-первых, есть LSEIC-ка первая, вторая, третья, четвертая, пятая, седьмая. То есть, это все LSEIC-ки сохранились, и по смыслу они примерно те же самые будут. Первая LSEIC-ка будет называться роутер LSEIC, вторая – нетворк LSEIC. Смысл у них тоже самое. Это все топология. Топология. Дальше. Есть третья LSEIC-ка. Она будет называться Inter-Area Prefix LSEIC. То есть, тот же самый смысл, что был раньше. Мы передаем информацию между регионами, и у нас LSEIC-ка третьего типа отвечает за то, что АБР рассказывает внутрь какого-то региона, что за его спиной в другом регионе есть какие-то другие сети. Это адресная информация. Четвертое. Inter-Area Rooter LSEIC. То же самое, что было в OSPFV2, просто переименовали. Раньше она называлась AS-Bio Summary. Сейчас она называется Inter-Area Rooter, что в таблице топологии у нас нету какого-то роутера в своем регионе.

Но АБР рассказывает, что какой-то роутер ID известен в другом регионе. Пятерка. AS External LSEIC. Смысл тот же самый. Шестерка. Деприкейтед. На самом деле, она никогда даже не пыталась быть живой. То есть это, опять же, тяжелое наследие M-USPF. Multicast LSEIC. Семерка. NSSA LSEIC. Ну, как вы понимаете, да? Not-So-Stabi Area. Все то же самое. И дальше начинаются новости. И новости заключаются в следующем. Восьмерка. Link LSEIC. В USPF второй версии у нас роутеры, например, которые были связаны между собой. Вот у нас простейшая топология R1 и R2. Просто прямым патч-кордом связывались. Мы тип среды ставили point-to-point. Point-to-point. И у нас, соответственно, была одна LSEIC первого типа от роутера R1. Вторая от роутера R2. И вот R1 говорил, я вижу R2. И R2 говорил, я вижу R1. Дальше каждый из них говорил, у меня за спиной есть сетка A. Другой говорил, у меня за спиной есть сетка B.

Они анонсировали стаб-нетворки. В каждой LSEIC первого типа у нас был один point-to-point link и один стаб-нетворк. И со стаб-нетворками все понятно. А point-to-point link указывал IP-шник, который висит на интерфейсе, к которому мы с соседом дружим. И это было не случайно. В LSEIC первого типа в USPF V2 мы IP-шники указывали, потому что соседу этот IP-шник нужно было знать. В таблицу маршрутизации он заносил именно IP-шники NextHop. Поэтому нам нужно было знать, что у нас использовалась сетка, например, 10.0.0.0.0-24. И у одного роутера был IP-шник .1, а у другого .2. Поэтому когда R1, например, говорил, давайте посчитаем кратчайшую топологию, как добраться до сетки B. Вот он говорил, кратчайшим способом будет направить трафик по маршруту до R2, а NextHop в этом маршруте будет IP-шник 10.002. Поэтому, зная вот этот вот IP-шник, который с ним в одной среде расположен, роутер мог пополнить таблицу маршрутизации, мог прописать правильные NextHop.

В USPF V3 концепция эта немножко усложнилась, потому что в LSEIC-ах роутерных у нас IP-шников больше нету никаких, даже linklocal. Мы дружим по linklocal. В таблицу маршрутизации мы должны добавить linklocal адрес, но мы его не знаем. И возникает вопрос, а что делать? И делать следующее. В LSEIC-ах первого типа у вас больше не указываются IP-шники, на которых у вас идет дружба с соседними роутерами. LSEIC-и, которые... не LSEIC-и, а сетки, которые у вас за спиной есть, они теперь анонсируются в специальных intra-area префикс LSE. Это отдельно указано, типа вот те самые в кавычках стаб-нетворки. Вы указываете, соответственно, вот здесь, что у вас LSEIC-и девятка. Это пользовательская сетка, которая маршрутизируемая, которая позволяет реплицировать между роутерами указания, какие именно IP-сети к какому роутеру подключены. Раньше это был кусок LSEIC-и первого типа. Сейчас адресная информация переехала в LSEIC-у девятку.

Но возникает вопрос, как LSEIC-у девятку прикрепить к LSEIC-и первого типа. И здесь очень просто. У нас каждый интерфейс пронумерован. И мы говорим, вот здесь у нас интерфейс номер один. Соответственно, LSEIC-а девятка говорит, у роутера первого на первом интерфейсе висит сетка FD 0,1,2,2,2,4. На роутере втором тоже у нас, соответственно, интерфейс номер один и сетка FD 0,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2. А, соответственно, связь между двумя роутерами. Для того, чтобы построить в таблице топологии маршрут и указать NextHop IP-шник, нам нужны, соответственно, еще рядышком адреса LinkLocal. То есть LLA. Это будет на интерфейсе номер два. И здесь то же самое. Мы выпускаем LSEIC-у и говорим LinkLocal адрес на интерфейсе номер два. У нас этот интерфейс второй. И, соответственно, мы говорим, на ROL3R2, на интерфейсе номер два, есть IP-шник.

Но этот IP-шник не маршрутизируемый. Он действительно только в пределах вот этого канала. И зона распространения таких новых LSEIC восьмого типа будет LinkLocal. Будет Link. То есть они не передаются между разными линками. В OSPF U2 у нас фактически было два варианта, как распространять LSEIC. Все нормальные LSEIC распространялись в пределах региона, а пятерки распространялись в пределах автономной системы. Здесь вот у нас появляется LSEIC восьмого типа, которая распространяется только между роутерами в пределах канала. Вот. И там вот как раз только LinkLocal и передаются. Действительно, зачем знать про LinkLocal адреса всем, кто в этом канале не находится? Не нужно это делать. И просто бессмысленно. И вот таким вот образом у SPF третьей версии будет строить топологию сначала по интерфейсам, кто на кого как смотрит. А потом для того, чтобы пополнить таблицу маршрутизации, вот эти вот LinkLocal у нас будут использоваться.

Тип LSEIC у нас будет двухбайтовый вместо однобайтового. И вот можно заметить, что здесь появляются какие-то 2, 0, 0, 1, 2, 0, 2, 0, 3, 2, 0, 4, 4, 0, 0, 5, 2, 0, 0, 6, 2, 0, 0, 0, 7, 0, 0, 0, 0, 8, 2, 0, 0, 9. И здесь на самом деле будет 3 битика. Самые старшие биты будут указывать на то, что это за LSEIC. Самый первый битик, вот этот вот самый-самый-самый первый битик, указывает на то, что делать, если к вам приходит LSEIC, и у нее какой-то непонятный тип. Этот непонятный тип может быть, например, не знаю, apache LSEIC. То есть как раз для traffic engineering у нас могут использоваться какие-то другие LSEIC тоже. Вот если у вас будет в этом самом старшем битике стоять нолик, то вы трактуете эту LSEIC как то, что надо ее раздать всем роутерам в пределах канала, но при этом дальше передавать уже не нужно.

И дальше, соответственно, если у вас там стоит единичка, то в этом случае надо просмотреть на следующие 2 бита, вот эти, и там будет написано, какая область у нее будет, у этой LSEIC использоваться. В нашем случае мы видим, что самые старшие битики у всех LSEIC, которые здесь показаны, это как раз нолик. То есть если вдруг какой-то роутер не умеет распространять такие LSEIC, то он должен их оставить только в своем канале. На самом деле, какой-то другой роутер, который присылает такую LSEIC, он должен будет ее раздать просто всем в пределах канала, и мы дальше эту LSEIC перекладывать никуда не будем. Но если бы вдруг у нас была какая-то LSEIC, какой-то тип LSEIC, и у него был бы самый первый битик единичка, то есть, например, 8, 0, 0, там, не знаю, 1, то вот такую вот LSEIC мы бы распространяли по зоне распространения, которая закодирована была бы вот в этих двух битах. Если там было бы 0, 0, это значит, что это LSEIC в пределах канала,

0, 1 в пределах региона, 1, 0 в пределах автономной системы, и единиц, две единицы это зарезервировано. На самом деле, можно здесь вот как раз будет увидеть, что 2, 0, 0, 1, вот самые первые 4 бита, которые здесь у нас есть, это 0, 0, 1, 0. То есть зона распространения такой LSEIC 0, 1 это area, регион. Ну, действительно, LSEIC роутер у нас распространяется в регионе. Дальше, Network LSEIC то же самое, 0, 0, 1, 0 в пределах региона. Inter-area, prefix inter-area роутер все то же самое. AS External LSE, 0, 1, 0, 0. AS Scoping. То есть эта LSEIC разбегается в пределах всей автономной системы. Дальше 0, 0, в смысле 0, 0, 1, 0, 0, 0, 0, 0, 0, 0. Link LSEIC распространяется в пределах канала. И 2, 0, 0, 9.

Здесь опять 0, 0, 1, 0. Эта штука тоже распространяется в пределах автономной системы. То есть все LSEIC, которые будут иметь какие-то вот такие вот номера двухбайтовые, они в своем номере будут указывать, где они распространяются. Вы можете просто запомнить на самом деле, что номера у этих LSEIC будут такие же, как у OSPF второй версии. То есть даже если вы не помните вот эти вот самые первые цифры, которые есть, вы все равно можете воспроизвести их. Потому что LSEIC 1, 2, 3, 4 и 7 типа распространяются в пределах региона в OSPF v2. Они точно так же распространяются в пределах региона в OSPF v3. Девятка, intra-area, prefix тоже нужна для того, чтобы в своем регионе рассказать про какие-то сетки. У этих всех LSEIC, которые я сейчас только что обвел, у них зона распространения регион. И соответственно вот первый битик нолик, дальше два битика указывают на регион и четвертый битик ноль. Получается двойка первая должна быть. У пятерки зона распространения вся автономная система, поэтому там 0, 1, 0, 0.

Это как раз 0, 4, 0, 0, 5. И link LSEIC распространяется в пределах канала. У нее первые три битика нулевые, ну и четвертый тоже нулевой, 0, 0, 0, 0, 8. Механизм этот позволяет создавать LSEIC'и новые и распространять их. Ну, соответственно, да. Если вы увидите какую-то LSEIC'у, которая вот как раз будет новая, она не будет использоваться для сборки топологии, но она будет каким-то образом использоваться для иных задач. Ну, то есть, например, это может быть тот же самый conditional OSPF, типа CSPF или что-то еще. То есть авторы протокола заложили масштабирование этого механизма и позволили придумать такие LSEIC'и, которых изначально в LSEIC'е не было. И заодно для этих LSEIC'и указать возможность их распространения в пределах различных соседств. Так, что касается логики LSEIC'а первого и второго типа,

все то же самое, за исключением того, что из LSEIC'а первого типа вытащили топологическую информацию. Соответственно, там остались только номера интерфейсов. Вот у нас есть LSEIC, например, первого типа. Мы говорим, я роутер 1, я своим интерфейсом номер 1 смотрю на интерфейс роутер 2, тоже интерфейс номер 1. То есть вот роутер 1 первым интерфейсом смотрит на роутер 2, первый интерфейс. Интерфейсом номер 2 я смотрю на роутер 3 первый интерфейс. Вторым интерфейсом смотрит на роутер 3 первый интерфейс. Вторая LSEIC'а роутер 2 смотрит своим первым интерфейсом на первый роутер, вторым интерфейсом смотрит на четвертом. Четвертый роутер, первый интерфейс. То есть это, опять же, позволяет нам собрать пазл. Здесь мы видим, что у нас вот эти два товарища связаны между собой. Третий роутер. Первым интерфейсом смотрят на второй интерфейс роутера.

Где он есть-то? R1, EF3. Так как-то. Ну, то есть, да, здесь показано, каким интерфейсом мы смотрим на какой интерфейс какого роутера соседа. И получается, да, что после того, как вы все это сделали, вам для того, чтобы рассказывать про свои link-local адреса, нужно дополнительно еще LSA-ки девятки бросить с link-local. Так, LSA-ки восьмерки. Пардон. Здесь не нарисованы они, но они, конечно же, есть. То есть рядышком здесь будет LSA-ка восьмерка. И здесь еще тоже будет LSA-ка восьмерка. Вот. Например, вот за этот вот канал у нас будет две LSA-ки восьмерки. За вот этот вот канал у нас будет две LSA-ки восьмерки. За вот этот вот канал две LSA-ки восьмерки. За вот этот вот канал две LSA-ки восьмерки. Так. Да, они не нарисованы здесь, потому что, да, они бы привязывались к конкретному каналу. А здесь, соответственно, мы говорим про регион в целом.

Поэтому, да, каналов нет. Но в базе каждого роутера, конечно же, не будут. А вот LSA-ки девятки распространяются в пределах региона. И здесь вот они как раз есть. Что у нас у роутера первого на третьем интерфейсе есть сетка 0.1.64. Вот эта вот штука. Третий интерфейс. На нем есть маршрутизируемая сетка, действительная в пределах региона. И то же самое на четвертом роутере. Третьим интерфейсом мы смотрим другую сетку. Получается, что у вас в каждой LSA-ки топологической остаются только номера интерфейсов. Если вдруг у вас есть, соответственно, LSA-ки второго типа. Не LSA-ки первого типа друг на друга point-to-point смотрят. А LSA-ки второго типа. То там уже LSID будет не IP-шник DR, а указание как раз номера интерфейса на DR, которым он эту LSA-ку выпускает. Смотрите здесь какая штука. Раньше у нас LSID был IP-шник DR, и, конечно же, в пределах канала IP-шник DR был только у DR.

Сейчас у нескольких роутеров интерфейс, которым они смотрят в общий канал, может иметь одинаковый номер. Поэтому, по факту, когда мы говорим, что у нас есть LSA-ка вот в этом вот канале, например, LSA-ка второго типа, вот мы говорим, что у нас есть LSA-ка с LSID, например, там, не знаю, 2. Это означает, что у DR номер интерфейса, которым он смотрит в этот регион, будет 2. Но также у нее будет и advertising router. Advertising router ID будет, например, R1. Вот. И совокупность LSID и advertising router ID как раз указывает на то, кто выпустил LSA-ку, и каким интерфейсом этот кто-то смотрит в общий канал. Естественно, эта штука будет уникальной. Так. Роутерные LSA-ки по сути своей примерно то же самое будут иметь, что и раньше.

Здесь уже отказались от множественных топологий, то есть никаких вот этих самых type of service, никаких множественных метрик для интерфейса. Один интерфейс, одна метрика. У LSA-ки есть флаги, соответственно, вот эти вот флаги. И есть опции. Это мясо LSA-ки. Есть еще, конечно, здесь рядышком заголовок. Но заголовок там простой. Так. Что касается флагов. Каждый роутер, который придумывает LSA-ку первого типа, он рассказывает, будет ли он ASBR, будет ли он ABR. Это все такие же флаги, как в OSPF второй версии. Будет ли он строить virtual link в OSPF V2. На самом деле это тоже штука была. И будет ли он перекладывать LSA-ки семерки в пятерку. NSSA Translator Road. То есть вы, когда будете рассказывать про то, что вы генерите какие-то LSA-ки, вы, естественно, понимаете, все понимают, что вы можете генерить LSA-ку второго типа,

можете генерить LSA-ку первого типа, восьмерки девятки. Но вот про всякие неожиданные LSA-ки. Если вы ABR, то вы можете генерить LSA-ки трешки-четверки. Если вы EASBR, то вы можете генерить пятерки. Если вы NT, вы можете из семерок делать пятерки. Дальше. По поводу link type. Здесь у нас есть такое же поле, как раньше было в LSA-ках первого типа в OSPF. Там у нас первый link type был point-to-point соседству. Второе – это мультиаксесс-среда, связь с LSA-кой второго типа. Третье было Stub Network. Четвертое – OSPF virtual link. Здесь трешка зарезервирована, потому что Stub Network уехали в LSA-ку девятку. То есть адресную информацию из LSA-ки первого типа всю выпилили. И никакого мяса с IP-шниками не осталось. Здесь вообще нигде нет IP-шников. То есть остались только ID-шники. Каким интерфейсом мы на кого смотрим? Как называется интерфейс у соседа и кто будет сосед?

Везде только ID-шники. Идентификатор интерфейса у соседа и идентификатор самого соседа. Идентификатор соседа мы знаем, потому что в приходящих hello-сообщениях сосед рассказывает, каким интерфейсом он послал это hello. Следовательно, если мы на интерфейсе ловим его hello, мы видим, каким интерфейсом он в эту среду смотрит. Мы с ним можем подружиться именно по этому интерфейсу. Ну и метрика. Метрика точно так же 2-байтовая. Network LSA упростилась. Network Mask исчезла. Ну, соответственно, опции, поскольку в заголовке они раньше были, а сейчас они переехали в мясо, вместо Network Mask у нас появилось поле опций. В общем, оно как было простенько, так и осталось. В, соответственно, в именах LSA тоже произошли некоторые изменения. Изменения стали вполне логичные. То есть, то, что раньше называлось summary LSA, им причиняло очень много попа боли тем, кто не понимал, почему там summary. Ну, да, название когда-то давным-давно было вполне логично и понятное,

потому что summary – это суммарная стоимость пути за АБРом. Сейчас ее переименовали в inter-area префикс LSA. LSA-ка четверка – это то, что называлось ASBR summary. Ну, тоже, опять же, когда-то вполне логичное название, но теперь оно вообще становится непонятным. Если учесть, что многие думают, что summary – это просетки, которые можно просуммировать, проагрегировать, то вот ASBR summary казалось вообще абсолютно нелогичным названием для тех, кто не понимал причину этого названия. Ну, вот сейчас ее переименовали в inter-area роутер LSA. Название уже теперь говорящее. Link LSA – проканальные адреса. Intra-area префикс LSA – ну, понятно, что это, да, что это что-то в пределах своего региона. Префиксы, которые известны в своем регионе. Так, у девятки формат будет следующий. Мы показываем, сколько у нас есть префиксов. Дальше эти префиксы идут вот раз, два, три и так далее. Показывается, к чему подвязаны эти…

Это LSA-к девятка. Опять же, у нас есть интерфейс, в котором мы говорим, что у нас есть какая-то сетка. Это фактически то, что раньше рассказывала LSA-к первого типа, просто она указывала тип соседства, трешечка, стаб-нетворк. Вот если у вас было раньше стаб-нетворк, вы теперь выпускаете LSA-ку девятку и указываете Reference LS Type, что это подвязывается к LSA-ке первого типа. То есть это фактически бывшая стаб-нетворк для конкретного роутера. Конкретный роутер не видел никаких соседств, он просто в эту сетку смотрел интерфейсом. Если же у вас есть какой-то канал между двумя роутерами, и в нем есть маршрутизируемые адреса FD00-64, и вы хотите сказать, что у нас есть в канале между двумя роутерами маршрутизируемые адреса, то нельзя сказать, что эту сетку известна и на одном роутере, и на другом. Более правильно сказать, что у нас здесь есть LSA-ка второго типа, и к этой LSA-ке второго типа подвязана LSA-ка девятка.

И в этом случае вы указываете Reference LS Type 2.0.0.2, что это бывшая LSA-1, соответственно, или бывшая LSA-2. Дальше вы указываете ID-шник той LSA-ке, к которой вы привязываете эти адреса. То есть если у вас стоит LSA-1, то вы говорите роутер ID того, с кем вы дружите. Либо если у вас LSA-2, то вы указываете LSA-ID того DR-а, ну, LSA-ID того канала, к которому эти самые адреса будут подвязаны. Вот, опять же, если у вас есть LSA-2, она фактически, у нее идентификатор будет состоять из двух составляющих. У нее есть LSA-ID и у нее есть Advertising Router ID. LSA-ID будет номер интерфейса, которым DR смотрит в канал. И Advertising Router ID – это вот, собственно, кто DR. И вот в этой ситуации, если вы указываете 2.0.0.2, то Reference-TLS ID – это у вас будет, например, интерфейс номер 3,

а Reference-Advertising Router вы говорите вот тогда DR-ID. Ну и дальше указываете, соответственно, что у вас за префикс, какая длина маски, какая метрика, с которым вы знаете эту сетку и какие-то вот опции. В одной LSA-ID-9 можно приложить сразу несколько сеток. Ну, достаточно очевидно, да, здесь. То есть, если у вас вдруг на роутере есть сразу целая пачка интерфейсов, вы на каждый интерфейс выпускаете… Вы на… Да, вы на каждый интерфейс выпускаете… Сейчас, секунду. Вы на… Вы выпускаете на каждый роутер LSA-ID-9, не на каждый интерфейс, на каждый роутер, и указываете, что есть у вас стаб-нетворки. Вот одна сетка, вторая сетка, третья сетка. И на разных интерфейсах эти сетки будут присутствовать.

LSA-ID-9 при этом будет всего одна. Так, еще одна клевая штука, которая в OSPFV3 есть – это инстанции. Изначально, когда OSPFV3 придумывали, его придумывали для IPv6. Он работает поверх IPv6, он таскает IPv6 маршруты, и все замечательно, как бы все радуются тому, что как бы все работает. То, для чего протокол создавался, он и работал. Но, если вспомнить OSPFV2, в котором когда-то была гениальная идея «давайте делать разные таблицы маршрутизации для разных типов трафика», OSPFV3 придумывался тоже как бы с целью, что вдруг кому-нибудь когда-нибудь эта идея придет в голову. Соответственно, то, что раньше реализовывалось с помощью разных метрик Type of Service, когда вы LSA-ку передавали, вы говорили, что вот я интерфейс такой-то в Type of Service таком-то вижу с такой метрикой, а тот же самый интерфейс, но в другом Type of Service вижу с другой метрикой.

Вот в OSPFV3 немножко эту идею модифицировали. Сказали, давайте делать разные инстанции, что мы можем на одном и том же интерфейсе запустить разные инстанции OSPF, и тем самым сделать просто разные базы для разных инстанций, но при этом они будут работать поверх одного и того же интерфейса. Это не то же самое, что экземпляр OSPF в OSPFV2, когда мы говорили роутер OSPF1, роутер OSPF2. Это немножко другое. Это про то, что у вас один и тот же экземпляр OSPF может дружить разными своими подсущностями с соседом и говорить, что у нас есть инстанс такой, есть инстанс с такой, и нам нужны разные базы для этих инстансов вести. Но экземпляр при этом один и тот же. И, соответственно, изначально идея была такая. Но, в принципе, когда это придумали, уже было понятно, что идея мертворожденная, и в OSPF2 она мертворожденная, и в OSPF3 она никому нафиг не нужна.

Поэтому авторы протокола сказали, ну раз такую клевую штуку придумали, раз мы можем по одному и тому же интерфейсу дружить разными способами. Можем дружить так, а можем дружить эдак. Например, у нас потому что есть интерфейс, в котором голос передается, интерфейс, в котором, не знаю, что-то еще передается. Есть один интерфейс, в котором на ворот раз связаны между собой. Вот мы можем один и тот же интерфейс в разные топологии фактически включать. Вот в какой-то момент сказали, ну блин, идея интересная, идея красивая, но абсолютно бесполезная в том смысле, что применение ей не нашлось. И тут кому-то пришла в голову светлая мысль. А давайте мы некоторые инстанции выделим под другие адресные семейства. Вот, типа у нас есть таблица IPv6, обычная нормальная Unicast таблица. Вот пусть это будет один инстанц. Пусть у нас рядышком будет мультикастовая таблица IPv6. IPv6 Multicast. Она тоже выглядит как IPv6 нормальная Unicast таблица, но она отдельная.

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

они были просто однобайтовые. Что типа вот можно было бы до одного, до 255 различных экземпляров, как подружиться с соседом, использовать, опять же, в намеке на Type of Service. Сегодня мы используем следующие номера инстансов. Первые 32 штуки под IPv6 Unicast. Вторые 32 штуки под IPv6 Multicast. Третьи 32 штуки под IPv4. Четвертые 32 штуки под IPv4 Multicast. Дальше. Следующие 64 номера не зарезервированы, и их можно использовать под какие-то еще задачи. И последний вот четверть адресов договорились не использовать никогда. В общем, по аналогии, да, с классом D и E, видимо, какой-то намек был на это. Но, тем не менее, да. Вот получается, что если вы отправляете какой-то пакет и говорите, этот пакет соответствует инстансу, например, нулевому, то сразу понятно.

Это базовое нормальное IPv6 взаимодействие. Мы реплицируем обычно таблицу маршрутизации IPv6 Unicast. Если мы отправляем пакет и мы говорим там, что инстанс в нем будет 64, это значит, что вы на самом деле реплицируете IPv4 маршруты. Топология IPv4 или IPv6, она вообще никак не завязана на адреса. Она завязана на интерфейсы, у которых есть метрики. И LSA-ки первого и второго типов в этом случае они никак на адреса действительно будут не подвязаны. А то, что содержит адресную информацию, это LSA-ки восьмерки и LSA-ки девятки. Ну, соответственно, LSA-ки там трешки, LSA-3 и LSA-ки пятерки, семерки. Вот. Они могут быть, соответственно, разного типа в зависимости от того протокола, который вы реплицируете. Если вы реплицируете IPv4, вы в LSA-ки восьмерки, девятки, трешки, пятерки вкладываете IPv4 содержимое. Если вы реплицируете IPv6 маршруты, вы вкладываете IPv6 содержимое.

Если вдруг вам в голову придет адаптировать USPF под какой-нибудь там, не знаю, IPX, пожалуйста, у вас еще вот большая пачка этих самых инстансов, нераспределенные. Вы можете их задействовать под какие-то свои задачи. Мы не можем напрямую рулить этими самыми номерами инстансов. То есть в отличие от номера экземпляра USPF, который мы можем выбрать, сказать там роутер, USPF 1. Вот это вот номер экземпляра, это не номер инстанса. Номер инстанса назначается фактически в цисках автоматически при указании того, с чем будет работать конкретный экземпляр USPF. Если вы говорите, что у вас есть экземпляр USPF V3, который работает с IPv4, прекрасно. Соответственно, у вас сразу автоматически назначается номер инстанса 64. Если вы говорите, что вы будете работать с IPv6, сразу назначается номер инстанса 0. Ну и при отправке hello-пакетов вы указываете, соответственно, в каком инстансе вы дружите, и эти номера инстансов обязаны совпадать у соседних узлов.

По поводу аутентификации я уже, в принципе, говорил. Да, вы можете использовать штатные механизмы подписывания трафика, штатный алгоритм EH, либо, если хотите, можете также завернуть все в шифрование ESP. Единственная проблема есть, что USPF третьей версии не задействует протоколы согласования ключей. Internet Key Exchange или ISA KMP, Key Management Protocol. Поэтому вы должны будете вручную создавать САшки. Когда мы говорим про IPsec, мы обычно говорим, что IPsec у нас работает в двух фазах. Фаза 1 и фаза 2. На фазе 1 согласуются так называемые пропозлы. На фазе 2 согласуется само шифрование трафика. И вот эти вот фазы 1 и фаза 2, они будут соответствовать как раз вот этим вот товарищам. Протоколу согласования ключей, которые на лету вам сгенерят Security Association в зависимости от тех параметров, которые вы хотите использовать. Здесь вы должны будете вручную сказать, какие алгоритмы шифрования, какие алгоритмы хеширования вы будете использовать.

И самое главное, вы должны будете задать тот самый вот Security Association ID-шник, с которым вы будете работать. Фактически можно сказать, что вы должны будете своего рода ключ указать, поверх которого OSPF будет работать. Вы можете также использовать дополнительную штуку, которая называется OSPF v3 Authentication Trailer. Это адаптация OSPF v3 для аутентификации с помощью механизма такого же, как и был в OSPF v2. То есть вы добавляете к пакету номер ключа и цифровую подпись. Эта штука не стандартная, она опциональная. И совершенно не факт, что у вас обязательно конкретно ваша железка ее будет поддерживать. Более того, очень многие роутеры ее по факту не поддерживают. Ну, даже по номеру RFS видно, что он достаточно свежий. Тем не менее, как бы теоретически такая возможность есть. Если вдруг очень сильно захочется, да, вы можете попробовать ее использовать. Но опять же, да, что многие роутеры будут поддерживать, это будет IPsec.

Его будут поддерживать почти все, почти наверняка. А authentication trailer, ну это под большим вопросом, будет он или нет. Так, давайте посмотрим, как это все дело будет включаться.