Протоколы маршрутизации RIP и OSPF

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

В сетях с возможностью широковещательной рассылки (broadcast networks) Hello_пакеты рассылаются по мультикастинговому адресу 224.0.0.5 («Всем ОSPF_маршрутизаторам»). В других сетях все возможные адреса соседей должны быть введены администратором.

Значения полей:

· Network Mask (4 октета) - маска IP_сети, в которой находится интерфейс маршрутизатора, отправившего сообщение.

· Hello Interval (2 октета) - период посылки Hello_сообщений, в секундах.

· Options (1 октет) - определено значение нескольких бит:

		DC	EA	N/P	MC	E	T

o Бит Т установлен, поддерживается маршрутизация по типу сервиса (этот бит исключен из последней версии стандарта OSPF, но может поддерживаться для совместимости с предыдущими версиями).

o Бит Е установлен, маршрутизатор может принимать и объявлять внешние маршруты через данный интерфейс; сброшен, данный интерфейс маршрутизатора принадлежит тупиковой области.

o Бит MC установлен, маршрутизатор поддерживает маршрутизацию мультикастинговых дейтаграмм (RFC 1584).

o Бит N/P установлен, данный интерфейс маршрутизатора принадлежит не совсем тупиковой области (NSSA).

o Бит EA установлен, маршрутизатор может получать и ретранслировать объявления о «внешних атрибутах» (к настоящему моменту описание опции не разработано).

o Бит DC установлен, маршрутизатор поддерживает работу с соединениями, устанавливаемыми по требованию (demand circuits, RFC 1793) - это, например, означает, что записи о связях, устанавливаемых по требованию, не устаревают.

o Поле «Options» используется для согласования возможностей маршрутизаторов-соседей (маршрутизатор может прервать соседские отношения, если какие-то опции соседа его не устраивают) и для определения того, какую информацию о состоянии связей не нужно посылать маршрутизатору-соседу, потому что он все равно не сможет ее обработать.

· Priority (1 октет) - приоритет маршрутизатора; устанавливается администратором, используется при выборах выделенного маршрутизатора; маршрутизатор с нулевым приоритетом никогда не будет избран.

· Dead Interval (4 октета) - время в секундах, по истечении которого маршрутизатор-сосед, не посылающий сообщения Hello, считается отключенным.

· Designated Router (DR) (4 октета) - идентификатор выделенного маршрутизатора с точки зрения маршрутизатора, посылающего сообщение (0, если выделенный маршрутизатор еще не выбран).

· Backup Designated Router (BDR) (4 октета) - идентификтор запасного выделенного маршрутизатора с точки зрения маршрутизатора, посылающего сообщение (0, если запасной выделенный маршрутизатор еще не выбран).

· Neighbor,…, Neighbor - список идентификаторов соседей, от которых получены Hello_сообщения за последние Dead Interval секунд; число полей «Neighbor» определяется из общей длины сообщения, указанной в OSPF_заголовке. Длина одного поля - 4 октета.

После того, как пара маршрутизаторов начинает обмениваться Hello_сообщениями с каким-то соседом, этот процесс проходит через несколько стадий:

· DOWN - сосед не обнаружен или отключился;

· INIT - послано Hello_сообщение или получено от маршрутизатора, еще не зачисленного в список соседей;

· 2_WAY (двусторонняя связь) - получено Hello_сообщение, в котором данный маршрутизатор-получатель перечислен в списке соседей, а отправитель этого сообщения также зачислен в список соседей данного маршрутизатора;

· WAIT - ожидание в течение Dead Interval секунд для обнаружения всех соседей; в это время маршрутизатор передает Hello_сообщения, но не участвует в выборах выделенного маршрутизатора и в синхронизировании баз данных;

· EXSTART - установление ролей главный / подчиненный и инициализация структур данных для обмена описаниями баз данных (протокол обмена);

· EXCHANGE - обмен описаниями баз данных (протокол обмена);

· LOADING - синхронизация баз данных, пересылка сообщений-запросов о состояниях связей и ответов на них (протокол обмена);

· FULL - базы данных синхронизированы.

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

Каждый маршрутизатор может объявить себя либо выделенным, либо запасным, поместив свой идентификатор в соответствующее поле своих Hello_сообщений. Иначе он может поместить туда адреса других маршрутизаторов, если он считает их занимающими соответствующие роли. Если маршрутизатор не определился с выбором DR и (или) BDR (например, после включения), он заполняет соответствующие поля нулями.

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

Итак, после получения очередного Hello_сообщения маршрутизатор приступает к выбору DR и BDR. Он помнит мнения своих соседей по поводу того, кто является DR и BDR, которые он узнал из получаемых Hello_сообщений, а также свой собственный предыдущий выбор.

Сначала выбирается BDR, на эту должность назначается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве BDR, при этом маршрутизаторы, объявившие себя в качестве DR, не рассматриваются. Если никто не объявил себя в качестве BDR, выбирается маршрутизатор с высшим приоритетом из тех, кто не объявил себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с большим идентификатором.

На должность DR выбирается маршрутизатор с наивысшим приоритетом из всех, объявивших себя в качестве DR. В случае равных приоритетов выбирается маршрутизатор с большим идентификатором.

Если никто не предложил себя в качестве DR, в поле «Designated Router» заносится идентификатор BDR.

Если маршрутизатор только что выбрал себя на роль DR или BDR или только что потерял статус DR или BDR, шаги 1-3 повторяются. Термин «только что» означает «в результате выполнения непосредственно предшествующих шагов 1-3, а не предыдущих итераций алгоритма».

После выбора DR и BDR маршрутизатор сообщает их идентификаторы в своих Hello_сообщениях. Если в результате процедуры выбора DR или BDR изменились по сравнению с предыдущим выбором данного маршрутизатора, он устанавливает необходимые отношения смежности, если они еще не были установлены, и разрывает ненужные больше отношения смежности, если таковые имеются.

Когда маршрутизатор подключается к сети, сначала он достигает состояния 2_WAY со всеми своими соседями, а потом, прежде чем приступать к выборам, ожидает время WAIT. В течение этого времени он передает Hello_сообщения с обнуленными полями DR и BDR. После истечения периода WAIT вновь подключившийся маршрутизатор может предлагать себя на роль BDR, производить выборы и формировать отношения смежности.

Протокол обмена

После установления отношений смежности для каждой пары смежных маршрутизаторов происходит синхронизация их баз данных. Эта же операция происходит при восстановлении ранее разорванного соединения, поскольку в образовавшихся после аварии двух изолированных подсистемах базы данных развивались независимо друг от друга. Синхронизация баз данных происходит с помощью протокола обмена (Exchange protocol).

Сначала маршрутизаторы обмениваются только описаниями своих баз данных (Database Description), содержащими идентификаторы записей и номера их версий, это позволяет избежать пересылки всего содержимого базы данных, если требуется синхронизировать только несколько записей.

Во время этого обмена каждый маршрутизатор формирует список записей, содержимое которых он должен запросить (то есть эти записи в его базе данных устарели либо отсутствуют), и соответственно отправляет пакеты запросов о состоянии связей (Link State Request). В ответ он получает содержимое последних версий нужных ему записей в пакетах типа «Обновление состояния связей (Link State Update)».

После синхронизации баз данных производится построение маршрутов.

Сообщение «Описание базы данных (Database Description)»

Значения полей:

· Options (1 октет) - то же, что и в сообщениях Hello.

· IMMS (3 бита) - последние 3 бита октета, следующего за полем «Options»: I - Initialize, бит 5; M - More, бит 6, MS - Master/Slave, бит 7. Использование этих бит будет описано ниже. Остальная часть октета, где находятся эти биты, обнулена.

· DD Sequence number (DDSN) (4 октета) - порядковый номер данного сообщения.

· LSA Header (20 октетов) - описание (набор идентификаторов) записи из базы данных состояния связей, представляющее собой заголовок «Объявления о состоянии связей». В сообщении может присутствовать несколько описаний (полей «LSA Header»), следующих друг за другом; их число определяется из общей длины сообщения, указанной в OSPF заголовке.

Обмен сообщениями «Описание базы данных» происходит при работе протокола обмена (Exchange protocol) между двумя смежными маршрутизаторами. Обмен начинается с выяснения, кто из двух маршрутизаторов будет играть главную роль, а кто подчиненную.

Маршрутизатор, желающий начать обмен на правах главного, отправляет пустое сообщение с установленными битами IMMS и произвольным, но не использованным в обозримом прошлом номером DDSN (предлагается использовать время суток). Второй маршрутизатор подтверждает, что согласен играть подчиненную роль: он отправляет обратно также пустое сообщение с тем же DDSN, c установленными битами I и M и сброшенным битом MS.

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

После того, как роли распределены, начинается обмен описаниями базы данных. Главный отправляет подчиненному сообщения с описаниями своей базы данных; номера DDSN увеличиваются с каждым сообщением, бит I сброшен, бит МS установлен, бит M установлен во всех сообщениях, кроме последнего.

Подчиненный отправляет подтверждения на каждое полученное от главного сообщения. Эти подтверждения представляют собой сообщения того же типа, содержащие описание базы данных подчиненного маршрутизатора. Номер DDSN равен номеру подтверждаемого сообщения, биты I и MS сброшены, бит М установлен во всех сообщениях, кроме последнего.

При неполучении подтверждения от подчиненного в течение некоторого тайм-аута главный посылает сообщение повторно. Если подчиненный получает сообщение с уже встречавшимся номером DDSN, он должен повторить передачу соответствующего подтверждения. Это касается также и фазы инициализации (распределения ролей).

Если один из маршрутизаторов уже передал все данные, он продолжает передавать пустые сообщения со сброшенным битом М, пока другая сторона также не закончит передачу всех данных и не передаст сообщение (или подтверждение) со сброшенным битом М.

На этом процедура обмена описаниями базы данных заканчивается.

Протокол затопления (flooding)

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

Подпротокол OSPF, выполняющий эту задачу, называется протоколом затопления (Flooding protocol). При работе этого протокола пересылаются сообщения типа «Обновление состояния связей (Link State Update)», получение которых подтверждается сообщениями типа «Link State Acknowledgment».

Каждая запись о состоянии связей имеет свой номер (номер версии), который также хранится в базе данных. Каждая новая версия записи имеет больший номер. При рассылке сообщений об обновлении записи в базе данных номер записи также включается в сообщение для предотвращения попадания в базу данных устаревших версий.

Маршрутизатор, ответственный за запись об изменившейся связи, рассылает сообщение «Обновление состояния связи» по всем интерфейсам. Однако новые версии состояния одной и той же связи должны появляться не чаще, чем оговорено определенной константой.

Далее на всех маршрутизаторах OSPF_системы действует следующий алгоритм.

1. Получить сообщение. Найти соответствующую запись в базе данных.

2. Если запись не найдена, добавить ее в базу данных, передать сообщение по всем интерфейсам.

3. Если номер записи в базе данных меньше номера пришедшего сообщения, заменить запись в базе данных, передать сообщение по всем интерфейсам.

4. Если номер записи в базе данных больше номера пришедшего сообщения и эта запись не была недавно разослана, разослать содержимое записи из базы данных через тот интерфейс, откуда пришло сообщение. Понятие «недавно» определяется значением константы.

5. В случае равных номеров сообщение игнорировать.

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

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

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

Чтобы записи в базе данных не устаревали, маршрутизаторы, ответственные за них, должны через каждые 30 минут затапливать систему сообщениями об обновлении записей, даже если состояние связей не изменилось. Содержимое записей в этих сообщениях неизменно, но номер версии больше, а возраст равен нулю.

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

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

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

Сообщение «Запрос состояния связи (Link State Request)»



Сообщение «Запрос состояния связи» отправляется при работе протокола обмена после того, как был произведен обмен описаниями баз данных.

Сообщение содержит один или несколько идентификаторов записей, которые маршрутизатор хочет получить от своего соседа. Каждый идентификатор записи состоит из полей «Link State Type», «Link State ID» и «Advertising Router»; значения этих полей будут рассмотрены при обсуждении заголовков объявлений о состоянии связей (LSA). Число идентификаторов (то есть число запросов) в одном сообщении определяется из общей длины сообщения, указанной в OSPF_заголовке.

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

Сообщение «Обновление состояния связей (Link State Update)»

Сообщение «Обновление состояния связей» собственно и содержит информацию из базы данных состояния связей. Это сообщение отправляется в ответ на запрос (тип 3) при работе протокола обмена, а также при работе протокола затопления для распространения информации об изменении состояния связей. В последнем случае его получение подтверждается сообщениями типа 5 «Link State Acknowledgment», в случае отсутствия подтверждения посылка повторяется.

Сообщение типа 4 состоит из одного или нескольких объявлений о состоянии связей (Link State Advertisement, LSA), следующих друг за другом. Существует несколько типов LSA. Каждое LSA состоит из заголовка и тела.

Число объявлений LSA в сообщении определяется первым 32_битным словом, следующим за OSPF заголовком. Длина каждого LSA определяется соответствующим полем в заголовке LSA. Если все LSA, которые требуется отправить, не помещаются в одно сообщение, они могут быть распределены по нескольким сообщениям.

Дейтаграмма с OSPF сообщением типа 4, несущим 3 LSA, имеет следующую общую структуру:

Сообщение «Подтверждение приема сообщения о состоянии связей
(Link State Acknowledgment)»



Сообщения типа 5 отправляются в подтверждение получения сообщений типа 4 при работе протокола затопления. Сообщение содержит одно или несколько подтверждений, каждое подтверждение состоит из заголовка LSA, получение которого подтверждается.

Маршрутизатор может не посылать подтверждение на каждое сообщение типа 4, а послать одно сообщение типа 5 с подтверждениями на получение LSA, присланных в нескольких сообщениях типа 4, но в любом случае задержка с посылкой подтверждений не должна быть велика.

Число подтверждений в одном сообщении типа 5 определяется из общей длины сообщения, указанной в OSPF_заголовке.

Типы Объявлений о состоянии связей (LSA)

Тип 1. Router Links Advertisement - маршрутизатор объявляет о своих связях с соседними маршрутизаторами, транзитными и тупиковыми сетями; распространяется каждым маршрутизатором внутри области, к которой принадлежат эти связи.

Тип 2. Network Links Advertisement - содержит список маршрутизаторов, подключенных к сети множественного доступа; распространяется выделенным маршрутизатором внутри области, к которой принадлежит данная сеть. Фактически описывает связи, направленные в графе системы от вершины типа «транзитная сеть» к маршрутизаторам этой сети.

Тип 3. Summary Link Advertisement - описывает расстояние от данного областного пограничного маршрутизатора (ABR) до IP_сети, находящейся за пределами данной области, но принадлежащей данной OSPF_системе; распространяется этим ABR внутри области.

Тип 4. AS Boundary Router Summary Link Advertisement - описывает расстояние от данного ABR до данного пограничного маршрутизатора системы (ASBR); распространяется этим ABR внутри области.

Тип 5. AS External Link Advertisement - описывает расстояние до сети, находящейся за пределами OSPF_системы; распространяется ASBR и ретранслируется во все области, кроме тупиковых, их пограничными маршрутизаторами.

Тип 7. AS External Link Advertisement (NSSA) - то же, что тип 5, но распространяется внутри не совсем тупиковых областей (в них распространение LSA типа 5 запрещено); на границе NSSA и магистрали преобразуется в LSA типа 5 для дальнейшего распространения в системе. Формат идентичен формату LSA типа 5 за исключением номера типа.

Заголовок LSA

Все объявления о состоянии связей (LSA) состоят из заголовка и тела и пересылаются в сообщениях OSPF типа 4, а заголовки отдельно также пересылаются в сообщениях типа 2 и 5. Заголовок LSA имеет одинаковый формат для всех типов LSA.

Значения полей:

· LS Age (2 октета) - возраст связи (связей), содержащихся в данном LSA.

· Options (1 октет) - содержимое октета аналогично такому же октету в сообщении Hello.

· LS Type (1 октет) - тип LSA.

· Link State ID (4 октета) - идентификатор связи (связей), объявляемых в данном LSA, интерпретация этого поля зависит от типа LSA:

Тип LSA	Link State ID
1	то же, что и «Advertising Router»
2	IP_адрес интерфейса выделенного маршрутизатора, подключенного к данной сети множественного доступа
3	IP_адрес сети, находящейся за пределами области
4	идентификатор ASBR
5	IP_адрес сети, находящейся за пределами системы

· Advertising Router (4 октета) - идентификатор маршрутизатора, ответственного за объявление и поддержку связи (связей), содержащихся в данном LSA.

· Link State sequence number (4 октета) - порядковый номер (версия) состояния связи (связей), содержащихся в данном LSA.

· LS Checksum (2 октета) - контрольная сумма, вычисляется таким же методом, что и контрольная сумма IP_заголовка; защищает как заголовок, так и тело LSA.

· length (2 октета) - длина LSA в октетах, включая 20 октетов заголовка LSA.

Тело LSA типа 1

Значения полей:

· VEB (3 бита) - первый октет обнулен за исключением трех старших бит V (бит 5), E (бит 6) и B (бит 7). Установленные значения этих бит говорят о том, что маршрутизатор, объявивший данное LSA, является:

o бит B - пограничным маршрутизатором области (ABR);

o бит Е - пограничным маршрутизатором системы (ASBR);

o бит V - оконечной точкой виртуальной связи.

· Число связей (2 октета) - число связей, объявленных в данном LSA.

· Объявление о каждой связи состоит из полей «Link ID», «Link Data», «Type», «#TOS», «TOS 0 metric», за которыми может следовать 0 или более 32_разрядных слов, состоящих из полей «TOS», нулевого октета и «TOS metric». Количество таких слов определяется полем «#TOS».

· Link ID (4 октета), Link Data (4 октета), Type (1 октет) - интерпретация полей «Link ID» и «Link Data» зависит от значения поля «Type» (ниже в колонке «Link Data» под IP_адресом понимается IP_адрес интерфейса объявляющего маршрутизатора, подключенного к той связи, которую он объявляет):

Type	Link ID	Link Data
1 - двухточечная связь между маршрутизаторами	идентификатор соседа	IP_адрес
2 - связь с транзитной сетью	IP_адрес интерфейса выделенного маршрутизатора	IP_адрес
3 - связь с тупиковой сетью (см. также конец этого пункта)	IP_адрес тупиковой сети	маска тупиковой сети
4 - виртуальная связь	идентификатор соседа по магистрали, с которым установлена виртуальная связь	IP_адрес

#TOS (1 октет) - число метрик для маршрутизации по типу сервиса для данной связи (0 - метрики для маршрутизации по типу сервиса не определены).

· TOS 0 metric (2 октета) - метрика данной связи для маршрутизации без учета типа сервиса (метрика по умолчанию).

· TOS (1 октет), TOS metric (2 октета) - метрика данной связи («TOS metric») для указанного типа сервиса («TOS»). Число таких метрик определено полем «#TOS» и может быть равно нулю. Значение TOS определяется, как в заголовке IP_дейтаграммы. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, эти поля поддерживаются для совместимости с предыдущими версиями.

Кроме собственно связей с тупиковыми сетями, следующие связи объявляются как связи с тупиковыми сетями:

· связь с собственным интерфейсом (интерфейсами) типа loopback (Link ID=IP_адрес интерфейса, Link Data заполняется единицами);

· cвязь с хостом, подключенным к маршрутизатору по двухточечной линии (Link ID=IP_адрес хоста, Link Data заполняется единицами);

· связь с сетью, представляющей собой двухточечное соединение между маршрутизаторами (в дополнение к собственно двухточечной связи между маршрутизаторами); в случае, если этой сети не присвоены адрес и маска, Link ID равен IP_адресу интерфейса соседнего маршрутизатора, Link Data заполняется единицами;

· связь с собственным интерфейсом, подключенным к соединению типа point-to-multipoint (в дополнение к двухточечным связям с каждым из соседей, подключенным к этому соединению); Link ID=IP_адрес интерфейса, Link Data заполняется единицами.

Тело LSA типа 2

Значения полей:

· Network Mask (4 октета) - маска сети множественного доступа (адрес этой сети указан в поле «Link State ID» заголовка LSA).

· Attached Router (4 октета) - идентификатор маршрутизатора, подключенного к сети множественного доступа. Перечисляются все маршрутизаторы, установившие отношения смежности с выделенным маршрутизатором. Длина списка маршрутизаторов определяется из общей длины LSA, указанной в заголовке LSA.

LSA этого типа описывает связи, направленные в графе системы от вершины типа «транзитная сеть» к маршрутизаторам этой сети. Метрика этих связей не указывается, поскольку она считается равной нулю.

Тело LSA типов 3 и 4

LSA типа 3 или 4 содержит объявление о расстоянии только до одной IP_сети, лежащей за пределами области (до одного пограничного маршрутизатора). Адрес сети или идентификатор маршрутизатора указан в поле «Link State ID» заголовка LSA.

Поле «Network Mask» (4 октета) содержит значение маски сети, если это LSA типа 3, или все единицы, если это LSA типа 4. Далее следует 32_битное слово, два последних октета которого содержат метрику расстояния по умолчанию (тип сервиса 0), после которого может следовать 0 или более 32_битных слов, объявляющих метрики расстояний для маршрутизации по типам сервиса - аналогично тому, как это сделано в LSA типа 1. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, эти поля поддерживаются для совместимости с предыдущими версиями.

Поле «#TOS» здесь отсутствует, т. к. число объявлений метрик для типов сервиса можно вычислить из общей длины LSA, указанной в заголовке LSA.

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

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

Тело LSA типа 5

Значения полей:

Network Mask (4 октета) - маска внешней IP_сети. IP_адрес этой сети указан в поле «Link State ID» заголовка LSA.

Далее следует одна или более записей с указанием метрики и других характеристик маршрута до данной сети для разных типов сервиса (поля «E TOS», «TOS metric», «Forwarding Address», «External Route Tag»). Первыми указываются характеристики для TOS=0 (т.е. когда тип сервиса не учитывается), эта часть присутствует обязательно. Число прочих типов сервиса, представленных в LSA, определяется из общей длины LSA, указанной в заголовке LSA. Несмотря на то, что маршрутизация по типу сервиса исключена из последней версии стандарта OSPF, соответствующие поля поддерживаются для совместимости с предыдущими версиями.

· E (E TOS) - младший бит октета, содержащего значение TOS (самим значением TOS используются биты 3-6). Имеет следующие значения:

o Е установлен a метрика внешнего маршрута исчисляется в единицах, не сравнимых с исчислением метрик в OSPF (протоколы внешней маршрутизации, поставляющие данные о внешних маршрутах, не обязаны использовать совместимые с OSPF значения метрик); в этом случае метрика, указанная для соответствующего TOS, должна считаться больше любой метрики в OSPF_системе;

o Е сброшен a метрика внешнего маршрута может складываться с метриками внутренних маршрутов.

· TOS 0 metric (TOS metric) (2 октета) - метрика для соответствующего значения TOS.

· Forwarding Address (4 октета) - адрес маршрутизатора, которому следует пересылать дейтаграммы, адресованные в объявляемую внешнюю сеть. Это поле используется, когда ASBR считает, что он сам - не лучший «следующий маршрутизатор» на пути в данную внешнюю сеть. Например, в одной IP_сети с ASBR находится маршрутизатор G, не поддерживающий протокол OSPF (а поддерживающий, например, BGP), причем через G лежат кратчайшие маршруты к определенным внешним сетям. ASBR, который также поддерживает и BGP, узнаёт от G об этих маршрутах и объявляет их в автономной системе, однако с помощью «Forwarding Address» он тут же указывает, что дейтаграммы, адресованные в эти сети, лучше сразу же направлять маршрутизатору G.
Возможны и другие примеры. Если поле «Forwarding Address» обнулено, то дейтаграммы следует пересылать тому ASBR, который объявил данное LSA.

· External Route Tag (4 октета) - поле, используемое ASBR для целей внешней маршрутизации; модулем OSPF игнорируется.

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

Конфигурирование OSPF_маршрутизатора

Для конфигурирования OSPF_маршрутизатора потребуются, как минимум, следующие шаги:

· указать связи, которые будут включены в OSPF_систему; если это широковещательные сети, то указать адреса этих сетей; в случае нешироковещательных сетей и двухточечных связей указать адреса возможных соседей;

· если требуется, указать тип cоединения (двухточечный, point-to-multipoint);

· если есть разбиение на области, для каждой связи указать номер области и ее тип;

· если требуется, сконфигурировать виртуальные связи;

· сконфигурировать внешние маршруты или организовать их получение от протоколов внешней маршрутизации, или установить маршрут по умолчанию - на пограничных маршрутизаторах системы.