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

Существует два класса протоколов маршрутизации внутри автономных систем: Distance Vector, к которому относятся RIP, EIGRP и Link State, к которому относятся OSPF и IS-IS. Идеология Link State подразумевает, что каждый маршрутизатор должен не просто знать самые лучшие маршруты во все удалённые сети, но и иметь в памяти полную карту сети со всеми существующими связями между другими маршрутизаторами в том числе. OSPF – наиболее распространённый протокол маршрутизации. Это связанно с тем, что его основной конкурент EIGRP вплоть до 2013 года был закрытым протоколом и мог использоваться только на оборудовании Cisco, в то время, как OSPF – это открытый протокол, и он изначально поддерживался как Cisco, так и другими производителями. Таким образом, OSPF завоевал популярность не смотря на некоторые его недостатки в сравнении с EIGRP: меньшую гибкость, отсутствие четкого описания механизма подсчёта метрики, повышенные требования к ресурсам маршрутизатора. В то же время, у OSPF есть и множество достоинств: иерархический дизайн сети (реализуется с помощью зон), удобство при отладке (так как можно видеть карту сети).

Стандартное значение административной дистанции для протокола OSPF – 110, что означает, что его маршруты считаются более приоритетными чем IS-IS, RIP, External EIGRP, Internal BGP, но менее приоритетными чем IGRP, EIGRP BGP. Такая административная дистанция – скорее преференция со стороны Cisco к своим протоколам. Так как с точки зрения здравого смысла, OSPF, конечно предпочтительнее RIP, в современных сетях, но он так же должен быть и предпочтительнее IGRP, который, в силу своего возраста является классовым протоколом маршрутизации. OSPF является бесклассовым (classless) протоколом маршрутизации, что означает передачу вместе с апдейтами информацию о маске подсети (префиксе), в то время, как старые классовые протоколы маршрутизации, опираются на стандартные классы сетей (A, B, C) и по этой причине в настоящее время малоприменимы.

Принцип работы OSPF

Логика работы протокола OSPF следующая:

  1. Маршрутизаторы обмениваются маленькими HELLO-пакетами
  2. Обменявшись пакетами, они устанавливают соседские отношения, добавляя каждый друг друга в свою локальную таблицу соседей
  3. Маршрутизаторы собирают состояния всех своих линков (связей с соседями), включающие в себя id Маршрутизатора, id соседа, сеть и префикс между ними, тип сети, стоимость линка (метрику) и формируют пакет, называемый LSA (Link State Advertisement).
  4. Маршрутизатор рассылает LSA своим соседям, те распространяют LSA дальше.
  5. Каждый маршрутизатор, получивший LSA добавляет в свою локальную табличку LSDB (Link State Database) информацию из LSA.
  6. В LSDB скапливается информация, обо всех парах соединённых в сети маршрутизаторов, то есть каждая строчка таблицы — это информация вида: «Маршрутизатор A имеет соединение со своим соседом маршрутизатором B, между ними сеть такая-то с такими-то свойствами».
  7. После обмена LSA, каждый маршрутизатор знает про все линки, на основании пар строится полная карта сети, включающая все маршрутизаторы и все связи между ними.
  8. На основании этой карты каждый маршрутизатор индивидуально ищет кратчайшие с точки зрения метрики маршруты во все сети и добавляет их в таблицу маршрутизации.

Как видно из описания алгоритма, он достаточно сложный и ресурсоёмкий. Это объясняет высокие требования OSPF к производительности маршрутизатора и оперативной памяти. Теперь, давайте представим, что происходит, если у одного из маршрутизаторов пропадает связь с соседом:

  1. Он рассылает всем новые LSA
  2. Все заново строят карту сети
  3. Заново считают кратчайшие маршруты во все сети
  4. Обновляют свою таблицу маршрутизации

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

OSPF пакет помещается в IP пакет, у которого адрес отправителя – адрес отправившего пакет маршрутизатора, а адрес получателя, как правило, мультикастовый. Пакет помещается в соответствующий мультикастовый фрейм, например, Ethernet. Следует обратить внимание, что OSPF напрямую инкапсулируется в IP, а не в TCP или UDP. Этот момент важен при написание списков контроля доступа.

Виды OSPF сообщений

Всего существует пять типов OSPF сообщений:

  1. Hello – отправляются регулярно для поиска соседей и установки соседских отношений
  2. Database Description DBD – используются для проверки синхронизации LSDB у соседних маршрутизаторов
  3. Link state request LSR – принудительный запрос у некого маршрутизатора его LSA. Может использоваться, например, когда маршрутизатор только включился и ему надо узнать текущие связи в сети, или, когда у маршрутизатора пропала сеть, и он хочет узнать нет ли у других маршрутизаторов альтернативных маршрутов к ней.
  4. Link state update LSU – содержит состояния связей маршрутизатора.
  5. Link State Acknowledgment LSAck – пакет-подтверждение, высылается в ответ на другие типы пакетов. Это связано с тем, что OSPF не использует протокол TCP и для надёжной доставки нужен свой собственный механизм подтверждений.

OSPF Hello и Dead интервалы

Hello пакеты рассылаются маршрутизаторами регулярно. Периодичность можно менять в соответствии с задачами, но по умолчанию они шлются раз в 10 секунд в сетях со множественным доступом (BMA) и сетях точка-точка (point-to-point) и раз в 40 секунд в сетях со множественным доступом без возможности широковещательной рассылки (NBMA). Если маршрутизатор не получает ни одного пакета в течении Dead-интервала, то считается, что сосед пропал и отношения разрываются, что влечёт за собой потерю, линка, отправку LSU, пересчёт топологии и т.д. Dead-интервал по умолчанию равен четырём Hello-интервалам, (40 секунд для BMA и 120 для NBMA).

ID маршрутизатора в OSPF

Так как маршрутизаторы строят карту сети, где в качестве узлов используются другие маршрутизаторы, то очень важно, чтобы все они имели уникальные имена. Это необходимо для того, чтобы глядя на полученные из разных источников LSA, понять, что речь идёт об одних и тех же устройствах. В качестве такого уникального имени в OSPF используется поле «Router ID». Идентификатор маршрутизатора выглядит как ip адрес, то есть, состоит из четырёх октетов, разделённых точками. Причём, даже в OSPF для IPv6 идентификатор выглядит как IPv4 адрес. Идентификатор всегда должен присутствовать. Не так важно, какой он будет, важна уникальность идентификаторов в пределах сети. Его можно задать вручную, либо, если этого не сделать, он будет присвоен автоматически.

В общем случае, алгоритм назначения маршрутизатору идентификатора следующий (в порядке приоритета):

  1. Если ID задан явно с помощью команды router-id, то используется именно он
  2. Если router-id не вводился, то берётся самый большой адрес из всех loopback интерфейсов, настроенных на данном маршрутизаторе
  3. Если loopback интерфейсов нет, то берётся самый большой адрес из всех включенных интерфейсов на данном маршрутизаторе. Причём, интерфейс не обязательно должен входить в OSPF процесс, не обязательно его сеть должна быть перечислена при настройке OSPF, достаточно чтобы был настроен адрес и интерфейс был включен.

Здесь под самым большим адресом подразумевается буквальное сравнение по октетам, то есть, например, 10.10.10.20>10.10.10.10, а 2.0.0.1>1.100.100.100, то есть сравниваем по октетам слева направо, как только увидели разницу, то сразу принимаем решение о том, кто больше и дальше не проверяем.

Работа OSPF в сетях со множественным доступом

Одна из проблем подхода OSPF к построению карты сети – использование его в сетях с множественным доступом. Часто используется топология, когда множество маршрутизаторов не подключаются последовательно друг к другу, а соединены через некоторую общую сеть, например, все имеют отдельный интерфейс в некоторой IP-сети для обмена трафиком друг с другом, все подключены один коммутатор, через который обмениваются, или все имеют интерфейс в некотором общем VLAN. В этом случае, OSPF в теории должен устанавливать соседские отношения по принципу «каждый с каждым» в пределах этой общей сети, что приводит к огромным таблицам соседей, повышенной нагрузке на канал, на память и процессор. Ниже приведена таблица, в которой показана зависимость количества соседских отношений от количества маршрутизаторов в одной сети, общая формула для количества отношений имеет вид n(n-1)/2.

Количество маршрутизаторов в сети со множественным доступомКоличество соседских отношений
510
20190
1004950
nn(n-1)/2

Для того чтобы преодолеть эту проблему в OSPF существует механизм выбора Designated Router (DR) и Backup Designated Router (BDR). DR и BDR – это роли маршрутизаторов. Когда имеется сеть со множественным доступом и в ней более двух маршрутизаторов, то один выбирается на роль DR, а второй – на BDR. Каждый маршрутизатор, который хочет отправить, например, LSA, шлёт его не всем в сети, а на специальный мультикастовый адрес, который слушает только DR и BDR, а DR рассылает LSA всем в сети. Таким образом у нас получается не связь «каждый с каждым», а связь «каждый с DR» + «DR с каждым», что позволяет существенно снизить нагрузку в случае, если маршрутизаторов в таком сегменте много. BDR же ничего никому не шлёт – он только слушает то же что и DR и в случае выхода из строя DR-а, BDR мгновенно занимает его место, а среди оставшихся маршрутизаторов проходят выборы нового BDR.

Метрика в OSPF

Сам по себе открытый протокол OSPF не предъявляет никаких требований к тому, как должна считаться метрика и как должно оцениваться «качество маршрута», в стандарте просто говорится, что у каждого линка есть некая стоимость (cost), если маршрут проходит через несколько линков, то их стоимость суммируется. Самым лучшим считается тот маршрут, у которого стоимость меньше остальных. Понятно, что мы имеем дело с той же метрикой, только без внятного механизма его подсчёта. Разные производители могут по разному считать стоимость, поэтому Cisco предусмотрела два варианта вычисления стоимости:

    1. Стоимость считается как обратная величина от скорости линка, например, 1 – для гигабита, 10 – для ста мегабит, 100 – для десяти мегабит, 1000 – для одного мегабита и т.п. Такой вариант хорош, когда мы строим сеть только на оборудовании cisco и знаем, что все маршрутизаторы считают метрику по такому алгоритму. В этом случае стоимость будет считаться автоматически, что существенно упростит настройку.
    2. Стоимость задаётся администратором вручную для каждого линка исходя из своих представлений о качестве этого линка. Такой вариант может применяться в случае, если качество линка не измеряется одной его скоростью. Например, администратор может искуственно завысить метрику для линка, на котором проводится таррификация трафика, или на котором часто возникают ошибки. Это даёт большую гибкость, но требует ручной настройки. Второй случай, когда приходится исползовать этот метод – присутствие в сети маршрутизаторов разных производителей. В этой ситуации надо обеспечить адекватный одинаковые представления о стоимости на всех маршрутизаторах. Надо изучить, как считается стоимость у других производителей, посчитать её так же и задать вручную на маршрутизаторах Cisco.

    При выборе первого способа стоимость считается так: берётся величина в 1 гигабит и делится на скорость интерфейса. Этот подход был придуман в те времена, когда 1 гигабит был максимальной скоростью, которую только можно представить. Если считать метрику таким образом, то стоимость гигабиат будет равна единице, но и стоимость 10 гигабитного канала тоже будет равна единице (так как стоимость – целое положительное число). Для того чтобы изменить то значение, которое делится на скорость линка, есть команда auto-cost reference-bandwidth, после которой указывается скорость в мегабитах. То есть, чтобы 1 Гбит отличался от 10 Гбит по стоимости, надо ввести команду:

    Router(config-router)#auto-cost reference-bandwidth 10000
    % OSPF: Reference bandwidth is changed.
            Please ensure reference bandwidth is consistent across all routers.

    После этого у 10 Гбит будет стоимость 1, у 1 Гб – стоимость 10, у 100 Мб – стоимость 100 и т.д. Важно ввести одинаковое значение на всех маршрутизаторах, чтобы метрика считалась не противоречиво.

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

    После прочтения данной статьи у вас должно быть достаточно информации чтобы перейти к практике: «Настройка OSPF для одной зоны на маршрутизаторах Cisco»

Добавить комментарий