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

М.В.
ДИБРОВ
МАРШРУТИЗАТОРЫ
Учебное пособие
Красноярск 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
EIGRP.................................................................................................................288
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 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 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 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

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

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

...
...
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
Математически доказано, что описанный алгоритм вычисляет крат-
чайшие пути между всеми парами вершин за конечный промежуток времени
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
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
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
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
R3 R1 R5

Сеть 1, расстояние =5 Сеть 1

R4
Рисунок 4.4 – Счет до бесконечности
Алгоритмы маршрутизации по вектору расстояния являются самокор-

ректирующимися, но проблема маршрутизации по кругу, прежде всего, тре-
бует разрешения ситуации со счетом до бесконечности. Чтобы исключить эту
длительную по времени проблему, в протоколах, использующих вектор рас-
стояния, бесконечность определяется как некоторое максимальное число. Это
число выражается в единицах метрики маршрутизации, например, в виде про-
стого количества переходов.
При таком подходе протокол маршрутизации позволит существовать
маршрутизации по кругу до тех пор, пока метрика не превысит максимально
допустимое значение.
71
Сеть 1, расстояние = 14
R2
R3 R1 R5

Сеть 1, расстояние = 12 Сеть 1

R4
Таблица маршрутизации
max метрика = 16
Рисунок 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
R3 R1 R5
Сеть 1 ... Сеть 1

R4
Рисунок 4.6 – Расщепление горизонта
4.5 Обратное обновление
Обратное обновление (poison reverse) позволяет маршрутизаторам отме-

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

...
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 Адрес
Маскаподсети
Следующая пересылка
Метрика
Идентификаторсемейства Тег маршрута

адресов
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)
Идентификаторсемейства
Тег маршрута
адресов
IP Адрес
Маска подсети
Метрика
Рисунок 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.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 – Параметры команды 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
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, синтаксис команды
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
Рисунок 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
.. .. ..
R 172.16.0.16 [120/1] via 172.16.0.1, 00:01:11, Serial0/0/0
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.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.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
Перечисленные выше команды предоставляют информацию, которая

может оказаться полезной при проверке конфигурации маршрутизатора.
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
via Connected, Serial2
via 10.93.0.1 (6538496/6026496), Serial0
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
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
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
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
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

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
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

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
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 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
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 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
Маршрутизатор 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
10.1.1.0/24 5
Via R 3 5 3 S
Via R 5 5 4 S
R2 R4
2
2 1 R
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.16) является сведенной и стабильной.

Маршрутизатор R4 имеет в таблице маршрутизации два маршрута до сети
10.1.1.0/24. По этим двум маршрутам автоматически включается механизм
балансировки нагрузки.
10.1.1.0/24
R1
10.1.1.0/24 5
ViaR 3 5 3 S
ViaR 5 5 4 S
R2 R4
2
2 1
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.

(config-router)# network network-number [wildcard-mask]
(config-router)# no network network-number [wildcard-mask]
Описание параметров команды network приводиться в таблице 7.1.
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
Так как при настройке не использовались обратные маски для задания

сетей участвующих в процессе маршрутизации, то маршрутизатор автомати-
чески произведет суммирование команд 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#
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
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

...
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

...
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 – Синтаксис команды 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 – Синтаксис команды 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.

(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 – Синтаксис команды 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 – Синтаксис команды 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
D 172.16.0.16 [90/2304000] via 172.16.0.1, 00:00:27, Serial0/0/0
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

всех протоколах IP маршрутизации, в том числе и о протоколе EIGRP, скон-
фигурированных на маршрутизаторе (Пример 7.20).
142
Routing Protocol is "eigrp 200"
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
10.0.0.0
172.16.0.0
Passive Interface(s):
FastEthernet0/0
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
0/0 peerQ un/rely 0/0
*Mar 15 13:40:50.251 KRSK: EIGRP: Sending HELLO on Serial0/0/1
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 ()
incoming QUERY packet
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
10.89.1.0/28 - do advertise out Serial0/0/1
10.89.1.0/28 metric 4294967295 - 0 4294967295
10.89.1.0/28 metric 4294967295 - 0 4294967295
10.89.1.0/28 metric 4294967295 - 0 4294967295
10.89.1.0/28 metric 4294967295 - 0 4294967295
incoming REPLY packet
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
10.89.1.0/28 routing table not updated thru 10.93.1.18
10.89.1.0/28 - not in IP routing table
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
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
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
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
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)

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
MTU интерфейса Опции Флаги

Порядковыйномер пакета
Заголовок 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
Тип LSA
Запрос LSA 1
Идентификатор LSA
Заявивший маршрутизатор
Тип LSA
Запрос LSA N
Идентификатор LSA
Заявивший маршрутизатор
Рисунок 10.8 – Формат LSR пакета
179
Пакет запроса на получение информации о топологическом элементе
протокола OSPF включает следующие поля:
– Тип LSA. Тип запрашиваемого LSA.
– Идентификатор LSA. Уникальный идентификатор записи LSA.
– Заявивший маршрутизатор. Уникальный идентификатор маршрутиза-
тора, которым был заявлен LSA.
В пакете LSR может содержаться одна или несколько троек полей опи-
сывающих требуемые LSA.
10.4.4 Обновление информации о топологических элементах
32 бита
8 8 8 8

Количество 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

Заголовок 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 – Синтаксис команды 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 запущен не бу-
дет, а операционная система выдаст сообщение об ошибке представленное в
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#
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#
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 -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-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#
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 приводиться

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 – Синтаксис команды 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
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
всех протоколах IP маршрутизации, в том числе и о протоколе OSPF, сконфи-
гурированных на маршрутизаторе (Пример 11.17).

Routing Protocol is "ospf 1"
Router ID 10.95.0.49
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
10.0.0.0 0.255.255.255 area 0
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 – Параметры команды 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 Вывод таблицы топологии процесса
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
92630 link state updates, 40052 link state acks
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
37831 link state upds, 33783 link state acks, 0 invalid
Sent: 79650010 total
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
neighbor-id Отчистка статистики о соседе.
traffic Отчистка статистики служебного тра-
фика протокола OSPF.
interface-type interface-number Отчистка статистики служебного тра-
фика прошедшему через выбранный
интерфейс.
В набор инструментов для отладки работы протокола OSPF запущенно-

го на маршрутизаторе также входит ряд команд debug.
Для вывода информации о событиях в работе протокола OSPF, таких
как получение и отправка Hello пакетов, обмен топологической информацией,
запуск алгоритма SPF и других служебных событий используется команда de-
bug ip ospf events. Информация, выводимая данной командой, представлена в
Пример 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
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
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: 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: 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
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
opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
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: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
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 – Параметры команды ip ospf network
broadcast Применяет к интерфейсу характери-
стики широковещательной сети. Ис-
пользует групповую рассылку Hello
пакетов для автоматического опреде-
ления соседей. Производятся выборы
DR и BDR маршрутизаторов. Адреса
соседей выдаются из одной подсети.
Требуется полно-связная топология
сети.
non-broadcast Соседние маршрутизаторы должны
быть сконфигурированы вручную.
Производятся выборы DR и BDR
маршрутизаторов. DR и BDR маршру-
тизаторы должны быть соединены со
всеми остальными маршрутизаторами
сегмента. Адреса соседей выдаются из
одной подсети. Используется в частич-
но-связной топологии сети.
213
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. Синтаксис команды при-

(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 – Параметры команды 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
Рисунок 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.10.1.10 Serial0
Рисунок 12.6 – Список соседей маршрутизатора R1
На рисунке 12.6 приводится список соседей маршрутизатора R1, имею-

щего подключения по двум интерфейсам Serial 0 (point-to-point интерфейс) и
Serial 1 (Frame Relay интерфейс). С соседом находящимся за интерфейсом S0
216
установлены полные соседские отношения. За интерфейсом S1 находятся два
соседа, с которыми установлены полные соседские отношения, причем для
этих соседей маршрутизатор R1 является DR маршрутизатором.
12.5.2 Многоточечный режим
Многоточечный режим для сетей NBMA разработан для топологии

«звезда» и частично-связной топологии. В данном режиме OSPF представляет
все каналы передачи данных между парами маршрутизаторов как несколько
каналов «Точка-Точка». В многоточечном режиме не производиться выбор
DR маршрутизатора. Автоматическое определение соседних маршрутизато-
ров и занесение их таблицу соседства происходит при помощи средств ка-
нального уровня среды NBMA.
Как и в неширововещательном режиме служебные пакеты протокола
OSPF копируются и отправляются каждому соседу из таблицы соседства на-
ходящемуся за многоточечным интерфейсом.
Для больших сетей использование многоточечного режима значительно
уменьшает число используемых VC для создания связности сети. К тому же
отказ от полно-связной топологии значительно уменьшает количество запи-
сей в таблицах соседства маршрутизаторов. Многоточечный режим обладает
следующими свойствами:
– Не требует наличия полно-связной топологии;
– Не требует статической настройки соседей;
– Используется одна IP подсеть;
– Копирование служебных пакетов OSPF.
На рисунке 12.7 представлен пример конфигурации многоточечного ре-
жима между тремя маршрутизаторами.
r2# interface serial 1

encapsulation frame-relay
ip address 10.10.1.2 255.255.255.248
10.10.1.0/29 ip ospf network point-to-multipoint
R2

ip address 10.10.1.3 255.255.255.248
ip ospf network point-to-multipoint
R1 R3

ip address 10.10.1.1 255.255.255.248
ip ospf network point-to-multipoint
Рисунок 12.7 – Пример настройки многоточечного режима
Как видно из рисунка на маршрутизаторах не производится статическая

настройка соседних маршрутизаторов, происходит автоматический поиск и
217
установка соседских отношений при помощи средств канального уровня сре-
ды Frame Relay.
12.5.3 Использование подинтерфейсов
Физический интерфейс маршрутизатора может быть логически разбит

на несколько логических интерфейсов называемых подинтерфейсами. Каж-
дый подинтерфейс может быть определен как интерфейс «Точка-Точка» или
многоточечным интерфейсом. Подинтерфейсы создаются для правильной об-
работки проблем, связанных с реализацией принципа разделенного гори-
зонта, имеющих место в сетях NBMA. Подинтерфейс описывается с помо-
щью команды interface. Синтаксис команды приводится в примере 12.4.
Пример 12.4 – Синтаксис команды interface

(config)# interface type number.subinterface-number {multipoint | point-to-
point}
(config)# no interface type number.subinterface-number
Таблица 12.3 – Параметры команды interface
type Тип физического интерфейса.
number.subinterface-number Номер интерфейса и подинтерфейса.
Номер интерфейса должен совпадать с
номером физического интерфейса, к
которому принадлежит подинтерфейс.
Номер подинтерфейса может задавать-
ся в пределах от 1 до 4294967293.
multipoint Многоточечный подинтерфейс.
point-to-point Подинтерфейс «Точка-Точка».
На рисунке 12.8 все три маршрутизатора имеют по одному последова-

тельному порту, однако маршрутизатор R1 имеет два логических порта. Каж-
дый логический порт имеет свой собственный IP адрес и работает как интер-
фейс «Точка-Точка».
218
0 R2
0/3
1.
10.
.
10
S1.1
10.10.1.4/30
S1.2
R1 R3
r1# interface serial 1.1 point-to-point

ip address 10.10.1.1 255.255.255.252
!
interface serial 1.2 point-to-point
ip address 10.10.1.5 255.255.255.252
Рисунок 12.8 – Пример использования подинтерфейсов «Точка-Точка»
Каждый подинтерфейс использует собственную подсеть, благодаря

чему не нужно проводить выборы DR и BDR маршрутизаторов и статическую
настройку списка соседей. На рисунке 12.9 приводится пример использования
многоточечных подинтерфейсов.
R4 R2
10.10.1.0/30 9
/2
.8
S1.1 0.1
.1
10
S1.2
R1 R3
r1# interface serial 1.1 point-to-point

ip address 10.10.1.1 255.255.255.252
!
interface serial 1.2 point-to-multipoint
ip address 10.10.1.9 255.255.255.248
Рисунок 12.9 – Пример использования многоточечного подинтерфейса
Многоточечные подинтерфейсы Frame Relay по умолчанию определя-

ются как нешироковещательные. В соответствии с правилами работы прото-
кола OSPF в нешироковешательных сетях требуется статическое задание
списка соседей и назначение DR и BDR маршрутизаторов.
На рисунке 12.9 маршрутизатор R1 имеет один подинтерфейс «Точка-
Точка», и один подинтерфейс многоточечный. На многоточечном интерфейсе
подключены два маршрутизатора с использованием IP адресов из одной под-
сети.
219
12.6 Проверка работы протокола OSPF в сетях различных типов
Для проверки параметров работы протокола OSPF на интерфейсах

маршрутизатора используется команда show ip ospf interface. Синтаксис ко-
Пример 12.5 – Синтаксис команды show ip ospf interface

show ip ospf interface [interface-type interface-number] [brief]
Таблица 12.4 – Параметры команды show ip ospf interface
interface-type interface-number Тип и номер интерфейса.
brief Вывод краткой информации.
Информация, выводимая командой show ip ospf interface, представлена

в примере 12.6.
Пример 12.6 – Информация, выводимая командой show ip ospf interface

Serial0 is up, line protocol is up
Internet Address 10.93.1.2/28, Area 0
Process ID 4, Router ID 4.4.4.4, Network Type NON_BROADCAST, Cost: 781
Transmit Delay is 1 sec, State DR, Priority 1
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:09
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 1
Adjacent with neighbor 3.3.3.3
Suppress hello for 0 neighbor(s)
Serial1 is up, line protocol is up
Internet Address 10.93.1.17/28, Area 0
Process ID 88, Router ID 4.4.4.4, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:19
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 29
Last flood scan time is 0 msec, maximum is 9 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 5.5.5.5
Suppress hello for 0 neighbor(s)
220
Для проверки процесса установки соседских отношений используется
команда debug ip ospf adj. Данная команда позволяет отследить обмен слу-
жебными пакетами, посылаемыми между маршрутизаторами.
Пример 12.7 – Процесс установки соседских отношений на канале

«Точка-Точка»
r1# debug ip ospf adj
Point–to–point interfaces coming up: No election
OSPF: Interface Serial1 going Up
OSPF: Rev hello from 192.168.0.11 area 0 from Serial1 10.1.1.2
OSPF: End of hello processing
OSPF: Build router LSA for area 0, router ID 192.168.0.10
OSPF: Rev DBD from 192.168.0.11 on Serial1 seq 0x20C4 opt 0x2 flag 0x7 len 32
state INIT
OSPF: 2 Way Communication to 192.168.0.11 on Seriall, state 2WAY
OSPF: Send DBD to 192.168.0.11 on Serial1 seq 0xl67F opt 0x2 flag 0x7 len 32
OSPF: NBR Negotiation Done. We are the SLAVE
OSPF: Send DBD to 192.168.0.11 on Serial1 seq 0x20C4 opt 0x2 flag 0x2 len 72
В примере 12.7 приводится пример установки соседских отношений на

канале «Точка-Точка». Замете что в данном случае выборов DR и BRD марш-
рутизаторов не производится. Сразу производится обмен DBD пакетами.
Пример 12.8 – Процесс установки соседских отношений на широкове-

щательном канале
.. .. ..
OSPF: 2 Way Communication to 192.168.0.10 on Ethernet0, state 2WAY
OSPF: end of Wait on interface Ethernet0
OSPF: DR/BDR election on Ethernet0
OSPF: Elect BDR 192.168.0.12
OSPF: Elect DR 192.168.0.12
DR: 192.168.0.12 (Id) BDR: 192.168.0.12 (Id)
OSPF: Send DBD to 192.168.0.12 on Ethernet0 seq 0x546 opt 0x2 flag 0x7 len 32
OSPF: DR/BDR election on Ethernet0
OSPF: Elect BDR 192.168.0.11
OSPF: Elect DR 192.168.0.12
DR: 192.168.0.12 (Id) BDR: 192.168.0.11 (Id)
В примере 12.8 приводится процесс выборов DR и BRD маршрутизато-

ров на широковещательном интерфейсе Ethernet 0. Только после выбора DR и
BRD маршрутизаторов начинается обмен DBD пакетами.
221
13 Работа протокола OSPF в нескольких зонах
Реализация протокола OSPF в единственной зоне имеет один крупный

недостаток: с ростом количества сетей и маршрутизаторов увеличивается раз-
мер базы данных состояния каналов. Когда база данных растет, от маршрути-
заторов находящихся в зоне OSPF требуется, чтобы они отслеживали измене-
ния состояния каждого маршрутизатора и каждого канала связи внутри зоны
OSPF. Хранение и поддержка базы данных большого размера требует значи-
тельно большего объема оперативной памяти и ресурсов процессора на каж-
дом из маршрутизаторов. Каждый раз, когда внутри зоны становиться доступ-
ным новый канал или выходит из строя действующий, все маршрутизаторы
зоны должны воспользоваться алгоритмом SPF для пересчета таблицы марш-
рутизации.
На рисунке 13.1 приводится пример домена маршрутизации OSPF, в ко-
тором не было произведено разделение на зоны.
SPF часто
Я получаюочень
пересчитывает
много LSA
маршруты
Уменя очень большая

таблицамаршрутизации
Рисунок 13.1 – Домен маршрутизации OSPF без разделения на зоны
В больших доменах маршрутизации протокола OSPF, в которых не

было произведено разделение на зоны, могут возникнуть три основные
проблемы:
– Большой размер таблицы топологии. Таблица состояния каналов со-
держит полную топологию сети, таким образом, любой маршрутизатор дол-
жен хранить по одной записи для каждой сети и маршрутизатора зоны, даже
если маршрут, проходящий по данному каналу связи, не занесен в таблицу
– Периодические перерасчеты по алгоритму SPF. При наличии большо-
го количества каналов связи возникновение изменений в топологии сети
222
неизбежно, при этом значительно возрастет нагрузка на центральный процес-
сор маршрутизаторов для перерасчета таблиц маршрутизации.
– Большой размер таблицы маршрутизации. Протокол OSPF не произ-
водит суммирование маршрутов внутри одной зоны. Если не используется
суммирование маршрутов, то количество записей в таблицах маршрутизации
на всех маршрутизаторах домена маршрутизации OSPF будет одинаковым и
соответствовать количеству частных сетей получателей в домене маршрути-
зации.
В свете этих проблем в протокол OSPF была добавлена возможность
иерархического разделения общего домена маршрутизации на более мелкие
зоны, которые по-прежнему будут обмениваться между собой маршрутной
информацией. Пример разделения домена маршрутизации OSPF на несколько
зон, приводится на рисунке 13.2.
Зона 1 Зона 2
Рисунок 13.2 – Разделение домена OSPF на три зоны
Иерархическое разделение домена маршрутизации OSPF на множество

зон дает возможность уменьшить объем служебного трафика, вызванного об-
новлениями топологической информации, и сократить вычисления по алго-
ритму SPF, которые должны выполнять маршрутизаторы.
В каждой зоне домена маршрутизации обмен обновлениями топологи-
ческой информации ограничивается только маршрутизаторами принадлежа-
щими данной зоне, и это помогает уменьшить общий размер базы данных со-
стояния каналов. Маршрутизаторы поддерживают таблицы топологии только
тех зон, с которыми они непосредственно соединены. Таким образом, вну-
тренний трафик обновлений топологической информацией ограничивается
только той зоной, в которой он был сгенерирован. Изменения состояния
маршрутов одной зоны не требуют, чтобы маршрутизаторы другой зоны за-
нимались пересчетом этих маршрутов. Благодаря тому, что маршрутизаторы
не должны пересчитывать свои таблицы маршрутизации из-за изменений со-
223
стояний каналов связи в другой зоне, существенно уменьшается объем вычис-
лений по алгоритму SPF, что в свою очередь значительно повышает стабиль-
ность сети.
Разделение общего домена маршрутизации OSPF может происходить
любым способом, но обычно такое разделение производиться по географиче-
скому принципу, при котором каждая зона определяется ее местоположени-
ем. Как говорилось ранее при разделении домена маршрутизации на несколь-
ко зон всегда должна существовать так называемая магистральная зона или
Зона 0. Данная зона исполняет роль транзитной зоны для всех остальных зон
и обеспечивает передачу топологической информации между зонами.
13.1 Типы маршрутизаторов OSPF
Протокол OSPF разграничивает функции маршрутизаторов в зависимо-

сти от того, какое место в домене маршрутизации они занимают и к какому
числу зон принадлежат. На рисунке 13.3 приводится пример домена маршру-
тизации OSPF разделенного на зоны, и функций маршрутизаторов которые
они выполняют в зависимости от своего расположения.
Backbone router
ABR ABR
Внешняя AS
Зона 1 Зона 2
Internal router ASBR
Рисунок 13.3 – Типы маршрутизаторов OSPF
Протокол OSPF использует четыре типа маршрутизаторов:

– Внутренние маршрутизаторы (Internal router);
– Магистральные маршрутизаторы (Backbone router);
– Пограничные маршрутизаторы зоны (Area border router - ABR);
– Пограничные маршрутизаторы автономной системы (Autonomous Sys-
tem Boundary router).
224
Маршрутизатор одновременно может классифицироваться как маршру-
тизатор нескольких типов. Например, если маршрутизатор подключен к зоне
0 и зоне 1, а также к не OSPF сети, его можно классифицировать как маршру-
тизатор ABR, ASBR и магистральный маршрутизатор.
13.1.1 Внутренние маршрутизаторы
Внутренние маршрутизаторы – это маршрутизаторы все интерфейсы,

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

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

двум разным зонам, одна из которых обязательно должна быть магистраль-
ной зоной. Эти маршрутизаторы ведут таблицы топологии тех зон, к которым
они подключены, и маршрутизируют входящий и исходящий трафики зон.
Для зоны протокола OSPF маршрутизаторы ABR являются граничными точ-
ками зон, а это значит, что маршрутизируемая информация, направляющаяся
в другие зоны, может достичь их только через пограничные маршрутизаторы.
Маршрутизаторы ABR могут суммировать маршруты зон подключенных, к
ним и передавать их в соседнюю зону в виде суммарной топологической ин-
формации. Зона может иметь один или более маршрутизаторов ABR.
13.1.4 Пограничные маршрутизаторы автономной системы
Маршрутизаторы ASBR располагаются на границе двух и более авто-

номных систем, в которых могут быть запущены различные протоколы марш-
рутизации. Основной функцией пограничных маршрутизаторов автономной
системы является экспорт и импорт маршрутной информации между домена-
ми маршрутизации OSPF и доменами маршрутизации других протоколов
маршрутизации. ASBR маршрутизаторы способны распространять внешнюю
маршрутную информации во все зоны домена маршрутизации OSPF.
225
13.2 Типы объявлений о состоянии каналов
Иерархическое разделение домена маршрутизации OSPF на несколько

зон приводит к нескольким способам прохождения пользовательского трафи-
ка по сети передачи данных.
– Трафик, отправитель и получатель которого располагаются в пределах
одной зоны, проходит только через данную зону.
– Трафик, отправитель и получатель которого располагаются в разных
зонах, проходит через магистральную зону до зоны, в которой располагается
получатель.
– Трафик, получатель которого располагается во внешней автономной
системе, поступает на пограничный маршрутизатор автономной системы,
объявляющий соответствующую сеть получатель. Этот ASBR маршрутизатор
является внутренним адресатом для домена маршрутизации OSPF, поэтому
трафик на него поступает в соответствии с вышеописанными правилами.
Как говорилось ранее, предназначение сообщений LSA заключается в
представлении топологической информации о сети передачи данных. Иерар-
хическое разделение домена маршрутизации приводящее к различным спосо-
бам прохождения пользовательского трафика также приводит к разделению
сообщений LSA на несколько типов. Правила распространения сообщений
LSA различных типов зависят как от содержания данных в сообщении, так и
от маршрутизаторов которые их объявили.
13.2.1 Структура заголовка сообщения LSA
Хотя, все типы сообщений LSA описывают различные типы топологи-

ческой информации, все сообщения имеют одинаковую структуру заголовка,
показанную на рисунке 13.4.
32 бита
8 8 8 8
Заголовок сообщения LSA
Возраст сообщения Опции Тип
Идентификатор сообщения
Объявляющий маршрутизатор
Порядковыйномер сообщения
Контрольная сумма Длина
Данные LSA
Рисунок 13.4 – Заголовок сообщения LSA
226
Стандартный заголовок сообщения LSA протокола OSPF размером 20
байт включает следующие восемь полей:
– Возраст сообщения. Поле содержит значение возраста сообщения
LSA в секундах. Когда создается экземпляр сообщения LSA, его возраст уста-
навливается равным 0. Каждую секунду, пока сообщение находится в памяти
маршрутизатора, его возраст увеличивается на единицу. Максимальное значе-
ние, которое может принимать поле «Возраст сообщения» равняется 1 часу
(3600 с).
– Опции. Поле описывает дополнительные возможности маршрутизато-
ра, объявившего данное сообщение LSA. Данное поле идентично полю «Оп-
ции» Hello пакета описанному в пункте 10.4.1.
– Тип. Поле указывает тип сообщения LSA. Различные типы сообщений
LSA обычно называют по их номерам. В таблице 13.1 перечисляются типы
LSA сообщений.
Таблица 13.1 – Типы сообщений LSA
Но-
Тип LSA Описание Кем объявляется
мер
Объявление со- Описывает состояния ин- Всеми маршрутизато-
1 стояние маршру- терфейсов маршрутиза- рами.
тизатора. тора.
Объявление со- Перечисляет маршрути- DR маршрутизаторами.
2 стояния сети. заторы, входящие в ши-
роковещательный домен.
Суммарное объ- Описывает суммарные Пограничными марш-
3 явление о состоя- маршруты. рутизаторами зоны
нии каналов. OSPF.
Суммарное объ- Описывает пограничные Пограничными марш-
4 явление о состоя- маршрутизаторы авто- рутизаторами зоны
нии каналов. номной системы. OSPF.
Объявления Описывает импортиро- Пограничными марш-
внешних связей ванные маршруты из дру- рутизаторами автоном-
5
автономной си- гих AS. ной системы.
стемы.
Групповые LSA. Описания топологиче- MOSPF маршрутизато-
ской информации для рами.
6 группового трафика. Данный тип не поддер-
живается маршрутиза-
торами Cisco.
227
Номер Тип LSA Описание Кем объявляется

Внешние LSA для Описывает импортиро- Пограничные
NSSA зон. ванные маршруты в об- маршрутизаторы
7
ласть NSSA из других NSSA.
AS.
VPN LSA для взаимо- Описывает импортиро- Пограничные
8 действия с BGP VPN ванные маршруты из маршрутизаторы
v4 BGP VPN v4. PE.
Зарезервировано.
9,10,11 - -
– Идентификатор сообщения. Поле является компонентом уникальной

идентификации LSA сообщения. Другими компонентами являются поля «Тип
сообщения» и «Объявляющий маршрутизатор». В зависимости от типа LSA
этому полю присваиваются значения, приведенные в таблице 13.2.
Таблица 13.2 – Значения поля «Идентификатор сообщения»
Тип LSA Идентификатор сообщения

1 RID маршрутизатора заявившего LSA.
2 IP адрес интерфейса DR маршрутиза-
тора подключенного к широковеща-
тельному домену.
3 Суммарный маршрут сети получателя.
4 RID пограничного маршрутизатора ав-
тономной системы.
5и7 Сеть получатель.
– Объявляющий маршрутизатор. Поле содержит RID маршрутизатора

заявившего сообщение LSA.
– Порядковый номер сообщения. Поле содержит величину, идентифи-
цирующую данный экземпляр сообщения LSA. Порядковый номер рассмат-
ривается как знаковое целое, он может быть изменен только маршрутизато-
ром, который объявляет данное LSA. Самый первый экземпляр каждого сооб-
щения LSA имеет порядковый номер 0x80000001 т.е. -231+1. Каждый раз при
достижении максимального возраста сообщения LSA маршрутизатор создает
новый экземпляр данного LSA и увеличивает порядковый номер на единицу.
Максимальное значение порядкового номера равняется 0x7FFFFFFF т.е. 231-1.
Минимальный период времени, за который при генерации новых экземпляров
228
LSA сообщений равным 5 секундам, данное значение будет достигнуто через
700 лет. Следовательно, слишком большие номера экземпляров сообщений
LSA могут свидетельствовать о наличии какой-либо проблемы в аппаратном
или программном обеспечении маршрутизатора.
– Контрольная сумма. Поле содержит контрольную сумму всего сооб-
щения LSA за исключением двух полей: самого себя и поля возраст сообще-
ния.
– Длина. Поле содержит длину сообщения в байтах.
После общего заголовка пакета OSPF идет поле данных со специфиче-
ской информацией, относящейся к одному из семи типов LSA.
13.2.2 Объявление состояния маршрутизатора (Тип 1)
Сообщения LSA 1 типа описывают состояния связей маршрутизатора в

отдельной зоне. Они объявляются всеми маршрутизаторами OSPF без исклю-
чений. Маршрутизатор OSPF генерирует отдельное сообщение первого типа
для каждой зоны, к которой он подключен. Например, если маршрутизатор
является ABR маршрутизатором, два интерфейса, которого подключены к ма-
гистральной зоне, а один к регулярной зоне, маршрутизатор сгенерирует одно
сообщение LSA для магистральной зоны и одно для регулярной зоны. Первое
сообщение будет описывать два интерфейса подключенные к магистральной
зоне, второе сообщение – один интерфейс регулярной зоны. Маршрутизатор
все интерфейсы, которого принадлежат одной зоне OSPF, заявляют одно со-
общение LSA первого типа. Сообщения LSA первого типа распространяются
только в пределах зоны, в которой они объявлены (Рисунок 13.5).
Зона 1
Internal Internal
LSA 1
Рисунок 13.5 – Область распространения LSA 1 типа
Структура сообщения LSA маршрутизатора представлена на рисунке

13.6.
229
32 бита
8 8 8 8
Заголовок LSA (Тип = 1)
Флаги Количество связей
Идентификаторсвязи
Данные связи
Связь 1
Тип связи Число ToS Метрика
ToS 0 Метрика ToS

Данные пакета LSA
Флаги Количество связей
Идентификаторсвязи
Данные связи
Связь N
Тип связи Число ToS Метрика
ToS 0 Метрика ToS
Рисунок 13.6 – Структура сообщения LSA 1 типа
Структура сообщения включает в себя заголовок LSA со значением 1 в

поле «Тип сообщения», далее идут поля данных:
– Флаги. Поле размеров в 16 бит имеет структуру, показанную на ри-
сунке 13.7.
– Количество связей. Поле содержит число связей маршрутизатора опи-
санное в сообщении.
16 бит
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
0 V E B 0
Рисунок 13.7 – Структура поля «Флаги»
Из 16 бит поля «Флаги» в настоящее время определены только 3,

остальные зарезервированы для будущего использования и в настоящее время
всегда равны 0. Три определенных в настоящее время бита выполняют следу-
ющие функции:
– Бит V. Бит указывает, что маршрутизатор имеет один или несколько
виртуальных каналов, установленных через зону, для которой это сообщение
LSA было создано.
230
– Бит E. Бит указывает, что маршрутизатор является пограничным
маршрутизатором автономной системы (ASBR).
– Бит B. Бит указывает, что маршрутизатор является пограничным
маршрутизатором зоны OSPF (ABR).
Каждая запись о связи состоит из пяти обязательных полей и до
четырех необязательных полей ToS. В настоящее время возможность указа-
ния типа сервиса убрана из стандарта OSPF, однако поля ToS оставлены в па-
кетах протокола OSPF для выполнения обратной совместимости с устаревши-
ми версиями протокола OSPF. Данные поля заполняются 0.
– Идентификатор связи. Идентификатор объекта, к которому ведет опи-
сываемая связь.
– Данные связи. Поле передает информацию сетевого уровня, необхо-
димую для алгоритма SPF.
– Тип связи. Поле указывает тип связи маршрутизатора.
– Метрика. Поле содержит стоимость соответствующей связи маршру-
тизатора.
Первые три поля, «Идентификатор связи», «Данные связи», «Тип
связи», тесно взаимосвязаны. Взаимозависимость между значениями, кото-
рые могут принимать эти поля, приведена в таблице 13.3.
Таблица 13.3 – Взаимосвязь полей в LSA 1 Типа
Тип Описание типа

Идентификатор связи Данные связи
связи связи
Канал «Точка- RID маршрутизатора на IP адрес интерфейса.
1 Точка». другом конце канала
связи.
Транзитная IP адрес DR маршрути- IP адрес интерфейса.
2
сеть. затора.
Тупиковая Сетевой префикс тупи- Маска подсети тупикового
3
сеть. кового сегмента. сегмента.
Виртуальная RID маршрутизатора на IP адрес интерфейса через
связь. другом конце виртуаль- который пакеты OSPF от-
4
ного. правляются по виртуально-
му каналу.
13.2.3 Объявление состояния сети (Тип 2)
Объявления состояния сети описывают маршрутизаторы, подключен-

ные к широковещательному сегменту или сегменту NBMA. Они объявляются
DR маршрутизатором выбранным в этом сегменте. Сообщения LSA второго
типа распространяются только в пределах зоны, в которой они объявлены
231
Зона 1
DR Internal
Internal
LSA 2
Рисунок 13.8 – Область распространения LSA 2 типа
Структура сообщения состояния сети представлена на рисунке 13.9.

32 бита
8 8 8 8
Заголовок LSA (Тип = 2)
Маска сети
Присоединенныймаршрутизатор 1
Присоединенныймаршрутизатор N
Рисунок 13.9 – Структура сообщения LSA 2 типа
Структура сообщения включает в себя заголовок LSA со значением 2 в

поле «Тип сообщения», далее идут поля данных:
– Маска сети. Поле содержит маску подсети широковещательного сег-
мента, о котором распространяется информация.
– Присоединенные маршрутизаторы. Поле содержит RID маршрутиза-
тора принадлежащего широковещательному сегменту. Количество полей рав-
няется количеству маршрутизаторов в широковещательном сегменте.
13.2.4 Суммарные объявления о состоянии каналов (Тип 3 и 4)
Суммарные объявления о состоянии каналов описывают места назначе-

ния, расположенные за пределами зоны, но в приделах домена маршрутиза-
ции OSPF. Суммарные LSA типа 3 описывают межзональные маршруты, а
LSA типа 4 описывают пограничные маршрутизаторы автономной системы,
расположенные за приделами зоны OSPF. Сообщения LSA обоих типов объ-
являются пограничными маршрутизаторами ABR. В независимости от типа
каждое суммарное LSA описывает ровно одно место назначения. Принцип
распространения суммарных LSA показан на рисунке 13.10.
232
Зона 1 Зона 0 (Backbone ) Зона 2
DR ABR /R1 BBone ABR/R2 Internal

LSA 3 LSA 1
RIP
ASBR
LSA 3 LSA 3
LSA 2
LSA 3
LSA 4
Internal LSA 3
LSA 3 LSA 1 LSA 1 LSA 4
LSA 1
Рисунок 13.10 – Принцип распространения суммарных LSA
Маршрутизаторы R1 и R2 объявляют в магистральную зону суммарные

LSA от зон 1 и 2, а в обратном направлении суммарные LSA магистральной
зоны. Пограничный маршрутизатор R1 объявляет несколько суммарных LSA
типа 3 для сетей получателей расположенных в 1 зоне и один суммарный LSA
типа 4 для ASBR маршрутизатора. Во 2 зоне нет точек входа в другие авто-
номные системы, следовательно, маршрутизатор R2 объявляет в магистраль-
ную зону только суммарные LSA 3 типа.
Как говорилось ранее, что одна из основных целей разделения домена
маршрутизации OSPF на несколько зон, это уменьшение нагрузки на процес-
соры маршрутизаторов, вызванной необходимостью выполнения алгоритма
SFP для большого количества топологических записей и поддержанием в ак-
туальном состоянии таблиц маршрутизации большого размера. Для выполне-
ния этой задачи в протоколе OSPF должно производиться суммирование то-
пологической информации. Такое суммирование может выполняться только
на ABR маршрутизаторах. Для этого применяются суммарные LSA 3 типа.
Однако суммирование топологической информации не происходит автомати-
чески, а должно настраиваться вручную, без проведения соответствующей на-
стройки ABR маршрутизаторы будут трансформирование всех известных им
LSA 1 и 2 типа в суммарные LSA 3 типа и производить их объявление в соот-
ветствии с правилами распространения суммарных LSA.
Структура сообщений LSA 3 и 4 типов представлена на рисунке 13.11.
Структура сообщения включает в себя заголовок LSA со значениями 3
или 4 в поле «Тип сообщения», далее идут поля данных:
– Маска. Для суммарного LSA 3 типа поле содержит маску подсети
объявляемого суммарного маршрута. Для LSA 4 типа поле заполняется 0.
– Метрика. Поле содержит метрику маршрута к месту назначения.
233
32 бита
8 8 8 8
Заголовок LSA (Тип = 3 или 4)
Маска сети

0 Метрика
ToS Метрика ToS
Рисунок 13.11 – Структура сообщения LSA 3 и 4 типов
13.2.5 Объявления внешних связей (Тип 5 и 7)
Объявления о внешних связях описывают места назначения, располо-

женные за пределами домена маршрутизации OSPF. Эти сообщения объяв-
ляются пограничными маршрутизаторами автономных систем (ASBR), и как
показано на рисунке 13.12, распространяются по всему домену маршрутиза-
ции OSPF.
Зона 1 Зона 0 (Backbone) Зона 2
ABR/DR BBone ABR/DR
Внешняя AS ASBR Internal
Рисунок 13.12 – Принцип распространения внешних LSA
Как видно из рисунка объявления о внешних связях распространяются

без изменения по всему домену маршрутизации OSPF, следовательно, с це-
лью уменьшения нагрузки на маршрутизаторы OSPF без крайней необходи-
мости не следует производить объявления частных маршрутов из других ав-
тономных систем.
При объявлении маршрутов из других автономных систем следует
производить объявление суммарных маршрутов до внешних сетей получа-
телей.
Различие между 5 и 7 типом внешних LSA заключается в том, что 5 тип
применяется для распространения внешних связей внутри и за приделами
234
стандартных зон протокола OSPF, а тип 7 предназначен для распространения
внешних связей внутри NSSA зон протокола OSPF.
Структура сообщений LSA 5 и 7 типов представлена на рисунке 13.13.
32 бита
8 8 8 8
Заголовок LSA (Тип = 5 или 7)
Маска сети
E 0 Метрика
Адрес пересылки
Ярлык внешнего маршрута
E ToS Метрика ToS
Адрес пересылки
Запись ToS
Ярлык внешнего маршрута
Рисунок 13.13 – Структура сообщения LSA 5 и 7 типов
Структура сообщения включает в себя заголовок LSA со значениями 5

или 7 в поле «Тип сообщения», далее идут поля данных:
– Маска. Поле содержит маску подсети объявляемого внешнего марш-
рута.
– Бит E. Бит E указывает на тип используемой метрики. Если бит равен
0, то используется метрика 1 типа, если бит равен 1, то метрика 2 типа. О ти-
пах метрик протокола OSPF будет рассказано далее.
– Метрика. Поле содержит метрику маршрута к месту назначения.
– Адрес пересылки. Поле содержит IP адрес маршрутизатора, который
должен передавать трафик к внешней сети получателю. Если это поле содер-
жит значение 0, передающий маршрутизатор является пограничным маршру-
тизатором ASBR, который объявляет данное сообщение LSA.
– Ярлык внешнего маршрута. Поле содержит ярлык внешнего маршру-
та, который был назначен при импорте маршрутной информации в домен
13.3 Построение таблицы маршрутизации протоколом OSPF
Сообщения LSA описывают топологическую информацию домена

маршрутизации протокола OSPF. Маршрутизаторы используют эту информа-
235
цию для построения таблицы маршрутизации, которая используется при
передаче трафика сети получателю.
Каждый маршрутизатор обладает отдельной базой данных состояния
связей для каждой зоны, к которой он подключен. Когда содержимое базы
данных изменяется, маршрутизатор запускает алгоритм SPF для повторного
построения таблицы маршрутизации. Алгоритм SPF выполняется для той та-
блицы топологии, в которой произошли изменения.
Процесс построения маршрутизатором таблицы маршрутизации состо-
ит из следующих основных пунктов.
1. Маршрутизатор выполняет алгоритм SPF для сообщений LSA 1 и 2
типов. Маршрутизатор производит расчет внутризональных записей таблицы
маршрутизации для всех сетей получателей, имеющихся в пределах зоны.
Кроме того, он генерирует записи маршрутизаторов для всех погранич-
ных маршрутизаторов ABR и ASBR находящихся внутри данной зоны. Эти
записи таблицы маршрутизации не используются для пересылки трафика, они
используются только протоколом OSPF при создании межзональных маршру-
тов, а также маршрутов к сетям получателям находящихся в других автоном-
ных системах.
2. Маршрутизатор рассчитывает межзональные маршруты, используя
суммарные LSA 3 и 4 типов. При создании межзональных маршрутов марш-
рутизатор должен проверить, имеется ли запись в таблице маршрутизации,
созданная на 1 шаге, для ABR маршрутизатора, идентификатор которого ука-
зан в качестве объявляющего маршрутизатора суммарного сообщения LSA.
Если такой записи не существует, межзональный маршрут не создается.
Для пограничных маршрутизаторов ASBR, маршрутизаторы создают
таблицы маршрутизации, которые не используются для пересылки трафика, а
используются протоколом OSPF при создании внешних маршрутов.
3. Маршрутизаторы рассчитывают маршруты к внешним сетям получа-
телям, используя информацию сообщений LSA 5 или 7 типов. При создании
внешних маршрутов маршрутизатор должен проверить, имеется ли записи в
таблице маршрутизации для маршрутизаторов ASBR, через который доступ-
ны внешние получатели созданные на шаге 2 для маршрутизатора ASBR,
идентификатор, которого указан в качестве объявляющего маршрутизатора
суммарного сообщения LSA. Если такой записи не существует, внешний
маршрут не создается.
Полное описание процесса расчета таблицы маршрутизации с обра-
боткой всех возможных вариантов и обработкой исключений приводится в
RFC 2328.
13.3.1 Типы маршрутов протокола OSPF
236
В соответствии с процессом построения таблицы маршрутизации про-
токол OSPF разделяет маршруты на четыре типа. В таблице 13.4 приведено
описание типов маршрутов протокола OSPF.
237
Таблица 13.4 – Типы маршрутов в протоколе OSPF
Идентификатор Тип маршрута Описание

O OSPF intra–area. Внутризональный марш-
рут.
O IA OSPF inter–area. Межзональный маршрут.
O E1 Type 1 External routes. Внешний маршрут 1
типа.
O E2 Type 2 External routes. Внешний маршрут 1
типа.
13.3.2 Расчет метрики внешних маршрутов
Расчет метрики внешних маршрутов зависит от типа внешнего маршру-

та.
Для внешних маршрутов 1 типа (E1) метрика вычисляется сложением
внешней метрики маршрута полученной при импортировании маршрута в до-
мен маршрутизации OSPF и метрики каждого канала, который проходит на
своем пути пакет до ASBR маршрутизатора.
Для внешних маршрутов 2 типа (E2) метрика состоит только из внеш-
ней метрики и не зависит от метрик внутренних каналов связи.
Пример распространения внешних маршрутов различных типов приво-
дится на рисунке 13.14.
R2 Cost to : R4 Cost to :
AS1 (E1) viaR 1 = 1675 AS1 (E1) viaR 3 = 1695
AS2 (E2) viaR 3 = 1785 AS2 (E2) viaR 4 = 1785
Зона 1 Зона 0 (Backbone)
Внешняя AS 1 1665 10 10 10 1785 Внешняя AS 2

R1 R2 R3 R4
R1 Cost to : R3 Cost to :
AS1 (E1) viaR 1 = 1665 AS1 (E1) viaR 2 = 1685
AS2 (E2) viaR 2 = 1785 AS2 (E2) viaR 4 = 1785
Рисунок 13.14 –Распространение внешних маршрутов
Внешние маршруты 2 типа применяются, если во внешнюю автоном-

ную систему, на которую они указывают, существует только одна точка вхо-
да. Следовательно, производить пересчет метрики маршрута внутри домена
маршрутизации OSPF не имеет смысла, так как внутренняя метрика ни как не
может повлиять на выбор внешнего маршрута.
238
Однако если во внешнюю автономную систему существуют две или бо-
лее точек входа, причем они могут быть расположены в разных частях домена
маршрутизации OSPF, то для корректной обработки таких внешних маршру-
тов необходимо их объявление как внешних маршрутов 1 типа. При этом в их
метрике будет учитываться не только внешняя составляющая, но и внутрен-
няя, это позволит маршрутизаторам находящимся в домене OSPF произво-
дить корректный выбор между альтернативными внешними маршрутами.
По умолчанию протокол OSPF все внешние маршруты распространяет
как внешние маршруты 2 типа.
13.4 Суммирование маршрутов протоколом OSPF
Использование механизма суммирования маршрутов существенно

уменьшает величину требуемых вычислительных ресурсов для процесса
маршрутизации OSPF. В протоколе OSPF существуют два типа суммирова-
ния маршрутов:
– Суммирование межзональных маршрутов;
– Суммирование внешних маршрутов.
13.4.1 Суммирование межзональных маршрутов
LSA 1
LSA 3
Рисунок 13.15 – Суммирование маршрутов в домене OSPF
В протоколе OSPF суммирование маршрутов в отличие от ранее

рассмотренных протоколов маршрутизации, где существуют механизмы сум-
239
мирования маршрутов в произвольной точке сети, можно производить только
на ABR маршрутизаторах. По умолчанию протокол OSPF не производит сум-
мирование маршрутов, однако, по принципу распространения топологиче-
ской информации ABR маршрутизатор производит замену каждого LSA 1 и 2
типа на сообщения LSA 3 типа.
При ручной настройке суммирования маршрутов, распространяемые
LSA 3 типа, описывают непрерывные группы сетей получателей как одну об-
щую сеть получатель, следовательно, множество LSA 1 и 2 типов заменяются
одним или несколькими сообщениями LSA 3 типа (Рисунок 13.15).
В примере, изображенном на рисунке 13.16, таблица маршрутизации
маршрутизатора R2 содержит 12 сетей, которые могут быть просуммированы
в два суммарных маршрута. Блок адресов с 172.16.8.0 по 172.16.15.0/24 пред-
ставляется маршрутом 172.16.8.0/21, а блок адресов с 17216.16.0 по
172.16.19.0/24 представляется маршрутом 172.16.16.0/22.
R1 R2 R3
O 172.16.8.0 255.255.255.0
O 172.16.9.0 255.255.255.0
O 172.16.10.0 255.255.255.0
O 172.16.11.0 255.255.255.0 IA 172.16.8.0 255.255.248.0
O 172.16.12.0 255.255.255.0
O 172.16.13.0 255.255.255.0
O 172.16.14.0 255.255.255.0
O 172.16.15.0 255.255.255.0
O 172.16.16.0 255.255.255.0
O 172.16.17.0 255.255.255.0 IA 172.16.8.0 255.255.248.0
O 172.16.18.0 255.255.255.0
O 172.16.19.0 255.255.255.0
Рисунок 13.16 – Пример суммирования межзональных маршрутов
Для настройки механизма суммирования межзональных маршрутов ис-

пользуется команда area range. Синтаксис команды приводится в примере
13.1
Пример 13.1 – Синтаксис команды area range

(config-router)# area area-id range address mask [advertise | not-advertise]
[cost cost]
(config-router)# no area-id range address mask [advertise | not-advertise]
[cost cost]
240
Таблица 13.5 – Параметры команды area range
area-id Идентификатор зоны OSPF, частные
маршруты которой буду агрегированы
в суммарный маршрут.
address mask Адрес и маска подсети объявляемого
advertise Разрешить объявление суммарного
маршрута и распространение LSA 3
типа.
not-advertise Запретить объявление суммарного
маршрута для описанного диапазона.
Сделать описанный диапазон скрытым
для всех остальных зон OSPF.
cost cost Метрика, назначаемая суммарному
маршруту.
Зона 1 Зона 0 (Backbone) Зона 2
c 172 .16.32.0/24 с 172 .16.96.0/24 с 172 .16.64.0/24

по 172 .16.63.0/24 по 172 .16.127 .0/24 по 172 .16.95.0/24
R1 R2
router ospf 200 router ospf 200

network 172.16.32.0 0.0.31.255 area 1 network 172.16.64.0 0.0.31.255 area 2
area 0 range 172.16.96.0 255.255.224.0 area 0 range 172.16.96.0 255.255.224.0
area 1 range 172.16.32.0 255.255.224.0 area 2 range 172.16.64.0 255.255.224.0
Рисунок 13.17 – Пример настройки суммарных межзональных маршрутов
На рисунке 13.17 приведен пример суммирования маршрутов распро-

страняемых в двух направлениях, из регулярной зоны в транзитную и из тран-
зитной зоны в регулярную.
Маршрутизатор R1 настроен на объявление двух суммарных маршру-
тов:
– Команда area 0 range 172.16.96.0 255.255.255.224.0 представляет ад-
ресное пространство зоны 0 как непрерывный адресный диапазон 172.16.96.0
255.255.255.224.0. Пограничный ABR маршрутизатор R1 суммирует диапазон
подсетей, с 172.16.96.0 по 172.16.127.0, в один суммарный маршрут
172.16.96.0 255.255.224.0 и объявляет его в зону 1.
– Команда area 1 range 172.16.32.0 255.255.255.224.0 представляет ад-
ресное пространство зоны 1 как непрерывный адресный диапазон 172.16.32.0
255.255.255.224.0. Пограничный маршрутизатор ABR R1 суммирует диапазон
241
подсетей, с 172.16.32.0 по 172.16.63.0, в один суммарный маршрут 172.16.32.0
255.255.224.0 и объявляет его в зону 0.
Настройка маршрутизатора R2 осуществляется аналогичным образом.
13.4.2 Суммирование внешних маршрутов
Под внешними маршрутами для домена маршрутизации OSPF понима-

ются маршруты, которые были импортированы в домен маршрутизации OSPF
из других автономных систем. Одной из проблем связанных с импортом
маршрутов из других автономных систем, является то, что при процедуре им-
порта в домен OSPF объявляются частные маршруты внешней автономной
системы. Так как ASBR маршрутизатор, который вносит внешние маршруты
в домен маршрутизации OSPF, не обязательно является еще и ABR маршру-
тизатором то, он не может произвести суммирование полученного диапазона
маршрутов в один суммарный маршрут описанным ранее способом.
Для суммирования диапазона внешних маршрутов в один суммарный
маршрут на ASBR маршрутизаторе применяется команда summary-address.
Синтаксис команды приводится в примере 13.2
Пример 13.2 – Синтаксис команды summary-address

(config-router)# summary-adress address mask [not-advertise] [tag tag]
(config-router)# no summary-adress address mask [not-advertise] [tag tag]
Таблица 13.6 – Параметры команды summary-address
address mask Адрес и маска подсети объявляемого
внешнего суммарного маршрута.
not-advertise Запретить объявление внешнего сум-
марного маршрута для описанного
диапазона. Сделать описанный диапа-
зон скрытым для всех зон OSPF.
tag tag Ярлык для использования при контро-
ле перераспределения маршрутов.
На рисунке 13.18 приведен пример суммирования маршрутов на ASBR

маршрутизаторе.
242
RIPv 2
172 .16.32.0/24
10.0.0.0/24
R1 R2
router ospf 200

network 172.16.32.0 0.0.31.255 area 1
redistribute rip metric 200
summary -address 10.0.0.0 255.0.0.0
Рисунок 13.18 – Пример настройки внешнего суммарного маршрута
Во внешней автономной системе запушен протокол маршрутизации RIP

v2 и имеются маршруты, которые необходимо передать в домен OSPF.
Поскольку во внешней автономной системе присутствует непрерывный
блок адресов то, он может быть представлен одним суммарным маршрутом.
Распространение суммарного маршрута в домен OSPF будет осуществлено
одним сообщением LSA 5 типа.
Если не произвести суммирование маршрутов из внешней автономной
системы на ASBR маршрутизаторе, то каждый частный маршрут из домена
маршрутизации RIP будет объявлен при помощи собственного сообщения
LSA 5 типа. Учитывая то, что сообщения LSA 5 типа распространяются по
всему домену маршрутизации OSPF без изменений, то каждый маршрутиза-
тор OSPF может получить достаточно большое количество сообщений LSA 5
типа в свою таблицу топологии, что может негативно сказаться на работе
13.4.3 Отображение внешних суммарных маршрутов
Для вывода информации о количестве и типах внешних суммарных

маршрутов импортированных в домен маршрутизации OSPF необходимо
воспользоваться командой show ip ospf summary-address. Информация, выво-
димая данной командой, представлена в примере 13.3.
Пример 13.3 – Информация, выводимая командой show ip ospf sum-

mary-address
r2#show ip ospf summary-address
OSPF Process 200, Summary-address
10.2.0.0/255.255.0.0 Metric -1, Type 0, Tag 0

10.2.0.0/255.255.0.0 Metric -1, Type 0, Tag 10
Описание выводимой командой show ip ospf summary-address приводит-

ся в таблице 13.7.
243
Таблица 13.7 – Описание информации выводимой командой show ip
ospf summary-address
10.2.0.0/255.255.0.0 IP адрес и маска подсети внешнего
Metric Метрика внешнего суммарного марш-
рута
Type Тип пакета LSA
Tag Ярлык, присвоенный внешнему сум-
марному маршруту
244
14 Специальные типы зон протокола OSPF
Подобно, рассмотренной ранее возможности протокола EIGRP задавать

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

для управления процессом объявления и получения топологической инфор-
мации. В протоколе OSPF определены следующие типы зон:
– Стандартная зона (standard area). Стандартная зона протокола OSPF
может объявлять и принимать пакеты LSA всех типов в зависимости от рас-
положенных внутри зоны типов маршрутизаторов и топологии сети передачи
данных.
– Магистральная зона (backbone area). В иерархической многозонной
модели организации домена маршрутизации протокола OSPF магистральная
зона занимает центральное положение. К ней подключаются все другие зоны
домена маршрутизации для обмена межзональными маршрутами. Маги-
стральная зона всегда обозначается как "Зона 0". Магистральная зона прото-
кола OSPF обладает всеми свойствами стандартной зоны протокола OSPF.
– Тупиковая зона (stub area). Тупиковая зона, не принимает информа-
цию о внешних связях, импортированных в домен маршрутизации OSPF.
Внешние связи, поступающие в тупиковую зону в виде сообщений LSA 5
типа, автоматически заменяются ABR маршрутизатором зоны на маршрут по
умолчанию, указывающий на ABR маршрутизатор. ABR маршрутизатор об-
ладает полной информацией о всех внешних связях в домене маршрутизации
OSPF. Тупиковые зоны не могут содержать ASBR маршрутизаторы.
– Полностью тупиковая зона (totally stub area). Зона, которая не прини-
мает не только информацию о внешних связях, но и суммарные сообщения
LSA 3 и 4 типов, являющиеся внутренними связями для данного домена
маршрутизации OSPF. Все внешние и межзональные маршруты заменяются
ABR маршрутизатором на маршрут по умолчанию, указывающий на ABR
маршрутизатор. Полностью тупиковые зоны не могут содержать ASBR марш-
рутизаторы.
– Не совсем тупиковая зона (not-so-stubby area, NSSA). Данный тип
зоны протокола OSPF обладает всеми свойствами тупиковых зон, однако не
совсем тупиковые зоны могут содержать ASBR маршрутизаторы.
245
– Полностью тупиковая не совсем тупиковая зона (totally stub not-so-
stubby area, totally stub NSSA). Данный тип зоны протокола OSPF обладает
всеми свойствами полностью тупиковых зон, однако totally stub NSSA зоны
могут содержать ASBR маршрутизаторы.
14.1.1 Правила тупиковых зон
Зону протокола OSPF можно настроить как тупиковую или полностью

тупиковую, если она удовлетворяет следующим критериям:
– Зона не является магистральной зоной;
– Зона имеет единственную точку выхода в магистральную зону;
– Зона не имеет ASBR маршрутизаторов;
– Зона не содержит виртуальных каналов.
14.2 Тупиковые зоны протокола OSPF
Настройка зоны OSPF как тупиковой зоны уменьшает размер таблиц

топологии на внутренних маршрутизаторах зоны за счет замены пограничны-
ми маршрутизаторами внешних сообщений LSA на маршрут по умолчанию.
Процесс распространения топологической информации изображен на рисунке
14.1.
Зона 1 (Stub) Зона 0 (Backbone ) Зона 2 (Standard)
Internal ABR ASBR ABR Internal
Default LSA 5 LSA 5 LSA 5
Внешняя AS
Рисунок 14.1 – Распространение маршрута по умолчанию в тупиковую зону
Использование маршрута по умолчанию позволяет маршрутизаторам,

находящимся в тупиковой зоне, уменьшать размеры таблиц маршрутизации,
так как множество внешних маршрутов заменяется одним маршрутом по
умолчанию. Обычно тупиковые зоны создаются в топологии «звезда», где в
роли луча выступает такая тупиковая зона.
246
14.2.1 Настройка тупиковой зоны
Чтобы настроить зону OSPF как тупиковую, необходимо воспользо-

ваться командой area stub. Синтаксис команды приводится в примере 14.1.
Пример 14.1 – Синтаксис команды area stub

(config-router)# area area-id stub
(config-router)# no area area-id stub
router ospf 200

network 172.16.32.0 0.0.31.255 area 1
network 172.16.96.0 0.0.31.255 area 0
area 1 stub
Зона 1 (Stub) Зона 0 (Backbone)
R1 R2 R3
router ospf 200

network 172.16.32.0 0.0.31.255 area 1
area 1 stub
Рисунок 14.2 – Пример настройки тупиковой зоны
На рисунке 14.2 Зона 1 определена как тупиковая зона протокола OSPF.

Необходимо обратить особое внимание на то, что команда area stub примене-
на в настройках всех маршрутизаторов принадлежащих зоне. Маршрутизатор
R2, который выступает в роли ABR маршрутизатора, автоматически распро-
страняет в тупиковую зону маршрут, указывающий на него, как маршрут по
умолчанию.
14.3 Полностью тупиковые зоны протокола OSPF
Полностью тупиковые зоны не определены в RFC 2328, а разработаны

компанией Cisco. Полностью тупиковые зоны позволяют еще большее сокра-
тить количество записей в таблице топологии внутренних маршрутизаторов
зоны. Полностью тупиковые зоны не принимают рассылку не только внеш-
них, но и межзональных сообщений LSA. Все внешние и межзональные
маршруты заменяются пограничным маршрутизатором зоны на маршрут по
умолчанию.
За счет блокирования внешних и межзональных маршрутов в таблицах
маршрутизации полностью тупиковой зоны присутствуют только внутризо-
нальные маршруты и маршрут по умолчанию на ABR маршрутизатор, вы-
247
бранный всеми маршрутизаторами в зоны как шлюз «последней надежды»
для всех маршрутов за пределами зоны.
ABR маршрутизатор производит автоматическую рассылку маршрута
по умолчанию для всех остальных маршрутизаторов зоны. Процесс распро-
странения топологической информации в полностью тупиковой зоне изобра-
жен на рисунке 14.3.
Зона 1 (Totally stub ) Зона 0 (Backbone ) Зона 2 (Standard)
Internal ABR ASBR ABR Internal
LSA 3 LSA 3 LSA 3
Default
LSA 5 LSA 5 LSA 5
Внешняя AS
Рисунок 14.3 – Распространение маршрута по умолчанию

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

в большей степени, чем тупиковые зоны, тем самым они повышают стабиль-
ность и упрощают масшабируемость сетей передачи данных. Использование
полностью тупиковых зон на маршрутизаторах Cisco предпочтительнее, чем
использование тупиковых зон.
14.3.1 Настройка полностью тупиковой зоны
Чтобы настроить зону как полностью тупиковую, необходимо восполь-

зоваться уже известной командой area stub на всех внутренних маршрутизато-
рах зоны, а на ABR маршрутизаторе добавить к команде area stub ключевое
слово no-summary. Необходимо помнить, что данное ключевое слово приме-
няется только на ABR маршрутизаторе.
Для изменения метрики автоматически распространяемого маршрута по
умолчанию можно воспользоваться командой area default-cost. Синтаксис ко-
Пример 14.2 – Синтаксис команды area default-cost

(config-router)# area area-id default-cost cost
(config-router)# no area area-id default-cost cost
248
Описание параметров команды area default-cost приводиться в таблице
14.1.
Таблица 14.1 – Параметры команды area default-cost
cost Метрика маршрута.
Данная команда применяется только для изменения метрики автомати-

чески сгенерированных маршрутов по умолчанию для тупиковых, полностью
тупиковых и NSSA зон протокола OSPF.
router ospf 200

area 1 stub no-summary
area 1 default-cost 5
Зона 1 (Stub) Зона 0 (Backbone)
R1
R3 R4
R2

area 1 stub area 1 stub no-summary
area 1 default-cost 10
Рисунок 14.4 – Пример настройки полностью тупиковой зоны
На рисунке 14.4 приведен пример конфигурации совсем тупиковой

зоны. Все межзональные или внешние маршруты, входящие в зону 1 из маги-
стральной зоны, меняются на маршрут по умолчанию. Метрика маршрута по
умолчанию через маршрутизатор R1 равняется 5, а через маршрутизатор R2
10. Применение двух маршрутизаторов в качестве ABR маршрутизаторов
полностью тупиковой зоны в данном случае не противоречит правилу об од-
ной точке выхода из тупиковой зоны.
В данном случае была применена команда area default-cost, которая на-
значает различные метрики для маршрутов по умолчанию, следовательно,
пока работают оба ABR маршрутизатора, трафик за пределы зоны будет пере-
даваться только по маршруту с меньшей метрикой, а это не противоречит
правилу, так как из зоны используется только одна точка выхода. Как только
маршрутизатор с меньшей метрикой становиться недоступен, трафик будет
отправляться по резервному маршруту по умолчанию, а как только основной
249
маршрутизатор станет доступен, произойдет обратное перенаправление тра-
фика.
Следует обратить внимание, что на маршрутизаторе R3 отсутствует
ключевое слово no-summary. Только конфигурация ABR маршрутизаторов со-
держит данное ключевое слово, чтобы препятствовать распространению меж-
зональных сообщений LSA 3 и 4 типов в полностью тупиковую зону.
14.4 Таблицы маршрутизации в тупиковых зонах
Возможность создания тупиковых и полностью тупиковых зон в прото-

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

r3#show ip route
.. .. ..
O IA 10.3.1.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
С 10.1.3.0 is directly connected, Serial0
О IA 10.2.1.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
О IA 10.3.3.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
О IA 10.2.2.0 [110/138] via 10.64.0.2, 00:31:46, Ethernet0
О 10.1.1.0 [110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial1
О IA 10.3.2.0 [110/212] via 10.64.0.2, 00:03:12, Ethernet0
О IA 10.2.3.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
O IA 10.4.2.0 [110/286] via 10.64.0.2, 00:02:50, Ethernet0
0 IA 10.4.3.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
0 IA 10.4.1.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
0 E2 10.66.0.0 [110/158] via 10.64.0.2, 00:02:51, Ethernet0
C 10.64.0.0 is directly connected, Ethernet0
0 E2 10.65.0.0 [110/84] via 10.64.0.2, 00:03:19, Ethernet0
Из примера видно, что в данной таблице маршрутизации присутствуют

все возможные виды маршрутов протокола OSPF: внутритональные, межзо-
нальные и маршруты из внешних автономных систем.
250
В следующем примере 14.4, представлена таблица маршрутизации, по-
лученная из таблицы маршрутизации представленной в примере 14.3 при по-
мощи настройки зоны, в которой расположен маршрутизатор, как тупиковой.
Пример 14.4 – Таблица маршрутизации в тупиковой зоне

r3#show ip route
.. .. ..

O IA 10.3.1.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
О IA 10.2.1.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
О IA 10.3.3.0 [110/148] via 10.64.0.2, 00:03:12, Ethernet0
О IA 10.2.2.0 [110/138] via 10.64.0.2, 00:31:46, Ethernet0
О 10.1.1.0 [110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial1
О IA 10.3.2.0 [110/212] via 10.64.0.2, 00:03:12, Ethernet0
О IA 10.2.3.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
O IA 10.4.2.0 [110/286] via 10.64.0.2, 00:02:50, Ethernet0
0 IA 10.4.3.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
0 IA 10.4.1.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
0*IA 0.0.0.0/0 [110/11] via 10.66.0.1, 00:20:43, Ethernet0
Из примера видно, что из таблицы маршрутизации были удалены два

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

r3#show ip route
.. .. ..

О 10.1.1.0 [110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial1
0*IA 0.0.0.0/0 [110/11] via 10.66.0.1, 00:20:43, Ethernet0
Из примера видно, что в таблице маршрутизации остались только вну-

тризональные маршруты, а все остальные маршруты были заменены маршру-
том по умолчанию.
251
14.5 Не совсем тупиковые зоны протокола OSPF
Применение тупиковых зон в домене маршрутизации OSPF оказалось

простым и эффективным методом уменьшения нагрузки на маршрутизаторы
OSPF вызванной необходимостью хранения и обработки больших объемов
топологической информации. Кроме этого применения тупиковых зон позво-
лило повысить стабильность процесса OSPF, за счет снижения зависимости
изменений в топологической информации внутри тупиковой зоны от измене-
ний топологической информации за ее пределами.
Однако область применения тупиковых зон резко ограничивает, суще-
ствующий запрет на расположение внутри зоны ASBR маршрутизаторов.
Для снятия этого ограничения и расширения области применения тупи-
ковых зон были созданы так называемые не совсем тупиковые зоны (not-so-
stubby area, NSSA). Первое описание функционирования зон NSSA было сде-
лано в документе RFC 1587, в настоящее время этот документ считается уста-
ревшим, а принципы функционирования NSSA зон регламентирует документ
RFC 3101.
Зоны NSSA обладают всеми свойствами тупиковых зон, и кроме этого
позволяют располагать внутри них ASBR маршрутизаторы.
Для распространения внешних маршрутов в пределах зоны NSSA был
добавлен 7 тип LSA сообщений. Сообщения данного типа объявляются ASBR
маршрутизаторами и распространяются в приделах зоны NSSA. На погранич-
ном маршрутизаторе все LSA 7 типа преобразуются в 5 тип LSA сообщений и
распространяются по всему домену маршрутизации OSPF. Процесс распро-
странения внешних маршрутов в зоне NSSA и за ее пределами показан на ри-
сунке 14.5.
Зона 1 (NSSA) Зона 0 (Backbone )
Внешняя AS
ASBR ABR BBone
LSA 7 LSA 5
Рисунок 14.5 – Распространение внешнего маршрута

в зоне NSSA и за ее пределами
14.5.1 Настройка не совсем тупиковой зоны
Чтобы настроить стандартную зону протокола OSPF как зону NSSA

необходимо в режиме конфигурации процесса маршрутизации воспользоваться
командой area nssa. Синтаксис команды приводится в примере 14.6.
252
Пример 14.6 – Синтаксис команды area nssa
(config-router)# area area-id [no-redistribution] [default-information-origin-
ate [metric] [metric-type]][no-summary]
(config-router)# no area area-id [no-redistribution] [default-information-ori-
ginate [metric] [metric-type]][no-summary]
Описание параметров команды area nssa приводиться в таблице 14.2.
Таблица 14.2 – Параметры команды area nssa
no-redistribution Параметр устанавливается в тех случа-
ях, когда ABR и ASBR маршрутизато-
ры совпадают и требуется распростра-
нение импортированных маршрутов
только в стандартные зоны OSPF.
default-information-originate Распространение маршрута по умолча-
нию при помощи сообщений LSA 7
типа.
metric Метрика маршрута.
metric-type Тип маршрута.
no-summary Полностью тупиковая зона NSSA
router ospf 200

area 1 nssa
default -information-originate
Зона 1 (NSSA) Зона 0 (Backbone)
RIPv 2
R1 R2 BBone
router ospf 200

redistribute rip metric 200 subnets
default metric 150
area 1 nssa
Рисунок 14.6 – Пример настройки NSSA зоны
На рисунке 14.6 приведен пример настройки NSSA зоны маршрутиза-

тор R1 является ASBR маршрутизатором, который производит импорт марш-
рутной информации из протокола RIP в зону NSSA.
253
Маршрутизатор R2 является ABR маршрутизатором, он объявляет
маршрут по умолчанию для NSSA зоны, а также производит замену сообще-
ний LSA 7 типа на сообщения LSA 5 типа для дальнейшего распространения
внешних маршрутов в магистральную зону домена маршрутизации OSPF.
Необходимо обратить внимание на то, что команда area nssa присут-
ствует в настройках всех маршрутизаторов входящих в зону NSSA.
14.5.2 Настройка полностью тупиковой зоны NSSA
Подобно возможности создания полностью тупиковых зон корпорация

Cisco добавила возможность создания полностью тупиковых зон NSSA. Пол-
ностью тупиковые зоны NSSA обладают всеми свойствами зон NSSA, а также
свойством полностью тупиковых зон не пропускать межзональные маршру-
ты.
router ospf 200

area 1 nssa no-summary
default -information-originate
Зона 1 (NSSA) Зона 0 (Backbone)
RIPv 2
R1 R2 BBone
router ospf 200

redistribute rip metric 200 subnets
default metric 150
area 1 nssa
Рисунок 14.7 – Пример настройки полностью тупиковой зоны NSSA
На рисунке 14.7 приводится пример настройки ABR маршрутизатора

NSSA зоны. Объявить зону NSSA как полностью тупиковую можно добавив
команду area nssa, на все маршрутизаторах входящих в зону, а на ABR марш-
рутизаторе добавить к команде ключевое слово no-summary. Необходимо по-
мнить, что данное ключевое слово применяется только на ABR маршрутиза-
торе. Другие маршрутизаторы NSSA зоны не требуют указания ключевого
слова no-summary.
14.6 Проверка функционирования специальных зон протокола OSPF
Для проверки корректной работы специальных зон протокола OSPF

необходимо воспользоваться рядом ранее описанных команд, таких как show
ip ospf, show ip ospf database и show ip route.
254
Еще одной полезной командой для проверки функционирования прото-
кола OSPF при разделении домена маршрутизации на несколько зон, является
команда show ip ospf border-router. Данная команда отображает все ABR и
ASBR маршрутизаторы находящиеся в переделах зоны OSPF. Информация,
выводимая данной командой, представлена в примере 14.7.
Пример 14.7 – Информация, выводимая командой show ip ospf border-

router
r2#show ip ospf border-routers
OSPF Process 109 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 192.168.97.53 [10] via 172.16.1.53, Serial0, ABR, Area 0.0.0.1, SPF 3

i 192.168.103.51 [10] via 192.168.96.51, Serial0, ABR, Area 0.0.0.1, SPF 3
I 192.168.103.52 [22] via 192.168.96.51, Serial0, ASBR, Area 0.0.0.1, SPF 3
I 192.168.103.52 [22] via 172.16.1.53, Serial0, ASBR, Area 0.0.0.1, SPF 3
Описание выводимой командой show ip ospf border-router приводится в

таблице 14.3.
Таблица 14.3 – Описание информации выводимой командой show ip

ospf border-router
192.168.97.53 Идентификатор маршрутизатора.
[10] Стоимость канала до маршрутизатора.
via 172.16.1.53 IP адрес следующего маршрутизатора
на пути к пограничному маршрутиза-
тору.
Serial0 Выходной интерфейс на пути к марш-
рутизатору.
ABR Тип пограничного маршрутизатора.
Area 0.0.0.1 Идентификатор зоны.
SPF Номер запуска алгоритма SFP на кото-
ром был добавлен этот маршрутиза-
тор.
255
15 Виртуальные каналы в протоколе OSPF
Главным правилом при разделении домена маршрутизации OSPF на

несколько зон, является то, что любые две зоны в протоколе OSPF должны
быть соединены через магистральную зону 0 (Рисунок 15.1).
ABR ABR
Рисунок 15.1 – Правило разделения домена маршрутизации OSPF на зоны
Из рисунка 15.1 видно, что в протоколе OSPF стандартные зоны не мо-

гут быть соединены между собой через пограничный маршрутизатор. В неко-
торых случаях становиться необходимо, создать новую зону в домене марш-
рутизации, однако организовать прямое соединение с магистральной зоной
либо невозможно, либо организация канала требует значительного времени.
В таких случаях для обеспечения соединения с магистральной зоной
можно создать виртуальный канал. Виртуальный канал задает логический
путь между новой и магистральной зонами. Виртуальный канал может пред-
ставлять собой как временное, так и постоянное решение обеспечения связно-
сти с магистральной зоной.
Виртуальный канал должен удовлетворять двум требованиям:
– Виртуальный канал устанавливается между двумя ABR маршрутиза-
торами, принадлежащим одной стандартной зоне домена маршрутизации.
– Один из двух ABR маршрутизаторов должен иметь непосредственное
подключение к магистральной зоне, другой к вновь создаваемой зоне.
Пример организации виртуального канала приводиться на рисунке 15.2.
Виртуальный канал
ABR ABR
Рисунок 15.2 – Виртуальный канал OSPF
Виртуальные каналы являются частью стандартной реализации прото-

кола OSPF и поддерживаются ОС Cisco IOS, начиная с версии 10.0. На рисун-
256
ке 15.2 виртуальный канал организуется между ABR маршрутизаторами R1 и
R2. Виртуальный канал подобен стандартному отношению соседства в прото-
коле OSPF, однако, в виртуальном канале маршрутизаторы не имеют непо-
средственного соединения между собой и по нему не может передаваться
пользовательский трафик.
Протокол обмена Hello пакетами работает по виртуальным каналам, так
же как и по обычным каналам связи. Промежуток рассылки Hello пакетов со-
ставляет 10 секунд. Рассылка LSA пакетов производится каждые 30 минут,
однако LSA пакеты, полученные по виртуальным каналам, имеют опцию
DNA (Do Not Age). Если у LSA пакета установлена опция DNA, он не имеет
возраста, т.е. не может устареть. Технология DNA позволяет снизить рассыл-
ку LSA пакетов по виртуальным каналам.
15.1 Настройка виртуальных каналов
Для настройки виртуального канала между двумя маршрутизаторами

используется команда area virtual-link. Синтаксис команды приводится в при-
мере 15.1.
Пример 15.1 – Синтаксис команды area virtual-link

(config-router)# area area-id virtual-link router-id [authentication [message–
digest | null]] [hello-interval seconds] [retransmit–interval seconds] [trans-
mit–delay seconds] [dead–interval seconds] [[authentication–key key] | [mes-
sage–digest–key key–id md5 key]]
(config-router)# no area area-id virtual-link router-id [hello-interval
seconds] [retransmit–interval seconds] [transmit–delay seconds] [dead–interval
seconds] [[authentication–key key] | [message–digest–key key–id md5 key]]
Описание параметров команды area virtual-link приводиться в таблице

15.1.
Таблица 14.2 – Параметры команды area nssa
area-id Номер зоны OSPF, по которой прохо-
дит виртуальный канал.
router-id Идентификатор маршрутизатора на
противоположной стороне виртуально-
го канала.
257
authentication Определяет метод аутентификации. По
умолчанию применяется аутентифика-
ция по паролю.
message-digest Аутентификация алгоритмом MD5.
null Аутентификация не используется.
hello-interval seconds Таймер рассылки Hello пакетов по вир-
туальному каналу.
По умолчанию 10 сек.
retransmit-interval seconds Таймер повторной передачи записей
LSA по виртуальному каналу.
transmit-delay seconds Предполагаемое время необходимое
для передачи одного сообщения LSA
по виртуальному каналу.
dead-interval seconds Таймер поддержания соседских отно-
шений по виртуальному каналу.
authentication-key key Ключ аутентификации при аутентифи-
кации по паролю.
message-digest-key key-id md5 key Номер ключа и ключ аутентификации
при использовании MD5.
Из таблицы 15.1 видно что, для задания виртуального канала необходи-

мо знать идентификаторы маршрутизаторов, между которыми устанавливает-
ся виртуальный канал. Идентификатор маршрутизатора можно узнать с помо-
щью команды show ip ospf или show ip protocol.
При настройке виртуальных каналов, так же как и соседних маршрути-
заторов, следует помнить, что при изменении стандартных таймеров, для кор-
ректной работы протокола OSPF необходимо соблюдать соотношение тайме-
ра рассылки Hello пакетов и таймера поддержания соседских отношений.
Подобно применению аутентификации соседних маршрутизаторов при
установке соседских отношений по каналам связи, в маршрутизаторах Cisco
для протокола OSPF предусмотрена возможность аутентификации соседних
маршрутизаторов при установке соседских отношений по виртуальным кана-
лам. Возможно применение двух методов аутентификации, как по паролю,
так и с помощью MD5.
258
15.1.2 Примеры использования виртуальных каналов
Виртуальные каналы в протоколе OSPF чаще всего используются в

двух ситуациях:
1. Для соединения вновь создаваемой зоны в домене маршрутизации
OSPF с магистральной зоной, если это невозможно сделать стандартным
способом (Рисунок 15.3).
2. Для обеспечения связности магистральной зоны (Рисунок 15.4).
R2 R1

router-id 2.2.2.2 router-id 1.1.1.1
area 1 virtual-link 1.1.1.1 area 1 virtual-link 2.2.2.2
Рисунок 15.3 – Использование виртуального канала для соединения стандарт-

ной и магистральной зоны OSPF
Чтобы обеспечить соединение с магистральной сетью, необходимо

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

router-id 2.2.2.2 router-id 1.1.1.1
area 1 virtual-link 1.1.1.1 area 1 virtual-link 2.2.2.2
Рисунок 15.4 – Использование виртуального канала для обеспечения связно-

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

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

OSPF применяется несколько команд.
Команда show ip ospf virtual-links выводит полную информацию о на-
строенных виртуальных каналах. Информация, выводимая данной командой,
представлена в примере 15.2.
Пример 15.2 – Информация, выводимая командой show ip ospf virtual-

links
r1# show ip ospf virtual–links
Virtual Link to router 10.2.2.2 is up
Transit area 0.0.0.1, via interface Ethernet0, Cost of using 10

Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured. Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 0:00:08 Adjacency State FULL
Маршрутизаторы устанавливают соседские отношения и производят

обмен LSA пакетами по виртуальным каналам точно также как и по физиче-
ским каналам, однако, команда show ip ospf neighbors не показывает сосед-
ские отношения установленные по виртуальному каналу.
Для того чтобы увидеть наличие соседских отношений установленных
по виртуальным каналам необходимо просмотреть таблицу топологии марш-
рутизатора с помощью команды show ip ospf database с параметром router.
Данная команда отобразит все записи в таблице топологии, которые были
объявлены маршрутизатором с указанным RID. Информация, выводимая дан-
ной командой, представлена в примере 15.3.
В наборе инструментов для отладки работы виртуальных каналов про-
токола OSPF также используется команда debug ip ospf adj. Данная команда
отображает процесс установки соседских отношений по виртуальному кана-
лу. Информация, выводимая данной командой, представлена в примере 15.4.
260
Пример 15.3 – Информация, выводимая командой show ip ospf database
router
rl# show ip ospf database router 3.3.3.3
Routing Bit Set on this LSA
LS age: 5 (DoNotAge)
Options: (No TOS–capability, DC)
LS Type: Router Links
Link State ID: 3.3.3.3
Advertising Router: 3.3.3.3
LS Seq Number: 80000002
Checksum: 0x3990
Length: 36
Area Border Router
Number of Links: 1
Link connected to: a Virtual Link

(Link ID) Neighboring Router ID: 1.1.1.1
(Link Data) Router Interface address: 6.0.0.3
Number of TOS metrics: 0
TOS 0 Metrics: 65
Пример 15.4 – Информация, выводимая командой debug ip ospf adj

lw2d: OSPF: Rev hello from 1.1.1.1 area 0 from 0SPF_VL3 5.0.0.1
lw2d: OSPF: 2 Way Communication to 1.1.1.1 on OSPF_VL3, state 2WAY
lw2d: OSPF: Send DBD to 1.1.1.1 on OSPF_VL3 seq 0xD1C opt 0x62 flag 0x7 len 32
lw2d: OSPF: End of hello processing
lw2d: OSPF: Rev DBD from 1.1.1.1 on OSPF_VL3 seq 0x1617 opt 0x22 flag 0x7 len
32 mtu 0 state EXSTART
lw2d: OSPF: First DBD and we are not SLAVE
lw2d: OSPF: Rev DBD from 1.1.1.1 on OSPF_VL3 seq OxDIC opt 0x22 flag 0x2 len
17 2 mtu 0 state EXSTART
lw2d: OSPF: NBR Negotiation Done. We are the MASTER
lw2d: OSPF: Send DBD to 1.1.1.1 on OSPF_VL3 seq 0xD1D opt 0x62 flag 0x3 len
172
lw2d: OSPF: Database request to 1.1.1.1
lw2d: OSPF: sent LS REQ packet to 5.0.0.1, length 36
lw2d: OSPF: Rev DBD from 1.1.1.1 on OSPF_VL3 seq 0xD1D opt 0x22 flag 0x0 len
32 mtu 0 state EXCHANGE
lw2d: OSPF: Send DBD to 1.1.1.1 on OSPF_VL3 seq 0xD1E opt 0x62 flag 0x1 len 32
lw2d: OSPF: Rev DBD from 1.1.1.1 on OSPF_VL3 seq 0xD1E opt 0x22 flag 0x0 len
32 mtu 0 state EXCHANGE
lw2d: OSPF: Exchange Done with 1.1.1.1 on OSPF_VL3
lw2d: OSPF: Synchronized with 1.1.1.1 on 0SPF_VL3, state FULL
lw2d: OSPF: Build router LSA for area 0, router ID 3.3.3.3, seq 0x80000029
lw2d: OSPF: Dead event ignored for 1.1.1.1 on demand circuit OSPF_VL3
261
16 Перераспределение маршрутной информации
16.1 Понятие перераспределения маршрутной информации
В некоторых ситуациях бывает необходимо использовать несколько

протоколов маршрутизации на одном маршрутизаторе. Наиболее распростра-
ненными причинами являются:
– Происходит объединение двух сетей передачи данных, а маршрутиза-
ция в них обеспечивается с помощью различных протоколов маршрутизации.
Если одна из сетей передачи данных перед объединением полностью не пере-
водится на протокол маршрутизации, используемый в другой сети, то в дан-
ной ситуации, по крайней мере, на граничных маршрутизаторах объединяе-
мых сетей передачи данных должны быть запущены оба протокола маршру-
тизации. Для обеспечения связи между данными сетями, пограничные марш-
рутизаторы должны проводить преобразование маршрутной информации
между двумя протоколами маршрутизации.
– Сеть передачи данных переводится с одного протокола маршрутиза-
ции на другой. Если миграция не производиться на всех маршрутизаторах од-
новременно, то на некоторых ключевых маршрутизаторах оба протокола
маршрутизации должны сосуществовать определенное время, которое потре-
буется для полного перехода на новый протокол маршрутизации. В этом слу-
чае, чтобы обеспечить связь между частью сети, которая уже была переведена
на новый протокол маршрутизации, и частью, где это еще не сделано, ключе-
вые маршрутизаторы должны не только позволять сосуществовать обоим
протоколам маршрутизации, но также и выполнять преобразование маршрут-
ной информации между этими протоколами маршрутизации.
– В сети передачи данных могут существовать сервера или рабочие
станции, которым необходимо участвовать в процессе динамической маршру-
тизации, без объявления собственной маршрутной информации. Примером
подобной ситуации могут выступать сервера под управлением ОС Unix или
Windows, которые используют протокол маршрутизации RIP, а сеть передачи
данных реализована на маршрутизаторах Cisco, на которых запущен протокол
маршрутизации EIGRP. В такой ситуации маршрутизаторы, которые подклю-
чены к сегментам сети, в которых имеются интеллектуальные хосты, должны
конвертировать маршрутную информацию протокола EIGRP в протокол RIP.
Существует значительно больше случаев, требующих работы несколь-
ких протоколов маршрутизации на одном маршрутизаторе. Не вдаваясь в по-
дробности каждой из таких ситуаций, очевидно, что все они налагают одно
требование: помимо простого сосуществования, протоколы маршрутизации
должны обмениваться маршрутной информацией.
262
Простого исполнения нескольких протоколов маршрутизации на одном
и том же маршрутизаторе недостаточно для обмена маршрутной информаци-
ей между этими протоколами.
Маршрутизаторы автоматически не производят обмен маршрутной ин-
формации между протоколами маршрутизации запущенными на них. Причи-
на этого заключается в том, что несколько протоколов маршрутизации, даже
присутствуя на одном маршрутизаторе, могут выполнять различные задачи.
Следовательно, обмен маршрутной информацией между ними может быть не-
желателен.
Другой причиной того, что несколько протоколов маршрутизации запу-
щенные на одном маршрутизаторе не обмениваются маршрутной информаци-
ей автоматически, является то, что различные протоколы маршрутизации по-
разному рассчитывают метрики маршрутов, вследствие чего эти метрики не-
совместимы. Например, протоколом RIP в качестве метрики используется ко-
личество переходов до сети получателя, тогда как протокол EIGRP использу-
ет комбинированную метрику. Метрика является одним из важнейших пара-
метров маршрута рассматриваемых протоколом маршрутизации при построе-
нии таблицы маршрутизации. Поскольку метрики несовместимы, не суще-
ствует простого способа адекватно преобразовывать метрики маршрутов рас-
считанных различными протоколами маршрутизации. Неадекватное преоб-
разование может с большой вероятностью привести к возникновению марш-
рутных петель.
Процесс преобразования маршрутной информации между различными
ее источниками называется перераспределением маршрутной информации
(routing information redistribution) или просто перераспределением.
Источники маршрутной информации не ограничиваются динамически-
ми протоколами маршрутизации. Они также включают статические и присо-
единенные маршруты. Однако статические и присоединенные маршруты мо-
гут быть лишь источником маршрутной информации для перераспределения.
По очевидным причинам перераспределение не может производиться в стати-
ческие и присоединенные маршруты.
Включение перераспределения на маршрутизаторе обычно предполага-
ет указание трех следующих компонентов:
– Источника маршрутной информации, которая должна быть перерас-
пределена.
– Получателя маршрутной информации в виде протокола маршрутиза-
ции, в который перераспределяется маршрутная информация.
– Метрик, которые должны использоваться протоколом маршрутизации
при объявлении в домен маршрутизации динамического протокола перерас-
пределенной маршрутной информации.
Последний компонент сводиться, как правило, к указанию одной или
нескольких фиксированных метрик, которые должны использоваться прото-
колом маршрутизации при объявлении перераспределенной маршрутной ин-
263
формации. Если указана лишь одна метрика, протокол маршрутизации будет
использовать ее для всех перераспределяемых сетей получателей, а если ука-
зано несколько, протокол маршрутизации использует каждую из них для ин-
дивидуального подмножества перераспределяемых сетей получателей в соот-
ветствии с отдельно указанными правилами.
Перераспределение маршрутной информации необязательно должно
быть двухсторонним. Если информация одного протокола маршрутизации
перераспределяется в другой, информация последнего не обязательно должна
перераспределяться в первый. Возможно, а в некоторых случаях и желатель-
но перераспределение маршрутной информации только из одного протокола
в другой, но не наоборот.
В качестве примера можно рассмотреть такую ситуацию. В сети переда-
чи данных имеется область, в которой маршрутизация осуществляется при
помощи устаревшего сетевого оборудования, на котором не может быть раз-
вернут основной протокол маршрутизации применяемый в корпоративной
сети передачи данных. В данной ситуации маршрутная информация должна
быть перераспределена из данного сегмента в общий домен маршрутизации, а
обратное перераспределение может привести к перегрузке маршрутной ин-
формацией сетевого оборудования расположенного внутри данной области. В
данном случае обеспечение маршрутной информацией о внешних сетях полу-
чателях маршрутизаторов внутри области, может быть выполнено распро-
странением маршрута по умолчанию на граничный маршрутизатор области,
который обладает полной маршрутной информацией.
16.2 Понятие метрического домена
Различные протоколы маршрутизации используют различные алгорит-

мы расчета метрик. Независимо от конкретного алгоритма расчета метрики,
метрики всех протоколов маршрутизации обладают одним общим свойством
– они увеличиваются с увеличением количества переходов на пути от сети
получателя.
Формально накопительный характер метрики можно описать выраже-
нием (16.1).
∀ d и d` где d`>d, M(d`)>M(d) (16.1)
где d и d` – количество переходов на пути от сети получателя,

M(x) – функция метрики.
Учитывая это общее свойство метрик протоколов маршрутизации,

определим метрический домен протокола маршрутизации как часть сети
передачи данных, в которой метрики протокола маршрутизации отражают
264
расстояние до сети получателя, и удовлетворяют выражению (16.1). Метрики
рассчитываются в соответствии с алгоритмом, предписанным запущенным на
маршрутизаторах протоколом маршрутизации. Другими словами, любой
маршрутизатор в пределах метрического домена протокола маршрутизации
рассчитывает метрики маршрутов до сетей получателей, находящихся в пре-
делах метрического домена, в соответствии с алгоритмом, предписанным
протоколом маршрутизации. Если маршрутизатор использует любой другой
алгоритм для расчета метрики маршрута до сети получателя, то этот маршру-
тизатор находится за пределами метрического домена, которому принадле-
жит сеть получатель.
172 .16.14.0/28 17
R2 2.
16
.14
.4
8/2
8
172 .16.14.64/28 192 .168 .1.0/28

172 .16.14.16/28
R3
R1 R5
8
0/2
.8
.14
16
2.
172 .16.14.32/28 17
R4
Домен 172.16.0.0 Домен 192.168.1.0
RIP v1
Рисунок 16.1 – Пример метрического домена
Примером метрического домена (Рисунок 16.1) протокола RIP v1 яв-

ляется непрерывная группа сегментов, подсети которых принадлежат одной и
той же классовой сети. Граница такого метрического домена для протокола
RIP пролегает по маршрутизатору R1, который, кроме того, имеет подключе-
ние к сегменту, принадлежащему другой классовой сети.
Как мы знаем, при формировании маршрутных обновлений протоколом
RIP, которые должны быть отправлены, через интерфейсы, принадлежащие
другой классовой сети, маршрутизатор производит автоматическое суммиро-
вание маршрутов до маршрута на классовую сеть, метрику которого устанав-
ливает равной 1, отбрасывая тем самым накопленную информацию о метри-
ках частных маршрутов. Очевидно, что любой маршрутизатор не принадле-
жащий классовой сети 172.16.0.0, может получать только суммарный марш-
рут на классовую сеть, а не частные маршруты до сетей получателей. Такие
маршрутизаторы будут воспринимать любую сеть получатель в пределах дан-
ного метрического домена с одной метрикой – той, которая имеется у них для
данной классовой сети. Маршрутизаторы принадлежащие другой классовой
сети больше не вычисляют метрики маршрутов, до сетей получателей в пре-
делах данного метрического домена в соответствии с алгоритмом протокола
265
RIP, а значит, такие маршрутизаторы находятся за пределами метрического
домена 172.16.0.0.
Приведенный выше пример представляет собой естественную границу
метрического домена, обусловленную суммированием маршрутов до сетей
получателей на границе классовой сети.
Граница метрического домена также создается на маршрутизаторах вы-
полняющих, перераспределение маршрутной информации, которое заменяет
накопленные метрики одной или несколькими фиксированными метриками.
В зависимости от протокола маршрутизации, перераспределение может, со-
провождаться или не сопровождаться суммированием маршрутов. Если оно
сопровождаются суммированием, полученная граница метрического домена
не отличается от естественной границы. В обратном случае граница носит
полностью искусственный характер – частные маршруты пересекают границу
не измененным, но их метрики заменяются на фиксированную величину.
Искусственные границы метрических доменов могут негативно влиять
на работу сети передачи данных, создавая маршрутные петли.
16.3 Маршрутные петли
Маршрутные петли (routing loops) представляют собой маршруты в сети

передачи данных, которые приводят на один и тот же маршрутизатор более
одного раза. Маршрутные петли крайне не желательны, поскольку трафику
приходится преодолевать дополнительный путь лишь для того, чтобы при-
быть на тот же самый маршрутизатор. Это в свою очередь приводит к задерж-
ке трафика, или даже к полной невозможности его доставки сетям получате-
лям. Маршрутные петли подвергают сеть передачи данных избыточной на-
грузке и приводят к огромному количеству операций по обработке поступаю-
щего трафика на причастных маршрутизаторах.
Маршрутные петли могут быть классифицированы как:
Короткоживущие маршрутные петли – петли существующие непродол-
жительное время, обычно не более пары минут.
Долгоживущие маршрутные петли – петли существующие продолжи-
тельное время, от нескольких минут до бесконечности.
Возникновение короткоживущих маршрутных петель обусловлено про-
цессами, происходящими во время схождения сети, после произошедших в
ней изменений. Время возможного существования таких маршрутных петель
зависит от скорости схождения сети и от протокола маршрутизации применя-
емого в сети передачи данных. Короткоживущие маршрутные петли имеют
возможность самоустраняться за определенный, не продолжительный период
времени.
Возникновение долгоживущих маршрутных петель обусловлено ошиб-
ками в настройке процесса маршрутизации внутри домена маршрутизации.
266
Обычно долгоживущие маршрутные петли не исчезают, если не принять мер
к устранению тех ошибок в процессе маршрутизации которые привели к их
возникновению. Долгоживущие маршрутные петли могут быть как постоян-
ными, так и периодическими. Постоянные маршрутные петли существую все
время, тогда как периодические проходят через циклы, исчезая и появляясь
вновь.
Протоколы маршрутизации разрабатываются самостабилизирующими-
ся. Тогда как временная нестабильность, вызываемая изменениями в тополо-
гии сети передачи данных и часто сопровождаемая короткоживущими марш-
рутными петлями, зачастую неизбежна. Протоколы маршрутизации преодо-
левают нестабильность и устанавливают маршрутизацию без петель. Ни один
протокол маршрутизации не спроектирован так, чтобы позволить долгоживу-
щим маршрутным петлям образоваться в какой-либо момент работы.
Все протоколы маршрутизации базируются на математических моде-
лях, для которых доказано, что они не вызывают появление долгоживущих
маршрутных петель. Большинство этих математических моделей обеспечива-
ют функционирование без образование петель, посредством соблюдения
условия, что метрики, связанные с местами назначения, растут с добавлением
каждого дополнительного перехода на пути к месту назначения.
Формально можно описать, что если маршрутизатор R1 выбирает
маршрут до сети получателя D через маршрутизатор R2, то M1>M2, где M1 и
M2 являются метриками маршрута до сети получателя D маршрутизаторов
R1 и R2 соответственно. Другими словами, чем дальше место назначения, тем
больше метрика. Если это допущение соблюдается, маршрутная петля образо-
ваться не может.
Доказывается это просто. Будем считать, что в сети передачи данных N
все маршрутизаторы выбирают маршруты к сетям получателям на основе вы-
шеупомянутого допущения. Предположим, однако, что петля существует и
имеется маршрутизатор R1, установивший маршрут к сети получателю D че-
рез маршрутизатор R2, который в свою очередь установил маршрут к D через
маршрутизатор R3, и так далее до маршрутизатора Rn, установившего марш-
рут к D через маршрутизатор R1. Такая ситуация показана на рисунке 16.2.
Как мы предположили, допущение соблюдается, следовательно, метри-
ки всех маршрутов должны соответствовать неравенству (16.2).
M1 > M2 > M3 … Mn-2 > Mn-1 >Mn >M1 (16.2)
Неравенство (16.2) сводится к M1 > M1. Следовательно, наша исходная

предпосылка о том, что петля может существовать даже в том случае, если
все маршрутизаторы соблюдают принятое допущение, неверна.
267
R2
M2
M1
R1 R3
M3
Mn Mn-2
Rn Rn-1
Mn-1
Mn-1
Рисунок 16.2 – Предположение об образовании маршрутной петли
Маршрутные петли не возникают в сети передачи данных, в которой

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

ным источником маршрутных петель может быть одна точка одностороннего
перераспределения маршрутной информации.
Маршрутизатор R1 объявляет сети получатели, имеющиеся в части сети
передачи данный N1 с использованием протокола маршрутизации RP1 марш-
рутизатору R2, который затем перераспределяет эти сети получатели в прото-
кол маршрутизации RP2. Маршрутизатор R2 объявляет перераспределенные
сети получатели своим соседям, находящимся в части сети передачи данных
N2. Административное расстояние протокола маршрутизации RP1 равно A1,
а административное расстояние протокола маршрутизации RP2 равно A2.
Административные расстояния таковы, что A2<A1.
268
4 M=N
M=N 3
R4
R1 M =M1 R2
M=
N1
R3 M=N
2
Сеть N1, Сеть N2,

Протокол маршрутизации RP1, Протокол маршрутизации RP2,
Административноерасстояние RP1 = A1 Административноерасстояние RP2 = A2
A1>A2 A2<A1
Рисунок 16.3 – Образование маршрутной петли при одностороннем

перераспределении маршрутной информации
Стрелки внутри N2 показывают поток маршрутных обновлений, кото-

рый, если имеет место, приводит к образованию маршрутной петли для сетей
получателей из N1 внутри N2.
Сначала обсудим сценарий, приводящий к маршрутным петлям, а затем
причины, вызывающие запуск такого сценария.
Маршрутизатор R1 отправляет маршрутное обновление, содержащие
сети получатели, расположенные в N1, маршрутизатору R2. Маршрутизатор
R2 получает маршрутное обновление, устанавливает маршрут к объявленным
сетям получателям и производит перераспределение полученной маршрутной
информации в протокол маршрутизации RP2, средствами которого затем объ-
являет эти сети получатели своим соседям в N2.
Предположим, что сосед R3 получает маршрутное обновление маршру-
тизатора R2 и устанавливает свои маршруты к объявленным сетям получате-
лям через R2. После этого маршрутизатор R3 сам начинает объявлять данные
сети получатели своим соседям. В конечном итоге это маршрутное обновле-
ние поступает на маршрутизатор R4,который после установки маршрутов к
этим сетям получателям, начинает объявлять их средствами протокола марш-
рутизации RP2 маршрутизатору R2.
Теперь маршрутизатор R2 должен заменить существующие у него
маршруты к этим сетям получателям, указывающие на маршрутизатор R1, на
новые маршруты, указывающие на R4. Поскольку маршрутизатор R1 объявил
их средствами протокола маршрутизации RP1, тогда как маршрутизатор R4
объявляет их средствами PR2, административное расстояние которого мень-
ше чем у PR1.
У этого сценария есть небольшое упущение: маршрутизатор R2 должен
объявить сети получатели, полученные им от маршрутизатора R1 всем своим
соседям практически одновременно. То есть маршрутизатор R4 получить пер-
вое маршрутное обновление, содержащие данные сети получатели, от марш-
рутизатора R2, после чего он должен установить свои маршруты до сетей по-
лучателей в N1 через маршрутизатор R2. С этого момента он должен откло-
269
нять все другие маршрутные обновления, если они имеют метрику, большую
метрики маршрутов, пролегающих через маршрутизатор R2.
Несмотря на это упущение, данный сценарий вполне реален и может
наступить, особенно если этому будут способствовать некоторые дополни-
тельные факторы.
– Маршрутизатор R2 может не отправить маршрутное обновление всем
своим соседям одновременно. Он может запланировать сначала отправку
маршрутной информации маршрутизатору R3 и только после этого маршру-
тизатору R4. Если промежуток времени между передачей маршрутных обнов-
лений маршрутизаторам R3 и R4 достаточно велик, маршрутизатор R4 может
получить маршрутное обновление от другого соседа, в этом случае он объ-
явит сети получатели из N1 маршрутизатору R2, что приведет к установке для
них ложных маршрутов.
– Стоимость канала связи между маршрутизаторами R2 и R4 настолько
велика, что маршрутизатор переключиться на какой-либо другой маршрут,
даже если он перед этим установил маршрут до сетей получателей в N1 через
маршрутизатор R2. Если это произойдет, маршрутизатор произведет объявле-
ние сетей получателей маршрутизатору R2, что приведет к удалению истин-
ных и установке ложных маршрутов маршрутизатором R2.
– Если в какой-то момент времени после первоначального объявления
маршрутной информации о сетях получателях расположенных в N1, произой-
дет временное отключение канала связи между маршрутизаторами R2 и R4,
маршрутизатор R4 установит маршруты до N1 через другого соседа. При
восстановлении канала связи маршрутизатор R4 произведет объявление
маршрутной информации маршрутизатору R2, что приведет к образованию
маршрутной петли.
Это наиболее вероятные факторы, способствующие возникновению
маршрутных петель.
Независимо от того, какие обстоятельства привели к переключению
маршрутов маршрутизатором R2, далее события будут развиваться следую-
щим образом:
1. После изменения маршрутизатором R2 направления маршрутов к се-
тям получателям их N1, он перестает использовать при объявлении этих сетей
метрику назначенную при перераспределении, а вместо нее использует мет-
рику которую он получил от маршрутизатора R4, увеличенную на стоимость
канала связи до маршрутизатора R4. Эта метрика выше, чем метрика полу-
ченная при перераспределении, поскольку она представляет собой эту исход-
ную метрику, увеличенную на стоимость каналов связи между маршрутизато-
рами R3 и R4.
2. Когда маршрутизатор R3 обнаружит увеличение метрики, объявляе-
мой маршрутизатором R2, он замораживает свои маршруты, и начинает объ-
являть эти сети получатели с метрикой, равной бесконечности.
270
3. С этого момента события могут развиваться различными путями,
каждый из которых приведет к тому, что маршрутизаторы R4 и R2 заморозят
ложные маршруты.
4. Когда период замораживания на маршрутизаторе R2 пройдет, марш-
рутизатор сможет восстановить правильные маршруты до сетей получателей
расположенных за маршрутизатором R1, которые вскоре после этого могут
быть снова вытеснены ложными маршрутами. Если правильные маршруты
вытесняются, то повторяется описанный процесс, который может продол-
жаться бесконечно долго.
Описанная конфигурация сети подвержена возникновению маршрут-
ных петель. Следующие факторы еще более ухудшают негативный эффект
описанных маршрутных петель:
– Такие петли могут возникать не сразу. Вместо этого они могут быть
вызваны каким-либо событием. Очевидно, что это может произойти в самый
неподходящий момент.
– Эти петли могут периодически возникать либо бесконечно, либо огра-
ниченное количество раз. Диагностика периодических маршрутных петель
белее сложная задача, чем диагностика постоянных.
16.3.2 Двухсторонние перераспределение маршрутной информации
В отличие от случая с односторонним перераспределением маршрутной

информации, приводящим к образованию периодических маршрутных пе-
тель, двухсторонние перераспределение маршрутной информации обычно
приводят к постоянным маршрутным петлям. Рассмотрим сеть, показанную
на рисунке 16.4.
4 M=N
M=N 3
R4
0
M=M
R5
R1
M =M
1
R2
M=
N1
R3 M=N
2
Сеть N1, Сеть N2,

Протокол маршрутизации RP1, Протокол маршрутизации RP2,
Административноерасстояние RP1 = A1 Административноерасстояние RP2 = A2
A1>A2 A2<A1
Рисунок 16.4 – Образование маршрутной петли при двухстороннем

271
Эта сеть аналогична сети рассмотренной ранее на рисунке 16.3, за ис-
ключением того, что маршрутизаторы R2 и R5 выполняют двухсторонние
перераспределение между протоколами маршрутизации RP1 и RP2.
Предположим, маршрутизатор R1 отправляет маршрутное обновление,
содержащие сети получатели в пределах N1, маршрутизатору R2. Как и рань-
ше, маршрутизатор R2 получает это обновление, устанавливает маршруты к
данным сетям получателям, производит перераспределение полученной
маршрутной информации в протокол маршрутизации RP2 и начинает объяв-
лять перераспределенные маршруты своим соседям по RP2. Соседи R2 после
получения обновлений от маршрутизатора R2, начинают в свою очередь объ-
являть полученную маршрутную информацию своим соседям. В конечном
итоге данное маршрутное обновление поступает на маршрутизатор R4, кото-
рый после занесения в свою таблицу маршрутизации полученных маршрутов,
начинает объявлять данную маршрутную информацию маршрутизатору R5.
Маршрутизатор R5 заносит полученную информацию в таблицу маршрутиза-
ции, а затем производит ее перераспределение обратно в протокол маршрути-
зации RP1 и начинает объявлять эту маршрутную информацию в сети N1.
В нашем случае эти маршрутные обновления поступят на маршрутиза-
тор R1. Если метрика перераспределения, с которой маршрутизатор R5,
произвел перераспределение маршрутной информации в RP1, меньше метри-
ки, с которой маршрутизатор R1 изначально узнал об этих сетях получателях,
то он отбросит правильные маршруты и занесет в свою таблицу маршрутиза-
ции ложные маршруты через R5.
Насколько вероятно, что события будут развиваться так, как было опи-
сано? Ответ таков: очень вероятно. В отличие от сценария с одной точкой
перераспределения, этот сценарий не имеет упомянутого ранее упущения.
Последующие развитие событий полностью отличается от того, что
происходило в схеме с одной точкой перераспределения. После того как
маршрутизатор R1 установит ложные маршруты к сетям получателям, распо-
ложенным в N1 через маршрутизатор R5, он сменит метрики, с которыми он
ранее объявлял эти сети маршрутизатору R2. Вероятно, что эти новые метри-
ки будут меньше корректных, как минимум для части наиболее удаленных се-
тей получателей. Следовательно, маршрутизатор R2 на этот раз станет полу-
чать маршрутные обновления от маршрутизатора R1 с меньшими метриками.
Маршрутизатор R2 посчитает эти изменения в сети благоприятными, и не
станет замораживать маршруты до сетей получателей из N1 через маршрути-
затор R1.
Но поскольку маршрутизатор R2 производит перераспределение полу-
ченной от R1 маршрутной информации в N2 с фиксированной метрикой, то
он не станет производить рассылку обновлений маршрутной информации для
своих соседей по протоколу маршрутизации RP2. На этом завершается про-
цесс обмена изменениями в маршрутной информации. Сеть передачи данных
272
переходит в стабильное состояние, в котором образовавшееся маршрутная
петля будет существовать неопределенно долгое время.
На рисунке 16.5 показана общая схема сети, которая подвержена образо-
ванию маршрутной петли, вызванной двумя точками перераспределения марш-
рутной информации.
Метрики протоколов маршрутизации RP1 и RP2 вычисляются с исполь-
зованием различных алгоритмов, поэтому они обозначаются различными бук-
вами – M и N. Точки перераспределения маршрутизаторы RX1 и RX2 объяв-
ляют сети получатели с фиксированной метрикой перераспределения N* и M*
соответственно. Маршрутизаторы RX1 и RX2 установили свои маршруты к се-
тям получателям в M и N с метриками M0 и N0. Необходимо обратить внима-
ние на то, что маршрутизаторы RX1 и RX2 объявляют сети получатели в один
домен маршрутизации, тогда как их маршруты к этим сетям получателям ука-
зывают в другой домен маршрутизации.
M2 Mk
RM1 RMk
1
M
M
*
Сеть M,
Протокол маршрутизации RP1,
Административноерасстояние RP1 = A1
A1>A2
RX1 Сеть N, RX2

Протокол маршрутизации RP2,
Административноерасстояние RP2 = A2
A2<A1
N
1
*
Nk N2
RNk RN1
Рисунок 16.5 – Образование маршрутных петель

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

зывают на соответствующую точку перераспределения маршрутной информа-
ции - либо маршрутизатор RX1, либо RX2.
Маршрутизатор RX2 производит перераспределение маршрутной инфор-
мации протокола маршрутизации RP2 о сетях получателях из N в домен марш-
рутизации M протокола маршрутизации RP1 с метрикой M*. Далее эта инфор-
мация распространяется по домену маршрутизации M, в итоге поступая на
маршрутизатор RM1, который объявляет ее маршрутизатору RX1. Маршрути-
затор RX1 в свою очередь производит ее перераспределение обратно в домен
маршрутизации RP2 с метрикой N*, тем самым, отбрасывая накопленную про-
токолом RP2 маршрутную информацию о сетях получателях в домене N, и об-
разуя маршрутную петлю.
273
С маршрутной информацией домена маршрутизации M после ее перерас-
пределения в домен маршрутизации N производятся такие же действия.
16.3.3 Протоколы маршрутизации подверженные образованию марш-

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

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

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

рутизации на одном и том же маршрутизаторе. В некоторых случаях это может
показаться неплохой идеей. Например, при планировании перехода с одного
протокола маршрутизации на другой, может потребоваться включить новый
протокол маршрутизации в «теневом режиме», т.е. установить административ-
ное расстояние большее, чем у основного протокола маршрутизации.
Хотя идея кажется неплохой, она вряд ли жизнеспособна, если в качестве
нового протокола маршрутизации выбран дистанционно-векторный протокол.
На самом деле дистанционно векторные протоколы маршрутизации могут объ-
являть только те сети получатели, которые были успешно внесены ими в свою
таблицу маршрутизации. В описанной ситуации, преднамеренно сделано так
чтобы маршруты нового протокола маршрутизации не попадали в таблицу
маршрутизации, следовательно, маршрутизаторы не смогут обмениваться
маршрутной информацией по новому протоколу маршрутизации, так как ис-
точником при обмене маршрутной информацией является таблица маршрутиза-
ции.
Может показаться, что протокол EIGRP не будет соблюдать описанное
ограничение, поскольку, в отличие от классических дистанционно-векторных
протоколов маршрутизации, в протоколе EIGRP, имеется таблица топологии, в
которой имеется вся необходимая информация для построения таблицы марш-
рутизации.
Рассмотрим, насколько сильно отличается поведение протокола EIGRP,
от других дистанционно-векторных протоколов маршрутизации в предложен-
ной ситуации. Для этого воспользуемся сетью передачи данных изображенной
на рисунке 17.1.
F0/0 172 .16.0.0/28 F0/0 F0/1 172 .16.0.16/28 F0/0 F0/1 172 .16.0.32/28
R1 R2 R3
r1# router eigrp 1 r2# router eigrp 1 r2# router eigrp 1

network 172.16.0.0 network 172.16.0.0 network 172.16.0.0
distance eigrp 130 170 distance eigrp 130 170 distance eigrp 130 170
! ! !
router rip router rip router rip
network 172.16.0.0 network 172.16.0.0 network 172.16.0.0
Рисунок 17.1 – Совместная работа двух протоколов маршрутизации

без перераспределения маршрутной информации
275
На всех маршрутизаторах входящих в сеть передачи данных параллельно
запущено два протокола маршрутизации – это протоколы RIP и EIGRP. Необ-
ходимо обратить внимание на то что, все маршрутизаторы имеют в своей кон-
фигурации строчку distance eigrp 130 170, которая устанавливает администра-
тивное расстояние протокола EIGRP равным 130, что больше административ-
ного расстояния протокола RIP, равного 120.
Рассмотрим таблицу маршрутизации маршрутизатора R1, показанную в
Пример 17.1 – Таблица маршрутизации маршрутизатора R1

r1#show ip route
R 172.16.0.32 [120/2] via 172.16.0.1, 00:00:18, FastEthernet0/0
C 172.16.0.0 is directly connected, FastEthernet0/0
Как и ожидалось, в таблице маршрутизации отсутствуют маршруты, по-

лученные при помощи протокола EIGRP.
Теперь рассмотрим таблицу топологии маршрутизатора R1, она пред-
ставлена в примере 17.2.
Пример 17.2 – Таблица топологии маршрутизатора R1

Router#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.0.2)
P 172.16.0.16/28, 0 successors, FD is Inaccessible

via 172.16.0.1 (30720/28160), FastEthernet0/0
via Connected, FastEthernet0/0
Таблица топологии содержит только две записи, одну о непосредственно

подключенной сети 172.16.0.0/28, и одну, полученную от соседнего маршрути-
затора R2, 172.16.0.16/28. Об остальных сетях находящихся в домене маршру-
тизации EIGRP, записи в таблице топологии отсутствуют.
Как видно из примера 17.2 маршрутизатор R2 объявляет сеть
172.16.0.16/28 маршрутизатору R1, с метрикой не равной бесконечности. Одна-
ко маршрутизатор R1, помечает данную запись как недоступную, поскольку
процессу маршрутизации EIGRP не удалось поместить данный маршрут в та-
блицу маршрутизации, так как там уже присутствует маршрут до этой сети с
меньшим административным расстоянием, полученный от протокола RIP.
Процессы EIGRP запущенные на других маршрутизаторах поступают
подобным образом. Они помечают как недоступные все сети, полученные в
маршрутных обновлениях, поступивших от соседних маршрутизаторов. По-
скольку сети получатели недоступны, маршрутизаторы не станут их объявлять
своим соседям.
276
Этот пример наглядно иллюстрирует, что независимо от наличия табли-
цы топологии в протоколе EIGRP его дистанционно-векторная природа не поз-
воляет использовать имеющуюся информацию.
Если удалить команду distance eigrp 130 170 из конфигурации маршрути-
затора R1, то он будет использовать административное расстояние назначенное
протоколу EIGRP по умолчанию и равное 90. Следовательно, протокол EIGRP
в данном случае сможет устанавливать маршруты в таблицу маршрутизации.
Произойдет ли это в действительности? В примере 17.3 приводится таблица
маршрутизации построенная маршрутизатором R1, после того как на нем было
восстановлено по умолчанию административное расстояние протокола EIGRP.
Пример 17.3 – Таблица маршрутизации маршрутизатора R1 после

восстановления административного расстояния протокола EIGRP
r1#show ip route
D 172.16.0.16 [90/30720] via 172.16.0.1, 00:00:16, FastEthernet0/0
Действительно в таблице маршрутизации появился один маршрут, по-

лученный по протоколу EIGRP. Данный маршрут относится к единственной
сети получателю, находившемуся в таблице топологии маршрутизатора R1 из
примера 17.2. Интересной особенностью данной сети получателя является то,
что она расположена ровно в одном переходе от маршрутизатора R1. Однако
для сетей получателей расположенных далее одного перехода в таблице
маршрутизации до сих пор указаны маршруты протокола RIP. Это не удиви-
тельно, поскольку на маршрутизаторе R2 и далее процесс маршрутизации EI-
GRP до сих пор имеет большее административное расстояние, чем процесс
маршрутизации RIP. Следовательно, маршрутизатор R2 объявляет посред-
ством протокола EIGRP только непосредственно подключенные к нему сети
получатели, которые в лучшем случае расположены в одном переходе от
маршрутизатора R1.
Если посмотреть таблицу топологии маршрутизатора R1 (Пример 17.4),
можно увидеть, что запись о сети 172.16.0.16 больше не помечена как недо-
ступная.
Пример 17.4 – Таблица топологии маршрутизатора R1 после восстанов-

ления административного расстояния протокола EIGRP
show ip eigrp topology
via 172.16.0.1 (30720/28160), FastEthernet0/0
via Connected, FastEthernet0/0
277
Это связано с тем, что теперь у протокола маршрутизации EIGRP запу-
щенного на маршрутизаторе R1, меньшее административное расстояние, чем
у протокола RIP, и он может занести в таблицу маршрутизации известные
ему маршруты.
Из рассмотренного примера можно сделать вывод о том, что хотя идея
запуска в теневом режиме протокола маршрутизации EIGRP, выглядит доста-
точно привлекательной, она не приносит желаемого результата, что соответ-
ствует общему правилу дистанционно векторных протоколов маршрутизации.
Теперь рассмотрим пример для сети передачи данных, показанной на
рисунке 17.1, но с выбранным в качестве теневого протокола маршрутизации
протоколом OSPF.
Для запуска протокола OSPF в теневом режиме используется команда
distance ospf intra-area 130, устанавливающая административное расстояние
внутризональных маршрутов большим, чем административное расстояние
маршрутов полученных по протоколу RIP. После запуска протокола маршру-
тизации OSPF в теневом режиме на всех маршрутизаторах представленной
сети передачи данных, необходимо посмотреть таблицу топологии сети пере-
дачи данных построенную протоколом OSPF (Пример 17.5).
Пример 17.5 – Таблица топологии сети передачи данных построенная

протоколом OSPF
r1#show ip ospf database
Link ID ADV Router Age Seq# Checksum Link count

172.16.0.2 172.16.0.2 270 0x80000002 0x0047EF 1
172.16.0.17 172.16.0.17 271 0x80000001 0x009BD2 2
172.16.0.33 172.16.0.33 271 0x80000002 0x006396 2
Net Link States (Area 1)

172.16.0.0 172.16.0.2 270 0x80000001 0x0075C9
172.16.0.16 172.16.0.17 272 0x80000001 0x00519F
172.16.0.32 172.16.0.33 271 0x80000001 0x0001CA
Из примера видно, что в таблице топологии построенной протоколом

OSPF, присутствуют записи обо всех маршрутизаторах и сетях получателях
расположенных в рассматриваемой сети передачи данных.
Уберем из настройки процесса маршрутизации OSPF команду distance
ospf intra-area 130, вернув тем самым административное расстояние протокола
OSPF используемое по умолчанию и равное 110.
Посмотрим, как изменится таблица маршрутизации (Пример 17.6).
278
Пример 17.6 – Таблица маршрутизации маршрутизатора R1 после
восстановления административного расстояния протокола OSPF
r1#show ip route
O 172.16.0.32 [110/3] via 172.16.0.1, 00:00:10, FastEthernet0/0
O 172.16.0.16 [110/2] via 172.16.0.1, 00:00:10, FastEthernet0/0
Следует обратить внимание, что маршруты, полученные по протоколу

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

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

(config-router)#redistribute protocol [metric metric-value][tag tag-value]
[route-map map-tag]
(config-router)# no redistribute protocol [metric metric-value][tag tag-value]
[route-map map-tag]
Описание параметров команды redistribute приводиться в таблице 17.1.
Таблица 17.1 – Параметры команды redistribute
protocol Источник маршрутной информации.
metric metric-value Метрика, назначаемая для перераспре-
деленных маршрутов.
tag tag-value Ярлык, назначаемый для использова-
ния при контроле перераспределения
маршрутов.
route-map map-tag Имя маршрутной карты используемой
при перераспределении.
Наиболее распространенные виды источников маршрутной информации

приводятся в таблице 17.2.
280
Таблица 17.2 – Наиболее распространенные источники маршрутной ин-
формации
Источник маршрутной информации Описание

connected Перераспределение непосредственно
подключенных к маршрутизатору се-
тей.
static Перераспределение статических марш-
рутов настроенных на маршрутизато-
ре.
rip Перераспределение маршрутной ин-
формации из протокола RIP.
eigrp Перераспределение маршрутной ин-
формации из протокола EIGRP.
ospf Перераспределение маршрутной ин-
формации из протокола OSPF.
bgp Перераспределение маршрутной ин-
формации из протокола BGP.
17.2.1 Метрика, присваиваемая перераспределяемым маршрутам
Не обязательное ключевое слово metric команды redistribute, задает мет-

рику, присваиваемую полученным при перераспределении маршрутам. Значе-
ние метрики зависит от протокола маршрутизации, в который будет произво-
диться перераспределение маршрутной информации. Для протокола RIP и
OSPF метрика задается одним числом из возможного для протокола диапазона
метрик. Для протокола RIP таким диапазоном является диапазон от 1 до 15, а
для протокола OSPF, требуемое значение метрики можно рассчитать по форму-
ле (10.1), где в качестве пропускной способности канала связи используется ве-
личина, подобранная из потребностей конкретной сети передачи данных.
Протокол EIGRP для расчета стоимости маршрутов использует комбини-
рованную метрику, вычисляемую по пяти компонентам, которые указываются
по порядку. Это пропускная способность, измеряемая в Кбит/с, задержка, на-
дежность, загрузка и значение MTU. Каждый их этих параметров, так же как и
для протокола OSPF, выставляется исходя из потребностей конкретной сети
передачи данных.
Для маршрутов перераспределяемых в протокол маршрутизации BGP, в
качестве BGP метрики используется числовая метрика протокола маршрутиза-
ции, из которого производилось перераспределение.
Еще одним способом назначения метрики всем перераспределяемым в
протокол маршрутизации маршрутам из различных источников является назна-
281
чение метрики по умолчанию, при помощи команды default-metric. Синтаксис
команды приводится в примере 17.8.
Пример 17.8 – Синтаксис команды default-metric

(config-router)# default-metric metric-value [bandwidth delay reliability
loading mtu]
(config-router)# no default-metric metric-value [bandwidth delay reliability
loading mtu]
Описание параметров команды default-metric приводиться в таблице

17.3.
Таблица 17.3 – Параметры команды default-metric
metric-value Метрика, назначаемая по умолчанию
для всех перераспределенных маршру-
тов.
bandwidth Значение пропускной способности ка-
нала связи. Используется для расчета
комбинированной метрики EIGRP.
delay Значение задержки канала связи. Ис-
пользуется для расчета комбинирован-
ной метрики EIGRP.
reliability Значение надежности канала связи.
Используется для расчета комбиниро-
ванной метрики EIGRP.
loading Значение загрузки канала связи. Ис-
пользуется для расчета комбинирован-
ной метрики EIGRP.
mtu Значение MTU канала связи. Исполь-
зуется для расчета комбинированной
метрики EIGRP.
Если не было использовано ни ключевое слово metric в команде redistrib-

ute, ни команда default-metric, то перераспределенным маршрутам присваива-
ются метрики, установленные по умолчанию для перераспределенных в дан-
ный протокол маршрутизации маршрутов. Значения метрик по умолчанию для
перераспределенных маршрутов приводится в таблице 17.4.
282
Таблица 17.4 – Метрики маршрутов используемые по умолчанию при
Получатель маршрутной
Метрика по умолчанию
информации
RIP Бесконечность.
EIGRP Бесконечность.
OSPF 20.
BGP Исходная метрика маршрута.
17.3 Настройка перераспределения маршрутной информации из присо-

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

присоединенных и статических маршрутов приводится на рисунке 17.2.
r1# router rip r2# router rip

network 172.16.0.0 network 172.16.0.0
redistribute connected redistribute connected
redistribute static !
! ip route 172.16.1.0 255.255.255.0 FastEthernet 0/0
ip route 10.0.0.0 255 .255.255.0 Null 0 ip route 192.168.3.0 255.255.255.0 172.16.0.1
F0/0 172 .16.0.0/28 F0/0
R1 R2
F0/1 F0/1
192 .168 .1.0/28 192 .168 .2.0/28
r1#show ip route
.. .. ..
172 .16.0.0/16 is variably subnetted , 2 subnets, 2 masks
R 172.16.1.0/24 [120/1] via 172.16.0.2, 00:00:18, FastEthernet0/0
C 172.16.0.0/28 is directly connected , FastEthernet0/0
192 .168.1.0/28 is subnetted, 2 subnets
R 192.168.2.0/28 [120/1] via 172.16.0.2, 00:00:18, FastEthernet 0/0
C 192.168.1.0/28 is directly connected , FastEthernet 0/1
10 .0.0.0/24 is subnetted , 1 subnets
S 1 0.0.0.0/24 is directly connected , Null0
r2#show ip route
.. .. ..
S 172.16.1.0/24 is directly connected , FastEthernet 0/0
R 192.160.1.0/28 [120/1] via 172.16.0.1, 00:00:18, FastEthernet0/0
C 192.168.2.0/28 is directly connected, FastEthernet 0/1
S 192.160.3.0/28 [1/0] via 172.16.0.1
R 10.0.0.0/24 [120/1] via 172.16.0.1, 00:00:18, FastEthernet 0/0
Рисунок 17.2 – Перераспределение присоединенных и статических

маршрутов в протокол RIP
283
Перераспределение маршрутной информации из присоединенных и ста-
тических маршрутов в динамические протоколы маршрутизации осуществляет-
ся при помощи команд redistribute connected и redistribute static соответственно.
Синтаксис команд соответствует общему синтаксису команды redistribute опи-
санному в примере 17.7.
После применения команд redistribute connected и redistribute static на
маршрутизаторах R1 и R2 в их таблицах маршрутизации появились маршруты
протокола RIP до непосредственно подключенных к их соседям сетей, хотя ко-
манд network описывающих эти сети в конфигурации процесса маршрутизации
RIP нет.
Стоит также обратить внимание на то, что в конфигурации маршрутиза-
тора R2, отсутствует команда redistribute static, однако в таблице маршрутиза-
ции маршрутизатора R1, находится сеть 172.16.1.0/24. Это связано с тем, что в
протоколе маршрутизации RIP механизм перераспределения маршрутной ин-
формации включается автоматически для статических маршрутов, у которых в
качестве точки назначения указывается не IP адрес, а непосредственно подклю-
ченный интерфейс, а также IP адрес сети получателя принадлежит сетям, опи-
санным в одной из команд network процесса маршрутизации RIP.
Рассмотренный механизм распространения информации о непосред-
ственно подключенных к маршрутизатору сетях в динамический протокол
маршрутизации получателях, может показаться, достаточно удобным, с точки
зрения внесения изменений в конфигурацию процесса маршрутизации таких
протоколов как EIGRP или OSPF. Ведь достаточно один раз использовать ко-
манду redistribute connected при настройке процесса маршрутизации и в даль-
нейшем не нужно описывать в процессе маршрутизации новые сети, настраива-
емые на маршрутизаторе и удалять неиспользуемые при помощи команд net-
work.
Стоит отметить, что практика такого использования команды redistribute
connected широко распространена в корпоративных сетях передачи данных. Од-
нако такое распространение информации о непосредственно подключенных се-
тях в протоколы маршрутизации EIGRP и OSPF является совершенно непра-
вильным.
Как упоминалось ранее, в протоколе маршрутизации EIGRP, введено раз-
деление внутренних и внешних маршрутов по административному расстоянию.
Внутренние маршруты протокола EIGRP имеют административное расстояние
равное 90, что позволяет им выигрывать практически у любых других динами-
ческих протоколов маршрутизации, тогда как для внешних маршрутов прото-
кол EIGRP по умолчанию устанавливает административное расстояние равным
170 (Рисунок 17.3). Это приводит к тому, что внешние маршруты протокола EI-
GRP наоборот проигрывают всем остальным динамическим протоколам марш-
рутизации. Следовательно данная ситуация потенциально может приводить к
возникновению маршрутных петель в домене маршрутизации EIGRP.
284
r1# router eigrp 100 r2# router eigrp 100
network 172.16.0.0 network 172.16.0.0
S0 172.16.0.0/28 S1
R1 R2
F0/1 F0/1
192 .168 .1.0/28 192 .168 .2.0/28
r1#show ip route
.. .. ..
C 172.16.0.0 is directly connected , Serial0
D EX 192.168.2.0/28 [170/2304000] via 172.16.0.2, 00:00:18, Serial0
r2#show ip route
.. .. ..
172 .16.0.0/28 is subnetted, 1 subnets
D EX 192.168.1.0/28 [170/2304000] via 172.16.0.1, 00:00:18, Serial1
C 192.168.2.0/28 is directly connected, FastEthernet0/1
Рисунок 17.3 – Перераспределение присоединенных маршрутов

в протокол EIGRP
Пример использования команды redistribute в протоколе OSPF приводит-

ся на рисунке 17.4.
r1# router ospf 1 r2# router ospf 1

S0 172 .16.0.0/28 S1
R1 R2
F0/1 F0/1
192 .168 .1.0/28 192 .168 .2.0/28
r1#show ip route
.. .. ..
192.168.1.0/28 is subnetted , 2 subnets
O E2 192.168.2.0/28 [110/1] via 172.16.0.2, 00:00:18, Serial0
C 192.168.1.0/28 is directly connected , FastEthernet0/1
r2# show ip ospf border-routers

OSPF Process 1 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i 172.16.0.1 [50] via 172.16.0.1, Serial0, ASBR, Area 1, SPF 4
Рисунок 17.4 – Перераспределение присоединенных маршрутов

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

ции OSPF, маршрутизатор становится ASBR маршрутизатором, и производит
285
распространение, полученных подобным образом маршрутов при помощи LSA
сообщений 5 типа. Как известно распространение данных LSA производится
без изменений по всему обмену маршрутизации OSPF. Кроме того, в протоколе
OSPF имеется запрет на размещение ASBR маршрутизаторов в тупиковых зо-
нах.
Как известно при перераспределении протокол OSPF для перераспреде-
ленных в него маршрутов, по умолчанию устанавливает второй тип внешнего
маршрута, а это значит, что метрика данного маршрута не изменяется при рас-
пространении маршрута внутри домена маршрутизации OSPF. Данный факт
может приводить к построению неоптимальных или даже неправильных таблиц
маршрутизации в сетях передачи данных со сложной топологической структу-
рой, в которой применяются каналы связи с различными величинами пропуск-
ной способности.
Из вышесказанного можно сделать вывод, что в протоколах маршрутиза-
ции EIGRP и OSPF перераспределение из присоединенных и статических
маршрутов, можно использовать в ограниченных масштабах и только как вре-
менное решение.
17.4 Настройка перераспределения маршрутной информации в прото-

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

RIP осуществляется при помощи команды redistribute, синтаксис которой при-
Пример 17.9 – Синтаксис команды redistribute (RIP)

(config-router)#redistribute protocol [process-id] [as-number] [metric metric-
value] [match route-type] [tag tag-value] [route-map map-tag]
(config-router)# no redistribute protocol [process-id] [as-number] [metric
metric-value] [match route-type] [tag tag-value] [route-map map-tag]
Описание параметров команды redistribute (RIP) приводиться в таблице

17.5.
Таблица 17.5 – Параметры команды redistribute (RIP)
protocol Источник маршрутной информации.
process-id Идентификатор процесса маршрутиза-
ции. Используется при перераспреде-
лении из протокола OSPF.
286
as-number Номер автономной системы. Исполь-
зуется при перераспределении из про-
токолов EIGRP или BGP.
metric metric-value Метрика, назначаемая для перераспре-
деленных маршрутов.
match route-type Тип перераспределяемых маршрутов.
Может принимать значения:
Internal – внутренний маршрут;
External 1 – внешний маршрут 1 типа;
External 2 – внешний маршрут 2 типа.
Параметр применяется при перерас-
пределении из протокола OSPF.
tag tag-value Ярлык, назначаемый для использова-
ния при контроле перераспределения
маршрутов.
route-map map-tag Имя маршрутной карты используемой
при перераспределении.
r1#show ip route
.. .. ..
O 172.16.1.0/28 [110/101] via 172.16.0.2, 00:00:18 FastEthernet 0/1
O 172.16.2.0/24 [110/61] via 172.16.0.3, 00:10:45 FastEthernet 0/1
.. .. ..
C 192.168.0.0/28 is directly connected , Serial0
R 192.168.0.16/28 [120/6] via 192.168.0.2, 00:00:18, Serial0
.. .. ..
Сеть N1, OSPF Сеть N2, RIP

172 .16.0.0/16 192 .168 .0.0/24
OSP F R IP
R2
R1
r1# router ospf 1

network 172.16.0.0 0.0.255.255 area 1
router rip
network 192.168.0.0
redistribute ospf 1 metric 3
r2# show ip route

.. .. ..
R 172.16.1.0/28 [120/4] via 192.168.0.1, 00:00:24 Serial1
R 172.16.2.0/24 [120/4] via 192.168.0.1, 00:00:24 Serial1
.. .. ..
R 192.168.0.0/28 is directly connected , Serial1
R 192.168.0.16/28 [120/6] via 192.168.0.16, 00:00:24, Serial2
.. .. ..
Рисунок 17.5 – Перераспределение маршрутной информации

в протокол RIP
287
На рисунке 17.5 приводится пример настройки перераспределения марш-
рутной информации в протокол RIP из протокола OSPF.
На маршрутизаторе R1 запущены два протокола маршрутизации: про-
токолы OSPF и RIP. Маршрутизатор R1 производит перераспределение
маршрутной информации из N1 в N2, и устанавливает метрику для перерас-
пределенных маршрутов в протокол RIP, равную 3 переходам. Поскольку в
команде redistribute не указаны типы маршрутов протокола OSPF, которые
должны быть перераспределены в протокол RIP, будет произведено перерас-
пределение всех маршрутов всех типов из протокола OSPF.
Маршрутизатор R2 получает маршруты до сетей получателей из N1 как
внутренние маршруты протокола RIP.
Из приведенного примера видно, что протокол RIP не производит раз-
деление маршрутов внутренние, включенные в процесс маршрутизации при
помощи команд network, и внешние, полученные при перераспределении
маршрутной информации из внешних источников.

кол EIGRP

EIGRP осуществляется при помощи команды redistribute, синтаксис которой
Пример 17.10 – Синтаксис команды redistribute (EIGRP)

value] [match route-type] [metric metric-value][tag tag-value] [route-map map-
tag]
metric-value] [match route-type] [metric metric-value][tag tag-value] [route-
map map-tag]
В синтаксисе команды redistribute (EIGRP) присутствует параметр as-

number, данный параметр применяется не только при перераспределении
маршрутной информации из протокола BGP, но и из экземпляра протокола
EIGRP запущенного в другой автономной системе.
рутной информации в протокол EIGRP из протокола RIP.
288
r1#show ip route
.. .. ..
D 172.16.1.0/28 [90/2432000] via 172.16.0.2, 01:37:26 Serial0
D 172.16.2.0/24 [90/1794560] via 172.16.0.2, 00:50:39 Serial0
.. .. ..
R 192.168.0.0/28 [120/4] via 192.168.0.2, 00:00:18, FastEthernet 0
R 192.168.0.16/28 [120/6] via 192.168.0.2, 00:00:18, FastEthernet0
.. .. ..
Сеть N1, RIP Сеть N2, EIGRP

192 .168 .0.0/24 172 .16.0.0/16
R IP OSP F
R2
R1

network 172.16.0.0 0.0.255.255
redistribute rip metric 100000 1 255 1 1500
router rip
network 192.168.0.0
r2# show ip route

.. .. ..
D 172.16.1.0/28 [90/2432000] via 172.16.2.1, 03:26:56 Serial2
D 172.16.3.0/24 [90/1794560] via 172.16.2.1, 01:50:39 Serial2
.. .. ..
D EX 192.168.0.0/28 [170/3328000] via 172.16.1.1, 00:16:47 Serial3
D EX 192.168.0.16/28 [170/3328000] via 172 .16.1.1, 00:16:47 Serial3
.. .. ..

в протокол EIGRP
На маршрутизаторе R1 запущены два протокола маршрутизации: про-

токолы RIP и EIGRP. Маршрутизатор R1 производит перераспределение
маршрутной информации из N1 в N2. Необходимо обратить внимание на то,
что при выполнении перераспределения маршрутизатор R1, не устанавливает
фиксированную метрику, как это было в протоколе RIP, а фиксировано задает
пять переменных, по которым протокол EIGRP в соответствии со своим алго-
ритмом сможет рассчитать метрику для перераспределенных маршрутов.
Маршрутизатор R2 получает маршруты до сетей получателей из N1 как
внешние маршруты протокола EIGRP, об этом свидетельствует администра-
тивное расстояние, равное 170 и ярлык «EX», указывающий на механизм по-
лучения маршрута, как внешнего маршрута протокола EIGRP.

кол OSPF

OSPF осуществляется при помощи команды redistribute, синтаксис которой
приводится в примере 17.11. В таблице 17.6 приводятся описания частных па-
раметров команды redistribute (OSPF).
289
Пример 17.11 – Синтаксис команды redistribute (OSPF)
value] [metric-type type-value] [match route-type] [metric metric-value][tag
tag-value] [route-map map-tag] [subnets]
metric-value] [metric-type type-value] [match route-type] [metric metric-
value][tag tag-value] [route-map map-tag] [subnets]
Таблица 17.6 – Частные параметры команды redistribute (OSPF)
metric-type type-value Тип внешнего маршрута OSPF, кото-
рый будет присвоен перераспределен-
ным маршрутам. По умолчанию тип 2.
subnets Производить перераспределение
маршрутов до подсетей. Если данный
параметр не используется, в протокол
OSPF перераспределяются только
маршруты до классовых сетей.
r1#show ip route
D 172.16.1.0/28 [90/2432000] via 172 .16.0.2, 00:00:18 FastEthernet 0/1
D 172.16.3.0/24 [90/1794560] via 172 .16.0.3, 00:10:45 FastEthernet0/1
.. .. ..
10.0.0.0/8 is variably subnetted , 26 subnets 8 masks
O 10.1.4.16/28 [110/61] via 10.1.0.2, 01:22:18, Serial0
.. .. ..
Сеть N1, EIGRP Сеть N2, OSPF

172 .16.0.0/16 10.0.0.0/8
E IG R P OSP F
R2
R1
r1# router ospf 10

network 10.0.0.0 0.255.255.255 area 1
redistribute eigrp 1 metric 100 metric-type 1 subnets
router eigrp 1
network 172.16.0.0 0.0.255.255
r2# show ip route

O E1 172.16.1.0/28 [110/150] via 192.168.0.1, 00:00:24 Serial1
O E1 172.16.2.0/24 [110/150] via 192.168.0.1, 00:00:24 Serial1
.. .. ..
10.0.0.0/8 is variably subnetted , 26 subnets 8 masks
O 10.1.4.16/28 [110/11] via 10.1.2.2, 01:22:18, Serial2
.. .. ..

в протокол OSPF
290
рутной информации в протокол OSPF из протокола EIGRP.
На маршрутизаторе R1 запущены оба протокола маршрутизации: про-
токолы EIGRP и OSPF. Маршрутизатор R1 производит перераспределение
полной маршрутной информации из N1 в N2, устанавливает метрику для
перераспределенных маршрутов в протокол OSPF, равную 100, а также назна-
чает 1 тип внешних маршрутов для перераспределяемой маршрутной инфор-
мации. Это значит, что метрика перераспределенных маршрутов в домене
маршрутизации OSPF будет изменяться по мере распространения внешних
маршрутов по домену OSPF.
291
18 Управление трафиком маршрутных обновлений
В крупных сетях передачи данных часто возникает необходимость рас-

пространять маршрутную информацию управляемо. Например, на рисунке
18.1 приводится ситуация, в которой двум маршрутизаторам, принадлежащим
различным сетям передачи данных и находящихся под различным админи-
стративным управлением, требуется установить соединение при помощи ди-
намического протокола маршрутизации с целью частичного обмена маршрут-
ной информацией.
Сеть N1 Сеть N2
R1 R2
Рисунок 18.1 – Необходимость управления

маршрутной информацией
В рассматриваемом примере, маршрутизатору R1 необходимо полно-

стью запретить распространение маршрутной информации из сети N1, однако
он должен иметь возможность получать маршрутные обновления от маршру-
тизатора R2. Маршрутизатору R2 в свою очередь необходимо объявлять
маршрутизатору R1 только часть известных ему сетей получателей располо-
женных в сети N2.
Рассмотренные в примере задачи принято называть фильтрацией марш-
рутной информации. Выделяют три основных вида управления маршрутной
информацией:
– Назначение пассивных интерфейсов.
– Фильтрация маршрутной информации передаваемой между соседни-
ми маршрутизаторами.
– Фильтрация маршрутной информации при перераспределении марш-
рутной информации между протоколами маршрутизации.
18.1 Использование пассивных интерфейсов
О применении пассивных интерфейсов для управления распространени-

ем маршрутной информации через интерфейсы маршрутизаторов, на которых
назначены IP адреса принадлежащие сетям, участвующим в процессе марш-
292
рутизации, уже не раз нами упоминалось. Теперь необходимо подробно оста-
новиться на данном механизме.
Как известно, все динамические протоколы маршрутизации после свое-
го запуска на маршрутизаторе и описания сетей участвующих в процессе
маршрутизации, начинают производить автоматическую рассылку служеб-
ных пакетов протокола маршрутизации со всех интерфейсов принадлежащих
сетям, описанным в настройках протокола маршрутизации. Это необходимо
для автоматического обнаружения соседних маршрутизаторов, с целью обме-
на с ними маршрутной информацией.
В настоящее время рекомендуется производить разделение адресного
пространства используемого в корпоративной сети передачи данных не толь-
ко по территориальному, но и функциональному признаку. Основными груп-
пами при делении адресного пространства по функциональному принципу яв-
ляются:
– Транспортные сети. В группу транспортных сетей входят сети, назна-
ченные на магистральных каналах связи между соседними маршрутизатора-
ми;
– Сети управления. В группу сетей управления входят сети, из которых
назначаются IP адреса для управления телекоммуникационным оборудовани-
ем;
– Пользовательские сети. В группу пользовательских сетей входят сети,
которые назначаются для нужд пользователей.
Понятно, что при подобном функциональном разделении адресного
пространства, для обмена маршрутной информацией между соседними марш-
рутизаторами достаточно чтобы служебные пакеты протоколов маршрутиза-
ции передавались только по транспортным сетям.
Однако для того чтобы протокол маршрутизации узнал о существова-
нии пользовательских сетей и сетей управления необходимо, либо произвести
перераспределение непосредственно подключенных сетей в протокол марш-
рутизации, либо описать их в протокол маршрутизации. Как говорилось в
предыдущей главе, перераспределение непосредственно подключенных сетей
в самые распространенные в настоящее время протоколы маршрутизации, та-
кие как EIGRP или OSPF, может приводить к неоптимальной работе этих про-
токолов маршрутизации, а в некоторых случаях, и к образованию маршрут-
ных петель.
Следовательно, для протоколов маршрутизации EIGRP и OSPF
единственно правильным способом объявлять группы пользовательских сетей
и сетей управления телекоммуникационным оборудованием в процесс марш-
рутизации, является способ описания данных сетей при помощи команд net-
work. На рисунке 18.2 приводится пример распространения служебных паке-
тов протоколами маршрутизации при описании сетей всех типов в процесс
маршрутизации при помощи команд network, без применения механизмов
управления служебным трафиком протоколов маршрутизации.
293
10.89.0.0/26
10.93.0.0/30
R1 R2
10.89.0.64/26
r1#
router eigrp 200
network 10.89.0.0 0.0.0.63
network 10.89.0.64 0.0.0.63
network 10.93.0.0 0.0.0.3
Рисунок 18.2 – Распространение служебной информации протоколами

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

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

манды passive-interface, синтаксис которой приводиться в примере 18.1.
294
Пример 18.1 – Синтаксис команды passive-interface
(config-router)# passive-interface [default] {interface-type interface-number}
(config-router)# no passive-interface {interface-type interface-number}
Описание параметров команды passive-interface приводиться в таблице

18.1.
interface-type interface-number Тип и номер интерфейса, назначаемого
пассивным.
default Назначение пассивными всех интер-
фейсов маршрутизатора по умолча-
нию.
Пример настройки пассивных интерфейсов приводится на рисунке 18.3.
10.89.0.0/26
F0 S0 10.93.0.0/30
R1 R2
10.89.0.64/26
r1#
router eigrp 200
passive-interface default
no passive-interface Serial 0
network 10.89.0.0 0.0.0.63
network 10.89.0.64 0.0.0.63
network 10.93.0.0 0.0.0.3
Рисунок 18.3 – Настройка пассивных интерфейсов
Необходимо заметить, что на рисунке, использована команда passive-in-

terface с ключом default, а интерфейсы, принадлежащие к транспортным се-
тям, описаны при помощи команды no passive-interface. Это сделано с целью
уменьшения строк в конфигурации маршрутизатора, т.к. в большинстве слу-
чаев транспортных сетей на маршрутизаторах меньше, чем всех остальных.
295
18.2 Фильтрация маршрутной информации, передаваемой между марш-
рутизаторами
Назначение пассивных интерфейсов маршрутизатора, удобно лишь в

том случае если необходимо полностью запретить распространение служеб-
ной информации протоколов маршрутизации через выбранный интерфейс.
Если необходимо чтобы маршрутизаторы устанавливали соседские от-
ношения и обменивались только частью маршрутной информации, необходи-
мо применять другие способы фильтрации маршрутной информации.
Таким способом фильтрации маршрутной информации является сравне-
ние содержащихся сетей получателей в маршрутных обновлениях с определен-
ным условием (Рисунок 18.4).
R1 R2
Рисунок 18.4 – Проверка условий при обмене

маршрутной информацией
Если сеть получатель удовлетворяет условию, то над ней производится

действие, указанное в условии, либо пропускается маршрутизатором, либо от-
брасывается. Действительный смысл слова «отбрасывается» зависит от того,
отправляется или принимается маршрутная информация.
Если маршрутная информация отправляется самим маршрутизатором, то-
гда оно должно содержать только те сети получатели которые удовлетворяют
указанному условию. Сети получатели, не удовлетворяющие условию, удаля-
ются из маршрутного объявления. Условие, которое налагается на сети получа-
тели, объявляемые самим маршрутизатором, называются исходящим фильтром
(outbound filter).
Если маршрутизатор получает маршрутное обновление, при обновлении
таблицы маршрутизации, он рассматривает только те сети получатели, которые
удовлетворяют условию. Точно так же сети получатели, не удовлетворяющие
условию, отбрасываются. Условие, которое маршрутизатор налагает на сети по-
лучатели, содержащиеся в полученных маршрутных обновлениях, называется
входящим фильтром (inbound filter).
Входящие и исходящие фильтры могут применяться как на конкретные
интерфейсы маршрутизатора, так и ко всему процессу маршрутизации. Исходя-
щие фильтры могут применяться только в дистанционно-векторных протоколах
296
маршрутизации. Они не могут использоваться для фильтрации внутренних
маршрутов в протоколах маршрутизации по состоянию канала, поскольку эти
протоколы в своей работе исходят из предпосылки, что все маршрутизаторы
знают действительную топологию сети. Исходящая фильтрация не позволяет
некоторым маршрутизаторам узнавать часть топологической информации сети,
которая не удовлетворяет условиям исходящего фильтра.
Хотя входящие фильтры могут использоваться с обоими типами протоко-
лов маршрутизации, их действие различается в зависимости от того, является
ли протокол маршрутизации дистанционно-векторным либо это протокол
маршрутизации по состоянию канала. В обоих случаях основная функция вхо-
дящего фильтра заключается в том, чтобы маршрутизатор не вносил фильтра в
таблицу маршрутизации маршруты до сетей получателей, не удовлетворяющих
условиям фильтра. В случае с дистанционно векторными протоколами маршру-
тизации, сети получатели, не удовлетворяющие условиям входящего фильтра,
не вносятся в таблицу маршрутизации. Как известно, если дистанционно век-
торный протокол маршрутизации, не может внести маршрут в таблицу маршру-
тизации он не может распространять его далее своим соседям.
В отличие от дистанционно-векторных протоколов маршрутизации, про-
токолы маршрутизации по состоянию канала, в независимости от того описаны
или не описаны входящие фильтры, заносят в таблицу топологии все приходя-
щие сети получатели. Однако если внесенная сеть получатель не удовлетворяет
условиям настроенного фильтра, маршрут до этой сети получателя не будет
внесен в таблицу маршрутизации, но по алгоритму работы протоколов маршру-
тизации данного типа, топологическая информация будет передана далее всем
маршрутизаторам входящих в область маршрутизации.
Существуют два типа описания правил для фильтрации маршрутных об-
новлений:
– Фильтрация сетей получателей по IP адресу сети;
– Фильтрация сетей получателей по длине префикса.
18.2.1 Фильтрация сетей получателей по IP адресу сети
Наиболее легким способом фильтрации маршрутных обновлении по IP

адресу сети получателя является применения стандартных списков доступа, ко-
торые будут применяться для фильтрации маршрутных обновлений.
Список доступа заданный на маршрутизаторе представляет, структуру,
изображенную на рисунке 18.5, состоящую из одного или нескольких правил.
Каждое правило, представляет собой, описание IP адреса сети получателя
с обратной маской сети (wildcard) и действие, которое нужно произвести, если
сеть получатель удовлетворяет описанному правилу. Действий соответственно
может быть два, это пропустить сеть получатель, или отбросить ее.
Как видно из рисунка 18.5 список доступа может состоять из множества
строк, каждая из которых будет описывать свое правило.
297
• список контроля доступа 1
♦ правило списка ACL 1;
♦ правило списка ACL 1.
Рисунок 18.5 – Внутренняя структура списка доступа
На рисунке 18.6 приводится алгоритм обработки маршрутизатором,

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

получатель получатель
выполненияпоследующих
условийв списке

выполненияпоследнего
условияв списке

Отбросить сеть
получатель
Конец
Рисунок 18.6 – Алгоритм работы списка доступа
298
Необходимо обратить особое внимание на то, что проверка поступившей
в маршрутном обновлении информации производится до первого совпадения, и
далее список правил не просматривается. Следовательно, с сетью получателем
производится то действие, что было назначено при обнаружении соответствия
первому совпавшему правилу. Исходя из этого, можно сформулировать прин-
цип построения списка правил. Правила с описанием частных маршрутов долж-
ны быть занесены в список перед суммарными маршрутами.
В связи с тем, что при добавлении нового правила в стандартный список
доступа производится в конец списка, изменение списка доступа необходимо
производить с предварительным удалением ранее заданного списка, и последу-
ющим заполнением отредактированного списка.
Настройка списка доступа, осуществляется последовательным добавле-
нием в конфигурацию маршрутизатора правил списка доступа, используя ко-
манду access-list. Синтаксис команды приводится в примере 18.2.
Пример 18.2 – Синтаксис команды access-list

(config)# access-list access-list-number {deny | permit} source [source-wild-
card]
(config)# no access-list access-list-number
Описание параметров команды access-list приводиться в таблице 18.2.
Таблица 18.2 – Параметры команды access-list
access-list-number Номер списка доступа, к которому
принадлежит описываемое правило.
deny Отбросить сеть получатель при поло-
жительном выполнении указанного
правила.
permit Пропустить сеть получатель при поло-
жительном выполнении указанного
правила.
source IP адрес сети, с которой производится
сравнение.
source-wildcard Обратная маска сети, с которой произ-
водится сравнение.
Обратная маска (wildcard mask) представляет собой 32 битовую величи-

ну, которая разделена на четыре октета, каждый из которых состоит из вось-
ми битов. Если в какой-либо позиции маски стоит бит, равный нулю, то соот-
ветствующий бит адреса должен быть проверен. Если же в какой-либо пози-
299
ции бит, равен единице, то соответствующий бит адреса должен быть
проигнорирован (Рисунок 18.7).
10 . 88. 25. 64
IP адрес
00001010 .01011000 .00011001 .01000000
0 . 0. 0. 0
0 . 0. 0. 255
0 . 0. 255. 255
0 . 255. 255. 255
0 . 1. 0. 255
Wildcard
00000000 .00000000 .00000000 .00000000 1 сеть получатель 10.88.25.64
00000000 .00000000 .00000000 .11111111 Все возможные подсети 10.88.25.0/24
00000000 .00000001 .00000000 .11111111 Все возможные подсети 10.88.25.0/24 и 10.89.25.0/24
Рисунок 18.7 – Обработка маршрутизатором обратной маски
Инвертированная маска, как и маска подсети, тесно связана с IP адре-

сом. В инвертированной маске используются нули и единицы, для того чтобы
указать, как следует трактовать соответствующие биты IP адреса.
Инвертированная маска используется для указания одного или несколь-
ких адресов, которые будут проверяться на соответствие условиям списка
контроля доступа. Термин использование инвертированной маски (wildcard
masking) обозначает процесс побитового сравнения и подстановки значений
битов адреса.
Несмотря на то, что инвертированная маска списков контроля доступа и
маска подсети представляют собой 32 битовые величины, выполняемые ими
функции, значительно отличаются. Нули и единицы в маске подсети опреде-
ляют сеть, подсеть и номер узла. Биты инвертированной маски указывают,
будет ли проверяться соответствующий бит. Еще одним важным отличием
обратной маски от маски подсети, показанным на рисунке 18.7, является то,
что в обратной маске числа отличные от нуля не только начиная с правого
октета, а в произвольном месте обратной маски.
Кроме нумерованных списков доступа, для фильтрации маршрутных
обновлений IP протокола можно использовать именованные списки. Главным
отличием таких списков от рассмотренных ранее, является возможность ука-
зания в качестве идентификатора списка доступа не номера, а символьного
имени.
Создание именованного списка доступа осуществляется при помощи ко-
манды ip access-list. Синтаксис команды приводится в примере 18.3. Добавле-
ние проверяемых правил осуществляется при помощи команд permit и deny,
синтаксис которых приводится в примерах 18.4 и 18.5.
300
Пример 18.3 – Синтаксис команды ip access-list
(config)# ip access-list {standard | extended}access-list-name
(config)# no ip access-list {standard | extended}access-list-name
Пример 18.4 – Синтаксис команды permit

(config-std-nacl)# [sequence-number] permit source [source-wildcard]
(config-std-nacl)# no sequence-number
(config-std-nacl)# no permit source [source-wildcard]
Пример 18.5 – Синтаксис команды deny

(config-std-nacl)# [sequence-number] deny source [source-wildcard]
(config-std-nacl)# no sequence-number
(config-std-nacl)# no deny source [source-wildcard]
Описание параметров команды ip access-list приводиться в таблице 18.3.
standard Стандартный тип именованного
списка доступа.
extended Расширенный тип именованного
списка доступа. (Не применяется для
фильтрации маршрутных обновлений)
access-list-name Имя списка доступа.
Описание параметров команд permit и deny приводиться в таблице 18.4.
Таблица 18.4 – Параметры команд permit и deny
sequence-number Последовательный номер правила в
списке доступа.
source IP адрес сети, с которой производится
сравнение.
source-wildcard Обратная маска сети, с которой произ-
водится сравнение.
Еще одной удобной особенностью именованных списков доступа, являет-

ся возможность редактирования списков доступа, с возможностью добавления
301
нового правила в указанное место списка или удаления конкретного правила
при помощи параметра sequence-number.
Необходимо обратить особое внимание при работе как с нумерованны-
ми, так и с именованными списками доступа на тот факт, что по алгоритму
работы в каждом списоке доступа в неявной форме указано правило deny
0.0.0.0 0.0.0.0, которое запрещает все, что не было разрешено в явном виде.
Это связано с тем, что первоначально правила доступа применялись для
фильтрации трафика проходящего через маршрутизатор, и такое правило
было полезным с точки зрения обеспечения безопасности и удобства админи-
стрирования.
18.2.2 Фильтрация сетей получателей по длине префикса
Длина префикса сети получателя это важный его компонент. Иногда

единственным отличием между двумя сетями получателями является длина
их сетевого префикса, поэтому возможность сравнивания длин сетевых пре-
фиксов должна присутствовать в механизмах фильтрации маршрутной ин-
формации (Рисунок 18.8).
10. 1.0.0/ 2 8
≤ /2 4
10. 1.0.0/ 2 4 1 0.1. 0.0/2 4
> /2 4
10. 1.0.0/ 2 6
R1 R2
Рисунок 18.8 – Фильтрация маршрутной информации по

длине префикса сети получателя
Как мы обсуждали в предыдущем пункте, стандартные списки доступа

IP, применяемые в качестве маршрутных фильтров, не позволяют производить
сравнение длин сетевых префиксов сетей получателей. Следовательно, должен
существовать какой-то другой способ установления соответствия между длина-
ми сетевых префиксов.
Для этого были, разработаны списки префиксов IP. Они представляют со-
бой логические выражения, которые могут устанавливать соответствие с ука-
занными начальными наборами битов в сетевых префиксах IP и длинами этих
сетевых префиксов. Подобно спискам доступа, списки префиксов IP состоят из
одного или нескольких выражений, каждое из которых определяет критерий со-
ответствия. Как и правила списков доступа, выражения списков префиксов воз-
вращают результат permit или deny. Однако, в отличие от выражений нумеро-
ванных списков доступа, выражения списков префиксов имеют порядковые но-
мера, что позволяет удалять или добавлять в нужное место отдельные выраже-
302
ния списка, не затрагивая весь список целиком, подобно тому как это делается в
именованных списках доступа.
Списки префиксов IP могут использоваться только как маршрутные
фильтры.
Настройка списка префиксов IP, осуществляется последовательным до-
бавлением в конфигурацию маршрутизатора правил списка префиксов, исполь-
зуя команду ip prefix-list. Синтаксис команды приводится в примере 18.6.
Пример 18.6 – Синтаксис команды ip prefix-list

(config)# ip prefix-list {list-name | list-number} [seq number] {deny net-
work/length | permit network/length} [ge ge-length] [le le-length]
(config)# no ip prefix-list {list-name | list-number} [seq number] {deny net-
work/length | permit network/length} [ge ge-length] [le le-length]
Описание параметров команды ip prefix-list приводиться в таблице 18.5.
Таблица 18.5 – Параметры команды ip prefix-list
list-name Имя списка префиксов, к которому
принадлежит выражение.
list-number Номер списка префиксов, к которому
принадлежит выражение.
seq number Последовательный номер выражения в
списке префиксов.
жительном выполнении условия опи-
санного в выражении.
network/length Указывает начальные биты, которые
будут сравниваться с соответствующи-
ми начальными битами сетевых пре-
фиксов из маршрутных обновлений.
жительном выполнении условия опи-
санного в выражении.
ge ge-length Максимальная длина сетевого префик-
са сети получателя.
le le-length Минимальная длина сетевого префик-
са сети получателя.
Правила, которые использует маршрутизатор при сравнении сетевых пре-

фиксов из маршрутного обновления со списком префиксов IP таковы:
303
1. Маршрутизатор рассматривает список префиксов как упорядоченный
список. Маршрутизатор сначала сравнивает сетевые префиксы с выражениями
с меньшим seq number, а затем – с большим. Первое сравнение производится
с выражением с наименьшим номером.
2. Маршрутизатор ищет лишь первое совпадение. При нахождении совпа-
дения просмотр списка префиксов прекращается. После этого результат, ука-
занный в строчке выражения по которому было получено совпадение, возвра-
щается в качестве результата сравнения сетевого префикса со всем списком
префиксов.
3. При сравнении сетевого префикса с выражением из списка маршрути-
затор сначала проверяет, является ли длина сетевого префикса, назовем ее L,
большей или равной параметру length указанному в строчке выражения. Если
это так, то маршрутизатор сравнивает первые length бит сети получателя с пер-
выми length битами параметра network Если все биты равны используются
следующие правила:
– Если не указаны ни ge ge-length ни le le-length, выражение дает совпа-
дение только в том случае, если длина сетевого префикса сети получателя
равна параметру length, т.е. L = length;
– Если указано только ge ge-length, то L ≥ ge-length;
– Если указано только le le-length, то L ≥ le-length;
– Если указанны оба параметра, то le-length ≥ L ≥ ge-length.
4. В конце каждого списка префиксов имеется неявное выражение deny
0.0.0.0/0 le 32, которое соответствует любому сетевому префиксу, который не
совпал ни с одним из явных выражений.
18.2.3 Использование списков доступа и списков префиксов при фильтра-

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

маршрутной информации, необходимо связать этот список с процессом
маршрутизации и указать параметры ее обработки.
Для связи списка доступа или списков префиксов с процессом маршру-
тизации применяются команды distribute-list in и distribute-list out, в зависимо-
сти от направления распространения маршрутной информации. Синтаксис
команды distribute-list in представлен в примере 18.7.
Пример 18.7 – Синтаксис команды distribute-list in

(config-router)# distribute-list [access-list-number | name | prefix-list
{list-name | list-number}] | [route-map map-tag] in [interface-type |inter-
face-number]
(config)# no distribute-list [access-list-number | name| prefix-list {list-
name | list-number}]] | [route-map map-tag] in [interface-type interface-num-
ber]
304
Таблица 18.6 – Параметры команды distribute-list in
access-list-number Номер списка доступа, который будет
применяться для фильтрации входяще-
го маршрутного обновления.
name Имя списка доступа, который будет
list-name Имя списка префиксов, который будет
list-number Номер списка префиксов, который бу-
дет применяться для фильтрации вхо-
дящего маршрутного обновления.
route-map map-tag Имя используемой маршрутной карты
при фильтрации маршрутных обновле-
ний. Параметр применяется только для
протокола OSPF.
interface-type interface-number Тип и номер интерфейса маршрутиза-
тора, к которому применяется правило
фильтрации. Если параметр не указан
правило фильтрации применяется ко
всем интерфейсам маршрутизатора, на
которых запущен соответствующий
протокол маршрутизации.
Синтаксис команды distribute-list out представлен в примере 18.8.
Пример 18.8 – Синтаксис команды distribute-list out

(config-router)# distribute-list {access-list-number | access-list-name | pre-
fix-list {list-name | list-number}]} out [interface-name | routing-process |
as-number]
(config)# no distribute-list {access-list-number | access-list-name | prefix-
list {list-name | list-number}]} out [interface-name | routing-process | as-
number]
305
Таблица 18.7 – Параметры команды distribute-list out
access-list-number Номер списка доступа, который будет
Name Имя списка доступа, который будет
list-name Имя списка префиксов, который будет
list-number Номер списка префиксов, который бу-
дет применяться для фильтрации вхо-
дящего маршрутного обновления.
interface- name Интерфейс маршрутизатора, к которо-
му применяется правило фильтрации.
Если параметр не указан правило
фильтрации применяется ко всем ин-
терфейсам маршрутизатора, на кото-
рых запущен соответствующий прото-
кол маршрутизации.
routing-process Процесс маршрутизации, в который
осуществляется фильтрация перерас-
пределяемой маршрутной информа-
ции.
as-number Номер автономной системы протокола
маршрутизации. Параметр применяет-
ся только с протоколом EIGRP.
На рисунке 18.9 приводится пример использования списка доступа для

фильтрации исходящих маршрутных обновлений.
Маршрутизатор R2 является пограничным маршрутизатором сетей
172.16.0.0/16 и 192.168.1.0/24, кроме этого он получает от маршрутизатора R1
маршрутную информацию о сети 10.0.0.0/8.
Необходимо, чтобы маршрутизатор R3 получал от маршрутизатора R2
маршрутную информацию только о подсетях принадлежащих сети
172.16.0.0/16. Для этого используется правило доступа, которое производит
фильтрацию маршрутных обновлений, поступающих маршрутизатору R3, при
котором, маршрутизатор R3 получает маршрутную информацию обо всех под-
сетях сети 172.16.0.0/16, а подсети сети 10.0.0.0/8 остаются ему, неизвестны.
306
S0
10.0.0.0/8 172.16.0.0/16 192.168.1.0/24
R1 R2 R3
r2#
router eigrp 200
network 172.16.0.0
network 192.168.1.0
distribute-list 1 out Serial 0
!
access-list 1 permit 172.16.0.0 0.0.255.255
Рисунок 18.9 – Фильтрация исходящих маршрутных обновлений
На рисунке 18.10 приводится пример использования списка доступа для

фильтрации входящих маршрутных обновлений.
r2#
router eigrp 200
network 172.16.0.0
distribute-list 1 in Serial 0
!
172.16.0.0/28
10.0.0.0/8 172.16.0.0/16
S0
R1 R2 R3
r2# show ip route

.. .. ..
O 172.16.0.32 [110/60] via 172.16.0.18, 00:10:35, Serial1
r3# show ip route

.. .. ..
O 172.16.0.32 is directly connected, Serial2
C 172.16.0.0 [110/60] via 172.16.0.18, 00:10:35, Serial1
O 10.89.2.80/28 [110/101] via 172.16.0.18, 00:09:45, Serial1
O 10.89.1.80/28 [110/101] via 172.16.0.2, 00:10:35, Serial1
O 10.89.2.64/28 [110/101] via 172.16.0.18, 00:09:47, Serial1
O 10.89.1.64/28 [110/101] via 172.16.0.2, 00:10:36, Serial1
Рисунок 18.10 – Фильтрация входящих маршрутных обновлений
На маршрутизаторе R2 используется входящий фильтр маршрутных об-

новлений, который пропускает только подсети сети 172.16.0.0/16. Следователь-
но, вывод таблицы маршрутизации содержит только данные подсети.
Тем не менее, таблица маршрутизации маршрутизатора R3 содержит
маршруты ко всем сетям получателям.
Как говорилось ранее, это происходит потому, что маршрутные фильтры
в протоколе OSPF не влияют на топологические таблицы, строящиеся маршру-
307
тизаторами., а затрагивают только таблицы маршрутизации. Поскольку на
маршрутизаторе не определены ни какие маршрутные фильтры, он не произво-
дит фильтрацию информации о сетях получателях в процессе построения та-
блицы маршрутизации протоколом OSPF.
Списки префиксов чаще всего применяются для фильтрации маршрут-
ных обновлений поступающих, например, с уровня распределения на уровень
ядра или от удаленного подразделения в головной офис.
В этом случае они применяются для фильтрации маршрутов до частных
сетей получателей, и пропускания только суммарных маршрутов.
На рисунке 18.11 приводится пример использования списка префиксов
для фильтрации входящих маршрутных обновлений.
172 .16.14.0/27 17 172 .16.12.0/24

2.
16
.1
4.
22
4/
30
S0
172 .16.14.32/27
172.16.0.0/16
R2 R1
30
2/
23
14.
.
16
2.
172 .16.14.64/27 17
172 .16.13.0/24
r1#
router eigrp 200
172.16.12.0/22 network 172.16.0.0
distribute-list prefix SUMMARY in serial 0
!
ip prefix-list SUMMARY seq 5 permit 172.16.12.0/22
Рисунок 18.11 – Фильтрация списком префиксов

входящих маршрутных обновлений
18.3 Фильтрация маршрутной информации в процессе перераспределе-

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

маршрутизации происходит перераспределение всей таблицы маршрутизации
из протокола источника в протокол назначения.
В случаях если необходимо контролировать процесс перераспределения
маршрутной информации и ограничивать вид и количество перераспределяе-
мых сетей получателей применяется команда distribute-list out указанием про-
цесса маршрутизации, в который будет производиться перераспределение
Использование фильтрации маршрутной информации при ее перераспре-
делении между протоколами маршрутизации, также позволяет избежать воз-
никновения маршрутных петель в случае обратного перераспределения сетей
получателей в их изначальный домен маршрутизации.
308
Пример настройки фильтров перераспределяемой маршрутной информа-
ции приводится на рисунке 18.12.
EIGRP RIP
172.16.0.0/16 192.168.1.0/24
R1
r1#
router eigrp 200
network 172.16.0.0
network 192.168.1.0
distribute-list 1 rip
!
router rip
network 172.16.0.0
network 192.168.1.0
distribute-list 2 eigrp
!
Рисунок 18.12 – Фильтрация перераспределяемой

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

ной информации из протокола EIGRP в протокол RIP, использованы два списка
доступа, которые описывают только собственные сети обоих доменов маршру-
тизации.
309
19 Маршрутные карты
19.1 Понятие маршрутных карт
Рассмотренные ранее методы контроля перераспределения маршрутной

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

лением в конфигурацию маршрутизатора выражений маршрутной карты, ис-
пользуя команду route-map. Синтаксис команды приводится в примере 19.1.
Пример 19.1 – Синтаксис команды route-map

(config)# route-map map-tag [permit | deny] [sequence-number]
(config)# no route-map map-tag [permit | deny] [sequence-number]
Описание параметров команды route-map приводиться в таблице 18.1.
Таблица 19.1 – Параметры команды route-map
map-tag Имя маршрутной карты.
жительном выполнении выражения.
жительном выполнении выражения.
sequence-number Порядковый номер выражения в
маршрутной карте.
Условия совпадения описываются внутри выражения маршрутной карты

с помощью команд группы match. Каждая из команд группы match применяется
для установления совпадения по определенному параметру сети получателя. В
примерах с 19.2 по 19.8 приводятся синтаксисы возможных команд группы
match, применяемых при перераспределении маршрутной информации.
Пример 19.2 – Синтаксис команды match interface

(config-route-map)# match interface interface-type interface-number [... in-
terface-type interface-number]
(config-route-map)# no match interface interface-type interface-number [...
interface-type interface-number]
311
Команда match interface применяется для определения соответствия
сети получателя по типу и номеру выходного интерфейса маршрутизатора
определенного в маршруте для рассматриваемой сети получателя. Как видно
из синтаксиса команды, она может содержать одну или несколько пар тип/но-
мер интерфейса для поиска соответствия в маршрутной информации. Для вы-
полнения условия команды достаточно одного соответствия проверяемой
сети получателя интерфейсам, описанным в команде.
Пример 19.3 – Синтаксис команды match ip address

(config-route-map)# match ip address {access-list-number [access-list-
number... | access-list-name...] | access-list-name [access-list-number...|
access-list-name] | prefix-list prefix-list-name [prefix-list-name...]}
(config-route-map)# no match ip address {access-list-number [access-list-num-
ber... | access-list-name...] | access-list-name [access-list-number...| ac-
cess-list-name] | prefix-list prefix-list-name [prefix-list-name...]}
Команда match ip address применяется для определения соответствия

сети получателя по IP адресу сети получателя. В качестве параметра команды
могут выступать один или несколько нумерованных, именованных списков
доступа или один или несколько списков префиксов. Для выполнения усло-
вия команды достаточно одного соответствия проверяемой сети получателя
IP адресам, описанным в команде.
Пример 19.4 – Синтаксис команды match ip next-hop

(config-route-map)# match ip next-hop {access-list-number | access-list-name}
[...access-list-number | ...access-list-name]
(config-route-map)# no match ip next-hop {access-list-number | access-list-
name}[...access-list-number | ...access-list-name]
Команда match ip next-hop применяется для определения соответствия

сети получателя по IP адресу следующего перехода. В качестве параметра ко-
манды могут выступать один или несколько нумерованных, именованных
списков доступа или один или несколько списков префиксов. Для выполне-
ния условия команды достаточно одного соответствия проверяемой сети по-
лучателя IP адресам, описанным в команде.
Пример 19.5 – Синтаксис команды match ip route-source

(config-route-map)# match ip route-source {access-list-number | access-list-
name}[...access-list-number | ...access-list-name]
(config-route-map)# no match ip route-source {access-list-number | access-
list-name}[...access-list-number | ...access-list-name]
Команда match ip route-source применяется для определения соответ-

ствия сети получателя по IP адресу маршрутизатора, от которого был получен
312
маршрут. В качестве параметра команды могут выступать один или несколь-
ко нумерованных, именованных списков доступа или один или несколько
списков префиксов. Для выполнения условия команды достаточно одного со-
ответствия проверяемой сети получателя IP адресам, описанным в команде.
Пример 19.6 – Синтаксис команды match metric

(config-route-map)# match metric {metric-value | external [+- deviation-num-
ber]}
(config-route-map)# no match metric {metric-value | external [+- deviation-
number]}
Команда match metric применяется для определения соответствия сети

получателя значению метрики маршрута. Описание параметров команды при-
водится в таблице 19.2.
Таблица 19.2 – Параметры команды match metric
metric-value Эталонное значение метрики.
external Указание на внешний тип маршрута.
+- deviation-number Возможное отклонение в большую или
меньшую сторону от эталонного зна-
чения метрики маршрута.
Пример 19.7 – Синтаксис команды match route-type

(config-route-map)# match route-type {local | internal | external [type-1 |
type-2]}
(config-route-map)# no match route-type {local | internal | external [type-1 |
type-2]}
Команда match route-type применяется для определения соответствия

сети получателя по типу маршрута. Описание параметров команды приводит-
ся в таблице 19.3.
Таблица 19.3 – Параметры команды match route-type
local Локальный маршрут протокола BGP.
internal Внутренний маршрут протоколов EI-
GRP или OSPF.
external type-1 Внешний маршрут 1 типа OSPF.
external type-2 Внешний маршрут 2 типа OSPF.
313
Пример 19.8 – Синтаксис команды match tag
(config-route-map)# match tag tag-value [...tag-value]
(config-route-map)# no match tag tag-value [...tag-value]
Команда match tag применяется для определения соответствия сети по-

лучателя по тегу присвоенному маршруту. В качестве параметра команды мо-
гут выступать один или несколько тегов маршрутов. Для выполнения условия
команды достаточно одного соответствия проверяемой сети получателя тегу,
описанному в команде.
При обработке выражений маршрутных карт маршрутизатор производит
проверку условий в соответствии с рисунком 19.1.
route-map ...
«ИЛИ»
match a b с
«И» match d e f
match g h i
Рисунок 19.1 – Проверка условий в выражении маршрутной карты
Между условиями, описанными в одной команде match, производится ло-

гическая операция «ИЛИ», а между условиями, описанными в разных командах
match логическая операция «И».
Главной отличительной чертой маршрутных карт от рассмотренных ра-
нее методов селекции маршрутной информации, является возможность внесе-
ния изменений в маршрутную информацию. Кроме того, имеется возможность
вносить различные изменения в зависимости от то того какое именно условие,
из описанных в выражении маршрутной карты, было выполнено.
Изменения, вносимые в маршрутную информацию, описываются внутри
выражения маршрутной карты с помощью команд группы set. Каждая из ко-
манд группы set, так же как и команды группы match применяется внесения из-
менений по определенному параметру маршрутной информации. В примерах с
19.9 по 19.12 приводятся синтаксисы возможных команд группы set, применяе-
мых при перераспределении маршрутной информации.
Пример 19.9 – Синтаксис команды set level

(config-route-map)# set level {stub-area | backbone}
(config-route-map)# no set level { stub-area | backbone}
Команда set level устанавливает принадлежность перераспределяемых

маршрутов либо тупиковой, либо транзитной зоне протокола OSPF.
314
Пример 19.10 – Синтаксис команды set metric
(config-route-map)# set metric metric-value
(config-route-map)# no set metric metric-value
Команда set metric устанавливает значение метрики, с которой будет

произведено перераспределение маршрута.
Пример 19.11 – Синтаксис команды set metric-type

(config-route-map)# set metric-type {internal | external | type-1 | type-2}
(config-route-map)# no set metric-type {internal | external | type-1 | type-2}
Команда set metric-type устанавливает тип метрики, с которым будет

произведено перераспределение.
Пример 19.12 – Синтаксис команды set tag

(config-route-map)# set tag tag-value
(config-route-map)# no set tag tag-value
Команда set tag устанавливает значение тега, присваиваемое перерас-

пределенному маршруту.
Начало
Да
(x || y || z) && v
Нет
route-map DEMO permit 10
match x y z
match v
set a Да
set b n
match n
set m
Нет
- m a, b
Конец
Рисунок 19.2 – Интерпретация правил маршрутной карты
315
Объяснить принцип работы маршрутной карты можно с помощью про-
стого примера изображенного на рисунке 19.2, на котором приводится алго-
ритм, по которому маршрутизатор производит интерпретацию правил match и
set описанных в маршрутной карте DEMO.
На реальном маршрутизаторе, все представленные на рисунке 19.2
условия и действия, в зависимости от используемых команд match и set,
должны быть замещены конкретными действиями.
19.3 Использование маршрутных карт при перераспределении маршрут-

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

маршрутной карты используется команда уже известная команда redistribute,
с параметром route-map и указанием имени маршрутной карты, которая будет
использована.
На рисунке 19.3 приводится пример использования маршрутной карты
redis-rip при перераспределении маршрутной информации из протокола RIP в
протокол OSPF.
Сеть N1, RIP Сеть N2, OSPF
172 .16.0.0/16
192 .168 .1.0/24
192 .168 .2.0/24
10.0.0.0/8
192 .168 .4.0/24
192 .168 .4.0/24 R1
192 .168 .5.0/24
r1# router ospf 10

network 10.0.0.0 0.255.255.255 area 1
redistribute rip route -map redis-rip
!
route-map redis-rip permit 10
match ip address 1 2
set metric 500
set metric -type type-1
!
route-map redis-rip deny 20
match ip address 3
!
route-map redis-rip permit 30
set metric 5000
set metric -type type-2
!
Рисунок 19.3 – Использование маршрутной карты

при перераспределении маршрутной информации
В соответствии с правилами, описанными в маршрутной карте redis-rip.

Маршруты, принадлежащие классовым сетям 192.168.1.0/24 и 192.168.2.0/24,
316
будут перераспределены в протокол OSPF как внешние маршруты 1 типа с
метриками равными 500.
Маршруты, принадлежащие сети 172.16.0.0/16 не будут перераспреде-
ляться в протокол маршрутизации OSPF.
Все остальные маршруты, находящиеся в домене маршрутизации про-
токола RIP, будет перераспределены в протокол OSPF как внешние маршру-
ты 2 типа с метриками равными 5000.
Необходимо обратить внимание на применение ключей deny и permit в
выражении маршрутной карты с номером 20. Использованный в роли пара-
метра сравнения список доступа возвращает значение permit, однако для вы-
ражения маршрутной карты назначено значение deny, следовательно, марш-
рутизатор не станет производить перераспределение маршрутной информа-
ции удовлетворяющей данному выражению маршрутной карты.
19.4 Проверка конфигурации маршрутных карт
Для отображения настроенных маршрутных карт и их конфигурации

используется команда show route-map. Синтаксис команды приводится в при-
мере 19.13.
Пример 19.13 – Синтаксис команды show route-map

show route-map [map-name] [all] [detailed]
Описание параметров команды приводится в таблице 19.4.
Таблица 19.4 – Параметры команды show route-map
map-name Имя маршрутной карты, по которой
необходимо отобразить информацию.
all Отображение информации по всем
маршрутным картам, настроенным на
маршрутизаторе.
detailed Отображение расширенной информа-
ции о маршрутной карте.
Информация, выводимая данной командой, представлена в примере

19.14.
317
Пример 19.14 – Информация, выводимая командой show route-map
rl# show route-map redistr
route-map redistr, permit, sequence 10
Match clauses:
ip address (access-lists): 1
Set clauses:
metric 5
route-map redistr, permit, sequence 20
Match clauses:
tag 1 2
Set clauses:
metric 6
Policy routing matches: 0 packets; 0 bytes
318
20 Маршрутизация по политикам
20.1 Понятие маршрутных политик
В современных корпоративных сетях передачи данных появилась необ-

ходимость в определенной свободе пересылки пользовательских пакетов и
маршрутизации с определенными правилами, выходящими за рамки механиз-
мов традиционной статической или динамической маршрутизации.
В операционной системе Cisco ISO данные правила получили название
маршрутных политик.
При маршрутизации по политикам определенные виды трафика могут
передаваться по различным маршрутам. Маршрутизация по политикам обес-
печивает также механизм маркировки пакетов различными типами обслужи-
вания (ToS). Эта возможность может использоваться с механизмами качества
обслуживания реализованными в маршрутизаторах.
Маршрутизация по политикам предоставляет следующие преимуще-
ства:
– Выбор магистрального канала связи. Для различных типов трафика
при маршрутизации по политикам могут выбираться различные магистраль-
ные каналы связи. В случае подключения к сети Internet, для различных видов
трафика могут использоваться различные провайдеры.
– Качество обслуживания. Для различных видов трафика можно зада-
вать различные показатели качества обслуживания. Для этого устанавливает-
ся очередность обслуживания или задаются значения ToS в заголовках IP па-
кетов маршрутизаторами расположенными на периферии сети передачи дан-
ных. Такая установка повышает эффективность работы сети передачи дан-
ных, позволяя не производить классификацию всего трафика на уровнях рас-
пределения и ядра, а пользоваться уже установленными параметрами.
– Снижение финансовых затрат. В большинстве случаев компаниям
приходится строить свои сети передачи данных на арендованных магистраль-
ных каналах связи. Имея возможность разделять трафик по его типу можно
снизить финансовые затраты, отправляя важный с точки зрения компании
трафик по более качественным, а следовательно дорогим каналам связи, весь
остальной трафик передавая по более дешевым каналам связи.
– Распределение нагрузки. Маршрутизация по политикам предостав-
ляет администраторам сети передачи данных более гибкие механизмы рас-
пределения трафика по альтернативным маршрутам по сравнению со стан-
дартными возможностями маршрутизаторов.
Для задания маршрутной политики используются маршрутные карты. В
отличие от ранее рассмотренного способа применения маршрутных карт, где
они применялись к маршрутной информации, при маршрутизации по полити-
кам, маршрутные карты применяются к входящим пакетам. Все пакеты, полу-
319
ченные на интерфейс с активизированной маршрутизацией по политикам, яв-
ляются объектом маршрутизации по политикам. Маршрутизатор анализирует
полученные пакеты с помощью маршрутной карты, и далее на основании
определенного в маршрутной карте действия производит модификацию
транспортной информации содержащейся в пакете. Пакет с измененной ин-
формацией передается далее с помощью стандартных алгоритмов маршрути-
зации.
20.2 Настройка маршрутизации по политикам
Первым шагом для настройки маршрутизации по политикам является

описание маршрутной карты. Для описания маршрутных карт применяемых в
маршрутизации выполняются те же правила, что и для рассмотренных ранее
маршрутных карт для перераспределения маршрутной информации.
Отличие маршрутных карт для маршрутизации по политикам от
рассмотренных ранее, заключается лишь в группах команд match и set приме-
няемых для задания выражений маршрутных карт.
Группа команд match содержит лишь две команды. Уже рассмотренную
ранее команду, match ip address и match length. Синтаксис команды match
length приводится в примере 20.1.
Пример 20.1 – Синтаксис команды match length

(config-route-map)# match length minimum-length maximum-length
(config-route-map)# no match length minimum-length maximum-length
Команда match length может использоваться для установки критерия со-

ответствия, на основании длинны пакета, которая должна находиться в преде-
лах диапазона заданным минимальным и максимальным значением.
В отличие от группы команды match группа команд set значительно
расширилась. В примерах с 20.2 по 20.5 приводятся синтаксисы возможных ко-
манд группы set, применяемых в маршрутизации по политикам.
Пример 20.2 – Синтаксис команды set default interface

(config-route-map)# set default interface type number [...type number]
(config-route-map)# no set default interface type number [...type number]
Команда set default interface обеспечивает список интерфейсов по умол-

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

(config-route-map)# set interface type number [...type number]
(config-route-map)# no set interface type number [...type number]
Команда set interface задает список интерфейсов, через которые будут

маршрутизироваться рассматриваемые пакеты. Если задано более одного ин-
терфейса, то для пересылки пакетов будет использован первый активный ин-
терфейс из списка. Если в таблице маршрутизации отсутствует явный марш-
рут на адрес сети получателя, например, широковещательный пакет, то ко-
манда не действует и будет проигнорирована.
Пример 20.4 – Синтаксис команды set ip default next-hop

(config-route-map)# set ip default next-hop ip-address [...ip-address]
(config-route-map)# no set ip default next-hop ip-address [...ip-address]
Команда set ip default next-hop задает список IP адресов по умолчанию,

используемых для определения маршрутизатора следующего перехода на
пути к сети получателю. Если задано более одного IP адрес, то для пересылки
пакетов будет использован первый IP адрес из списка, принадлежащий актив-
ному интерфейсу.
Пример 20.5 – Синтаксис команды set ip next-hop

(config-route-map)# set ip next-hop ip-address [...ip-address]
(config-route-map)# no set ip next-hop ip-address [...ip-address]
Команда set ip next-hop задает список IP адресов, используемых для

определения маршрутизатора следующего перехода на пути к сети получате-
лю. Если задано более одного IP адрес, то для пересылки пакетов будет ис-
пользован первый IP адрес из списка, принадлежащий активному интерфейсу.
Кроме описанных команд группы set существует еще несколько команд
принадлежащих данной группе, например команды set ip tos и set ip preced-
ence, которые изменяют параметры пакета, используемые механизмами QoS,
однако их подробное рассмотрение выходит за рамки данного курса.
Для привязки описанной маршрутной карты к выбранному интерфейсу
используется команда ip policy route-map, синтаксис которой описан в приме-
ре 20.6.
321
Пример 20.6 – Синтаксис команды ip policy route-map
(config-if)# ip policy route-map map-tag
(config-if)# no ip policy route-map map-tag
Необходимо еще раз обратить внимание на то что, маршрутизация по

политикам задается на входном интерфейсе, принимающем пакеты, а не на
отправляющем выходном интерфейсе.
В случае если необходимо применить маршрутизацию по политикам к
трафику сгенерированному самим маршрутизатором применяется команда ip
local policy route-map описываемой в глобальной конфигурации маршрутиза-
тора. Синтаксис команды приводится в примере 20.7.
Пример 20.7 – Синтаксис команды ip local policy route-map

(config)# ip local policy route-map map-tag
(config)# no local ip policy route-map map-tag
Начиная с версии Cisco IOS 12.0, при маршрутизации по политикам

стал доступен механизм быстрой коммутации Fast-Switched. До этого момен-
та маршрутизация по политикам обрабатывалась только программными мето-
дами. Применение механизма Fast-Switched позволило значительно увеличить
скорость обработки пакетов при маршрутизации по политикам.
Быстрая коммутация по политикам по умолчанию отключена, и вклю-
чается после применения маршрутной политики к выбранному интерфейсу
при помощи команды ip route-cache с ключом policy.
20.3 Пример маршрутизации по политикам
На рисунке 20.1 приводится пример использования маршрутизации по

политикам.
Сеть передачи данных удаленного подразделения организации имеет
два подключения к центральному офису. Один из этих каналов связи имеет
высокую пропускную способность, но он является арендуемым, причем
арендная плата зависит от количества трафика переданного по нему.
Второй канал связи является собственным каналом связи организации,
однако его пропускной способности не хватает для передачи всего трафика до
центрального офиса.
В подобной ситуации появляется необходимость передавать важный
для организации трафик, по высокоскоростному каналу связи, а весь осталь-
ной с целью экономии финансовых ресурсов по более медленному каналу
связи.
322
0
E1 10.10.0.0/3
E0 R2
R1 S1 10.10.0.4/
30
R3
r1#
ip policy route -map speed
ip address 10.10.0.2 255.255.255.252
interface serial 1
ip address 10.10.0.6 255.255.255.252
!
route-map speed permit 10
match ip address 1
set ip next -hop 10.10.0.1
!
route-map speed permit 20
set ip next -hop 10.10.0.5
!
Рисунок 20.1 – Использование маршрутизации по политике
Для разделения трафика, была настроена маршрутная карта, которая

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

группы команд show, такие как show ip policy и show ip local policy.
Данные команды выводят все маршрутные политики, настроенные на
маршрутизаторе. Информация, выводимая данными командами, представлена
323
Пример 20.8 – Информация, выводимая командами show ip policy
r1# show ip policy
Interface Route map

Local equal
Ethernet0/2 equal
Еже одним средством проверки маршрутизации по политикам является

команда debug ip policy. Синтаксис команды представлен в примере 20.9.
Пример 20.9 – Синтаксис команды debug ip policy

debug ip policy [access-list-name]
no debug ip policy [access-list-name]
Данная команда выводит информацию о каждом пакете, попавшем под

действие маршрутной политики, или только те из попавших, которые удовле-
творяют правилу access-list-name. Информация, выводимая командой, пред-
ставлена в примере 20.10.
Пример 20.10 – Информация, выводимая командами debug ip policy

r1# debug ip policy
IP: s=30.0.0.1 (Ethernet1), d=40.0.0.7, len 100,FIB flow policy match

IP: s=30.0.0.1 (Ethernet1), d=40.0.0.7, len 100,FIB PR flow accelerated!
IP: s=30.0.0.1 (Ethernet1), d=40.0.0.7, g=10.0.0.8, len 100, FIB policy routed
324
21 Обзор протокола BGP
В данном курсе рассматривается классическое применение протокола

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

маршрутизации является разбиение их на отдельные категории в зависимости
от того, являются они внутренними или внешними. Протоколы маршрутиза-
ции могут быть разбиты на два следующих типа:
– Протокол внутреннего шлюза (протокол IGP). Протокол маршрутиза-
ции, используемый для обмена маршрутной информацией в пределах авто-
номной системы.
– Протокол внешнего шлюза (протокол EGP). Протокол маршрутиза-
ции, который используется для обмена данными между автономными систе-
мами.
AS 65000 AS 65500
IGP IGP
(RIP) (OSPF)
EGP
(BGP)
IGP IGP
(EIGRP) (RIP)
Рисунок 21.1 – Разделение функций между протоколами IGP и EGP
Эта концепция проиллюстрирована на рисунке 21.1. Протокол BGP яв-

ляется протоколом маршрутизации между автономными системами.
325
Все протоколы маршрутизации, которые были изучены ранее, являются
внутренними протоколами маршрутизации.
В настоящее время широко распространен протокол BGP версии 4. Он
описан в документе RFC 1771. Как подчеркнуто в этом стандарте, классиче-
ским определением автономной системы является следующее: «набор марш-
рутизаторов под одним техническим управлением, с использованием прото-
кола внутреннего шлюза и общих метрик для маршрутизации пакетов в пре-
делах AS и с использованием протокола внешнего шлюза для маршрутизации
пакетов в другие автономные системы».
Сегодня автономные системы могут использовать более одного прото-
кола IGP, которые имеют несколько наборов метрик. С точки зрения протоко-
ла BGP важной характеристикой AS является то, что одна AS для другой AS
имеет один согласованный внутренний план маршрутизации и представляет
весь диапазон сетей получателей, которые будут достижимыми через эту AS.
Все части AS должны быть соединены друг с другом.
Агентство по выделению имен и уникальных параметров протоколов
Internet (IANA) является разветвленной организацией, ответственной за рас-
пределение номеров автономных систем во всем мире. Отдельно за присвое-
ние номеров для Северной и Южной Америки, стран Карибского бассейна и
Африки отвечает Американский реестр адресов Internet (ARIN). Европейская
континентальная сеть TCP/IP – Информационный центр Internet (центр
RIPENIC) отвечает за номера для европейской зоны. А Азиатско-Тихо-
океанский NIC (APNIC) ведет учет номеров автономных систем для стран
азиатско-тихоокеанского региона.
Номер автономной системы представляет собой 16 битовое число, ле-
жащее в диапазоне чисел от 1 до 65535. Документ RFC 1930 содержит указа-
ния по использованию номеров AS. Так, номера AS, лежащие в диапазоне от
64512 до 65535, зарезервированы для частного использования, во многом ана-
логично частным IP адресам протокола Internet. Во всех примерах и упражне-
ниях, приведенных далее, используются частные номера AS.
21.2 Использование протокола BGP
Протокол BGP используется для обмена данными между автономными

системами, как показано на рисунке 21.2.
Главной задачей протокола BGP является гарантированная маршрутиза-
ция информации между автономными системами без создания петель. BGP
маршрутизаторы производят обмен информацией о путях к сетям получате-
лям.
Протокол BGP является преемником протокола EGP, протокола внеш-
него шлюза. Необходимо обратить внимание на неоднозначность использова-
326
ния аббревиатуры EGP. Протокол EGP был разработан на ранних стадиях раз-
вития Internet для изоляции сетей друг от друга.
AS 65000
R2 R3
AS 65520 AS 65500
R1 R6
R4 R5
AS 65250
Рисунок 21.2 – Маршрутизация между автономными системами
Использование термина «автономная система» в совокупности с прото-

колом BGP подчеркивает тот факт, что управление автономными системами
для других автономных систем предполагает наличие единого согласованного
плана внутренней маршрутизации, и представляет полную информацию о тех
сетях, которые будут доступны через AS. Существует также различие между
обычной автономной системой и AS, которая конфигурируется протоколом
BGP для осуществления транзитной политики; последние называются про-
вайдерами услуг Internet (ISP), или просто Internet провайдерами.
В настоящее время, с ростом корпоративных сетей передачи данных,
требуется применение протокола BGP, не только при наличии подключения,
но и при необходимости разделения корпоративной СПД на несколько авто-
номных систем.
21.2.1 Когда используется протокол BGP
Использование протокола BGP в AS наиболее уместно, когда действие

протокола BGP понятно и, по крайней мере, выполняется одно из следующих
условий:
– Автономная система пропускает транзитные пакеты на пути к другим
автономным системам.
– Автономная система имеет множество соединений с другими авто-
номными системами.
– Входящий и исходящий трафики автономной системы должны быть
управляемыми.
327
Необходимость распознавания трафика, поступающего от AS и его In-
ternet провайдера, означает, что AS должна подключаться к Internet провайде-
ру с помощью протокола BGP, а не простого статического маршрута.
Протокол BGP был разработан для того, чтобы позволить Internet про-
вайдеру организовать связь и обмен пакетами. Internet провайдеры имеют
множество соединений между собой и соглашений об обмене пакетами об-
новления. BGP является протоколом, который используется для выполнения
этих соглашений между двумя или более автономными системами.
Чтобы понять какой объем информации приходиться обрабатывать
маршрутизаторам Internet провайдеров, нужно отметить, тот факт что, для
простого размещения в оперативной памяти маршрутизатора таблицы всей
сети Internet построенной протоколом BGP потребуется объем оперативной
памяти порядка 2 Гбайт.
При неправильной настройке протокола BGP всегда существует опас-
ность влияния извне на принятие решений о маршрутизации.
21.2.2 Когда не следует использовать протокол BGP
При соединении автономных систем применение протокола BGP не

всегда может оказаться оправданным решением. Например, если есть только
один путь, вполне достаточно маршрута по умолчанию или статического
маршрута; использование протокола BGP в таком случае не несет никаких
преимуществ за исключением загрузки ресурсов и памяти процессора марш-
рутизатора. Если политика маршрутизации AS совпадает с политикой Internet
провайдера, в такой AS настраивать протокол BGP необязательно и даже не-
желательно. Это требуется только тогда, когда локальная политика отличает-
ся от политики Internet провайдера.
Использование протокола BGP нежелательно, если выполняется, хотя
бы одно или более, ниже перечисленных условий:
– Соединение с Internet или другой автономной системой единственное.
– Не планируется применения какой-либо политики маршрутизации и
выбора маршрутов.
– Налицо недостаток памяти или мощности процессора маршрутизато-
ра, необходимых для обработки постоянных пакетов обновления протокола
BGP.
– Недостаточно полное понимание процесса фильтрации маршрутов и
процесса выбора путей протоколом BGP.
– Низкая пропускная способность между автономными областями. В та-
ких случаях лучше пользоваться статическими маршрутами.
328
22 Терминология и концепции протокола BGP
22.1 Характеристики протокола BGP
К какому типу протоколов можно отнести протокол BGP? В главе 3,

«Принципы динамической маршрутизации» описаны характеристики дистан-
ционно-векторных протоколов маршрутизации и протоколов маршрутизации
по состоянию каналов. Протокол BGP можно отнести к дистанционно-вектор-
ным протоколам маршрутизации, но он сильно отличается от другого прото-
кола этого типа – от протокола RIP. Вектор расстояния для протокола BGP
является больше вектором пути. Одновременно с маршрутной информацией
передается большое количество атрибутов, описывающих путь; эти атрибуты
будут подробно рассмотрены далее.
В качестве транспортного протокола BGP использует протокол TCP,
обеспечивающий надежную доставку, ориентированную на соединение. Та-
ким образом, протокол BGP предполагает, что его связь является надежной, и
поэтому нет необходимости выполнять повторные посылки или реализовы-
вать механизмы восстановления ошибок. Протокол BGP использует в своей
работе порт ТСР 179.Два маршрутизатора, работающие под управлением про-
токола BGP, устанавливают TCP соединение между собой и обмениваются
сообщениями, чтобы открыть соединение и подтвердить параметры соедине-
ния. Такие маршрутизаторы, называются одноранговыми маршрутизаторами,
или соседями.
После того как соединение установлено, производится обмен полными
таблицами маршрутизации. Однако из-за того, что соединение является на-
дежным, маршрутизаторам, работающим под управлением протокола BGP,
после этого достаточно посылать только изменения (инкрементные пакеты
обновления). Периодическая рассылка пакетов обновления надежного канала
также не требуется, поэтому используются пакеты обновления по событию.
Протокол BGP рассылает сообщения KEEPALIVE, подобные Hello сообщени-
ям, рассылаемым протоколами OSPF и EIGRP.
BGP маршрутизаторы обмениваются информацией о достижимости
сети, которая называется векторами путей, полученной из атрибутов пути,
включая список полного пути (с номерами АС протокола BGP), который вы-
бирает маршрут на пути к сети-получателю. Эта информация о пути исполь-
зуется для построения графа автономной системы, в котором будут отсут-
ствовать петли. Петли в пути будут отсутствовать из-за того, что маршрутиза-
тор, работающий под управлением протокола BGP, не примет пакет обновле-
ния маршрутизации, уже включающий номер его АС в списке путей; это
должно означать, что пакет обновления уже однажды прошел через эту АС и
что повторный прием такого пакета приведет к образованию петли. Для нало-
жения некоторых ограничений на поведение маршрутизации можно также
329
применить определенные правила маршрутизации (которые называются по-
литиками).
Протокол BGP был разработан для масштабирования сетей, имеющих
большие размеры, таких как Internet.
22.2 Таблицы протокола BGP
Как показано на рисунке 22.1, маршрутизатор, работающий под управ-

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

Таблица маршрутизации Таблица BGP
Рисунок 22.1 – Взаимодействие таблицы BGP

и таблицы маршрутизации
22.3 Одноранговые устройства или соседи BGP
Любые два маршрутизатора, которые установили между собой TCP со-

единение для обмена маршрутной информацией протокола BGP, или, други-
ми словами, установили BGP соединение, называются одноранговыми
устройствами, или соседями. Одноранговые устройства протокола BGP могут
быть по отношению к AS как внутренними, так и внешними.
Протокол BGP, работающий между маршрутизаторами, находящимися
в пределах одной автономной системы, называется внутренним протоколом
BGP или протоколом IBGP. Протокол IBGP производит обмен информацией
протокола BGP таким образом, что она может быть передана на другие авто-
номные системы. Маршрутизаторы, работающие под управлением протокола
IBGP, не обязательно должны быть непосредственно соединены друг с дру-
гом, если они достижимы друг для друга, например, когда маршрут до IBGP
330
соседа устанавливается при помощи одного из протоколов IGP запущенного в
пределах AS.
Протокол BGP, работающий между маршрутизаторами, находящимися
в различных автономных системах, называется внешним протоколом BGP
или протоколом EBGP. Маршрутизаторы, работающие под управлением про-
токола EBGP, обычно непосредственно соединены друг с другом.
IBGP соседи и EBGP соседи показаны на рисунке 22.2
IBGP Соседи
AS 65000
R2 R3
AS 65520 AS 65500
EBGP Соседи
R1 R4
Рисунок 22.2 – IBGP и EBGP соседи в протоколе BGP
22.4 Маршрутизация по политикам
Протокол BGP позволяет принимать решения на уровне АС на основа-

нии политик. Такая установка политик, или правил маршрутизации, известна
как маршрутизация по политикам.
Протокол BGP позволяет задавать политики для определения того, как
данные будут проходить через автономную систему. Эти политики основыва-
ются на атрибутах, которые передаются в маршрутной информации и настра-
иваются непосредственно на маршрутизаторах.
Протокол BGP определяет, что BGP маршрутизатор может объявлять
одноранговым устройствам, находящимся в соседних автономных системах,
только те маршруты, которые он использует сам. Это правило отражает
поэтапную парадигму маршрутизации, повсеместно используемую в Internet в
настоящее время. Некоторые политики не поддерживаются поэтапной (hop-
by-hop) парадигмой маршрутизации и, таким образом, требуют подключения
методов, таких как маршрутизация, исходящая от отправителя. Например,
протокол BGP не позволяет, чтобы одна автономная система посылала тра-
фик на соседнюю автономную систему, с тем, чтобы этот трафик пошел по
маршруту, отличному от того, которым пользуется трафик, происходящий из
331
этой соседней автономной системы. Однако протокол BGP может поддержи-
вать любую политику, соответствующую поэтапной парадигме маршрутиза-
ции. Другими словами, невозможно влиять на то, как соседняя AS маршрути-
зирует трафик, но можно повлиять на то, каким образом трафик попадает в
соседнюю AS.
Из-за того, что современная сеть Internet использует только поэтапную
парадигму маршрутизации и протокол BGP может поддерживать любую по-
литику, соответствующую этой парадигме, протокол BGP является отличным
кандидатом для применения в качестве протокола маршрутизации для обес-
печения связи между автономными системами в современной сети Internet.
22.5 Атрибуты протокола BGP
Маршрутизаторы рассылают сообщения BGP обновлений о сетях полу-

чателях. Эти сообщения включают информацию о метриках протокола BGP,
которые называются атрибутами пути. Вот некоторые термины, определяю-
щие применение этих атрибутов.
– Атрибут может быть стандартным или опциональным, обязательным
или необязательным, транзитивным или нетранзитивным. Атрибут может
также быть частичным.
– Не все комбинации таких характеристик допустимы. Действительно,
атрибуты пути можно разбить на четыре отдельные категории:
– стандартные, обязательные;
– стандартные, необязательные;
– опциональные, транзитивные;
– опциональные, нетранзитивные.
– Только опциональный транзитивный атрибут может быть маркирован
как частичный.
22.5.1 Содержимое сообщения обновления протокола BGP
Сообщение BGP обновления включает последовательность атрибутов

пути, описывающих маршрут, имеющих переменную длину. Атрибуты пути
характеризуются переменной длиной и состоят из следующих трех полей:
– Тип атрибута, который состоит из двух полей длинной в по одному
байту поля флага атрибута и поля кода типа атрибута;
– Длина атрибута;
– Значение атрибута.
Первый бит поля флагов атрибута показывает, является ли атрибут оп-
циональным или известным. Второй бит отражает, является ли опциональный
атрибут транзитивным или нетранзитивным.
332
Третий бит показывает, является ли транзитивный атрибут частичным
или полным. Четвертый бит отражает размер поля атрибута (1 или 2 байта).
Остальные биты флагов не используются и установлены в 0.
22.5.2 Стандартные и опциональные атрибуты
Стандартный атрибут – это атрибут, который описан в одном из доку-

ментов RFC. Такие атрибуты должны распознавать все реализации протокола
BGP. Атрибуты этого типа передаются BGP соседям.
Известный обязательный атрибут должен всегда присутствовать в описа-
нии маршрута. Известный дискретный атрибут не обязательно присутствует в
описании маршрута.
Опциональные атрибуты не обязательно поддерживаются всеми реали-
зациями протокола BGP; это может быть уникальный атрибут, используемый
только в одной реализации протокола. И в том случае, когда он поддержива-
ется, он может быть передан BGP соседям.
Опциональные транзитивные атрибуты – это атрибуты, которые марш-
рутизатор передает на другие BGP маршрутизаторы без изменений. В этом
случае атрибут маркируется как частичный.
Опциональный нетранзитивный атрибут должен удаляться маршрути-
затором, который не использует этот атрибут.
Атрибуты протокола BGP включают следующие:
Известные, обязательные атрибуты:
– атрибут «Путь к AS» (AS-PATH);
– атрибут «Узел следующего перехода» (NEXT-HOP);
– атрибут «Отправитель» (ORIGIN).
Известные, необязательные атрибуты:
– атрибут «Локальный приоритет» (LOCAL PREFERENCE);
– атрибут «Атомарный суммарный» (ATOMIC AGGREGATE).
Опциональные, транзитивные атрибуты:
– атрибут «Составной» (AGGREGATOR);
– атрибут «Сообщество» (COMMUNITY).
Опциональный, нетранзитивный атрибут:
– атрибут «Дискриминатор мультивыходов» (MED – multi-exit-discrim-
inator).
Кроме того, для протокола BGP компания Cisco ввела новый атрибут –
атрибут «Вес» (WEIGHT).
Коды используемые в маршрутизаторах Cisco для обозначения типов
атрибутов представлены в таблице 22.1
333
Таблица 22.1 – Коды типов атрибутов
Атрибут Код типа атрибута

ORIGIN Тип 1
AS-PATH Тип 2
NEXT-HOP Тип 3
MED Тип 4
LOCAL PREFERENCE Тип 5
ATOMIC AGGREGATE Тип 6
AGGREGATOR Тип 7
COMMUNITY Тип 8
ORIGINATOR-ID Тип 9
CLUSTER LIST Тип 10
22.5.3 Атрибут «Путь к AS»
Атрибут «Путь к AS» (AS-PATH) является стандартным обязательным

атрибутом. В случае, когда через автономную систему проходит пакет обнов-
ления маршрута, для этого пакета обновления подготавливается номер AS,
иными словами, он помещается в начало списка. В действительности атрибут
AS-PATH представляет собой список номеров автономных систем, которые
проходит маршрут на пути к получателю. При этом номер автономной систе-
мы, из которой маршрут был послан, помещается в конец списка.
AS 64520
192 .168 .2.0/24
AS 65500 R2 R3 AS 65000
192 .168 .1.0/24 192 .168 .3.0/24
Путь к сети 192 .168 .1.0/24
R1 R4 равен (64520 ,65500 )
Рисунок 22.3 – Добавление номера AS в атрибут AS-PATH
На рисунке 22.3 сеть 192.168.1.0/24 объявляется маршрутизатором R1 в

AS 65500. Когда этот маршрут пересекает AS 64520, маршрутизатор R2 допи-
сывает в него собственный номер AS. Когда 192.168.1.0/24 достигает маршру-
тизатора R4, к нему уже будет добавлено два номера автономных систем, ко-
торые были пройдены данным маршрутом. С точки зрения маршрутизатора
R4 путь к адресу 192.168.1.0/24 будет представлять собой (64520, 65500).
334
Аналогичные рассуждения справедливы для маршрута 192.168.3.0/24.
Путь от маршрутизатора R1 к 192.168.3.0/24 будет (64520, 65000) – маршрут
проходит AS 64520, а затем AS 65000. Маршрутизатор R3 должен пройти
маршрут (65500) на пути к 192.168.1.0/24 и маршрут (65000) на пути к
192.168.3.0.
Атрибут AS-PATH используется BGP маршрутизаторами для создания
среды, свободной от петель. BGP маршрутизатор не примет маршрут, в кото-
ром номер его собственной AS является частью атрибута AS-PATH.
Номера автономных систем добавляются только маршрутизаторами,
рассылающими объявления о маршрутах своим EBGP соседям. Маршрутиза-
торы, рассылающие объявления о маршрутах IBGP соседям, не изменяют
атрибут AS-PATH.
22.5.4 Атрибут «Узел следующего перехода»
BGP атрибут «Узел следующего перехода» (NEXT-HOP) является стан-

дартным обязательным атрибутом, отражающим IP адрес следующего марш-
рутизатора, находящегося на пути к сети получателю.
Для протокола EBGP следующий узел представляет собой IP адрес со-
седа, на который посылается пакет обновления.
AS 65000
172 .16.10.0/24
AS 64520 R2 R3
172 .16.0.0/24
10.1.1.0/30
R1
Рисунок 22.4 – Атрибут NEXT-HOP протокола BGP
На рисунке 22.4 маршрутизатор R1 объявляет 172.16.0.0/24 на маршру-

тизатор R2, с узлом следующего перехода 10.1.1.2, а маршрутизатор R2 объ-
являет 172.16.10.0/24 на маршрутизатор R1, с узлом следующего перехода
10.1.1.1. Поэтому маршрутизатор R1 использует 10.1.1.2 в качестве атрибута
NEXT-HOP для того, чтобы попасть в 172.16.10.0/24, а маршрутизатор R2 ис-
пользует 10.1.1.1 в качестве атрибута NEXT-HOP для того, чтобы получить
доступ к 172.16.0.0/24.
В случае протокола IBGP протокол устанавливает, что следующий узел,
объявленный протоколом EBGP, должен быть передан на протокол IBGP.
Благодаря этому правилу маршрутизатор R2 будет рассылать объявление о
335
маршруте 172.16.0.0 своему соседу по протоколу IBGP, каковым является
маршрутизатор R3, со следующим узлом 10.1.1.1 (адрес маршрутизатора R1).
Поэтому маршрутизатор R3 знает, что следующим узлом к 172.16.0.0 являет-
ся 10.1.1.1, а не 172.16.10.1 (адрес маршрутизатора R2), как это можно было
ожидать.
Поэтому очень важно, чтобы с помощью протокола IGP или статиче-
ского маршрута маршрутизатору R3 был известен маршрут к подсети
10.1.1.0/30. В противном случае из-за того, что он не будет иметь возможно-
сти передавать пакеты на следующий маршрутизатор, лежащий на пути, он
удалит пакеты, направленные на 172.16.0.0/24.
При работе под управлением протокола BGP в широковещательной
сети, такой как Ethernet, BGP маршрутизатор воспользуется соответствую-
щим адресом в качестве адреса следующего перехода, чтобы избежать допол-
нения в сеть дополнительных узлов. Эта возможность иногда называется сле-
дующим узлом третьей стороны.
172 .16.10.0/24 AS 65000 172 .16.20.0/24
10.1.1.0/28
R2 R3
EBGP Соседи EBGP Соседи

R1
AS 64520
172 .16.0.0/24
Рисунок 22.5 – Применение атрибута NEXT-HOP

в широковещательной сети
Например, на рисунке 22.5 предполагается, что маршрутизаторы R2 и

R3 из AS 65000 работают под управлением протокола IGP. Маршрутизатор
R2 может делать рассылки в сеть 172.20.0.0 через 10.1.1.3. Маршрутизатор R2
устанавливает связь с маршрутизатором R1 с помощью протокола BGP.
Когда маршрутизатор R2 посылает BGP обновление на маршрутизатор R1 от-
носительно 172.20.0.0, он будет использовать в качестве следующего узла ад-
рес маршрутизатора R3 10.1.1.3, а не свой собственный IP адрес (10.1.1.2).
Так происходит из-за того, что сеть, которой принадлежат эти три маршрути-
затора, является широковещательной сетью, поэтому маршрутизатору R1 эф-
фективнее в качестве следующего узла на пути к 172.20.0.0 использовать
маршрутизатор R3, а не создавать дополнительный трафик через маршрутиза-
тор R2.
336
Однако если общей средой между маршрутизаторами является среда
NBMA, могут возникнуть осложнения.
172 .16.10.0/24 AS 65000 172 .16.20.0/24
R2 R3
Frame Relay
10.1.1.0./28
EBGP Соседи EBGP Соседи

R1
AS 64520
172 .16.0.0/24
Рисунок 22.6 – Применение атрибута NEXT-HOP

в сети NBMA
Например, на рисунке 22.6 мы видим рассмотренный ранее пример в

видоизмененной топологии, и теперь три маршрутизатора соединены с помо-
щью протокола Frame Relay. Маршрутизатор R2 по-прежнему может достичь
сети 172.20.0.0 через 10.1.1.3. Когда маршрутизатор R2 посылает BGP обнов-
ление на маршрутизатор R1 относительно 172.20.0.0, в качестве узла следую-
щего перехода он будет использовать 10.1.1.3, а не свой собственный IP адрес
10.1.1.2. Затруднение возникнет, когда маршрутизаторы R1 и R3 не будут
иметь возможности производить обмен данными непосредственно между со-
бой, другими словами, если маршрутизаторы R1 и R3 не имеют виртуального
канала между собой. Маршрутизатор R1 не будет иметь информации об адре-
се следующего узла на маршрутизатор R3.
Такого поведения маршрутизаторов можно избежать, настроив маршру-
тизатор R2 таким образом, чтобы он объявлял самого себя в качестве адреса
следующего перехода для маршрутов, посланных на маршрутизатор R1.
22.5.5 Атрибут «Локальный приоритет»
Атрибут «Локальный приоритет» (LOCAL PREFERENCE) – стандарт-

ный необязательный атрибут, который содержит информацию для маршрути-
заторов автономной системы о том, какой путь может быть предпочтитель-
337
ным для выхода из нее. Предпочтительным является путь, локальный приори-
тет которого выше.
Атрибут LOCAL PREFERENCE является атрибутом, который настраи-
вается непосредственно на маршрутизаторе и обмен которым производится
только между маршрутизаторами, принадлежащими одной и той же автоном-
ной системе. По умолчанию значение локального приоритета для маршрути-
заторов Cisco равно 100.
Термин «локальный» имеет отношение ко всему, что находится внутри
автономной системы. Атрибут LOCAL PREFERENCE рассылается только
внутренним BGP соседям; он не передается между EBGP устройствам.
AS 65350 AS 65250 AS 65000
R3
R1
LP=200
AS 65500
R2
LP=150
AS 64520
Рисунок 22.7 – Применение атрибута LOCAL PREFERENCE
На рисунке 22.7 AS 64520 принимает пакеты обновления о сети

172.16.0.0 сразу в двух направлениях. Предположим, что LOCAL
PREFERENCE на маршрутизаторе R1 для сети 172.16.0.0 установлен равным
200, а локальный приоритет на маршрутизаторе R2 для сети 172.16.0.0 уста-
новлен равным 150. Из-за того что обмен информацией о локальном приори-
тете производится в пределах AS 64520, весь трафик в AS 64520, адресован-
ный к сети 172.16.0.0, будет послан на маршрутизатор R1 как на выходную
точку из AS 64520.
338
22.5.6 Атрибут MED
Атрибут MED, упоминаемый также как метрика, является необязатель-

ным нетранзитивным атрибутом. Атрибут MED в протоколе BGP v3 был из-
вестен как атрибут, описывающий отношения между автономными система-
ми.
Атрибут MED сообщает внешним соседям об оптимальном пути в авто-
номной системе. Это динамический способ влияния одних автономных си-
стем на другие, каким способом при наличии множества точек входа в авто-
номную систему, выбирается определенный маршрут. Предпочтение отдается
более низким значениям атрибута.
Атрибут MED делает протокол BGP единственным протоколом, кото-
рый может попытаться влиять на то, как маршруты посылаются в автоном-
ную систему.
В отличие от атрибута LOCAL PREFERENCE, атрибут MED может
передаваться между автономными системами. Атрибут MED передается в ав-
тономной системе и используется там, но не проходит в следующие AS.
Когда аналогичный пакет обновления передается на другую автономную си-
стему, метрика устанавливается назад в значение по умолчанию, равное 0.
По умолчанию маршрутизатор будет сравнивать атрибуты MED только
у путей от соседей одной автономной системы.
AS 65000
172 .16.20.0/24
MED =150 MED=200
R2 R3
R1
AS 65000
172 .16.0.0/24
Рисунок 22.8 – Применение атрибута MED
На рисунке 22.8 атрибут MED маршрутизатора R2 имеет значение 150,

а атрибут MED маршрутизатора R3 – 200. Когда маршрутизатор R1 принима-
ет пакеты обновления от маршрутизаторов R2 и R3, он выбирает маршрутиза-
339
тор R2 в качестве лучшего следующего узла для того, чтобы получить доступ
к AS 65500. Такое решение принимается из-за того, что значение 150 меньше
значения 200.
По умолчанию сравнение атрибутов MED осуществляется только в том
случае, когда соседняя автономная система является единственной для всех
рассматриваемых маршрутов. Для того чтобы маршрутизатор имел возмож-
ность сравнения метрик, поступающих от соседей из различных автономных
систем, необходимо настроить маршрутизатор командой bgp always-compare-
med.
22.5.7 Атрибут «Отправитель»
Атрибут «Отправитель» (ORIGIN) является стандартным обязательным

атрибутом, определяющим источник информации о пути. Атрибут ORIGIN
может принимать одно из трех следующих значений.
IGP – маршрут является внутренним по отношению к первоначальной
АС. Такое обычно происходит, когда для объявления маршрута через прото-
кол BGP используется команда network. Протокол IGP обозначается в табли-
це протокола BGP символом «i».
EGP – маршрут был получен с помощью внешнего шлюзового протоко-
ла. Он обозначается в таблице протокола BGP символом «e».
Incomplete – отправитель такого маршрута неизвестен или был опреде-
лен с помощью других средств. Такая ситуация обычно происходит тогда,
когда маршрут был перераспределен в протокол BGP, такой отправитель
обозначается в таблице протокола BGP символом «?».
22.5.7 Атрибут «Сообщество»
– Сообщества протокола BGP являются одним из способов фильтрации

входящих или исходящих маршрутов. BGP-сообщества позволяют маршрути-
заторам помечать маршруты соответствующим индикатором (сообщество –
COMMUNITY) и позволяет другим маршрутизаторам принимать решения на
основании этого индикатора. Любой BGP маршрутизатор может помечать
маршруты во входящих и исходящих пакетах обновления или в то время,
когда выполняет перераспределение. Любой BGP маршрутизатор может
фильтровать маршруты во входящих или исходящих пакетах обновления или
выбирать предпочтительные маршруты на основании данных о сообществе.
BGP сообщества используются для получателей (маршрутов), которые
разделяют некоторые общие свойства и поэтому могут разделять общие поли-
тики, правила; таким образом, маршрутизаторы воздействуют на целые сооб-
щества, а не только на отдельные маршруты. Сообщества не ограничиваются
одной сетью или одной АС и не имеют физических границ.
340
Атрибут COMMUNITY является необязательным транзитивным атри-
бутом. Если маршрутизатор не понимает концепции сообщества, он должен
подчиняться следующему маршрутизатору. Однако если маршрутизатор «по-
нимает» концепцию сообщества, тогда он настраивается таким образом, что-
бы распространять информацию о сообществе; в противном случае сообще-
ства удаляются по умолчанию.
22.5.8 Атрибут «Вес»
Атрибут вес (WEIGHT) является атрибутом, специфическим для обору-

дования Cisco, используемым при выборе пути. Атрибут WEIGHT настраива-
ется для маршрутизатора локально, обеспечивает только политику локальной
маршрутизации и не распространяется на других BGP соседей.
Атрибут WEIGHT может принимать значение от 0 до 65535. Пути, ко-
торые рассылает маршрутизатор по умолчанию, имеют вес 32768, а другие
пути по умолчанию имеют вес, равный 0.
При наличии нескольких маршрутов к одному получателю предпочти-
тельными являются маршруты, имеющие больший вес.
AS 65000 AS 65250 AS 65500

172 .20.0.0/24
R2 R3 R4
MED=200
WEIGHT =200 WEIGHT =150
R1
AS 64520
Рисунок 22.9 – Применение атрибута WEIGHT
Маршрутизаторы R2 и R4, изображенные на рисунке 22.9, определяют

сеть 172.20.0.0 в автономной системе 65250 и распространяют обновления на
маршрутизатор R1. Маршрутизатор R1 имеет два маршрута до сети 172.20.0.0
и должен принимать решение, какой из этих путей выбрать. Например, марш-
рутизатор R1 устанавливает вес пакетов обновления, приходящих от маршру-
тизатора R2, равным 200, и вес пакетов обновления, приходящих от маршру-
тизатора R3, равным 150. Из-за того, что значение атрибута WEIGHT марш-
341
рутизатора R2 больше значения атрибута WEIGHT маршрутизатора R3,
маршрутизатор R1 примет решение использовать маршрутизатор R2 в каче-
стве узла перехода на пути к 172.20.0.0.
342
23 Работа протокола BGP
23.1 Типы сообщений протокола BGP
Протокол BGP имеет следующие типы сообщений:

– сообщение OPEN;
– сообщение KEEPALIVE;
– сообщение UPDATE;
– сообщение NOTIFICATION.
После того как TCP соединение установлено, первым сообщением, по-
сланным каждой стороной, является сообщение OPEN. Если сообщение
OPEN может быть принято, назад посылается сообщение KEEPALIVE, под-
тверждающее прием сообщения OPEN. После подтверждения сообщения
OPEN BGP соединение считается установленным, и возможен обмен обнов-
лениями, сообщениями KEEPALIVE и NOTIFICATION.
Одноранговые BGP устройства сначала обмениваются своими полными
BGP таблицами маршрутизации. После этого при изменениях таблицы марш-
рутизации будут рассылаться только инкрементные обновления.
Пакеты KEEPALIVE посылаются для подтверждения существования
соединения между одноранговыми BGP устройствами, а NOTIFICATION па-
кеты посылаются в ответ на ошибки или специальные условия.
Сообщение OPEN содержит следующую информацию.
– Версия – поле длиной 8 бит, отражающее номер версии протокола
BGP. Текущий номер версии протокола BGP v4.
– Моя автономная система – поле длиной 16 бит, отражающее номер ав-
тономной системы отправителя.
– Время задержки – поле длиной 16 бит, отражающее максимальное
время в секундах, которое может пройти между приемом последовательных
сообщений KEEPALIVE или обновлений от отправителя. После приема сооб-
щения OPEN маршрутизатор вычисляет значение таймера задержки для ис-
пользования его или меньшего времени задержки, полученного в сообщении
OPEN.
– BGP идентификатор (идентификатор маршрутизатора) – 32-битовое
поле, отражающее BGP идентификатор отправителя. BGP идентификатор яв-
ляется IP адресом, присвоенным маршрутизатору, который задается при
запуске. BGP идентификатор маршрутизатора выбирается аналогично OSPF
идентификатору маршрутизатора – он является наибольшим активным IP ад-
ресом на маршрутизаторе, если для такого IP адреса интерфейса обратной
петли не существует, в этом случае таковым будет наибольший IP адрес
обратной петли.
– Необязательные параметры – поле длины, отражающее общую длину
поля не обязательных параметров в октетах. Поле необязательных параметров
343
может содержать список необязательных параметров (в настоящее время име-
ется только аутентификация).
Для определения достижимости одноранговых устройств протокол BGP
не использует механизм сообщений KEEPALIVE, основанных на транспорт-
ном протоколе. Вместо этого обмен сообщениями KEEPALIVE осуще-
ствляется между одноранговыми устройствами достаточно часто, не вызывая
при этом истечения времени таймера задержки. Если согласованный интервал
времени задержки равен нулю, периодическое сообщение KEEPALIVE не
посылается.
Сообщение обновления содержит информацию только об одном пути;
несколько путей требуют несколько сообщений. Все атрибуты сообщения
имеют отношение только к пути и тем сетям, которые будут достижимы по
этому пути. Сообщение обновления включает следующие поля.
– Нерабочие маршруты – список префиксов IP-адресов, маршрутов, ко-
торые не обслуживаются, если они не указываются.
– Атрибуты пути – это известные нам атрибуты пути AS-PATH,
ORIGIN, LOCAL PREFERENCE и другие рассмотренные ранее атрибуты.
Каждый атрибут пути включает тип атрибута, его длину и значение. Тип
атрибута состоит из флагов атрибута и следующего за ним кода типа атрибу-
та.
– Информация о достижимости сетевого уровня – это поле содержит
список префиксов IP-адресов, которые достижимы по этому пути.
Сообщение NOTIFICATION посыпается при обнаружении ошибки.
BGP соединение закрывается немедленно после посылки этого сообщения.
Сообщение NOTIFICATION включает код и подкод ошибки, а также данные,
соответствующие ошибке.
23.1.1 Состояния BGP соседей
Протокол BGP является машиной состояний, которая принимает соот-

ветствующие состояния в зависимости от состояния процесса обмена данны-
ми маршрутизатора с его соседями:
– простой (Idle);
– соединение (Connect);
– активный (Active);
– открыт посылка (Open- Sent);
– открыт подтверждение (Open- Confirm);
– установлено (Established).
Обмен сообщениями UPDATE, KEEPALIVE и NOTIFICATION осуще-
ствляется только тогда, когда соединение находится в состоянии Established.
Сообщение KEEPALIVE состоит только из заголовка и имеет длину 19
байтов; по умолчанию они рассылаются каждые 60 секунд. Длина других со-
344
общений может быть – от 19 до 4096 байтов. По умолчанию время задержки
составляет 180 секунд.
345
23.2 Процесс принятия решения при выборе пути
После приема пакетов обновления о различных получателях из различ-

ных автономных систем протокол BGP принимает решение о том, какой путь
избрать для достижения конкретного получателя. Протокол BGP выбирает
только один путь к конкретному получателю.
Процесс принятия решения выполняется на основании анализа атрибу-
тов, которые обсуждались ранее. При наличии нескольких маршрутов к одно-
му получателю для осуществления маршрутизации трафика к получателю
BGP выбирает лучший маршрут.
Следующий алгоритм отражает процесс выбора лучшего маршрута про-
токолом BGP на маршрутизаторе Cisco.
Шаг 1. Этот шаг не выполняется, если путь является внутренним, син-
хронизация включена, и маршрут не синхронизирован, другими словами,
маршрут отсутствует в таблице маршрутизации протокола IGP.
Шаг 2. Этот шаг не выполняется, если адрес следующего узла маршрута
не является достижимым.
Шаг 3. Маршрут с наибольшим весом является предпочтительным.
Атрибут WEIGHT применим только к оборудованию корпорации Cisco и яв-
ляется локальным для маршрутизаторов.
Шаг 4. Если несколько маршрутов имеют одинаковое значение атрибу-
та WEIGHT, выбирается маршрут с наибольшим значением LOCAL
PREFERENCE. Значение LOCAL PREFERENCE используется в пределах од-
ной АС.
Шаг 5. Если несколько маршрутов имеют один и тот же локальный при-
оритет, будет выбран маршрут, отправителем которого является локальный
маршрутизатор.
Шаг 6. Если несколько маршрутов имеют один и тот же локальный при-
оритет, но нет маршрута, разосланного локальным маршрутизатором, более
высоким приоритетом будет обладать маршрут, имеющий кратчайшее значе-
ние атрибута AS-PATH.
Шаг 7. При равных значениях атрибута AS-PATH более высокий прио-
ритет будет присвоен отправителю с меньшим кодом: IGP < EGP < incom-
plete.
Шаг 8. При равных кодах отправителя будет предпочтен путь с мень-
шим значением атрибута MED. Атрибут MED поступает из другой автоном-
ной системы.
Сравнение атрибута MED проводится только тогда, когда соседние ав-
тономные системы подобны во всем для всех маршрутов и не активизирована
команда bgp always-compare-med.
Шаг 1. При равных значениях атрибута MED предпочтение перед вну-
тренним путем (протокол IBGP) отдается внешнему пути (протокол EBGP).
346
Шаг 2. При отключенной синхронизации и оставшихся только внутрен-
них путях будет выбран путь через ближайшего IGP соседа. Это означает, что
маршрутизатор выберет кратчайший внутренний путь в пределах АС на пути
к получателю кратчайший путь к следующему узле протокола BGP.
Шаг 3. Для минимизации влияния на EBGP пути «переброски» маршру-
тов выбирайте самый старый, а следовательно и самый надежный маршрут.
Шаг 4. Маршрут с минимальным значением идентификатора соседнего
BGP маршрутизатора является более предпочтительным.
Шаг 5. При равных значениях идентификаторов BGP маршрутизатора
будет предпочтен маршрут с меньшим IP адресом соседа.
Путь запоминается в таблице маршрутизации и рассылается на сосед-
ние BGP маршрутизаторы. Здесь процесс принятия решения о выборе марш-
рута имеет обобщенный характер и не описывает все случаи, но этого доста-
точно для общего понимания того, каким образом протокол BGP выбирает
маршруты.
На шаге 11 в процессе принятия решения для EBGP путей предпочте-
ние отдается самому старому маршруту. Этого нельзя найти ни в одной доку-
ментации по протоколу BGP; такой метод разработан в Центре технической
поддержки компании Cisco (TAC).
23.2.1 Выбор нескольких путей
В соответствии с протоколом BGP для любого получателя выбирается

только один путь.
Команда настройки маршрутизатора для протокола BGP maximum-paths
работает, если маршрутизатор имеет два параллельных пути к двум разным
маршрутизаторам, находящимся в одной удаленной автономной системе.
Рассмотрим, например, три маршрутизатора: R1 из AS 65201 и маршрутиза-
торы R2 и RЗ из AS 65301. Маршрутизатор R1 работает с R2 и RЗ под управ-
лением протокола EBGP. Маршрутизаторы R2 и RЗ рассылают объявления о
сети 10.0.0.0. Без команды maximum-paths, в настройках процесса маршрути-
зации BGP на маршрутизаторе R1, в его таблице маршрутизации не могут
быть представлены два пути. После добавления в конфигурацию протокола
BGP на маршрутизаторе R1 команды maximum-paths 2 в таблице маршрутиза-
ции прописываются оба пути. Это хорошо видно в примере 23.1. Кроме того,
по-прежнему в качестве лучшего пути выбран только один путь, такой путь
обозначается символом «>».
347
Пример 23.1 – Применение команды maximum-paths в протоколе BGP
r1#show ip route bgp
В 10.0.0.0/8 [20/0] via 192.168.1.18, 00:00:41
[20/0] via 192.168.1.50, 00:00:41
r1#show ip bgp
BGP table version is 3, local router ID is 192.168.1.49
Status codes: s suppressed, d damped, h history, * valid, > best,i -> internal
Origin codes:i - IGP,e - EGP,? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 10.0.0.0 192.168.1.18 0 0 65301 i
* 192.168.1.50 0 0 0 65301 i
23.3 CIDR маршрутизация и суммирование маршрутов
Бесклассовая междоменная маршрутизация (CIDR маршрутизация)

представляет собой механизм, разработанный для решения проблемы истоще-
ния IP адресного пространства и роста размеров таблиц маршрутизации. За-
мысел CIDR маршрутизации заключается в комбинировании или агрегирова-
нии в блоки множества адресов класса С. Это и позволяет создавать большие
бесклассовые наборы IP-адресов. Затем эти множества адресов класса C сум-
мируются в таблицах маршрутизации, что в результате уменьшает количество
рассылаемых объявлений маршрута.
В отличие от протокола BGP v4, более ранние версии протокола BGP не
поддерживают CIDR маршрутизацию. Поддержка протокола BGP v4 включа-
ет следующее.
– Сообщение UPDATE протокола BGP включает как префикс, так и его
длину. Предыдущие версии включали только префикс; длина устанавлива-
лась в соответствии с адресом класса.
– При объявлении адресов маршрутизатором протокола BGP они могут
агрегироваться.
– Атрибут AS-PATH может включать комбинированный, несортирован-
ный список всех автономных систем, пройденные всеми агрегированными
маршрутами. Этот комбинированный список должен быть проверен на пред-
мет отсутствия в маршруте петель.
Например, на рисунке 23.1 маршрутизатор R3 рассылает объявления о
сети 192.168.1.0/24, а маршрутизатор R4 рассылает объявления о сети
192.168.2.0/24. Маршрутизатор R1 может передавать эти объявления на
маршрутизатор R2; однако есть возможность уменьшить размер таблицы
маршрутизации маршрутизатора R1. Для этого достаточно суммировать (аг-
регировать) эти два маршрута в один, например, 192.168.0.0/16.
348
AS 65000 AS 65500 AS 65500
192 .168 .1.0/24 192 .168 .2.0/24
R2 R3 R4
19
2.
16
8.
.00
/1
6
R1
AS 64520
Рисунок 23.1 – Использование CIDR маршрутизации в протоколе BGP
Два атрибута протокола BGP имеют отношение к агрегированной адре-

сации. Это известный необязательный атрибут ATOMIC AGGREGATE, ин-
формирующий соседнюю автономную систему о том, что маршрутизатор от-
правитель имеет агрегированные маршруты, и необязательный транзитивный
атрибут AGGREGATOR, задающий идентификатор BGP маршрутизатора и
номер AS маршрутизатора, агрегировавшего маршрут.
По умолчанию агрегированный маршрут будет объявлен как приходя-
щий из автономной системы, которая производит агрегирование, и его атри-
бут ATOMIC AGGREGATE задается таким образом, чтобы показать, какой
информации не достает. Номера автономных систем необъединенных марш-
рутов не перечисляются. Маршрутизатор может быть настроен таким об-
разом, чтобы иметь несортированный список всех автономных систем, содер-
жащихся во всех просуммированных путях.
На рисунке 23.1 агрегированный маршрут 192.168.0.0/16 по умолчанию
может иметь атрибут AS-PATH, равный {64520}. Если маршрутизатор R1
был настроен так, чтобы включать комбинированный несортированный спи-
сок, он должен включать в атрибут AS-PATH набор {65250, 65500} и
{64520}.
349
24 Настройка протокола BGP
24.1 Одноранговые группы
В протоколе BGP соседние устройства зачастую настраиваются с ис-

пользованием одной и той же политики, например, применяются одни и те же
правила фильтрации. На маршрутизаторах Cisco соседи, использующие
подобные политики обновления, могут быть сгруппированы в одноранговые
группы для упрощения настройки и, что более важно, для того, чтобы сделать
модификацию более эффективной. Такой подход желателен при наличии
большого количества одноранговых устройств.
Одноранговая группа протокола BGP представляет собой группу сосед-
них устройств протокола BGP маршрутизатора, настроенных таким образом,
что они все имеют одинаковые политики обновления. Вместо задания одина-
ковых правил для каждого соседа в отдельности эти политики задаются для
всей одноранговой группы одновременно. После этого отдельные соседи ста-
новятся членами одноранговой группы. Политики одноранговой группы
подобны групповым шаблонам, применяющимся к отдельным членам одно-
ранговой группы.
Члены одноранговой группы наследуют все конфигурационные опции
группы. Маршрутизаторы могут быть настроены на отключение этих опций
для некоторых членов одноранговой группы. При этом опции не должны
влиять на исходящие пакеты обновления; другими словами, могут быть от-
ключены только те опции, которые влияют на входящие пакеты обновления.
Все соседние устройства протокола EBGP в одноранговой группе долж-
ны быть достижимы через один и тот же интерфейс. Так происходит потому,
что атрибут NEXT-HOP для соседей протокола EBGP, доступных через раз-
личные интерфейсы, должен различаться. Это ограничение можно обойти за
счет настройки логического интерфейса loopback отправителя для одноранго-
вых устройств протокола EBGP.
Одноранговые группы помогают упростить настройки в случаях, когда
большое количество соседних устройств имеют одинаковые политики. Они
также более эффективны из-за того, что обновления генерируются только
один раз для всей одноранговой группы, а не по разу для каждого соседнего
устройства в отдельности.
Имя одноранговой группы является локальным только для маршрутиза-
тора, на котором оно задано; оно не передается другим маршрутизаторам.
350
24.2 Основные команды протокола BGP
Для активизации протокола BGP и идентификации локальной автоном-

ной системы можно воспользоваться конфигурационной командой router bgp
autonomous-system. В этой команде параметр autonomous-system идентифици-
рует локальную автономную систему.
Для идентификации однорангового маршрутизатора, с которым будет
устанавливать сеанс локальный маршрутизатор, необходимо воспользоваться
командой neighbor remote-as.
Синтаксис команды neighbor remote-as для протокола BGP приводится в
Пример 11.1 – Синтаксис команды neighbor remote-as

(config-router)# neighbor {ip-address | peer-group-name} remote-as as-number
(config-router)# no neighbor {ip-address | peer-group-name} remote-as as-num-
ber
Описание параметров команды neighbor remote-as приводиться в табли-

це 24.1.
Таблица 24.1 – Параметры команды neighbor remote-as
ip-address IP адрес однорангового маршрутизато-
ра.
peer-group-name имя одноранговой группы.
as-number Номер автономной системы, которой
принадлежит описываемый маршрути-
затор.
Значение, размещенное в параметре autonomous-system команды neigh-

bor remote-as, определяет, является связь с соседями EBGP или IBGP сеансом.
Если параметр autonomous-system в команде router bgp идентично параметру в
команде neighbor remote-as, тогда протокол BGP инициирует внутренний се-
анс. Если значения параметров не равны, протокол BGP инициирует внешний
сеанс
Для того чтобы отключить существующего BGP соседа или соседнюю
одноранговую группу, можно воспользоваться командой neighbor shutdown.
Чтобы активизировать прежде существовавшего соседа или соседнюю одно-
ранговую группу, которая была отключена с помощью данной команды необ-
ходимо воспользоваться ей с ключом no.
351
Синтаксис команды neighbor shutdown для протокола BGP приводится в
Пример 24.2 – Синтаксис команды neighbor shutdown

(config-router)# neighbor {ip-address | peer-group-name} shutdown
(config-router)# no neighbor {ip-address | peer-group-name} shutdown
Описание параметров команды neighbor shutdown подобны параметрам

команды neighbor remote-as рассмотренным в таблице 24.1.
Использование логического интерфейса loopback для определения сосе-
дей является обычной практикой протокола IBGP, значительно чаще, чем с
протоколом EBGP. Обычно логический интерфейс loopback используется для
того, чтобы гарантировать постоянное присутствие IP адреса соседа, незави-
симо от надежности работы оборудования, которое может работать недоста-
точно стабильно. При использовании в команде neighbor IP адреса логическо-
го интерфейса на соседнем маршрутизаторе необходимо произвести некото-
рые дополнительные настройки. Соседний маршрутизатор должен известить
протокол BGP, что он для инициализации ТСР соединения с BGP соседом ис-
пользует не физический интерфейс, а логический интерфейс. Для настройки
маршрутизатора на использование его логического интерфейса BGP соедине-
ния маршрутизатора с его соседями можно воспользоваться командой neigh-
bor update-source.
Синтаксис команды neighbor update-source приводится в примере 24.3.
Пример 24.3 – Синтаксис команды neighbor update-source

(config-router)# neighbor {ip-address | peer-group-name} update-source inter-
face-type interface-number
(config-router)# no neighbor {ip-address | peer-group-name} update-source in-
terface-type interface-number
Описание параметров команды neighbor remote-as приводиться в табли-

це 24.2.
Таблица 24.2 – Параметры команды neighbor update-source
ра.
peer-group-name Имя одноранговой группы.
interface-type interface-number Тип и номер используемого интерфей-
са.
352
Команда настройки маршрутизатора network предназначена для предо-
ставления возможности протоколу BGP объявлять сеть, если она имеется в IP
таблице маршрутизации.
Синтаксис команды neighbor shutdown приводится в примере 24.4.

(config-router)# network {network-number [mask network-mask]} [route-map map-
tag]
(config-router)# no network {network-number [mask network-mask]} [route-map
map-tag]
Описание параметров команды network приводиться в таблице 24.3.
network-number Адрес сети.
mask network-mask Описание маски подсети.
route-map map-tag Привязка к описанной маршрутной
карте.
Команда network управляет тем, какие сети берут начало от данного

маршрутизатора. Эта концепция отличается от той, которая существует при
настройке протокола IGP. Команда network не запускает протокол BGP на
определенных интерфейсах; она предназначена для указания протоколу BGP,
какая сеть должна начинаться от данного маршрутизатора. Параметр mask ис-
пользуется для того, чтобы протокол BGP v4 мог работать с подсетями.
Список команд network должен включать все сети AS, которые будут
объявляться, а не только те, которые локально подключены к маршрутизато-
ру.
Команда network допускает бесклассовые префиксы; маршрутизатор
имеет возможность объявлять индивидуальные подсети или сети. Необходи-
мо отметить, что префикс должен точно соответствовать записи в таблице
маршрутизации. При отсутствии такого маршрута в таблице маршрутизации
может использоваться статический маршрут на Null0 для создания такой за-
писи.
На рисунке 24.1 показан пример сети, работающей под управлением
протокола BGP.
353
AS 64520 AS 65000
172 .16.0.0/16 172 .17.0.0/16
10.1.1.0/30
R1 R2
r1# router bgp 64520

neighbor 10.1.1.1 remote-as 65000
network 172.16.0.0

network 172.17.0.0
Рисунок 24.1 – Пример настройки сети для работы протокола BGP
Маршрутизаторы R1 и R2 определяют друг друга в качестве BGP сосе-

дей и запускают EBGP сеанс. Маршрутизатор R1 объявляет сеть
172.16.0.0/16, а маршрутизатор R2 - сеть 172.17.0.0/16.
24.2.1 Модификация атрибута NEXT-HOP
Модификация атрибута NEXT-HOP иногда необходима, например, в

среде NBMA, чтобы отключать стандартное поведение маршрутизатора и
перепрограммировать его на рассылку объявлений о самом себе как адресе
следующего маршрутизатора для маршрутов, посылаемых соседу.
Команда настройки маршрутизатора neighbor next-hop-self используется
для того, чтобы вынудить протокол BGP использовать собственный IP адрес в
качестве IP адреса следующего узла и не дать протоколу возможности выбора
адреса следующего узла. Синтаксис команды neighbor next-hop-self приводит-
ся в примере 24.5.
Пример 24.5 – Синтаксис команды neighbor next-hop-self

(config-router)# neighbor {ip-address | peer-group-name} next-hop-self
(config-router)# no neighbor {ip-address | peer-group-name} next-hop-self
Описание параметров команды neighbor next-hop-self подобны парамет-

рам команды neighbor remote-as рассмотренным в таблице 24.1.
24.2.2 Описание объединенного адреса в BGP таблице
Конфигурационная команда aggregate-address используется для созда-

ния общих записей таблицы протокола BGP. Синтаксис команды приводится
354
Пример 24.6 – Синтаксис команды aggregate-address
(config-router)# aggregate-address address mask [as-set] [summary-only]
(config-router)# no aggregate-address address mask [as-set] [summary-only]
Описание параметров команды aggregate-address приводиться в таблице

24.4.
Таблица 24.4 – Параметры команды aggregate-address
address mask Описание объединенного адреса.
as-set Генерирует информацию об AS пути
суммарного маршрута, включающего
все AS перечисленные во всех путях
всех маршрутов которые были суммар-
ным маршрутом.
summary-only Задает режим объявления маршрутиза-
тором только суммарного маршрута.
Команда aggregate-address применима к сетям, в которых BGP таблица

уже используется. Это отличается от требования к сетям при рассылке объяв-
лений результатов суммирования командой BGP network, когда сеть уже
должна присутствовать в IP таблице маршрутизации. В этом случае агрегиру-
емые сети должны присутствовать в BGP таблице.
При использовании этой команды без ключевого слова as-set агрегиро-
ванный маршрут будет объявлен как приходящий из вашей автономной си-
стемы, и атрибут ATOMIC AGGREGATE будет установлен таким образом,
чтобы показать, что информации может недоставать. Атрибут ATOMIC
AGGREGATE установлен в том случае, если не задано ключевое слово as-set.
Без ключевого слова summary-only маршрутизатор может по-прежнему
объявлять индивидуальные сети. Это может пригодиться при наличии избы-
точных каналов к Internet провайдеру. Например, если один Internet про-
вайдер рассылает в объявлениях только суммарные маршруты, в то время как
другой рассылает в объявлениях не только суммарные маршруты, но и
отдельные маршруты, отслеживаться будут эти отдельные маршруты. Если
же Internet провайдер, рассылающий объявления об отдельных маршрутах,
становится недоступным, тогда отслеживаться будут провайдеры, рассылаю-
щие в объявлениях только суммированные маршруты.
Только при использовании ключевого слова summary-only командой ag-
gregate-address будет объявлен суммарный маршрут. Путь теперь будет отра-
жать только просуммированные AS, причем любая другая информация о пу-
355
тях станет недоступной. При использовании в команде aggregate-address толь-
ко ключевого слова as-set информация о пути будет включать номера авто-
номных систем, если существовала команда с ключевым словом summary-
only, она будет удалена. Однако оба ключевых слова можно использовать в
одной команде одновременно; в результате чего будет рассылаться только
суммарный адрес и в маршрутной информации будут перечислены все авто-
номные системы
24.2.3 Перезапуск протокола BGP
Для удаления записей из BGP таблиц и сброса сеансов протокола BGP

используется команда clear ip bgp. Синтаксис команды приводится в примере
24.7.
Пример 24.7 – Синтаксис команды clear ip bgp

#clear ip bgp {* | neighbor-address} [soft [in | out]]
Описание параметров команды clear ip bgp приводиться в таблице 24.5.
Таблица 24.5 – Параметры команды clear ip bgp
* Сброс всех текущих BGP соседей.
neighbor-address Сброс выбранного BGP соседа.
soft Производит мягкий сброс BGP соседа.
in Производит мягкий сброс входящих
соединений.
out Производит мягкий сброс исходящих
соединений.
Команда clear ip bgp используется после каждого изменения настройки

для того, чтобы активизировать внесенные изменения и проинформировать о
них одноранговые маршрутизаторы.
Задавая мягкую перенастройку протокола BGP с помощью ключевого
слова soft, обеспечивается такой режим работы, когда сеансы протокола BGP
не сбрасываются, а маршрутизатор повторно возобновляет посылку всех па-
кетов обновления маршрутизации. Для генерирования новых входящих паке-
тов обновления без переустановки сеанса протокола BGP локальный BGP-
спикер должен сохранять все полученные пакеты обновления без изменения,
независимо от того, принят ли он в соответствии с входящей политикой или с
использованием конфигурационной команды маршрутизатора neighbor soft-
reconfiguration. После первой настройки с помощью команды neighbor soft-re-
356
configuration очистите все текущие BGP-сеансы, чтобы все пакеты обновле-
ния были повторно пересланы всем соседям, а затем сохранены в локальном
маршрутизаторе. Этот процесс требует много памяти, и его желательно по
возможности избегать. Исходящая мягкая настройка протокола BGP не при-
водит к перегрузке памяти.
На рисунке 24.2 показан еще один пример сети, работающей под управ-
лением протокола BGP.
AS 64520 172 .16.10.0/24 AS 65000 172 .16.20.0/24

192 .168 .2.0/24 172 .16.10.0/16
10.1.1.0/30 192 .168 .1.48/30
R1 R2 R3

network 172.16.0.0

network 172.16.10.0 mask 255.255.255.0
network 192.168.1.48 mask 255.255.255.252
neighbor 192.168.1.50 next-hop-self
aggregate-address 172.16.0.0 255.255.0.0 summary-only
Рисунок 24.2 – Пример сети работающей под управлением BGP
На рисунке 24.2 первые две команды, следующие за командой router

bgp 65000, устанавливают, что маршрутизатор R2 имеет два BGP соседа:
маршрутизатор R1 из AS 64520 и маршрутизатор R3 из AS 65000. Следующие
две команды позволят маршрутизатору R2 объявлять сети 172.16.10.0/24 и
192.168.1.48/30 для его BGP соседей.
Для того чтобы сбросить BGP сеансы после отключения синхрониза-
ции, команда clear ip bgp * потребуется на маршрутизаторах R2 и R3.
По умолчанию маршрутизатор R2 будет передавать BGP объявление о
сети 192.168.2.0/24 из маршрутизатора R1 на маршрутизатор R3 с адресом
следующего узла, равным 10.1.1.2. Однако маршрутизатор R3 не знает, как
попасть на 10.1.1.2, поэтому он не установит маршрут. Команда neighbor
192.168.1.50 next-hop-self заставит маршрутизатор R2 рассылать объявления
на маршрутизатор R3 с его собственным адресом в качестве адреса следую-
щего узла. Маршрутизатор R3 тогда получает возможность доступа к сети
192.168.2.0/24.
По умолчанию маршрутизатор R1 может знать об обеих подсетях
172.16.10.0/24 и 172.16.20.0/24. Однако после добавления команды aggregate-
address 172.16.0.0 255.255.0.0 summary-only маршрутизатор R2 будет сум-
мировать подсети и посылать на маршрутизатор R1 только маршрут
172.16.0.0/16.
357
24.3 Проверка работоспособности протокола BGP
Проверка функционирования протокола BGP может быть выполнена с

помощью следующих основных команд группы show:
show ip bgp – отображает записи таблицы маршрутизации протокола
BGP. С помощью этой команды можно определить сетевой адрес для получе-
ния более конкретной информации по определенной сети.
show ip bgp summary – отображает статус всех BGP-соединений.
show ip bgp neighbors – отображает информацию о TCP- и BGP соедине-
ниях с соседями.
С помощью команд отладки отображаются события на маршрутизаторе.
Для протокола BGP привилегированная команда debug ip bgp имеет следую-
щие опции.
dampening – затухание протокола BGP.
events – события протокола BGP.
keepalives – сообщения KEEPALIVES протокола BGP.
updates – пакеты обновления протокола BGP.
358
25 Множественная адресация
В этом разделе описываются принципы множественной адресации и

приводятся примеры ее настройки.
Множественная адресация (multihoming) – это термин, который исполь-
зуется для описания подключения автономной системы более чем к одному
провайдеру Internet. Так делается обычно по одной из двух следующих при-
чин:
– Для повышения надежности подключения к Internet, чтобы обеспе-
чить как минимум одно надежное соединение.
– Для повышения производительности, чтобы для обеспечения пути к
определенным получателям использовался лучший путь.
25.1 Типы множественной адресации
Конфигурацию множественных соединений с провайдерами услуг Inter-

net можно классифицировать в соответствии с маршрутами, имеющимися к
автономным системам провайдеров. Можно выделить три наиболее популяр-
ных способа настройки соединений.
– Все провайдеры Internet используют только маршруты по умолчанию
на автономные системы.
– Все провайдеры Internet используют как по умолчанию, так и избран-
ные специальные маршруты на автономную систему, например, от потреби-
телей, с которыми у автономной системы имеется большой трафик.
– Все провайдеры Internet используют полные маршруты на автоном-
ную систему.
При множественной адресации провайдеры Internet, к которым имеются
подключения, должны рассылать объявления в Internet с префиксами подклю-
ченной AS. Например, если присвоенные префиксы являются частью только
одного из диапазонов адресов провайдера Internet, провайдер Internet, не вла-
деющий данными префиксами, также должен объявлять в Internet эти префик-
сы явным образом.
Первый сценарий основан на том, что все провайдеры Internet имеют
соединение с автономной системой только при помощи маршрутов по умол-
чанию. Это потребует минимального расхода ресурсов маршрутизаторов ав-
тономной системы, так как обрабатываются только маршрут по умолчанию.
Автономная система будет рассылать все свои маршруты к провайде-
рам Internet, которые будут обрабатывать и передавать их другим автоном-
ным системам.
Провайдер Internet, используемый конкретным маршрутизатором в пре-
делах автономной системы для доступа в Internet, будет выбран по метрикам
359
протокола внутреннего шлюза IGP, который используется для достижения
маршрута по умолчанию в пределах в приделах автономной системы.
Маршрут, которым пользуются внутренние пакеты для доступа к AS,
выбирается за пределами автономной системы, в зоне ответственности про-
вайдера Internet и в других автономных системах.
AS 64520
172 .16.0.0/16
AS 65000 AS 65250
ISP ISP
R4 R5
0.
0.
0.
0. 0
0.
0. 0
R1 R2
R3
AS 65500
Рисунок 25.1 – Обработка маршрутов по умолчанию

от провайдеров Internet
В примере, показанном на рисунке 25.1 AS 65000 и AS 65250 посылают

маршруты по умолчанию на AS 65500.
Провайдер Internet, использующий для достижения любого внешнего
адреса определенный маршрутизатор в пределах AS 65500, выбирается на
основании той же метрики протокола IGP, которая используется для достиже-
ния маршрута по умолчанию в пределах AS. Например, если протокол RIP
используется в пределах AS 65500, маршрутизатор R3, когда ему необходимо
послать пакеты в сеть 172.16.0.0/16, выберет маршрут с минимальным счет-
чиком узлов к стандартному маршруту, т.е. к маршрутизатору R1 или R2.
Когда маршрутизатор R3 выбирает путь через маршрутизатор R2, пакеты бу-
дут пересылаться на 172.16.0.0/16, как показано на рисунке 25.1.
Второй сценарий выполняется тогда, когда все провайдеры Internet
передают на AS как маршрут по умолчанию, так и избранные маршруты.
360
Такой подход потребляет больше ресурсов памяти и процессора марш-
рутизаторов автономной системы из-за того, что будут обрабатываться как
маршрут по умолчанию, так и отдельные внешние маршруты. Автономная си-
стема посылает все маршруты провайдеру Internet, который обработает их и
передаст на другие автономные системы.
Провайдер Internet, используемый конкретным маршрутизатором AS
для достижения сетей потребителей, будет кратчайшим AS путем; однако это
ограничение можно обойти. Путь ко всем остальным внешним получателям
будет выбран на основании метрик протокола IGP, которые используются для
достижения маршрута по умолчанию в пределах AS.
Маршрут, по которому внутренние пакеты поступают в автономную си-
стему, выбирается за пределами AS в зоне ответственности провайдера Inter-
net и в других автономных системах.
AS 64520
172 .16.0.0/16
AS 65000 AS 65250
ISP ISP
R4 R5
R1 R2
R3
AS 65500
Рисунок 25.2 – Обработка маршрутов по умолчанию и частных маршрутов
В примере, показанном на рисунке 25.2, AS 65000 и 65250 посылают

как маршрут по умолчанию, так и частные маршруты, направленные в сеть
потребителя – AS 64520 172.16.0.0//16, в автономную систему 65500.
Провайдер Internet, используемый маршрутизатором из AS 65500, будет
кратчайшим AS путем к потребительским сетям. Кратчайший AS путь к AS
64520 проходит через AS 65000 и маршрутизатор R1, а не через AS 65250, а
361
затем AS 65000. Маршрутизатор R3 выберет этот маршрут при посылке паке-
тов в сеть 172.16.0.0/16, что показано на рис. 25.2 соответствующей стрелкой.
Маршруты к другим внешним адресам, которые не были специально
объявлены на AS 65500, будут выбраны по метрике протокола IGP для дости-
жения стандартного маршрута в пределах автономной системы.
AS 64520
172 .16.0.0/16
AS 65000 AS 65250
ISP ISP
R4 R5
Для сети 172 .16.0.0/16

атрибут local preference =800
R1 R2
R3
AS 65500
Рисунок 25.3 – Обработка маршрутов по умолчанию и частных маршрутов

от всех провайдеров Internet
В примере, показанном на рис. 25.3 AS 65000 и 65250 посылают как

маршруты по умолчанию, так и заданные маршруты в потребительскую сеть
172.16.0.0/16 AS 64520 в AS 65500. Провайдер Internet, использующий задан-
ный маршрутизатор в пределах AS 65500 для достижения сети получателя,
будет кратчайшим AS путем. Однако маршрутизатор R2 настроен таким об-
разом, чтобы вносить изменения в локальные приоритеты маршрутов на
172.16.0.0/16 со значения по умолчанию, равного 100, на 800. Поэтому марш-
рутизатор R3 для достижения 172.16.0.0/16 предпочтет путь через маршрути-
затор R2, что показано на рисунке 25.3 стрелками.
Маршруты к другим внешним адресам, не объявленным специально в
AS 65500, будут выбраны на основании метрик, используемых стандартным
маршрутом в пределах автономной системы.
Третий сценарий выполняется тогда, когда для доступа к AS все про-
вайдеры Internet используют все маршруты.
362
Этот сценарий требует большого количества ресурсов памяти и процес-
сора маршрутизаторов, имеющихся в автономной системе, поскольку все
внешние маршруты должны быть обработаны.
Автономная система посылает все свои маршруты провайдерам Internet,
которые обрабатывают их и передают другим автономным системам.
Провайдер Internet, который используется заданным маршрутизатором
в пределах AS для достижения внешней сети, будет кратчайшим AS путем.
Однако это ограничение можно обойти.
Маршрут, по которому входящие пакеты попадают в AS, выбираются
вне автономной системы.
AS 64520 AS 64510
AS 65000 AS 65250
ISP ISP
R4 R5
R1 R2
R3
AS 65500
Рисунок 25.4 – Обработка полных маршрутов

от всех провайдеров Internet
В примере, показанном на рисунке 25.4, AS 65000 и 65250 посылают

все маршруты в AS 65500.
Провайдер Internet, используемый заданным маршрутизатором из AS
65500 для достижения внешних сетей, обычно является кратчайшим AS пу-
тем. Например, на рисунке 25.4 маршрутизатор R3 выбирает путь через AS
363
65000, чтобы попасть в AS 64520, и выбирает AS 65250, чтобы попасть в AS
65510. На рисунке это обозначено стрелками.
Однако маршрутизаторы из AS 65500 могут быть настроены таким об-
разом, чтобы повлиять на выбор маршрутов к определенным сетям. Напри-
мер, может быть изменено значение атрибута LOCAL PREFERENCE опреде-
ленного маршрута или вес соединения между соседями.
Для этого используется ряд команд, позволяющие влиять на выбор пути
к внешним маршрутам.
Конфигурационная команда neighbor weight предназначена для присво-
ения веса соединению между соседями. Синтаксис команды приводится в
Пример 25.1 – Синтаксис команды neighbor weight

(config-router)# neighbor ip-address | peer-group-name weight number
(config-router)# no neighbor ip-address | peer-group-name weight number
Описание параметров команды clear ip bgp приводиться в таблице 25.1.
Таблица 25.1 – Параметры команды neighbor weight
ра.
number Присваиваемое значение веса.
Конфигурационная команда маршрутизаторов bgp default local-prefer-

ence предназначена для изменения значения атрибута LOCAL PREFERENCE,
принимаемого по умолчанию. Синтаксис команды приводится в примере
25.2.
Пример 25.2 – Синтаксис команды bgp default local-preference

(config-router)# neighbor ip-address | peer-group-name weight number
(config-router)# no neighbor ip-address | peer-group-name weight number
Описание параметров команды bgp default local-preference приводиться

364
Таблица 25.2 – Параметры команды bgp default local-preference
ра.
number Присваиваемое значение локального
приоритета.
По умолчанию значение атрибута LOCAL PREFERENCE равно 100.

Эта команда используется для изменения значения атрибута LOCAL
PREFERENCE на всех маршрутах.
Необходимо помнить, что понятие LOCAL в термине LOCAL
PREFERENCE имеет отношение к автономной системе. Значение LOCAL
PREFERENCE используется для выбора маршрутов с равными весами из-за
того, что атрибут WEIGHT сравнивается в первую очередь. Только тогда,
когда все веса равны, рассматривается локальный приоритет. Атрибут
WEIGHT влияет только на локальный маршрутизатор, тогда как атрибут ло-
кального приоритета влияет и на другие маршрутизаторы автономной систе-
мы.
Локальный приоритет присутствует в исходящих пакетах обновления
протокола EBGP.
Для того чтобы активизировать новые параметры, необходимо с помо-
щью команды clear ip bgp установить новый сеанс с соседом. Так происходит
благодаря инкрементной природе обновлений протокола BGP и тому, что
атрибут MODIFIERS применяется на входящие или исходящие пакеты обнов-
ления, а не на записи, уже существующие на маршрутизаторе.
В примере, показанном на рисунке 25.5, автономная система 64520 под-
ключена к двум провайдерам Internet: AS 65000 и 65250. Оба провайдера рас-
сылают полные маршруты на AS 64520.
Пример 25.3 – Конфигурация R1 без дополнительных настроек

router bgp 64520
network 10.10.10.0 mask 255.255.255.0
network 10.10.20.0 mask 255.255.255.0
365
AS 65500
172 .25.0.0/16
R4
AS 65000 AS 65250
172 .20.0.0/16 172 .30.0.0/16
R2 R3
10
0
/3
.1
.0
0.
20
10
.0
0.
.1
/3
10
0
R1
AS 64520
Рисунок 25.5 – Двойное подключение AS 64520
В первой конфигурации, показанной в примере 25.3, маршрутизатор R1

настроен на работу с двумя EBGP соседями: маршрутизаторами R2
(10.10.10.2) и R3 (10.10.20.1). Не было сделано никаких дополнительных на-
строек, влияющих на путь, по которому пакеты из AS 64520 попадают в дру-
гие автономные системы.
В примере 25.4 приведен вывод команды show ip bgp для маршрутиза-
тора R1 из сети, изображенной на рисунке 25.5.
Пример 25.4 – Вывод команды show ip bgp для маршрутизатора R1

r1#show ip bgp
Status codes: s suppressed, d damped, h history,* valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
*> 10.10.10.0/24 0.0.0.0 0 32768 i
*> 10.10.20.0/24 0.0.0.0 0 32768 i
* 172.20.0.0 10.10.20.1 0 65250 65000 i
*> 10.10.10.2 0 0 65000 i
*> 172.25.0.0 10.10.10.2 0 65000 65500 1
* 10.10.20.1 0 65250 65500 i
* 172.30.0.0 10.10.10.2 0 65000 65250 i
*> 10.10.20.1 0 0 65250 i
366
В нем маршрутизатор R1 для доступа к 172.20.0.0 выбирает маршрут,
проходящий через 10.10.10.2, и маршрут, проходящий через 10.10.20.1, для
доступа к 172.30.0.0 из-за того, что эти пути имеют кратчайшее значение
атрибута AS-PATH.
От маршрутизатора R1 есть два пути к 172.25.0.0, характеризующиеся
одинаковой длиной AS пути. В этом случае, при равенстве всех остальных
атрибутов, маршрутизатор R1 выберет самый старый путь. Проигнорировав
критерий выбора самого старого пути, маршрутизатор R1 выберет путь, име-
ющий минимальное значение идентификатора маршрутизатора для протокола
BGP.
К сожалению, значения идентификатора протокола BGP маршрутизато-
ров R2 и R3 не отображаются в листинге команды show ip bgp. Для получения
этих значений можно воспользоваться командой show ip bgp neighbors или
show ip bgp 172.25.0.0.
По результатам работы этих команд видно, что идентификатор маршру-
тизатора для маршрутизатора R2 равен 172.20.0.1, а идентификатор маршру-
тизатора для маршрутизатора R3 равен 172.30.0.1. Маршрутизатор R1 выбе-
рет маршрутизатор с меньшим идентификатором и путь на 172.25.0.0 через
маршрутизатор R2 (172.20.0.1).
В примере 25.5 маршрутизатор R1 настроен на работу с двумя EBGP
соседями: это маршрутизаторы R2 и R3. Значения весов, используемых для
маршрутов от каждого соседа, были изменены и отличаются от значений по
умолчанию. Маршруты, полученные от R2, будут иметь вес, равный 100, а
маршруты, полученные от R2, будут иметь вес, равный 150.
Пример 25.5 – Конфигурация R1 с дополнительными настройками

router bgp 64520
network 10.10.10.0 mask 255.255.255.0
network 10.10.20.0 mask 255.255.255.0
neighbor 10.10.10.2 weight 100
neighbor 10.10.20.1 weight 150
В примере 25.6 представлена команда show ip bgp для маршрутизатора

R1 при измененных весах. В этом примере видно, что, из-за того, что вес для
маршрутизатора R3 больше веса маршрутизатора R2, маршрутизатор R1 вы-
нужден использовать маршрутизатор R3 в качестве следующего узла на пути
на внешние маршруты. Атрибут WEIGHT анализируется до анализа длины
AS пути, поэтому длина AS пути в этом случае игнорируется.
367
Пример 25.6 – Вывод команды show ip bgp для маршрутизатора R1
r1#show ip bgp
Status codes: s suppressed, d damped, h history,* valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
*> 10.10.10.0/24 0.0.0.0 0 32768 i
*> 10.10.20.0/24 0.0.0.0 0 32768 i
* 172.20.0.0 10.10.20.1 150 0 65250 65000 i
*> 10.10.10.2 0 100 0 65000 i
*> 172.25.0.0 10.10.10.2 150 0 65000 65500 1
* 10.10.20.1 100 0 65250 65500 i
* 172.30.0.0 10.10.10.2 150 0 65000 65250 i
*> 10.10.20.1 0 100 0 65250 i
368
Заключение
Сетевые специалисты утверждают, что 50% знаний в этой динамичной

области техники полностью устаревают за 10 лет. Можно, конечно, спорить о
точном количестве лет и процентов, но факт остается фактом: набор базовых
технологий, представления о перспективности той или иной технологии, под-
ходы и методы решения ключевых задач и даже понятия о том, какие задачи
при создании корпоративных сетей являются ключевыми – все это изменяет-
ся очень быстро и часто неожиданно. И примеров, подтверждающих такое по-
ложение дел, можно привести достаточно много.
Еще не так давно казалось, что протокол RIP будет постоянно самым
распространенным протоколом маршрутизации. Это было связано, прежде
всего, с его простотой и минимальными требованиями к вычислительным ре-
сурсам маршрутизаторов.
Однако прошло совсем немного времени, и протокол RIP сдал свои по-
зиции более интеллектуальным протоколам маршрутизации, таким как EI-
GRP и OSPF. Данные протоколы позволяют осуществлять более качествен-
ную маршрутизацию трафика, снимают ограничения по размерам сети пере-
дачи данных. А их недостатки, такие как значительные требования, к ресур-
сам маршрутизаторов, компенсируются техническими возможностями совре-
менных маршрутизаторов и коммутаторов третьего уровня.
Но, несмотря на обилие примеров, нельзя абсолютизировать изменчи-
вость сетевых технологий. Ведь остаются «другие» 50% - это те знания о се-
тях передачи данных, которые составляют фундамент образования сетевого
специалиста. Несмотря на свою изменчивость, протоколы маршрутизации ис-
пользуют в своей работе математические задачи и алгоритмы которые были
доказаны и разработаны на заре эры компьютерных сетей.
369
Словарь терминов
A
ААА. См. аутентификация, авторизация и учет.
АСК. 1. Бит подтверждения в сегменте TCP. 2. См. подтверждение (acknow-
ledgment).
ACL. См. список доступа.
AD. См. административное расстояние.
AppleTalk. Набор коммуникационных протоколов, разработанных Apple
Computer.
ARIN. См. американский реестр адресов Internet.
AS. См. автономная система.
ASBR. См. граничный маршрутизатор автономной системы.
AUX. Вспомогательный порт в маршрутизаторах Cisco.
B
BDR. См. резервный выделенный маршрутизатор.
BGP. См. протокол пограничного шлюза.
C
CIDR. См. внеклассовая междоменная маршрутизация.
CIR. См. согласованная скорость передачи.
CPE. См. оборудование клиента.
CSU. См. модуль обслуживания канала.
D
DBD. См. пакеты описания базы данных.
DCE. См. терминальное оборудование канала передачи данных.
DHCP. См. протокол динамической конфигурации узла.
DR. См. выделенный маршрутизатор.
DSU. См. модуль обработки данных.
DTE. См. терминальное оборудование.
DUAL. См. алгоритм диффузионного обновления.
370
E
E1 (External Type 1). Запись о внешнем канале автономной системы. Рассы-
лаемые ASBR маршрутизаторами, они описывают маршруты к получателям,
являющимся внешними относительно автономной системы. Они рассылаются
через автономные системы протокола OSPF за исключением тупиковых, пол-
ностью тупиковых и NSSA зон. Если пакет является пакетом E1, то метрика
вычисляется прибавлением внешней стоимости к внутренней стоимости каж-
дого канала, который проходит пакет.
E2 (External Type 2). Запись о внешнем канале автономной системы. Рассы-
лаются из ASBR маршрутизаторов и описывают маршруты к получателям,
являющимся внешними относительно автономной системы. Они рассылаются
через автономные системы протокола OSPF за исключением тупиковых, пол-
ностью тупиковых и NSSA зон. Если пакет является пакетом E2, то метрике
будет всегда присваиваться только внешняя стоимость, независимо от того,
где в зоне он проходит. Пакеты этого типа используются только тогда, когда
единственный маршрутизатор объявляет маршрут на автономную систему.
Маршруты типа 2 имеют предпочтение перед маршрутами типа 1, если од-
новременно не существует два маршрута к получателю, имеющему одинако-
вую стоимость.
EBGP. См. внешний протокол BGP.
EIGRP. См. расширенный протокол маршрутизации внутреннего шлюза.
F
Frame Relay. Стандартный протокол коммутируемой передачи данных ка-
нального уровня, который с помощью HDLC инкапсуляции управляет
несколькими виртуальными каналами между подключенными устройствами.
H
Hello пакет. Широковещательный пакет, который используется маршрутиза-
торами для обнаружения и восстановления информации о соседних маршру-
тизаторах. Сообщения приветствия также сообщают об активности устрой-
ства и его готовности к работе в сети.
HSRP. См. резервный протокол маршрутизации.
I
IPX. См. межсетевой пакетный обмен.
371
IP адрес (IP address). 32 разрядный адрес, присваиваемый узлам протоколом
TCP/IP. IP адрес относится к одному из пяти классов (А, В, С, D или Е) и за-
писывается в виде 4 октетов, разделенных точками. Каждый адрес состоит из
сетевого номера, дополнительного номера подсети и номера узла. Номера
сети и подсети используются для маршрутизации, а номер узла - для адреса-
ции отдельного узла этой сети или подсети. Маска подсети используется для
извлечения информации о сети и подсети из IP адреса.
IP протокол (Internet Protocol, IP). Протокол сетевого уровня из набора
TCP/IP для объединения сетей без подтверждения соединения. IP протокол
обладает возможностями адресации, спецификации типа обслуживания, фраг-
ментации и повторной сборки, а также обеспечения безопасности. Описан в
документе RFC 791.
K
kbps. Килобит в секунду.
L
LSA. См. объявление о состоянии канала.
LSAck. См. подтверждение состояния канала.
LSR. См. запрос состояния канала.
LSU. См. обновление состояния канала.
M
MD5 (Message Digest 5). Алгоритм аутентификации. MD5 проверяет це-
лостность связи, выполняет аутентификацию отправителя и проверяет
своевременность действий.
MED (Multi-Exit-Discriminator). В протоколе BGP атрибут MED является
опциональным нетранзитивным атрибутом.
N
NAT. См. трансляция сетевых адресов.
NBMA. См. нешироковещательный множественный доступ.
NSSA зона. В протоколе OSPF NSSA-зона импортирует ограниченное коли-
чество внешних маршрутов. Количество маршрутов ограничено только теми,
которые необходимы для обеспечения связности между магистральными зо-
нами.
NVRAM. См. энергонезависимое ОЗУ.
372
O
OSI. См. взаимодействие открытых систем.
OSPF. См. первоочередное открытие кратчайших маршрутов.
P
ping. См. проверка доступности получателя.
Q
QoS. См. качество обслуживания.
R
RFC. См. документы RFC.
RIP. См. протокол маршрутной информации.
Метрика маршрутизации. Иногда называют просто метрикой. Стандартное
измерение, такое как длина пути, с помощью которого алгоритм маршрутиза-
ции определяет, что один маршрут лучше другого. Эта информация хранится
в таблицах маршрутизации. Метриками являются полоса пропускания, затра-
ты на соединение, задержка, количество пройденных узлов, нагрузка, MTU,
стоимость пути и надежность.
RTO. См. тайм-аут повторной посылки.
RTP. См. Быстрый транспортный протокол.
S
SA. Адрес отправителя.
SIA (Stuck in active). В некоторых ситуациях ожидание ответов на запросы
протокола EIGRP занимает очень много времени. Таким образом, в действи-
тельности маршрутизатор, выдавший запрос, отменяет его и разрывает связь
с маршрутизатором, который не отвечает, тем самым, перезапуская сеанс свя-
зи с соседом
SPF. См. алгоритм предпочтительного выбора кратчайшего маршрута.
split-horizon. См. разделение горизонта.
SRTT (Smooth round-trip time). Это время в миллисекундах, необходимое
локальному маршрутизатору для отсылки EIGRP пакета на соседнее устрой-
ство и получения подтверждения.
Stub area. См. тупиковая зона.
373
Stub network. См. тупиковая сеть.
Subnet. См. подсеть.
Successor. См. преемник.
SVC. См. коммутируемый виртуальный канал.
T
TCP. См. протокол управления передачей.
TCP/IP. См. протокол управления передачей/Internet протокол.
ToS. См. тип обслуживания.
U
UDP. См. протокол дейтаграмм пользователя.
V
VLSM. См. маска подсети переменной длины.
W
WAN. См. глобальная сеть.
А
Автономная система (autonomous system, AS). Объединение сетей под об-
щим управлением, в котором используется одна стратегия маршрутизации.
Автономные системы могут делиться на зоны.
Агрегирование (aggregation). См. суммирование маршрутов.
Административное расстояние (administrative distance, AD). Степень дове-
рительности отправителя маршрутной информации. Выражается числом от 0
до 255. Чем больше административное расстояние, тем ниже степень довери-
тельности.
Адрес (address). Структура данных или логическое соглашение для иденти-
фикации уникального объекта, например процесса или сетевого устройства.
Адрес отправителя. Адрес сетевого устройства, отсылающего данные. См.
также адрес получателя.
Адрес получателя. Адрес сетевого устройства, получающего данные. См. так-
же адрес отправителя.
Алгоритм (algorithm). Четко определенное правило или процесс решения за-
дачи. В сетях по алгоритмам определяется наилучший маршрут трафика от от-
374
правителя к получателю.
Алгоритм выбора первого кратчайшего маршрута (Shortest Path First Al-
gorithm, SPF). Алгоритм маршрутизации, включающий в связное дерево в
первую очередь кратчайшие маршруты. Иногда называется алгоритмом
Дейкстра (Dijkstra).
Алгоритм диффузионного обновления (Diffusing Update Algorithm,
DUAL). Алгоритм сходимости, используемый в расширенном протоколе
IGRP. Обеспечивает отсутствие циклов на протяжении всего маршрута. Поз-
воляет маршрутизаторам, задействованным в изменении топологии, прово-
дить синхронизацию одновременно, не затрагивая маршрутизаторы, на ко-
торые не повлияли изменения.
Алгоритм маршрутизации Беллмана-Форда (Bellman-Ford routing al-
gorithm). См. алгоритм дистанционно-векторной маршрутизации.
Алгоритм маршрутизации по состоянию канала (link-state routing al-
gorithm). Алгоритм маршрутизации, в котором каждый маршрутизатор пере-
дает в широковещательном режиме информацию, учитывая стоимость дости-
жения соседних маршрутизаторов для всех узлов объединенной сети.
Американский реестр адресов Internet (American Registry for Internet
Numbers, ARIN). Некоммерческая организация, которая занимается адми-
нистрированием и регистрацией IP-адресов в соответствии с географически-
ми областями, определяемыми Network Solutions (InterNIC). Эти области
включают Северную и Южную Америку, Южную Африку, Карибский бас-
сейн и др.
Аутентификация, авторизация и учет (Authentication, authorization, and
accounting, AAA). Триединая задача, решаемая в процессе контроля доступа
пользователей в различных сетях.
Аутентификация. В контексте обеспечения безопасности - проверка иден-
тичности пользователя или процесса.
Б
Байт (byte). Последовательность двоичных цифр, которые воспринимаются
как единое целое (например, 8-битовый байт).
Бесклассовые протоколы маршрутизации. Протоколы маршрутизации -
это протоколы, которые включают длину префикса с обновлениями маршру-
тизации; маршрутизаторы, работающие под управлением бесклассовых про-
токолов маршрутизации, не должны определять префиксы сами. Бесклассо-
вые протоколы маршрутизации поддерживают VLSM маршрутизацию.
Бит (bit). Двоичная цифра, используемая в двоичной системе счисления.
Принимает значение 0 или 1.
Быстрый транспортный протокол (Rapid Transport Protocol, RTP). Про-
токол RTP отвечает за гарантированную, упорядоченную доставку пакетов
протокола EIGRP всем соседям.
375
В
Взаимодействие открытых систем (Open System Interconnection, OSI).
Международная программа стандартизации, созданная ISO и ITU-T, для раз-
работки стандартов межсетевого обмена данными, способствующих функци-
ональной совместимости оборудования различных производителей.
Виртуальный канал (virtual circuit, VC). Логический канал, обеспечиваю-
щий надежное соединение между двумя сетевыми устройствами. Виртуаль-
ный канал определяется парой VPI/VCI и может быть постоянным (perman-
ent, PVC) или коммутируемым (switched, SVC). Виртуальные каналы приме-
няются в сетях Frame Relay, X.25 и ATM. Иногда используется аббревиатура
VC. См. также PVC и SVC.
Внеклассовая междоменная маршрутизация (classless interdomain routing,
CIDR). Технология, поддерживаемая протоколом BGP4, основанная на агре-
гации маршрута. Позволяет маршрутизаторам группировать маршруты для
сокращения объема маршрутной информации, передаваемой основными
маршрутизаторами. С ее помощью несколько IP сетей выглядят для внешних
сетей как одна сеть. Благодаря этому IP адреса и их маски подсети записыва-
ются в виде 4 байтов, разделенных точками, за которыми следует косая черта
и двухзначное число - маска подсети.
Внешний протокол BGP (External BGP, EBGP). Когда протокол BGP рабо-
тает между маршрутизаторами, находящимися в различных автономных си-
стемах, он называется EBGP. Маршрутизаторы, работающие под управлени-
ем протокола EBGP, обычно непосредственно подключены друг к другу.
Внутренние протоколы маршрутизации. Протоколы маршрутизации, исполь-
зуемые маршрутизаторами в пределах одной и той же AS, такие как RIP,
IGRP и EIGRP.
Внутренний протокол пограничного шлюза (Internal Border Gateway Pro-
tocol, IBGP). Когда протокол BGP работает между маршрутизаторами, при-
надлежащими одной AS, он называется внутренним BGP.
Выделенный маршрутизатор (designated router, DR). OSPF маршрутиза-
тор, который генерирует LSA пакеты для сетей с коллективным доступом и
имеющий другие специальные задачи, направленные на обеспечение работо-
способности протокола OSPF. Каждая OSPF сеть коллективного доступа, име-
ющая по крайней мере два подключенных маршрутизатора, обладает одним вы-
деленным маршрутизатором, выбранным hello протоколом протокола OSPF.
Выделенный маршрутизатор позволяет уменьшить количество устанавливае-
мых отношений соседства в сетях коллективного доступа, что позволяет умень-
шить объем трафика протокола маршрутизации и размер топологической базы
данных.
376
Г
Граничный маршрутизатор автономной системы (Autonomous System
Boundary Router, ASBR). ABR маршрутизатор, расположенный между авто-
номной системой OSPF и системой, не принадлежащей OSPF. Он может рабо-
тать с протоколом OSPF и другими протоколами маршрутизации, например
RIP. ASBR маршрутизатор должен находиться в стандартной зоне OSPF.
Групповая передача (multicast). Режим копирования одиночных пакетов и
их передачи заданному подмножеству сетевых адресов. Эти адреса задаются
в поле адреса получателя. Сравните с широковещательной и одноадресной
передачей.
Д
Алгоритм дистанционно-векторной маршрутизации (distance vector rout-
ing algorithm). Класс алгоритмов маршрутизации, основанный на запросах
к маршрутизаторам для посылки всей таблицы маршрутизации или ее ча-
сти, но только соседями. Эти алгоритмы также называются алгоритмами
маршрутизации Беллмана-Форда.
Документы RFC (Request For Comments, RFC). Серия документов IETF с
описаниями набора протоколов Internet и дополнительной информацией. Не-
которые документы RFC приняты IAB в качестве стандартов Internet.
Большинство документов RFC определяют такие протоколы, как Telnet и
FTP, но некоторые носят скорее юмористический или даже исторический ха-
рактер. Документы RFC доступны на многих Web узлах.
Домен маршрутизации. Группа конечных систем и промежуточных сетей,
работающих под управлением одного набора административных правил.
З
Заголовок (header). Управляющая информация, размещаемая перед данными
при их инкапсуляции для передачи по сети.
Закрепление (holddown). Состояние, при котором маршрут задается таким
образом, что маршрутизаторы не посылают и не принимают объявления о
маршруте в течение заданного промежутка времени (holddown period). За-
крепление используется для сброса всей неверной информации о маршруте
во всех маршрутизаторах сети. Маршрут обычно переводится в состояние
закрепления при выходе канала из строя.
Запрос состояния канала (Link-state request, LSP). В протоколе OSPF па-
кет, посланный главному маршрутизатору в случае, если DBD имеет новую
запись о состоянии канала.
Зона (area). Логический набор сетевых сегментов (на основе CLNS, DECnet
377
или OSPF) и присоединенных к ним устройств. Обычно зоны соединены с
другими зонами с помощью маршрутизаторов и образуют единую автоном-
ную систему. См. также автономная система.
К
Канал. 1. Коммуникационный путь достаточной ширины для одной радиоча-
стотной передачи. В некоторых средах несколько каналов может мульти-
плексироваться в одном канале. 2. Коммуникационный путь между двумя
или более точками. 3. Среда сетевых коммуникаций, состоящая из цепи или
пути передачи данных и связанного с ней оборудования, между получа-
телем и отправителем данных. Чаще всего относится к глобальным сетям, но
иногда применяется по отношению к линиям (line) или каналам связи (trans-
mission link).
Качество обслуживания (Quality of Service, QoS). Показатель эффективно-
сти системы передачи данных, который отражает качество передачи и обслу-
живания.
Килобит (Kb). Равен 1024 битам.
Классовые протоколы маршрутизации. Протоколы маршрутизации, не пере-
дающие информацию о длине префикса. Примерами таких протоколов марш-
рутизации являются RIP и IGRP.
Коммутатор (Switch). Сетевое устройство, которое фильтрует, пересылает и
направляет фреймы в зависимости от их адреса получателя. Коммутатор ра-
ботает на канальном уровне модели OSI.
Коммутируемый виртуальный канал (Switched Virtual Circuit, SVC). В
терминологии ATM - коммутируемое виртуальное соединение. Создается ди-
намически, по требованию, разрывается по окончании передачи. SVC приме-
няются в случаях, когда передача данных носит случайный характер. Сравни-
те с PVC.
Л
Лавинная передача (flooding). Способ передачи трафика, используемый в
коммутаторах и мостах, при котором полученный интерфейсом трафик пере-
сылается всем другим интерфейсам этого устройства, за исключением того
интерфейса, по которому информация была первоначально получена.
Локальная сеть (local-area network, LAN). Высокоскоростная компьютер-
ная сеть, покрывающая относительно небольшую площадь (до нескольких
километров). Локальные сети объединяют рабочие станции, периферийные
устройства, терминалы и другие устройства, находящиеся в одном здании
или на другой небольшой территории. В LAN-стандартах определяются типы
кабелей и сигналов на физическом и канальном уровнях модели OSI. Наибо-
378
лее популярными LAN-технологиями являются Ethernet, FDDI и Token Ring.
См. региональная сеть и глобальная сеть.
М
Магистраль (backbone). Часть сети, по которой передается основной трафик
и которая чаще всего является отправителем и получателем для других сетей.
Максимальная единица передачи данных в сети (Maximum transmission
unit, MTU). Максимальный размер (в байтах) пакета данных, который мож-
но передать через данный интерфейс.
Маршрутизатор. Устройство сетевого уровня, которое по одной или несколь-
ким метрикам определяет оптимальный маршрут сетевого трафика. Маршрути-
заторы направляют пакеты данных из одной сети в другую на основании ин-
формации сетевого уровня.
Маршрут по умолчанию. Элемент таблицы маршрутизации, который исполь-
зуется для пересылки фреймов на следующий узел при отсутствии в таблице
маршрутизации явно указанного маршрута.
Маршрутизация. Процесс определения пути к получателю. Маршрутизация в
больших сетях очень сложна, так как пакет по пути к получателю может прой-
ти через множество потенциальных промежуточных точек. Маршрутизация по-
является на сетевом уровне.
Маска подсети (subnet mask). 32 разрядная маска адреса, связанная с IP ад-
ресом, каждый бит маски подсети показывает, как интерпретируются соответ-
ствующие биты IP адреса. В двоичной интерпретации значение 1 обозначает,
что соответствующий бит IP адреса является сетевым или подсетевым битом,
значение 0 в маске подсети обозначает, что соответствующий бит IP адреса
является узловым. Маска подсети показывает, сколько битов было взято у
узлового поля для подсетевого поля. Иногда называется просто маской.
Маска подсети переменной длины (variable-length subnet mask, VLSM).
Возможность определять различные маски для одного и того же сетевого
номера в различных подсетях. VLSM позволяет оптимизировать доступное
адресное пространство. См. также бесклассовые протоколы маршрутизации.
Мгновенное обновление (flash update). Асинхронное обновление маршру-
тов после изменения сетевой топологии. См. обновление маршрутизации.
Международная организация по стандартизации (International Organiza-
tion for Standardization, ISO). Международная ассоциация национальных ор-
ганизаций по стандартизации, разрабатывающая и поддерживающая глобаль-
ные стандарты в сфере коммуникаций и обмена информацией. ISO разработа-
ла популярную модель взаимодействия открытых систем OSI.
Межсетевой пакетный обмен (Internetwork Packet Exchange, IPX). Прото-
кол сетевого уровня NetWare (уровень 3) для передачи данных от серверов к
рабочим станциям.
Метрика (metric). Стандартная мера, такая как производительность, которая
379
служит для измерения того, насколько сеть справляется с задачами, для ре-
шения которых она была создана.
Модули, зависимые от протокола (protocol-dependent modules, PDM). В
протоколе EIGRP PDM-модули отвечают за сетевой уровень, специфические
протокола требования для протоколов IP, IPX и AppleTalk.
Модуль данных протокола (Protocol data unit, PDU). Термин OSI для паке-
тов данных. См. также пакет.
Модуль обработки данных (data service unit, DSU). Устройство, используе-
мое для цифровой передачи данных, которое адаптирует физический интер-
фейс DTE устройства к устройствам линии. DSU модуль также отвечает за
синхронизацию сигналов. Часто упоминается вместе с CSU, например, в виде
CSU/DSU. См. также CSU.
Модуль обслуживания канала (Channel Service Unit, CSU). Цифровое ин-
терфейсное оборудование, устанавливаемое у клиента, для подключения к
локальным телефонным линиям. Часто упоминается вместе с DSU как
CSU/DSU. См. также DSU.
Н
Нешироковещательный множественный доступ (Non Broadcast Multi Ac-
cess, NBMA). Режим множественного доступа к сети, в которой широковеща-
ние не поддерживается (например, в сетях Х.25) или невозможно (например,
группа широковещания SMDS или расширенная Ethernet, которая слишком
велика для этого).
О
Обновление маршрутизации. Сообщение, посылаемое маршрутизатором,
содержащее информацию о доступности сети и дополнительную информа-
цию о стоимости маршрута. Эти сообщения обычно посылаются регулярно
или после изменения сетевой топологии. Сравните с мгновенным обновлени-
ем.
Обновление состояния канала (link-state update, LSU). В протоколе OSPF
главный маршрутизатор отвечает полной информацией о запрошенной запи-
си в LSU пакете.
Оборудование клиента (Customer Premises Equipment, CPE). Конечное
оборудование - терминалы, телефоны, модемы и т.п., - устанавливаемое теле-
фонной компанией у клиента и подключенное к сети телефонной компании.
Объединенная сеть (internetwork). Комплекс сетей, связанных маршрутиза-
торами и другими устройствами. Обычно функционирует как единая сеть.
Иногда называется internet. Этот термин не следует путать с названием гло-
бальной сети Internet.
380
Объявление о состоянии канала (link-state advertisement, LSA). Широкове-
щательный пакет, который содержит информацию о соседних маршрутиза-
торах и стоимости маршрутов. LSA пакеты используются маршрутизатора-
ми приемниками для обновления таблиц маршрутизации.
Объявленное расстояние (advertised distance). Стоимость пути между сле-
дующим узлом и получателем.
Одноадресная передача (unicast). Сообщение, посылаемое по сети одному
определенному получателю. Сравните с широковещательной и групповой
передачей.
Операционная система IOS (Internetwork Operating System). Операцион-
ная система Cisco для объединений сетей. Системное программное обеспече-
ние Cisco, обеспечивающее общую функциональность, возможность
масштабирования и безопасность всех продуктов, использующих архитекту-
ру Cisco Fusion. Cisco IOS обеспечивает централизованную, интегрирован-
ную и автоматизированную установку и управление сетевыми комплексами,
гарантирует поддержку широкого набора протоколов, типов среды переда-
чи, служб и платформ.
Открытый протокол SPF (Open Shortest Path First, OSPF). Канальный
иерархический алгоритм маршрутизации ЮР, предложенный в качестве
преемника RIP для сообщества Internet. В число функций OSPF входит марш-
рутизация по принципу наименьших затрат, многомаршрутная маршрутиза-
ция и распределение нагрузки. См. также EIGRP, IGP, IGRP и RIP.
П
Пакет (packet). Логически сгруппированная информация, состоящая из заго-
ловка, содержащего управляющую информацию, и данных пользователя.
Чаще всего пакетами называют блоки данных сетевого уровня. На разных
уровнях эталонной модели OSI и в разных областях техники для описания ло-
гического группирования информации используются термины «дейтаграм-
ма», «фрейм», «сообщение» и «сегмент».
Пакеты описания базы данных (Database description packets, DBD). Со-
держат описание топологической базы данных. Обмен этими сообщениями
осуществляется в момент установки соседства.
Перераспределение (redistribution). Позволяет переносить маршрутную ин-
формацию в сообщениях обновления из одного протокола маршрутизации в
другой. Иногда называется перераспределением маршрутов (route redistribu-
tion).
Переход (hop). Проход пакета данных между двумя сетевыми узлами (напри-
мер, между двумя маршрутизаторами). См. также счетчик узлов.
Плавающий статический маршрут (floating static route). Статический
маршрут, который имеет большее административное расстояние, чем динами-
чески определенный маршрут; таким образом, он будет заменен динамически
381
определенной маршрутной информацией.
Пограничный маршрутизатор зоны (Area Border Router, ABR). Маршру-
тизатор на границе одной или нескольких OSPF зон, соединяющий их с ма-
гистральной сетью. ABR маршрутизаторы считаются членами OSPF зоны
магистральной сети и присоединенных зон. Следовательно, они поддержи-
вают таблицы маршрутизации, где описаны топологии магистральной сети и
других зон.
Подсеть (subnetwork). В IP сетях - часть сети с общим адресом подсети. Сеть
делится на подсети произвольно, сетевым администратором, чтобы обеспе-
чить многоуровневую, иерархическую структуру маршрутизации, в то же
время, избавляя подсеть от сложной адресации присоединенных сетей.
Подтверждение (уведомление) (acknowledgment). Уведомление, посланное
одним сетевым устройством другому, для подтверждения какого-либо собы-
тия, например, приема сообщения. Иногда сокращается как АСК.
Подтверждение состояния канала (link-state acknowledgment, LSAck). В
протоколе OSPF пакет, в котором маршрутизатор подтверждает получение
DBD информации.
Полоса пропускания (bandwidth). Диапазон между самой высокой и самой
низкой частотой, доступной для передачи сетевых сигналов. Этот термин
также используется для описания пропускной способности носителя или
протокола.
Постоянный виртуальный канал (Permanent Virtual Circuit, PVC). Посто-
янно действующий виртуальный канал. Каналы PVC экономят полосу про-
пускания, необходимую для установки и разрыва соединения, если виртуаль-
ный канал должен существовать постоянно. В ATM он называется постоян-
ным виртуальным соединением. См. коммутируемый виртуальный канал.
Преемник (Successor). Соседний маршрутизатор, используемый для пере-
сылки пакетов по пути к преемнику, характеризующемуся наименьшей сто-
имостью, который при этом гарантированно не является частью маршрут-
ной петли.
Приемлемое расстояние (Feasible Distance, FD). В протоколе EIGRP прием-
лемое расстояние является маршрутом к получателю, характеризующимся наи-
меньшей стоимостью.
Приемлемый преемник (feasible successor, FS). В протоколе EIGRP это со-
седний маршрутизатор, который расположен на пути к получателю, но по по-
казателю «стоимости пути» не самый оптимальный и поэтому не используется
для пересылки данных.
Провайдер услуг Internet (Internet Service Provider, ISP). Коммерческая ор-
ганизация, предоставляющая другим компаниям и индивидуальным поль-
зователям доступ к службам сети Internet.
Проверка доступности получателя (ping, packet internet groper). Эхо-сооб-
щение ICMP и ответ на него. Часто используется в IP-сетях для проверки до-
ступности сетевого устройства.
382
Протокол BGP, версия 4 (BGP v4). BGP v4 поддерживает CIDR маршрути-
зацию и использует механизм агрегации маршрута для уменьшения размера
таблиц маршрутизации. См. также BGP и CIDR.
Протокол внешнего шлюза (Exterior Gateway Protocol, EGP). Протокол
сети Internet для обмена информацией о маршрутизации между автономны-
ми системами. Описан в RFC 904. Не следует путать его с общим внешним
протоколом маршрутизации. EGP является устаревшим вариантом протокола
BGP.
Протокол внутреннего шлюза (Interior Gateway Protocol, IGP). Протокол
Internet, используемый для обмена маршрутной информацией внутри авто-
номной системы. Например, протоколы IGRP, OSPF и RIP.
Протокол дейтаграмм пользователя (User Datagram Protocol, UDP). Про-
токол транспортного уровня, не требующий подтверждения соединения. Вхо-
дит в набор TCP/IP. UDP является простым протоколом для обмена дейта-
граммами без подтверждения или гарантии доставки. Обработка и передача
ошибок выполняется другими протоколами. UDP описан в RFC 768.
Протокол маршрутизации внутреннего шлюза (Interior Gateway Routing
Protocol, IGRP). IGP-протокол, разработанный компанией Cisco для решения
проблем, возникающих при маршрутизации в больших гетерогенных сетях.
Сравните с EIGRP.
Протокол маршрутизации (routing protocol). Протокол, который управляет
работой маршрутизаторов сети с помощью механизмов разделения маршрут-
ной информации. Сообщения протокола маршрутизации перемещаются между
маршрутизаторами. Протокол маршрутизации позволяет производить обмен
данными между маршрутизаторами для обновления и ведения информации, со-
держащейся в таблицах маршрутизации, и осуществляет маршрутизацию с по-
мощью определенных алгоритмов маршрутизации. Сообщения протокола
маршрутизации не содержат трафик конечных пользователей между сетями.
Примерами протоколов маршрутизации являются протоколы IGRP, OSPF и
RIP.
Протокол маршрутной информации (routing information protocol, RIP). 1.
Протокол RIP использует в качестве метрики число узлов. См. модифициро-
ванный IGRP, счетчик узлов, протоколы IGP, IGRP и OSPF. 2. IPX routing
information protocol. Дистанционно-векторный протокол для IPX.
Протокол пограничного шлюза (border gateway protocol, BGP). Междо-
менный протокол маршрутизацией, который пришел на смену EGP и регла-
ментирует обмен информации с другими BGP-системами об их достижимо-
сти. Описан в RFC 1163. См. также и EGP.
Протокол управления передачей (Transmission Control Protocol, TCP).
Ориентированный на соединение протокол транспортного уровня, обеспечи-
вающий надежную дуплексную передачу данных. TCP входит в набор прото-
колов TCP/IP. См. также TCP/IP.
Протокол управления передачей/Internet протокол (Transmission Control
383
Protocol/Internet Protocol, TCP/IP). Общее название набора протоколов, раз-
работанных Министерством обороны США в 1970-х годах для всемирного
сетевого комплекса. Наиболее известные протоколы из этого набора - TCP и
IP. См. также IP, TCP и UDP.
P
Разделение горизонта (split-horizon). Метод маршрутизации, при котором
запрещается передача маршрутной информации через интерфейс маршрути-
затора, через который эта информация была получена. Обновление с разде-
лением горизонта предотвращает зацикливание при маршрутизации.
Распределение нагрузки (load balancing). Способность маршрутизатора рас-
пределять трафик по всем сетевым портам, которые находятся на одинако-
вом расстоянии от адреса получателя. В хороших алгоритмах распределения
нагрузки используется информация о пропускной способности и надежности
каналов. Распределение нагрузки повышает интенсивность использования
сетевых сегментов, а следовательно, и эффективную пропускную способ-
ность сети в целом.
Расширенный протокол маршрутизации внутреннего шлюза (Enhanced
Interior Gateway Routing Protocol, EIGRP). Усовершенствованная версия
протокола IGRP, разработанная компанией Cisco. Обеспечивает высокую схо-
димость и эффективность работы, объединяет преимущества протоколов
маршрутизации по состоянию канала и дистанционно-векторных протоко-
лов.
Резервный выделенный маршрутизатор (backup designated router, BDR).
BDR маршрутизатор не выполняет функции выделенного маршрутизатора,
когда тот работает. Он получает всю информацию, но позволяет назначенному
маршрутизатору выполнять продвижение данных и синхронизацию. BDR
маршрутизатор начинает работать только в случае отказа выделенного маршру-
тизатора.
Резервный протокол маршрутизации (Hot Standby Router Protocol,
HSRP). Обеспечивает высокий уровень доступности сети и прозрачность из-
менений сетевой топологии. HSRP создает группу резервных маршрутизаторов
с главным маршрутизатором, который обслуживает все пакеты, посланные на
резервный (Hot Standby) адрес. Главный маршрутизатор контролируется дру-
гими маршрутизаторами группы, и если он даст сбой, один из этих запасных
маршрутизаторов станет главным и унаследует адрес резервной группы.
С
Сеть с множественным доступом (multiaccess network). Позволяет соеди-
няться и обмениваться данными сразу нескольким устройствам.
384
Сеть (network). Набор компьютеров, принтеров, маршрутизаторов, коммута-
торов и других устройств, способных обмениваться данными по некоторому
каналу передачи.
Смежность (adjacency). Отношение, устанавливаемое между избранными со-
седними маршрутизаторами и конечными узлами, для обмена маршрутной
информацией. В основе смежности лежит общий сегмент сетевой среды.
Согласованная скорость передачи (committed information rate, CIR).
Усредненная по минимальному приращению времени скорость передачи ин-
формации по сети Frame Relay в нормальных условиях. Является одной из
основных метрик, подлежащих согласованию, и измеряется в битах в секун-
ду.
Соседний маршрутизатор (neighboring router). В OSPF - два маршрутизато-
ра, обладающие интерфейсами с общей сетью. В сетях с множественным до-
ступом соседние маршрутизаторы динамически обнаруживаются протоколом
приветствия OSPF.
Список доступа (access list). Список, хранящийся в маршрутизаторе для
управления доступа к маршрутизатору или его доступа к службам, например,
во избежание пересылки пакетов с определенным IP адресом через определен-
ный интерфейс маршрутизатора.
Статический маршрут (static route). Маршрут, настроенный явным образом
и введенный в таблицу маршрутизации.
Субинтерфейс (subiuterface). Один из множества виртуальных интерфейсов
на одном физическом интерфейсе.
Суммирование маршрутов (route summarization). Объединение объявлен-
ных адресов в таблицах маршрутизации. Просуммированные маршруты
уменьшают количество маршрутов в таблице маршрутизации, интенсив-
ность трафика маршрутных обновлений и общую загрузку сети. Также из-
вестно как агрегирование маршрутов.
Счетчик узлов (hop count). Метрика маршрутизации, используемая для из-
мерения расстояния между отправителем и получателем. В протоколе RIP
счетчик узлов является единственной метрикой.
Т
Таблица маршрутизации (routing table). Таблица, хранящаяся в маршрути-
заторе или другом межсетевом устройстве, которая содержит маршруты к
конкретным получателям, а иногда - метрики этих маршрутов.
Тайм-аут повторной посылки (Retransmission timeout, RTO). Это время,
которое протокол EIGRP ожидает перед повторной посылкой пакета из очере-
ди повторной посылки к соседнему сетевому устройству.
Терминальное оборудование (data terminal equipment, DTE). Конечное
устройство пользователя или интерфейса пользовательской сети, которое
является отправителем и/или получателем данных. Терминальное оборудо-
385
вание соединяется с сетью с помощью DCE устройств, например, модема и
обычно использует сигналы синхронизации, генерируемые DCE-устрой-
ством. DTE устройствами могут быть компьютеры, трансляторы протоколов,
а также мультиплексоры. Сравните с DCE.
Терминальное оборудование канала передачи данных (Data circuit-ter-
minating equipment, DCE). Расширенное определение ITU-T, обозначающее
сетевые устройства и соединения, которые находятся в конце сети и образу-
ют интерфейс «пользователь – сеть». DCE – это физическое соединение с се-
тью, передающее трафик и предоставляющее тактовый сигнал для синхрони-
зации передачи данных между устройствами DCE и DTE. К числу DCE при-
надлежат модемы и интерфейсные платы. Сравните с DTE.
Тип обслуживания (Type of service, ToS). Характеристика, применяемая для
маркировки пакетов при маршрутизации по политикам.
Топологическая таблица. В протоколе EIGRP топологическая таблица со-
держит всех получателей, объявленных соседними маршрутизаторами.
Точечная десятичная форма записи (dotted decimal notation). Синтаксиче-
ское представление 32 разрядных адресов в виде четырех 8-разрядных целых
чисел, записанных в десятичном формате и разделенных точками. Использу-
ется для представления IP-адресов, например, в виде 192.67.67.20.
Трансляция сетевых адресов (Network Address Translation, NAT). Меха-
низм сокращения необходимости в глобально уникальных IP адресах. Позво-
ляет подключаться к Internet организации с локально уникальными адресами
путем трансляции этих адресов в глобально маршрутизируемое адресное про-
странство. Также называется Network Address Translator.
Тупиковая зона (stub area). Область OSPF, через которую проходит стан-
дартный, внутризональные и межзональные, но не внешние маршруты.
Тупиковая сеть (stub network). Часть объединенной сети, достичь которую
можно только по одному пути; сеть, где есть только одно соединение с
У
Уровень доступа (access layer). Уровень в иерархической сети, который
обеспечивает доступ пользователя или пользовательских групп к сети.
Ф
Фильтр (filter). Обычно процесс или устройство, которое определяет, пере-
давать или не передавать трафик дальше на основе заданных критериев, таких
как адрес отправителя, адрес получателя или протокол.
386
Ш
Широковещательная передача (broadcast). Система доставки пакетов, при
которой копия каждого пакета передается всем узлам сети. Характеризуется
широковещательными адресами.
Э
Эталонная модель взаимодействия открытых систем (OSI reference mod-
el). Архитектурная модель сети, разработанная ISO и ITU-T. Состоит из семи
уровней, каждый из которых определяет конкретную сетевую функцию, та-
кую как адресация, управление потоками данных, контроль ошибок, инкап-
суляция и надежная передача сообщений. Самый низкий уровень (физиче-
ский) наиболее близок к технологии среды передачи данных. Второй, ниж-
ний, уровень используется программным и аппаратным обеспечением, а пять
верхних уровней используется только программным обеспечением. Самый
верхний уровень (уровень приложений) ближе всего к пользователю. Эталон-
ная модель OSI находит универсальное применение в качестве методики изу-
чения функционирования сетей. В некоторых отношениях OSI подобна SNA.
387
Список использованных источников
1. Cisco IOS AppleTalk Command Reference Release 12.4 / Cisco Systems,

Inc., 2006. – 183 p.
2. Cisco IOS Configuration Fundamentals Command Reference Release 12.4
/ Cisco Systems, Inc., 2006. – 831 p.
3. Cisco IOS Configuration Fundamentals Configuration Guide Release
12.4 / Cisco Systems, Inc., 2006. – 486 p.
4. Cisco IOS Debug Command Reference Release 12.4 / Cisco Systems, Inc.,
2006. – 2086 p.
5. Cisco IOS DECnet Command Reference Release 12.4 / Cisco Systems,
Inc., 2006. – 108 p.
6. Cisco IOS Interface and Hardware Configuration Guide Release 12.4 /
Cisco Systems, Inc., 2006. – 864 p.
7. Cisco IOS IP Addressing Services Command Reference Release 12.4 /
Cisco Systems, Inc., 2006. – 322 p.
8. Cisco IOS IP Routing Protocols Command Reference Release 12.4 / Cisco
Systems, Inc., 2006. – 863 p.
9. Cisco IOS IP Routing Protocols Configuration Guide Release 12.4 / Cisco
Systems, Inc., 2006. – 880 p.
10. Cisco IOS Novell IPX Command Reference Release 12.4 / Cisco Sys-
tems, Inc., 2006. – 230 p.
11. RFC 950. Mogul J. / Internet Standard Subnetting Procedure / J. Mogul,
J. Postel. – Network Working Group, 1985. – 18 p.
12. RFC 1058. Hedrick C. / Routing Information Protocol / C. Hedrick. –
Network Working Group, 1988. – 33 p.
13. RFC 1219. Tsuchiya P. / On the Assignment of Subnet Numbers / P.
Tsuchiya. – Network Working Group, 1991. – 13 p.
14. RFC 1247. Moy J. / OSPF Version 2 / J. Moy. – Network Working
Group, 1991. – 189 p.
15. RFC 1584. Moy J. / Multicast Extensions to OSPF / J. Moy. – Network
Working Group, 1994. – 102 p.
16. RFC 1587. Coltun R. / The OSPF NSSA Option / R. Coltun, V. Fuller. –
17. RFC 1721. Malkin G. / RIP Version 2 Protocol Analysis / G. Malkin. –
18. RFC 1722. Malkin G. / RIP Version 2 Protocol Applicability Statement /
G. Malkin. – Network Working Group, 1994. – 5 p.
19. RFC 1723. Malkin G. / RIP Version 2 / G. Malkin. – Network Working
Group, 1994. – 9 p.
388
20. RFC 1724. Malkin G. / RIP Version 2 MIB Extension / G. Malkin, F.
Baker. – Network Working Group, 1994. – 18 p.
21. RFC 1771. Rekhter Y. / A Border Gateway Protocol 4 (BGP-4) / Y.
Rekhter, T. Li. – Network Working Group, 1995. – 57 p.
22. RFC 1793. Moy J. / Extending OSPF to Support Demand Circuits / J.
Moy. – Network Working Group, 1995. – 32 p.
23. RFC 1918. Rekhter Y. / Address Allocation for Private Internets / Y.
Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. – Network Work-
ing Group, 1996. – 9 p.
24. RFC 1930. Hawkinson J. / Guidelines for creation, selection, and regis-
tration of an Autonomous System (AS) / J. Hawkinson, T. Bates. – Network Work-
ing Group, 1996. – 10 p.
25. RFC 2091. Meyer G. / Triggered Extensions to RIP to Support Demand
Circuits / G. Meyer, S. Sherry. – Network Working Group, 1997. – 22 p.
26. RFC 2270. Stewart J. / Using a Dedicated AS for Sites Homed to a
Single Provider / J. Stewart, T. Bates, R. Chandra, E. Chen. – Network Working
Group, 1998. – 6 p.
27. RFC 2328. Moy J. / OSPF Version 2 / J. Moy. – Network Working
Group, 1998. – 244 p.
28. RFC 2370. Coltun R. / The OSPF Opaque LSA Option / R. Coltun. –
29. RFC 2453. Malkin G. / RIP Version 2 / G. Malkin. – Network Working
Group, 1998. – 39 p.
30. RFC 3101. Murphy P. / The OSPF Not-So-Stubby Area (NSSA) Option /
P. Murphy. – Network Working Group, 2003. – 33 p.
31. Остерлох, Х. Маршрутизация в IP сетях. Принципы, протоколы, на-
стойка: Пер. с англ. / Хифер Остерлох – СПб.: ООО «ДиаСофтЮП», 2002. –
512 с.
32. Руденко, И. Маршрутизаторы CISCO для IP–сетей. Пер. с англ. / И.
Руденко, Tsunami Computing. – М.: КУДИЦ–ОБРАЗ, 2003. – 656 с.
389

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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

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

Загружено:

Авторское право:

Доступные форматы

М.В.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

172 .16.1.0 172 .16.2.0

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

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

172 .16.1.1 172 .16.2.1

172 .16.1.2 172 .16.1.20 172 .16.1.16

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

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

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

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

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

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

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

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

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

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

192.168.0.0/24 192.168.0.0/25 192.168.0.0/26

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

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

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

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

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

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

172 .16.15.0/27 17 172 .16.12.0/24