В этой статье какие то моменты в работе OSPF не будут описаны, которые как мне кажется не сложны для понимания. Что то же в свою очередь наоборот будет рассмотрено детально. Я попробую осветить те моменты, на которые мы даже не обращаем внимания в обычной жизни. Выбор тем был сформирован исключительно на мой вкус, которые как мне показалось или не очевидны на первый взгляд, или сложны в понимании. Рекомендуемые знания для более легкого понимания описанного - OSPF на уровне CCNA.
Ниже представлена следующая топология:
В топологии используются образы Cisco. Адресация в текущей топологии следующая:
Рассмотрим адресацию на примере стыка между R1 и R2.
- На интерфейсах между маршрутизаторами маска будет использоваться 24 битная, а в IP адресе первый октет всегда будет 10, второй октет будет соответствовать номеру меньшего из пары роутеров между которыми поднят линк (R1), третий октет соответствует большему номеру из пары роутеров (R2), и четвертый, последний октет, он будет соответствовать номеру самого маршрутизатора. Например, адресация на стыке между R1 и R2 получается следующая: у маршрутизатора R1 адрес будет 10.1.2.1/24, а у R2 10.1.2.2/24
- На интерфейсе в сторону Switch всегда будет адресация 10.0.0.X/24, где X - это соответствие с номером маршрутизатора. А случае с R2 это будет 10.0.0.2/24
- Все 4 октета адреса Loopback интерфейса всегда будут соответствовать номеру маршрутизатора. У R1 это будет 1.1.1.1/32, а у R2 адресом на Loopback будет 2.2.2.2/32
Что мы будем делать в рамках данной топологии:
- Сконфигурируем OSPF в backbone area (Ее еще называют area 0).
- Посмотрим содержимое LSDB.
- Посмотрим содержимое топологической информации, которая содержится LSA.
- Рассмотрим топологию с точки зрения графа.
Все интерфейсы уже сконфигурированы в соответствии с IP адресацией. Switch не сконфигурирован никак. Это обычный коммутатор, у которого все интерфейсы в состоянии UP.
И так, начнем с конфигурации маршрутизатора R1. Для начала нам потребуется создать сам процесс OSPF. Для этого дадим команду
router ospf 1
Давайте разберем чуть более детально, что делает команда выше.
- router - Говорит маршрутизатору о том, что мы собираемся создать процесс маршрутизации. Далее, за командой router следует выбор самого процесса
- ospf - Тут мы указываем маршрутизатору какой именно процесс мы будем создавать
- 1 - Ну и сам номер процесса. Номер можно выбрать в диапазоне 1-65535
Как только мы ввели команду "router ospf 1", мы автоматически проваливаемся в режим конфигурации OSPF, понять это можно по новому приглашению в CLI: "R1(config-router)#". Помимо этого на маршрутизаторе появился процесс OSPF, а значит и заработал протокол OSPF. Убедиться в этом мы можем с помощью команды "show ip protocols | section ospf" из режима Enable, которая показывает информацию о запущенных протоколах маршрутизации на устройстве. В нашем случае мы увидим вывод только касательно протокола OSPF, так как с помощью фильтрации мы указали, какая именно секция нас интересует.
*Многое из описания может быть не понятно на текущем этапе, но далее мы постепенно будем погружаться в смысл каждого из терминов/описания. Что то мы рассмотрим в этой статье, что то в следующей части.
- Первая строчка нам говорит о том, какой это протокол маршрутизации а так же его номер, номер процесса OSPF.
- Вторая и третья строчки показывают на наличие либо отсутствие каких либо фильтров настроенных на интерфейсах
- Четвертая строка показывает на Router ID маршрутизатора
- Пятая строка показывает на количество зон, в которых состоит этот маршрутизатор
- Шестая строка показывает максимальное количество одновременно активных путей до одной точки назначения, иными словами - ECMP (Equal-Cost Multi-Path)
- Седьмая строка показывает область поиска, заданной с помощью команды "network"
- Восьмая строка. Сейчас тут пусто, но мы таки разберем значения каждого столбца в этой строке. Gateway - тут указывается Router ID маршрутизатора от которого пришла топологическая информация (LSA). Distance - дистанция до этого маршрутизатора по маршрутам, полученных из OSPF. Last Update - когда последний раз была получена LSA от этого маршрутизатора. Стоит отметить, что эта информация получается только от устройств, относящихся к той же зоне что и само устройство.
- Девятая строка показывает административную дистанцию для маршрутов, которые были получены с помощью OSPF (По умолчанию 110)
Начнем пожалуй с Router ID.
- Router ID, или сокращенно RID, это 32 битное число которое записывается в том же формате что и IP адрес, и при этом является идентификатором маршрутизатора в домене OSPF.
С помощью RID маршрутизаторы могут идентифицируют друг друга в OSPF домене, что помогает не только определить от кого именно они получают топологическую информацию, но и построить граф. Правилом хорошего тона является назначение RID вручную, да и практическая польза с этого есть. Очень часто RID совпадает с адресом интерфейса Loopback. Задается RID вручную с помощью команды "router-id x.x.x.x" из режима конфигурирования OSPF процесса. Если этого не сделать, то маршрутизатор его сам себе назначит. По какой логике маршрутизатор это будет делать? А логика в Cisco IOS следующая: "Я посмотрю все интерфейсы что у меня есть, и если я обнаружу что у меня присутствует интерфейс у которого Network Type является Loopback, то я назначу RID в соответствии с адресом который назначен на Loopback интерфейс. Если таких интерфейсов не будет, то я выберу самый большой IP адрес из всех что у меня назначены на каких либо интерфейсах и сделаю RID таким же, как этот IP адрес". Что еще за Network Type такой? Прежде чем ответить на этот вопрос, давайте в LSDB поместим информацию об интерфейсе lo0. Сделать это можно с помощью нескольких способов:
- Первый способ, это с помощью команды "Network" из режима конфигурирования OSPF.
- Второй способ, это зайти в конфигурацию самого интерфейса и явно указать его причастие к OSPF.
С помощью команды "Network" мы задаем некий фильтр, или иными словами область поиска. Эта область поиска задается с помощью ввода адреса сети и обратной маски, а в конце указываем в какой зоне должна быть опубликована информация. Например, сделаем так:
network 1.1.1.1 0.0.0.0 area 0 Давайте разберемся, что произошло. У этой команды есть два два действия:
- После ввода команды "network" маршрутизатор начинает проверять все свои IP адреса на всех интерфейсах. Те интерфейсы, на которых присутствует IP адрес который попадает под заданную область поиска (В нашем случае область поиска это 1.1.1.1/32), информация о них (Интерфейсах) попадает в OSPF, а именно в Interface Data Structure.
- Те интерфейсы, на которых присутствует IP адрес который попадает под заданную область поиска, они начинают принимать и отправлять служебные сообщения Hello.
Например, мы можем дать команду "network 0.0.0.0 255.255.255.255 area 0" которая говорит следующее: "Информация обо всех интерфейсах, на которых IP адрес попадает в диапазон 0.0.0.0/0 должна попасть в Interface Data Structure". То есть, все интерфейсы на которых у нас есть какой либо IP адрес :) Давайте так и сделаем.
И так, давайте теперь убедимся, что информация обо всех интерфейсах на которых назначен какой либо IP адрес попала в Interface Data Structure. Сделать это можно с помощью команды "show ip ospf interface".
*В выводе содержится достаточно много информацию, часть которой станет понятна по мере прочтения этой статьи. Что то мы разберем в следующих статьях, а что то вообще разбирать не будем.
Прежде чем продолжить, немного поговорим про Interface Data Structure, о которой несколько раз говорили чуть выше. Interface Data Structure - это то место, где хранится информация об интерфейсах которые хоть как то связаны с OSPF. И уже после, из Interface Data Structure необходимая информация для описания канала попадает в LSDB.
Обратите внимание на тот самый Network Type. У интерфейса Loopback0 Network Type равен LOOPBACK, а у интерфейса GigabitEthernet0/0 Network Type равен BROADCAST. Откуда он берется? Почему у интерфейса gi0/0 Network Type BROADCAST, а у интерфейса Loopback0 Network Type LOOPBACK? Все идет от типа интерфейса. Это интерфейс типа Ethernet, что подразумевает под собой сеть со множественным доступом. То есть за этим интерфейсом возможно нахождение как одного, так и нескольких сетевых устройств. Ну а Network Type LOOPBACK берется так же с типа интерфейс. Интерфейс lo0, это интерфейс типа Loopback :)
Ранее мы говорили, что информацию об интерфейсах в OSPF можно дать двумя способами, это командой "network" или же явным способом указать, информация о каком интерфейсе будет попадать в LSDB. Давайте теперь разберем второй способ. Но перед этим скажем "no network 0.0.0.0 255.255.255.255 area 0" и убедимся, что информация обо всех интерфейсах из Interface Data Structure у нас пропала.
Отлично. Информации об этих интерфейсах действительно больше нет. Теперь зайдем в конфигурацию самого интерфейса lo0 и явно укажем, что он будет относиться к процессу OSPF с номером 1 к зоне 0. Делается это командой "ip ospf 1 area 0". Ну а после убедимся, что этот интерфейс теперь снова причастен к OSPF.
Аналогичным образом поступим с интерфейсом gi0/0. Стоит обратить внимание, что у команды "ip ospf 1 area 0" есть так же два действия:
- Информация об интерфейсе в конфигурации которого мы дали эту команду, она публикуется в Interface Data Structure.
- На этом интерфейсе начинают отправляться и приниматься Hello сообщения.
Мы разобрали два способа публикации информации об интерфейсах в OSPF, или если выражаться более правильно, то в Interface Data Structure. Какой способ выбрать - решать вам. Я же явно указал принадлежность интерфейсов gi0/0 и lo0 к OSPF, после чего с помощью команды "show ip protocols | section ospf" убедился, что информация о них появились в Interface Data Structure.
Кстати, обратите внимание на появление строки, которой ранее не было: Routing on Interfaces Configured Explicity (Area 0) - эта строка показывает информацию об интерфейсах, которые мы явно опубликовали в OSPF с помощью команды "ip ospf 1 area 0".
И так. Информацию об интерфейсах в Interface Data Structure мы занесли. Далее, из Interface Data Structure часть информации попадает в Link State Data Base (LSDB). А что же за база данных состояния каналов такая? Тут ничего сложно нет. В базе данных как всем известно хранятся данные. А в базе данных состояния каналов хранятся Link State Advertisement, или сокращенно LSA. Получается, что в LSDB содержится вся топологическая информация, каждый кусочек графа, который описывается с помощью LSA. Тут то мы незаметно и подходим к графу.
В основу OSPF заложено построение графа и обсчет этого графа с помощью алгоритма Дейкстры, после подсчета которого появятся соответствующие маршруты в таблице маршрутизации. Как построить этот граф и обсчитать его? Ведь мы маршрутизаторам не даем никакие листочки с нарисованной топологией. :) Значит нужно что то, что помогло бы каждому маршрутизатору в OSPF домене построить этот граф "В голове". И этим "Что то" является топологическая информация, которая содержится в служебных сообщениях под названием Link State Advertisement (LSA), или же объявление о состоянии канала, о чем упоминалось чуть ранее. В эти LSA записывается некая информация на основе которой маршрутизатор сможет построить граф и рассчитать стоимость до других вершин, в роли которых выступают маршрутизаторы. Но подождите. LSA - это объявление о состоянии каналов. Выходит, что граф строится на основе информации об этих каналах? Почти да, но с небольшим дополнением. Несмотря на название "Объявление о состоянии канала", в LSA помимо описания самих каналов содержится еще некая дополнительная информация. Смотрите. Эти описания каналов передает кто то, передает какая то вершина с точки зрения графа. И этот канал описывает путь до чего то, а именно до другой вершины. И с точки зрения сетей, такой вершиной является маршрутизатор. Вот и получается что в LSA содержится информация о вершине (Маршрутизаторе) и его ребрах (Интерфейсах). И такая LSA называется Router LSA. Router LSA генерируется каждым маршрутизатором в OSPF домене. По итогу мы выяснили, что каждый маршрутизатор порождает Router LSA, которая описывает самого себя (Маршрутизатор) и его интерфейсы (Каналы), информация о которых присутствует в LSDB. Хотелось бы отметить, что область распространения Router LSA - это вся зона к которой относится интерфейс. Тут есть одно важное и обязательно условие - одинаковая LSDB у всех устройств в пределах зоны, отсюда и требования к такой области распространения. Это нужно для корректного обсчета графа на основе информации, хранящийся в LSDB. К слову, сам алгоритм производит обсчет от некой вершины X, где в роли вершины X является тот, кто будет производить обсчет, то есть сам маршрутизатор. Иными словами, маршрутизатор всегда ставит себя корнем дерева при обсчете SPF.
Прежде чем мы пойдем дальше, давайте посмотрим на содержимое LSDB. Сделать это можно с помощью команды "show ip ospf database"
- Первая строка, вывод которой в виде заголовка. Там нам говорят следующее: "Ты смотришь LSDB процесса OSPF с номером 1 (Напоминаю, что мы его задавали в самом начале при объявлении процесса OSPF) роутера, чей Router ID равен 1.1.1.1
- Вторая строка говорит о том, что вывод ниже предназначен для LSA которая называется Router LSA и находится в области 0.
- Третья строчка. В ней есть несколько столбцов. Сейчас мы рассмотрим только часть. Понимание каждого столбца будет приходить по мере чтения этой статьи :)
3.1. Link ID - Этот столбец говорит о том, какую вершину (Маршрутизатор) описывает эта LSA. А идентификатором маршрутизатора в OSPF домене как мы помним является RID.
3.2. ADV Router - Тут мы видим RID маршрутизатора который эту LSA породил.
3.3. Age - Возраст. Время жизни LSA. У каждой LSA хранящийся в LSDB есть MaxAge. MaxAge - это 3600 секунд, по достижению которых LSA становится не валидной. Если топологическая информация содержащаяся в этой LSA не валидная, то значит что и граф уже не соответствует действительности. Поэтому при достижении возраста LSA равным MaxAge происходит перерасчет SPF уже без учета данных из этой LSA.
Содержимой LSDB смотреть мы смотрели. А как посмотреть содержимое уже самой LSA? Для просмотра детального содержимого Router LSA нужно дать команду "show ip ospf database router 1.1.1.1". Разберем чуть детальнее эту команду:
show ip ospf database - покажи мне содержимое LSDB
router - где тип LSA - это Router LSA
1.1.1.1 - которая описывает маршрутизатор 1.1.1.1
И того все вместе получается "show ip ospf database router 1.1.1.1"
Первые две строчки вывода мы пропустим, т.к. их описание уже было выше.
LS age - уже рассматриваемое в прошлом нами время жизни LSA, MaxAge которого равняется 3600 секунд. Но что бы информация никуда не пропадала по достижению MaxAge в уже устоявшейся топологии, есть некий LSRefreshTime, которое равняется 1800 секунд. Как только возраст LSA которую породил маршрутизатор достигает значения LSRefreshTime, он генерирует новую LSA, заносит ее в свою LSDB, и отправляет ее всем своим OSPF соседям. Таким образом MaxAge достигнут не будет, и соседи его не вычеркнут из своей топологии :)
Option: (No TOS-capability, DC) - маршрутизация на основе TOS. Достигалось это путем отдельного графа на каждое значение TOS. Сейчас это не используется. Более подробно почитать об этом можно в rfc1583. DC - это опция, позволяющая более эффективно использовать некоторые типы физических каналов с оплатой на основе времени/по байтовой оплате. Более подробно почитать об этом можно в rfc1793.
LS Type: Router Links - сам тип LSA. Router LSA, или по-другому ее называют LSA Type 1.
Link State ID: 1.1.1.1 - какую вершину, а раз мы говорим про сети, то какой маршрутизатор описывает эта LSA.
Advertising Router: 1.1.1.1 - какая вершина, а раз мы говорим про сети, то какой маршрутизатор эту LSA породил.
LS Seq Number: 80000003 - вот тут поговорим поподробнее. Seq Number, как не сложно догадаться, это порядковый номер LSA. Он увеличивается каждый раз, когда маршрутизатор генерирует новую LSA. Ну например. У LSA которая описывает маршрутизатор 1.1.1.1 Age достиг LSRefreshTime. Маршрутизатор, ответственный за эту LSA, а именно 1.1.1.1 (Он же ее и рекламирует), он генерирует новую LSA, все так же заносит ее в LSDB и отправляет своим OSPF соседям. Так как это новая LSA, ее Age сброшен до 0, а Seq Number стал +1. Давайте предположим, у нас уже рабочая топология, и вот по достижению LSRefreshTime маршрутизатор 1.1.1.1 сгенерировал новую LSA и отправил ее R2. Как R2 будет понимать, что с этой LSA ему делать, с учетом того что у него в LSDB уже есть LSA которая описывает маршрутизатор 1.1.1.1? Инсталлировать в LSDB, или может быть проигнорировать? Тут как раз поможет обсуждаемый нами Seq Number. Он увидит, что у только что пришедшей LSA Seq Number будет выше чем у той что сейчас инсталлирована в собственной LSDB. Это значит что это новая LSA, а значит более актуальная, поэтому устройство сделает несколько действий: Сравнит содержимое только полученной, новой LSA с LSA которая уже имеется в LSDB, после чего заинсталлирует к себе в LSDB, а так же перешлет эту LSA в свою очередь уже своим OSPF соседям. Зачем сравнивать содержимое только полученной LSA с уже имеющийся в LSDB старой LSA? Ну потому что если новая LSA содержит точно такую же топологическую информацию, то перерасчета SPF не будет за ненадобностью. Но достижение LSRefreshTime не единственная причина которая может послужить увеличению LS Seq Number. Но об этом поговорим позже.
Checksum: 0x57AE - контрольная сумма, подсчитывается она для всего LSA, за исключением поля LS Age. Следовательно, LS Age может меняться без последствий на результат подсчета контрольной суммы. Подсчет контрольной суммы нужен для понимания, была ли искажена LSA или нет. Высчитывается она в двух случаях:
- При получении LSA.
- При достижении CheckAge, значение которого равняется 5 минут.
У каждого маршрутизатора, локально, при достижении LS Age кратному CheckAge, происходит проверка контрольной суммы LSA. Казалось бы, какой смысл проверять уже хранящуюся LSA в LSDB. Полагаю, что это реализовано на случай неисправности ячейки в ОЗУ, в которой как раз таки и будут храниться биты относящиеся к LSA.
Length - длинна LSA в байтах.
Number of Links - количество интерфейсов опубликованных в OSPF.
И ниже, после "Number of Links" мы как раз таки и видим эти два интерфейса, которые описываются в Router LSA. Давайте рассмотрим и само описание этих интерфейсов.
Link connected to: a Stub Network - сюда мы вернемся чуточку позже, когда мы будем рассматривать OSPF с точки зрения графа.
(Link ID) Network/subnet number: 1.1.1.1 - Тут описывается адрес интерфейса (В случае с 32 битной маской) или сеть к которой относится интерфейс (В случае с маской отличной от 32 битной).
(Link Data) Network Mask: 255.255.255.255 - Описание сетевой маски о котором чуть упоминалось выше. Вместе с Link ID дает описание, к какой сети относится интерфейс.
Number of MTID metrics: 0 - MTID позволяет создать несколько топологий внутри одной области на основе поля TOS. Более подробно рассказать не получится, так как не сталкивался с этим.
И так, по итогу мы видим что Router LSA описывает сущность 1.1.1.1, а так же интерфейсы этой сущности и то к какому типу канала (a Stub Network) они подключены. Один интерфейс имеет адрес 1.1.1.1 с маской 32 бита, а второй интерфейс относится к сети 10.1.2.0 с маской 24 бита. Почему не указан конкретный адрес, а указана сеть к которой принадлежит интерфейс? Для этого обратимся к графу.
Что такой ребро в графе? Это некая линия если визуально, или же интерфейс который соединяет две вершины (Маршрутизатора). Давайте на секунду представим граф состоящий из трех вершин, который будет обсчитываться от R1:
Так вот, линия, или же интерфейс соединяющий R1 и R2 - это и есть ребро с точки зрения графа. Таким образом, ребром с точки зрения графа, и интерфейсом с точки зрения сети так же будут и соединения R2 и R3. Прошу обратить внимание, что если мы рассматриваем эту топологию именно с точки зрения графа, то на картинке "10. Граф из трех вершин" мы видим три вершины, которые соединены между собой ребрами, а не три маршрутизатора которые подключены интерфейсам gi0/0 :) Топология из роутеров в Eve-ng это лишь способ продемонстрировать строение графа и его составляющих. Что такое ребро, мы уже разобрались.
А что такое вершина? Чуть ниже на картинке "11. Картинка из wiki", там есть вершины обозначенные номерами. Поэтому вершина в графе - это некая сущность до которой можно добраться через соответствующее ребро. Вершины соединяются ребрами. А если смотреть на все с точки зрения сети, то вершиной является маршрутизатор.
*Картинка из wiki для более лучшего представления
Но давайте теперь отстранимся от математического графа и вернемся к нашей уже реальной топологии. В начале статьи мы рассматривали типы интерфейсов, одним из которых в OSPF значится как Network Type BROADCAST. Network Type это некая абстракция на уровне OSPF, а берется же эта абстракция от типа интерфейса, которые относится к OSPF. У нас интерфейсы типа Ethernet, который в свою очередь относится к сетям со множественным доступом. Это значит, что за одним интерфейсом может быть много устройств. Все бы ничего, только вот в графе, который обсчитывается по алгоритму Дейкстры, ребром могут быть соединены только две вершины. То есть ситуации, когда за одним ребром находится несколько вершин быть не может.
Теперь, основываясь на этой информации, становится понятно почему в Router LSA в описании интерфейса нет конкретного адреса "(Link ID) Network/subnet number: 1.1.1.1 - В этом случае описывает адрес интерфейса (В случае с 32 битной маской) или сеть к которой относится интерфейс (В случае с маской отличной от 32 битной)". В алгоритме Дейкстры не подразумевается что между вершинами будет более двух устройств, поэтому какой там именно у интерфейса адрес так же не важно. То есть, с точки зрения графа мы не встретимся с ситуацией когда за одним интерфейсом может быть несколько точек назначения.
А как же быть в ситуациях, когда маршрутизаторы состоящие в OSPF домене подключены к коммутатору, как например на нашей топологии? Давайте попробуем это представить с точки зрения графа, на который мы смотрим от лица R1:
И тут возникает большая проблема. Как описать ситуацию, когда как нам кажется за одним находится несколько подключенных вершин? В алгоритме Дейкстры такая ситуация и не подразумевалась, ибо он разрабатывался не под сети. Он не предназначен для таких ситуаций. И тут разработчики OSPF идут на ухищрение, создавая LSA, которая называется Network LSA, или же LSA Type 2. Эта LSA как раз таки способна описать такую ситуацию. Что бы продолжить изучение Network LSA, нам потребуется настроить OSPF на каждом из устройств, кроме коммутатора Switch. Он нужен просто для эмуляции множества вершин за одним ребром. Приводить сюда настройки каждого устройства я не буду. Описанных ранее в статье строк конфигурации вполне должно хватить для этого, ничего нового там не будет.
И так, настройку мы произвели. Давайте теперь посмотрим содержимое LSDB от например R1.
Помните про область распространения Router LSA? Так вот, область распространения Network LSA такая же как и у Router LSA. Так как все устройства находятся в области 0, то и получается что каждый знает о каждом, отсюда и такое количество Router LSA. Но теперь у нас появились и Network LSA. Как же эта LSA поможет нам описать ситуацию со множественным доступом? Да в принципе все просто, наверное :)
Network LSA порождается на каждый широковещательный домен. А Network Type: BROADCAST как раз таки и дает подсказку процессу OSPF о том, что этот интерфейс подключен к широковещательному домену, следовательно нужно сгенерировать Network LSA. Так как у нас все интерфейсы типа BROADCAST, то на каждый широковещательный домен появляется LSA Type 2. Давайте посчитаем, сколько же у нас широковещательных доменов.
3 широковещательных домена. А теперь посмотрите на количество Network LSA из вывода на картинки "12. show ip ospf database". Их тоже 3. На каждый широковещательный домен по Network LSA. Но где же описание других вершин? Смотрите, у нас в широковещательном домене под номером 2 находится 3 устройства, а Network LSA которая описывает широковещательный домен под номером 2, она одна. В ней Link ID = 10.0.0.6. То есть мы видим описание только одной вершины, вершины R6. Но, это только на первый взгляд. Тут то и вступает магия Network LSA, вместе с новым понятием как Designated Router.
Designated Router - это тот маршрутизатор, который строит отношения соседства со всеми OSPF устройствами в широковещательном домене. Помимо этого, DR порождает новую вершину - Transit Network. С точки зрения графа, все ребра, в том числе и ребро самого DR маршрутизатора, они подключаются к вершине этой транзитной сети. Таким образом эмулируется обычное p2p подключение между графами. То есть от Transit Network которую породил DR, эмулируется подключение ребрами к другим вершинам, а именно к R2, R3 и R5. И с точки зрения графа, ребро подключено не в какую то сущность со множественным доступом, а к вершине сети, в роли которой выступает Transit Network. Следовательно, раз DR породил новую вершину сети, то он же и выпускает Network LSA на широковещательный домен. А тот Link ID который указан в Network LSA, это и есть тот самый DR. Так же стоит отметить, что не смотря на название Designated Router, это свойство не маршрутизатора а интерфейса. Выборы DR происходят по Priority на интерфейсе. Если Priority одинаковы среди участников, то DR'ом станет тот, у кого больший RID. Так же кратко про BDR. Как мы видим из названия (Designated Backup Router), это резервный DR который устанавливает отношения соседства не только с DR'ом, но и со всеми маршрутизаторами в широковещательном домене. Network LSA он не генерирует до тех пор пока жив DR. Как только DR становится недоступен, то BDR берет на себя его роль. И так, вспоминая наш план адресации понимаем, что выпущена LSA Type 2 была вершиной R6.
Давайте посмотрим на это с точки зрения графа, как это все видит например R1:
И вот, нет никакого "К одному ребру подключено несколько вершин". А теперь взглянем на содержание Network LSA Designated Router'а в широковещательном домене №3 которая эмулирует обычное подключение между вершинами, тем самым как бы стирая на логическом уровне этот самый широковещательный домен. Поэтому дадим команду "show ip ospf database network 10.0.0.6"
Видим уже много знакомых нам полей. Но обратите внимание теперь на Link State ID. Там указан уже конкретный адрес а не просто сеть к которой относится интерфейс. Ведь в широковещательном домене у нас может быть множество устройств, поэтому тут уже надо указывать конкретный адрес, а не просто сеть которая сама в свою очередь является пунктом назначения. Указан адрес того самого DR который эмулирует обычное подключение вершин через ребра графа. А что мы видим ниже?
Attached Router: 6.6.6.6 Attached Router: 2.2.2.2 Attached Router: 3.3.3.3 Attached Router: 5.5.5.5
Это и есть ничто иное как описание подключенных вершин к Transit Network. То есть, тут говорится: За ребром (Интерфейсом) с адресом 10.0.0.6 можно найти вершины, RID которых 6.6.6.6 (Он сам), 2.2.2.2, 3.3.3.3 и 5.5.5.5. И глядя на картинку "15. Построение графа с точки зрения R1", мы эту эмуляцию и наблюдаем. И нет никакого широковещательного домена, который привел бы граф в негодность :)
Думаю, самое время вспомнить про момент, к которому мы обещали вернуться позже когда рассматривали содержимое Router LSA: "Link connected to: a Stub Network - сюда мы вернемся чуточку позже, когда мы будем рассматривать OSPF с точки зрения графа.". Давайте еще раз посмотрим на Router LSA, но уже маршрутизатора R6:
Обратите внимание на описание последнего интерфейса, а именно на:
Link connected to: a Transit Network
Ранее мы такого не видели в Router LSA. Транзитная сеть, это вершина графа, к которой подключены рёбрами вершины маршрутизаторов, и при этом вершины маршрутизаторов не имеют прямой связи друг с другом. А транзитной сетью сеть считается в случаях, если она находится на интерфейсе типа BROADCAST или NBMA, и за этим интерфейсом есть хотя бы 1 OSPF маршрутизатор. Почему называется транзитной? Потому что через эту сеть (Вершину) можно добраться до других вершин. А в свою очередь вершина транзитной сети это и есть ничто иное как DR интерфейс, который эмулирует подключение между вершинами, путем выставления себя как вершины. Да, вам не показалось, у сети тоже есть вершина. И вершина транзитной сети будет выглядеть примерно вот так:
Обратите внимание, что к вершине транзитной сети подключен и R6. Вспомните вывод на картинки "16. show ip ospf database network 10.0.0.6". В Network LSA было описано, что к ней подключена так же и вершина 6.6.6.6. Поэтому с точки зрения графа это самая обычная вершина, ничем не отличающаяся от вершины маршуртизатора.
А что с "Link connected to: a Stub network" которая присутствует к описанию того же LOOPBACK интерфейса? На самом деле тупиковая сеть может быть не только за LOOPBACK интерфейсом, но и за тем же интерфейсом типа BROADCAST/NBMA, за которыми нет никаких соседей. С точки зрения графа это будет выглядеть как вершина маршрутизатора, ребро которой соединяется с вершиной тупиковой сети. А тупиковая она потому что к ней подключена всего одна вершина, то есть она не соединяет через себя несколько вершин. Давайте попробуем это все визуализировать. Для этого а маршрутизаторе R1 на интерфейсе gi0/1 назначим адрес 110.110.110.1/24, и поместим этот интерфейс в OSPF процесс в зону 0, после чего еще раз взглянем на содержимое Router LSA маршрутизатора R1
Обратите внимание на описание к интерфейсу который относится к сети 110.110.110.0/24. И тот самый "Link connected to: a Stub Network". Так как же это все смотрится с точки зрения графа?
Вот и та самая тупиковая сеть, к которой подключена всего одна вершина и через которую нельзя добраться до другой вершины.
Хочу выразить огромную благодарность @zanswer, к которому я обращался за консультациями не однократно, а так же Гусеву Алексею за его бесценные курсы.