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

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

Продолжение таблицы 5.6

Параметр Описание

holddown После истечения времени интервала

«возможно не доступен» маршрутиза-

тор, если это возможно использует аль-

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

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

ресата как недоступного и вычеркивает

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

По умолчанию 180 секунд.

flush Время в течении которого маршрут не

удаляется из таблицы маршрутизации.

Это время должно быть больше чем In-

valid, если оно меньше не может на-

чаться отсчет интервала Holddown, при

истечении которого в таблицу маршру-

тизации устанавливается альтернатив-

ный маршрут. По умолчанию длитель-

ность интервала 240 секунд.

5.8.2 Совместное использование в сети протокола RIP v1 и v2

По умолчанию ОС Cisco IOS принимает как пакеты RIP v1 так и RIP v2,

однако посылает пакеты только RIP v1. Это сделано с целью обратной совме-

стимости протоколов.

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

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

приводится в примере 5.7.

Пример 5.7 – Синтаксис команды version

(config-router)# version {1 | 2}

(config-router)# no version

Для более гибкой настройки маршрутизаторов в случае одновременного

использования в сети маршрутизаторов с разными версиями протокола RIP

используются команды ip rip send version и ip rip receive version, синтаксис ко-

манд приводится в примере 5.8.

Пример 5.8 – Синтаксис команд ip rip send version и ip rip receive version

(config-if)# ip rip receive version [1] [2]

(config-if)# no ip rip receive version

(config-if)# ip rip send version [1] [2]

(config-if)# no ip rip send version

Пример совместной работы маршрутизаторов с разными версиями про-

токола RIP приводится на рисунке 5.11.

r2# router rip

version 1

network 10.0.0.0

r1# router rip

version 2

network 10.0.0.0

interface serial 1

ip rip send version 1

ip rip receive version 1

S1 10.1.1.0/24

Рисунок 5.11 – Использование протокола RIP различных версий

5.8.3 Распределение нагрузки в протоколе RIP

Под распределением нагрузки понимается использование механизма,

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

маршрутов к сети получателю.

Протокол RIP способен осуществлять распределение нагрузки по

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

вышать 16. На рисунке 5.12 приведен пример распределения нагрузки по

четырем маршрутам с равной метрикой.

R1 R2

Рисунок 5.12 – Распределение нагрузки в протоколе RIP

Поскольку метрикой протокола RIP является количество переходов и

скорость каналов при этом не учитывается. Поэтому канал со скоростью 56К-

бит/с будет обрабатывать, столько же данных что и канал со скоростью

155Мбит/с.

Маршруты с равной стоимостью обычно можно найти с помощью ко-

манды show ip route до конкретной сети. В примере 5.9 приводится информа-

ция, которая выдает команда show ip route для конкретной сети.

Пример 5.9 – Вывод маршрутов с равной стоимостью

r1# show ip route 10.1.2.0

Routing entry for 10.1.2.0/24

Known via "rip", distance 120, metric 1

Redistributing via rip

Last update from 10.1.4.2 on FastEthernet0/0, 00:00:18 ago

Routing Descriptor Blocks:

10.1.4.1, from 10.1.4.1, 00:02:45 ago, via FastEthernet0/0

Route metric is 1, traffic share count is 1

* 10.1.4.2, from 10.1.4.2, 00:00:18 ago, via FastEthernet0/0

Route metric is 1, traffic share count is 1

В приведенном выше примере имеются два описательных блока. Каж-

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

символ «*», указывающий, что блок соответствует активному маршруту, ко-

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

5.8.4 Настройка протокола RIP для работы в сетях NBMA

Известно, что протокол RIP, как и большинство протоколов динамиче-

ской маршрутизации использует механизм широковещательной рассылки.

Однако существуют технологии построения сетей, поддерживающие множе-

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

К таким технологиям относятся сети Frame Relay, ATM и X25. Данные сети

получили название NBMA (non broadcast multi access) не широковещательные

сети группового доступа.

В сетях NBMA может быть больше двух маршрутизаторов, но из–за от-

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

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

NBMA групповой пакет, посланный одним маршрутизатором, не может быть

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

протоколу RIP необходимо предоставить информацию о соседних маршрути-

заторах. Для указания соседнего маршрутизатора, с которым требуется обме-

ниваться информацией, используется команда neighbor, синтаксис команды

приводится в примере 5.10.

Пример 5.10 – Синтаксис команды neighbor

(config-router)# neighbor ip-address

(config-router)# no neighbor ip-address

5.8.5 Механизм инициированных обновлений в протоколе RIP

Модификации протокола RIP позволяют использовать инициированные

обновления маршрутной информации. В RFC 2091 регламентируется исполь-

зование инициированных обновлений маршрутной информации. Инициация

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

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

таймер.

Ниже перечислены события, которые инициируют посылку сообщений

о корректировках:

– Маршрутизатор запрашивает обновленную информацию о маршрутах

при инициализации. Происходит обмен полными копиями таблиц маршрути-

зации.

– В сети имеют место изменения. Посылается информация только об

изменениях в сети.

– Переход состояния канала из включенного в выключенное или наобо-

рот.

Инициированные обновления маршрутной информации должны ис-

пользовать три дополнительных типа пакетов RIP, а также расширенный заго-

ловок сообщения длиной в 4 байта. Обе версии, RIP v1 и RIP v2, поддержива-

ют все три типа пакетов и расширенный 4 байтный заголовок.

Версия

Неиспользуемое поле

(заполняется нулями )

88 8 8

32 бита

Flush Sequence Number

Идентификатор семейства

адресов

Ноль (RIP v 1)

Тег маршрута (RIP v2)

Записи RIP

88 8 8

32 бита

Запись маршрута

Поля (максимум 25)

Записи RIP

Версия

Flush Sequence Number

88 8 8

32 бита

Версия

Update Request (9)

Update Acknowledge (11)

Update Response (10)

Рисунок 5.13 – Дополнительные типы пакетов протокола RIP

На рисунке 5.13 показан формат трех дополнительных типов пакетов

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

формации. В таблице 5.7 приведено описание пакетов.

Таблица 5.7 – Дополнительные пакеты протокола RIP

Ко-

манда

Значение

9 Запрос. Посылается маршрутизатором для запроса информации о

корректировках маршрутной информации.

10 Ответ. Посылается в ответ за запрос и включает любо полную ко-

пию таблицы маршрутизации, либо измененные маршруты в зави-

симости от содержания запроса.

11 Подтверждение. Посылается для подтверждения приема обновле-

ния маршрутной информации.

Всем ответам (10) назначаются номера пакетов в последовательности.

Каждый ответ увеличивает номер очередного пакета на единицу. Маршрути-

затор, запросивший информацию, при получении этих ответом должен под-

твердить получение информации о маршрутах, переданной внутри дейтаграм-

мы, путем посылки подтверждения с соответствующим номером пакета в по-

следовательности. Маршрутизатор, отвечающий на запрос, предполагает, что

неподтвержденные дейтаграммы утеряны и должны быть переданы повторно.

К сожалению, механизм инициированных обновлений маршрутной ин-

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

RFC 2091 разрабатывался в первую очередь для реализации динамической

маршрутизации по модемным соединениям. Данный механизм не поддержи-

вается на других типах интерфейсов маршрутизаторов.

5.9 Тестирование и устранение ошибок в работе протокола RIP

Для проверки правильности созданной конфигурации протокола RIP

могут быть использованы несколько команд. Двумя наиболее часто использу-

емыми командами являются show ip route и show ip protocols.

При вводе команды show ip protocols отображается информация обо

всех протоколах IP маршрутизации, сконфигурированных на маршрутизаторе

(Пример 5.11).

Пример 5.11 – Информация, выводимая командой show ip protocols

r4#show ip protocols

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is not set

Incoming update filter list for all interfaces is not set

Sending updates every 30 seconds, next due in 26 seconds

Invalid after 180 seconds, hold down 180, flushed after 240

Redistributing: rip

Default version control: send version 2, receive version 2

Interface Send Recv Triggered RIP Key-chain

FastEthernet0/0 2 2 AUTH

Serial0/0/0 2 2 AUTH

Automatic network summarization is not in effect

Maximum path: 4

Routing for Networks:

10.0.0.0

Passive Interface(s):

FastEthernet0/1

FastEthernet0/1.811

Loopback0

Routing Information Sources:

Gateway Distance Last Update

10.93.1.1 120 00:00:02

10.93.1.34 120 00:00:11

Distance: (default is 120)

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

большинства параметров протокола RIP. Ниже перечислены островные тести-

руемые параметры конфигурации.

– Включен ли на требуемых интерфейсах протокол RIP.

– Какие интерфейсы принимают и отправляют обновления маршрутной

информации.

– Правильная ли версия обновлений маршрутной информации исполь-

зуется.

– Анонсирует ли маршрутизатор требуемые сети.

– Включен ли механизм аутентификации сторон.

Команда show ip route или команда show ip route rip отображает таблицу

маршрутизации построенную маршрутизатором. Вторая команда отображает

только маршруты из таблицы маршрутизации полученные протоколом RIP,

такие маршруты помечаются буквой «R» (Пример 5.12).

Пример 5.12 – Таблица маршрутизации полученная от протокола RIP

r2#show ip route rip

.. .. ..

Gateway of last resort is 172.16.0.1 to network 0.0.0.0

172.16.0.0/28 is subnetted, 1 subnets

R 172.16.0.16 [120/1] via 172.16.0.1, 00:01:11, Serial0/0/0

10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks

R 10.89.2.64/26 [120/3] via 172.16.0.1, 00:01:11, Serial0/0/0

R 10.89.1.64/26 [120/1] via 10.93.1.18, 00:01:11, Serial0/1/0

R 10.95.2.7/32 [120/3] via 172.16.0.1, 00:01:11, Serial0/0/0

R 10.95.2.6/32 [120/3] via 172.16.0.1, 00:01:12, Serial0/0/0

R 10.89.2.0/26 [120/3] via 172.16.0.1, 00:01:12, Serial0/0/0

R 10.89.1.0/26 [120/1] via 10.93.1.2, 00:01:12, Serial0/0/1

R 10.89.0.0/28 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0

R 10.95.2.3/32 [120/2] via 172.16.0.1, 00:01:13, Serial0/0/0

R 10.95.0.1/32 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0

R 10.93.2.0/26 [120/2] via 172.16.0.1, 00:01:13, Serial0/0/0

R 10.93.1.32/28 [120/1] via 10.93.1.18, 00:01:13, Serial0/1/0

[120/1] via 10.93.1.2, 00:01:13, Serial0/0/1

R* 0.0.0.0/0 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0

Большинство ошибок в настройке протокола RIP связано с некоррект-

ным выполнением команд network, с разрывами в сетях или с аутентификаци-

ей сторон. Первичным инструментом для обнаружения перечисленных оши-

бок является команда debug ip rip.

При выполнении команды debug ip rip отображаются обновления марш-

рутной информации протокола RIP по мере их отправки и получения (Пример

5.13).

Пример 5.13 – Информация об обмене маршрутной информацией

r4#debug ip rip

*Feb 15 20:19:46.007 KRSK: RIP: received packet with MD5 authentication

*Feb 15 20:19:46.007 KRSK: RIP: received v2 update from 10.93.1.34 on FastEth-

ernet0/0

*Feb 15 20:19:46.007 KRSK: 10.89.0.0/28 via 0.0.0.0 in 3 hops

*Feb 15 20:19:46.007 KRSK: 10.89.1.64/28 via 0.0.0.0 in 1 hops

*Feb 15 20:19:46.007 KRSK: 10.89.2.0/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.007 KRSK: 10.89.2.16/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.007 KRSK: 10.89.2.32/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.007 KRSK: 10.89.2.48/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.011 KRSK: 10.89.2.64/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.011 KRSK: 10.89.2.80/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.011 KRSK: 10.89.2.96/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.011 KRSK: 10.89.2.112/28 via 0.0.0.0 in 5 hops

*Feb 15 20:19:46.011 KRSK: 172.16.0.0/28 via 0.0.0.0 in 2 hops

*Feb 15 20:19:46.011 KRSK: RIP: received packet with MD5 authentication

*Feb 15 20:19:46.011 KRSK: RIP: received v2 update from 10.93.1.34 on FastEth-

ernet0/0

*Feb 15 20:19:46.011 KRSK: 172.16.0.16/28 via 0.0.0.0 in 3 hops

*Feb 15 20:19:46.243 KRSK: RIP: sending v2 update to 224.0.0.9 via FastEther-

net0/0 (10.93.1.33)

*Feb 15 20:19:46.243 KRSK: RIP: build update entries

*Feb 15 20:19:46.243 KRSK: 10.89.0.0/28 via 0.0.0.0, metric 3, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.1.0/28 via 0.0.0.0, metric 1, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.1.16/28 via 0.0.0.0, metric 1, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.1.32/28 via 0.0.0.0, metric 1, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.1.48/28 via 0.0.0.0, metric 1, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.0/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.16/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.32/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.48/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.64/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.80/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.96/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 10.89.2.112/28 via 0.0.0.0, metric 5, tag 0

*Feb 15 20:19:46.243 KRSK: 172.16.0.0/28 via 0.0.0.0, metric 2, tag 0

Перечисленные выше команды предоставляют информацию, которая

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

6 Протокол EIGRP

Протокол EIGRP (Enhanced Interior Getaway Routing Protocol) – расши-

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

версией протокола IGRP. Он является фирменным протоколом корпорации

Cisco представленным в 1994 году, однако в настоящее время ряд сторонних

производителей лицензировал EIGRP для реализации в своем телекоммуника-

ционном оборудовании.

Протокол EIGRP берет свое начало от дистанционно–векторной марш-

рутизации. Как и его предшественник, протокол IGRP, EIGRP прост в на-

стройке и нашел применение в большом спектре сетевых топологий.

По способу представления маршрутной информации протокол EIGRP

все же является дистанционно-векторным протоколом. Сети получатели в

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

щих» маршрутизаторов. Подобно другим дистанционно-векторным протоко-

лам, протокол EIGRP не обладает полными знаниями о топологии сети пере-

дачи данных.

Однако в основе протокола EIGRP лежит не алгоритм Беллмана-Форда,

а алгоритм DUAL (Diffusing Update Algorithm), алгоритм диффузионного об-

новления. Сам алгоритм ведет свое начало от работы Эдсгера Дейкстры и К.

С. Шольтена (Edsger Dijkstra, C. S. Sholten) «Termination Detection for Diffus-

ing Computations» изданной в 1980 году.

Алгоритм DUAL подкреплен многими математическими работами,

основной из которых является «Loop-Free Routing Using Diffusing Computa-

tions», написанная Х. Х. Гарсия-Луна-Асевесом (J. J. Garcia-Luna-Aceves).

6.1 Алгоритм диффузионного обновления

Алгоритм DUAL лежит в основе протокола EIGRP. Поэтому рассмот-

рим его первым. Начнем с классического алгоритма DUAL. А затем рассмот-

рим необходимые изменения для адаптации алгоритма для протокола марш-

рутизации EIGRP.

Протоколы маршрутизации на основе дистанционно-векторного алго-

ритма Беллмана-Форда, имеют две фундаментальные проблемы:

– Маршрутные петли;

– Счет до бесконечности.

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

знают о действительной топологии сети передачи данных. Все что они знают,

это какие сети получатели доступны через каждого из соседей. Когда в сети

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

основании новых метрик, которые им становятся известны.

До достижения сходимости сети, метрики могут неточно отражать дей-

ствительную стоимость маршрутов, что может привести к маршрутным

петлям.

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

ляется введение метрики равной бесконечности, при достижении которой

маршрут считается недоступным. Обычно маршрутизаторам необходимо вы-

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

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

ционно-векторных алгоритмов значительно увеличивается. Чтобы ускорить

схождение сети, приходиться применять дополнительные методы: правило

расщепления горизонта, метод обратного обновления, мгновенные обновле-

ния и таймеры удержания информации.

Вспомним, какую информацию маршрутизаторы получают друг от дру-

га и как они ее используют. Маршрутизаторы в случае использования алго-

ритма Беллмана-Форда, обмениваются маршрутными обновлениями, содер-

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

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

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

сети.

Маршрутизатор, получающий маршрутное обновление, использует мет-

рику из этого обновления для расчета своей собственной метрики. В

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

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

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

здает маршрут к этой сети. Маршрут указывает на маршрутизатор, который

отправил маршрутное обновление, и содержит только что рассчитанную мет-

рику. Эта метрика затем используется маршрутизатором в своих собственных

маршрутных обновлениях об этой сети получателе.

В такой ситуации маршрутизатор, получающий маршрутное обновле-

ние, отбрасывает фрагмент очень важной информации – метрику маршрута

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

чета своей метрики, а затем эта метрика забывается.

Возникает вопрос: что такого ценного в заявленном расстоянии? На ри-

сунке 6.1 изображена топология сети, с маршрутизатором R1 в центре. У

маршрутизатора R1 имеется маршрут к некоторой сети получателю (СП) че-

рез маршрутизатор R2.

СП

100

105

Рисунок 6.1 – Обработка топологии сети

алгоритмом Беллмана-Форда

Стрелки с числами указывают, с какой метрикой маршрутизатор, с ко-

торого указывает стрелка, объявляет маршрут до СП на соответствующем ка-

нале связи. Числа в кругах указывают стоимость каналов связи. Маршрутиза-

торы вычисляют свои метрики сложением метрики из маршрутного обновле-

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

Маршрутизатор R1 изначально выбрал маршрутизатор R2 в качестве

следующего маршрутизатора к СП, поскольку объявленная метрика маршру-

тизатора R2 (100) в сумме со стоимостью канала связи до него (5) дала наи-

меньшее значение (100 + 5 = 105).

Расположение маршрутизаторов R4 и R5 таково, что независимо от

того, какой путь они изберут для передачи трафика, направленного до СП,

этот путь пролегает через маршрутизатор R1. Например, маршрутизатор R5

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

связи между двумя этими маршрутизаторами. Или же он может выбрать аль-

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

Этот путь сначала приводит трафик на маршрутизатор R4, который затем

передает его на маршрутизатор R1.

Как показано на рисунке метрика пути по альтернативному маршруту

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

тельно, маршрутизатор R5 выбирает альтернативный маршрут. Несмотря на

то, что объявляемая маршрутизатором R1 метрика (105) меньше, маршрутиза-

тор R5 выбирает маршрут через другого соседа, поскольку объявляемая сосе-

дом метрика (135) в сумме со стоимостью сегмента, дает меньшее значение

(135 + 5 = 140), чем метрика маршрута через маршрутизатор R1 (105 + 40 =

145).

100