Итак, приступим.

Статей и видео о том, как настроить OSPF горы. Гораздо меньше описаний принципов работы. Вообще, тут такое дело, что OSPF можно просто настроить согласно мануалам, даже не зная про алгоритмы SPF и непонятные LSA. И всё будет работать и даже, скорее всего, прекрасно работать - на то он и рассчитан. То есть тут не как с вланами, где приходилось знать теорию вплоть до формата заголовка.
Но инженера от эникейщика отличает то, что он понимает, почему его сеть функционирует так, а не иначе, и не хуже самогo OSPF знает, какой маршрут будет выбран протоколом.
В рамках статьи, которая уже на этот момент составляет 8 000 символов, мы не сможем погрузиться в глубины теории, но рассмотрим принципиальные моменты.
Очень просто и понятно, кстати, написано про OSPF на xgu.ru или в английской википедии .
Итак, OSPFv2 работает поверх IP, а конкретно, он заточен только под IPv4 (OSPFv3 не зависит от протоколов 3-го уровня и потому может работать с IPv6).

Рассмотрим его работу на примере вот такой упрощённой сети:

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

1) в OSPF должны быть настроены одинаковые Hello Interval на тех маршрутизаторах, что подключены друг к другу. По умолчанию это 10 секунд в Broadcast сетях, типа Ethernet. Это своего рода KeepAlive сообщения. То есть каждые 10 секунд каждый маршрутизатор отправляет Hello пакет своему соседу, чтобы сказать: “Хей, я жив”,
2) Одинаковыми должны быть и Dead Interval на них. Обычно это 4 интервала Hello - 40 секунд. Если в течение этого времени от соседа не получено Hello, то он считается недоступным и начинается ПАНИКА процесс перестроения локальной базы данных и рассылка обновлений всем соседям,
3) Интерфейсы, подключенные друг к другу, должны быть в одной подсети ,
4) OSPF позволяет снизить нагрузку на CPU маршрутизаторов, разделив Автономную Систему на зоны. Так вот номера зон тоже должны совпадать,
5) У каждого маршрутизатора, участвующего в процессе OSPF есть свой уникальный индентификатор - Router ID . Если вы о нём не позаботитесь, то маршрутизатор выберет его автоматически на основе информации о подключенных интерфейсах (выбирается высший адрес из интерфейсов, активных на момент запуска процесса OSPF). Но опять же у хорошего инженера всё под контролем, поэтому обычно создаётся Loopback интерфейс, которому присваивается адрес с маской /32 и именно он назначается Router ID. Это бывает удобно при обслуживании и траблшутинге.
6) Должен совпадать размер MTU

1) Штиль. Состояние OSPF - DOWN
В это короткое мгновение в сети ничего не происходит - все молчат.

2) Поднимается ветер: маршрутизатор рассылает Hello-пакеты на мультикастный адрес 224.0.0.5 со всех интерфейсов, где запущен OSPF. TTL таких сообщений равен одному, поэтому их получат только маршрутизаторы, находящиеся в том же сегменте сети. R1 переходит в состояние INIT .

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

• Router ID
• Hello Interval
• Dead Interval
• Neighbors
• Subnet mask
• Area ID
• Router Priority
• Адреса DR и BDR маршрутизаторов
• Пароль аутентификации

Нас интересуют пока первые четыре или точнее вообще только Router ID и Neighbors.
Сообщение Hello от маршрутизатора R1 несёт в себе его Router ID и не содержит Neighbors, потому что у него их пока нет.
После получения этого мультикастного сообщения маршрутизатор R2 добавляет R1 в свою таблицу соседей (если совпали все необходимые параметры).

И отправляет на R1 уже юникастом новое сообщение Hello, где содержится Router ID этого маршрутизатора, а в списке Neigbors перечислены все его соседи. В числе прочих соседей в этом списке есть Router ID R1, то есть R2 уже считает его соседом.

3) Дружба. Когда R1 получает это сообщение Hello от R2, он пролистывает список соседей и находит в нём свой собственный Router ID, он добавляет R2 в свой список соседей.

Теперь R1 и R2 друг у друга во взаимных соседях - это означает, что между ними установлены отношения смежности и маршрутизатор R1 переходит в состояние TWO WAY .

Общий совет по всем задачам:

Даже если Вы сразу не знаете ответа и решения, постарайтесь подумать к чему относится условие задачи:
- К каким особенностям, настройкам протокола?
- Глобальные эти настройки или привязаны к конкретному интерфейсу?
Если Вы не знаете или забыли команду, такие размышления, скорее всего, приведут Вас к правильному контексту, где Вы просто, с помощью подсказки в командной строке, можете догадаться или вспомнить как настроить то, что требуется в задании.
Постарайтесь поразмышлять в таком ключе прежде чем пойдете в гугл или на какой-то сайт в поиске команд.

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

Прежде чем мы перейдём к тестированию резервных линков и скорости, сделаем ещё одну полезную вещь.
Если бы у нас была возможность отловить трафик на интерфейсе FE0/0.2 msk-arbat-gw1, который смотрит в сторону серверов, то мы бы увидели, что каждые 10 секунд в неизвестность улетают сообщения Hello. Ответить на Hello некому, отношения смежности устанавливать не с кем, поэтому и пытаться рассылать отсюда сообщения смысла нет.
Выключается это очень просто:

msk-arbat-gw1(config)#router OSPF 1
msk-arbat-gw1(config-router)#passive-interface fastEthernet 0/0.2

Такую команду нужно дать для всех интерфейсов, на которых точно нет соседей OSPF (в том числе в сторону интернета).
В итоге картина у вас будет такая:

*Не представляю, как вы до сих пор не запутались*

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

Теперь займёмся самым интересным - тестированием.
Ничего сложного нет в настройке OSPF на всех маршрутизаторах в Сибирском кольце - сделаете сами.
И после этого картина должна быть следующей:

msk-arbat-gw1#sh ip OSPF neighbor

172.16.255.32 1 FULL/DR 00:00:31 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:31 172.16.2.18 FastEthernet0/1.5
172.16.255.80 1 FULL/BDR 00:00:36 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/BDR 00:00:37 172.16.2.197 FastEthernet1/0.911

Питер, Кемерово, Красноярск и Владивосток - непосредственно подключенные.

msk-arbat-gw1#sh ip route

172.16.0.0/16 is variably subnetted, 25 subnets, 6 masks



S 172.16.2.4/30 via 172.16.2.2



O 172.16.2.160/30 via 172.16.2.130, 00:05:53, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:04:18, FastEthernet1/0.911





S 172.16.16.0/21 via 172.16.2.2
S 172.16.24.0/22 via 172.16.2.18
O 172.16.24.0/24 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 00:07:18, FastEthernet0/1.8

O 172.16.255.32/32 via 172.16.2.2, 00:24:03, FastEthernet0/1.4
O 172.16.255.48/32 via 172.16.2.18, 00:24:03, FastEthernet0/1.5
O 172.16.255.80/32 via 172.16.2.130, 00:07:18, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:04:18, FastEthernet0/1.8
via 172.16.2.197, 00:04:18, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:04:28, FastEthernet1/0.911

Все обо всех всё знают.
Каким маршрутом трафик доставляется из Москвы в Красноярск? Из таблицы видно, что krs-stolbi-gw1 подключен напрямую и это же видно из трассировки:

1 172.16.2.130 35 msec 8 msec 5 msec

Теперь рвём интерфейс между Москвой и Красноярском и смотрим, через сколько линк восстановится.
Не проходит и 5 секунд, как все маршрутизаторы узнали о происшествии и пересчитали свои таблицы маршрутизации:

msk-arbat-gw1(config-subif)#do sh ip ro 172.16.128.0

Known via «OSPF 1», distance 110, metric 4, type intra area
Last update from 172.16.2.197 on FastEthernet1/0.911, 00:00:53 ago
Routing Descriptor Blocks:
* 172.16.2.197, from 172.16.255.80, 00:00:53 ago, via FastEthernet1/0.911
Route metric is 4, traffic share count is 1

Vld-gw1#sh ip route 172.16.128.0
Routing entry for 172.16.128.0/24
Known via «OSPF 1», distance 110, metric 3, type intra area
Last update from 172.16.2.193 on FastEthernet1/0, 00:01:57 ago
Routing Descriptor Blocks:
* 172.16.2.193, from 172.16.255.80, 00:01:57 ago, via FastEthernet1/0
Route metric is 3, traffic share count is 1

Msk-arbat-gw1#traceroute 172.16.128.1
Type escape sequence to abort.
Tracing the route to 172.16.128.1

1 172.16.2.197 4 msec 10 msec 10 msec
2 172.16.2.193 8 msec 11 msec 15 msec
3 172.16.2.161 15 msec 13 msec 6 msec

То есть теперь Красноярска трафик достигает таким путём:

Как только вы поднимете линк, маршрутизаторы снова вступают в связь, обмениваются своими базами, пересчитываются кратчайшие пути и заносятся в таблицу маршрутизации.
На видео всё это более наглядно. Рекомендую ознакомиться .

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

EIGRP

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

Итак, чем хорош EIGRP?
- прост в конфигурации
- быстрое переключение на заранее просчитанный запасной маршрут
- требует меньше ресурсов роутера (по сравнению с OSPF)
- суммирование маршрутов на любом роутере (в OSPF только на ABR\ASBR)
- балансировка трафика на неравноценных маршрутах (OSPF только на равноценных)

Мы решили перевести одну из записей блога Ивана Пепельняка, в которой разбирается ряд популярных мифов про EIGRP:
- “EIGRP это гибридный протокол маршрутизации”. Если я правильно помню, это началось с первой презентации EIGRP много лет назад и обычно понимается как «EIGRP взял лучшее от link-state и distance-vector протоколов». Это совершенно не так. У EIGRP нет никаких отличительных особенностей link-state. Правильно будет говорить «EIGRP это продвинутый distance-vector- протокол маршрутизации».

- “EIGRP это distance-vector протокол”. Неплохо, но не до конца верно тоже. EIGRP отличается от других DV способом, которым обрабатывает потерянные маршруты (или маршруты с возрастающей метрикой). Все остальные протоколы пассивно ждут обновления информации от соседа (некоторые, например, RIP, даже блокируют маршрут для предотвращения петель маршрутизации), в то время как EIGRP ведет себя активнее и запрашивает информацию сам.

- “EIGRP сложен во внедрении и обслуживании”. Неправда. В свое время, EIGRP в больших сетях с низкоскоростными линками было сложновато правильно внедрить, но ровно до того момента, как были введены stub routers. С ними (а также несколькими исправлениями работы DUAL-алгоритма), он не чуть не хуже, чем OSPF.

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

- “EIGRP это DV протокол, который действует, как LS”. Неплохая попытка, но по-прежнему, абсолютно неверно. LS протоколы строят таблицу маршрутизации, проходя через следующие шаги:
- каждый маршрутизатор описывает сеть, исходя из информации, доступной ему локально (его линки, подсети, в которых он находится, соседи, которых он видит) посредством пакета (или нескольких), называемого LSA (в OSPF) или LSP (IS-IS)
- LSA распространяются по сети. Каждый маршрутизатор должен получить каждую LSA, созданную в его сети. Информация, полученная из LSA, заносится в таблицу топологии.
- каждый маршрутизатор независимо анализирует свою таблицу топологии и запускает SPF алгоритм для подсчета лучших маршрутов к каждому из других маршрутизаторов
Поведение EIGRP даже близко не напоминает эти шаги, поэтому непонятно, с какой стати он «действует, как LS»

Единственное, что делает EIGRP - это хранит информацию, полученную от соседа (RIP сразу же забывает то, что не может быть использовано в данный момент). В этом смысле, он похож на BGP, который тоже хранит все в таблице BGP и выбирает лучший маршрут оттуда. Таблица топологии (содержащая всю информацию, полученную от соседей), дает EIGRP преимущество перед RIP – она может содержать информацию о запасном (не используемом в данный момент) маршруте.

Теперь чуть ближе к теории работы:

Каждый процесс EIGRP обслуживает 3 таблицы:
- Таблицу соседей (neighbor table), в которой содержится информация о “соседях”, т.е. других маршрутизаторах, непосредственно подключенных к текущему и участвующих в обмене маршрутами. Можно посмотреть с помощью команды show ip eigrp neighbors
- Таблицу топологии сети (topology table), в которой содержится информация о маршрутах, полученная от соседей. Смотрим командой show ip eigrp topology
- Таблицу маршрутизации (routing table), на основе которой роутер принимает решения о перенаправлении пакетов. Просмотр через show ip route

Метрика.
Для оценки качества определенного маршрута, в протоколах маршрутизации используется некое число, отражающее различные его характеристики или совокупность характеристик- метрика. Характеристики, принимаемые в расчет, могут быть разными- начиная от количества роутеров на данном маршруте и заканчивая средним арифметическим загрузки всех интерфейсов по ходу маршрута. Что касается метрики EIGRP, процитируем Jeremy Cioara: “у меня создалось впечатление, что создатели EIGRP, окинув критическим взглядом свое творение, решили, что все слишком просто и хорошо работает. И тогда они придумали формулу метрики, что бы все сказали “ВАУ, это действительно сложно и профессионально выглядит”. Узрите же полную формулу подсчета метрики EIGRP: (K1 * bw + (K2 * bw) / (256 - load) + K3 * delay) * (K5 / (reliability + K4)), в которой:
- bw это не просто пропускная способность, а (10000000/самая маленькая пропускная способность по дороге маршрута в килобитах) * 256
- delay это не просто задержка, а сумма всех задержек по дороге в десятках микросекунд * 256 (delay в командах show interface, show ip eigrp topology и прочих показывается в микросекундах!)
- K1-K5 это коэффициенты, которые служат для того, чтобы в формулу “включился” тот или иной параметр.

Страшно? было бы, если бы все это работало, как написано. На деле же из всех 4 возможных слагаемых формулы, по умолчанию используются только два: bw и delay (коэффициенты K1 и K3=1, остальные нулю), что сильно ее упрощает - мы просто складываем эти два числа (не забывая при этом, что они все равно считаются по своим формулам). Важно помнить следующее: метрика считается по худшему показателю пропускной способности по всей длине маршрута .

Интересная штука получилась с MTU: довольно часто можно встретить сведения о том, что MTU имеет отношение к метрике EIGRP. И действительно, значения MTU передаются при обмене маршрутами. Но, как мы можем видеть из полной формулы, никакого упоминания об MTU там нет. Дело в том, что этот показатель принимается в расчет в довольно специфических случаях: например, если роутер должен отбросить один из равнозначных по остальным характеристикам маршрутов, он выберет тот, у которого меньший MTU. Хотя, не все так просто (см. комментарии).

Определимся с терминами, применяемыми внутри EIGRP. Каждый маршрут в EIGRP характеризуется двумя числами: Feasible Distance и Advertised Distance (вместо Advertised Distance иногда можно встретить Reported Distance, это одно и то же). Каждое из этих чисел представляет собой метрику, или стоимость (чем больше-тем хуже) данного маршрута с разных точек измерения: FD это “от меня до места назначения”, а AD- “от соседа, который мне рассказал об этом маршруте, до места назначения”. Ответ на закономерный вопрос “Зачем нам надо знать стоимость от соседа, если она и так включена в FD?”- чуть ниже (пока можете остановиться и поломать голову сами, если хотите).

У каждой подсети, о которой знает EIGRP, на каждом роутере существует Successor- роутер из числа соседей, через который идет лучший (с меньшей метрикой), по мнению протокола, маршрут к этой подсети. Кроме того, у подсети может также существовать один или несколько запасных маршрутов (роутер-сосед, через которого идет такой маршрут, называется Feasible Successor). EIGRP- единственный протокол маршрутизации, запоминающий запасные маршруты (в OSPF они есть, но содержатся, так сказать, в “сыром виде” в таблице топологии- их еще надо обработать алгоритмом SPF), что дает ему плюс в быстродействии: как только протокол определяет, что основной маршрут (через successor) недоступен, он сразу переключается на запасной. Для того, чтобы роутер мог стать feasible successor для маршрута, его AD должно быть меньше FD successor’а этого маршрута (вот зачем нам нужно знать AD). Это правило применяется для того, чтобы избежать колец маршрутизации.

Предыдущий абзац взорвал мозг? Материал трудный, поэтому еще раз на примере. У нас есть вот такая сеть:

С точки зрения R1, R2 является Successor’ом для подсети 192.168.2.0/24. Чтобы стать FS для этой подсети, R4 требуется, чтобы его AD была меньше FD для этого маршрута. FD у нас ((10000000/1544)*256)+(2100*256) =2195456, AD у R4 (с его точки зрения это FD, т.е. сколько ему стоит добраться до этой сети) = ((10000000/100000)*256)+(100*256)=51200. Все сходится, AD у R4 меньше, чем FD маршрута, он становится FS. *тут мозг такой и говорит: “БДЫЩЬ”*. Теперь смотрим на R3- он анонсирует свою сеть 192.168.1.0/24 соседу R1, который, в свою очередь, рассказывает о ней своим соседям R2 и R4. R4 не в курсе, что R2 знает об этой подсети, и решает ему рассказать. R2 передает информацию о том, что он имеет доступ через R4 к подсети 192.168.1.0/24 дальше, на R1. R1 строго смотрит на FD маршрута и AD, которой хвастается R2 (которая, как легко понять по схеме, будет явно больше FD, так как включает и его тоже) и прогоняет его, чтобы не лез со всякими глупостями. Такая ситуация довольно маловероятна, но может иметь место при определенном стечении обстоятельств, например, при отключении механизма “расщепления горизонта” (split-horizon). А теперь к более вероятной ситуации: представим, что R4 подключен к сети 192.168.2.0/24 не через FastEthernet, а через модем на 56k (задержка для dialup составляет 20000 usec), соответственно, добраться ему стоит ((10000000/56)*256)+(2000*256)= 46226176. Это больше, чем FD для этого маршрута, поэтому R4 не станет Feasible Successor’ом. Но это не значит, что EIGRP вообще не будет использовать данный маршрут. Просто переключение на него займет больше времени (подробнее об этом дальше).

соседство

Роутеры не разговаривают о маршрутах с кем попало - прежде чем начать обмениваться информацией, они должны установить отношения соседства. После включения процесса командой router eigrp с указанием номера автономной системы, мы, командой network говорим, какие интерфейсы будут участвовать и одновременно, информацию о каких сетях мы желаем распространять. Незамедлительно, через эти интерфейсы начинают рассылаться hello-пакеты на мультикаст- адрес 224.0.0.10 (по умолчанию каждые 5 секунд для ethernet). Все маршрутизаторы с включенным EIGRP получают эти пакеты, далее каждый маршрутизатор-получатель делает следующее:
- сверяет адрес отправителя hello-пакета, с адресом интерфейса, из которого получен пакет, и удостоверяется, что они из одной подсети
- сверяет значения полученных из пакета K-коэффициентов (проще говоря, какие переменные используются в подсчете метрики) со своими. Понятно, что если они различаются, то метрики для маршрутов будут считаться по разным правилам, что недопустимо
- проверяет номер автономной системы
- опционально: если настроена аутентификация, проверяет соответствие ее типа и ключей.

Если получателя все устраивает, он добавляет отправителя в список своих соседей, и посылает ему (уже юникастом) update-пакет, в котором содержится список всех известных ему маршрутов (aka full-update). Отправитель, получив такой пакет, в свою очередь, делает то же самое. Для обмена маршрутами EIGRP использует Reliable Transport Protocol (RTP, не путать с Real-time Transport Protocol, который используется в ip-телефонии), который подразумевает подтверждение о доставке, поэтому каждый из роутеров, получив update- пакет, отвечает ack -пакетом (сокращение от acknowledgement- подтверждение). Итак, отношение соседства установлены, роутеры узнали друг у друга исчерпывающую информацию о маршрутах, что дальше? Дальше они будут продолжать посылать мультикаст hello-пакеты в подтверждение того, что они на связи, а в случае изменения топологии- update-пакеты, содержащие сведения только об изменениях (partial update).

Теперь вернемся к предыдущей схеме с модемом.

R2 по каким-то причинам потерял связь с 192.168.2.0/24. До этой подсети у него нет запасных маршрутов (т.е. отсутствует FS). Как всякий ответственный роутер с EIGRP, он хочет восстановить связь. Для этого он начинает рассылать специальные сообщения (query- пакеты) всем своим соседям, которые, в свою очередь, не находя нужного маршрута у себя, расспрашивают всех своих соседей, и так далее. Когда волна запросов докатывается до R4, он говорит “погодите-ка, у меня есть маршрут к этой подсети! Плохонький, но хоть что-то. Все про него забыли, а я-то помню”. Все это он упаковывает в reply-пакет и отправляет соседу, от которого получил запрос (query), и дальше по цепочке. Понятное дело, это все занимает больше времени, чем просто переключение на Feasible Successor, но, в итоге, мы получаем связь с подсетью.

А сейчас опасный момент: может, вы уже обратили внимание и насторожились, прочитав момент про эту веерную рассылку. Падение одного интерфейса вызывает нечто похожее на широковещательный шторм в сети (не в таких масштабах, конечно, но все-таки), причем чем больше в ней роутеров, тем больше ресурсов потратится на все эти запросы-ответы. Но это еще пол-беды. Возможна ситуация и похуже: представим, что роутеры, изображенные на картинке- это только часть большой и распределенной сети, т.е. некоторые могут находится за много тысяч километров от нашего R2, на плохих каналах и прочее. Так вот, беда в том, что, послав query соседу, роутер обязан дождаться от него reply. Неважно, что в ответе- но он должен прийти. Даже если роутер уже получил положительный ответ, как в нашем случае, он не может поставить этот маршрут в работу, пока не дождется ответа на все свои запросы. А запросы-то, может, еще где-нибудь на Аляске бродят. Такое состояние маршрута называется stuck-in-active. Тут нам нужно познакомится с терминами, отражающими состояние маршрута в EIGRP: active\passive route. Обычно они вводят в заблуждение. Здравый смысл подсказывает, что active значит маршрут “активен”, включен, работает. Однако тут все наоборот: passive это “все хорошо”, а состояние active означает, что данная подсеть недоступна, и маршрутизатор находится в активном поиске другого маршрута, рассылая query и ожидая reply. Так вот, состояние stuck-in-active (застрял в активном состоянии) может продолжатся до 3 минут! По истечение этого срока, роутер обрывает отношения соседства с тем соседом, от которого он не может дождаться ответа, и может использовать новый маршрут через R4.

История, леденящая кровь сетевого инженера. 3 минуты даунтайма это не шутки. Как мы можем избежать инфаркта этой ситуации? Выхода два: суммирование маршрутов и так называемая stub-конфигурация.

Вообще говоря, есть еще один выход, и он называется фильтрация маршрутов (route filtering). Но это настолько объемная тема, что впроу отдельную статью под нее писать, а у нас и так уже пол-книги получилось в этот раз. Поэтому на ваше усмотрение.

Как мы уже упоминали, в EIGRP суммирование маршрутов можно проводить на любом роутере. Для иллюстрации, представим, что к нашему многострадальному R2 подключены подсети от 192.168.0.0/24 до 192.168.7.0/24, что очень удобненько суммируется в 192.168.0.0/21 (вспоминаем binary math). Роутер анонсирует этот суммарный маршрут, и все остальные знают: если адрес назначения начинается на 192.168.0-7, то это к нему. Что будет происходить, если одна из подсетей пропадет? Роутер будет рассылать query-пакеты с адресом этой сети (конкретным, например, 192.168.5.0/24), но соседи, вместо того, чтобы уже от своего имени продолжить порочную рассылку, будут сразу в ответ слать отрезвляющие реплаи, мол, это твоя подсеть, ты и разбирайся.

Второй вариант- stub- конфигурация. Образно говоря, stub означает “конец пути”, “тупик” в EIGRP, т.е., чтобы попасть в какую-то подсеть, не подключенную напрямую к такому роутеру, придется идти назад. Роутер, сконфигурированный, как stub, не будет пересылать трафик между подсетями, которые ему стали известны от EIGRP (проще говоря, которые в show ip route помечены буквой D). Кроме того, его соседи не будут отправлять ему query-пакеты. Самый распространенный случай применения- hub-and-spoke топологии, особенно с избыточными линками. Возьмем такую сеть: слева- филиалы, справа- основной сайт, главный офис и т.п. Для отказоустойчивости избыточные линки. Запущен EIGRP с дефолтными настройками.

А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. Будет страдать не только подсеть за R1, но и подсеть за R2 (или R3), из-за увеличения объемов трафика и его последствий. Вот для таких-то ситуаций и придуман stub. За роутерами в филиалах нет других роутеров, которые вели бы в другие подсети, это “конец дороги”, дальше только назад. Поэтому мы с легким сердцем можем сконфигурировать их как stub’ы, что, во-первых, избавит нас от проблемы с “кривым маршрутом”, изложенной чуть выше, а во-вторых, от флуда query-пакетов в случае потери маршрута.

Существуют различные режимы работы stub-роутера, задаются они командой eigrp stub:

R1(config)#router eigrp 1
R1(config-router)#eigrp stub?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set IP-EIGRP as receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes

По умолчанию, если просто дать команду eigrp stub, включаются режимы сonnected и summary. Интерес представляет режим receive-only, в котором роутер не анонсирует никаких сетей, только слушает, что ему говорят соседи (в RIP есть команда passive interface, которая делает то же самое, но в EIGRP она полностью отключает протокол на выбранном интерфейсе, что не позволяет установить соседство).

Важные моменты в теории EIGRP, не попавшие в статью:

• В EIGRP можно настроить аутентификацию соседей
• Концепция graceful shutdown

Практика EIGRP

“Лифт ми Ап” купили фабрику в Калининграде. Там производят мозги лифтов: микросхемы, ПО. Фабрика очень крупная - три точки по городу - три маршрутизатора соединены в кольцо.

Но вот незадача - на них уже запущен EIGRP в качестве протокола динамической маршрутизации. Причём адресация конечных узлов совсем из другой подсети - 10.0.0.0/8. Все другие параметры (линковые адреса, адреса лупбэк интерфейсов) мы поменяли, но несколько тысяч адресов локальной сети с серверами, принтерами, точками доступа - работа не на пару часов - отложили на потом, а в IP-плане зарезервировали на будущее для Калининграда подсеть 172.16.32.0/20.

Сейчас у нас используются такие сети:

Как настраивается это чудо? Незамысловато, на первый взгляд:

router eigrp 1
network 172.16.0.0 0.0.255.255
network 10.0.0.0

В EIGRP обратную маску можно задавать, указывая тем самым более узкие рамки, либо не задавать, тогда будет выбрана стандартная маска для этого класса (16 для класса B - 172.16.0.0 и 8 для класса 8 - 10.0.0.0)

Такие команды даются на всех маршрутизаторах Автономной Системы. АС определяется цифрой в команде router eigrp, то есть в нашем случае имеем АС №1. Эта цифра должна быть одинаковой на всех маршрутизаторах (в отличии от OSPF).

Но есть в EIGRP серьёзный подвох: по умолчанию включено автоматическое суммирование маршрутов в классовом виде (в версиях IOS до 15).
Сравним таблицы маршрутизации на трёх калининградских маршрутизаторах:

Сеть 10.0.0.1/24 подключена у нас к klgr-center-gw1 и он о ней знает:

klgr-center-gw1:
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:35:23, Null0
C 10.0.0.0/24 is directly connected, FastEthernet1/0

Но не знает о 10.0.1.0/24 и 10.0.2.0/24/

Klgr-balt-gw1 знает о своих двух сетях 10.0.1.0/24 и 10.0.2.0/24, но вот сеть 10.0.0.0/24 он куда-то спрятал.

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
D 10.0.0.0/8 is a summary, 00:42:05, Null0
C 10.0.1.0/24 is directly connected, FastEthernet1/1.2
C 10.0.2.0/24 is directly connected, FastEthernet1/1.3

Они оба создали маршрут 10.0.0.0/8 с адресом next hop Null0.

А вот klgr-center-gw2 знает, что подсети 10.0.0.0/8 находятся за обоими его WAN интерфейсами.

D 10.0.0.0/8 via 172.16.2.41, 00:42:49, FastEthernet0/1
via 172.16.2.45, 00:38:05, FastEthernet0/0

Что-то очень странное творится.
Но, если вы проверите конфигурацию этого маршрутизатора, то, вероятно, заметите:

router eigrp 1
network 172.16.0.0
network 10.0.0.0
auto-summary

Во всём виновато автоматическое суммирование. Это самое большое зло EIGRP. Рассмотрим более подробно, что происходит. klgr-center-gw1 и klgr-balt-gw1 имеют подсети из 10.0.0.0/8, они их суммируют по умолчанию, когда передают соседям.
То есть, например, msk-balt-gw1 передаёт не две сети 10.0.1.0/24 и 10.0.2.0/24, а одну обобщённую: 10.0.0.0/8. То есть его сосед будет думать, что за msk-balt-gw1 находится вся эта сеть.
Но, что произойдёт, если вдруг на balt-gw1 попадёт пакет с адресатом 10.0.50.243, о котором тот ничего не знает? На этот случай и создаётся так называетмый Blackhole-маршрут:
10.0.0.0/8 is a summary, 00:42:05, Null0
Полученный пакет будет выброшен в эту чёрную дыру. Это делается во избежание петель маршрутизации.
Так вот оба эти маршрутизатора создали свои blackhole-маршруты и игнорируют чужие анонсы. Реально на такой сети эти три девайса друг друга так и не смогут пинговать, пока… пока вы не отключите auto-summary.

Первое, что вы должны сделать при настройке EIGRP:

router eigrp 1
no auto-summary

На всех устройствах. И всем будет хорошо:

Klgr-center-gw1:

C 10.0.0.0 is directly connected, FastEthernet1/0
D 10.0.1.0 via 172.16.2.37, 00:03:11, FastEthernet0/0
D 10.0.2.0 via 172.16.2.37, 00:03:11, FastEthernet0/0

klgr-balt-gw1

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.38, 00:08:16, FastEthernet0/1
C 10.0.1.0 is directly connected, FastEthernet1/1.2
C 10.0.2.0 is directly connected, FastEthernet1/1.3

klgr-center-gw2:

10.0.0.0/24 is subnetted, 3 subnets
D 10.0.0.0 via 172.16.2.45, 00:11:50, FastEthernet0/0
D 10.0.1.0 via 172.16.2.41, 00:11:48, FastEthernet0/1
D 10.0.2.0 via 172.16.2.41, 00:11:48, FastEthernet0/1

Настройка передачи маршрутов между различными протоколами

Наша задача организовать передачу маршрутов между этими протоколами: из OSPF в EIGRP и наоборот, чтобы все знали маршрут до любой подсети.
Это называется редистрибуцией (перераспределением) маршрутов.

Для её осуществления нам нужна хотя бы одна точка стыка, где будут запущены одновременно два протокола. Это может быть msk-arbat-gw1 или klgr-balt-gw1. Выберем второй.

Из EIGRP в OSPF:

klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Смотрим маршруты на msk-arbat-gw1:

msk-arbat-gw1#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is 198.51.100.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O E2 10.0.0.0/8 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.1.0/24 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
O E2 10.0.2.0/24 via 172.16.2.34, 00:24:50, FastEthernet0/1.7
172.16.0.0/16 is variably subnetted, 30 subnets, 5 masks
O E2 172.16.0.0/16 via 172.16.2.34, 00:25:11, FastEthernet0/1.7
C 172.16.0.0/24 is directly connected, FastEthernet0/0.3
C 172.16.1.0/24 is directly connected, FastEthernet0/0.2
C 172.16.2.0/30 is directly connected, FastEthernet0/1.4
C 172.16.2.16/30 is directly connected, FastEthernet0/1.5
C 172.16.2.32/30 is directly connected, FastEthernet0/1.7
O E2 172.16.2.36/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.40/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.2.44/30 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
C 172.16.2.128/30 is directly connected, FastEthernet0/1.8
O 172.16.2.160/30 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.2.192/30 via 172.16.2.197, 00:13:21, FastEthernet1/0.911
C 172.16.2.196/30 is directly connected, FastEthernet1/0.911
C 172.16.3.0/24 is directly connected, FastEthernet0/0.101
C 172.16.4.0/24 is directly connected, FastEthernet0/0.102
C 172.16.5.0/24 is directly connected, FastEthernet0/0.103
C 172.16.6.0/24 is directly connected, FastEthernet0/0.104
O 172.16.24.0/24 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O 172.16.128.0/24 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.129.0/26 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.144.0/24 via 172.16.2.130, 00:13:21, FastEthernet0/1.8

O 172.16.160.0/24 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
C 172.16.255.1/32 is directly connected, Loopback0
O 172.16.255.48/32 via 172.16.2.18, 01:00:55, FastEthernet0/1.5
O E2 172.16.255.64/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.65/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O E2 172.16.255.66/32 via 172.16.2.34, 01:00:55, FastEthernet0/1.7
O 172.16.255.80/32 via 172.16.2.130, 01:00:55, FastEthernet0/1.8
O 172.16.255.96/32 via 172.16.2.130, 00:13:21, FastEthernet0/1.8
via 172.16.2.197, 00:13:21, FastEthernet1/0.911
O 172.16.255.112/32 via 172.16.2.197, 00:13:31, FastEthernet1/0.911
198.51.100.0/28 is subnetted, 1 subnets
C 198.51.100.0 is directly connected, FastEthernet0/1.6
S* 0.0.0.0/0 via 198.51.100.1

Вот те, что с меткой Е2 - новые импортированные маршруты. Е2 - означает, что это внешние маршруты 2-го типа (External), то есть они были введены в процесс OSPF извне

Теперь из OSPF в EIGRP. Это чуточку сложнее:

klgr-gw1(config)#router eigrp 1
klgr-gw1(config-router)#redistribute ospf 1 metric 100000 20 255 1 1500

Без указания метрики (вот этого длинного набора цифр) команда выполнится, но редистрибуции не произойдёт.

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

klgr-gw2#sh ip route

Gateway of last resort is not set

172.16.0.0/16 is variably subnetted, 30 subnets, 4 masks
D EX 172.16.0.0/24 [170 /33280] via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.1.0/24 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.0/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.4/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D EX 172.16.2.16/30 via 172.16.2.37, 00:00:07, FastEthernet0/0
D 172.16.2.32/30 [90 /30720] via 172.16.2.37, 00:38:59, FastEthernet0/0
C 172.16.2.36/30 is directly connected, FastEthernet0/0
D 172.16.2.40/30 via 172.16.2.37, 00:38:59, FastEthernet0/0
via 172.16.2.46, 00:38:59, FastEthernet0/1
….

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

Маршрут по умолчанию

Теперь самое время проверить доступ в интернет. Из Москвы он прекрасно себе работает, а вот если проверить, например из Петербурга (помним, что мы удалили все статические маршруты):

PC>ping linkmeup.ru

Pinging 192.0.2.2 with 32 bytes of data:

Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.
Reply from 172.16.2.5: Destination host unreachable.

Ping statistics for 192.0.2.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Это связано с тем, что ни spb-ozerki-gw1, ни spb-vsl-gw1, ни кто-либо другой в нашей сети не знает о маршруте по умолчанию, кроме msk-arbat-gw1, на котором он настроен статически.
Чтобы исправить эту ситуацию, нам достаточно дать одну команду в Москве:

msk-arbat-gw1(config)#router ospf 1
msk-arbat-gw1(config-router)#default-information originate

После этого по сети лавинно распространяется информация о том, где находится шлюз последней надежды.

Интернет теперь доступен:

PC>tracert linkmeup.ru

Tracing route to 192.0.2.2 over a maximum of 30 hops:

1 3 ms 3 ms 3 ms 172.16.17.1
2 4 ms 5 ms 12 ms 172.16.2.5
3 14 ms 20 ms 9 ms 172.16.2.1
4 17 ms 17 ms 19 ms 198.51.100.1
5 22 ms 23 ms 19 ms 192.0.2.2

Полезные команды для траблшутинга

1) Список соседей и состояние связи с ними вызывается командой show ip ospf neighbor

msk-arbat-gw1:

Neighbor ID Pri State Dead Time Address Interface
172.16.255.32 1 FULL/DROTHER 00:00:33 172.16.2.2 FastEthernet0/1.4
172.16.255.48 1 FULL/DR 00:00:34 172.16.2.18 FastEthernet0/1.5
172.16.255.64 1 FULL/DR 00:00:33 172.16.2.34 FastEthernet0/1.7
172.16.255.80 1 FULL/DR 00:00:33 172.16.2.130 FastEthernet0/1.8
172.16.255.112 1 FULL/DR 00:00:33 172.16.2.197 FastEthernet1/0.911

2) Или для EIGRP: show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.2.38 Fa0/1 12 00:04:51 40 1000 0 54
1 172.16.2.42 Fa0/0 13 00:04:51 40 1000 0 58

3) С помощью команды show ip protocols можно посмотреть информацию о запущенных протоколах динамической маршрутизации и их взаимосвязи.

Klgr-balt-gw1:

Routing Protocol is «EIGRP 1 »

Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: EIGRP 1, OSPF 1
Automatic network summarization is in effect
Automatic address summarization:
Maximum path: 4
Routing for Networks:
172.16.0.0

172.16.2.42 90 4
172.16.2.38 90 4
Distance: internal 90 external 170

Routing Protocol is «OSPF 1»
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 172.16.255.64
It is an autonomous system boundary router
Redistributing External Routes from,
EIGRP 1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
172.16.2.32 0.0.0.3 area 0
Routing Information Sources:
Gateway Distance Last Update
172.16.255.64 110 00:00:23
Distance: (default is 110)

4) Для отладки и понимания работы протоколов будет полезно воспользоваться следующими командами:
debug ip OSPF events
debug ip OSPF adj
debug EIGRP packets

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

Задача №7
На последок комплесная задачка.
На последнем совещании Лифт ми Ап было решено, что сеть Калининграда необходимо также переводить на OSPF.
Переход должен быть совершен без разрывов связи. Было решено, что лучшим вариантом будет параллельно с EIGRP поднять OSPF на трёх маршрутизаторах Калининграда и после того, как будет проверено, что вся информация о маршрутах Калининграда распространилась по остальной сети и наоборот, отключить EIGRP. за логотип сайта. Добавить метки

Наиболее распространенными устройствами межсетевого взаимодействия сетей, подсетей и устройств являются маршрутизаторы . Они представляют собой специализированные компьютеры для выполнения специфических функций сетевых устройств. В лекции 4 было показано, что маршрутизаторы используются, чтобы сегментировать локальную сеть на широковещательные домены, т. е. являются устройствами LAN , но они применяются и как устройства формирования глобальных сетей. Поэтому маршрутизаторы имеют как LAN -, так и WAN -интерфейсы. Маршрутизаторы используют WAN -интерфейсы, чтобы связываться друг с другом, и LAN -интерфейсы – для связи с узлами (компьютерами), например через коммутаторы. Поэтому маршрутизаторы являются устройствами как локальных, так и глобальных сетей . Маршрутизаторы являются также основными устройствами больших корпоративных сетей .

Рис. 6.3.

Главными функциями маршрутизаторов являются:

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

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

Протоколы канального ( data link ) уровня WAN описывают, как по сети передаются кадры. Они включают протоколы, обеспечивающие функционирование через выделенные соединения " точка-точка " и через коммутируемые соединения. Основными WAN протоколами и стандартами канального уровня являются: High-level Data Link Control ( HDLC ), Point-to-Point Protocol ( PPP ), Synchronous Data Link Control ( SDLC ), Serial Line Internet Protocol ( SLIP ), X.25, Frame Relay , ATM . Основными протоколами и стандартами физического уровня являются: EIA / TIA -232, EIA / TIA -449, V.24, V.35, X.21, G.703, EIA-530 , ISDN , E1, E3, XDSL , SDH ( STM -1, STM -4 и др.).

Функционируя на Уровне 3 модели OSI , маршрутизаторы принимают решения, базируясь на сетевых логических адресах (IP-адресах). Для определения наилучшего пути передачи данных через связываемые сети маршрутизаторы строят таблицы маршрутизации и обмениваются сетевой маршрутной информацией с другими маршрутизаторами. Администратор может конфигурировать статические маршруты и поддерживать таблицы маршрутизации вручную. Однако большинство таблиц маршрутизации создается и поддерживается динамически, за счет использования протоколов маршрутизации ( routing protocol ), которые позволяют маршрутизаторам автоматически обмениваться информацией о сетевой топологии друг с другом.

Функционирование маршрутизаторов происходит под управлением сетевой операционной системы (Internetwork Operation System – IOS ), текущая (running ) версия которой находится в оперативной памяти RAM ( рис. 6.4). Помимо текущей версии IOS оперативная память хранит активный конфигурационный файл ( Active Configuration File ) и таблицы протоколов динамической маршрутизации , выполняет буферизацию пакетов и поддерживает их очередь , обеспечивает временную память для конфигурационного файла маршрутизатора, пока включено питание.

операционной системы IOS в оперативную память обычно производится из энергонезависимой флэш-памяти (Flash ), которая является перепрограммируемым запоминающим устройством (ППЗУ ). После модернизации IOS она перезаписывается во флэш-память , где может храниться несколько версий. Версию операционной системы можно также сохранять на TFTP -сервере ( рис. 6.4).

Постоянное запоминающее устройство ( ПЗУ – ROM ) содержит программу начальной загрузки ( bootstrap ) и сокращенную версию операционной системы, установленную при изготовлении маршрутизатора. Обычно эта версия IOS используется только при выходе из строя флэш-памяти. Память ROM также поддерживает команды для теста диагностики аппаратных средств (Power-On Self Test – POST ).

Рис. 6.4.

Энергонезависимая (non- volatile ) оперативная память NVRAM маршрутизатора является перепрограммируемым запоминающим устройством (ППЗУ). NVRAM хранит стартовый (startup ) конфигурационный файл , который после изменения конфигурации перезаписывается в ППЗУ, где создается резервная копия (backup ). Конфигурационные файлы содержат команды и параметры для управления потоком трафика, проходящим через маршрутизатор . Конфигурационный файл используется для выбора сетевых протоколов и протоколов маршрутизации , которые определяют наилучший путь для пакетов к адресуемой сети. Первоначально конфигурационный файл обычно создается с консольной линии (console) и помимо памяти NVRAM может сохраняться на TFTP -сервере ( рис. 6.4). Временное хранение входящих и исходящих пакетов обеспечивается в памяти интерфейсов, которые могут быть выполнены на материнской плате или в виде отдельных модулей.

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

6.2. Принципы маршрутизации

Информационный поток данных, созданный на прикладном уровне, на транспортном уровне "нарезается" на сегменты , которые на сетевом уровне снабжаются заголовками и образуют пакеты (см. рис. 1.7 , рис. 1.8). Заголовок пакета содержит сетевые IP-адреса узла назначения и узла источника. На основе этой информации средства сетевого уровня – маршрутизаторы осуществляют передачу пакетов между конечными узлами составной сети по определенному маршруту.

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

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

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

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

Процесс ретрансляции пакетов маршрутизаторами рассмотрен на примере сети, приведенной на рис. 6.5 . Маршрутизаторы в целом

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

Для автоматического построения таблиц маршрутизации маршрутизаторы обмениваются информацией о топологии составной сети в соответствии со специальным служебным протоколом. Протоколы этого типа называются протоколами маршрутизации (или маршрутизирующими протоколами). Протоколы маршрутизации (например, RIP, OSPF, NLSP) следует отличать от собственно сетевых протоколов (например, IP, IPX). И те и другие выполняют функции сетевого уровня модели OSI - участвуют в доставке пакетов адресату через разнородную составную сеть. Но в то время как первые собирают и передают по сети чисто служебную информацию, вторые предназначены для передачи пользовательских данных, как это делают протоколы канального уровня. Протоколы маршрутизации используют сетевые протоколы как транспортное средство. При обмене маршрутной информацией пакеты протокола маршрутизации помещаются в поле данных пакетов сетевого уровня или даже транспортного уровня, поэтому с точки зрения вложенности пакетов протоколы маршрутизации формально следовало бы отнести к более высокому уровню, чем сетевой.

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

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

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

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

Существует и прямо противоположный, многошаговый подход - маршрутизация от источника (Source Routing). В соответствии с ним узел-источник задает в отправляемом в сеть пакете полный маршрут его следования через все промежуточные маршрутизаторы. При использовании многошаговой маршрутизации нет необходимости строить и анализировать таблицы маршрутизации. Это ускоряет прохождение пакета по сети, разгружает маршрутизаторы, но при этом большая нагрузка ложится на конечные узлы. Эта схема в вычислительных сетях применяется сегодня гораздо реже, чем схема распределенной одношаговой маршрутизации. Однако в новой версии протокола IP наряду с классической одношаговой маршрутизацией будет разрешена и маршрутизация от источника.

Одношаговые алгоритмы в зависимости от способа формирования таблиц маршрутизации делятся на три класса:

алгоритмы фиксированной (или статической) маршрутизации;

алгоритмы простой маршрутизации;

алгоритмы адаптивной (или динамической) маршрутизации.

В алгоритмах фиксированной маршрутизации все записи в таблице маршрутизации являются статическими. Администратор сети сам решает, на какие маршрутизаторы надо передавать пакеты с теми или иными адресами, и вручную (например, с помощью утилиты route ОС Unix или Windows NT) заносит соответствующие записи в таблицу маршрутизации. Таблица, как правило, создается в процессе загрузки, в дальнейшем она используется без изменений до тех пор, пока ее содержимое не будет отредактировано вручную. Такие исправления могут понадобиться, например, если в сети отказывает какой-либо маршрутизатор и его функции возлагаются на другой маршрутизатор. Различают одномаршрутные таблицы, в которых для каждого адресата задан один путь, и многомаршрутные таблицы, определяющие несколько альтернативных путей для каждого адресата. В многомаршрутных таблицах должно быть задано правило выбора одного из маршрутов. Чаще всего один путь является основным, а остальные - резервными. Понятно, что алгоритм фиксированной маршрутизации с его ручным способом формирования таблиц маршрутизации приемлем только в небольших сетях с простой топологией. Однако этот алгоритм может быть эффективно использован и для работы на магистралях крупных сетей, так как сама магистраль может иметь простую структуру с очевидными наилучшими путями следования пакетов в подсети, присоединенные к магистрали.

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

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

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

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

Самыми распространенными являются алгоритмы адаптивной (или динамической) маршрутизации. Эти алгоритмы обеспечивают автоматическое обновление таблиц маршрутизации после изменения конфигурации сети. Протоколы, построенные на основе адаптивных алгоритмов, позволяют всем маршрутизаторам собирать информацию о топологии связей в сети, оперативно отрабатывая все изменения конфигурации связей. В таблицах маршрутизации при адаптивной маршрутизации обычно имеется информация об интервале времени, в течение которого данный маршрут будет оставаться действительным. Это время называют временем жизни маршрута (Time To Live, TTL) .

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

ПРИМЕЧАНИЕ В последнее время наметилась тенденция использовать так называемые серверы маршрутов. Сервер маршрутов собирает маршрутную информацию, а затем раздает ее по запросам маршрутизаторам, которые освобождаются в этом случае от функции создания таблиц маршрутизации, либо создают только части этих таблиц. Появились специальные протоколы взаимодействия маршрутизаторов с серверами маршрутов, например Next Hop Resolution Protocol (NHRP).

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

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

дистанционно-векторные алгоритмы (Distance Vector Algorithms, DVA);

алгоритмы состояния связей (Link State Algorithms, LSA).

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

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

Наиболее распространенным протоколом, основанным на дистанционно-векторном алгоритме, является протокол RIP, который распространен в двух версиях - RIP IP, работающий с протоколом IP, и RIP IPX, работающий с протоколом IPX.

Алгоритмы состояния связей обеспечивают каждый маршрутизатор информацией, достаточной для построения точного графа связей сети. Все маршрутизаторы работают на основании одинаковых графов, что делает процесс маршрутизации более устойчивым к изменениям конфигурации. «Широковещательная» рассылка (то есть передача пакета всем непосредственным соседям маршрутизатора) используется здесь только при изменениях состояния связей, что происходит в надежных сетях не так часто. Вершинами графа являются как маршрутизаторы, так и объединяемые ими сети. Распространяемая по сети информация состоит из описания связей различных типов: маршрутизатор - маршрутизатор, маршрутизатор - сеть,

Чтобы понять, в каком состоянии находятся линии связи, подключенные к его портам, маршрутизатор периодически обменивается короткими пакетами HELLO со своими ближайшими соседями. Этот служебный трафик также засоряет сеть, но не в такой степени как, например, RIP-пакеты, так как пакеты HELLO имеют намного меньший объем.

Протоколами, основанными на алгоритме состояния связей, являются протоколы IS-IS (Intermediate System to Intermediate System) стека OSI, OSPF (Open Shortest Path First) стека TCP/IP и недавно реализованный протокол NLSP стека Novell.

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

Крупные объединенные компьютерные сети состоят из множества физических сетей, которые связываются между собой с помощью маршрутизаторов. Автономной системой AS (Autonomous Systems) называют группу сетей и маршрутизаторов R, объединенных общей политикой маршрутизации.

Рисунок 4.8

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

Для определения маршрута внутри AS применяют внутренние протоколы маршрутизации IGP (Interior GatewayProtocols). Наиболее распространенными протоколами внутренней маршрутизации являются протоколы RIP (Routing Information Protocol), OSPF (Open Shortest Path First), IGRP (Interior Gateway Routing Protocol), разработанный компанией CISCO, как альтернативный RIP, а затем и его улучшенный вариант EIGRP (Enhanced Interior Gateway Routing Protocol).

Автономные системы объединяются между собой при помощи внешних или пограничных (Border) маршрутизаторов, используя протоколы внешней маршрутизации BGP (Border Gateway Protocol). Два соседних маршрутизатора, которые обмениваются информацией внутри AS, называются внутренним и внешним, если они обмениваются информацией, принадлежащей разным системам (рис. 4.8). Связь между разными автономными системами осуществляется с помощью высокоскоростной магистральной или опорной сети (Backbone).

В соответствии с терминологией международного института стандартов ISO используется понятие конечных ES и промежуточных систем IS. Промежуточная система IS (Intermedia Systems) – передающий узел между 2 подсетями. Устройство сети, которые не обладают способностью пересылать пакеты, называется оконечным. В это же время сетевое устройство, обладающее такой возможностью – промежуточной системой IS. Промежуточные системы, которые могут сообщаться внутри домена маршрутизации (эквивалент AS), называются внутридоменные AS и системы, которые общаются с другими доменами, называются междоменными.

Процесс взаимодействия и уровни взаимодействий в соответствии с OSI показан на рис. 4.9.

Рисунок 4.9

Протокол внутренней маршрутизации RIP (Routing Information Protocol) предназначался для небольших сетей. Для нахождения оптимального пути используется алгоритм вектора расстояния DVA (Distance Vector Algorithm) – алгоритм Беллмана-Форда. Маршрут в данном алгоритме характеризуется вектором расстояния до пункта назначения (пункт назначения – направление вектора, метрика – модуль вектора). Маршрутизаторы, которые используют протокол RIP в режиме широковещания, передают список сетей, с которыми они могут связаться, и метрику, содержащую информацию о том, за сколько пересылок, шагов (hops) каждая из этих сетей может быть достигнута.

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

Таблица маршрутизации содержит по одной записи на каждый маршрут.

Такая запись имеет следующие поля: поле IP адреса пункта назначения, IP-адрес ближайшего (соседнего) маршрутизатора, метрику маршрута – до 15 шагов, таймеры (счетчики времени). Каждый маршрутизатор передает такую широковещательную информацию каждые 30 сек, генерируя достаточно большой трафик. RIP работает на сетевом уровне стека TCP/IP, используя протокол UDP (порт 520).

Каждый маршрут содержит счетчики тайм-аута и «сборщики» маршрутов. Счетчик тайм-аута сбрасывается в нуль при коррекции или инициализации маршрута. Если к моменту последней коррекции прошло 3 мин, маршрут закрывается, однако запись о нем в таблице сохраняется до наступления времени «сборка маршрута».

Формат сообщения протокола RIP имеет вид (рис. 4.10). Поле «Команда» определяет вид сообщения:

Код 1 – запрос на получение информации, код 2 – отклик, содержащий информацию о расстояниях из маршрутной таблицы отправителя, код 3 - включение режима трассировки, код 4 – выключение режима трассировки. Поле «Версия» для протокола RIP-1 равно 1. Номер протоколов, которые используются в соответствующей сети (для Интернет поле имеет значение, равное 2). Поле стоимость – число шагов. В одном сообщении может иметься информация до 25 маршрутов.

Рисунок 4.10

1. Таймер обновления – 70 сек (посылается всем соседям);

2. Таймер устаревшего маршрута – 90 сек;

3. Таймер удаления маршрута - 240 сек.

В протоколе RIP реализовано правило расщепления горизонта при модификации (Split Horizon Updates), которое препятствует появлению маршрутных петель в две пересылки, однако петли, включающие три и больше пересылок могут возникать.

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

Протокол маршрутизации внутренних шлюзов IGRP(Interior Gateway Routing Protocol) работает на основе использования алгоритма вектора расстояния DVA. Протоколы маршрутизации с вектором расстоянии требуют от каждого маршрутизатора отправления через определенные интервалы времени соседним маршрутизаторам всей или части своей таблицы маршрутизации, используя сообщения о корректировки маршрута. После того, как маршрутная информация распределиться по сети, маршрутизатор может вычислить расстояние до всех узлов объединенной сети.

Максимальное число транзисторных участков в этом протоколе может быть равным 255, а не 15 как в протоколе RIP. При формировании таблиц маршрутизации задаются следующие параметры:

1. Расстояние – число в диапазоне от 1 до 255.

2. Задержка. Измеряется кратно 10 мс. Для сетей E задается показателем 100.

3. Полоса от 1200 бит/с до 10 Гбит/с.

4. Надежность. Оптимальное значение составляет 255.

5. Загруженность канала в долях числа 255.

Для регулирования производительности применяются следующие таймеры:

1. Таймер обновления (по умолчанию 90с) – задает период передачи сообщения.

2. Таймер устаревшего маршрута. Столько времени ожидает маршрутизатор обновления, прежде чем объявить маршрут устаревшим (задается три периода обновления).

3. Таймер блокировки (по умолчанию 10 с).

4. Таймер удаления маршрута (семь периодов обновления).

Протокол предусматривает три типа маршрутов:

системные – ведущие в сети в рамках AS,

внешние – маршруты в сети вне AS.

Внешние, связанные с наличием граничного пути

Структура таблицы маршрутизации имеет вид, показанный на рис. 4.11

Рисунок 4.11

Первое поле в заголовке таблицы маршрутизации – номер версии,

затем следует поле операционного кода (OP Code). Это поле обозначает вид пакета. Код, равный 1, определяет пакет корректировки, код 2 – пакет запроса. Пакеты запроса использует маршрутизатор для получения информации о маршрутных таблицах других маршрутизаторов. Эти пакеты состоят только из заголовка, операционного кода и номера AS. Пакеты корректировки содержат заголовок, за которым следует записи данных маршрутных таблиц. Этот пакет не должен превышать 1500 байт. Далее следует поле редактирование, которое содержит последовательный номер, указывающий, когда маршрутная таблица изменялась. Далее следует номер автономной системы AS. Следующие поля определяют номер внешних сетей, главных сетей и подсетей. Последнее поле в заголовке – поле контрольной суммы. Сообщения о корректировке содержит семь полей данных для каждой записи данных маршрутной таблицы. Первое поле – 3 байта адреса IP, следующее – задержка, выраженная в десятках микросекунд, далее – поле ширины полосы в единицах 1 Кбит/с, затем идет поле размера блока данных MTU, поле надежности в процентах. Следующим является поле – загрузка, указывающее в процентах занятость канала. Последнее поле – число пересылок (счетчик шагов).

Протокол внешнего шлюза EGP (Exterion Gateway Protocol) – используется алгоритм вектора расстояния DVA для соединения AS через центральную сеть (ядро). Маршрутизатор выполняет следующие функции: выделяет соседей, с которыми обменивается информацией о достижении тех или иных сетей, посылает сообщения о их работоспособности, передает сообщения об обновлении, указывает информацию о доступности сетей для данной AS.

Типы сообщений:

1. Проверочные, если нужно установить работают ли соседние маршрутизаторы.

2. Сообщения о достижимости соседа (не выключен ли соседний маршрутизатор).

3. Сообщения о неисправности.

Протокол граничного шлюза BGP (Border Gateway Protocol) предназначен для обеспечения взаимодействий разных AS. Этот протокол можно использовать для организации связей не только между AS, но и внутри их. В BGP – нет ядра. Когда маршрутизатор подключается к сети, он получает от соседей полную таблицу маршрутизации, хранит информацию обо всех маршрутах, ведущих до пункта назначения.

Открытый протокол с алгоритмом поиска кратчайшего пути OSPF {Open Shortest Path First) – это протокол внутренних маршрутизаторов. Он гораздо сложнее RIP-протокола, однако OSPF может функционировать в сетях любой сложности и не имеет ограничений, характерных для RIP. Время, используемое на по­строение таблиц маршрутизации и загрузки сети служебной информацией, в среднем меньше по сравнению с тем, что потребовал бы протокол RIP для такой же системы. Кроме этого, переходные процессы в OSPF завершаются быстрее, чем в RIP. OSPF представляет собой протокол учета состояния канала LSA (Link State Algorithm), в котором маршрутизация выполняется по алгоритму Дийкстры. В качестве метрики используется коэффициент качества обслуживания QoS (Quality of Service). Каждый маршрутизатор обладает полной информацией о состоянии всех ин­терфейсов всех маршрутизаторов (узлов коммутации) автономной системы. Протокол OSPF реализован программным модулем - демоном маршрути­зации gated, который поддерживает также RIP и внешний протокол маршрутизации BGP. Качество обслуживания (QoS) характеризуется следующими параметрами: пропускной способностью канала, задержкой (временем распространения пакета), загрузкой канала, требованиями безопасности, типом трафика, числом шагов до места назначения, надежностью передачи пакетов.

Доминирующими являются три характеристики: задержка, пропуск­ная способность и надежность. На практике чаще всего метрика связи в OSPF определяется как количество секунд, требуемых для передачи 100 Мбит по каналу, через который проложен маршрут. Например, метрика сети на основе 10BASE-T Ethernet равна 10, метрика канала модемной связи со скоростью 56 кбит/с составляет 1785, а канала со скоростью 100 Мбит и вы­ше равна 1.

Для транспортных целей OSPF применяет протокол IP непосредст­венно, т.е. не привлекая протоколы UDP или TCP. OSPF имеет свой код в протокольном поле IP-заголовка. Код типа обслуживания ToS {type of service) в IP-пакетах, содержащих OSPF-сообщения, равен нулю, значение типа обслуживания ToS здесь задается в самих пакетах OSPF.

Маршрутизация в протоколе OSPF определяется IP-адресом и типом сервиса. В связи с тем, что протокол не требует инкапсуляции пакетов, су­щественно облегчается управление сетями с большим количеством мостов и сложной топологией (исключается циркуляция пакетов, сокращается тран­зитный трафик). Автономная система может быть разделена на отдельные области, каждая из которых становится объектом маршрутизации, а внут­ренняя структура снаружи не видна. Этот прием позволяет значительно со­кратить необходимый объем маршрутной базы данных. В OSPF использует­ся термин магистральная сеть {backbone), обозначающий среду для коммуникаций между выделенными областями. Протокол OSPF работает лишь в пределах автономной системы.

В стеке протоколов TCP/IP протокол OSPF находится непосредственно над протоколом IP, его код равен 89. Поэтому если значение поля "Прото­кол" IP-дейтаграммы равно 89, то данные дейтаграммы являются сообщени­ем OSPF и передаются OSPF-модулю для обработки. Соответственно размер OSPF сообщения ограничен максимальным размером дейтаграммы.

При передаче OSPF-пакетов фрагментация не желательна, но не за­прещается. Для передачи статусной информации OSPF использует широко­вещательные сообщения Hello. Повышение безопасности обеспечивается ав­торизацией процедур. Протокол OSPF требует резервирования двух группо­вых адресов: адрес 224.0.0.5 - предназначен для обращения ко всем маршрутиза­торам, поддерживающим этот протокол; адрес 224.0.0.6 - служит для обращения к специально выделенному маршрутизатору. Любое сообщение OSPF начина­ется с 24-октетного заголовка (рисунок 4.12).

Рисунок 4.12

Поле "Версия" определяет версию протокола. Поле "Тип" иден­тифицирует функцию сообщения, в частности: код 1- Hello (используется для проверки доступности маршрутизатора); код 2 - Описание базы данных (тополо­гия); код 3 - Запрос состояния канала; код 4 - Изменение состояния канала; код 5- Под­тверждение получения сообщения о статусе канала.

Поле "Длина сообщения" указывает длину блока в октетах, включая заго­ловок. "Идентификатор области" - 32-битный код, задающий область, ко­торой данный пакет принадлежит. Все OSPF-пакеты ассоциируются с той или иной областью. Большинство из них не преодолевает более одного шага. Пакеты, перемещающиеся по виртуальным каналам, помечаются идентифи­катором опорной (магистральной) области {backbone).

Поле "Контрольная сумма" содержит проверочную сумму IP-пакета, включая поле типа идентификации. Поле "Тип идентификации" может принимать значения 0 при отсутствии контроля доступа, и 1 при его нали­чии. В дальнейшем функции поля предполагается расширить.

Для взаимообмена данными между соседними маршрутизаторами протокол OSPF использует сообщения типа Hello. Важную функцию в этих сообщениях выполняет однобайтное поле "Опции", служащее для объявле­ния состояния канала и описания базы данных.

Структура пакетов этого типа показана на рисунке 4.13.

Рисунок 4.13

Особую роль в поле "Опции" играют младшие биты Е и Т: Бит Е ха­рактеризует возможность внешней маршрутизации и имеет значение только в сообщениях типа Hello, в остальных сообщениях этот бит должен быть об­нулен. Если Е=0, то данный маршрутизатор не будет посылать или прини­мать маршрутную информацию от внешних автономных систем. Бит Т оп­ределяет сервисные возможности маршрутизатора. Если Т=0, это означает, что маршрутизатор поддерживает только один вид услуг (тип сервиса ToS=0) и он не пригоден для маршрутизации с учетом вида услуг. Такие маршрутизаторы, как правило, не используются для транзитного трафика.

Поле "Сетевая маска" сообщения Hello соответствует маске подсети данного интерфейса. Поле "Время между Hello" содержит значение времени в секундах, между сообщениями Hello. Поле "Опции" характеризует возможности, ко­торые предоставляет данный маршрутизатор. Поле "Приоритет" задает уро­вень приоритета маршрутизатора, используемый при выборе резервного {backup) маршрутизатора. Если приоритет равен нулю, данный маршрутиза­тор никогда не будет реализован в качестве резервного. Поле "Время от­ключения маршрутизатора" определяет временной интервал в секундах, по истечении которого "молчащий" маршрутизатор считается вышедшим из строя. IP-адреса маршрутизаторов, записанные в последующих полях, ука­зывают место, куда следует послать данное сообщение, Поля "IP-адрес со­седа к" образуют список адресов соседних маршрутизаторов, откуда за по­следнее время были получены сообщения Hello.

Маршрутизаторы обмениваются сообщениями из баз данных OSPF, чтобы инициализировать, а в дальнейшем актуализовать свои базы данных, характеризующие топологию сети. Обмен происходит в режиме клиент-сервер. Клиент подтверждает получение каждого сообщения. Формат пере­сылки записей из базы данных изображен на рисунке 4.14.

Рисунок 4.14

Если размер базы данных велик, ее содержимое может пересылаться по частям. Для реализации этого используются биты I и М. Бит I устанавлива­ется в 1 в стартовом сообщении, а бит М принимает единичное состояние для сообщений, которые являются продолжением. Бит S определяет, кем по­слано сообщение (S=l для сервера, S=0 для клиента, этот бит иногда имеет имя MS).

Поле "Порядковый номер сообщения" служит для контроля пропу­щенных в процессе обмена информацией блоков. Первое сообщение содер­жит в этом поле случайное целое число М, последующие: М+1, M+2,...M+L. Поле "Тип канала" содержит коды, определяющие состояние каналов, а именно, его интерфейсов, описание внешних связей автономных систем.

Поле "Идентификатор канала" указывает вид идентификатора, в качестве которого может быть IP-адрес маршрутизатора или сети. Маршрутизатор, объявляющий канал, определяет адрес этого маршрутизатора. Поле "Поряд­ковый номер канала" позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле "Возраст канала" задает время в се­кундах с момента установления связи. После обмена сообщениями с соседями маршрутизатор может выяснить, что часть данных в его базе устарела. Он может послать своим соседям запрос с целью получения свежей мар­шрутной информации о каком-то конкретном канале связи. Сосед, получив­ший запрос, высылает необходимую информацию.

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

Маршрутизатор, получивший OSPF-пакет, посылает подтверждение его приема. Возможно подтверждение одним пакетом получения нескольких объявлений о состоянии линий. Адресом места назначения этого пакета мо­жет быть индивидуальный маршрутизатор, их группа или все маршрутиза­торы автономной системы.

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

Маршрутная таблица OSPF включает следующие поля:

• IP-адрес места назначения и маску;
• тип места назначения (сеть, граничный маршрутизатор и т.д.);
• тип функции (возможен набор маршрутизаторов для каждой из функ­ций ToS);
• область (описывает область, связь с которой ведет к цели; возможно несколько записей данного типа, если области действия граничных маршру­тизаторов перекрываются);
• тип пути (характеризует путь как внутренний, межобластной или внешний, ведущий к автономной системе AS);
• цена маршрута до цели;
• очередной маршрутизатор, куда следует послать дейтаграмму;
• объявляющий маршрутизатор (используется для межобластных обме­нов и для связей автономных систем друг с другом).

К преимуществам протокола маршрутизации OSPF следует отнести:

• возможность применения для любого получателя нескольких мар­шрутных таблиц, по одной на каждый вид IP-операции;
• каждому интерфейсу присваивается безразмерная цена, учитывающая пропускную способность, время транспортировки сообщения; собственная цена (коэффициент качества) может быть присвоена любой IP-операции;
• при существовании эквивалентных маршрутов OSFP распределяет по­ток равномерно по этим маршрутам;
• поддерживается адресация подсетей (разные маски для разных маршрутов);
• при связи точка-точка не требуется IP-адрес для каждого из конечных интерфейсов;
• применение групповой рассылки вместо широковещательных сообще­ний снижает загрузку значительной части сегментов.

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

Существует два основных способа определения маршрута и построения таблиц маршрутизации - статический и динамический.

Статическая маршрутизация. При использовании статического способа таблицы маршрутизации строятся администратором сети вручную. Для ихВ построения используются специальные команды маршрутизатора (обычноВ это команда route, с помощью которой определяется маршрут для указанной сети). Параметрами этих команд служат адрес и маска сети назначения, адрес следующего маршрутизатора (next hop) для этой сети и имя илиВ адрес интерфейса, через который должна быть передана дейтаграмма. ДляВ корректной доставки дейтаграммы достаточно первых трех параметров.В При использовании внеклассовых сетей в таблице маршрутизации вполнеВ могут появиться конфликтующие маршруты, поэтому указание маскиВ является обязательным.

Построение полной таблицы маршрутизации, в которой были бы указаны все сети, образующие Интернет, невозможно из-за огромного количества этих сетей. Для того чтобы упростить процедуру построения таблицы маршрутизации, в нее может быть включен специальный узел, куда необходимо передать дейтаграммы, адрес сети назначения которых не указан в таблице маршрутизации. Этот специальный узел называется шлюзом по умолчанию (Default Gateway) и применяется для маршрутизацииВ в режиме «по умолчанию». Для обозначения маршрута к Default GatewayВ в качестве адресов сети и маски принято использовать нулевые значения.

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

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

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

• алгоритмы вектора расстояния (Distance-Vector) - маршрутизатор через заранее определенные промежутки времени передает соседнимВ маршрутизаторам содержимое своей таблицы маршрутизации;
• алгоритмы состояния канала (Link-State ) - маршрутизатор передаетВ информацию только об изменениях состояния системы.

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

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

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

Для определения внутренних маршрутов в автономных системах обычно используется один или несколько протоколов маршрутизации.В В автономных системах этот класс протоколов принято называть протоколами внутренней маршрутизации (Interior Gateway Protocol, IGP). Применение протоколов внешней маршрутизации (Exterior Gateway Protocol,В EGP ) позволяет администратору реализовать совокупность мер повышения надежности и экономической эффективности информационного взаимодействия с внешними системами. В число параметров, используемыхВ современным протоколом внешней маршрутизации для определения качества маршрута, входят предпочтительность маршрута, последовательностьВ проходимых автономных систем и другие параметры.

Протокол RIP. Внутренний протокол маршрутизации RIP (Routing Information Protocol) использует алгоритм вектора расстояния для определения маршрута следования пакетов.

Функционирование маршрутизаторов по алгоритму вектора расстояния.

• 1. Маршрутизатор строит первичную таблицу маршрутизации, в которую помещает номера непосредственно подключенных сетей. Эта таблицаВ содержит следующие поля:
  • Address (Адрес) - адрес сети или узла назначения;
  • Router (Маршрутизатор) - сетевой адрес первого маршрутизатораВ на маршруте к сети или узлу назначения;
  • Interface (Интерфейс) - сетевой адрес или номер интерфейса связиВ с первым маршрутизатором;
  • Metric (Метрика) - числовая характеристика маршрута от 0 до 15В (значение 0 соответствует непосредственно подключенной сети, метрика 15В указывает на недостижимость сети или узла назначения, в остальныхВ случаях - соответствует количеству промежуточных маршрутизаторовВ на маршруте к сети или узлу назначения);
  • Timer (Таймер) - показатель актуальности информации о сети илиВ узле назначения (если информация не подтверждается источником в течение установленного временного интервала, запись о маршруте удаляетсяВ из таблицы).
• 2. Маршрутизатор рассылает оформленную в виде специального сообщения об обновлении (Update) текущую версию таблицы маршрутизацииВ соседним маршрутизаторам.
• 3. При приеме аналогичного сообщения от соседнего маршрутизатораВ выполняются следующие действия:
  • а) если сообщение содержит информацию о сети, которой нет в таблицеВ маршрутизации, адрес этой сети заносится в таблицу со следующими значениями полей:
    • - Router (Маршрутизатор) - адрес источника сообщения,
    • - Interface {Интерфейс ) - адрес интерфейса, принявшего сообщение,
    • - в поле Metric {Метрика) заносится значение соответствующего поляВ исходного сообщения, увеличенное на весовой коэффициент интерфейсаВ (обычно все весовые коэффициенты интерфейсов принимаются равными 1),
    • - значение поля Timer {Таймер) у созданной записи устанавливаетсяВ равным утроенному периоду обновлений (90 с);
  • б) если сообщение содержит информацию о сети, которая есть в таблицеВ маршрутизации, выполняется сравнение содержимого полей Router существующей записи и принятого сообщения. Если источник маршрутнойВ информации в обоих случаях был один и тот же, поле Metric существующей записи модифицируется по обычному алгоритму значением соответствующего поля принятого сообщения. Поле Timer для модифицированной записи формируется так же, как и для вновь созданной;
  • в) если информацию об известной сети содержит сообщение, принятое от нового источника, маршрутизатор сравнивает содержимое полейВ Metric существующей записи и принятого сообщения. Если метрика существующего маршрута больше метрики нового маршрута, прежняя записьВ в таблице маршрутизации заменяется новой. В противном случае таблицаВ маршрутизации никак не модифицируется;
  • г) в том случае, если значение поля Timer у существующей записи сталоВ равным 0, запись удаляется из таблицы маршрутизации.

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

В протоколе RIP в качестве предельного значения метрики маршрута используется значение 15. Сети, удаленные от данного узла на расстояние,В которое превышает 15 переходов, считаются недостижимыми {Unreachable).

Методы противодействия возникновению циклических маршрутов. Для противодействия возникновению циклических маршрутов алгоритмыВ маршрутизации Distance-Vector вообще и RIP в частности используютВ некоторые специальные методы.

• Правило расщепленного горизонта {Split Horizon). ИнформацияВ о маршруте в некоторую сеть N, полученная от маршрутизатора, не можетВ быть включена в регулярные обновления, отправляемые этому маршрутизатору. Использование этой процедуры позволяет гарантированноВ избежать появления циклических маршрутов между двумя соседнимиВ маршрутизаторами, повышает эффективность использования пропускнойВ способности канала за счет сокращения неинформативной составляющейВ сообщения об обновлении маршрутов. Однако в том случае, если циклический маршрут образован несколькими маршрутизаторами, применениеВ этой процедуры не даст желаемого эффекта.
• Правило отравленного обратного пути {Poison Reverse). ДействуетВ аналогично предыдущему правилу, однако, в отличие от процедуры расщепленного горизонта, информация о маршруте в некоторую сеть N, полученная от маршрутизатора, включается в регулярные обновления,В отправляемые этому маршрутизатору с метрикой 16. В результате использования этой процедуры потенциально опасные маршруты будут удаленыВ из таблицы маршрутизации. Но если при использовании чистой процедурыВ Split Horizon эти маршруты будут удалены по истечении определенногоВ времени, то использование Poison Reverse приведет к их мгновенномуВ уничтожению.
• Метод управляемых обновлений (Triggered Update). Наиболее мощным средством борьбы с длинными циклическими маршрутами является использование апериодических управляемых обновлений маршрутовВ (Triggered Update). Маршрутизатор формирует обновление при каждомВ изменении своей таблицы маршрутизации, не дожидаясь наступленияВ момента передачи очередного периодического обновления. При полученииВ такого управляемого обновления последующий маршрутизатор скорректирует свою таблицу маршрутизации, а затем, в свою очередь, сформируетВ свое управляемое обновление, которое направит своим соседям. ТакимВ образом, информация об изменении конфигурации распространяетсяВ по сети немедленно. Кроме того, вследствие особого дифференциальногоВ принципа формирования таких обновлений они распространяются по сетиВ от источника только в нужных направлениях, поскольку маршрутизатор,В не изменивший свою таблицу маршрутизации при получении управляемого обновления, не сформирует вторичное обновление и заблокирует егоВ дальнейшее распространение.

Режимы RIP. При реализации RIP можно выделить следующие режимы:

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

Формат сообщения RIP. Для взаимного обмена маршрутной информацией со своими соседями маршрутизаторы протокола RIP применяют сообщения специального формата (рис. 5.32).

Для отправки этих сообщений маршрутизаторы первой версии RIP обычно использовали широковещательный адрес (Broadcast) сетевогоВ уровня. Особенно негативно эта особенность протокола проявляласьВ в сетях множественного доступа (например, Ethernet), где она могла приводить к значительному снижению эффективности использования сетевыхВ ресурсов. В версии RIPv2 применяется специально выделенный групповойВ адрес 224.0.0.9 или для передачи сообщения конкретному соседу - обычный одноадресный режим (Unicast).

Сообщения протокола RIP состоят из заголовка и следующих за ним маршрутных записей (Route Entries, RTE). Обычно в сообщении протокола

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

Рис. 532.

Поле Команда (Command ) может принимать следующие значения:

• 1 - запрос на получение частичной или полной маршрутной информации;
• 2 - отклик, содержащий информацию о расстояниях из маршрутнойВ таблицы отправителя;
• 3 - включение режима трассировки;
• 4 - выключение режима трассировки;
• 5-6 - зарезервированы для внутренних целей SUN Microsystem.

Поле Версия (Version ) указывает версию протокола RIP (1 или 2). Поле Набор протоколов сети (Address family identifier ) i (i

Сообщения типа «запрос» используются для запроса на получение полной таблицы маршрутизации или ее части. Обработка запроса ведетсяВ запись за записью (RTE за RTE). Для каждой маршрутной записи проверяется таблица маршрутизации на предмет того, есть ли там соответствующая запись. Если есть, то в ноле маршрутной записи помещается метрикаВ из таблицы маршрутизации. Если нет - в поле маршрутной записи помещается число 16, обозначающее бесконечную метрику. После того как все маршрутные записи обработаны, пакет отсылается обратно запрашивающему.

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

При получении сообщения типа «отклик» для каждого содержащегося в нем элемента вектора расстояний выполняются следующие действия:

• проверяется корректность указанных в сообщении адреса сетиВ и маски;
• проверяется, не превышает ли метрика бесконечности:
  • - некорректный элемент игнорируется,
  • - если метрика меньше бесконечности, она увеличивается на 1;
• в таблице маршрутов производится поиск сети, указанной в рассматриваемом элементе вектора расстояний, причем, если запись о такой сетиВ в таблице маршрутов отсутствует и метрика в полученном элементе вектора меньше бесконечности, сеть вносится в таблицу маршрутов с указанной метрикой;
• в ноле «Следующий маршрутизатор» заносится адрес маршрутизатора, приславшего сообщение;
• запускается таймер для принятой записи в таблице;
• если искомая запись присутствует в таблице с метрикой больше,В чем объявленная в полученном векторе, в таблицу вносятся новые записиВ о метрике и, соответственно, об адресе следующего маршрутизатора и таймер для этой записи перезапускается;
• если искомая запись присутствует в таблице и отправителем полученного вектора был маршрутизатор, указанный в поле «СледующийВ маршрутизатор» этой записи, то таймер для этой записи перезапускается;
• более того, если при этом метрика в таблице отличается от метрикиВ в полученном векторе расстояний, в таблицу вносится значение метрикиВ из полученного вектора;
• во всех прочих случаях рассматриваемый элемент вектора расстояний игнорируется.

Недостатки RIP.

• - Отсутствие поддержки спецификации CIDR. RIP-I воспринимаетВ внеклассовые сети типа 10.1.0.0/16, 10.2.0.0/16 и т.д. как одну сеть классаВ А 10.0.0.0/8 и формирует для нее один маршрут, что, естественно, приводит к потере пакетов, направляемых в указанные подсети. Этот недостатокВ был устранен во второй версии протокола путем введения в маршрутнуюВ информацию дополнительной характеристики SUBNET MASK (маска сетиВ назначения).
• - Требует много времени для восстановления связи после сбоя в маршрутизаторе.
• - Возможно возникновение циклов.
• - Наличие лишь одного параметра определения маршрута - числаВ промежуточных маршрутизаторов.

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

Так, в новой версии протокола появилась возможность аутентификации передаваемых сообщений, для чего используется первая маршрутная запись в заголовке пакета . Кроме того, стало возможным различать «внутренние» маршруты (полученные через RIP) от «внешних» (полученныхВ от других протоколов маршрутизации, таких как EGP, ВОР).

Как было сказано ранее, в новой версии протокола RIP стало возможным при помощи поля Маска подсети различать не только сети, но и подсети. В целях уменьшения использования полосы пропускания сетей протокол RIPv2 вместо адреса broadcast использует multicast-адрес - 224.0.0.9.

Протокол OSPF (Open Shortest Path First ) относится к протоколам маршрутизации на основе состояния канала (класс Link-State).

Функционирование маршрутизаторов по алгоритму состояния каналов. Как и все протоколы маршрутизации класса Link-State, протокол OSPF предназначен для построения внутренних маршрутов автопомпойВ системы (.Autonomous System ).

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

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

• внутренний (Internal Router , //?);
• пограничный области (Area Border Router );
• пограничный автономной системы (AS Boundary Router , ASBR );
• магистральный (Backbone Router , BR ).

Все маршрутизаторы OSPF принимают участие в формировании маршрутной информации автономной системы путем передачи специальных сообщений, содержащих информацию о текущем состоянии фрагментаВ сети. Эти сообщения называются объявлением состояния капала (Link StateВ Advertisement , LSA). Сообщения LSA обязательно формируются при любомВ изменении состояния контролируемого компонента сети. Для обеспечения большей надежности сообщения LSA могут быть сформированыВ и при отсутствии каких-либо изменений в сети через достаточно большиеВ интервалы времени, например, один раз за полчаса.

Принятые сообщения образуют в каждом маршрутизаторе базу данных состояния сети (Link State Data Base). При получении сообщения об изменениях в структуре сети маршрутизатор вносит соответствующие изменения в свою копию базы данных. Таким образом, в каждый момент времениВ все базы данных маршрутизаторов, находящихся внутри одной автономной системы, являются идентичными и адекватно отображают структуруВ этой системы. Для того чтобы определить маршрут, по которому должнаВ быть передана дейтаграмма, маршрутизатор на основании своей копии базы данных строит дерево кратчайших путей, в вершине которого размещает самого себя (используя алгоритм Дсйкстры). Построение кратчайших путей маршрутизатор выполняет всякий раз, когда происходит изменениеВ состояния сети.

Существенной особенностью протокола маршрутизации OSPF является специальная процедура информационного обмена между маршрутизаторами в сетях с множественным доступом (например, Ethernet). Маршрутизаторы, подключенные к одной и той же сети, называются соседними маршрутизаторами (Neighboring Routers). Маршрутизаторы протоколаВ OSPF устанавливают и обслуживают соседские отношения, используяВ специальный дополнительный протокол Hello. С помощью этого протоколаВ определяется состав подключенных к сети маршрутизаторов, их работоспособность и производится выбор одного из них в качестве назначенногоВ маршрутизатора (Designated Router, DR). Назначенный маршрутизаторВ выбирается для того, чтобы исключить возможность многократного представления информации об одной сети. Он формирует сообщения, содержащие список подключенных к сети маршрутизаторов, и передает содержимое текущей базы данных по запросу, полученному от одного из них. ЕслиВ по каким-либо причинам назначенный маршрутизатор перестал функционировать, его функции автоматически переходят к запасному назначенномуВ маршрутизатору (Backup Designated Router, BDR), выбираемому одновременно с основным.

Для передачи маршрутной информации маршрутизаторы протокола OSPF используют различные типы обновлений о состоянии сетевых компонентов (LSA). Процесс распространения LSA в пределах автономнойВ системы называется затоплением (Flooding).

Для хранения маршрутной информации протокола OSPF маршрутизаторы используют специальные топологические базы данных (Link-State Database). База данных формируется из принятых сообщений LSA и отображает текущее состояние и структуру информационных связей в рассматриваемой области маршрутизации. На основании этой базы каждыйВ маршрутизатор строит дерево кратчайших путей, соединяющих его самогоВ с остальными компонентами области, и собственно таблицу маршрутизации.

Формат сообщений протокола OSPF. Формат заголовка сообщений протокола OSPF приведен на рис. 5.33.

Поле Версия (Version No.) указывает версию протокола (= 2). Поле Тип (Packet Туре) идентифицирует функцию сообщения и может приниматьВ следующие значения:

• 1 - сообщение является сообщением Hcllovv (используется для проверки доступности маршрутизатора);
• 2 - сообщение является описанием базы данных;
• 3 - сообщение является запросом состояния канала;
• 4 - сообщение информирует об изменении состояния канала;
• 5 - сообщение является подтверждением получения сообщения о статусе канала.

Рис. 533-

Поле Длина пакета (Packet Length ) определяет длину блока (включая заголовок) в октетах. Поле Идентификатор области {Area ID) представляет собой 32-битный код, идентифицирующий область, которой принадлежит данный пакет. Поле Контрольная сумма {Checksum) содержитВ контрольную сумму IP-пакета, включая поле Тип идентификации. Контрольное суммирование производится по модулю 1. Поле Тип идентификации {A U type ) имеет значение 0, если отсутствует контроль доступа, и 1 -В в противном случае.

Формат сообщения Hellow протокола OSPF приведен на рис. 5.34.

Рис. 534.

Поле Сетевая маска соответствует маске подсети интерфейса. Поле Время между сообщениями НЕЬЬО? содержит значение времени в секундах между сообщениями Не11оу. Поле Приоритет определяет уровень

приоритета маршрутизатора. Поле Время отключения маршрутизатора определяет временной интервал в секундах, по истечении которого не отвечающий маршрутизатор считается вышедшим из строя. Поля 1Р-адресВ маршрутизатора и 1Р-адрес резервного маршрутизатора указывают, кудаВ надо послать сообщение. Поля 1Р-адрес соседа г образуют список адресовВ соседних маршрутизаторов, от которых недавно были получены сообщенияВ Не11о?. Поле Опции (8 бит) информирует о состоянии канала и описываетВ базу данных. Его формат приведен на рис. 5.35.

Рис. 5.35.

Бит Е характеризует возможность внешней маршрутизации и имеет значение только в сообщениях типа Hcllow, в остальных сообщениях данный бит должен быть обнулен (т.е. маршрутизатор не будет посылать илиВ принимать маршрутную информацию от внешних автономных систем).В Бит Т определяет сервисные возможности маршрутизатора (Type of Service,В ToS). Если Т = 0, то маршрутизатор поддерживает лишь один вид услуг.

Формат сообщения OSPF о маршрутах приведен на рис. 5.36.

Рис. 5J6. Формат OSPF-сообщения о маршрутах

Поля, начиная с поля Тип канала, повторяются для каждого описания канала. Содержимое базы может пересылаться по частям. В стартовомВ сообщении бит I устанавливается в 1, в сообщении-продолжении бит МВ устанавливается в 1. Бит Б определяет, послано сообщение сервером (8=1)В или клиентом (Б = 0). Поле Номер сообщения по порядку служит для кон-

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

• 1 - описание каналов маршрутизатора (состояние его интерфейсов);
• 2 - описание сетевых каналов (перечень маршрутизаторов, непосредственно связанных с сетью);
• 3 или 4 - сводное описание каналов, в которое входят маршруты междуВ отдельными областями сети (тип 3 приписан маршрутам, ведущим к сетям,В а тип 4 - маршрутам, ведущим от сетей);
• 5 - описание внешних связей автономной системы.

Поле Идентификатор канала определяет характер канала (идентификатором может быть 1Р-адрес маршрутизатора или сети). Поле Маршрутизатор, рекомендующий канал определяет адрес этого маршрутизатора. Иоле Порядковый номер канала позволяет маршрутизатору контролировать порядок прихода сообщений и их потерю. Поле ПродолжительностьВ связи определяет время в секундах с момента установления связи.

Формат ОЗРР-запроса маршрутной информации приведен на рис. 5.37.

Рис. 537.

Формат сообщения о получении ОБРР-пакета и формат ОБРР-сообщения об изменении маршрутов приведены на рис. 5.38, 5.39 соответственно.

Рис. 538.

Причины посылки сообщений об изменении маршрута:

• 1) продолжительность связи достигла предельного значения;
• 2) изменилось состояние интерфейса;
• 3) произошли изменения в маршрутизаторе сети;
• 4) произошли изменения в одном из соседних маршрутизаторов;
• 5) изменилось состояние одного из внутренних маршрутов;
• 6) изменение состояния межзонного маршрута;
• 7) появление нового маршрутизатора, подключенного к сети;
• 8) изменение виртуального маршрута одним из маршрутизаторов сети;
• 9) изменение одного из внешних маршрутов;
• 10) маршрутизатор перестал быть пограничным для автономнойВ системы.

Рис. 5.39.

Достоинства протокола OSPF. В отличие от универсальных протоколов (например, RIP), протокол OSPF предназначен для построения маршрутов только в сетях TCP/IP.

Основными достоинствами протокола OSPF являются:

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

Протокол пограничного шлюза (Border Gateway Protocol, BGP ) является протоколом маршрутизации между автономными системами. Данный протокол работает поверх протокола транспортного уровня. Это позволяетВ нс нагружать сервисы обработки протокола BGP механизмами фрагментации или обеспечения достоверности доставки пакетов. Схемы аутентификации протоколов транспортного уровня также могут быть использованыВ BGP в дополнение к собственной системе аутентификации. Кроме того,В хотя BGP разработан как протокол маршрутизации между автономнымиВ системами, он может использоваться для маршрутизации и внутри автономных систем.

Основным предназначением BGP является обеспечение обмена информацией с другими BGP-системами о досягаемости определенных сетей или

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

Отличия протокола ВвР от других протоколов маршрутизации. Протокол ВвР нельзя отнести ни к классу дистанционно-векторных, ниВ к классу протоколов маршрутизации на основе состояния канала. НижеВ приведены характерные отличия протокола ВОР от других протоколовВ маршрутизации.

• Коммуникация между автономными системами. Поскольку протоколВ ВОР относится к протоколам внешнего шлюза, его основное назначение -В обеспечить обмен информацией между двумя автономными системами.
• Координирование работы нескольких спикеров ВСР. Если в составВ автономной системы входит несколько маршрутизаторов, каждый из которых обменивается информацией с равным ему по рангу маршрутизаторомВ внешней автономной системы (их называют спикерами ВСР), протоколВ ВвР может использоваться для координации работы всего набора маршрутизаторов. Это гарантирует, что маршрутизаторы распространяют непротиворечивую информацию.
• Распространение информации о достижимости. Протокол ВвРВ позволяет автономной системе сообщить информацию о расположенныхВ в ней получателях, а также о тех получателях, доступ к которым осуществляется через данную автономную систему. Кроме того, с помощью протокола ВвР подобную информацию можно получить от других автономныхВ систем.
• Принцип ближайшего перехода. Подобно дистанционно-векторнымВ протоколам маршрутизации, протокол ВСР предоставляет информациюВ об адресе ближайшей точки перехода для каждого получателя.
• Поддержка различной политики маршрутизации. В отличие от многих дистанционно-векторных протоколов, которые сообщают только туВ маршрутную информацию, которая находится в локальной таблице маршрутизации, протокол ВвР обеспечивает политику маршрутизации в зависимости от выбора администратора. В частности, маршрутизатор, работающий под управлением протокола ВСР, можно настроить так, чтобы онВ различал получателей, доступ к которым осуществляется через компьютеры его автономной системы, и получателей, анонсированных другимиВ автономными системами.
• Надежный транспортный протокол. Протокол ВСР отличаетсяВ от других протоколов, передающих информацию о маршрутизации, тем,В что он предполагает использование надежного транспортного протокола.В Таким образом, для обмена информацией в протоколе ВСР используетсяВ исключительно транспортный протокол ТСР.
• Информация о маршруте. Кроме указания списка возможных получателей и адреса ближайшей точки перехода для каждого из них в сообще нии протокола BGP анонсируется также маршрутная информация, которая позволяет узнать, через какие автономные системы проложен маршрут к конкретному получателю.
• Передача обновлений. Чтобы не создавать дополнительную нагрузкуВ на сеть, в каждом сообщении протокола BGP об обновлении не передаетсяВ полная маршрутная информация. Вместо этого обмен полной информацией происходит только один раз, а в следующих сообщениях передаютсяВ только изменения.
• Поддержка бесклассовой адресации. Протокол BGP поддерживаетВ CIDR-адреса. Это означает, что программа протокола BGP не полагаетсяВ на методы идентификации IP-адресов, а вместе с каждым адресом отсылаетВ и его маску.
• Объединение маршрутов. Чтобы не создавать дополнительной нагрузкиВ на сеть, протокол BGP позволяет отправителю накапливать информациюВ о маршрутах и отсылать в одном пакете данные сразу о нескольких, связанных между собой получателях.
• Аутентификация. Протокол BGP позволяет получателю удостоверить подлинность сообщений (т.е. подтвердить «личность» отправителя).

Функции протокола BGP и виды сообщений. В процессе взаимодействия по протоколу BGP выполняется три основных действия:

• 1) получение согласия сторон на взаимодействие по протоколу BGPВ и аутентификацию (при этом два равноправных маршрутизатора устанавливают соединение по протоколу TCP и обмениваются сообщениями, которые подтверждают, что обе стороны согласны вступить в процесс обменаВ информацией);
• 2) каждая сторона отсылает информацию о доступности или недоступности получателей (это означает, что отправитель может сообщить о возможности доступа к одной или нескольким сетям получателя (при этомВ указывается адрес ближайшей точки перехода для каждой сети) или,В напротив, может заявить, что одна или несколько сетей, о которых сообщалось ранее, более недоступны);
• 3) осуществление постоянного контроля над правильностью функционирования взаимодействующих пар маршрутизаторов и сетевых соединений.

В протоколе BGP определено четыре основных типа сообщений: OPEN (инициализирует процесс), UPDATE (аннулирует маршрутную информацию),В NOTIFICATION (отвечает на неверное сообщение), KEEPALIVE (выполняетВ активную проверку возможности соединения между BGP-парами).

В начале каждого сообщения протокола BGP расположен заголовок фиксированного формата, с помощью которого определяется тип сообщения (рис. 5.40).

Рис. 5.40.

В ноле Маркер (Marker ) (16 октетов) заносится значение, которое обе стороны «договорились» использовать в качестве метки начала сообщения. В поле Длина (Length ) (2 октета) указывается общая длина сообщения в октетах. Минимальный размер сообщения составляет 19 октетовВ (для типа сообщения, в котором после заголовка нет данных). Максимально допустимая длина сообщения составляет 4096 октетов.

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

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

BGP-сообщения OPEN (рис. 5.41) являются запросом BGP-соединения и передаются для организации сеанса связи между равноправными BGP-маршрутизаторами. Принявший это сообщение маршрутизатор подтверждает установление соединения, передавая сообщение KEEPALIVEВ (сообщение KEEPALIVE содержит только заголовок и обеспечивает сбросВ таймера удержания соединения).

Рис. 5.41.

Поле Версия (длина 8 бит) указывает на версию протокола BGP. Моя автономная система (длина 16 бит) содержит идентификатор автономнойВ системы отправившего сообщение маршрутизатора. Поле Время сохранения (Hold Time ) длиной 16 бит указывает на максимальное время (в секундах) между приходами сообщений KEEPALIVE, используемых для мониторинга активности соединения. BGP-идентификатор в 32 бита содержит идентификатор маршрутизатора (один из адресов интерфейсов). Поле КодВ идентификации, длина которого 8 бит, содержит длину поля Идентификационные данные, содержащего различные опции.

Сообщение UPDATE рассылается маршрутизатором BGP с целью внесения изменений в таблицы маршрутизации. Формат BGP-сообщения UPDATE приведен на рис. 5.42.

Рис. 5.42.

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

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

Сообщениями-уведомлениями (NOTIFICATION) BGP-маршрутизаторы обмениваются при возникновении ошибок. Такие сообщения содержатВ в себе код ошибки (например, ошибка заголовка, ошибка в сообщенииВ OPEN, ошибка в сообщении UPDATE и т.д.).

• ИРС 2453 специфицирует использование только одной схемы аутентификации - использование простого нешифруемого пароля.