Протокол OSPFv2

продолжаем говорить про динамическую маршрутизацию и на повестке дня у нас другой протокол не такой как и jrp во всех отношениях это протоколу spf протоколу spf не похож на и рип не похож на и jrp он действительно другой он обменивается не кусками таблицы маршрутизации то есть что рип что и и jrp они в апдейтах просто ворил я знаю вот такую сеть я знаю от открывайте вот так дальше вы говорили что раз вася знает эту сеть я могу давать и добраться вот так значит я через васю могут добраться до этой сети вот и дак и дальше вы рассказывали я знаю как добраться до этой сети вот и дак но вы уже про васю не упоминали в классических дистанци Free worship протоколах а ну вот так вот и работает то есть вы рассказываете как вы знаете эту сеть соседи говорят они знают вас и они видят, что вы знаете эту сеть, значит, они могут добраться до этой сети.

Они дальше начинают рассказывать про то, как они знают эту сеть. Дистанс-векторная маршрутизация – это маршрутизация по слухам, где каждый роутер говорит «я знаю, как добраться до сети, верьте мне». OSPF – это протокол, который разработан был для того, чтобы отойти от концепции маршрутизации по слухам. Это протокол, который обменивается кусками таблицы топологии, не маршрутами, а именно указаниями, кто с какими соседями как связан и, соответственно, какие сети в топологии будут известны. А дальше, зная, что какая-то сеть известна на каком-то роутере, и имея полную карту топологии, полное понимание того, как до удаленной сети можно будет добраться, каждый маршрутизатор может построить кратчайший маршрут до удаленной сети. OSPF будет обмениваться действительно кусочками таблицы топологии, которые называются LSA – Link State Advertisement. У меня здесь аннонсмент написан «Advertisement», в которых рассказывается, соответственно, с какими маршрутизаторами этот маршрутизатор дружит,

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

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

обменивается только маршрутами и пире четвертыми то есть это тот самый успев который мы просто сегодня говорим включил spf вот имеется виду spf 2 версия есть много стандартов которые описывают поведение у spf 2 версия актуальные 23 28 который описывает базовое взаимодействие а плюс к нему есть огромное количество костыльных фишек которые описывают какие-то дополнительные опциональные механизмы эти опциональные механизмы как правило появляются вследствие того что кому-то хочется чтобы успев умел какую-нибудь фичу и он приходит в вендор ну условно в циска говорит циска запили мне пожалуйста вот такой вот хрень и циска говорит ну ты знаешь это как противоречит логике протокол горит эти денег заплачу циска это запиливает потом все говорят о какой клевый костыль придумали давайте мы его тоже реализуем и в итоге получается что да что вот успев начинает обрастать об обрастать свистелками перделками это действительно костыли действительно

свистелки и перделки в 99 процентах случаев есть кроме того что есть вот это вот базовый рфси 23 28 свистелки перделки есть еще сложность с тем что бывают рфси устаревшие для успев в 2 в том числе наиболее скажем скажем важный из них это 1583 это все еще успев в 2 но он уже соответственно старый разница там будут в мелочах но тем не менее она есть и поэтому в случае если вдруг вы будете работать с циской вы должны будете помнить что не обязательно циска работает в рфси самая последняя версия если у вас циска работает циска и у железка работает с успехом она по умолчанию работает по рфси 1583 соответственно в 2178 и в 2328 добавили некоторые изменения и эти некоторые изменения могут привести к тому что у вас будет две железки одна железка 1583 циска и у с по умолчанию работает в нем другая

2328 но например какой-нибудь условный циска nexus и они друг на друга строят маршрут один и тот же то есть они говорят у нас есть какая-то сетка где-то тут вот наверху и nexus говорит это надо ходить через иос а а иос говорит это надо ходить через nexus вот из-за того что они работают по факту в разных режимах у spf а такое произойти может поэтому вы должны будете знать соответственно в каком режиме работает именно ваша железка успев будет использовать мультикаст для работы соответственно там где это будет возможно у него будет использоваться два мультикастовых адреса 224 005 в spf v2 и 224 006 224 005 для обнаружения соседей для hello пакетов и для модификации поведения у spf в мультиксесс средах будет использоваться роль диссигнейт от роутера и соответственно там для вот этих обладателей

роли диссигнейт от роутера будет использовать специальный мультикаст в адрес 224 006 это намек на то что в и и джорпи например у нас тоже используется мультикаст 224 0010 и в рипи используется мультикаст 224 009 но там по одному мультикастовом адресу было для всего достаточно а здесь вот используется h2 также как и и и джорпи у spf не использует не тси пинию дипи он использует свое собственное вложение в ip 89 поэтому да не забудьте что если у вас есть интерфейс и в этом интерфейсе access листом фильтруете трафик входящий вы должны будете разрешить прием входящего 89 типа 89 вложения исходящий трафик access листами не блокируется а вот входящий вполне может быть поэтому если вы не за не разблокируете успf явном виде и повесить access лист на интерфейс то соответственно да он будет заблокирован очень типичный сценарий да при котором там говорят tcp разрешаем и дп разрешаем и все больше нам типа ничего не надо еще и 7p например

и думаем что это разрешает вообще весь трафик что типа всякие злодейские вложения которые там будут указываться что это обязательно мусорные и спам нет не всегда это мусор спам иногда это там полезный трафик тоже бывает так дальше если говорить про из пиве 3 это новый протокол он очень похож в некоторых деталях на успех второй версии поэтому когда мы на сессии на и проходим по спе 3 мы говорим там все то же самое что в успех и 2 но на самом деле конечно же там есть изменения изменения эти довольно значительные у успех 3 версии другие лс и ки не только в том смысле что в них другие размеры ip адресов передаются но и там структура самой лысо и ки будет другая более того успf 3 версии хотя изначально затачивался под работу с ipv6 он работает только поверх а пиве 6 он обменивается и пиве 6 маршрутами по умолчанию но потом его допилили

сделали ему костылик можно для успf v3 задать синхронизировать таблицы маршрутизации пиве 4 и у вас будет очень хитрый сценарий при котором два роутера они связаны между собой и по ай пиве 6 и по ай пиве 4 вот и соответственно не обмениваются успf v3 пакетами эти успf v3 пакеты используют ай пиве 6 для транспорта но они реплицируют таблицам маршрутизации и ай пиве 4 и ай пиве 6 ну или если вам захочется можно только пиве 4 реплицировать но это будет очень странно вот успf v3 тоже использует вложение 89 тоже использует два мультикастовых адреса тоже заканчивается на пятерку и на шестерку и точно для тех же задач каждый маршрутизатор в голове будет строить полную карту топологии то есть если у вас есть вот как карта до карта она состоит из отдельных кусочков я сейчас попробую нарисовать какой-то такой типа пазл то есть

вот как пазл он и есть вы поняли да и и и сеть будет состоять из кусочков этого самого пазла вот и каждый роутер придумывает кусочек пазл рассказывает то что он знает про сеть сам рассказывает про все кусочки которые ему прислали соседи всем своим соседям и в голове у каждого роутера каждый кусочек соответственно будет присутствовать у меня лень вы рисовать все кусочки этого пазла ну вот идея думаю что вы поняли каждый роутер придумывает свой кусочек один роутер придумал вот этот вот кусочек рассказывает его всем остальным после того как все кусочки в главе у каждого роутера появились роутере могут собрать все кусочки воедино и построить полную карту в каждом кусочке пазла передается указание какие соседи обнаружены и какие connected сетки на интерфейсах самого роутера будет будут подключены важное замечание да действительно рассказывают роутер про connected сетки на интерфейсах но при этом передаются не

все-таки не сети а именно кусочки таблицы топологии то есть когда роутер один говорит в цепочке нарисую 4 роутера в цепочке вот роутер 1 2 3 4 и у нас в таблице в дистанте вектор на протоколе роутер 1 сказал бы у меня есть сетка а эта сетка анонсировалась бы 2 2 сказал я знаю сетку анонсировал ее третьему 3 сказал я знаю сетку анонсировал бы четвертому в link state и роутер один сказал бы я знаю вот так вот устроена сеть с моей точки зрения и дальше в голове у например 2 роутера было бы указание что 1 роутер знает сетку а 3 роутер тоже сказал бы вот у меня есть кусочек пазала в котором роутер 1 говорит что знает сетку а это же самое четверто говорит я вижу кусочек пазла в котором 1 роутер а на отсеку при этом это не то что второй роутер говорит что знает сетку а это 1 роутер знает сетку а но получены элла сейка соответственно полученного сайка роутера первого получено рядышком элисейка роутера 2 рядышком элисейка роутера 3 рядышком элисейка

роутера 4 у нас в голове получилось 4 кусочка кто на кого как смотрит мы эти кусочки собрали воедино и получили полную картинку единица передачи информации в оспф не маршрут а именно вот элисейка внутри элисейки маршруты не передаются передаются только connect от сетки то есть но фактически айпишники которые висят на интерфейсах link state протоколы по сравнению с дистанц-векторными в среднем намного более эффективно используют полосу пропускания если говорить про сравнение например у spf с рипом то рип каждые 30 секунд будет шарашить в каждый из интерфейсов полную таблицу топологии если у вас маршрутов много тури по этом случае будет занимать довольно заметную полосу пропускания особенно на медленных интерфейсах а придумывался рип как вы помните тогда когда интерфейса все были медленные у spf один раз насосал таблицу топологии дальше правилет маленькое сообщение у меня все хорошо у меня все хорошо мне ничего не изменилось меня

все хорошо поэтому вот это вот маленькое сообщение передать занимает очень мало времени большое сообщение с полной таблицы топологии занимает много времени поэтому link state протоколы эффективнее использует полосу. LinkState протоколы будут быстрее реагировать на изменения в целом. Если мы говорим, например, про протокол RIP в качестве образца, RIP на изменения будет реагировать прямо медленно-медленно. То есть он перестал получать от соседа какой-то маршрут, и он ждет. Ждет в течение инвалид-таймера, чтобы маршрут этот сдох таблицы, после чего станет понятно, что сетка недоступна, после чего там с этой сеткой что-то можно сделать. Три минуты по умолчанию. В LinkState у нас упал интерфейс, в котором мы смотрели, мы перестали знать доступ в какую-то сеть, потому что у нас IP-шник в эту сеть перестал существовать. Мы придумали новый кусочек пазла, разослали его всем своим соседям, сказали, раньше мы знали вот IP-шник в эту сеть, теперь мы не знаем IP-шник в эту сеть. И все роутеры,

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

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

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

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

LSA-ки время. Он ждет, если получена LSA-ка повторная. Типа, если у нас сосед прислал одну LSA-ку, потом сразу в догонку прислал другую LSA-ку, а потом сразу в догонку третью. Мы говорим, ты знаешь, что-то как ты много LSA-ек посылаешь. Давай мы накопим от тебя их сразу штука 10, а потом просуммируем и просчитаем сразу всем скопом. Поэтому ОСПФ очень ленивый протокол, и поэтому на изменения он в среднем реагирует медленнее, чем EJRP. EJRP, ну что, ему просто, он получил запрос от NextHop своего, от Саксессора, ну понимает, значит, что сетка сдохла и переключается на Feasible Successor. Получил запрос от кого-то еще, кто не Successor, не Feasible Successor, есть ли сетка? Он сразу ответил, да, сетка есть, все в порядке. Поэтому алгоритм Dual, он очень быстрый, а запасной NextHop в виде Feasible Successor в EJRP, он вообще мгновенно работает. Здесь вот ничего мгновенного нет. Здесь за счет того, что протокол

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

Использовать для обнаружения соседей будет такой же механизм у SPF, как использует EJRP. Он будет просто отправлять в Hello пакеты, но в этих Hello пакетах он будет указывать, соответственно, как он сам настроен. Будет указываться сейчас будут указываться таймеры. Таймеры в EJRP указывался только один, это был hold time, через сколько признавать себя трупом, если сосед не будет получать Hello сообщение от нас в течение некоторого времени. Здесь таймеры обязаны совпадать на обоих соседях, и поэтому сказать, что кто-то отвечает один за эти таймеры нельзя. Оба роутера будут отвечать за таймеры. Если таймеры разные, соседство не поднимется. Должны совпасть номер региона, если мы используем то, что в английском языке ARIA называется. И если у вас будет роутер входить в регион, который он считает стабом, то вот, соответственно, сосед тоже должен входить в этот регион со флагом стаба. Про стаба будем потом отдельно

говорить. Если используется аутентификация, естественно, пакеты должны быть правильно проутентифицированы. Более того, Hello пакеты будут приходить от соседа, который не может иметь такой же роутер ID, как у нас. То есть, если мы отправляем Hello пакет, мы указываем свой роутер ID, и входящие пакеты с таким же роутер ID на интерфейсе мы пригибать не будем. После того, как соседство обнаружено, мы Hello пакеты отправили, получили, соседа занесли в список соседей. Дальше мы начинаем обмен LSA. И в этих LSA указывается, кто на кого, каким интерфейсом смотрит. Соответственно, вот здесь у нас есть топология R1, R2, R3, R4. По факту, да, каждый из этих роутеров придумает свой кусочек таблицы топологии, свою LSA. Роутер 1 скажет, что я вижу R2 и R4. То есть, он выпустит LSA, скажет, я первый роутер,

я вижу R2, я вижу R4. И скажет, за сколько он их видит. Каждый интерфейс между роутерами стоит определенное количество, ну, назовем это копеечек, определенную стоимость имеет. Вот в нашем случае R2 будет известен за 10 копеек, R4 будет известен за 5 копеек. Дальше R4 скажет, что он знает первый роутер R1 за 5 копеек и R3 за 10 копеек. R3 выпустит, давайте R2 сначала. R2 выпустит LSA и Ко. Скажет, что он видит R1 за 10 копеек, R3 за 20 копеек. И вот R3, наконец, скажет, что он видит R2 за 20 копеек, он видит R4 за 10 копеек, и он видит стаб-сетку 10-0-0-0 по 24 маске за 15 копеек.

То есть и соседство, и коннект-сетки уходят в одной и той же сущности, которая называется LSA. Каждый интерфейс, будь то интерфейс до соседа, или интерфейс, на котором у нас висит IP-шник с коннект-сеткой, будет иметь некоторую стоимость. Стоимость – это метрика, насколько хороший или плох этот интерфейс. Чем меньше стоимость, тем лучше интерфейс, тем более вероятно прохождение по нему трафика. Соответственно, если у вас есть два интерфейса, один, допустим, стоит 10 копеек, другой стоит 20 копеек, вот в этом случае вы хотите, чтобы трафик по 10 копеечному интерфейсу ходил вдвое сильнее, чем по 20 копеечному. Чем меньше стоимость интерфейса, тем больше вероятно прохождение трафика по нему. И когда вы строите кратчайший путь до удаленной сети, вы сначала собираете в голове полную карту топологии, а потом по этой карте строите такой маршрут, который имел бы наименьшую стоимость, то есть наименьшую сумму стоимости интерфейсов,

через которые этот маршрут проходит. Причем, если вы строите маршрут до соседнего роутера, то вы считаете только стоимость интерфейсов между этими роутерами. Но если вы считаете маршрут до какой-то сетки, вот, например, на A3 10.000 по 24 маске, то вы включаете, конечно, и стоимость этого интерфейса тоже. И в нашем случае у нас есть вариант, допустим, на роутере R1 пройти до сети 10.000 по 24 маске, либо вот так вот, и это будет стоить 10 плюс 20, 30 плюс 15, 45 копеек. Либо можно пойти через низ, это будет 5 плюс 10, 15 плюс еще 15, 30 копеек. Ну вот мы посчитали и решили, что от R1 до сети 10.000 по 24 маске удобнее всего пройти через R4, потом на R3 и потом уже в сетку 10.000-24. Вот. В таблицу маршрутизации мы такой маршрут и занесем. Каждая LSA, которую мы будем выпускать, она будет подписана. У нее будет идентификатор, у нее будет указание, кто ее придумал,

у нее будет номер серийный, у нее будет, ну, своего рода такая чек-сумма. Ну, для нас сейчас вот интересно то, что у каждой LSA есть указание на автора, кто ее придумал, кто ее выпустил. Так называемый advertising router. Это значение advertising router будет иметь в себе уникальный идентификатор самого роутера или роутер ID. То есть каждый роутер, который будет выпускать LSA, он будет эту LSA подписывать своим ID-шником. И вот этот вот ID-шник – это просто число. 32-битное число, потому что размер поля, кто придумал LSA, 32-битный. Учитывая, что этот ID-шник должен быть уникальный, и учитывая, что он имеет размер 32-бита, очень удобно взять IP-шник какой-нибудь в железке, которые должны быть уникальны на интерфейсах, и заимствовать его в качестве роутера ID.

То есть вот, например, у вас есть роутер, у этого роутера есть IP-шник 10.0.0.1, не важно, по 24-й маске какой. Этот IP-шник уникальный в вашей сети, и вы можете взять его, заимствовать в качестве роутера ID. Или вот другой, например, интерфейс, у вас там 10.0.0.2. Его тоже можно взять. Он тоже, наверное, уникальный, его тоже можно взять в качестве роутера ID. Соответственно, когда у вас железка запускается, она должна каким-то образом этот самый уникальный идентификатор получить. Самый простой вариант, как это сделать, это взять вручную назначить. То есть вы запускаете OSPF роутер, вы говорите, роутер ID у тебя будет, не знаю, 10, 10, 10, 10. Какие еще варианты есть? Можно взять просто самый маленький IP-шник на устройстве. Это один из рекомендованных способов в RFC, который как раз говорит, возьмите просто самый маленький IP-шник. Можно взять какой-нибудь другой IP-шник. То есть, опять же, вы не обязаны брать IP-адреса. Можете взять любое уникальное 32-битное число, которое найдете.

Просто вероятность того, что IP-4 IP-шник на железке есть, она довольно велика, раз это роутер. Поэтому, да, удобно брать именно его. ЦИСки предпочитают брать самый большой IP-шник с виртуальных интерфейсов, например, с лупбеков. То есть, уже говорили, да, что в EGRP такой же метод. Сначала проверяем, не задан ли вручную. Потом проверяем, есть ли IP-шник на лупбеках. Если IP-шник на лупбеках нет, если вручную не задан, то тогда просто берем самый большой IP-шник с физических интерфейсов. Будьте осторожны, если будете работать с некоторыми другими железками ЦИСки, потому что не у всех ЦИСок вот этот вот алгоритм будет использоваться. Потому что, например, XR и те же самые, они будут брать либо вручную заданный роутер ID, либо IP-шник с лупбеков и все. И вот с физических интерфейсов они, в принципе, роутер ID брать не будут. После того, как роутер ID вы назначили, дальше в течение срока жизни процесса OSPF этот роутер ID не меняется. Если вы захотите перевыпустить ваши LSA с новым роутер ID,

то вам надо, ну, своего рода их отозвать, сказать, что все, что вы понавыпускали со старым роутер ID, оно все протухло. Потом процесс OSPF выключить и запустить с новым роутер ID и перевыпустить все LSA, которые вы выпускали. Вот. То есть сказать, что это прям сильно нужно делать в большинстве случаев нельзя, но иногда бывает нужно обновить роутер ID на железке. Например, если вдруг случайно выяснилось, что две железки охапнули себе одинаково роутер ID, вот для этого да, вы должны будете перевыпустить все свои лассейки. Старые лассейки, которые были с неправильным роутер ID, отозвать, новые запустить. Каждый сосед, который будет принимать или отправлять LSA, должен пройти через определенные этапы. Самый первый этап – это установление соседства. И это будет выполняться с помощью процедуры, которая называется Hello Protocol. Мы отправляем Hello пакеты. Если мы сначала принимаем Hello пакеты от соседа,

мы еще ничего ему не отправили, мы просто получили Hello от соседа, и он говорит, я просто есть. Ну, просто мультикастовый пакет пришел, мы его получили. Мы говорим, о, прикольно. У нас обнаружен сосед, с которым не проверена двусторонняя связность. В этом случае мы соседа в табличку соседей заносим, но говорим, это непроверенный сосед, заносим его в состояние init. Также есть вариант, при котором мы отправили Hello пакет первым. Сосед это увидел и отправил нам встречное Hello с указанием «Я тебя вижу». Он указал наш роутер ID в списке соседей на этом интерфейсе. В этом случае мы знаем, что у нас проверена двусторонняя связность между нами и им. И в этом случае мы соседа заносим в табличку с указанием статуса «2way». Может быть такое, что мы приняли Hello пакет от соседа, он там нас не перечислил в качестве соседей, мы его занесли в init, отправили встречное сообщение «Я тебя вижу», и он занес нас в «2way». После этого он нам отправил встречное сообщение с криком «Я тебя тоже вижу», и мы его уже тоже занесли в «2way».

Это вот процедура, которая называется Hello Protocol. Дальше. Если вдруг мы принимаем решение, что с этим соседом нужно реплицировать таблицу топологии, мы переходим в состояние обмена базой данных. Это не всегда происходит. В некоторых ситуациях роутеры могут сказать, нам не нужно с этим соседом обновлять, синхронизировать таблицу, например, потому что вы почему-то знаете, что вы оба синхронизируете таблицу с кем-то третьим. Но вот если вы решаете, что такого третьего нет, то если вам нужно синхронизировать таблицу все равно, то вы дальше переходите в фазы «Xstart», «Exchange», «Loading» и «Full». Последовательно. «Xstart» — это согласование процедуры синхронизации таблицы. Дальше. «Exchange» — это обмен оглавлением таблицы топологии. «Loading» — это обмен самими мясными лосейками. И «Full» — значит, с соседом все полностью синхронизировано. Ну, по крайней мере, то, что от вас зависело.

Поэтому вы от соседа больше ничего не хотите. Кроме того, бывают еще два состояния — «Attempt» и «Down». «Attempt» — это… Ну, давайте, «Down» — это вы знаете IP-шник соседа, но вы в принципе не можете до него добраться, например, потому что такого IP-шника у вас в таблице маршрутизации нет. Он не резолвится. Очень редкое явление и бывает чаще всего в NBMA-сетях. Потому что в нормальной ситуации вы IP-шник соседа заранее не знаете. И второе состояние — это «Attempt», при котором IP-шник соседа вы знаете, вы отправляете ему пакеты, но от него пакетов никаких нет. То есть, да, это… Противоположный смысл по смыслу будет состояние «Init». Если вы обнаруживаете соседей автоматически, то вот этих вот двух состояний вы не увидите никогда. Потому что, ну, в списке соседей может быть только тот, кто прислал вам хотя бы один пакет. От «Tempted Down» предполагает, что вы знаете IP-шник соседа, хотя он вам ничего не присылал. Так, дальше.

По поводу синхронизации таблиц. Вы можете перейти в процедуру синхронизации таблиц, если вы решаете, что это имеет смысл. В какой ситуации есть смысл синхронизировать таблицы? Например, если вы работаете на Point-to-Point интерфейсе. То есть, у вас обнаружился сосед, вы точно знаете, что на этом интерфейсе больше никого нету. Ну, вы говорите, окей, значит, запускаем процедуру синхронизации. А что делать? То есть, мы не знаем точно, что у этого соседа нет для нас никакой новой информации. Или что у нас нет для него никакой новой информации. Если у нас есть мультиаксесс-среда, ну, например, Ethernet, и в этом Ethernet у нас есть роль DR, то есть мы DR или мы BDR, или наш собеседник DR или BDR. В этом случае мы тоже с этим соседом DR и BDR устанавливаем полные соседские взаимоотношения. Но если ни мы, ни наш сосед не является ни DR, ни BDR,

и DR и BDR существуют в сети, то мы говорим, раз мы полностью реплицируем свою таблицу с DR, и наш сосед реплицирует полностью свою таблицу с DR, то нам напрямую реплицировать наши таблицы нет смысла. Это будет просто излишняя информация, потому что у нас таблицы и так реплицируются с вот этим самым диспетчером. Поэтому может быть такое, что вы не будете выходить из состояния 2-way, вы, может быть, вполне скажете, что с соседом нам вполне будет комфортно в 2-way находиться. Вот, например, да, у нас есть свитч. У нас на этом свитче есть 4 роутера. R1, R2, R3, R4. R1 будет DR, R2 будет BDR, R3, R4 будут так называемые DR-азер. Дрочер. Раз DR-азер и два DR-азер. Вот, соответственно, R1 будет дружить со всеми,

будет реплицировать свою таблицу со всеми, в том числе с BDR. Дальше. R2, как запасной диспетчер, тоже реплицировать свою таблицу будет со всеми. Но вот эти вот самые DR-азеры между собой реплицировать таблицу не будут. Они знают, что если вдруг какие-то изменения у них произойдут, они про эти изменения отчитаются DR и BDR, а они уже расскажут про эти изменения всем остальным. Поэтому нет смысла в такой ситуации R3 и R4 напрямую дружить. Они останутся в 2-way. Вот. Если же вы решаете переходить в полноценное взаимодействие, то вы должны будете сначала запустить процедуру согласования порядка передачи данных. Это будет состояние X-Start. В состояние X-Start отправляется буквально один или два пакета, которые будут называться DBD, Database Description. И эти DBD, они в норме передают содержимое оглавление вашей базы данных. То есть там не само мясо будет передаваться,

а вот список LSA, которые у вас есть, но именно в виде списка, не в виде содержимого их. Вот. И вы передаете пустой пакет DBD фактически, и сосед передает пустой пакет DBD в сторону вас. И в состоянии X-Start вы определяете, кто из вас круче. Вот один из вас получит роль мастера, а второй получит роль слейв. Опять же, да, что недавно речь шла про то, что там в питоне понятие мастер и слейв отменили, потому что питон — это язык очень прогрессивный, и они против дискриминации. Но вот в SPF не настолько прогрессивный протокол, там мастер и слейв есть, и один из роутеров должен будет выбрать, быть выбран мастером, второй будет выбран слейвом. И мастер начинает в этом случае передачу, после того, как определяется, кто из них мастер, кто из них слейв, оба роутера переходят в состояние X-Start, и дальше мастер отправляет DBD в сторону соседа, сосед отправляет DBD в сторону мастера. Ну, то есть один из них будет мастер, второй будет слейв.

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

значит сосед вашу DBD-шку не получил, значит ее надо переотправить. Никакого другого механизма подтверждения здесь нет. Вы отправляете ДБДшку, сосед отправляет вам ДБДшку. То же самое на самом деле в обратную сторону действует. R2, будучи слейвом, отправляет свою ДБДшку и ожидает подтверждения этой ДБДшки, ДБДшкой от мастера. Но надо в какой-то момент из этого замкнутого круга будет выйти. То есть они могут, конечно, ДБДшками швыряться друг в друга, сколько влезет, но в какой-то момент, да, надо будет сказать, что я отправляю тебе ДБДшку, чтобы подтвердить твою ДБДшку, и мне, пожалуйста, пришли ДБДшку, чтобы подтвердить мою. Процедура выхода будет следующая. Нет смысла отправлять ДБДшки, если нет уже больше ничего, что хотелось бы рассказать. Если у вас база LSDB, LinkState Database, маленькая, она, скорее всего, уместится в один пакет ДБД с очень большой вероятностью. Вы отправляете ДБД с криком, вот у меня все, что есть, я тебе больше не готов ничего рассказать.

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

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

Отправляется сообщение link state request Это сообщение указывает лысейку, которая интересует нас у соседа Сосед принимает такой запрос и говорит Я тебе посылаю ту лысейку, которую ты попросил Или те лысейки, которые ты попросил Сообщение LSR — это link state request ЛСУ — это ответное сообщение, которое идет на link state request Оно будет link state update называться В реквесте можно запросить несколько лсейок сразу И в апдейте тоже можно отправить несколько лсейок сразу То есть лсушка идет в ответ на лср, потому что сосед попросил И значит мы должны ему это ответить В ответ на лсушку надо будет подтвердить получение сообщения И есть для этого специальный тип сообщения, который называется lsack Link state acknowledge Вот эти вот типы пакетов надо будет на экзамене тоже знать То есть первый пакет — это hello С ним все понятно, очевидно Дальше пакеты dbd используются в фазах xstart и exchange

И в фазе loading используется link state request, link state update, link state acknowledge Если мы запросили соседа, у соседа какие-то пачки лсейок И сосед все, что мы у него запросили, нам прислал Мы соседа переводим в фазу full Это значит, что мы от соседа больше ничего не хотим При этом может быть такое, что сосед у нас еще не закончил запрашивать все, что он от нас хотел Потому что, да, вот он говорит, мне не хватает большого количества лсейок, а тебе не хватало маленького Поэтому ты свою фазу full получил быстро А я у тебя сейчас буду долго и нудно запрашивать Дай мне вот такую лсейку, вот секую, вот пятую, вот десятую Но рано или поздно все равно фаза loading должна перейти в full В фазе full можно находиться неограниченно долго Ну, собственно, до тех пор, пока у нас соседство не развалится Поэтому состояние two-way и состояние full, они будут стабильные Все остальные состояния, они так или иначе переходные И в них роутеры долго находиться не должны В фазе loading можно находиться весьма долго, если у вас действительно большая таблица топологии

Но как долго? Ну, десяток секунд, два десятка секунд Если прям большая таблица, три десятка Но в большинстве ситуаций, да, loading у вас заканчивается за единицу секунд Если вы видите, что роутеры достаточно долго находятся в каком-то странном состоянии Например, один роутер завис в X-старте, а другой завис в X-чейнже Ну, значит, вот какой-то один из роутеров не может выйти из X-старта Значит, да, надо будет траблшутить, почему это происходит Вы не должны видеть вот такое вот состояние, что там какой-то роутер находится в этом промежуточном состоянии Если это только не loading Да, вы не должны будете наблюдать, что там в X-старте, например, роутер находится дольше секунды Так, дальше В OSPF у нас есть топология Роутер обменивается кусками топологии Потом по этой таблице топологии строят кратчайшие маршруты

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

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

Она то есть, то нет, то есть, то нет То, что сетка известна вот этому транзитному роутеру Он рассказывает именно про то, что я знаю определенную сеть То есть, рассказывает он это именно в том виде, в котором обычно, традиционно мы говорим про дистанц-векторные протоколы Он говорит, я транзитный роутер, за моей спиной у меня есть сетка Я не скажу вам, как я до нее добрался Просто посмотрите, за сколько вы можете добраться до меня Прибавьте, сколько я знаю эту сеть копеечек И вы получите стоимость полного маршрута через меня до удаленной сети Это классическое дистанц-векторное поведение А поскольку дистанц-векторные протоколы склонны к образованию петель То для того, чтобы передавать трафик в таком дистанц-векторном стиле У SPF был нужен механизм борьбы с внешними петлями С петлями между разными регионами У SPF решила эту проблему очень просто Регионы могут подключаться между собой не как попало

Трафик, который проходит между регионами Он может проходить либо между каким-то регионом и специально выделенным транзитным Либо никак То есть напрямую трафик между двумя нетранзитными регионами ходить не может Даже если вдруг такой роутер будет Который соединяет между собой, например, седьмой и третий регионы До тех пор, пока они оба нетранзитные Он просто не занимается перекладыванием маршрутов между этими регионами Перекладыванием маршрутов мы будем заниматься только между Одним единственным регионом, который будет называться транзитным Или он же Backbone Такой регион-позвоночник Он же Area 0 Вот, и соответственно между всеми остальными маршрутами Вот этот вот роутер, он действительно у нас сидит на границе нулевого региона и седьмого Поэтому маршруты седьмого региона он перекладывает ноль Маршруты нуля он перекладывает в седьмой регион Вот этот вот роутер у нас сидит в третьем регионе Поэтому третий регион он перекладывает в ноль Ноль перекладывает в трешку

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

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

интерфейсами которые принадлежат к одному и тому же региону границы между роутерами проходит границы между регионами проходит по роутеру таким образом то есть у нас на роутере могут быть интерфейс а который смотрит в разные регионы но если мы дружим с соседем то у нас номер региона по которому мы и дружим обязан совпадать вот здесь у нас границы между регионами проходит пара утра здесь у нас границей между регионами проходит по роутеру здесь у нас опять же проходит по работу ручью нас проходит по роутеру раутер который находится целиком внутри одного региона будет называться словом интернал роутер то есть это роутер у которого все интерфейсы смотрят в один и тот же регион неважно какой если у нас есть роутер у которого интерфейса смотрит в несколько разных регионов то он будет называться area border router но есть ограничение у него один из регионов в котором смотрят обязательно должен быть нулевой то есть если это роутер у которого просто два разных интерфейса смотрят два разных региона например 1 и 3 вот он в этом случае обером не будет он

не будет запускать вот тот самый алгоритм перекладывания маршрутов из одного региона в другой у него хотя бы один интерфейс должен быть в нулевой регион для того чтобы он мог перекладывать маршруты поэтому ирира борду роутер это роутер у которого хотя бы один интерфейс смотрят нулевой регион и хотя бы один интерфейс смотрят вне нулево регион если у вас есть роутер у которые вы есть хотя бы один интерфейс нулевом регионе он может быть всего один или все интерфейсы смотрят нулевой регион это роутер которой будет иметь в голове соответственно базу нулевого региона и соответственно в этом случае такой роутер будет называться backbone роутер не важно Это может быть internal router, backbone router, или это может быть ABR, area border router, backbone router. В любом случае у него есть база нулевого региона. И есть еще роутеры, которые имеют на себе какую-то внешнюю маршрутную информацию. Например, вот у нас здесь есть какой-нибудь условный EJRP на этом роутере. Вот у него здесь интерфейс есть, и он по этому интерфейсу, по EJRP дружит непонятно с кем.

Мы хотим маршрут EJRP перекладывать в SPF. В этом случае роутер, который будет внешнюю маршрутную информацию вбрасывать в SPF, будет называться специальным словом AS boundary router. Роутер пограничный для автономной системы. Иногда сокращается до ASBR. Ну, соответственно, здесь аббревиатуры типичные. АBR и ASBR. Вот, АBR это area border router. Роутер на границе с нескольких регионов, в том числе и один из этих регионов нулевой. И ASBR это роутер, который вбрасывает внешнюю маршрутную информацию и делает ее доступной в OSBF. Так, да, ну, собственно, картинка, которую я нарисовал, да, уже. Здесь хорошо видно, что есть у нас регион, который нулевой, который имеет специальную особую роль, он называется транзитный. И есть и остальные регионы, которые должны во всю остальную сеть ходить через этот самый нулевой транзитный регион. При этом регионы между собой соединяются через АБР.

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

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

Вот, и у нас здесь вот Area 0, и, соответственно, здесь у нас Area 0. Но да, в этом случае маршруты из одного нулевого региона, одного куска нулевого региона попадут в ненулевой регион, а дальше из ненулевого региона они обратно в другой кусочек нулевого уже не попадут. Потому что маршруты, которые, да, зародились в нуле, они перекладываются в ненули. А вот маршруты, которые не зародились в ненуле, обратно в ноль уже не перекладываются. Ну, мы про это будем говорить, когда говорим про LSA. Когда будем говорить про LSA. Вот, это такое краткое напоминание того, как устроен SPF просто в рамках такого повторения материала CCNA. Здесь, понятно, никакого хардкора не было. Хардкор будет дальше, когда мы будем говорить про сами LSA, про то, как они перекладываются между регионами, как они перекладываются между роутерами и что с их помощью можно будет делать.

Это совсем не пи deck. Смотрите-что много. Ну, давайте начнем. Мы Comm�