Протоколы маршрутизации RIP и OSPF
МОСКОВСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ СВЯЗИ И ИНФОРМАТИКИ
Курсовая работа
по дисциплине «Локальные Вычислительные Сети»
на тему
«Внутренние протоколы маршрутизации RIP и OSPF»
Москва 2009
Внутренний протокол маршрутизации RIP (Routing Information Protocol)
Назначение
Протокол маршрутизации RIP (Routing Information Protocol) относится к алгоритмам класса «distance vector» (алгоритм Белмана-Форда). Этот алгоритм является одним из первых алгоритмов маршрутизации, которые были использованы в информационно – вычислительных сетях вообще и в сети Internet – в частности. Однако он до сих пор чрезвычайно распространен в вычислительных сетях. Помимо версии RIP для сетей TCP/IP, существует также версия RIP для сетей IPX/SPX компании Novell.
Этот протокол маршрутизации предназначен для сравнительно небольших и относительно однородных сетей. Протокол разработан в университете Калифорнии (Беркли), базируется на разработках фирмы Ксерокс и реализует те же принципы, что и программа маршрутизации routed, используемая в ОC UNIX (4BSD). Маршрут здесь характеризуется вектором расстояния до места назначения. Предполагается, что каждый маршрутизатор является отправной точкой нескольких маршрутов до сетей, с которыми он связан. С 1988 года RIP был повсеместно принят производителями персональных компьютеров для использования в их изделиях передачи данных по сети.
Решение, найденное по алгоритму Белмана-Форда, является не оптимальным, а близким к оптимальному. Преимуществом протокола RIP является его вычислительная простота и простота конфигурирования, а недостатками – увеличение трафика при периодической рассылке широковещательных пакетов и неоптимальность найденного маршрута.
В современных сетевых средах RIP – не самое лучшее решение для выбора в качестве протокола маршрутизации, так как его возможности уступают более современным протоколам, таким как EIGRP, OSPF. Присутствует ограничение на 15 хопов, которое не дает применять его в больших сетях.
Архитектура
RIP работает на основе UDP протокола и использует порт 520. На каждом хосте, использующем RIP, должно быть установлено программное обеспечение, обрабатывающее RIP пакеты. Настроить работу протокола на маршрутизаторе можно с помощью того же Hyper Terminal с рабочей станции, имеющей на это право и доступ. Настройки производится с помощью команд в соответствии с документацией к маршрутизатору.
Пример корректной работы протокола
(на рисунке: маршрутизаторы 1-6, сегменты сетей A..F; приведена изначальная информация в маршрутизаторе 2 и информация в нем после двух итераций обмена маршрутными пакетами RIP; после определенного числа итераций маршрутизатор будет знать о расстояниях до всех сегментов, а также альтернативные маршруты)
Пусть сетью назначения является сегмент D. При необходимости отправить пакет в сеть D маршрутизатор просматривает свою базу данных маршрутов и выбирает порт, имеющий наименьшее расстояния до сети назначения (в данном случае порт, связывающий его с маршрутизатором 3).
Для адаптации к изменению состояния связей и оборудования с каждой записью таблицы маршрутизации связан таймер. Если за время тайм-аута не придет новое сообщение, подтверждающее этот маршрут, то он удаляется из маршрутной таблицы.
Пример неустойчивой работы по протоколу (отслеживание изменений в топологии)
(на рисунке: маршрутизаторы M1..M3; при работоспособном состоянии в таблице маршрутов каждого маршрутизатора есть запись о сети 1 и о соответствующем расстоянии до нее; далее рассмотрим случай обрыва линии связи между сетью 1 и маршрутизатором M1).
При обрыве связи с сетью 1 маршрутизатор М1 отмечает, что расстояние до этой сети приняло значение 16. Однако получив через некоторое время от маршрутизатора М2 маршрутное сообщение о том, что от него до сети 1 расстояние составляет 2 хопа, маршрутизатор М1 наращивает это расстояние на 1 и отмечает, что сеть 1 достижима через маршрутизатор 2. В результате пакет, предназначенный для сети 1, будет циркулировать между маршрутизаторами М1 и М2 до тех пор, пока не истечет время хранения записи о сети 1 в маршрутизаторе 2, и он не передаст эту информацию маршрутизатору М1.
Для исключения подобных ситуаций маршрутная информация об известной маршрутизатору сети не передается тому маршрутизатору, от которого она пришла.
Существуют и другие, более сложные случаи нестабильного поведения сетей, использующих протокол RIP, при изменениях в состоянии связей или маршрутизаторов сети.
Пример неустойчивой работы по протоколу (возникновение циклических маршрутов – процедура split horizon).
В исходном состоянии все каналы передачи данных функционируют нормально и, поэтому, маршруты из узлов D и C к сети N лежат через маршрутизатор B и имеют метрику 2.
Предположим, что в некоторый момент времени канал, который связывает маршрутизаторы A и В, выходит из строя. Маршрутизатор B в этом случае перестает принимать update для сети N от маршрутизатора A и по истечении установленного интервала времени маршрутизатор B определяет сеть N в качестве недостижимой и исключает её из своих массивов update.
Однако из-за того, что эти массивы передаются в сети асинхронно вполне возможно, что вскоре после этого маршрутизатор C получит массивов update от маршрутизатора D, который пока ещё считает, что маршрут из B до сети N существует. Получив такую информацию, маршрутизатор C включит в свою таблицу маршрутизации новый маршрут до сети N – через маршрутизатор D с метрикой 3. После того, как истечет время существования исходного маршрута в маршрутизаторе D, эта ситуация повторится совершенно аналогичным образом.
В результате маршрутизатор D скорректирует свою таблицу маршрутизации и внесет в неё маршрут до сети N через шлюз C с метрикой 4. Подобная ситуация будет таким образом возобновляться снова и снова с периодом, который соответствует времени существования маршрута (3 T Update). Этот цикл, который называется «счет до бесконечности», будет продолжаться до тех пор, пока метрика циклического маршрута не достигнет значения 15, после чего он разорвется автоматически.
Правило split horizon (предотвращение возникновения циклических маршрутов)
Алгоритм split horizon является неотъемлемой частью протокола маршрутизации RIP и предназначен для предотвращения появления циклических маршрутов в сети. Для предотвращения возникновения подобных ситуаций достаточно использовать следующее правило:
Маршрутизатор не должен направлять update для маршрутов в адрес их источника.
За этим правилом закрепилось название split horizon – расщепленный горизонт. Маршрутизатор, используя данное правило, разделяет свои маршруты на столько групп, сколько у него есть активных интерфейсов. При использовании правила split horizon, обновления для маршрутов, которые были получены через некоторый интерфейс, не должны передаваться через этот же интерфейс.
Правило split horizon with poisoned reverse
Правило split horizon может быть использовано с незначительной модификацией. Правило split horizon with poisoned reverse «расщепленный горизонт с отравленным обратным путем» – разрешает передачу update для потенциально опасных, с точки зрения возникновения циклов, маршрутов. В данном случае для таких маршрутов устанавливается метрика, которая соответствует бесконечности – 15.
Пример неустойчивой работы по протоколу (процедура triggered update – управляемые модификации)
Использование процедуры Split horizon позволяет избежать появления зацикленного маршрута у двух шлюзов. Однако возможно возникновение ситуации, когда в циклическом маршруте участвуют три шлюза.
На рисунке приведен пример возникновения подобной ситуации. В приведенной сети при выходе из строя канала, который связывает узел А с сетью N, маршрутизатор B может принять от маршрутизатора С несуществующий маршрут до сети N, который якобы проходит через узел C. К тому моменту, когда маршрутизатор C определит, что он не имеет собственного маршрута до сети N, маршрутизатор B уже успеет передать информацию о наличии у него маршрута до этой сети марщрутизатору D.
Использование процедуры Split horizon не сможет предотвратить появление такой петли, поскольку сообщения о маршруте поступают не от того маршрутизатора, которому передаются сообщения update. Следовательно, эта петля будет разорвана только тогда, когда метрика циклического маршрута достигает бесконечности. Для того чтобы уменьшить время переходных процессов в сети, можно использовать процедуру управляемых модификаций (triggered update).
Использование данной процедуры предписывает необходимость формирования мгновенных модификаций в том случае, когда происходит изменение состояния сети. Благодаря тому, что управляемые модификации передаются по сети с высокой скоростью, использование этого механизма может предотвратить появление циклических маршрутов. Однако, поскольку процесс передачи управляемых модификаций имеет вполне определенную конченую скорость, сохраняется возможность, что в процессе передачи регулярного update циклический маршрут все-таки возникнет.
Пример неустойчивой работы
по протоколу
(счетчик времени timeout –
timer)
Возможно возникновение ситуации, когда периодическое обновление будет просто потеряно в сети из-за возникновения краткосрочной перегрузки или временной неработоспособности канала передачи данных. Для того чтобы в этой ситуации маршруты не были ошибочно удалены из таблицы маршрутизации, каждому маршруту ставится в соответствие специальный счетчик времени, который называется timeout – timer. В тот момент времени, когда данный маршрут включается в таблицу маршрутизации, или когда для него приходит очередное обновление значение счетчика timeout – timer устанавливается равным T>timeout max. >= 180 секунд и этот счетчик начинает обратный отсчет времени. В том случае, если счетчик timeout – timer какого либо маршрута достигнет значения 0, этот маршрут должен быть исключен из числа активных маршрутов.
Протокол RIP не обеспечивает решение всех возможных проблем, которые могут возникнуть в процессе определения маршрута в сетях передачи данных. Как уже упоминалось выше, в первую очередь он предназначен для использования в качестве IGP в гомогенных сетях небольшого размера. Кроме того, использование данного протокола приводит к появлению специфических ограничений на параметры сети, в которой он может быть использован.
Ограничение максимальной длины маршрута
Использование протокола RIP целесообразно в сетях, самый длинный путь в которых составляет не более 15 переходов (hops). Данное ограничение определяется способом вычисления маршрута, который принят в данном алгоритме и не может быть преодолено.
Зацикливание маршрутов
Использование протокола RIP может в ряде случаев привести к появлению «зацикленных маршрутов». Для предотвращения возникновения подобных ситуаций должны быть использованы специальные меры (poison reverse, split horizon).
Формат метрики
Для сравнения маршрутов протокол RIP использует достаточно простую «метрику» – число переходов. Однако использование данного критерия в целом ряде случаев не может обеспечить оптимальный выбор маршрута.
Спецификации
RFC 1388. Протокол RIP 2 (1993 год) является новой версией RIP, которая в дополнение к широковещательному режиму поддерживает мультикастинг; позволяет работать с масками субсетей.
RFC 1582. Расширение к RIP по требованиям к хостам к поддержке определённых параметров.
RFC 1721. Анализ протокола RIP версии 2.
RFC 1722 (STD 0057). Протокол RIP версии 2, предписание к применению.
RFC 1724. Протокол RIP версии 2, расширение по MIB (база управляющей информации – management information base).
RFC 2080. Спецификации протокола RIP для IPv6.
RFC 2082. Протокол RIP версии 2, проблемы аутентификации с использованием MD5 (Message Digest 5) – 128 битный алгоритмом хеширования, разработанный в 1991 году. MD5 предназначен для создания «отпечатков» или «дайджестов» сообщений произвольной длины.
RFC 2092. Спецификация для автоматически запускающегося протокола RIP (triggered RIP).
RFC 2453 (STD 0056). Общее описание протокола второй версии.
Реализация протокола.
Существуют две версии протокола RIP: RIP 1 и RIP 2. Версия 2 имеет некоторые усовершенствования, как то: возможность маршрутизации сетей по модели CIDR (кроме адреса сети передается и маска), поддержка мультикастинга, возможность использования аутентификации RIP сообщений и др.
Типы и формат сообщений.
В протоколе RIP имеются два типа сообщений, которыми обмениваются маршрутизаторы:
ответ (response) – рассылка вектора расстояний;
запрос (request) – маршрутизатор (например, после своей загрузки) запрашивает у соседей их маршрутные таблицы или данные об определенном маршруте.
Формат сообщений обоих типов одинаков:
Поля, помеченные знаком *, относятся к версии 2; в сообщениях RIP 1 эти поля должны быть обнулены.
Сообщение RIP состоит из 32 битного слова, определяющего тип сообщения и версию протокола (плюс «Routing Domain» в версии 2), за которым следует набор из одного и более элементов вектора расстояний. Каждый элемент вектора расстояний занимает 5 слов (20 октетов) (от начала поля «Address Family Identifier» до конца поля «Metric» включительно). Максимальное число элементов вектора – 25, если вектор длиннее, он может разбиваться на несколько сообщений.
Поле «Command» определяет тип сообщения: 1 – request, 2 – response; поле «Version» – версию протокола (1 или 2).
Поле «Address Family Identifier» содержит значение 2, которое обозначает семейство адресов IP; другие значения не определены. Поля «IP address» и «Metric» содержат адрес сети и расстояние до нее.
Дополнительно к полям версии 1 во второй версии определены следующие.
«Routing Domain» – идентификатор RIP системы, к которой принадлежит данное сообщение; часто – номер автономной системы. Используется, когда к одному физическому каналу подключены маршрутизаторы из нескольких автономных систем, в каждой автономной системе поддерживается своя таблица маршрутов. Поскольку сообщения RIP рассылаются всем маршрутизаторам, подключенным к сети, требуется различать сообщения, относящиеся к «своей» и «чужой» автономным системам.
«Route Tag» – используется как метка для внешних маршрутов при работе с протоколами внешней маршрутизации.
«sub>net Mask» – маска сети, адрес которой содержится в поле IP address. RIP 1 работает только с классовой моделью адресов.
«Next Hop» – адрес следующего маршрутизатора для данного маршрута, если он отличается от адреса маршрутизатора, пославшего данное сообщение. Это поле используется, когда к одному физическому каналу подключены маршрутизаторы из нескольких автономных систем и, следовательно, некоторые маршрутизаторы «чужой» автономной системы физически могут быть достигнуты напрямую, минуя пограничный (логически подключенный к обеим автономным системам) маршрутизатор. Об этом пограничный маршрутизатор и объявляет в поле «Next Hop».
Адрес 0.0.0.0 в сообщении типа «ответ» обозначает маршрут, ведущий за пределы RIP системы. В сообщении типа «запрос» этот адрес означает запрос информации о всех маршрутах (полного вектора расстояний). Указание в сообщении типа «запрос» адреса конкретной сети означает запрос элемента вектора расстояний только для этой сети – такой режим используется обычно только в отладочных целях.
Аутентификация может производиться протоколом RIP 2 для обработки только тех сообщений, которые содержат правильный аутентификационный код. При работе в таком режиме первый 20 октетный элемент вектора расстояний, следующий непосредственно за первым 32 битным словом RIP сообщения, является сегментом аутентификации. Он определяется по значению поля «Address Family Identifier», равному в этом случае 0xFFFF. Следующие 2 октета этого элемента определяют тип аутентификации, а остальные 16 октетов содержат аутентификационный код. Таким образом, в RIP сообщении с аутентификацией может передаваться не 25, а только 24 элемента вектора расстояний, которые следуют за сегментом аутентификации. К настоящему моменту надежного алгоритма аутентификации для протокола RIP не разработано; стандартом определена только аутентификация с помощью обычного пароля (значение поля «Тип» равно 2).
Работа протокола RIP
Для каждой записи в таблице маршрутов существует время жизни, контролируемое таймером. Если для любой конкретной сети, внесенной в таблицу маршрутов, в течение 180 с не получен вектор расстояний, подтверждающий или устанавливающий новое расстояние до данной сети, то сеть будет отмечена как недостижимая (расстояние равно бесконечности). Через определенное время модуль RIP производит «сборку мусора» – удаляет из таблицы маршрутов все сети, расстояние до которых бесконечно.
При получении сообщения типа «ответ» для каждого содержащегося в нем элемента вектора расстояний модуль RIP выполняет следующие действия:
проверяет корректность адреса сети и маски, указанных в сообщении;
проверяет, не превышает ли метрика (расстояние до сети) бесконечности;
некорректный элемент игнорируется;
если метрика меньше бесконечности, она увеличивается на 1;
производится поиск сети, указанной в рассматриваемом элементе вектора расстояний, в таблице маршрутов;
если запись о такой сети в таблице маршрутов отсутствует и метрика в полученном элементе вектора меньше бесконечности, сеть вносится в таблицу маршрутов с указанной метрикой; в поле «Следующий маршрутизатор» заносится адрес маршрутизатора, приславшего сообщение; запускается таймер для этой записи в таблице;
если искомая запись присутствует в таблице с метрикой больше, чем объявленная в полученном векторе, в таблицу вносятся новые метрика и, соответственно, адрес следующего маршрутизатора; таймер для этой записи перезапускается;
если искомая запись присутствует в таблице и отправителем полученного вектора был маршрутизатор, указанный в поле «Следующий маршрутизатор» этой записи, то таймер для этой записи перезапускается; более того, если при этом метрика в таблице отличается от метрики в полученном векторе расстояний, в таблицу вносится значение метрики из полученного вектора;
во всех прочих случаях рассматриваемый элемент вектора расстояний игнорируется.
Сообщения типа «ответ» рассылаются модулем RIP каждые 30 сек. по широковещательному или мультикастинговому (только RIP 2) адресу; рассылка «ответа» может происходить также вне графика, если маршрутная таблица была изменена (triggered response). Стандарт требует, чтобы triggered response рассылался не немедленно после изменения таблицы маршрутов, а через случайный интервал длительностью от 1 до 5 с. Эта мера позволяет несколько снизить нагрузку на сеть.
В каждую из сетей, подключенных к маршрутизатору, рассылается свой собственный вектор расстояний, построенный с учетом дополнения 1 (1А), сформулированного выше в п. 4.2.1. Там, где это возможно, адреса сетей агрегируются (обобщаются), то есть несколько подсетей с соседними адресами объединяются под одним, более общим адресом с соответствующим изменением маски.
В случае triggered response посылается информация только о тех сетях, записи о которых были изменены.
Информация о сетях с бесконечной метрикой посылается только в том случае, если она была недавно изменена.
При получении сообщения типа «запрос» с адресом 0.0.0.0 маршрутизатор рассылает в соответствующую сеть обычное сообщение типа ответ. При получении запроса с любым другим значением в поле (полях) «IP Address» посылается ответ, содержащий информацию только о сетях, которые указаны. Такой ответ посылается на адрес запросившего маршрутизатора (не широковещательно).
Настройка протокола RIP (логи)
<Quidway>
%May 12 16:08:13:801 2009 Quidway SHELL/5/LOGIN: Console login from con0
<Quidway>vrbd
Routing Platform Software
Version AR28–10 8040V300R003B03D040 (COMWAREV300R002B60D021), RELEASE SOFTWARE
Compiled Apr 04 2006 14:35:29 by Houming
<Quidway>display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.1.0
<Quidway>su
User privilege level is 3, and only those commands can be used
whose level is equal or less than this.
Privilege note: 0 VISIT, 1 MONITOR, 2 SYSTEM, 3 MANAGE
<Quidway>system-view
System View: return to User View with Ctrl+Z.
%May 12 16:24:58:322 2009 Quidway PHY/2/PHY: Ethernet0/0: change status to up
%May 12 16:24:58:322 2009 Quidway IFNET/5/UPDOWN: Line protocol on the interface
Ethernet0/0 is UP
[Quidway] interface Ethernet 0/0
[Quidway-Ethernet0/0] display ip interface
Aux0 current state: Administratively DOWN
Line protocol current state:DOWN
Internet Address is 172.16.0.2/24
Broadcast address: 172.16.0.255
The Maximum Transmit Unit: 1500 bytes
ip fast-forwarding incoming packets state is Disabled
ip fast-forwarding outgoing packets state is Disabled
ip multicast-fast-forwarding packets state is Disabled
IP packets input number: 0, bytes: 0, multicasts: 0
IP packets output number: 0, bytes: 0, multicasts: 0
TTL invalid packet number: 0
ICMP packet input number: 0
Echo reply: 0
Unreachable: 0
Source quench: 0
Routing redirect: 0
Echo request: 0
Router advert: 0
Router solicit: 0
Time exceed: 0
IP header bad: 0
Timestamp request: 0
Timestamp reply: 0
Information request: 0
Information reply: 0
Netmask request: 0
Netmask reply: 0
Unknown type: 0
Ethernet0/0 current state:UP
Line protocol current state:UP
Internet Address is 192.168.1.5/24
Broadcast address: 192.168.1.255
The Maximum Transmit Unit: 1500 bytes
ip fast-forwarding incoming packets state is Enabled
ip fast-forwarding outgoing packets state is Enabled
ip multicast-fast-forwarding packets state is Disabled
IP packets input number: 15, bytes: 4920, multicasts: 0
IP packets output number: 0, bytes: 0, multicasts: 0
ARP packets input number: 35
Request packet: 35
Reply packet: 0
Unknown packet: 0
TTL invalid packet number: 0
ICMP packet input number: 0
Echo reply: 0
Unreachable: 0
Source quench: 0
Routing redirect: 0
Echo request: 0
Router advert: 0
Router solicit: 0
Time exceed: 0
IP header bad: 0
Timestamp request: 0
Timestamp reply: 0
Information request: 0
Information reply: 0
Netmask request: 0
Netmask reply: 0
Unknown type: 0
DHCP packet
[Quidway] ping 192.168.1.10
PING 192.168.1.10: 56 data bytes, press CTRL_C to break
Reply from 192.168.1.10: bytes=56 Sequence=1 ttl=64 time=2 ms
Reply from 192.168.1.10: bytes=56 Sequence=2 ttl=64 time=1 ms
Reply from 192.168.1.10: bytes=56 Sequence=3 ttl=64 time=2 ms
Reply from 192.168.1.10: bytes=56 Sequence=4 ttl=64 time=1 ms
Reply from 192.168.1.10: bytes=56 Sequence=5 ttl=64 time=2 ms
– 192.168.1.10 ping statistics –
5 packet(s) transmitted
5 packet(s) received
0.00% packet loss
round-trip min/avg/max = 1/1/2 ms
deal mode: global
[Quidway] rip
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
[Quidway-rip] network 192.168.0.0
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] peer 192.168.1.10
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
Peer:
192.168.1.10
Network:
192.168.0.0
[Quidway-rip] undo peer 192.168.1.10
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip]
Quidway-rip] filter-policy gateway 192.168.1.10 import
The gateway does not exist, but the configuration is saved
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Checkzero is on Default cost: 1
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
filter-policy gateway 192.168.1.10 import
[Quidway-rip] undo filter-policy gateway 192.168.1.10 import
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Host-route is off
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] host-route
[Quidway-rip] undo summary
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is off Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] summary
[Quidway-rip] preference 150
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 150
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] preference 100
[Quidway-rip] timers timeout 200
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 200
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
[Quidway-rip] timers timeout 180
[Quidway-rip] timers update 1005
[Quidway-rip] display rip
RIP is running
public net
Checkzero is on Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 1005
Timeout timer: 180
Garbage-collection timer: 4020
No peer router
Network:
192.168.0.0
[Quidway-rip] timers update 30
[Quidway-rip] display rip
RIP is running
public net
Checkzero is off Default cost: 1
Summary is on Preference: 100
Validate-source-address is on
Traffic-share-across-interface is off
Period update timer: 30
Timeout timer: 180
Garbage-collection timer: 120
No peer router
Network:
192.168.0.0
<Quidway>
Внутренний протокол маршрутизации OSPF (Open Shortest Pass First)
Назначение.
Протокол OSPF (Open Shortest Pass First, алгоритмы предложены Дейкстрой) является альтернативой RIP в качестве внутреннего протокола маршрутизации. OSPF представляет собой протокол состояния маршрута (в качестве метрики используется – коэффициент качества обслуживания). Каждый маршрутизатор обладает полной информацией о состоянии всех интерфейсов всех маршрутизаторов (переключателей) автономной системы. Он был изобретён для избавления сетей, использующих RIP от таких напастей, как:
Циклические маршруты. Так как в протоколе нет механизмов выявления замкнутых маршрутов, необходимо либо слепо верить партнерам, либо принимать меры для блокировки такой возможности.
Для подавления нестабильностей RIP должен использовать малое значение максимально возможного числа шагов (<16).
Медленное распространение маршрутной информации по сети создает проблемы при динамичном изменении маршрутной ситуации (система не поспевает за изменениями). Малое предельное значение метрики улучшает сходимость, но не устраняет проблему.
Протокол OSPF представляет собой классический протокол маршрутизации класса Link–State, который обеспечивает:
отсутствие ограничений на размер сети
поддержку внеклассовых сетей
передачу обновлений маршрутов с использованием адресов типа multicast
достаточно большую скорость установления маршрута
использование процедуры authentication при передаче и получении обновлений маршрутов
Архитектура
OSPF является иерархическим протоколом маршрутизации с объявлением состояния о канале соединения (link-state). Он был спроектирован как протокол работы внутри сетевой области – AS (Autonomous System), которая представляет собой группу маршрутизаторов и сетей, объединенных по иерархическому принципу и находящихся под единым управлением и совместно использующих общую стратегию маршрутизации. В качестве транспортного протокола для маршрутизации внутри AS OSPF использует IP протокол.
AS представляет собой набор сетей, которые находятся под единым управлением и совместно используют общую стратегию маршрутизации. OSPF является протоколом маршрутизации внутри AS, хотя он также может принимать и отправлять пакеты в другие AS.
Настройка на маршрутизаторах производится аналогичным образом как при настройке RIP.
Иерархическая маршрутизация
Использование иерархической маршрутизации позволяет существенно повысить эффективность использования каналов передачи данных за счет сокращения доли передаваемого по ним служебного трафика.
Информационный обмен, который осуществляют маршрутизаторы для определения маршрута передачи данных внутри области, показан на рисунке зелеными стрелками. Определение маршрута и информационный обмен между областями в данном случае производится через специальную центральную область – AREA 0.
Использование такой схемы логического построения сети позволяет существенно уменьшить долю неинформативного трафика, который передается по каналам передачи данных между областями. В частности в этом случае по каналам, используемых для передачи данных между областями, (красный цвет) не будет передаваться информация о сетях, которые имеют чисто локальное значение.
Распределение нагрузки между параллельными каналами (Load balancing)
При использовании протокола маршрутизации OSPF допускается существование нескольких маршрутов в направлении некоторого узла сети. В том случае, если эти маршруты обеспечивают одинаковое качество передачи данных, информационный поток в адрес данного узла может быть направлен по всем этим каналам одновременно, что обеспечит существенное увеличение скорости передачи данных. Динамическое перераспределение трафика между параллельными каналами, которое выполняется пропорционально степени загруженности этих каналов, называется Load balancing.
Иерархия маршрутизации
В отличие от RIP, OSPF может работать в пределах некоторой иерархической системы. Самым крупным объектом в этой иерархии является автономная система (Autonomous System – AS) AS является набором сетей, которые находятся под единым управлением и совместно используют общую стратегию маршрутизации. OSPF является протоколом маршрутизации внутри AS, хотя он и способен принимать маршруты из других AS и отправлять маршруты в другие AS.
Любая AS может быть разделена на ряд областей (area). Область – это группа смежных сетей и подключенных к ним хостов. Роутеры, имеющие несколько интерфейсов, могут участвовать в нескольких областях. Такие роутеры, которые называются роутерами границы областей (area border routers), поддерживают отдельные топологические базы данных для каждой области.
Топологическая база (topological database) данных фактически представляет собой общую картину сети по отношению к роутерам. Топологическая база данных содержит набор LSA, полученных от всех роутеров, находящихся в одной области. Т.к. роутеры одной области коллективно пользуются одной и той же информацией, они имеют идентичные топологические базы данных.
Термин «домен» (domain) исользуется для описания части сети, в которой все роутери имеют идентичную топологическую базу данных. Термин «домен» часто используется вместо AS.
Топология области является невидимой для объектов, находящихся вне этой области. Путем хранения топологий областей отдельно, OSPF добивается меньшего трафика маршрутизации, чем трафик для случая, когда AS не разделена на области.
Разделение на области приводит к образованию двух различных типов маршрутизации OSPF, которые зависят от того, находятся ли источник и пункт назначения в одной и той же или разных областях.
Маршрутизация внутри области имеет место в том случае, когда источник и пункт назначения находятся в одной области.
Маршрутизация между областями – когда они находятся в разных областях.
Стержневая часть OSPF (backbone) отвечает за распределение маршрутной информации между областями. Она включает в себя все роутеры границы области, сети, которые не принадлежат полностью какого-либо из областей, и подключенные к ним роутеры. На следующем рисунке представлен пример объединенной сети с несколькими областями.
На этом рисунке роутеры 4, 5, 6, 10, 11 и 12 образуют стержень. Если хост Н1 Области 3 захочет отправить пакет хосту Н2 Области 2, то пакет отправляется в роутер 13, который продвигает его в роутер 12, который в свою очередь отправляет его в роутер 11. Роутер 11 продвигает пакет вдоль стержня к роутеру 10 границы области, который отправляет пакет через два внутренних роутера этой области (роутеры 9 и 7) до тех пор, пока он не будет продвинут к хосту Н2.
Сам стержень представляет собой одну из областей OSPF, поэтому все стержневые роутеры используют те же процедуры и алгоритмы поддержания маршрутной информации в пределах стержневой области, которые используются любым другим роутером. Топология стержневой части невидима для всех внутренних роутеров точно также, как топологии отдельных областей невидимы для стержневой части.
Область может быть определена таким образом, что стержневая часть не будет смежной с ней. В этом случае связность стержневой части должна быть восстановлена через виртуальные соединения. Виртуальные соединения формируются между любыми роутерами стержневой области, которые совместно используют какую-либо связь с любой из нестержневых областей; они функционируют так, как если бы они были непосредственными связями.
Граничные роутеры AS, использующие OSPF, узнают о внешних роутерах через протоколы внешних роутеров (EGPs), таких, как Exterior Gateway Protocol (EGP) или Border Gateway Protocol (BGP), или через информацию о конфигурации.
Спецификации.
RFC 1245. Анализ протокола OSPF.
RFC 1246. Экспериментальная часть работы протокола.
RFC 1247 (обновлено 1349). Спецификации к протоколу OSPF версии 2.
RFC 1248, RFC 1850. База управляющей информации протокола второй версии.
RFC 1584. Дополнение к протоколу по широковещанию.
RFC 1585. Расширение протокола по широковещанию, анализ и практические приложения.
RFC 1586. Руководство по использованию OSPF на сетях Frame Relay.
RFC 1587. Опция протокола для «не совсем тупиковой зоны» (Not-so-stubby area).
RFC 1793. Расширение к спецификациям по требованию к оборудованию с поддержкой протокола.
RFC 2178. Черновой вариант спецификаций.
RFC 2328 (STD 0054). Действующий стандарт по OSPF.
Реализация протокола.
Метрики.
Метрика сети, оценивающая пропускную способность, определяется как количество секунд, требуемое для передачи 100 Мбит через физическую среду данной сети. Например, метрика сети на базе 10Base-T Ethernet равна 10, а метрика выделенной линии 56 кбит/с равна 1785. Метрика канала со скоростью передачи данных 100 Мбит/с и выше равна единице.
Порядок расчета метрик, оценивающих надежность, задержку и стоимость, не определен. Администратор, желающий поддерживать маршрутизацию по этим типам сервисов, должен сам назначить разумные и согласованные метрики по этим параметрам.
Если не требуется маршрутизация с учетом типа сервиса (или маршрутизатор ее не поддерживает), используется метрика по умолчанию, равная метрике по пропускной способности.
База данных состояния связей
Для работы алгоритма SPF на каждом маршрутизаторе строится база данных состояния связей, представляющая собой полное описание графа OSPF системы. При этом вершинами графа являются маршрутизаторы, а ребрами – соединяющие их связи. Базы данных на всех маршрутизаторах идентичны.
За создание баз данных и поддержку их взаимной синхронизации при изменениях в структуре системы сетей отвечают другие алгоритмы, содержащиеся в протоколе OSPF.
Поддержка множественных маршрутов.
Если между двумя узлами сети существует несколько маршрутов с одинаковыми или близкими по значению метриками, протокол OSPF позволяет направлять части трафика по этим маршрутам в пропорции, соответствующей значениям метрик. Например, если существует два альтернативных маршрута с метриками 1 и 2, то две трети трафика будет направлено по первому из них, а оставшаяся треть – по второму.
Положительный эффект такого механизма заключается в уменьшении средней задержки прохождения дейтаграмм между отправителем и получателем, а также в уменьшении колебаний значения средней задержки.
Менее очевидное преимущество поддержки множественных маршрутов состоит в следующем. Если при использовании только одного из возможных маршрутов этот маршрут внезапно выходит из строя, весь трафик будет разом перемаршрутизирован на альтернативный маршрут, при этом во время процесса массового переключения больших объемов трафика с одного маршрута на другой весьма велика вероятность образования затора на новом маршруте. Если же до аварии использовалось разделение трафика по нескольким маршрутам, отказ одного из них вызовет перемаршрутизацию лишь части трафика, что существенно сгладит нежелательные эффекты.
Внешние маршруты.
Для достижения сетей, не входящих в OSPF систему (в автономную систему), используются пограничные маршрутизаторы автономной системы (autonomous system border router, ASBR), имеющие связи, уходящие за пределы системы.
ASBR вносят в базу данных состояния связей данные о сетях за пределами системы, достижимых через тот или иной ASBR. Такие сети, а также ведущие к ним маршруты называются внешними (external).
В простейшем случае, если в системе имеется только один ASBR, он объявляет через себя маршрут по умолчанию (default route) и все дейтаграммы, адресованные в сети, не входящие в базу данных системы, отправляются через этот маршрутизатор.
Если в системе имеется несколько ASBR, то, возможно, внутренним маршрутизаторам системы придется выбирать, через какой именно пограничный маршрутизатор нужно отправлять дейтаграммы в ту или иную внешнюю сеть. Это делается на основе специальных записей, вносимых ASBR в базу данных системы. Эти записи содержат адрес и маску внешней сети и метрику расстояния до нее, которая может быть, а может и не быть сравнимой с метриками, используемыми в OSPF системе (см. также п. 5.5.12). Если возможно, адреса нескольких внешних сетей агрегируются в общий адрес с более короткой маской.
ASBR может получать информацию о внешних маршрутах от протоколов внешней маршрутизации, а также все или некоторые внешние маршруты могут быть сконфигурированы администратором (в том числе единственный маршрут по умолчанию).
Сети множественного доступа
Протокол OSPF особым образом выделяет сети множественного доступа, то есть сети, где каждый узел может непосредственно связаться с каждым. Такие сети могут также поддерживать широковещательную передачу и мультикастинг (broadcast networks, например, Ethernet, FDDI) или не поддерживать таковой (non-broadcast multi-access networks, NBMA, например, Х.25, Frame Relay, ATM). Следуя модели работы протоколов состояния связей, связь каждой пары маршрутизаторов должна рассматриваться как связь типа «точка-точка», что значит: каждый маршрутизатор должен установить смежность с каждым, то есть всего N (N 1)/2 отношений смежности, по которым происходит обмен всеми типами сообщений.
Протокол OSPF сводит ситуацию только к N отношениям смежности, выбирая среди всех маршрутизаторов данной широковещательной сети один выделенный маршрутизатор (designated router, DR), с которым все остальные маршрутизаторы устанавливают отношения смежности.
Это значит, что каждый «невыделенный» маршрутизатор поддерживает синхронизацию базы данных состояния связей не со всеми соседями, а только с выделенным маршрутизатором. При этом протокол затопления в подобной сети работает следующим образом: «обычный» маршрутизатор сообщает об изменении состояния своих связей выделенному маршрутизатору, а тот затапливает сеть этим сообщением и его получают все остальные маршрутизаторы сети. Естественно, что по своим внешним интерфейсам, ведущим к прочим маршрутизаторам системы, не находящимся в данной сети множественного доступа, каждый маршрутизатор отправляет сообщения без участия выделенного маршрутизатора.
Протокол OSPF позволяет также редуцировать размер базы данных состояния связей. Для этого в граф системы вводится виртуальная вершина «транзитная сеть», представляющая собой сеть множественного доступа как таковую. Каждый маршрутизатор, в том числе и выделенный, при таком подходе имеет не набор двухточечных связей со всеми остальными маршрутизаторами своей сети, а одну связь с вершиной «транзитная сеть».
Выборы выделенного маршрутизатора проводятся с помощью протокола Hello. Кроме выделенного маршрутизатора выбирается также и запасной выделенный маршрутизатор (backup designated router, BDR), остальные маршрутизаторы сети устанавливают отношения смежности как с DR, так и с BDR (следовательно, в предыдущем пункте при описании отношений смежности не хватает BDR). Все сообщения для DR и BDR посылаются по мультикастинговому адресу 224.0.0.6 «Всем выделенным OSPF маршрутизаторам».
Запасной выделенный маршрутизатор получает эти сообщения, но не предпринимает никаких действий, связанных со своей выделенной функцией. Однако если выделенный маршрутизатор отключается (этот факт детектируется с помощью протокола Hello), то запасной немедленно становится выделенным, не тратя времени на установление отношений смежности с остальными маршрутизаторами, так как эти отношения уже установлены. При этом с помощью протокола Hello выбирается новый запасной выделенный маршрутизатор. Если бывший выделенный маршрутизатор подключится снова, статус выделенного маршрутизатора ему не возвращается.
NBMA- и point-to-multipoint сети
В случае, когда несколько OSPF маршрутизаторов подключены к сети множественного доступа, не поддерживающей широковещательную передачу (NBMA сеть), они следуют той же процедуре, что и в случае широковещательной сети, поскольку каждый маршрутизатор также может непосредственно связаться с каждым, и, следовательно, существует та же проблема по числу отношений смежности и числу записей в базе данных состояния связей. В случае NBMA сетей проблема даже усугубляется тем, что поддержка постоянных соединений между любыми двумя маршрутизаторами для обмена маршрутной информацией (отношения смежности) может потребовать значительных технических и финансовых затрат.
Отличие NBMA от широковещательных сетей состоит в том, что адреса всех соседей должны быть предварительно сконфигурированы на каждом маршрутизаторе, потому что возможности передавать мультикастинговые сообщения нет.
Если маршрутизатор, подключенный к нешироковещательной сети, может непосредственно связаться с несколькими, но не со всеми маршрутизаторами этой сети (неполный множественный доступ), такое соединение конфигурируется как point-to-multipoint и не рассматривается протоколом OSPF как сеть множественного доступа со всеми вышеописанными последствиями. Маршрутизатор, подключенный к соединению типа point-to-multipoint, устанавливает двухточечные связи с каждым своим соседом по соединению.
Могут быть также причины, по которым администратор пожелает сконфигурировать сеть с полным множественным доступом как point-to-multipoint.
Иерархическая маршрутизация (Разбиение на области)
Для упрощения вычисления маршрутов и уменьшения размера базы данных состояния связей OSPF система может быть разбита на отдельные независимые области (areas), объединяемые в единую систему особой областью, называемой магистралью (backbone). Области, не являющиеся магистралью, называются периферийными.
Маршруты внутри каждой области вычисляются как в отдельной системе: база данных состояния связей содержит записи только о связях маршрутизаторов внутри области, действие протокола затопления не распространяется за пределы области.
Некоторые маршрутизаторы принадлежат магистрали и одной или нескольким периферийным областям. Такие маршрутизаторы называются областными пограничными маршрутизаторами (area border router, ABR). Каждая область должна иметь как минимум один ABR, иначе она будет полностью изолирована от остальной части системы.
Областные пограничные маршрутизаторы поддерживают отдельные базы данных состояния связей для всех областей, к которым они подключены. На основании этих данных они обобщают информацию о достижимости сетей внутри отдельных областей и сообщают результат в смежную область. Также ABR обрабатывают подобные сообщения от других ABR (граничащих с другими областями) и ретранслируют информацию о внешних маршрутах, исходящую от пограничных маршрутизаторов (автономной) системы (ASBR).
Тем самым обеспечивается передача маршрутной информации и коннективность между областями. При этом, за пределы области передается не полная база данных состояния связей, а просто список сетей этой области, достижимых извне области через данный ABR, вместе с метриками расстояния до этих сетей. Если возможно, адреса сетей агрегируются в общий адрес с более короткой маской. Подобную же информацию, но только о сетях, лежащих за пределами OSPF системы, распространяют ASBR.
Тупиковые и не совсем тупиковые области
Области, внутрь которых не передается информация о внешних маршрутах, называются тупиковыми областями (stub areas). Все дейтаграммы, исходящие из данной области и адресованные за пределы автономной системы, отправляются по маршруту по умолчанию (default) через определенный ABR. Тупиковая область может иметь несколько ABR, но для каждого узла внутри области установлен маршрут по умолчанию, проходящий только через один их ABR.
Протокол OSPF определяет также понятие не совсем тупиковых областей (not so stubby area, NSSA). К таким областям относятся тупиковые области, в которых разрешено объявлять некоторые внешние маршруты.
OSPF заголовок
Протокол OSPF в стеке протоколов TCP/IP находится непосредственно над протоколом IP, код OSPF равен 89. То есть если значение поля «Protocol» IP дейтаграммы равно 89, то данные дейтаграммы являются сообщением OSPF и передаются OSPF модулю для обработки. Соответственно размер OSPF сообщения ограничен максимальным размером дейтаграммы.
Все сообщения OSPF имеют общий заголовок (следующий в дейтаграмме непосредственно за IP заголовком):
Значения полей:
Version (1 октет) – версия протокола (=2);
Type (1 октет) – тип сообщения:
Hello;
описание базы данных (Database Description);
запрос состояния связей (Link State Request);
обновление состояния связей (Link State Update);
подтверждение приема сообщения о состоянии связей (Link State Acknowledgment).
Packet length (2 октета) – длина сообщения в октетах, включая заголовок.
Router ID (4 октета) – идентификатор маршрутизатора, отправившего сообщение. Router ID равен адресу одного из IP интерфейсов маршрутизатора. У маршрутизаторов Cisco это наибольший из адресов локальных интерфейсов, а если таковых нет, то наибольший из адресов внешних интерфейсов.
Area ID (4 октета) – номер области, к которой относится данное сообщение; номер 0 зарезервирован для магистрали. Часто номер области полагают равным адресу IP сети (одной из IP сетей) этой области.
Checksum (2 октета) – контрольная сумма, охватывает все OSPF сообщение, включая заголовок, но исключая поле «Authentication»; вычисляется по тому же алгоритму, что и в IP заголовке.
Authentication Type (2 октета) – тип аутентификации сообщения. Стандарт определяет несколько возможных типов, самые простые из них: 0 – нет аутентификации, 1 – аутентификация с помощью пароля.
Authentication (8 октетов) – аутентификационные данные; например, восьмисимвольный пароль.
Далее при рассмотрении формата сообщений вышеописанный заголовок будет изображаться в виде поля «OSPF заголовок», помещенного в начало сообщения.
Протокол Hello
После инициализации модуля OSPF (например, после подачи питания на маршрутизатор) через все интерфейсы, включенные в OSPF систему, начинают рассылаться Hello сообщения. Задача Hello протокола – обнаружение соседей и установление с ними отношений смежности.
Соседями называются OSPF маршрутизаторы, подключенные к одной сети (к одной линии связи) и обменивающиеся Hello сообщениями.
Смежными называются соседние OSPF маршрутизаторы, которые приняли решение обмениваться друг с другом информацией, необходимой для синхронизации базы данных состояния связей и построения маршрутов. Не все соседи становятся смежными.
Другая задача протокола Hello – выбор выделенного маршрутизатора в сети с множественным доступом, к которой подключено несколько маршрутизаторов.
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 |
Бит Т установлен, поддерживается маршрутизация по типу сервиса (этот бит исключен из последней версии стандарта OSPF, но может поддерживаться для совместимости с предыдущими версиями).
Бит Е установлен, маршрутизатор может принимать и объявлять внешние маршруты через данный интерфейс; сброшен, данный интерфейс маршрутизатора принадлежит тупиковой области.
Бит MC установлен, маршрутизатор поддерживает маршрутизацию мультикастинговых дейтаграмм (RFC 1584).
Бит N/P установлен, данный интерфейс маршрутизатора принадлежит не совсем тупиковой области (NSSA).
Бит EA установлен, маршрутизатор может получать и ретранслировать объявления о «внешних атрибутах» (к настоящему моменту описание опции не разработано).
Бит DC установлен, маршрутизатор поддерживает работу с соединениями, устанавливаемыми по требованию (demand circuits, RFC 1793) – это, например, означает, что записи о связях, устанавливаемых по требованию, не устаревают.
Поле «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 системы действует следующий алгоритм.
Получить сообщение. Найти соответствующую запись в базе данных.
Если запись не найдена, добавить ее в базу данных, передать сообщение по всем интерфейсам.
Если номер записи в базе данных меньше номера пришедшего сообщения, заменить запись в базе данных, передать сообщение по всем интерфейсам.
Если номер записи в базе данных больше номера пришедшего сообщения и эта запись не была недавно разослана, разослать содержимое записи из базы данных через тот интерфейс, откуда пришло сообщение. Понятие «недавно» определяется значением константы.
В случае равных номеров сообщение игнорировать.
Протокол 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, является:
бит B – пограничным маршрутизатором области (ABR);
бит Е – пограничным маршрутизатором системы (ASBR);
бит 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). Имеет следующие значения:
Е установлен à метрика внешнего маршрута исчисляется в единицах, не сравнимых с исчислением метрик в OSPF (протоколы внешней маршрутизации, поставляющие данные о внешних маршрутах, не обязаны использовать совместимые с OSPF значения метрик); в этом случае метрика, указанная для соответствующего TOS, должна считаться больше любой метрики в OSPF системе;
Е сброшен à метрика внешнего маршрута может складываться с метриками внутренних маршрутов.
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);
если есть разбиение на области, для каждой связи указать номер области и ее тип;
если требуется, сконфигурировать виртуальные связи;
сконфигурировать
внешние маршруты или организовать их
получение от протоколов внешней
маршрутизации, или установить маршрут
по умолчанию – на пограничных
маршрутизаторах системы.