Дибров М.В. Маршрутизаторы

Подождите немного. Документ загружается.

R1 R2

Hello

D:224 .0.0.10

S:10.0.0.1

AS:200

K:1,0,1,0,0

10.1.1.0/30

Hello

D:224 .0.0.10

S:10.0.0.2

AS:200

K:1,0,1,0,0

Update

D:10.0.0.2

S:10.0.0.1

Sq:1

A:0

Update

D:10.0.0.1

S:10.0.0.2

Sq:1

A:1

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

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

Update

D:10.0.0.2

S:10.0.0.1

Sq:2

A:0

ROUTES ...

ACK

D:10.0.0.1

S:10.0.0.2

Sq:0

A:2

Update

D:10.0.0.1

S:10.0.0.2

Sq:2

A:0

ROUTES ...

ACK

D:10.0.0.2

S:10.0.0.1

Sq:0

A:2

Таблица соседства Таблица соседства

Таблица топологии Таблица топологии

Таблица

маршрутизации

Таблица

маршрутизации

Установка двунаправленных соседских отношений

Обмен

модифицированными

Hello пакетами

Обмен таблицами топологии

Рисунок 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

6.6.2 Разрыв соседских отношений

В стабильной сети EIGRP маршрутизатор ожидает установленное вре-

мя, и если за это время от соседа не пришло ни одного пакета, то EIGRP

маршрутизатор считает, что сосед находится в нерабочем состоянии.

Если маршрутизатор не может переустановить связь с соседом, он уда-

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

альтернативные маршруты для сетей получателей, которые были доступны по

удаленным маршрутам.Максимальное из стандартных времен задержки рав-

няется 180 секундам, может показаться, что такое время ожидания слишком

большое, однако оно задается для очень низкоскоростных каналов связи, по

которым могут быть подключены не критичные к задержкам удаленные узлы.

В высокоскоростных сетях или в сетях с трафиком от систем реального

времени даже минимальная задержка в 15 секунд может быть критична.

Поэтому ставятся дополнительные условия для сброса таймера ожидания, что

позволяет сети сходиться быстрее.

Если сеть не стабильна и в ней происходят изменения маршрутов, вы-

шестоящие маршрутизаторы посылают обновления маршрутной информации

нижестоящим маршрутизаторам, а нижестоящие маршрутизаторы не отвеча-

ют на эти обновления, вышестоящие маршрутизаторы пытаются 16 раз по-

вторно отослать обновление.

Повторные попытки передачи обновлений производятся по истечении

RTO. После 16 попыток передать обновление маршрутизатор разрывает со-

седские отношения. Это позволяет сети сходиться быстрее, чем по истечению

таймера ожидания.

6.6.3 Запланированное отключение

Для ускорения сходимости сети при штатных отключениях маршрути-

заторов, например, при перезагрузке или перезапуске процесса маршрутиза-

ции в ОС IOS начиная с версий 12.3(2) была добавлена возможность рассыл-

ки сообщений Goodbye (Рисунок 6.7).

FSS

Рисунок 6.7 – Рассылка пакетов Goodbye

115

Данные сообщения отключаемый маршрутизатор рассылает со всех

свои интерфейсов по групповому адресу 224.0.0.10. Сообщение представляет

собой модифицированный Hello пакет, в котором все весовые значения уста-

новлены в значение 255.

Рассылка Goodbye пакетов позволяет соседним маршрутизаторам более

оперативно произвести перерасчет своих таблиц топологии, для исключения

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

общение, чем это было бы при использовании таймеров ожидания. При полу-

чении Goodbye пакета маршрутизатор, поддерживающий данную возмож-

ность, выведет сообщение представленное в примере 6.3.

Пример 6.3 – Сообщение о получении Goodbye пакета

*Feb 16 19:07:01.191 KRSK: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor

10.95.1.5 (FastEthernet0/1) is down: Interface Goodbye received

Если маршрутизатор не поддерживает Goodbye пакеты, то при получе-

нии такого пакета он выведет сообщение представленное в примере 6.4.

Пример 6.4 – Обработка Goodbye пакета маршрутизатором со старым

IOS

*Feb 16 19:07:01.191 KRSK: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor

10.95.1.5 (FastEthernet0/1) is down: K-value mismatch

Как видно соседские отношения все равно будут разорваны, так как в

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

совых коэффициентов.

6.6.5 Меры обеспечения стабильности протокола EIGRP

В протоколе EIGRP реализованы два из наиболее распространенных

способов обеспечения стабильности дистанционно-векторных протоколов:

обратное обновление и правило расщепления горизонта.

Как обычно, обратное обновления – это обновления, объявляющие сети

получатели с метрикой, равной бесконечности. В протоколе EIGRP бесконеч-

ность обозначается объявлением метрики маршрута, равной 4 294 967 295

или в шестнадцатеричном виде 0xFFFFFFFF.

116

6.7 Алгоритм DUAL

Алгоритм DUAL представляет собой машину с конечным числом состо-

яний осуществляющую отслеживание всех маршрутов объявляемых соседя-

ми. Алгоритм DUAL использует метрики маршрутов для определения лучше-

го маршрута до сети получателя.

Метрика маршрута до сети получателя (выполнимое расстояние – FD)

рассчитывается суммированием метрики заявленной соседом (заявленное

расстояние – AD) и метрики маршрута до соседа заявившего этот маршрут.

Маршрутизатор объявивший маршрут с самой низкой метрикой стано-

вится преемником, соседом на которого будут передаваться пакеты до сети

получателя. Может быть несколько преемников, если они имеют одинаковые

FD до сети получателя. Все преемники помещаются в таблицу маршрутиза-

ции.

Алгоритм DUAL может вычислить резервный маршрут через вероятно-

го преемника. Маршрутизатор может быть выбран алгоритмом DUAL в каче-

стве вероятного преемника, если заявленное им расстояние до сети получате-

ля меньше чем выполнимое расстояние до сети получателя через маршрутиза-

тор преемник. Вероятные преемники не заносятся в таблицу маршрутизации,

а хранятся в таблице топологии. В ней могут присутствовать более одного ве-

роятного преемника.

Если маршрутизатор преемник становится недоступным, а для данного

маршрута есть вероятный преемник, то он заносится в таблицу маршрутиза-

ции на место преемника, при этом не производятся дополнительные перерас-

четы маршрутов.

Если маршрутизатор преемник становится недоступным, а в таблице

топологии отсутствуют вероятные преемники, то алгоритму DUAL необходи-

мо произвести выборы нового преемника, если это возможно, что потребует

некоторого времени, в течение которого пакеты до сети получателя отправ-

ляться не будут.

Для сегмента сети передачи данных изображенной на рисунке 6.8,

маршрутизатор R2 объявляет маршрутизатору R3 сеть 10.1.1.0/24 с заявлен-

ным расстоянием (AD) 1000. Маршрутизатор R3 заносит в свою таблицу то-

пологии заявленное расстояние маршрутизатором R2 до сети 10.1.1.0/24 и вы-

числяет выполнимо расстояние (FD) для этой сети через маршрутизатор R2,

которое равняется 2000. Маршрутизатор R4 также объявляет маршрутизатору

R3 сеть 10.1.1.0/24, но с заявленным расстоянием (AD) 1500. Маршрутизатор

R3 также заносит в таблицу топологи AD от маршрутизатора R4 и вычисляет

FD через него, равное 3000. Исходя из полученных данных, маршрутизатор

R3 назначает преемником для сети 10.1.1.0/24 маршрутизатор R2, так как FD

через маршрутизатор R2 до сети 10.1.1.0/24 наименьшее.

117

Сеть FD AD Topology

10.1.1.0/24 2000

Via R2 2000 1000 S

Via R4 3000 1500 FS

10.1.1.0/24

R2 R4

1000

500

1500

Рисунок 6.8 – Выбор преемника и вероятного преемника

Однако AD заявленное маршрутизатором R4 до сети 10.1.1.0/24 меньше

FD преемника, назначенного маршрутизатором R3, следовательно, маршрути-

затор R3 имеет право назначить маршрутизатор R4 вероятным преемником

для сети 10.1.1.0/24.

10.1.1.0/24

R2 R4



Сеть FD AD Topology

10.1.1.0/24 3000

Via R2 2000 1000

Via R4 3000 1500 S

1000

500

1500

Рисунок 6.9 – Действия маршрутизатора при недоступности преемника

118

Если канал связи между маршрутизаторами R2 и R3 выходит из строя

(Рисунок 6.9), маршрутизатор R3 вычеркивает из таблицы топологии запись о

маршрутизаторе R3, преемником для сети 10.1.1.0/24 становиться маршрути-

затор R4 и этот маршрут записывается в таблицу маршрутизации. Других

действий маршрутизатор R3 не производит, при этом передача пользователь-

ского трафика не прерывается.

6.7.1 Работа алгоритма DUAL

На рисунке 6.10 изображен сегмент сети, в котором маршрутизатор R4

не может выбрать для сети 10.1.1.0/24 вероятного преемника, так как AD

заявленное маршрутизаторами R3 и R5 больше FD через маршрутизатор R2

назначенного маршрутизатором R4 преемником для сети 10.1.1.0/24.

Сеть FD AD Topology

10.1.1.0/24 3

Via R 2 3 1 S

Via R 4 4 2 FS

Via R 5 4 3

10.1.1.0/24

R2 R4

R3 R5

Сеть FD AD Topology

10.1.1.0/24 2

Via R 2 2 1 S

Via R 3 5 3

Via R 5 5 4

Сеть FD AD Topology

10.1.1.0/24 3

Via R 4 3 2 S

Via R 3 4 3

Рисунок 6.10 – Сегмент сети без вероятного преемника

Что будет происходить в сети, если маршрутизатор R4 обнаружит недо-

ступность маршрутизатора R2 (Рисунок 6.11).

119

Сеть FD AD Topology

10.1.1.0/24 3

Via R 2 3 1 S

Via R 4 4 2 FS

Via R 5 4 3

10.1.1.0/24

R2 R4

R3 R5

Сеть FD AD Topology

10.1.1.0/24 2

Via R 2 2 1 S

Via R 3 5 3

Via R 5 5 4

Сеть FD AD Topology

10.1.1.0/24 3

Via R 4 3 2 S

Via R 3 4 3



Рисунок 6.11 – Маршрутизатор R2 недостижим

На маршрутизаторе R4 алгоритм DUAL маркирует маршрут до сети

10.1.1.0/24 через R2 как недостижимый и вычеркивает этот маршрут из табли-

цы топологии и таблицы маршрутизации.

На маршрутизаторе R4 алгоритм DUAL не имеет вероятного преемника

для сети и 10.1.1.0/24, поэтому он выставляет метрику маршрута на сеть

10.1.1.0/24 равную -1 (недостижима). Вероятный преемник не может быть

найден в таблице топологии и маршрут переводится из пассивного состояния

в активное. В активном состоянии маршрутизатор начинает рассылку запро-

сов соседям для определения нового преемника. Маршрутизатор R4 посылает

запросы на R3 и R5 для поиска альтернативного маршрута до сети 10.1.1.0/24.

В таблице топологии маршрутизатор R4 помечает что, он отправил запрос о

сети 10.1.1.0/24 маршрутизаторам R3 и R5. Маршрутизатор R5 получив

запрос на сеть 10.1.1.0/24 от маршрутизатора R4, который в его таблице топо-

логии назначен преемником, вычеркивает маршрут до сети 10.1.1.0/24 через

маршрутизатор R4 (Рисунок 6.12).

На маршрутизаторе R5 алгоритм DUAL маркирует маршрут до сети

10.1.1.0/24 через R4 как недостижимый и отсылает запрос о наличии маршру-

та до сети 10.1.1.0/24 маршрутизатору R3.

В это время маршрутизатор R3, получив запрос от R4 о маршруте до

сети 10.1.1.0/24, вычеркивает маршрут до сети 10.1.1.0/24 через маршрутиза-

тор R4 из своей таблицы топологии.

120