LSDB в OSPFv2

Продолжаем разговор про OSPF в рамках нашего замечательного курса по маршрутизации. Посмотрели мы с вами на LSA, которыми обмениваются роутеры. Напоминаю, что в пределах региона все роутеры должны иметь одинаковую базу и, соответственно, одинаковую LSDB, LinkState Database. Плюс к тому, все роутеры должны будут иметь одинаковый набор LSA-пятёрок. У каждой LSA есть область видимости. В каждом случае это может быть три области видимости. Либо Link, либо Area, либо Autonomous System. LSA первого, второго, третьего, четвёртого типов имеют область видимости Area, регион. Поэтому они распространяются на все роутеры в пределах региона. Нельзя сделать так, чтобы какие-то роутеры не получили какие-то LSA-ки. Фильтровать сами LSA-ки нельзя. Можно только каким-то образом попытаться скрыть некоторую информацию внутри LSA-ки.

Но это отдельная тема. Давайте посмотрим на то, что внутри LSDB у нас будет передаваться. Пакеты, которыми будут LSA-ки передаваться, будут иметь некоторый формат заголовка. Как вы помните, из вчерашнего занятия, было пять пакетов. Первый пакет Hello, потом DBD, LinkState Request, LinkState Update и LinkState Acknowledgement. Номера у них в поле «тип» — 1, 2, 3, 4, 5 — будут указываться в содержимом передаваемых пакетов. Каждый пакет имеет такой заголовок. Сначала в поле версии указывается, что это OSPFv2, потом тип пакета 1, 2, 3, 4, 5 — Hello, DBD, Request, Update, Acknowledge, потом указывается размер пакета. Опять же, намёк на то, что вы можете, например, передавать такой пакет в Ethernet-кадре, и тогда у вас пакет, например Hello, будет совсем маленький, совсем крошечный.

У вас есть OSPF Hello пакет, который оборачивается в IP-пакет, заголовок IP 20 байт, Hello пакет — тоже маленький. И всё это надо завернуть в Ethernet. А в Ethernet минимальный размер содержимого, который вы можете вложить, — 46 байт. И придётся добивать это всё паддингом, нулями. И по внешнему виду в кадре Ethernet 2 не видно, сколько этого паддинга передаётся. Поэтому всё, что вкладывается внутрь IP, должно явно указывать размер содержимого. В нашем случае PacketLength указывает на то, сколько у нас данных передаётся в каждом конкретном случае. Дальше указывается Router ID того, кто отправил такой пакет. Мы отсылаем пакет, мы указываем в нём свой Router ID. Мы указываем свой Area ID в том интерфейсе, через который мы посылаем такой пакет.

Я говорил, что у нас не получится установить соседство, если роутеры находятся в разных регионах. Но на самом деле Area ID пересылается в каждом пакете, не только в Hello. Поэтому если вдруг мы каким-то магическим образом соседство установили, а потом роутер почему-то решил, что он находится в другом регионе, то у него быстро перестанет хотеться с нами дружить. Потому что мы будем присылать каждый раз пакет и указывать, в каком регионе мы находимся. Checksum. Стандартный интернет-чексам, такой же как в IP, такой же как в ICMP, в TCP, UDP. 16-битовая чексумма, которая защищает только достаточно небольшой набор данных. Неплохо справляется с ситуацией вида «случайно один битик поломался». Если поломалось больше одного битика, интернет-чексам будет себя вести плохо. Это не поле с чексуммой CRC32. Это именно такой простенький способ проверить, что хотя бы один битик не поломался.

Дальше. Authentication Type указывает на то, используем ли мы аутентификацию или нет. Если используем, то потом идёт Authentication и Authentication Data. Заголовок достаточно простой. В Authentication Type может быть либо нолик — мы не используем аутентификацию, либо единичка — мы в каждый пакет plain-текстом вкладываем пароль, что лишено особого смысла, потому что злоумышленник перехватит такой пакет, увидит пароль и сможет отправлять пакеты с этим паролем. Поэтому смысла в этой опции примерно ноль. И второй вариант — это криптографическая аутентификация. Что-то наподобие того, что мы видели в EIGRP, когда в пакете будет передаваться хэш от содержимого пакета плюс пароля. Там будет передаваться некая информация про то, как у вас настроена аутентификация. После того как вы указали, какой тип аутентификации используется — либо ноль, либо двойка. Ноль — это значит не используем вообще, двойка — значит используем криптографию.

Единицу смысла использовать вообще никакого нет, поэтому просто можно её сразу вычеркнуть. Дальше указывается Authentication и Authentication Data. Про аутентификацию будем говорить потом отдельно. Там можно сделать попроще и посложнее. Пять пакетов — Hello, единичка, DBD — двойка, LSR — тройка, LinkState Update — четвёрка и LS Acknowledge — пятёрка. Hello используется для установления соседства, и поскольку они отсылаются так же, как и в EIGRP, по таймеру, то неприхождение в течение некоторого времени Hello-пакетов от соседа означает, что сосед недоступен, поэтому обнаружение отказа соседа тоже с помощью них будет происходить. DBD используется только на этапе первичной синхронизации, когда сосед устанавливается, два роутера видят друг друга, два роутера говорят: мы хотим друг с другом установить полные взаимоотношения, мы из 2-Way хотим перейти в Full.

В этом случае мы сначала переходим в ExStart. В ExStart мы обмениваемся DBD-шками для того, чтобы определить порядок взаимоотношений в Exchange. Переходим в Exchange. В Exchange мы обмениваемся самим списком наших LSA-ек без мяса, правда, но синхронизируем оглавление таблицы LSDB, и в Database Description будет как раз это оглавление передаваться. Дальше мы переходим в фазу Loading, и в фазе Loading у нас будут использоваться три типа пакетов: LinkState Request, LinkState Update и LinkState Acknowledge. LinkState Request используется в фазе Loading для того, чтобы сказать: у соседа есть определённая LSA-ка, которой нет у нас, мы видели её заголовок, который передавался в DBD-шке, но мы не видели её содержимого и хотим его запросить. Мы отправляем сообщение Request, говорим: дай нам эту LSA-ку, которая у тебя есть и которую ты только что показал в DBD-шке. Мы отправляем Request с указанием LSA-ек, сосед присылает нам эти LSA-ки, и мы подтверждаем получение LSA-ек с помощью сообщения LS Acknowledge.

Это при установлении соседства — все пять пакетов можно будет встретить. Если у нас нормальная работа — два роутера подружились, установили соседство, оба видят друг друга в состоянии Full, и потом на одном роутере что-то происходит. Какая-то новая сеть возникает. Этот роутер выпускает новую LSA-ку первого типа, что у него что-то произошло, и он про это хочет рассказать своим соседям. Он посылает пакет LinkState Update, в котором будет указана новая LSA-ка. И в этой ситуации, уже в рамках нормальной работы, будут использоваться только два пакета: LinkState Update и LinkState Acknowledge. Такие LSU-шки надо подтверждать. Подтверждаются они либо отдельным LS Acknowledge, либо может быть такое, что вместо LS Acknowledge будет встречная такая же LSU-шка. Про это сейчас отдельно поговорим. LSU-шки могут подтверждаться LS Acknowledge, могут подтверждаться встречными LSU-шками в некоторых случаях.

Для того чтобы понять, как OSPF будет себя вести в каждом конкретном случае при переходе из 2-Way в Full, мы должны понимать, какие канальные среды OSPF различает. Здесь есть некоторая сложность. Сложность заключается в том, что есть стандартный способ определения, какие среды бывают, а есть способ цисковский. И цисковский способ очень сильно не похож на стандартный. Поэтому нам нужно будет запомнить, как это в стандарте выглядит, для того чтобы понимать, как это у многих вендоров сделано. А потом посмотреть, как это у Cisco сделано, и посмотреть различия со стандартом. Потому что если вы будете дружить по какой-то хитрой среде Cisco с не Cisco, вполне возможно, что они у вас по умолчанию не задружатся. Именно потому, что они будут считать, что это разные среды, и в этих разных средах надо себя по-разному вести. По стандарту, по RFC 2328, разделяют все канальные среды на 5 типов. Один из них очень простой — это Virtual Link.

Как раз тот самый псевдопровод, который будет строиться между двумя роутерами, которые ABR, у которых есть разрывный кусок Area 0 — Area 0 с одной стороны, Area 0 с другой стороны. Так быть не должно. Но мы говорим: здесь у нас есть псевдопровод, который тоже Area 0. И базы нулевого региона будут реплицироваться таким образом, даже несмотря на то, что здесь по факту нулевого региона нет. Здесь у нас Area какая-нибудь 50, 51. С Virtual Link сейчас отдельно разберёмся. Остальные среды будут либо Broadcast. Это значит, что в такой среде есть мультикаст. Несмотря на то, что называется она бродкастовая, требуется от этой среды поддержка мультикаста на канальном уровне. Хотя бы в виде бродкаста. Да, бродкаст — это частный случай мультикаста. Если вы хотите отправить какой-то кадр, чтобы он дошёл до всех участников или до некоторых участников, и если среда такое сделать позволяет, а Ethernet такое сделать позволяет, то мы говорим: да, у нас всё хорошо.

Предполагается, что в этой среде есть full mesh, полносвязная топология. У нас есть, например, Ethernet-овский свитч. К этому свитчу подключены 4 роутера. И мы, отправляя какой-то мультикастовый кадр, знаем, что этот кадр обязательно дойдёт до всех роутеров в канале. Не может быть такого, что мы кадр отправили, а он в принципе дойти до соседа не может. От бродкаст-среды именно этого и ожидают. За счёт того, что есть мультикаст, за счёт того, что этот мультикаст дойдёт до всех роутеров в канале, соседство у нас обнаруживается автоматически. Мы просто отправляем Hello-пакеты. И сосед видит наши Hello-пакеты, отвечает нам: привет, я тебя вижу. Но для того чтобы в такой среде у нас не превратилось всё это в огромную кашу из соседств, у нас выбирается DR и BDR. И с этим DR и BDR на самом деле будут выпущены LSA второго типа, установлены соседские отношения со всеми в топологии. За канал будет выпускаться LSA второго типа, и каждый роутер будет говорить: я вижу канал, в котором есть другие соседи.

Но не перечисляется в LSA первого типа, кто конкретно к той же самой LSA второго типа подключен. Если нужно посмотреть, к кому мы подключены в этом канале, мы запрашиваем отдельную LSA второго типа из базы. По умолчанию, на таких бродкастовых интерфейсах, в которых есть полносвязная топология, мультикаст, — например, это Ethernet-среда — у нас таймеры будут 10 на 40. Если мы включаем OSPF на интерфейсе Ethernet, то Hello timer 10 секунд, Hold timer 40 секунд. И если мы включаем на Ethernet OSPF, то анонсируются IP-адреса на этой сети именно в той connected-сетке, в которой они по факту есть. У нас на интерфейсе висит сеть A — мы говорим: да, анонсируется целиком вся сетка. 10.0.0.0/24. Она и анонсируется. Даже несмотря на то, что IP-адрес там 10.0.0.1, всё равно анонсируется вся сеть целиком, без каких-либо сюрпризов.

Если у нас есть point-to-point случай — это провод, в котором ровно два участника. Соответственно, это можно расценивать как частный случай бродкаст-среды. В такой среде есть мультикаст. Мы можем просто отправить в провод кадр, и он дойдёт до получателя. До всех получателей — до всего одного получателя, который в этом проводе есть. Естественно, это можно рассматривать как full mesh, но на самом деле там всего один участник, поэтому full mesh не особо применимо в такой ситуации. Опять же, соседство автоматически обнаруживается, потому что мультикаст у нас, хоть и в урезанном виде, но всё равно работает. Пусть даже до одного участника он достать может. Поэтому нам не надо прописывать соседей вручную, но в этой ситуации у нас не выбирается DR и BDR, не выпускается LSA второго типа, потому что она не нужна. Если мы объявляем интерфейс как point-to-point, например, это PPP-шные интерфейсы, то у нас оно само работает так же, как на Ethernet — само работает и пить-есть не просит.

Таймеры на таком интерфейсе тоже будут по умолчанию 10 на 40. Анонсируется опять же сетка. Если у нас между двумя роутерами будет point-to-point канал и здесь есть какая-то сеть, там 10.0.1.0/24, то эта сетка попадает в таблицы маршрутизации на всех роутерах, которые где-то там могут присутствовать. Анонсируется, да, вся сеть. Если у вас есть какой-то другой тип среды, не broadcast и не point-to-point, я вас поздравляю, потому что вы попали. Это будет означать, что у вас в этих средах нет мультикаста. А нет мультикаста – это сразу беда. В point-to-multipoint среде нет мультикаста, поэтому мы должны будем каким-то образом понять, что у нас есть интерфейс, в котором возможно множество соседей. То есть мы одним проводом смотрим на соседей,

и в этом проводе у нас есть много разных соседей, но мы не можем отправить какой-то кадр, который дойдет до всех этих соседей сразу. Мы должны будем отдельно кадр отправлять каждому из наших соседей. Например, DMVPN, да. То есть если у нас есть такой провод, в котором много соседей, но мы не можем отправить один пакет на всех, мы должны каждому отдельному отправлять отдельный пакет, То в этом случае возникают проблемы Единственное, что мы должны будем каким-то образом автоматически обнаруживать этих самых соседей То есть мы должны будем фактически наперед знать, с кем мы дружим Соседство у нас появляется автоматически DR и BDR в этой ситуации не выбираются, потому что у нас неполно связанная топология Мы до некоторых добраться можем, а некоторые еще здесь возможно будут Что трафик до них в принципе дойти не может И вот если у вас есть point-to-multipoint, стандартная среда То в этом случае есть роутеры, с которыми мы можем дружить

А есть роутеры в пределах канала, с которыми мы не можем дружить Но есть кто-то еще, кто с ними может дружить То есть вот так трафик не ходит, а вот так ходит Таймеры в этой среде будут устанавливаться 30 на 120 То есть мы каждому соседу раз 30 секунд будем посылать отдельное hello У нас есть связь с вот этим вот товарищем, мы ему посылаем hello Связь с вот этим товарищем, мы ему посылаем hello С этим товарищем связи нет, мы ему hello не посылаем, потому что не можем Но тем не менее, да, мы должны будем в принципе предполагать Что нам в какой-то ситуации захочется ему посылать трафик Поэтому наша задача будет в SPF Каким-то образом сделать понимание, какие сетки за спиной у этого роутера есть По факту, если у нас есть вот такая вот топология В которой вроде бы все подключены к одной и той же среде Вроде бы у всех один интерфейс, который смотрит в одну и ту же среду Но по факту это не одна и та же среда Это на самом деле несколько разных способов передавать друг другу данные Вот в такой ситуации у нас на самом деле у SPF должен пазл собрать по-другому

Он должен будет сказать, давайте вот это сотру Он должен будет сказать, что связи у нас есть не между всеми и всеми А у нас есть роутер Роутер-1, роутер-2, роутер-3, роутер-4 Роутер-1, роутер-2, роутер-3, роутер-4 Ну как мог, воспроизвел У нас должен роутер-1 сказать Я дружу с четвертым, я дружу с третьим Я не дружу со вторым, но третий дружит со вторым То есть у нас нет какой-то общей среды, с которой подключены вообще все. У нас есть отдельные соседства между разными роутерами. И если вдруг у роутера 2 за спиной есть какая-то сетка, то NextHop для такой сетки должен быть не роутер 2, а роутер 3. Я в интерфейс посылаю кадр и говорю, не на роутер 2 посылаем, а на роутер 3. А роутер 3 должен обратно это все перефарвардить на двойку. И опять же, это все в одном регионе находится, все в одном интерфейсе находится, в одной канальной среде.

Но вот OSPF под такие вещи должен быть заточен, и он это может сделать только в одном сценарии. Если всю вот эту вот сетку он будет воспринимать не как единый монолитный канал, а как отдельные IPшники. Кто-то на кого-то в этом канале как-то смотрит, окей, пусть прекрасно смотрит. У нас нет никакого коннекта среды на этом интерфейсе, нет никакой слэш 24. У нас есть отдельные IPшники, поверх которых строится соседство. Соседство фактически типа в кавычках point-to-point-to-to. Поэтому вся сетка целиком здесь вот эта вот слэш 24 или какая она там не будет анонсироваться. Вместо нее анонсируются IPшники хоста. И фактически, когда второй роутер говорит, я знаю, как добраться до вот этой вот сетки, он говорит, у меня вот здесь вот есть IPшник, ну не знаю, 192.168.1.2. Третий роутер принимает такой анонс и отправляет анонс, говорит, я знаю, как добраться до IPшника 192.168.1.2, ходить через меня. И в таблицу топологии первого роутера будет добавляться IPшник 192.168.1.2, до которого можно добраться через 192.168.1.3.

анонсируются хостовые IPшники, а не вся сетка внутренней, вот эта вот сетка для соседства целиком. DRBDR в такой сети не выбираются, никаких LSA второго типа у нас нету, никакого общего канала нету. Поэтому да, вот point-to-multipoint это такой вот сценарий, при котором есть общая сетка в кавычках, но она на самом деле не общая. На самом деле поверх нее надо устанавливать соседство отдельно на каждого соседа и проверять у кого с кем есть двусторонняя связность. И для определения этой двусторонней связности у нас будут бегать hello-пакеты, которые будут предназначены именно специально для отдельно этого соседа. Есть отдельный случай, который называется non-broadcast. Этот non-broadcast сеть предполагает, что у вас полносвязная топология, то есть все роутеры друг друга в принципе могут видеть. Но в этом случае, так же как и в предыдущем point-to-multipoint, нет мультикаста, поэтому мы должны будем дружить, как бы это сказать, мы должны будем дружить с использованием unicast-вых hello-пакетов.

Но если это топология, в которой все друг друга видят, мы можем сказать, это фактически эквивалент тому, что у нас есть вот такая вот LSA-ка второго типа. То есть опять же сокращаем количество дружбы между роутерами, мы говорим, у нас есть LSA-ка второго типа, в non-broadcast-овой среде выбирается DR-BDR, в non-broadcast-овой среде будет анонсироваться вся сетка целиком, потому что нет проблемы вида Вася, Петю не видит, но в non-broadcast-овой среде у нас нет мультикаста, у нас все hello-пакеты будут бегать unicast-ом, поэтому DR будет известен, DR будет существовать, он будет делать LSA-ку второго типа, и он будет, соответственно, unicast-ом устанавливать hello-сообщениями соседство с каждым роутером. Их нельзя загнать в разные регионы, потому что это все один и тот же интерфейс, одна и та же канальная среда, поэтому в разных регионах они здесь в принципе не могут быть, это все один, ну, как назовите, один VLAN, если хотите. Они всеми интерфейсами должны получать hello-сообщения от друга,

и в этих hello-сообщениях должно все быть в одном регионе. Если вы их можете руками распихать по разным VLAN, пожалуйста, сделайте эти интерфейсы в разные регионы, ну, то есть, если вдруг захочется. Но здесь как раз фишка именно в том, что все находится в одном регионе, в одном интерфейсе, в одном канальной среде. Соседство вам придется прописывать ручками. Да. Non-broadcast означает именно то, что вот написано, что бродкастов нету, мультикастов нету, а в остальном оно работает так же, как бродкаст. То есть полно связанная топология, анонсируется вся сетка, придумывается LSA-ка второго типа, как следствие есть DR, DR со всеми дружит, все, кто видит DR, видят и всех остальных, кого видит DR. Ну, вот, да, единственное, что соседи прописывать ручками. Frame Relay нет, потому что во Frame Relay у вас не Full Mesh, поэтому non-broadcast это не про Frame Relay. Non-broadcast это про какую-то вот среду, даже не знаю. DMVPN, вот, DMVPN как раз идеальный пример.

У вас мультикаст на нем не работает, а Full Mesh там есть. Еще раз повторю, это 5 типов канальных сред, которые описаны в RFC 2328. Если исключить OSPF Virtual Link, то останется 4. Broadcast, Non-broadcast, Point-to-Point, Point-to-Multipoint. Что в Broadcast? Что в Non-broadcast у нас полносвязная топология? Все всех видят. Просто в случае с Broadcast есть Multicast, а в случае с Non-broadcast мультикаста нет. Broadcast предполагает, что у вас есть полносвязная топология, Non-broadcast предполагает тоже, что у вас есть полносвязная топология. Но в Broadcast есть Multicast, или как его разновидность Broadcast, то есть вы можете отправить кадр, такой, который дощупает вообще всех, и тем самым установить автоматически соседство со всеми участниками. Non-broadcast не предполагает, что у вас есть такой способ отправить один кадр, который дойдет сразу до всех. Поэтому вы вынуждены отправлять отдельные Unicast-овы Hello пакеты всем участникам.

И вы не можете один отправить. Вы можете отправить только каждому отдельный Unicast-овы пакет, и вы должны заранее знать, кому вы такие пакеты отправляете, потому что автоматически соседей вы нащупать таким образом не можете. Вот. В остальном они одинаковые. Анонсируется вся сетка целиком, выбирается DRBDR, он генерирует LSA ко второго типа, и эта LSA ко второго типа символизирует, что у вас связность именно полноценная, что каждый видит каждого. Unicast-овы по крайней мере. Вот. Point-to-Multipoint, пардон, Point-to-Point, это сценарий, в котором у нас только два участника. Там LSA ко второго типа не нужна, там DRBDR не нужен. Анонсируется при этом вся сетка Connected. Ну, Multicast-овы когда он как? Что его есть, что его нет, это на самом деле не нужно. Соседство у нас опять же поднимается автоматически. И вот еще один сценарий, это Point-to-Multipoint, который указывает, что Multicast-то у нас нету,

топология неполносвязная, кто-то кого-то как-то видит, но не все-всех. Но зато мы, да, мы можем каким-то образом нащупать наших всех соседей. Point-to-Multipoint в стандартном RFC 2328 предполагает, что у вас есть способ какой-то нащупать всех соседей, которые вам доступны. Вот. Поскольку неполносвязанная топология DRBDR не выбирают, LSA ко второго типа не генерится. И для того, чтобы маршрутизаторы могли построить маршруты правильно на те роутеры, через которые действительно сетка может быть достигнута, у вас анонсируется не вся Connected сетка целиком, а только хосты на NTM-интерфейсе. Ну и в случае с Point-to-Multipoint и Non-Broadcast Hello-пакеты у нас начинают ходить Unicast. Соседей у нас в таких интерфейсах может быть много. Поэтому, чтобы не отправлять пакеты слишком часто, таймеры увеличиваются в три раза. Вместо 10 на 40 таймер становится 30 на 120.

Замечание следующее. В стандарте не написано, что роутеры, которые друг с другом начинают дружить, что они друг к другу отправляют пакеты с указанием этого самого типа среды. Поэтому вы, в принципе, можете сделать ход конем. Вы можете сказать, что у вас один роутер будет отправлять пакеты, имея в виду, что это пакеты, допустим, на Point-to-Point соседстве, а другой роутер будет говорить, а я, в принципе, этот интерфейс считаю, что это Broadcast-овый интерфейс. Ну и да, главное, чтобы у них таймеры не выходили за пределы разумного. Таймеры обязаны быть одинаковыми, впрочем. Поэтому, если у нас Point-to-Point соседство, у нас таймеры будут 10 на 40, в Broadcast-овой среде тоже таймеры 10 на 40. То есть вот такая вот ситуация, когда Point-to-Point сосед с Broadcast-ом пытаются подружиться, у них действительно все подружится. Единственное, что Point-to-Point при этом не будет генерить LSA-ку второго типа, а Broadcast-овый сосед, он будет пытаться выбрать DR-а, BDR-а,

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

Вот, вы можете выбирать тип канала, как правило. Это, конечно, зависит от реализации, но, тем не менее, если у вас есть интерфейс, у него есть какой-то автоматически назначенный тип, и вы можете сказать, что это Cisco, например, Cisco, да, или роутер ваш правильно назначил этот тип интерфейса или неправильный. Я как раз уже показывал в предыдущей демонстрашке, что действительно можно взять и поменять тип интерфейса. У меня интерфейс был Ethernet-овый, и у него был тип среды Broadcast. В Broadcast выбирается DR-BDR, генериция LSA-ка второго типа, но если я поменял на Point-to-Point, то, соответственно, да, LSA-ка второго типа там оттуда исчезла, именно потому что она там не нужна. Вот. Такая вот штука. Далее. Так, что-то у меня еще тут такое было. Хочу обратить ваше внимание на следующий момент. Давайте сотру слайда. Это стандартные способы указания канала.

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

Наши соседи, они будут проходить некоторый процесс установления этого самого соседства. Если вдруг мы знаем, что у нас сосед существует, он прописан, например, статически, как раз в предыдущий сценарий, да, что у нас есть каналы, в которых соседство можно прописать статикой. Это нонбродкаст и верталлинг. Вот если мы знаем, что сосед у нас существует, мы знаем, кто он, но он нам не присылает hello-пакеты, мы такого соседа будем считать, что он... Пардон. Мы не можем сами отправлять ему hello-пакеты, в принципе, потому что мы не можем добраться до IP-шника. Это будет состояние down. Down означает, мы знаем IP-шник соседа, но мы не можем на него добраться, его нет в таблице маршрутизации. В down мы не отправляем hello-пакеты. Если мы начинаем уметь отправлять hello-пакеты соседу, то мы переводим соседа в фазу attempt. Attempt — это мы ему отправляем hello, а от него ничего не приходит. Если вдруг от соседа приходят hello-пакеты, он сразу переходит в init.

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

Если мы der other на интерфейсе, если он der other, то мы дальше в этом состоянии и останемся. Поэтому здесь, в этот момент, принимается решение, нужно ли нам дальше дружить. Здесь происходит выбор DR и BDR. То есть вот тут вот они происходят на самом деле. DR, BDR выбирается тут. Если мы принимаем решение, что DR, BDR в этой сети есть, мы знаем, кто DR, мы знаем, кто BDR, мы знаем, кто мы, мы знаем, кто наш сосед. Вот. Мы принимаем решение, что мы должны перейти с этим соседом в фазу следующую, или мы не должны это делать, потому что и мы, и наш сосед DR other. Если мы принимаем решение, что нам либо не нужно выбирать DR и BDR, либо нужно выбирать DR и BDR, и это кто-то из нас, то дальше мы переходим в следующую фазу, xStart. Нам требуется синхронизация таблицы LSDB. Выбираем мастера слева, переходим в Exchange. В фазе Exchange обмениваемся DBDшками. После завершения переходим в фазу Loading.

В фазе Loading запрашиваем недостающие у нас LSA-ки с соседа. Он нам эти LSA-ки присылает. LS Request, LS Update. И, соответственно, мы подтверждаем все, что мы получили от соседа, переходим в... Точнее, переводим соседа в фазу Full. Все вот эти вот Down, Attempt, ToWay, Full и прочее, это только в голове нашего роутера, в табличке соседей, напротив каждого соседа упоминает... Ну, не упоминание, а заметочка. Вот насколько хорошо или насколько плохо с этим соседом мы продвинулись в установлении соседства. По сети вот эти вот самые фазы не передаются нигде, и сосед не знает, в какой фазе он у нас. То есть мы знаем, в какой фазе сосед у нас находится, но это не значит, что сосед должен знать про нас, что мы знаем про него. Вот. Сосед напротив про нас ведет такой же учет, то есть он говорит, у меня обнаружился новый сосед, с ним надо перейти там в такую-то фазу и так далее. Это означает, что в принципе может быть ситуация,

когда два роутера друг на друга смотрят, интерфейс, допустим, прямой. Вот они говорят, мы видим соседа Васю, мы видим соседа Петю, нам нужно перейти в следующее взаимоотношение, то есть мы находимся в фазе ToWay, мы должны перейти в XStart. Оба переходят в XStart, соседа говорят, мы видим соседа, XStart, у него текущая фаза. XStart здесь, XStart здесь. Дальше один из соседей говорит, я все закончил выбирать мастера Слейва, я перевожу соседа в фазу Exchange. Я напротив соседа говорю, что с моей точки зрения с этим соседом мы выбрали мастера Слейва, и нам нужно обмениваться DBD-шками. А сосед почему-то не хочет переходить фазу Exchange, он остается в XStart. То есть на соседе мы с его точки зрения не прошли какую-то процедуру, которая позволит ему перевести вас в Exchange. И может быть такое, что у вас на роутере левом, на R1, сосед R2 виден в фазе Exchange, а на R2 сосед R1 виден в фазе XStart. Такое вполне может быть.

Вот. Да. Роутер будет обмениваться Hello-сообщениями. Формат Hello-сообщения довольно простой. Сначала указывается, какая у нас маска на интерфейсе. IP-шник, который у нас на интерфейсе, очень легко увидеть из самого IP-пакета. То есть мы отправляем IP-пакет, и мы говорим, мы отправляем этот пакет с интерфейса, на котором IP-шник, ну какой-то определенный, мы этот IP-шник указываем в качестве source IP-адрес. Вот. Но когда у нас есть два роутера, R1 и R2, вот они должны будут иметь возможность подружиться, только если у них IP-шники будут из одной сети. 10.0.0.1.24 и 10.0.0.2.25 Пинги друг к другу посылать могут, а подружиться в OSPF не смогут. Именно потому, что есть вот это вот поле Network Mask, которое в каждом Hello передается, и эти Network Mask должны совпадать. Это вот эта 24-я маска здесь, и 25-я маска вот здесь.

Опять же, это зависит от реализации, и некоторые реализации, например, цисковские, замечены в том, что они это поле Network Mask игнорируют, и они позволят подружиться по OSPF, если у вас маски не совпадают. Но тем не менее, да. Указывается Network Mask, и Network Mask, естественно, указывается с Primary IP-шника. И у вас для того, чтобы роутеры подружились, должны совпадать именно Primary сетки на интерфейсах. Дальше вы указываете, как часто вы посылаете Hello пакеты. Пересылается в пакете только Hello интервал, то есть вот они обязаны у вас совпадать. HoldTime'ы по факту не пересылаются. Пардон, HoldTime'ы пересылаются, да, HoldTime'ы пересылаются, наврал, наврал. И они пересылаются отдельно. Hello интервал у вас будет 16-битовый, 2-байтовый, а Dead Interval будет 32-битовый, 4-байтовый. Вот. Дальше указываются какие-то возможные поля опций, 8-битовое поле с флагами, и указывается поле Priority.

Вот это вот поле Priority будет нужно для выбора DR и BDR. Чем больше приоритет, тем больше вероятность того, что роутер станет DR и BDR. Дальше каждый роутер, каждый раз, когда посылает Hello пакет, он указывает, кого он читает DR, и каждый раз он указывает, кого он считает BDR. При этом может быть такое, что вы DR и BDR не выбирали, и вы пока не знаете, кто они будут, поэтому вы указываете их нулями. Эти поля не сравниваются при прохождении Hello пакетов. То есть даже если вдруг получится так, что у нас роутер R1 говорит, я считаю DR самого себя, а R2 говорит, а я считаю DR самого себя тоже. Ну, соответственно, у них не совпадают эти самые DR, и очевидно, что каждый из них считает DR себя. Каждый из них будет выпускать, например, лосевику второго типа. Но по каким-то причинам они это сделали, и вот в этой ситуации, да, ничто не помешает им подружиться. То есть DR IP-адрес и BDR IP-адрес это чисто справочная информация. Она не обязана совпадать

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

это не является препятствием для установления соседства. Дальше. Вот этот вот самый атрибут neighbor list. Мы указываем ID-шники соседей, с которыми мы хоть как-то обмениваемся трафиком. То есть, если сосед прислал нам hello сообщение непротиворечивое, мы его сразу же заносим в neighbor list. Мы его заносим в табличку соседей, мы его заносим в neighbor list на этом интерфейсе. И мы отправляем сообщение. Мы видим от тебя непротиворечивое hello сообщение. И если сосед отправляет сообщение с указанием того, что он видит нас, это значит, что у нас действительно непротиворечивая конфигурация на обоих роутерах, и мы действительно можем переходить в следующую фазу. Так, hello сообщение будет отправляться на мультикастовый адрес 224.005. Все SPF роутеры. Отправляются они с частотой один раз в hello интервал по умолчанию 10 на 40 на интерфейсах

бродкастовых и point-to-point или 30 на 120 на нон-бродкаст и как называется там point-to-multipoint. Но если мы говорим да, на бродкаст и point-to-point, то у нас 10 на 40. Вот. В случае с NBMA каналами нон-бродкаст и point-to-multipoint мы отправляем пакеты unicast мультикаст не работает. Мы отправляем unicast и мы отправляем один пакет раз в hello интервал каждому соседу независимо. То есть в случае с бродкастом point-to-point мы отправляем один на всех. И за счет этого мы можем отправлять их часто раз в 10 секунд. Учитывая, что в каналах, где мультикаста нету, мы отправляем каждому соседу отдельный hello пакет, то мы делаем это реже, чтобы с учетом большого количества соседей у нас, соответственно, сообщения пересылались не очень много в единицу времени. Поэтому мы присылаем один пакет

по таймеру каждому соседу. Hello сообщения не содержат в себе никакого ценного мяса. Они всегда одинаковые, до тех пор, пока у нас стабильно работает, они всегда одинаковые, поэтому они не требуют подтверждения. Там нет ничего, что требовалось бы подтверждать. Есть одна такая штука, которая называется immediate hello. Это дополнительный механизм костыльный. Очень интересный на самом деле костыль, который заключается в следующем. У нас есть роутер R1, интерфейс, на котором только что организовался роутер R2. R2 только что проснулся, прислал обычное hello сообщение. Говорит, я просто проснулся, я никого пока не вижу, вот я есть. Радуйтесь. R1 по-хорошему, по стандарту, мы отправляем сообщение на интерфейсе один раз в hello интервал. Этот интерфейс у нас Ethernet-овский, на нем, соответственно, есть LSA-ка второго типа, на нем, возможно, есть какие-то другие роутеры, вот, и поэтому мы отправляем сообщение hello по таймеру раз в 10 секунд, если мы этот таймер не трогали.

Если hello сообщение, что я только что проснулся от R2, пришло почти сразу после того, как мы предыдущее сообщение hello отправили, то мы должны будем 9 секунд ждать до тех пор, пока не сработает снова таймер, и мы не скажем привет, я тебя тоже вижу. Ответное hello пойдет через 9 секунд. Схема immediate hello заключается в том, что как только вы увидели hello сообщение, в котором вас в качестве соседа нету, вы отправляете немедленно hello unicast на этого соседа. Вы говорите привет, я тебя тоже вижу. Эта схема предполагает, что сосед будет согласен принять unicast hello. Если сосед согласен его принять, окей, он его обработает, и, соответственно, немедленно вы установите соседские взаимоотношения, немедленно сможете перейти в рабочую фазу. Если сосед не понимает, что такое unicast соседи, то в этом случае он будет говорить, нет, я это выбрасываю, это неправильное hello, и в этом случае вы по таймеру опять же отправите

в следующую, там, через 9 секунд, уже нормальная мультикастовое hello сообщение, и в этом случае, да, у вас просто медленнее, но все то же самое будет сработать. Immediate hello поддерживается, например, цисками, и оно действительно заметно ускоряет работу, заметно ускоряет процедуру установления соседства. Иногда, впрочем, эта схема может не сработать, поэтому, если вдруг вы включили интерфейс, и на нем не сразу нашлись соседства, только через некоторое время, да, это вот вполне может быть в ситуации, когда immediate hello одним из соседей не поддерживается. Так, hello у нас будет работать на этапе down, это значит, что мы не отправляем hello сообщение, потому что мы не можем это делать. Attempt означает, что мы знаем IP-шник соседа, мы пытаемся отправлять ему hello сообщение, но мы ничего не получаем. init мы получаем сообщение от соседа, но он нас не указал в качестве нейбора, to way мы получаем hello сообщение, и он указал

наш router ID в нейбор лист в качестве нейбора. Дальше возникает вопрос, а что еще мы будем делать? И мы определяем DR и BDR, именно определяем, потому что зная, какие hello сообщения приходят от соседей, мы знаем весь список соседей, мы знаем их IP-шники, мы знаем их приоритеты. Мы можем сказать, исходя из той информации, которая у нас в базе есть, мы будем считать, что DR и BDR будут вот кто-то. Мы эту информацию затем будем отправлять в hello сообщениях, что мы считаем DR и BDR, вот его на этом интерфейсе, но, соответственно, эта информация нигде не будет проверяться. То есть, то, что мы считаем, окей, это наше право так считать. Сразу возникает вопрос, а что, если у нас есть неполносвязная мультикастовая топология, а сеть у нас объявлена как вот, например, бродкаст. То есть, у нас есть LSA-ка второго типа, LSA-2, у нас ее должен будет выбирать BDR, простите,

DR, у нас выбирается DR и BDR, но к этой сети у нас подключаются там 4 роутера. Вот. То есть, по-хорошему, предполагается, что DR должен видеть вообще всех. У нас должна быть связь между DR и всеми остальными. И, соответственно, если у нас есть мультикаст, то прекрасно этот DR должен будет нащупать всех остальных с помощью как раз того самого мультикаста. Если вдруг у нас, ну вот типичный пример, это DMVPN. Давайте представим себе, что у нас вот здесь вот есть DMVPN-облако. DMVPN. И в этом DMVPN-е мультикаста нету. Мультикаст есть только между хабом и споуками, но между споуками мультикаста нету. И вот у нас есть, вот, например, хаб споук 1, споук 2, споуки 2 и споук 3. И вот так получилось. Соответственно, что у нас у хаба приоритет будет,

например, поменьше, ну, например, 10, а у споуков будет приоритет 20, 30 и 40. Что в этой ситуации будет? Хаб со споуком 2 подружились, и, соответственно, они перешли в фазу 2-way. Дальше они сказали, надо выбрать DR и BDR. И хаб говорит, я считаю, что DR в такой ситуации должен быть ты, дорогой, споук 2. И тот говорит, да, я тоже так считаю, у меня действительно есть мнение, что DR в этой сети буду я. У меня приоритет будет больше, чем у тебя. Дальше хаб со споуком 2 начинает дружить и говорит, хаб с споуком 2, ты знаешь, я считаю в этой сети DR с споука 2. У него приоритет аж 30. И споук 1 говорит, ты знаешь, это, конечно, очень здорово, что ты его считаешь DR, только я не знаю, как до него добраться, поэтому DR в сети буду я. И споук 1 будет считать DR себя, споук 2 будет считать DR себя, а хаб будет считать DR кого-то из них. После чего, соответственно, хаб дружит со споуком 3. Опять же, у нас в предположении, что мультикаст

дружит между только хабом и споуками. Споук 3 будет говорить, ты кого считаешь DR? Ага, второго. Я не знаю, кто такой второй, но у него в любом случае приоритет недостаточно такой крутой, как у меня, поэтому DR буду в такой сети я. И получается, да, что хаб переквалифицируется, говорит, хабом, самым DR будет у нас споук 4, у него приоритет самый крутой. Споук 4 будет говорить, да, я действительно крутой, у меня тоже приоритет самый крутой. А споук 2 и споук 1 при этом про споука 3 ничего не знают, и они будут по факту считать DR себя. И у вас в такой сети будет 3 LSE 2 типа, которые на самом деле будут указывать непонятно на кого. Споук 2 выпустит LSE свою, который говорит, я через нее связываюсь с хабом. споук 1 то же самое сделает отдельную LSE скажет, я через нее связываюсь с хабом, а хаб будет говорить, вы знаете, ребят, вы, конечно, крутые, но по факту, да, я-то с вами как бы не согласен

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

роутерами. Нужны они только в ситуации, когда у вас полносвязная топология, когда все друг к другу могут отправлять трафик. Используются не только в средах с бродкастом и нон-бродкастом. Здесь написано NBMA, давайте я лучше напишу вместо этого нон-бродкаст. Вот, нон-бродкаст. Когда у вас начинает работать OSPF на интерфейсе, он ни про кого не знает, он говорит, я сейчас буду отправлять hello-сообщение, и вы отправляете hello-сообщение с криками, я никого не вижу, никого не знаю, DR-BDR у меня пустые, 0-0-0-0-0. И вы в течение некоторого таймера, который по умолчанию равен датинтервалу, вы в течение некоторого времени анонсируете эти самые 0-0-0-0-0 в качестве DR-BDR. Если вы в течение некоторого времени, вот этого самого по умолчанию, например, 40 секунд, получаете какое-то hello от соседа, который знает, что DR будет кто-то еще, вы говорите,

окей, DR будет он. DR – это роль без приемтинга, в смысле, да, без приемтинга, то есть один раз выбрали его, и дальше он такой работает. Нагрузка на DR, в общем-то, небольшая. Если кто-то считает себя DR, мы говорим, окей, мы считаем DR-ом его, раз он уже работает, а мы только что включились. Если вы получаете несколько hello от соседей разных, и они указывают DR-ами разных соседей, да, разные ID-шники, то вы говорите, окей, в этом случае мы будем выбирать DR-а по максимальному приоритету, а если приоритеты одинаковые, тогда по роутер ID. Но опять же, вы выбираете в качестве DR-а только тех, от кого вы получаете hello сообщение. Если вы видите, что кто-то вам присылает hello сообщение и указывает DR-ом кого-то еще, а вы от этого кого-то еще не получали hello сообщение, то такое указание DR-а вы будете игнорировать. Вот.

Ну, по факту, да. Кто может стать DR-ом? Это может быть мы. Если вдруг мы считаем, что у нас самый крутой приоритет, либо самый крутой ротер ID, самый большой, то вот в этом случае мы сами себя будем считать DR-ом. Это могут быть те соседи, с которыми мы перешли в фазу two-way, за исключением тех, у кого приоритет ноль. То есть, если кто-то заявляет, что у него приоритет ноль, он никогда DR-ом не может быть. Ни он себя не будет считать DR-ом, ни мы его тоже DR-ом считать не будем. Он присылает нам hello-сообщение, он говорит, я в этом hello-сообщении отказываюсь от того, чтобы стать DR-ом. Ну, вот, когда мы получаем несколько вариантов, кто может быть DR-ом, в этом случае мы выбираем соседа с максимальным приоритетом, а если есть несколько узлов, у которых одинаковый приоритет, тогда у кого максимальный роутер ID. А потом за всех, из всех, кто может гипотетически быть BDR-ом, ну, кроме самого

DR-а, вы, соответственно, отдельно производите процедуру вычисления BDR-а. И опять же, вы проверяете, что у вас есть тувей-связность со всеми вашими кандидатами. Если у вас тувей-связности с кем-то нету, значит, вы с ним не готовы устанавливать соседские отношения. Значит, вы с ним не готовы объявить его DR-ом. После того, как соседи перешли в тувей, дальше каждый роутер, независимо от всех остальных, посчитал, кого он считает DR-ом в DR-ом. Мы определились с тем, кто будет DR-ом в DR-ом. Мы должны будем перейти в следующую стадию. И следующая стадия это будет, соответственно, X-start. И какой ситуации мы будем переходить из туве в X-start? Если мы выбираем DR-ом, BDR-ом, то есть, если мы вообще не выбираем в принципе DR-ом,

BDR-ом, это происходит в point-to-point, это происходит в point-to-multipoint и это происходит на virtual link. Вот в этой ситуации мы сразу переходим в X-start, как только мы перешли в тувей. Если мы выбираем DR-ом, BDR-ом, и мы считаем, что DR-ом должен быть кто-то другой, тогда мы должны будем нет, пардон, если мы выбираем DR-ом, BDR-ом, и мы либо сами будем DR-ом, либо мы будем гипотетически дружить с DR-ом или BDR-ом, то в этом случае мы говорим да, мы должны будем перейти в следующую фазу в X-start. Если мы DR-other и другой роутер, с которым мы собираемся принять решение о переходе в X-start, тоже DR-other, то мы говорим нет, мы не будем переходить в X-start, мы остаемся кто вы. В фазе X-start нас обменивают роутеры одной DBD-шкой, которая будет непротиворечива по отношению к соседям. То есть для того, чтобы перейти в следующую фазу в exchange

из X-start, нам нужно будет отправить соседу DBD-шку и получить от соседа непротиворечивую DBD-шку. В этой фазе будут определяться, кто из нас будет мастером, кто будет слейвом и проверяется совпадение MTU. Если у вас два роутера и они друг на друга настроены интерфейсом, у которых с одной стороны и с другой стороны будут MTU не совпадать, один будет например 1480, а другой будет 1500, то в этой ситуации успех у вас не подружится. Именно не подружится, потому что они не смогут друг от друга друг другу отправить непротиворечивые DBD-шки на фазе X-start. Мы отправляем DBD-шку и указываем MTU 1500. Сосед отправляет DBD-шку и говорит я тебе буду отправлять DBD-шку 1480. До тех пор, пока они не согласуют какое-нибудь MTU общее для них, они

соответственно не смогут перейти дальше. при этом внутри DBD-шки у нас будет передаваться сообщение следующим образом. Сначала идет двухбайтовый интерфейс MTU, ну здесь все понятно. Если это Virtual Link, то MTU указывается нулевой. В остальных случаях вы можете указать MTU, тот, который у вас висит на интерфейсе. Однако вы не должны будете как бы знать, что отправляются пакеты с вот этим вот самым MTU, если вы действительно не уверены, что MTU будет именно такой. То есть если вдруг у вас есть интерфейс например Point-to-Point или интерфейс Broadcast вы можете конечно взять PathM2Discovery и попытаться каким-то образом опознать какого размера пакеты на таком интерфейсе пройдут. Самый простой

вариант в принципе это посмотреть настройки интерфейса. Есть такие интерфейсы по которым не видно какой у них MTU. В этой ситуации если вдруг у вас есть такой воображаемый интерфейс и на нем непонятно какой MTU у вас будет вы должны будете сказать что MTU мы предполагаем будет минимально гарантированный в протоколе IPv4. Гарантированный MTU который поддерживается обязательно любым интерфейсом это будет 576 байт. То есть если вы говорите что мы не знаем какой MTU у нас используется мы не можем выполнить пасс MTU discovery то в этой ситуации мы прописываем 576 ну и тогда все пакеты у нас должны быть не более чем такого размера. если мы можем взять посмотреть настройки интерфейса ну например там не знаю у нас Ethernet есть вот в Ethernet у нас вложение может быть до 1500 байт размера. Мы говорим раз у нас размер вложения в Ethernet 1500 байт мы вкладываем в это IP пакет и IP пакет как следствие тоже может быть 1500 байт. Ну вот в этом случае мы говорим

MTU в IP у нас 1500 байт. Дальше поле с опциями там ничего для нас принципиально интересного нету. Вот здесь вот еще соответственно опция еще флаги и тут уже как раз интересное для нас есть. Тут будут три флага init more и соответственно master slave imms more будет означать что вы начинаете работать в фазе exchange и у вас еще есть чего отправлять соседу. Ну мы при этом говорим когда мы говорим мастер slave а тут как раз интересный для нас будет интересный флаг потому что он работает как раз в фазе x-start поэтому получается что

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

то есть оба роутера в фазе экстарт отправляют стартовую дбдшку init означает что у нас происходит процедура экстарт m означает что это не последняя дбдшка и ms я считаю себя мастером потом один говорит я сдаюсь я не считаю себя мастером я считаю себя слайвом ms отправляет 0 m1 означает что есть еще что рассказать но это уже фазе эксченж и вот и 0 указывает на то что фаза инициализация у него закончена флаг и давайте вернусь на предыдущий слайд вот этот вот флаг и будет нужен для того чтобы согласовать стартовые так называемый sequence number каждое сообщение которое будет мастер передавать в сторону слейва будет подписано оно будет иметь номер то есть мы отправляем дбдшка мы говорим это дбдшка такой же номер потом соответственно второе отправляем второе дбдшка второе дбдшка третье дбдшка третье дбдшка и каждый раз

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

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

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

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

большой вероятностью не совпадение мту абсолютно классическая вещь на экзамене весьма вероятно будут на это вопросы то есть если два соседа видят друг друга по-разному один в экстарте другой в эксчейнже это мту классическая проблема вот дальше dbd всегда обмениваются парами то есть сначала мастер посылает dbd с крикой потом слэйв подтверждает ее ответные если вдруг вам уже нечего больше сказать то вы все равно отправляете dbd парами от этого ничего не изменяется если вы мастер и вы знаете что у чего Shouldnister вы отправляете dbd пустую иución dbd с указанием я тебе еще готов что-нибудь рассказать но в апт под отправляете это позволено что у вас уже все и вот когда у вас уже все отправляете m равны 0 что вы больше ничего не хотите сказать и когда оба роутера друг другу отправили

dbd acum последняя ДБДшка, у нас больше ничего нет. Дальше оба роутера переходят в фазу лоудинг. Если кто-то еще отправил ДБДшку с М1, то, соответственно, вы отправляете ДБДшку, получаете на нее ответ. ДБДшка, которую вы отправили, подтверждается ДБДшкой, которую вы получили. Если вы отправили ДБДшку номер 7, и вам на ДБДшку номер 7 пришла ответная ДБДшка номер 7, значит, она сама себя и подтверждает. В некоторых книжках, в некоторых курсах рассказывают, что ДБДшки подтверждаются LSoCnowledge. Это ложь и провокация. ДБДшка подтверждается самой ДБДшкой. Отправили ДБДшку с номером 7, получили ДБДшку с номером 7. Это значит, что вы ДБДшку с номером 7 подтвердили. Если вы мастер, вы отправляете ДБДшки, вам приходит ДБДшки с тем же номером. Если вы слэйв, вы отправили ДБДшку с указанием «у вас еще не все» или «у соседа еще не все», неважно, вы отправили ДБДшку с номером 8, пришла ДБДшка с номером 9. Значит, сосед вашу ДБДшку с номером 8 получил,

dbd не надо как дополнительно подтверждать dbd самая подтверждающаяся они всегда отправляются парами всегда сами себя подтверждают если вы мастер и у вас все закончилось вы все равно pros & продолжаете отправлять dbd пустые чтобы slave на вас выгрузил то чего в него есть если вы слое у вас все закончилось вы отправляете maist flagmore 0 но соответственно мастер вам продолжает выгружать свои dbd и вы их подтверждаете просто пустыми dbd и шками и говорите, у меня все, у меня все, у меня все. Но просто вы обязаны отправить ДБДшку в ответ на ДБДшку соседа. Даже если у вас больше ничего нет, вы все равно обязаны отправить пустую ДБДшку. После того, как оба роутера отправили ДБДшки с признаком, что это все, это значит, что оба роутера, как бы это сказать, закончили фазу экстарт, они готовы перейти в лоудинг. Так, если вы мастер, вы отправили ДБДшку с флагом М0,

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

Поэтому, да, схема не требует подтверждения последней ДБДшки. Сама последняя ДБДшка, она на самом деле является подтверждением на предыдущую. Поэтому, если вдруг она не дойдет до получателя, то отправитель той самой первой ДБДшки заставит вас переотправить ее заново. Дальше. В Exchange у нас обмениваются заголовками, обмениваются роутеры заголовками LSA, то есть после того, как мы передаем заголовок, там еще надо будет само мясо передать. Мясо, как выглядит, мы уже видели, но вот в ДБДшках мясо не передается, передаются только заголовки. И у каждой LSA есть одинаковый заголовок, не зависящий от ее типа. Указывается время в секундах, которое прошло с момента выпуска LSA, то есть роутер выпускает LSA, и дальше все роутеры в своей LSDB начисляют копеечку раз в секунду.

Роутер выпустил, начинает распространять по всей сети, роутеры передают от одного к другому, и вот каждый роутер, который будет отправлять сообщение, что я знаю какую-то LSA, выпущенную, может быть, не мной, а кем-то еще, он говорит, сколько времени прошло с момента выпуска той LSA. Когда роутер отправляет такую LSA к соседям, он говорит, у меня известно, что LSA имеет возраст вот такой. Ты, пожалуйста, начинай сразу подсчет возраста с вот этого числа. И дальше он передает эту LSA к соседу, и сосед начинает ввести возраст уже с действительно значения, которое похоже на правду. Вот, пример. У нас есть два роутера. Роутер 1, роутер 2. Они подружились. Роутер 1 выслал LSA свою роутеру 2. Прошло там, не знаю, 5 минут, 300 секунд. И здесь у нас образовался новый третий роутер. Вот LSA роутера 1 уйдет в сторону роутера 3 от роутера 2 с указанием, что LSH 300 секунд.

Что эта LSA была выпущена 5 минут назад. Дальше с опциями там все сложно. LSType здесь у нас понятно. 1, 2, 3, 4, 5, 7. LSID – идентификатор LSA. Advertising роутер – кто придумал? Checksumma – интернет checksum. Length – длина LSA. То есть мы указываем, что LSA содержит сколько-то мяса, но мы не указываем само это мясо. И у каждой LSA есть версия. Вот это вот LSEquenceNumber – это просто, ну, как версия, она и есть версия. То есть сначала роутер выпускает свою LSA и говорит, что это версия номер 1. Потом у него что-то произошло. Он говорит, что старая версия LSA с номером 1 неправильная. Теперь у нас актуальная версия 2. Он перевыпускает LSA с тем же LSA ID, с тем же Advertising роутер. Но, соответственно, у него будет больше номер на единичку. И, соответственно, у него будет уже новая как бы LSA, которая заменяет старую. LSA здесь немножко хитрый.

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

И у вас получится такое, что есть роутер, у которого есть два разных соседства, получены и получены две разные версии LSA с одинаковыми LSA, с одинаковыми Advertising Router, но придуманы, на самом деле, разными физическими роутерами, у которых ID-шники совпадают. Вот эту вот штуку необычайно тяжело траблшутить, потому что ID-шники у нас обязаны быть уникальными в пределах всей автономной системы. Если у нас где-то начинают совпадать ID-шники, то это вызывает неправильную сборку пазла. Но и этот момент надо будет каким-то образом траблшутить. Заходить отдельно на каждый роутер, проверять, а не совпадает ли ID-шник у него со всеми остальными ID-шниками в топологии, это просто тяжело. Для того, чтобы быстро определить, где у нас конкретно с какими ID-шниками будет проблема, есть как раз вот эта вот самая чек-сумма. В DBD-шках, которыми роутеры будут обмениваться, будут заголовки LSA, и мы сможем быстро понять, что LSA, которая правильная, у нее чек-сумма будет одна. И мы смотрим, соответственно, чек-сумму LSA в одном месте, чек-сумму LSA в другом месте.

Мы видим, что ID-шники у них одинаковые, все там, роутер ID одинаковый, LSA ID одинаковый, а чек-суммы разные. Значит, это LSA-ки, выпущенные разными роутерами, и они рассказывают про разные. Чек-суммы передаются в DBD-шках, и мы можем таким образом быстро определить, какая из LSA-ек будет правильная. А кроме того, когда у нас выпускается несколько разных версий одной и той же LSA-ки разными физическими роутерами, нам нужно все-таки каким-то образом будет из этих LSA-ек выбрать какую-то одну. Мы же не можем сказать, у нас все вообще, OSPF в принципе не срастается, выкидываем все-все-все и сжигаем всю топологию к ядрению феня. Нам нужно каким-то образом из этих двух LSA-ек будет выбрать одну. И вот как раз LSA-ксумм будет способом из двух равнозначных, в кавычках, неправильных LSA-ек сказать, что одна из них будет более неправильная, другая менее неправильная. Вот у кого будет чек-сумма больше, тот и будет более правильный. Так, после фазы exchange мы знаем, какие LSA-ки есть у соседа,

мы видим заголовки этих LSA-ек, но мы не видим мяса, мы не видим метрики, мы не видим адреса, мы не видим содержимое. И мы можем захотеть его получить. Обязательно, не обязательно мы любые LSA-ки, которые есть у соседа, будем получать. Мы можем сказать, что много из этих LSA-ек мы уже и так знали из какого-то другого источника. Но вот, соответственно, да, в некоторых случаях мы можем захотеть какие-то LSA-ки получить. Из фазы exchange мы переходим в фазу loading, переводим соседа в фазу loading. И в этой фазе мы говорим, у соседа есть LSA-ки, которые известны нам, что они существуют, потому что сосед про них заявил в эксченже. Но мы их сами не имеем. Мы отправляем linkstate request, мы принимаем LSA-update, в котором содержатся запрошенные нами LSA-ки. То есть мы в linkstate request отправляем, какие заголовки LSA-ку нам нужны. В linkstate update приходят LSA-ки уже с мясом.

И мы это дело подтверждаем. Linkstate acknowledge идет, опять же, с теми заголовками, которые мы просили. Там не просто мы говорим, мы подтверждаем получение пакета номер один. Мы говорим, мы подтверждаем получение linkstate update, в котором мы получили LSA-ки такие-то, такие-то, такие-то, такие-то. То есть там вы указываете заголовки. Если мы все, что хотели, все соседа запросили, сосед нам это все прислал, а мы отправили ему подтверждение, то мы переводим соседа в фазу full. И дальше бурно радуемся тому, что у нас все хорошо. Так. Дальше. LSA-ка, которую роутер придумывает. Он придумывает ее про себя, если это LSA-ка первого типа, либо про общую канальную среду, если это LSA-ка второго типа, AVDR, либо про какие-то сетки, которые известны в других регионах, если это LSA-ка третьего типа, AVR, либо про какие-то внешние сетки, если у вас LSA-ка пятерк.

Ну, то есть, да, вы придумываете периодически какие-то LSA-ки. Эти LSA-ки будут иметь возраст и будут иметь стартовый секвенс номер. Стартовый номер будет вот такой. Это число, которое минимальное знаковое IN32. То есть, это минус 2 миллиарда чего-то там с 295 миллионов с копейками. Почему решили знаковое число использовать в качестве стартового номера, я не знаю. Никакой причины мне для этого не видится. Но, тем не менее, там с минус 4 миллиардов с копейками нумерация идет. И дальше доходит до плюс 2 миллиардов с копейками. 2 миллиарда здесь 147 миллионов, чего-то там тысяч. Вот. С минус 2 миллиардов до плюс 2 миллиардов 147 миллионов, чего-то там тысяч. До достижения вот такого вот значения у вас LSA-ка может обновляться. Вы выпустили LSA-ку про себя, у вас произошло изменение, вы выпустили новую версию,

снова произошло изменение, вы снова выпустили новую версию, и у вас вот нумерация идет с 80001 до 7FFFFFFF. Визуально это будет выглядеть как то, что вы с 80001 доходите до FFFFFFF, а потом следующий у вас будет 00001. И дальше вот 7FFFFFFF это самое последнее значение, которое у вас может быть достигнуто. Когда у вас достигается 8000, это число фактически будет равно минус бесконечности или плюс бесконечности. Это будет означать, что у вас LSA-ка флашится в кавычках. Давайте попробую написать флаш, как смыть в туалет. LSA-ка распространяется с таким серийным номером, это означает, что эта LSA-ка больше не валидная.

То есть роутеры должны будут ее перевыпустить и уже перевыпустить с новым номером 80001. Если вы хотите отправить внезапно сообщение, что у вас какая-то LSA-ка была и теперь ее больше нет, то вы можете внепланово отправить сообщение, что вот новая версия LSA-ки, но у нее будет версия там не 8000000, условно 9, а вот как раз 7FFFFFFFF. Это значит, что LSA-ка раньше была правильная, а сейчас вот она неправильная, и все ее должны из топологии вытащить. Это один из способов отправить сообщение, что LSA-ка сдохла, и надо ее теперь больше не принимать во внимание. Второй вариант, как можно сделать так, чтобы LSA-ка у вас быстро ушла из топологии, это поиграть временем. Время, как вы помните, у нас в заголовке LSA-ки указывается LSA-age, и это время будет 16-битовое. То есть максимальное значение туда можно указать 65000 с копейками.

Но есть правило. Роутеры по умолчанию раз в 30 минут или раз в 1800 секунд перевыпускают LSA-ки. То есть сначала роутер выпустил LSA-ку 80001, потом через 30 минут он говорит, я выпускаю более новую версию 000002, потом еще через 30 минут 00003, если ничего не происходит, если что-то происходит, внепланово отправляются 80004 и так далее. Но, соответственно, да, раз в 30 минут это должно происходить. Если вдруг вы выпустили какую-то LSA-ку и не захотели ее через 30 минут продлевать, она у вас может жить-жить-жить-жить, если только вы ее не флашите ручками. И когда LSA-ка доходит до 3600, до одного часа, LSA-ка считается сдохшей, протухшей. То есть у нее возраст считается слишком большой. Так что каждая LSA-ка, которую вы выпускаете, если только там не будет специальных лайфхаков сделано, как можно это предотвратить.

Вот если вы просто обычную LSA-ку выпускаете, она у вас раз в 30 минут будет перевыпускаться. А если вы не перевыпускаете ее, то через еще 30 минут она у вас из топологии будет убрана. Сделано это специально для того, чтобы если был какой-то роутер, который анонсировал LSA-ку, а потом внезапно из топологии пропал, а этого никто не заметил, чтобы эти LSA-ки в базе не копились. Так, если у вас есть LSA-ка, которую вы выпустили сами, а дальше вы хотите сказать, что у вас произошло какое-то изменение, ну, например, там, не знаю, новый интерфейс поднялся, и вы хотите выпустить более новую версию, то вы создаете более новую версию LSA-ки у себя в базе. Дальше вы отправляете LSU-ку с новой LSA-кой в интерфейс, где у вас есть соседство, и затем вы ждете получения LSA-ки, в которой будут такие же заголовки. Это будет либо LSA-кноуэллэдж, ну, самый простой вариант,

вы отправили апдейт соседу, и вы говорите, этот апдейт должен быть подтвержден соседом, он присылает LSA-кноуэллэдж с такими же заголовками, которые мы ему отправили, с таким же sequence number, с таким же ID-шником, с таким же advertising row, с такой же чек-суммой, что главное. Вот. И, соответственно, если вы отправили сообщение LSU и получили LSA, то, значит, все хорошо. Но есть нюанс. Если у вас есть, например, три роутера в топологии в кайце, вот, и на одном случилось какое-то изменение, здесь вот появилась новая сетка, он отправляет LSU-шку в один интерфейс и в другой интерфейс. Оба роутера говорят, я получил изменение, отправляет LSA-к, один руутер и второй роутер. И, соответственно, один роутер другому говорит, я тебе отправляю LSU-шку, которая у меня только что вот возникла, я тебя готов про нее рассказать. И другой отправляет, у меня новый LSA-к, я тебя отправляю LSU-шку, я тебе готов мне рассказать про то, что у меня произошло.

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

Так же, как в EJRP, можно любое сообщение, которое Unicast-ом пойдет с таким же serienem, с таким же acknowledge number-ом, вот здесь любое сообщение, которое Unicast-ом придет на вас с таким же заголовками LSA-ек, вот оно будет считаться подтверждением того, что вы получили, того, что вам, да, что сосед получил ту информацию, которую вы им отправили. Если вы отправляете соседу информацию в LSU-шке, то дальше зависит от того, есть там DR или нет. В среде без DR мы отправляем сообщение Multicast-ом напрямую соседу, каждому. Мы отправляем один Multicast, и он доходит до всех-всех-всех. Это в среде с Point-to-Point, это в среде с Point-to-Multipoint-ом, там у нас Unicast-ом приходится отправлять все на адрес соседа. То есть мы отправляем сообщение, и эти сообщения доходят до всех. Если у нас DR есть, это либо Broadcast-овая, либо Non-Broadcast-овая среда, то все будет немножко сложнее.

У нас есть среда, в этой среде много роутеров. Один из них будет DR, другой из них будет BDR. Все остальные будут не DR, не BDR, они будут DR Other. У какого-то роутера возникают изменения, которые произошли в сети. Вот он говорит, у меня есть что-то новенькое, я готов рассказать про какое-то изменение. У меня, например, новый интерфейс поднялся или там что-то еще произошло. Он отправляет LSU, но не на адрес вообще все роутеры, потому что это значит, что надо, чтобы ему все эти роутеры подтвердили получение сообщения. А дальше они бы вынуждены были сказать, что мы знаем, что такое сообщение знает только один роутер, который нам это прислал. И поэтому они должны были бы снова и снова отправлять такие сообщения в эту среду и снова и снова ждать на них подтверждения. То есть у нас там роутер, давайте пронумеруемых, первый, второй, третий, четвертый, пятый и шестой. Шестой роутер отправил сообщение, я знаю про какую-то новую сетку, пятый говорит, я подтверждаю, четвёртый говорит, я подтверждаю, третий говорит, я подтверждаю, второй говорит, я подтверждаю, первый говорит, я подтверждаю.

Но они подтверждают Unica option, поэтому шестой роутер знает про то, что все роутеры уже в этой сети были, оповещены, но они первый, второй, третий, четвертый, пятый про это ничего не знают. Поэтому шестой роутер, который не DR и не BDR, отправляет LSUшку не на 224.005, он отправляет на 224.006. Это адрес, который называется все DR-ы. Это фактически либо DR, либо BDR. Вот он отправляет один пакет. DR и BDR принимают такой апдейт, складывают LSUшки новые себе в базу. BDR тихо молчит, ничего не отправляет в ответ. А DR говорит, я понял, я сейчас обратно в тот же канал, отправлю LSUшку, точно такую же, с точно таким же содержимым, но на адрес 224.005. И в этой ситуации получается, да, что все подтверждают DR-у, что они получили новое обновление.

Все, зная, что у нас есть DR, что все с DR-ом дружат, говорят, что если вдруг DR принимает какое-то сообщение и пересылает его всем остальным участникам, то не надо не DR-ом заботиться о том, что другие не DR-ы, возможно, не знают эту сетку. Если нам что-то рассказал DR, мы исходим из того, что DR рассказал про это уже всем сразу. Поэтому первый шаг в среде, где у нас есть DR-ы, отправляется мультикастовое сообщение DR-у, ну или юникастовое, если у нас нон-браткаст среда. Дальше DR говорит, я отправляю точно ту же самую LSUшку, но всем остальным. И все остальные юникастом подтверждают LS-acknowledge DR-у. BDR тоже получает на самом деле сообщение от DR-а и тоже подтверждает именно его. Поэтому все роутеры в среде будут знать, что действительно сетка у нас такая, как эта там новая образовалась или не сетка, LS-ack-а. И все роутеры в сети знают, что действительно LS-ack-а это распространилось по всем остальным соседям.

Причем, что интересно, если вдруг вы отправляете сообщение на LSU на адрес 224.006, и в этот момент DR дохнет, то BDR получает такое сообщение, у него в базе оно остается. И он, принимая решение, что он теперь будет DR-ом, говорит, окей, я подтверждаю тогда, что я буду DR-ом, я вот перехватываю власть и отправляет сообщение уже дальше, что что-то изменилось уже от его имени, от имени DR-а. Что я DR, я рассказываю всем, как надо жить. Поэтому в OSPF, да, по факту используются два мультикастовых адреса, все DR-ы, включая BDR, и все SPF роутеры 224.005, 224.006. Вот такая вот схема, она позволяет не городить огород с огромным количеством подтверждений, потому что иначе нам пришлось бы по схеме каждый на каждого реплицировать все изменения, это было бы долго и дорого. Она позволяет именно отправлять все сообщения только DR-у. DR подтверждает их ответная рассылка, я сейчас вам расскажу про новую сетку, это же вот это вот 224.005,

это включая и того, кто отправил оригинальный 224.006. Поэтому изначальный роутер R6 отправляет сообщение, я сейчас расскажу DR-у, он получает от DR-а сообщение, я сейчас расскажу вам всем, точно такое же, которое подтверждает предыдущую LSU-шку, и уже acknowledge идут, соответственно, от всех остальных, кто про эту сетку еще не знает. Вот, включая BDR, кстати. Вот такая вот схема. Схема сложная, но по умолчанию она используется в средах, где используется DR, ну то есть она просто используется там, где DR есть, а по умолчанию, например, в Ethernet происходит. То есть если вдруг вы захотите проверить, что действительно так оно и будет, вы можете взять в один VLAN, например, запихать несколько роутеров, ну вот, как минимум имеет смысл 4 использовать роутер, чтобы у вас было как минимум 2 DR-а, и на одном из них выпустить новую LSU-ку, посмотреть, какие пакеты по сети будут бегать. Вы увидите, что если вдруг изменение происходит на одном DR-а, он отправляет сообщение на адрес 224.006,

оно acknowledge-то DR-ом, отправкой встречной LSU-шки на адрес 224.005, и DR, и все остальные DR-азеры подтверждают такое сообщение Unicast-овыми LSA-ками DR. Так, далее. В каждой LSA-ке у нас есть чек-сумма, в каждой LSA-ке у нас, не в каждой LSA-ке, в каждом пакете у нас есть поле аутентификации, тип аутентификации, данные какие-то про то, что за аутентификация у нас используется, и дополнительные опциональные authentication data. Если мы используем authentication type 0, то, соответственно, мы говорим, что у нас вот этого authentication data отсутствует, там ничего нету, а само authentication 0, 0, 0, 0, 0, 0, 0. То есть, ну, пароль не используется, там чего интересного для нас нет. Если вдруг вы зачем-то захотите отправить authentication type 1,

что означает, что это плентекстовый пароль, то в authentication будет указываться первые 8 символов пароля. Поэтому, если вдруг вы вкладываете плентекстовый пароль, вы должны будете знать, да, что пароли, например, там, не знаю, password 1, 2 и password 1, 2, 3, вот с точки зрения, да, с точки зрения циски, это одинаковые пароли, равно как просто password без цифр, потому что там плентекстом вкладывается только первые 8 символов. Если вы говорите, что используется криптографическая аутентификация, то есть двоечку вкладываете, то в этом случае превращается заголовок в следующее. Authentication type 2. Дальше. Authentication разбивается на 4 подполя. Первое подполе зарезервировано. Дальше второе поле номер ключа. Вы уже намекаете, наверное, поняли намек, да, на ключевой цепочке.

Дальше. Размер поля с данными аутентификации. Это вот эта вот authentication data длина. И потом криптографический sequence number. Вы можете в определенных случаях, да, подписывать ваши сообщения и каждое из них отдельно нумеровать. Вот те сообщения, которые требуют цифровую подпись, фактически, да, вы будете говорить, что вот одно сообщение, которое мы отправляем, и другое сообщение, которое мы отправляем, это разные сообщения, даже если у них мясо одинаковое, у них должны быть разные цифровые подпись. И вы можете в каждое сообщение вкладывать разные номера, и тем самым у вас цифровая подпись тоже каждого сообщения будет разной. Если вдруг кто-то перехватит наш Hello-пакет, условно говоря, и дальше будет пытаться сделать вид, что наш роутер все еще живой, хотя на самом деле он и не живой будет, вот в этом случае он не сможет даже Hello-сообщение подменить, потому что он не сможет, не зная пароль, сгенерировать Hello. В HRP, если вы помните, у нас там не было ничего подобного,

у нас все сообщения, которые были одинаковые, получали одинаковую цифровую подпись. Нам нужно было для того, чтобы наши Hello-сообщения получали бы в HRP разную цифровую подпись, нам нужно было бы пароль сменить. А здесь получается, что хэш считается от содержимого пакета и вот от этой вот самой секвенс-намбера, который каждый раз разный. Поэтому даже Hello-сообщения, которые будут отправляться, они будут отправляться с разной цифровой подписью. Ну и потом уже сам хэш, который вот здесь вот в Authentication Data будет прижать. OSPFv2 позволяет использовать различные варианты цифровой подписи, то есть можно использовать MD5, можно использовать что-то еще. OSPFv3 тоже позволяет это делать, там тоже аналогичные системы с аутентификацией. И, соответственно, можно будет таким образом защищаться от множества разных атак. Но, опять же, предполагается, что злоумышленник у вас должен получить доступ к каналу связи между роутерами для того, чтобы это все работало. И, соответственно, с другой стороны соседей,

вот я все, где-то подождаю. И, что есть дваorithза подписью? Неожде guides мнеiti County Дохрегnity, о问 Bahia the lerin В segur