6.6 Функционирование протокола EIGRP
Протокол EIGRP использует в своей работе 5 типов служебных пакетов, описание которых приводится в таблице 6.1.
Таблица 6.1 – Типы служебных пакетов протокола EIGRP
Тип |
Назначение пакета |
|
|
Пакеты обновления рассылаются для обмена данными о маршру- |
|
Update (1) |
тах до сетей получателей. При изменении топологии сети марш- |
|
рутизатор рассылает пакеты обновления всем маршрутизаторам |
||
|
из его таблицы соседства. |
|
|
Пакеты запросы рассылаются всем соседям с целью нахождения |
|
Query (3) |
маршрута до сети получателя, когда преемник маршрута стано- |
|
|
виться недоступен. |
|
Reply (4) |
Пакет отсылается в ответ на пакет запроса. |
|
|
Пакеты приветствия используются для поиска соседей и дальней- |
|
Hello (5) |
шего подтверждения работоспособности соседних маршрутизато- |
|
ров. Они рассылаются по групповому адресу и не требуют под- |
||
|
||
|
тверждения. |
|
|
Пакет подтверждения используется для подтверждения получе- |
|
АСК (5) |
ния пакетов обновлений, запросов и ответов. Пакет ACK пред- |
|
ставляет собой пустой Hello пакет, в котором указан номер паке- |
||
|
||
|
та, получение которого подтверждается. |
После запуска протокола EIGRP на маршрутизаторе, он начинает рассылку Hello пакетов со всех активных интерфейсов по групповому адресу 224.0.0.10. Когда маршрутизатор получает на свой интерфейс Hello пакет от другого маршрутизатора, содержащий такой же номер автономной системы, между маршрутизаторами запускается процесс установки соседских отношений. Соседские отношения не устанавливаются, если не совпадают номера автономных систем или в полученных Hello пакетах содержаться отличные, от настроенных на маршрутизаторе, весовые коэффициенты.
Начиная с версии IOS 12.2(15)S в процесс установки соседских отношений между маршрутизаторами EIGRP были внесены изменения. Процесс установки маршрутизаторами под управлением IOS семейства 12.4 соседских отношений проиллюстрирован на рисунке 6.6.
110
Таблица соседства
Таблица топологии
Таблица
маршрутизации
Обмен модифицированными Обментаблицамитопологии Helloпакетами Установка двунаправленных соседских отношений
10.1.1.0/30
R1
Hello
D:224 .0.0.10
S:10.0.0.1
AS:200
K:1,0,1,0,0
Update
D:10.0.0.2
S:10.0.0.1
Sq:1
A:0
ACK
D:10.0.0.2
S:10.0.0.1
Sq:0
A:1
Hello
D:224 .0.0.10
S:10.0.0.1
AS:200
K:1,0,1,0,0
N-IP:10.0.0.2
Update
R2
Hello
D:224 .0.0.10 S:10.0.0.2
AS:200
K:1,0,1,0,0
Update
D:10.0.0.1
S:10.0.0.2
Sq:1
A:1
Hello
D:224 .0.0.10 S:10.0.0.1
AS:200
K:1,0,1,0,0 N-IP:10.0.0.1
ACK
D:10.0.0.2 |
|
S:10.0.0.1 |
D:10.0.0.1 |
Sq:2 |
S:10.0.0.2 |
A:0 |
Sq:0 |
ROUTES ... |
A:2 |
ACK |
Update |
|
|
|
D:10.0.0.1 |
D:10.0.0.2 |
S:10.0.0.2 |
S:10.0.0.1 |
Sq:2 |
Sq:0 |
A:0 |
A:2 |
ROUTES ... |
Таблица соседства
Таблица топологии
Таблица
маршрутизации
Рисунок 6.6 – Процесс установки соседских отношений
После получения на своем интерфейсе Hello пакета от соседнего маршрутизатора, маршрутизатор R1 отсылает Update пакет по индивидуальному адресу соседнего маршрутизатора. Это делается, для того, чтобы между маршрутизаторами установились двунаправленные отношения.
После получения маршрутизатором R2 отсылает Update пакет по индивидуальному адресу маршрутизатора R1, причем этот Update пакет является и подтверждением о получении предыдущего пакета, о чем свидетельствует поле A (Acknowledge) с указанным номером пакета, получение которого подтверждается. Добавление возможности подтверждения ранее полученного пакета с помощью посылки следующего Update пакета позволяет значительно снизить количество передаваемых ACK пакетов.
111
Подобный процесс установки двунаправленных соседских отношений был принят до версии IOS 12.2(15)S в которой были внесены изменения в данный процесс. Начиная с версии IOS 12.2(15)S в процесс установки соседских отношений был добавлен обмен модифицированными Hello пакетами которые содержат адрес соседнего маршрутизатора. Но обмен Update пакетами все же был оставлен в процессе установки для совместимости работы различных версий IOS.
После установки соседских отношений в процессе, которого ведется заполнение таблицы соседства, маршрутизаторы приступают к обмену Update пакетами, содержащими копии таблиц топологии.
Стоит заметить, что обмен Update пакетами ведется по индивидуальным адресам маршрутизаторов, и каждый Update пакет подтверждается индивидуальным ACK пакетом.
Такой процесс обмена Update пакетами реализован в версиях IOS семейства 12.4. В более старых версиях IOS Update пакетs рассылаются по групповому адресу, а процесс подтверждения аналогичен тому который происходит при установке соседских отношений.
Процесс установки соседских отношений и обмена Update пакетами зависит от версий IOS запущенных на соседних маршрутизаторах и может отличаться от представленного на рисунке 6.6.
После заполнения таблицы топологии маршрутизаторы преступают к процессу построения таблиц маршрутизации.
6.6.1 Надежность передачи пакетов протокола EIGRP
Транспортный протокол RTP (Протокол ускоренной передачи данных – Rapid Transport Protocol) отвечает за гарантированную, упорядоченную доставку EIGRP пакетов ко всем соседним маршрутизаторам. Протокол RTP поддерживает возможность смешанной передачи групповых и индивидуальных пакетов. Для большей эффективности только определенные типы пакетов передаются гарантированно.
В сетях коллективного доступа, имеющих возможность групповой рассылки, таких как Ethernet не обязательно гарантированно рассылать Hello пакеты. По этой причине протокол EIGRP рассылает единственный групповой Hello пакет, содержащий индикатор, информирующий всех преемников о том, что получение пакетов не нуждается в подтверждении отправкой ACK пакета.
Пакеты, несущие маршрутизирующую информацию, такие как Update, Query и Reply, рассылаются гарантированно. Каждый пакет, который посылается гарантированно, нумеруется и требует явного подтверждения. Нумерация пакетов и подтверждение каждого пронумерованного пакета обеспечивают надежность при их передаче.
112
Протокол RTP имеет механизм быстрой рассылки широковещательных пакетов в случае, когда есть задержанные неподтвержденные пакеты, что способствует уменьшению времени сходимости сети при наличии каналов с разными скоростными характеристиками.
Протокол RTP обеспечивает обмен данными между соседними маршрутизаторами. Для каждого соседа ведется свой список повторных передач, который содержит список гарантированных пакетов, которые были переданы, но не были подтверждены за время RTO. Если таймер RTO истекает, а пакет остается неподтвержденным протокол RTP производит отсылку копии данного пакета. Протокол RTP производит до 16 попыток повторной передачи пакета до истечения таймера ожидания. Если сосед все так же не отвечает, маршрутизатор объявляет соседа утерянным.
Маршрутизатор ведет учет отдельного времени RTO для каждого соседа. Чтобы вычислить RTO, маршрутизатор сначала измеряет время кругового обращения (RTT, roundtrip time) для каждой транзакции протокола RTP. Время RTT определяется как разность между временем отправки пакета протокола EIGRP и временем получения подтверждения. Маршрутизатор продолжает измерять RTT для каждого подтвержденного EIGRP пакета. Каждый раз после измерения RTT маршрутизатор использует полученное значение для вычисления времени SRTT с использованием формулы (6.5).
SRTT нов = SRTT пред * 0.8 + RTT * 0.2 |
(6.5) |
где SRTT пред – предыдущее рассчитанное время SRTT.
Время RTO рассчитывается на основе SRTT при помощи формулы
(6.6).
RTO = 6 * max (SRTT, PI) |
(6.6) |
где PI – специальная величина, индивидуальным образом вычисляемая для каждого EIGRP пакета.
Рассчитанное время RTO используется только для первой повторной передачи. Каждый раз, когда требуется последующая повторная передача, маршрутизатор будет пересчитывать RTO в соответствии с формулой (6.7).
RTO нов = RTO пред * 1.5 |
(6.7) |
где RTO пред – RTO, рассчитанное для предыдущей повторной передачи. Однако время RTO не может быть меньше 200 миллисекунд или
больше 5 секунд. При таком условии действительная формула для вычисления RTO принимает вид (6.8).
113
RTO нов = min (5c, max (200мс, RTO пред * 1.5)) |
(6.8) |
В процессе схождения протокол EIGRP может генерировать огромное количество служебных пакетов, которые могут занять большую часть имеющейся пропускной способности некоторых медленных каналов, если не уменьшить скорость их передачи.
Когда процесс EIGRP на маршрутизаторе создает служебный пакет, маршрутизатор не отправляет их немедленно, а помещает его в очередь на выходном интерфейсе. Точно так же служебный пакет из выходной очереди не отправляются при первой же возможности. Для каждого служебного пакета маршрутизатор вычисляет время PI, в течение которого он должен находиться в очереди, перед тем как его можно будет отправить.
Время PI вычисляется на основе размера служебного пакета, пропускной способности интерфейса и процентной доли этой пропускной способности, которую позволено занять протоколу EIGRP. Эта доля является настраиваемой величиной (EBP, EIGRP bandwidth percentage – доля пропускной способности, выделенная для EIGRP), которая по умолчанию равна 50%. Маршрутизатор вычисляет PI для служебного пакета с использованием этих трех составляющих по формуле (6.9).
PI = (S / BW )* EBP |
(6.8) |
где S – это размер служебного пакета EIGRP PDU в битах;
BW – пропускная способность интерфейса в битах в секунду; EBP – измеряется в долях единицы (по умолчанию 50%, или 0.5).
Использование надежного группового трафика протоколами маршрутизации очень эффективно, однако всегда есть возможность задержек в сетях коллективного доступа, где существует множество соседей. В такой ситуации следующий надежный групповой пакет не может быть передан до тех пор, пока от всех соседей не будет получено подтверждение о том что предыдущий надежный групповой пакет был получен. Именно такие ситуации и призван решать протокол RTP. Соседи, обнаружившие задержку, пересылают неподтвержденные групповые пакеты как индивидуальные пакеты тем соседям, которые не подтвердили получение группового пакета. Это позволяет надежной групповой передачи работать с другими получателями, без каких либо задержек.
Величина таймера переключения с группового на индивидуальный трафик, так же как и таймера RTO зависит от времени SRTT.
114