Транспорт IP-MPLS (2)

Продолжаем мы разговор про протокол динамической маршрутизации. Мы говорили с вами про то, что, в принципе, в сетях необходимо будет реплицировать таблицы маршрутизации на роутерах. Вспомнили, как выглядят RIP и EJRP, и теперь вспоминаем остальные протоколы, которые бывают в реальных сетях. Если RIP и EJRP — это протоколы, которые, ну, по большому счету, нам нужны просто потому, чтобы о них рассказать на экзамене, что они бывают, то вот те протоколы, которые будут сейчас, — это уже протоколы реально живые, которые используются в продакшене в провайдерских сетях, поэтому знать их работу надо будет как очень нашим. Опять же, поскольку наш курс все-таки базовый, мы не будем с вами прямо детально изучать их работу, не будем на этом курсе изучать все возможные крутилки в SPF, в BGP. Мы пробежим их все-таки рамочно. Но, тем не менее, я постараюсь рассказать максимально подробно в том объеме, который предусмотрен курсом, и, может быть, чуть даже глубже, то, что вам может пригодиться. OSPF — это протокол стандартный.

В отличие от того же самого EJRP, который долгое время был проприетарным протоколом, потом Cisco его открыла, OSPF протоколом стандартным был всегда. Этот протокол достаточно быстрый по сравнению с RIP, по сравнению с другими стандартными протоколами, которые были 30 лет назад. То есть, когда вы видите в литературе, что OSPF говорит «быстрый протокол», да, он быстрый, да, он быстрый по сравнению с RIP. Он не такой же быстрый, как EJRP, например. То есть, EJRP быстрее во многих случаях, чем OSPF. Но OSPF внутри корпоративной сети действительно заметно ускорял обработку пакетов, заметно ускорял сходимость сети по сравнению с какими-то другими протоколами, которые были на тот момент, когда OSPF появился. Другой должен был протокол RIP, который был действительно методом. OSPF, так же как и EJRP, будет устанавливать соседские взаимоотношения. Опять же, поскольку он не отсылает всю таблицу маршрутизации целиком, он будет кидать только дельты. Он должен знать, какому соседу какую дельту будет кинуть нужно.

Устанавливают соседские взаимоотношения, находят роутеры соседей друг друга с помощью HelloPacket. Дальше, после того, как соседские отношения установлены, роутеры обмениваются кусочками информации. И вот этот кусочек информации в RIP и в EJRP был маршрут. То есть RIP и EJRP дали друг другу натуральные маршруты. Они говорили, я знаю такой-то маршрут, я знаю такой-то маршрут с таким-то набором метрик. OSPF не передает маршруты. То есть самое популярное заблуждение, что OSPF работает на уровне маршрутов. Нет, он может передавать все, что угодно. Ему абсолютно все равно, что передавать. Он не работает с маршрутами, он работает с кусками топологии. Роутеры рассказывают друг другу, как они друг с другом соединены. Соответственно, после того, как все роутеры у вас выпускают свои кусочки топологии, и все роутеры обмениваются всеми кусочками топологии между собой, у вас все роутеры складываются в единую сеть. Каждый роутер знает, как эта сеть устроена, кто на кого какими интерфейсами смотрит, и может посчитать кратчайшие маршруты между роутерами.

Здесь я говорю слово маршрут, но я не имею в виду IP маршрут, я не имею в виду строчку в таблице маршрутизации, я имею в виду натуральную трассу, по которой можно кратчайшим способом добраться между двумя роутерами. У нас на картинке 4 роутера. R1, R2, R3 и R4. И, соответственно, каждый роутер строит кратчайшую трассу до каждого другого роутера. Как можно добраться от роутера R1 до R3? Можно пойти через роутер R2 транзитный, можно пойти через роутер R4. И роутеры выясняют, какая трасса лучше путем натурального подсчета стоимости каждой трассы. После того, как кратчайшие стоимости посчитаны, кратчайшие трассы найдены, дальше роутеры рассказывают, в какие IP-сети они смотрят. Кроме того, что есть интерфейсы, которые смотрят на соседей, роутеры говорят, я еще вижу маршруты, они прямо ко мне присоединены. То есть каждый роутер рассказывает про свои connected маршруты. И после того, как R1 говорит, я построил кратчайшую трассу до роутера R3, я вижу, что у R3 есть подключенная сетка такая-то,

R1 может сказать, окей, значит, я могу добраться до той сети, которая подключена к роутеру R3, просто по кратчайшей трассе до роутера R3. То есть ключевой момент. Роутеры не передают друг другу маршрут. Роутеры передают друг другу кусочки топологии. Каждый кусочек — это то, с какими соседями роутеры подружились и в какие подключенные сети у них есть живые интерфейсы. Никогда транзитный роутер не рассказывает, что у него есть доступ к какой-то сети. То есть вот это вот ключевое отличие протокола distance-векторного от протокола link state, и в нашем случае в SPF. Дальше. После того, как у нас соседские взаимоотношения установлены, роутеры подружились друг с другом, синхронизировали таблицы LSA, кусочек информации, которая будет передаваться, будет называться link state advertisement. Здесь неправильно написано advertisement. И, соответственно, все эти LSA попадают в базу LSDB, link state database. У SPF есть в двух версиях. Первый, который мы с вами будем изучать, это SPF второй версии.

Есть другой, который — SPF третьей версии. У SPF V2 работает только поверх IPv4 и обменивается только маршрутами IPv4. У SPF V3 работает только поверх IPv6. Изначально сделан для того, чтобы обмениваться маршрутами только IPv6. Потом к нему сбоку прикрутили возможность обмена и IPv4 маршрутами тоже. В любом случае, обе версии работают поверх мультикаста. То есть они отправляют hello-пакеты мультикастом, обнаруживают соседей мультикастом и посылают много чего тоже мультикастом. В случае необходимости они могут переключаться на unicast. Но это у них как бы опциональная возможность. По умолчанию, если есть мультикаст на канальном уровне, они используют именно его. Используются два адреса. Для работы hello-протокола, обмена hello-пакетами, установления соседства и всего остального будет использоваться 224.005.eff02.2.2.2.5. Это специальные, соответственно, адреса для обнаружения соседей. И есть еще концепция designated router в OSPF.

Соответственно, для его работы будут использоваться адреса 224.006.eff02.2.2.2.6. То есть вы можете отправить пакет на адрес 224.006, и designated router его получит. Специальный адрес для того, чтобы не надо было знать, кто конкретно сейчас designated router. Он один всего в канале, и, соответственно, вот он всегда получит этот пакет. Дальше. Hello-пакеты отправляются по таймеру. Таймеры на всех соседских роутерах должны будут совпадать. Они не обязаны совпадать на всех роутерах в топологии, но они обязаны совпадать на всех роутерах в одном сегменте, в котором у вас происходит соседство. То есть если вы соединяете два роутера патчкордом, вот на этих двух роутерах, на интерфейсах, которыми они друг на друга смотрят, таймеры должны быть одинаковые. Таймеров два — это Hello-интервал и Dead-интервал. Оба они указываются прямо в самих Hello-пакетах. Hello-интервал — как часто отправлять Hello-пакеты, Dead-интервал — через сколько признавать соседа трупом, если он ничего не присылает.

По умолчанию 10 на 40. на медленных сетях. Медленные сети — это в концепции EJRP был. На point-to-point линках и на broadcast-линках, там, где можно отправить один Hello-пакет, и он дойдет до всех абонентов сразу. Там, где нельзя в канал отправить один пакет, чтобы он дошел до всех абонентов сразу, то есть там, где нету broadcast или multicast на канальном уровне, вы должны будете каждому отдельному своему соседу отправлять unicast-овый Hello-пакет, и вы должны будете в этом случае гипотетически отправлять много разных пакетов Hello в одном и том же проводе. Поэтому Hello-интервал увеличивается до 30 секунд, и Dead-интервал увеличивается до 120 секунд. Просто для того, чтобы вы могли не так часто отправлять пакеты, и у вас оставалась какая-то полоса пропускания для других пакетов в том числе. То есть когда у вас, например, point-to-point провод, здесь никаких проблем нет. Вы просто отправляете все в канал, и оно просто доходит до получателя.

В ситуации, когда у вас, например, есть frame-relay link, вот здесь frame-relay switch, и в этом frame-relay switch еще есть роутеры, вы должны будете каждому отдельному соседу отправить свой собственный кадр с указанием своего собственного DLCI. Соответственно, в один и тот же интерфейс вы отправляете кадры до одного роутера, до другого роутера и до третьего роутера. И у вас получается в один и тот же канал надо отправлять периодически три разных hello для того, чтобы достать до трех разных соседей и сказать им, что вы живы. В этом случае нужно будет увеличить время между отправкой отдельных кадров до каждого отдельного роутера соседа, чтобы не забивать канал. Дальше. Как уже было сказано, таймеры обязаны совпадать. Если не совпадают, соседства не установятся. Также должны совпадать номера регионов. То есть, как вы помните, у SPF можно топологию единую автономную систему разбить на несколько частей, на несколько area, так называемых,

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

к одному и тому же региону с одинаковыми номерами, они должны будут еще так же одинаково трактовать этот регион, как то, что этот регион действительно будет стабом являться или не будет. У стаба есть только один флаг, хотя на самом деле стаб-регионов есть несколько разных типов. Мы на курсе по роутингу разбираем, что там есть обычные стабы, тотали стабы, НССА, тотали НССА. Вот флаг стаба должен совпасть на соседнем роутере, причем неважно какой стаб, главное, чтобы оно просто сошлось. Дальше. У вас должно быть... Должно в пакетах отправляться, иногда будут какие-то признаки, по которым можно будет понять, что пакет легитимный или нелегитимный. Вы в OSPF можете использовать процедуру аутентификации, вы можете отправлять в пакетах, которые вы отправляете в OSPF, также и хэш от содержимого пакета, либо вы можете вкладывать пароль в открытом виде. Понятное дело, в открытом виде вкладывать пароли –

это совсем плохая идея, а вот хэши вкладывать в пароль – это, в принципе, неплохая идея. То есть если вы опасаетесь, что у вас в этом проводе вдруг кто-то возьмет и будет подслушивать злодейски и будет пытаться вбрасывать вам какие-то левые маршруты, то при отправке hello-пакетов вы можете отправлять эти пакеты с указанием некоторого ключика. С одной стороны отправляете ключик, и с другой стороны на роутере настраиваете такой же ключик. Роутер, который пытается вам отправить левые hello-пакеты, не предъявляя такой ключик, не демонстрировав владение таким ключиком, он, соответственно, подружиться с нашими роутерами не сможет. После того, как вы установили соседские взаимоотношения, дальше каждый роутер рассказывает, как он видит сеть, какие коннекта сети у него есть и какие интерфейсы смотрят на соседей, с какими соседями установились соседские взаимоотношения. То есть каждый раз, когда у нас что-то происходит в топологии, у нас выпускается новый кусочек топологии, новая лосейка, и эта лосейка разбегается по всей сети. В нашем случае у нас на роутере R1

будет, естественно, своя лосейка будет, я не знаю, почему на этом слайде ее нету, но, естественно, будет своя лосейка, где роутер 1 скажет, что я вижу роутер R2 за 10 копеек, и я вижу роутер R4 за 5 копеек. То есть интерфейс, которым R1 смотрит на роутер R4, будет стоить 5 копеек. R2 говорит, что я вижу R1 за 10 копеек, R2 за 20 копеек. То есть вот за 10 копеек, за 20 копеек. R3 говорит, я вижу R2 за 20 копеек, я вижу R4 за 10 копеек, и кроме того, R3 заявляет, что у него есть коннекта сетка 10.0.0 по 24 маски, и интерфейс, который в нее стоит, стоит 15 копеек. И R4 заявляет, что у него есть интерфейс, который смотрит на роутер R3 за 10 копеек, и на R1 за 5 копеек. R4, вот, R1 за 5 копеек, R3 за 10 копеек. Каждый из этих роутеров выпускает такой кусочек информации, который называется LSA, и все эти LSA в памяти у всех роутеров возникают в таблице LSDB за общий какой-то регион.

То есть все вот это вот происходит в одном регионе. Например, не знаю, Area 1. Вот. Все они подружились между собой, все они обменялись LSA, и дальше начинается процедура сборки пазла. Каждый роутер говорит, вот, допустим, R1 говорит, я роутер R1, я начинаю собирать пазл с самого себя. Так же, как мы, например, когда берем, вот, покупаем коробку с пазлом, там все кусочки, они перемешаны. Мы находим какие-то ключевые, как правило, ключевые элементы в этом пазле, с которых удобно начинать этот пазл. Допустим, если у нас есть картинка, которая разделана на кусочки, и дальше все кусочки в перемешку лежат, обычно там собираются сначала с рамки. То есть находят кусочки, которые формируют рамку, складывают их между собой, потому что проще всего начинать именно с них. Та же самая история и с OSPF. OSPF находит свою собственную LSA, он ее сам выпустил, он ее может легко найти, говорит, я R1 смотрю на роутер R2 за 10 копеек. Соответственно, мне надо сейчас найти кусочек пазла R2

и убедиться, что он меня тоже видит. Он находит LSA у роутера R2 и видит, что, да, с R1 действительно связь есть. Поэтому, когда он говорит, сейчас я буду собирать, вот моя LSA, вот она смотрит на роутер R2, вот соответствующий кусочек пазла роутера R2, он меня тоже видит. Дальше он говорит, я вижу также R4. Вот он говорит, я вижу R4, R4 меня тоже видит. Вот он R4, вот он я. Дальше R2, вот он роутер R2, видит меня и видит R3. Соответственно, R2 видит, ну, вот так вот это выглядит, R3. R3 действительно согласен, что он R2 видит. И R4 тоже говорит, я вижу тоже R3. Соответственно, R4 говорит, что видит R3, и R3 тоже видит R4. Вот у нас картинка собралась, то есть путем сборки пазла из LSDB получается карта, кто на кого, какими интерфейсами смотрит. Кроме того, R1 говорит, это все у нас происходит в сознании роутера R1. На самом деле у всех остальных роутеров точно такие же вычисления происходят.

Он говорит, что R3, помимо всего прочего, помимо того, что он видит роутер R2, помимо того, что он видит роутер R4, у него еще есть интерфейс, который смотрит в сетку 10000 по 24 маске. Он говорит, я вижу, что у него есть вот здесь вот 100004 и стоимости, которые здесь есть. Стоимости считаются в сторону соседа. То есть когда мы говорим, что у нас есть R1, который смотрит на R2, вот он говорит, я вижу соседа R2 за 10 копеек. R2 говорит, что он видит R3 за 20 копеек. R1 видит R4 за 5 копеек. R4 видит R3 за 10 копеек. И, соответственно, R3 видит сетку за 15 копеек. И, соответственно, мы считаем стоимости, как можно добраться до вот этой вот сети 10.000. Есть вариант пойти вот так вот, есть вариант пойти вот так вот. Ну, понятно, что в одном случае 10 копеек плюс 20 копеек, 30 плюс 15 — это 45 копеек. То есть по верхнему маршруту сетку можно добрать за 45 копеек. Через низ можно добраться 5 плюс 10 плюс 15 за 30 копеек.

Мы посчитали два возможных маршрута и вычисляем один самый дешевый, в нашем случае вот такой вот. То есть от роутера R1 через роутер R4 добраться до роутера R3 стоит 40 копеек. Это самый короткий маршрут от роутера R1 до сети 10.000 по 24 маске. У SPF полученный результат записывает в промежуточную табличку. Дальше из таблички промежуточный маршрут пытается установиться в таблицу маршрутизации. Может быть, у SPF сможет несколько маршрутов в таблицу маршрутизации поставить, если будет два абсолютно одинаковых маршрута по стоимости. Например, у нас будет здесь вот не 10 и 20 копеек и 5 и 10 внизу, а вот 20 и 10, например, вот так вот будет. Тогда вариант пойти через верх и вариант пойти через низ, они будут одинаково стоить 45 копеек. Может быть, конкретная реализация сможет поставить два маршрута в таблицу маршрутизации. У нас трафик будет ходить, например, по обоим. Дальше. Стоимости на интерфейсах, как вы знаете, они совершенно произвольно расставляются,

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

Потому что РИП фактически тоже трактует сеть как набор пост-ворышков. Каждый интерфейс у него стоит как один прыжок. Один прыжок или одна копейка – разницы особо нет. То есть, что РИП, что у SPF будут примерно одинаково вычислять маршруты. Но вы можете эти стоимости выставить совершенно произвольным образом. Если в РИПе вы не можете сказать, что интерфейс стоит 5 прыжков, то в SPF вы можете сказать, что у нас интерфейс стоит 5 копеек. Или 10, или 20, или миллион. Никто вам это сделать не мешает. И как следствие, вы можете сказать, что у нас, допустим, медленные интерфейсы должны по возможности роутера избегать. Быстрые интерфейсы по возможности они должны загружать. Можете наоборот сделать. Что сказать, у нас не скорость интерфейса будет принципиально важной метрикой, а, например, то, что задержка через определенные интерфейсы будет выше или ниже. Например, какой-то интерфейс – это у нас использует спутниковый провайдерский канал. Вот мы купили там L2 канал через спутник у провайдера. И говорим, ну вот как бы через него трафик пускать – это как бы неплохо, но дорого. И, во-первых, и, во-вторых, это тупо медленно.

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

стоимостью стартового назначают в соответствии с какими-то своими предпочтениями, с какими-то своими представлениями прекрасным. Может быть такое, что стартовые стоимости на интерфейсах у вас на роутерах будут совсем-совсем не похожи. Кто-то скажет, давайте везде стоимости по 100 поставим, кто-то скажет, давайте везде стоимости по единичке, кто-то скажет, давайте обратно пропорционально скорости, кто-то скажет, давайте обратно пропорционально задержке, кто-то скажет, что давайте вообще от балды поставим. То есть фантазия производителя, она не ограничена ничем, поэтому логику вы должны сами здесь будете контролировать. Далее. Хотел здесь какую-то умную мысль сказать, но ладно, потом вспомню, скажу. Каждый роутер у вас должен иметь уникальный идентификатор, который называется роутер ID, и этим роутер ID будут подписываться все LSA, которые выпускают ваш роутер. Соответственно, вы запускаете процесс OSPF, OSPF у вас выписывает LSA,

и все эти LSA идут с указанием того, кто их придумал. И вот в течение всего срока работы OSPF у вас этот роутер ID обязан оставаться неизменным. Если он поменяется, у вас не будет понятно, что LSA, которые выписаны на старый роутер ID, это все еще ваши LSA. Поэтому вы поменяли роутер ID, вы должны будете все LSA из базы всех роутеров удалить, желательно соседство с соседями прервать, и после чего выпустить новые LSA уже с новым роутер ID. Поэтому обычно роутер ID стараются менять только один раз. Один раз поставили роутер ID при настройке сети, и дальше уже я его не меняю. Этот роутер ID — это просто число. То есть просто 32-битное число. Его удобно записывать в форме IP-адреса, IP-ли-четвертого. Но что у OSPF о второй версии, что у OSPF о третьей версии, этот роутер ID — это просто 32-битное число. Например, 1 — это число, и оно может быть роутер ID. А IP-шникам оно быть не очень может,

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

роутер ID не сможет стать дублирующимся. То есть если вы используете адреса лупбеков, которые у вас используются для целеадминистрирования, и вы точно знаете, что на каждом отдельном роутере используется свой отдельный уникальный IP-адрес, то и роутер ID логично сделать именно таким уникальным. Вот. Роутер ID, единственное, что от него требуется, это быть уникальным, больше от него ничего не требуется. Ну, еще и требуется, чтобы он был числом. Каким образом железка может этот самый роутер ID получить? Самый простой вариант – это администратор приходит и прибивает гвоздями, говорит, «Вот всегда использую роутер ID 0001». «Я всегда использую роутер ID 10, 17, 34, 49». То есть какие хотите использовать роутер ID, такие прибиваете гвоздями, но вы сами отвечаете за то, чтобы потом вам это пришлось траблшутить. Можно сказать системе. Вот ты запускаешь OSPF, ты, пожалуйста, возьми себе просто какой-нибудь IP-шник, который у нас есть на устройстве, по какому-то критерию. Можно взять, например, самый маленький адрес или самый большой адрес, или самый большой адрес из тех интерфейсов,

которые у вас вообще есть, или из тех интерфейсов, которые у вас прямо сейчас запущены, или из тех интерфейсов, которые не физические, потому что, опять же, каждый раз, если у вас роутер ID будет назначаться произвольным образом, это может повлечь за собой увлекательный проблшотинг. Поэтому лучше будет, если у вас система будет работать сравнительно детерминированно, и каждый раз после каждого ребута она будет давать вам предсказуемый результат, какой именно роутер ID она возьмет. По стандарту сказано, что роутер ID может быть любым, но если администратор не назначил его ручками, то имеет смысл в качестве одного из способов назначения роутер ID использовать такой. Возьмите просто самый маленький IP-шник на железке. То есть если у вас есть роутер, на нем есть два интерфейса. С одной стороны у него есть 192.168.1.1, а с другой стороны у него есть 10.0.1. То в этом случае 10.0.1 будет меньше, чем 192.168.1.1. Мы помним, что IP-адрес — это тоже просто число. И, соответственно, число, соответствующее адресу 10.0.1,

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

она вам лупбек просто так не положит. Но вот если у вас есть несколько интерфейсов, которые не зависят от физики, то выбирается CISC-овскими маршрутизаторами самый большой адрес. Супротив рекомендаций по RFC выбрать самый маленький. Но рекомендация — это одно, а то, как поступает по факту железо, — это другое. Дальше. Вы можете разбить вашу физическую топологию на отдельные регионы, и внутри региона вы делаете все вычисления по-честному. Для чего эта штука нужна? Для того, чтобы избавиться от излишне большого количества вычислений. Раз. То есть если у вас в одной автономной системе, не знаю, 10 тысяч роутеров, гипотетически, то в этом случае количество вычислений, кто на кого как смотрит, будет очень большим и сложным. Собрать пазл из, не знаю, сотни элементов — это занятие на 5 минут. То есть вы берете просто, вы складываете. Собрать пазл из тысячи элементов — это занятие на несколько вечеров. Те, кто пазл складывает, меня поймут.

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

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

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

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

Есть механизмы, которые позволят в некоторых случаях сделать вид, что вы можете взять, соединить между собой два роутера, которые вроде бы не принадлежат к нулевому региону оба, и они все равно будут обмениваться маршрутами. Но это отдельная тема. Это там всякие виртуал-линки, шам-линки и прочее. Поэтому для того, чтобы сейчас не усложнять нам жизнь, мы про это говорить не будем. Ну, то есть звезда и звезда. Вот. Как уже было сказано, hello-пакеты у нас... Мне кажется, слайд уже был. Да? Был же, да? У нас hello-пакеты отправляются по мультикасту, как правило, 224.005. Для того, чтобы соседство установилось, информация, которая в этих самых пакетах содержится, должна либо совпасть, либо быть непротиворечивой. То есть, например, нельзя сделать так, чтобы у нас подружились два роутера с одинаковыми роутерами. Они не подружатся. То есть сосед просто не примет hello-пакеты от другого соседа, если роутер-одитом будут совпадать.

Должны совпадать номера регионов, должны совпадать флаги стабов, должны совпадать... Ну, или, по крайней мере, пройти процедуру аутентификации должны у соседей. Должны совпадать пароли, которые используются для шифрования и расшифрования. Ну и таймеры. Да. Каждый сосед у нас работает, отправляя и принимает нас пакеты. Мы знаем про соседей, когда они нам присылают hello-пакет. Если сосед не присылает нам hello-пакеты, мы про него, как правило, ничего не знаем. Но есть нюансы. В некоторых случаях, там, например, где у нас не бывает мультикаста, мы должны будем заранее, до того, как мы начинаем вести обмен с некоторым соседом данными, мы должны заранее знать его канальные адреса. А канальные адреса мы должны заранее знать из IP-адресов. А для того, чтобы указать, соответственно, IP-адрес соседа, мы его должны где-то прописать. И в некоторых случаях мы соседей в OSPF прописываем до того, как мы с ними начинаем вести взаимоотношения. То есть у нас есть роутер, он смотрит каким-то интерфейсом на некоторую среду,

в которой у нас есть связь с другим роутером. У нас в этой среде нет мультикаста, нет браткаста. То есть мы должны отправлять пакеты с явным указанием того, кому мы это отправляем. Ну, например, во Framework Lite такая штука есть. В этой ситуации у нас сосед, который известен, что у нас есть вот некий сосед, он прописан, но у нас вообще нет возможности с ним вести какие-то взаимоотношения. В этом случае он будет находиться у нас в табличке соседей с указанием «это сосед даун». Не в том смысле, что у него синдром дауна, а в том смысле, что у нас нет возможности даже пытаться отправить ему hello-пакеты. Если у нас появляется возможность отправить ему hello-пакеты, и мы начинаем это делать, то мы указываем, что сосед у нас будет находиться в состоянии attempt. То есть мы отправляем ему hello-пакеты, hello-пакетов от него мы пока никаких не видели. Если сосед отправляет hello-пакеты нам, то этот сосед может быть либо в состоянии init, это значит, что он hello-пакет посылает,

но при этом в списке соседей, которые в hello-пакете указываются, нет указания нас как соседа. Все hello-пакеты, которые мы будем отправлять в канал, они будут содержать список роутер-ид тех роутеров, с которыми установлены в этом канале соседские взаимоотношения. То есть если у нас в этом канале есть уже соседские взаимоотношения с роутерами, там вот наш роутер первый, второй, третий, четвертый. Вот если мы уже подружились со вторым и третьим роутером, хотим подружиться с четвертым, мы указываем, мы hello-пакет отправляем, мы указываем, что второй и третий у нас уже полноценные соседские взаимоотношения есть. С четвертым мы только собираемся подружиться, мы ему отправляем hello-пакет и говорим, давай дружить. Но мы при этом все равно указываем соседство. Далее. Attempt — это мы посылаем hello-пакеты ему. Init — это он посылает hello-пакеты, например, нам или, например, непонятно кому, используя Multicast 224.005, но при этом в init он нас не указывает как соседа, он не видит нас пока еще.

Если мы ему отправили hello-пакет, он нас увидел, и он отправляет сообщение, что он нас видит в качестве соседа, то в этом случае мы, получая такие сообщения, переводим соседа в фазу to way. То есть это вот эти вот все штуки, attempt, down, init, to way и вот эти вот тоже, это все как бы пометочки напротив каждого соседа в списке соседей, типа в каком состоянии этот сосед, что с ним вообще происходит, в какой фазе этот сосед находится. При этом два роутера, которые друг на друга смотрят, они совершенно не обязаны друг друга в списке соседей воспринимать адекватно, одновременно в одной и той же фазе. Например, если у вас есть два роутера, которые друг на друга смотрят, один другому hello-пакет посылает, ну не другому, а просто Multicast-овый пакет, у него в списке соседей пока пусто. А другой роутер принимает пакет от соседа hello, говорит, ой, я его вижу, он не противоречен настроен, заносит себе в список соседей указания, что вот у нас есть некий Вася. Вася присылает нам hello-пакеты без указания нас как соседа, значит, Вася будет в init.

На левом роутере пусто в списке соседей, на правом роутере есть один сосед в состоянии init. Отправляется встречное сообщение, я вижу Васю. Соответственно, как только этот пакет приходит на левый роутер, он понимает, значит, что сосед есть, и сосед нас видит. Он заносит нового соседа в список соседей, и соседу сразу прописывает состояние two-way. После того, как роутеры перевели друг друга в two-way, то есть проверили двустороннюю связность, да, кстати, как только мы получили первый hello-пакет, соответственно, мы получили в ответ от него указание «Я тебя вижу», мы в следующих hello-сообщениях отправляем сообщение «Я тебя тоже вижу». То есть как только мы занесли соседа в список соседей, в two-way или не в two-way, мы отправляем hello-пакеты на этом интерфейсе с указанием роутера ID этого соседа. И сосед тоже переносит нас в two-way. Когда в two-way мы перенесли соседа, мы тем самым убедились, что у соседа с нами есть двусторонняя связность, мы это проверили. Естественно, отправляя сообщение соседу с указанием

«Я тебя вижу», мы тем самым даем ему возможность указать, что он нас тоже видит с двусторонней связностью. Когда мы переводим соседа в two-way, дальше принимается решение, следует ли переходить в фазу обмена hello-sake. Не любые роутеры должны между собой будут hello-sake обмениваться. Если два роутера принимают, что они находятся в состоянии two-way, они могут остаться в этой фазе, они не могут не переходить дальше. То есть они говорят, нам и так хорошо. Но вот в two-way замечательно, и мы не переходим в следующую фазу x-start. Но если вы вдруг понимаете, что вам нужно будет вести взаимоотношения полноценные, то вы переходите в фазу x-start, после чего очень быстро переходите в фазу exchange, после чего очень быстро переходите в фазу loading. Фаза loading может быть достаточно длительной. Ну и после того, как фаза loading закончится, вы переходите в фазу full. X-start — это промежуточное согласование некоторых параметров, необходимых для обмена содержимым вашей LSDB. Exchange — это передача оглавления LSDB.

Loading — это передача самого мяса, самих LSDB. И full — это значит, что у вас все предыдущие три фазы закончились, вы от соседа больше ничего не хотите. Может быть такое, что у вас есть два соседа, которые друг на друга смотрят, один и второй, и, соответственно, один с другого все, что хотел, уже утянул, и напротив соседа поставил в списке соседей состояние full, а другой с первого все еще пока тянет. И, соответственно, у другого первый сосед висит в фазе loading. Ну, рано или поздно должен завершить эту фазу, перейти в full тоже. Поэтому то, что с одной стороны сосед видит другого в одной фазе, не следует, что с другой стороны первый тоже должен быть виден в той же самой фазе. Фазы на соседних роутерах — это просто пометочки в таблице соседей, чего с этим соседом прямо сейчас делаем. То есть что от него стоит ожидать, что от него не стоит ожидать. Дальше. После того, как мы перешли в two-way, то есть мы вот здесь вот находимся, дальше принимаем решение, стоит переходить в X-start или не стоит.

В X-start идет обмен стартовыми параметрами, обмена маршрута, обмена LSA. Один роутер посылает другому пакет, который называется database description, и второй в этот момент тоже посылает первому, тоже пакет, тоже, соответственно, database description. Они друг другу отправляют по одному пакету, дбд, и каждый говорит, я сейчас буду начинать передачу, приготовься. Но они одновременно друг другу не могут начинать передачу, потому что SPF — протокол достаточно старый, который создавался в тех случаях, когда у нас в одном канале могло быть много участников, и в этом канале могли быть коллизии. Для того, чтобы коллизии избегать, они, да, друг другу отправляют маленькие пакетики, вот эти дбдшки, они практически пустые, то есть они крошечные по размеру. Но дальше они согласуют возможность отправки крупных пакетов, database description с большим содержимым, и тем более крупных пакетов, которые будут нести в себе мясо LSA. Поэтому, да, они друг другу кинули по одному маленькому пакету, но они в этом маленьком пакете должны быть принять решение, кто начинает первый интенсивно занимать среду, чтобы второй в этот момент помолчал.

И в этих самых дбд-пакетах, первых самых, они говорят, я сейчас буду мастером, я сейчас буду начинать передачу первой. И второй говорит то же самое, я тоже буду начинать передачу первой. Но они не могут одновременно начинать оба передачи первым, поэтому первый отправляет ДБДшку, второй отправляет ДБДшку в ответ, но дальше кто-то из них должен сдаться. Ну, например, второй сдается, он тоже посылает ДБДшку, но с указанием «Окей, убедил, ты будешь первым, а я первым, соответственно, не буду». Там есть флажок «Кто будет мастером?». И вот согласование одного из параметров «Кто будет мастером?» — это важная задача в X-Start. Кроме того, X-Start проверяет корректность настройки канала. Для того, чтобы в фазе X-Start… Здесь неправильно написано Exchange, должна быть вот эта фаза Exchange. В фазе Exchange большие пакеты проходили нормально, и в фазе Loading тоже проходили большие пакеты нормально. Эти пакеты будут отправляться максимально возможного размера. И если у вас, например, некорректно настроена IP MTU, то есть на роутере R1 настроен MTU 1500, а на роутере R2 настроен MTU, скажем, не знаю, 576.

Допустимый MTU, который в IP как бы штатно предусмотрен, так как обязательно поддерживаем их всеми. В этом случае роутер R1 будет отправлять большие пакеты, а роутер R2 их принять не сможет. OSPF создавался тогда, когда 1500 MTU не был нормой. То есть нормой была обязательная поддержка 576 байт на MTU, а все остальное было как бы опционально. Но для того, чтобы обойти эту проблему, разные протоколы ведут себя по-разному. Например, RIP, он говорит, а я никогда не буду отправлять пакеты больше, чем 576 байт. Я более того, буду отправлять всегда пакеты меньше, чем 500 байт, чтобы они заведомо пролезли в это самое ограничение 576. А OSPF, он говорит, мы во всех отношениях должны быть лучше, чем RIP, поэтому мы отправляем MTU в пакетах Database Description. Сами пакетики маленькие, но в них указывается, как настроен наш интерфейс. Если MTU не совпадает, у вас один из соседей не перейдет в следующую фазу Exchange. Здесь неправильно написано Exchange.

Не перейдет тот, у которого прописан MTU меньше. То есть сосед с DBD, отправляющим MTU 1500, будет отправлять такой пакет на соседа, у которого прописан MTU 576, и такой DBD просто выкинется. Соответственно, сосед R2 будет считать себя единственным и неповторимым мастером, у которого нету слейва. Включение MTU Ignore. Вы можете заставить OSPF обойти это ограничение. То есть бывают реализации, которые вам позволяют сказать «Игнорируй не совпадение MTU». Естественно, это плохо. Естественно, у вас в канале, в котором два роутера друг на друга смотрят, в любом случае MTU должны быть одинаковые. Это естественно, что у вас так должно быть. Поэтому лучше будет решить сначала проблемы с MTU, если у вас есть несовпадение MTU, а потом уже думать, стоит ли отключать защитные механизмы, которые в OSPF и есть. В противном случае они у вас подружатся, они вам скажут «Окей, давайте переходим в следующую фазу, в Exchange», и друг к другу будут насовывать пакеты слишком большого размера,

которые сосед не сожрет. Зачем заставлять роутеры отправлять друг к другу пакеты, которые по сети пройдут, канал зажмут, но, соответственно, они не вызовут каких-то дальнейших действий. Поэтому лучше сразу просто на этапе «Кстарт» спотнуться. Тем более, что если у вас есть проблема с несовпадением MTU, то это очень характерная проблема, потому что вы на R1 смотрите и говорите «Покажи соседей, show IP интерфейс, show IP OSPF Neighbors». Он говорит «У нас есть сосед R2, который висит в фазе Exchange». На R2 мы смотрим, говорим «Покажи соседей». Он говорит «У нас есть один сосед R1, который висит в состоянии X-start». Ну, X-start. Вот. И у нас вот это вот состояние длится довольно долго. То есть мы заходим на один роутер, у него сосед в Exchange, заходим на другой роутер, у него сосед в старте. Ну, прям замечательный пример того, как troubleshoot эти проблемы с SPF. Это классическая проблема. Если вы видите, что у вас два соседа, один завис в X-start, другой в Exchange, несовпадением MTU гарантированное. После чего у нас роутеры отправили друг другу,

либо, может быть, так получилось, что один DBD-шку отправил с флагом мастера, а второй сразу говорит «Окей, я сдаюсь, я буду своим слейвом». Очень неполиткорректная терминология, как вы знаете. Очень фу-фу-фу так делать, но, тем не менее, вот термины такие, какие есть. Либо, может быть, такое, что оба отправят DBD-шки с флагом мастер, и потом один скажет «Окей, я сдаюсь, я буду твоим подчиненным». После чего роутеры переходят в фазу Exchange. Это не просто переходят, они переводят соседа в фазу Exchange, и дальше начинают отправлять ему список всех LSA, которые есть у этого роутера. Но список только оглавления, не само содержимое этих LSA. Фактически оглавление идет, заголовки LSA посылаются, а сами LSA не посылаются. Вы отправляете DBD-шку, какие LSA есть у вас. Если все это дело укладывается в одном пакете, то вы отправляете один пакет и говорите, я тебе отправляю пакет с оглавлением своих LSA, и у меня больше ничего нет. То есть там есть два флага, флаг «Мастер», я говорю, что я мастер,

и флаг «Есть еще». Я забыл, как флаги называются, я прошу прощения. Ну, типа да, условно, флаг «Мастер», я говорю, что я мастер, и флаг «Еще», флаг «Море» — это тоже там ноль, что у нас больше ничего нет. Сосед отвечает своей DBD-шкой и говорит, окей, я тебе тоже посылаю что-то в ответ. DBD-шки устроены таким образом, что они не требуют подтверждения, они сами друг друга подтверждают. DBD-шку можно отправить только в ответ на соседнюю DBD-шку. То есть вы на мастер отправляете DBD-шку соседу, сосед отправляет DBD-шку в ответ вам. Он может вам отправить DBD-шку только в ответ. Поэтому иногда в литературе пишут, что там DBD-шки нужно подтверждать LSA-ками. Ничего подобного, DBD-шки лосаками не подтверждаются, DBD-шки подтверждают сами себя. Мы отправили одну DBD-шку и ждем в ответ одну DBD-шку. Мы в ответ на ту DBD-шку отправим свою одну DBD-шку и в ответ на нее получаем одну DBD-шку.

То есть они вот так вот друг к другу перекидывают фактически один и тот же пакет. Отправляем указание, что мы считаем себя мастером, и мы, соответственно, больше ничего не хотим сказать. Сосед говорит, окей, я тебя считаю мастером, я отправляю указание, что я буду слэйвом, там, допустим, M01, первый, и, соответственно, что у меня тоже, допустим, ничего нет. В этом случае сосед отправил указание «я больше ничего не хочу отправить», получил указание «я больше ничего не хочу отправить» и переходит дальше в фазу лоидинг. Если вы отправились по указанию, что у вас больше ничего нет, а сосед вам отправляет сообщение «а у меня есть кое-что еще», вы должны будете ему отправить еще одну пустую DBD-шку. Вы отправляете DBD-шку натурально пустую с указанием «я мастер», но у меня по-прежнему больше ничего нет, чтобы тебе рассказать. но я тебе вынужден отправить ДБДшку, потому что ты только в ответ на нее можешь рассказать мне то, чего у меня пока не хватает. И, соответственно, вот рано или поздно дойдет все это дело до того, что оба роутера друг другу отправят ДБДшки с указанием «Все, больше ничего нет». Дальше они переходят в фазу лоудинг.

Фаза лоудинг означает, что оба роутера знают, какие ЛСА-ки есть у соседей, с какими ID-шниками, с какими Advertising Reuters, с какими типами и какими номерами версии. И эти ЛСА-ки можно заказать. То есть вы отправляете сообщение. «Я знаю, что у тебя есть ЛСА-ка с определенными характеристиками, с определенным заголовком. Вот я тебе показываю заголовок, который ты мне только что показал. Дай-ка мне ее мясо». Это идет в пакетах LS-request, linkstate-request. И, соответственно, в ответ на нее приходит пакет LS-update, содержащий заказанные ЛСА-ки. В одном ЛСР, в одном ЛСУ может быть много ЛСА-ек. Но, естественно, что ЛСР может быть довольно большой. И может быть такое, что он идет почти максимального размера. То есть вы полтора килобайта кидаете и говорите, дает мне ЛСА-ку такую, такую, такую, такую, такую. Ответ будет, естественно, более рыхлый. Потому что само мясо ЛСА-ек, оно, естественно, более объемное по сравнению с заголовками, которые передаются в ЛСР. Поэтому в ответ на один linkstate-request у вас может идти пакет linkstate-update не один, а много. И вот после того, как заказанные заголовки все отправлены в ответ

вместе с содержимым, эти ЛСА-ки надо будет подтвердить. ЛСА-ки подтверждаются путем отправки любого пакета, содержащего эти самые заголовки, либо linkstate-acknowledge. Это вы указываете, что ты мне только что отправил пакет ЛСУ-шки, или один, или несколько, содержащий определенные мясо ЛСА-ек. Я тебе подтверждаю это получение путем отправки ответа с заголовками этих ЛСА-ек, с указанием версий и всего остального. На самом деле, не обязательно ЛСУ-шки подтверждать acknowledgedby, то есть вы можете ЛСУ-шку подтвердить и другой ЛСУ-шкой тоже. Если вдруг вы захотите сами отправить ЛСУ-шку в ответ на ЛСУ-шку, пожалуйста, никаких проблем. Просто вы передаете фактически то же самое плюс мясо. То есть ЛСА-к — это только заголовки, ЛСУ — это заголовки плюс мясо. Хотите отправить в ответ заголовки — пожалуйста, хотите отправить в ответ заголовки и мясо, пожалуйста, никто вас от этого не отговаривает. Просто вы лишний раз займете среду. ЛСА-к — это способ доказать, что у вас определенные LSA в базе тоже есть.

Почему я сейчас говорю, что можно LSU-шки подтверждать не только LS-acknowledge-ами? Потому что после того, как мы закончили передачу всех LSA, которые есть в базе у соседа, мы усосали с него все, что хотели. Мы отправили ему link state request и получили все LSU-шки, отправили все соответствующие LSU-шки. Соседа мы переводим в фазу full. И дальше в этой фазе идет нормальная цивилизованная работа. Но может быть такое, что у соседа в какой-то момент времени просыпается желание рассказать нам, как устроена сеть. У него известны какие-то изменения. Он нам рассылает LSA, а мы в этот момент сами только что узнали, откуда-то еще, как устроена сеть. И тоже соседу хотим рассказать, как устроена сеть, отправить ему какую-то новую LSA, которую у него еще нет. И получается, что два роутера друг к другу могут одновременно отправить указания. У нас в сети произошло какое-то изменение. То есть, например, вот в такой вот ситуации, когда они только что получили эти изменения от кого-то третьего. И, соответственно, здесь у нас получается коллизия. То есть, один другому рассказывает «смотри, как сеть устроена»,

и другой первому рассказывает «смотри, как сеть устроена». И в этом случае не требуется отдельно подтверждать получение такой же LSA, которую соседу только что отправили. Если вы ему отправили LSA, и сосед вам только что отправил LSA, эти LSA одинаковые, точнее сказать, они содержат одинаковые LSA. Точнее сказать, что вы посмотрели, что каждую из LSA, которые вы отправили, содержится в ответной LSA, которую сосед прислал вам. В этом случае нет необходимости это дополнительно еще раз подтверждать. Сосед уже все знает. Поэтому, если вы отправили LSA живую, настоящую, мясную, в LSA, у нее есть заголовок. Этот заголовок точно так же подтверждает получение пакета, содержащего определенные LSA от соседа. Вот. LSA бывают многих разных типов. Классический набор LSA будет следующий. Те, которые проходят на CCNA, это LSA первых трех типов. Первый, второй, третий — роутер, нетворк, саммари. Четвертый, пятый и седьмой используют при редистрибуции.

Мы с вами про это отдельно поговорим. Девятый, десятый и одиннадцатый позволяют в OSPF запихать что-нибудь еще. Экзотическое. То есть вы, например, в OSPF можете указать, что линки, которыми роутеры соединены, они не просто соединены с такой-то стоимостью, они еще и, например, имеют определенную загрузку. То есть прямо сейчас загрузка этих интерфейсов может быть вплоть до определенной. Эта штука активно используется в MPLS Traffic Engineering, например. То есть вы можете вот эти вот самые APAC-ULSA, то есть дополнительные какие-то параметры работы роутеров, доложить в OSPF для того, чтобы OSPF мог передать еще какую-то хитрую дополнительную информацию. Девятый, десятый и одиннадцатый LSA имеют разные зоны видимости. Девятый LSA имеет зону видимости Link, десятка Area и одиннадцать Autonomous System. Далее. Как видно, здесь не хватает шестого и восьмого типов.

Шестой и восьмой не поддерживаются практически никем в современном мире. Все это жуткая экзотика. Шестерка используется для мультикастового OSPF. Восьмерка просто зарезервирована, и ее никто никогда в здравом уме не реализовал вообще. Про мультикасты OSPF даже сами авторы стандарта в RFC написали, что протокол как бы сугубо экспериментальный, не предполагается, что его кто-то в реальности будет использовать, и те полторы коллеги, которые им все-таки используют, если вдруг им что-то не нравится, они могут пойти в лес самостоятельно, не дожидаясь приглашения со стороны авторов протокола. То есть Cisco никогда его не реализовывала, другие вендоры тоже никогда его не реализовывали, поэтому что шестой, что восьмой тип в реальности вы не можете встретить вообще. ЛСА-ки в OSPF, значит, самая первая ЛСА-ка, которая у нас в курсе есть, самая первая, самая простая и самая, наверное, очевидная,

то раньше все и придумалось. Это та самая ЛСА-ка, которую роутеры выпускают, рассказывают про то, что их кое-что окружает. Вокруг них есть другие роутеры, вокруг них есть какие-то подключенные сети. Вот это вот как раз в ЛСА-ках и указывается. У каждой ЛСА-ки есть некие параметры. Есть, во-первых, в каком регионе она выпущена, есть, какого типа она будет, есть указание, кто ее придумал, Advertised Router ID, и есть указание LSID, то есть ID-шник, про который идет рассказ. ID-шник, скажем, самой ЛСА-ки. В случае, если мы делаем ЛСА-ки первого типа в OSPF версии 2, то роутер, который рассказывает сам про себя, он рассказывает, что вот он, его ID-шник, допустим, роутер 1, то есть 1, 1, 1, 1, вот он рассказывает сам про себя. То есть предмет, про который идет рассказ, это LSID, это вот в нашем случае ID 1, 1, 1, 1.

Роутер ID, который придумал эту ЛСА-ку, Advertising Router ID, это у нас тоже роутер говорит, я сам про себя придумал эту ЛСА-ку, он сам себя указывает в качестве Advertising Router. И внутри этой ЛСА-ки, если у нас вот такая топология 1 и 2, указывается, что роутер 1 видит роутер R2, то есть он говорит, я вижу R2 на таком-то расстоянии, ну, указывает себя в качестве Neighbor, в смысле, указывает R2 в качестве Neighbor, указывает его роутер ID. Здесь нигде не фигурируют никакие IP-адреса, если вы посмотрите. То есть по-хорошему здесь указан именно роутер ID. Далее. Вы можете, если захотите, в принципе здесь указать IP-шник соседа. То есть гипотетически никто вам не мешает это сделать. Далее. Вы выпустите ЛСА-ку, и этот ЛСА-ка будет как кусочек пазла. Ну, для того, чтобы собрать полную картину, нам нужно найти недостающие кусочки пазла, которые в этот кусочек пазла вщелкнутся.

И, соответственно, вы находите ту ЛСА-ку, говорите, вот мы смотрим на роутер R2, соответственно, роутер R2, находим его ЛСА-ку, подтвердаем, что он нас видит, что мы у него в списке ноябров есть. То есть мы находим такую же ЛСА-ку первого типа и говорим, вот мы нашли связь между роутерами R1 и R2. Связь вот такая вот будет иметь тип point-to-point. То есть если мы нашли ЛСА-ку, которая смотрит на одну ЛСА-ку соседа, а другая ЛСА-ка соседа смотрит на нас, то это соседство point-to-point типа, когда в одном канале, который связывает роутеры, может быть только вот два роутера, больше ничего. Кроме того, вы можете рассказывать про то, что у вас есть какие-то подключенные сети, например, 10, 0, 0, 0 по 24-й маске. Ну, в этом случае вы в этой же ЛСА-ке будете указывать, что есть сетка 10, 0, 0, 0. Она доступна там через интерфейс, который стоит 5 копеек. То есть вы напротив каждого соседа указываете стоимость, как вы его видите. Допустим, здесь у нас 10 копеек. И вы напротив каждой подключенной сети указываете, сколько стоит добраться до сети.

То есть вы в нее смотрите интерфейс, и в этой интерфейсе все равно есть какая-то стоимость. После того, как Р2 получает такую ЛСА-ку, дальше здесь, возможно, есть какой-то еще роутер, какой-то еще роутер. Но в любом случае, каждый из них выпускает свою ЛСА-ку первого типа и указывает, с какими соседями он подружился, какие сети к нему подключены. Только роутер R1 заявил про существование сети 10, 0, 0, 0. То есть R2 про эту сеть ничего не говорил, R3 про эту сеть ничего не говорил, R4, там, который следующий в цепочке, тоже про эту сеть ничего не говорил. В таком раскладе есть небольшая проблема. То есть когда у нас есть роутеры, которые друг на друга смотрят прямыми интерфейсами, все хорошо. Но бывают и экзотические сценарии. Например, OSPF создавался тогда, когда у вас в одном канале, например, коаксиальном, могло быть 5 роутеров. То есть все 5 роутеров подключены в один провод. И они, если будут связываться между собой по схеме каждый с каждым, то будет проблема. Проблема будет то, что у нас слишком много соседств будет. Потому что первый роутер должен смотреть на второй, подружиться с ним, на третий, подружиться с ним.

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

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

или если вы не хотите работать с технологиями сорокалетней давности, все шесть роутеров могут быть подключены к свечу, и в этом свече у нас сетка 10.000 по восьмой маске. Вот. То есть у нас раз провод в свече, два провод в свече, три провод в свече и так далее. То есть все в одном вилане находятся, все в одном широкощательном домене. Вот у нас DR выпускает LSA-ку за вот, если хотите, за этот свеч. И, соответственно, каждый из роутеров говорит, я не вижу пятерых или там шестерых, сколько там у него есть соседей. Я вижу свеч. У каждого соседа прописывается нейбором LSA-ка второго типа. То есть роутер R1 говорит, я вижу свеч. Роутер R2 говорит, я вижу свеч. Роутер R3 говорит, я вижу свеч. И каждый из них заявляет одно соседство. А вот это вот LSA-ка второго типа, в ней указывается, что да, действительно, ответные части этих соседств приходят на, если хотите, на свеч. То есть у нас в LSA-ике второго типа прописываются шесть соседств. Если вдруг у нас в сети происходят какие-то изменения. Например,

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

и в этот свеч не будет воткнута через полчаса еще 4, 10, 50, 100 миллионов роутеров. Она говорит, я вижу Ethernet, в этом Ethernet гипотетически возможно наличие свеча, и ни одного между нами. Поэтому в эти свечи могут быть воткнуты другие роутеры потом. Поэтому даже если мы сейчас подключили два роутера друг на друга, мы все равно выпустили лосейку за вот этот вот возможный свеч, за широкомещательный домен, в который мы находимся. Для того, чтобы потом какие-то роутеры, которые будут подключаться, могли бы испытывать преимущество при сборке пазла. И мы бы тоже испытывали преимущество при сборке пазла потом когда-нибудь. Но если вы используете по умолчанию настройки в SPF, то имейте в виду, что даже если вы два роутера соединили патчкордом, лосейка второго типа там все равно будет. И естественно, что в ситуации, если бы вы сказали, что этот линк имеет природу point-to-point, у вас бы сборка пазла была бы простой. Вы бы сказали, лосейка первого типа, лосейка первого типа, и они друг на друга смотрят. Все, больше ничего бы не было.

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

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

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

а вот между регионами нам нужно будет тоже каким-то образом маршруту передавать. Важное замечание. Изменения в топологии, которые вызывают пересчет маршрутов вычислительно сложный, это только лосейки первого и второго типа. То есть лосейки всех остальных типов не вызывают смену топологии. Не нагружают роутеры по большому счету. То есть все остальные лосейки, они могут появляться, исчезать из базы. Роутеры сравнительно легко переживают. А вот лосейки первого и второго типа и любые изменения в них, любые пропадания или добавления лосейки первого и второго типов это всегда смена топологии. лсееко 3 типа нужно будет для того чтобы рассказать что происходит за пределами нашего региона например у нас есть роутер r1 у него есть некая сетка тоже на интерфейсе которая смотрит нулевой регион и роутер 1 рассказывает у меня есть вот я я выпускаю лсаеко первого типа у меня есть интерфейс смотрящий в сетку там 10 0 0 0 сеть у меня есть интерфейс который смотрит на роутере r2 р2 говорит Я тоже выпускаю LSA-ку первого типа, рассказываю, что я вижу роутер R1,

но все это происходит внутри нулевого региона. Внутри нулевого региона R2 может посчитать, как добраться кратчайшим способом до сетки A. Но R3, который находится за пределами нулевого региона, не может узнать, что существует такая сеть, тем более не может посчитать до нее кратчайший маршрут, потому что он не видит в LSDB нулевого региона. Для того, чтобы узнать, что происходит за пределами своего региона роутер R3, нужно как-то помочь, подсказать. Роутеры, которые находятся на границах между регионами, будут называться специальным словом АБР, они будут рассказывать про то, какие сети есть у них за спиной. Такая LSA-ка называется Summary LSA, и название у нее вполне говорящее. Иногда думают, что это обязательно про суммирование, про агрегацию сетей, не, ничего подобного. Summary LSA указывает, что за спиной у АБРа есть некая сетка, доступная за суммарное расстояние такой, суммарная стоимость ее указывается. Summary LSA здесь, Summary не про IP-шники, а Summary про стоимость интерфейсов. То есть в нашем случае роутер R1 заявил, что сетка А доступна за 5 копеек,

R2 видит R1 за 10 копеек прямым проводом, R2 посчитал, сколько стоит добраться до сетки А, сказал, я по-честному посчитал, вот добраться до сетки А стоит 15 копеек. Внутри региона у него есть свой маршрут, но за пределами региона он говорит, я роутер R2, знаю, как добраться до сети А, и указывается здесь стоимость 15 копеек. У этой LSA-ки третьего типа есть тот, кто ее придумал, роутер ID. Это роутер ID АБРа. R3, будучи в одном регионе с АБРом, он считает кратчайший маршрут, как можно добраться до АБРа, до любого другого роутера в пределах своего канала, равен как и до АБРа. Вот он до АБРа взял, посчитал, что стоит добраться 10 копеечек. Он видит LSA-ку, что за спиной у АБРа есть сетка за 15 копеечек, говорит, кратчайший способ добраться до АБРа стоит 10 копеек. В итоге добраться до сети А на моем роутере стоит 25 копеек. Если вдруг у вас есть, например, топология какая-то вот такая вот,

у нас есть АРЯ-1, АРЯ-А-1, здесь у нас АРЯ-0, АРЯ-0, здесь у нас снова АРЯ-1. И, соответственно, у нас здесь вот АБР, здесь вот АБР, здесь провод, здесь роутер, и сетка какая-то, и здесь тоже какой-то роутер. Вот у нас сеть А зародилась в регионе номер 1, дальше перекладывается в регион номер 0, то есть вот тут вот порождается LSA-ка первого типа, здесь порождается LSA-ка первого и третьего типа. И дальше вот этот вот роутер по точно той же схеме, что здесь я показал, просчитывает кратчайший способ добраться до сети А. Но поскольку он тоже является АБРом, то он перекладывает маршруты, зародившиеся в нуле, в ненулевой регион. И он тоже говорит, что я знаю, как добраться до некоторой сетки. LSA-ка, которая распространяется в нулевом регионе, LSA-ка третьего типа, и LSA-ка, которая распространяется третьего типа в первом регионе, это разные LSA-ки.

То есть здесь у нас LSA-3 уйдет, допустим, со стоимостью 15 копеек, и придумал ее роутер, ну вот здесь какая-то у нас там R2. А вот тут вот будет распространяться LSA-ка третьего типа, она в другом регионе, в Are1. У нее стоимость будет там, например, 25 копеек, и придумает ее роутер R3. То есть это разные LSA-ки в разных регионах. Роутер, который находится в первом регионе, LSA-ку вот эту вот не видит. Область распространения ЛСЭКи третьего типа — это тоже регион, так же, как ЛСЭКи первого-второго типа. В многих книгах, в мультиках, различных курсах рассказывают про то, что ЛСЭКи третьего типа перелетают через АБРы и рассылаются дальше. Котинку такую рисуют, что здесь у нас один регион есть, маршрут перекладывается из одного региона в другой, порождается ЛСЭКи третьего типа, и вот эта ЛСЭКи третьего типа разбегается по всей сети. Нет, ничего подобного. ЛСЭКи третьего типа живет только в своем регионе. Если надо маршрут, полученный из ЛСЭКи третьего типа в нулевом регионе,

рассказать про него в каком-то другом неналевом регионе, порождается новая ЛСЭКа, не похожая на предыдущую. Да, у нее будет такой же предмет разговора, да, у нее будет такой же IP-адрес сети, но все остальное у нее будет другое. У нее будет другой ЛСАД, ЛСАД в WSBF второй версии такой же был, ладно. У нее будет другой роутер-айди, advertising роутер-айди, у нее будет другая стоимость, у нее будут другие флаги. Поэтому это разные ЛСЭКи. На каждый маршрут, который будет просчитан с помощью таких ЛСЭК третьего типа, добавляется отдельный... Продон. На каждый маршрут, который на АБРе перекладывается между сетями, будет генериться отдельный ЛСЭКа третьего типа. То есть в одной ЛСЭКе третьего типа указывается одна сеть. вы можете при перекладывании информации между регионами контролировать то, какие маршруты вы перекладываете. То есть АБР может немножко наврать, может какие-то сети скрыть. То есть раз мы не хотим, допустим, показывать некоторую сетку из одного региона в другой,

мы можем сказать, окей, не надо показывать какие-то определенные сети, пусть они останутся только в своем регионе. У нас вот здесь зародилась какая-то сеть. Какая она может быть? Не знаю. Сеть 8.8.8.8 по 32 маске. Вот мы захотели, вот в этом регионе мы эту сеть зародили. Но мы не хотим, чтобы во все остальные сети этот маршрут уходил, во все остальные регионы. Вот мы можем сказать, АБР не перекладывает такую сеть в другой регион. И он на уровне маршрута будет фильтровать перекладывание данных из одного региона в другой. Внутри региона вы не можете скрыть, что у вас какой-то роутер знает определенную сетку. То есть внутри региона все роутеры ЛСДБ имеют одинаковую. Если какой-то роутер кому-нибудь в пределах региона спалил, что маршрут имеется, маршрут подключенный, в который смотрим напрямую интерфейсом, то все роутеры в этом регионе все знают. Если хотя бы один АБР спалил, что сетка существует, значит все остальные роутеры в виде ЛСЭК-трешки эту сетку получат. В ЛСДБ у всех все будет одинаково.

Вот. Можно будет выполнить агрегацию, можно будет выполнить фильтрацию. То есть можно, например, сказать, что если у нас сети в каком-то регионе 10.0.1.0.24, 2.0.24, 3.0.24 и так далее. Вот мы можем взять и сказать, давайте мы перекладываем все это дело из одного региона в другую, но мы не делаем отдельную ЛСЭКу на вот такую сеть, на такую сеть, на такую сеть. Мы вместо этого сделаем одну большую ЛСЭКу третьего типа за сетку 10.0.0.0. slash 16. То есть вот вы тем самым не рассказали про какие-то отдельные мелкие сетки, но вы вместо этого сделали одну большую крупную. АБР может наврать. Может рассказать про то, чего у него по факту нету, как, например, в случае с агрегацией. Может рассказать, может не рассказать про то, чего у него в таблице есть, как, например, опять же, в случае с агрегацией он не рассказывает про какие-то вот эти вот мелкие сетки. То есть при перекладывании маршрутов между регионами OSPF действует в дистанц-векторном стиле. Он оперирует маршрутами, а не кусками топологии.

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

много-много-много маршрутов. И вот мы в этом случае говорим, некоторые маршруты следует рассказать про них соседям по OSPF. В этом случае вы будете называться роутером Autonomous System Boundary Router, ASBR, и вы будете рассказывать про то, что некоторые сети есть у вас в таблице маршрутизации. По каждой сетке вы порождаете отдельную лосейку пятого типа, вы указываете в качестве автора этой лосейки самого себя свой роутер ID, и вы указываете некую стартовую стоимость, что у нас есть определенные маршруты, которые мы породили. Есть эти самые лосейки двух разных типов. То есть стоимость, которую вы в ЛСЕЕ указали, она может быть либо сравнимой с той стоимостью, которой посчитают роутеры до вас, либо несравнимой. Я люблю приводить пример, что когда роутер ASBR рассказывает про то, что он знает какие-то сети, он должен указать стоимость, но эта стоимость может быть разной.

Иногда можно сказать, я отправляю маршрут, и этот маршрут стоит 10 копеек. Иногда можно сказать, а я отправляю этот маршрут, и он стоит 100 баксов. И вот в этом случае вы знаете, что все роутеры, которые находятся в одной топологии с вами, они будут считать маршрут в копеек, они получат маршрут стоимостью 10 копеек, 15 копеек, 100 копеек. И тут вы приходите и говорите, я готов вам продать этот маршрут за 100 баксов. А в этом случае понятно, что копейки уже никакую роль не играют. Играют роль только вот та стоимость, которую вы заявляете. А то, что какие-то маршруты где-то там с копейками, тем возиться вообще никому не интересно. То есть стоимость, которую заявляют роутер ASBR, в любом случае принципиально более важная, чем внутренняя транспортная стоимость SPF. Либо вы можете сказать, ребята, такой же, как вы, я продаю вам маршруты по честной стоимости, я вам тоже за те же самые копейки продаю. Вот у меня есть маршрут, он стоит 15 копеек. То есть в случае, если вы заявляете LSA-ку пятерку первого типа, это не то же самое, что LSA первого типа, это LSA-ка пятерка первого типа, то вы указываете стоимость, сравнимую с транспортной стоимостью SPF.

Если вы указываете, что у вас стоимость принципиально отличается, то эта стоимость будет важнее, будет приоритетнее по сравнению с любой другой стоимостью, посчитанную в SPF по-честному. Также в LSA-ке пятерки может указываться некая сущность, которая называется forwarding address. Эта штука более интересна в предприятиях, но тем не менее знать про нее тоже надо. Вы можете сказать, что вот вы, роутер ASBR, рассказываете про то, что некоторая сеть существует, но вы можете в LSA-ке указать forwarding address и дальше указать какой-то IP-шник. 10, 0, 0, 1. Эта логика будет такая, что если вдруг рядышком с вами где-то есть другой роутер, и вы знаете, что надо трафик на самом деле через другой роутер пропустить, и вы знаете, что у всех роутеров в SPF этот IP-шник есть, просто этот самый другой роутер почему-то в SPF не может вбросить эту информацию самостоятельно. В этом случае вы forwarding address можете поставить.

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

Поэтому если кто-то породил LSA-ку пятерку, то это все роутеры в автономной системе получают именно эту самую LSA-ку пятерку. В том числе, конечно же, и все роутеры внутри своего региона, одного региона с ASBR. Но я уже сказал, что внутри LSA-ки пятерки указывается роутер ID того, кто ее придумал. Роутер ID ASBR. И если вы находитесь в одном регионе с ASBR, то вы можете посчитать кратчайшую стоимость, как добраться до ASBR. И дальше сложить это с транспортной стоимостью, если у вас они складывабельные, либо, допустим, сказать, что вот у нас есть несколько ASBR, один из них присылает LSA-ку пятерку более дорогую, другой более дешевую. Я беру LSA-ку более дешевую и считаю кратчайший маршрут, как добраться до того ASBR, который прислал более дешевую LSA-ку. Ну, короче говоря, я считаю, как добраться до этого самого ASBR и считаю кратчайшую стоимость, сколько мне до него стоит добраться. И OSPF мне действительно дает такую возможность сделать. Но если я нахожусь в другом регионе, в том, которым роутер ID ASBR в принципе не виден,

возникает вопрос, как роутер R3 узнает, что есть у нас роутер 1, который анонсирует сетку, некую сеть A, он от него LSA-ку пятерку видит, а ID-шник его не видит. Как добраться до него? В этом случае АBR, который знает, что за пределами своего в кавычках региона другие роутеры не могут добраться до ASBR, он при перекладывании LSA-ки пятерки из одного региона в другой порождает рядышком с ней LSA-ку четверку. То есть если у нас АBR видит, что есть в одном регионе, например, в нулевом регионе, какая-то LSA-ка пятерка, и надо про нее рассказать всем остальным узлам, он LSA-ку пятерку перекладывает без изменений. Там сохраняются все роутеры ID, все стоимости, все на свете. Но рядышком с ней он генерирует LSA-ку четверку, в которой рассказывает, как добраться до ASBR, то есть какой роутер ID будет у ASBR, это предмет разговора, и как добраться до этой LSA-ки,

надо отходить через АБР, через роутер на границе регионов. Он указывает свой роутер ID, и, соответственно, все роутеры в пределах региона одного с АБР строят кратчайший маршрут до придумавшего такую LSA-ку четверку АБР. Дальше. Внутри этой LSA-ки четверки указывается стоимость, сколько стоит добраться до ASBR за спиной у АБР. То есть здесь указывается, например, стоимость 20, это значит, что вот R2 посчитал, сколько стоит добраться до R1, 20 копеек. И, соответственно, мы берем посчитанную стоимость здесь, допустим, 15 копеек, складываем с LSA-кой четверкой стоимостью 20 копеек, и получается, что роутер R3 может добраться до роутера R1 за 35 копеек. При этом R3 посчитал эту стоимость не целиком самостоятельно. Он доверился тому, что в LSA-ке четверки было написано, сколько стоит добраться до ASBR. И вот это вот summary ASBR или ASBR summary – это суммарная стоимость, сколько стоит добраться до ASBR.

Так. По поводу LSA-ек пятерок первого и второго типа. Предположим, что у нас есть некоторые роутеры, которые вбрасывают LSA-ки пятерки. И, соответственно, у нас эти LSA-ки пятерки могут быть разных типов. То есть, например, у нас есть роутер 1, который рассказывает про то, что знает сеть А, и роутер R3 знает его за 35 копеек. Равным образом у нас есть какой-то другой роутер, R, не знаю, 4, который известен за, не знаю, за 30 копеек. И он анонсирует ту же самую сетку. Вот, соответственно, у нас, не знаю, по BGP, допустим, тоже он получает ее. Не суть важна, откуда он получает ее. У нас есть некий внешний источник маршрута информации. И R4 тоже порождает LSA-ку пятерку. LSA-ка пятерка за ту же самую сеть и роутер ID R4. Он указывает некую стоимость. И R1 тоже указывает некую стоимость.

Если у нас используются LSA-ки первого типа, то есть мы говорим, вот здесь у нас LSA-ка первого типа, и вот здесь у нас используется LSA-ка пятерка первого типа, type 1. Иногда они обозначаются как E1 и, соответственно, E1. То есть E1 — это LSA-ка external пятерка, единичка означает, что это LSA-ка пятерка первого типа. Так вот, в этом случае стоимость, указанная в этих LSA-ках, может складываться напрямую с транспортной стоимостью. Вот, допустим, вот этот роутер анонсировал сетку за 20 копеек, и вот этот роутер анонсировал сетку за 20 копеек. Потому что LSA-ки пятерки первого типа выражают стоимость в тех же копейках, которыми оперируют успев и при подсчете своей родной стоимости. В этом случае, когда роутер R3 пытается понять, как лучше всего выйти из своей автономной системы в сеть, про который рассказывается в LSA-ках пятерках, мы считаем кратчайший маршрут. Мы берем стоимость, анонсированную в LSA-ке пятерки, 20 копеек. Мы смотрим, сколько стоит добраться до ASBR,

который в ней анонсирован. Складываем одно с другим и получаем стоимость. Сколько стоит добраться до указанной сети через указанного ASBR. Если у нас здесь вот есть две LSA-ки пятерки, то у нас эти две LSA-ки пятерки будут распространяться на все-все роутеры. И вот R3 будет видеть две LSA-ки пятерки. Одну от R1, другую от R4. R1 будет говорить, что знает сетку за 20 копеек. R1. R4 будет говорить, что знает сетку тоже за 20 копеек. R4 за 20 копеек. R1 тоже за 20 копеек. Сетка одна и та же. ASBR и RID разные. Рядышком с каждой из LSA-ек пятерок есть возможная LSA-ка четверка, если мы не находимся в одном регионе с ним. Соответственно, R4, R2 рассказывает, что до него можно добраться за... Сколько там получается? За 15 копеек. За 15 копеек. Вот в этом случае мы говорим, как можно выйти на роутере R3 в сеть А. По каждой LSA-ке пятерки, простите.

Считаем суммарный маршрут. Сколько стоит добраться до такой сети? Написано в LSA-ке 20 копеек. Написано, что добраться до нее можно через R1. Как добраться до R1? Находим LSA-ку четверку. В ней написано, что до этого соседа стоит добраться там еще 20 копеек. Поэтому получается 20 копеек написано в LSA-ке пятерки, плюс 20 копеек написано в LSA-ке четверки, плюс 15 копеек, которые мы посчитали маршрут, сколько стоит добраться до ABRA, анонсировавшего такую LSA-ку четверку. Соответственно, итоговая стоимость, как добраться до сети А через роутер R1, в таком случае будет 15 копеек, плюс 20 копеек, 35, плюс сколько написано в самой LSA-ке? 55 копеек. То есть через R1 это стоимость 55 копеек. Мы можем складывать, в случае с LSA-ками пятерками первого типа, стоимость напрямую. Если мы хотим посчитать, сколько будет стоить добраться до той же самой сети, но через роутер R4, мы говорим, окей, находим LSA-ку роутер R4,

в ней написано 20 копеек. Дальше находим LSA-ку четвертого типа, в которой написано, сколько стоит за спиной у ABRA добраться до ASBR. И он говорит здесь, до ASBR стоит добраться, ну, допустим, вот так, 15 копеек. То есть в LSA-ке четверки написано 15 копеек. Мы говорим, окей, 20 копеек плюс 15 копеек, получается всего 35 копеек. Плюс 15 копеек стоит добраться до ABRA. Поэтому через роутер R2 до той же самой сети стоит добраться всего, получается, 50 копеек. В этом случае есть два варианта, как добраться до сети за спиной у двух разных ASBR. Но одна и та же сеть доступна из двух разных источников. То не R2, а R4. Вот, получается, что через R4 выгоднее на 5 копеек. Если LSA-ка первого типа, то мы можем складывать транспортные стоимости напрямую. Если у нас вся та же самая история, но LSA-ки разных типов, то в этом случае давайте мы… Еще раз нарисуем. Вот у нас так вот будет R4.

Оба они анонсируют LSA-ку пятерку, соответственно, до той же самой сети. Но и здесь у нас будет LSA-ка… Так, стоимости здесь у нас 15 были, 20, 15. И в LSA-ках стоимости тоже 20. Но вот эта вот LSA-ка будет типа 1, а вот эта LSA-ка будет типа 2. Типа 2. Ну, то есть это E1 и E2, соответственно, если мы говорим в цисковской терминологии. Так вот, мы в этом случае на роутере R3 получаем две LSA-ки пятерки. LSA-ка пятерка. Соответственно, здесь у нас E1, а здесь у нас E2. И роутер, который я придумал, роутер R4. И рядышком лежит еще LSA-ка четверка. LSA-ка четверка, в которой указано, как искать роутер R4. И доступен он там за 15 копеек.

Здесь у нас написано 20 копеек, здесь у нас написано 20 копеек, здесь у нас написано 20 копеек. Вот роутер R3 говорит, окей, я вижу две LSA-ки пятерки разных типов. LSA-ка первого типа всегда приоритетнее, чем LSA-ка второго типа. То есть если у нас есть до одной и той же сети, LSA-ка E1 и LSA-ка E2, мы пользуемся LSA-кой E1 типа. Поэтому мы говорим, не важно, что у нас стоимость как добраться до R4, 15 плюс 15, 30 копеек, и за спиной у него эта сетка доступна за 20 копеек. Это сеть по определению некорректно построенная, то есть она менее доверенная по сравнению с сетью первого типа. В этом случае мы говорим, из двух этих LSA-ек мы сразу LSA-ку вот эту вот вычеркиваем. У нас остается только LSA-ка первого типа, только одна. Мы можем добавить ее в таблицу маршрутизации за 20 копеек плюс 20 копеек, плюс 15 копеек. То есть в таблицу маршрутизации мы добавляем сеть А за 55 копеек.

Именно потому, что LSA-ки первого и второго типа не сравниваются между собой в принципе. LSA-ки первого типа заведомо приоритетнее, чем вторые. Если у нас обе LSA-ки пятерки второго типа будут, то есть оба роутера заявляют, что LSA-ки пятерки второго типа, и, соответственно, они у нас показываются как E2, в этом случае они заявляются как доллары. И в этом случае мы говорим, что если у нас есть какая-то LSA-ка второго типа, ну, здесь за 20 копеек, а здесь за 20 копеек, история будет та же самая, что в предыдущем случае. То есть мы считаем кратчайший маршрут до АБР, который придумывает LSA-ки четверки, потом складываем стоимость, сколько будет добираться до АБР, до АБРа, с тем, что написано в LSA-ке четверки. И у нас получается некая транспортная стоимость, сколько стоит выгоднее всего добраться до вот этого вот соседа. То есть мы по всей сети нашли самый короткий способ, как добраться до R1.

И до второй LSA-ки мы тоже построили кратчайший маршрут. Каким-то кратчайшим путем можно выгоднее всего добраться до роутера R4. Вот эту вот транспортную стоимость мы просто высчитываем для того, чтобы добраться кратчайшим путем до двух роутеров. И у нас получается, для того, чтобы воспользоваться вот этой сеткой, нам нужно 20 долларов и плюс, сколько получается до роутера R1? 35 копеек. Хватит центов, напишу. И, соответственно, для того, чтобы добраться до вот этой вот сетки, нам нужно 20 долларов плюс 15, то есть 15, плюс 30 центов. Вот в такой ситуации, если у нас есть две LSA-ки второго типа, которые одинаковые по стоимости, мы выбираем между ними ту, у которой транспортная стоимость будет меньше. Мы сравниваем между собой копеечки. Если LSA-ки, которые к нам вбрасываются, будут немножко хотя бы отличаться, то есть, допустим, роутер R4 говорит, что я немножко поднимаю стоимость, я теперь продаю эти LSA-ки за 21 доллар.

То, в общем, все то же самое, но у нас получается LSA-ка пятерка от верхнего роутера стоит 21 доллар. В такой ситуации мы говорим, нет, 21 доллар плюс 30 копеек, это сильно хуже, чем 20 долларов и 35 копеек. То есть копейки в этом случае не надо сравнивать, сравниваем только доллары, сравниваем только стоимость, которая написана в LSA-ке второго типа. Да, выбрать вы при этом можете тип редистрибуции сами. При редистрибуции вы указываете, какие сети вы выбрасываете в SPF, и с какой метрикой. Метрику можно указать тип, и метрику можно указать, собственно, стоимость. Понятное дело, что вы должны будете прописать какое-то правило, вот маршрут по BGP прибежал, вы его перекладываете в SPF. Что это за маршрут? Откуда он взялся? Сколько в нем копеек должно быть? Вы должны сказать, что вы определенную сеть знаете, сколько копеек при порождении LSA-ки пятерки. Там стоимость надо написать. Поэтому вы можете сказать, допустим, какое-то гибкое правило написать, что такие-то сетки я вбрасываю с метрикой такого-то типа, такие-то сетки с метрикой другого типа, такие-то метрика 100,

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

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

то вы можете сказать, давайте все в один регион запихнем, это будет нормально. И достаточно нормальная ситуация будет, когда у вас все роутеры в одном регионе. Это не проблема до тех пор, пока у вас работает все стабильно. Нету проблем с тем, что в одном регионе у вас тысяча роутеров. Правда. Само по себе это не является проблемой. Проблемой является количество пересчетов топологии. Если вы используете достаточно современное железо, чаще всего все реализации в SPF умеют поддерживать такую штуку, которая называется ISPF. Incremental Shortest Path First. То есть не OSPF, а ISPF. Это такая штука, которая в случае получения каких-то изменений, допустим, у нас вот здесь поднялся какой-то интерфейс, а потом снова пропал, а потом снова поднялся, а потом снова пропал, а потом снова поднялся, а потом снова пропал. Все роутеры в этом регионе будут получать новые лессейки. Но вычисления по пересчету региона, они будут в этом случае проводить халявля. То есть они не будут по-честному пытаться найти, как вот этот роутер смотрит вот на этот вот.

Они говорят, если у нас вот на этом роутере появился новый интерфейс, вот он только задействован в этом. И, возможно, тот сосед, через которого, через, простите, тот сосед, на которого сбойная LSA-ка смотрела интерфейсом, который потух. То есть если у нас был роутер, который смотрел на соседа, на роутер, там, не знаю, один. А потом пришла новая версия от LSA-ки, в которой указано, что интерфейс подох. Ну, в этом случае мы можем не пересчитывать всю топологию. Мы можем сказать, если роутер R2 смотрел на соседа R1, а сейчас перестал, то связь между роутером R2 и R1 сломалась. Соответственно, можно ожидать через некоторое время, что R1 пришлет LSA-ку свою. Раньше он смотрел на роутер R2, а сейчас он смотрит в никуда тоже, что оно сломалось. Вот эти две LSA-ки задействованные, надо пересчитать, на кого они и как там смотрят. Если у нас новый интерфейс появился, надо найти, в каком месте точка приложена, и, соответственно, посмотреть, какие маршруты могут проходить через этот новый интерфейс.

Если у нас интерфейс сломался, надо посчитать, какие маршруты были проложены через этот интерфейс. Но не надо каждый раз, на каждый чих, пересчитывать всю топологию прям совсем целиком. достаточно будет, если у нас интерфейс сломался между двумя роутерами, посмотреть, какие маршруты через него проходили. Эта штука более затратна по памяти, чем прям по-честному все высчитывать, потому что вы должны будете все маршруты хранить в памяти с указанием того, через какие интерфейсы, через какие роутеры проходили эти маршруты. Не просто next-hop хранить, а вот прям по-честному всю трассу. Но, тем не менее, она заметно снижает нагрузку на ваши роутеры. Еще что-то хотелось сказать. Да, еще можно будет настроить всякие разные крутилки в SPF, касающиеся LSA-тротлинга, касающиеся таймеров, касающиеся Control Plane Policing. Так что, в принципе, даже если вдруг у вас начинает моргать интерфейс в пределах одного региона, ну, с некоторой вероятностью вы можете защититься от этого, по крайней мере, на небольшой период, когда у вас сеть будет деградировавшая.

Дальше вы разберетесь с проблемой, и у вас все будет работать по-прежнему хорошо. То есть не является самостоятельно проблемой то, что у вас в одном регионе много роутеров. Понятное дело, что все вот эти вот тонкие крутилки это тема, ну, достаточно отдельного разговора. Мы про это дело будем говорить на CCNP-шном треке провайдерском, потому что там все это дело крутить надо, на CCNA все это крутить как бы не надо. Так, если вдруг вы будете разбивать сеть на регионы, что касается того, зачем это может понадобиться. Во-первых, если ваше железо не поддерживает вот эту штуку, если ваше железо не поддерживает троттлинг, если ваше железо не поддерживает всякие штуки с control plane policy, то разбивать, конечно, сеть надо. Плюс к тому, если вы в OSPF засовываете пользовательские маршруты, а на провайдерском уровне это делать очень плохая идея, поэтому не надо так делать никогда вообще, но в предприятиях иногда так делают. То вот если вы пользовательский маршрут засовываете в OSPF,

то в этом случае вы на границах регионов, на АБРе, можете немножко поднаврать. Вы можете сказать, что у нас в одном регионе есть какие-то одни сетки, а наружу, за другие регионы, вы показываете какие-то другие сетки, немножко видоизменяя ЛСА-китрешки. Ну вот, такие вот вещи сделать можно в некоторых случаях, да, и несмотря на то, что как бы OSPF такие вещи сделать позволяет, я вам не рекомендую, на самом деле, бить сеть на регионы. Я не рекомендую вам это делать по одной простой причине. Каждый раз, когда вы разбиваете вашу сеть на регионы, все маршруты, которые вы передаете между регионами, начинают работать в дистанц-векторном стиле. Вы передаете не топологию, вы передаете маршруты. OSPF — это протокол, который хорошо работает с топологией. Он плохо работает с дистанц-векторными штуками. Поэтому, если вам надо передавать маршруты, и вы согласны на дистанц-векторный стиль, используйте дистанц-векторный протокол. У нас есть замечательный протокол BGP, дистанц-векторный, который очень хорошо работает с маршрутами, с единицей измерения у него маршрут.

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

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

Если мы работаем, обнаруживая соседей в OSPF, то мы обнаруживаем этих соседей в одном канале с собой. И, соответственно, у нас везде, где только можно, эти самые линкокал-адреса могут использоваться. Как следствие, вам для работы в OSPF V3 не нужны IP-шники. Для того, чтобы у вас установилось соседство, вам не нужно иметь IPv6 маршрутизируемый адреса на интерфейсах. Для того, чтобы передавать пакеты между роутерами, вам не нужно иметь маршрутизируемый IPv6 адреса на интерфейсах. У вас есть роутер, он смотрит на соседний роутер, он смотрит на соседний роутер, он смотрит на соседний роутер, который знает сеть А. Все роутеры в таблице маршрутизации могут иметь сеть А, и у них не будет вот здесь вот маршрутизируемых IP-шников. У вас может быть такое, что во всех роутерах в таблице маршрутизации есть только и исключительно сеть А. И никаких connected сеток. Ну, на самом роутере, который анонсирует эту сетку, connected есть, конечно. Ну, то есть вам не нужны транзитные адреса в OSPF v3. В OSPF v2 они по большому счету тоже не нужны. Но мы вынуждены включать OSPF на интерфейсах.

И мы для того, чтобы сказать, что на этих интерфейсах IPv4 обслуживаются, должны были повесить на эти интерфейсы IPv4 адреса. И они, естественным образом, разбегались по таблицам топологии, по таблицам маршрутизации на всех роутерах. Поэтому если мы говорили у нас вот здесь вот IP-шник там 10.0.1.1, здесь 10.0.1.2, здесь 10.0.2.1, здесь 10.0.2.2. Ну, в общем, все вот эти транзитные сетки, они попадали в таблицы маршрутизации на всех роутерах. И потом с этими сетками приходилось бороться. Есть механизм, который в OSPF v2 версии говорит, вот эти вот транзитные сетки в таблицы маршрутизации добавлять не нужно. Это именно дополнительный опциональный механизм, который совершенно не обязательно поддерживается всеми вендорами, который скрывает транзитные сети. В OSPF v3, в принципе, такой проблемы нету, что у вас транзитные сетки появляются, потому что вы не обязаны иметь IPv6 адреса на транзитных интерфейсах. У вас достаточно того, что есть линклоклы.

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

и он вокруг себя видит мечта. В OSPFV3 эту информацию разнесли. То есть отдельно в OSPFV3 используется топологическая информация, кто на кого какими интерфейсами смотрит. И отдельно в OSPFV3 используется адресная информация, в какие сетки есть доступ. То есть то, что у нас в LSA-ках первого типа было, оно теперь разнесено по двум разным типам LSA-ек. Дальше. Что еще? Как уже было сказано, OSPFV3 используют для работы IPv6. Он изначально создавался для того, чтобы таскать IPv6 маршруты, после чего к нему придумали механизм, как можно будет внутри OSPFV3 сообщений, которые идут поверх IPv6, передавать и IPv4 маршруты тоже. То есть если у вас есть роутер и другой роутер, и они связаны по проводу, и на этом проводе мы включили IPv6, и здесь включили тоже IPv6,

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

А потом внезапно выяснилось, что большинству, в общем, кроме одного инстанса IPv6, не сильно что-то надо, и подумали, ну давайте тогда мы все инстансы, которые бывают, разобьем на несколько диапазонов, и вот один из диапазонов выделим под IPv4. Все равно, раз там адресные топологические информации разнесены, то мы можем, не сильно модифицируя LSA-ки адресные, запихать в них и IPv4 маршруты тоже. Пакеты, в которых передаются LSA-ки, все те же самые, то есть у нас точно так же есть пакеты типа hello, пакеты содержимой LSDB, database description, пакеты хочу LSA-ку вот с таким вот заголовком, linkstate request, ты просил LSA-ку, или я тебе сам захотел послать LSA-ку, не потому что ты попросил, а потому что мне в голову так взглянуло, linkstate update, и подтверждение только заголовок LSA-ки, которое только что пришло, ls acknowledge. В отличие от OSPF второй версии, который может использовать аутентификацию с использованием либо плавинтекста, либо пароля,

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

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

какой IP-шник NextHop в OSPF V2 использовать, знать, какая сетка там используется, в какой сети соседи есть. И для того, чтобы сети, вот эти транзитные роутеры понимали, какие у них есть, использовалась как раз LSA второго типа, в которой прям натуральные IP-шники писались, IP-шники самих сетей. В OSPF третьей версии, как уже было сказано, все connect-отсетки переехали в отдельную LSA, поэтому у нас вообще нигде никакой адресной информации нет. У нас указывается, что есть роутер 1, у него есть сосед роутер R2, у соседа R2 есть сосед роутер R1. Дружат они поверх link-local адресов, но даже link-local адресов на самом деле в LSA первого типа нет. А для того, чтобы можно было указывать, на кого мы какими адресами смотрим, какие IP-шники должны быть у роутеров в таблице маршрутизации в качестве NextHop указываться, здесь порождаются LSA-ки восьмого типа. Восьмого типа LSA-ки имеют область распространения

интерфейс или link, и, соответственно, они не видны другим участникам. То есть R1 и R2 порождают по одной LSA-ки восьмого типа в пределах провода, они обмениваются этими LSA-ками, и роутер R1 знает, какой LSA-ка, какой канальный адрес соседский у роутера R2 есть. Равным образом, допустим, R1 и R3 тоже самое. Вот они тоже порождают LSA-ку-восьмерку, и у нас R1 знает, какой канальный адрес будет у роутера R3. По большому счету, зачем, казалось бы, здесь пересылать эти самые LSA-ки, если все равно link local address address друг другу роутера передают неизбежно, когда hello-пакеты посылают. А дело в том, что здесь может быть какая-то экзотическая ситуация, когда у вас есть, опять же, какое-то там облако frame-рилея, например. В облако frame-рилея смотрят один роутер, второй роутер, третий роутер и четвертый роутер. Вот они все в этом случае должны будут прописать соседство, кто-то на кого-то как-то там смотрит.

Во frame-рилея у нас нету multi-cast. И вы можете сказать, давайте у нас будет один роутер выбран диспетчером, и, соответственно, с ним будут все устанавливать полноценные соседские взаимоотношения. В этом случае роутер, допустим, R1, роутер R2 и роутер R3 имеют соседские взаимоотношения полные с диспетчером, у них есть связь с диспетчером, у диспетчера есть связь со всеми, но у роутера 1, 2 и 3 напрямую связь между собой тоже есть, но прописывать эти соседства было лениво. То есть мы не прописываем указания, что эти роутеры должны друг на друга смотреть. Прописываем только диспетчера. С диспетчером все дружат. Если что-то происходит, отсылается информация на диспетчера. Если диспетчер что-то хочет рассказать, он рассылает это на всех остальных unicast. Но R1 и R2, например, напрямую гипотетически могут обмениваться трафиком. Сама линия связи там есть. У нас с точки зрения фрейм-рилея все возможные каналы между роутерами куплены. Просто администратор поленился настраивать связь между роутерами R1 и R2. Так вот, в такой ситуации у нас появляется общий канал.

Здесь LSA второго типа точно так же генерится DRM, с которым все дружат. И таким образом роутеры узнают, какие канальные адреса у них есть. R1 и R2 друг другу hello-пакеты не посылают, но знают link-local адреса друг друга. И таким образом они могут обмениваться трафиком напрямую друг на друга. Вот. Это как бы не очень частый сценарий, но иногда бывает интересно. Дальше. Из LSA первого типа вся адресная информация уехала. Те адреса, которые используются для связи между двумя роутерами, то есть транзитные адреса, переехали в LSA 8 типа, это link-local адреса. Те адреса, которые соответствуют интерфейсам, на которых у нас идут юзеры, ради которых все, собственно, затевается, у нас переезжают в LSA 9. LSA 9 будет явно указывать, что роутер, который придумал такую LSA, на определенном интерфейсе, и эти интерфейсы будут пронумерованы. Допустим, здесь у нас указывается интерфейс номер, не знаю, 9, или 3, или 3.

Вот. Что на третьем интерфейсе живет вот такая вот сеть. Для чего это сделано? Для того, чтобы если вдруг роутер R1 скажет, у меня больше на этом интерфейсе ничего нету, все сетки, соответствующие интерфейсу третьего, можно было погасить. Или равным образом, если у нас здесь на этом интерфейсе появляется еще одна сеть, а в IPv6 нормально то, что на одном интерфейсе может быть много разных сетей. А, допустим, у нас здесь появляется FD, не знаю, 0.3, 2.2, по 64-й маске. У нас LSA первого типа, выпущенный этим роутером, не изменяется. Появляется новая LSA 9, которая не является сменой топологии. Это изменения в адресной информации, изменения в таблице маршрутизации, но не вызывают пересчет SPF. То есть добавление или удаление новой сети — это не топологическая смена. Это смена именно, как называется-то, смена адресной информации. При этом есть указание, что на этом роутере есть интерфейс 3.

Просто не сказано в самой LSA первого типа, какие именно сетки на интерфейсе номер 3 присутствуют. Сказано, что у нас есть интерфейс номер 1, на котором есть роутер R2. Есть интерфейс номер 2, на котором есть роутер R3. И показано, какими интерфейсами они смотрят на нас. Ну и равным образом в их LSA сказано, что на интерфейсе номер 1, который смотрит на соседа R2, мы видим R2 с его интерфейсом интерфейса 1. И вот так вот каждый роутер рассказывает, кто на кого какими интерфейсами смотрит. Если вдруг у вас есть роутеры, которые дружат по Ethernet, ну или по любой другой мультиаксесс-среде, то генерится LSA 2 типа. В LSA 2 типа тоже адресная информация уехала в LSA 9. Вот. По большому счету пазл сам собирается точно так же. То есть единственное, что изменилось, появились новые LSA, в которых содержатся адреса, которые приклеиваются однозначно к тому роутеру, который их придумал. Далее. Я уже сказал про аутентификацию в OSPF,

что OSPF v2 поддерживает либо plaintext, либо хэш от содержимого некоторого секретного ключа плюс пакета. OSPF v3 использует IPsec. И есть еще альтернативная штука. В OSPF v3 вы можете взять и использовать аутентификацию почти такой же, как была в OSPF второй версии. То есть если вы хотите использовать authentication trailer, он будет передавать в пакете, подпись цифровой пакета, зависящую от конкретного ключа и от конкретного пакета. То есть если пакет изменится, цифровая подпись тоже изменится. Если ключ изменится, подпись тоже изменится. И плюс к тому там будут ключи пронумерованные. То есть вы в одном пакете будете передавать номер ключа, и вы будете передавать хэш. Та же самая история и в OSPF второй версии. у вас будут передаваться ключи номерованные и передаваться будут пакеты. Так, что касается OSPF третьей версии,

как уже было сказано, он использует IPsec, можно включить дополнительное шифрование, но это как бы никто особо не делает, потому что в OSPF третьих пакетах ничего особо секретного, как правило, нет. И еще один момент, что IPsec обычно состоит из нескольких фаз. Первая фаза, вы согласовываете, что и зачем вы делаете, как вы это делаете, и потом вы уже дальше передаете шифрованные данные. Но вот на этапе первой части вы также согласуете параметры, с каким ключом вы будете шифровать данные. OSPF третьей не умеет работать с протоколами автоматического согласования ключей. То есть OSPF третьей просто по заданному ключу фактически шифрует или подписывает данные. Вы должны будете в ручном режиме создавать параметры Security Association для того, чтобы у вас OSPF поверх IPsec работал. То есть автоматические протоколы KIA или ISAC-MP, K-менеджмент протокол, здесь применить не получится. В ручками создаете SASH-ку, и дальше у вас все начинает подписываться.

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

ISAS — это очень хитрый протокол. Он изначально разработан не для IP. То есть если говорить про RIP, про EGRP, про OSPF тот же самый. Ну, ладно, RIP — это отдельная история, но EGRP и OSPF — это протоколы, которые изначально создавались для работы IP. Они нужны для аппликации, там, битс-маршрутизации IP. ISAS — это протокол, который изначально был создан вообще для совсем другого. Он прям совсем-совсем-совсем для другого. Разработан он компанией DEC, Digital Electronic Corporation, для их протокола DEC.NET. Потом на него посмотрели ISO и сказали, какой замечательный протокол у вас появился. Давайте мы его используем в другом совершенно сценарии, который на DEC.NET совсем никак не похож. И его с использованием напильника и такой-то матери допилили для того, чтобы он работал в протоколе CLNS — Connectionless Network Service. Это протокол, с которым вы сегодня вряд ли сталкиваетесь, потому что все-таки он очень старый. Но, тем не менее, это протокол стандартный для модели ISO, OSI.

Та самая 7-ровневая модель, она не просто предусматривает стандартные механизмы обмена, стандартные механизмы решения задач, скажем, сетевого взаимодействия. Она еще и предписывает использовать некие конкретные протоколы, которые образцово-показательные эти самые задачи решают. Вот один из этих образцово-показательных протоколов, которые могут работать, например, на втором уровне модели OSI, это протокол PVP. А один из образцово-показательных протоколов, который работает на третьем уровне модели OSI, никоим образом не IP, как вы могли бы подумать, а вот как раз тот самый CLNS. И ISIS — это был протокол, который нужен был для работы этого самого протокола CLNS — Connectionless Network Service. Работал он следующим образом. У вас были некие абоненты. Эти абоненты назывались ES — End Station. И, соответственно, они соединялись между собой через какие-то транзитные узлы, которые можно было бы назвать роутеры, можно было бы назвать свечи. И вот эти вот самые свечи назывались AS — Intermediate Station.

И, соответственно, этих самых Intermediate Station могло быть достаточно много. И вам нужно было соединять эти самые Intermediate Station между собой. Каждая станция, она имела свой собственный адрес. Но при этом она адрес имела не в отдельный адрес, на каждый интерфейс, как вы могли бы подумать, зная протокол IP. А у нее был просто один адрес. И, соответственно, могло быть такое, что у вас одна и та же рабочая станция, одна и та же End Station подключалась к двум разным Intermediate Station. И в этом случае у вас получалось, что один и тот же адрес известен двум разным Intermediate Station, двум разным AS. И надо было понять, как лучше всего добраться до конкретного вот этого самого адреса конечной рабочей станции. Как лучше пойти. Пойти напрямки, пойти в обход, пойти через какой-то другой, третий роутер вот таким длинным путем. И для работы в вот этой самой Connection Less Network Service штатный протокол, который реплицировал указания,

до какого узла, как можно ходить, это был как раз протокол ASIS. То есть Intermediate Station работали с этими самыми End Station, и они запускали протокол, с помощью которого можно было просчитать кратчайший маршрут, как добраться до конкретной рабочей станции. При этом, на самом деле, там чуть более изощренное все было. Был специальный механизм обмена данными с подключенными, ну, назовем это, роутерами, свечами. То есть у вас был специальный отдельный режим работы ESIS, с помощью которых рабочая станция могла, ну, как бы сказать, зарегистрироваться на роутере. А дальше роутеры уже рассказывали про то, какие рабочие станции к ним подключены. Фактически вы могли сказать, что после того, как станция зарегистрировалась на роутере, у роутера появляется Connected Marchrot. И дальше этими Connected Marchrotами дальше уже все обменивались вот эти вот самые ASIS. AS-ки между собой с использованием протокола ASIS. Вот. Изначально протокол красивый,

изначально протокол интересный. Сегодня, к сожалению, напрямую не используется, но, на самом деле, если вы посмотрите на то, в каком направлении двигаются современные сети, вы увидите, что все те концепции, которые в 78-м году были заложены в модели OSI, они все сегодня прям один в один появляются в топовых решениях самых известных вендоров. Если мы говорим про решения для дата-центров, если мы говорим про решения для тех ситуаций, когда там действительно много трафика нужно передавать между узлами, которые действительно требуют супер-высоконадежные соединения, все вот эти вот концепции, они прям один в один там, соответственно, будут. У нас есть конечные абоненты, например, сервер, который ставится в дата-центре, который генерирует сотни гигабит трафика. Мы разве говорим, что давайте просто подключать такой сервер к свечу? Нет, мы говорим, давайте у нас будет этот сервер смотреть двумя разными ногами на два разных свеча. Желательно в двух разных стойках, если уж не получается, до двух свечей в одной и той же стойке. Давайте этот сервер будет запускать на себе какой-то протокол обмена динамической информацией

с соседними свечами. Мы можем запустить либо на самом этом самом свече, допустим, на самом роутере, на самом хосте протокол BGP, либо мы можем запустить на хосте какой-то более простой протокол и дальше уже переделать это в BGP на свечах, на которых регистрируется этот узел. То есть у нас опять же появляется вот этот механизм ESIS. У нас на современных самых жирных решениях не используется никогда на свечах механизм MacLearning. Мы говорим, давайте здесь запускать какой-нибудь VIX, LAN. Если говорить про те решения, которые Cisco продавала лет 10 назад, какой-нибудь там Shortest Path Bridging, Cisco Fabric Path, все вот эти вот штуки, они как раз и используют фактически указания, что у нас на свече есть некий там IP-шник или MAC-адрес, который надо рассылать всем остальным оппонентам и считать кратчайшие маршруты уже не по MacLearning, не по механизму вида, давайте прикидываться шлангом,

а уже прям по-честному. Пополнять таблицу фактически маршрутов, как лучше всего добраться до какого-то узла. И опять же, да, в современном мире мы приходим к тому, что было заложено изначально в протоколе ESIS. или, по крайней мере, к этому подходим очень близко. И сейчас мы вынуждены адаптировать, допиливать напильником протокол IP, который, в общем-то, не предназначен для работы в этом самом механизме ESIS, для того, чтобы он как можно ближе стал похож на ESIS. Ну, точнее, IP похож на CLNS, а протоколы обмена маршрута информации, которые предназначены для IP, чтобы они напоминали ESIS. Ну, короче говоря, протокол был создан для работы с одним протоколом, в смысле, routing протокол ESIS был создан для работы с routed протоколом CLNS. Потом на него посмотрел интернет-engineering task force, который делает RFC, и сказал, какой клевый протокол вы придумали, давайте мы его используем для IP.

И в RFC 1195 был предложен механизм, как допилить напильником ESIS, чтобы в него бы IP можно было тоже запихнуть. И протокол стал называться integrated ESIS. Integrated он, потому что он, вообще-то говоря, работает все еще по-прежнему поверх CLNS. То есть, если вы поднимаете два роутера или два свитча с ESIS, они между собой не обмениваются IPv4-трафиком или IPv6-трафиком, они обмениваются с CLNS-пакетами. На одном роутере мы запускаем ESIS, на другом роутере мы запускаем ESIS. они поднимают CLNS-связь между собой и дальше поверх этой CLNS-связи они строят сессию ESIS. И дальше внутри этой сессии ESIS они обмениваются маршрутами IPv4 и IPv6. Естественно, у вас не получится обменяться маршрутами, если у вас на этом интерфейсе не включен IPv4 или IPv6. Но это именно программно. Проверяют роутер, типа, согласен он дружить по IPv4 или не согласен. Если сосед говорит, давай дружить по IPv4,

а у вас на интерфейсе IPv4 нету, ну просто сессия не поднимется и все. Вот. Она не поднимется, потому что вы ее активно прямо скажете, я не хочу с тобой дружить, потому что ты не дружишь по IPv4. ESIS может работать с IPv4 маршрутами, может работать с IPv6 маршрутами в пределах одной и той же сессии, может работать с какими-то, совсем другими типами маршрутов. Например, вы можете сюда же запихнуть нативный и вот CLMS, пожалуйста, никто не мешает. То есть вы будете облиниваться еще адресами endpoints and services своих. Вы можете в ASIS запихать указание, какой MAC-адрес где сидит. То есть IPv4 маршрут, которым мы обмениваемся, это же просто connected маршрут. Мы говорим, у нас есть connected маршрут там 10, 0, 0, 0, 24. Как до него проще всего добраться? Вот таким вот кривым путем. У нас есть сетка FD 0, 1, 2, 2, точа, по 64 маске. Как до нее проще всего добраться? Вот таким вот кривым путем. У нас есть MAC-адрес

A, A, B, B, C, C, D, E, E, F, F. Как до него добраться? Вот таким вот кривым путем. То есть с точки зрения ASIS любая полезная нагрузка, это указание, как добраться до некоторой сущности, она, соответственно, состоит просто из маршрута, по которым нужно будет пройти для того, чтобы доставить трафик в удаленную какую-то сеть. Чем является удаленная сеть? Является она маршрутом IPv4, является она маршрутом IPv6, является ли она адресом N-System с точки зрения CLNS, является ли она MAC-адресом с точки зрения Ethernet. Это, в общем, совершенно произвольная нагрузка. Если вдруг вам кажется, что Ethernet это вообще как-то совсем не отсюда, то не пугайтесь, пожалуйста, ну вот есть тут такие вот протоколы Shortest Pass Bridging, и, а его брат близнец Tril, Transparent Routing Сейчас. Tril, забыл, как расшифровывается. Transparent Routing over Lots of Links,

по-моему, так называется. Это протоколы, которые включаются на свечах, и у вас свечи начинают натурально синхронизировать MAC-адреса. То есть, мы говорили на некотором отдалении от этого модуля, что коммутаторы на Ethernet никоим образом не обмениваются MAC-адресами. Но вот с помощью вот этих протоколов можно натурально обменяться MAC-адресами. Можно построить кратчайшие маршруты до удаленных MAC-адресов. То есть, если у вас, например, есть три свеча, которые вы соединяете по, ну, либо SPB, либо Tril, и вы запускаете на них этот самый ASAS, то есть, вы запускаете вот здесь ASAS, вот здесь ASAS, вот здесь ASAS, и вы говорите, у нас есть здесь станция А, здесь у нас есть станция Б. То, соответственно, у них строятся кратчайшие маршруты, как добраться от одного SPB-свеча до другого SPB-свеча. И вот он говорит, вот это вот короткий самый маршрут от узла А до узла Б. Если мы хотим построить указание,

как до узла С добраться, то, соответственно, мы опять же строим кратчайший маршрут от узла А до узла С и говорим, трафик должен пойти вот сюда вот. Мы фактически включаем роутинг для кадров Ethernet. Но для того, чтобы роутинг у нас работать, у нас должен быть механизм обмена маршрутами. Ну, только единица обмена информации у нас будет не маршрут IPv4, а именно отдельный Макадес. Ну, вот, собственно говоря, SPB и Tril так и работают. Дальше. Мы, естественно, будем работать с ASAS для того, чтобы таскать все-таки IPv4 или IPv6 маршруты. И в этом случае мы будем обмениваться CLNS пакетами. Очень редко злоумышленник может догадаться, что вы обмениваетесь не IPv4, не IPv6, а CLNS, поэтому немножко ASAS более стойк к атакам. Невозможно взять и сказать, давайте вот мы подключаемся к роутеру, который работает по ASAS, на IP-шник, через который он, соответственно, дружит с другим роутером.

В OSPF мы включали IPv4, мы говорим, у нас здесь вот IP-шник 10.0.0.1, здесь у нас IP-шник 10.0.0.2, и вот мы тем самым говорили, если кто-то, какой-то злоумышленник вдруг внезапно сможет подключиться к нашему роутеру по 10.0.0.1, мы, соответственно, его пустим на себя в настройки нашего роутера, потому что этот IP-шник есть, и как бы если мы не закроем его на фаерволе где-то на входе в нашу сеть, все может случиться. В случае с ASAS у вас транзитных IP-шников может и не быть. Ну, то есть, они могут быть, но они, в общем, ни на что не влияют, они никому особо не нужны, и подключение к ним можно сразу запретить. Дело в том, что эти IP-шники вообще никогда ни в каких ситуациях, ни для чего, кроме как для резолва в канальной адреса, опять же, не будут использоваться. CLNS у нас есть, CLNS у нас таскает маршруты и прекрасно себя, соответственно, чувствует. ASAS протокол, который изначально создавался для таскания произвольной нагрузки, если мы говорим про integrated ASAS,

именно в версии того, как его придумал AETF, и, соответственно, в принципе, он может таскать совершенно все, что угодно, и кроме того, что он может таскать все, что угодно, он может таскать совершенно любые тройки type-lamp value. То есть, вы можете расширить функциональность ASAS практически неограниченно в зависимости от того, что вам нужно. Вы можете про один и тот же MAC-адрес, допустим, рассказать какие-то свойства, как вы его знаете, и с какой, за каким портом он сидит, и с какой порт группы вы его видите. То есть, фактически, с помощью ASAS вы можете передавать совершенно любую информацию, и у вас он, получается, действительно очень гибок в части конфигурирования. И не в том смысле, что вы можете в какой-то конкретной реализации взять и какие-то настройки изменить, а в том смысле, что если вам нужно добавить какую-то функциональность в ASAS, вы просто добавляете новую TL. В сравнении с OSPF, это действительно существенно более гибкая штука. Если вы в OSPF хотите дополнительную информацию сделать, вы должны будете сделать аппакию LSA

и в эту LSA в предсказуемом формате положить какие-то данные, которые совершенно не факт, что остальные роутеры смогут сожрать. TL. Вашки, ASAS-овские, они предсказуемого формата, и в них можно написать, должны ли соседние роутеры их жрать или нет. Ну, в общем говоря, ASAS протокол для провайдеров существенно более популярны, чем OSPF. Его тоже можно будет разбить на регионы. У него структура будет немного похожа на OSPF и немного различаться с OSPF. OSPF точно так же, соответственно, у нас будет использовать поиск кратчайшего маршрута. Использует ASAS точно тот же самый алгоритм поиска кратчайшего маршрута, как OSPF. Это алгоритм Dijkstra. Точно так же работает все по-честному только в пределах своего региона. То есть, если у нас вот здесь вот есть регион, вот внутри него мы алгоритм Dijkstra будем все по-честному считать. Но немножко по-другому устроены сами регионы.

Соответственно, у нас так же, как в OSPF защита от петель внутри региона происходит нативно, точно так же через границу регионов маршруты передаются только на определенных роутерах. В OSPF они назывались АБРами, здесь они специально так как-то не называются. Ну и плюс к тому у нас регионы между собой соединяются только по схеме звезда. То есть, трафик между регионами не через некий центральный регион не передается. Что касается различия с OSPF. В OSPF у нас регионы нумеровались. И номер региона был просто четырехбайтовое число. То есть, мы говорим, у нас есть регион номер 0, регион номер 1, регион номер, не знаю, миллион. И каждый вот регион мы могли вот обозначить, что есть регион номер такой-то. У каждого региона был флаг, является он с тобой, не является. В случае с ISAS, у нас есть регионы

двух типов. Регион, назовем это центральный, это регион левел 2, к которому могут подключаться регионы уровня 1, L1. Эти самые регионы уровня L1, они могут в себе точно так же, как и в случае с одним регионом в SPF, содержать какие-то маршруты, которые перекладываются во второй регион. Точно так же, если у нас есть какие-то маршруты, которые пробегают из разных мест в сеть, они сначала должны попасть в регион номер 2, а потом они должны из региона L2 попасть в регион 1, регион типа 1. Ну вот есть нюанс. Когда у нас маршруты зарождаются в втором регионе, пардон, когда у нас маршрут, простите, зарождаются в первом регионе, они во второй попадают без особых проблем. То есть все, что попадает из одного региона в другой, все как бы мы видим и здесь, и здесь. Если у нас что-то зарождается во втором регионе

нативно или потому, что оно попало во второй регион через, опять же, границу между регионами, то есть что-то зародилось, например, в первом регионе, оно попало во второй регион, из второго региона в первый регион оно не попадает. То есть тот роутер, который находится на границе между регионами, он фактически заявляет, что я знаю всего, что в вашем регионе нет. Это фактически как дефолтный маршрут. Он начинает рассказывать про дефолтный маршрут и говорит, я подключен ко всем остальным сетям. Рассылает флаг оттачи. Каждый из регионов реплицируется по-честному в пределах своих соседств. То есть вот мы говорим, у нас есть регион 1, левел 1, регионы левел 2, здесь тоже регион левел 1. Вот здесь вот происходит репликация 1, здесь происходит репликация 2, здесь происходит репликация 3. Так же, как и в OSPF, все роутеры внутри одного региона, все роутеры имеют одинаковую базу.

То есть. ДИНАМИЯ, здесь происходит репликация базы одного региона, здесь у нас происходит репликация другого региона, здесь у нас происходит репликация базы третьего региона. Есть нюанс, заключающийся в том, что вы можете сказать на роутере, к каким регионам он будет относиться. То есть будет ли он относиться к региону уровне 1 или будет ли он относиться к региону уровня 2. То есть, например, вот здесь вот мы можем сказать, Этот роутер может относиться к региону и 1, и 2. Но региону уровня 2 у него нет, потому что его нет куда взять. На этом роутере мы можем сказать, этот роутер может присутствовать в регионе только региона 1, и с ним все хорошо. Он даже не пытается стать роутером второго уровня, потому что, ну, опять же, ему мы это сделать запретили, а даже если бы не запретили, у него база второго региона была бы пустой. И, наконец, вот этот вот роутер, он действительно присутствует в этом втором регионе,

поэтому он должен быть роутером второго уровня, и он при этом смотрит и в первый уровень тоже. Поэтому мы на нем обе базы создаем. В отличие от OSPF, где можно было сделать сколько угодно интерфейс, осмотрящим сколько угодно регионов, у нас есть только две базы. База первого уровня и база второго уровня. И вы можете выбрать на каждом роутере, какие из этих баз вам поднимать. Дальше. Если мы работаем вот на этом, например, роутере, мы можем, в принципе, сказать, на этом роутере есть и первый, и второй регион. Но, опять же, первый регион ему взять нет, куда у него ни одного соседства в первом регионе нет, поэтому он его как бы не делает. Это будет роутер второго региона. То же самое здесь. Вот на этих двух роутерах мы должны будем сказать, что здесь у нас есть и первый, и второй регионы. И регион типа 1, и регион типа 2. То есть у нас обе базы здесь присутствуют. Еще раз подчеркну. В OSPF мы могли сказать, что у нас есть Area 0. есть у нас здесь, допустим, Area 1.

И здесь у нас есть Area 2. Вот. И у нас есть интерфейс смотрит сюда, смотрит сюда, смотрит сюда. Вот это вот было нормально. У нас на АБРе могло быть 2, 3, 5, 10 регионов. И, соответственно, мы на АБРе в OSPF держали 2, 3, 10 различных баз LSDB. В OSPF мы не можем держать две разные базы. То есть мы можем держать базу уровня 1 или базу уровня 2. Если у нас есть на роутере вот какое-то вот такое вот соседство, то мы здесь должны будем сказать, что вот этот вот роутер, он обязан смотреть в тот же самый регион уровня 1. То есть мы естественным образом должны будем реплицировать в него ту единственную базу первого уровня, которая у нас есть. То есть мы не можем сказать, что у него будет какая-то обособленная база, он будет сидеть в своем обособленном регионе. Либо мы смотрим только в один регион, либо мы смотрим в два региона. Но не больше. Вот. И, соответственно, если вы включаете два региона на двух роутерах,

которые между собой как-то связаны, вы можете указать, по каким линкам какие соседства вы будете устанавливать. Например, смотрите, если у нас здесь вот этот вот есть роутер, он и первый, и второй регион на себя держат. Вот этот вот роутер по факту держит только базу первого региона. Соседство между этими роутерами будет реплицировать только базу первого региона. Равным образом вот здесь соседство реплицирует только базу первого региона. Вот здесь у нас роутеры сидят только во втором регионе. Они тоже, соответственно, будут реплицировать соседство только второго региона. Если вот здесь у нас, опять же, соседство первого региона, а вот здесь соседство второго региона, то вот линки между вот этими двумя товарищами, они могут быть разными. И мы можем сказать, давайте реплицировать по разным линкам по разные соседства. По одному линку, скажем, реплицируем только второй регион, по другому линку реплицируем только первый регион, по вот этому линку реплицируем и то, и другое. Да, действительно, вы можете реплицировать и то, и другое по одному проводу.

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

OSPF по большому счету работает очень похоже на ASIS. За какими-то минорными исключениями, связанными с тем, что ASIS, во-первых, не работает по IP, во-вторых, у него вот там немножко структура региона другая, по большому счету ASIS и OSPF – это очень похожий протокол друг на друга. Давайте разберем те термины, которые есть в OSPF и сравним их с теми терминами, которые есть в ASIS. OSPF оперирует термином host. На самом деле здесь по-хорошему можно было бы сказать, что еще есть маршрут в OSPF. Это то, что… Роу-слэш-префикс, более правильно сказать. То, чем обменивается OSPF. В ASIS эта штука называется end-system. То есть host – это то, что может формировать трафик. Вот в ASIS, если мы используем терминологию, которая есть в CLNS, то, что может формировать трафик – это end-system.

Это терминальный узел, который формирует пользовательские пакеты, которые должны отправляться куда-то там. Вот это вот куда-то там в случае с IPv4. Представьте себе, что если бы в IPv4 держали только слэш-32 маршруты. Вот у вас все префиксы были по 32 маске. Вот в ASIS в этом случае указания, как добраться до всех остальных end-system, они как раз вот этим самым 32 маскам бы и передавались бы. По сути. Если у вас есть в OSPF какой-то узел, который участвует в этом самом OSPF взаимодействии, то мы его называем роутер. В ASIS мы роутером называем intermediate system. Это та железка, которая находится в транзите между двумя терминальными узлами, которые называются end-system. Если два роутера у вас связаны прямым проводом, или каким-то каналом, которые позволяют участвовать между собой двум участникам, или больше, чем двум участникам, то в OSPF мы это называем link.

В ASIS мы это называем circuit. То есть если у нас есть ASIS, то вот это circuit. circuit. Ну и, соответственно, circuit и до ES тоже идут. То есть какие-то каналы, которыми железки связываются между собой. OSPF будет передавать пакеты. То есть для нас нормой является то, что OSPF указывает, что он хочет отправить чего-нибудь. Вот там у него есть LSU, есть LSA, есть HELLO. Это все пакеты OSPF. Они укладываются в 89-е вложение, и все отправляется в IP-пакетах. В ASIS у нас единица передачи информации — это PDU. И они вкладываются напрямую в канальный уровень. То есть у нас есть PDU-шка ASIS, и она вкладывается, ну, например, в Ethernet. То есть напрямую, без каких-либо прокладок. Дальше. У ASIS есть концепция, как будут себя вести железки,

если у вас есть несколько узлов в одном circuit. То есть у нас есть коаксиальный провод, в этом коаксиальном проводе 5 intermediate систем. В этом случае, точно так же, как в ASIS, выбирается диспетчер. Диспетчер в ASIS называется designated router, в ASIS он называется designated IS. Ну, то есть одно и то же, да? Designated router, router, designated IS, ну, и дис, сокращение. Если мы хотим отправить какое-то обновление своему соседу, мы это соседское уведомление формируем в виде link state advertisement, и мы его называем LSA. Это вот кусочек информации, который мы хотим обмениваться со всеми узлами. В ASIS эта штука называется link state PDU. Вообще здесь немножко, конечно, криво, потому что link state PDU – это вообще говоря пакет. Ну, вот как бы LSP – стандартное обозначение для того же, что в USPF называется LSA.

Невозможно понять, и надо запомнить. Мне, в свою очередь, было сложно довольно запомнить в свое время, но как-то запомнил. LSA, LSP. Дальше. То, что мы отправляем hello-пакеты, эти hello-пакеты в ASIS называется IEH. Это IEH – это ASIS intermediate system to intermediate system hello. Вот это вот сокращение, оно невозможно, и меня каждый раз ржак пробивает, когда я его вижу. Вот. Вот это вот CSNP – complete sequence number PDU – это то же самое, что database description. Он, по сути, передает указание, какие LSA, какие LSA, какие LSP, точнее, вы знаете. Так. Если мы используем ASIS, мы используем, на самом деле, взаимодействие поверх CLNS, и мы уже говорили, что каждая система в ASIS или в CLNS

имеет свой адрес. И, как уже говорилось, этот адрес будет один на всю систему в целом. То есть у нас нет такого, как в IP, что на каждом интерфейсе мы можем повесить отдельно кучу разных IP-шников. У нас будет роутер в IP. Выглядит как то, что у него есть там четыре разных интерфейса. Здесь один IP-шник, здесь один IP-шник, здесь один IP-шник, здесь два IP-шника, еще лунбек, который придуман, на нем еще пять IP-шников. Такого нету. В CLNS у железки есть куча серквитов, которые она смотрит, и есть один адрес. Этот адрес называется вот таким вот словом Network Service Access Point или NSAP. Особенность этого адреса заключается в том, что он, во-первых, переменной длины, то есть у него есть плавающая часть, которая может быть плавающего размера. Эти адреса состоят из нескольких частей. Сначала идет указание area, то есть в каком регионе этот адрес живет. Причем она делится на две части. Сначала указывается тип региона,

тип area, а потом уже указывается сам area ID. Если мы работаем с CLNS-адресами, которые локально значимые, которые мы сами назначаем по своему хотению, то мы в тип региона вкладываем 49. Это просто хорошо известный указатель на то, что дальше адреса будут какие-то кастомные, наши собственные. Связано это с тем, что структура адресации используется общая для вообще всех ISO-шных протоколов. А ISO-шные протоколы – это не только ценный мех, но еще, например, телефония. Если вы хотите использовать, например, CLNS для телефонии, то у вас эти INSAP-адреса будут в себе содержать, ну, например, телефоны. Я сейчас не про IP-телефоны, я сейчас про обычную стационарную телефонию, которая тоже поверх CLNS зачастую бегает. И вот в этом случае, соответственно, у вас будет какой-то специфический тип региона, обозначающий, что этот регион будет работать с телефонными адресами.

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

вы его можете сами по себе назначать, каким хотите образом. Ну, например, можно сказать 0001. Это вот номер региона. Или 0002. Этот номер региона будет... Давайте отмотаю немножко назад. Вот этот номер региона будет указывать на вот эти вот ваши регионы. То есть фактически номер региона имеет смысл задавать только для L1 регионов. Вы указываете, что здесь у нас будет регион 0001. Здесь у нас указывается 0002. А L2 не требует указания кода региона. Это вот такой хитрый ход. И более того, вы можете сделать какую-то такую вот штуку, если здесь у вас не только L2 связь будет идти, но и L1 связь тоже. То есть фактически вот этот роутер будет включаться в один регион 0002. Вот таким вот нехитрым образом вы можете сделать так, чтобы у вас все роутеры имели бы какие-то номера регионов. Ну то есть можно сказать, что вот этот вот роутер у вас будет иметь номер area 0003. И фактически в этом случае он будет сидеть один сам в регионе с номером 0003.

У него никаких соседей по L1 нету. И он сам себе лучший друг. Вот. То есть каждый роутер должен сидеть в каком-то регионе. И один роутер сидит только в одном регионе, имеющем номер. В OSPF мы должны были сказать, что у нас есть роутер, у него есть интерфейс. Один интерфейс смотрит в регион номер 0, другой в номер 1, третий в номер 2. Вот. В ASIS не так. В ASIS у вас роутер сидит целиком в каком-то одном регионе. Но он может сидеть в одном регионе L1, и кроме того, он может сидеть в регионе L2. Связи по L2 не требуют указания региона. Так. Дальше. После указания 1-байтового, пардон, 1-байтового типа региона, 2-байтового номера региона, дальше идет система ID. Система ID может быть плавающей, то есть он может иметь случайный размер. Но если мы хотим соответствовать вот такой вот смешной штуке, стандарту американского правительства, который сделан для того, чтобы быть адаптирован для международной организации по стандартизации, соответствовать модели OSI.

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

Соответственно, что здесь в таком случае делать? Ну, в этом случае вы можете не записывать сюда MAC-адрес. Вы можете записать сюда что-нибудь еще. Например, если мы записываем в 16-ти личном виде этот самый систем ID, он у нас получается первый байт, второй байт, третий байт, четвертый байт, пятый байт и шестой байт. 12 символов. Если мы хотим записать IP-в четвертый адрес в форме обычной, привычной нам десятичной формы, мы говорим, у нас есть, например, 192.168.000.001. Понимаете, к чему я? Можно записать его вот в таком вот виде. Можно IP-в четвертый адрес взять и записать в виде 12 символов, каждый из которых представляет некую 16-ти личную цифру, и разбить его на вот 12 цифр таким образом.

И у нас получится 48-битовый, 6-байтовый, простите, систем ID. Мы в него запишем IP-в четвертый адрес, который вообще-то ни разу не 48-битный, а всего лишь 32-битный. Но вот за счет того, что мы таким лайфхаком воспользовались, мы в него записали IP-в четвертый адрес. Если хотите, можете использовать систем ID 0.0.0.0.0.0.0.1. Пожалуйста, используйте. То есть никто от вас ничего не требует. Единственное, что систем ID должен быть уникальный в пределах всей автономной системы. То есть неважно, в каком регионе вы находитесь. Главное, чтобы у вас систем ID был действительно уникальный-уникальный. Ну и заканчивается NSAP-адрес на 1 байт. С ним все просто, он всегда должен быть 0. То есть этот адрес используется для указания типа адреса. Если мы указываем, что у нас этот узел, который имеет такой адрес, будет являться автономной системой, то там всегда указывается 0.

Если у вас NSAP-адрес содержит вот этот последний байт нулевой, кстати, этот байт называется NSEL или NSAP-селектор, так вот, если у вас адрес заканчивается на 0, то такой адрес имеет специальное название – NET – Network Entity Title. То есть это именно не просто MAC-адрес, а MAC-адрес, который характерен для маршрутизатора. Ну, IP-адрес. IP-адрес характерен для маршрутизатора. Вот. Если говорить про связь с MAC-адресами, то мы говорили, что у нас есть роутер, у которого есть куча интерфейсов. В IPv4 у нас IPv4-адреса есть на каждом интерфейсе. Но иногда мы можем сказать, давайте мы поднимем просто loopback, особенно в IPv6 мы это можем сделать, сказать, у нас есть loopback 0. А на интерфейсах у нас никаких IP-шников нет. Ну, вот фактически в такой форме ISIS очень похож на IPv6, когда мы на интерфейсы не назначаем никакие маршрутизеримые адреса, у нас есть один адрес, по которому мы работаем через роутер.

На интерфейсах у нас при этом есть канальные адреса, которые действительно только в пределах канала. И вот такие адреса, которые действительно только в пределах канала, они имеют специальное название в CLNS. Это будет называться SNPA – Subnetwork Point of Attachment. То есть SNPA – это просто обозначение того самого канального адреса, который используется в вашем серкуте. Если вы используете Ethernet, то у вас два роутера, у них есть свои собственные NSAP-адреса, которые заканчиваются на ноль, поэтому они называются Net-адреса. И здесь то же самое. Другой роутер, другая автономная система тоже. Это роутер тоже оно Net, соответственно. И у них есть MAC-адреса, которыми они друг на друга смотрят. Вот у каждого из этих роутеров есть MAC-адрес. Один MAC-адрес, второй MAC-адрес. Вот они этими MAC-адресами друг к другу посылают кадры Ethernet, внутри которых лежат CLNS-ные пакеты с IS-IS. Я надеюсь, что я вас не сильно смутил всем этим рассказами. Постарался объяснить максимально понятно, насколько вообще мог.

Но смысл здесь будет очень простой. В IS-IS у нас используются хитрые адреса. Нам эти адреса нужно будет назначать. Назначаются они по достаточно простой схеме. Сначала указывается код региона 49, тип региона, простите, потом номер региона, потом системы ID 6-байтовой и в конце нолики. Так, дальше. После того, как мы назначили адреса, после того, как роутеры или интермедиат-системы узнали друг друга, отправили друг другу hello-пакеты, нашли друг друга, установили соседские взаимоотношения, дальше они начинают обмениваться LSA-ками. Ну, то есть не LSA-ками, конечно, LSP-шками. Они обмениваются кусками топологии LSP-шками, складывают это все дело в базу, дальше по этой базе начинают складывать пазл. И когда база сложилась, когда топология вся сошлась, начинают строить кратчайшие маршруты.

ASIS использует тот же самый алгоритм Dijkstra для поиска кратчайшего пути в графе с весами. Соответственно, так же, как в OSPF, у нас каждый интерфейс получает некую стоимость, некую метрику. Точно так же, как в OSPF, итоговая стоимость всех транзитных метрик будет составлять стоимость маршрута. Так же, как в OSPF, чем меньше, тем лучше. Но изначально ASIS отличался от OSPF тем, что метрик в нем было 4 штуки. То есть в OSPF у нас одна метрика, за сколько копеечек мы можем отправить трафик через интерфейс. А в ASIS метрик было 4 штуки заложено. Соответственно, первая метрика, которая называлась просто дефолт метрик, и она поддерживается всеми реализациями. И еще дополнительно, ASIS умеет отправлять, не просто умеет, он их отправляет, метрику, которая называется задержка, стоимость и уровень ошибок. То есть вы можете, отправляя HelloPacket,

не HelloPacket, вы можете, отправляя указание, что вы в какую-то сеть смотрите, указать, как именно вы смотрите. Если вы указываете, что вы видите соседа, указать, как именно вы видите соседа. То есть вы можете, вот эта стоимость, это в долларах натурально. То есть чем более дорогой интерфейс, тем, соответственно, менее выгоден этот интерфейс для отправки трафика. Вот. И вы можете построить гипотетический маршрут, не исходя из какой-то безразмерной величины, что он там кто-то заявил, что кто-то знает там какую-то сеть за 100 копеек. А вы можете сказать, вот мне интересно конкретно этот маршрут построить с учетом задержки. То есть вот мы все маршруты нормально и строим нормально по метрике обычной по умолчанию. А некоторые маршруты, мы можем сказать, для них интересно использовать ту же самую топологию, те же самые связи между роутерами, но с учетом задержки. Что-то аналогичное потом появилось в OSPF, к слову сказать. То есть OSPF с дополнительными ограничениями. Будет называться CSPF, и он активно используется в MPLS Traffic Engineering.

Вот он получил примерно такую же возможность, но существенно позже. И, естественно, не все реализации поддерживают CSPF, constraint SPF. Но изначально в ASIS эта штука как бы уже была. Опять же, не все реализации в ASIS это стали поддерживать, потому что по стандарту написано, что метрику по умолчанию обязаны поддерживать вообще все. А вот все вот эти дополнительные метрики, их передавать как бы можно, но никто не обязан их уметь поддерживать. Поэтому с ними в итоге вышло некрасиво. Та же самая CSPF их реализовать просто не стала. Но, тем не менее, они бывали. Дальше. Кроме того, что метрик было 4 штуки, у них еще было дополнительное ограничение, что они были реально маленькие. То есть, если вы передавали указание, что вы каким-то интерфейсом смотрите на что-то, либо на сетку у соседа, либо на endstation, end system, почему station все время называют, end system, то стоимость одного интерфейса, которым вы смогли смотреть,

либо на конечную станцию, либо на соседа, она была от единицы до 63. То есть она была до двойки в шестой степени минус 1. Максимальная стоимость всего маршрута в целом была до двойки в десятой степени, опять же, тоже минус 1, до 1023. Вот в принципе, если вы используете какую-то небольшую сеть, вам таких метрик должно хватить. Вы можете сказать, что какие-то маршруты будут получше, какие-то маршруты будут похуже, но все равно они непринципиально отличаются. Допустим, какие-то маршруты стоят 1 копеек, какие-то маршруты стоят 5 копеек, какие-то 10 копеек. И в итоге вам стоимости вот такой вот на интерфейс и стоимости вот такой вот на маршрут в принципе по большому счету должно хватить. Если вдруг вам их не хватает, вы должны будете переключить стиль метрик в так называемые широкие вайд-метрики. В этом случае и на интерфейсе на маршрут стоимость может быть до 16 миллионов.

Двойка в 24 степени. Эта штука будет использовать отдельную TLV-шку. То есть вы указываете, что вы, отправляя, допустим, LSP-шку, указываете, что у нас есть какой-то интерфейс со стоимостью ровно 63, и отдельно прикладываете рядом TLV-шку, в которой указываете, сколько на самом деле оно есть. То есть 63 — это максимум, который можно написать в штатное место. Ну и это автоматически означает, что если у вас есть TLV-шка с более правильным указанием стоимости, на самом деле это не 63, а больше. Да, ну в итоге вы можете указать, соответственно, сколько стоят ваши интерфейсы, дальше посчитать, сколько стоит весь маршрут в целом. Если какой-то узел не поддерживает расширенные TLV-шки, вот эти вот со стоимостьями, он будет оперировать максимальной стоимостью, которая ему доступна в 63 копейки на интерфейс. И в итоге у вас, да, чем меньше стоимость итогового маршрута получится, тем будет лучше. Меньше метрика интерфейса, больше вероятно прохождение трафика через него, и самый выгодный интерфейс,

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

Ну, здесь все просто. Если у нас есть два роутера, которые находятся в двух разных регионах. Один из роутеров находится в первом регионе, другой роутер находится во втором регионе. Как в этом случае кратчайшие маршруты будут строиться? У нас есть роутер R1. У него на нем есть база, соответственно, первого региона. Только первый регион и больше ничего. На нем появляется конечная система А. Это конечная система. Здесь написано ЕС. Никто вам не мешает сказать, что это на самом деле сетка. 10, 0, 0, 0. Вот на роутере R1 появляется интерфейс, который смотрит на что-то интересное. R1 хочет сказать, ребятки, у меня есть LSP-шка, и рассказывает про то, что он смотрит в эту сеть. Он говорит, я рассказываю про то, что у меня есть такая ЕС, такая сетка. Он рассказывает, как его зовут, какой у него адрес, и рассказывает про то, что вот к нему она подключена.

Это, ну, фактически, как LSA-ка первого типа. Эта штука разбегается по всем роутерам в пределах региона, в том числе и на роутер R2, который и первого, и второго типа, у него обе базы есть. Поскольку это роутер первого типа, у него, соответственно, такая LSP-шка обрабатывается, он просчитывает кратчайший маршрут и говорит, я знаю, как добраться до вот этой вот конечной станции, до вот этой инстейшн. Если хотите, он добавляет себе маршрут в таблицу маршрутизации. Дальше. Он про это начинает рассказывать от своего имени, так же, как в OSPF себя вел АБР. АБР говорил, у меня в таблице маршрутизации есть маршрут, который стоит столько копеечек, я его узнал из другого региона, который я вам не покажу, и вам я даю только summary, только готовую суммарную стоимость. То же самое делает роутер R2 при перекладывании маршрута из первого региона во второй. Он формирует свою собственную LSP-шку, которая рассказывает, как его зовут и до чего он может добраться. Он говорит, я роутер R2, я могу добраться до LSA,

прости, до сетки 10.000, по сути. И он говорит, что я могу добраться за 10 копеек. То есть он посчитал, сколько стоит добраться, и говорит, за столько могу добраться. Все роутеры во втором регионе, они видят эту LSA, и они забирают ее к себе. И просчитывают кратчайший маршрут в пределах своего региона, как добраться до этого роутера. Точно так же, если несколько роутеров анонсируют одну и ту же сетку, то выбирается тот, до которого суммарный маршрут будет меньше. Если у вас есть другая ситуация, сетка зарождается во втором регионе либо через какой-то транзитный роутер, либо она там нативно появилась. Вот, допустим, роутер R1 нативно в втором регионе зародил какую-то сетку A. И дальше он про нее рассказывает. Я, говорит, знаю сетку A, и этот роутер дальше рассказывает про эту сеть, про эту LSP-шку всем роутерам во втором регионе. Некий роутер R2, который и первого, и второго регионов получает такую сетку,

и дальше рассказывает про это дело всем остальным. Но в регионы первого типа маршруты из второго типа не попадают для того, чтобы не формировать петли. Поэтому вместо того, чтобы рассказывать про то, что он знает такую-сякую пятую-десятую сетки, R2 в первый регион формирует LSP-шку, который говорит, я знаю все, чего вы не знаете. Он, по сути, присылает указания, что все присылайте мне. Это вот штука ATT. Это флаг оттачит. Типа этот роутер подключен ко всем остальным сетям. И роутер R3, получив LSP-шку с флагом оттачит, говорит, окей, я у себя в таблице маршрутизации не буду держать отдельные сетки, потому что мне про них не рассказали. В этой вот LSP-шке нет указания, какие сети есть за спиной R2. Но есть указания, что там доступны вообще все сети в мире. Фактически это как в SPF, в цисках Total Estab работает. Нам происходит дефолт от АБРа, и мы говорим, окей, мы не видим ничего, что находится за спиной АБРа,

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

никаких проблем. Делайте все L2, и все будет хорошо работать. По умолчанию на конкретно, например, на CISC, как все роутеры и все линки будут L1 и L2. То есть у вас реплицироваться будут и первый регион, и второй регион. Ну да, то есть через L2 как минимум все будет работать. Вот такая вот фигня. ISIS точно так же, как и SPF, поддерживает аутентификацию. Можно аутентифицироваться по открытому ключу, можно аутентифицироваться по хэшу, подключая пакета. И нюанс заключается в том, что вы настраиваете разные ключи для пакетов Hello и для пакетов LSP, LSP. То есть для пакетов, которые у вас содержат мясо. То есть отдельно Hello пакеты подписываете, и отдельно мясо. Зачем это нужно так и сделать было, я не понял, честно говоря. То есть я пытался в свое время разобраться в этой проблеме, зачем сделали два разных ключа. Никакого реального юзкейса я для этого не придумал. Но, тем не менее,

настраивался в двух разных местах. Спасибо. Спасибо. Спасибо. Спасибо. Спасибо.