69579

OSPF (Часть II)

Практическая работа

Информатика, кибернетика и программирование

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

Русский

2014-10-07

6.73 MB

3 чел.

OSPF (Часть II)

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

При рассмотрении механизмов взаимодействия маршрутизаторов, изучены форматы кадров, соответствующие каждому типу взаимодействия, а именно:

  •  Hello
  •  Database Description
  •  Link State Request
  •  Link State Update
  •  Link State Acknowledgment
  •  Router-LSA
  •  Network-LSA
  •  Summary-LSA
  •  AS-external- LSA

Кроме этого, приведены примеры конфигурации протокола OSPF на маршрутизаторах под управлением операционной системы Windows Server. Далее рассмотрим практические примеры взаимодействий протокола OSPF в различных схемах подключений маршрутизаторов.

Пример схемы, состоящей из одной области OSPF.

После конфигурирования интерфейсов маршрутизаторов, участвующих в схеме (R1, R2, R3), рассмотрим консоль управления OSPF на примере R3.

Идентификатор маршрутизатора (Router ID) соответствует IP адресу одного из интерфейсов, участвующих в работе OSPF

По условию, количество областей – одна, что и подтверждается приведенной ниже закладкой конфигурации областей OSPF.

Оба интерфейса маршрутизатора принадлежат одной области с кодом 0.0.0.0 или Backbone – магистральной области.

Настройки остальных маршрутизаторов, участников схемы, аналогичны, и содержат IP адреса подключенных интерфейсов лежащих в одной -  магистральной области. Стоимость маршрута в сеть 13.0.0.0/8 в ручную увеличена до 40.

Рассмотрим взаимодействие маршрутизаторов в хронологическом порядке. Итак, маршрутизатор R3 подключен, и рассылает в общий сегмент сети (15.0.0.0) сообщения типа Hello, для обнаружения соседних маршрутизаторов.

Сообщение передается групповой рассылкой, в адресе получателя указывается 224.0.0.5, что соответствует маршрутизаторам OSPF. В заголовке пакета OSPF указывается:

OSPF version - Версия протокола – 2

Message Type - Тип сообщения – 1 , что соответствует сообщениям Hello

Packet Length - Длина пакета OSPF с учетом заголовка – 44 байта

Source OSPF Router - Идентификатор маршрутизатора-источника пакета – 15.0.0.3

Area ID - Идентификатор области-источника пакета – 0.0.0.0

А так же, контрольная сумма пакета, тип аутентификации 0х0001 что соответствует использованию открытого пароля и сам пароль 123456.

В пакете Hello содержится следующая информация:

Network Mask - Маска сети интерфейса-источника – 255.0.0.0

Hello Interval - Интервал передачи пакетов Hello – 10 (секунд)

Options - Опции – бит E (0х02) означает OSPF ExternalRoutingCapability и устанавливается всеми маршрутизаторами, связанными с магистралью, либо передающими в нетупиковые области. При этом, установка данного флага приводится только в информационных целях и не влияет на расчет таблицы маршрутизации.

Router Priority - Приоритет маршрутизатора – 1, указывает на возможность данного маршрутизатора быть основным DR (Designated Router) либо запасным (Backup) DR.

Router Dead Interval - Количество секунд, спустя которое, данный маршрутизатор можно считать неработоспособным – 40 (секунд).

Designated Router – идентификатор выделенного маршрутизатора для данной сети с точки зрения источника пакета  - 15.0.0.3 (т.е. маршрутизатор предлагает себя в качестве DR)

Backup Designated Router - идентификатор запасного выделенного маршрутизатора для данной сети с точки зрения источника пакета – 0.0.0.0 (т.е. это место вакантно, принимаются предложения)

Такие сообщения Hello маршрутизатор R3 рассылает, до тех пор, пока не получит аналогичное сообщение от соседнего маршрутизатора. Спустя некоторое время включается маршрутизатор R1, и отправляет мультикастом пакет Hello

Содержание пакета аналогично, за исключением адреса отправителя, и значения поля Designated Router. DR = 0.0.0.0 т.е. маршрутизатор R1 не знает ID маршрутизатора выполняющего роль DR, но и сам становится Designated Router в данный момент времени маршрутизатор R1 не собирается. Не известен так же и Backup DR. В данном случае, маршрутизатор R1 в конечно итоге предложил бы себя в качестве DR, если бы не поступило иных предложений, но так как в схеме уже существует DR, то максимум на что может претендовать R1, так это должность Backup DR, т.е. запасного выделенного маршрутизатора.

Базовые операции обработки пакетов Hello на стороне получателя включают проверку заголовка IP и заголовка OSPF. После этого значения полей Network Mask, HelloInterval и RouterDeadInterval в принятом пакете Hello сравниваются с параметрами принимающего интерфейса. При любом несовпадении обработка завершается, а пакета сбрасывается. Т.е., перечисленные поля описывают характеристики и конфигурацию подключенной сети. Однако это правило имеет одно исключение – в сетях point-to-point и виртуальных каналах, значение Network Mask принятого пакета Hello игнорируется. Установка бита E в поле Options пакета Hello должна соответствовать параметру ExternalRoutingCapability для этой области. Если анонсы AS-external-LSA не рассылаются в данную область (область является тупиковой) то бит E в пакетах Hello должен быть сброшен, в остальных случаях бит E=1. Несоответствие значений прерывает обработку пакета и пакет отбрасывается. Установка остальных опций Hello должна игнорироваться.

После этого проверяется совпадение адреса отправителя пакета Hello с адресами соседей принимающего интерфейса. Если принимающий интерфейс подключен к широковещательной, Point-to-MultiPoint или NBMA-сети, отправитель идентифицируется по IP-адресу отправителя в заголовке IP пакета Hello. Если принимающий интерфейс подключен к сети point-to-point или виртуальному каналу, отправитель идентифицируется значением Router ID в заголовке OSPF пакета Hello. Текущий список соседних интерфейсов содержится в структуре данных интерфейса. Если отправитель не найден в списке соседей (т. е., получен первый пакет в сессии) то в структуру данных вносятся дополнения. Для нового соседа состояние устанавливается в Down.

При получении пакета Hello от соседа в широковещательной, Point-to-MultiPoint или NBMA-сети, в базу данных заносится значение Neighbor ID, равное значению Router ID в заголовке OSPF принятого пакета. Для таких типов сетей поля структуры данных о соседе Router Priority, Designated Router и Backup Designated Router также устанавливаются равными значениям соответствующих полей пакета Hello. При получении пакета Hello из сети point-to-point (но не из виртуального канала) значение Neighbor IP устанавливается в соответствии с IP-адресом отправителя. Далее проверяется остальная часть пакета Hello и генерируются события для механизма состояний соседа и интерфейса. Данный механизмы состояний срабатывает немедленно или в соответствии с очередью. В приведенном ниже примере указано, что механизмы состояний соседа исполняется сразу же (in line) и несколько смен состояния могут быть инициированы одним пакетом Hello:

  •  Каждый принятый пакет Hello активизирует механизм состояний соседа событием HelloReceived.
  •  После этого проверяется список соседей в пакете Hello. Если принявший маршрутизатор присутствует в списке, механизму состояний передается событие 2-WayReceived. В противном случае используется событие 1-WayReceived и обработка пакета заканчивается.
  •  Далее, если было зафиксировано изменение поля Router Priority, планируется активизация механизма состояний интерфейса событием NeighborChange (Изменение информации о соседе).
  •  Если сосед декларирует себя как DR (в пакете Hello поле Designated Router = Neighbor IP), поле Backup DR в пакете имеет значение 0.0.0.0 и принимающий интерфейс находится в состоянии Waiting, планируется активизация механизма состояний интерфейса событием BackupSeen. В остальных случаях, если сосед декларирует себя как DR, но не был им до этого или не декларирует себя в этом качестве, хотя ранее играл роль DR, планируется активизация механизма состояний принимающего интерфейса событием NeighborChange.
  •  Если сосед декларирует себя как Backup DR (в пакете Hello поле Backup Designated Router = Neighbor IP) и приемный интерфейс находится в состоянии Waiting, планируется активизация механизма состояний интерфейса событием BackupSeen. В остальных случаях, когда сосед объявил себя Backup DR, не будучи таковым до этого, или снял с себя полномочия Backup DR, планируется активизация механизма состояний принимающего интерфейса событием NeighborChange. В сетях NBMA прием пакета Hello может также вызывать передачу ответного пакета Hello.

Таким образом, получив пакет Hello от R1, маршрутизатор R3 отправляет пакет Hello c указанием активного соседа. Т.е. R3 указывает в своем пакете, что им найден соседний маршрутизатор OSPF и указывает адрес этого маршрутизатора.

Active Neighbor – 15.0.0.1, это значение Router ID маршрутизатора, чьи пакеты Hello были получены, в течении интервала Router Dead Interval.

Далее R1, согласно с алгоритмом работы OSPF, отправляет следующий пакет OSPF типа Database Description в адрес R3.

Данный тип пакета соответствует номеру 2, и используется при инициализации отношений смежности между маршрутизаторами. Для пакетов DD значение поля Interface MTU устанавливается равным размеру максимальной дейтаграммы IP, которая может быть передана интерфейсом без фрагментации. Для пакетов DD, передаваемых через виртуальные соединения устанавливается Interface MTU=0.

Дополнительные возможности OSPF сообщаются соседу через поле Options пакета DD. Маршрутизатор должен поддерживать такой же набор дополнительных возможностей в процедурах Database Exchange и лавинной рассылки, как и его сосед. Флаг E- устанавливается, только если подключенная сеть не относится к тупиковой области. Неиспользуемые биты поля Options должны иметь нулевое значение. Передача пакетов DD зависит от состояния соседа. В состоянии ExStart (Начало работы) маршрутизатор передает только пустые пакеты DD с установленным и битами I, M и MS, пакеты повторяются с интервалом RxmtInterval. Приведенный выше пример пакета описывает состояние маршрутизатора ExStart, при этом значение байта Flags соответствует 00000111dec , т.е. биты I=1, M=1, MS=1. Значение MS=1 соответствует ведущему маршрутизатору, 0 –ведомому. I=1 означает первый по порядку пакет в сессии. М=1 говорит о  том, что следует ожидать еще пакеты типа DD в данной сессии.

В состоянии Exchange (обмен информацией), пакеты DD содержат информацию о состоянии каналов, содержащейся в базе данных маршрутизатора. Каждая запись LSA в базе данных области, при переходе соседа в состояние Exchange, указывается в списке Database Summary соседа. Каждый новый пакет DD копирует свой порядковый номер из структуры данных о соседе и далее содержит начальную часть списка Database Summary. Описанные элементы удаляются из списка после подтверждения приема содержащего их пакета. В состоянии Exchange момент передачи пакетов DD определяется ролью маршрутизатора (ведущий или ведомый):

  •  Master - пакеты DD передаются, если a) ведомый маршрутизатор подтвердил прием предыдущего пакета DD, указав его номер в отклике, или b) прошло RxmtInterval секунд без подтверждения приема предыдущего пакета (заново передается прежнийпакет).
  •  Slave - пакеты DD передаются только в ответ на получение пакета DD от ведущего маршрутизатора. Если получен новый пакет DD, в ответ передается новый отклик DD, в противном случае снова передается предыдущий пакет DD.

Аналогичный пакет отправляет R3 в адрес R1

После открытия сессии обмена пакетами  DD, маршрутизаторы переходят в состояние Exchange (Обмен информацией), при этом каждый последующий пакет DD содержит заголовок LSA (Link State Advertisiment) с соотвествующим типом объявлений маршрутной информации, рассылаемой маршрутизатором.

R1 отправляет R3 пакет DD содержащий Router-LSA

Обратите внимание, в данном пакете поле флаги не содержит отметок, т.е. маршрутизатор R1 является подчиненным (Slave) в текущем взаимодействии.

Заголовок LSA содержит следующую информацию:

- LS age – время в секундах с момента генерации LSA – 1 (секунда)

- Options – опции – 0х02 (ExternalRoutingCapability)

- LS type – тип объявления – 1 , соответствует Router-LSA (Объявление от маршрутизатора). Этот тип LSA описывают состояние и стоимость каналов (интерфейсов) маршрутизатора в данную область.

- Link State ID – идентификатор состояния соединения, в случае анонса типа Router-LSA, содержит IP адрес интерфейса-источника анонса

- Advertising Router – объявляющий маршрутизатор – содержит Router ID маршрутизатора источника LSA.

- LS Sequence number – порядковый номер анонса – 0х80000001, служит для обнаружения дублей анонсов

- LS Checksum – контрольная сумма LSA

- Length – длина

Аналогичный пакет отправляет R3 в адрес R1

Обратите внимание, в данном пакете поле флаги содержит отметку MS, т.е. маршрутизатор R3 является главным (Master) в текущем взаимодействии.

На каждом из маршрутизаторов входящий пакет DD ассоциируются с соседним маршрутизатором и своим интерфейсом принявшим данный пакет. Отказ или прием пакета для дальнейшей обработки зависит от состояния соседнего маршртизатора. Различают следующие состояния:

Down - пакет должен отбрасываться.

Attempt - пакет должен быть отброшен.

Init - механизм состояний соседа должен активизироваться событием 2-WayReceived, что ведет к немедленному переходу в состояние 2-Way или ExStart. Если новым состоянием является ExStart, обработка текущего пакета должна продолжаться для случая ExStart, описанного ниже.

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

ExStart - если принятый пакет соответствует одному из приведенных ниже условий, механизм состояний соседа должен активизироваться событием NegotiationDone (переход в транзитное состояние Exchange), поле Options должно быть сохранено в структуре данных о соседе (Neighbor Options), а пакет должен быть воспринят для последующей обработки.

- Биты I, M и MS установлены, остальные поля пакеты пусты и значение Router ID у соседа больше, чем у принявшего пакет маршрутизатора. Маршрутизатор в данном случае является ведомым, бит master/slave устанавливается в slave и в структуре данных о соседе устанавливается порядковый номер DD, заданный ведущим маршрутизатором.

- Биты I и MS не установлены, порядковый номер DD для пакета равен порядковому номеру DD в структуре данных о соседе (подтверждение) и значение Router ID у соседа меньше, чем у принявшего пакет маршрутизатора (данный маршрутизатор является ведущим).

Exchange - дубликаты пакетов DD отбрасываются ведущим маршрутизатором и заставляют ведомый заново передавать последний пакет DD. Для пакетов, не являющихся дубликатом выполняются следующие действия:

- Если состояние бита MS не соответствует состоянию master/slave для соединения, генерируется событие SeqNumberMismatch для соседа и обработка пакета прекращается.

- Если бит I установлен, для соседа генерируется событие Seq Number Mismatch и обработка пакета прекращается.

- Если поле Options показывает другой набор дополнительных возможностей OSPF по сравнению со значением полученным от соседа ранее (записан в поле Neighbor Options структуры данных о соседе), для соседа генерируется событие Seq Number Mismatch и обработка пакета прекращается.

- Пакеты DD должны обрабатываться в соответствии с их порядковыми номерами. Если маршрутизатор является ведущим, следующий порядковый номер принятого пакета должен совпадать с номером в структуре данных о соседе. Иначе для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается.

Loading или Full - в этих состояниях маршрутизатор передает или принимает всю последовательность пакетов DD. Дубликаты возможны только для принимаемых пакетов, Поле Options в пакетах должно соответствовать дополнительным возможностям OSPF, ранее объявленным соседним маршрутизатором (этот параметр хранится в поле опций структуры данных Neighbor). Прием любых других пакетов, включая пакеты с установленным битом I, должен сопровождаться генерацией события SeqNumberMismatch. Для маршрутизатора возможна рассинхронизация полных отношений смежности путем перехода назад в состояние ExStart. Это заставит смежный маршрутизатор обрабатывать сообщение SeqNumberMismatch и вернуться в состояние ExStart. Ведущий маршрутизатор должен отбрасывать дубликаты, а ведомый – повторять в ответ передачу последнего пакета DD.

Когда маршрутизатор принимает пакет DD со следующим порядковым номером, этот пакет воспринимается и обрабатывается. Для каждой перечисленной записи LSA проверяется корректность типа LS. Если тип LS неизвестен (т. е., не относится к типам 1 – 5) или запись является AS-external-LSA (тип 5), а сосед связан с тупиковой областью, для соседа генерируется событие SeqNumberMismatch и обработка пакета прекращается. В остальных случаях маршрутизатор ищет LSA в своей базе данных. Если такой записи нет или существует более старая версия то запись LSA помещается в список Link state request для ее последующего запроса (немедленно или спустя некоторое время) с помощью Link State Request.

Для пакетов DD со следующим порядковым номером, кроме перечисленных выше операций, маршрутизатор выполняет еще ряд действий в зависимости от своей роли – ведущий или ведомый:

Master - увеличивается порядковый номер DD в базе данных о соседе. Если маршрутизатор уже передал все пакеты DD и принятый пакет не содержит флага M, для соседа генерируется событие ExchangeDone . В остальных случаях ведомому маршрутизатору передается новый пакет DD.

Slave - порядковый номер DD в структуре данных о соседе устанавливается в соответствии с порядковым номером DD в принятом запросе. Ведомый маршрутизатор должен передать в ответ пакет DD. Если в принятом пакете не установлен бит M и переданный ведомым маршрутизатором пакет также не содержит флага M, для соседа генерируется событие ExchangeDone. Обратите внимание, ведомый маршрутизатор всегда генерирует это событие раньше ведущего.

Если поле Interface MTU в пакете DD показывает, что размер дейтаграммы IP превышает возможности маршрутизатора (требует фрагментации), пакет DD отбрасывается.

В соответствии с описанной выше логикой работы, главный (Master) маршрутизатор R3, после приема последнего пакета DD от R1, содержащего следующую информацию – [тип маршрутизатора Slave; тип LSRouter-LSA (1-корректно)], выполняет поиск в своей базе данных записи соответствующей данной LSA, т.е. Router-LSA от R1.  Однако такой записи пока еще быть не может, т.к. взаимодействие только началось, и поиск заканчивается неудачей. Следуя логике описанного выше алгоритма, маршрутизатор R3 подготавливает запрос Link state request, в который и цитируется запись LSA type 1, полученная от маршрутизатора R1. Данный запрос помещается в очередь и отправляется в адрес R1.

Аналогично поступает и маршрутизатор R1, не найдя соответствий в своей базе данных записи  Router-LSA с идентификатором 15.0.0.3, маршрутизатор генерирует запрос LSR в  адрес R3.

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

Каждый запрошенный анонс LSA сопровождается указанием типа, а также значениями Link State ID и Advertising Router. Эти параметры уникально описывают LSA, но не конкретный экземпляр анонса.

При состояниии соседа – Exchange, список запросов состояний каналов содержит те LSA, которые нужно получить от соседнего маршрутизатора. Для запроса LSA маршрутизатор сначала отправляет соседу список запросов, помещенный в пакет LSR. Когда соседний маршрутизатор отвечает на эти запросы пакетами Link State Update, соответствующие элементы удаляются из списка запросов и передается следующий пакет LSR. Этот процесс продолжается, пока список запросов не будет исчерпан. Записи из списка LSA, которые уже были запрошены, но еще не получены, помещаются в пакет LSR для повторной передачи по истечении интервала RxmtInterval. В любой момент времени может сохраняться по крайней мере один необработанный пакет LSR. Когда список запросов исчерпан и соседний маршрутизатор находится в состоянии Loading (передан и принят полный набор пакетов DD от соседа) для него генерируется событие Loading Done.

Таким образом, для маршрутизатора-получателя LSR, принятые пакеты содержат списки LSA, которые требует соседний маршрутизатор. Пакеты LSR должны восприниматься, если сосед находится так же в состояниях Exchange, Loading или Full. Для всех остальных состояний соседа пакеты LSR должны игнорироваться. Каждая запись LSA, указанная в пакете LSR, должна отыскиваться в базе данных маршрутизатора и копироваться в пакет Link State Update (LSU) для передачи соседу. Если LSA не удается найти в базе данных, это говорит о наличии ошибки в процессе Database Exchange и ведет к генерации события BadLSReq.

В соответствии с приведенным выше алгоритмом обработки пакетов LSR, маршрутизатор R3 отправляет в адрес R1 пакет типа Link State Update.

Проанализируем данный пакет, используя значения основных полей заголовка OSPF и тела пакета Update.

Message type – 4, что соответствует Link State Update

Number of LSA – 1, количество LSA в данном пакете Link State Update

LS age – 104, количество секунд в течении которых существует данная LSA

Flags – 0x02, или 00000010bin , что в соответствии с форматом LSA означает флаг E (External), т.е. флаг для граничных маршрутизаторов.

Number of Links – 2, число каналов маршрутизатора, описываемых в LSA (должно совпадать в числом интерфейсов маршрутизатора в область). Перечисленные ниже поля используются для описания каждого канала (т. е., интерфейса) маршрутизатора. Каждый канал имеет определенный тип (поле Type) – канал в транзитную сеть, к другому маршрутизатору или в тупиковую сеть. Значения всех остальных полей, описывающих канал маршрутизатора, зависят от типа канала. Например, каждый канал имеет связанное с ним 32-битовое поле Link Data. Для каналов в тупиковые сети это поле содержит маску адреса, а для остальных типов – IP-адрес интерфейса маршрутизатора

Таким образом, следующее четырехбайтовое поле идентифицируется в зависимости от значения поля Type (Link Type) в соответствии с таблицей:

Значение поля Link Type

Информация, указываемая в Link ID

1-Соединение Point-to-Point с маршр-ром

RouterID соседнего маршрутизатора

2-Соединение с транзитной сетью

IP-адрес маршрутизатора DR

3-Соединение с тупиковой сетью

IP-адрес сети/подсети

4-Виртуальный канал

RouterID соседнего маршрутизатора

Значит, в рассматриваемом пакете поле LinkID для обоих каналов содержит IP-адрес сети/подсети источника анонса т.к. поле Link Type = 3, т.е. маршрутизатор R3 подключен в тупиковые сети двумя интерфейсами. Таким образом, в объявлении размещена информация о подключенных сетях 12.0.0.0 и 15.0.0.0.

Поле LinkData, в этом случае содержит маску объявляемых сетей – 255.0.0.0.

Поле TOS metric используется для обратной совместимости с предыдущими версиями OSPF, значения поля TOS metric, указывают на критерий выбора маршрута для отправки пакетов IP протокола и соответствуют приведенной ниже таблице (сокращенный вариант):

Код TOS metric (DEC)

Значение критерия

0

Нормальное обслуживание

2

Минимальная стоимость

4

Максимальная надежность

8

Максимальная пропускная способность

16

Минимальная задержка

Тогда, в анализируемом пакете, оба маршрута сообщаются, как маршруты с минимальной стоимостью, такая характеристика соответствует топологии подключения маршрутов – обе сети являются подключенными.

Аналогичный пакет посылает R1 в адрес R3 (фрагмент)

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

Т.е. маршрутизатор R3 переходит к передаче пакетов LSU типа Network-LSA. Network-LSA относятся к типу 2 и генерируются для каждой широковещательной и NBMA-сети в области, поддерживающей более 1 маршрутизатора. Поле Link State ID содержит IP-адрес интерфейса DR. Дистанция от сети до всех подключенных маршрутизаторов равна 0, поэтому поле метрики не включается в Network-LSA.

       Network-LSA от маршрутизатор R3 имеет вид:

Заголовок Network-LSA содержит следующую информацию:

Advertising RouterIP-адрес маршрутизатора-источника

Netmask – маска соответствующая адресу маршрутизатора-источника для вычисления сети маршрутизатора-источника.

Attached router – подключенные маршрутизаторы со значениями RouterID соответственно 15.0.0.1 и 15.0.0.3. Т.е. R3 сообщает, что к нему в область 0.0.0.0 напрямую или в один широковещательный сегмент подключены два маршрутизатора с указанными идентификаторами.

Цитата Router-LSA, отправленная маршрутизатором R3 накануне – указывается для тог, что бы остальные маршрутизаторы принявшие данное объявление записали его в соответствующую часть базы данных, относящуюся к маршрутизатору R3 и его LinkStateID 15.0.0.3.

Следующим отправленным пакетом, будет подтверждение маршрутизатором R3, информации о приеме Router-LSA от маршрутизатора R1.

Аналогично подтверждает принятую информацию и маршрутизатор R1.

Далее маршрутизатор R1, отправляет мультикастом сообщение LSU содержащее часть базы данных, которая соответствует области 0.0.0.0.  В приведенном примере,  LSU содержит информацию о выделенном маршрутизаторе области, и сетях, известных маршрутизатору R1, как подключенные. Такая информация необходима для построения графа связей, описывающего область OSPF.

Маршрутизатор R3 подтверждает полученные данные

Таким образом, взаимодействие между R1 и R3 состоит из следующих этапов:

  1.  Обмен пакетами Hello
  2.  После взаимного обнаружения, отправка пакетов DD, содержащих Router-LSA с указанием Router-ID отправителя.
  3.  Формирование и отправка запроса LS Reuest на основании полученных пакетов Router-LSA. На этой стадии происходит формирование вершин графа связей области.
  4.  Формирование и отправка пакетов LS Update, содержащих информацию о подключенных сетях и назначенном маршрутизаторе. На этой стадии, сформированные ранее,  вершины графа соединяются отрезками, соответствующими содержанию LS Update.
  5.  Формирование и отправка подтверждений LS Acknowledge в ответ на принятые пакеты LS Update.

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

Вначале работы R2 посылает пакеты Hello, для обнаружения соседей, таким образом, информация о существовании R2 достигает маршрутизаторов R1 и R3, а маршрутизатор R2, принимая Hello посылаемые R1 и R3 узнает о соседях.

На основании принятых пакетов Hello, маршрутизатор R2 посылает пустой пакет DD в адрес R1, означающий приглашение к обмену информацией.

В ответ маршрутизатор R1 посылает такой же пакет DD

Далее маршрутизатор R2, отправляет пакет DD, содержащий Router-LSA, с реквизитами R2

Маршрутизатор R1, отправляет макет DD, содержащий LSA записи, известные маршрутизатору R1 на данный момент времени

Записи Router-LSA содержат информацию о подключенных маршрутизаторах области, запись Newtork-LSA указывает на выделенный маршрутизатор.

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

Результатом анализа является взаимный обмен запросами по соответствующим частям базы данных маршрутов.

R1 -> R2

R2 -> R1

В ответ на полученные запросы маршрутизаторы отправляют пакеты LS Update, содержащие запрашиваемую информацию о подключенных интерфейсах и сетях, реализуемых через эти интерфейсы.

R2 -> R1

R1 -> R2 (Начало)

R1 -> R2 (продолжение)

Таким образом, R2 сообщил о том, что он подключен в сеть 15.0.0.0/8, а R1 сообщил о сетях 10.0.0.0/8 и 11.0.0.0/8 достижимых через шлюз 15.0.0.1 и сети 12.0.0.0/8 – достижимой через 1шлюз 15.0.0.3. Также в LS Update отправленным маршрутизатором R1 указываются известные адреса подключенных маршрутизаторов и выделенный маршрутизатор DR = 15.0.0.3.

Далее R1, мультикастом отправляет информацию, подтверждающую его работоспособность в отношении подключенных сетей 11.0.0.0/8 и 10.0.0.0/8, а так же подтверждающую существование DR=15.0.0.3. Это действие осуществляется пакетом Network-LSA.

Далее R2 уточняет у R1 содержимое базы данных соответствующее записи Router-LSARouterID 15.0.0.3.

 

R1 отвечает R2

Таким образом, R1 дублирует информацию о маршруте в сеть 12.0.0.0/8, полученную ранее из предыдущего пакета LS Update. При этом и одна и другая маршрутная запись в сеть 12.0.0.0/8 являются одинаковыми по возрасту – 101 секунда, т.е. какую именно из предоставленных записей использовать в таблице маршрутизации в данном случае не принципиально.

Следующий пакет, интересен, прежде всего, адресом получателя. Адрес групповой рассылки 224.0.0.6 означает передачу «всем выделенным маршрутизаторам» (all Designated Routers ).

Т.е. R2 отправляет LSA объявления всем - выделенному и запасному маршрутизаторам области для подтверждения тог, что ему (R2), известны подключенные маршрутизаторы области R3 и R1, и что R3 известен, так же, как выделенный маршрутизатор.

Далее, R2 принимает Hello, отправленное R3, содержащее список активных соседей, среди которых и R2.

Этот пакет служит сигналом, для начала взаимодействия R2-R3, которое происходит по стандартному сценарию, за исключением того, что R3 является выделенным маршрутизатором и именно ему R2 объявит маршрут в подключенную тупиковую сеть 13.0.0.0/8.

R2 -> R3 DD (пустой)

R3 -> R2 DD (пустой)

R2 -> R3 отправляет DD c заголовками известных LSA

R3 -> R2 отправляет DD c заголовками известных LSA

После обмена пакетами маршрутизатор R3  посылает запрос к R2 относительно записи Router-LSALinkStateID 13.0.0.1. Так как такой записи у маршрутизатора R3 в базе не существует.

В ответ, маршрутизатор R2 сообщает

Содержимое данного пакета, учитывается R3 при построении графа связей относительно маршрутизатора R1 RouterID 13.0.0.1. Т.е. получается, что R1 с идентификатором 13.0.0.1 подключен напрямую через сеть 15.0.0.0/8. Эта запись сразу же объявляется всем маршрутизаторам области

Следующим этапом взаимодействия является генерация маршрутизатором R2 пакета LSU в адрес всех DR области,  содержащего информацию о подключенных сетях – 13.0.0.0/8 (тупиковая) и 15.0.0.0 (транзитная) с маской, соответствующей маске сети, в которую подключен интерфейс 15.0.0.2, отправляющий это сообщение.

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

Пример пакета R3:

Маршрутизатор R1 подтверждает принятую информацию о сети 13.0.0.0/8 достижимую через шлюз 15.0.0.2 использующий идентификатор 13.0.0.1.

Далее маршрутизатор R3 объявляет известные ему активные соседние маршрутизаторы области, а маршрутизаторы R1 и R2 подтверждают эту информацию.

В подтверждениях от маршрутизаторов цитируется Network-LSA от R3, а именно поля LS Sequence number и LS Checksum.

На этом взаимодействие маршрутизаторов прекращается до истечения таймаута действующих объявлений.

В результате рассмотренных взаимодействий таблица маршрутизации на R3  имеет вид.

Информация о связях R3:

Информация о соседях:

Рассмотрим взаимодействие внутри данной системы маршрутизаторов при изменении топологической картины. Пусть на маршрутизаторе R2 в результате аварии стала недоступна сеть 13.0.0.0.

Тогда взаимодействие происходит следующим образом – в начале, маршрутизатор R2 посылает LS Update в адрес DR, в котором корректирует информацию последнего объявления по поводу подключенных интерфейсов, указывая только интерфейс 15.0.0.2 и не указывая сеть 13.0.0.0/8.

В свою очередь DR т.е. R3 рассылает эту информацию остальным маршрутизаторам области:

R1 подтверждает полученные изменения

В результате таблица маршрутизации R3 имеет вид

Аналогична ситуация и на R1.

При возобновлении доступа в сеть 13.0.0.0 на маршрутизаторе R2 взаимодействия имеют вид:

R2 сообщает DR обновленную запись LSU, содержащую сеть 13.0.0.0/8

R3 сообщает об обновлении всем маршрутизаторам области

R1 подтверждает получение новой информации

В результате таблица маршрутизации R3 принимает исходный вид

Возвращается в исходное состояние и таблица на маршрутизаторе R1.

Далее рассмотрим взаимодействие маршрутизаторов OSPF при подключении в разные области, объединенные магистралью backbone, с подключением во внешние сети. Схема подключения остается прежняя, однако интерфейсы тупиковых сетей лежат в разных областях.

Рассмотрим конфигурацию маршрутизаторов на примере R1:

Маршрутизатор указывается как граничный

Аналогично, конфигурируются и остальные маршрутизаторы, на маршрутизаторе R4 дополнительно создается статический маршрут по умолчанию.

Рассмотрим взаимодействия между маршрутизаторами, и сравним с предыдущее схемой, состоящей из одной области.

Первым включается маршрутизатор R4 и начинает рассылку пакетов Hello. Следующим включается маршрутизатор R1, и после взаимного обнаружения, маршрутизаторы обмениваются пустыми пакетами DD.

После чего R1 начинает процесс обмена анонсами, и сообщает Router-LSA с указанием своего RouterID:

В свою очередь R4 сообщает свои LSA с указанием AS-External-LSA, указывающих на наличие внешних маршрутов.

Маршрутизатор R4  проверяет свою базу данных и не находит соответствия записи Router-LSA-LinkStateID 15.0.0.1. В результате маршрутизатору 15.0.0.01 отправляется запрос вида

В ответ маршрутизатор R1 сообщает о своем подключении в сеть 15.0.0.0/8. Данная информация используется для завершения построения графа связей на участке R4-R1.

Маршрутизатор R1 так же проверяет свою базу данных на наличие записей AS-External-LSA-LinkStateID 0.0.0.0; AS-External-LSA-LinkStateID 192.168.12.0;      Router-LSA-LinkStateID 15.0.0.4, и так же не находит соответствия. При этом формируется запрос к маршрутизатору R4:

Маршрутизатор R4, формирует ответ в виде записей  AS-External-LSA. Анонсы AS-external-LSA описывают маршрут в заданном направлении. Для таких LSA поле LinkState ID содержит IP-номер сети (при необходимости в него могут также включаться некоторые биты адреса хоста, это позволяет маршрутизатору разделять LSA для сетей с одинаковым номерам, но разными масками – как в случае использования систем, содержащих суперсети и вырожденные сети). Анонсы AS-external-LSA также используются для описания маршрутов по умолчанию (эти маршруты применяются при отсутствии явного пути к адресату). В таких случаях поле Link State ID всегда содержит значение DefaultDestination (0.0.0.0), а поле Network Mask имеет значение 0.0.0.0.

Поле Network Mask описывает адресную маску для анонсируемого получателя.

Поле E описывает тип внешней метрики. Если E=1, это значит, что в анонсе указывается  внешняя метрика типа 2, которая заведомо больше метрики любого из внутренних путей. Если E=0, это значит, что в анонсе указывается  внешняя метрике типа 1, использующей такие же единицы, что и внутренняя метрика link state.

Поле metric описывает стоимость маршрута. Интерпретация этого поля зависит индикации типа внешней метрики (бит E).

Поле Forwarding address указывает адрес, по которому будут пересылаться пакеты данных для анонсируемого направления. Если Forwarding address = 0.0.0.0, то пакеты будут пересылаться на маршрутизатор-источник LSA (т. е., данному граничному маршрутизатору AS).

Поле External Route Tag содержит 32-битовое поле, относящееся к внешним маршрутам. Протокол OSPF сам по себе не использует это поле, оно может применяться при обмене информацией между граничными маршрутизаторами AS. Для обратной совместимости с предыдущими версиями OSPF может включаться информация, связанная с TOS.

Ответ R4:

Таким образом, ответ содержит информацию о том, что R4 реализует маршрут во внешнюю сеть 192.16.8.12.0 255.255.255.0 и маршрут по умолчанию 0.0.0.0. Кроме этого R4, сообщает о подключении в сеть 15.0.0.0/8 и эта информация используется R1 для формирования графа связей на участке R1-R4.

Дальнейшее взаимодействие заключается в рассылке взаимных подтверждений получения новой информации.

Следующий анонс, содержит информацию о сети 10.0.0.0/8 и формируется маршрутизатором R1. Так как сеть 10.0.0.0/8 принадлежит к другой области (1.0.0.0), то маршрутизатор R1 является граничным, значит объявление в сеть 15.0.0.0 лежащую в области 0.0.0.0 будет совершено в виде сообщения Summary-LSA.

Анонсы Summary-LSA типа 3 используются для рассылки в сеть, тогда поле Link State ID содержит IP-номер сети (как отмечалось ранее,  Link State ID может включать также биты адреса хоста). Но если анонс адресуется граничному маршрутизатору AS - используется summary-LSA типа 4 и поле Link State ID содержит RouterID граничного маршрутизатора AS.

Для тупиковых областей summary-LSA типа 3 могут также использоваться для описания принятых по умолчанию маршрутов между областями. Такие маршруты используются внутри тупиковых областей взамен лавинной рассылки полного набора внешних маршрутов. При описании используемого по умолчанию маршрута поле Link State ID в summary-LSA всегда содержит значение DefaultDestination (0.0.0.0), а Network Mask = 0.0.0.0.

Объявление R1:

Далее, следует подтверждение от R4 и очередной LSU от R1, в котором явно указывается, что должность DR в данной системе закреплена за R4 (DR=15.0.0.4), а сеть 15.0.0.0 переходит в разряд транзитной.

Объявление сети 11.0.0.0/8 маршрутизатор R1 осуществляет так же, используя Summary-LSA:

На этом взаимодействия R1-R4 заканчиваются до истечения таймаутов существующих LSA. Маршрутизатор R1 назначается запасным выделенным маршрутизатором (backup DR).

Далее, в сеть включается R2 (15.0.0.2), и начинает рассылку пакетов Hello, одновременно с этим принимая аналогичные пакеты соседних маршрутизаторов. Взаимодействия с соседями, как и в предыдущей схеме, начинается по возрастанию значений RouterID. В процессе обмена заголовками записей баз данных, маршрутизатор R1 отправляет пакет DD, содержащий известные ему, на данный момент LSA:

(продолжение)

Маршрутизатор R2 анализирует записи своей базы данных, и не найдя соответствий полученным LSA, посылает запрос в адрес R1.

 

(продолжение)

В ответ, маршрутизатор R1 отправляет соответствующие части базы данных.

(продолжение)

(окончание)

Маршрутизатор R2 понимает, что 15.0.0.4 является граничным маршрутизатором AS, и для обнаружения кратчайшего пути, отдельно запрашивает данные по Router-LSA-LinkStateID 15.0.0.4.

Ответ R1:

Далее маршрутизатор R2 объявляет всем выделенным маршрутизаторам известные ему маршруты:

(окончание)

Кроме этого, маршрутизатор R2 отправляет Summary-LSA с информацией о сети 13.0.0.0/8

На этом взаимодействия R2-R1 заканчиваются до истечения таймаутов существующих LSA. Следующее взаимодействие происходит между R2 и R4. Процесс обмена маршрутной информацией происходит аналогично рассмотренному выше.

В результате маршрутизатор R4 объявляет о трех подключенных маршрутизаторах области:

После включения всех маршрутизаторов участников схемы, таблица маршрутизации имеет вид:

Для R1

Для R2

Для R3

Для R4

Информация о соседях на каждом из маршрутизаторов имеет вид:

Для R1

Для R2

Для R3

Для R4

Взаимодействия маршрутизаторов при отказе маршрутов, происходит аналогично первой рассмотренной схеме. Пусть на маршрутизаторе R4 отказал интерфейс, реализующий маршрут в сеть 192.168.12.0/24 и маршрут по умолчанию. Тогда маршрутизатор R4, вне очереди корректирует LSA относительно этих маршрутов, используя LS Update.

(продолжение)

Обратите внимание, недоступные более маршруты отмечаются полем LSAge=3600 секунд, что указывает на максимальный возраст LSA, после превышения которого, информация, указанная в LSA, считается недействительной.

После восстановления работоспособности интерфейса, маршрутизатор R4 рассылает LS Update, со значением LSAge=1 секунде.

Далее, рассмотрим взаимодействия маршрутизаторов при изменении метрики маршрута. Пусть на маршрутизаторе R1 в ручную увеличили метрику для сети 10.0.0.0/8 до значения 40 единиц, тогда маршрутизатор так же отправляет пакет LS Update в адрес выделенного маршрутизатора, содержащий соответствующую информацию:

После чего R4, отправляет полученные данные остальным маршрутизаторам области

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


 

А также другие работы, которые могут Вас заинтересовать

1979. Правовое регулирование коммерческой концессии в Российской Федерации 1.15 MB
  Коммерческая концессия: теоретический и исторический анализ. Правовое регулирование коммерческой концессии: становление и развитие. Договор коммерческой концессии: проблемы и противоречия законодательного регулирования.
1980. УПРАВЛЕНИЕ ИНВЕСТИЦИОННЫМ ПРОЦЕССОМ В РЕГИОНАЛЬНЫХ СИСТЕМАХ, ОРИЕНТИРОВАННЫХ НА ЭКОНОМИЧЕСКИЙ РОСТ 1.15 MB
  Место категории инвестиционный процесс в экономической науке. Сравнительный анализ экономического аспекта инвестиционной привлекательности региона. Обоснование использования коэффициентов расширения для управления инвестиционным процессом в региональных системах, ориентированных на экономический рост. Методические подходы к использованию коэффициентов расширения для прогнозной оценки роста региональной экономической системы.
1981. ПЕДАГОГИЧЕСКИЕ УСЛОВИЯ ФОРМИРОВАНИЯ КОММУНИКАТНОЙ КУЛЬТУРЫ СТУДЕНТОВ В ПРОЦЕССЕ ПРОФЕССИОНАЛЬНОЙ ПОДГОТОВКИ В ВУЗЕ 1.15 MB
  Коммуникативная культура будущего специалиста и совокупность педагогических условий ее развития. Коммуникативная культура преподавателя и ее влияние на профессиональную подготовку студентов вуза. Педагогические условия формирования коммуникативной культуры студентов в учебном процессе вуза.
1982. КОРРЕКТИРОВКА ФОРМИРОВАНИЯ ИНФОРМАЦИОННОЙ КУЛЬТУРЫ ПРИ ПРОФЕССИОНАЛЬНОЙ ПОДГОТОВКЕ ЭКОНОМИСТОВ В ВУЗАХ 1.15 MB
  Теоретические основы формирования информационной культуры при подготовке специалистов на экономических факультетах в вузах. Практическая реализация корректировки процесса формирования информационной культуры при подготовке специалистов на экономических факультетах в вузах. Особенности проведения педагогического эксперимента по корректировке формирования информационной культуры экономистов специальности 060400 Финансы и кредит
1983. ЕКОНОМІКА ПРИРОДОКОРИСТУВАННЯ 1.15 MB
  Поняття, види і особливості природокористування. Навколишнє природне середовище. Поняття і класифікація природних ресурсів, сутність і функції статистики навколишнього середовища.
1984. Уголовно-правовая характеристика нарушения правил обращения экологически опасных веществ и отходов 1.14 MB
  Правовое регулирование общественных отношений в сфере охраны окружающей среды. Юридическая природа уголовной ответственности за нарушение правил обращения экологически опасных веществ и отходов. Проблемы совершенствования правоприменительной практики и квалификация нарушения правил обращения экологически опасных веществ и отходов.
1985. Управление культурными процессами на кавказских минеральных водах в XIX начале XX веках 1.14 MB
  СТАНОВЛЕНИЕ РЕГИОНАЛЬНОЙ КУЛЬТУРНОЙ ПОЛИТИКИ НА КАВКАЗСКИХ МИНЕРАЛЬНЫХ ВОДАХ В ПЕРВОЙ ПОЛОВИНЕ XIX ВЕКА. ФОРМИРОВАНИЕ ОСНОВНЫХ НАПРАВЛЕНИЙ КУЛЬТУРНОЙ ПОЛИТИКИ НА КАВКАЗСКИХ МИНЕРАЛЬНЫХ ВОДАХ В ПЕРВОЙ ПОЛОВИНЕ XIX ВЕКА. РОЛЬ ОБЩЕСТВЕННЫХ ОРГАНИЗАЦИЙ КАК НОВЫХ СУБЪЕКТОВ КУЛЬТУРНОЙ ПОЛИТИКИ.
1986. Разработка биотехнологии вакцины чумной живой сухой со сниженным количеством человеко-доз в производственной упаковке (ампуле) 1.14 MB
  Современное состояние и перспективы совершенствования эффективности чумных вакцин. Пути совершенствования биологических показателей вакцины чумной живой на этапах сведения, разлива и лиофилизации бактериальной суспензии. Смыв бактериальной массы с поверхности агара с последующим приготовлением необходимой концентрации микробных клеток, разлив, лиофилизация вакцины. Изучение реактогенности различных образцов вакцины чумной живой сухой.
1987. Политический терроризм: детерминация и формы проявления 1.13 MB
  Политический терроризм: категориальный анализ. Политический терроризм и другие виды политического насилия: грани соотношения. Политический терроризм как форма этнического экстремизма. Основные направления преодоления политического терроризма.