Смекни!
smekni.com

Разработка системы маршрутизации в глобальных сетях(протокол RIP для IP) (стр. 15 из 26)

Пример с альтернативными маршрутами

Рисунок 4.24

Пусть каждый из маршрутизаторов уже вычислил комбинированную метрику для системы, изображенной на рис. 4.4.11.3.2. Для места назначения в сети 6 маршрутизатор A вычислит метрику для двух путей, через маршрутизаторы B и C. В действительности существует три маршрута из A в сеть 6:

-непосредственно в B

- в C и затем в B

- в C и затем в D

Маршрутизатору A не нужно выбирать между двумя маршрутами через C. Маршрутная таблица в A содержит только одну запись, соответствующую пути к C. Если маршрутизатор A посылает пакет маршрутизатору C, то именно C решает, использовать далее путь через маршрутизаторы B или D.

IGRP-сообщение вкладывается в IP-пакет, это сообщение имеет следующие поля:

version номер версии протокола 4 байта

opcode код операции

edition код издания

asystem номер автономной системы


Ninterior, Nsystem, Nexterior числа субсетей в локальной сети, в автономной системе и вне автономной системы.
checksum контрольная сумма IGRP-заголовка и данных
Version - номер версии в настоящее время равен 1. Пакеты с другим номером версии игнорируются.

Opcode - код операции определяет тип сообщения и может принимать значения:

1 - изменение; 2 - запрос

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

Asystem - номер автономной системы. Согласно нормам Сisco маршрутизатор может входить в более чем одну автономную систему. В каждой AS работает свой протокол и они могут иметь совершенно независимые таблицы маршрутизации. Хотя в IGRP допускается "утечка" маршрутной информации из одной автономной системы в другую, но это определяется не протоколом, а администратором.

Ninterior, nsystem, и nexterior определяют числа записей в каждой из трех секций сообщения об изменениях.

Checksum - контрольная сумма заголовка и маршрутной информации, для вычисления которой используется тот же алгоритм, что и в UDP, TCP и ICMP.

IGRP запрос требует от адресата прислать свою маршрутную таблицу. Сообщение содержит только заголовок. Используются поля version, opcode и asystem, остальные поля обнуляются. IP-пакет, содержащий сообщение об изменении маршрутов, имеет 1500 байт (включая IP-заголовок). Для описанной выше схемы это позволяет включить в пакет до 104 записей. Если требуется больше записей, посылается несколько пакетов. Фрагментация пакетов не применяется.

Ниже приведено описание структуры для маршрута:

Number 3 октета IP-адреса
delay задержка в десятках микросекунд 3 октета
bandwidth Пропускная способность, в Кбит/с 3 октета
uchar mtu MTU, в октетах 2 октета
reliability процент успешно переданных пакетов tx/rx 1 октет
load процент занятости канала 1 октет
hopcount Число шагов 1 октет

Субполе описание маршрута Number определяет IP-адрес места назначения, для экономии места здесь используется только 3 его байта. Если поле задержки содержит только единицы, место назначения недостижимо.

Пропускная способность измеряется в величинах, обратных бит/сек, умноженных на 1010. (Т.е., если пропускная способность равна N Кбит/с, то ее измерением в IGRP будет 10000000/N.). Надежность измеряется в долях от 255 (т.е. 255 соответствует 100%). Загрузка измеряется также в долях от 255, а задержка в десятках миллисекунд.

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

Вид среды Задержка Пропускная способность
Спутник 200,000 (2 сек) 20 (500 Мбит/c)
Ethernet 100 (1 мсек) 1,000
1.544 Мбит/c 2000 (20 мсек) 6,476
64 Кбит/c 2000 156,250
56 Кбит/c 2000 178,571
10 Кбит/c 2000 1,000,000
1 Кбит/c 2000 10,000,000

Комбинированная метрика в действительности вычисляется по следующей формуле (для версии Cisco 8.0(3)):

Метрика = [K1*пропускная_способность + (K2*пропускная_способность)/(256 - загрузка) + K3*задержка] * [K5/(надежность + K4)].

Если K5 == 0, член надежности отбрасывается. По умолчанию в IGRP K1 == K3 == 1, K2 == K4 == K5 == 0, а загрузка лежит в интервале от 1 до 255.

В начале 90-х годов разработана новая версия протокола IGRP - EIGRP с улучшенным алгоритмом оптимизации маршрутов, сокращенным временем установления и масками субсетей переменной длины. EIGRP поддерживает многие протоколы сетевого уровня. Рассылка маршрутной информации здесь производится лишь при измении маршрутной ситуации. Протокол периодически рассылает соседним маршрутизаторам короткие сообщения hello. Получение отклика означает, что сосед функционален и можно осуществлять обмен маршрутной информацией. Протокол EIGRP использует таблицы соседей (адрес и интерфейс), топологические таблицы (адрес места назначения и список соседей, объявляющих о доступности этого адреса), состояния и метки маршрутов. Для каждого протокольного модуля создается своя таблица соседей. Протоколом используется сообщения типа hello (мультикастная адресация), подтверждени (acknowledgent), актуализация (update), запрос (query; всегда мультикастный) и отклик (reply; посылается отправителю запроса). Маршруты здесь делятся на внутренние и внешние - полученные от других протоколов или записанные в статических таблицах. Маршруты помечаются идентификаторами их начала. Внешние маршруты помечаются следующей информацией:

1) Идентификатор маршрутизатора EIGRP, который осуществляет рассылку информации о маршруте;

2) Номер AS, где расположен адресат маршрута;

3) Метка администратора;

4) Идентификатор протокола;

5) Метрика внешнего маршрута;

6) Битовые флаги маршрута по умолчанию.

Протокол EIGRP полностью совместим с IGRP, он обеспечивает работу в сетях IP, Apple Talk и Novell.

4.5 Внешний протокол маршрутизации BGP-4

Протокол BGP (RFC-1267, BGP-3; RFC-1268; RFC-1467, BGP-4; -1265-66, 1655) разработан компаниями IBM и CISCO. Главная цель BGP - сократить транзитный трафик. Местный трафик либо начинается, либо завершается в автономной системе (AS); в противном случае – это транзитный трафик. Системы без транзитного трафика не нуждаются в BGP (им достаточно EGP для общения с транзитными узлами). Но не всякая ЭВМ, использующая протокол BGP, является маршрутизатором, даже если она обменивается маршрутной информацией с пограничным маршрутизатором соседней автономной системы. AS передает информацию только о маршрутах, которыми она сама пользуется. BGP-маршрутизаторы обмениваются сообщениями об изменении маршрутов (UPDATE-сообщения, рисунок 4.25). Максимальная длина таких сообщений составляет 4096 октетов, а минимальная 19 октетов. Каждое сообщение имеет заголовок фиксированного размера. Объем информационных полей зависит от типа сообщения.

Формат BGP-сообщений об изменениях маршрутов

Рисунок 4.25

Поле маркер содержит 16 октетов и его содержимое может легко интерпретироваться получателем. Если тип сообщения "OPEN", или если код идентификации в сообщении OPEN равен нулю, то поле маркер должно быть заполнено единицами. Маркер может использоваться для обнаружения потери синхронизации в работе BGP-партнеров. Поле длина имеет два октета и определяет общую длину сообщения в октетах, включая заголовок. Значение этого поля должно лежать в пределах 19-4096. Поле тип представляет собой код разновидности сообщения и может принимать следующие значения:

1 OPEN (открыть)
2 UPDATE (изменить)
3 NOTIFICATION (внимание)
4 KEEPALIVE (еще жив)

После того как связь на транспортном протокольном уровне установлена, первое сообщение, которое должно быть послано - это OPEN. При успешном прохождении этого сообщения партнер должен откликнуться сообщением KEEPALIVE ("Еще жив"). После этого возможны любые сообщения. Кроме заголовка сообщение OPEN содержит следующие поля (рисунок 4.26):

Формат сообщения OPEN

Рисунок 4.26

Поле версия описывает код версии используемого протокола, на сегодня для BGP он равен 4. Двух-октетное поле моя автономная система определяет код AS отправителя. Поле время сохранения характеризует время в секундах, которое отправитель предлагает занести в таймер сохранения. После получения сообщения OPEN BGP-маршрутизатор должен выбрать значение времени сохранения. Обычно выбирается меньшее из полученного в сообщении OPEN и значения, определенного при конфигурации системы (0-3сек). Время сохранения определяет максимальное время в секундах между сообщениями KEEPALIVE и UPDATE или между двумя UPDATE-сообщениями. Каждому узлу в рамках BGP приписывается 4-октетный идентификатор (BGP-identifier, задается при инсталляции и идентичен для всех интерфейсов локальной сети). Если два узла установили два канала связи друг с другом, то согласно правилам должен будет сохранен канал, начинающийся в узле, BGP-идентификатор которого больше. Предусмотрен механизм разрешения проблемы при равных идентификаторах.