Вы находитесь на странице: 1из 389

М.В.

ДИБРОВ

МАРШРУТИЗАТОРЫ
Учебное пособие

Красноярск 2008
2
Содержание

Введение..................................................................................................................10
Условные обозначения, используемые в пособии...........................................10
Графические символы.....................................................................................10
Соглашения по синтаксису командного языка.............................................11
1 Проектирование масштабируемых сетей передачи данных...........................12
1.1 Масштабируемые сети передачи данных...................................................12
1.2 Архитектура корпоративной сети передачи данных.................................16
1.3 Введение в технологию подсетей и ее обоснование.................................19
1.4 Применение технологии VLSM...................................................................24
1.5 Суммирование маршрутов...........................................................................27
1.6 Проектирование масштабируемого адресного пространства...................28
2 Принципы маршрутизации.................................................................................31
2.1 Определение маршрутизации......................................................................31
2.1.1 Маршрутизируемые и маршрутизирующие протоколы.....................31
2.1.2 Основные функции маршрутизаторов.................................................33
2.2 Концептуальные основы маршрутизации..................................................34
2.2.1 Таблицы маршрутизации.......................................................................34
2.2.2 Административное расстояние.............................................................35
2.2.3 Метрики маршрутов...............................................................................36
2.2.4 Построение таблицы маршрутизации..................................................37
2.3 Механизмы маршрутизации........................................................................37
2.3.1 Прямое соединение................................................................................38
2.3.2 Статическая маршрутизация.................................................................39
2.3.3 Настройка статических маршрутов......................................................40
2.3.4 Использование «плавающих» статических маршрутов......................41
2.3.5 Маршрутизация по умолчанию.............................................................42
2.4 Проверка и устранение ошибок в статических маршрутах......................44
3 Принципы динамической маршрутизации.......................................................45
3.1 Операции динамической маршрутизации..................................................46
3.1.1 Стоимость маршрута..............................................................................47
3.2 Внутренние и внешние протоколы маршрутизации.................................48
3.2.1 Понятие автономной системы и домена маршрутизации..................48
3.2.2 IGP – протоколы внутреннего шлюза..................................................49
3.2.3 EGP – протоколы внешнего шлюза......................................................49
3.3 Обзор классовых протоколов маршрутизации..........................................50
3.3.1 Суммирование маршрутов при классовой маршрутизации...............51
3.3.2 Суммирование маршрутов в разобщенных классовых сетях............52
3.4 Обзор бесклассовых протоколов маршрутизации.....................................53
3.4.1 Суммирование маршрутов при бесклассовой маршрутизации.........53
3.4.2 Суммирование маршрутов в разобщенных классовых сетях............55

3
3.5 Категории алгоритмов маршрутизации......................................................56
3.5.1 Особенности дистанционно-векторных протоколов..........................56
3.5.2 Маршрутизация по состоянию канала.................................................58
3.5.3 Гибридные протоколы маршрутизации...............................................61
3.6 Конфигурирование протокола маршрутизации.........................................61
4 Дистанционно-векторная маршрутизация........................................................65
4.1 Дистанционно-векторный алгоритм...........................................................65
4.1.1 Дистанционно-векторный алгоритм для протокола IP.......................67
4.2 Маршрутизация по замкнутому кругу........................................................69
4.3 Максимальное количество транзитных переходов...................................71
4.4 Применения принципа расщепления горизонта........................................72
4.5 Обратное обновление...................................................................................73
4.6 Таймеры удержания информации...............................................................74
4.7 Механизм мгновенных обновлений............................................................75
5 Протокол RIP.......................................................................................................77
5.1 Настройка протокола RIP.............................................................................78
5.2 Протокол RIP v1............................................................................................78
5.2.1 Заголовок и поля протокола RIP v1......................................................79
5.2.2 Команда – 1 байт....................................................................................80
5.2.3 Версия – 1 байт.......................................................................................80
5.2.4 Неиспользуемые поля – 2 байта............................................................80
5.2.5 Идентификатор семейства адресов – 2 байта......................................80
5.2.6 IP адрес – 4 байта....................................................................................81
5.2.6 Метрика – 4 байта...................................................................................81
5.3 Использование команды ip classless............................................................81
5.4 Недостатки протокола RIP v1......................................................................82
5.5 Протокол RIP v2............................................................................................82
5.5.1 Заголовок и поля протокола RIP v2......................................................83
5.5.2 Тег маршрута – 2 байта..........................................................................83
5.5.3 Маска подсети – 4 байта........................................................................83
5.5.4 Следующая пересылка – 4 байта...........................................................84
5.6 Аутентификация в протоколе RIP v2..........................................................84
5.6.1 Настройка аутентификации для протокола RIP..................................85
5.7 Суммирование маршрутов в протоколе RIP..............................................86
5.7.1 Распространение маршрута по умолчанию.........................................88
5.8 Расширенная настройка протокола RIP......................................................89
5.8.1 Таймеры протокола RIP.........................................................................89
5.8.2 Совместное использование в сети протокола RIP v1 и v2.................91
5.8.3 Распределение нагрузки в протоколе RIP............................................92
5.8.4 Настройка протокола RIP для работы в сетях NBMA........................93
5.8.5 Механизм инициированных обновлений в протоколе RIP................94
5.9 Тестирование и устранение ошибок в работе протокола RIP..................95
6 Протокол EIGRP..................................................................................................98

4
6.1 Алгоритм диффузионного обновления.......................................................98
6.2 Преимущества протокола EIGRP..............................................................103
6.3 Автономная система протокола EIGRP....................................................104
6.4 База данных протокола EIGRP..................................................................105
6.4.1 Таблица соседства................................................................................105
6.4.2 Таблица топологии...............................................................................107
6.5 Метрика протокола EIGRP........................................................................109
6.6 Функционирование протокола EIGRP......................................................110
6.6.1 Надежность передачи пакетов протокола EIGRP.............................112
6.6.2 Разрыв соседских отношений..............................................................115
6.6.3 Запланированное отключение.............................................................115
6.6.5 Меры обеспечения стабильности протокола EIGRP........................116
6.7 Алгоритм DUAL.........................................................................................117
6.7.1 Работа алгоритма DUAL......................................................................119
6.8 Механизм ответов на запросы...................................................................124
7 Конфигурирование и тестирование протокола EIGRP..................................127
7.1 Запуск протокола EIGRP............................................................................127
7.2 Настройка аутентификации в протоколе EIGRP..................................131
7.3 Суммирование маршрутов в протоколе EIGRP.......................................133
7.4 Настройка маршрута по умолчанию в протоколе EIGRP.......................134
7.5 Распределение нагрузки в протоколе EIGRP...........................................135
7.6 Расширенная настройка протокола EIGRP..............................................137
7.6.1 Таймеры протокола EIGRP..................................................................137
7.6.2 Изменение административного расстояния протокола EIGRP........138
7.6.3 Изменение весовых коэффициентов протокола EIGRP...................139
7.6.4 Настройка протокола EIGRP для сетей NBMA.................................140
7.6.5 Использование EIGRP пропускной способности каналов связи.....141
7.6.6 Идентификация маршрутизаторов в протоколе EIGRP ..................141
7.7 Тестирование и устранение ошибок в работе протокола EIGRP...........142
8 Использование протокола EIGRP в масштабируемых сетях........................151
8.1 Масштабируемость. Проблемы и решения..............................................152
8.2 Использование суммарных маршрутов....................................................153
8.3 Использование тупиковых маршрутизаторов..........................................155
8.4 Использование протокола EIGRP в современных условиях..................158
9 Протоколы маршрутизации по состоянию канала.........................................160
9.1 Алгоритм «кратчайшего пути» Дейкстры................................................163
10 Протокол OSPF ...............................................................................................167
10.1 Характеристики протокола OSPF............................................................167
10.1.1 Групповая рассылка обновлений состояния каналов.....................168
10.1.2 Аутентификация.................................................................................168
10.1.3 Быстрота распространения изменения в топологии.......................168
10.1.4 Иерархическое разделение сети передачи данных.........................169
10.2 База данных протокола OSPF..................................................................170

5
10.2.1 Таблица соседства..............................................................................170
10.2.2 Таблица топологии.............................................................................171
10.3 Метрика протокола OSPF........................................................................174
10.4 Служебные пакеты протокола OSPF......................................................175
10.4.1 Пакет приветствия..............................................................................176
10.4.2 Суммарная информация о таблице топологии................................178
10.4.3 Запрос на получение информации о топологическом элементе....179
10.4.4 Обновление информации о топологических элементах.................180
10.4.5 Подтверждение о получении.............................................................180
10.5 Процесс установки соседских отношений.............................................181
10.5.1 Поиск соседей.....................................................................................181
10.5.2 Обмен топологической информацией..............................................183
11 Настройка протокола OSPF в одной зоне.....................................................185
11.1 Запуск протокола OSPF............................................................................185
11.2 Управление значением идентификатора маршрутизатора OSPF.........188
11.3 Настройка аутентификации в протоколе OSPF..................................190
11.3.1 Проверка функционирования аутентификации...............................192
11.4 Настройка маршрута по умолчанию в протоколе OSPF.......................193
11.5 Распределение нагрузки в протоколе OSPF...........................................194
11.6 Расширенная настройка протокола OSPF..............................................195
11.6.1 Таймеры протокола OSPF..................................................................195
11.6.2 Изменение административного расстояния протокола OSPF........196
11.7 Тестирование и устранение ошибок в работе протокола OSPF...........197
12 Работа протокола OSPF в сетях различных типов.......................................208
12.1 Работа протокола OSPF в сетях «Точка-Точка»....................................208
12.2 Работа протокола OSPF в широковещательных сетях..........................209
12.2.1 Правила выбора DR и BDR маршрутизаторов................................210
12.3 Работа протокола OSPF в сетях NBMA..................................................211
12.4 Режимы работы протокола OSPF в сетях NBMA..................................212
12.5 Режимы работы протокола OSPF в сетях Frame Relay.........................214
12.5.1 Нешироковешательный режим ........................................................214
12.5.2 Многоточечный режим .....................................................................217
12.5.3 Использование подинтерфейсов.......................................................218
12.6 Проверка работы протокола OSPF в сетях различных типов...............220
13 Работа протокола OSPF в нескольких зонах................................................222
13.1 Типы маршрутизаторов OSPF.................................................................224
13.1.1 Внутренние маршрутизаторы...........................................................225
13.1.2 Магистральные маршрутизаторы.....................................................225
13.1.3 Пограничные маршрутизаторы.........................................................225
13.1.4 Пограничные маршрутизаторы автономной системы....................225
13.2 Типы объявлений о состоянии каналов..................................................226
13.2.1 Структура заголовка сообщения LSA..............................................226
13.2.2 Объявление состояния маршрутизатора (Тип 1).............................229

6
13.2.3 Объявление состояния сети (Тип 2).................................................231
13.2.4 Суммарные объявления о состоянии каналов (Тип 3 и 4)..............232
13.2.5 Объявления внешних связей (Тип 5 и 7)..........................................234
13.3 Построение таблицы маршрутизации протоколом OSPF.....................235
13.3.1 Типы маршрутов протокола OSPF...................................................236
13.3.2 Расчет метрики внешних маршрутов...............................................238
13.4 Суммирование маршрутов протоколом OSPF.......................................239
13.4.1 Суммирование межзональных маршрутов......................................239
13.4.2 Суммирование внешних маршрутов................................................242
13.4.3 Отображение внешних суммарных маршрутов..............................243
14 Специальные типы зон протокола OSPF......................................................245
14.1 Типы зон протокола OSPF.......................................................................245
14.1.1 Правила тупиковых зон.....................................................................246
14.2 Тупиковые зоны протокола OSPF...........................................................246
14.2.1 Настройка тупиковой зоны................................................................247
14.3 Полностью тупиковые зоны протокола OSPF.......................................247
14.3.1 Настройка полностью тупиковой зоны............................................248
14.4 Таблицы маршрутизации в тупиковых зонах........................................250
14.5 Не совсем тупиковые зоны протокола OSPF.........................................252
14.5.1 Настройка не совсем тупиковой зоны..............................................252
14.5.2 Настройка полностью тупиковой зоны NSSA.................................254
14.6 Проверка функционирования специальных зон протокола OSPF.......254
15 Виртуальные каналы в протоколе OSPF.......................................................256
15.1 Настройка виртуальных каналов.............................................................257
15.1.2 Примеры использования виртуальных каналов..............................259
15.2 Проверка функционирования виртуальных каналов.............................260
16 Перераспределение маршрутной информации............................................262
16.1 Понятие перераспределения маршрутной информации.......................262
16.2 Понятие метрического домена................................................................264
16.3 Маршрутные петли...................................................................................266
16.3.1 Односторонние перераспределение маршрутной информации....268
16.3.2 Двухсторонние перераспределение маршрутной информации.....271
16.3.3 Протоколы маршрутизации подверженные образованию маршрут-
ных петель......................................................................................................274
17 Совместная работа нескольких протоколов маршрутизации.....................275
17.1 Совместная работа протоколов маршрутизации без перераспределения
.............................................................................................................................275
17.2 Настройка базового перераспределения маршрутной информации....279
17.2.1 Метрика, присваиваемая перераспределяемым маршрутам..........281
17.3 Настройка перераспределения маршрутной информации из присоеди-
ненных и статических маршрутов...................................................................283
17.4 Настройка перераспределения маршрутной информации в протокол
RIP......................................................................................................................286

7
17.5 Настройка перераспределения маршрутной информации в протокол
EIGRP.................................................................................................................288
17.6 Настройка перераспределения маршрутной информации в протокол
OSPF...................................................................................................................289
18 Управление трафиком маршрутных обновлений.........................................292
18.1 Использование пассивных интерфейсов................................................292
18.1.1 Настройка пассивных интерфейсов..................................................294
18.2 Фильтрация маршрутной информации, передаваемой между маршру-
тизаторами.........................................................................................................296
18.2.1 Фильтрация сетей получателей по IP адресу сети..........................297
18.2.2 Фильтрация сетей получателей по длине префикса.......................302
18.2.3 Использование списков доступа и списков префиксов при фильтра-
ции маршрутной информации......................................................................304
18.3 Фильтрация маршрутной информации в процессе перераспределения
маршрутной информации.................................................................................308
19 Маршрутные карты.........................................................................................310
19.1 Понятие маршрутных карт.......................................................................310
19.2 Настройка маршрутной карты.................................................................311
19.3 Использование маршрутных карт при перераспределении маршрутной
информации.......................................................................................................316
19.4 Проверка конфигурации маршрутных карт...........................................317
20 Маршрутизация по политикам.......................................................................319
20.1 Понятие маршрутных политик................................................................319
20.2 Настройка маршрутизации по политикам..............................................320
20.3 Пример маршрутизации по политикам...................................................322
20.4 Проверка маршрутизации по политикам................................................323
21 Обзор протокола BGP.....................................................................................325
21.1 Автономные системы...............................................................................325
21.2 Использование протокола BGP...............................................................326
21.2.1 Когда используется протокол BGP...................................................327
21.2.2 Когда не следует использовать протокол BGP................................328
22 Терминология и концепции протокола BGP................................................329
22.1 Характеристики протокола BGP.............................................................329
22.2 Таблицы протокола BGP..........................................................................330
22.3 Одноранговые устройства или соседи BGP...........................................330
22.4 Маршрутизация по политикам................................................................331
22.5 Атрибуты протокола BGP........................................................................332
22.5.1 Содержимое сообщения обновления протокола BGP....................332
22.5.2 Стандартные и опциональные атрибуты..........................................333
22.5.3 Атрибут «Путь к AS».........................................................................334
22.5.4 Атрибут «Узел следующего перехода»............................................335
22.5.5 Атрибут «Локальный приоритет».....................................................337
22.5.6 Атрибут MED......................................................................................339

8
22.5.7 Атрибут «Отправитель».....................................................................340
22.5.7 Атрибут «Сообщество»......................................................................340
22.5.8 Атрибут «Вес»....................................................................................341
23 Работа протокола BGP....................................................................................343
23.1 Типы сообщений протокола BGP............................................................343
23.1.1 Состояния BGP соседей.....................................................................344
23.2 Процесс принятия решения при выборе пути........................................346
23.2.1 Выбор нескольких путей...................................................................347
23.3 CIDR маршрутизация и суммирование маршрутов..............................348
24 Настройка протокола BGP..............................................................................350
24.1 Одноранговые группы..............................................................................350
24.2 Основные команды протокола BGP........................................................351
24.2.1 Модификация атрибута NEXT-HOP.................................................354
24.2.2 Описание объединенного адреса в BGP таблице............................354
24.2.3 Перезапуск протокола BGP...............................................................356
24.3 Проверка работоспособности протокола BGP.......................................358
25 Множественная адресация.............................................................................359
25.1 Типы множественной адресации.............................................................359
Заключение...........................................................................................................369
Словарь терминов.................................................................................................370
Список использованных источников.................................................................388

9
Введение

Корпоративные сети передачи данных развиваются огромными темпа-


ми. С каждым годом задачи, возлагаемые на сеть передачи данных, значи-
тельно усложняются, вследствие чего усложняется ее внутренняя структура и
принципы организации, а также растет потребность в эффективной маршру-
тизации трафика.
Настоящее учебное пособие написано для подготовки магистров по
программе 230100.68.13 «Сети ЭВМ и телекоммуникации», хотя может быть
использовано так же для подготовки специалистов обучающихся по направ-
лению 210100 в качестве спец. курса по выбору в 9 семестре.
В учебном пособии рассматриваются как классические принципы по-
строения, так и современные тенденции в развитии архитектуры сетей пере-
дачи данных.
В курсе лекционных и практических занятий, рассматриваются различ-
ные принципы маршрутизации, а также детально изучаются протоколы дина-
мической маршрутизации, используемые в современных условиях.
Теоретический материал о каждом из протоколов маршрутизации, осно-
вывается на соответствующих стандартах RFC, что дает возможность
рассматривать протокол без привязки к оборудованию конкретного произво-
дителя.
Практическая часть курса, команды и примеры конфигурации маршру-
тизаторов, представленные в пособии, описаны для маршрутизаторов корпо-
рации Cisco с версией операционной системы IOS семейства 12.4. Такой вы-
бор сделан по многим причинам, главные из которых это широкое распро-
странение телекоммуникационного оборудования Cisco, а также унифициро-
ванный интерфейс ОС IOS для всего спектра маршрутизаторов Cisco.

Условные обозначения, используемые в пособии

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


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

Графические символы

Пиктограммы, показанные на рисунке 0.1, используются на протяжении


всего пособия.

10
Маршрутизатор Коммутатор Персональный Сервер
компьютер

Token
Ring

Топология Топология Последовательный Канал


Ethernet Token Ring канал связи связи

500

RIP
Пользователь Метрика
маршрута
Область сети
Домен
передачи
маршрутизации
данных

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

Соглашения по синтаксису командного языка

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


синтаксиса команд, идентичны условным обозначениям, используемым в
«Справочнике по командам ОС Cisco IOS 12.4» («Cisco IOS Command Refer-
ence»).
– Полужирным шрифтом выделяются команды и ключевые слова, ко-
торые должны вводиться без изменения.
– Курсивом выделяются параметры с переменными значениями.
– В квадратных скобках ([]) заключены не обязательные элементы.
– Фигурными скобками ({}) выделяется выбор вероятных значений
ключевых слов.
– Вертикальной чертой (|) разделяются альтернативные взаимоисклю-
чающие элементы.
– Фигурными скобками и вертикальной чертой внутри квадратных ско-
бок, например [X{Y | Z}], обозначается жесткий выбор необязательного
элемента. Не обязательно вводить все, что заключено в скобках, но если это
сделано, то выбирать будет нужно из указанных значений.

11
1 Проектирование масштабируемых сетей передачи данных

1.1 Масштабируемые сети передачи данных

Корпоративная сеть передачи данных (СПД) отражает движение инфор-


мационных потоков корпорации. Структура корпоративной СПД напрямую за-
висит от общей организационной структуры корпорации. Такие структуры на-
зываются иерархические.
Существует два главных типа иерархических структур:
– функциональные структуры;
– географические структуры.
Некоторые корпорации имеют независимые подразделения, отвечающие
за всю деятельность, включая построение и обслуживание сети передачи дан-
ных в зоне ответственности подразделения. Такие подразделения взаимодей-
ствуют между собой, используя общие информационные ресурсу корпорации.
Такая структура корпорации отражается и на дизайне корпоративной сети пере-
дачи данных (Рисунок 1.1).

Подразделение

Подразделение Подразделение

Подразделение Корпорация Подразделение

Подразделение Подразделение

Подразделение

Рисунок 1.1 – Пример дизайна СПД при функциональной


структуре корпорации

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


сти имеют свои территориальные представительства в различных географиче-
ских точках, как внутри страны, так и за ее пределами (Рисунок 1.2).

12
Филиал
Город Б
Филиал Филиал
Город А Город В

Филиал Филиал
Город З Корпорация Город Г

Филиал
Филиал
Город Ж
Город Д
Филиал
Город Е

Рисунок 1.2 – Пример дизайна СПД при географической


структуре корпорации

При такой структуре организации каждое территориальное представи-


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

Распределение
Распределение
Распределение

Доступ Ядро Доступ

Распределение

Рисунок 1.3 – Трех уровневая модель организации СПД

– Уровень ядра (Core layer). Главной задачей является обработка пото-


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

13
уменьшения задержек при передаче потоков данных. Для повышения надежно-
сти применяются схемы резервирования оборудования.
– Уровень распределения (Distribution layer). Распределение потоков
данных внутри сегмента сети и передача части потока данных в уровень ядра
для дальнейшей обработки.
– Уровень доступа (Access layer). Точка входа в сеть конечных пользо-
вателей. Главная задача оборудования уровня доступа состоит в обеспечении
возможности подключения к сети пользователей их аутентификация и авто-
ризация.
Для обеспечения требуемой скорости передачи данных внутри ядра
сети могут применяться различные виды топологии. Например, при использо-
вании полносвязной топологии (Рисунок 1.4) достигается наименьшее время
задержки и наибольший уровень отказоустойчивости.

Рисунок 1.4 – Полносвязная топология ядра

Данная топология может применяться только для небольших организа-


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

14
Рисунок 1.5 – Топология «звезда» в ядре сети

Данный вид топологии также обладает свойством хорошей масштаби-


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

Ядро

Распределение

Доступ
Доступ
Доступ

Рисунок 1.6 – Трехуровневая организация сети передачи данных

Удаленные узлы являются точками входа в сеть для конечных пользова-


телей и клиентов. В корпоративной сети передачи данных удаленные узлы
предоставляют доступ к сетевым ресурсам через уровень доступа. Главной за-
дачей уровня доступа является предоставление доступа к корпоративной СПД
только зарегистрированным пользователям. На уровне доступа помимо сер-
висов, предоставляющих доступ к сети также разворачиваются сервисы, осу-
ществляющие аутентификацию и авторизацию пользователей.
Уровень распределения является точкой консолидации потоков данных
от уровня доступа. На уровень распределения могут быть вынесены некото-
рые сервисы уровня доступа, такие как DHCP - Dynamic Host Configuration

15
Protocol (протокол динамического конфигурирования узла), DNS - Domain
Name System (служба доменных имён) если их расположение на уровне до-
ступа может оказаться невыгодным.

1.2 Архитектура корпоративной сети передачи данных

Тщательно проработанная архитектура сети помогает применению но-


вых технологий, служит заделом для будущего роста, определяет выбор сете-
вых технологий, помогает избежать избыточных затрат.
Необходимые требования к архитектуре корпоративной сети:
– Расширяемость (Scalability). Учет в дизайне сети передачи данных воз-
можности многократного увеличения числа узлов;
– Предсказуемость (Predictability). Предсказуемое поведение, как всей
сети, так и ее частей во всех возможных режимах работы;
– Гибкость (Flexibility). Минимизация издержек связанных с дополнени-
ем, изменением и удалением узлов внутри сети.
В масштабируемой сети передачи данных отвечающей всем приведен-
ным требованиям добавление нового подразделения (Рисунок 1.7) происходит с
наименьшими затратами времени и средств.

Подразделение Д

S
X Y
R
P

A
D
K
B E J

M L

G C F

Подразделение А
N O I H

ПодразделениеБ

Рисунок 1.7 – Расширяемость СПД

Операция подключения подразделения, в котором уже существовала своя


сеть передачи данных, к общей СПД корпорации содержит следующие основ-
ные этапы:
– Подключение маршрутизаторов P и Q к ядру общей сети передачи дан-
ных;

16
– Перевод адресного пространства нового подразделения в общее адрес-
ное пространство корпорации и настройка на маршрутизаторах P и Q службы
NAT - Network Address Translation (трансляция сетевых адресов);
– Перевод DHCP сервера подключаемого подразделения в общее адрес-
ное пространство;
– Удаление на маршрутизаторах P и Q службы NAT.
Поведение полученной сети предсказуемо (Рисунок 1.8).

Подразделение Д

S
X Y
R
P

A
D
K
B E J

M L

G C F

Подразделение А
N O I H

ПодразделениеБ

Рисунок 1.8 – Предсказуемость СПД

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


лов передачи данных до вышестоящих узлов должны быть примерно равными.
Например, маршрутизатор C имеет одинаковые каналы связи до маршрутизато-
ров B и E, поэтому маршрутизатор C может использовать механизм баланси-
ровки трафика до сетей расположенных за маршрутизаторами B и E. Маршру-
тизаторы B и E являются точкой консолидации для маршрутизаторов уровня
доступа C, G и F.
Скорость каналов связи между маршрутизаторами B и E и маршрутизато-
рами A и D должна быть выше, чтобы иметь возможность беспрепятственно
передавать трафик между подразделениями корпорации.
Поскольку маршрутизаторы A и D выступают точкой консолидации по-
токов трафика от множества подразделений корпорации, фактически принадле-
жат ядру СПД, то каналы связи между ними должны иметь наивысшую про-
пускную способность.
Используя пути с равной стоимостью и пропускной способностью между
двумя любыми маршрутизаторами в сети, включается механизм балансировки
нагрузки. Если канал связи или маршрутизатор выходят из строя, в таблице
маршрутизации каждого маршрутизатора существует альтернативный маршрут
с той же стоимостью к сети получателю. Такой альтернативный путь ограничи-

17
вает время пересчетов маршрутов на маршрутизаторе менее чем к одной секун-
де, после того как он обнаруживает отказ канала связи.
Например, рассмотрим сеть, в которой маршрутизатор C использует аль-
тернативные маршруты до маршрутизатора X. Таблица маршрутизации марш-
рутизатора C содержит два маршрута до X в три перехода через маршрутизато-
ры B или E.
Если маршрутизатор D становиться недоступным, то таблица маршрути-
зации маршрутизатора C не изменяется. Каждый из маршрутизаторов B и E
имеет два лучших маршрута до маршрутизатора X, через маршрутизатор D или
A. Поэтому маршрутизаторы B и E не ищут альтернативный маршрут, посколь-
ку он уже присутствует в их таблице маршрутизации.
В результате получается предсказуемое движение трафика из одного сег-
мента сети в другой.
Допустим, корпорация решила продать свое подразделение Б другой ор-
ганизации, за исключением его части, которая находится за маршрутизатором
N (Рисунок 1.9).

Подразделение Д

S
X Y
R
P

A
D
K
B E J

M L

G C F

Подразделение А
N O I H

ПодразделениеБ

Рисунок 1.9 –Гибкость СПД

Для организации связи с удаленным узлом N администраторам сети пере-


дачи данных потребуется:
– Организовать каналы связи между маршрутизатором N и маршрутиза-
торами B и E;
– После успешной организации новых каналов связи, отключить каналы
связи маршрутизатора N с маршрутизаторами M и L;
– Настроить NAT на маршрутизаторе N для трансляции адресов из адрес-
ного пространства подразделения A;
– Удалить каналы связи до маршрутизаторов J и K с других маршрутиза-
торов ядра сети (A, D, P, Q, X и Y);

18
– Заменить адреса удаленного узла N на адреса из адресного про-
странства подразделения A.

1.3 Введение в технологию подсетей и ее обоснование

Для выполнения требований применяемых архитектуре корпоративной


сети передачи данных применяются как технические, так и организационные
меры. Следует обратить особое внимание на разработку политики распределе-
ния адресного пространства корпорации, так называемый адресный план.
Для корпоративных сетей передачи данных, согласно RFC 1918, выделе-
ны частные сети из каждого класса A, B и C (Таблица 1.1).

Таблица 1.1 – Зарезервированные адреса для частного использования

Класс сети Адресное пространство


A 10.0.0.0 – 10.255.255.255
B 172.16.0.0 – 172.31.255.255
C 192.168.0.0 – 192.168.255.255

В зависимости от текущего числа устройств в сети и предполагаемого ро-


ста этого числа в обозримом будущем, администратор выбирает один из пред-
ставленных диапазонов адресов.
Первоначально Internet имел двух уровневую иерархию: верхний уро-
вень – Internet в целом и уровень ниже это сети каждая со своим индивиду-
альным номером. В такой двух уровневой иерархии узел представлял всю
сеть как одиночный объект, «черный ящик», к которому подключено некото-
рое количество узлов.
Однако с усложнением внутренней структуры сети передачи данных по-
требовалось введение трех уровневой сетевой иерархии. Согласно RFC 950 был
введен третий уровень иерархии – подсеть.

Класс A Сеть Узел


Октет 1 2 3 4

Класс B Сеть Узел


Октет 1 2 3 4

Класс C Сеть Узел


Октет 1 2 3 4

Рисунок 1.10 – Сети классов A-C, сетевая и узловая части

19
Чтобы наиболее эффективно использовать имеющийся ограниченный
запас IP адресов, каждая сеть может быть разделена на подсети меньшего раз-
мера. На рисунке 1.10 показано разделение на сетевую и узловую части адресов
сетей разных классов.
Чтобы выделить подсеть, биты сетевого узла должны быть переназначе-
ны как сетевые биты посредством деления октета сетевого узла на части. Такой
механизм называют заимствованием битов. Процесс деления всегда начинается
с крайнего левого бита узла, положение которого зависит от класса сети.
Помимо повышения управляемости, создание подсетей позволяет сете-
вым администраторам ограничить широковещательные рассылки. Широкове-
щательные пакеты рассылаются всем узлам сети или подсети. Когда широкове-
щательный трафик начинает расходовать значительную часть доступной поло-
сы пропускания канала передачи данных, сетевой администратор должен при-
нять решение об уменьшении широковещательного домена.
Как и номера сетевых узлов в сетях класса A, B или C адреса подсетей
задаются локально. Каждый адрес подсети является уникальным. Использова-
ние подсетей никак не отражается на том, как внешний мир видит эту сеть, но
в пределах организации подсети рассматриваются как дополнительные струк-
туры.
Например, сеть 172.16.0.0 (Рисунок 1.11) разделена на 4 подсети:
172.16.0.0, 172.16.1.0, 172.16.2.0 и 172.16.3.0.

172 .16.3.0
172.16.0.0

172 .16.1.0 172 .16.2.0

Рисунок 1.11 – Сеть 172.16.0.0 разделенная на четыре подсети

Маршрутизатор определяет сеть назначения, используя адрес подсети,


тем самым, ограничивая объем трафика в других сегментах сети.
С точки зрения адресации, подсети являются расширением сетевой ча-
сти IP адреса сетевого узла (Рисунок 1.12).

20
Таблицамаршрутизации

Сеть Интерфейс
172 .16.1.0 E0
172 .16.2.0 E1

172 .16.1.1 172 .16.2.1


E0 E1

172 .16.1.2 172 .16.1.20 172 .16.1.16

172 .16 1 16
Сеть Подсеть Узел

Рисунок 1.12 – Адреса подсетей

Сетевые администраторы задают размеры подсетей, исходя из потреб-


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

Таблица 1.2 – Позиция бита и соответствующее десятичное значение

Бит 1 2 3 4 5 6 7 8
Значение 128 64 32 16 8 4 2 1

Независимо от класса IP адреса, последние два бита в последнем октете


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

Таблица 1.3 – Два формата записи маски подсети

Префикс /25 /26 /27 /28 /29 /30 /31 /32


Маска 128 192 224 240 248 252 254 255
Бит 1 2 3 4 5 6 7 8
Значение 128 64 32 16 8 4 2 1

21
Другим способом записи маски подсети является способ записи с обрат-
ной чертой. Число указанное после символа обратной черты, представляет со-
бой количество бит, составляющих адрес сети, плюс биты, использующиеся
для маски подсети. Данное число также называется префиксом подсети.
В маски подсети используется тот же формат, что и в IP адресе, маска
подсети состоит из четырех октетов, а длина ее составляет 32 бита (Рисунок
1.13).
Сеть Узел

IP адрес 172 16 0 0

Сеть Узел

Стандартная
маска 255 255 0 0

Сеть Подсеть Узел

8-битная
маска
255 255 255 0

Рисунок 1.13 – Адреса сети и узла

Сетевая часть маски подсети, как и часть, определяющая подсеть, состоит


из всех единиц, а узловая ее часть заполнена нулями. Стандартная маска сети
класса B, если ни один бит, не заимствован для разбиения сети на подсети, вы-
глядит, как 255.255.0.0 как показано на рисунке 1.14.

128 64 32 16 8 4 2 1

1 0 0 0 0 0 0 0 = 128

1 1 0 0 0 0 0 0 = 192

1 1 1 0 0 0 0 0 = 224

1 1 1 1 0 0 0 0 = 240

1 1 1 1 1 0 0 0 = 248

1 1 1 1 1 1 0 0 = 252

1 1 1 1 1 1 1 0 = 254

1 1 1 1 1 1 1 1 = 255

Рисунок 1.14 – Схема двоичных преобразований

Поскольку в адресе класса B выделены два октета под адреса узлов, для
задания маски подсети может быть заимствовано не более 14 бит. В сети класса

22
C используется только 8 бит для поля узла, следовательно, для задания маски
подсети, может быть использовано не более 6 бит.
При расчете количества узлов в подсети следует помнить, что каждый раз
при заимствовании одного бита из поля узла количество бит, которые использу-
ются для указания номера узла, уменьшается. Каждый раз при заимствовании
нового бита из поля узла количество адресов узлов, которые могут быть назна-
чены, уменьшается вдвое. На рисунке 1.15 приводится пример разделения сети
класса C на подсети. Подобное разделение можно сравнить с разделением пи-
рога, потому что деление производиться всегда на 2n равных частей, где n число
заимствованных бит.

62 62
254 126 126
62 62

192.168.0.0/24 192.168.0.0/25 192.168.0.0/26


192.168.0.128/25 192.168.0.64/26
192.168.0.128/25
192.168.0.192/26

Рисунок 1.15 – Разделение сети класса C на подсети

Число адресов для устройств в подсети вычисляется как 2n–2, где n –


число бит выделенной под адресацию устройств. Каждая подсеть имеет два
служебных адреса, первый это адрес подсети, второй это широковещатель-
ный адрес, используемый для обращения ко всем устройствам данной подсе-
ти.
Без маски подсети все 8 бит последнего октета используются о поле узла,
следовательно, могут быть использованы 254 (28-2) адреса. Если заимствовать
один бит из стандартных восьми, поле узла уменьшится до 7,следовательно, ко-
личество узлов в подсети будет равно 126. Если заимствовать два бита, то поле
узла уменьшится до 6,а количество узлов в подсети будет равно 62.
Необходимо отметить что изначально, маски подсетей были фиксирован-
ной длины – fixed length subnet masking (FLSM). Это означало то, что в одной
сети все подсети были одинакового размера.
Однако фиксированная длина маски подсети имеет неудобство с точки
зрения эффективного распределения адресного пространства.
Например, маска сети в 27 бит подходит для адресации большинства
сегментов Ethernet, в которых не более 30 хостов. Однако, 30 адресов слиш-
ком много для каналов связи «точка-точка», в которых необходимо всего два
адреса. Поэтому 28 адресов остаются неиспользованными.

23
1.4 Применение технологии VLSM

Для более эффективного использования адресного пространства была


разработана технология маски подсети переменной длины – variable length sub-
net masking (VLSM). Данная технология подробно описана в RFC 1219.
Маски подсети переменной длины обеспечивают возможность создания
более одной маски подсети в переделах одной сети, возможность разбивать
на подсети уже разбитые на подсети группы IP адресов.
Применение масок подсети переменной длины предоставляет следую-
щие преимущества:
– Эффективным распределением адресных блоков. Иерархическое рас-
пределение адресных блоков позволяет использовать все доступные адреса,
не создавая конфликтов и не оставляя части адресных блоков неиспользован-
ными.
– Возможность использования суммированных маршрутов. Технология
VLSM позволяет задавать больше иерархических уровней в рамках одного
адресного плана. Это позволяет производить оптимальное суммирование в та-
блицах маршрутизации. Например, подсеть 172.16.12.0/22 суммирует все ад-
реса, которые входят в нее, включая подсети 172.16.13.0/24, 172.16.14.0/24 и
172.16.15.0/24.
– Небольшое число записей в таблицах маршрутизации. В Интернет и
интранет маршрутизаторах применяется механизм иерархического суммиро-
вания маршрутов. Благодаря применению данного механизма одна запись в
таблице маршрутизации представляет иерархическую совокупность IP адре-
сов. Данный механизм обеспечивает следующие преимущества:
– Более эффективная маршрутизация;
– Использование значительно меньших вычислительных возможностей
маршрутизатора;
– Быстрая сходимость сети при изменениях в ее структуре;
– Упрощенный поиск и устранение ошибок.
На рисунке 1.16 показано двоичное представление сетей с 172.16.11.0
по 172.16.16.0. Видно, что сети с 172.16.12.0 по 172.16.15.255 имеют 22 оди-
наковых бит в начале адреса. Сети 172.16.11.0 и 172.16.16.0 не имеют в нача-
ле адреса все 22 одинаковых бит. Поэтому эти сети не входят в блок
172.16.12.0/22.
В качестве примера использование технологии масок подсетей пере-
менной длины можно рассмотреть разделение адресного пространства выде-
ленного для адресации подразделения, изображенного на рисунке 1.17.

24
Адреса подсетей 172.16.12.0/22
Десятичная запись Двоичная запись
172.16.11.0 10101100.00010000.00001011.00000000
172.16.12.0 10101100.00010000.00001100.00000000
172.16.12.255 10101100.00010000.00001100.11111111
172.16.13.0 10101100.00010000.00001101.00000000
172.16.13.255 10101100.00010000.00001101.11111111
172.16.14.0 10101100.00010000.00001110.00000000
172.16.14.255 10101100.00010000.00001110.11111111
172.16.15.0 10101100.00010000.00001111.00000000
172.16.15.255 10101100.00010000.00001111.11111111
172.16.16.0 10101100.00010000.00010000.00000000

Рисунок 1.16 – Двоичная запись сетей 172.16.11.0 – 172.16.16.0

20 200
R2

Центральный офис
20 172.16.0.0/16
R3
R1

20 200
R4
Подразделение А
172.16.12.0/22

Рисунок 1.17 – Структура СПД Подразделения А

Из центрального офиса компании для подразделения A был выделен


диапазон адресов 172.16.12.0 /22.
Данное подразделение имеет две крупные локальные сети примерно по
200 пользователей каждая, а также три удаленных узла примерно по 20 поль-
зователей. Также не следует забывать о том, что для каналов связи до марш-
рутизаторов удаленных узлов тоже должны быть выделены IP адреса.
Создание иерархического адресного плана подразделения содержит
следующие шаги:
1. Выделение из выделенного адресного пространства адресов для двух
локальных сетей на 200 пользователей.
2. Перераспределение оставшегося адресного пространства между тре-
мя сетями по 20 пользователей.
3. Перераспределение оставшегося адресного пространства для адреса-
ции каналов связи между маршрутизаторами.
Произведем разделение адресного пространства 172.16.12.0/22.

25
1. Так как у нас есть две локальные сети по 200 пользователей нам
необходимо два блока по 256 адресов. Под локальные сети выделяем подсети
172.16.12.0/24 и 172.16.13.0/24.
2. Берем последний из оставшихся блоков адресов 172.16.15.0/24 и де-
лим его на блоки по 32 адреса. Получаем подсети для удаленных офисов
172.16.15.0/27, 172.16.15.32/27 и 172.16.15.64/27.
3. Берем последний блок из оставшихся блоков адресов
172.16.15.224/27 и делим его на блоки по 4 адреса для присвоения адресов ин-
терфейсам маршрутизаторов 172.16.15.224/30, 172.16.15.228/30,
172.16.15.232/30.
Получившийся адресный план подразделения A представлен на рисунке
1.18.

172 .16.15.0/27 17 172 .16.12.0/24


2.
R2 16
.1
5.
22
4/
30

172 .16.15.228 /30 Центральный офис


172 .16.15.32/27
R3 172.16.0.0/16
R1
30
2/
23
15.
.
16
2.
172 .16.15.64/27 17
172 .16.13.0/24
R4
Подразделение А
172.16.12.0/22

Адреса подсетей 172.16.12.0/24


172.16.12.0 10101100.00010000.00001100.00000000 Локальная сеть 1
172.16.13.0 10101100.00010000.00001101.00000000 Локальная сеть 1
172.16.14.0 10101100.00010000.00001110.00000000 Резерв
172.16.15.0 10101100.00010000.00001111.00000000 Удаленные узлы

Адреса подсетей 172.16.15.0/27


172.16.15.0 10101100.00010000.00001110.00000000 Удаленный узел R1
172.16.15.32 10101100.00010000.00001110.00100000 Удаленный узел R2
172.16.15.64 10101100.00010000.00001110.01000000 Удаленный узел R3

Адреса подсетей 172.16.15.224/30


172.16.15.224 10101100.00010000.00001110.11100000 R1–R2
172.16.15.228 10101100.00010000.00001110.11100100 R1–R3
172.16.15.232 10101100.00010000.00001110.11101000 R1–R4
172.16.15.236 10101100.00010000.00001110.11101100 Резерв
172.16.15.240 10101100.00010000.00001110.11110000 Резерв
172.16.15.244 10101100.00010000.00001110.11110100 Резерв
172.16.15.248 10101100.00010000.00001110.11111000 Резерв
172.16.15.252 10101100.00010000.00001110.11111100 Резерв

Рисунок 1.18 – Адресный план Подразделения А

26
1.5 Суммирование маршрутов

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


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

172 .16.12.0/24

172 .16.13.0/24

172 .16.12.0/22

172 .16.14.0/24 R1 R2

172 .16.15.0/24 Таблицамаршрутизации Таблица маршрутизации

172 .16.12.0/24 172 .16.12.0/22


172 .16.13.0/24
172 .16.14.0/24
172 .16.15.0/24

Рисунок 1.19 – Суммирование маршрутов

На рисунке 1.19 маршрутизатор R1 может послать четыре маршрута на


известные ему подсети маршрутизатору R2, однако, используя механизм сум-
мирования маршрутов, R1 посылает на R2 только один суммарный маршрут
на все подсети.
Применение суммирования маршрутов резко уменьшает объемы таблиц
маршрутизации, снижает загрузку маршрутизаторов, а также снижает загруз-
ку каналов передачи данных за счет уменьшения объемов передаваемой ин-
формации между маршрутизаторами об известных им маршрутах.
Еще одним преимуществом использования суммирования маршрутов в
больших сетях является, то, что оно может изолировать изменение топологии
в одной области сети от других маршрутизаторов.
Например, канал связи до сети 172.16.13.0/24 часто пропадает из–за
присутствия на нем физических помех, при этом суммарный маршрут
172.16.12.0/22 для маршрутизатора R2 изменятся, не будет и маршрутизатору
R2 не потребуется постоянно менять свою таблицу маршрутизации.

27
1.6 Проектирование масштабируемого адресного пространства

Распределение адресного пространства должно быть оптимизировано.


Правильное распределение адресных блоков обеспечивает выполнение необхо-
димых условий для создания корпоративных сетей.
Иерархическая структура адресного плана характеризуется:
– Эффективным распределением адресных блоков. Иерархическое рас-
пределение адресных блоков позволяет использовать все доступные адреса,
не создавая конфликтов и не оставляя части адресных блоков неиспользован-
ными.
– Небольшим числом записей в таблицах маршрутизации. В Интернет и
интранет маршрутизаторах применяется механизм иерархического суммиро-
вания маршрутов. Благодаря применению данного механизма одна запись в
таблице маршрутизации представляет иерархическую совокупность IP адре-
сов. Данный механизм обеспечивает следующие преимущества:
– Более эффективная маршрутизация;
– Использование значительно меньших вычислительных возможностей
маршрутизатора;
– Быстрая сходимость сети при изменениях в ее структуре;
– Упрощенный поиск и устранение ошибок.
При иерархическом распределении адресов адресное пространство долж-
но иметь точки суммирования маршрутов в ключевых местах сети. Суммирова-
ние маршрутов помогает уменьшить размер таблиц маршрутизации. Также
суммирование маршрутов помогает локализовать изменения, происходящие в
топологии сети, что позволяет повысить стабильность сети передачи данных.
Стабильность сети передачи данных позволяет уменьшить требования по про-
пускной способности каналов связи для передачи служебной информации, ко-
торой обмениваются маршрутизаторы для построения своих таблиц маршрути-
зации. Также уменьшается загрузка оперативной памяти и процессора маршру-
тизаторов, которые тратятся на построение таблиц маршрутизации.
В качестве примера рассмотрим распределенную сеть передачи данных
(Рисунок 1.20) которая объединяет 50 подразделений, каждое из которых имеет
по 200 сетей /24.
Общее количество сетей в рассматриваемой корпоративной сети равно
50*200=10000. При грамотном использовании иерархической структуры рас-
пределения адресного пространства маршрутизаторы уровня распределения
каждого из подразделений имеют в своих таблицах маршрутизации 200 сетей /
24 которые находятся внутри подразделения и еще 49 сетей 10.x.0.0 /16 кото-
рые представляют собой суммарные маршруты на сети других подразделений.
Общее количество записей в таблице маршрутизации маршрутизаторов уровня
распределения равняется 249.

28
10.1.0.0/16 10.3.0.0/16
Ядро
10.2.0.0/16

10.1.1.0 10.1.2.0 10.3.1.0 10.3.2.0

10.2.1.0 10.2.2.0

Рисунок 1.20 – Иерархическое распределение адресного пространства

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


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

10.1.1.0/24 10.2.2.0/24
10.3.2.0/24 10.1.2.0/24
Ядро
10.2.1.0/24
10.3.1.0/24

10.1.1.0 10.3.2.0 10.2.2.0 10.1.2.0

10.2.1.0 10.3.1.0

Рисунок 1.21 – Произвольное распределение адресного пространства

Теперь рассмотрим сеть с тем же количеством сетей без применения


иерархического распределения адресного пространства (Рисунок 1.21).
В данной сети нет возможности произвести суммирование маршрутов на
маршрутизаторах уровня распределения каждого из подразделений. Следова-
тельно, все частные маршруты попадают в таблицы маршрутизаторов ядра
сети, а оттуда в таблицы маршрутизации каждого маршрутизатора корпорации.
Общее число записей в таблицах маршрутизации будет равно 50*200=10000.

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

30
2 Принципы маршрутизации

2.1 Определение маршрутизации

2.1.1 Маршрутизируемые и маршрутизирующие протоколы

Протокол IP является маршрутизируемым протоколом сети Internet. Па-


кеты маршрутизируются по оптимальному пути от сети отправителя к сети
получателю на основе уникальных идентификаторов – IP адресов.
Схожее звучание, особенно в английском написании, двух терминов
«маршрутизируемый протокол» (routed protocol) и «маршрутизирующий про-
токол» (routing protocol) нередко приводит к путанице. Стоит дать определе-
ния каждому термину.
Маршрутизируемый протокол – это любой сетевой протокол, адрес сетевого
уровня которого предоставляет достаточное количество информации для до-
ставки пакета от одного сетевого узла другому на основе используемой схемы
адресации. Примеры маршрутизируемых протоколов приведены на рисунке
2.1. В их число входят:
– Internet протокол (IP);
– протокол межсетевого пакетного обмена (Internetwork Packet exchange
– IPX);
– протокол AppleTalk (коммуникационный протокол компании Apple);
– протокол DECnet (коммуникационный протокол компании DEC).
IPX 123 .00e0.1efc.0b01 AppleTalk 100 .119

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

Novell DECnet Token


Ring
IPX 123 .00e0.1efc .0b01 Apple IP
IP 15.16.4.8

Token
Ring
DECnet 19.15

IP 15.17.42.8

DECnet 3.33

AppleTalk 1.129 IP 15.16.42.8

Рисунок 2.1 – Маршрутизируемые протоколы

31
Маршрутизирующий протокол (протокол маршрутизации) – это протокол, ко-
торый поддерживает маршрутизируемые протоколы и предоставляет меха-
низмы обмена маршрутной информацией. Протокол маршрутизации позволя-
ет маршрутизаторам обмениваться информацией друг с другом для обновле-
ния записей и поддержки таблиц маршрутизации. Протоколы маршрутизации
это протоколы обмена маршрутной информацией. Примеры протоколов
маршрутизации стека TCP/IP:
– протокол маршрутной информации (Routing Information Protocol –
RIP)
– усовершенствованный протокол маршрутизации внутреннего шлюза
(Enhanced Interior Gateway Routing Protocol – EIGRP);
– открытый протокол предпочтения кратчайшего пути (Open Shortest
Path First –OSPF).
Основываясь на этих двух определениях можно дать определение
маршрутизации.
Маршрутизация – это процесс, при котором осуществляется передача
пакетов маршрутизируемого протокола, при помощи протокола маршрутиза-
ции от логического отправителя логическому получателю.
Маршрутизация является функцией третьего уровня модели OSI. Она
основана на иерархической схеме, которая позволяет группировать отдельные
адреса и работать с группами как с единым целым до тех пор, пока не потре-
буется установить индивидуальный адрес для окончательной доставки дан-
ных (Рисунок 2.2).

Рисунок 2.2 – Принцип работы протокола сетевого уровня

32
2.1.2 Основные функции маршрутизаторов

Основным устройством, отвечающим за осуществления процесса марш-


рутизации, является маршрутизатор.
Маршрутизатор выполняет две ключевые функции:
– Маршрутизация – поддержание таблицы маршрутизации и обмен ин-
формацией об изменениях в топологии сети с другими маршрутизаторами.
Эта функция реализуется с помощью одного или нескольких протоколов
маршрутизации либо при помощи статически настроенных таблиц маршрути-
зации.
– Коммутация – перенаправление пакетов с входного интерфейса марш-
рутизатора на выходной интерфейс в зависимости от таблицы маршрутиза-
ции. При необходимости маршрутизатор может произвести переупаковку IP
пакета из одного вида пакетов канального уровня в другой.
В настоящее время из-за распространения технологии Ethernet на маги-
стральные каналы передачи данных, в которых в качестве физического физи-
ческой среды используется оптоволоконный кабель, широкое распростране-
ние получили коммутаторы третьего уровня. Такие коммутаторы, так же как
и маршрутизаторы строят таблицы маршрутизации и на их основе осуще-
ствляют маршрутизацию сетевого трафика.
Необходимо понимать, что в механизме коммутации пакетов маршру-
тизатором и коммутатором третьего уровня есть серьезные различия. На ри-
сунке 2.3 приводится пример сетей, для маршрутизации в которых использу-
ются маршрутизаторы и коммутаторы третьего уровня.

PPP FrameRelay Ethernet Ethernet

Ethernet Ethernet

Рисунок 2.3 – Маршрутизаторы и коммутаторы третьего уровня

На рисунке видно, что маршрутизатор осуществляет коммутацию паке-


тов между интерфейсами с различными протоколами второго уровня. Други-
ми словами маршрутизатор производит переупаковку полезной информации

33
из поступающих к нему пакетов различных протоколов второго уровня.
Например, из Ethernet в PPP или Frame Relay.
Коммутаторы третьего уровня могут только просматривать информа-
цию сетевого уровня находящуюся в поступающих на его интерфейсы паке-
тах. На основе полученной информации коммутатор третьего уровня произ-
водит коммутацию пакета на выходной интерфейс. Коммутатор третьего
уровня не производит переупаковку полезной информации из поступающих к
нему пакетов. Следовательно, применение коммутаторов третьего уровня воз-
можно только в сетях Ethernet. Однако благодаря высокой производительно-
сти коммутаторы третьего уровня осуществляют быструю маршрутизацию
пакетов в сетях с пропускной способностью каналов связи до 1 Гбит/с и вы-
ше.Маршрутизирующие протоколы и алгоритмы работы маршрутизации на
маршрутизаторах и коммутаторах третьего уровня одинаковые. По этой при-
чине далее мы будем понимать под маршрутизаторами как их самих, так и
коммутаторы третьего уровня.

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

Алгоритмы работы маршрутизаторов могут быть как статическими, так


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

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

Все маршрутизаторы должны иметь локальные таблицы маршрутиза-


ции. Они используются маршрутизатором при передаче информации для
определения наилучшего пути от источника к пункту назначения. Таблица
маршрутизации (Пример 2.1) содержит следующие записи:
– Механизм, по которому был получен маршрут.
– Логический получатель в виде сети или подсети.
– Административное расстояние.
– Метрика маршрута.
– Адрес интерфейса маршрутизатора расположенного на расстоянии
одной пересылки, через которого доступна сеть получатель.
– Время присутствия маршрута в таблице;
– Выходной интерфейс маршрутизатора, через который доступна сеть
получатель.

34
Пример 2.1 – Таблица маршрутизации маршрутизатора Cisco
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 172.16.0.1 to network 0.0.0.0

172.16.0.0/28 is subnetted, 1 subnets


C 172.16.0.0 is directly connected, Serial0
10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
D 10.89.1.64/26 [90/5639936] via 10.93.1.18, 00:04:50, Serial2
C 10.93.1.16/28 is directly connected, Serial2
D 10.89.1.0/26 [90/5639936] via 10.93.1.2, 00:05:15, Serial1
D 10.93.1.0/26 is a summary, 00:08:57, Null0
C 10.93.1.0/28 is directly connected, Serial1
C 10.95.0.32/28 is directly connected, Loopback0
D 10.93.1.32/28 [90/5514496] via 10.93.1.2, 00:04:51, Serial1
[90/5514496] via 10.93.1.18, 00:04:51, Serial2
D 10.95.0.44/30 [90/5639936] via 10.93.1.18, 00:04:51, Serial2
D 10.95.0.40/30 [90/5639936] via 10.93.1.2, 00:05:16, Serial1
D* 0.0.0.0/0 [90/5514496] via 172.16.0.1, 00:00:15, Serial0

2.2.2 Административное расстояние

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


рута к сетям получателям. Так как одновременно на маршрутизаторе может
быть запущено сразу несколько протоколов маршрутизации, необходим ме-
тод выбора между маршрутами, полученными от разных протоколов маршру-
тизации. В маршрутизаторах для выбора маршрутов полученных от разных
протоколов маршрутизации используется концепция административного рас-
стояния.
Административное расстояние рассматривается как мера достоверности
источника информации о маршруте. Это имеет смысл тогда, когда маршрути-
затор имеет информацию о маршруте до сети получателя от нескольких про-
токов маршрутизации.
Малые значения величины административного расстояния предпочти-
тельнее больших значений. Стандартные значения административного рас-
стояния устанавливаются такими, чтобы значения, вводимые вручную, были
предпочтительнее, значений полученных автоматически, и протоколы марш-
рутизации с более сложными метриками были предпочтительнее протоколов
маршрутизации, имеющих простые метрики. В таблице 2.1 представлены
административные расстояния, которые применяются в маршрутизаторах
Cisco для различных протоколов маршрутизации.

35
Таблица 2.1 – Административные расстояния в маршрутизаторах Cisco

Источник информации о Стандартное административное


маршруте расстояние
Прямое соединение 0
Статический маршрут 1
Суммарный маршрут EIGRP 5
Внешний BGP 20
Внутренний EIGRP 90
IGRP 100
OSPF 110
IS–IS 115
RIPv1 RIPv2 120
Внешний EIGRP 170
Внутренний BGP 200
Неизвестный 255

2.2.3 Метрики маршрутов

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


тем к сети получателю, является особенностью присущей любому протоколу.
Каждый протокол имеет свою меру того, что является лучшим. Маршрутиза-
торы характеризуют маршрут к сети с помощью метрики маршрута.
Процесс маршрутизации выбирает маршрут, обладающий наименьшим
значением метрики.
Метрики могут быть вычислены на основе одной или нескольких харак-
теристик. Наиболее часто в алгоритмах маршрутизации используются следу-
ющие параметры:
– Ширина полосы пропускания представляет собой средство оценки
объема информации, который может быть передан по каналу связи;
– Задержка – промежуток времени, необходимый для перемещения па-
кета по каждому из каналов связи от отправителя к получателю. Задержка за-
висит от пропускной способности промежуточных каналов, размера очередей
в портах маршрутизаторов, загрузки сети и физического расстояния;
– Загрузка – средняя загруженность канала связи в единицу времени;
– Надежность – относительное количество ошибок на канале связи;
– Количество переходов – количество маршрутизаторов, которые дол-
жен пройти пакет, прежде чем он достигнет пункта назначения;
– Стоимость – значение, обычно вычисляемое на основе пропускной
способности, денежной стоимости или других единиц измерения, назначае-
мых администратором.
К пункту назначения может существовать множество путей, и все они
могут отображаться в таблице маршрутизации. Если существует более чем

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

2.2.4 Построение таблицы маршрутизации

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


цы маршрутизации на основе данных полученных от протоколов маршрути-
зации и настройках введенных вручную.
Выбор маршрута для занесения в таблицу маршрутизации должен осно-
вываться на следующих критериях:
– Доступность IP адреса перехода. Процесс маршрутизации заключает-
ся в последовательной передачи трафика от отправителя к получателю.
Маршрутизатор должен знать IP адрес следующего маршрутизатора в цепоч-
ки передачи трафика.
– Метрика маршрута. Если переход возможен, то протокол маршрутиза-
ции выбирает наилучший возможный маршрут передачи. Критерием выбора
маршрута является минимальная метрика маршрута.
– Префикс. Маршрутизатор рассматривает длину префикса (маска под-
сети), если имеется несколько маршрутов до сети получателя, но с разными
прификсами, то в таблицу маршрутизации заносятся все маршруты.
– Административное расстояние маршрута. Если маршрутизатор имеет
более одного маршрута до получателя, критерием выбора для занесения в та-
блицу маршрутизации является минимальное административное расстояние.
После создания таблицы маршрутизации маршрутизатор должен под-
держивать ее точное соответствие реальной топологии сети. Поддержка та-
блиц маршрутизации осуществляется либо администратором сети вручную,
либо с помощью динамических протоколов маршрутизации. Независимо от
того, конфигурируются ли маршруты вручную или с помощью протоколов
маршрутизации, точность отображения маршрутов является ключевым фак-
тором в способности маршрутизатора обеспечивать пересылку данных ее по-
лучателям.

2.3 Механизмы маршрутизации

Существует несколько механизмов маршрутизации, которые маршрути-


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

37
рутизации маршрутизатор применяет комбинацию следующих методов
маршрутизации:
– Прямое соединение;
– Статическая маршрутизация;
– Маршрутизация по умолчанию;
– Динамическая маршрутизация.
И хотя каждый из этих методов имеет свои преимущества и недостатки,
они не являются взаимоисключающими.

2.3.1 Прямое соединение

Прямое соединение – это маршрут, который является локальным по от-


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

R2
172.16.0.0

S0

R1
0 17
. 1. 2.
16 S1 S2 16
2. .2
17 . 0

R3 R4

r1#show ip route
...
Gateway of last resort is not set

172.16.0.0/24 is subnetted, 3 subnets


C 172.16.0.0 is directly connected, Serial0
C 172.16.1.0 is directly connected, Serial1
C 172.16.2.0 is directly connected, Serial2

Рисунок 2.4 – Прямое соединение

Прямые соединения всегда являются наилучшим способом маршрути-


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

38
2.3.2 Статическая маршрутизация

Статические маршруты – это такие маршруты к сетям получателям, ко-


торые администратор сети вручную вносит в таблицу маршрутизации. Стати-
ческий маршрут определяет IP адрес следующего соседнего маршрутизатора
или локальный выходной интерфейс, который используется для направления
трафика к определенной сети получателю.
Как следует из самого названия, статический маршрут не может быть
автоматически адаптирован к изменениям в топологии сети. Если определен-
ный в маршруте маршрутизатор или интерфейс становятся недоступными, то
маршрут к сети получателю становиться недоступным.
Преимуществом этого способа маршрутизации является то, что он ис-
ключает весь служебный трафик, связанный с поддержкой и корректировкой
маршрутов.
Статическая маршрутизация может быть использована в следующих си-
туациях:
– Когда администратор нуждается в полном контроле маршрутов ис-
пользуемых маршрутизатором;
– Когда необходимо резервирование динамических маршрутов;
– Когда есть сети достижимые единственно возможным путем;
– Когда нежелательно иметь служебный трафик необходимый для об-
новления таблиц маршрутизации, например при использовании коммутируе-
мых каналов связи.
– Когда используются устаревшие маршрутизаторы не имеющие необ-
ходимого уровня вычислительных возможностей для поддержки динамиче-
ских протоколов маршрутизации.
Наиболее предпочтительной топологией для использования статиче-
ской маршрутизации является топология «звезда». При данной топологии
маршрутизаторы, подключенные к центральной точки сети, имеют только
один маршрут для всего трафика, который будет проходить через централь-
ный узел сети. И один или два маршрутизатора в центральной части сети име-
ют статические маршруты до всех удаленных узлов.
Однако со временем такая сеть может вырасти до десятков и сотен
маршрутизаторов с произвольным количеством подключенных к ним подсе-
тей. Количество статических маршрутов в таблицах маршрутизации будет
увеличиваться пропорционально увеличению количества маршрутизаторов в
сети. Каждый раз при добавлении новой подсети или маршрутизатора, адми-
нистратор должен будет добавлять новые маршруты в таблицы маршрутиза-
ции на всех необходимых маршрутизаторах.
При таком подходе может наступить момент, когда большую часть сво-
его рабочего времени администратор будет заниматься поддержкой таблиц

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

2.3.3 Настройка статических маршрутов

Для конфигурации статического маршрута используется команда ip


route (Пример 2.2).

Пример 2.2 – Синтаксис команды ip route


(config) ip route prefix mask {ip-address | interface-type interface-number
[ip-address]} [dhcp] [distance] [name] [permanent] [tag tag]
(config) no ip route prefix mask

Описание параметров команды ip route приводиться в таблице 2.2.

Таблица 2.2 – Параметры команды ip route

Параметр Описание
prefix Префикс сети получателя.
mask Маска сети получателя.
ip-address IP адрес следующего маршрутизатора
который может быть использован для
достижения сети получателя.
interface-type interface-number Тип и номер интерфейса, на который
следует передать пакет для отправки
сети получателю.
dhcp Позволяет серверу DHCP распростра-
нять статический маршрут как марш-
рут по умолчанию.
distance Административное расстояние марш-
рута.
name Назначение имени указанному марш-
руту.
permanent Указание того, что маршрут не может
быть удален из таблицы маршрутиза-
ции, если интерфейс, на который он
указывает становиться недоступным.
tag tag Ярлык для использования при контро-
ле перераспределения маршрутов.

40
Статические маршруты должны быть заданы на обоих концах канала
связи между маршрутизаторами, иначе удаленный маршрутизатор не будет
знать маршрута, по которому нужно отправлять ответные пакеты и будет по-
строена лишь односторонняя связь (Рисунок 2.5)

S0 10.1.2.0/24

R2

.2
.1
.1

.1
.1

10
.1
10
r2# ip route 172.16.1.0 255.255.255.0 10.1.1.1
172 .16.1.0/24 S1

R1

r1# ip route 10.1.2.0 255.255.255.0 Serial1

Рисунок 2.5 – Статические маршруты

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


рута может применяться IP адрес входного интерфейса соседнего маршрути-
затора или указываться выходной интерфейс маршрутизатора. Единственным
различием между этими двумя видами записи команды будет являться адми-
нистративное расстояние маршрута при его помещении в таблицу маршрути-
зации. Стандартно при использовании адреса следующего перехода админи-
стративное расстояние устанавливается равным 1. При задании выходного
интерфейса для административного расстояния устанавливается значение 0.
Если требуется установить административное расстояние, отличающееся от
стандартного, то следует ввести значение в интервале от 0 до 255 в качестве
параметра distance команды ip route.
Если маршрутизатор, по каким либо причинам, не может использовать
выходной интерфейс, заданный в маршруте, то такой маршрут не будет зане-
сен в таблицу маршрутизации.

2.3.4 Использование «плавающих» статических маршрутов

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


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

41
Статический маршрут, настроенный подобным образом, появится в та-
блице маршрутизации только в том случае, если станет недоступным динами-
ческий маршрут. Как только динамический маршрут вновь станет доступным,
статический маршрут будет вычеркнут из таблицы маршрутизации. Такие
маршруты называются плавающими (Рисунок 2.6).

Dial -Up
(BackUp )

.1

17
.1

2.
16

16
2.

.1.
17

2
192 .168 .1.0/30
10.1.1.0/24 10.1.2.0/24

R1 R2

r2# router eigrp 200


network 10.0.0.0
network 192.168.1.0

ip route 10.1.1.0 255.255.255.0 172.16.1.1 100

r1# router eigrp 200


network 10.0.0.0
network 192.168.1.0

ip route 10.1.2.0 255.255.255.0 172.16.1.2 100

Рисунок 2.6 – Плавающий маршрут

На рисунке 2.6 маршрутизаторы R1 и R2 соединены скоростным кана-


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

2.3.5 Маршрутизация по умолчанию

Бывают ситуации, когда маршрутизатору не нужно знать обо всех сетях


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

42
10.1.2.0/24

192 .168 .1.0/30


S0 WAN
172 .16.1.0/24 S1
R2

.2
.1
.1

.1
.1

10
.1
10
r2# ip route 172.16.1.0 255.255.255.0 Serial 0
S1 ip route 0.0.0.0 0.0.0.0 Serial 1

R1

r1# ip route 10.1.2.0 255.255.255.0 10.1.1.2


ip route 0.0.0.0 0.0.0.0 10.1.1.2

r1# show ip route


...
Gateway of last resort is not set
...
C 172.16.1.0/24 is derectly connected, Ethernet 0
C 10.1.1.0/30 is derectly connected, Serial 1
S 10.1.2.0/24 [1/0] via 10.1.1.0
S* 0.0.0.0/0 [1/0] via 10.1.1.0

Рисунок 2.7 – Маршрут по умолчанию

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


ющий формат команды ip route (Пример 2.3).

Пример 2.3 – Статический маршрут по умолчанию

(config) ip route 0.0.0.0 0.0.0.0 [next-hop-address | outgoing interface]

Описание параметров статического маршрута по умолчанию приво-


диться в таблице 2.3.

Таблица 2.3 – Параметры статического маршрута по умолчанию

Параметр Описание
next-hop-address IP адрес маршрутизатора которому
перенаправляется пакет.
outgoing interface Выходной интерфейс, на который сле-
дует передать пакет для отправки.

Маршрут по умолчанию возможен для любого адреса сети получателя.


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

43
2.4 Проверка и устранение ошибок в статических маршрутах

После того как статические маршруты сконфигурированы, важно про-


верить, что они находятся в таблице маршрутизации и пересылка пакетов по
ним осуществляется требуемым образом. Для просмотра таблицы маршрути-
зации и наличия маршрута в ней используется команда show ip route (Пример
2.4).

Пример 2.4 – Синтаксис команды show ip route


show ip route [ip-address [mask] [longer-prefixes] | protocol [process-id] |
list [access-list-number | access-list-name]

Описание параметров команды show ip route приводиться в таблице 2.4.

Таблица 2.4 – Параметры команды show ip route

Параметр Описание
ip-address IP адрес, по которому необходимо вы-
вести маршрутную информацию.
mask Маска подсети.
longer-prefixes Вывод информации о маршрутах, ко-
торые имеют больший префикс, чем
ip-address mask.
protocol Имя протокола или метода маршрути-
зации, по которому необходимо выве-
сти маршрутную информацию.
process-id Номер процесса для указанного прото-
кола маршрутизации.
list Вывод информации о маршрутах от-
фильтрованной списком доступа.
access-list-number Номер списка доступа.
access-list-name Имя списка доступа.

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


зуется команда ping. Для вывода пути пакета через маршрутизаторы находя-
щиеся между маршрутизаторами используется команда traceroute.

44
3 Принципы динамической маршрутизации

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


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

R1 R2

R4 R3

Рисунок 3.1 – Динамический маршрут

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


другую на основе вручную заданных маршрутов. В данном примере маршру-
тизатор R1 всегда пересылает потоки данных, предназначенные маршрутиза-
тору R3, через маршрутизатор R4. Маршрутизатор обращается к своей табли-
це маршрутизации и в соответствии находящейся там информацией о стати-
ческом маршруте направляет пакет на узел получатель.
Если маршрут от маршрутизатора R1 к маршрутизатору R4 по какой
либо причине становиться недоступным, то маршрутизатор R1 не может
передавать пакет маршрутизатору R4 по нему. Соответственно, до повторно-
го ручного конфигурирования маршрутизатора R1 на передачу пакетов через
маршрутизатор R2 связь с сетью получателем будет невозможна.

45
Динамическая маршрутизация обеспечивает большую гибкость. В соот-
ветствии с таблицей маршрутизации, созданной на маршрутизаторе R1, пакет
может быть доставлен к пункту назначения по более предпочтительному
маршруту через маршрутизатор R4. Однако при этом остается доступным и
второй путь к пункту назначения – через маршрутизатор R2. Когда маршру-
тизатор R1 узнает о том, что канал к маршрутизатору R4 вышел из строя, он
обновит свою таблицу маршрутизации, делая маршрут через маршрутизатор
R2 предпочтительным маршрутом к пункту назначения. В этом случае марш-
рутизаторы продолжают пересылку пакетов по резервному каналу.
После того как маршрут между маршрутизаторами R1 и R4 восстано-
виться, маршрутизатор R1 снова обновляет свою таблицу маршрутизации,
отдавая предпочтение основному маршруту через маршрутизатор R4.
Протоколы динамической маршрутизации могут также для повышения
эффективности работы сети применять механизм балансировки нагрузки по
нескольким маршрутам.

3.1 Операции динамической маршрутизации

Успешное функционирование динамической маршрутизации зависит от


выполнения маршрутизатором двух его основных функций при динамической
маршрутизации (Рисунок 3.2):

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

Таблица маршрутизации Таблица маршрутизации

Рисунок 3.2 – Протоколы маршрутизации поддерживают


информацию о маршрутах

– Поддержка таблицы маршрутизации в актуальном состоянии;


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

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

3.1.1 Стоимость маршрута

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


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

56

R1 R2

Полоса пропускания
Количествопереходов
Задержка E1 56
Загрузка канала
Стоимость
Надежность

R4 E1 R3

Рисунок 3.3 – Метрики, используемые для определения


наилучшего маршрута

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


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

47
3.2 Внутренние и внешние протоколы маршрутизации

3.2.1 Понятие автономной системы и домена маршрутизации

В технологии маршрутизации существует два понятия автономная си-


стема и домен маршрутизации (Рисунок 3.4).

Автономная система

EIGRP

IGRP RIP

Рисунок 3.4 – Автономная система и домен маршрутизации

Автономная система (autonomous system, AS) – это набор сетей, кото-


рые находятся под единым административным управлением и в которых ис-
пользуются единая стратегия и правила маршрутизации. Автономная система
для внешних сетей представляется как некий единый объект.
Домен маршрутизации – это совокупность сетей и маршрутизаторов,
использующих один и тот же протокол маршрутизации.
В сети Интернет термин автономная система используется для описа-
ния крупных логически объединенных сетей, например сетей Internet про-
вайдеров. Каждая такая AS имеет в качестве своего идентификатора шестна-
дцати-битовое число. Для публичных сетей Internet провайдеров номер AS
выдает и регистрирует Американский реестр Internet номеров (American Re-
gistry of Internet Numbers – ARIN), согласно RFC 2270 для частных AS выде-
лен диапазон номеров 64512 – 65534, автономная система 65535 зарезервиро-
вана под служебные задачи.
Протоколы маршрутизации делятся на две категории: внутренние (In-
terior) и внешние (Exterior).

48
3.2.2 IGP – протоколы внутреннего шлюза

Внутренние протоколы имеют общее название IGP (Interior Gateway


Protocol, протоколы внутреннего шлюза). К ним относятся любой протокол
маршрутизации, используемый исключительно внутри автономной системы,
к таким протоколам относятся, например RIP, EIGRP и OSPF. Каждый IGP
протокол представляет один домен маршрутизации внутри AS. В пределах ав-
тономной системы может существовать множество IGP доменов (Рисунок
3.5).

AS100
EIGRP

Домены Граничный
маршрутизации маршрутизатор

RIP

Рисунок 3.5 – Домены маршрутизации внутри AS

Маршрутизаторы, поддерживающие один и тот же протокол IGP обме-


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

3.2.3 EGP – протоколы внешнего шлюза

Внешние протоколы – EGP (Exterior Gateway Protocol протоколы внеш-


него шлюза) – это протоколы маршрутизации, обеспечивающие маршрутиза-
цию между различными автономными системами. Протокол BGP (Border
Gateway Protocol, протокол пограничного шлюза) является одним из наиболее

49
известных межсистемных протоколов маршрутизации. Протоколы EGP обес-
печивают соединение отдельных AS и транзит передаваемых данных между
этими AS и через AS (Рисунок 3.6).

AS100 AS200

IGP IGP

EGP

IGP IGP

Рисунок 3.6 – Внешние протоколы маршрутизации

Протоколы EGP только распознают автономные системы в иерархии


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

3.3 Обзор классовых протоколов маршрутизации

Когда разрабатывались классовые протоколы маршрутизации сети


передачи данных сильно отличались от современных. Самые быстрые моде-
мы имели скорость передачи 300Бит/с., скорость в магистральных каналах
связи не превышала 56кБит/с., а маршрутизаторы имели максимум 640Кб
оперативной памяти. Обновления маршрутной информации были маленькие,
чтобы не занимать и так слишком малую пропускную способность маги-
стральных каналов, к тому же маршрутизаторы не имели вычислительных ре-
сурсов обрабатывать маршрутную информацию о каждой подсети.
Классовые протоколы маршрутизации не содержат в обновлениях
маршрутной информации информацию о подсетях. Поскольку маршрутная
информация не содержит информацию о подсетях, то маршрутизатор делает
предположение о маске подсети по адресу сети, пришедшему в обновлении.

50
Такое предположение основывается на классе IP адреса. После получения па-
кета с обновлением маршрутизатор чтобы определить сетевую составляю-
щую IP адреса делает следующие:
– Если обновление маршрутизации содержит тот же адрес сети, что на-
строен на интерфейсе, на который пришло обновление. Маршрутизатор до-
бавляет к маршруту маску подсети, которая назначена на интерфейсе.
– Если обновление содержит адрес сети отличный от настроенного на
интерфейсе. Маршрутизатор назначает адресу сети маску стандартную для
класса, к которому принадлежит адрес сети.
Все подсети сети класса A, B или C при использовании классового про-
токола маршрутизации должны иметь туже маску подсети. Когда производит-
ся деление на подсети адресного пространства для классовых протоколов
маршрутизации, используются маски подсетей фиксированной длины FLSM.
Если это не соблюдать, то маршрутизатор может неправильно назначать мас-
ку подсети для полученных маршрутов.

3.3.1 Суммирование маршрутов при классовой маршрутизации

Классовые протоколы маршрутизации могут производить только авто-


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

10.1.0.0/16 10.2.0.0/16 172 .16.2.0/24 172 .16.1.0/24

R1 R2 R3

10.1.0.0 10.1.0.0 10.0.0.0


10.2.0.0 10.2.0.0

172 .16.0.0 172 .16.1.0 172 .16.1.0


172 .16.2.0 172 .16.2.0

Рисунок 3.7 – Суммирование маршрутов в классовых протоколах

На рисунке 3.7 маршрутизатор R1 посылает маршрут на подсеть 10.1.0.0


маршрутизатору R2, так как он имеет подключение к нему с адресом принадле-

51
жащему той же сети 10.0.0.0. Маршрутизатор R2 используя маску подсети ин-
терфейса, с которого он получил обновление, устанавливает маску подсети для
принятого маршрута равную 16 битам.
Маршрутизаторы R2 и R3 точно также передают в обновлениях между
собой информацию о подсетях сети 172.16.0.0, потому что они имеют непо-
средственное подключение в этой сети.
Маршрутизатор R2 знает обо всех подсетях как сети 10.0.0.0, так и сети
172.16.0.0. Однако маршрутизатор R2 сначала суммирует информацию о подсе-
тях 10.1.0.0 и 10.2.0.0, прежде чем передать ее маршрутизатору R3, потому что
тот не имеет интерфейсов подключенных к сети 10.0.0.0. Маршрутизатор R2
передает маршрут 10.0.0.0 в сеть 172.16.0.0, точно также R2 передает маршрут
172.16.0.0 в сеть 10.0.0.0.

3.3.2 Суммирование маршрутов в разобщенных классовых сетях

На рисунке 3.8 показана ситуация в которой две подсети сети 10.0.0.0


подключаются через маршрутизатор принадлежащей сети 172.16.0.0.

10.1.0.0 172 .16.2.0 172 .16.1.0 10.2.0.0

S0 S1
R2 R1 R3

10.1.0.0 10.0.0.0 S0
10.0.0.0 S1 10.2.0.0

172 .16.1.0 172 .16.1.0 172 .16.1.0


172 .16.2.0 172 .16.2.0 172 .16.2.0

Рисунок 3.8 – Суммирование маршрутов при разделении сети

Так как маршрутизатор R1 использует описанный выше алгоритм назна-


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

52
3.4 Обзор бесклассовых протоколов маршрутизации

Бесклассовые протоколы маршрутизации можно назвать вторым поколе-


нием протоколов маршрутизации, потому что они разрабатывались, чтобы
снять ограничения которые накладывали классовые протоколы маршрутизации.
К бесклассовым протоколам относятся такие протоколы как RIP v2, EIGRP и
OSPF.
Главным недостатком классовых протоколов маршрутизации являлось
то, что маска подсети не передается в обновлениях маршрутной информации,
поэтому необходимо использования одной и той же маски подсети для всех
подсетях в пределах одной сети. При использовании бесклассовых протоколов
маршрутизации применяется технология VLSM, подсети одной сети могут
иметь маски переменной длины (Рисунок 3.9).

172 .16.14.0/27 17 172 .16.12.0/24


2.
R2 16
.1
4.
22
4/
30

172 .16.14.228 /30


172 .16.14.32/27
R3
0
R1
/3
32
4.2
1
6.
2.1
172 .16.14.64/27 17
172 .16.13.0/24
R4

Рисунок 3.9 – Бесклассовая маршрутизация

При использовании бесклассовых протоколов маршрутизации информа-


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

3.4.1 Суммирование маршрутов при бесклассовой маршрутизации

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


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

53
ются в пределах всего домена маршрутизации, ручное суммирование марш-
рутов может позволить уменьшить размер таблиц маршрутизации.
По умолчанию бесклассовые протоколы маршрутизации, такие как RIP
v2 и EIGRP производят автоматическое суммирование на границе сети, так
же как это делают протоколы классовой маршрутизации. Автоматическое
суммирование в эти протоколы добавлено для совместимости с их предше-
ственниками RIP v1 и IGRP. В отличие от предшественников, в протоколах
RIP v2 и EIGRP можно отключить автоматическое суммирование, используя
команду no auto–summary в настройках протокола маршрутизации, причем,
начиная с версии IOS 12.2(8)T для протокола EIGRP функция автоматическо-
го суммирования по умолчанию отключена. Протокол OSPF не использует
автоматическое суммирование.
На рисунке 3.10 изображены сети с протоколом маршрутизации RIP v2
и EIGRP и протоколом OSPF.
RIPv 2
EIGRP

Таблица
маршрутизации
172 .16.2.0/24 172 .16.1.0/24 10.1.0.0/16
10.1.0.0/16
R1 R2 R3 172 .16.0.0/16

172 .16.2.0/24 172 .16.0.0/16

OSPF

Таблица
маршрутизации
172 .16.2.0/24 172 .16.1.0/24 10.1.0.0/16
10.1.0.0/16
172 .16.1.0/24
R1 R2 R3 172 .16.2.0/24

172 .16.1.0/24
172 .16.2.0/24 172 .16.2.0/24

Рисунок 3.10 – Эффект использования автосуммирования

В сети RIP v2 или EIGRP, маршрутизатор R2 автоматически производит


суммирование маршрутов до 172.16.1.0/24 и 172.16.2.0/24 в маршрут
172.16.0.0/16 перед отправкой маршрутизатору R3. Поэтому маршрутизатор
R3 в своей таблице маршрутизации имеет запись только о суммарном марш-
руте на сеть 172.16.0.0/16.
В сети OSPF, маршрутизатор R2 не производит автоматического сум-
мирования маршрутов и отправляет маршрутизатору R3 полную маршрутную
информацию, содержащую подсеть и маску подсети. Поэтому маршрутизатор
R3 имеет в своей таблице маршрутизации записи маршрутов до обеих подсе-
тей сети 172.16.0.0/16.

54
RIPv 2
EIGRP

Таблица
маршрутизации
172 .16.2.0/24 172 .16.1.0/24 10.1.0.0/16
10.1.0.0/16
172 .16.1.0/24
R1 R2 R3 172 .16.2.0/24

172 .16.1.0/24
172 .16.2.0/24
172 .16.2.0/24

OSPF

Таблица
маршрутизации
172 .16.2.0/24 172 .16.1.0/24 10.1.0.0/16
10.1.0.0/16
172 .16.1.0/24
R1 R2 R3 172 .16.2.0/24

172 .16.1.0/24
172 .16.2.0/24 172 .16.2.0/24

Рисунок 3.11 – Эффект отключения автосуммирования

Когда автоматическое суммирование маршрутов отключено (Рисунок


3.11) протоколы RIP v2 и EIGRP, так же как и OSPF при рассылке обновлений
маршрутной информации через границу класса сети включают в нее инфор-
мацию о масках подсетей.

3.4.2 Суммирование маршрутов в разобщенных классовых сетях

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


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

192.168.1.0/24

172 .16.5.0/24 172 .16.6.0/24


172 .16.7.0/24 172 .16.9.0/24
R2 R1 R3

172 .16.0.0/16 172 .16.0.0/16

Рисунок 3.12 – Суммирование в бесклассовых


протоколах маршрутизации

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


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

55
маршрутизаторов. Протоколы бесклассовой маршрутизации используют ме-
ханизм наибольшего соответствия при выборе маршрута. Поэтому если
маршрутизатор R1 будет знать маршруты на 172.16.6.0/24, 172.16.9.0/24 и
суммарный маршрут на 172.16.0.0/16, он сможет правильно маршрутизиро-
вать трафик к маршрутизаторам R2 и R3. Трафик до R3 будет использовать
маршруты до подсетей 172.16.6.0/24 и 172.16.9.0/24, а трафик до маршрутиза-
тора R2 будет отправляться по суммарному маршруту 172.16.0.0/16.

3.5 Категории алгоритмов маршрутизации

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


из трех категории:
– дистанционно-векторные протоколы;
– протоколы с учетом состояния канала;
– сбалансированные гибридные протоколы.
Дистанционно-векторный протокол (distance vector routing protocol)
определяет направление, или вектор, и расстояние до нужного узла объеди-
ненной сети.
Протокол с учетом состояния канала (link-state routing protocol), также
называется алгоритмом выбора кратчайшего пути (shortest path first – SPF),
воссоздает топологию сети на каждом маршрутизаторе.
Сбалансированный гибридный протокол (balanced hybrid routing pro-
tocol) соединяет в себе определенные черты обоих предыдущих типов алго-
ритмов.

3.5.1 Особенности дистанционно-векторных протоколов

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


рутизаторами происходит периодическая пересылка копий таблиц маршрути-
зации друг друга. В таких регулярных обновлениях маршрутизаторы сообща-
ют друг другу об изменениях в топологии сети. Дистанционно-векторные ал-
горитмы маршрутизации также называются алгоритмами Белламана–Форда
(Bellaman–Ford).
На рисунке 3.13 каждый маршрутизатор получает таблицу маршрутиза-
ции от соседних маршрутизаторов. В частности маршрутизатор R2 получает
информацию от маршрутизатора R1. Маршрутизатор R2 добавляет значение
вектора расстояния, количества переходов, что увеличивает результирующий
вектор расстояния. После этого маршрутизатор R2 передает свою новую та-
блицу маршрутизации своему соседу, маршрутизатор R3. Такой пошаговый
процесс происходит на всех соседних маршрутизаторах.

56
R2

R3 R1

R4

R4 R3 R2 R1

Рисунок 3.13 – Концепция дистанционно-векторной маршрутизации

В дистанционно-векторном алгоритме накапливаются расстояния в


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

W X Y Z

R1 R2 R3

Таблица Таблица Таблица


маршрутизации маршрутизации маршрутизации
W 0 X 0 Y 0

X 0 Y 0 Z 0

Y 1 Z 1 X 1

Z 2 W 1 W 2

Рисунок 3.14 – Процесс построения структуры сети в


дистанционно-векторной маршрутизации

На рисунке 3.14 проиллюстрировано формирование вектора расстоя-


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

57
Применение дистанционно-векторной маршрутизации накладывает
жесткие ограничения по диаметру сети передачи данных. Такие протоколы
маршрутизации не предназначены для функционирования в больших объеди-
ненных сетях с множеством каналов связи, где маршрутизаторы соединяют
сотни или даже тысячи сетей. Максимальный диаметр сети определяет рас-
стояние, на которое можно передать пакет, после чего пункт назначения счи-
тается недостижимым. Это максимальное расстояние измеряется числом
пересылок от отправителя к получателю. Правило максимального расстояния
гласит: Между двумя нельзя установить соединение, если они находятся на
расстоянии более чем X пересылок.
Для протоколов RIP v1 и v2 максимальное число пересылок равно 15.
Это означает, что диаметр сети не должен превышать 15 маршрутизаторов.
Еще одним важным понятием в дистанционно-векторных алгоритмах
маршрутизации является сходимость сети. Сходимость достигается, когда все
маршрутизаторы внутри домена маршрутизации имеют согласованную ин-
формацию о доступных маршрутах. Дистанционно-векторные протоколы тре-
буют рассылки маршрутизаторами своей таблицы маршрутизации всем своим
соседям. Частотой рассылки управляют таймеры. Когда маршрутизатор полу-
чает обновление маршрутной информации, он, прежде чем передавать тра-
фик, должен произвести пересчет всех маршрутов и обновить таблицу марш-
рутизации.
Дистанционно-векторные протоколы отличаются медленной сходимо-
стью, и поэтому весьма подвержены возникновению петель маршрутизации.
Время, которое требуется, для того чтобы все маршрутизаторы обработали
обновление маршрутной информации и обновили свои таблицы маршрутиза-
ции, называется временем сходимости. Это очень важный параметр сети, по-
скольку при отказе канала или маршрутизатора данные не передаются в
объединенной сети до тех пор, пока все таблицы маршрутизации не будут
полностью обновлены.

3.5.2 Маршрутизация по состоянию канала

Вторым базовым алгоритмом маршрутизации является алгоритм выбо-


ра маршрута по состоянию канала. Такие алгоритмы известны как алгоритмы
Дейкстры (Dijkstra) или как алгоритмы выбора кратчайшего пути (Shortest
Path First – SPF). Они поддерживают сложную базу топологии сети. Дистан-
ционно-векторные алгоритмы не содержат определенной информации об уда-
ленных сетях и маршрутизаторах, алгоритмы с использованием состояния ка-
нала поддерживают полную информацию об удаленных маршрутизаторах и
их соединениях друг с другом. Одним из самых широко распространенных
протоколов маршрутизации с учетом состояния канала является протокол
OSPF. Ключевыми понятиями алгоритмов по состоянию канала являются:

58
– сообщение о состоянии канала (Link-State Advertisement - LSA). Эти
объявления представляют собой небольшие пакеты, которые содержат ин-
формацию об известных маршрутизатору каналах связи;
– база данных топологии (Topological Database). Эта база данных содер-
жит информацию, полученную в сообщениях LSA;
– алгоритм выбора кратчайшего пути (Shortest Path First – SPF). Алго-
ритм осуществляет вычисления над базой данных топологии сети, результа-
том чего является построение связующего дерева протокола SPF.
На рисунке 3.15 проиллюстрированы основные операции алгоритма
маршрутизации на основе состояния канала.

A LS
A
LS

Таблица
LS SA
маршрутизации
A
L

База данных
топологии сети


SPF

Дерево SPF

Рисунок 3.15 – Основные действия алгоритма маршрутизации


на основе состояния канала

Маршрутизаторы обмениваются сообщениями LSA, начиная с непо-


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

59
Если маршрутизатор узнает об изменении состояния канала, он рассы-
лает эту информацию остальным маршрутизаторам домена маршрутизации с
тем, чтобы они смогли отразить ее в своих базах топологии сети. При получе-
нии маршрутизатором пакета LSA его база топологии сети обновляется в со-
ответствии с последней полученной информацией. При получении каждого
пакета LSA, содержащего изменения состояний каналов, алгоритм SPF заново
вычисляет наилучшие маршруты и обновляет таблицу маршрутизации.
Время сходимости протоколов маршрутизации с учетом состояния ка-
налов связи значительно меньше, чем у дистанционно-векторных протоколов
маршрутизации. Это связано с тем, что каждый маршрутизатор в домене
маршрутизации имеет информацию о реальной топологии сети и может само-
стоятельно производить пересчет маршрутов к сетям получателям при полу-
чении пакетов LSA с изменениями топологии сети. Фактически временем
сходимости сети будет время необходимое для расчета нового SPF дерева по-
сле получения изменений топологии сети.
При использовании протоколов состояния канала возникают две основ-
ные проблемы:
– перегрузка процессора служебной информацией;
– повышение требований к оперативной памяти.
Маршрутизаторы, на которых работают протоколы маршрутизации с
учетом состояния канала, требуют большего объема памяти и выполняют
больший объем обработки данных, чем при использовании дистанционно-
векторных протоколов маршрутизации.
Как показано на рисунке 3.16, маршрутизаторы должны иметь доста-
точно памяти для сохранения большого объема информации в базе топологии
сети.


Базаданных
топологиисети SPF

Таблица
маршрутизации

Дерево SPF

Рисунок 3.16 – Проблемы протоколов состояния канала

60
3.5.3 Гибридные протоколы маршрутизации

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


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

3.6 Конфигурирование протокола маршрутизации

В маршрутизаторах Cisco все протоколы маршрутизации имеют общие


аспекты конфигурирования. Для запуска протокола маршрутизации использу-
ется команда router. Синтаксис команды представлен в примере 3.1.

Пример 3.1 – Синтаксис команды router


(config) router protocol {process-id | autonomous-system }

Описание параметров команды router приводиться в таблице 3.1.

Таблица 3.1 – Параметры команды router

Параметр Описание
protocol Один из возможных протоколов марш-
рутизации RIP, EIGRP, OSPF и т.д.
process-id Идентификатор процесса маршрутиза-
ции.
autonomous-system Номер автономной системы.

После запуска процесса маршрутизации необходимо в режиме конфигу-


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

61
сетей участвующих в процессе маршрутизации используется команда net-
work. Синтаксис команды представлен в примере 3.2.

Пример 3.2 – Синтаксис команды network


(config-router) network ip-address [subnet-mask]

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


це 3.2.

Таблица 3.2 – Параметры команды network

Параметр Описание
ip-address IP адрес сети участвующей в процессе
маршрутизации.
subnet-mask Сетевая маска.

Команда network может иметь различный синтаксис в зависимости от


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

Пример 3.3 – Синтаксис команды passive-interface


(config-router) passive-interface [default] {interface-type interface-number}
(config-router) no passive-interface {interface-type interface-number}

Описание основных параметров команды passive-interface приводиться


в таблице 3.3.

62
Таблица 3.3 – Параметры команды passive-interface

Параметр Описание
default Задание по умолчанию пассивного ре-
жима на всех интерфейсах маршрути-
затора.
interface-type Тип интерфейса.
interface-number Номер интерфейса.

Применение данной команды позволяет производить рассылку служеб-


ных пакетов маршрутизации только по тем интерфейсам, за которыми распо-
лагаются соседние маршрутизаторы.
Хорошим тоном в настойке маршрутизаторов является применение ко-
манды passive-interface default, которая отключает рассылку маршрутной ин-
формации со всех интерфейсам маршрутизатора. А для включения возможно-
сти обмена маршрутной информацией применение команды no passive-inter-
face для конкретных интерфейсов.
Применение данного механизма позволяет уменьшить нагрузку на сеть,
а так же в некоторой мере защитить сеть от угрозы атак со стороны злоумыш-
ленников.
Как говорилось ранее, протоколы динамической маршрутизации могут
производить балансировку нагрузки по маршрутам с равной стоимостью.
Большинство протоколов способны осуществлять распределение на-
грузки по нескольким маршрутам, число которых для версий ОС IOS начиная
с 12.3(2)T не должно превышать 16. Количество одновременно используемых
маршрутов может быть указано с помощью команды maximum-paths. Синтак-
сис команды представлен в примере 3.4.

Пример 3.4 – Синтаксис команды maximum-paths


(config-router) maximum-paths [number-of-paths]
(config-router) no maximum-paths

Описание основных параметров команды maximum-paths приводиться в


таблице 3.4.

Таблица 3.4 – Параметры команды maximum-paths

Параметр Описание
number-of-paths Число одновременно используемых
параллельных маршрутов передавае-
мых в таблицу маршрутизации.

63
Стандартно количество маршрутов для перераспределения нагрузки в
большинстве протоколов маршрутизации не должно превышать четырех.
Маршрутизатор осуществляет балансировку нагрузки по циклическому
принципу, который предполагает, что по очереди используется сначала пер-
вый, потом второй и так далее параллельный канал, и по достижении послед-
него процедура повторяется.
Для многих интерфейсов маршрутизаторов Cisco стандартно включен
механизм быстрой коммутации пакетов (Fast Switching), о чем свидетельству-
ет команда ip route-cache в их конфигурации. В этом случае распределение
нагрузки осуществляется на основе IP адресов получателей. Это означает, что
при наличии, например, двух каналов все пакеты для IP адреса одного полу-
чателя будут отправлены через первый канал, для второго адресата через вто-
рой, для третьего снова по первому каналу.
Если в конфигурации интерфейса ввести команду no ip route-cache, то в
действие вступит программный механизм коммутации, который осуще-
ствляет балансировку нагрузки в пакетном режиме, т.е. первый пакет отправ-
ляется по первому каналу, второй по второму, а третий пакет снова по перво-
му каналу.

64
4 Дистанционно-векторная маршрутизация

4.1 Дистанционно-векторный алгоритм

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


тизации основываются на дистанционно-векторном алгоритме, который был
впервые описан Фордом и Фулкерсоном в работе «Потоки в Сетях». Их рабо-
та опиралась в свою очередь на уравнение Беллмана из его книги «Динамиче-
ское программирование».
Изучение классического дистанционно-векторного алгоритма прово-
диться в курсе дискретной математики. Мы же рассмотрим версию, которая
используется в протоколах динамической маршрутизации.
Задача, которую решает дистанционно-векторный алгоритм, – это зада-
ча нахождения кратчайших путей между вершинами графа. Граф – это мате-
матическая абстракция, в которой вершины соединены между собой ребрами.
Каждое ребро имеет некоторую стоимость его использования. Путь между
двумя вершинами является набором промежуточных ребер и вершин, соеди-
няющих две исходные вершины. Стоимость пути определяется как сумма
стоимостей ребер, составляющих его. Кратчайшим путем между двумя вер-
шинами при этом считается путь с наименьшей стоимостью.
Дистанционно-векторный алгоритм можно определить в виде следую-
щего набора правил:
– В начале работы алгоритма каждая вершина знает лишь пути к смеж-
ным вершинам, т. е. вершинам, с которыми она соединена ребрами.
– В процессе работы алгоритма смежные вершины сообщают друг дру-
гу о вершинах, им доступных. Каждое объявление состоит из вершины-адре-
сата и стоимости кратчайшего пути, известного информирующей вершине.
– Изначально каждая вершина сообщает только о смежных вершинах со
стоимостью кратчайших путей, равной стоимости ребер.
– При получении объявления вершина рассчитывает стоимость пути к
объявленной вершине через объявляющую как сумму стоимости ребра, веду-
щего к объявляющей вершине, и стоимости пути, содержащегося в объявле-
нии. После этого вершина проверяет, знает ли она уже о пути к объявленной
вершине-адресату.
– Если не знает или если стоимость известного пути больше вычислен-
ной стоимости нового пути, вершина запоминает новый путь к вершине-адре-
сату.
– Если новый путь заменяет существующий, последний отбрасывается.
– Если стоимость существующего пути меньше или равна стоимости
нового пути, последний будет отброшен.
– После запоминания нового пути вершина должна объявить смежным
вершинам вершину адресат и стоимость нового пути.

65
Математически доказано, что описанный алгоритм вычисляет крат-
чайшие пути между всеми парами вершин за конечный промежуток времени
(Рисунок 4.1).

A
1 1

B C
1 1 1 1

D E F H

Шаг 1 A B C D E F H

B 1 B A 1 A A 1 A B 1 B B 1 B C 1 C C 1 C

C 1 C D 1 D F 1 F

E 1 E H 1 H

Шаг 2 A B C D E F H

B 1 B A 1 A A 1 A A 2 B A 2 B A 2 C A 2 C

C 1 C C 2 A B 2 A B 1 B B 1 B C 1 C C 1 C

D 2 B D 1 D F 1 F E 2 B D 2 B H 2 C F 2 C

E 2 B E 1 E H 1 H

F 2 C

H 2 C

Шаг 3 A B C D E F H

B 1 B A 1 A A 1 A A 2 B A 2 B A 2 C A 2 C

C 1 C C 2 A B 2 A B 1 B B 1 B B 3 C B 3 C

D 2 B D 1 D D 3 A C 3 B C 3 B C 1 C C 1 C

E 2 B E 1 E E 3 A E 2 B D 2 B H 2 C F 2 C

F 2 C F 3 A F 1 F

H 2 C H 3 A H 1 H

Шаг 4 A B C D E F H

B 1 B A 1 A A 1 A A 2 B A 2 B A 2 C A 2 C

C 1 C C 2 A B 2 A B 1 B B 1 B B 3 C B 3 C

D 2 B D 1 D D 3 A C 3 B C 3 B C 1 C C 1 C

E 2 B E 1 E E 3 A E 2 B D 2 B D 4 C D 4 C

F 2 C F 3 A F 1 F F 4 B F 4 B E 4 C E 4 C

H 2 C H 3 A H 1 H H 4 B H 4 B H 2 C F 2 C

Рисунок 4.1 – Функционирование дистанционно-векторного алгоритма

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


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

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

4.1.1 Дистанционно-векторный алгоритм для протокола IP

В версии дистанционно-векторного алгоритма для протокола IP или


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

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

68
На рисунке 4.2 показано, как дистанционно-векторные протоколы обра-
батывают изменения топологии.

Обновление Обновление
таблицы таблицы
маршрутизации маршрутизации

R1 рассылает
обновленную Изменение
таблицу топологиисети
R2 маршрутизации R1

Рисунок 4.2 – Обработка изменений топологии сети

Когда маршрутизатор начинает получать маршрутные обновления от


других маршрутизаторов, он заполняет свою таблицу маршрутизации объяв-
ленными сетевыми префиксами, которые затем начинает объявлять сам. В
итоге все маршрутизаторы сегмента маршрутизации узнают обо всех сетевых
префиксах, доступных в сегменте.
Дистанционно-векторные алгоритмы требуют, чтобы каждый маршру-
тизатор рассылал копию своей таблицы маршрутизации соседним маршрути-
заторам (neighbor router).
Маршрутизацию на основе дистанционно-векторного протокола иногда
называют «маршрутизацией по слухам» («routing by rumors»), поскольку
маршрутизаторы не знают ничего о маршрутизаторах на пути к известным им
сетевым префиксам.
Дистанционно векторные протоколы маршрутизации являются самыми
простыми алгоритмами динамической маршрутизации. Использование про-
стых алгоритмов позволяет снизить вычислительную нагрузку на маршрути-
заторы, однако использование таких алгоритмов маршрутизации имеет и свои
слабые стороны. Перед тем как администратор корпоративной сети передачи
данных сделает свой выбор в пользу одного из дистанционно-векторных про-
токолов маршрутизации, ему необходимо понять слабые стороны дистанци-
онно векторной маршрутизации и пути решения возможных проблем.

4.2 Маршрутизация по замкнутому кругу

Явление маршрутизации по замкнутому кругу может возникать в тех


случаях, когда плохая сходимость сети для новой топологии сети может вы-
зывать наличие противоречивых записей о маршрутах (Рисунок 4.3).

69
R2

Сеть 1 недостижима
R3 R1 R5

Сеть 1
Альтернативный маршрут : R4 Альтернативный маршрут :
Сеть 1, расстояние = 3 Сеть 1, расстояние = 4

Рисунок 4.3 – Петли маршрутизации

1. Непосредственно перед выходом из строя «Сети 1» все маршрутиза-


торы имеют согласованные и корректные таблицы маршрутизации, т.е. для
данного домена маршрутизации произошла конвергенция. Предположим, что
для маршрутизатора R3 наилучший маршрут к «Сети 1» проходит через
маршрутизатор R2 и что в своей таблице маршрутизации маршрутизатор R3
имеет запись о расстоянии до «Сети 1», равном 3 переходам.
2. Если «Сеть 1» выходит из строя, то маршрутизатор R5 пересылает
маршрутизатору R1 обновление маршрутов, содержащее эту информацию.
После получения обновления маршрутизатор R1 прекращает направлять па-
кеты в «Сеть 1», однако маршрутизаторы R2, R3 и R4 продолжают это делать,
так как они еще не проинформированы о сбое в «Сети 1». После того как
маршрутизатор R1 отправляет свое обновление маршрутной информации,
маршрутизаторы R2 и R4 прекращают направлять пакеты в «Сеть 1». Однако
в этот момент маршрутизатор R3 еще не получил обновление маршрутной
информации. Для него по-прежнему «Сеть 1» считается доступной через
маршрутизатор R2.
3. Предположим, что маршрутизатор R3 не успел получить обновлен-
ную информацию о топологии сети от своих соседей, но по алгоритму работы
дистанционно-векторных протоколов маршрутизации настало время рассыл-
ки маршрутной информации своим соседям. Маршрутизатор R3 посылает
свою таблицу маршрутизации маршрутизатору R4, указывая, что он имеет
маршрут до «Сети 1» через маршрутизатор R2. Маршрутизатор R4 изменяет
свою таблицу маршрутизации, отражая эту хорошую, но не правильную ин-
формацию, и передает эти сведения дальше маршрутизатору R1. Маршрути-
затор R1 распространяет ее маршрутизаторам R2 и R5. Теперь любой пакет,
имеющий назначением «Сеть 1», движется по кольцевому маршруту (петле)
от маршрутизатора R3 к маршрутизатору R2, далее к R1 и R4 и вновь к марш-
рутизатору R3.

70
4.3 Максимальное количество транзитных переходов

Продолжим рассмотрение примера, пакеты обновления с информацией


о «Сети 1» будут продолжать ходить по кругу до тех пор, пока какой-нибудь
другой процесс не сможет остановить это зацикливание. Подобное состояние,
называемое счетом до бесконечности (count to infinity), продолжает зацикли-
вание перемещения пакетов по сети. Пока маршрутизаторы имеют возмож-
ность считать до бесконечности, некорректная информация позволяет суще-
ствовать маршрутизации по кругу.
В отсутствие контрмер, которые могли бы остановить процесс, вектор
расстояния, исчисляемый количеством переходов, увеличивается на единицу
каждый раз, когда пакет проходит следующий маршрутизатор (Рисунок 4.4).
Эти пакеты ходят в сети по кругу, из-за неправильной информации в табли-
цах маршрутизации.

Сеть 1, расстояние =7
R2
Сеть 1, расстояние =6

R3 R1 R5


Сеть 1, расстояние =4

Сеть 1, расстояние =5 Сеть 1


R4

Рисунок 4.4 – Счет до бесконечности

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


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

71
Сеть 1, расстояние = 14
R2
Сеть 1, расстояние = 13

R3 R1 R5


Сеть 1, расстояние = 15

Сеть 1, расстояние = 12 Сеть 1


R4

Таблица маршрутизации
max метрика = 16
Сеть 1 недостижима

Рисунок 4.5 – Назначение максимальной длины маршрута

На рисунке 4.5 показан случай, когда это максимальное значение равно


16; обычно для векторов расстояния, измеряемых в количестве переходов,
максимальное значение устанавливается равным 15 переходам. В любом слу-
чае, если значение метрики превысит максимум, то «Сеть 1» будет считаться
недостижимой.

4.4 Применения принципа расщепления горизонта

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


туация, когда неправильная информация, посылаемая назад маршрутизатору,
противоречит информации, посылаемой им самим. Вот как возникает эта
проблема.
1. Маршрутизатор R1 передает маршрутизаторам R2 и R4 пакет с об-
новлением маршрутной информации, говорящий о том, что «Сеть 1» стала
недоступна.
2. Однако маршрутизатор R3 передает маршрутизатору R2 пакет обнов-
ления, который информирует, что «Сеть 1» доступна по маршруту с расстоя-
нием 4 через маршрутизатор R4. Такое действие не нарушает правило рас-
щепления горизонта, так как для маршрутизатора R3 «Сеть 1» находится за
двумя его интерфейсами и оба маршрута имеют одинаковую метрику равную
3.
2. Маршрутизатор R2 делает неправильный вывод о том, что маршрути-
затор R3 имеет достоверный путь к «Сети 1», хотя и с менее предпочтитель-

72
ной метрикой. Маршрутизатор R2 посылает маршрутизатору R1 пакет обнов-
ления информации, в котором дает совет R1 о "новом" маршруте к «Сети 1».
3. Теперь маршрутизатор R1 определяет, что он может посылать пакеты
в «Сеть 1» через маршрутизатор R2; маршрутизатор R2 определяет, что он
может посылать пакеты через маршрутизатор R3, а маршрутизатор R3 опре-
деляет, что он может посылать пакеты в «Сеть 1» через маршрутизатор R4.
Любой пакет, помещенный в такую среду, будет ходить по кругу между
маршрутизаторами.
Одним из способов устранения маршрутизации по кругу и ускорения
сходимости сети является метод так называемого расщепления горизонта
(split horizon). Логика, стоящая за этим методом, заключается в том, что ни-
когда нет ничего хорошего в посылке информации о маршруте назад в
направлении, из которого она первоначально пришла. Согласно этому мето-
ду, при поступлении сообщения об обновлении маршрутов для «Сети 1» от
маршрутизатора R1, маршрутизаторы R2 и R4 не могут посылать информа-
цию о «Сети 1» в обратном направлении, т.е. маршрутизатору R1 (Рисунок
4.6).

Сеть 1 ...
R2

Сеть 1 недостижима
R3 R1 R5

Сеть 1 ... Сеть 1


R4

Рисунок 4.6 – Расщепление горизонта

4.5 Обратное обновление

Обратное обновление (poison reverse) позволяет маршрутизаторам отме-


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

73
Сеть 1, расстояние = 16
R2

Сеть 1 недостижима
R3 R1 R5

Сеть 1, расстояние = 16 Сеть 1


R4

Рисунок 4.7 – Обратное обновление

4.6 Таймеры удержания информации

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


удержания информации (hold-down timer) (Рисунок 4.8).
Внести обновления
маршрутов после
срабатывания таймера
Внестиобновления R2
маршрутов после
срабатывания таймера

R3 R1 R5

Внести обновления 
маршрутов после
срабатывания таймера
Внести обновления
маршрутов после Сеть 1
срабатывания таймера R4

Рисунок 4.8 – Таймеры удержания информации

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


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

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

4.7 Механизм мгновенных обновлений

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


соседним маршрутизаторам. Протокол маршрутизации рассылает сообщения
обновлений каждые 30 секунд. Однако применение мгновенных обновлений
(triggered update) позволяет рассылать сообщения немедленно в ответ на ка-
кое-либо изменение в таблице маршрутизации. Маршрутизатор обнаружив-
ший изменение в топологии, немедленно рассылает сообщение-обновление
смежным маршрутизаторам. Такие маршрутизаторы в свою очередь также ге-
нерируют мгновенные обновления, оповещая о переменах своих соседей. При
выходе какого-либо маршрута из строя сообщение об этом отправляется, не
дожидаясь истечения времени таймера обновления. Мгновенное сообщение
представляет собой анонс, который рассылается до истечения времени тайме-
ра обновления. Такой принцип работы приводит к рассылке обновленной ин-
формации о состоянии маршрута и сбрасывает таймеры на соседних маршру-
тизаторах. Эта волна обновлений распространяется по всей сети (Рисунок 4.9)

Сеть 1 недостижима
R2
Сеть 1 недостижима

Сеть 1 недостижима
R3 R1 R5

Сеть 1 недостижима Сеть 1


R4

Рисунок 4.9 – Мгновенные обновления

75
Маршрутизатор R5 генерирует мгновенное обновление, извещая о том,
что «Сеть 1» недостижима. После получения этой информации маршрутиза-
тор R1 извещает соседние с ним маршрутизаторы R2 и R4, а они в свою оче-
редь маршрутизатор R3.

76
5 Протокол RIP

Протокол маршрутной информации (Routing Informational Protocol –


RIP) был первоначально определен в документе RFC 1058. Наиболее суще-
ственны следующие его характеристики:
– RIP является дистанционно-векторным протоколом маршрутизации;
– В качестве метрики при выборе маршрута используется количество
переходов;
– Максимальная длина маршрута равняется 15 переходам;
– По умолчанию обновления маршрутной информации рассылаются
широковещательным способом.
При работе протокола RIP используется транспортный протокол UDP.
Все устройства, поддерживающие RIP, прослушивают UDP порт 520 и осуще-
ствляют передачу через этот же порт. В сетях общего доступа, таких как Eth-
ernet, эти широковещательные дейтаграммы получают все устройства широ-
ковещательного домена.
Протокол RIP использует расстояние как единственную метрику для
определения наилучшего маршрута, т.е. чем короче маршрут, тем он лучше.
Если к пункту назначения существует множество маршрутов, то маршрутиза-
торы поддерживающие протокол RIP, выбирают из них кротчайший и запи-
сывают его в таблицу маршрутизации.

19.2k

E1 E1

E1

Рисунок 5.1 – Метрика маршрута в протоколе RIP

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


пропускания равной 19,2 Кбит/с включает в себя три перехода. Нижний аль-
тернативный маршрут по каналам связи E1 включает пять переходов. По-
скольку выбор маршрута в протоколе RIP основывается исключительно на
количестве переходов, то в данном случае в таблицу маршрутизации будет за-
писан маршрут с пропускной способностью 19,2 Кбит/с вместо гораздо более
быстрых каналов E1.

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

5.1 Настройка протокола RIP

Для настройки протокола RIP на маршрутизаторах Cisco необходимо


использовать команду router rip. После запуска на маршрутизаторе процесса
маршрутизации RIP необходимо включить в данный процесс маршрутизации
сети, о которых будет распространяться маршрутная информация. Для описа-
ния сетей участвующих в процессе маршрутизации используется команда net-
work network–number (Рисунок 5.2).

192 .168 .1.0/24 172.16.1.0/24 10.1.1.0/24

R1 R2 R3 R4

r1# router rip r2# router rip r3# router rip r4# router rip
network 192.168.1.0 network 172.16.0.0 network 10.0.0.0 network 10.0.0.0
network 192.168.1.0 network 172.16.0.0

Рисунок 5.2 – Запуск процесса маршрутизации RIP

После задания сетей участвующих в процессе маршрутизации, с интер-


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

5.2 Протокол RIP v1

Протокол RIP v1 является классовым протоколом маршрутизации, и он


не поддерживает технологию VLSM. В настоящее время применение данного
маршрутизирующего протокола ограничено.

78
5.2.1 Заголовок и поля протокола RIP v1

Устройства, поддерживающие RIP, используют два типа пакетов для


обмена маршрутной информацией. Сообщения первого типа применяются
для запроса на получение маршрутной информации. Сообщение второго типа
содержит ответ на запрос маршрутной информации.
Формат сообщений протокола RIP v1 приводится на рисунке 5.3.
32 бита
8 8 8 8
Неиспользуемоеполе
Команда Версия (заполняетсянулями )
Идентификаторсемейства Неиспользуемоеполе
адресов (заполняетсянулями )
Запись маршрута

IP Адрес

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

Метрика

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

Идентификаторсемейства Неиспользуемоеполе
адресов (заполняетсянулями )
Запись маршрута

IP Адрес

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

Метрика

Рисунок 5.3 – Формат сообщения протокола RIP v1

Сообщение начинается с фиксированного заголовка и далее следует


список пар значений: сеть и дистанция до нее. Размер сообщения зависит от
числа пар «сеть/дистанция», однако он не может превышать 512 байт. Кроме
того, пакет не может содержать более 25 записей о маршрутах. Максималь-
ный размер 512 байт не включает заголовки канального уровня, IP и UDP за-
головки.
Каждое сообщение начинается с трех полей, первое поле – команда,
второе – версия, третье поле зарезервировано и не используется. Далее следу-
ют поля с сетями и дистанциями до них, которые повторяются в зависимости
от числа маршрутов объявленных маршрутизатором. Например, если марш-
рутизатор объявляет о пяти маршрутах, то пять раз повторяются группы по-
лей о записи маршрута.

79
5.2.2 Команда – 1 байт

Это поле указывает предполагаемую цель сообщения, в частности, яв-


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

Таблица 5.1 – Команды сообщений протокола RIP

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

5.2.3 Версия – 1 байт

Поле версии указывает версию протокола RIP, 1 или 2. Маршрутизато-


ры поддерживающие протокол RIP, должны согласовывать применяемую
версию протокола. Если в сети существуют обе версии протокола, то из-за
того, что устройства версии 1 не поддерживают расширений, реализованных
в версии 2, могут возникнуть проблемы при их взаимодействии.

5.2.4 Неиспользуемые поля – 2 байта

Формат сообщения версии 1 включает несколько неиспользуемых по-


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

5.2.5 Идентификатор семейства адресов – 2 байта

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


колы сетевого уровня, это поле содержит только значение 2, которое соответ-
ствует протоколу IP.

80
5.2.6 IP адрес – 4 байта

Поле IP адрес указывает адрес пункта назначение: сети, подсети или


маршрута по умолчанию, объявляемого маршрутизатором.

5.2.6 Метрика – 4 байта

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


пересылок от маршрутизатора до сети получателя. Поле должно содержать
значения от 1 до 15, если поле содержит значение 16, то данная сеть считает-
ся недоступной.

5.3 Использование команды ip classless

R2# show ip route


...
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
10.0.0.0/24 is subnetted, 3 subnets,
R 10.1.1.0/24 [120/1] via 10.1.2.2, 00:00:05, Ethernet 0
C 10.1.2.0/24 is directly connected, Ethernet 0
R 10.1.3.0/24 [120/2] via 10.1.2.2, 00:00:05, Ethernet 0
R 192.168.24.0/24 [120/2] via 10.1.2.2, 00:00:16, Ethernet 0
R 172.16.0.0/16 [120/3] via 10.1.2.2, 00:00:16, Ethernet 0
R* 0.0.0.0/0 [120/2] via 10.1.2.2, 00:00:05, Ethernet 0

Рисунок 5.4 – Таблица маршрутизации протокола RIP v1

На рисунке 5.4 приводиться пример таблицы маршрутизации содержа-


щей маршруты от классового протокола RIP v1.
По каким маршрутам будет отправлен трафик до хостов?
– 192.168.24.3;
– 172.16.5.1;
– 10.1.2.7;
– 200.100.50.1;
– 10.2.2.2.
Таблица маршрутизации содержит маршруты до подсетей, в которых на-
ходятся первые три хоста. Следовательно, пакеты до хостов в этих сетях будут
направлены по соответствующим маршрутам.
До четвертого хоста нет маршрута в таблице маршрутизации, однако
определен маршрут по умолчанию, по которому и будет отправлен трафик до
четвертого хоста.
Пятый хост принадлежит неизвестной подсети 10.2.2.0/24 сети 10.0.0.0/24
которая присутствует в таблице маршрутизации. По умолчанию, протоколы
классовой маршрутизации предполагают, что им известны маршруты до всех
подсетей. Поэтому трафик до 10.2.2.2 будет отвергнут.

81
Поведение классовых протоколов маршрутизации меняется при исполь-
зовании команды ip classless. Данная команда заставляет классовый протокол
маршрутизации отправлять трафик, используя принцип наибольшего соответ-
ствия. Это также справедливо для неизвестных подсетей известных сетей.
Поэтому при использовании команды ip classless маршрутизатор отпра-
вит трафик до 10.2.2.2 по маршруту заданному по умолчанию.
В ОС Cisco IOS начиная с версии 11.3, данная команда включена по
умолчанию.

5.4 Недостатки протокола RIP v1

Протокол RIP v1 обладает рядом существенных недостатков, главными


из которых являются следующие:
– Является классовым протоколом маршрутизации, но не поддерживает
технологию VLSM;
– Отсутствие возможности производить суммирование маршрутов;
– Использует широковещательный механизм рассылки обновлений
маршрутной информации;
– В реализации протокола отсутствуют механизмы аутентификации со-
седних маршрутизаторов при передачи маршрутной информации.
Для устранения перечисленных недостатков была разработана следую-
щая версия протокола RIP – RIP v2.

5.5 Протокол RIP v2

Протокол RIP v2 является бесклассовым дистанционно векторным про-


токолом маршрутизации, он описан в RFC 1721–1724 и 2453. Цель создания
второй версии протокола RIP была в том, чтобы расширить возможности про-
токола. Главным дополнением второй версии стала поддержка технологии
VLSM протоколом RIP. Основные отличия второй версии от первой являют-
ся:
– Бесклассовая маршрутизация;
– Поддержка технологии VLSM;
– Использование групповой рассылки маршрутной информации;
– Поддержка аутентификации соседних маршрутизаторов;
– Поддержка ручного суммирования маршрутов.
Протокол RIP v2 использует групповой адрес 224.0.0.9 для периодиче-
ского обновления маршрутной информации с другими RIP v2 маршрутизато-
рами. Такой подход является более эффективным, потому что RIP v1 исполь-
зовал широковещательный адрес сети, что приводило к необходимости всем

82
устройствам в широковещательном домене обрабатывать пакеты обновления
маршрутной информации.

5.5.1 Заголовок и поля протокола RIP v2


32 бита
8 8 8 8
Неиспользуемоеполе
Команда Версия
(заполняетсянулями )
Идентификаторсемейства
Тег маршрута
адресов

Запись маршрута
IP Адрес

Маскаподсети

Следующая пересылка

Метрика

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

Идентификаторсемейства Тег маршрута


адресов
Запись маршрута

IP Адрес

Маскаподсети

Следующая пересылка

Метрика

Рисунок 5.5 – Формат сообщения протокола RIP v2

Заголовок RIP v2 в основном подобен заголовку RIP v1. Из рисунка 5.5


видно, что несколько неиспользованных ранее в заголовке RIP v1 полей те-
перь используются для поддержки технологии VLSM. Следует обратить осо-
бое внимание на появление полей маски подсети и следующей пересылки.
Оба этих поля являются ключевыми для обеспечения поддержки подсетей.

5.5.2 Тег маршрута – 2 байта

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


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

5.5.3 Маска подсети – 4 байта

Поле содержит маску подсети для IP адреса сети получателя. Наличие


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

83
5.5.4 Следующая пересылка – 4 байта

Поле содержит IP адрес следующего маршрутизатора, которому должен


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

5.6 Аутентификация в протоколе RIP v2

В отличие от версии 1, которая не поддерживает аутентификацию, вер-


сия 2 позволяет использовать для аутентификации, как нешифрованные тек-
стовые пароли, так и аутентификацию с использованием алгоритма хеширо-
вания MD5. Использование алгоритма MD5 с точки зрения защиты информа-
ции предпочтительнее, однако, в RFC 1723 описан только метод аутентифи-
кации при помощи нешифрованного пароля, что привело к тому, что не все
производители сетевого оборудования реализовали возможность использова-
ния MD5 в своей продукции.
Для каждой пары маршрутизаторов обменивающихся маршрутной ин-
формацией может быть настроен уникальный пароль. На рисунке 5.6 приво-
дится формат пакета обновления маршрутной информации с использованием
аутентификации.
32 бита
8 8 8 8
Неиспользуемое поле
Команда Версия (заполняется нулями )

0xFFFF Тип аутентификации


Аутентификация

Пароль (байты 0-3)

Пароль (байты 4-7)

Пароль (байты 8-11)

Пароль (байты 12-15)

Идентификаторсемейства
Тег маршрута
адресов
Запись маршрута

IP Адрес

Маска подсети

Следующая пересылка

Метрика

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

Рисунок 5.6 – Формат сообщения с аутентификацией протокола RIP v2

84
5.6.1 Настройка аутентификации для протокола RIP

Аутентификация настраивается на каждом выходном интерфейсе марш-


рутизатора, за которым находятся соседние маршрутизаторы. Для настройки
аутентификации используются следующие команды. Команда ip rip authentic-
ation key-chain описывает ключевую цепочку, которая будет использована для
аутентификации, ключевая цепочка настраивается отдельно, в ней описыва-
ются все параметры использования пароля. Команда ip rip authentication mode
указывает метод аутентификации. Необходимо отметить что в независимости
от метода аутентификации пароли, использованные в ключевых цепочках
хранятся на маршрутизаторе в открытом виде, а хеширование MD5 использу-
ется только при передаче пакетов аутентификации по каналам связи.
Синтаксис команд ip rip authentication key-chain и ip rip authentication
mode приводится в примерах 5.1 и 5.2.

Пример 5.1 – Синтаксис команды ip rip authentication key-chain


(config-if)# ip rip authentication key-chain name-of-chain
(config-if)# no ip rip authentication key-chain [name-of-chain]

Пример 5.2 – Синтаксис команды ip rip authentication mode


(config-if)# ip rip authentication mode {text | md5}
(config-if)# no ip rip authentication mode

Описание параметров команд ip rip authentication key-chain и ip rip au-


thentication mode приводиться в таблицах 5.2 и 5.3.

Таблица 5.2 – Параметры команды ip rip authentication key-chain

Параметр Описание
name-of-chain Имя ключевой цепочки используемой
при аутентификации.

Таблица 5.3 – Параметры команды ip rip authentication mode

Параметр Описание
text Аутентификация с помощью открыто-
го пароля.
md5 Аутентификация с помощью алгорит-
ма MD5.

85
В ключевой цепочки описываются текстовые строки, используемые в
качестве пароля и время в течение, которого эти пароли могут использовать-
ся. Пример описания ключевой цепочки приводится в примере 5.3

Пример 5.3 – Пример настройки ключевой цепочки


key chain trees
key 1
key-string chestnut
accept-lifetime 13:30:00 Jan 25 2006 duration 7200
send-lifetime 14:00:00 Jan 25 2006 duration 3600
key 2
key-string birch
accept-lifetime 14:30:00 Jan 25 2006 duration 7200
send-lifetime 15:00:00 Jan 25 2006 duration 3600

Как видно из примера ключевая цепочка может содержать несколько


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

172 .10.1.0/30

S0 S1
R1 R2

r1# r2#
interface serial 0 interface serial 1
ip address 172.16.1.1 255 .255.255.252 ip address 172.16.1.2 255.255.255.252
ip rip authentication key -chain trees ip rip authentication key-chain trees
ip rip authentication mode md 5 ip rip authentication mode md5
! !
router rip router rip
network 172.16.0.0 network 172.16.0.0
version 2 version 2
! !
key chain trees key chain trees
key 1 key 1
key-string chestnut key-string chestnut
accept-lifetime 13:30:00 Jan 25 2006 duration 7200 accept-lifetime 13:30:00 Jan 25 2006 duration 7200
send-lifetime 14:00:00 Jan 25 2006 duration 3600 send-lifetime 14:00:00 Jan 25 2006 duration 3600
key 2 key 2
key-string birch key-string birch
accept-lifetime 14:30:00 Jan 25 1996 duration 7200 accept-lifetime 14:30:00 Jan 25 1996 duration 7200
send-lifetime 15:00:00 Jan 25 1996 duration 3600 send-lifetime 15:00:00 Jan 25 1996 duration 3600

Рисунок 5.7 – Настройка аутентификации

5.7 Суммирование маршрутов в протоколе RIP

Обе версии протокола RIP поддерживают автоматическое суммирова-


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

86
Как раннее рассказывалось, автоматическое суммирование маршрутов
использовать не следует, При необходимости произвести суммирование
маршрутной информации необходимо пользоваться заданными вручную сум-
марными маршрутами.
Для задания суммарного маршрута в протоколе RIP используется ко-
манда ip summary–address rip, данная команда задается на интерфейсе, через
который будет распространяться суммарный маршрут. Синтаксис команды ip
summary–address rip приводится в примере 5.4

Пример 5.4 – Синтаксис команды ip summary–address rip


(config-if)# ip summary-address rip ip-address ip-network-mask
(config-if)# no ip summary-address rip ip-address ip-network-mask

Описание параметров команды ip summary–address rip приводиться в та-


блице 5.4.

Таблица 5.4 – Параметры команды ip summary–address rip

Параметр Описание
ip-address IP адрес суммарного маршрута.
ip-network-mask Маска подсети суммарного маршрута.

Пример настройки суммарных маршрутов в протоколе RIP приводится


на рисунке 5.8

172 .16.14.0/27 17 172 .16.12.0/24


2.
R2 16
.1
4.
22
4/
30
S0
172 .16.14.228 /30 Центральный офис
172 .16.14.32/27
R3 172.16.0.0/16
R1
30
2/
23
14.
6.
2.1
172 .16.14.64/27 17 172 .16.13.0/24
R4

r1#
.. .. ..
router rip
network 172.16.0.0
no auto-summary
interface Serial 0
ip summary-address rip 172.16.12.0 255.255.252.0

Рисунок 5.8 – Настройка суммарных маршрутов в протоколе RIP

87
5.7.1 Распространение маршрута по умолчанию

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


по умолчанию с главного маршрутизатора сети. Для включения механизма
рассылки маршрута по умолчанию на главном маршрутизаторе в сети необхо-
димо указать команду default-information originate. Синтаксис команды de-
fault-information originate приводится в примере 5.5

Пример 5.5 – Синтаксис команды default-information originate


(config-router)# default-information originate [route-map map-name]
(config-router)# no default-information originate

Описание параметров команды default-information originate приводиться


в таблице 5.5.

Таблица 5.5 – Параметры команды default-information originate

Параметр Описание
route-map map-name Указание процессу маршрутизации
распространять маршрут по умолча-
нию в том случае если выполняется
условие route-map.

Пример настройки маршрута по умолчанию в протоколе RIP приводит-


ся на рисунке 5.9

172 .16.14.0/27 17 172 .16.12.0/24


2.
R2 16
.1
4.
22
4/
30
S0
172 .16.14.32/27
172 .16.14.228 /30 Центральный офис
R3 172.16.0.0/16
0
R1
/3
32
.2
.14
16
2.
172 .16.14.64/27 17
172 .16.13.0/24
R4
router rip
network 172.16.0.0
default -information originate
no auto -summary

Рисунок 5.9 – Настройка маршрута по умолчанию в протоколе RIP

88
5.8 Расширенная настройка протокола RIP

5.8.1 Таймеры протокола RIP

Протокол RIP использует в своей работе несколько таймеров, главными


из которых являются: таймер рассылки обновлений маршрутной информации
и таймер удержания информации. Стандартно обновления протокола RIP рас-
сылаются каждые 30 секунд, но это время может быть увеличено для эконо-
мии полосы пропускания канала или уменьшено для увеличения скорости
сходимости сети.
Таймер удержания информации позволяет предотвратить зацикливание
пакетов, однако увеличивает время сходимости сети. Стандартно время удер-
жания в протоколе RIP составляет 180 секунд. В течении этого времени не
разрешается обновление внутренних маршрутов, при этом действительные
альтернативные маршруты также не будут заноситься в таблицу маршрутиза-
ции. Для ускорения сходимости сети время таймера удержания может быть
уменьшено, однако такое уменьшение требует осторожности. Идеальным ре-
шением является установка этого периода чуть большим максимального вре-
мени обновления маршрутов данной сети.

R2
30
с
30

R3 R1
с
30

30
с

R4

Рисунок 5.10 – Определение периода таймера удержания

На рисунке 5.10 показана образовавшаяся из четырех маршрутизаторов


петля. Если время обновления для каждого маршрутизатора составляет 30 се-
кунд, то общее время обхода петли равно 120 секундам. Соответственно, для
таймера удержания информации следует сконфигурировать период, немного
больший 120 секунд.
Для изменения основных таймеров протокола RIP используется ко-
манда timers basic. Синтаксис приводится в примере 5.6.

89
Пример 5.6 – Синтаксис команды timers basic
(config-router)# timers basic update invalid holddown flush
(config-router)# no timers basic

Описание параметров команды timers basic приводиться в таблице 5.6.

Таблица 5.6 – Параметры команды timers basic

Параметр Описание
update Промежуток времени, через который
осуществляется рассылка обновлений
маршрутной информации. Данный ин-
тервал является базовым, относитель-
но него устанавливаются остальные
таймеры. По умолчанию длительность
интервала 30 секунд.
invalid Время в секундах, после которого
маршрут помечается как недоступный.
Это время не должно быть меньше
трех интервалов обновления. Маршрут
становится недопустимым, если он не
присутствует в трех обновлениях
маршрутной информации, маршрут
помечается как holddown и в обновле-
ниях маршрутной информации он от-
мечается как недоступный. Но он все
еще участвует в отправке трафика. По
умолчанию 180 секунд.
holddown Время в секундах, в течение которого
маршрут помечается как «возможно не
доступный». Это время должно быть не
менее трех интервалов обновления
маршрутной информации. Маршрут по-
мечается «возможно недоступным»
если маршрутизатор получает обновле-
ние в котором указывается на недоступ-
ность этого маршрута. Такой маршрут
помечается как недоступный, но этот
маршрут все еще используется для от-
правки трафика.

90
Продолжение таблицы 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.

91
Пример 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.

S1 10.1.1.0/24

S0
R1 R2

r1# router rip r2# router rip


version 2 version 1
network 10.0.0.0 network 10.0.0.0
!
interface serial 1
ip rip send version 1
ip rip receive version 1

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

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

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


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

56k

64k

1,544
R1 M R2

15
5M

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

92
Поскольку метрикой протокола 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.

93
Пример 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 байтный заголовок.
UpdateRequest (9) UpdateResponse (10)

32 бита 32 бита

8 8 8 8 8 8 8 8
Неиспользуемое поле
Версия Версия Flush Sequence Number
(заполняется нулями )
Идентификатор семейства Ноль (RIPv 1)
адресов Тег маршрута (RIPv 2)
Запись маршрута

Записи RIP

UpdateAcknowledge (11)
Записи RIP
32 бита
Записи RIP
8 8 8 8

Версия Flush SequenceNumber Записи RIP

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

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

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


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

94
Таблица 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

95
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

96
Большинство ошибок в настройке протокола 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

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


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

97
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.
Протоколы маршрутизации на основе дистанционно-векторного алго-
ритма Беллмана-Форда, имеют две фундаментальные проблемы:
– Маршрутные петли;
– Счет до бесконечности.
Обе эти проблемы обусловлены тем, что маршрутизаторы ничего не
знают о действительной топологии сети передачи данных. Все что они знают,
это какие сети получатели доступны через каждого из соседей. Когда в сети
происходят изменения, маршрутизаторы пытаются переключать маршруты на
основании новых метрик, которые им становятся известны.

98
До достижения сходимости сети, метрики могут неточно отражать дей-
ствительную стоимость маршрутов, что может привести к маршрутным
петлям.
Основным методом борьбы с возникновением маршрутных петель яв-
ляется введение метрики равной бесконечности, при достижении которой
маршрут считается недоступным. Обычно маршрутизаторам необходимо вы-
полнить некоторое число итераций, перед тем как установить метрику в бес-
конечность, следовательно, время сходимости сети с использованием дистан-
ционно-векторных алгоритмов значительно увеличивается. Чтобы ускорить
схождение сети, приходиться применять дополнительные методы: правило
расщепления горизонта, метод обратного обновления, мгновенные обновле-
ния и таймеры удержания информации.
Вспомним, какую информацию маршрутизаторы получают друг от дру-
га и как они ее используют. Маршрутизаторы в случае использования алго-
ритма Беллмана-Форда, обмениваются маршрутными обновлениями, содер-
жащими известные им сети получатели. Каждая сеть получатель, сопрово-
ждается метрикой, отражающей, насколько далеко маршрутизатор, отправ-
ляющий это маршрутное обновление, по его мнению, находиться от данной
сети.
Маршрутизатор, получающий маршрутное обновление, использует мет-
рику из этого обновления для расчета своей собственной метрики. В
большинстве случаев новая метрика включает в себя стоимость интерфейса,
через который было получено маршрутное обновление. Если полученная мет-
рика является наименьшей для данной сети получателя, маршрутизатор со-
здает маршрут к этой сети. Маршрут указывает на маршрутизатор, который
отправил маршрутное обновление, и содержит только что рассчитанную мет-
рику. Эта метрика затем используется маршрутизатором в своих собственных
маршрутных обновлениях об этой сети получателе.
В такой ситуации маршрутизатор, получающий маршрутное обновле-
ние, отбрасывает фрагмент очень важной информации – метрику маршрута
которую он получил от своего соседа. Маршрутизатор использует ее для рас-
чета своей метрики, а затем эта метрика забывается.
Возникает вопрос: что такого ценного в заявленном расстоянии? На ри-
сунке 6.1 изображена топология сети, с маршрутизатором R1 в центре. У
маршрутизатора R1 имеется маршрут к некоторой сети получателю (СП) че-
рез маршрутизатор R2.

99
СП

0
10

5 R2

5
10

R1 10
0
40
100

105
0
14 30

R5 R3

135
R4

Рисунок 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
На рисунках 6.2 и 6.3 показаны представления маршрутизатора R1 о то-
пологии после обнаружения им отказа маршрутизатора R2. Разница между
двумя рисунками заключается в том, что на рисунке 6.2 маршрутизатор R1
отбросил объявленные его соседом метрики для сети получателя СП, тогда
как на рисунке 6.3 он их запомнил.

СП

 R2

180
200
R1
40
100

30

R5 R3

R4

Рисунок 6.2 – Поиск альтернативного маршрута


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

На рисунке 6.2 перед маршрутизатором R1 стоит дилемма: два маршру-


тизатора которые недавно объявляли СП, это маршрутизаторы R3 и R5. Те
менее, несмотря на меньшую результирующую метрику маршрута к СП через
маршрутизатор R5, маршрутизатор не может положиться на эту метрику, по-
скольку она может быть устаревшей. Поэтому маршрутизатор R1 должен ис-
пользовать нормальные процедуры достижения стабильности, такие, как
таймеры удержания информации, мгновенные обновления, а также другие
описанные ранее методы, чтобы убедиться, что он не имеет дело с устарев-
шей информацией о метрике.
На рисунке 6.3 маршрутизатор R1 запомнил метрики, с которыми был
объявлен СП всеми его соседями. Поэтому при обнаружении отказа маршру-
тизатора R2 маршрутизатор R1 способен сразу определить, что он не может
положиться на лучшую метрику маршрутизатора R5, поскольку его объявлен-
ная метрика (140) больше, чем собственная метрика маршрутизатора R1 (105)
через отказавший маршрутизатор R2. Это значит, что маршрутизатор R5 из-
начально находился дальше от СП, чем маршрутизатор R1.

101
СП

105  R2

180
200
R1 10
0
40
100
0
14 30

R5 R3

R4

Рисунок 6.3 – Поиск альтернативного маршрута алгоритмом DUAL

Наоборот, объявленная метрика маршрутизатором R3 равна 100, что


меньше, чем 105, а значит, маршрутизатор R3 был изначально ближе к СП.
Тем не менее, несмотря на более близкое исходное расположение маршрути-
затора R3 к СП, «плохая» метрика маршрута через него 200 против 180, мет-
рики через маршрутизатор R5 не позволяет маршрутизатору R1 выбрать этот
маршрут.
В этой конкретной ситуации маршрутизатор R1 до сих пор не знает точ-
но, может ли он использовать маршрутизатор R5 в качестве нового следую-
щего маршрутизатора для СП, поскольку он не знает еще, почему объявлен-
ная маршрутизатором R5 метрика больше, чем собственная метрика маршру-
тизатора R1. Возможно, причина в том, что маршрут маршрутизатора R5 ле-
жит через маршрут самого R1, и тогда восстановление маршрута через марш-
рутизатор R5 приведет к созданию маршрутной петли. Или, может быть,
маршрут маршрутизатора R5 просто более длинный, но он не лежит через
маршрутизатор R1, в таком случае восстановление маршрута через R5 допу-
стимо.
До сих пор могло казаться, что знание маршрутизатором R1 метрик
своих соседей для СП не представляет никаких преимуществ.
Представим, что стоимость сегмента, соединяющего маршрутизаторы
R1 и R3, равна 10 (Рисунок 6.4).
Изначально маршрутизатор R1 все равно бы использовал маршрут че-
рез маршрутизатор R2. Но после отказа маршрутизатора R2 маршрутизатор
R1 мог бы сразу выбрать маршрутизатор R3 в качестве нового следующего
маршрутизатора, поскольку маршрутизатор R3 дал бы новую, лучшую метри-
ку - 110 против 180 для маршрутизатора R5.

102
СП

105  R2

180
110
R1 10
0
40
10
0
14 30

R5 R3

R4

Рисунок 6.4 – Немедленное переключение на запасной маршрут


алгоритмом DUAL

Маршрутизатор R3 с самого начала был бы ближе к СП, чем маршрути-


затор R1 - метрика R3 равна 100 против метрики R1, равной 105. Это, означа-
ет, что нет возможности создать маршрутную петлю, если маршрутизатор R1
установит маршрут через маршрутизатор R3.
Немедленное переключение на новый следующий маршрутизатор воз-
можно благодаря тому, что маршрутизатор R1 отслеживал объявляемые его
соседями метрики для СП. Эти метрики позволяют маршрутизатору R1 в не-
которых случаях немедленно сделать вывод, что имеется маршрут без петель
через другого соседа.
Отслеживание метрик соседей маршрутизатора - это то, что составляет
ядро подхода DUAL. По сравнению с подходом DUAL дистанционно-вектор-
ный алгоритм Беллмана-Форда кажется несколько близоруким. Подход алго-
ритма DUAL заключающийся в более глубоком рассмотрении окружения,
позволяет получить знания о топологии, которых часто оказывается достаточ-
но для принятия быстрых решений о маршрутизации, что очень важно для до-
стижения более быстрого схождения.

6.2 Преимущества протокола EIGRP

Как и все бесклассовые протоколы маршрутизации, протокол EIGRP


рассылает обновления маршрутной информации с масками подсетей. Это поз-
воляет поддерживать работу с изолированными подсетями и масками подсе-
тей переменной длины.

103
Протокол EIGRP представляет собой комбинированный протокол
маршрутизации, включающий многие свойства дистанционно-векторных про-
токолов и, кроме того, некоторые характеристики протоколов маршрутизации
по состоянию канала. Такой гибридный протокол обеспечивает следующие
возможности:
– Быстрота процесса сходимости. Маршрутизатор, с запущенным про-
токолом EIGRP, сохраняет резервные маршруты, что повышает скорость схо-
димости сети. Если в локальной таблице маршрутизации нет соответствую-
щего резервного маршрута, протокол EIGRP опрашивает соседние маршрути-
заторы. Эти запросы рассылаются до тех пор, пока альтернативный маршрут
не будет найден.
– Снижение служебного трафика. Протокол EIGRP не рассылает перио-
дические обновления. Вместо этого здесь используются частичные обновле-
ния при изменении маршрутов или метрик маршрутов к получателям. При из-
менении маршрутизирующей информации алгоритм DUAL рассылает обнов-
ление только о конкретном канале передачи данных, не затрагивая при этом
всю таблицу маршрутизации.
– Поддержка на различных сетевых уровнях. Протокол EIGRP поддер-
живает сети IP, IPX, и Apple Talk благодаря применению модулей PDM (pro-
tocol dependent modules).
– Совместимость между всеми протоколами и топологиями. EIGRP не
требует специальной конфигурации для работы с любыми протоколами вто-
рого уровня. Другие протоколы маршрутизации, например OSPF, используют
различные конфигурации для различных протоколов второго уровня, таких
как Ethernet или Frame Relay. EIGRP также поддерживает настройки позволя-
ющие снижать служебный трафик по низкоскоростным каналам связи.

6.3 Автономная система протокола EIGRP

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


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

104
тизаторы будут способны определить, какие из них недоступны, и тем самым
обнаружить неисправность в сети. Это позволяет им быстро отреагировать на
неисправность и откорректировать маршруты в таблице маршрутизации.

6.4 База данных протокола EIGRP

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


мы должны создать и поддерживать базу данных, содержащую две таблицы:
– Таблица соседства. Все маршрутизаторы EIGRP ведут таблицу сосед-
ства, в которой хранится список соседних маршрутизаторов. Эта таблица, как
и в протоколах по состоянию канала служит для обеспечения дуплексного об-
мена данными между соседями, имеющими непосредственное соединение.
– Таблица топологии. Маршрутизатор EIGRP ведет таблицу топологии
для всех сетей, на которые настроен протокол. В таблице хранятся все извест-
ные маршруты ко всем известным сетям, а также вся необходимая информа-
ция о маршруте. Таблица изменяется каждый раз при любых изменениях в то-
пологии сети. Каждый маршрутизатор EIGRP передает свою таблицу тополо-
гии всем своим соседям из таблицы соседства. Сосед, получивший таблицу
топологии соседнего маршрутизатора записывает ее в свою базу данных то-
пологии сети. Маршрутизатор EIGRP изучает базу данных топологии с целью
нахождения лучшего маршрута до каждой сети адресата. По нахождению
лучшего маршрута до сети получателя этот маршрут передается в таблицу
маршрутизации.

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

Чтобы начать обмен маршрутной информацией, маршрутизаторы EI-


GRP, находящиеся в одном и том же сегменте в пределах одного домена
маршрутизации, должны сформировать соседские взаимоотношения. Марш-
рутизаторы становятся соседями после того, как они обменяются привет-
ственными пакетами. Когда маршрутизатор EIGRP находится в процессе пер-
воначальной загрузки, он должен распознать все соседние EIGRP маршрути-
заторы и установить с ними соседские взаимоотношения. Этот процесс назы-
вается процессом обнаружения соседей. Каждый маршрутизатор в результате
обмена приветственными сообщениями создает локальную таблицу соседей,
отслеживая всех соседей и их состояние. Если маршрутизатор не получает
приветственного сообщения от соседнего маршрутизатора в течение несколь-
ких временных интервалов, то он считает его неработоспособным и удаляет
из своей таблицы. В примере 6.1 приводится таблица соседства маршрутиза-
тора EIGRP.

105
Пример 6.1 – Таблица соседства маршрутизатора EIGRP
IP–EIGRP neighbors for process 200
H Address Interface Holdtime Uptime Q Seq SRTT RTO
(sec) (h:m:s) Count Num (ms) (ms)
2 10.93.1.18 Serial2 13 00:06:38 0 8 7 282
1 10.93.1.2 Serial1 10 00:08:53 0 7 9 282
0 10.93.0.1 Serial0 12 00:18:24 0 11 164 984

Ниже описаны поля, содержащиеся в таблице соседства:


– Номер соседнего маршрутизатора (H). Порядковый номер соседнего
маршрутизатора.
– Адрес соседнего маршрутизатора (Address). Адрес сетевого уровня
соседнего маршрутизатора.
– Время удержания (Holdtime). Интервал времени, по истечении кото-
рого, в случае отсутствия сообщений от соседнего маршрутизатора, сосед
рассматривается как неработоспособный. По умолчанию интервал равен 15
секундам. Первоначально в качестве ожидаемых пакетов рассматривались
только пакеты приветствия, однако, в текущих версиях IOS любой пакет про-
токола EIGRP сбрасывает таймер на нулевое значение.
– Время существования соседских отношений (Uptime). Временной ин-
тервал, прошедший с момента установки соседских отношений с данным
маршрутизатором.
– Счетчик очереди (Q Count). Число пакетов, которые находятся в оче-
реди и ожидают передачи. Если это значение постоянно больше нуля, то,
маршрутизатор испытывает переполнение. Значение 0 означает, что пакетов
EIGRP в очереди нет.
– Последовательный номер (Seq Num). Номер последнего пакета, полу-
ченного от данного соседнего маршрутизатора. Протокол EIGRP использует
это поле для подтверждения приема пакета, переданного соседним маршрути-
затором и для идентификации пакетов, которые переданы с нарушением по-
рядка.
– Таймер цикла обмена сообщениями (SRTT). Среднее время, которое
требуется для того, чтобы отправить пакет соседнему маршрутизатору и по-
лучить от него ответный пакет. Этот таймер определяет интервал повторной
передачи пакета.
– Таймер повторной передачи (RTO). Время, которое маршрутизатор
ожидает прихода ответного сообщения от соседа после посылки ему пакета.
После истечения таймера происходит повторная отправка неподтвержденного
пакета.

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

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


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

Пример 6.2 – Таблица топологии маршрутизатора EIGRP


IP–EIGRP Topology Table for AS(200)/ID(10.95.0.2)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 10.93.2.16/28, 1 successors, FD is 6535936
via 10.93.0.1 (6535936/6023936), Serial0
P 10.93.1.16/28, 1 successors, FD is 5511936
via Connected, Serial2
P 10.93.1.0/28, 1 successors, FD is 5511936
via Connected, Serial1
P 10.93.0.0/28, 1 successors, FD is 5511936
via Connected, Serial0
P 10.93.2.32/28, 1 successors, FD is 6538496
via 10.93.0.1 (6538496/6026496), Serial0
P 10.93.1.32/28, 2 successors, FD is 5514496
via 10.93.1.18 (5514496/28160), Serial2
via 10.93.1.2 (5514496/28160), Serial1

Вывод, приведенный в примере 6.2 представляет собой таблицу тополо-


гии, созданную в результате обмена обновлениями маршрутной информации
по протоколу EIGRP. В примере имеются записи о шести известных маршру-
тизатору подсетях. Ниже описаны поля, содержащиеся в таблице топологии:
– Статус маршрута. Различают два основных состояния. Пассивные
маршруты (passive P), под которыми понимаются устойчивые и готовые к ис-
пользованию маршруты, и активные (active A), в отношении которых алго-
ритм DUAL не закончил процесс расчета маршрута.

107
– Число преемников (successors). Число маршрутов с равной стоимо-
стью до сети получателя, или другими словами число маршрутизаторов кото-
рым могут быть переданы далее пакеты при маршрутизации.
– Источник маршрута (via). Адрес маршрутизатора анонсировавшего
маршрут. Если маршрут анонсирован несколькими маршрутизаторами, то
первые n строк являются маршрутизаторами преемниками (n число преемни-
ков) а остальные маршруты выступают либо вероятными преемниками, либо
просто резервными маршрутами. Строчка connected означает, что сеть являет-
ся непосредственно подключенной к маршрутизаторы.
– Выполнимое/Заявленное расстояние (Feasible/Advertised distance). Вы-
полнимое расстояние это полная метрика маршрута равная заявленному рас-
стоянию от соседнего маршрутизатора до сети адресата плюс метрика марш-
рута до заявившего его соседнего маршрутизатора. Заявленное расстояние
это метрика маршрута от соседа до сети получателя.
– Выходной интерфейс. Интерфейс маршрутизатора, через который до-
ступна сеть получатель.
В описании полей таблицы топологии приводилось четыре важнейших
определения для протокола EIGRP, эти определения необходимо повторить:
– Преемник (successor) – это первичный маршрут, который использу-
ется для достижения получателя. Преемники передаются в таблицу маршру-
тизации.
– Вероятный преемник (feasible successor) – это сосед, который нахо-
дится на пути к получателю. Его нельзя назвать оптимальным, поэтому он не
используется для пересылки данных, это резервный маршрут к получателю.
Эти маршруты определяются одновременно с преемниками и сохраняются в
таблице топологии. Таблица топологии может хранить множество вероятных
преемников.
– Заявленное расстояние (Advertised distance). Метрика маршрута,
полученная от соседа заявившего его до сети адресата.
– Выполнимое расстояние (Feasible distance). Заявленное расстояние
от соседа до сети адресата плюс метрика маршрута до соседа.
Заявленное и выполнимое расстояние до сети 10.0.2.0/24 приводится на
рисунке 6.5.

AD

1 2 10.1.2.0/24

R1 R2 R3

FD

Сеть FD AD Topology
10.1.2.0/24 3
ViaR 2 3 2 S

Рисунок 6.5 – Заявленное и выполнимое расстояние

108
6.5 Метрика протокола EIGRP

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


метрику, состоящую из суммы нескольких метрик умноженных на их весовые
коэффициенты. В качестве промежуточных метрик выступают:
– Ширина полосы пропускания (BW). Наименьшая пропускная способ-
ность между отправителем и получателем.
– Время задержки (D). Суммарная задержка по всему маршруту.
– Надежность (R). Самая низкая надежность канала между отправи-
телем и получателем.
– Нагрузка (L). Максимальная нагрузка, имеющаяся в канале между от-
правителем и получателем; измеряется в битах в секунду.
Метрика протокола EIGRP рассчитывается по формуле (6.1):

Metric = [K1 * BW + ((K2 * BW) / (256 – L)) + K3 * D] * [K5 / (R + K4)] (6.1)

где K1 – K5 – весовые коэффициенты.

По умолчанию константы принимают следующие значения:

К1 = КЗ = 1
К2 = К4 = К5 = 0

Следовательно, по умолчанию формула (6.1) для расчета метрики EI-


GRP имеет вид (6.2):

Metric = BW + Delay (6.2)

Весовые коэффициенты передаются в Hello пакетах. Несоответствие ве-


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

BW = (107 / bw) * 256 (6.3)

где bw – полоса пропускания канала связи заданная на интерфейсе.

D = (d / 10) * 256 (6.4)

где d – задержка на канале связи рассчитанная маршрутизатором.

109
6.6 Функционирование протокола EIGRP

Протокол EIGRP использует в своей работе 5 типов служебных пакетов,


описание которых приводится в таблице 6.1.

Таблица 6.1 – Типы служебных пакетов протокола EIGRP

Тип Назначение пакета


Пакеты обновления рассылаются для обмена данными о маршру-
тах до сетей получателей. При изменении топологии сети марш-
Update (1)
рутизатор рассылает пакеты обновления всем маршрутизаторам
из его таблицы соседства.
Пакеты запросы рассылаются всем соседям с целью нахождения
Query (3) маршрута до сети получателя, когда преемник маршрута стано-
виться недоступен.
Reply (4) Пакет отсылается в ответ на пакет запроса.
Пакеты приветствия используются для поиска соседей и дальней-
шего подтверждения работоспособности соседних маршрутизато-
Hello (5)
ров. Они рассылаются по групповому адресу и не требуют под-
тверждения.
Пакет подтверждения используется для подтверждения получе-
ния пакетов обновлений, запросов и ответов. Пакет ACK пред-
АСК (5)
ставляет собой пустой Hello пакет, в котором указан номер паке-
та, получение которого подтверждается.

После запуска протокола EIGRP на маршрутизаторе, он начинает рас-


сылку Hello пакетов со всех активных интерфейсов по групповому адресу
224.0.0.10. Когда маршрутизатор получает на свой интерфейс Hello пакет от
другого маршрутизатора, содержащий такой же номер автономной системы,
между маршрутизаторами запускается процесс установки соседских отноше-
ний. Соседские отношения не устанавливаются, если не совпадают номера ав-
тономных систем или в полученных Hello пакетах содержаться отличные, от
настроенных на маршрутизаторе, весовые коэффициенты.
Начиная с версии IOS 12.2(15)S в процесс установки соседских отноше-
ний между маршрутизаторами EIGRP были внесены изменения. Процесс
установки маршрутизаторами под управлением IOS семейства 12.4 соседских
отношений проиллюстрирован на рисунке 6.6.

110
10.1.1.0/30

R1 R2

Hello Hello

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


D:224 .0.0.10 D:224 .0.0.10
S:10.0.0.1 S:10.0.0.2
AS:200 AS:200
K:1,0,1,0,0 K:1,0,1,0,0

Update
Update

D:10.0.0.2
S:10.0.0.1 D:10.0.0.1
Sq:1 S:10.0.0.2
A:0 Sq:1
A:1
ACK

D:10.0.0.2
S:10.0.0.1
Таблица соседства Таблицасоседства
Sq:0
A:1
модифицированными

Hello Hello
Hello пакетами
Обмен

D:224 .0.0.10 D:224 .0.0.10


S:10.0.0.1 S:10.0.0.1
AS:200 AS:200
K:1,0,1,0,0 K:1,0,1,0,0
N-IP:10.0.0.2 N-IP:10.0.0.1

Update
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

Update
ACK

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
6.6.2 Разрыв соседских отношений

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


мя, и если за это время от соседа не пришло ни одного пакета, то EIGRP
маршрутизатор считает, что сосед находится в нерабочем состоянии.
Если маршрутизатор не может переустановить связь с соседом, он уда-
ляет из таблицы маршрутизации все маршруты через него и пытается найти
альтернативные маршруты для сетей получателей, которые были доступны по
удаленным маршрутам.Максимальное из стандартных времен задержки рав-
няется 180 секундам, может показаться, что такое время ожидания слишком
большое, однако оно задается для очень низкоскоростных каналов связи, по
которым могут быть подключены не критичные к задержкам удаленные узлы.
В высокоскоростных сетях или в сетях с трафиком от систем реального
времени даже минимальная задержка в 15 секунд может быть критична.
Поэтому ставятся дополнительные условия для сброса таймера ожидания, что
позволяет сети сходиться быстрее.
Если сеть не стабильна и в ней происходят изменения маршрутов, вы-
шестоящие маршрутизаторы посылают обновления маршрутной информации
нижестоящим маршрутизаторам, а нижестоящие маршрутизаторы не отвеча-
ют на эти обновления, вышестоящие маршрутизаторы пытаются 16 раз по-
вторно отослать обновление.
Повторные попытки передачи обновлений производятся по истечении
RTO. После 16 попыток передать обновление маршрутизатор разрывает со-
седские отношения. Это позволяет сети сходиться быстрее, чем по истечению
таймера ожидания.

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

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


заторов, например, при перезагрузке или перезапуске процесса маршрутиза-
ции в ОС IOS начиная с версий 12.3(2) была добавлена возможность рассыл-
ки сообщений Goodbye (Рисунок 6.7).
e

R1
by
oo
G

S FS

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

R1

1000

500

R2 R4

1000 1500

Сеть FD AD Topology
10.1.1.0/24 2000
ViaR 2 2000 1000 S
R3 ViaR 4 3000 1500 FS

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

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


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

10.1.1.0/24

R1

1000

500

R2 R4

1000 1500

Сеть FD AD Topology
10.1.1.0/24 3000
Via R 2 2000 1000
R3 Via R 4 3000 1500 S

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

10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 2
1 Via R 2 2 1 S
Via R 3 5 3
R2 R4 Via R 5 5 4

2
2 1

Сеть FD AD Topology Сеть FD AD Topology


10.1.1.0/24 3 10.1.1.0/24 3
Via R 2 3 1 S 1 Via R 4 3 2 S
Via R 4 4 2 FS Via R 3 4 3
Via R 5 4 3 R3 R5

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

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


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

119
10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 2
1  Via R 2
Via R 3
2
5 3
1 S

R2 R4 Via R 5 5 4

2
2 1

Сеть FD AD Topology Сеть FD AD Topology


10.1.1.0/24 3 10.1.1.0/24 3
Via R 2 3 1 S 1 Via R 4 3 2 S
Via R 4 4 2 FS Via R 3 4 3
Via R 5 4 3 R3 R5

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

R1

Сеть FD AD Topology
10.1.1.0/24 -1 **ACTIVE **
Via R 3 5 3 (Q)
Via R 5 5 4 ( Q)
R2 R4

2 Q
2 1
Q

Сеть FD AD Topology Сеть FD AD Topology


10.1.1.0/24 3 10.1.1.0/24 3
Via R 2 3 1 S 1 Via R 4 3 2 S
Via R 4 4 2 FS Via R 3 4 3
Via R 5 4 3 R3 R5

Рисунок 6.12 – Маршрутизатор R4 рассылает запросы соседям

Однако у маршрутизатора R3 в таблице присутствует маршрут до этой


сети через маршрутизатор R2, причем маршрутизатор R2 назначен преемни-
ком. Следовательно, маршрутизатор R3 может ответить маршрутизатору R4
на запрос о маршруте до сети 10.1.1.0/24.
10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 -1 **ACTIVE **
ViaR 3 5 3
ViaR 5 5 4 ( Q)
R2 R4

2
2 1
R

Сеть FD AD Topology
Сеть FD AD Topology 10.1.1.0/24 -1 **ACTIVE **
10.1.1.0/24 3
1 ViaR 3 4 3 (Q)
Via R 2 3 1 S
Via R 5 4 3 R3 Q R5

Рисунок 6.13 – Маршрутизатор R4 получает ответ от R3

121
Маршрутизатор R4 принимает ответ от R3 о наличии маршрута до сети
10.1.1.0/24 и снимает маркер запроса со строчки в таблице топологии, однако,
сеть 10.1.1.0/24 все еще находится в активном состоянии, так как маршрути-
затор R5 еще не ответил на запрос (Рисунок 6.13).
Затем маршрутизатор R5 рассчитывает новое FD маршрута до сети
10.1.1.0/24, устанавливает нового преемника в таблицу топологии, и перево-
дит маршрут из активного состояния в пассивное. Маршрутизатор R4 все еще
ожидает ответа от R5 (Рисунок 6.14).

10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 -1 **ACTIVE **
Via R 3 5 3
Via R 5 5 4 ( Q)
R2 R4

2
2 1

Сеть FD AD Topology
Сеть FD AD Topology 10.1.1.0/24 4
10.1.1.0/24 3
1 Via R 3 4 3 S
Via R 2 3 1 S
Via R 5 4 3 R3 R R5

Рисунок 6.14 – Маршрутизатор R5 получает ответ от R3

Маршрутизатор R5 отвечает на запрос о маршруте до сети 10.1.1.0/24


маршрутизатору R4. На маршрутизаторе R4 алгоритм DUAL получает ответ и
удаляет флаг запроса с маршрута до сети 10.1.1.0/24 через R5.
Маршрутизатор R4 рассчитывает новые FD до сети 10.1.1.0/24 через
маршрутизаторы R3 и R5. Маршруты через R3 и R5 имеют одинаковые FD и
оба маркируются как преемники. Маршрут до сети 10.1.1.0/24 переводится из
активного состояния в пассивное.
Маршрутизатор R4 устанавливает новых преемников в таблицу марш-
рутизации (Рисунок 6.15).

122
10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 5
Via R 3 5 3 S
Via R 5 5 4 S
R2 R4

2
2 1 R

Сеть FD AD Topology
Сеть FD AD Topology 10.1.1.0/24 4
10.1.1.0/24 3
1 Via R 3 4 3 S
Via R 2 3 1 S
Via R 5 4 3 R3 R5

Рисунок 6.15 – Маршрутизатор R4 получает ответ от R5

Полученная сеть (Рисунок 6.16) является сведенной и стабильной.


Маршрутизатор R4 имеет в таблице маршрутизации два маршрута до сети
10.1.1.0/24. По этим двум маршрутам автоматически включается механизм
балансировки нагрузки.

10.1.1.0/24

R1

Сеть FD AD Topology
10.1.1.0/24 5
ViaR 3 5 3 S
ViaR 5 5 4 S
R2 R4

2
2 1

Сеть FD AD Topology
Сеть FD AD Topology 10.1.1.0/24 4
10.1.1.0/24 3
1 ViaR 3 4 3 S
Via R 2 3 1 S
Via R 5 4 3 R3 R5

Рисунок 6.16 – Сегмент сети после завершения работы алгоритма DUAL

123
6.8 Механизм ответов на запросы

Как модифицированный дистанционно-векторный протокол маршрути-


зации, в вопросе получения маршрутизирующей информации протокол
EIGRP полагается на соседей. Если маршрут потерян и нет возможного
преемника, протокол EIGRP начнет рассылать запросы на предмет поиска за-
мены утерянному маршруту.
Если маршрутизатор, получивший запрос, имеет альтернативный марш-
рут, он даст ответ на запрос, и не будет распространять его дальше. Если со-
сед не имеет альтернативного маршрута, он разошлет этот запрос в поисках
альтернативного маршрута на соседние с ним маршрутизаторы. Таким об-
разом, запросы будут распространяться по сети, создавая тем самым расширя-
ющееся дерево запросов. Отвечая на запрос, маршрутизатор останавливает
дальнейшее распространение запроса по сети.
Когда маршрут становится активным и генерируется рассылка запро-
сов, единственным способом выхода этого маршрутизатора из активного со-
стояния является получение ответа на каждый сгенерированный запрос.
Поэтому, получив ответы на все запросы, маршрутизатор переводит маршрут
из активного состояния в пассивное.
Если маршрутизатор не получает ответа на исходящие запросы в тече-
ние трех минут он разрывает соседские отношения с не отвечающим маршру-
тизатором. Маршрутизатор переводит все маршруты на этот соседний марш-
рутизатор в активное состояние. Такая ситуация называется stuck in active –
SIA (Рисунок 6.17).

10.1.1.0/24 10.1.1.0/24
Q Q

 10.1.1.0/24

R1 R2 R3

Рисунок 6.17 – Состояние SIA

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


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

124
– Маршрутизатор использует симплексные каналы. Причиной сбоя мо-
жет стать канал, который пропускает трафик только в одном направлении.
Количество ситуаций SIA можно минимизировать при помощи меха-
низма SIA–Query.
Использование множества автономных систем, работающих под управ-
лением протокола EIGRP, что ограничивает диапазон рассылки запросов, не
является правильным решением данной проблемы. Когда запрос достигает
границы автономной системы, будет получен ответ на первоначальный
запрос, но затем граничный маршрутизатор рассылает новый запрос в другой
автономной системе. Поэтому рассылка запросов не будет остановлена, так
как она будет продолжаться в другой автономной системе, где маршрут по-
тенциально может перейти в состояние SIA.
SIA–Query и SIA–Reply два новых дополнения в заголовок пакета
EIGRP. Эти пакеты генерируются автоматически в ОС Cisco IOS, начиная с
версии 12.1(5), и не требуют конфигурирования. Они дают возможность
EIGRP маршрутизатору контролировать процесс поиска преемника и гаранти-
ровать, что соседи являются все еще достижимыми. Работа механизма SIA–
Query приводится на рисунке 6.18.

10.1.1.0/24 10.1.1.0/24
Q Q

 10.1.1.0/24

R1 SIA-Q R2 R3
SIA-R

Рисунок 6.18 – Работа механизма SIA–Query

Маршрутизатор R1 обнаруживает недоступность сети 10.1.1.0/24 и


посылает запрос о ней маршрутизатору R2. Маршрутизатор R2 не подключен
к этой сети и обращается с запросом к маршрутизатору R3. Если проблема в
канале связи находиться между маршрутизаторами R2 и R3, пакет ответа от
маршрутизатора R3 к R2 может быть потерян. Маршрутизатор R1 не видит
протекание процесса и предполагает, что проблема находится в канале связи
до маршрутизатора R2. После трех минутной задержки R1 прекращает сосед-
ские отношения с R2 и сбрасывает все известные маршруты, проходящие че-
рез маршрутизатор R2.
При использовании SIA–Query маршрутизатор R1 при отсылке запроса
к R2 в середине трехминутного интервала посылает SIA–Query к маршрутиза-
тору R2. Маршрутизатор R2 получает SIA–Query и отвечает на него SIA–
Reply, R1 получив пакет, подтверждает достижимость маршрутизатора R2 и
не разрывает и ним соседские отношения. Через такое же время R2 посылает
SIA–Query маршрутизатору R3 и не получив на него ответ прекращает с ним
соседские отношения. После этого маршрутизатор R2 оповещает маршрути-

125
затор R1 о недостижимости сети 10.1.1.0/24. Маршрутизаторы R1 и R2 удаля-
ют активный маршрут до сети 10.1.1.0/24 из своих таблиц топологии. Отно-
шения соседства между маршрутизаторами R1 и R2 не изменяются.

126
7 Конфигурирование и тестирование протокола EIGRP

Несмотря на сложность алгоритма DUAL, конфигурирование протокола


EIGRP является относительно простым.

7.1 Запуск протокола EIGRP

Для запуска протокола EIGRP используется команда router eigrp


autonomus–system–number. Параметр autonomus–system–number представляет
собой номер автономной системы, который используется для идентификации
маршрутизаторов принадлежащих домену маршрутизации. Это значение
должно совпадать у всех маршрутизаторов в пределах домена маршрутиза-
ции.
Для описания сетей участвующих в процессе маршрутизации использу-
ется команда network.
Синтаксис команды network для протокола EIGRP приводится в приме-
ре 7.1.

Пример 7.1 – Синтаксис команды network


(config-router)# network network-number [wildcard-mask]
(config-router)# no network network-number [wildcard-mask]

Описание параметров команды network приводиться в таблице 7.1.

Таблица 7.1 – Параметры команды network

Параметр Описание
network-number Номер сети участвующей в процессе
маршрутизации EIGRP.
wildcard-mask Обратная маска подсети для сети
участвующей в процессе маршрутиза-
ции EIGRP.

По значению network-number маршрутизатор определяет, какие сети бу-


дут участвовать в процессе маршрутизации EIGRP и через какие интерфейсы
производить рассылку служебных пакетов протокола EIGRP. По умолчанию
рассылка служебных пакетов производиться со всех интерфейсов попадаю-
щих в network-number, поэтому не следует забывать о команде passive-inter-
face для контроля интерфейсов, с которых производиться рассылка служеб-
ной информации.

127
Если не использовать параметр wildcard-mask, то процесс маршрутиза-
ции EIGRP предполагает, что все непосредственно подключенные подсети яв-
ляющиеся частью описанной полной классовой сети, будут участвовать в
процессе маршрутизации EIGRP.
При использовании параметра wildcard-mask процесс маршрутизации
EIGRP проводит отбор подсетей участвующих в процессе маршрутизации как
по совпадению номера сети, так по попаданию маски подсети в диапазон
wildcard-mask. Стоит подчеркнуть, что при использовании на маршрутизаторе
нескольких непрерывных подсетей, в процессе маршрутизации не стоит опи-
сывать каждую сеть в отдельности, а можно описать сеть с суммарной wild-
card-mask. Для работы процесса маршрутизации не имеет значения, использу-
ются суммарные или частные wildcard-mask, в независимости от этого, марш-
руты будут распространяться о частных подсетях. Использование суммарных
wildcard-mask уменьшает количество строк конфигурации маршрутизатора,
тем самым, упрощая процесс ее восприятия администратором сети.
Как говорилось ранее, главной составляющей в метрике протокола EI-
GRP является полоса пропускания канала связи. Поэтому, особенно на после-
довательных интерфейсах, необходимо задать пропускную способность кана-
ла. Если значение пропускной способности для таких интерфейсов не менять,
протокол EIGRP будет считать, что пропускная способность канала будет
равна T1. Если канал работает медленнее, маршрутизатор будет вести непра-
вильный расчет метрик маршрутов. Для задания справочной скорости на ка-
нале связи используется команда bandwidth.
Синтаксис команды bandwidth приводится в примере 7.2.

Пример 7.2 – Синтаксис команды bandwidth


(config-if)# bandwidth kbps

Здесь значение kbps определяет задаваемую пропускную способность в


килобитах в секунду. Для топологий типа "точка–точка", таких как РРР или
HDLC, пропускная способность устанавливается равной скорости линии. Для
интерфейсов типа "точка–точка" Frame Relay пропускная способность уста-
навливается равной согласованной скорости передачи информации (Commit-
ted Information Rate – CIR). Для многоточечных каналов это значение устанав-
ливается равным сумме всех значений CIR на данном интерфейсе.
Стоит обратить особенное внимание, что скорость канала, задаваемая
командой bandwidth, является только справочной, и ни как не влияет на ре-
альную скорость передачи данных по каналу связи. Часто сетевые админи-
страторы задают на каналах справочные скорости меньше или больше реаль-
ных с целью того чтобы маршрут через этот канал становился менее или нао-
борот более привлекательным с точки зрения протокола EIGRP. Манипулиро-

128
вание значением bandwidth является самым простым и действенным способом
влияния на процесс выбора маршрутов протоколом EIGRP.
Также рекомендуется в настройках процесса маршрутизации использо-
вать команду eigrp log-neighbor-changes. При использовании данной команды
фиксируются все события связанные с изменением состояния соседних EI-
GRP маршрутизаторов с которыми установлены и поддерживаются соседские
отношения. В последних версиях IOS данная команда включена по умолча-
нию и не отображается в конфигурации маршрутизатора.

AS200
r1#
router eigrp 200
network 10.0.0.0 10.4.0.0/16
network 172.16.0.0

10.1.0.0/16 172 .16.2.0/24


192 .168 .1.0/24 172 .16.1.0/24
R2 S0 S1 R4
R1
172.16.7.0/24
S2

R3

172 .16.4.0/24

Рисунок 7.1 – Пример конфигурации процесса маршрутизации в AS 200

На рисунке 7.1 приводится конфигурация процесса маршрутизации EI-


GRP на маршрутизаторах автономной системы. Маршрутизатор R1, совмест-
но с другими маршрутизаторами является частью автономной системы с но-
мером 200. Для установки соседских отношений все маршрутизаторы должны
принадлежать одной автономной системе.
При включении в процесс маршрутизации EIGRP сетей настроенных на
интерфейсах маршрутизатора R1 можно воспользоваться следующими ко-
мандами (Пример 7.1).

Пример 7.1 – Запуск процесса EIGRP на маршрутизаторе R1


r1(config)# router eigrp 200
r1(config–router)# network 10.1.0.0
r1(config–router)# network 10.4.0.0
r1(config–router)# network 172.16.2.0
r1(config–router)# network 172.16.7.0

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


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

129
зультате получится конфигурация представленная на рисунке 7.1, следова-
тельно, все интерфейсы маршрутизатора R1 являющееся частью сетей
10.0.0.0/8 и 172.16.0.0/16 участвуют в процессе маршрутизации.
Другой возможной конфигурацией маршрутизатора может быть конфи-
гурация представленная в примере 7.2.

Пример 7.2 – Конфигурация EIGRP с использованием wildcard-mask


router eigrp 200
network 10.1.0.0 0.0.255.255
network 10.4.0.0 0.0.255.255
network 172.16.2.0 0.0.0.255
network 172.16.7.0 0.0.0.255

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


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

17
2.
16
R2 .2.
0/2
4

r2# S1 172 .16.1.0/30


router eigrp 200 External Network
S2 S0
network 172.16.0.0
R1
/24
3.0
16.
2.
17
R3 r1#
router eigrp 200
network 172.16.3.0 0.0.0.255
network 172.16.4.0 0.0.0.255

Рисунок 7.2 – Запуск EIGRP на маршрутизаторе с подключением


к внешней сети

На рисунке 7.2 приводится пример сети, в которой необходимо исполь-


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

130
В ОС IOS при описании сетей в процесс маршрутизации EIGRP есть
возможность автоматического преобразования масок подсетей в wildcard-
mask, При описании сети можно использовать маски подсети, а в конфигура-
ционный файл маршрутизатора будут внесены требуемые сети с соответству-
ющими wildcard-mask.

7.2 Настройка аутентификации в протоколе EIGRP

Также как и в протоколе RIP в протоколе EIGRP аутентификация на-


страивается на каждом выходном интерфейсе, за которым находятся соседние
маршрутизаторы. Для настройки аутентификации используются следующие
команды. Команда ip authentication key-chain eigrp указывает на ключевую це-
почку, которая будет использована для аутентификации. Команда ip authentic-
ation mode eigrp md5 указывает, что в качестве метода аутентификации будет
использоваться MD5.
Синтаксис команд ip authentication key-chain eigrp и ip authentication
mode eigrp md5 приводится в примерах 7.3 и 7.4.

Пример 7.3 – Синтаксис команды ip eigrp authentication key-chain


(config-if)# ip authentication key-chain eigrp as-number key-chain
(config-if)# no ip eigrp as-number authentication key-chain [key-chain]

Пример 7.4 – Синтаксис команды ip authentication mode eigrp md5


(config-if)# ip authentication mode eigrp as-number md5
(config-if)# no ip authentication mode eigrp as-number md5

Пример настройки аутентификации между парой соседних маршрутиза-


торов приводится на рисунке 7.3

172 .10.1.0/30

S0 S1
R1 R2

r1# r2#
interface serial 0 interface serial 1
ip address 172.16.1.1 255 .255.255.252 ip address 172.16.1.2 255.255.255.252
ip authentication key -chain eigrp 200 trees ip authentication key -chain eigrp 200 trees
ip authentication mode eigrp 200 md5 ip authentication mode eigrp 200 md5
! !
router eigrp 200 router eigrp 200
network 172.16.1.0 255.255.255.252 network 172.16.1.0 255.255.255.252
! !
key chain trees key chain trees
key 1 key 1
key-string chestnut key-string chestnut

Рисунок 7.3 – Настройка аутентификации в протоколе EIGRP

131
Если маршрутизаторы проходят взаимную аутентификацию, то они
устанавливают между собой соседские отношения и обмениваются маршрут-
ной информацией.
Это можно отследить с помощью команд show ip route и show ip eigrp
neighbor, данная команда выводит таблицу соседства процесса маршрутиза-
ции EIGRP. Подробно о данной команде будет рассказано ниже.
При установке соседских отношений с новым маршрутизатором на кон-
соль будет выведено сообщение представленное в примере 7.5

Пример 7.5 – Сообщение об установке соседских отношений


*Mar 13 18:41:51.743 KRSK: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor
10.93.1.2 (Serial0/0/1) is up: new adjacency

Также процесс обмена Hello пакетами можно посмотреть при помощи


команды debug eigrp packets, которая выводит информацию обо всех служеб-
ных пакетах протокола EIGRP, отправленных и полученных маршрутизато-
ром (Пример 7.6).

Пример 7.6 – Вывод информации о пакетах протокола EIGRP


*Mar 13 18:42:20.079 KRSK: EIGRP: Sending HELLO on Serial0/0/1
*Mar 13 18:42:20.079 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0
*Mar 13 18:42:20.299 KRSK: EIGRP: received packet with MD5 authentication, key
id = 1
*Mar 13 18:42:20.299 KRSK: EIGRP: Received HELLO on Serial0/0/1 nbr 10.93.1.2
*Mar 13 18:42:20.299 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0 peerQ un/rely 0/0

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


debug eigrp packets проинформирует об этом при помощи сообщения вида
(Пример 7.7)

Пример 7.7 – Ошибка аутентификации


*Mar 13 18:45:26.843 KRSK: EIGRP: pkt key id = 1, authentication mismatch
*Mar 13 18:45:26.843 KRSK: EIGRP: Serial0/0/1: ignored packet from 10.93.1.2,
opcode = 5 (invalid authentication)

Если до настройки аутентификации маршрутизаторы уже находились в


соседских отношениях, а при аутентификации произошла ошибка, то на кон-
соль будет выведено сообщение представленное в примере 7.8

132
Пример 7.8 – Разрыв соседских отношений
*Mar 13 18:44:44.951 KRSK: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor
10.93.1.2 (Serial0/0/1) is down: Auth failure

7.3 Суммирование маршрутов в протоколе EIGRP

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


ное суммирование маршрутов. Протокол EIGRP автоматически производит
суммирование маршрутов на классовых границах сетей. Так же как и в проко-
ле RIP v2 данная возможность оставлена для совместимости с предшествен-
ником протокола EIGRP, классовым протоколом IGRP.
В большинстве современных сетей передачи данных функция автомати-
ческого суммирования маршрутов не актуальна, а в некоторых случаях может
вызвать проблемы при распространении маршрутов. Для отключения автома-
тического суммирования маршрутов необходимо воспользоваться командой
no auto–summary в настройке EIGRP маршрутизатора. При необходимости
произвести суммирование маршрутной информации необходимо пользовать-
ся заданными вручную суммарными маршрутами.
Для задания суммарного маршрута в протоколе EIGRP используется ко-
манда ip summary–address eigrp, данная команда задается на интерфейсе, че-
рез который будет распространяться суммарный маршрут. Синтаксис ко-
манды ip summary–address eigrp приводится в примере 7.9

Пример 7.9 – Синтаксис команды ip summary–address eigrp


(config-if)# ip summary-address eigrp as-number ip-address ip-network-mask
[admin-distance]
(config-if)# no ip summary-address eigrp as-number ip-address ip-network-mask

Описание параметров команды ip summary–address eigrp приводиться в


таблице 7.2.

Таблица 7.2 – Параметры команды ip summary–address eigrp

Параметр Описание
as-number Номер автономной системы, для кото-
рой задается суммарный маршрут.
ip-address IP адрес суммарного маршрута.
ip-network-mask Маска подсети суммарного маршрута.
admin-distance Административное расстояние для
суммарного маршрута.

133
По умолчанию параметр admin-distance для суммарных маршрутов про-
токола EIGRP равняется 5. Это сделано, для того чтобы такой суммарный
маршрут выигрывал по административному расстоянию у маршрутов от всех
других динамических протоколов маршрутизации, в том числе и у самого EI-
GRP. Однако в некоторых ситуациях это может привести к неправильной ра-
боте сети, поэтому для суммарных маршрутов желательно устанавливать
административное расстояние равное административному расстоянию прото-
кола EIGRP, т.е. 90.
На рисунке 7.4 маршрутизаторы R1 – R3 имеют непосредственное под-
ключение к сетям 172.16.х.0/24, а включение между собой этих маршрутиза-
торов произведено через сеть 10.0.0.0/8. При таком включении для передачи
трафика между сетями 172.16.х.0/24, в сети 10.0.0.0/8 должны существовать
частные маршруты до каждой из этих сетей. Следовательно, на маршрутиза-
торах R1 – R3 необходимо отключить автоматическое суммирование маршру-
тов.
На маршрутизаторе R4 администратор вручную задает распространение
суммарных маршрутов на все подсети сетей 172.16.0.0/16 и 10.0.0.0/8 с интер-
фейса serial 0 во внешнюю WAN сеть. Таким образом, для сети WAN марш-
рутизатор R4 представляется как единственный вход в сеть 172.16.0.0/16.

172 .16.1.0/24
R1

192 .168 .1.0/30


172 .16.2.0/24 10.0.0.0/8 WAN
R2 S0
R4

172 .16.3.0/24
R3 r4#
router eigrp 200
network 10.0.0.0
network 192.168.1.0 0.0.0.3
r3# !
router eigrp 200 interface Serial 0
network 10.0.0.0 ip address 192.168.1.1 255.255.255.252
network 172.16.0.0 ip summary-address eigrp 200 10.0.0.0 255.0.0.0 90
no auto -summary ip summary-address eigrp 200 172.16.0.0 255.255.0.0 90

Рисунок 7.4 – Суммирование маршрутов в протоколе EIGRP

7.4 Настройка маршрута по умолчанию в протоколе EIGRP

Протокол EIGRP не имеет возможности распространять маршрут по


умолчанию 0.0.0.0 0.0.0.0, так как это реализовано в протоколе RIP.
При использовании EIGRP можно создать маршрут по умолчанию с по-
мощью команды ip default–network (Рисунок 7.5).

134
r1
router eigrp 200
network 10.64.0.0 0.0.0.255
network 192.168.1.0 0.0.0.3
passive-interface Serial 0
!
ip default-network 192.168.1.0
ip route 192.168.1.0 255.255.255.0 192.168.1.1

10.64.0.0/24 192 .168 .1.0/30


10.0.0.0/8 External AS
S0
R2 R1

r1# show ip route

Gateway of last resort is not set


...
C 10.64.0.0/24 is derectly connected , Ethernet 0
S* 192.168.1.0/30 [1/0] via 192.168.1.1

r2# show ip route


...
Gateway of last resort is 10.64.0.1 to network 192.168.1.0
10.0.0.0/8 is variably subnetted , 7 subnets, 2 masks
...
C 10.64.0.0/24 is derectly connected , Ethernet 0
D* 192.168.1.0/30 [90/10486122] via 10.64.0.1, 00:00:15, Ethernet0

Рисунок 7.5 – Маршрут по умолчанию в протоколе EIGRP

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


сеть, описанную в этой команде как шлюз «последней надежды». Сеть долж-
на быть достижима для маршрутизатора, который использует эту команду,
прежде чем он объявит себя как кандидат на маршрут по умолчанию.
Сеть, сконфигурированную в этой команде нужно также объявить дру-
гим EIGRP маршрутизаторам так, чтобы те могли использовать эту сеть как
маршрут по умолчанию и установить шлюз «последней надежды».
Начиная с версии IOS 12.0(4)T еще одним возможным способом рас-
пространения маршрута по умолчанию 0.0.0.0 0.0.0.0 является настройка сум-
марного маршрута 0.0.0.0 0.0.0.0 на выходных интерфейсах головного марш-
рутизатора.

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

Как и другие протоколы динамической маршрутизации, протокол EI-


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

135
фигурации процесса маршрутизации EIGRP. Синтаксис команды variance
приводится в примере 7.10.

Пример 7.10 – Синтаксис команды variance


(config-router)# variance multiplier
(config-router)# no variance

Параметр multiplier (множитель) отражает значение вариации от 1 до 128,


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

20 10

R2

10 10 Z

R5 R3 R1

30 15

R4

Рисунок 7.6 – Распределение нагрузки по маршрутам


с различными метриками

На рисунке 7.6 диапазон метрик, для маршрутов от маршрутизатора R5


до сети Z, составляет от 20 до 45. Этот диапазон значений используется в про-
цедуре определения потенциального маршрута. Маршрут считается приемле-
мым, если следующий маршрутизатор, лежащий на пути, будет ближе к полу-
чателю, чем текущий, и метрика всего маршрута лежит в пределах вариации.
Если этих условия соблюдены, то такой маршрут будет считаться приемле-
мым, и он будет записан в таблицу маршрутизации. Для распределения на-
грузки могут быть использованы только приемлемые маршруты.
На рисунке 7.6, имеются три маршрута к сети Z, метрики для этих
маршрутов:
– 30 – верхний маршрут;
– 20 – средний маршрут;
– 45 – нижний маршрут.

136
По умолчанию маршрутизатор R5 помещает в свою таблицу маршрути-
зации только средний маршрут потому, что он обладает наименьшей метри-
кой.
Для включения режима балансировки нагрузки по маршрутам с различ-
ными метриками воспользуемся командой variance, при этом балансировка
будет осуществляться по маршрутам, чья метрика меньше метрики наилуч-
шего маршрута умноженного на величину variance.
Для включения балансировки между средним и верхним маршрутами
необходимо использовать variance = 2, т.к. 20*2=40, а это больше метрики
верхнего маршрута. Точно также, что бы добавить нижний маршрут необхо-
димо использовать variance = 3.
При включении процесса распределения нагрузки по маршрутам с
разными метриками, маршрутизатор производит распределение пакетов в за-
висимости от величины variance. По маршруту соответствующему variance =
2, будет отправлено в два раз меньше пакетов относительно количества паке-
тов отправленного по наилучшему маршруту.

7.6 Расширенная настройка протокола EIGRP

7.6.1 Таймеры протокола EIGRP

Протокол EIGRP не использует периодическую рассылку маршрутной


информации соседним маршрутизаторам. Однако для поддержания соседских
отношений между маршрутизаторами необходимо периодически передавать
Hello пакеты. При получении от соседа Hello пакета маршрутизатор понима-
ет, что сосед продолжает функционировать.
Исходя из этого, в протоколе EIGRP существует два основных таймера:
– таймер рассылки Hello пакетов;
– таймер ожидания Hello пакетов.
По умолчанию таймер рассылки Hello пакетов равняется 60 секундам
для низкоскоростных каналов связи, со скоростями меньшими, чем T1 и сетей
NBMA. Для всех остальных типов сетей интервал рассылки Hello пакетов ра-
вен 5 секундам.
Время ожидания получения Hello пакетов должно равняться не менее
трем интервалам рассылки Hello пакетов, следовательно, для низкоскорост-
ных каналов связи данный интервал равняется 180 секундам, а для всех
остальных каналов связи 15 секундам.
При необходимости стандартные значения таймеров можно изменить,
используя команды ip hello-interval eigrp и ip hold-time eigrp . Синтаксис ко-
манд приводится в примерах 7.11 и 7.12.

137
Пример 7.11 – Синтаксис команды ip hello-interval eigrp
(config-router)# ip hello-interval eigrp as-number seconds
(config-router)# no ip hello-interval eigrp as-number seconds

Пример 7.12 – Синтаксис команды ip hold-time eigrp


(config-router)# ip hold-time eigrp as-number seconds
(config-router)# no ip hold-time eigrp as-number seconds

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


ректной работы протокола EIGRP необходимо соблюдать соотношение
таймеров рассылки Hello пакетов и ожидания Hello пакетов.
Еще одним таймером протокола EIGRP является таймер наступления
состояния SIA для сети, о которой был отправлен запрос. По умолчанию дан-
ный таймер равняется трем минутам. В больших сетях передачи данных ис-
пользующих низкоскоростные каналы связи может понадобиться изменить
данный таймер, используя команду timers active-time. Синтаксис команды
приводится в примере 7.13.

Пример 7.13 – Синтаксис команды timers active-time


(config-router)# timers active-time [time-limit | disabled]
(config-router)# no timers active-time

Описание параметров команды timers active-time приводиться в таблице


7.3.

Таблица 7.3 – Параметры команды timers active-time

Параметр Описание
time-limit Время в минутах, по истечении кото-
рого наступает состояние SIA.
disabled Отключение таймера, разрешение
маршрутизатору ожидать получение
ответов бесконечно долгое время.

7.6.2 Изменение административного расстояния протокола EIGRP

По умолчанию административное расстояние протокола EIGRP равня-


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

138
лью сделать его менее предпочтительным, чем старый протокол маршрутиза-
ции. Для этого используется команда distance eigrp. Синтаксис команды при-
водится в примере 7.14.

Пример 7.14 – Синтаксис команды distance eigrp


(config-router)# distance eigrp internal-distance external-distance]
(config-router)# no distance eigrp

Описание параметров команды distance eigrp приводиться в таблице 7.4.

Таблица 7.4 – Параметры команды distance eigrp

Параметр Описание
internal-distance Административное расстояние вну-
тренних (собственных) маршрутов EI-
GRP. По умолчанию 90.
external-distance Административное расстояние внеш-
них маршрутов EIGRP. Под внешними
маршрутами понимаются маршруты,
полученные от других протоколов
маршрутизации. По умолчанию 170.

7.6.3 Изменение весовых коэффициентов протокола EIGRP

Формула расчета метрики маршрута в протоколе EIGRP зависит от ве-


совых коэффициентов. По умолчанию коэффициенты равняются: k1=1, k2=0,
k3=1, k4=0, k5=0.
Процесс маршрутизации EIGRP позволяет при помощи команды metric
weights изменить весовые коэффициенты. Синтаксис команды приводится в
примере 7.15.

Пример 7.15 – Синтаксис команды metric weights


(config-router)# metric weights tos k1 k2 k3 k4 k5
(config-router)# no metric weights

Описание параметров команды metric weights приводиться в таблице


7.5.

139
Таблица 7.5 – Параметры команды metric weights

Параметр Описание
tos Параметр типа сервиса, всегда уста-
навливается равным 0.
k1 k2 k3 k4 k5 Устанавливаемые весовые коэффици-
енты.

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


налов связи, можно установить k5=1, тогда формула расчета метрики примет
вид (7.1):

Metric = (BW + Delay)*(1/R) (7.1)

где BW – пропускная способность канала;


Delay – задержка на канале связи;
R – надежность канала связи.

Необходимо подчеркнуть, что модификация весовых коэффициентов


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

7.6.4 Настройка протокола EIGRP для сетей NBMA

Для функционирования протокола EIGRP в сетях NBMA необходимо


на каждом маршрутизаторе вручную указывать соседей при помощи команды
neighbor, синтаксис команды приводится в примере 7.16.

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


(config-router)# neighbor ip-address interface-type interface-number
(config-router)# no neighbor ip-address interface-type interface-number

В данной команде помимо IP адреса соседнего маршрутизатора явно


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

140
7.6.5 Использование EIGRP пропускной способности каналов связи

По умолчанию протокол EIGRP использует до 50% объявленной про-


пускной способности интерфейса. Этот процент можно отрегулировать с по-
мощью команды ip bandwidth–percent eigrp, синтаксис команды приводится в
примере 7.17.

Пример 7.17 – Синтаксис команды ip bandwidth–percent eigrp


(config-if)# ip bandwidth-percent eigrp as-number percent
(config-if)# no ip bandwidth-percent eigrp as-number percent

Параметр percent можно устанавливать в значение, превышающее 100.


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

7.6.6 Идентификация маршрутизаторов в протоколе EIGRP

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


маршрутизатора – router ID (RID). Значение RID устанавливается в момент
запуска процесса маршрутизации EIGRP и не изменяется во время дальней-
шей работы процесса маршрутизации. В качестве RID может быть выбран:
– Старший IP адрес любого физического интерфейса маршрутизатора.
Интерфейс может не использоваться в процессе EIGRP маршрутизации, но он
должен находиться в активном состоянии.
– В качестве идентификатора может использоваться логический интер-
фейс loopback. Данный интерфейс всегда находиться в активном состоянии,
поэтому использование логического интерфейса является наиболее предпо-
чтительным. Если на маршрутизаторе задано несколько логических интер-
фейсов в качестве идентификатора будет выбран старший IP адрес.
– В случаях если на маршрутизаторе запущено несколько процессов
маршрутизации EIGRP имеется возможность задания идентификатора вруч-
ную с помощью команды eigrp router-id. Синтаксис команды eigrp router-id
приводится в примере 7.18.

Пример 7.18 – Синтаксис команды eigrp router-id


(config-router)# eigrp router-id ip-address
(config-router)# no eigrp router-id ip-address

В данном случае в качестве параметра ip-address назначается IP адрес


выбранного loopback интерфейса. Существует два исключения, в качестве

141
RID не могут быть назначены значения 0.0.0.0 и 255.255.255.255.Самым вы-
соким приоритетом при назначении идентификатора обладает ручная на-
стройка, самым низким старший адрес физического интерфейса.
Однажды заданный идентификатор активен все время работы процесса
маршрутизации EIGRP. Если во время работы маршрутизатора интерфейс ад-
рес, которого используется в качестве идентификатора маршрутизатора, пере-
ходит в неактивное состояние, идентификатор маршрутизатора не изменяет-
ся. Однако при использовании адресов физических интерфейсов в качестве
идентификатора маршрутизатора нельзя гарантировать, что после перезагруз-
ки маршрутизатора будет назначен тот же идентификатор.
Хотя применение RID было представлено еще в версии IOS 12.1, оно не
получило функционального наполнения и не имеет такого значения как RID
для протокола OSPF.

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

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


могут быть использованы несколько команд. Наиболее часто используемыми
командами общего назначения являются show ip route и show ip protocols.
Команда show ip route или команда show ip route eigrp отображает та-
блицу маршрутизации построенную маршрутизатором. Вторая команда отоб-
ражает только маршруты из таблицы маршрутизации полученные протоко-
лом EIGRP, такие маршруты помечаются буквой «D» (Пример 7.19).

Пример 7.19 – Таблица маршрутизации протокола EIGRP


r2#show ip route eigrp
172.16.0.0/28 is subnetted, 2 subnets
D 172.16.0.16 [90/2304000] via 172.16.0.1, 00:00:27, Serial0/0/0
10.0.0.0/8 is variably subnetted, 16 subnets, 2 masks
D 10.89.1.64/28 [90/1794560] via 10.93.1.18, 00:00:27, Serial0/1/0
D 10.89.1.16/28 [90/1794560] via 10.93.1.2, 00:00:27, Serial0/0/1
D 10.95.1.4/32 [90/1920000] via 10.93.1.2, 00:00:27, Serial0/0/1
D 10.95.1.5/32 [90/1920000] via 10.93.1.18, 00:00:27, Serial0/1/0
D 10.89.1.0/28 [90/1794560] via 10.93.1.2, 00:00:27, Serial0/0/1
D 10.89.0.0/28 [90/1794560] via 172.16.0.1, 00:00:27, Serial0/0/0
D 10.95.0.1/32 [90/1920000] via 172.16.0.1, 00:00:27, Serial0/0/0
D 10.93.1.32/28 [90/1794560] via 10.93.1.18, 00:00:28, Serial0/1/0
[90/1794560] via 10.93.1.2, 00:00:28, Serial0/0/1

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


всех протоколах IP маршрутизации, в том числе и о протоколе EIGRP, скон-
фигурированных на маршрутизаторе (Пример 7.20).

142
Пример 7.20 – Информация, выводимая командой show ip protocols
r2#show ip protocols
Routing Protocol is "eigrp 200"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
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 200
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
172.16.0.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
10.93.1.18 90 00:01:22
10.93.1.2 90 00:01:22
172.16.0.1 90 00:01:22
Distance: internal 90 external 170

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


большинства параметров протокола EIGRP. Ниже перечислены островные те-
стируемые параметры конфигурации:
– Номер автономной системы, в которой запущен протокол EIGRP;
– Значения весовых коэффициентов используемых в AS;
– Используется или нет автоматическое суммирование маршрутов;
– Анонсирует ли маршрутизатор требуемые сети;
– Интерфейсы, через которые не распространяется маршрутная инфор-
мация;
– С какими маршрутизаторами установлены соседские отношения.
Кроме команд применимых ко всем протоколам маршрутизации суще-
ствует ряд специальных команд отображающих информацию протокола EI-
GRP. К такой информации относятся таблицы соседства и топологии, стати-
стическая информация о переданных и полученных служебных пакетах, ин-
формация о работе интерфейсов маршрутизатора по обработке служебных па-
кетов.
Для вывода таблиц соседства и топологии применяются соответственно
команды show ip eigrp neighbors и show ip eigrp topology, синтаксис команд
приводится в примерах 7.21 и 7.22.

143
Пример 7.21 – Синтаксис команды show ip eigrp neighbors
show ip eigrp neighbors [interface-type | as-number | static | detail]

Пример 7.22 – Синтаксис команды show ip eigrp topology


show ip eigrp topology [autonomous-system-number | [[ip-address] mask]] [act-
ive | all-links | pending | summary | zero-successors]

Описание параметров команд приводиться в таблицах 7.6 и 7.7.

Таблица 7.6 – Параметры команды show ip eigrp neighbors

Параметр Описание
interface-type Вывод информации о соседях располо-
женных за интерфейсом.
as-number Вывод информации о соседях в авто-
номной системе.
static Вывод статических маршрутов.
detail Вывод расширенной информации о со-
седях.

Таблица 7.7 – Параметры команды show ip eigrp topology

Параметр Описание
autonomous-system-number Вывод таблицы топологии автономной
системы.
ip-address Вывод расширенной информации о
сети.
mask Маска подсети.
active Вывод информации только об актив-
ных сетях.
all-links Вывод всей информации из таблицы
топологии.
pending Вывод информации о сетях, по кото-
рым от соседей ожидаются пакеты об-
новлений или пакеты подтверждений.
summary Вывод суммарной информации о топо-
логии сети.
zero-successors Вывод информации о доступных
маршрутах.

144
Информация, выводимая командами show ip eigrp neighbors и show ip ei-
grp topology, а так же ее описание приводилось в примерах 6.1 и 6.2.
Наиболее интересной является информация, выводимая командой show
ip eigrp topology для конкретной сети, которая содержит всю информацию, по
которой производится расчет метрики для этой сети (Пример 7.23).

Пример 7.23 – Информация таблицы топологии для конкретной сети


r2#show ip eigrp topology 10.93.1.32/28
IP-EIGRP (AS 200): Topology entry for 10.93.1.32/28
State is Passive, Query origin flag is 1, 2 Successor(s), FD is 1794560
Routing Descriptor Blocks:
10.93.1.2 (Serial0/0/1), from 10.93.1.2, Send flag is 0x0
Composite metric is (1794560/28160), Route is Internal
Vector metric:
Minimum bandwidth is 2000 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
10.93.1.18 (Serial0/1/0), from 10.93.1.18, Send flag is 0x0
Composite metric is (1794560/28160), Route is Internal
Vector metric:
Minimum bandwidth is 2000 Kbit
Total delay is 20100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1

Статистическую информацию о количестве переданных и полученных


служебных пакетов можно посмотреть, используя команду show ip eigrp
traffic. Синтаксис команды приводится в примере 7.24.

Пример 7.24 – Синтаксис команды show ip eigrp traffic


show ip eigrp traffic [as-number]

Информация, выводимая данной командой, содержит количество от-


правленных и полученных служебных EIGRP пакетов за время работы про-
цесса маршрутизации (Пример 7.25).

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


IP-EIGRP Traffic Statistics for AS 200
Hellos sent/received: 1052/893
Updates sent/received: 43/34
Queries sent/received: 3/1
Replies sent/received: 1/3
Acks sent/received: 25/34

145
Input queue high water mark 1, 0 drops
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 164
PDM Process ID: 135

Другой командой выводящей статистическую информацию является ко-


манда show ip eigrp accounting. Синтаксис команды приводится в примере
7.26.

Пример 7.26 – Синтаксис команды show ip eigrp accounting


show ip eigrp accounting [as-number]

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


ченных от соседей, и статистику по поддержанию соседских отношений
(Пример 7.27).

Пример 7.27 – Информация, выводимая командой show ip eigrp account-


ing
IP-EIGRP accounting for AS(200)/ID(10.95.1.2)
Total Prefix Count: 18 States: A-Adjacency, P-Pending, D-Down
State Address/Source Interface Prefix Restart Restart/
Count Count Reset(s)
A 10.93.1.2 Se0/0/1 12 3 211
A 172.16.0.1 Se0/0/0 3 5 84
A 10.93.1.18 Se0/1/0 12 1 114

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


пакетами EIGRP можно посмотреть при помощи команды show ip eigrp inter-
faces (Пример 7.28).

Пример 7.28 – Информация, выводимая командой show ip eigrp inter-


faces
IP-EIGRP interfaces for process 200
Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes
Se0/0/1 1 0/0 2 0/12 50 0
Se0/1/0 1 0/0 1 0/12 50 0
Se0/0/0 1 0/0 1 0/12 50 0

Синтаксис команды show ip eigrp interfaces приводится в примере 7.29.

146
Пример 7.29 – Синтаксис команды show ip eigrp interfaces
show ip eigrp interfaces [interface-type interface-number] [as-number]

В набор инструментов для отладки работы протокола EIGRP запущен-


ного на маршрутизаторе также входит ряд команд debug.
Для вывода информации о передачи служебных пакетов EIGRP исполь-
зуется команда debug eigrp packets. Данная команда отображает все служеб-
ные пакеты протокола EIGRP, которые были получены или переданы марш-
рутизатором. Информация, выводимая данной командой, представлена в при-
мере 7.30.

Пример 7.30 – Информация, выводимая командой debug eigrp packets


r2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
*Mar 15 13:40:50.151 KRSK: EIGRP: Received HELLO on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:50.151 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0 peerQ un/rely 0/0
*Mar 15 13:40:50.251 KRSK: EIGRP: Sending HELLO on Serial0/0/1
*Mar 15 13:40:50.251 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0
*Mar 15 13:40:51.695 KRSK: EIGRP: Received QUERY on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.699 KRSK: AS 200, Flags 0x0, Seq 84/71 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 15 13:40:51.699 KRSK: EIGRP: Enqueueing ACK on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.699 KRSK: Ack seq 84 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 15 13:40:51.703 KRSK: EIGRP: Sending ACK on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.703 KRSK: AS 200, Flags 0x0, Seq 0/84 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 1/0
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing REPLY on Serial0/0/1 nbr
10.93.1.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 77-77
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing UPDATE on Serial0/0/0 iidbQ
un/rely 0/1 serno 78-78
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing UPDATE on Serial0/1/0 iidbQ
un/rely 0/1 serno 78-78

Если необходимо получить расширенную информацию о содержимом


пакетов с маршрутной информацией, таких как Update, Query, Replay необхо-
димо воспользоваться командой debug ip eigrp. Данная команда отображает
получение или отправку всех служебных пакетов EIGRP за исключением
Hello пакетов, и содержащуюся в них информацию. Информация, выводимая
командой, представлена в примере 7.31.

147
Пример 7.31 – Информация, выводимая командой debug ip eigrp
r2#debug ip eigrp
IP-EIGRP Route Events debugging is on
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming QUERY packet
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 routing table not updated thru 10.93.1.2
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): route in-
stalled for 10.89.1.0 ()
*Mar 15 13:44:02.039 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming QUERY packet
*Mar 15 13:44:02.039 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/1
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/0
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.047 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.051 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/1
*Mar 15 13:44:02.051 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.067 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.067 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.071 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.071 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 routing table not updated thru 10.93.1.18
*Mar 15 13:44:02.199 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - not in IP routing table
*Mar 15 13:44:02.199 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295

Для отображения информации о процессе работы алгоритма DUAL, ис-


пользуется команда debug eigrp fsm. Информация, выводимая командой,
представлена в примере 7.32.

148
Пример 7.32 – Информация, выводимая командой debug eigrp fsm
r2#debug eigrp fsm
EIGRP FSM Events/Actions debugging is on
*Mar 15 14:05:16.051 KRSK: DUAL: rcvquery: 10.93.1.32/28 via 10.93.1.2 metric
4294967295/4294967295, RD is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL: Find FS for dest 10.93.1.32/28. FD is
1794560, RD is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL: 10.93.1.2 metric 4294967295/4294967295
*Mar 15 14:05:16.051 KRSK: DUAL: 10.93.1.18 metric 1794560/28160 found
Dmin is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL: send REPLY(r1/n1) about 10.93.1.32/28 to
10.93.1.2
*Mar 15 14:05:16.051 KRSK: DUAL: RT installed 10.93.1.32/28 via 10.93.1.18
*Mar 15 14:05:16.051 KRSK: DUAL: Send update about 10.93.1.32/28. Reason:
nexthop changed
*Mar 15 14:05:16.051 KRSK: DUAL: Send update about 10.93.1.32/28. Reason:
lost if
*Mar 15 14:05:16.075 KRSK: DUAL: Removing dest 10.93.1.32/28, nexthop
10.93.1.2, infosource 10.93.1.2
*Mar 15 14:05:16.087 KRSK: DUAL: dest(10.93.1.32/28) not active
*Mar 15 14:05:16.087 KRSK: DUAL: rcvupdate: 10.93.1.32/28 via 10.93.1.2 metric
1797120/30720
*Mar 15 14:05:16.087 KRSK: DUAL: Find FS for dest 10.93.1.32/28. FD is
1794560, RD is 1794560
*Mar 15 14:05:16.087 KRSK: DUAL: 10.93.1.18 metric 1794560/28160
*Mar 15 14:05:16.087 KRSK: DUAL: 10.93.1.2 metric 1797120/30720 found
Dmin is 1794560
*Mar 15 14:05:16.087 KRSK: DUAL: RT installed 10.93.1.32/28 via 10.93.1.18

Для отображения детальной информации о процессе формировании


передачи служебных пакетов используется команда debug eigrp transmit. Син-
таксис команды debug eigrp transmit приводится в примере 7.33.

Пример 7.33 – Синтаксис команды debug eigrp transmit


debug eigrp transmit [ack] [build] [detail] [peerdown] [sia] [startup]
[strange]
no debug eigrp transmit [ack] [build] [detail] [peerdown] [sia] [startup]
[strange]

Описание параметров команды debug eigrp transmit приводиться в та-


блице 7.8.

Таблица 7.8 – Параметры команды debug eigrp transmit

Параметр Описание
ack Информация о пакетах ACK послан-
ных маршрутизатором.
build Вывод сообщений об изменениях в та-
блице топологии.

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

Параметр Описание
detail Вывод детальной информации.
peerdown Вывод сообщений генерируемых по-
сле потери соседа.
sia Вывод сообщений SIA.
startup Вывод сообщений генерируемых по-
сле установки соединения с соседом.
strange Вывод редких сообщений связанных с
обменом служебными пакетами.

При тестировании и устранении ошибок в процессе маршрутизации EI-


GRP бывает необходимо сбросить соседские отношения с одним, нескольки-
ми или со всеми соседними EIGRP маршрутизаторами, для этого существует
команда clear ip eigrp neighbors. Синтаксис команды приводится в примере
7.34.

Пример 7.34 – Синтаксис команды clear ip eigrp neighbors


clear ip eigrp neighbors [ip-address | interface-type interface-number]

Описание параметров команды приводиться в таблице 7.9.

Таблица 7.9 – Параметры команды clear ip eigrp neighbors

Параметр Описание
ip-address Сброс соседских отношений с указан-
ным маршрутизатором.
interface-type interface-number Сброс соседских отношений с соседя-
ми за указанным интерфейсом.

150
8 Использование протокола EIGRP в масштабируемых сетях

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


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

10.1.1.0/24

Q R R3
R1

Q R
R4

Q R

R2 R5

Рисунок 8.1 – Обработка изменений в топологии сети

На рисунке 8.1 изображена сеть передачи данных с резервными канала-


ми связи между центральным узлом и удаленными подразделениями. Каждый
удаленный маршрутизатор имеет два возможных пути до сети 10.1.1.0/24 че-
рез маршрутизаторы R1 или R2.
В такой топологии при запуске процесса запросов, каждый путь между
региональным и удаленным узлом получает двойной трафик в процессе схо-
димости из–за избыточности, заложенной в топологию сети.
Если маршрутизатор R2 теряет сеть 10.1.1.0/24, то начинается процесс
многократных запросов и ответов между региональными маршрутизаторами
R1 и R2 и удаленными маршрутизаторами R3, R4 и R5. Такое увеличение тра-
фика значительно усложняет процесс сходимости сети.
В сети с двумя региональными и тремя удаленными маршрутизаторами
эта проблема не является очень серьезной, но если маршрутизаторов значи-
тельно больше, данная проблема может парализовать работу всей сети.
Разберем детально процесс запросов для сети 10.1.1.0/24. В предлагае-
мом примере, сеть 10.1.1.0/24 всем другим маршрутизаторам анонсирует
маршрутизатор R2. Наилучший путь до 10.1.1.0/24 для маршрутизатора R1

151
проходит через Ethernet канал до R2. Удаленные маршрутизаторы R3, R4 и
R5 используют последовательные магистральные каналы связи и маршрути-
затор R2 как преемника для сети 10.1.1.0/24. Но в их таблицах маршрутиза-
ции имеется так же запись о вероятном преемнике для сети 10.1.1.0/24, кото-
рым является маршрутизатор R1.
Когда маршрутизатор R2 теряет маршрут до сети 10.1.1.0/24, то он по
алгоритму DUAL опрашивает всех своих соседей на предмет наличия марш-
рута до сети 10.1.1.0/24. Удаленные маршрутизаторы получив данный запрос,
автоматически начинают использовать маршрут к запрашиваемой сети через
маршрутизатор R1, и отвечают об этом маршрутизатору R2.
Маршрутизатор R2 получил три ответа из четырех и продолжает ожи-
дать ответ от маршрутизатора R1.
Когда маршрутизатор R1 получает от маршрутизатора R2 запрос на
сеть 10.1.1.0/24, не имея вероятного преемника но, зная, что есть путь к этой
сети через удаленные маршрутизаторы, начинает рассылать им запросы о
маршруте до этой сети.
Удаленные маршрутизаторы принимают данные запросы, но так как в
их таблицах топологии маршрутизатор R1 уже значится как преемник для
маршрута на сеть 10.1.1.0/24, им приходится вычеркивать его из таблиц топо-
логии и производить рассылку запросов на соседние маршрутизаторы, в дан-
ном случае R2.
Маршрутизатор R2 получает запросы от удаленных маршрутизаторов,
но не может им ответить, потому что сам ожидает ответ от маршрутизатора
R1. А маршрутизатор R1 в свою очередь не может ответить R2 пока не полу-
чит ответа от удаленных маршрутизаторов. Для сети 10.1.1.0/24 наступает си-
туация SIA.
Так как маршрутизатор R2 послал запрос первым, то его таймер SIA ис-
текает первым, теперь он может ответить удаленным маршрутизаторам о том,
что не существует маршрута до сети 10.1.1.0/24.
Удаленные маршрутизаторы отсылают на маршрутизатор R1 ответ о
том, что они не имеют маршрута до сети 10.1.1.0/24.
Описанный дизайн сети не плох, но в нем возможна генерация больших
объемов служебного трафика EIGRP. Поэтому необходимы методы уменьше-
ния количества распространяемых запросов о маршрутах.

8.1 Масштабируемость. Проблемы и решения

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


влияют на масштабируемость сетей:
– Объем трафика передаваемого между соседями. Появление новых
соседей и изменения топологии приводят к увеличению служебного трафика
протокола EIGRP.

152
– Количество маршрутизаторов. При изменении топологии объем ре-
сурсов, потребляемых протоколом EIGRP, зависит от количества маршрути-
заторов, которые будут непосредственно задействованы в происходящих из-
менениях.
– Глубина топологии. Глубина топологии может повлиять на время
сходимости. Глубиной является количество маршрутизаторов, на которое
должен разойтись запрос об изменении в топологии сети, чтобы достичь
маршрутизатора способного ответить на запрос.
– Количество альтернативных путей в сети. Сеть передачи данных
по возможности должна предоставлять альтернативные маршруты, которые
необходимы для повышения отказоустойчивости сети. Однако в это же время
наличие большого количества альтернативных путей может создать пробле-
мы для сходимости протокола EIGRP, поскольку протокол EIGRP использует
механизм рассылки запросов для исследования всех возможных путей для за-
мены потерянного маршрута, что может приводить активную сеть в состоя-
ние SIA.
Должно быть проведено исследование, что бы определить объем ин-
формации необходимый удаленным маршрутизаторам, что бы достичь желае-
мого уровня распределения маршрутов.
Для достижения максимальной стабильности и масштабируемости, уда-
ленные маршрутизаторы могут использовать маршруты по умолчанию для
достижения ядра сети.
Если некоторые сети нуждаются в знании большего количества марш-
рутов, чтобы гарантировать оптимальный выбор, администратор сети должен
принять решение относительно того, принесет ли распространение дополни-
тельной маршрутной информации большую выгоду, чем расширение про-
пускной способности каналов связи, для достижения поставленной цели.
Когда администратор определит минимальный, набор требований к
сети, можно сделать EIGRP более масштабируемым. Два лучших пути сде-
лать это:
– Сконфигурировать суммарные маршруты на выходных интерфейсах
маршрутизаторов на уровне распределения.
– Сконфигурировать удаленные маршрутизаторы как тупиковые EIGRP
маршрутизаторы.

8.2 Использование суммарных маршрутов

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


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

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

Q 172 .16.1.0/24 Q 172 .16.1.0/24

S0 S1
192 .168 .1.0/24 172 .16.0.0/16
R2 R3
R1 172 .16.1.0/24

R 172 .16.1.0/24 R 172 .16.1.0/24


Unreachable Unreachable

r1# interface Serial 0


ip summary-address eigrp 200 172.16.0.0 255.255.0.0

Рисунок 8.2 – Применение суммарных для предотвращения


распространения запросов

На рисунке 8.2 маршрутизатор R1 отсылает только суммарный маршрут


на сеть 172.16.0.0/16 маршрутизатору R2. Если сеть 172.16.1.0/24 станет недо-
ступна, R2 получит запрос от R1 об этой сети. В таблице маршрутизации у R2
есть только запись на весь суммарный маршрут к сети 172.16.0.0/16, а кон-
кретной сети 172.16.1.0/24 в таблице маршрутизации нет, поэтому R2 ответит
о недостижимости сети 172.16.1.0/24.
Если для рассмотренной ранее сети (Рисунок 8.3) применить суммиро-
вание маршрутов на последовательных интерфейсах, то количество запросов
и ответов в сети значительно уменьшится.
В данном примере применение суммарных маршрутов предотвращает
распространение запросов о пропавшей сети 10.1.1.0/24 от удаленных марш-
рутизаторов, и предотвращает наступление SIA на маршрутизаторе R2.
При использовании суммарных маршрутов на выходных интерфейсах
маршрутизаторов R2 и R1, на удаленные маршрутизаторы распространяются
только маршруты на всю сеть 10.0.0.0/8.
Подсеть 10.1.1.0/24 неизвестна удаленным маршрутизаторам, поэтому
они на такой запрос могут ответить только, что им не известна сеть
10.1.1.0/24

154
10.1.1.0/24

10.0.0.0/8
Q R R3
R1

R4

10.0.0.0/8
Q R

R2 R5

Рисунок 8.3 – Обработка изменений в топологии сети с использованием


суммарных маршрутов

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


сети.

8.3 Использование тупиковых маршрутизаторов

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


ОС Cisco IOS начиная с 12.0(7)T.
Использование тупиковых EIGRP маршрутизаторов улучшает стабиль-
ность сети, уменьшает использование вычислительных и сетевых ресурсов и
упрощает конфигурацию маршрутизаторов.
При использовании данной возможности, только удаленные маршрути-
заторы могут быть сконфигурированы как тупиковые.
Настройка удаленных маршрутизаторов как тупиковых EIGRP маршру-
тизаторов информирует вышестоящие маршрутизаторы о том, что посылать
им запросы не имеет смысла потому, что они не имеют нижестоящих соседей
и не могут знать альтернативных маршрутов.
Тупиковые маршрутизаторы могут иметь соседские отношения только с
вышестоящими маршрутизаторами. Однако применение тупиковых маршру-
тизаторов не запрещает им распространять маршруты о сетях непосредствен-
но подключенных к ним, или настроенные на них суммарные и статические
маршруты.
Топология «звезда» наилучшим образом подходит для создания тупи-
ковых маршрутизаторов. В данной топологии удаленный маршрутизатор весь
трафик, который не является локальным передает центральному маршрутиза-
тору. Удаленный маршрутизатор не должен знать таблицы маршрутизации
всей сети, ему достаточно знать маршрут на центральный маршрутизатор. В
топологии «звезда» размещение таблицы маршрутизации всей сети на уда-

155
ленном маршрутизаторе не имеет ни какой технической необходимости, так
как все равно все маршруты проходят через центральный маршрутизатор.
Для настройки процесса маршрутизации EIGRP как тупикового приме-
няется команда eigrp stub, синтаксис команды приводится в примере 8.1

Пример 8.1 – Синтаксис команды eigrp stub


(config-router)#eigrp stub [receive-only | connected | static | summary |
redistributed]
(config-router)no eigrp stub [receive-only | connected | static | summary |
redistributed]

Описание параметров команды eigrp stub приводиться в таблице 8.1.

Таблица 8.1 – Параметры команды eigrp stub

Параметр Описание
receive-only Ограничивает функции маршрутизато-
ра только получением маршрутов от
других маршрутизаторов. Маршрути-
затор сконфигурированный, данной
командой не рассылает другим марш-
рутизаторам известные ему маршруты.
Любые другие опции при использова-
нии receive–only становятся недоступ-
ны, потому что они предусматривают
рассылку маршрутов во внешнюю
сеть.
connected Опция разрешает рассылку маршрутов
на сети, которые являются непосред-
ственно подключенными к данному
маршрутизатору. Эта опция включает-
ся по умолчанию при конфигурации
тупикового маршрутизатора и являет-
ся наиболее используемой.
static Даная опция позволяет маршрутизато-
ру производить рассылку статических
маршрутов из его таблицы маршрути-
зации. Для корректной работы марш-
рутизатора в данной конфигурации
необходимо присутствие команды re-
distribute static в настройках EIGRP
маршрутизатора

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

Параметр Описание
summary Опция позволяет рассылку суммарных
маршрутов. Суммарные маршруты мо-
гут быть настроены вручную при по-
мощи команды summary–address или
автоматически командой auto–sum-
mary. Опция summary включается ав-
томатически.
redistributed Опция позволяет рассылку маршрутов
полученную от других протоколов
маршрутизации. Для корректной рабо-
ты маршрутизатора в данной конфигу-
рации необходима настройка механиз-
мов перераспределения маршрутной
информации от других протоколов
маршрутизации

Команда eigrp stub может конфигурироваться с несколькими опциями,


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

10.1.1.0/24

Q R R3
R1

S
R4

R2 R5

Рисунок 8.4 – Обработка изменений в топологии сети с использованием


тупиковых маршрутизаторов

157
Использование тупиковых маршрутизаторов в удаленных офисах (Рису-
нок 8.4) позволяет центральным маршрутизаторам немедленно отвечать на
запросы о поиске альтернативных маршрутов без распространения запросов в
сторону удаленных маршрутизаторов. Таким образом, сокращается время
сходимости сети.
Использование тупиковых маршрутизаторов предотвращает проблему,
рассылки удаленными маршрутизаторами маршрутов от центральных марш-
рутизаторов другим маршрутизаторам находящимся в центральной части
сети.

8.4 Использование протокола EIGRP в современных условиях

В настоящее время в сетях передачи данных широкое распространение


получили высокоскоростные каналы передачи данных со скоростями 1Гбит/с
и выше. Также значительно изменился вид передаваемого трафика. Если
раньше это был в основном FTP трафик, трафик почтовых и WEB приложе-
ний, то в настоящее время все большую долю трафика в сетях передачи дан-
ных занимает трафик приложений реального времени, таких как IP-телефония
или видеоконференции.
Исходя из этого, значительно изменились требования к устойчивости и
времени сходимости сети. Если раньше время сходимости сети после произо-
шедших изменений равнявшееся нескольким секундам считалось хорошим, и
ни как не сказывалось на работе приложений, то в настоящее время подобные
задержки могут негативно сказаться на работе приложений реального време-
ни.
Для избегания подобных проблем используется ряд мер: использование
высокоскоростных каналов связи, резервирование каналов связи, а также вне-
сение изменений в работу маршрутизаторов и протоколов маршрутизации с
целью уменьшения времени сходимости сети при обнаружении изменений.
Для протокола EIGRP применяется два основных механизма уменьшения вре-
мени сходимости сети.
Это уменьшение Hello интервала до минимума равного 1 секунде. При-
менение данного механизма может показаться чересчур расточительным с
точки зрения использования пропускной способности каналов связи. Однако
доля Hello пакетов, по сравнению с другим служебным трафиком в сети пере-
дачи данных, при использовании высокоскоростных каналов связи незначи-
тельна.
Вторым методом уменьшения времени сходимости сети является
уменьшение времени реакции маршрутизатора на изменения в состоянии его
интерфейсов. По умолчанию, время реакции маршрутизатора ни переход ин-
терфейса из состояния Up в Down и наоборот равно 2 секундам. Минималь-

158
ным значением времени реакции маршрутизатора является ноль секунд, т.е.
мгновенная реакция. Время реакции на переход интерфейса между его состо-
яниями устанавливается независимо на каждом из интерфейсов при помощи
команды carrier-delay синтаксис команды приводится в примере 8.2

Пример 8.2 – Синтаксис команды carrier-delay


(config-if)#carrier-delay [seconds | msec milliseconds]
(config-if)#no carrier-delay [seconds | msec milliseconds]

Описание параметров команды carrier-delay приводиться в таблице 8.2.

Таблица 8.2 – Параметры команды carrier-delay

Параметр Описание
seconds Время реакции в секундах на измене-
ние состояния интерфейса. По умолча-
нию 2 секунды.
msec milliseconds Время реакции в миллисекундах на из-
менение состояния интерфейса. По
умолчанию 50 миллисекунд.

На рисунке 8.5 приводится пример настройки маршрутизаторов с целью


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

GI 1

GI 0
R1 R2

r1# interface GigabitEthernet 1 r2# interface GigabitEthernet 0


ip hello -interval eigrp 1 ip hello-interval eigrp 1
ip hold-time eigrp 3 ip hold -time eigrp 3
carrier-delay msec 0 carrier -delay msec 0

Рисунок 8.5 – Минимизация времени обнаружения изменений


в топологии мети

159
9 Протоколы маршрутизации по состоянию канала

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


которых маршрутная информация представляется в форме векторов до сетей
получателей. Протоколы маршрутизации по состоянию канала обладают точ-
ным знанием топологии сети передачи данных, исходя из которой, они строят
таблицу маршрутизации.
Чтобы лучше понять различие между дистанционно-векторными алго-
ритмами Беллмана-Форда, алгоритмом DUAL, и алгоритмами маршрутизации
по состоянию канала, взглянем на рисунки 9.1 – 9.3.

22 25

СП2 СП3 СП7

СП6 СП5 10 18
R1

10
14

22 СП1

СП4

Рисунок 9.1 – Представление топологии сети


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

На рисунке. 9.1 изображено представление топологии сети передачи


данных маршрутизатором R1, который использует один из вариантов дистан-
ционно-векторного алгоритма Беллмана-Форда. Маршрутизатор имеет ин-
формацию только о сетях получателях, показанных в виде сегментов Ethernet,
о том, как далеко и в каком направлении они находятся.
На рисунке. 9.2 изображено представление той же сети передачи дан-
ных маршрутизатором R1, но на этот раз маршрутизатор использует протокол
маршрутизации на основе алгоритма DUAL. Маршрутизатор знает о своих
непосредственных соседях, о том, насколько далеко и в каком направлении
они расположены, а также дистанции от соседей до всех известных сетей по-
лучателей.

160
СП2 СП3 СП7

12

СП6 СП5 10 18 7

4 R4 R1 R6

16 10

12 СП1

R2

СП4

Рисунок 9.2 – Представление топологии сети алгоритмом DUAL


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

Как видно, кроме кратчайшего пути к сети получателю СП4, лежащего


через маршрутизатор R2, маршрутизатор R1 смог также обнаружить альтер-
нативный маршрут, лежащий через маршрутизатор R4. Метрика кратчайшего
маршрута равна 22 (10 + 12), тогда как метрика альтернативного – 26 (10 +
16). Несмотря на более высокую метрику, маршрутизатор R1 все же рассмат-
ривает маршрут через маршрутизатор R4 как альтернативу, поскольку метри-
ка собственного маршрута маршрутизатора R4 к СП4 равна всего 16, т.е.
меньшему значению, чем метрика кратчайшего маршрута маршрутизатора
R1. Следовательно, маршрутизатор R4 находится ближе к сети получателю,
чем маршрутизатор R1, а значит, маршрутизатор R1 может мгновенно
переключиться на маршрут через R4, если характеристики маршрута через R2
ухудшатся или он станет недоступен.

СП2 СП3 СП7

СП6 СП5 10 18 7

R4 R1 R6

8 4 10
R5

12 СП1

R3 R2

СП4

Рисунок 9.3 – Представление топологии сети


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

161
На рисунке 9.3 показано представление топологии сети передачи дан-
ных маршрутизатором R1 с использованием протокола маршрутизации по со-
стоянию канала. Здесь маршрутизатор R1 знает полную топологию сети пере-
дачи данных. Следовательно, он знает не только об альтернативном маршруте
к сети получателю СП4 через маршрутизатор R4, но также и об альтернатив-
ных маршрутах к СП6 и СП5 через маршрутизатор R2.
Протоколы маршрутизации по состоянию канала имеют два главных
преимущества над дистанционно-векторными протоколами маршрутизации.
Первое преимущество заключается в том, что каждый маршрутизатор в доме-
не маршрутизации имеет точную информацию о топологии сети передачи
данных, следовательно, он может гарантировать, что в таблицу маршрутиза-
ции будут внесены истинные и оптимальные маршруты до сетей получателей.
Второе преимущество следует из первого. Оно заключается в том, что
если маршрутизатор имеет точную информацию о топологии сети передачи
данных в домене маршрутизации, он может самостоятельно, не прибегая к
механизму рассылки запросов соседним маршрутизаторам, о возможных аль-
тернативных маршрутах, вносить изменения в таблицу маршрутизации, после
того как, он обнаружил недоступность того или иного маршрута. Следова-
тельно, время сходимости протоколов маршрутизации по состоянию канала,
значительно меньше, чем у дистанционно-векторных протоколов маршрути-
зации использующих алгоритм Беллмана-Форда.
Однако превосходство протоколов маршрутизации по состоянию кана-
ла имеет свою цену. Такие протоколы обычно значительно сложнее реализо-
вать, чем дистанционно-векторные протоколы Беллмана-Форда и протоколы
на основе алгоритма DUAL. Вычисление маршрутов, исходя из топологиче-
ской информации, обычно требует больше усилий по обработке, чем необхо-
димо для выполнения дистанционно-векторных вычислений. Кроме того, что-
бы обеспечить идентичность топологических сведений на всех маршрутиза-
торах, требуется более интенсивный обмен данными между маршрутизатора-
ми.
Если протоколы маршрутизации по состоянию канала сходятся бы-
стрее, чем протоколы Беллмана-Форда, этого нельзя сказать при сравнении
этих протоколов с протоколами на основе алгоритма DUAL. Эксперименталь-
ные данные указывают на то, что в большинстве случаев протоколы маршру-
тизации на основе DUAL сходятся, по меньшей мере настолько же быстро,
как и протоколы маршрутизации по состоянию канала.
И все же алгоритм маршрутизации по состоянию канала популярен
благодаря широко распространенному протоколу маршрутизации OSPF, а сам
протокол обязан своей популярностью открытости своей спецификации.
Эта открытость позволила множеству различных производителей,
включая Cisco, успешно реализовать протокол OSPF в своем оборудовании и
программном обеспечении. Хотя протоколы маршрутизации, основанные на

162
конкурирующем алгоритме DUAL, работают быстро, практически единствен-
ный популярный экземпляр таких протоколов – это протокол EIGRP, являю-
щийся фирменным протоколом корпорации Cisco.
Протокол OSPF оказался способен поддерживать очень крупные сети
передачи данных, состоящие зачастую из тысяч маршрутизаторов. Даже в та-
ких крупных сетях протокол OSPF быстро обрабатывает происходящие изме-
нения, и время его сходимости редко превышает доли минуты.
В основе протокола OSPF, как и любого другого протокола маршрути-
зации по состоянию канала, лежит алгоритм кратчайшего пути Дейкстры
(Dijkstra), используемый для создания маршрутов на основе топологической
информации. Учитывая центральное место алгоритма Дейкстры в работе про-
токолов маршрутизации по состоянию канала, необходимо сначала рассмот-
реть сам алгоритм и получить понятие о работе ядра протокола маршрутиза-
ции по состоянию канала. И только после этого обратиться к подробному
рассмотрению протокола OSPF.

9.1 Алгоритм «кратчайшего пути» Дейкстры

Алгоритм кратчайшего пути – shortest path algorithm (SPF) Дейкстры ра-


ботает с графами, состоящими из вершин, соединенных ребрами. Каждое ре-
бро соединяет ровно две вершины в одном направлении. Каждое ребро имеет
стоимость, связанную с ним. Каждая вершина может быть связана с любым
числом ребер.
Вершины можно представлять как точки, а ребра – как перемещение
между этими точками. Перемещение обеспечивается лишь в одном направле-
нии и за определенную стоимость – в направлении ребра и за стоимость ре-
бра. Например, если ребро соединяет вершину A с вершиной B, это означает,
в сущности, что имеется возможность за стоимость этого ребра переместить-
ся из вершины A в вершину B. Это ребро, однако, не позволяет переместиться
обратно из вершины B в вершину A. Такое перемещение требует наличия
другого ребра – из вершины B в вершину A.

B
1
A 3 3
8 5
4 D
4
2 C 8
7 2
6

E 4 F

Рисунок 9.4 – Пример графа

163
На рисунке 9.4 приводится пример графа. Этот граф содержит шесть
вершин, помеченных буквами от A до F. Ребра обозначаются линиями со
стрелками, которые соединяют вершины, а стоимость ребер указана в виде
чисел, изображенных поверх ребер.
Говорится, что вершина X является смежной с вершиной Y, если имеет-
ся ребро, ведущее от вершины X к вершине Y. Например, на рисунке 9.4 вер-
шина B является смежной с вершиной A. Необходимо обратить внимание,
что обратное может быть неверно, например, вершина A не является смежной
с вершиной B, поскольку ребра, ведущего от вершины A к вершине B, не су-
ществует.
Граф с большим количеством вершин может иметь множество путей
между двумя вершинами. Среди этих путей лучший путь определяется как
путь, совокупная стоимость которого, рассчитана как минимальная сумма
стоимостей составляющих путь ребер. Например, кратчайший путь от верши-
ны D к вершине A лежит через вершину B, его стоимость равна 4. Обратный
путь, от вершины A к вершине D, имеет большую длину, он лежит через вер-
шины C и B и имеет стоимость 15.
В приведенном примере задача нахождения кратчайшего пути относи-
тельно проста, но если граф становится больше, количество вычислений рас-
тет экспоненциально. И даже самый быстрый компьютер будет затрачивать
слишком много времени на перебор всех возможных путей и расчет их стои-
мости.
Алгоритм SFP решает задачу быстрого нахождения кратчайшего пути
между любыми двумя вершинами в графе с произвольными связями.
Для работы алгоритм использует две вспомогательные структуры дан-
ных: базу данных вершин, для которых ищется кратчайший путь, и базу дан-
ных вариантов вершин, для которых кратчайший путь может быть найден.
Обозначим эти базы как «Найденные» и «Кандидаты». Обе базы данных име-
ют идентичную структуру: они содержат два поля, содержащие ссылку на
вершину и совокупную стоимость пути от начальной вершины к указанной.
Чтобы продемонстрировать работу алгоритма по шагам воспользуемся
графом, изображенным на рисунке 9.4.
Работа алгоритма начинается с помещения начальной вершины в базу
«Найденные» с совокупной стоимостью 0, а всех ее смежных вершин - в базу
«Кандидаты» с совокупной стоимостью, равной стоимости соответствующих
ребер. После этого алгоритм циклически проходит через следующие рекур-
сивные шаги:
Шаг 1. Найти в базе «Кандидаты» вершину с наименьшей совокупной
стоимостью. Переместить вершину в базу «Найденные».
Шаг 2. Определить вершины, с которыми перемещенная вершина яв-
ляется смежной.
Шаг 3. Отбросить смежные вершины данной вершины, которые уже
были перемещены в базу «Найденные».

164
Шаг 4. Для каждой из смежных вершин перемещенной вершины, кото-
рая уже была помещена в базу «Кандидаты», установить записанную сово-
купную стоимость равной меньшей из величин предыдущей записанной сово-
купной стоимости и суммы совокупной стоимости перемещенной вершины
плюс стоимость ребра, ведущего от перемещенной вершины к смежной, фор-
мула (9.1).

Cсмеж. нов. = min(Cсмеж. стар., C перемещ. + Cребра) (9.1)

где Cсмеж. нов. и Cсмеж. стар. – соответственно новая и старая записанные совокуп-
ные стоимости смежной вершины,
C перемещ. – записанная совокупная стоимость перемещенной вершины,
Cребра – стоимость ребра от перемещенной вершины к смежной.

Шаг 5. Поместить каждую смежную вершину, не содержащуюся ни в


базе «Найденные», ни в базе «Кандидаты», в базу «Кандидаты». Установить
ее совокупную стоимость равной сумме совокупной стоимости перемещен-
ной вершины и стоимости ребра, ведущего от перемещенной вершины к
смежной, формула (9.2).

Cсмеж. = C перемещ. + Cребра (9.2)

где Cсмеж. – совокупная стоимость смежной вершины.

Шаг 6. Если база «Кандидаты» пуста, завершить работу. В противном


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

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

Шаг 1 Шаг 2

A Найденные A Найденные
4 4 4 4
А 0 А 0
*
С E С E
Кандидаты 12 C 4
*
> C 4 B Кандидаты

> E 4 E 4

> B 12

Шаг 3 Шаг 4

A Найденные A Найденные
4 4 4 4
А 0 А 0
С E С E
12 ? 8 C 4 12 8 C 4
?

B A C F *
E 4 B F E 4
16
Кандидаты F 8
*
D
B 12 Кандидаты

> F 8 B 12

> D 16

Шаг 5 Шаг 6

A Найденные A Найденные
4 4 4 4
А 0 А 0
С E С E
12 8 C 4 12 8 C 4

B F E 4 B F E 4
? 15 16 15
? B 12 B 12
* *
A C D D D
Кандидаты ? ? Кандидаты
?
> D 16→15 B E F <Пусто >

Рисунок 9.5 – Итерации алгоритма SPF

166
10 Протокол OSPF

Протокол маршрутизации по состоянию каналов OSPF (Open Shortest


Path First) описан в документе RFC 2328. Протокол OSPF использует алго-
ритм SPF и поэтому может осуществлять более интеллектуальный выбор
маршрута по сравнению с дистанционно-векторными протоколами маршру-
тизации. Существует несколько версий протокола OSPF, в настоящее время
широкое распространение получила вторая версия протокола – OSPF v2.
Все маршрутизаторы поддерживающие OSPF, сети и подсети логически
объединены в зоны. Сети передачи данных, в которых применяется протокол
OSPF, могут составлять одну зону или включать множество зон, организован-
ных по иерархическому признаку. Объединенная сеть передачи данных, ис-
пользующая протокол OSPF, независимо от того, состоит ли она из одной
зоны или включает множество зон, представляет собой один домен маршру-
тизации, или другими словами одну автономную систему. Такая иерархиче-
ская структура позволяет локализовать изменения маршрутов и трафик марш-
рутных обновлений в пределах каждой зоны. Соответственно, это уменьшает
нагрузку на каналы связи, связанные с поддержкой больших таблиц маршру-
тизации и пересчетом этих таблиц в случае изменения маршрутов.

10.1 Характеристики протокола OSPF

Протокол OSPF обладает следующими свойствами:


– Групповая рассылка обновлений. В протоколе OSPF рассылка тополо-
гической информации о состоянии каналов связи осуществляется по группо-
вому адресу 224.0.0.5 для всех маршрутизаторов OSPF и по адресу 224.0.0.6
для назначенного и резервного назначенного маршрутизатора.
– Бесклассовая маршрутизация. Протоколом OSPF поддерживается тех-
нология VLSM.
– Аутентификация. Маршрутизаторы OSPF имеют возможность ис-
пользовать несколько методов аутентификации, таких как аутентификация по
паролю или с помощью MD5.
– Быстрота распространения изменений в топологии. Благодаря отсут-
ствию периодической рассылки обновлений маршрутной информации марш-
рутизатор, обнаруживший изменения в топологии сети, незамедлительно опо-
вещает об этом все соседние маршрутизаторы
– Экономия пропускной способности каналов связи. Протокол OSPF
производит периодическую рассылку информации базы данных топологии
сети передачи данных через длительные промежутки времени, 30 минут.
– Иерархическое разделение сети передачи данных. Протокол OSPF
позволяет произвести иерархическое разделение сети передачи данных на

167
несколько зон, с целью уменьшения нагрузки на маршрутизаторы внутри
каждой зоны.

10.1.1 Групповая рассылка обновлений состояния каналов

Для распространения обновлений о состоянии каналов передачи дан-


ных OSPF маршрутизаторы не используют широковещательные рассылки.
Вместо этого они применяют групповую рассылку по зарезервированным для
протокола OSPF групповым IP адресам.
Протокол OSPF поддерживает два основных групповых адреса:
224.0.0.5 – для всех маршрутизаторов OSPF и 224.0.0.6 - адрес для назначен-
ного и резервного назначенного маршрутизатора. Маршрутизатор, на кото-
ром активизирован протокол OSPF, автоматически становится членом группы
многоадресной рассылки с адресом 224.0.0.5 и начинает рассылать и получать
групповые сообщения OSPF.
В широковещательных сетях выбирается назначенный маршрутизатор
(Designated Router) – DR и резервный назначенный маршрутизатор (Backup
Designated Router) – BDR. Оба эти маршрутизатора с момента принятия на
себя таких функций становятся членами группы многоадресной рассылки с
адресом 224.0.0.6 и начинают принимать групповые сообщения, посылаемые
на этот адрес всеми остальными маршрутизаторами OSPF принадлежащими
тому же широковещательному домену.

10.1.2 Аутентификация

Протокол OSPF обеспечивает аутентификацию соседних маршрутиза-


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

10.1.3 Быстрота распространения изменения в топологии

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


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

168
10.1.4 Иерархическое разделение сети передачи данных

В небольших сетях количество каналов связи межу маршрутизаторами


не столь велико и расчет маршрутов для каждой сети получателя не столь
сложен. Однако, в больших сетях, где присутствует значительно большее ко-
личество каналов связи между маршрутизаторами и число потенциальных
маршрутов велико, применение алгоритма SPF требует достаточного большо-
го промежутка времени и значительных вычислительных возможностей
маршрутизатора. Протокол OSPF для уменьшения числа расчетов применяют
разделение сети передачи данных на зоны. Число маршрутизаторов в каждой
зоне, а так же число LSA в пределах зоны не велико, следовательно, база дан-
ных состояния каналов в пределах зоны значительно меньше. Поэтому расчет
маршрутов становиться легче и занимает меньше времени. Различается два
основных типа зон:
– Транзитная зона. Главная задача транзитной зоны быстрое и эффектив-
ное продвижение IP пакетов в другие зоны. В транзитной зоне не рекомендует-
ся размещать пользовательские сети, хотя это не запрещено в спецификации.
В протоколе OSPF в качестве транзитной зоны применяется Зона 0, также
именуемая базовой (backbone area).
– Регулярные зоны. В протоколе OSPF зоны, чья основная задача под-
ключение пользователей называются регулярными. Регулярные зоны устанав-
ливаются исходя из функциональных или географических группировок. По
умолчанию регулярные зоны не пропускают трафик из других зон. Весь тра-
фик из других зон проходит через транзитную зону.
Применение протокола OSPF вынуждает применять жесткую двух
уровневую иерархию сети передачи данных (Рисунок 10.1). Все регулярные
зоны должны иметь соединение с базовой зоной.

Зона 0 (Backbone )

Зона 1 Зона 2 Зона 3

Рисунок 10.1 – Зональное разделение в протоколе OSPF

169
10.2 База данных протокола OSPF

Все маршрутизаторы OSPF создают и поддерживают в своей базе дан-


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

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

Чтобы начать обмен топологической информацией, маршрутизаторы


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

Пример 10.1 – Таблица соседства маршрутизатора OSPF


Neighbor ID Pri State Dead Time Address Interface
10.95.72.27 1 2WAY/DROTHER 00:00:37 10.93.72.41 Vlan325
10.95.72.29 1 2WAY/DROTHER 00:00:32 10.93.72.42 Vlan325
10.95.120.22 1 FULL/BDR 00:00:35 10.93.72.34 Vlan325
10.95.120.23 1 FULL/DR 00:00:38 10.93.72.35 Vlan325
10.95.12.10 1 FULL/- 00:00:18 10.93.18.10 Serial0/0

Ниже описаны поля, содержащиеся в таблице соседства:


– Идентификатор соседа (Neighbor ID). Уникальное число идентифици-
рующее соседний маршрутизатор.
– Приоритет маршрутизатора (Pri). Приоритет соседнего маршрутизато-
ра.
– Состояние (State). Состояние соседских отношений.

170
– Время до разрыва соседских отношений (Dead Time). Временной ин-
тервал, по истечении которого будут разорваны соседские отношения, если
до его окончания не придет ни одного пакета OSPF от данного соседа.
– Адрес соседнего маршрутизатора (Address). Адрес сетевого уровня
соседнего маршрутизатора.
– Интерфейс (Interface). Локальный интерфейс маршрутизатора за кото-
рым находится сосед.

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

Все маршрутизаторы OSPF должны создавать и поддерживать в акту-


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

Пример 10.2 – Таблица топологии маршрутизатора OSPF

OSPF Router with ID (10.95.56.58) (Process ID 2)

Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count


10.95.56.33 10.95.56.33 60 0x8000127F 0x00BE67 2
10.95.56.34 10.95.56.34 1837 0x8000127D 0x00DD37 2
10.95.56.58 10.95.56.58 640 0x80001284 0x00E368 6
10.95.56.59 10.95.56.59 1677 0x8000127C 0x00E956 6

Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum


10.93.254.2 10.95.56.33 1606 0x80000207 0x0082D9
10.93.255.158 10.95.56.33 1606 0x80000207 0x008E14
10.93.254.2 10.95.56.34 1606 0x80000204 0x0080D9
10.93.255.158 10.95.56.34 1606 0x80000204 0x008014

Summary Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum


0.0.0.0 10.95.56.33 60 0x80001278 0x00E60B
0.0.0.0 10.95.56.34 1837 0x80001278 0x00E010

Вывод, приведенный в примере 10.2, представляет собой таблицу топо-


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

171
токолу OSPF. В примере имеются записи о четырех маршрутизаторах принад-
лежащих той же зоне, что и маршрутизатор рассматриваемый в примере. Так-
же имеются записи о четырех сетях и о двух суммарных маршрутах на сеть
0.0.0.0. Ниже описаны поля, содержащиеся в таблице топологии:
– Идентификатор топологического элемента (Link ID). Уникальное чис-
ло идентифицирующее топологический элемент.
– Маршрутизатор (ADV Router). Маршрутизатор объявивший тополо-
гический элемент.
– Возраст (Age). Время существования топологического элемента.
– Номер последнего LSA (Seq#). Последовательный номер последнего
пришедшего LSA, о данном топологическом элементе.
– Контрольная сумма (Checksum). Контрольная сумма последнего LSA.
– Число интерфейсов (Link count). Количество интерфейсов маршрути-
затора, на которых разрешен процесс OSPF.
В протоколе OSPF топология сети описывается, хранится и передается
в виде сообщений LSA. Содержимое LSA описывает отдельный топологиче-
ский элемент сети, такой как маршрутизатор, сеть или суммарный маршрут.
Как существуют разные типы элементов топологии сети, имеются и разные
типы сообщений LSA, каждый из которых соответствует отдельному типу
компонентов сети. Подробно о типах сообщений LSA будет рассказано далее.
Создавать и изменять сообщения LSA могут только маршрутизаторы
OSPF, никакие другие компоненты сети передачи данных не могут этого де-
лать. Маршрутизаторы OSPF создают новую топологическую информацию
или производят изменения существующей только после изменений в тополо-
ги сети передачи данных.
Маршрутизатор создающий сообщение LSA объявляет (advertised) его в
домен маршрутизации OSPF. Каждое отдельное сообщение LSA может объ-
явить только один единственный маршрутизатор OSPF.
Когда маршрутизатор объявляет новое сообщение LSA или изменяет
существующие, он должен передать его всем своим соседям. По получении
нового или обновленного LSA соседи сначала сохраняют его в своих базах
данных, а затем передают его далее своим соседям.
Информация о топологических элементах должна быть синхронизиро-
вана между всеми маршрутизаторами, для этого необходимо выполнение сле-
дующих условий:
– Достижение надежной рассылки LSA благодаря применению меха-
низма отправки подтверждений о получении LSA;
– Рассылка LSA производиться последовательно по всем маршрутиза-
торам входящим в зону или по всему домену маршрутизации, если не приме-
няется разделение на зоны OSPF;
– Сообщения LSA имеют порядковые номера, чтобы каждый маршру-
тизатор мог сравнить порядковый номер, поступившего LSA, с уже имею-
щемся в его базе данных, и при необходимости обновить ее.

172
Благодаря гарантированной рассылке сообщений LSA, каждый маршру-
тизатор в пределах зоны или домена маршрутизации может гарантировать,
что он имеет последнюю и самую точную информацию о топологии сети.
Только в данном случае маршрутизатор имеет возможность расчета достовер-
ных маршрутов до всех сетей получателей.
В протоколах маршрутизации по состоянию канала должно проводить-
ся периодическое обновление записей таблицы топологии для актуализации,
имеющейся в ней информации. В протоколе OSPF по умолчанию интервал
обновления информации таблицы топологии составляет 30 минут. Необходи-
мо отметить, что интервал рассылки устанавливается не на всю таблицу топо-
логии, а на каждую отдельно взятую запись из таблицы.
По истечении 30 минут маршрутизатор производит рассылку обновлен-
ных LSA сообщений, у которых параметр Seq увеличен на единицу. При по-
лучении LSA каждый маршрутизатор OSPF выполняет действия по следую-
щему алгоритму, представленному на рисунке 10.2.

Начало

Есть запись Нет


в таблице
топологии

Да

Нет
Тот женомер LSA

Да

Номерпоступившей Нет
Игнорировать LSA
LSA меньше

Да
Добавить LSA
в таблицу топологии .
Отправить подтверждение
Послать отправителю ополучении .
последнююверсию LSA
Разослать LSA соседям .
Обновить таблицу
маршрутизации .

Конец

Рисунок 10.2 – Алгоритм обработки поступившего LSA

173
1. Если поступившее LSA не присутствует в базе данных состояния ка-
налов:
– Маршрутизатор добавляет LSA в свою таблицу топологии;
– Посылает подтверждение о получении LSA;
– Производит рассылку полученного LSA своим соседям за исключени-
ем того от которого это LSA было получено;
– Производит обновление таблицы маршрутизации.
2. Если поступившее LSA присутствует в базе данных состояния кана-
лов и имеет тот же порядковый номер, то поступившее LSA игнорируется;
3. Если, поступившее LSA присутствует в базе данных состояния кана-
лов, но имеет больший порядковый номер:
– Маршрутизатор добавляет, LSA в свою таблицу топологии;
– Посылает подтверждение о получении LSA;
– Производит рассылку полученного LSA своим соседям за исключени-
ем того от которого это LSA было получено;
– Производит обновление таблицы маршрутизации.
4. Если поступившее LSA присутствует в базе данных состояния кана-
лов, но имеет меньший порядковый номер, маршрутизатор посылает отправи-
телю последнюю версию данного LSA.

10.3 Метрика протокола OSPF

Протокол OSPF для оценки маршрутов в отличие от протокола EIGRP


использует не комбинированную метрику, а простую метрику зависящую от
ширины полосы пропускания канала связи.
Метрика протокола OSPF рассчитывается по формуле (10.1):

Metric = 108 / BW (10.1)

где BW – ширина полосы пропускания канала связи.

Из формулы (10.1) видно, что для протокола OSPF каналы связи со ско-
ростями выше 100Мбит/с. будут иметь одинаковую метрику равную 1, так
как в протоколе OSPF метрика меньше 1 не существует.
Для решения данной проблемы необходимо использовать команду auto-
cost reference-bandwidth. Синтаксис команды приводится в примере 10.3.

Пример 10.3 – Синтаксис команды auto-cost reference-bandwidth


(config-router)# auto-cost reference-bandwidth mbps
(config-router)# no auto-cost reference-bandwidth mbps

174
В качестве параметра данной команды выступает ширина полосы про-
пускания канала связи в Мбит/с, которая изменяется от 1 до 4294967. По
умолчанию параметр mbps равен 100, что соответствует формуле (10.1).
Следует отметить, что при необходимости изменения константы для
расчета метрики каналов связи в протоколе OSPF, данные изменения необхо-
димо производить на всех маршрутизаторах входящих в домен маршрутиза-
ции.

10.4 Служебные пакеты протокола OSPF

Все служебные пакеты OSPF инкапсулируются непосредственно в про-


токол IP. Пакеты OSPF не используют в качестве транспорта TCP или UDP
протоколы. Протоколу OSPF требуется гарантированная доставка пакетов, но
так как он не использует протокол TCP для транспортировки пакетов, ему
приходиться использовать механизм подтверждений о получении пакетов. В
заголовке IP пакета служебные пакеты протокола OSPF имеют номер 89.
Протокол OSPF использует в своей работе 5 типов служебных пакетов,
описание которых приводится в таблице 10.1.

Таблица 10.1 – Типы служебных пакетов протокола OSPF

Тип Назначение пакета


Пакеты приветствия используются для поиска соседей и дальней-
Hello (1) шего подтверждения работоспособности соседних маршрутизато-
ров.
DBD (2) Суммарная информация о содержимом таблицы топологии.
LSR (3) Запрос на получение информации о топологическом элементе.
Обновление информации о топологических элементах. Может со-
LSU (4)
держать один или несколько LSA.
LSАck (5) Подтверждение получения пакетов обновлений.

Все пакеты протокола OSPF имеют одинаковый заголовок представлен-


ный на рисунке 10.3.

175
32 бита
8 8 8 8

Версия Тип Длина

Заголовок пакета OSPF


Идентификатормаршрутизатора

Идентификаторзоны

Контрольнаясумма Типаутентификации

Аутентификация

Аутентификация

Данныепротокола OSPF

Рисунок 10.3 – Заголовок пакетов протокола OSPF

Стандартный заголовок протокола OSPF включает следующие восемь


полей:
– Версия. Указывает номер версии протокола OSPF.
– Тип. Указывается тип и номер пакета OSPF из таблицы 10.1.
– Длина. Длина пакета OSPF в байтах, включая заголовок.
– Идентификатор маршрутизатора. Поле содержит уникальное значе-
ние, которое идентифицирует маршрутизатор, инициировавший посылку па-
кета OSPF.
– Идентификатор зоны. Значение идентифицирует зону, из которой по-
ступил пакет OSPF.
– Контрольная сумма. Используется для контроля целостности пакета
OSPF.
– Тип аутентификации. Тип применяемой аутентификации (0 аутенти-
фикация отсутствует, 1 аутентификация по паролю, 2 аутентификация при по-
мощи MD5).
– Аутентификация. В зависимости от типа аутентификации содержит
информацию, применяемую для аутентификации.
После общего заголовка пакета OSPF идет поле данных со специфиче-
ской информацией, относящейся к одному из пяти типов пакетов.

10.4.1 Пакет приветствия

На рисунке 10.4 приводится формат пакета приветствия протокола


OSPF.

176
32 бита
8 8 8 8

Заголовок пакета OSPF (Тип = 1)

Маскаподсети

Hello интервал Опции Приоритет

Данные пакета OSPF


Dead интервал

Назначенныймаршрутизатор

Резервныйназначенныймаршрутизатор

Сосед 1

Сосед N

Рисунок 10.4 – Формат Hello пакета

Пакет приветствия протокола OSPF включает следующие поля:


– Маска подсети. Маска подсети заданная на интерфейсе, через кото-
рый был отправлен пакет.
– Hello интервал. Интервал времени в секундах между отправкой паке-
тов приветствия.
– Опции. Поле описывает дополнительные возможности маршрутизато-
ра отправившего пакет приветствия. Бит, равен 0 – опция не поддерживается,
1 – опция поддерживается. Формат поля представлен на рисунке 10.5. Значе-
ния битов поля приводятся в таблице 10.2.
– Приоритет. Поле содержит значение приоритета маршрутизатора
OSPF заданное на интерфейсе, через который был отправлен пакет.
– Dead интервал. Интервал времени по истечении которого маршрути-
затор считается неработоспособным если от него не поступило ни одного па-
кета.
– Назначенный маршрутизатор. Поле содержит идентификатор назна-
ченного маршрутизатора (designated router) – DR.
– Резервный назначенный маршрутизатор. Поле содержит идентифика-
тор резервного назначенного маршрутизатора (backup designated router) –
BDR.
– Сосед. Поля содержат идентификаторы известных соседей данного
маршрутизатора.
8 бит
0 1 2 3 4 5 6 7

MBZ O DC EA N/P MC E T

Рисунок 10.5 – Структура поля Опции

177
Таблица 10.2 – Значения отдельных битов поля Опции

Бит Значение
MBZ Зарезервировано. Равно 0.
O Опция Opaque-LSA. RFC 2370.
DC Опция Demand Circuit. RFC 1793.
Опция External Attributes LSA, описана в работе Д. Фергюсона
«Сообщения LSA протокола OSPF с внешними атрибутами» (Fer-
EA
guson D., «The OSPF External Attribute LSA»). Опция имеет статус
в процессе разработки.
N/P Опция NSSA. RFC 1587.
MC Опция MOSPF. RFC 1584.
Опция ASBR. Указание на то, что маршрутизатор OSPF является
E
ASBR маршрутизатором.
T Опция ToS. Устаревшее. Равно 0.

10.4.2 Суммарная информация о таблице топологии

На рисунке 10.6 приводится формат пакета суммарной информации о


таблице топологии протокола OSPF.
32 бита
8 8 8 8

Заголовок пакета OSPF (Тип = 2)

MTU интерфейса Опции Флаги


Данные пакета OSPF

Порядковыйномер пакета

Заголовок LSA 1

Заголовок LSAN

Рисунок 10.6 – Формат DBD пакета

Пакет суммарной информации таблицы топологии протокола OSPF


включает следующие поля:
– MTU интерфейса. MTU интерфейса через который был отправлен па-
кет.
– Опции. Поле идентично полю в пакете приветствия.
– Флаги. Поле описывает служебные флаги пакета. Формат поля пред-
ставлен на рисунке 10.7. Значения битов поля приводятся в таблице 10.3.

178
– Порядковый номер пакета. Отправитель упорядочивает последова-
тельность всех пакетов с суммарной информацией таблицы топологии, а по-
лучатель подтверждает прием каждого пакета.
– Заголовок LSA. Заголовок LSA об известном топологическом элемен-
те. В пакете DBD может содержаться один или несколько заголовков LSA.
8 бит
0 1 2 3 4 5 6 7

0 0 0 0 0 I M MS

Рисунок 10.7 – Структура поля Флаги

Таблица 10.3 – Значения отдельных битов поля Флаги

Бит Значение
Бит инициализации. Установка бита означает, что передается пер-
I
вый пакет с описанием таблицы топологии.
Установка бита означает, что должны последовать другие пакеты
M с описанием таблицы топологии. Если бит M равен 0, то поступил
последний пакет.
Установка бита означает, что маршрутизатор является DR марш-
MS
рутизатором.

10.4.3 Запрос на получение информации о топологическом элементе

На рисунке 10.8 приводится формат пакета запроса на получение ин-


формации о топологическом элементе протокола OSPF.
32 бита
8 8 8 8

Заголовок пакета OSPF (Тип = 3)

Тип LSA
Запрос LSA 1

Идентификатор LSA
Данные пакета OSPF

Заявивший маршрутизатор

Тип LSA
Запрос LSA N

Идентификатор LSA

Заявивший маршрутизатор

Рисунок 10.8 – Формат LSR пакета

179
Пакет запроса на получение информации о топологическом элементе
протокола OSPF включает следующие поля:
– Тип LSA. Тип запрашиваемого LSA.
– Идентификатор LSA. Уникальный идентификатор записи LSA.
– Заявивший маршрутизатор. Уникальный идентификатор маршрутиза-
тора, которым был заявлен LSA.
В пакете LSR может содержаться одна или несколько троек полей опи-
сывающих требуемые LSA.

10.4.4 Обновление информации о топологических элементах

32 бита
8 8 8 8

Заголовок пакета OSPF (Тип = 4)


Данные пакета OSPF

Количество LSA

LSA 1

LSAN

Рисунок 10.9 – Формат LSU пакета

На рисунке 10.9 приводится формат пакета обновления информации о


топологическом элементе протокола OSPF.
Пакет обновления информации о топологических элементах протокола
OSPF включает следующие поля:
– Количество LSA. Число записей LSA которое содержится в пакете.
– LSA. Информация о топологическом элементе. В пакете LSU может
содержаться один или несколько LSA.

10.4.5 Подтверждение о получении

На рисунке 10.10 приводится формат пакета подтверждения о получе-


нии топологической информации протокола OSPF.

180
32 бита
8 8 8 8

Заголовок пакета OSPF (Тип = 5)

Данные пакета OSPF


Заголовок LSA 1

Заголовок LSAN

Рисунок 10.10 – Формат LSAck пакета

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


ции состоят из полей с заголовками тех LSA, получение которых подтвержда-
ется.

10.5 Процесс установки соседских отношений

Соседские отношения между маршрутизаторами устанавливаются в


случае, если оба маршрутизатора принадлежат одной и той же зоне. Во время
процесса установки соседских отношений маршрутизаторы OSPF последова-
тельно проходят следующие семь состояний:
– Нерабочее (Down);
– Инициализация (Init);
– Двунаправленные отношения (Two-Way);
– Выборы DR и BDR (Exstart);
– Обмен (Exchange);
– Загрузка (Loading);
– Полные соседские отношения (Full).
В зависимости от типа канала связи между маршрутизаторами, процесс
установки соседских отношений может не содержать некоторые из этапов.
Подробно об этом будет рассказано в разделе 12.
Процесс установки соседских отношений можно разбить на две основ-
ных части:
– Поиск соседей;
– Обмен топологической информацией.

10.5.1 Поиск соседей

На рисунке 10.11 приводиться пример процесса поиска соседей марш-


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

181
10.1.1.0/30

R1 Down R2
Hello
Hello

D:224 .0.0.5
RID:10.0.0.1 D:224 .0.0.5
Area :1 RID:10.0.0.2
Area :1
Init

Hello
Hello

D:224 .0.0.5
Таблицасоседства Таблицасоседства
RID:10.0.0.1 D:224 .0.0.5
Area :1 RID:10.0.0.2
Nei :10.0.0.2 Area :1
Nei :10.0.0.1
Two-Way

BDR DR

Exstart

Рисунок 10.11 – Поиск соседей в протоколе OSPF

1. После запуска процесса маршрутизации OSPF на маршрутизаторе R1,


с него начинается производиться рассылка Hello пакетов со всех интерфейсов
участвующих в процессе маршрутизации OSPF. Рассылка Hello пакетов
производиться по групповому адресу 224.0.0.5, одновременно с рассылкой
пакетов маршрутизатор начинает прослушивать все интерфейсы, участвую-
щие в процессе маршрутизации, на предмет получения Hello пакетов от со-
седних OSPF маршрутизаторов.
2. После получения Hello пакета от соседнего маршрутизатора R2,
маршрутизатор R1 узнает о его существовании и добавляет его идентифика-
тор в Hello пакет в поле известных соседей. После этого производится рас-
сылка измененных Hello пакетов. Маршрутизатор R2 производит те же самые
действия.
3. После получения маршрутизатором R1 от маршрутизатора R2 Hello
пакета, в котором находится его идентификатор в поле известных маршрути-
затору R2 соседей, маршрутизатор R1 вносит маршрутизатор R2 в таблицу
соседей и между маршрутизаторами устанавливаются двунаправленные со-
седские отношения.
4. После установки двунаправленных соседских отношений маршрути-
заторам R1 и R2 необходимо произвести выборы DR и BDR маршрутизато-
ров, так как они включены в широковещательный сегмент Ethernet.
Стоит отметить, что во время выборов DR и BDR маршрутизаторов об-
мена данными между маршрутизаторами не происходит. Назначение DR и
BDR маршрутизаторов происходит на основании уже полученной во время
установки соседских отношений информации из Hello пакетов.

182
Для выбора DR и BDR маршрутизаторов рассматриваются два парамет-
ра:
– Приоритет маршрутизатора;
– Идентификатор маршрутизатора.
Сначала маршрутизаторы рассматривают приоритеты маршрутизато-
ров, а затем идентификатор маршрутизатора. Маршрутизатор с наивысшим
приоритетом становиться DR маршрутизатором, маршрутизатор со следую-
щим после него значением приоритета становиться BDR маршрутизатором.
Если же все маршрутизаторы имеют одинаковые значения приоритета, то DR
маршрутизатором становиться маршрутизатор с наивысшим значением иден-
тификатора, а маршрутизатор со следующим по значению RID соответствен-
но BDR маршрутизатором.

10.5.2 Обмен топологической информацией

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


меняться известной им топологической информацией. Процесс обмена топо-
логической информацией представлен на рисунке 10.12.

10.1.1.0/30

R1 R2
DBD
DBD

Exchange

LSR
LSR

LSU
LSU

Loading

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

Full

Таблица Таблица
маршрутизации маршрутизации

Рисунок 10.12 – Обмен топологической информацией в протоколе OSPF

183
1. Маршрутизаторы R1 и R2 обмениваются DBD пакетами. После полу-
чения DBD пакета с соседнего маршрутизатора R1 просматривает информа-
цию о LSA известных соседу, и сравнивает ее со своей таблицей топологии.
2. После просмотра DBD пакетов и сравнения их со своими таблицами
топологии, маршрутизаторы R1 и R2 обмениваются пакетами LSR в которых
содержаться запросы на получение LSA неизвестных маршрутизатору, но из-
вестных его соседу.
3. После получения LSR пакетов маршрутизаторы производят обмен па-
кетами LSU содержащими затребованные LSA. Получение каждого LSU под-
тверждается отправкой пакетов SLAck. После синхронизации маршрутизато-
рами своих таблиц топологии, они устанавливают между собой полные сосед-
ские отношения.
Затем маршрутизаторы могут произвести запуск алгоритма SPF для рас-
чета своих таблиц маршрутизации.

184
11 Настройка протокола OSPF в одной зоне

11.1 Запуск протокола OSPF

Для запуска протокола OSPF используется команда router ospf process-


id. Параметр process-id представляет собой номер локального процесса марш-
рутизации OSPF запущенного на маршрутизаторе. Параметр process-id имеет
лишь локальное значение и может не совпадать на маршрутизаторах принад-
лежащих зоне или домену маршрутизации OSPF. Однако в современных се-
тях передачи данных на маршрутизаторах может быть запущено несколько
процессов маршрутизации OSPF, поэтому хорошим тоном считается исполь-
зовать один и тот же process-id на всех маршрутизаторах домена маршрутиза-
ции, на которых запущен один и тот же экземпляр маршрутизатора OSPF.
Для описания сетей участвующих в процессе маршрутизации использу-
ется команда network area.
Синтаксис команды network area для протокола OSPF приводится в при-
мере 11.1.

Пример 11.1 – Синтаксис команды network area


(config-router)# network network-number [wildcard-mask] area area-id
(config-router)# no network network-number [wildcard-mask] area area-id

Описание параметров команды network area приводиться в таблице


11.1.

Таблица 11.1 – Параметры команды network area

Параметр Описание
network-number Номер сети участвующей в процессе
маршрутизации OSPF.
wildcard-mask Обратная маска подсети для сети
участвующей в процессе маршрутиза-
ции OSPF.
area-id Номер зоны OSPF, которой принадле-
жит описанная сеть.

По значению пары network-number wildcard-mask маршрутизатор опре-


деляет, какие сети будут участвовать в процессе маршрутизации OSPF и че-
рез какие интерфейсы производить рассылку служебных пакетов. По умолча-
нию рассылка служебных пакетов производиться со всех интерфейсов, попа-
дающих в network-number wildcard-mask, поэтому не следует забывать о ко-

185
манде passive-interface для контроля интерфейсов, с которых производиться
рассылка служебной информации.
Параметр area-id определяет, к какой зоне будет отнесена описываемая
сеть.
Стоит подчеркнуть, что при использовании на маршрутизаторе
нескольких непрерывных подсетей относящихся к одной зоне протокола
OSPF, в процессе маршрутизации не стоит описывать каждую сеть в отдель-
ности, а можно описать сеть с суммарной wildcard-mask. Для работы процесса
маршрутизации не имеет значения, используются суммарные или частные
wildcard-mask, в независимости от этого, топологическая информация будет
распространяться о частных подсетях. Использование суммарных wildcard-
mask уменьшает количество строк конфигурации маршрутизатора, тем са-
мым, упрощая процесс ее восприятия администратором сети.
В последних версиях ОС IOS при задании сетей в процесс маршрутиза-
ции OSPF есть возможность автоматического преобразования масок подсетей
в wildcard-mask, При описании сети можно использовать маски подсети, а в
конфигурационный файл маршрутизатора будут внесены требуемые сети с
соответствующими wildcard-mask.
В версиях IOS начиная с 12.3(11)T появилась возможность запуска про-
цесса маршрутизации OSPF на конкретном интерфейсе, без запуска глобаль-
ного процесса маршрутизации OSPF. Для запуска процесса OSPF на выбран-
ном интерфейсе используется команда ip ospf area. Синтаксис команды при-
водиться в примере 11.2.

Пример 11.3 – Синтаксис команды ip ospf area


(config-if)# ip ospf process-id area area-id [secondaries none]
(config-if)# no ip ospf process-id area area-id [secondaries none]

Описание параметров команды ip ospf area приводиться в таблице 11.2.

Таблица 11.2 – Параметры команды ip ospf area

Параметр Описание
process-id Номер локального процесса маршру-
тизации OSPF.
area-id Номер зоны OSPF, к которой принад-
лежит описанный на интерфейсе IP ад-
рес.
secondaries none Запрет на объявление в процесс марш-
рутизации OSPF вторичный IP адресов
настроенных на интерфейсе.

186
Команда ip ospf area имеет больший приоритет, чем команда network
area. Применение данной команды может быть полезно, если на маршрутиза-
торе необходимо разрешить процесс маршрутизации OSPF только на одном
интерфейсе, либо в том случае если необходимо что бы выбранный интер-
фейс принадлежал другой зоне протокола OSPF.
Как говорилось ранее, метрика протокола OSPF напрямую зависит от
ширины полосы пропускания канала связи. Поэтому, особенно на последова-
тельных интерфейсах, необходимо вручную задать пропускную способность
канала. Если значение пропускной способности для таких интерфейсов не ме-
нять, протокол OSPF будет считать, что пропускная способность канала равна
T1. Если канал работает медленнее, маршрутизатор будет производить непра-
вильный расчет метрик маршрутов. Для задания справочной скорости на ка-
нале связи используется команда bandwidth. Синтаксис команды bandwidth
приводится в примере 11.3.

Пример 11.3 – Синтаксис команды bandwidth


(config-if)# bandwidth kbps

Значение kbps определяет задаваемую пропускную способность в кило-


битах в секунду. Для топологий типа «Точка-Точка», таких как РРР или
HDLC, пропускная способность устанавливается равной скорости линии. Для
интерфейсов типа «Точка-Точка» Frame Relay пропускная способность уста-
навливается равной согласованной скорости передачи информации (Commit-
ted Information Rate – CIR). Для многоточечных каналов это значение устанав-
ливается равным сумме всех значений CIR на данном интерфейсе.
Стоит обратить особенное внимание, что скорость канала, задаваемая
командой bandwidth, является только справочной, и ни как не влияет на ре-
альную скорость передачи данных по каналу связи. Часто сетевые админи-
страторы задают на каналах справочные скорости меньше или больше реаль-
ных с целью того, чтобы маршрут через этот канал становился менее или нао-
борот более привлекательным с точки зрения протокола OSPF.
В протоколе OSPF существует альтернативная возможность задания
метрики маршрута через определенный интерфейс. При помощи команды ip
ospf cost можно вручную установить стоимость выбранного интерфейса. Син-
таксис команды ip ospf cost приводится в примере 11.4

Пример 11.4 – Синтаксис команды ip ospf cost


(config-if)# ip ospf cost interface-cost

Значение interface-cost задает стоимость канала для протокола OSPF,


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

187
Также рекомендуется в настройках процесса маршрутизации использо-
вать команду log-adjacency-change. При использовании данной команды фик-
сируются события связанные с переходом соседних маршрутизаторов из со-
стояния DOWN в состояние FULL и наоборот.
При использовании команды с ключом detail фиксируются все состоя-
ния соседних маршрутизаторов с которыми установлены и поддерживаются
соседские отношения. В последних версиях IOS данная команда включена по
умолчанию.
Пример вариантов настройки протокола OSPF приводится на рисунке
11.1.

r2# r3#
router ospf 1 interface Serial 1
network 10.0.0.0 0.255.255.255 area 0 ip address 10.1.1.6 255.255.255.252
log-adjacency-change ip ospf 1 area 0

E1 10.1.1.0/30 10.1.1.4/30 S1
RIP
E0 S0
R2 R1 R3

r1#
router ospf 1
network 10.1.1.0 0.0.0.7 area 0
log-adjacency-change

Рисунок 11.1 – Пример настройки протокола OSPF

11.2 Управление значением идентификатора маршрутизатора OSPF

Для процесса маршрутизации OSPF идентификатор маршрутизатора


(RID) является очень важным параметром. Идентификатор маршрутизатора
применяется в алгоритмах работы протокола OSPF для однозначной иденти-
фикации маршрутизатора.
Идентификатор маршрутизатору назначается при запуске процесса
OSPF. Идентификатором маршрутизатора может быть назначен:
– Старший IP адрес любого физического интерфейса маршрутизатора.
Интерфейс может не использоваться в процессе OSPF маршрутизации, но он
должен находиться в активном состоянии. Поэтому на маршрутизаторе при
запуске процесса OSPF должен быть активен хотя бы один интерфейс, иначе
маршрутизатор выдаст ошибку, представленную в примере 11.6 и процесс не
будет запущен.
– Старший IP адрес логического интерфейса loopback. Логические ин-
терфейсы всегда находиться в активном состоянии, поэтому использование
логического интерфейса является наиболее предпочтительным.
– Вручную. Для ручного задания RID используется команда router-id.

188
Самым высоким приоритетом при назначении идентификатора облада-
ет ручная настройка, самым низким старший адрес физического интерфейса.
Синтаксис команды router-id приводится в примере 11.5

Пример 11.5 – Синтаксис команды router-id


(config-router)# router-id ip-address
(config-router)# no router-id ip-address

В качестве параметра команды router-id может выступать IP адрес либо


число, записанное в формате IP адреса.
Однажды заданный идентификатор активен все время работы процесса
маршрутизации OSPF. Если во время работы маршрутизатора интерфейс, ад-
рес которого используется в качестве RID, переходит в неактивное состояние,
идентификатор маршрутизатора не изменяется. Однако при использовании
адресов физических интерфейсов в качестве идентификатора маршрутизатора
нельзя гарантировать, что после перезагрузки маршрутизатора будет назна-
чен тот же идентификатор, что был ранее. Идентификатор маршрутизатора
также переназначается при перезапуске процесса маршрутизации OSPF.
Исходя из этого использование логических интерфейсов предпочти-
тельнее, во-первых, логический интерфейс всегда активен, во-вторых, он мо-
жет быть объявлен в процесс маршрутизации, что позволит использовать ping
с других маршрутизаторов, чтобы проверять наличие связи между маршрути-
заторами.
При назначении RID, используя команду router-id, на идентификатор
нельзя будет послать ping.
Еще одним плюсом использования реальных IP адресов, будь то адреса
физических или логических интерфейсов является возможность применения
команды ip ospf name-lookup. Данная команда вводится в режиме глобальной
конфигурации маршрутизатора и позволяет при выводе информации содер-
жащей RID заменять его числовое значение DNS именем. Это позволяет
упростить администратору СПД идентифицировать маршрутизаторы OSPF.
При первоначальной конфигурации идентификатора маршрутизатора с
помощью команды router-id необходимо перезапустить процесс маршрутиза-
ции OSPF, используя команду clear ip ospf process. В дальнейшем при переза-
грузках маршрутизатора идентификатор, заданный командой router-id будет
назначаться автоматически.
Стоит обратить внимание, что если во время запуска процесса OSPF
операционная система не сможет назначить маршрутизатору RID. Например,
по причине того, что в этот момент у маршрутизатора не будет ни одного ак-
тивного интерфейса, и в конфигурационном файле будет отсутствовать вруч-
ную заданный идентификатор. Процесс маршрутизации OSPF запущен не бу-
дет, а операционная система выдаст сообщение об ошибке представленное в
примере 11.6.

189
Пример 11.6 – Ошибка назначения RID
%OSPF-4-NORTRID: OSPF process [dec] cannot start. There must be at least one
"up" IP interface, for OSPF to use as router ID

11.3 Настройка аутентификации в протоколе OSPF

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


рых аутентифицируется только часть служебных пакетов, в протоколе OSPF
поле аутентификации вынесено в заголовок служебного пакета, что делает
возможным аутентифицировать каждый служебный пакет протокола OSPF.
Данная возможность делает протокол OSPF более защищенным от нежела-
тельного воздействия по сравнению с рассмотренными ранее протоколами
маршрутизации.
Как и другие протоколы маршрутизации, протокол OSPF поддерживает
два типа аутентификации:
– Аутентификация по паролю;
– Аутентификация при помощи MD5.
Оба типа аутентификации настраиваются отдельно на каждом интер-
фейсе маршрутизатора, на котором запущен протокол OSPF.
Для задания типа аутентификации используется команда ip ospf authen-
tication. Синтаксис команды ip ospf authentication приводится в примере 11.7.

Пример 11.7 – Синтаксис команды ip ospf authentication


(config-if)# ip ospf authentication [message-digest | null]
(config-if)# no ip ospf authentication

Описание параметров команды ip ospf authentication приводиться в та-


блице 11.3.

Таблица 11.3 – Параметры команды ip ospf authentication

Параметр Описание
message-digest Аутентификация с помощью MD5.
null Отсутствие аутентификации.

При использовании команды ip ospf authentication без параметров будет


использована аутентификация по паролю.
Для задания текстовой строки используемой при аутентификации по па-
ролю используется команда ip ospf authentication-key. Синтаксис команды ip
ospf authentication-key приводится в примере 11.8.

190
Пример 11.8 – Синтаксис команды ip ospf authentication-key
(config-if)# ip ospf authentication-key password
(config-if)# no ip ospf authentication-key

В качестве параметра команды ip ospf authentication-key выступает стро-


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

172 .10.1.0/30

S0 S1
R1 R2

r1# r2#
interface serial 0 interface serial 1
ip address 172.16.1.1 255 .255.255.252 ip address 172.16.1.2 255.255.255.252
ip ospf authentication ip ospf authentication
ip ospf authentication -key PassWord ip ospf authentication -key PassWord

Рисунок 11.2 – Аутентификация по паролю в протоколе OSPF

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


мощью MD5 используется команда ip ospf message-digest-key md5. Синтаксис
команды ip ospf message-digest-key md5 приводится в примере 11.9. Описание
параметров команды приводиться в таблице 11.4.

Пример 11.9 – Синтаксис команды ip ospf message-digest-key md5


(config-if)# ip ospf message-digest-key key-id encryption-type md5 key
(config-if)# no ip ospf message-digest-key key-id

Таблица 11.4 – Параметры команды ip ospf message-digest-key md5

Параметр Описание
key-id Номер используемого ключа.
encryption-type Тип вводимой строки:
0 нешифрованная строка;
7 шифрованная средствами IOS стро-
ка.
key Строка для аутентификации.

При использовании аутентификации с помощью MD5, на интерфейсе


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

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

172 .10.1.0/30

S0 S1
R1 R2

r1# r2#
interface serial 0 interface serial 1
ip address 172.16.1.1 255 .255.255.252 ip address 172.16.1.2 255.255.255.252
ip ospf authentication message -digest ip ospf authentication message -digest
ip ospf message-digest-key 1 md5 SeCrEt ip ospf message-digest-key 1 md5 SeCrEt

Рисунок 11.3 – Аутентификация с помощью MD5 в протоколе OSPF

11.3.1 Проверка функционирования аутентификации

На рисунке 11.4 приводятся сообщения об обнаруженных проблемах в


аутентификации по паролю.

r1#
interface ethernet 0
ip address 10.1.1.1 255.255.255.252
ip ospf authentication
ip ospf authentication -key PassWord
!
interface serial 0
ip address 10.1.1.5 255.255.255.252
ip ospf authentication
ip ospf authentication -key PassWord

r2# r3#
interface ethernet 1 interface Serial 1
ip address 10.1.1.2 255.255.255.252 ip address 10.1.1.6 255.255.255.252
ip ospf authentication
ip ospf authentication-key password

E1 10.1.1.0/30 10.1.1.4/30 S1

E0 S0
R2 R1 R3

r2# r3#
*Mar 2 08:13:15.562: OSPF: Rcv pkt from 10.1.1.1, *Mar 2 08:14:12.450: OSPF: Rcv pkt from 10.1.1.5,
Ethernet 1 : Mismatch Authentication Key - Clear Text Serial 1 : Mismatch Authentication type .
Input packet specified type 1, we use type 0

r1#
*Mar 2 08:14:12.450: OSPF: Rcv pkt from 10.1.1.6, Serial 0 : Mismatch Authentication type .
Input packet specified type 0, we use type 1

*Mar 2 08:15:42.450: OSPF: Rcv pkt from 10.1.1.2, Ethernet0 : Mismatch Authentication Key - Clear Text

Рисунок 11.4 – Сообщения об ошибках аутентификации по паролю

192
При корректно настроенной аутентификации соседних маршрутизато-
ров, они смогут установить между собой соседские отношения.
Если соседские отношения не устанавливаются необходимо воспользо-
ваться командой debug ip ospf events, которая выводит процесс установки со-
седских отношений между маршрутизаторами. В выводе данной команды бу-
дут присутствовать сообщения о неправильно настроенной аутентификации.
На рисунке 11.5 приводятся сообщения об обнаруженных проблемах в
аутентификации при помощи MD5.

r1# r2#
interface serial 0 interface serial 1
ip address 172.16.1.1 255 .255.255.252 ip address 172.16.1.2 255.255.255.252
ip ospf authentication message -digest ip ospf authentication message -digest
ip ospf message-digest-key 1 md5 SeCrEt ip ospf message-digest-key 0 md5 SeCrEt

172 .10.1.0/30

S0 S1
R1 R2

r1# r2#
*Mar 2 08:12:44.372: OSPF: Send with youngest Key 1 *Mar 2 08:19:52.332: OSPF: Send with youngest Key 0

*Mar 2 08:15:26.560: OSPF: Rcv pkt from 172.16.1.2, *Mar 2 08:19:52.460: OSPF: Rcv pkt from 172.16.1.1,
Serial 0: Mismatch Authentication Key - No message Serial 1: Mismatch Authentication Key - No message
digest key 0 on interface digest key 1 on interface

Рисунок 11.5 – Сообщения об ошибках аутентификации с помощью MD5

11.4 Настройка маршрута по умолчанию в протоколе OSPF

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


по умолчанию с главного маршрутизатора сети. Для включения механизма
рассылки маршрута по умолчанию на главном маршрутизаторе в сети необхо-
димо указать команду default-information originate. Синтаксис команды de-
fault-information originate приводится в примере 11.10.

Пример 11.10 – Синтаксис команды default-information originate


(config-router)# default-information originate [always] [metric metric-value]
[metric-type type-value] [route-map map-name]
(config-router)# no default-information originate

Описание параметров команды default-information originate приводиться


в таблице 11.5.

193
Таблица 11.5 – Параметры команды default-information originate

Параметр Описание
always Всегда распространять маршрут по
умолчанию, в независимости от алго-
ритмов автоматического назначения
маршрутов по умолчанию в протоколе
OSPF.
metric metric-value Метрика маршрута.
Значение по умолчанию 10.
metric-type type-value Тип внешнего маршрута:
1 – 1 тип внешнего маршрута;
2 – 2 тип внешнего маршрута.
Значение по умолчанию 2.
route-map map-name Указание процессу маршрутизации
распространять маршрут по умолча-
нию в том случае если выполняется
условие route-map.

Пример настройки маршрута по умолчанию в протоколе OSPF приво-


дится на рисунке 11.6

172 .16.14.0/27
R2

S0
172 .16.14.32/27 WAN
R3
R1

172 .16.14.64/27
R4
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
ip route 0.0.0.0 0.0.0.0 serial 0

Рисунок 11.6 – Настройка маршрута по умолчанию в протоколе OSPF

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

Как и другие протоколы динамической маршрутизации, протокол OSPF


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

194
В отличие от протокола EIGRP протокол OSPF не имеет возможности
производить распределение нагрузки по маршрутам с разной стоимостью.

11.6 Расширенная настройка протокола OSPF

11.6.1 Таймеры протокола OSPF

Протокол OSPF, как и протокол EIGRP не использует периодическую


рассылку маршрутной информации соседним маршрутизаторам. Однако для
поддержания соседских отношений между маршрутизаторами необходимо
периодически передавать Hello пакеты. При получении от соседа Hello пакета
маршрутизатор понимает, что сосед продолжает функционировать.
Исходя из этого, в протоколе OSPF существует два основных таймера:
– таймер рассылки Hello пакетов;
– таймер поддержания соседских отношений.
По умолчанию таймер рассылки Hello пакетов равняется 30 секундам
для сетей NBMA. Для всех остальных типов сетей интервал рассылки Hello
пакетов равен 10 секундам.
Время поддержания соседских отношений должно равняться не менее
четырем интервалам рассылки Hello пакетов, следовательно, для сетей NBMA
данный интервал равняется 120 секундам, а для всех остальных каналов связи
40 секундам.
При необходимости стандартные значения таймеров можно изменить,
используя команды ip ospf hello-interval и ip ospf dead-interval. Синтаксис ко-
манд приводится в примерах 11.11 и 11.12.

Пример 11.11 – Синтаксис команды ip ospf hello-interval


(config-if)# ip ospf hello-interval seconds
(config-if)# no ip ospf hello-interval

Пример 11.12 – Синтаксис команды ip ospf dead-interval


(config-if)# ip ospf dead-interval seconds
(config-if)# no ospf dead-interval

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


ректной работы протокола OSPF необходимо соблюдать соотношение тайме-
ров рассылки Hello пакетов и поддержания соседских отношений.
Еще одним важным таймером протокола OSPF является таймер повтор-
ной передачи записей LSA, получение которых не было подтверждено. По
умолчанию таймер повторной передачи записей LSA равняется 5 секундам.
При необходимости стандартное значение таймера можно изменить, исполь-

195
зуя команду ip ospf retransmit-interval. Синтаксис команды приводится в при-
мере 11.13.

Пример 11.13 – Синтаксис команды ip ospf retransmit-interval


(config-if)# ip ospf retransmit-interval seconds
(config-if)# no ospf retransmit-interval

Изменение данного параметра может понадобиться на высокоскорост-


ных каналах связи для улучшения временных характеристик сходимости сети
или на низкоскоростных каналах связи, где задержка при получении пакетов
LSAck может превышать значение по умолчанию.
Как известно максимальный возраст экземпляра сообщения LSA со-
ставляет 30 минут. По истечении этого времени маршрутизатор объявивший,
данное сообщение LSA, должен разослать обновленный экземпляр сообще-
ния. Для корректной работы протокола OSPF необходимо, что бы учитыва-
лось не только время нахождения сообщения LSA в таблице топологии, но и
время, затраченное на его передачу по каналам связи. Для этого в протокол
OSPF был внесен временной параметр, задающий время передачи сообщения
LSA по каналу связи. По умолчанию данный параметр равен 1 секунде. При
необходимости стандартное значение параметра можно изменить, используя
команду ip ospf transmit-delay. Синтаксис команды приводится в примере
11.14.

Пример 11.14 – Синтаксис команды ip ospf transmit-delay


(config-if)# ip ospf transmit-delay seconds
(config-if)# no ospf transmit-delay

11.6.2 Изменение административного расстояния протокола OSPF

По умолчанию административное расстояние протокола OSPF равняет-


ся 110.
В некоторых ситуациях, например во время перехода с некоторого про-
токола маршрутизации на протокол OSPF требуется на время подготовки дан-
ного перехода изменить административное расстояние протокола OSPF с це-
лью сделать его менее предпочтительным, чем старый протокол маршрутиза-
ции. Для этого используется команда distance ospf. Синтаксис команды при-
водится в примере 11.15.

Пример 11.15 – Синтаксис команды distance ospf


(config-router)# distance ospf {[intra-area dist1] [inter-area dist2] [extern-
al dist3]}
(config-router)# no distance ospf

196
Описание параметров команды distance ospf приводиться в таблице
11.6.

Таблица 11.6 – Параметры команды distance ospf

Параметр Описание
intra-area dist1 Административное расстояние внутри-
зональных маршрутов OSPF. По умол-
чанию 110.
inter-area dist2 Административное расстояние межзо-
нальных маршрутов OSPF. По умолча-
нию 110.
external dist3 Административное расстояние внеш-
них маршрутов OSPF. Под внешними
маршрутами понимаются маршруты,
полученные от других протоколов
маршрутизации.
По умолчанию 110.

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

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


могут быть использованы несколько команд. Наиболее часто используемыми
командами общего назначения являются show ip route и show ip protocols.
Команда show ip route или команда show ip route ospf отображает табли-
цу маршрутизации построенную маршрутизатором. Вторая команда отобра-
жает только маршруты из таблицы маршрутизации полученные от протокола
OSPF, такие маршруты помечаются буквой «O» (Пример 11.16).

Пример 11.16 – Таблица маршрутизации протокола OSPF


r3#show ip route ospf
10.0.0.0/8 is variably subnetted, 32 subnets, 3 masks
O 10.89.2.81/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O 10.89.1.81/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O 10.89.2.65/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O 10.89.1.65/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O 10.89.2.113/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O 10.89.1.113/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O 10.89.2.97/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O 10.89.1.97/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O 10.89.2.17/32 [110/196] via 10.93.2.2, 00:00:40, Serial1
O 10.89.1.17/32 [110/586] via 10.93.0.17, 00:00:40, Serial0

197
При вводе команды show ip protocols отображается информация обо
всех протоколах IP маршрутизации, в том числе и о протоколе OSPF, сконфи-
гурированных на маршрутизаторе (Пример 11.17).

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


r3#show ip protocols
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 10.95.0.49
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.0.0.0 0.255.255.255 area 0
Routing Information Sources:
Gateway Distance Last Update
10.95.0.1 110 00:00:20
10.95.0.49 110 00:00:20
10.95.0.61 110 00:00:20
10.95.0.57 110 00:00:20
10.95.0.33 110 00:00:20
10.95.0.45 110 00:00:20
10.95.0.41 110 00:00:20
Distance: (default is 110)

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


большинства параметров протокола OSPF. Ниже перечислены островные
отображаемые в выводе команды параметры конфигурации:
– Номер локального процесса маршрутизации OSPF;
– Идентификатор маршрутизатора;
– Число и виды зон OSPF, которым принадлежит маршрутизатор;
– Номера сетей и их принадлежность зонам анонсированных протоко-
лом OSPF;
– С какими маршрутизаторами установлены соседские отношения;
– Административное расстояние, назначенное протоколу OSPF.
Кроме команд применимых ко всем протоколам маршрутизации суще-
ствует ряд специальных команд, отображающих информацию протокола
OSPF. К такой информации относятся таблицы соседства и топологии, стати-
стическая информация о переданных и полученных служебных пакетах, ин-
формация о работе интерфейсов маршрутизатора по обработке служебных па-
кетов.
Для вывода таблицы соседства применяется команда show ip ospf neigh-
bors, синтаксис команды приводится в примере 11.18.

Пример 11.18 – Синтаксис команды show ip ospf neighbors


show ip ospf neighbors [interface][neighbor-id][detail]

198
Описание параметров команды приводиться в таблице 11.7.

Таблица 11.7 – Параметры команды show ip ospf neighbors

Параметр Описание
interface Вывод информации о соседях располо-
женных за интерфейсом
neighbor-id Вывод информации о соседе с указан-
ным идентификатором
detail Вывод расширенной информации о со-
седях

Информация, выводимая командой show ip ospf neighbors, а так же ее


описание приводилось в примере 10.1.
Наиболее интересной является информация, выводимая командой show
ip ospf neighbors detail, которая содержит полную информацию о соседях
OSPF (Пример 11.19).

Пример 11.19 – Полная информация о соседях OSPF


r4#show ip ospf neighbor detail
Neighbor 10.95.0.33, interface address 10.93.1.1
In the area 0 via interface Serial0
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x42
Dead timer due in 00:00:38
Neighbor is up for 00:04:51
Index 1/1, retransmission queue length 0, number of retransmission 1
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Neighbor 10.95.0.45, interface address 10.93.1.34
In the area 0 via interface FastEthernet0
Neighbor priority is 1, State is FULL, 6 state changes
DR is 10.93.1.34 BDR is 10.93.1.33
Options is 0x42
Dead timer due in 00:00:37
Neighbor is up for 00:04:42
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec

Ниже перечислены островные отображаемые в выводе команды пара-


метры соседских отношений между маршрутизаторами:
– Идентификатор соседа;
– Локальный интерфейс, через который доступен сосед;
– Номер зоны, которой принадлежит сосед;
– Приоритет соседа;

199
– Состояние соседских отношений и сколько раз они изменялись;
– Адреса DR и BDR маршрутизаторов;
– Опции, поддерживаемые соседом (только E);
– Время, оставшееся до разрыва соседских отношений;
– Время поддержания соседских отношений.
Для вывода таблицы топологии применяется команда show ip ospf data-
base, синтаксис команды приводится в примере 11.20.

Пример 11.20 – Синтаксис команды show ip ospf database


show ip ospf [process-id area-id] database
show ip ospf [process-id area-id] database [adv-router [ip-address]]
show ip ospf [process-id area-id] database [database-summary]
show ip ospf [process-id area-id] database [self-originate][link-state-id]
show ip ospf [process-id area-id] database [LSA-type] [link-state-id]
show ip ospf [process-id area-id] database [LSA-type] [link-state-id] [adv-
router [ip-address]]
show ip ospf [process-id area-id] database [LSA-type] [link-state-id] [self-
originate][link-state-id]

Таблица топологии для протокола OSPF является главным источником


информации, по которой маршрутизатор имеет возможность построить та-
блицу маршрутизации. Вывод полной таблицы топологии представляет очень
большой объем информации, поэтому команда show ip ospf database имеет
возможность выводить частичную информацию необходимую администрато-
ру СПД. Описание параметров команды приводиться в таблице 11.8.

Таблица 11.8 – Параметры команды show ip ospf database

Параметр Описание
process-id Вывод таблицы топологии процесса
маршрутизации OSPF.
area-id Вывод таблицы топологии зоны OSPF.
adv-router ip-address Вывод LSA, заявленных указанным
маршрутизатором.
database-summary Вывод суммарной топологической ин-
формации.
LSA-type Вывод таблицы топологии по их типу:
External – внешние LSA;
Network – LSA сети;
nssa-external – внешние LSA NSSA;
router – LSA маршрутизаторов;
summary – суммарные LSA.
link-state-id Вывод информации о указанном LSA.
self-originate Вывод собственных LSA.

200
Информация, выводимая командой show ip ospf database, а так же ее
описание приводилось в примере 10.2.
Информацию о параметрах работы протокола OSPF на маршрутизаторе
можно получить, воспользовавшись командой show ip ospf.
Статистическую информацию о количестве переданных и полученных
служебных пакетов можно посмотреть, используя команду show ip ospf traffic.
Синтаксис команды приводится в примере 11.21.

Пример 11.21 – Синтаксис команды show ip ospf traffic


show ip ospf [process-id] traffic [interface]

Информация, выводимая данной командой, содержит количество от-


правленных и полученных служебных пакетов OSPF за время работы процес-
са маршрутизации или за время прошедшее поле применения команды clear
ip ospf traffic (Пример 11.22).

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


r1#show ip ospf traffic
OSPF statistics:
Rcvd: 159054687 total, 0 checksum errors
158930565 hello, 40 database desc, 10 link state req
64212 link state updates, 59860 link state acks
Sent: 159273144 total
159140414 hello, 37 database desc, 11 link state req
92630 link state updates, 40052 link state acks
OSPF Router with ID (10.95.184.58) (Process ID 88)
OSPF queues statistic for process ID 88:
Hello queue size 0, no limit, drops 0, max size 4, max delay 235ms
Router queue size 0, limit 200, drops 0, max size 2, max delay 235ms
Output queue size 0, no limit, max size 3, max delay 25ms

Interface statistics:
Interface FastEthernet0/1
OSPF packets received/sent
Invalid Hellos DB-des LS-req LS-upd LS-ack Total
Rx: 0 39790618 6 2 15650 16959 39823235
Tx: 0 39785151 8 2 34989 11878 39832028

OSPF header errors


Length 0, Checksum 0, Version 0, Bad Source 0,
No Virtual Link 0, Area Mismatch 0, No Sham Link 0,
Self Originated 0, Duplicate ID 0, Hello 0,
MTU Mismatch 0, Nbr Ignored 0, LLS 0,
Unknown neighbor 0, Authentication 0,
OSPF LSA errors
Type 0, Length 0, Data 0, Checksum 0,

201
Summary traffic statistics for process ID 88:
Rcvd: 79538526 total, 0 errors
79466889 hello, 18 database desc, 5 link state req
37831 link state upds, 33783 link state acks, 0 invalid
Sent: 79650010 total
79570321 hello, 17 database desc, 5 link state req
55767 link state upds, 23900 link state acks, 0 invalid

Ниже перечислены островные отображаемые в выводе команды пара-


метры обмена служебными пакетами между маршрутизаторами:
– Общее количество полученных и переданных служебных пакетов
OSPF, а также общее количество пакетов различных типов;
– Информация по конкретному процессу OSPF:
– Статистическая информация об использовании очередей процессом
OSPF;
–Количество полученных и переданных служебных пакетов OSPF по
конкретному интерфейсу;
– Количество и типы ошибок в заголовках пакетов;
– Количество ошибок в сообщениях LSA;
–Количество полученных и переданных служебных пакетов процессом
OSPF.
Обобщенную информацию о запущенных процессах маршрутизации
OSPF можно посмотреть, воспользовавшись командой show ip ospf. Синтак-
сис команды приводится в примере 11.23.

Пример 11.23 – Синтаксис команды show ip ospf


show ip ospf [process-id]

Информация, выводимая командой show ip ospf, представлена в приме-


ре 11.24.

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


r1#show ip ospf traffic
Routing Process "ospf 88" with ID 10.0.0.1
Supports only single TOS(TOS0) routes
Supports opaque LSA
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
LSA group pacing timer 100 secs
Interface flood pacing timer 55 msecs
Retransmission pacing timer 100 msecs
Number of external LSA 0. Checksum Sum 0x0
Number of opaque AS LSA 0. Checksum Sum 0x0
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
External flood list length 0

202
Area BACKBONE(0)
Number of interfaces in this area is 2
Area has message digest authentication
SPF algorithm executed 4 times
Area ranges are
Number of LSA 4. Checksum Sum 0x29BEB
Number of opaque link LSA 0. Checksum Sum 0x0
Number of DCbitless LSA 3
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
Area 1
Number of interfaces in this area is 0
Area has no authentication
SPF algorithm executed 1 times
Area ranges are
192.168.0.0/16 Passive Advertise
Number of LSA 1. Checksum Sum 0x44FD
Number of opaque link LSA 0. Checksum Sum 0x0
Number of DCbitless LSA 1
Number of indication LSA 1
Number of DoNotAge LSA 0
Flood list length 0

Как говорилось ранее, в протоколе OSPF при внесении некоторых изме-


нений в конфигурацию процесса маршрутизации, требуется производить пе-
резапуск процесса маршрутизации OSPF. Для этого используется команда
clear ip ospf. Синтаксис команды приводится в примере 11.25.

Пример 11.25 – Синтаксис команды clear ip ospf


clear ip ospf [pid] {process | redistribution | counters [neighbor [neighbor-
interface][neighbor-id]] | traffic [interface-type interface-number]}

Описание параметров команды clear ip ospf приводиться в таблице 11.9.

Таблица 11.9 – Параметры команды clear ip ospf

Параметр Описание
pid Номер процесса маршрутизации, для
которого будут производиться дей-
ствия.
process Перезапуск процесса OSPF.
redistribution Очистка перераспределения произво-
димого процессом маршрутизации
OSPF.
counters Очистка счетчиков протокола OSPF.
neighbor Отчистка статистики о соседях.
neighbor-interface Отчистка статистики о соседях за ин-
терфейсом.

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

Параметр Описание
neighbor-id Отчистка статистики о соседе.
traffic Отчистка статистики служебного тра-
фика протокола OSPF.
interface-type interface-number Отчистка статистики служебного тра-
фика прошедшему через выбранный
интерфейс.

В набор инструментов для отладки работы протокола OSPF запущенно-


го на маршрутизаторе также входит ряд команд debug.
Для вывода информации о событиях в работе протокола OSPF, таких
как получение и отправка Hello пакетов, обмен топологической информацией,
запуск алгоритма SPF и других служебных событий используется команда de-
bug ip ospf events. Информация, выводимая данной командой, представлена в
примере 11.26.

Пример 11.26 – Информация, выводимая командой debug ip ospf events


r2#debug ip ospf events
*Jun 10 15:15:47.831 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on FastEther-
net0/0.301 from 172.16.0.33
*Jun 10 15:15:49.923 KRSK: OSPF: Rcv hello from 3.3.3.3 area 1 from FastEther-
net0/0.301 172.16.0.34
*Jun 10 15:15:49.923 KRSK: OSPF: End of hello processing
*Jun 10 15:15:57.831 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/1
from 10.93.1.1
*Jun 10 15:15:59.591 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/0
from 172.16.0.2
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv hello from 1.1.1.1 area 1 from
Serial0/0/0 172.16.0.1
*Jun 10 15:15:59.595 KRSK: OSPF: Send immediate hello to nbr 1.1.1.1, src ad-
dress 172.16.0.1, on Serial0/0/0
*Jun 10 15:15:59.595 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/0
from 172.16.0.2
*Jun 10 15:15:59.595 KRSK: OSPF: End of hello processing
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv hello from 1.1.1.1 area 1 from
Serial0/0/0 172.16.0.1
*Jun 10 15:15:59.595 KRSK: OSPF: 2 Way Communication to 1.1.1.1 on
Serial0/0/0, state 2WAY
*Jun 10 15:15:59.595 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x183
opt 0x52 flag 0x7 len 32
*Jun 10 15:15:59.595 KRSK: OSPF: End of hello processing
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x966
opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Jun 10 15:15:59.599 KRSK: OSPF: First DBD and we are not SLAVE
*Jun 10 15:15:59.599 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x183
opt 0x52 flag 0x2 len 232 mtu 1500 state EXSTART
*Jun 10 15:15:59.599 KRSK: OSPF: NBR Negotiation Done. We are the MASTER

204
*Jun 10 15:15:59.599 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x184
opt 0x52 flag 0x3 len 232
*Jun 10 15:15:59.603 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x184
opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*Jun 10 15:15:59.603 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x185
opt 0x52 flag 0x1 len 32
*Jun 10 15:15:59.607 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x185
opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*Jun 10 15:15:59.607 KRSK: OSPF: Exchange Done with 1.1.1.1 on Serial0/0/0
*Jun 10 15:15:59.607 KRSK: OSPF: Synchronized with 1.1.1.1 on Serial0/0/0,
state FULL
*Jun 10 15:15:59.607 KRSK: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on
Serial0/0/0 from LOADING to FULL, Loading Done
*Jun 10 15:15:59.923 KRSK: OSPF: Rcv hello from 3.3.3.3 area 1 from FastEther-
net0/0.301 172.16.0.34
*Jun 10 15:15:59.923 KRSK: OSPF: End of hello processing
*Jun 10 15:16:00.091 KRSK: OSPF: Rcv LS UPD from 1.1.1.1 on Serial0/0/0 length
124 LSA count 1
*Jun 10 15:16:00.095 KRSK: OSPF: Rcv LS UPD from 3.3.3.3 on
FastEthernet0/0.301 length 124 LSA count 1

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


ских отношений используется команда debug ip ospf adj. Информация, выво-
димая командой, представлена в примере 11.27.

Пример 11.27 – Информация, выводимая командой debug ip ospf adj


r2#debug ip ospf adj
01:01:23: OSPF: Interface Serial0 going Up
01:01:23: OSPF: Build router LSA for area 0, router ID 10.95.0.33, seq
0x80000005
01:01:24: %LINEPROTO–5–UPDOWN: Line protocol on Interface Serial0, changed
state to up
01:01:33: OSPF: 2 Way Communication to 10.95.0.1 on Serial0, state 2WAY
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15DE opt 0x42 flag 0x7
len 32
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x1A29 opt 0x52 flag 0x7
len 32 mtu 1500 state EXSTART
01:01:33: OSPF: First DBD and we are not SLAVE
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15DE opt 0x52 flag 0x2
len 212 mtu 1500 state EXSTART
01:01:33: OSPF: NBR Negotiation Done. We are the MASTER
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15DF opt 0x42 flag 0x3
len 212
01:01:33: OSPF: Database request to 10.95.0.1
01:01:33: OSPF: sent LS REQ packet to 172.16.0.1, length 12
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15DF opt 0x52 flag 0x0
len 32 mtu 1500 state EXCHANGE
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15E0 opt 0x42 flag 0x1
len 32
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15E0 opt 0x52 flag 0x0
len 32 mtu 1500 state EXCHANGE
01:01:33: OSPF: Exchange Done with 10.95.0.1 on Serial0
01:01:33: OSPF: Synchronized with 10.95.0.1 on Serial0, state FULL
01:01:33: %OSPF–5–ADJCHG: Process 1, Nbr 10.95.0.1 on Serial0 from LOADING to
FULL, Loading Done

205
Для вывода информации о приеме или передачи служебных пакетов
OSPF используется команда debug ip ospf packet. Данная команда отображает
краткую информацию о приеме или получении служебного пакета протокола
OSPF. Информация, выводимая командой, представлена в примере 11.28.

Пример 11.28 – Информация, выводимая командой debug ip ospf packet


r2#debug ip ospf packet
01:19:49: OSPF: rcv. v:2 t:1 l:48 rid:10.95.0.45
aid:0.0.0.0 chk:CF99 aut:0 auk: from FastEthernet0
01:19:50: OSPF: rcv. v:2 t:1 l:48 rid:10.95.0.33
aid:0.0.0.0 chk:E6A2 aut:0 auk: from Serial0

Описание информации, выводимой командой debug ip ospf packet, при-


водится в таблице 11.10.

Таблица 11.10 – Описание информации выводимой командой debug ip


ospf packet

Информация Описание
v: Версия пакета.
t: Тип пакета.
l: Длина пакета.
rid: Идентификатор отправителя.
aid: Идентификатор зоны.
chk: Контрольная сумма.
aut: Тип аутентификации.
auk: Ключ аутентификации.
keyid: Идентификатор ключа MD5.
seq: Последовательный номер.

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


кола OSPF, является команда debug ip ospf spf statistic. Команда выводит ста-
тистическую информацию, работы алгоритма SPF (Пример 11.29).

Пример 11.29 – Информация, выводимая командой debug ip ospf spf stat-


istic
r2#debug ip ospf spf statistic
*Mar 6 00:27:27.136: OSPF: Begin SPF at 431519.513ms, process time 848ms
*Mar 6 00:27:27.136: spf_time 4d23h, wait_interval 5000ms
*Mar 6 00:27:27.136: OSPF: End SPF at 431519.513ms, Total elapsed time 0ms
*Mar 6 00:27:27.136: Intra: 0ms, Inter: 0ms, External: 0ms
*Mar 6 00:27:27.140: R: 1, N: 1, Stubs: 1
*Mar 6 00:27:27.140: SN: 0, SA: 0, X5: 0, X7: 0
*Mar 6 00:27:27.140: SPF suspends: 0 intra, 0 total

206
Описание информации выводимой командой debug ip ospf spf statistic
приводится в таблице 11.11.

Таблица 11.11 – Описание информации выводимой командой debug ip


ospf spf statistic

Информация Описание
Begin SPF at Абсолютное время запуска SPF.
process time Среднее время работы процесса SPF.
spf_time Время, прошедшее с предыдущего
запуска SPF.
wait_interval Время ожидания перед началом расче-
та SPF.
End SPF at Абсолютное время остановки SPF.
Total elapsed time Время, потребовавшееся для запуска
SPF.
Intra Время, затраченное на расчет внутри-
зональных LSA.
Inter Время, затраченное на расчет межзо-
нальных LSA.
External Время, затраченное на расчет внешних
LSA.
R Число LSA – маршрутизаторы.
N Число LSA – сети.
Stub Число LSA – тупиковые связи.
SN Число LSA – суммарные.
SA Число LSA – на внешние AS.
X5 Число LSA – тип 5.
X7 Число LSA – тип 7.
SPF suspends intra Число «зависаний» процесса SPF во
время внутризональных запусков.
total Общее число «зависаний» процесса
SPF.

207
12 Работа протокола OSPF в сетях различных типов

Алгоритмы функционирования протокола OSPF во многом зависят от


типа сети передачи данных, в которой он запущен. Для протокола OSPF вы-
деляют три основных типа сети:
– Сеть «Точка-Точка»;
– Широковещательная сеть;
– Сеть NBMA.

12.1 Работа протокола OSPF в сетях «Точка-Точка»

Сеть «Точка-Точка» состоит из единственной пары маршрутизаторов. В


качестве примера сетей «Точка-Точка» можно привести выделенные каналы
связи с настроенными протоколами транспортного уровня PPP или HDLC
(Рисунок 12.1).

R1 R2 R3

Рисунок 12.1 – Пример сети «Точка-Точка» в протоколе OSPF

С точки зрения протокола OSPF сети «Точка-Точка» являются самыми


простыми для их представления в общей топологии сети передачи данных. В
таких сетях маршрутизаторы автоматически определяют своего соседа, ис-
пользуя групповую рассылку Hello пакетов по адресу 224.0.0.5. Каждая пара
маршрутизаторов имеет непосредственное соединение между собой, поэтому
нет необходимости проводить выборы DR и BDR маршрутизаторов.
В качестве IP адреса источника в пакет OSPF записывается IP адрес вы-
ходного интерфейса маршрутизатора. Возможно, использование ненумеро-
ванных интерфейсов при этом в качестве IP адреса источника будет высту-
пать адрес интерфейса маршрутизатора, который был указан в команде ip un-
numbered interface.
По умолчанию в протоколе OSPF для сетей «Точка-Точка» устанавли-
ваются Hello и Dead интервалы равные 10 и 40 секунд соответственно.

208
12.2 Работа протокола OSPF в широковещательных сетях

Для широковещательных сетей типа Ethernet или Token Ring протокол


OSPF модифицирует алгоритм обмена служебными пакетами между маршру-
тизаторами с целью его уменьшения. В отличие от протоколов RIP или EI-
GRP, в которых каждая пара маршрутизаторов устанавливает и поддерживает
между собой соседские отношения в независимости от типа сети, в протоколе
OSPF каждый маршрутизатор устанавливает полные отношения соседства
только с DR и BDR маршрутизаторами, выбранными внутри широковеща-
тельного сегмента. С остальными маршрутизаторами внутри сегмента под-
держиваются двухсторонние соседские отношения, при которых не происхо-
дит обмена служебными пакетами, содержащими топологическую информа-
цию (Рисунок 12.2).

FULL

DR BDR

2WAY

Рисунок 12.2 – Пример широковещательного сегмента в протоколе OSPF

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


ры DR и BDR маршрутизаторов. После проведения выборов DR и BDR марш-
рутизаторов все остальные маршрутизаторы в сегменте сети устанавливают с
ними полные соседские отношения с целью синхронизации своих таблиц то-
пологии.
Пока активен DR маршрутизатор, BDR маршрутизатор не исполняет ни
каких функций кроме приема LSA пакетов от DR маршрутизатора с целью
поддержания своей таблицы топологии в актуальном состоянии. Обмен слу-
жебной информацией между DR и BDR маршрутизаторами происходит по
групповому адресу 224.0.0.6. Если по какой-либо причине DR маршрутизатор
становится недоступен, BRD маршрутизатор занимает его место и в широко-
вещательном сегменте сети производятся повторные выборы BDR маршрути-
затора. Использование в широковещательной сети DR и BDR маршрутизато-
ров вносит следующие улучшения в работу протокола OSPF:
– Уменьшение служебного трафика между маршрутизаторами. DR и
BDR маршрутизаторы выступают центральной точкой обмена топологиче-

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

12.2.1 Правила выбора DR и BDR маршрутизаторов

Процесс выбора DR и BDR маршрутизаторов приводится на рисунке


12.3.
Pri = 10 Pri = 5
RID = 1 RID = 5

DR BDR

Hello

R3 R4 R5
Pri = 5 Pri = 1 Pri = 0
RID = 2 RID = 3 RID = 4

Рисунок 12.3 – Процесс выбора DR и BDR маршрутизаторов

Выборы DR и BDR маршрутизаторов производятся в момент первона-


чальной установки соседских отношений по следующим правилам:
– Маршрутизатор с наибольшим приоритетом выбирается DR маршру-
тизатором;
– Маршрутизатор со вторым по величине приоритетом назначается
BDR маршрутизатором;
– Если маршрутизаторы имеют равный приоритет, то в качестве DR
маршрутизатора выбирается маршрутизатор с наибольшим RID, BDR марш-
рутизатором выбирается маршрутизатор со вторым по величине RID;
– Маршрутизатор, с приоритетом равным нулю, не принимает участия в
выборах DR и BDR маршрутизаторов;
– Если после выбора DR и BDR маршрутизаторов в сегмент сети добав-
ляется маршрутизатор с более высоким приоритетом или большим RID, то
повторные выборы не производятся;

210
– Повторные выборы производятся только после того как DR или BDR
маршрутизаторы становится недоступными.
Для обнаружения того, что DR маршрутизатор становится недоступ-
ным, BDR маршрутизатор использует таймер ожидания. Если за время ис-
течения таймера BDR маршрутизатор не получил Hello пакет от DR маршру-
тизатора, BDR маршрутизатор считает, что DR маршрутизатор стал недоступ-
ным и занимает его место. После этого в сегменте сети проводятся повторные
выборы BDR маршрутизатора.
Если маршрутизатор имеет два интерфейса подключенных к разным
сегментам сети, он может быть DR или BDR маршрутизатором в одном сег-
менте и простым маршрутизатором в другом. Для ручной настройки приори-
тетов маршрутизаторов используется команда ip ospf priority. Синтаксис ко-
манды приводится в примере 12.1.

Пример 12.1 – Синтаксис команды ip ospf priority


(config-if)# ip ospf priority [number]
(config-if)# no ip ospf priority [number]

Значение number задает приоритет маршрутизатора в приделах от 0 до


255, по умолчанию приоритет задается равным 1. По умолчанию в протоколе
OSPF для широковещательных сетей устанавливаются Hello и Dead интерва-
лы равные 10 и 40 секунд соответственно.

12.3 Работа протокола OSPF в сетях NBMA

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


ственный доступ, но в которых не применяются широковещательные пакеты.
К таким технологиям относятся сети Frame Relay, ATM и X25. Данные сети
получили название NBMA (non broadcast multi-access) (Рисунок 12.4).

Frame Relay
ATM
X.25

Рисунок 12.4 – Пример сети NBMA в протоколе OSPF

211
В сетях NBMA может быть больше двух маршрутизаторов подключен-
ных к одному логическому сегменту сети, но из-за отсутствия возможности
использования групповых пакетов в таких сетях маршрутизаторы не могут
проводить автоматический поиск соседей и установку с ними соседских отно-
шений.
В сетях NBMA для имитации групповой рассылки пакет копируется и
посылается индивидуально по каждому виртуальному каналу (VC). Такой ме-
ханизм сильно повышает загрузку маршрутизатора и каналов передачи дан-
ных.
По умолчанию в протоколе OSPF для сетей NBMA установлены Hello и
Dead интервалы равные соответственно 30 и 120 секунд.
Сети NBMA в большинстве случаев используют логическую топологию
«звезда», построенную при помощи постоянных (PVC) или коммутируемых
(SVC) виртуальных каналов, но физическая топология сети не поддерживает
групповую рассылку пакетов, которая используется протоколом OSPF, поэто-
му OSPF не может автоматически устанавливать соседские отношения между
маршрутизаторами в сетях NBMA.
Выбор DR и BDR маршрутизаторов в сетях NBMA невозможен, потому
что для проведения выборов DR и BDR маршрутизаторов все маршрутизато-
ры принадлежащие сегменту сети должны иметь логическое соединение.

12.4 Режимы работы протокола OSPF в сетях NBMA

В RFC2328 описываются два основных режима функционирования про-


токола OSPF в сетях NBMA:
– Нешироковещательный (Non broadcast). Режим эмулирует работу про-
токола OSPF для широковещательных сетей. Для данного режима работы
должны быть вручную настроены отношения соседства между маршрутизато-
рами и проведено назначение DR и BDR маршрутизаторов.
– Многоточечный (Point-to-multipoint). Режим рассматривает сеть как
совокупность каналов «Точка-Точка». В этой среде маршрутизаторы автома-
тически определяют своих соседей, но не производят выборы DR и BDR
маршрутизаторов.
Выбор между нешироковещательным и многоточечным режимом рабо-
ты определяет способ рассылки Hello пакетов и рассылки обновлений тополо-
гической информации по NBMA сети.
Главным преимуществом многоточечного режима является минималь-
ная потребность ручной настройки, а главным преимуществом неширокове-
щательного режима минимальное использование каналов связи.
Компанией Cisco были разработаны дополнительные режимы функцио-
нирования протокола OSPF в NBMA сетях неописанные в RFC:

212
– Нешироковещательный многоточечный режим. Этот режим позволяет
в многоточечном режиме статически задавать соседские отношения.
– Широковещательный режим. Интерфейс логически переводится в ши-
роковещательный режим и ведет себя, так как если бы маршрутизатор был бы
подключен к широковещательной сети. Требует применение полно-связной
топологии.
– Режим «Точка-Точка». Данный режим используется в тех случаях,
когда в сети NBMA требуется соединить пару маршрутизаторов.
Режим работы протокола OSPF в сети NBMA задается для конкретного
интерфейса при помощи команды ip ospf network. Синтаксис команды приво-
дится в примере 12.2.

Пример 12.2 – Синтаксис команды ip ospf network


(config-if)# ip ospf network {broadcast | non-broadcast | {point-to-multipoint
[non-broadcast] | point-to-point}}
(config-if)# no ip ospf network

Описание параметров команды приводиться в таблице 12.1.

Таблица 12.1 – Параметры команды ip ospf network

Параметр Описание
broadcast Применяет к интерфейсу характери-
стики широковещательной сети. Ис-
пользует групповую рассылку Hello
пакетов для автоматического опреде-
ления соседей. Производятся выборы
DR и BDR маршрутизаторов. Адреса
соседей выдаются из одной подсети.
Требуется полно-связная топология
сети.
non-broadcast Соседние маршрутизаторы должны
быть сконфигурированы вручную.
Производятся выборы DR и BDR
маршрутизаторов. DR и BDR маршру-
тизаторы должны быть соединены со
всеми остальными маршрутизаторами
сегмента. Адреса соседей выдаются из
одной подсети. Используется в частич-
но-связной топологии сети.

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

point-to-multipoint Использует групповую рассылку Hello


пакетов для автоматического опреде-
ления соседей. DR и BDR маршрутиза-
торы не выбираются. Адреса соседей
выдаются из одной подсети. Использу-
ется в частично связной топологии.
point-to-multipoint non-broadcast Соседние маршрутизаторы должны
быть сконфигурированы вручную. DR
и BDR маршрутизаторы не выбирают-
ся. Адреса соседей выдаются из одной
подсети.
point-to-point Алгоритм работы протокола OSPF со-
ответствует правилам работы в сетях
«Точка-Точка».

12.5 Режимы работы протокола OSPF в сетях Frame Relay

12.5.1 Нешироковешательный режим

В нешироковещательном режиме протокол OSPF эмулирует работу ши-


роковещательной сети в среде Frame Relay. Производятся выборы DR и BDR
маршрутизаторов, DR маршрутизаторы организуют рассылку обновлений то-
пологической информации по всему сегменту сети Frame Relay. Для автома-
тического определения соседей и выбора DR и BDR маршрутизаторов необ-
ходимо использование в сегменте сети полно-связной топологии.
Если маршрутизаторы включены с сеть с не полно-связной топологией,
они не могут автоматически произвести выборы DR и BDR маршрутизаторов.
Поэтому отношения соседства маршрутизаторов настраивается вручную,
причем DR и BDR маршрутизаторы должны быть соединены со всеми осталь-
ными соседями.
При использовании нешироковещательного режима все интерфейсы
маршрутизаторов подключенные к сегменту Frame Relay должны принадле-
жать одной подсети.
Для рассылки с нешироковешательного интерфейса DR маршрутизатор
скопирует пакету обновлений топологической информации на каждый PVC
настроенный на интерфейсе маршрутизатора. После этого копия обновления
посылается каждому соседнему маршрутизатору определенному на интер-
фейсе.

214
Для статической настройки соседских отношений между маршрутизато-
рами в сетях NBMA используется команда neighbor. Синтаксис команды при-
водится в примере 12.3.

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


(config-router)# neighbor ip-address [priority number] [poll-interval seconds]
[cost number] [database-filter all]
(config-router)# no neighbor ip-address [priority number] [poll-interval
seconds] [cost number] [database-filter all]

Описание параметров команды приводиться в таблице 12.2.

Таблица 12.2 – Параметры команды neighbor

Параметр Описание
ip-address IP соседнего маршрутизатора.
priority number Приоритет соседнего маршрутизатора.
По умолчанию приоритет равен 0.
poll-interval seconds Интервал времени по истечению, кото-
рого будет отправляться Hello пакеты,
если за время ожидания от соседа не
поступило ни одного пакета. В RFC
1247 рекомендовано устанавливать
данный интервал значительно
большим, чем Hello интервал. Значе-
ние по умолчанию 120 секунд.
cost number Метрика канала до соседнего маршру-
тизатора. Если параметр не указан, ис-
пользуется метрика, настроенная на
интерфейсе командой ip ospf cost. Для
сетей NBMA данный параметр не при-
меняется.
database-filter all Фильтр на исходящие LSA.

На рисунке 12.5 приводится пример статической настройки соседских


отношений между маршрутизаторами.

215
r2# router ospf 200
network 10.10.1.0 0.0.0.7 area 0
10.10.1.0/29 neighbor 10.10.1.1 priority 10
R2

r3# router ospf 200


network 10.10.1.0 0.0.0.7 area 0
neighbor 10.10.1.1 priority 10
R1(DR) R3

r1# router ospf 200


network 10.10.1.0 0.0.0.7 area 0
neighbor 10.10.1.2 priority 0
neighbor 10.10.1.3 priority 0

Рисунок 12.5 – Статическая настройка соседских отношений

При данной логической топологии сети Frame Relay только маршрути-


затор R1 может быть назначен DR маршрутизатором, так как он единствен-
ный имеет соединения со всеми остальными маршрутизаторами входящими в
сегмент Frame Relay, для этого ему назначается самый высокий приоритет. В
данном примере BDR маршрутизатор не назначается.
В сетях NBMA команда neighbor может использоваться только на DR и
BRD маршрутизаторах. В топологии «звезда» данная команда используется
только на центральном маршрутизаторе, являющемся для данной топологии
единственно возможным DR маршрутизатором. Это позволяет упростить на-
стройку маршрутизаторов, однако при этом инициировать установку сосед-
ских отношений смогут только DR и BDR маршрутизаторы. Применение ко-
манды neighbor на удаленных маршрутизаторах позволит им выступать ини-
циаторами установки соседских отношений, но при правильном задании при-
оритетов не позволит им занять место DR или BDR маршрутизаторов.

10.10.1.0/29
R2

10.10.1.8/30

S0 S1
R4 R1(DR) R3

r1# show ip ospf neighbor


Neighbor ID Pri State Dead Time Address Interface
10.10.1.2 0 FULL/DROTHER 00:00:32 10.10.1.2 Serial1
10.10.1.3 0 FULL/DROTHER 00:00:35 10.10.1.3 Serial1
10.10.1.10 1 FULL/- 00:00:18 10