Манипуляции с маршрутами в OSPFv2

Продолжение следует... Продолжение следует...

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

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

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

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

то в этом случае не все коннект-отсетки попадут, а только то, что пройдет фильтр. Для того, чтобы вот эти вот внешние маршруты для USPF передавать, у нас используется LSE-ка пятерка, а для помощи того, как чтобы эту LSE-ку пятерку превратить в маршрут, у нас иногда будет использоваться также LSE-ка четверка. И вот типичный сценарий для использования внешних маршрутов, это два на самом деле сценария. Первый — это маршрут по умолчанию. У нас есть сетка USPF-овская, где-то на одном из роутеров у нас есть выход в интернет. И, соответственно, вот этот вот роутер говорит, у меня есть маршрут по умолчанию, я его хочу анонсировать всем своим соседям, для того, чтобы они могли тоже ходить в интернет. У него маршрут по умолчанию смотрят в интернет, допустим, с татикой, и он его выбрасывает в виде LSE-ка пятерки. Дальше все роутеры в топологии говорят, построим кратчайший маршрут до этого самого роутера, который нам выбрасывает USPF, LSE-ку пятерку, и дальше выйдем в интернет через него. То есть как-то вот так вот это будет выглядеть.

У нас будут маршруты строиться, и дальше трафик выйдет в интернет. Вот. Второй сценарий — это не про интернет. Это про то, что у вас есть какая-то сеть, и в этой сети вы хотите анонсировать некоторые маршруты. Я здесь это назвал пользовательские маршруты, но по сути своей это, назовем это customer route, не пользовательские, а потребительские, что ли. Представьте себе, что у вас есть роутер. К этому роутеру подключены у вас, ну, например, юзеры или, например, сервера. И вот вы хотите анонсировать маршруты до этих серверов так, чтобы трафик до них дошел до... трафик до них ходил от каких-то других точек сети. В случае с пользователями тут все просто и предсказуемо. Вы можете просто включить OSPF на этих интерфейсах, и оно заведется. Но если это сервера, то на этих серверах могут быть какие-то сервисы. И вот если там у вас есть сервис, например, не знаю, SMTP,

условно говоря, SMTP, да, почтовый сервер в СИД. Соответственно, вы можете сказать, у нас SMTP сервер работает на IPшнике 10.0.0.25. Вот вы можете сказать, давайте мы возьмем статический маршрут до этого сервера, пропишем на вот этом вот роутере, и его редистрибутим 10.0.0.25.32, редистрибутим в OSPF в виде лосеки пятерки. Зачем такую фигню делать? А затем, что у нас может быть еще другой роутер, и на нем может быть другой SMTP сервер, тоже SMTP, но другой. И у него тоже такой же IPшник будет 10.0.0.25. И вы в нескольких местах вбрасываете LSA-ку пятерку с одной и той же сеткой. То есть так по-хорошему делать, конечно, нельзя, но вы вбрасываете ее действительно таким вот образом, и вы делаете так, чтобы никогда, ни при каких условиях, трафик у вас до этих самых, до этой сети не балансировался, чтобы вот всегда один из, один из маршрутов был всегда более приоритетным,

чем другой. И получится, что если у вас есть где-то какой-то вот роутер, который, на котором сидит юзер, вот юзер говорит, я бы хотел подключиться к IPшнику 10.0.0.25, он посылает пакет на ближайший роутер, а ближайший роутер говорит, ближайшая ко мне точка, которая вбрасывает такой маршрут, это вот, например, роутер левый, R1, и он трафик посылает на него. В какой-то другой точке сети вполне может быть другая ситуация, что тоже пользователь сидит, тоже посылает трафик на этот же IPшник, но трафик идет на другой сервер, который находится ближе к нему. Это такое географическое, географическое балансировка трафика, и называется эта штука AnyCast. AnyCast. Вот. С использованием LSEC пятерок это, соответственно, делается достаточно легко и достаточно приятно. Почему здесь имеет смысл использовать LSEC пятерки, а не, например, LSEC трешки или даже не просто OSP включить на интерфейсе,

который смотрит напрямую на сервер? Дело в том, что в такой ситуации как раз у вас, во-первых, есть возможность вбрасывать именно один и тот же IPшник AnyCast в разных точках, потому что вы его можете выбрасывать по 32-й маске, которая у вас по факту не висит на интерфейсе. Это раз. А во-вторых, вы можете таких маршрутов бросить довольно много. Если говорить про, например, дата-центровые дизайны, мы все-таки сейчас оперируем терминами сеть предприятия, но дата-центр тоже специфические у них есть заморочки. Там, в принципе, OSPF в некоторых ситуациях можно вообще довести до конечного сервера. И дальше уже конечный сервер вам будет выбрасывать IPшники, соответствующие определенным сервисам. У вас висит сервер, на нем есть, соответственно, сервис, там, не знаю, SMTP и сервис POP3. Вот. И он отдельно IPшник вбрасывает, говорит, я вбрасываю LSA-ку пятерку SMTP-шного IPшника, я вбрасываю LSA-ку пятерку POP3-шного IPшника. И у вас тогда трафик балансируется

не просто вот по IPшникам, а именно по сервисам, которым соответствуют отдельные адреса. Очень интересная вещь, на самом деле, и в определенных дизайнах оно даже имеет право на существование. Единственное, что если у вас прям совсем много серверов и совсем много сервисов, то в этой ситуации OSPF начинает хереть, потому что он, опять же, не заточен под большое количество сервисов, и в этой ситуации лучше переходить на протокол, который лучше адаптирован под большие масштабы. Ну, вы догадываетесь, да? BGP. Но, тем не менее, OSPF до определенных масштабов тоже вполне себе неплохо с этим справляется. Могу привести пример. Есть такой поисковый... Как это назвать? Поисковая система. Называется Яндекс. И у нее в начале 2000-х как раз было довольно... Ну, как начало, середина 2000-х было довольно много серверов, но, в принципе, их было все еще разумное количество. И вот там как раз OSPF приходил на сами сервера, и сервера эти анонсировали LSA-ки пятерки для сервисов.

То есть на каждый сервис, на каждый IP-шник сервиса выбрасывался отдельный LSA-ка пятерка. И все это работало, в принципе, неплохо до тех пор, пока количество маршрутов внутри сети не стало расти довольно бурно. И примерно к тому же периоду как раз относится известная ошибка, когда случайно в OSPF запихали лишние маршруты из интернета. То есть фактически весь интернет взяли и запихали в OSPF. Ну и, естественно, все OSPF роутеры от такого офигели и задымились, и сдохли. Но, тем не менее, да, в тот момент уже админы Яндекса вполне себя осознавали, что пора переходить на другой протокол, на BGP, который будет лучше заточен под большое количество маршрутов. И тот известный фейл с редистрибуцией BGP в OSPF, он только лишь подстегнул процесс перехода на BGP. Ну и сейчас, естественно, у Яндекса BGP внутри сети. Так, в любом случае, да, вы можете вбрасывать LSE-ки пятерки и тем самым

сократить количество информации внутри ваших регионов. Чем хорош такой подход? Тем, что у вас фактически идет, опять же, обособление маршрутной информации и адресной информации. Адресная информация идет в виде LSE-ек пятерок, топологическая информация, кто на кого как смотрит. Это LSE-ек первого и второго типов. Вы можете взять, соединить роутер между собой. В LSE-еках первого и второго типов у вас не содержатся всякие вот эти вот коннект от сетки. Пропадание какой-то сетки или поднятие нового интерфейса, на котором у вас нет соседств, не вызывает смену топологической информации. И, соответственно, все вот эти вот IP-шные части, все именно маршруты, которые у вас есть, они могут появляться, могут гаснуть. И появление новой LSE-ек пятерки, оно не вызывает смену топологии. Да, оно вызывает смену содержимого LSDB, но оно не вызывает смену топологии. Не надо запускать пересчет кратчайшего пути в графе.

В случае, если вы берете и вбрасываете сетки как просто обычный connected network, включаете SPF-ный интерфейс, и у вас connected сетки с этих интерфейсов включаются в анонс. Если вдруг этот интерфейс погаснет, у вас новая LSE-ека первого типа выпускается, она все роутеры разлетается в пределах региона, и все роутеры запускают пересчет топологии, пересчет кратчайшего пути в графе до всех сетей. Поэтому, если у вас сетей много, но не очень много, то имеет смысл как раз вбрасывать их в виде LSE-ек пятерок. Вы, получается, разделяете построение топологии по LSE-екам первого типа и перетаскивание адресной информации по LSE-екам пятого типа. Это намного удобнее, намного стабильнее работает, чем просто все загонять, вообще все в один регион, включая кастомерские маршруты. Соответственно, если вы хотите что-то скрыть в OSPF, то вы это не можете сделать внутри региона. Все роутеры внутри региона, всю информацию, которая получена в LSE-еках первого и второго типа,

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

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

все, дальше все роутеры в регионе получателя получат лосейки мелкие, и обмануть их уже будет нельзя. Но если он скроет то, что мелкие лосейки существуют, и вместо них вбросит одну крупную, то, соответственно, да, он. Вот он, если это сделает, то все роутеры будут знать про существование одного крупного префикса. Сразу возникает вопрос, а с метрикой чего у нас будет? То есть, когда мы рассказываем, что у нас сетка есть за нашим роутером, за АБРом в другом регионе, мы рассказываем, как мы эту сетку знаем. И в случае с агрегацией у нас получится, что у нас есть несколько мелких сеток, которые, возможно, известны через разные пути, через разные трассы, и, соответственно, метрика у них будет разная. У нас есть на АБРе одна мелкая сетка за 10 копеек, вторая мелкая сетка за 20 копеек, третья мелкая сетка за 30 копеек. А мы вот берем и говорим, все сетки доступны через нас, но мы можем только одну метрику положить в метрику агрегированного маршрута.

И RFC 1583 устаревший говорит, что метрика агрегатного маршрута должна быть минимальной метрикой его компонентов. То есть вот если мы знаем хотя бы одну сетку хорошо, то мы говорим, что мы всю сетку знаем хорошо. RFC 2328 меняет это поведение, и актуальное поведение на других, вот более свежих узлах будет другое. Метрика агрегатного маршрута будет максимальной метрикой его компонентов. То есть вот мы настолько плохо знаем всю сетку, насколько плохо мы знаем самую плохую, самую дальнюю мелкую часть этой сети. Даже если вдруг у нас есть вся сеть, которую мы знаем хорошо, все отдельные компоненты мы знаем хорошо, но один маленький компонент находится где-то, где-то далеко, вот в этом случае мы будем агрегатную метрику отправлять, что мы знаем всю большую сетку где-то там далеко. По умолчанию CISC работают в 1583 RFC. То есть они будут отправлять минимальную метрику агрегатного маршрута. Покажу сейчас на примере. У нас есть роутер, у него есть три интерфейса в регион,

здесь три соседа. Вот здесь у нас метрика 10, здесь 10, здесь 100. Каждый из соседей отправляет, что он знает какую-то сетку за одну копейку. И все эти сетки, это будут там 10.0.1.0.24, 10.0.2.0, 10.0.3.0. Вот мы наружу хотим отправить указание 10.0.0.0.16. И метрику, которую мы выберем, мы скажем, самая маленькая метрика здесь 11, самая большая метрика 101. Вот если мы работаем в RFC 1583, то мы скажем, мы знаем эту сетку за 11 копеек, всю целиком. Если мы работаем в 2328, то мы скажем, 101 копеек будет. CISC работает в RFC 1583, напомню. Поэтому они отправляют по умолчанию минимальную метрику. Но можно это поведение изменить, сказать, что надо работать в RFC 2328, и тогда у вас будет метрика максимальная. Если вы анонсируете суммарку, то в этом случае вы должны будете делать это одинаково на всех роутерах в пределах региона, потому что если у вас есть вот регион 1,

регион, ну, допустим, 0, и у вас два АБРа рассказывают про то, что какие-то сетки есть, то, соответственно, вы на обоих роутерах должны одинаково сказать, что у нас мелочевки не существуют, а вместо нее есть суммарка 100. 0,16. Потому что если вы анонсируете на одном суммарку, а на другом вместо суммарки вы анонсируете 10, 0, 1, 0, 10, 0, 2, 0, 10, 3, 0, то, соответственно, на роутеры внутри того региона придет отдельно суммарка и отдельно куча мелочевки с 24 масками. И когда трафик будет приходить на этот роутер, он скажет, по правилу Longest Prefix Match, я выбираю маршруты, у которых метрика числа больше. И, соответственно, трафик будет ходить через тот роутер, который не выполняет суммаризацию. Поэтому если вы выполняете суммаризацию, агрегацию, то, пожалуйста, делайте это однотипно на всех АБРах в регионе. Равным образом и фильтрация маршрутов. Если вы где-то зафильтровали маршрут, то вы должны будете фильтровать его везде. Нигде нельзя скрыть информацию о том, что сетка какая-то существует. Если вы в одном месте не придумали

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

Опять же, вы должны будете придумать метрику, но метрику в SPF на лосейке пятерки надо придумывать в любом случае. Если в лосейке трешке метрика у нас вычисляется автоматически, и поэтому, когда мы агрегацию делаем, нам надо какой-то автоматический метод придумать, какая метрика будет, то с пятеркой метрику в любом случае мы задаем руками. И там задачи вида, как выбрать метрику, особо не стоит. Так, опять же, если у вас несколько роутеров выполняют агрегацию сеток или редистрибуцию вообще в целом, то вы должны на них сделать одинаковое поведение, фильтрацию делать одинаково, агрегацию делать одинаково. В противном случае вы не добьетесь своей цели. Если вы скажете, что у нас есть два роутера, которые из EJRP перекладывают маршруты в SPF, и на одном роутере вы в SPF зафильтровали какую-то сетку, а на другом нет, то все равно весь трафик до этой сети сможет пройти просто через другой роутер. Равным образом, если вы на одном роутере сделали агрегацию, а на другом не сделали, то другой роутер будет анонсировать кучу мелочевки, трафик по longest prefix match правилу

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

А в других регионах, ну просто получат LSA-ки трешки или не получат LSA-ки трешки. Трешка не вызывает пересчет топологии. Трешка — это не топологическая информация. Трешка — это чисто адресная информация, которую мы просто как в дистанц-векторном протоколе получаем и говорим, окей, мы будем знать, что через АБР можно добраться до этой сети и все. Вот. Вы можете на АБР при перекладывании маршрутов между регионами фильтровать маршруты и агрегировать эти маршруты. Но это сделать можно только на АБР, то есть внутри региона сделать это нельзя. С регионами все тоже не так просто. Если вы думали, что все хорошо и красиво, то да, хорошо и красиво было в RFC 2328, но потом появилось тяжело. И это тяжело заключается в следующем. Регионы бывают разные. Бывают регионы нормальные, ну просто обычные регионы, Regular Area — это вот регионы, ну как те, которые не нулевые.

Есть регион нулевой, он же транзитный, он же регион позвоночник, он же Backbone Area. К нему можно подключать все остальные регионы. Это то, что мы с вами уже прошли. То есть вот эти два типа, Backbone Area и Regular Area, мы с вами уже видели. Проблема в том, что кому-то этого не хватило, и кто-то пришел к условной ЦИСКе и сказал, ЦИСК, а давай ты сделаешь нам еще разных других типов регионов, потому что нам вот этих вот не хватает. И не хватает нам их в следующем. Если у нас есть OSPF, и в этом OSPF мы указываем, кто на кого каким интерфейсом смотрит, мы все сделали хорошо, правильно, то мы сократили тем самым количество вычислений. Ну, соответственно, мы разнесли топологическую информацию по разным регионам, по разным ариям. Мы сделали то, как ты рекомендовала. Вбрасывали LLC капитерки на каждом сервисе, там, где у нас были connected сетки или сервисные сетки, кастомерские. То есть у нас вот здесь вот, например, были кастомерские сетки,

мы их в виде LLC капитерки вбрасывали. Здесь были LLC платформы, и моя сетка из beneficiarства мы их в виде LLC капитерки вбрасывали. Здесь тоже были кастомерские сетки, тоже в виде LLC капитерек вбрасывали. Мы не могли их скрыть, потому что, да, мы можем только либо зафильтровать, либо не зафильтровать Но в итоге получается, что мы про все эти сетки вынуждены рассказывать Они ни во что не суммируются, они вот просто в виде отдельных LSA-к пятерок бегают И получается, что на каждом роутере мы вбрасываем кучу LSA-к пятерок И у нас этих LSA-к пятерок становится слишком много Да, если у вас большая сеть, получится, что действительно пятерок в такой сети И если оно построено по принципу кастомерские сетки вбрасываем виде LSA-к пятерок Этих LSA-к становится слишком много И некоторые люди сказали, слушайте, а вот какой смысл в том, что мы знаем, что вот эти LSA-ки пятерки Вот эти LSA-ки пятерки, вот эти LSA-ки пятерки, вот эти LSA-ки пятерки, вот эти LSA-ки пятерки Они отдельно существуют Если вот у нас есть, например, регион седьмой У него вот на этом роутере есть огромное количество LSA-к пятерок

В том числе вот эти, вот эти, вот эти, вот эти Он по-честному считает, как до них добраться Находит LSA-ку четверку Находит кратчайший маршрут до АБРа, который прислал четверку Складывает с тем, что в четверке было написано, сколько стоит добраться до АСБРа Складывает это с тем, что написано в LSA-ки пятерки Или не складывает, если LSA-ка пятерка второго типа Ну короче, он по-честному вычисляет все для каждой отдельной LSA-ки пятерки Вот куча-куча-куча этих пятерок есть Он по всем вычислениям это делает И все ради того, чтобы сказать, next hop'ом будет вот этот вот роутер И он по каждой из этих сетей скажет, next hop'ом будет роутер АБР В таком сценарии получается, что мы сделали огромное количество вычислений Пусть это не кратчайший путь в графе Пусть это не алгоритм Декстра Но все равно это как бы пересчет информации Мы все равно тратим процессорные циклы И все это ради того, чтобы сказать, тот АБР, который прислал нам четверку Вот он и будет АБР До него и надо построить маршрут

В любом случае, никто другой, кроме АБРов Не может являться выходной точкой из региона для внешнего трафика В этой ситуации можно сделать следующее Можно сказать, давайте мы скажем, что определенный регион у нас будет особенный Вот определенный регион у нас будет называться Stub Area И это значит, что он будет нетранзитный Ни в каком смысле нетранзитный То есть в нем самом не может быть вариантов, как добраться до каких-то внешних сетей Кроме как выйти через АБР И в этой ситуации мы скажем, что в этом регионе не должно появляться пятерок вообще Сделаем так, чтобы у нас в этом регионе вместо всех пятерок Которые по-честному приходится обрабатывать Появлялся только бы один маршрут до АБР 0.0.0.0 Вместо LSA и пятерок вбрасываем только дефолт Вообще всех То есть вместо вот этих всех Вместо вот этих всех То есть их приходит там миллион Вместо этого миллиона мы получаем один маршрут дефолтный

И говорим, любой трафик, который мы хотим выпустить наружу Вот он будет через АБР доступен Это заметно сокращает нагрузку на вот эти вот роутеры Которые находятся внутри такого тупикового региона И, соответственно, если вы такую штуку делаете То действительно вот нагрузка на роутеры внутри такого региона сильно сокращается Cisco это сделала И потом выяснило, что есть нюанс Что некоторым хочется, чтобы трафик до всех-всех-всех юзерских сетей ходил по-честному То есть через АБР А вот трафик, допустим, до интернета Все-таки через АБР не ходил Потому что вот здесь вот у нас есть свой собственный выход в интернет, например И получается, у нас есть один дефолт, который присылает нам АБР Что трафик можно пустить до всех сетей туда И есть отдельно другой, например, дефолт Или какие-то другие вот сети Через которые надо выйти внутри своего региона И получается, что в этом регионе мы пообещали, что пятерок не будет, а нам вот как-то надо туда пятерку вбросить. И вот для этой штуки придумали not-so-stubby area.

Это не совсем тупиковый регион, в котором можно вбрасывать внешние маршруты, они там допустимы. Но поскольку в стабах мы уже сказали, давайте пятерок не будет вообще, то есть просто LSA-ки пятерки внутри стаба не распространяются, то, соответственно, вот эти вот NSSA, not-so-stubby area, они допускают появление внешних маршрутов, но не через LSA-ку пятерку. А чтобы выйти из ситуации, пятерки-то уже нельзя, сказали, давайте мы сделаем копипаст LSA-ки пятерки, просто назовем LSA-кой семеркой. И вот в NSSA, в not-so-stubby area, есть, соответственно, возможность вбросить пятерку, в которой написано, что это не пятерка. То есть она просто переименована. Формат у нее абсолютно точно такой же, содержимое точно такое же, поведение точно такое же. Ну, соответственно, да, вот внутри региона у вас будет LSA-ка семерка распространяться. Но возникает вопрос, а дальше что с ней делать? Ну, мы вбросили какую-то вот сетку в седьмой регион, а дальше надо ее взять и переложить в дефолт, получается. И действительно, АБР, который будет получать LSA-ку семерку от какого-то своего внутреннего NSSA-соседа,

он будет ее перекладывать в весь остальной мир, но во всем остальном мире уже не знает, что такое семерки, поэтому он генерит просто обычную пятерку. И с точки зрения всего остального мира, АСБР им будет являться именно он. Хотя на самом деле АСБР будет вот кто-то другой внутри NSSA-стаба. Вот. Кроме того, ЦИСКО на это дело посмотрела и сказала, что можно это еще улучшить, что бывает тотали стаб, в котором еще, например, и трешки фильтруются, или тотали ноцсо стаби эре, полностью не такой уж и стаб регион. Если вы подумали, что это бред сумасшедшего, да, это бред сумасшедшего. И все это на самом деле жуткие костыли, которые привели на самом деле к тому, что ОСПФ использовать в определенных сценариях абсолютно бессмысленно, потому что если вам нужны вот эти вот самые тотали ноцсо стаби эре, то имеет смысл просто заморочиться на BGP, переделать всю сетку на BGP и радоваться жизни. В общем, давайте разбираться, что такое стабы, не стабы, стабы, но не совсем,

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

эта LSA-5 распространяется во все остальные регионы, в том числе и в 0. И АБР, который перекладывает эту LSA-5, он ее в неизменном виде перекладывает. Он указывает, кто автор. И автор здесь у нас будет какой-то, не знаю, роутер 1. Ну, здесь будет написано роутер 1 автор. Чтобы добраться до этого роутера 1, у нас LSA-4 прикладывается, в которой она рассказывается, как добраться до сети B, до роутера R1. Так, да. Кроме того, на самом деле, в этой ситуации, если это будет NSSA-регион вот здесь вот, то тогда еще будет появляться дополнительная задача транслировать семерки в пятерки. Ну, про это отдельно поговорим. Если у нас есть просто обычный нормальный регион, все, что зарождается в нулевом регионе, это LSA-ки первого типа, маршруты, которые здесь в LSA-ках первого типа содержатся. То есть маршрутная информация, не топологическая, а именно маршрутная информация из LSA-ки первого типа, она перекладывается в LSA-ки третьего типа вне нулей.

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

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

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

Это не совсем стандартный термин, то есть с точки зрения стандарта, это просто обычный стаб-регион. Но с точки зрения поведения АБРа, вот можно сказать на АБРе, что поведение АБРа должно быть таким, чтобы сократить еще большее количество маршрутов в тот или стаб-регионе. Делается это именно на АБРе, это именно поведение АБРа, не стандартное, но, тем не менее, оно очень популярно, и у многих вендоров оно реализовано. Смысл заключается в следующем. Если у нас есть регион, в котором есть несколько роутеров, АБРов, АБР1, давайте АБР1, АБР2, они стоят где-то рядышком друг с другом. Есть какие-то роутеры внутри этого региона, которые с обоими АБРами, скорее всего, связаны. Ну, достаточно типичный дизайн, когда у нас ставятся два АБРа, и дальше к ним подключаются все остальные. Если мы делаем обычный стаб, то мы говорим, у нас есть LSE-ки трешки, которые получены перекладыванием первых LSE-к,

у нас есть LSE-ки трешки, получены третьими LSE-ками, у нас есть LSE-ка трешка с дефолтом, который получен с суммированием всех LSE-к пятерок в нуле. Но получается, что если у нас есть маршруты нулевого региона и маршруты других регионов, которые зародились в нуле в виде LSE-к первого или третьего типов и переложились в LSE-ке третьего типа в наш ненулевой регион, то, соответственно, получится. Есть LSE-ка трешка, что все сети в мире доступны через АБРы, через оба АБРа. А кроме того, есть еще какое-то количество сетей, которые тоже доступны через эти два АБРа. И какой смысл в том, что мы рассказываем, что вот такая сетка доступна, всякая сетка доступна, пятая сетка доступна, десятая сетка доступна и все остальные сетки тоже доступны через оба АБРа. Какой в этом смысл, если оба АБР идентичны и равноправны? Смысла нет. Поэтому Totalist Tab включается на АБРе, и АБР говорит, я буду фильтровать не только LSE-ки пятерки, вместо них делать LSE-ку трешку с дефолтом, а я вообще все-все-все-все маршруты буду фильтровать и вместо них выбрасывать дефолтный маршрут.

Вот. Это именно нестандартная фича. В стандарте она не описана, но в стандарте описаны все отдельные компоненты этого поведения. Что если у нас есть LSE-ка пятерка, вместо нее мы выбрасываем трешку с дефолтом, и все остальные сетки мы просто фильтруем. Мы говорим, вот здесь вот мы хотели бы вбросить LSE-ку трешку, здесь хотели бы вбросить LSE-ку трешку, но мы имеем право их зафильтровать. Имеем. Получится ли у нас LSE-ка трешка из LSE-ки пятерки? Получится. Ну и поэтому да, все это поведение, хоть и не описано в стандарте, но оно, тем не менее, стандарту не противоречит. Важно здесь понимать, что роутеры, которые будут не АБРами, а просто обычными интернал роутерами в таком стаб-регионе, тот или стаб-регионе, они не обязаны знать, что им там чего-то зафильтровали. То есть с их точки зрения это будут просто обычные стабы. Ну и да, про NSSA, это я уже в принципе сказал, что NSSA-регион это стаб, в котором могут появляться внешние сети. И соответственно да, с точки зрения вбрасывания маршрутов

в этот регион, это обычный стаб. LSE-ки первого типа вкладываются в виде LSE-ки, маршруты, полученные по LSE-кам первого типа на АБРе, перекладываются в виде LSE-ек трешек, маршруты, полученные по LSE-кам трешкам, перекладываются в виде LSE-ек трешек, пятерки не перекладываются, вместо всех LSE-ек пятерок вбрасывается LSE-ек трешка, но поведение not so stubby area будет отличаться от поведения обычного стаба в том, что вы можете завести ASBR внутри сети. То есть если вы попытаетесь включить редистрибуцию на обычном стаб роутере, он скажет, извините, не могу. А вот если вы включаете NSSA-регион и на нем включаете ASBR, то есть говорите, возьмем какие-то маршруты биджепишные и начнем их перекладывать в наш NSSA, то вы вместо LSE-ки пятерки, которые запрещены в стабе, генерите LSE-ку семерку. И вот эта вот семерка распространяется на все роутеры в регионе, а все роутеры строят кратчайший маршрут до ASBR, включая ABR. Он тоже строит кратчайший маршрут до ASBR.

И дальше ему надо рассказать, что вот эта вот сетка, она известна в стабе и она должна быть известна везде в остальных сетях тоже. Поэтому он перекладывает маршрут, полученный в LSE-ке семерки, в нулевой регион. Но в нулевой регион он не может положить семерку, зато он может положить пятерку. Фактически пятерка и семерка это одно и то же, по сути. Это одно и то же сообщение, просто у него тип 5 и 7, а так формат сообщения одинаковый. Поэтому он просто переименовывает эту LSE-ку, говорит, что это маршрут, который ко мне пришел. Вот я сообщаю, что эта LSE-ка будет пятерка. Но с точки зрения логики, это уже новая LSE-ка. Да, сетка там та же самая, но это получается, что пятерку придумал уже не тот ASBR, который был оригинальный, а придумал ее ABR. Вот. И поэтому он говорит, можете добраться до меня, и дальше на мне эта сетка есть. И он указывает стоимость, какую-то, да, как можно добраться до этой сети через внешний мир, через вот этот вот NSE-регион.

он указывает свой роутер ID в ASBR, он указывает forwarding address, и он указывает стоимость LSE-ки, которая прибежала в LSE-ки семерки, с указанием, что вы, пожалуйста, посчитаете кратчайший путь до вот этого роутера ASBR, IP-шника ASBR, и, соответственно, вы, пожалуйста, прибавьте к этому стоимость LSE-ки семерки, которую я вкладываю вам в виде LSE-ки пятерки. То есть стоимость LSE-ки пятерки не меняется относительно семерки. Но для того, чтобы сказать, что, ребят, вот это не моя стоимость в таблице маршрутизации, это вот его стоимость в таблице маршрутизации, здесь как раз forwarding address проставляется. Это единственный случай, когда forwarding address имеет смысл. В LSE-ках пятерках вы можете задать forwarding address просто так, если захотите, но это будет, скажем, в большинстве ситуаций излишне. А вот при перекладывании семерок в пятерки, при трансляции семерок в пятерки этот forwarding address уже начинает иметь смысл. Если бы его не было, то вы должны были бы сказать, ребята, стройте маршрут до меня,

а дальше за моей спиной эта сетка будет иметь определенную метрику. Но здесь возникает вопрос. Маршрут к нам пришел, вот, например, по BGP. У него было, ну, у него метрики нет, у него есть атрибуты. Мы вместо BGP-шных атрибутов сказали, у нас есть LSE-ка семерка с метрикой, ну, например, 10. И метрика будет, соответственно, второго типа в долларах выраженная. Вот. И сразу возникает вопрос, если мы делаем LSE-ку пятерку, то мы должны будем указать, что вот у нас есть LSE-ка пятерка, которая указывает, что есть какая-то внешняя сетка на другом роутере, которая стоит 10 долларов и 20 копеек. Вот как про копейки рассказать в этой LSE-ке пятерке? Никак. Он говорит, я рассказываю про то, что стоит 10 долларов, и говорит, что построите, пожалуйста, кратчайший маршрут до вот, до того АСБР, который на самом деле это все придумал. И роутеры, которые будут строить кратчайший маршрут, они, соответственно, вот это вот сами посчитают внутреннюю метрику самостоятельно через LSE-ке четверки. Вот таким вот образом, таким вот образом,

да, у нас роутеры смогут все построить полную таблицу. Зачем нужен NSSA? Для того, чтобы иметь возможность внутри региона избавиться от LSE-к пятерок чужих, но тем не менее иметь выбрасывать возможности LSE-ке пятерки, ну, в кавычках, пятерки, семерки на самом деле, свои. Как раз дизайн, при котором вы, например, кастомерские сетки вбрасываете, вы как раз говорите, давайте дистрибьюшн блоки все разделим на отдельные регионы. Один дистрибьюшн блок это отдельный регион. В каждом дистрибьюшн блоке все свои сетки будут известны в виде LSE-к семерок. В каждом дистрибьюшн блоке чужие сетки будут известны в виде дефолта, который приходит от АБР. Так, вот. Это с NSSA. Есть totali NSSA. Полностью не совсем стаб. Смысл тот же, что в обычном totali стабе. То есть, мы вместо LSE-к, пятерок, трешек

и сеток, полученных из LSE-к, единички, вбрасываем только один дефолт, но при этом мы разрешаем появление АСБРов. АСБР точно так же себя будет вести. Он вбрасывает LSE-ки типа пятерки, но на самом деле семерки. И вместо LSE-к семерок пятерка вбрасывается АБР. Ну, опять же, он указывает стоимость LSE-ки семерки в пятерке, свой роутер ID в качестве того, кто придумал эту LSE-ку, но при этом ID-шник настоящего АСБРа, айпишник настоящего АСБРа в forwarding address. То есть, если какие-то другие роутеры вот здесь получают указание, что у нас есть LSE-ка пятерка, они говорят, что мы метрику будем считать не до АБРа, а до айпишника вот этого вот АСБРа. И, соответственно, стоимость этой LSE-ки пятерки первой или второго типа мы будем прибавлять или не прибавлять к метрике до айпишника АСБРа. Вот. Такая вот штука. Опять же, да, тот или NSSA,

концепция, которая придумана циской, которая нестандартная, в стандарте нет такого слова, но, тем не менее, очень многие вендоры так себя ведут, действительно. Вот. Внутри тотали стаба и тотали NSSA все внешние сетки для OSPF, то есть те, которые получены из нуля, превращаются в один-единственный дефолт. При этом можно вбрасывать дополнительно какие-то маршруты, которые прибегают из внешних источников. Вы можете внутри NSSA региона редистрибутить что-нибудь в OSPF, и оно будет дальше порождать LSE-ки-семерки, которые будут в свою очередь транслироваться в LSE-ки-пятерки. В каждом сообщении OSPF включая сообщение Hello, что наиболее важно есть, поле Options. И на самом деле, когда у нас будет устанавливаться соседство, там будут проверяться некоторые параметры, в частности, вот, будет проверяться в Hello сообщениях номер региона, будет проверяться совпадение

и несовпадение роутера ID, будет проверяться парольная информация, таймеры, и еще проверяются флаги, E и N это флаги, отвечающие за то, какого типа будет ваш регион. То есть, когда у нас два роутера начинают пытаться подружиться между собой, они начинают друг другу посылать Hello сообщения, и в этих сообщениях они указывают, каким регионам они посылают это Hello сообщение, и что за свойства у этого региона есть. Первая опция, это флаг E, будет означать, что вы поддерживаете LSA пятерки. То есть, это регион либо нормальный регион, либо транзитный. То есть, либо, ну просто, да, нулевой регион, либо ненулевой, но нормальный, просто обычный regular area. Если вы указываете там нолик, то значит, что в этом регионе не поддерживают LSA пятерки, как следствие это стаб, какой-то из стабов. Вот, обратите внимание, здесь флаг не то,

что мы хотим объявить, что это регион стаб. Нет, мы единичку указываем для того, чтобы показать, что это регион не стаб, либо нормальный, либо транзитный бэкбон. Если это стаб, то в этом случае вы должны будете сказать, какой это стаб. Либо стаб нормальный, либо стаб NSSA. И для этого у вас есть другой флаг, который называется nbit, если это единичка, то в этом регионе поддерживаются LSA-ки семерки. Соответственно, это значит, что это NSSA. Вот. Если вы хотите сказать, что это просто обычный стаб, то это значит, вот тут будет нолик. То есть, обычный у нас получается регионы нулевой и обычный regular area. У нас здесь получается 1,0. Если это стаб, просто обычный стаб, то там получается 0,0. И NSSA получается

0,1. То есть, вот так вот. При установлении соседства эти флаги проверяются, поэтому все маршрутизаторы в регионе должны быть одинаково настроены в смысле установки вот этих флагов. То есть, если у нас есть роутер, который говорит, что я работаю в регионе номер 7 и этот регион я считаю NSSA регион, то все регионы, все роутеры в этом регионе должны считать, что регион 7 это действительно NSSA. Не получится сделать так, чтобы у вас один роутер с другим роутером дружил и один говорил, я отправляю этот hello-пакет в area, допустим, 9 и считаю это NSSA. А второй говорил бы, я считаю, что это area 9, area 9, но это не NSSA, это просто обычный стаб. У вас будет не совпадение флага nbit и, соответственно, вы не подружитесь. Если вы заказываете totalistab и total NSSA, то это поведение, настройка, это локально для АБРа, они влияют на то, как он перекладывает LSE кетрешки, и никаких специальных

флагов там нет. То есть, вы можете сказать, что у вас с одной стороны NSSA, а с другой стороны на АБРе вы указываете, что area 9 у вас будет total NSSA. Это никаких проблем с этим нет. Вот это total не требует никаких специальных извращений в содержимом пакетов. Это просто то, какие LSE вы генерите. Запоминать то, что это в поле options, запоминать там значение этих флагов не нужно. Нужно просто понимать, что настройки стабовости NSSA вности региона проверяются при установлении соседства. Есть еще один битик. Этот битик будет указываться внутри LSE-ки пятерки. Пардон, внутри LSE-ки семерки. Битик будет следующий. Он будет называться P-bit и он будет указывать, нужно ли эту семерку перекладывать в пятерки. Смотрите, какая ситуация. Представьте себе, что у нас есть регион,

который NSSA. Этот регион, естественно, не нулевой и у нас есть АБРы. АБР1, АБР1, АБР2. Эти АБРы находятся между NSSA, нашим регионом, и нулем. Вариантов других нет. Если один из регионов не нулевой, второй должен быть нулевой. В NSSA у нас есть внешний роутер, который является ASBR. Если бы он был вот здесь, никаких проблем бы не было. Он сделал бы семерку, эта семерка транслировалась бы в пятерки, дальше бы уже работало то, что мы с вами обсуждали. Но есть нюанс. И заключается этот нюанс в том, что ASBR может быть сам АБР. Вот этот вот. И в этой ситуации получается, что если у вас АБР есть, и он же ASBR, то он генерит и пятерку, и семерку. Потому что, ну, получается, да, что он в нулевой регион смотрит, он в этом регионе нулевом сам же сделает пятерку про себя. И он рассказывает, что, ребята, я буду вот раз, я буду

ASBR, ходите, пожалуйста, до какой-то внешней сети через меня. И дальше он в NSSA регион тоже рассказывает, что я могу до этой сети добраться. Он делает и лосевику семерку, в которой рассказывает, что да, через меня можно до этой сети добраться. Но, если у вас есть другой АБР, то эта семерка дойдет до другого АБР, и другой АБР сделает еще одну пятерку с указанием ходите через меня до этой сети вот через АБР1. это поведение было бы нежелательное, потому что, на самом деле, никакой новой сети здесь не появляется, и вот этот вот вброс лишней пятерки, он будет не нужен. Поэтому для того, чтобы не транслировать семерку в пятерку, вы можете поставить вот этот вот P-bit и заставить его не транслировать в нулевой регион другим АБРом эту семерку, что она уже как бы транслирована, что это ее придумал АСБР, который является АБРом, и он уже транслировал все, что нужно. Смысл этого поведения

именно в том, чтобы из одной сетки сделать одну пятерку на одном единственном АСБРе. Если у вас есть несколько АБРов, и давайте сейчас еще один пример разберем. Если у вас есть несколько АБРов и АСБР, который где-то вот тут находится, он говорит, я могу добраться до какой-то внешней сети. Вот он при BGP получает какие-то маршруты и перекладывает семерку в НССА регион. То есть у нас это уже не вот здесь приходит, а вот здесь LSA-7 генерится. И эта LSA-7 доходит до одного АБРа, до другого АБРа. И получается, что в этой ситуации семерку транслировать в пятерку должны будут оба АБРа. Ну, как бы получается, да? Но опять же, нехорошо, что у нас семерка была одна, а транслировалась она бы в две. Поэтому для того, чтобы в такой ситуации не получить вместо одной семерки две пятерки, есть дополнительное правило.

АБР с наибольшим роутер-ID будет выполнять трансляцию в НССА регионе из семерок в пятерку. То есть в этом случае у вас роутеры в НССА регионе знают ID-шники друг друга. Они по НССА региону уже дружат. Они же знают, какие ID-шники у кого-то есть. И если АБР видит какой-то другой АБР, у кого роутер-ID больше, он не выполняет трансляцию семерки в пятерку. А если он видит, что роутер-ID у него самый большой, то он как раз ее выполняет. Поэтому вот эти вот два АБРа, они посмотрят на ID-шники друг друга и скажут, соответственно, что у одного из них ID-шник больше, поэтому семерки чужие он перекладывает в пятерки. А другой скажет, нет, я не перекладываю семерки в пятерки, потому что у меня ID-шник в этом регионе не самый большой среди всех АБРов. Вот. Это уже не про P-bit, это просто про поведение, что если у нас есть семерка, то только один роутер в топологии по умолчанию перекладывает эту семерку в пятерку. Это поведение можно отключить.

То есть, если вам это не нравится, вы можете сказать, что-то как-то сложно, давайте перекладывать семерки в пятерки на всех роутерах. В принципе, вы можете это сделать, это не повлияет на поток трафика, но тем не менее, да, если вы захотите, вы можете включить на цисках, например, поведение, что да, что семерки в пятерки транслируются везде. Вот. Кроме того, есть еще одно замечание, что вот этот вот самый битик, который, давайте на предыдущий слайд вернусь, битик, вот этот вот nbit, который указывал на флаг, что этот флаг указывает на то, будет ли наш регион на SSI или нет, на самом деле именно этот битик будет называться pbit. То есть, если мы в hello сообщениях устанавливаем соседство, нам интересно знать, что роутер думает по поводу состояния нашего

стаба, будет ли он NSI или нет. Но если вы уже установили соседство, вы уже перекладываете LSA, то на самом деле вам внутри самой LSA этот флаг уже не сильно нужен. И он превращается вот в этот самый pbit. То есть, это на самом деле один и тот же битик, просто у него такая двойственная природа. Так. Опять же, на экзамене вам вряд ли это понадобится, понимание того, что там есть какие-то вот эти вот флаги, которые влияют на поведение. Но, пожалуйста, запомните, что по умолчанию LSA 7 в пятерке перекладывает только один роутер. И это роутер, у которого ID внутри региона будет больше. Если вдруг, соответственно, мы перекладываем LSA 7 в пятерке и вдруг у нас роутер ID соответственно не самый большой, то мы можем заказать, что определенная семерка в пятерке не перекладывается. И делается это с помощью отдельного флажка. Так, что получается?

У нас есть маршруты нормальные, полученные внутри региона и intra-area. У нас есть маршруты между регионами через LSA 3. у нас есть маршруты через LSA 5 полученные. Причем у них есть там разные флаги, есть разные типы и есть маршруты из NSSA. Как в случае, если у нас одна и та же сетка получена из нескольких источников, из нескольких, скажем, LSA разных, как выбрать, какой способ нам будет больше нравиться? В случае с обычным классическим RFC 2328 то предпочтения там были очень простые. LSA 1, LSA 3, LSA 5 и все. Здесь возникает вопрос. Соответственно, у нас есть LSA 1, 3, 5, 7, у нас есть разные метрики типа 1, типа 2 и у нас есть еще вот эти вот всякие там флаги, которые мы только что разобрали. Эти флаги будут на что-то влиять. Ну, соответственно, вот RFC 3101, который рассказывает про то, что есть такая штука, как NSSA, он говорит,

что предпочтение маршрутов будут следующие. Если у нас есть маршрут внутри нашего региона, это intra-area маршрут, полученный по LSA 1 типа. Это самый выгодный способ. То есть, другого нам уже не нужно. Если у нас есть маршрут внутри региона и маршрут какой-то еще через другие регионы, например, или через какие-то внешние источники, то мы всегда предпочитаем USPM-овский intra-area маршрут, несмотря на стоимость. То есть, если у нас есть два роутера, которые связаны, может быть, даже напрямую между собой, но они связаны через регион area 1. И у них есть вот такой вот большой, большой, большой, большой, большой способ пойти в обход. И, соответственно, вот здесь у нас какие-то другие роутеры будут в обход. Я специально рисую такой очень большой обход, но, тем не менее, да, это большой обход. И вот эта вот штука у нас area 0. И, соответственно, у нас внутри area 0 вот здесь вот есть

какая-то сетка, сеть А. То роутер, который находится в нулевом регионе, до сетки, который находится в нулевом регионе, будет идти по своему региону в обход. Никогда не пойдет через другие регионы. Потому что здесь он узнает эту сетку через LSE 3, а здесь он увидит эту сетку по LSE 1 типа. Поэтому он предпочтет intra area маршрут, невзирая на стоимость. Дальше. Если у нас есть LSE 1 типа, мы считаем по ним. Если у нас нет LSE 1 типа, то тогда мы предпочитаем intra area маршруты. Маршруты, которые получены из другого региона, но, соответственно, здесь есть вариант, опять же, пойти по нулевому региону или пойти по недулевому региону. Ну, то есть, если меня память не изменяет, в 3101 уже не указывается, что нулевой регион будет более предпочтительным, чем ненулевой. Там они расцениваются как одинаковые. В случае, если у нас есть маршруты внешние какие-то или LSE 3, то мы предпочитаем

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

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

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

Ну и да, в случае, если LSE 5-ка первого типа нам администратор сказал, ну, примерно так же посчитано. В случае LSE 5-ка второго типа он сказал, совсем не так посчитано, не верьте, не пытайтесь это даже сравнивать со своими метриками. Поэтому да, здесь вполне логичное сравнение идет. Но внутри каждого из этих типов у нас есть, опять же, различные варианты, как можно добраться, если LSE 5-ки у нас разные. Вот, например, у нас есть роутер, и у него есть два ASBR, и каждая из них вбрасывает пятерку. И, соответственно, мы можем пойти так, а можем пойти эдак. Какой вариант выбрать? У нас здесь есть алгоритм. Если это LSE 7-ка, она будет более предпочтительна, чем все остальное, но при условии, что эта LSE-ка будет транслируема. То есть, у нас есть ASBR в одном с нами регионе NSSA. Он придумал такую LSE-ку, говорит, переложите, пожалуйста, информацию об этой LSE-ке куда-то дальше.

Если у нас есть такая LSE-ка и, например, пятерка, то это значит, что мы находимся в нулевом регионе, мы видим пятерки. У нас есть вот здесь вот Area 0. Вот, мы видим семерку, мы находимся в ненулевом регионе Area, допустим, 1 NSSA. И у нас есть вариант дойти напрямую до ASBR или пойти в обход через как-то вот так вот. Вот в этом случае LSE-ке пятерки мы не доверяем, мы говорим, это LSE-ке пятерка про ту же самую сетку, которую мы знаем внутри региона. Поэтому LSE-ке семерки более кошерные считаются, чем LSE-ке пятерки, но только если они транслируемы. Если они нетранслируемы, то в этом случае у нас есть вариант, как добраться до какой-то сети, до ASBR пойти вот так или вот так вот. В нулевом регионе у нас мы видим LSE-ку пятерку, в ненулевом регионе мы видим LSE-ку семерку с флагом ноль. Она будет наименее

предпочтительной, она будет наименее предпочтительной даже по сравнению с LSE-кой пятеркой. То есть, если есть вариант как пойти до какого-то внешнего узла по нулю или не по нулю, мы всегда стараемся пойти по нулю. И вот LSE-ка пятерка будет означать, что мы пустим трафик через нулевой регион, LSE-ка семерка нетранслируемый с P-битом 0, означает, что мы пойдем через NSSA. Мы стараемся пойти через 0. Ну и аналогичная история опять же в LSE-ке пятерках семерка второго типа. Сначала предпочитаем ASBR в одном с нами регионе NSSA, потом предпочитаем LSE-ке пятерки пойти через 0, и потом LSE-ке семерки, которые доступны через нулевой регион, через ненулевой регион, но они нетранслируемые, то есть на самом деле они доступны также и в нулевом регионе. Вот. Так что как-то так. Запоминать, опять же, это не нужно, это нужно понять и осмыслить.

То есть от вас не потребуется уметь восстановить вот эту логику, но от вас потребуется понимать, почему в каком-то порядке эти самые LSE-ке предпочитаются. И когда вас спросят, почему в определенной ситуации у SPF выбрал вот такой вот маршрут, а не другой, вы должны будете сказать, что вот он выбрал, потому что дальше говорите. Здесь он пошел по такому пути, потому что он выбрал LSE-ку трешку перед пятеркой, здесь он пошел по такому пути, потому что он выбрал LSE-ку пятерку перед LSE-кой семеркой нетранслируемой. Ну вот, как-то так. Дальше. Что еще у нас тут есть? Дальше начинается рассказ про Virtual Link. Если у нас есть хорошая нормальная сеть, в этой нормальной сети у нас есть нулевой регион и есть ненулевые регионы. Соответственно, представим себе, что у нас есть просто нормальная обычная сетка, нулевой регион, здесь у нас регион

номер один, здесь регион номер два, и соответственно у нас какие-то сетки зарождаются в одном регионе, перекладываются в ноль в виде трешки, и дальше мы перекладываем сетку, полученную в трешке в одном регионе в другой регион, тоже в виде LSE-ки трешки, но уже, соответственно, с другим авторством. То есть вот этот вот АБР говорит, я знаю, что есть какая-то сетка, я перекладываю эту сетку в другую LSE-ку трешку, я рассказываю про нее в другом регионе. В этих LSE-ках трешках мы видели, что содержится. Содержится ID-шник, совпадающий с IP-шником в сети, содержится маска и содержится метрика. Там не указывается, из какого региона оно прибегает. Поэтому, в принципе, вы можете сделать вот такой вот лайфхак. Вы можете сказать, что поскольку нигде не проверяется, из какого региона пришла LSE-ка трешка, в принципе, вы можете взять и сказать, что у нас вот этот вот кусок региона, Area 1, и вот этот вот кусок Area 1, они вообще независимы друг от друга регионы, и фактически все, что от них требуется, это быть не нулевыми регионами.

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

в виде трешки в ненулевом регионе, оно уже взялось из нуля. Вот этот вот АБР, он, соответственно, говорит, я не буду перекладывать трешку из ненуля в ноль. Это сетка, которая изучена в первом регионе в виде LSE-ки трешки. Она там могла трешкой породиться только из нуля. А, соответственно, мы то, что получено из нуля, обратно в ноль уже в виде трешки не перекладываем. Вот. Еще хуже ситуация будет, если у вас вот этот вот роутер, например, вот здесь вот, имеет какой-то стык с другим регионом, не знаю, Area 2. Area 2. Вот. Он тоже какие-то сетки прикладывает. Соответственно, здесь порождается LSE-ка трешка. И тогда даже здесь уже трешка это генерится. Ну и, соответственно, то же самое все будет, да, что трешка отсюда приходит в ненулевой регион, и дальше здесь эта трешка уже не появляется. Маршруты из одного куска нуля в другой кусок нуля автоматом, соответственно, будут теряться. Вы не можете синхронизировать между собой

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

транзитные роутеры могут быть, это все ненулевой регион, например, регион 1. Мы поднимаем псевдопровод, и этот псевдопровод, ну, как бы, как бы, как интерфейс считается, да, только не полноценный интерфейс, а такой нарисованный. И этот интерфейс будет автоматически принадлежать к нулевому региону. И когда у вас появляется какая-то LSA первого типа или третьего типа в нуле, это сами именно LSA, они реплицируются по интерфейсу в нулевом регионе на все остальные роутеры нулевого региона. То есть вот в нашем случае именно вот эта LSA будет передаваться по псевдопроводу в нулевой регион. Да, это LSA не будет видна вот здесь вот, именно как LSA первого типа. Да, АБР возьмет и переложит информацию про эту сетку в виде LSA третьего типа, который потом дальше не уйдет никуда. Здесь у нас трешки не перекладываются обратно в ноль. Но зато про эту сетку роутеры будут знать через LSA первого типа.

Поэтому виртуальному проводу не может ходить трафик. Это хитрый момент. По этому проводу передается только LSA. Трафик по нему не ходит, но это и не нужно. Если вот этот вот роутер скажет, я знаю, как у нас выглядит нулевой регион. Нулевой регион у нас выглядит вот так вот. То есть у нас есть связи между роутерами и поэтому по этой топологии я могу построить кратчайший маршрут до вот этого вот роутера. Самый правый роутер, давайте сотру все со слайда, то есть здесь рисовал все. Самый правый роутер говорит, я знаю, какой кратчайший маршрут будет до роутера. Вот здесь вот у нас есть какая-то сетка А. Вот такой вот кратчайший маршрут у нас будет между двумя роутерами. И соответственно вот здесь 10 копеек, 10 копеек, там не знаю, 10 копеек, 10 копеек. Вот он взял и сказал, я знаю, как добраться до этой сети за 40 копеек. Next Hop'ом будет вот этот вот товарищ. Трафик посылается на вот этот вот роутер. А вот этот вот роутер уже говорит,

я знаю, как можно добраться до сети А. Я знаю эту сетку через VLSA и Q3. Он вот не строит маршрут через псевдопровод. Он говорит, я не могу трафик пустить через псевдопровод. Я могу трафик пустить только по своему полноценному интерфейсу. Вот это вот будет у нас тут 15 копеек маршрут стоит. Я трафик по нему буду пускать. И в моей табличке соответственно этот маршрут будет стоить 15 копеек плюс 20 копеек, 35 копеек. Вот. То есть, такой псевдопровод нужен для репликации базы данных нулевого региона, но трафик по нему не ходит. Это не является проблемой, именно потому, что у вас трафик по факту может пойти через ненулевой регион. Он нормально дойдет до другого конца этого псевдопровода, потому что мы будем знать, куда его пускать. до какого-то другого АБРа он должен дойти. Здесь вариантов особых нет. Но, соответственно, да, в таблице маршрутизации здесь может у нас быть небольшое

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

до до ЛАБы на SPF и вот там заодно это дело и посмотрим. Как вы видите, у SPF вот допустим когда мы проходили с вами на CCNA там было все как бы просто. Нажмите Network там 0.000 и у вас там SPF заведется. И казалось бы, да, все очень просто. Какой простой протокол его включил и он работает. А на самом деле внутри под капотом у этого SPF работает огромное количество неочевидных концепций и вот просто его включить и просто оно заработало подход, который применим только на самых самых базовых уровнях. Как только вы начинаете разбираться что там по факту передается выясняется, что SPF это огромный неповоротливый монстр. И даже если не вбрать в расчет всякие костыли типа вот этих самых NSSA, Total NSSA и прочих, которые только вот к RFC 2328 к обычному стандартному скелету SPF относятся, то да, получается, что внутри под капотом внезапно очень сложный. В чем сакральный смысл наличия больше одного региона нулевого?

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

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

самому псевдопроводу. Пардон. И здесь у меня нарисовано не совсем как бы красиво. Давайте опять сотру со слайда. Здесь у меня нарисовано как будто бы кратчайший маршрут между роутерами вот такой, а псевдопровод идет как-то иначе. На самом деле, вы когда запускаете вот этот вот самый псевдопровод, запускаете virtual link, вы говорите, с каким роутером надо установить этот псевдолинк, и он строится по кратчайшему маршруту. То есть, у вас кратчайший маршрут внутри USPF вот такой, и псевдопровод вот такой же строится. Поэтому трасса, по которой пойдут LSA, на самом деле, будет совпадать с трассой, которая построит USPF для трафика. Он случайно это сделает, в том смысле, что да, по псевдопроводу трафик не пойдет. Трафик пойдет по ненулевому региону, по базе ненулевого региона. Но он пойдет фактически так же, как если бы вы взяли и сказали, давайте мы построим, не знаю, ГРИЕ-туннель между этими двумя роутерами. Вот они все равно сказали бы, да, кратчайшая трасса вот такая. Мы по этой трассе можем ГРИЕ построить,

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

которые смотрят в первый регион, вы видите, потому что в вашем регионе вы топологию все знаете. Вы должны будете каким-то образом определить, какой айпишник будет ближайший и посылать hello на этот айпишник. Вот. Там не указано, каким образом вы это должны делать. Но вы должны будете каким-то образом сказать, что вот ваш роутер должен догадаться, какой он будет ближайший. если говорить про циску, то в циске вы для построения вот этого псевдопровода, псевдотуннеля будете указывать айдишник роутера соседа. И когда вы указываете айдишник соседа, здесь все просто. То есть вы говорите, у вас здесь вот айдишник там 1111, здесь айдишник 2222. Циска берет, строит кратчайший маршрут между роутерами 1111, 12222, говорит, он пойдет по какой-то вот такой вот трассе, и тот айпишник, который будет коннектат на интерфейсе, куда приходят кратчайшие трассы, он, собственно, и будет другим концом туннеля. Именно на него мы будем посылать уникастовые пакеты.

Тут есть, конечно, неочевидные моменты, что на этом интерфейсе у нас не обязательно айпишник будет, там может быть такое, что этот айпишник отсутствует в нашей таблице маршрутизации. Есть такие вот моменты, что как бы неочевидные сложности здесь задать будет можно. Но в стандарте они никак не описаны. И предполагается, что вы сами себе злобный баратин, если вы сделали какую-то странную топологию, в которой VirtualLink построиться сам не смог. Но в нормальной ситуации, если у вас просто обычная сетка, как правило, там проблем особых не возникает. Вы указываете, с каким роутер-айд вы строите VirtualLink, Cisco по ненулевому региону строит кратчайший маршрут до этого роутера-айд, и вот тот айпишник, который на том интерфейсе, который с другого конца трассы будет, он, соответственно, и будет использоваться в качестве айпишника-получателя. Дальше вы устанавливаете соседство, отправляете DPD-пакеты, которые содержат нужные вам LSEC, отправляете LSEC,

LSEC, LSEC, LSEC, LSEC, LSEC, LSEC, LSEC, LSEC, LSEC, синхронизируете соседство, у вас соседство переходит в full, и дальше, ну, дальше все начинает работать. В LSEC первого типа у нас добавляется вот линк, которым эти роутеры по факту якобы связаны. То есть, как будто бы, ну, не знаю, вы ГРЕшный туннель запустили, это не ГРЕшный туннель, это просто интерфейсы, как будто вот два роутера между собой связаны. Как вы помните, в LSEC первого типа у нас есть четыре типа разных того, чего можно внутри LSEC первого типа указать. Первый тип это point-to-point соседство, второй тип это через LSEC 2-код транзитный нетворк, третий тип это стаб-нетворк, то есть, у нас пользовательские IP-шники есть, и четвертый это вот как раз Virtual Link. Ну, то есть, у нас получается, что роутеры внутри нулевого региона будут видеть, на самом деле, что вот этот вот тип соседства в нулевом регионе, оно не совсем как бы нормальное, немножко кривоватое,

но для них, на самом деле, это будет неважно. То есть, они понимают, что вот это вот соседство, оно по интерфейсу типа Virtual Link. Ну, да, будет и будет. У этого Virtual Link будет автоматически назначаться стоимость. Когда у нас есть вот этот вот первый регион, в нем есть какая-то кратчайшая трасса между двумя АБР-ами, между двумя роутерами, вот этим вот кусочком роутера, и вот этим кусочком любого региона. Соответственно, здесь какие-то вот стоимости на этих интерфейсах есть, они автоматически суммируются, и вот 10 плюс 15 плюс 15 плюс 25, 75. И на Virtual Link назначается автоматическая стоимость 75 копеек. Поэтому, по факту, я вам сказал, что трафик будет ходить вот таким образом, чтобы у нас совпадать с кратчайшей трассой, да, действительно, Virtual Link будет иметь такую же стоимость, как кратчайшая трасса между роутерами. Поэтому, по факту, когда у нас вот этот вот роутер будет считать, как добраться до сети А, которая за спиной у другого конца нулевого региона, вот, он будет говорить,

что вот с моей точки зрения пойти вот так вот и пойти вот так вот, это на самом деле одно и то же. Это действительно одно и то же, это физически одно и то же. Но с точки зрения топологии он вот всю вот эту вот колбасу внутри первого региона не видит, но он знает ее суммарную стоимость, которая в Virtual Link как раз и прописана. Только ли у ЦИСКи, или у всех Virtual Link предназначен для нулевого региона? Virtual Link по определению только для нулевого региона. Нужен для того, чтобы разные куски нулевого региона склеить между собой. Такая синяя изолента, которую вы можете склеивать только куски нулевого региона. Склеивать отдельные куски первого региона смысла нет. Вот я специально вам сделал отдельный слайд. Стираю все со слайда. Если у вас разрывный какой-то другой регион, проблем не будет. Проблема возникает только когда нулевой регион расклеивается. И вот склеивать его обратно можно с помощью Virtual Link. еще одна интересная штука, которая есть в OSPF.

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

То есть, кажется, не очень очевидно, зачем это может быть нужно, но это очень полезная вещь. Дело в том, что если у вас есть какая-то сеть, вот как, например, на картинке нарисовано, у нас 4 роутера, на этих роутерах есть сети, которыми роутеры соединены между собой, 10, 0, 1, 0, 0, 2, 0, 0, 3, 0, 0, 4, 0. И, соответственно, есть пользовательские сетки, 192.168.1.0, 192.168.2.0. Возникает вопрос. Да, мы, если хотим в OSPF настроить связь между юзерами, вот здесь, вот, у нас же здесь юзеры сидят, да, и все, что мы делаем, мы делаем ради них. А для того, чтобы юзеры между собой трафиком могли обмениваться. Мы же не делаем это для того, чтобы прикольно сказать, какие, смотрите, у нас тут маршруты клевые. И вот, для того, чтобы эти юзеры обменивались трафиком, нам нужно, чтобы юзерские маршруты в таблице маршрутизации были на всех роутерах. По большому счету, нам не нужно, чтобы у нас вот эти вот коннект от сетки в таблице маршрутизации были. Мы видим, что у нас на роутере R, например, есть OSPF-овская сетка

10, 0, 1, 0, 2, 0, не сильно нужны. И в таблице маршрутизации они в любом случае не попадают, потому что это коннект от сетки. И вот 192, 168, 1, 0, вот эта вот сетка OSPF-овская. Вот это вот коннект от соответственно. Получается, что всего в таблице маршрутизации у нас маршрутов 6 штук. Из них по OSPF-у на вот этот вот роутер прибежали 3. 192, 168, 1, 0, 1, 10, 0, 1, 0, 10, 0, 2, 0. При этом, на самом деле, нужен нам только вот этот вот маршрут. А вот эти два, по большому счету, нам не нужны. Мы никогда не отправляем трафик, если мы нормальный роутер и у нас есть просто обычные пользовательские маршруты и пользователи на эти IP-шники не должны отправлять трафик. Правда? Это транзитные сетки. Они не нужны. Нам не нужно, чтобы вот эти вот сетки попадали в анонс OSPF-а. Но мы не можем не включить здесь OSPF. И вот здесь возникает такая вот коллизия. Что делать в такой ситуации? RFC-6860 говорит,

что если у нас есть интерфейс point-to-point и мы говорим, что нам транзитные сетки не нужны, то в нормальной ситуации у нас создается интерфейс, ну не интерфейс, у нас создается в LSE-ике первого типа, link point-to-point типа, но и рядышком с ним создается стаб-запись. Вот если мы включаем RFC-6860, то мы point-to-point link создаем, IP-шник сосед наш увидит, но стаб-записи для вот коннекта сетки у нас не создастся. Если у нас point-to-multipoint, та же самая история, там отдельно создается соседство и отдельно указывается стаб-запись. Если у нас интерфейс broadcast-inon-broadcast, то тогда все немножко становится сложнее. Там не просто стаб-запись будет, там есть, что у нас? Если у нас есть роутер, который смотрит на LSE-ику второго типа, который смотрит на роутер, у нас есть link второго типа, мы указываем, какой IP-шник у нас здесь будет, там 10, 0, 1, 1.

И здесь у нас IP-шник 10, 0, 1, 2. И вот эта вот LSE-ика второго типа, она указывает, соответственно, какая у нас будет сетка LSE-ика второго типа. И здесь будет там slash 24. Network mask указывается именно в LSE-ике второго типа. Можем ли мы не рассказывать про IP-шник? Не можем, потому что этот IP-шник будет использоваться в качестве NextHop-ов таблицы маршрутизации. Поэтому мы обязаны указать IP-шники в этой ситуации. Что мы здесь можем не анонсировать? Ну, фактически ничего. То есть мы в LSE-ике второго типа сами IP-шники не указываем, там только длина маски. IP-шники указываются на интерфейсах, и мы их обязаны анонсировать, иначе построить таблицу маршрутизации не получится. Но если вы включаете поддержку RFC-6860, то все роутеры получат и LSE-ики второго типа, где маска написана, и LSE-ики первого типа, где IP-шники прописаны. Но в таблицу маршрутизации они не будут добавлять маршруты из LSE-ики,

из LSE-ики второго типа. Вот. Если вы будете использовать новые роутеры, они, соответственно, все поймут и скажут, окей, не проблема, мы не будем использовать вот эти вот транзитные сетки. Что делать тогда со старыми роутерами? Они-то как раз будут в таблицу маршрутизации заносить что-то лишнее. И для того, чтобы избавиться от проблемы, что старые роутеры все равно будут на такое реагировать, вы будете делать следующую вещь. Вы будете анонсировать в LSE-ике двушки маршрут по 32-й маске. И тогда роутеры будут видеть, что здесь какая-то нездоровая хрень. Старые роутеры, они будут говорить, что здесь у нас сетка 32-я, а вот эти вот IP-шники, они явно из разных сетей. И они, в свою очередь, тоже в таблицу маршрутизации это добавлять не будут. Вот для того, чтобы и старые роутеры, которые не знают, что такое RFC 6860, и новые роутеры уже с поддержкой этого RFC могли бы не добавлять лишний маршрут в таблицу, вот такой вот, может быть,

не очень элегантный лайфхак, но тем не менее, да, хак есть. Как сделать так, чтобы в таблицу маршрутизации транзитные маршруты вот эти вот не добавлялись? Если у вас point-to-point соседство, все просто, вы просто не анонсируете стаб-нетворки. Если у вас бродкастовое соседство и нон-бродкастовое, то вы вынуждены рассказывать про эти сетки, но вы рассказываете, что вы их знаете с 32-й маской. И по факту, да, в таблицу маршрутизации они все равно добавляться не будут. Вот. CISC эту штуку поддерживают. Не любые устройства будут поддерживать RFC 6860, уже упоминавшийся микротик, например, его не умеют. Поэтому, если вдруг вы его включаете, то включаете, да, там, где оно поддерживается. В любом случае, штука полезная, сокращает количество записей в таблице маршрутизации, ну, да, сокращает нагрузку на железке. Так что, если есть возможность, используйте ее. Не сказать, чтобы она прям сильно сокращала, но, тем не менее, она очень приятная в использовании. И все равно вам эти транзитные сетки, они не сильно нужны.

Если у вас сетей много, то как раз и есть смысл от них избавиться. Это вот что касалось манипулирования маршрутами, когда у нас есть ОСПФ, что мы с ними можем делать. Резюмируя, можем LSA-ки трешки либо не анонсировать вовсе, либо анонсировать вовсе, но, скажем так, одновременно с агрегацией, когда мы говорим, что у нас вместо кучи мелочевки анонсируем одну большую трешку. Либо можно будет маршруты внешние вбрасывать в виде LSA-ек пятерок. Опять же, возможно с агрегацией. Если мы делаем это на нескольких роутерах, либо LSA-ки трешки суммируем, либо LSA-ки пятерки суммируем, то это надо делать одновременно на всех роутерах, одинаково и однотипно. Плюс к тому, можно объявить регион стабом или не совсем стабом и, соответственно, сократить распространение LSA-ек пятерок. Если вы объявляете не совсем стабом, то у вас появляются еще LSA-ек семерки, которые в свою очередь будут перекладываться в LSA-ек пятерки.

Так, давайте попробуем теперь посмотреть, как это все делается на цисках. ПО muchas Shepherd руководила на самом деле! ПО- Android К римм-び-лс К римм-び-лс К римм- либо С grandmother-чрушî К римм- либо С баба-чур Б猿-п люд-лс Драк Turtle