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

М.В. ДИБРОВ
МАРШРУТИЗАТОРЫ
Учебное пособие
Красноярск 2008
2
Содержание
Введение..................................................................................................................10
Условные обозначения, используемые в пособии...........................................10
Графические символы.....................................................................................10
Соглашения по синтаксису командного языка.............................................11
1 Проектирование масштабируемых сетей передачи данных...........................12
1.1 Масштабируемые сети передачи данных...................................................12
1.2 Архитектура корпоративной сети передачи данных.................................16
1.3 Введение в технологию подсетей и ее обоснование.................................19
1.4 Применение технологии VLSM...................................................................24
1.5 Суммирование маршрутов...........................................................................27
1.6 Проектирование масштабируемого адресного пространства...................28
2 Принципы маршрутизации.................................................................................31
2.1 Определение маршрутизации......................................................................31
2.1.1 Маршрутизируемые и маршрутизирующие протоколы.....................31
2.1.2 Основные функции маршрутизаторов.................................................33
2.2 Концептуальные основы маршрутизации..................................................34
2.2.1 Таблицы маршрутизации.......................................................................34
2.2.2 Административное расстояние.............................................................35
2.2.3 Метрики маршрутов...............................................................................36
2.2.4 Построение таблицы маршрутизации..................................................37
2.3 Механизмы маршрутизации........................................................................37
2.3.1 Прямое соединение................................................................................38
2.3.2 Статическая маршрутизация.................................................................39
2.3.3 Настройка статических маршрутов......................................................40
2.3.4 Использование «плавающих» статических маршрутов......................41
2.3.5 Маршрутизация по умолчанию.............................................................42
2.4 Проверка и устранение ошибок в статических маршрутах......................44
3 Принципы динамической маршрутизации.......................................................45
3.1 Операции динамической маршрутизации..................................................46
3.1.1 Стоимость маршрута..............................................................................47
3.2 Внутренние и внешние протоколы маршрутизации.................................48
3.2.1 Понятие автономной системы и домена маршрутизации..................48
3.2.2 IGP – протоколы внутреннего шлюза..................................................49
3.2.3 EGP – протоколы внешнего шлюза......................................................49
3.3 Обзор классовых протоколов маршрутизации..........................................50
3.3.1 Суммирование маршрутов при классовой маршрутизации...............51
3.3.2 Суммирование маршрутов в разобщенных классовых сетях............52
3.4 Обзор бесклассовых протоколов маршрутизации.....................................53
3.4.1 Суммирование маршрутов при бесклассовой маршрутизации.........53
3.4.2 Суммирование маршрутов в разобщенных классовых сетях............55
3
3.5 Категории алгоритмов маршрутизации......................................................56
3.5.1 Особенности дистанционно-векторных протоколов..........................56
3.5.2 Маршрутизация по состоянию канала.................................................58
3.5.3 Гибридные протоколы маршрутизации...............................................61
3.6 Конфигурирование протокола маршрутизации.........................................61
4 Дистанционно-векторная маршрутизация........................................................65
4.1 Дистанционно-векторный алгоритм...........................................................65
4.1.1 Дистанционно-векторный алгоритм для протокола IP.......................67
4.2 Маршрутизация по замкнутому кругу........................................................69
4.3 Максимальное количество транзитных переходов...................................71
4.4 Применения принципа расщепления горизонта........................................72
4.5 Обратное обновление...................................................................................73
4.6 Таймеры удержания информации...............................................................74
4.7 Механизм мгновенных обновлений............................................................75
5 Протокол RIP.......................................................................................................77
5.1 Настройка протокола RIP.............................................................................78
5.2 Протокол RIP v1............................................................................................78
5.2.1 Заголовок и поля протокола RIP v1......................................................79
5.2.2 Команда – 1 байт....................................................................................80
5.2.3 Версия – 1 байт.......................................................................................80
5.2.4 Неиспользуемые поля – 2 байта............................................................80
5.2.5 Идентификатор семейства адресов – 2 байта......................................80
5.2.6 IP адрес – 4 байта....................................................................................81
5.2.6 Метрика – 4 байта...................................................................................81
5.3 Использование команды ip classless............................................................81
5.4 Недостатки протокола RIP v1......................................................................82
5.5 Протокол RIP v2............................................................................................82
5.5.1 Заголовок и поля протокола RIP v2......................................................83
5.5.2 Тег маршрута – 2 байта..........................................................................83
5.5.3 Маска подсети – 4 байта........................................................................83
5.5.4 Следующая пересылка – 4 байта...........................................................84
5.6 Аутентификация в протоколе RIP v2..........................................................84
5.6.1 Настройка аутентификации для протокола RIP..................................85
5.7 Суммирование маршрутов в протоколе RIP..............................................86
5.7.1 Распространение маршрута по умолчанию.........................................88
5.8 Расширенная настройка протокола RIP......................................................89
5.8.1 Таймеры протокола RIP.........................................................................89
5.8.2 Совместное использование в сети протокола RIP v1 и v2.................91
5.8.3 Распределение нагрузки в протоколе RIP............................................92
5.8.4 Настройка протокола RIP для работы в сетях NBMA........................93
5.8.5 Механизм инициированных обновлений в протоколе RIP................94
5.9 Тестирование и устранение ошибок в работе протокола RIP..................95
6 Протокол EIGRP..................................................................................................98
4
6.1 Алгоритм диффузионного обновления.......................................................98
6.2 Преимущества протокола EIGRP..............................................................103
6.3 Автономная система протокола EIGRP....................................................104
6.4 База данных протокола EIGRP..................................................................105
6.4.1 Таблица соседства................................................................................105
6.4.2 Таблица топологии...............................................................................107
6.5 Метрика протокола EIGRP........................................................................109
6.6 Функционирование протокола EIGRP......................................................110
6.6.1 Надежность передачи пакетов протокола EIGRP.............................112
6.6.2 Разрыв соседских отношений..............................................................115
6.6.3 Запланированное отключение.............................................................115
6.6.5 Меры обеспечения стабильности протокола EIGRP........................116
6.7 Алгоритм DUAL.........................................................................................117
6.7.1 Работа алгоритма DUAL......................................................................119
6.8 Механизм ответов на запросы...................................................................124
7 Конфигурирование и тестирование протокола EIGRP..................................127
7.1 Запуск протокола EIGRP............................................................................127
7.2 Настройка аутентификации в протоколе EIGRP..................................131
7.3 Суммирование маршрутов в протоколе EIGRP.......................................133
7.4 Настройка маршрута по умолчанию в протоколе EIGRP.......................134
7.5 Распределение нагрузки в протоколе EIGRP...........................................135
7.6 Расширенная настройка протокола EIGRP..............................................137
7.6.1 Таймеры протокола EIGRP..................................................................137
7.6.2 Изменение административного расстояния протокола EIGRP........138
7.6.3 Изменение весовых коэффициентов протокола EIGRP...................139
7.6.4 Настройка протокола EIGRP для сетей NBMA.................................140
7.6.5 Использование EIGRP пропускной способности каналов связи.....141
7.6.6 Идентификация маршрутизаторов в протоколе EIGRP ..................141
7.7 Тестирование и устранение ошибок в работе протокола EIGRP...........142
8 Использование протокола EIGRP в масштабируемых сетях........................151
8.1 Масштабируемость. Проблемы и решения..............................................152
8.2 Использование суммарных маршрутов....................................................153
8.3 Использование тупиковых маршрутизаторов..........................................155
8.4 Использование протокола EIGRP в современных условиях..................158
9 Протоколы маршрутизации по состоянию канала.........................................160
9.1 Алгоритм «кратчайшего пути» Дейкстры................................................163
10 Протокол OSPF ...............................................................................................167
10.1 Характеристики протокола OSPF............................................................167
10.1.1 Групповая рассылка обновлений состояния каналов.....................168
10.1.2 Аутентификация.................................................................................168
10.1.3 Быстрота распространения изменения в топологии.......................168
10.1.4 Иерархическое разделение сети передачи данных.........................169
10.2 База данных протокола OSPF..................................................................170
5
10.2.1 Таблица соседства..............................................................................170
10.2.2 Таблица топологии.............................................................................171
10.3 Метрика протокола OSPF........................................................................174
10.4 Служебные пакеты протокола OSPF......................................................175
10.4.1 Пакет приветствия..............................................................................176
10.4.2 Суммарная информация о таблице топологии................................178
10.4.3 Запрос на получение информации о топологическом элементе....179
10.4.4 Обновление информации о топологических элементах.................180
10.4.5 Подтверждение о получении.............................................................180
10.5 Процесс установки соседских отношений.............................................181
10.5.1 Поиск соседей.....................................................................................181
10.5.2 Обмен топологической информацией..............................................183
11 Настройка протокола OSPF в одной зоне.....................................................185
11.1 Запуск протокола OSPF............................................................................185
11.2 Управление значением идентификатора маршрутизатора OSPF.........188
11.3 Настройка аутентификации в протоколе OSPF..................................190
11.3.1 Проверка функционирования аутентификации...............................192
11.4 Настройка маршрута по умолчанию в протоколе OSPF.......................193
11.5 Распределение нагрузки в протоколе OSPF...........................................194
11.6 Расширенная настройка протокола OSPF..............................................195
11.6.1 Таймеры протокола OSPF..................................................................195
11.6.2 Изменение административного расстояния протокола OSPF........196
11.7 Тестирование и устранение ошибок в работе протокола OSPF...........197
12 Работа протокола OSPF в сетях различных типов.......................................208
12.1 Работа протокола OSPF в сетях «Точка-Точка»....................................208
12.2 Работа протокола OSPF в широковещательных сетях..........................209
12.2.1 Правила выбора DR и BDR маршрутизаторов................................210
12.3 Работа протокола OSPF в сетях NBMA..................................................211
12.4 Режимы работы протокола OSPF в сетях NBMA..................................212
12.5 Режимы работы протокола OSPF в сетях Frame Relay.........................214
12.5.1 Нешироковешательный режим ........................................................214
12.5.2 Многоточечный режим .....................................................................217
12.5.3 Использование подинтерфейсов.......................................................218
12.6 Проверка работы протокола OSPF в сетях различных типов...............220
13 Работа протокола OSPF в нескольких зонах................................................222
13.1 Типы маршрутизаторов OSPF.................................................................224
13.1.1 Внутренние маршрутизаторы...........................................................225
13.1.2 Магистральные маршрутизаторы.....................................................225
13.1.3 Пограничные маршрутизаторы.........................................................225
13.1.4 Пограничные маршрутизаторы автономной системы....................225
13.2 Типы объявлений о состоянии каналов..................................................226
13.2.1 Структура заголовка сообщения LSA..............................................226
13.2.2 Объявление состояния маршрутизатора (Тип 1).............................229
6
13.2.3 Объявление состояния сети (Тип 2).................................................231
13.2.4 Суммарные объявления о состоянии каналов (Тип 3 и 4)..............232
13.2.5 Объявления внешних связей (Тип 5 и 7)..........................................234
13.3 Построение таблицы маршрутизации протоколом OSPF.....................235
13.3.1 Типы маршрутов протокола OSPF...................................................236
13.3.2 Расчет метрики внешних маршрутов...............................................238
13.4 Суммирование маршрутов протоколом OSPF.......................................239
13.4.1 Суммирование межзональных маршрутов......................................239
13.4.2 Суммирование внешних маршрутов................................................242
13.4.3 Отображение внешних суммарных маршрутов..............................243
14 Специальные типы зон протокола OSPF......................................................245
14.1 Типы зон протокола OSPF.......................................................................245
14.1.1 Правила тупиковых зон.....................................................................246
14.2 Тупиковые зоны протокола OSPF...........................................................246
14.2.1 Настройка тупиковой зоны................................................................247
14.3 Полностью тупиковые зоны протокола OSPF.......................................247
14.3.1 Настройка полностью тупиковой зоны............................................248
14.4 Таблицы маршрутизации в тупиковых зонах........................................250
14.5 Не совсем тупиковые зоны протокола OSPF.........................................252
14.5.1 Настройка не совсем тупиковой зоны..............................................252
14.5.2 Настройка полностью тупиковой зоны NSSA.................................254
14.6 Проверка функционирования специальных зон протокола OSPF.......254
15 Виртуальные каналы в протоколе OSPF.......................................................256
15.1 Настройка виртуальных каналов.............................................................257
15.1.2 Примеры использования виртуальных каналов..............................259
15.2 Проверка функционирования виртуальных каналов.............................260
16 Перераспределение маршрутной информации............................................262
16.1 Понятие перераспределения маршрутной информации.......................262
16.2 Понятие метрического домена................................................................264
16.3 Маршрутные петли...................................................................................266
16.3.1 Односторонние перераспределение маршрутной информации....268
16.3.2 Двухсторонние перераспределение маршрутной информации.....271
16.3.3 Протоколы маршрутизации подверженные образованию маршрутных петель......................................................................................................274
17 Совместная работа нескольких протоколов маршрутизации.....................275
17.1 Совместная работа протоколов маршрутизации без перераспределения
.............................................................................................................................275
17.2 Настройка базового перераспределения маршрутной информации....279
17.2.1 Метрика, присваиваемая перераспределяемым маршрутам..........281
17.3 Настройка перераспределения маршрутной информации из присоединенных и статических маршрутов...................................................................283
17.4 Настройка перераспределения маршрутной информации в протокол
RIP......................................................................................................................286
7
17.5 Настройка перераспределения маршрутной информации в протокол
EIGRP.................................................................................................................288
17.6 Настройка перераспределения маршрутной информации в протокол
OSPF...................................................................................................................289
18 Управление трафиком маршрутных обновлений.........................................292
18.1 Использование пассивных интерфейсов................................................292
18.1.1 Настройка пассивных интерфейсов..................................................294
18.2 Фильтрация маршрутной информации, передаваемой между маршрутизаторами.........................................................................................................296
18.2.1 Фильтрация сетей получателей по IP адресу сети..........................297
18.2.2 Фильтрация сетей получателей по длине префикса.......................302
18.2.3 Использование списков доступа и списков префиксов при фильтрации маршрутной информации......................................................................304
18.3 Фильтрация маршрутной информации в процессе перераспределения
маршрутной информации.................................................................................308
19 Маршрутные карты.........................................................................................310
19.1 Понятие маршрутных карт.......................................................................310
19.2 Настройка маршрутной карты.................................................................311
19.3 Использование маршрутных карт при перераспределении маршрутной
информации.......................................................................................................316
19.4 Проверка конфигурации маршрутных карт...........................................317
20 Маршрутизация по политикам.......................................................................319
20.1 Понятие маршрутных политик................................................................319
20.2 Настройка маршрутизации по политикам..............................................320
20.3 Пример маршрутизации по политикам...................................................322
20.4 Проверка маршрутизации по политикам................................................323
21 Обзор протокола BGP.....................................................................................325
21.1 Автономные системы...............................................................................325
21.2 Использование протокола BGP...............................................................326
21.2.1 Когда используется протокол BGP...................................................327
21.2.2 Когда не следует использовать протокол BGP................................328
22 Терминология и концепции протокола BGP................................................329
22.1 Характеристики протокола BGP.............................................................329
22.2 Таблицы протокола BGP..........................................................................330
22.3 Одноранговые устройства или соседи BGP...........................................330
22.4 Маршрутизация по политикам................................................................331
22.5 Атрибуты протокола BGP........................................................................332
22.5.1 Содержимое сообщения обновления протокола BGP....................332
22.5.2 Стандартные и опциональные атрибуты..........................................333
22.5.3 Атрибут «Путь к AS».........................................................................334
22.5.4 Атрибут «Узел следующего перехода»............................................335
22.5.5 Атрибут «Локальный приоритет».....................................................337
22.5.6 Атрибут MED......................................................................................339
8
22.5.7 Атрибут «Отправитель».....................................................................340
22.5.7 Атрибут «Сообщество»......................................................................340
22.5.8 Атрибут «Вес»....................................................................................341
23 Работа протокола BGP....................................................................................343
23.1 Типы сообщений протокола BGP............................................................343
23.1.1 Состояния BGP соседей.....................................................................344
23.2 Процесс принятия решения при выборе пути........................................346
23.2.1 Выбор нескольких путей...................................................................347
23.3 CIDR маршрутизация и суммирование маршрутов..............................348
24 Настройка протокола BGP..............................................................................350
24.1 Одноранговые группы..............................................................................350
24.2 Основные команды протокола BGP........................................................351
24.2.1 Модификация атрибута NEXT-HOP.................................................354
24.2.2 Описание объединенного адреса в BGP таблице............................354
24.2.3 Перезапуск протокола BGP...............................................................356
24.3 Проверка работоспособности протокола BGP.......................................358
25 Множественная адресация.............................................................................359
25.1 Типы множественной адресации.............................................................359
Заключение...........................................................................................................369
Словарь терминов.................................................................................................370
Список использованных источников.................................................................388
9
Введение
Корпоративные сети передачи данных развиваются огромными темпами. С каждым годом задачи, возлагаемые на сеть передачи данных, значительно усложняются, вследствие чего усложняется ее внутренняя структура и
принципы организации, а также растет потребность в эффективной маршрутизации трафика.
Настоящее учебное пособие написано для подготовки магистров по
программе 230100.68.13 «Сети ЭВМ и телекоммуникации», хотя может быть
использовано так же для подготовки специалистов обучающихся по направлению 210100 в качестве спец. курса по выбору в 9 семестре.
В учебном пособии рассматриваются как классические принципы построения, так и современные тенденции в развитии архитектуры сетей передачи данных.
В курсе лекционных и практических занятий, рассматриваются различные принципы маршрутизации, а также детально изучаются протоколы динамической маршрутизации, используемые в современных условиях.
Теоретический материал о каждом из протоколов маршрутизации, основывается на соответствующих стандартах RFC, что дает возможность
рассматривать протокол без привязки к оборудованию конкретного производителя.
Практическая часть курса, команды и примеры конфигурации маршрутизаторов, представленные в пособии, описаны для маршрутизаторов корпорации Cisco с версией операционной системы IOS семейства 12.4. Такой выбор сделан по многим причинам, главные из которых это широкое распространение телекоммуникационного оборудования Cisco, а также унифицированный интерфейс ОС IOS для всего спектра маршрутизаторов Cisco.
Условные обозначения, используемые в пособии
Это учебное пособие содержит вспомогательные элементы, такие как
рисунки, примеры конфигурации и описание синтаксиса команд, целью которых является упрощение восприятия при изучении материала.
Графические символы
Пиктограммы, показанные на рисунке 0.1, используются на протяжении
всего пособия.
10
Маршрутизатор
Коммутатор
Персональный
компьютер
Сервер
Последовательный
канал связи
Канал
связи
Token
Ring
Топология
Ethernet
Топология
Token Ring
500
RIP
Пользователь
Область сети
передачи
данных
Метрика
маршрута
Домен
маршрутизации
Рисунок 0.1 – Пиктограммы, используемые в пособии
Соглашения по синтаксису командного языка
Условные обозначения, используемые в пособии для представления
синтаксиса команд, идентичны условным обозначениям, используемым в
«Справочнике по командам ОС Cisco IOS 12.4» («Cisco IOS Command Reference»).
– Полужирным шрифтом выделяются команды и ключевые слова, которые должны вводиться без изменения.
– Курсивом выделяются параметры с переменными значениями.
– В квадратных скобках ([]) заключены не обязательные элементы.
– Фигурными скобками ({}) выделяется выбор вероятных значений
ключевых слов.
– Вертикальной чертой (|) разделяются альтернативные взаимоисключающие элементы.
– Фигурными скобками и вертикальной чертой внутри квадратных скобок, например [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
Q
A
D
B
G
C
E
J
K
M
L
N
O
F
Подразделение А
I
H
ПодразделениеБ
Рисунок 1.7 – Расширяемость СПД
Операция подключения подразделения, в котором уже существовала своя
сеть передачи данных, к общей СПД корпорации содержит следующие основные этапы:
– Подключение маршрутизаторов P и Q к ядру общей сети передачи данных;
16
– Перевод адресного пространства нового подразделения в общее адресное пространство корпорации и настройка на маршрутизаторах P и Q службы
NAT - Network Address Translation (трансляция сетевых адресов);
– Перевод DHCP сервера подключаемого подразделения в общее адресное пространство;
– Удаление на маршрутизаторах P и Q службы NAT.
Поведение полученной сети предсказуемо (Рисунок 1.8).
Подразделение Д
S
X
Y
R
P
Q
A
D
B
G
C
E
J
K
M
L
N
O
F
Подразделение А
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
Q
A
D
B
G
C
E
J
K
M
L
N
O
F
Подразделение А
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
B
C
Адресное пространство
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
В зависимости от текущего числа устройств в сети и предполагаемого роста этого числа в обозримом будущем, администратор выбирает один из представленных диапазонов адресов.
Первоначально Internet имел двух уровневую иерархию: верхний уровень – Internet в целом и уровень ниже это сети каждая со своим индивидуальным номером. В такой двух уровневой иерархии узел представлял всю
сеть как одиночный объект, «черный ящик», к которому подключено некоторое количество узлов.
Однако с усложнением внутренней структуры сети передачи данных потребовалось введение трех уровневой сетевой иерархии. Согласно RFC 950 был
введен третий уровень иерархии – подсеть.
Класс A
Октет
Класс B
Октет
Класс C
Октет
Сеть
1
2
Узел
3
Сеть
4
Узел
1
2
1
Сеть
2
3
4
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.0.0
172 .16.3.0
172 .16.1.0
172 .16.2.0
Рисунок 1.11 – Сеть 172.16.0.0 разделенная на четыре подсети
Маршрутизатор определяет сеть назначения, используя адрес подсети,
тем самым, ограничивая объем трафика в других сегментах сети.
С точки зрения адресации, подсети являются расширением сетевой части IP адреса сетевого узла (Рисунок 1.12).
20
Таблицамаршрутизации
Сеть
172 .16.1.0
172 .16.2.0
172 .16.1.1
E0
172 .16.1.2
172 .16.1.20
Интерфейс
E0
E1
172 .16.2.1
E1
172 .16.1.16
172 .16
1
16
Сеть
Подсеть
Узел
Рисунок 1.12 – Адреса подсетей
Сетевые администраторы задают размеры подсетей, исходя из потребностей организации и возможного ее роста. Чтобы вычислить результат заимствования определенного количества узловых битов для создания подсети,
необходимо иметь базовые знания из области двоичной математики и помнить битовые значения в каждой из позиций октета, как показано в таблице
1.2.
Таблица 1.2 – Позиция бита и соответствующее десятичное значение
Бит
Значение
1
128
2
64
3
32
4
16
5
8
6
4
7
2
8
1
Независимо от класса IP адреса, последние два бита в последнем октете
никогда не могут быть использованы для формирования подсети. Заимствование всех доступных битов, за исключением двух последних, позволяет создать
подсеть, которая содержит только два узла. Такой способ используется на практике для адресации последовательных каналов связи «точка-точка» между
маршрутизаторами.
Чтобы создать маску подсети, дающую маршрутизатору информацию,
необходимую для вычисления адреса подсети, которой принадлежит конкретный узел, необходимо выбрать столбец из таблицы 1.3 с нужным количеством
бит и в качестве значения маски воспользоваться числом строкой выше из того
же столбца.
Таблица 1.3 – Два формата записи маски подсети
Префикс
Маска
Бит
Значение
/25
128
1
128
/26
192
2
64
/27
224
3
32
/28
240
4
16
/29
248
5
8
/30
252
6
4
/31
254
7
2
/32
255
8
1
21
Другим способом записи маски подсети является способ записи с обратной чертой. Число указанное после символа обратной черты, представляет собой количество бит, составляющих адрес сети, плюс биты, использующиеся
для маски подсети. Данное число также называется префиксом подсети.
В маски подсети используется тот же формат, что и в IP адресе, маска
подсети состоит из четырех октетов, а длина ее составляет 32 бита (Рисунок
1.13).
Сеть
172
IP адрес
Узел
16
0
0
Сеть
Стандартная
маска
255
Узел
255
0
Сеть
8-битная
маска
255
0
Подсеть
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 число
заимствованных бит.
254
192.168.0.0/24
126
62
62
62
62
126
192.168.0.0/25
192.168.0.128/25
192.168.0.0/26
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 subnet 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
20
20
R2
R3
R4
200
R1
Центральный офис
172.16.0.0/16
200
Подразделение А
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
172 .16.15.32/27
172 .16.15.64/27
R2
17
2.
16
.1
5.
22
4/
30
172 .16.12.0/24
172 .16.15.228 /30
R3
30
2/
23
5.
1
.
16
2.
17
R4
R1
Центральный офис
172.16.0.0/16
172 .16.13.0/24
Подразделение А
172.16.12.0/22
172.16.12.0
172.16.13.0
172.16.14.0
172.16.15.0
Адреса подсетей 172.16.12.0/24
10101100.00010000.00001100.00000000
10101100.00010000.00001101.00000000
10101100.00010000.00001110.00000000
10101100.00010000.00001111.00000000
Локальная сеть 1
Локальная сеть 1
Резерв
Удаленные узлы
172.16.15.0
172.16.15.32
172.16.15.64
Адреса подсетей 172.16.15.0/27
10101100.00010000.00001110.00000000
10101100.00010000.00001110.00100000
10101100.00010000.00001110.01000000
Удаленный узел R1
Удаленный узел R2
Удаленный узел R3
172.16.15.224
172.16.15.228
172.16.15.232
172.16.15.236
172.16.15.240
172.16.15.244
172.16.15.248
172.16.15.252
Адреса подсетей 172.16.15.224/30
10101100.00010000.00001110.11100000
10101100.00010000.00001110.11100100
10101100.00010000.00001110.11101000
10101100.00010000.00001110.11101100
10101100.00010000.00001110.11110000
10101100.00010000.00001110.11110100
10101100.00010000.00001110.11111000
10101100.00010000.00001110.11111100
R1–R2
R1–R3
R1–R4
Резерв
Резерв
Резерв
Резерв
Резерв
Рисунок 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
172 .16.15.0/24
R1
Таблицамаршрутизации
172 .16.12.0/24
172 .16.13.0/24
172 .16.14.0/24
172 .16.15.0/24
R2
Таблица маршрутизации
172 .16.12.0/22
Рисунок 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.2.1.0
10.3.2.0
10.2.2.0
Рисунок 1.20 – Иерархическое распределение адресного пространства
Таблицы маршрутизации ядра этой сети содержат только суммарные
маршруты до сетей каждого подразделения. Общее число записей таблиц
маршрутизации маршрутизаторов ядра равно 50.
Стоит обратить внимание на то, что любые изменения в сетевой структуре отдельного подразделения ни как не влияют на суммарный маршрут до этого
подразделения, поэтому эти изменения ни как не могут повлиять на таблицы
маршрутизации ни ядра сети, ни какого-либо другого подразделения.
10.1.1.0/24
10.3.2.0/24
10.2.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.2.1.0
10.1.2.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
IPX 123 .00e0.1efc .0b01
DECnet
Apple
Token
Ring
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
C
D
C
D
D
C
C
D
D
D
D*
172.16.0.0/28 is subnetted, 1 subnets
172.16.0.0 is directly connected, Serial0
10.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
10.89.1.64/26 [90/5639936] via 10.93.1.18, 00:04:50, Serial2
10.93.1.16/28 is directly connected, Serial2
10.89.1.0/26 [90/5639936] via 10.93.1.2, 00:05:15, Serial1
10.93.1.0/26 is a summary, 00:08:57, Null0
10.93.1.0/28 is directly connected, Serial1
10.95.0.32/28 is directly connected, Loopback0
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
10.95.0.44/30 [90/5639936] via 10.93.1.18, 00:04:51, Serial2
10.95.0.40/30 [90/5639936] via 10.93.1.2, 00:05:16, Serial1
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
Источник информации о
маршруте
Прямое соединение
Статический маршрут
Суммарный маршрут EIGRP
Внешний BGP
Внутренний EIGRP
IGRP
OSPF
IS–IS
RIPv1 RIPv2
Внешний EIGRP
Внутренний BGP
Неизвестный
Стандартное административное
расстояние
0
1
5
20
90
100
110
115
120
170
200
255
2.2.3 Метрики маршрутов
Определение того, какой собственно маршрут является наилучшим путем к сети получателю, является особенностью присущей любому протоколу.
Каждый протокол имеет свою меру того, что является лучшим. Маршрутизаторы характеризуют маршрут к сети с помощью метрики маршрута.
Процесс маршрутизации выбирает маршрут, обладающий наименьшим
значением метрики.
Метрики могут быть вычислены на основе одной или нескольких характеристик. Наиболее часто в алгоритмах маршрутизации используются следующие параметры:
– Ширина полосы пропускания представляет собой средство оценки
объема информации, который может быть передан по каналу связи;
– Задержка – промежуток времени, необходимый для перемещения пакета по каждому из каналов связи от отправителя к получателю. Задержка зависит от пропускной способности промежуточных каналов, размера очередей
в портах маршрутизаторов, загрузки сети и физического расстояния;
– Загрузка – средняя загруженность канала связи в единицу времени;
– Надежность – относительное количество ошибок на канале связи;
– Количество переходов – количество маршрутизаторов, которые должен пройти пакет, прежде чем он достигнет пункта назначения;
– Стоимость – значение, обычно вычисляемое на основе пропускной
способности, денежной стоимости или других единиц измерения, назначаемых администратором.
К пункту назначения может существовать множество путей, и все они
могут отображаться в таблице маршрутизации. Если существует более чем
36
один путь к узлу получателю, протокол маршрутизации должен выбрать один
путь как наилучший и поместить его в таблицу маршрутизации. Однако многие протоколы маршрутизации поддерживают механизм балансировки нагрузки, при котором в таблицу маршрутизации могут быть записаны несколько возможных маршрутов к узлу получателю, и передача трафика будет осуществляться по каждому из маршрутов.
2.2.4 Построение таблицы маршрутизации
Одной из основных задач маршрутизаторов является построение таблицы маршрутизации на основе данных полученных от протоколов маршрутизации и настройках введенных вручную.
Выбор маршрута для занесения в таблицу маршрутизации должен основываться на следующих критериях:
– Доступность IP адреса перехода. Процесс маршрутизации заключается в последовательной передачи трафика от отправителя к получателю.
Маршрутизатор должен знать IP адрес следующего маршрутизатора в цепочки передачи трафика.
– Метрика маршрута. Если переход возможен, то протокол маршрутизации выбирает наилучший возможный маршрут передачи. Критерием выбора
маршрута является минимальная метрика маршрута.
– Префикс. Маршрутизатор рассматривает длину префикса (маска подсети), если имеется несколько маршрутов до сети получателя, но с разными
прификсами, то в таблицу маршрутизации заносятся все маршруты.
– Административное расстояние маршрута. Если маршрутизатор имеет
более одного маршрута до получателя, критерием выбора для занесения в таблицу маршрутизации является минимальное административное расстояние.
После создания таблицы маршрутизации маршрутизатор должен поддерживать ее точное соответствие реальной топологии сети. Поддержка таблиц маршрутизации осуществляется либо администратором сети вручную,
либо с помощью динамических протоколов маршрутизации. Независимо от
того, конфигурируются ли маршруты вручную или с помощью протоколов
маршрутизации, точность отображения маршрутов является ключевым фактором в способности маршрутизатора обеспечивать пересылку данных ее получателям.
2.3 Механизмы маршрутизации
Существует несколько механизмов маршрутизации, которые маршрутизатор использует для построения и поддержания в актуальном состоянии своей таблицы маршрутизации. В общем случае при построении таблицы марш-
37
рутизации маршрутизатор применяет комбинацию следующих методов
маршрутизации:
– Прямое соединение;
– Статическая маршрутизация;
– Маршрутизация по умолчанию;
– Динамическая маршрутизация.
И хотя каждый из этих методов имеет свои преимущества и недостатки,
они не являются взаимоисключающими.
2.3.1 Прямое соединение
Прямое соединение – это маршрут, который является локальным по отношению к маршрутизатору. Если один из интерфейсов маршрутизатора соединен, с какой либо сетью напрямую, то при получении пакета, адресованного такой подсети, маршрутизатор сразу отправляет пакет на интерфейс к
которому она подключена, не используя протоколы маршрутизации (Рисунок
2.4).
172.16.0.0
R2
S0
R1
2.
17
.
16
0
1.
S1
S2
17
2.
16
.2
.
R3
0
R4
r1#show ip route
...
Gateway of last resort is not set
C
C
C
172.16.0.0/24
172.16.0.0
172.16.1.0
172.16.2.0
is
is
is
is
subnetted, 3 subnets
directly connected, Serial0
directly connected, Serial1
directly connected, Serial2
Рисунок 2.4 – Прямое соединение
Прямые соединения всегда являются наилучшим способом маршрутизации. Поскольку маршрутизатору всегда известна непосредственно присоединенная к нему сеть, пакеты, предназначенные для нее, направляются из
первых рук, и маршрутизатор не полагается на другие средства определения
маршрутов, например на статические или динамические механизмы маршрутизации.
38
2.3.2 Статическая маршрутизация
Статические маршруты – это такие маршруты к сетям получателям, которые администратор сети вручную вносит в таблицу маршрутизации. Статический маршрут определяет IP адрес следующего соседнего маршрутизатора
или локальный выходной интерфейс, который используется для направления
трафика к определенной сети получателю.
Как следует из самого названия, статический маршрут не может быть
автоматически адаптирован к изменениям в топологии сети. Если определенный в маршруте маршрутизатор или интерфейс становятся недоступными, то
маршрут к сети получателю становиться недоступным.
Преимуществом этого способа маршрутизации является то, что он исключает весь служебный трафик, связанный с поддержкой и корректировкой
маршрутов.
Статическая маршрутизация может быть использована в следующих ситуациях:
– Когда администратор нуждается в полном контроле маршрутов используемых маршрутизатором;
– Когда необходимо резервирование динамических маршрутов;
– Когда есть сети достижимые единственно возможным путем;
– Когда нежелательно иметь служебный трафик необходимый для обновления таблиц маршрутизации, например при использовании коммутируемых каналов связи.
– Когда используются устаревшие маршрутизаторы не имеющие необходимого уровня вычислительных возможностей для поддержки динамических протоколов маршрутизации.
Наиболее предпочтительной топологией для использования статической маршрутизации является топология «звезда». При данной топологии
маршрутизаторы, подключенные к центральной точки сети, имеют только
один маршрут для всего трафика, который будет проходить через центральный узел сети. И один или два маршрутизатора в центральной части сети имеют статические маршруты до всех удаленных узлов.
Однако со временем такая сеть может вырасти до десятков и сотен
маршрутизаторов с произвольным количеством подключенных к ним подсетей. Количество статических маршрутов в таблицах маршрутизации будет
увеличиваться пропорционально увеличению количества маршрутизаторов в
сети. Каждый раз при добавлении новой подсети или маршрутизатора, администратор должен будет добавлять новые маршруты в таблицы маршрутизации на всех необходимых маршрутизаторах.
При таком подходе может наступить момент, когда большую часть своего рабочего времени администратор будет заниматься поддержкой таблиц
39
маршрутизации в сети. В этом случае необходимо сделать выбор в сторону
использования динамических протоколов маршрутизации.
Другой недостаток статической маршрутизации проявляется при изменении топологии корпоративной сети. При этом администратор должен вручную вносить все изменения в таблицы маршрутизации маршрутизаторов, на
которые повлияли изменения в топологии сети.
2.3.3 Настройка статических маршрутов
Для конфигурации статического маршрута используется команда ip
route (Пример 2.2).
Пример 2.2 – Синтаксис команды ip route
(config) ip route prefix mask {ip-address | interface-type interface-number
[ip-address]} [dhcp] [distance] [name] [permanent] [tag tag]
(config) no ip route prefix mask
Описание параметров команды ip route приводиться в таблице 2.2.
Таблица 2.2 – Параметры команды ip route
Параметр
prefix
mask
ip-address
interface-type interface-number
dhcp
distance
name
permanent
tag tag
Описание
Префикс сети получателя.
Маска сети получателя.
IP адрес следующего маршрутизатора
который может быть использован для
достижения сети получателя.
Тип и номер интерфейса, на который
следует передать пакет для отправки
сети получателю.
Позволяет серверу DHCP распространять статический маршрут как маршрут по умолчанию.
Административное расстояние маршрута.
Назначение имени указанному маршруту.
Указание того, что маршрут не может
быть удален из таблицы маршрутизации, если интерфейс, на который он
указывает становиться недоступным.
Ярлык для использования при контроле перераспределения маршрутов.
40
Статические маршруты должны быть заданы на обоих концах канала
связи между маршрутизаторами, иначе удаленный маршрутизатор не будет
знать маршрута, по которому нужно отправлять ответные пакеты и будет построена лишь односторонняя связь (Рисунок 2.5)
10
.1
.1
.2
10
.1
.1
.1
S0
10.1.2.0/24
R2
r2# ip route 172.16.1.0 255.255.255.0 10.1.1.1
S1
172 .16.1.0/24
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).
2
.1.
16
2.
17
17
2.
16
.1
.1
Dial -Up
(BackUp )
192 .168 .1.0/30
10.1.1.0/24
10.1.2.0/24
R1
R2
r2# router eigrp 200
network 10.0.0.0
network 192.168.1.0
ip route 10.1.1.0 255.255.255.0 172.16.1.1 100
r1# router eigrp 200
network 10.0.0.0
network 192.168.1.0
ip route 10.1.2.0 255.255.255.0 172.16.1.2 100
Рисунок 2.6 – Плавающий маршрут
На рисунке 2.6 маршрутизаторы R1 и R2 соединены скоростным каналом связи, так же имеется возможность создания резервного канала связи,
когда основной канал связи недоступен. Пока будет доступен основной канал
связи, статический маршрут не будет занесен в таблицу маршрутизации, потому что его административное расстояние больше чем у маршрута полученного по динамическому протоколу EIGRP. Как только основной канал связи
станет недоступным, маршрут от протокола EIGRP будет удален из таблицы
маршрутизации и на его место будет внесен статический маршрут по резервному коммутируемому каналу.
2.3.5 Маршрутизация по умолчанию
Бывают ситуации, когда маршрутизатору не нужно знать обо всех сетях
в топологии (Рисунок 2.7). Такой маршрутизатор может быть сконфигурирован так, что бы посылать весь трафик или часть трафика, не описанного в таблице маршрутизации, по специальному маршруту, так называемому маршруту по умолчанию. Маршруты по умолчанию могут поступать на маршрутизатор с помощью протоколов динамической маршрутизации или быть настроены на нем вручную.
42
10.1.2.0/24
192 .168 .1.0/30
S0
S1
10
.1
.1
.2
10
.1
.1
.1
172 .16.1.0/24
WAN
R2
S1
r2# ip route 172.16.1.0 255.255.255.0 Serial 0
ip route 0.0.0.0 0.0.0.0 Serial 1
R1
r1# ip route 10.1.2.0 255.255.255.0 10.1.1.2
ip route 0.0.0.0 0.0.0.0 10.1.1.2
r1# show ip route
...
Gateway of last resort is not set
...
C
172.16.1.0/24 is derectly connected, Ethernet 0
C
10.1.1.0/30 is derectly connected, Serial 1
S
10.1.2.0/24 [1/0] via 10.1.1.0
S* 0.0.0.0/0 [1/0] via 10.1.1.0
Рисунок 2.7 – Маршрут по умолчанию
Для задания статического маршрута по умолчанию используется следующий формат команды ip route (Пример 2.3).
Пример 2.3 – Статический маршрут по умолчанию
(config) ip route 0.0.0.0 0.0.0.0 [next-hop-address | outgoing interface]
Описание параметров статического маршрута по умолчанию приводиться в таблице 2.3.
Таблица 2.3 – Параметры статического маршрута по умолчанию
Параметр
next-hop-address
outgoing interface
Описание
IP адрес маршрутизатора которому
перенаправляется пакет.
Выходной интерфейс, на который следует передать пакет для отправки.
Маршрут по умолчанию возможен для любого адреса сети получателя.
Так как маршрутизатор пытается найти в таблице маршрутизации наибольшее соответствие между записями в таблице и адресом получателя, сети
присутствующие в таблице маршрутизации будут просмотрены раньше, чем
маршрутизатор обратиться к маршруту по умолчанию. Если альтернативного
пути в таблице маршрутизации найдено не будет, то будет использован маршрут по умолчанию.
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
mask
longer-prefixes
protocol
process-id
list
access-list-number
access-list-name
Описание
IP адрес, по которому необходимо вывести маршрутную информацию.
Маска подсети.
Вывод информации о маршрутах, которые имеют больший префикс, чем
ip-address mask.
Имя протокола или метода маршрутизации, по которому необходимо вывести маршрутную информацию.
Номер процесса для указанного протокола маршрутизации.
Вывод информации о маршрутах отфильтрованной списком доступа.
Номер списка доступа.
Имя списка доступа.
Для проверки сквозного соединения между маршрутизаторами используется команда 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 Registry of Internet Numbers – ARIN), согласно RFC 2270 для частных AS выделен диапазон номеров 64512 – 65534, автономная система 65535 зарезервирована под служебные задачи.
Протоколы маршрутизации делятся на две категории: внутренние (Interior) и внешние (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.2.0.0
10.1.0.0
10.2.0.0
10.0.0.0
172 .16.0.0
172 .16.1.0
172 .16.2.0
172 .16.1.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
R2
S0
172 .16.1.0
R1
S1
10.2.0.0
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.2.0
172 .16.1.0
172 .16.2.0
172 .16.1.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
172 .16.14.32/27
172 .16.14.64/27
R2
17
2.
16
.1
4.
22
4/
30
172 .16.12.0/24
172 .16.14.228 /30
R3
0
/3
32
.2
4
1
6.
2.1
17
R4
R1
172 .16.13.0/24
Рисунок 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
R1
R2
172 .16.2.0/24
172 .16.0.0/16
R3
10.1.0.0/16
172 .16.0.0/16
R3
Таблица
маршрутизации
10.1.0.0/16
172 .16.1.0/24
172 .16.2.0/24
OSPF
172 .16.2.0/24
172 .16.1.0/24
10.1.0.0/16
R1
R2
172 .16.2.0/24
172 .16.1.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
R3
Таблица
маршрутизации
10.1.0.0/16
172 .16.1.0/24
172 .16.2.0/24
R3
Таблица
маршрутизации
10.1.0.0/16
172 .16.1.0/24
172 .16.2.0/24
10.1.0.0/16
R1
R2
172 .16.2.0/24
172 .16.1.0/24
172 .16.2.0/24
OSPF
172 .16.2.0/24
172 .16.1.0/24
10.1.0.0/16
R1
R2
172 .16.2.0/24
172 .16.1.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.7.0/24
R2
172 .16.0.0/16
R1
R3
172 .16.6.0/24
172 .16.9.0/24
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 protocol) соединяет в себе определенные черты обоих предыдущих типов алгоритмов.
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
R1
Z
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
LS
A
LS
A
L
SA
LS
A
– сообщение о состоянии канала (Link-State Advertisement - LSA). Эти
объявления представляют собой небольшие пакеты, которые содержат информацию об известных маршрутизатору каналах связи;
– база данных топологии (Topological Database). Эта база данных содержит информацию, полученную в сообщениях LSA;
– алгоритм выбора кратчайшего пути (Shortest Path First – SPF). Алгоритм осуществляет вычисления над базой данных топологии сети, результатом чего является построение связующего дерева протокола SPF.
На рисунке 3.15 проиллюстрированы основные операции алгоритма
маршрутизации на основе состояния канала.
Таблица
маршрутизации
База данных
топологии сети

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
process-id
autonomous-system
Описание
Один из возможных протоколов маршрутизации RIP, EIGRP, OSPF и т.д.
Идентификатор процесса маршрутизации.
Номер автономной системы.
После запуска процесса маршрутизации необходимо в режиме конфигурирования выбранного протокола маршрутизации задать номера сетей, которые будут участвовать в выбранном процессе маршрутизации. Для описания
61
сетей участвующих в процессе маршрутизации используется команда network. Синтаксис команды представлен в примере 3.2.
Пример 3.2 – Синтаксис команды network
(config-router) network ip-address [subnet-mask]
Описание основных параметров команды network приводиться в таблице 3.2.
Таблица 3.2 – Параметры команды network
Параметр
ip-address
subnet-mask
Описание
IP адрес сети участвующей в процессе
маршрутизации.
Сетевая маска.
Команда 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-interface для конкретных интерфейсов.
Применение данного механизма позволяет уменьшить нагрузку на сеть,
а так же в некоторой мере защитить сеть от угрозы атак со стороны злоумышленников.
Как говорилось ранее, протоколы динамической маршрутизации могут
производить балансировку нагрузки по маршрутам с равной стоимостью.
Большинство протоколов способны осуществлять распределение нагрузки по нескольким маршрутам, число которых для версий ОС IOS начиная
с 12.3(2)T не должно превышать 16. Количество одновременно используемых
маршрутов может быть указано с помощью команды maximum-paths. Синтаксис команды представлен в примере 3.4.
Пример 3.4 – Синтаксис команды maximum-paths
(config-router) maximum-paths [number-of-paths]
(config-router) no maximum-paths
Описание основных параметров команды maximum-paths приводиться в
таблице 3.4.
Таблица 3.4 – Параметры команды maximum-paths
Параметр
number-of-paths
Описание
Число одновременно используемых
параллельных маршрутов передаваемых в таблицу маршрутизации.
63
Стандартно количество маршрутов для перераспределения нагрузки в
большинстве протоколов маршрутизации не должно превышать четырех.
Маршрутизатор осуществляет балансировку нагрузки по циклическому
принципу, который предполагает, что по очереди используется сначала первый, потом второй и так далее параллельный канал, и по достижении последнего процедура повторяется.
Для многих интерфейсов маршрутизаторов Cisco стандартно включен
механизм быстрой коммутации пакетов (Fast Switching), о чем свидетельствует команда ip route-cache в их конфигурации. В этом случае распределение
нагрузки осуществляется на основе IP адресов получателей. Это означает, что
при наличии, например, двух каналов все пакеты для IP адреса одного получателя будут отправлены через первый канал, для второго адресата через второй, для третьего снова по первому каналу.
Если в конфигурации интерфейса ввести команду no ip route-cache, то в
действие вступит программный механизм коммутации, который осуществляет балансировку нагрузки в пакетном режиме, т.е. первый пакет отправляется по первому каналу, второй по второму, а третий пакет снова по первому каналу.
64
4 Дистанционно-векторная маршрутизация
4.1 Дистанционно-векторный алгоритм
Как говорилось ранее, все дистанционно-векторные протоколы маршрутизации основываются на дистанционно-векторном алгоритме, который был
впервые описан Фордом и Фулкерсоном в работе «Потоки в Сетях». Их работа опиралась в свою очередь на уравнение Беллмана из его книги «Динамическое программирование».
Изучение классического дистанционно-векторного алгоритма проводиться в курсе дискретной математики. Мы же рассмотрим версию, которая
используется в протоколах динамической маршрутизации.
Задача, которую решает дистанционно-векторный алгоритм, – это задача нахождения кратчайших путей между вершинами графа. Граф – это математическая абстракция, в которой вершины соединены между собой ребрами.
Каждое ребро имеет некоторую стоимость его использования. Путь между
двумя вершинами является набором промежуточных ребер и вершин, соединяющих две исходные вершины. Стоимость пути определяется как сумма
стоимостей ребер, составляющих его. Кратчайшим путем между двумя вершинами при этом считается путь с наименьшей стоимостью.
Дистанционно-векторный алгоритм можно определить в виде следующего набора правил:
– В начале работы алгоритма каждая вершина знает лишь пути к смежным вершинам, т. е. вершинам, с которыми она соединена ребрами.
– В процессе работы алгоритма смежные вершины сообщают друг другу о вершинах, им доступных. Каждое объявление состоит из вершины-адресата и стоимости кратчайшего пути, известного информирующей вершине.
– Изначально каждая вершина сообщает только о смежных вершинах со
стоимостью кратчайших путей, равной стоимости ребер.
– При получении объявления вершина рассчитывает стоимость пути к
объявленной вершине через объявляющую как сумму стоимости ребра, ведущего к объявляющей вершине, и стоимости пути, содержащегося в объявлении. После этого вершина проверяет, знает ли она уже о пути к объявленной
вершине-адресату.
– Если не знает или если стоимость известного пути больше вычисленной стоимости нового пути, вершина запоминает новый путь к вершине-адресату.
– Если новый путь заменяет существующий, последний отбрасывается.
– Если стоимость существующего пути меньше или равна стоимости
нового пути, последний будет отброшен.
– После запоминания нового пути вершина должна объявить смежным
вершинам вершину адресат и стоимость нового пути.
65
Математически доказано, что описанный алгоритм вычисляет кратчайшие пути между всеми парами вершин за конечный промежуток времени
(Рисунок 4.1).
A
1
1
1
1
B
C
1
D
Шаг 1
A
E
B
1
B
A
1
A
A
1
A
1
C
D
1
D
F
1
F
E
1
E
H
1
H
B
H
D
C
A
F
C
B
Шаг 2
1
B
C
1
E
B
B
D
1
F
B
C
E
1
H
C
C
F
1
C
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
A
2
B
A
2
C
A
2
C
Шаг 3
A
B
C
D
E
F
H
B
1
B
A
1
A
A
1
A
A
2
B
C
1
C
C
2
A
B
2
A
B
1
B
B
1
B
B
3
C
B
3
C
D
2
B
D
1
D
D
3
A
C
3
B
C
3
B
C
1
C
C
1
C
E
2
B
E
1
E
E
3
A
E
2
B
D
2
B
H
2
C
F
2
C
F
2
C
F
3
A
F
1
F
H
2
C
H
3
A
H
1
H
Шаг 4
A
B
C
D
E
F
H
B
1
B
A
1
A
A
1
A
A
2
B
A
2
B
A
2
C
A
2
C
C
1
C
C
2
A
B
2
A
B
1
B
B
1
B
B
3
C
B
3
C
D
2
B
D
1
D
D
3
A
C
3
B
C
3
B
C
1
C
C
1
C
E
2
B
E
1
E
E
3
A
E
2
B
D
2
B
D
4
C
D
4
C
F
2
C
F
3
A
F
1
F
F
4
B
F
4
B
E
4
C
E
4
C
H
2
C
H
3
A
H
1
H
H
4
B
H
4
B
H
2
C
F
2
C
Рисунок 4.1 – Функционирование дистанционно-векторного алгоритма
Обратите внимание, что ни по завершении работы алгоритма, ни в процессе ее, ни одна вершина не обладает топологическими сведениями ни об
одном маршруте. Каждый обнаруженный путь представлен лишь вершинойадресатом, стоимостью пути и следующей вершиной на пути к вершине-адресату, и представление пути не содержит промежуточных вершин и ребер.
Именно поэтому алгоритм называется дистанционно-векторным; стоимость
66
пути - это дистанция, а вершина-адресат и следующая вершина представляют
собой вектор.
Когда алгоритм завершает работу, результаты могут быть использованы
для «путешествия» между любыми двумя вершинами графа. Находясь в исходной вершине, «путешественник» должен найти путь к вершине-адресату и
переместиться в следующую вершину, указанную в пути. Находясь в следующей вершине, путешественник должен опять найти путь к вершине-адресату
и переместиться в следующую вершину, указанную в этом пути. Путешественник должен продолжать эти действия, пока не достигнет искомой вершины.
Описанный процесс, по существу, является маршрутизацией. Пути,
имеющиеся у каждой вершины, составляют таблицу маршрутизации этой
вершины. Следовательно, задача, которую решает дистанционно-векторный
алгоритм, – это заполнение таблицы маршрутизации путями, или маршрутами, именно эта задача и решается протоколами динамической маршрутизации.
4.1.1 Дистанционно-векторный алгоритм для протокола IP
В версии дистанционно-векторного алгоритма для протокола IP или
другого маршрутизируемого протокола вершины представляют маршрутизаторы, а ребра – соединения между ними.
Предназначение версии дистанционно-векторного алгоритма для протокола IP несколько отличается от предназначения общей версии. Цель версии
для протокола IP находить пути к сетевым префиксам. Следовательно, содержимое объявлений, которыми обмениваются маршрутизаторы, тоже отличается - вместо вершин объявления содержат сетевые префиксы, к которым
имеют доступ объявляющие маршрутизаторы.
Говорят, что сетевые префиксы, содержащиеся в маршрутных обновлениях, анонсируются маршрутизатором. Объявляемые сетевые префиксы берутся с собственных интерфейсов маршрутизатора и получаются от других
маршрутизаторов в маршрутных обновлениях.
Процесс получения и принятия сетевых префиксов, передаваемых в
маршрутных обновлениях других маршрутизаторов, называется обучением.
Однако не все сетевые префиксы в маршрутных обновлениях, которые получает маршрутизатор, принимаются.
Интерфейсы, через которые маршрутизатор получает и отправляет
маршрутные обновления, должны быть отдельно сконфигурированы администратором для выполнения этой задачи. Маршрутизатор не получает и не отправляет маршрутные обновления через другие интерфейсы. Каждый интерфейс, сконфигурированный для получения и передачи маршрутных обновлений, получает некоторую стоимость в рамках протокола маршрутизации, которая используется в двух целях.
67
Маршрутизатор использует стоимость интерфейса в расчетах своих
метрик для сетевых префиксов, содержащихся в маршрутных обновлениях,
полученных через этот интерфейс
Маршрутизатор использует ее в качестве метрики при объявлении сетевого префикса, соответствующего интерфейсу.
Маршрутизатор выполняет следующую трехступенчатую процедуру
для решения, должен ли он принять сетевой префикс, содержащийся в полученном маршрутном обновлении:
– Маршрутизатор сначала рассчитывает свою метрику для объявленного сетевого префикса, складывая метрику, содержащуюся в маршрутном обновлении, со стоимостью интерфейса, через который было получено обновление. Точная формула для расчета собственной метрики маршрутизатора зависит от протокола маршрутизации, но рассчитанное значение должно быть в
любом случае больше метрики, содержащейся в маршрутном обновлении.
– Если маршрутизатор не имеет маршрута для объявленного сетевого
префикса, он принимает этот префикс и создает для него новый маршрут.
Маршрутизатор использует IP адрес объявляющего маршрутизатора и интерфейс, через который было получено маршрутное обновление, в качестве значений полей следующего маршрутизатора и выходного интерфейса соответственно. Маршрутизатор также сохраняет вычисленную метрику в части
маршрута, специфичной для протокола маршрутизации.
– Если маршрутизатор имеет маршрут для объявленного сетевого префикса, и если маршрут был создан тем же дистанционно-векторным протоколом, маршрутизатор сравнивает рассчитанную метрику с метрикой, содержащейся в существующем маршруте. Если рассчитанная метрика меньше существующей, маршрутизатор отбрасывает имеющийся маршрут и создает новый
маршрут. Если же новая метрика больше или равна существующей, маршрутизатор просто отбрасывает полученное маршрутное обновление, не изменяя
таблицу маршрутизации.
После принятия объявленного сетевого префикса и создания соответствующей записи в таблице маршрутизации маршрутизатор сам начинает
объявлять об этом сетевом префиксе с рассчитанной метрикой. Он также объявляет о сетевых префиксах, присвоенных его интерфейсам, которые были
сконфигурированы для отправки и получения маршрутных обновлений.
В самом начале процесса, до того, как маршрутизатор получит какиелибо маршрутные обновления, он объявляет только о сетевых префиксах,
присвоенных его интерфейсам, которые были сконфигурированы для отправки и получения маршрутных обновлений. По мере обнаружения новых сетевых префиксов, обновления маршрутизации систематически передаются от
одного маршрутизатора другому.
68
На рисунке 4.2 показано, как дистанционно-векторные протоколы обрабатывают изменения топологии.
Обновление
таблицы
маршрутизации
R2
Обновление
таблицы
маршрутизации
R1 рассылает
обновленную
таблицу
маршрутизации
R1
Изменение
топологиисети
Рисунок 4.2 – Обработка изменений топологии сети
Когда маршрутизатор начинает получать маршрутные обновления от
других маршрутизаторов, он заполняет свою таблицу маршрутизации объявленными сетевыми префиксами, которые затем начинает объявлять сам. В
итоге все маршрутизаторы сегмента маршрутизации узнают обо всех сетевых
префиксах, доступных в сегменте.
Дистанционно-векторные алгоритмы требуют, чтобы каждый маршрутизатор рассылал копию своей таблицы маршрутизации соседним маршрутизаторам (neighbor router).
Маршрутизацию на основе дистанционно-векторного протокола иногда
называют «маршрутизацией по слухам» («routing by rumors»), поскольку
маршрутизаторы не знают ничего о маршрутизаторах на пути к известным им
сетевым префиксам.
Дистанционно векторные протоколы маршрутизации являются самыми
простыми алгоритмами динамической маршрутизации. Использование простых алгоритмов позволяет снизить вычислительную нагрузку на маршрутизаторы, однако использование таких алгоритмов маршрутизации имеет и свои
слабые стороны. Перед тем как администратор корпоративной сети передачи
данных сделает свой выбор в пользу одного из дистанционно-векторных протоколов маршрутизации, ему необходимо понять слабые стороны дистанционно векторной маршрутизации и пути решения возможных проблем.
4.2 Маршрутизация по замкнутому кругу
Явление маршрутизации по замкнутому кругу может возникать в тех
случаях, когда плохая сходимость сети для новой топологии сети может вызывать наличие противоречивых записей о маршрутах (Рисунок 4.3).
69
R2
R3
Сеть 1 недостижима
R1
R5

Альтернативный маршрут
:
Сеть 1, расстояние = 3
R4
Сеть 1
Альтернативный маршрут
:
Сеть 1, расстояние = 4
Рисунок 4.3 – Петли маршрутизации
1. Непосредственно перед выходом из строя «Сети 1» все маршрутизаторы имеют согласованные и корректные таблицы маршрутизации, т.е. для
данного домена маршрутизации произошла конвергенция. Предположим, что
для маршрутизатора R3 наилучший маршрут к «Сети 1» проходит через
маршрутизатор R2 и что в своей таблице маршрутизации маршрутизатор R3
имеет запись о расстоянии до «Сети 1», равном 3 переходам.
2. Если «Сеть 1» выходит из строя, то маршрутизатор R5 пересылает
маршрутизатору R1 обновление маршрутов, содержащее эту информацию.
После получения обновления маршрутизатор R1 прекращает направлять пакеты в «Сеть 1», однако маршрутизаторы R2, R3 и R4 продолжают это делать,
так как они еще не проинформированы о сбое в «Сети 1». После того как
маршрутизатор R1 отправляет свое обновление маршрутной информации,
маршрутизаторы R2 и R4 прекращают направлять пакеты в «Сеть 1». Однако
в этот момент маршрутизатор R3 еще не получил обновление маршрутной
информации. Для него по-прежнему «Сеть 1» считается доступной через
маршрутизатор R2.
3. Предположим, что маршрутизатор R3 не успел получить обновленную информацию о топологии сети от своих соседей, но по алгоритму работы
дистанционно-векторных протоколов маршрутизации настало время рассылки маршрутной информации своим соседям. Маршрутизатор R3 посылает
свою таблицу маршрутизации маршрутизатору R4, указывая, что он имеет
маршрут до «Сети 1» через маршрутизатор R2. Маршрутизатор R4 изменяет
свою таблицу маршрутизации, отражая эту хорошую, но не правильную информацию, и передает эти сведения дальше маршрутизатору R1. Маршрутизатор R1 распространяет ее маршрутизаторам R2 и R5. Теперь любой пакет,
имеющий назначением «Сеть 1», движется по кольцевому маршруту (петле)
от маршрутизатора R3 к маршрутизатору R2, далее к R1 и R4 и вновь к маршрутизатору R3.
70
4.3 Максимальное количество транзитных переходов
Продолжим рассмотрение примера, пакеты обновления с информацией
о «Сети 1» будут продолжать ходить по кругу до тех пор, пока какой-нибудь
другой процесс не сможет остановить это зацикливание. Подобное состояние,
называемое счетом до бесконечности (count to infinity), продолжает зацикливание перемещения пакетов по сети. Пока маршрутизаторы имеют возможность считать до бесконечности, некорректная информация позволяет существовать маршрутизации по кругу.
В отсутствие контрмер, которые могли бы остановить процесс, вектор
расстояния, исчисляемый количеством переходов, увеличивается на единицу
каждый раз, когда пакет проходит следующий маршрутизатор (Рисунок 4.4).
Эти пакеты ходят в сети по кругу, из-за неправильной информации в таблицах маршрутизации.
Сеть 1, расстояние
=7
R2
Сеть 1, расстояние
=6
R3
R1
R5

Сеть 1, расстояние
Сеть 1, расстояние
=5
=4
R4
Сеть 1
Рисунок 4.4 – Счет до бесконечности
Алгоритмы маршрутизации по вектору расстояния являются самокорректирующимися, но проблема маршрутизации по кругу, прежде всего, требует разрешения ситуации со счетом до бесконечности. Чтобы исключить эту
длительную по времени проблему, в протоколах, использующих вектор расстояния, бесконечность определяется как некоторое максимальное число. Это
число выражается в единицах метрики маршрутизации, например, в виде простого количества переходов.
При таком подходе протокол маршрутизации позволит существовать
маршрутизации по кругу до тех пор, пока метрика не превысит максимально
допустимое значение.
71
Сеть 1, расстояние
= 14
R2
Сеть 1, расстояние
= 13
R3
R1
R5

Сеть 1, расстояние
Сеть 1, расстояние
= 12
= 15
R4
Сеть 1
Таблица маршрутизации
max метрика = 16
Сеть 1 недостижима
Рисунок 4.5 – Назначение максимальной длины маршрута
На рисунке 4.5 показан случай, когда это максимальное значение равно
16; обычно для векторов расстояния, измеряемых в количестве переходов,
максимальное значение устанавливается равным 15 переходам. В любом случае, если значение метрики превысит максимум, то «Сеть 1» будет считаться
недостижимой.
4.4 Применения принципа расщепления горизонта
Другим возможным источником маршрутизации по кругу является ситуация, когда неправильная информация, посылаемая назад маршрутизатору,
противоречит информации, посылаемой им самим. Вот как возникает эта
проблема.
1. Маршрутизатор R1 передает маршрутизаторам R2 и R4 пакет с обновлением маршрутной информации, говорящий о том, что «Сеть 1» стала
недоступна.
2. Однако маршрутизатор R3 передает маршрутизатору R2 пакет обновления, который информирует, что «Сеть 1» доступна по маршруту с расстоянием 4 через маршрутизатор R4. Такое действие не нарушает правило расщепления горизонта, так как для маршрутизатора R3 «Сеть 1» находится за
двумя его интерфейсами и оба маршрута имеют одинаковую метрику равную
3.
2. Маршрутизатор R2 делает неправильный вывод о том, что маршрутизатор R3 имеет достоверный путь к «Сети 1», хотя и с менее предпочтитель-
72
ной метрикой. Маршрутизатор R2 посылает маршрутизатору R1 пакет обновления информации, в котором дает совет R1 о "новом" маршруте к «Сети 1».
3. Теперь маршрутизатор R1 определяет, что он может посылать пакеты
в «Сеть 1» через маршрутизатор R2; маршрутизатор R2 определяет, что он
может посылать пакеты через маршрутизатор R3, а маршрутизатор R3 определяет, что он может посылать пакеты в «Сеть 1» через маршрутизатор R4.
Любой пакет, помещенный в такую среду, будет ходить по кругу между
маршрутизаторами.
Одним из способов устранения маршрутизации по кругу и ускорения
сходимости сети является метод так называемого расщепления горизонта
(split horizon). Логика, стоящая за этим методом, заключается в том, что никогда нет ничего хорошего в посылке информации о маршруте назад в
направлении, из которого она первоначально пришла. Согласно этому методу, при поступлении сообщения об обновлении маршрутов для «Сети 1» от
маршрутизатора R1, маршрутизаторы R2 и R4 не могут посылать информацию о «Сети 1» в обратном направлении, т.е. маршрутизатору R1 (Рисунок
4.6).
Сеть 1 ...
R2
R3
Сеть 1 недостижима
R1
R5

R4
Сеть 1 ...
Сеть 1
Рисунок 4.6 – Расщепление горизонта
4.5 Обратное обновление
Обратное обновление (poison reverse) позволяет маршрутизаторам отменить правило расщепленного горизонта и распространять информацию, полученную с определенного интерфейса через тот же самый интерфейс. Однако
маршрутизатор может распространять сообщения о маршрутах через тот же
интерфейс, с которого они получены с использованием метрики означающей
недоступность сети, например, для протокола RIP метрика такого маршрута
должна равняться 16 (Рисунок 4.7).
73
Сеть 1, расстояние = 16
R2
Сеть 1 недостижима
R3
R1
R5

Сеть 1, расстояние = 16
R4
Сеть 1
Рисунок 4.7 – Обратное обновление
4.6 Таймеры удержания информации
Маршрутных петель можно избежать путем использования таймеров
удержания информации (hold-down timer) (Рисунок 4.8).
Внестиобновления
маршрутов после
срабатывания таймера
R2
R3
Внести обновления
маршрутов после
срабатывания таймера
R1
Внести обновления
маршрутов после
срабатывания таймера
Внести обновления
маршрутов после
срабатывания таймера
R4
R5

Сеть 1
Рисунок 4.8 – Таймеры удержания информации
Когда маршрутизатор получает от соседа пакет актуализации, свидетельствующий о том, что первоначально доступный маршрут теперь недоступен, он помечает этот маршрут как недоступный и запускает таймер удержания информации.
Если в какой-либо момент времени до истечения срока, устанавливаемого таймером удержания, от того же соседа приходит пакет актуализации,
информирующий о том, что сеть снова доступна, то маршрутизатор помечает
эту сеть как доступную и выключает таймер удержания.
74
Если от другого соседнего маршрутизатора приходит пакет актуализации с метрикой для этой сети, которая лучше первоначально записанной, то
маршрутизатор помечает сеть как доступную и сбрасывает таймер удержания. Если в какой-либо момент времени до истечения срока, устанавливаемого таймером удержания, от другого соседа приходит пакет актуализации с
худшей метрикой, то этот пакет актуализации игнорируется. Игнорирование
пакетов актуализации с худшей метрикой в период закрытия маршрута обеспечивает большее время на распространение сведений о разрушительном изменении по всей сети.
4.7 Механизм мгновенных обновлений
Новые копии таблиц маршрутизации обычно регулярно рассылаются
соседним маршрутизаторам. Протокол маршрутизации рассылает сообщения
обновлений каждые 30 секунд. Однако применение мгновенных обновлений
(triggered update) позволяет рассылать сообщения немедленно в ответ на какое-либо изменение в таблице маршрутизации. Маршрутизатор обнаруживший изменение в топологии, немедленно рассылает сообщение-обновление
смежным маршрутизаторам. Такие маршрутизаторы в свою очередь также генерируют мгновенные обновления, оповещая о переменах своих соседей. При
выходе какого-либо маршрута из строя сообщение об этом отправляется, не
дожидаясь истечения времени таймера обновления. Мгновенное сообщение
представляет собой анонс, который рассылается до истечения времени таймера обновления. Такой принцип работы приводит к рассылке обновленной информации о состоянии маршрута и сбрасывает таймеры на соседних маршрутизаторах. Эта волна обновлений распространяется по всей сети (Рисунок 4.9)
Сеть 1 недостижима
R2
R3
Сеть 1 недостижима
Сеть 1 недостижима
R1
R5

Сеть 1 недостижима
R4
Сеть 1
Рисунок 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 и осуществляют передачу через этот же порт. В сетях общего доступа, таких как Ethernet, эти широковещательные дейтаграммы получают все устройства широковещательного домена.
Протокол 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 необходимо включить в данный процесс маршрутизации
сети, о которых будет распространяться маршрутная информация. Для описания сетей участвующих в процессе маршрутизации используется команда network network–number (Рисунок 5.2).
192 .168 .1.0/24
R1
r1# router rip
network 192.168.1.0
172.16.1.0/24
R2
r2# router rip
network 172.16.0.0
network 192.168.1.0
10.1.1.0/24
R3
r3# router rip
network 10.0.0.0
network 172.16.0.0
R4
r4# router rip
network 10.0.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
3
4
5
Значение
Запрос на получение всей информации о маршрутах, посылаемый
маршрутизатором всем своим соседям во время инициализации или
после того как таблица маршрутизации была отчищена.
Сообщение, посылаемое маршрутизатором в ответ на запрос маршрутной информации, либо регулярно посылаемое (раз в 30 с.) периодическое сообщение маршрутной информации.
Включение режима трассировки (устаревшая).
Выключение режима трассировки (устаревшая).
Зарезервировано для внутреннего использования компанией Sun
Microsystems.
5.2.3 Версия – 1 байт
Поле версии указывает версию протокола RIP, 1 или 2. Маршрутизаторы поддерживающие протокол RIP, должны согласовывать применяемую
версию протокола. Если в сети существуют обе версии протокола, то из-за
того, что устройства версии 1 не поддерживают расширений, реализованных
в версии 2, могут возникнуть проблемы при их взаимодействии.
5.2.4 Неиспользуемые поля – 2 байта
Формат сообщения версии 1 включает несколько неиспользуемых полей. Эти поля всегда содержат нули и повторяются в зависимости от количества маршрутов передаваемых в сообщении.
5.2.5 Идентификатор семейства адресов – 2 байта
Хотя протокол RIP технически может поддерживать различные протоколы сетевого уровня, это поле содержит только значение 2, которое соответствует протоколу IP.
80
5.2.6 IP адрес – 4 байта
Поле IP адрес указывает адрес пункта назначение: сети, подсети или
маршрута по умолчанию, объявляемого маршрутизатором.
5.2.6 Метрика – 4 байта
Это значение представляет стоимость маршрута, выраженную числом
пересылок от маршрутизатора до сети получателя. Поле должно содержать
значения от 1 до 15, если поле содержит значение 16, то данная сеть считается недоступной.
5.3 Использование команды ip classless
R2# show ip route
...
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
10.0.0.0/24 is subnetted, 3 subnets,
R
10.1.1.0/24 [120/1] via 10.1.2.2, 00:00:05, Ethernet 0
C
10.1.2.0/24 is directly connected, Ethernet 0
R
10.1.3.0/24 [120/2] via 10.1.2.2, 00:00:05, Ethernet 0
R
192.168.24.0/24 [120/2] via 10.1.2.2, 00:00:16, Ethernet 0
R
172.16.0.0/16 [120/3] via 10.1.2.2, 00:00:16, Ethernet 0
R*
0.0.0.0/0 [120/2] via 10.1.2.2, 00:00:05, Ethernet 0
Рисунок 5.4 – Таблица маршрутизации протокола RIP v1
На рисунке 5.4 приводиться пример таблицы маршрутизации содержащей маршруты от классового протокола RIP v1.
По каким маршрутам будет отправлен трафик до хостов?
– 192.168.24.3;
– 172.16.5.1;
– 10.1.2.7;
– 200.100.50.1;
– 10.2.2.2.
Таблица маршрутизации содержит маршруты до подсетей, в которых находятся первые три хоста. Следовательно, пакеты до хостов в этих сетях будут
направлены по соответствующим маршрутам.
До четвертого хоста нет маршрута в таблице маршрутизации, однако
определен маршрут по умолчанию, по которому и будет отправлен трафик до
четвертого хоста.
Пятый хост принадлежит неизвестной подсети 10.2.2.0/24 сети 10.0.0.0/24
которая присутствует в таблице маршрутизации. По умолчанию, протоколы
классовой маршрутизации предполагают, что им известны маршруты до всех
подсетей. Поэтому трафик до 10.2.2.2 будет отвергнут.
81
Поведение классовых протоколов маршрутизации меняется при использовании команды ip classless. Данная команда заставляет классовый протокол
маршрутизации отправлять трафик, используя принцип наибольшего соответствия. Это также справедливо для неизвестных подсетей известных сетей.
Поэтому при использовании команды ip classless маршрутизатор отправит трафик до 10.2.2.2 по маршруту заданному по умолчанию.
В ОС Cisco IOS начиная с версии 11.3, данная команда включена по
умолчанию.
5.4 Недостатки протокола RIP v1
Протокол RIP v1 обладает рядом существенных недостатков, главными
из которых являются следующие:
– Является классовым протоколом маршрутизации, но не поддерживает
технологию VLSM;
– Отсутствие возможности производить суммирование маршрутов;
– Использует широковещательный механизм рассылки обновлений
маршрутной информации;
– В реализации протокола отсутствуют механизмы аутентификации соседних маршрутизаторов при передачи маршрутной информации.
Для устранения перечисленных недостатков была разработана следующая версия протокола RIP – RIP v2.
5.5 Протокол RIP v2
Протокол RIP v2 является бесклассовым дистанционно векторным протоколом маршрутизации, он описан в RFC 1721–1724 и 2453. Цель создания
второй версии протокола RIP была в том, чтобы расширить возможности протокола. Главным дополнением второй версии стала поддержка технологии
VLSM протоколом RIP. Основные отличия второй версии от первой являются:
– Бесклассовая маршрутизация;
– Поддержка технологии VLSM;
– Использование групповой рассылки маршрутной информации;
– Поддержка аутентификации соседних маршрутизаторов;
– Поддержка ручного суммирования маршрутов.
Протокол RIP v2 использует групповой адрес 224.0.0.9 для периодического обновления маршрутной информации с другими RIP v2 маршрутизаторами. Такой подход является более эффективным, потому что RIP v1 использовал широковещательный адрес сети, что приводило к необходимости всем
82
устройствам в широковещательном домене обрабатывать пакеты обновления
маршрутной информации.
5.5.1 Заголовок и поля протокола RIP v2
32 бита
8
8
Команда
Версия
8
8
Неиспользуемоеполе
(заполняетсянулями )
Запись маршрута
Идентификаторсемейства
адресов
Тег маршрута
IP Адрес
Маскаподсети
Следующая пересылка
Метрика
Поля (максимум 25)
Запись маршрута
Идентификаторсемейства
адресов
Тег маршрута
IP Адрес
Маскаподсети
Следующая пересылка
Метрика
Рисунок 5.5 – Формат сообщения протокола RIP v2
Заголовок RIP v2 в основном подобен заголовку RIP v1. Из рисунка 5.5
видно, что несколько неиспользованных ранее в заголовке RIP v1 полей теперь используются для поддержки технологии VLSM. Следует обратить особое внимание на появление полей маски подсети и следующей пересылки.
Оба этих поля являются ключевыми для обеспечения поддержки подсетей.
5.5.2 Тег маршрута – 2 байта
Данное поле является указателем на то, каким методом был получен
данный маршрут. Например, является ли маршрут внутренним маршрутом
протокола RIP, либо же он импортирован из какого либо другого динамического протокола маршрутизации или из статических записей маршрутов.
5.5.3 Маска подсети – 4 байта
Поле содержит маску подсети для IP адреса сети получателя. Наличие
данного поля позволяет использовать технологию VLSM. При использовании
данной технологии маршрутизатору необходимо точно указывать маску подсети для сетей маршруты, на которые он получает, иначе он не сможет правильно выделять сетевую часть IP адреса сетей получателей и не сможет
производить правильную маршрутизацию.
83
5.5.4 Следующая пересылка – 4 байта
Поле содержит IP адрес следующего маршрутизатора, которому должен
быть отправлен пакет для указанной сети получателя. Обычно указывается
значение равное 0.0.0.0, что позволяет маршрутизатору получившему информацию о сети получателе самому принимать решение о том по какому маршруту отправлять пакеты до сети получателя.
5.6 Аутентификация в протоколе RIP v2
В отличие от версии 1, которая не поддерживает аутентификацию, версия 2 позволяет использовать для аутентификации, как нешифрованные текстовые пароли, так и аутентификацию с использованием алгоритма хеширования MD5. Использование алгоритма MD5 с точки зрения защиты информации предпочтительнее, однако, в RFC 1723 описан только метод аутентификации при помощи нешифрованного пароля, что привело к тому, что не все
производители сетевого оборудования реализовали возможность использования MD5 в своей продукции.
Для каждой пары маршрутизаторов обменивающихся маршрутной информацией может быть настроен уникальный пароль. На рисунке 5.6 приводится формат пакета обновления маршрутной информации с использованием
аутентификации.
32 бита
8
8
Команда
Версия
8
8
Неиспользуемое поле
(заполняется нулями )
Аутентификация
0xFFFF
Тип аутентификации
Пароль (байты 0-3)
Пароль (байты 4-7)
Пароль (байты 8-11)
Пароль (байты 12-15)
Запись маршрута
Идентификаторсемейства
адресов
Тег маршрута
IP Адрес
Маска подсети
Следующая пересылка
Метрика
Поля (максимум 24)
Рисунок 5.6 – Формат сообщения с аутентификацией протокола RIP v2
84
5.6.1 Настройка аутентификации для протокола RIP
Аутентификация настраивается на каждом выходном интерфейсе маршрутизатора, за которым находятся соседние маршрутизаторы. Для настройки
аутентификации используются следующие команды. Команда ip rip authentication 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 authentication 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
R1
S0
r1#
interface serial 0
ip address 172.16.1.1 255 .255.255.252
ip rip authentication key -chain trees
ip rip authentication mode md 5
!
router rip
network 172.16.0.0
version 2
!
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 1996 duration 7200
send-lifetime 15:00:00 Jan 25 1996 duration 3600
S1
R2
r2#
interface serial 1
ip address 172.16.1.2 255.255.255.252
ip rip authentication key-chain trees
ip rip authentication mode md5
!
router rip
network 172.16.0.0
version 2
!
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 1996 duration 7200
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 адрес суммарного маршрута.
Маска подсети суммарного маршрута.
ip-address
ip-network-mask
Пример настройки суммарных маршрутов в протоколе RIP приводится
на рисунке 5.8
172 .16.14.0/27
172 .16.14.32/27
172 .16.14.64/27
R2
17
2.
16
.1
4.
22
4/
30
172 .16.12.0/24
S0
172 .16.14.228 /30
R3
30
2/
23
4.
1
6.
2.1
17
R4
R1
Центральный офис
172.16.0.0/16
172 .16.13.0/24
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. Синтаксис команды default-information originate приводится в примере 5.5
Пример 5.5 – Синтаксис команды default-information originate
(config-router)# default-information originate [route-map map-name]
(config-router)# no default-information originate
Описание параметров команды default-information originate приводиться
в таблице 5.5.
Таблица 5.5 – Параметры команды default-information originate
Параметр
route-map map-name
Описание
Указание процессу маршрутизации
распространять маршрут по умолчанию в том случае если выполняется
условие route-map.
Пример настройки маршрута по умолчанию в протоколе RIP приводится на рисунке 5.9
172 .16.14.0/27
172 .16.14.32/27
172 .16.14.64/27
R2
17
2.
16
.1
4.
22
4/
30
172 .16.12.0/24
S0
172 .16.14.228 /30
R3
0
/3
32
.2
14
.
16
2.
17
R4
R1
Центральный офис
172.16.0.0/16
172 .16.13.0/24
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
R1
с
30
30
с
R3
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
invalid
holddown
Описание
Промежуток времени, через который
осуществляется рассылка обновлений
маршрутной информации. Данный интервал является базовым, относительно него устанавливаются остальные
таймеры. По умолчанию длительность
интервала 30 секунд.
Время в секундах, после которого
маршрут помечается как недоступный.
Это время не должно быть меньше
трех интервалов обновления. Маршрут
становится недопустимым, если он не
присутствует в трех обновлениях
маршрутной информации, маршрут
помечается как holddown и в обновлениях маршрутной информации он отмечается как недоступный. Но он все
еще участвует в отправке трафика. По
умолчанию 180 секунд.
Время в секундах, в течение которого
маршрут помечается как «возможно не
доступный». Это время должно быть не
менее трех интервалов обновления
маршрутной информации. Маршрут помечается «возможно недоступным»
если маршрутизатор получает обновление в котором указывается на недоступность этого маршрута. Такой маршрут
помечается как недоступный, но этот
маршрут все еще используется для отправки трафика.
90
Продолжение таблицы 5.6
Параметр
holddown
flush
Описание
После истечения времени интервала
«возможно не доступен» маршрутизатор, если это возможно использует альтернативный маршрут до получателя,
но если такого не имеется, помечает адресата как недоступного и вычеркивает
маршрут из таблицы маршрутизации.
По умолчанию 180 секунд.
Время в течении которого маршрут не
удаляется из таблицы маршрутизации.
Это время должно быть больше чем Invalid, если оно меньше не может начаться отсчет интервала 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)#
(config-if)#
(config-if)#
(config-if)#
ip
no
ip
no
rip receive version [1] [2]
ip rip receive version
rip send version [1] [2]
ip rip send version
Пример совместной работы маршрутизаторов с разными версиями протокола RIP приводится на рисунке 5.11.
S1 10.1.1.0/24
R1
r1# router rip
version 2
network 10.0.0.0
!
interface serial 1
ip rip send version 1
ip rip receive version 1
S0
R2
r2# router rip
version 1
network 10.0.0.0
Рисунок 5.11 – Использование протокола RIP различных версий
5.8.3 Распределение нагрузки в протоколе RIP
Под распределением нагрузки понимается использование механизма,
который позволяет маршрутизатору воспользоваться наличием нескольких
маршрутов к сети получателю.
Протокол RIP способен осуществлять распределение нагрузки по
нескольким маршрутам с равной стоимостью, число которых не должно превышать 16. На рисунке 5.12 приведен пример распределения нагрузки по
четырем маршрутам с равной метрикой.
56k
64k
R1
1,544
M
R2
15
5M
Рисунок 5.12 – Распределение нагрузки в протоколе RIP
92
Поскольку метрикой протокола RIP является количество переходов и
скорость каналов при этом не учитывается. Поэтому канал со скоростью 56Кбит/с будет обрабатывать, столько же данных что и канал со скоростью
155Мбит/с.
Маршруты с равной стоимостью обычно можно найти с помощью команды show ip route до конкретной сети. В примере 5.9 приводится информация, которая выдает команда show ip route для конкретной сети.
Пример 5.9 – Вывод маршрутов с равной стоимостью
r1# show ip route 10.1.2.0
Routing entry for 10.1.2.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 10.1.4.2 on FastEthernet0/0, 00:00:18 ago
Routing Descriptor Blocks:
10.1.4.1, from 10.1.4.1, 00:02:45 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
* 10.1.4.2, from 10.1.4.2, 00:00:18 ago, via FastEthernet0/0
Route metric is 1, traffic share count is 1
В приведенном выше примере имеются два описательных блока. Каждый из них описывает один маршрут. Перед началом одного из блоков сто
символ «*», указывающий, что блок соответствует активному маршруту, который используется для новых потоков данных.
5.8.4 Настройка протокола RIP для работы в сетях NBMA
Известно, что протокол RIP, как и большинство протоколов динамической маршрутизации использует механизм широковещательной рассылки.
Однако существуют технологии построения сетей, поддерживающие множественный доступ, но в которых не применяются широковещательные пакеты.
К таким технологиям относятся сети Frame Relay, ATM и X25. Данные сети
получили название NBMA (non broadcast multi access) не широковещательные
сети группового доступа.
В сетях NBMA может быть больше двух маршрутизаторов, но из–за отсутствия возможности использования широковещательных пакетов в таких
сетях могут возникать проблемы установления соседских отношений. В сети
NBMA групповой пакет, посланный одним маршрутизатором, не может быть
получен всеми остальными маршрутизаторами в сети. В сетях такого типа
протоколу RIP необходимо предоставить информацию о соседних маршрутизаторах. Для указания соседнего маршрутизатора, с которым требуется обмениваться информацией, используется команда neighbor, синтаксис команды
приводится в примере 5.10.
93
Пример 5.10 – Синтаксис команды neighbor
(config-router)# neighbor ip-address
(config-router)# no neighbor ip-address
5.8.5 Механизм инициированных обновлений в протоколе RIP
Модификации протокола RIP позволяют использовать инициированные
обновления маршрутной информации. В RFC 2091 регламентируется использование инициированных обновлений маршрутной информации. Инициация
означает, что послать сообщение о корректировке маршрутизатор побуждает
какое-либо событие в сети или запрос соседнего маршрутизатора, а не
таймер.
Ниже перечислены события, которые инициируют посылку сообщений
о корректировках:
– Маршрутизатор запрашивает обновленную информацию о маршрутах
при инициализации. Происходит обмен полными копиями таблиц маршрутизации.
– В сети имеют место изменения. Посылается информация только об
изменениях в сети.
– Переход состояния канала из включенного в выключенное или наоборот.
Инициированные обновления маршрутной информации должны использовать три дополнительных типа пакетов RIP, а также расширенный заголовок сообщения длиной в 4 байта. Обе версии, RIP v1 и RIP v2, поддерживают все три типа пакетов и расширенный 4 байтный заголовок.
UpdateRequest
(9)
UpdateResponse
32 бита
8
8
Версия
8
Неиспользуемое поле
(заполняется нулями
8
8
Версия
)
8
(11)
32 бита
8
Версия
Flush
8
SequenceNumber
8
Запись маршрута
UpdateAcknowledge
8
Flush
Идентификатор семейства
адресов
8
(10)
32 бита
8
Sequence Number
Ноль (RIPv 1)
Тег маршрута (RIPv 2)
Записи RIP
Записи RIP
Записи RIP
Записи RIP
Поля (максимум 25)
Рисунок 5.13 – Дополнительные типы пакетов протокола RIP
На рисунке 5.13 показан формат трех дополнительных типов пакетов
RIP, которые используются в инициированных обновлениях маршрутной информации. В таблице 5.7 приведено описание пакетов.
94
Таблица 5.7 – Дополнительные пакеты протокола RIP
Команда
9
10
11
Значение
Запрос. Посылается маршрутизатором для запроса информации о
корректировках маршрутной информации.
Ответ. Посылается в ответ за запрос и включает любо полную копию таблицы маршрутизации, либо измененные маршруты в зависимости от содержания запроса.
Подтверждение. Посылается для подтверждения приема обновления маршрутной информации.
Всем ответам (10) назначаются номера пакетов в последовательности.
Каждый ответ увеличивает номер очередного пакета на единицу. Маршрутизатор, запросивший информацию, при получении этих ответом должен подтвердить получение информации о маршрутах, переданной внутри дейтаграммы, путем посылки подтверждения с соответствующим номером пакета в последовательности. Маршрутизатор, отвечающий на запрос, предполагает, что
неподтвержденные дейтаграммы утеряны и должны быть переданы повторно.
К сожалению, механизм инициированных обновлений маршрутной информации поддерживается только на последовательных каналах связи, т.к.
RFC 2091 разрабатывался в первую очередь для реализации динамической
маршрутизации по модемным соединениям. Данный механизм не поддерживается на других типах интерфейсов маршрутизаторов.
5.9 Тестирование и устранение ошибок в работе протокола RIP
Для проверки правильности созданной конфигурации протокола RIP
могут быть использованы несколько команд. Двумя наиболее часто используемыми командами являются show ip route и show ip protocols.
При вводе команды show ip protocols отображается информация обо
всех протоколах IP маршрутизации, сконфигурированных на маршрутизаторе
(Пример 5.11).
Пример 5.11 – Информация, выводимая командой show ip protocols
r4#show ip protocols
Routing Protocol is "rip"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
95
Default version control: send version 2, receive version 2
Interface
Send Recv Triggered RIP Key-chain
FastEthernet0/0
2
2
AUTH
Serial0/0/0
2
2
AUTH
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
Passive Interface(s):
FastEthernet0/1
FastEthernet0/1.811
Loopback0
Routing Information Sources:
Gateway
Distance
Last Update
10.93.1.1
120
00:00:02
10.93.1.34
120
00:00:11
Distance: (default is 120)
Такие сведения могут быть использованы для тестирования
большинства параметров протокола RIP. Ниже перечислены островные тестируемые параметры конфигурации.
– Включен ли на требуемых интерфейсах протокол RIP.
– Какие интерфейсы принимают и отправляют обновления маршрутной
информации.
– Правильная ли версия обновлений маршрутной информации используется.
– Анонсирует ли маршрутизатор требуемые сети.
– Включен ли механизм аутентификации сторон.
Команда show ip route или команда show ip route rip отображает таблицу
маршрутизации построенную маршрутизатором. Вторая команда отображает
только маршруты из таблицы маршрутизации полученные протоколом RIP,
такие маршруты помечаются буквой «R» (Пример 5.12).
Пример 5.12 – Таблица маршрутизации полученная от протокола RIP
r2#show ip route rip
.. .. ..
Gateway of last resort is 172.16.0.1 to network 0.0.0.0
172.16.0.0/28 is subnetted, 1 subnets
R
172.16.0.16 [120/1] via 172.16.0.1, 00:01:11, Serial0/0/0
10.0.0.0/8 is variably subnetted, 11 subnets, 3 masks
R
10.89.2.64/26 [120/3] via 172.16.0.1, 00:01:11, Serial0/0/0
R
10.89.1.64/26 [120/1] via 10.93.1.18, 00:01:11, Serial0/1/0
R
10.95.2.7/32 [120/3] via 172.16.0.1, 00:01:11, Serial0/0/0
R
10.95.2.6/32 [120/3] via 172.16.0.1, 00:01:12, Serial0/0/0
R
10.89.2.0/26 [120/3] via 172.16.0.1, 00:01:12, Serial0/0/0
R
10.89.1.0/26 [120/1] via 10.93.1.2, 00:01:12, Serial0/0/1
R
10.89.0.0/28 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0
R
10.95.2.3/32 [120/2] via 172.16.0.1, 00:01:13, Serial0/0/0
R
10.95.0.1/32 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0
R
10.93.2.0/26 [120/2] via 172.16.0.1, 00:01:13, Serial0/0/0
R
10.93.1.32/28 [120/1] via 10.93.1.18, 00:01:13, Serial0/1/0
[120/1] via 10.93.1.2, 00:01:13, Serial0/0/1
R*
0.0.0.0/0 [120/1] via 172.16.0.1, 00:01:13, Serial0/0/0
96
Большинство ошибок в настройке протокола RIP связано с некорректным выполнением команд network, с разрывами в сетях или с аутентификацией сторон. Первичным инструментом для обнаружения перечисленных ошибок является команда debug ip rip.
При выполнении команды debug ip rip отображаются обновления маршрутной информации протокола RIP по мере их отправки и получения (Пример
5.13).
Пример 5.13 – Информация об обмене маршрутной информацией
r4#debug ip rip
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
ernet0/0
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
*Feb 15 20:19:46.007
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
*Feb 15 20:19:46.011
ernet0/0
*Feb 15 20:19:46.011
*Feb 15 20:19:46.243
net0/0 (10.93.1.33)
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
*Feb 15 20:19:46.243
KRSK: RIP: received packet with MD5 authentication
KRSK: RIP: received v2 update from 10.93.1.34 on FastEthKRSK:
10.89.0.0/28 via 0.0.0.0 in 3 hops
KRSK:
10.89.1.64/28 via 0.0.0.0 in 1 hops
KRSK:
10.89.2.0/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.16/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.32/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.48/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.64/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.80/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.96/28 via 0.0.0.0 in 5 hops
KRSK:
10.89.2.112/28 via 0.0.0.0 in 5 hops
KRSK:
172.16.0.0/28 via 0.0.0.0 in 2 hops
KRSK: RIP: received packet with MD5 authentication
KRSK: RIP: received v2 update from 10.93.1.34 on FastEthKRSK:
172.16.0.16/28 via 0.0.0.0 in 3 hops
KRSK: RIP: sending v2 update to 224.0.0.9 via FastEtherKRSK: RIP: build update entries
KRSK:
10.89.0.0/28 via 0.0.0.0, metric 3, tag 0
KRSK:
10.89.1.0/28 via 0.0.0.0, metric 1, tag 0
KRSK:
10.89.1.16/28 via 0.0.0.0, metric 1, tag 0
KRSK:
10.89.1.32/28 via 0.0.0.0, metric 1, tag 0
KRSK:
10.89.1.48/28 via 0.0.0.0, metric 1, tag 0
KRSK:
10.89.2.0/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.16/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.32/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.48/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.64/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.80/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.96/28 via 0.0.0.0, metric 5, tag 0
KRSK:
10.89.2.112/28 via 0.0.0.0, metric 5, tag 0
KRSK:
172.16.0.0/28 via 0.0.0.0, metric 2, tag 0
Перечисленные выше команды предоставляют информацию, которая
может оказаться полезной при проверке конфигурации маршрутизатора.
97
6 Протокол EIGRP
Протокол EIGRP (Enhanced Interior Getaway Routing Protocol) – расширенный протокол маршрутизации внутреннего шлюза является расширенной
версией протокола IGRP. Он является фирменным протоколом корпорации
Cisco представленным в 1994 году, однако в настоящее время ряд сторонних
производителей лицензировал EIGRP для реализации в своем телекоммуникационном оборудовании.
Протокол EIGRP берет свое начало от дистанционно–векторной маршрутизации. Как и его предшественник, протокол IGRP, EIGRP прост в настройке и нашел применение в большом спектре сетевых топологий.
По способу представления маршрутной информации протокол EIGRP
все же является дистанционно-векторным протоколом. Сети получатели в
маршрутных обновлениях сопровождаются метриками и адресами «следующих» маршрутизаторов. Подобно другим дистанционно-векторным протоколам, протокол EIGRP не обладает полными знаниями о топологии сети передачи данных.
Однако в основе протокола EIGRP лежит не алгоритм Беллмана-Форда,
а алгоритм DUAL (Diffusing Update Algorithm), алгоритм диффузионного обновления. Сам алгоритм ведет свое начало от работы Эдсгера Дейкстры и К.
С. Шольтена (Edsger Dijkstra, C. S. Sholten) «Termination Detection for Diffusing Computations» изданной в 1980 году.
Алгоритм DUAL подкреплен многими математическими работами,
основной из которых является «Loop-Free Routing Using Diffusing Computations», написанная Х. Х. Гарсия-Луна-Асевесом (J. J. Garcia-Luna-Aceves).
6.1 Алгоритм диффузионного обновления
Алгоритм DUAL лежит в основе протокола EIGRP. Поэтому рассмотрим его первым. Начнем с классического алгоритма DUAL. А затем рассмотрим необходимые изменения для адаптации алгоритма для протокола маршрутизации EIGRP.
Протоколы маршрутизации на основе дистанционно-векторного алгоритма Беллмана-Форда, имеют две фундаментальные проблемы:
– Маршрутные петли;
– Счет до бесконечности.
Обе эти проблемы обусловлены тем, что маршрутизаторы ничего не
знают о действительной топологии сети передачи данных. Все что они знают,
это какие сети получатели доступны через каждого из соседей. Когда в сети
происходят изменения, маршрутизаторы пытаются переключать маршруты на
основании новых метрик, которые им становятся известны.
98
До достижения сходимости сети, метрики могут неточно отражать действительную стоимость маршрутов, что может привести к маршрутным
петлям.
Основным методом борьбы с возникновением маршрутных петель является введение метрики равной бесконечности, при достижении которой
маршрут считается недоступным. Обычно маршрутизаторам необходимо выполнить некоторое число итераций, перед тем как установить метрику в бесконечность, следовательно, время сходимости сети с использованием дистанционно-векторных алгоритмов значительно увеличивается. Чтобы ускорить
схождение сети, приходиться применять дополнительные методы: правило
расщепления горизонта, метод обратного обновления, мгновенные обновления и таймеры удержания информации.
Вспомним, какую информацию маршрутизаторы получают друг от друга и как они ее используют. Маршрутизаторы в случае использования алгоритма Беллмана-Форда, обмениваются маршрутными обновлениями, содержащими известные им сети получатели. Каждая сеть получатель, сопровождается метрикой, отражающей, насколько далеко маршрутизатор, отправляющий это маршрутное обновление, по его мнению, находиться от данной
сети.
Маршрутизатор, получающий маршрутное обновление, использует метрику из этого обновления для расчета своей собственной метрики. В
большинстве случаев новая метрика включает в себя стоимость интерфейса,
через который было получено маршрутное обновление. Если полученная метрика является наименьшей для данной сети получателя, маршрутизатор создает маршрут к этой сети. Маршрут указывает на маршрутизатор, который
отправил маршрутное обновление, и содержит только что рассчитанную метрику. Эта метрика затем используется маршрутизатором в своих собственных
маршрутных обновлениях об этой сети получателе.
В такой ситуации маршрутизатор, получающий маршрутное обновление, отбрасывает фрагмент очень важной информации – метрику маршрута
которую он получил от своего соседа. Маршрутизатор использует ее для расчета своей метрики, а затем эта метрика забывается.
Возникает вопрос: что такого ценного в заявленном расстоянии? На рисунке 6.1 изображена топология сети, с маршрутизатором R1 в центре. У
маршрутизатора R1 имеется маршрут к некоторой сети получателю (СП) через маршрутизатор R2.
99
СП
0
10
R2
5
5
10
40
R1
10
0
30
R5
105
100
0
14
R3
5
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
40
R1
200
100
30
R5
R3
5
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
40
R1
200
10
0
100
0
14
30
R5
R3
5
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
40
R1
110
10
0
10
0
14
30
R5
R3
5
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 (protocol 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 Таблица соседства
Чтобы начать обмен маршрутной информацией, маршрутизаторы EIGRP, находящиеся в одном и том же сегменте в пределах одного домена
маршрутизации, должны сформировать соседские взаимоотношения. Маршрутизаторы становятся соседями после того, как они обменяются приветственными пакетами. Когда маршрутизатор EIGRP находится в процессе первоначальной загрузки, он должен распознать все соседние EIGRP маршрутизаторы и установить с ними соседские взаимоотношения. Этот процесс называется процессом обнаружения соседей. Каждый маршрутизатор в результате
обмена приветственными сообщениями создает локальную таблицу соседей,
отслеживая всех соседей и их состояние. Если маршрутизатор не получает
приветственного сообщения от соседнего маршрутизатора в течение нескольких временных интервалов, то он считает его неработоспособным и удаляет
из своей таблицы. В примере 6.1 приводится таблица соседства маршрутизатора EIGRP.
105
Пример 6.1 – Таблица соседства маршрутизатора EIGRP
IP–EIGRP neighbors for process 200
H
Address
Interface
Holdtime
(sec)
2
10.93.1.18
Serial2
13
1
10.93.1.2
Serial1
10
0
10.93.0.1
Serial0
12
Uptime
(h:m:s)
00:06:38
00:08:53
00:18:24
Q
Count
0
0
0
Seq
Num
8
7
11
SRTT
(ms)
7
9
164
RTO
(ms)
282
282
984
Ниже описаны поля, содержащиеся в таблице соседства:
– Номер соседнего маршрутизатора (H). Порядковый номер соседнего
маршрутизатора.
– Адрес соседнего маршрутизатора (Address). Адрес сетевого уровня
соседнего маршрутизатора.
– Время удержания (Holdtime). Интервал времени, по истечении которого, в случае отсутствия сообщений от соседнего маршрутизатора, сосед
рассматривается как неработоспособный. По умолчанию интервал равен 15
секундам. Первоначально в качестве ожидаемых пакетов рассматривались
только пакеты приветствия, однако, в текущих версиях IOS любой пакет протокола EIGRP сбрасывает таймер на нулевое значение.
– Время существования соседских отношений (Uptime). Временной интервал, прошедший с момента установки соседских отношений с данным
маршрутизатором.
– Счетчик очереди (Q Count). Число пакетов, которые находятся в очереди и ожидают передачи. Если это значение постоянно больше нуля, то,
маршрутизатор испытывает переполнение. Значение 0 означает, что пакетов
EIGRP в очереди нет.
– Последовательный номер (Seq Num). Номер последнего пакета, полученного от данного соседнего маршрутизатора. Протокол EIGRP использует
это поле для подтверждения приема пакета, переданного соседним маршрутизатором и для идентификации пакетов, которые переданы с нарушением порядка.
– Таймер цикла обмена сообщениями (SRTT). Среднее время, которое
требуется для того, чтобы отправить пакет соседнему маршрутизатору и получить от него ответный пакет. Этот таймер определяет интервал повторной
передачи пакета.
– Таймер повторной передачи (RTO). Время, которое маршрутизатор
ожидает прихода ответного сообщения от соседа после посылки ему пакета.
После истечения таймера происходит повторная отправка неподтвержденного
пакета.
106
6.4.2 Таблица топологии
Все маршрутизаторы EIGRP должны создавать и поддерживать в актуальном состоянии таблицу топологии. Эта таблица представляет собой карту
всей автономной системы, в которой указаны все сети, подсети и метрики
маршрутов ко всем получателям. Процесс создания и поддержки таблицы топологии является результатом обмена маршрутной информацией. Обмен
маршрутной информацией начинается после завершения установки соседских
отношений между смежными маршрутизаторами в домене EIGRP. Маршрутизатор EIGRP во время инициализации получают полные копии таблиц топологии своих соседей и на их основе создают свою таблицу топологии домена маршрутизации. С этой целью маршрутизаторы EIGRP используют, запросы о сетях получателях, ответы на эти запросы и обновления маршрутной информации. Маршрутизаторы EIGRP используют данные из таблицы топологии для создания и поддержания в актуальном состоянии таблицы маршрутизации, с помощью алгоритма DUAL вычисляя маршруты до сетей получателей. В примере 6.2 приводится таблица топологии маршрутизатора EIGRP.
Пример 6.2 – Таблица топологии маршрутизатора EIGRP
IP–EIGRP Topology Table for AS(200)/ID(10.95.0.2)
Codes: P – Passive, A – Active, U – Update, Q – Query, R – Reply,
r – reply Status, s – sia Status
P 10.93.2.16/28, 1 successors, FD is 6535936
via 10.93.0.1 (6535936/6023936), Serial0
P 10.93.1.16/28, 1 successors, FD is 5511936
via Connected, Serial2
P 10.93.1.0/28, 1 successors, FD is 5511936
via Connected, Serial1
P 10.93.0.0/28, 1 successors, FD is 5511936
via Connected, Serial0
P 10.93.2.32/28, 1 successors, FD is 6538496
via 10.93.0.1 (6538496/6026496), Serial0
P 10.93.1.32/28, 2 successors, FD is 5514496
via 10.93.1.18 (5514496/28160), Serial2
via 10.93.1.2 (5514496/28160), Serial1
Вывод, приведенный в примере 6.2 представляет собой таблицу топологии, созданную в результате обмена обновлениями маршрутной информации
по протоколу EIGRP. В примере имеются записи о шести известных маршрутизатору подсетях. Ниже описаны поля, содержащиеся в таблице топологии:
– Статус маршрута. Различают два основных состояния. Пассивные
маршруты (passive P), под которыми понимаются устойчивые и готовые к использованию маршруты, и активные (active A), в отношении которых алгоритм DUAL не закончил процесс расчета маршрута.
107
– Число преемников (successors). Число маршрутов с равной стоимостью до сети получателя, или другими словами число маршрутизаторов которым могут быть переданы далее пакеты при маршрутизации.
– Источник маршрута (via). Адрес маршрутизатора анонсировавшего
маршрут. Если маршрут анонсирован несколькими маршрутизаторами, то
первые n строк являются маршрутизаторами преемниками (n число преемников) а остальные маршруты выступают либо вероятными преемниками, либо
просто резервными маршрутами. Строчка connected означает, что сеть является непосредственно подключенной к маршрутизаторы.
– Выполнимое/Заявленное расстояние (Feasible/Advertised distance). Выполнимое расстояние это полная метрика маршрута равная заявленному расстоянию от соседнего маршрутизатора до сети адресата плюс метрика маршрута до заявившего его соседнего маршрутизатора. Заявленное расстояние
это метрика маршрута от соседа до сети получателя.
– Выходной интерфейс. Интерфейс маршрутизатора, через который доступна сеть получатель.
В описании полей таблицы топологии приводилось четыре важнейших
определения для протокола EIGRP, эти определения необходимо повторить:
– Преемник (successor) – это первичный маршрут, который используется для достижения получателя. Преемники передаются в таблицу маршрутизации.
– Вероятный преемник (feasible successor) – это сосед, который находится на пути к получателю. Его нельзя назвать оптимальным, поэтому он не
используется для пересылки данных, это резервный маршрут к получателю.
Эти маршруты определяются одновременно с преемниками и сохраняются в
таблице топологии. Таблица топологии может хранить множество вероятных
преемников.
– Заявленное расстояние (Advertised distance). Метрика маршрута,
полученная от соседа заявившего его до сети адресата.
– Выполнимое расстояние (Feasible distance). Заявленное расстояние
от соседа до сети адресата плюс метрика маршрута до соседа.
Заявленное и выполнимое расстояние до сети 10.0.2.0/24 приводится на
рисунке 6.5.
AD
1
R1
2
R2
10.1.2.0/24
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) для расчета метрики EIGRP имеет вид (6.2):
Metric = BW + Delay
(6.2)
Весовые коэффициенты передаются в Hello пакетах. Несоответствие весовых коэффициентов не позволит установить соседские отношения между
маршрутизаторами. Весовые коэффициенты могут модифицироваться только
после тщательного планирования, изменение этих значений может препятствовать сходимости сети. Для определения значений, требуемых при вычислении метрики, протокол EIGRP использует формулы (6.3) и (6.4).
BW = (107 / bw) * 256
где
bw – полоса пропускания канала связи заданная на интерфейсе.
D = (d / 10) * 256
где
(6.3)
(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
Обмен
модифицированными
Hello пакетами
Таблица соседства
Установка двунаправленных соседских отношений
R1
Hello
D:224 .0.0.10
S:10.0.0.1
AS:200
K:1,0,1,0,0
R2
Hello
D:224 .0.0.10
S:10.0.0.2
AS:200
K:1,0,1,0,0
Update
Update
D:10.0.0.2
S:10.0.0.1
Sq:1
A:0
D:10.0.0.1
S:10.0.0.2
Sq:1
A:1
ACK
D:10.0.0.2
S:10.0.0.1
Sq:0
A:1
Hello
D:224 .0.0.10
S:10.0.0.1
AS:200
K:1,0,1,0,0
N-IP:10.0.0.2
Таблицасоседства
Hello
D:224 .0.0.10
S:10.0.0.1
AS:200
K:1,0,1,0,0
N-IP:10.0.0.1
Update
Таблица топологии
Таблица
маршрутизации
Обмен таблицами топологии
ACK
D:10.0.0.2
S:10.0.0.1
Sq:2
A:0
ROUTES ...
D:10.0.0.1
S:10.0.0.2
Sq:0
A:2
Таблицатопологии
Update
ACK
D:10.0.0.2
S:10.0.0.1
Sq:0
A:2
D:10.0.0.1
S:10.0.0.2
Sq:2
A:0
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 Запланированное отключение
R1
G
oo
by
e
Для ускорения сходимости сети при штатных отключениях маршрутизаторов, например, при перезагрузке или перезапуске процесса маршрутизации в ОС IOS начиная с версий 12.3(2) была добавлена возможность рассылки сообщений Goodbye (Рисунок 6.7).
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)
10.95.1.5 (FastEthernet0/1) is down: Interface Goodbye received
1:
Neighbor
Если маршрутизатор не поддерживает Goodbye пакеты, то при получении такого пакета он выведет сообщение представленное в примере 6.4.
Пример 6.4 – Обработка Goodbye пакета маршрутизатором со старым
IOS
*Feb 16 19:07:01.191 KRSK: %DUAL-5-NBRCHANGE: IP-EIGRP(0)
10.95.1.5 (FastEthernet0/1) is down: K-value mismatch
1:
Neighbor
Как видно соседские отношения все равно будут разорваны, так как в
пакете содержатся отличные от настроенных на маршрутизаторе значения весовых коэффициентов.
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
1000
R4
1500
Сеть
FD
AD
10.1.1.0/24 2000
ViaR 2
2000 1000
ViaR 4
3000 1500
R3
Topology
S
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
R3
1500
Сеть
FD
AD
10.1.1.0/24 3000
Via R 2
2000 1000
Via R 4
3000 1500
Topology
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
1
1
R2
2
Сеть
10.1.1.0/24
Via R 2
Via R 4
Via R 5
FD
3
3
4
4
R4
2
S
FS
1
R3
FD AD Topology
2
2
1
S
5 3
5
4
Сеть
10.1.1.0/24
Via R 4
Via R 3
FD AD Topology
3
3 2
S
4 3
1
AD Topology
1
2
3
Сеть
10.1.1.0/24
Via R 2
Via R 3
Via R 5
R5
Рисунок 6.10 – Сегмент сети без вероятного преемника
Что будет происходить в сети, если маршрутизатор R4 обнаружит недоступность маршрутизатора R2 (Рисунок 6.11).
119
10.1.1.0/24
R1
1
1
R2
2
Сеть
10.1.1.0/24
Via R 2
Via R 4
Via R 5
FD
3
3
4
4
2

R4
S
FS
1
R3
FD AD Topology
2
2
1
S
5 3
5
4
Сеть
10.1.1.0/24
Via R 4
Via R 3
FD AD Topology
3
3 2
S
4 3
1
AD Topology
1
2
3
Сеть
10.1.1.0/24
Via R 2
Via R 3
Via R 5
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
1
R2
2
R4
2
1
Сеть
10.1.1.0/24
Via R 3
Via R 5
FD AD
-1
5 3
5 4
Topology
**ACTIVE **
(Q)
( Q)
Сеть
10.1.1.0/24
Via R 4
Via R 3
FD AD Topology
3
3 2
S
4 3
Q
Q
Сеть
10.1.1.0/24
Via R 2
Via R 4
Via R 5
FD
3
3
4
4
AD Topology
1
2
3
S
FS
1
R3
R5
Рисунок 6.12 – Маршрутизатор R4 рассылает запросы соседям
Однако у маршрутизатора R3 в таблице присутствует маршрут до этой
сети через маршрутизатор R2, причем маршрутизатор R2 назначен преемником. Следовательно, маршрутизатор R3 может ответить маршрутизатору R4
на запрос о маршруте до сети 10.1.1.0/24.
10.1.1.0/24
R1
1
R2
2
R4
2
Сеть
10.1.1.0/24
ViaR 3
ViaR 5
FD AD Topology
-1
**ACTIVE **
5 3
5 4
( Q)
1
R
Сеть
10.1.1.0/24
Via R 2
Via R 5
FD AD Topology
3
3
1 S
4 3
Сеть
FD AD Topology
10.1.1.0/24 -1
**ACTIVE **
ViaR 3
4 3
(Q)
1
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
1
R2
2
Сеть
10.1.1.0/24
Via R 2
Via R 5
FD AD Topology
3
3
1 S
4 3
R4
2
R
FD AD Topology
-1
**ACTIVE **
5 3
5 4
( Q)
1
Сеть
FD AD Topology
10.1.1.0/24 4
Via R 3
4 3
S
1
R3
Сеть
10.1.1.0/24
Via R 3
Via R 5
R5
Рисунок 6.14 – Маршрутизатор R5 получает ответ от R3
Маршрутизатор R5 отвечает на запрос о маршруте до сети 10.1.1.0/24
маршрутизатору R4. На маршрутизаторе R4 алгоритм DUAL получает ответ и
удаляет флаг запроса с маршрута до сети 10.1.1.0/24 через R5.
Маршрутизатор R4 рассчитывает новые FD до сети 10.1.1.0/24 через
маршрутизаторы R3 и R5. Маршруты через R3 и R5 имеют одинаковые FD и
оба маркируются как преемники. Маршрут до сети 10.1.1.0/24 переводится из
активного состояния в пассивное.
Маршрутизатор R4 устанавливает новых преемников в таблицу маршрутизации (Рисунок 6.15).
122
10.1.1.0/24
R1
1
R2
2
Сеть
10.1.1.0/24
Via R 2
Via R 5
FD AD Topology
3
3
1 S
4 3
Сеть
10.1.1.0/24
Via R 3
Via R 5
R4
2
1
R
Сеть
FD AD Topology
10.1.1.0/24 4
Via R 3
4 3
S
1
R3
FD AD Topology
5
5 3
S
5 4
S
R5
Рисунок 6.15 – Маршрутизатор R4 получает ответ от R5
Полученная сеть (Рисунок 6.16) является сведенной и стабильной.
Маршрутизатор R4 имеет в таблице маршрутизации два маршрута до сети
10.1.1.0/24. По этим двум маршрутам автоматически включается механизм
балансировки нагрузки.
10.1.1.0/24
R1
1
R2
2
Сеть
10.1.1.0/24
Via R 2
Via R 5
FD AD Topology
3
3
1 S
4 3
R4
2
FD AD Topology
5
5 3
S
5 4
S
1
Сеть
FD AD Topology
10.1.1.0/24 4
ViaR 3
4 3
S
1
R3
Сеть
10.1.1.0/24
ViaR 3
ViaR 5
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
R1

Q
10.1.1.0/24
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
R1
SIA-Q
Q
R2

10.1.1.0/24
R3
SIA-R
Рисунок 6.18 – Работа механизма SIA–Query
Маршрутизатор R1 обнаруживает недоступность сети 10.1.1.0/24 и
посылает запрос о ней маршрутизатору R2. Маршрутизатор R2 не подключен
к этой сети и обращается с запросом к маршрутизатору R3. Если проблема в
канале связи находиться между маршрутизаторами R2 и R3, пакет ответа от
маршрутизатора R3 к R2 может быть потерян. Маршрутизатор R1 не видит
протекание процесса и предполагает, что проблема находится в канале связи
до маршрутизатора R2. После трех минутной задержки R1 прекращает соседские отношения с R2 и сбрасывает все известные маршруты, проходящие через маршрутизатор R2.
При использовании SIA–Query маршрутизатор R1 при отсылке запроса
к R2 в середине трехминутного интервала посылает SIA–Query к маршрутизатору R2. Маршрутизатор R2 получает SIA–Query и отвечает на него SIA–
Reply, R1 получив пакет, подтверждает достижимость маршрутизатора R2 и
не разрывает и ним соседские отношения. Через такое же время R2 посылает
SIA–Query маршрутизатору R3 и не получив на него ответ прекращает с ним
соседские отношения. После этого маршрутизатор R2 оповещает маршрути-
125
затор R1 о недостижимости сети 10.1.1.0/24. Маршрутизаторы R1 и R2 удаляют активный маршрут до сети 10.1.1.0/24 из своих таблиц топологии. Отношения соседства между маршрутизаторами R1 и R2 не изменяются.
126
7 Конфигурирование и тестирование протокола EIGRP
Несмотря на сложность алгоритма DUAL, конфигурирование протокола
EIGRP является относительно простым.
7.1 Запуск протокола EIGRP
Для запуска протокола EIGRP используется команда router eigrp
autonomus–system–number. Параметр autonomus–system–number представляет
собой номер автономной системы, который используется для идентификации
маршрутизаторов принадлежащих домену маршрутизации. Это значение
должно совпадать у всех маршрутизаторов в пределах домена маршрутизации.
Для описания сетей участвующих в процессе маршрутизации используется команда network.
Синтаксис команды network для протокола EIGRP приводится в примере 7.1.
Пример 7.1 – Синтаксис команды network
(config-router)# network network-number [wildcard-mask]
(config-router)# no network network-number [wildcard-mask]
Описание параметров команды network приводиться в таблице 7.1.
Таблица 7.1 – Параметры команды network
Параметр
network-number
wildcard-mask
Описание
Номер сети участвующей в процессе
маршрутизации EIGRP.
Обратная маска подсети для сети
участвующей в процессе маршрутизации EIGRP.
По значению network-number маршрутизатор определяет, какие сети будут участвовать в процессе маршрутизации EIGRP и через какие интерфейсы
производить рассылку служебных пакетов протокола EIGRP. По умолчанию
рассылка служебных пакетов производиться со всех интерфейсов попадающих в network-number, поэтому не следует забывать о команде passive-interface для контроля интерфейсов, с которых производиться рассылка служебной информации.
127
Если не использовать параметр wildcard-mask, то процесс маршрутизации EIGRP предполагает, что все непосредственно подключенные подсети являющиеся частью описанной полной классовой сети, будут участвовать в
процессе маршрутизации EIGRP.
При использовании параметра wildcard-mask процесс маршрутизации
EIGRP проводит отбор подсетей участвующих в процессе маршрутизации как
по совпадению номера сети, так по попаданию маски подсети в диапазон
wildcard-mask. Стоит подчеркнуть, что при использовании на маршрутизаторе
нескольких непрерывных подсетей, в процессе маршрутизации не стоит описывать каждую сеть в отдельности, а можно описать сеть с суммарной wildcard-mask. Для работы процесса маршрутизации не имеет значения, используются суммарные или частные wildcard-mask, в независимости от этого, маршруты будут распространяться о частных подсетях. Использование суммарных
wildcard-mask уменьшает количество строк конфигурации маршрутизатора,
тем самым, упрощая процесс ее восприятия администратором сети.
Как говорилось ранее, главной составляющей в метрике протокола EIGRP является полоса пропускания канала связи. Поэтому, особенно на последовательных интерфейсах, необходимо задать пропускную способность канала. Если значение пропускной способности для таких интерфейсов не менять,
протокол EIGRP будет считать, что пропускная способность канала будет
равна T1. Если канал работает медленнее, маршрутизатор будет вести неправильный расчет метрик маршрутов. Для задания справочной скорости на канале связи используется команда bandwidth.
Синтаксис команды bandwidth приводится в примере 7.2.
Пример 7.2 – Синтаксис команды bandwidth
(config-if)# bandwidth kbps
Здесь значение kbps определяет задаваемую пропускную способность в
килобитах в секунду. Для топологий типа "точка–точка", таких как РРР или
HDLC, пропускная способность устанавливается равной скорости линии. Для
интерфейсов типа "точка–точка" Frame Relay пропускная способность устанавливается равной согласованной скорости передачи информации (Committed Information Rate – CIR). Для многоточечных каналов это значение устанавливается равным сумме всех значений CIR на данном интерфейсе.
Стоит обратить особенное внимание, что скорость канала, задаваемая
командой bandwidth, является только справочной, и ни как не влияет на реальную скорость передачи данных по каналу связи. Часто сетевые администраторы задают на каналах справочные скорости меньше или больше реальных с целью того чтобы маршрут через этот канал становился менее или наоборот более привлекательным с точки зрения протокола EIGRP. Манипулиро-
128
вание значением bandwidth является самым простым и действенным способом
влияния на процесс выбора маршрутов протоколом EIGRP.
Также рекомендуется в настройках процесса маршрутизации использовать команду eigrp log-neighbor-changes. При использовании данной команды
фиксируются все события связанные с изменением состояния соседних EIGRP маршрутизаторов с которыми установлены и поддерживаются соседские
отношения. В последних версиях IOS данная команда включена по умолчанию и не отображается в конфигурации маршрутизатора.
AS200
r1#
router eigrp 200
network 10.0.0.0
network 172.16.0.0
192 .168 .1.0/24
10.4.0.0/16
10.1.0.0/16
R2
172 .16.2.0/24
S0
R1
R4
172 .16.1.0/24
172.16.7.0/24
S2
S1
R3
172 .16.4.0/24
Рисунок 7.1 – Пример конфигурации процесса маршрутизации в AS 200
На рисунке 7.1 приводится конфигурация процесса маршрутизации EIGRP на маршрутизаторах автономной системы. Маршрутизатор R1, совместно с другими маршрутизаторами является частью автономной системы с номером 200. Для установки соседских отношений все маршрутизаторы должны
принадлежать одной автономной системе.
При включении в процесс маршрутизации EIGRP сетей настроенных на
интерфейсах маршрутизатора R1 можно воспользоваться следующими командами (Пример 7.1).
Пример 7.1 – Запуск процесса EIGRP на маршрутизаторе R1
r1(config)# router
r1(config–router)#
r1(config–router)#
r1(config–router)#
r1(config–router)#
eigrp 200
network 10.1.0.0
network 10.4.0.0
network 172.16.2.0
network 172.16.7.0
Так как при настройке не использовались обратные маски для задания
сетей участвующих в процессе маршрутизации, то маршрутизатор автоматически произведет суммирование команд network до классовых сетей. В ре-
129
зультате получится конфигурация представленная на рисунке 7.1, следовательно, все интерфейсы маршрутизатора R1 являющееся частью сетей
10.0.0.0/8 и 172.16.0.0/16 участвуют в процессе маршрутизации.
Другой возможной конфигурацией маршрутизатора может быть конфигурация представленная в примере 7.2.
Пример 7.2 – Конфигурация EIGRP с использованием wildcard-mask
router eigrp 200
network 10.1.0.0 0.0.255.255
network 10.4.0.0 0.0.255.255
network 172.16.2.0 0.0.0.255
network 172.16.7.0 0.0.0.255
В данной конфигурации маршрутизатор сопоставляет номер сети и
обратную маску сети для определения интерфейсов участвующих в процессе
маршрутизации в пределах автономной системы.
R2
17
2.
16
.2.
0/2
4
S1
r2#
router eigrp 200
network 172.16.0.0
S2
R3
/24
3.0
6.
1
.
2
17
172 .16.1.0/30
R1
External Network
S0
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 пакеты во внешнюю сеть. Это приведет к потерям пропускной способности канала связи, загрузке вычислительных возможностей маршрутизатора и распространению во внешнюю сеть информации о
топологии «домашней» сети.
В современных сетях передачи данных на маршрутизаторах могут быть
одновременно запущены несколько протоколов маршрутизации или несколько процессов маршрутизации одного протокола, поэтому использование wildcard-mask позволяет точно указывать какие сети, будут участвовать в конкретном процессе маршрутизации.
130
В ОС IOS при описании сетей в процесс маршрутизации EIGRP есть
возможность автоматического преобразования масок подсетей в wildcardmask, При описании сети можно использовать маски подсети, а в конфигурационный файл маршрутизатора будут внесены требуемые сети с соответствующими wildcard-mask.
7.2 Настройка аутентификации в протоколе EIGRP
Также как и в протоколе RIP в протоколе EIGRP аутентификация настраивается на каждом выходном интерфейсе, за которым находятся соседние
маршрутизаторы. Для настройки аутентификации используются следующие
команды. Команда ip authentication key-chain eigrp указывает на ключевую цепочку, которая будет использована для аутентификации. Команда ip authentication 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
R1
r1#
interface serial 0
ip address 172.16.1.1 255 .255.255.252
ip authentication key -chain eigrp 200 trees
ip authentication mode eigrp 200 md5
!
router eigrp 200
network 172.16.1.0 255.255.255.252
!
key chain trees
key 1
key-string chestnut
S0
S1
R2
r2#
interface serial 1
ip address 172.16.1.2 255.255.255.252
ip authentication key -chain eigrp 200 trees
ip authentication mode eigrp 200 md5
!
router eigrp 200
network 172.16.1.0 255.255.255.252
!
key chain trees
key 1
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:
10.93.1.2 (Serial0/0/1) is up: new adjacency
IP-EIGRP(0)
200:
Neighbor
Также процесс обмена Hello пакетами можно посмотреть при помощи
команды debug eigrp packets, которая выводит информацию обо всех служебных пакетах протокола EIGRP, отправленных и полученных маршрутизатором (Пример 7.6).
Пример 7.6 – Вывод информации о пакетах протокола EIGRP
*Mar 13 18:42:20.079 KRSK: EIGRP: Sending HELLO on Serial0/0/1
*Mar 13 18:42:20.079 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0
*Mar 13 18:42:20.299 KRSK: EIGRP: received packet with MD5 authentication, key
id = 1
*Mar 13 18:42:20.299 KRSK: EIGRP: Received HELLO on Serial0/0/1 nbr 10.93.1.2
*Mar 13 18:42:20.299 KRSK: AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0 peerQ un/rely 0/0
Если по каким либо причинам аутентификация не прошла, то команда
debug eigrp packets проинформирует об этом при помощи сообщения вида
(Пример 7.7)
Пример 7.7 – Ошибка аутентификации
*Mar 13 18:45:26.843 KRSK: EIGRP: pkt key id = 1, authentication mismatch
*Mar 13 18:45:26.843 KRSK: EIGRP: Serial0/0/1: ignored packet from 10.93.1.2,
opcode = 5 (invalid authentication)
Если до настройки аутентификации маршрутизаторы уже находились в
соседских отношениях, а при аутентификации произошла ошибка, то на консоль будет выведено сообщение представленное в примере 7.8
132
Пример 7.8 – Разрыв соседских отношений
*Mar 13 18:44:44.951 KRSK: %DUAL-5-NBRCHANGE:
10.93.1.2 (Serial0/0/1) is down: Auth failure
IP-EIGRP(0)
200:
Neighbor
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-network-mask
admin-distance
Описание
Номер автономной системы, для которой задается суммарный маршрут.
IP адрес суммарного маршрута.
Маска подсети суммарного маршрута.
Административное расстояние для
суммарного маршрута.
133
По умолчанию параметр admin-distance для суммарных маршрутов протокола EIGRP равняется 5. Это сделано, для того чтобы такой суммарный
маршрут выигрывал по административному расстоянию у маршрутов от всех
других динамических протоколов маршрутизации, в том числе и у самого EIGRP. Однако в некоторых ситуациях это может привести к неправильной работе сети, поэтому для суммарных маршрутов желательно устанавливать
административное расстояние равное административному расстоянию протокола 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
172 .16.2.0/24
R2
172 .16.3.0/24
192 .168 .1.0/30
10.0.0.0/8
R3
r3#
router eigrp 200
network 10.0.0.0
network 172.16.0.0
no auto -summary
WAN
R4
S0
r4#
router eigrp 200
network 10.0.0.0
network 192.168.1.0 0.0.0.3
!
interface Serial 0
ip address 192.168.1.1 255.255.255.252
ip summary-address eigrp 200 10.0.0.0 255.0.0.0 90
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
R2
R1
S0
r1# show ip route
Gateway of last resort is not set
...
C
10.64.0.0/24 is derectly connected , Ethernet 0
S* 192.168.1.0/30 [1/0] via 192.168.1.1
r2# show ip route
...
Gateway of last resort is 10.64.0.1 to network 192.168.1.0
10.0.0.0/8 is variably subnetted , 7 subnets, 2 masks
...
C
10.64.0.0/24 is derectly connected , Ethernet 0
D* 192.168.1.0/30 [90/10486122] via 10.64.0.1, 00:00:15, Ethernet0
Рисунок 7.5 – Маршрут по умолчанию в протоколе EIGRP
Маршрутизатор сконфигурированный данной командой, рассматривает
сеть, описанную в этой команде как шлюз «последней надежды». Сеть должна быть достижима для маршрутизатора, который использует эту команду,
прежде чем он объявит себя как кандидат на маршрут по умолчанию.
Сеть, сконфигурированную в этой команде нужно также объявить другим EIGRP маршрутизаторам так, чтобы те могли использовать эту сеть как
маршрут по умолчанию и установить шлюз «последней надежды».
Начиная с версии IOS 12.0(4)T еще одним возможным способом распространения маршрута по умолчанию 0.0.0.0 0.0.0.0 является настройка суммарного маршрута 0.0.0.0 0.0.0.0 на выходных интерфейсах головного маршрутизатора.
7.5 Распределение нагрузки в протоколе EIGRP
Как и другие протоколы динамической маршрутизации, протокол EIGRP способен использовать механизм распределения нагрузки по маршрутам
с равной стоимостью. По умолчанию количество маршрутов, по которым может производиться распределение нагрузки, равняется четырем.
Кроме этого протокол EIGRP имеет возможность распределения нагрузки между маршрутами с различными метриками. Степень различия метрик маршрутов, по которым будет производиться распределение нагрузки,
можно контролировать с помощью команды variance заданной в режиме кон-
135
фигурации процесса маршрутизации EIGRP. Синтаксис команды variance
приводится в примере 7.10.
Пример 7.10 – Синтаксис команды variance
(config-router)# variance multiplier
(config-router)# no variance
Параметр multiplier (множитель) отражает значение вариации от 1 до 128,
используемой при распределении нагрузки. По умолчанию принимается значение 1, что означает распределение нагрузки по маршрутам с равной стоимостью. Множитель отражает диапазон значений метрик маршрутов, которые будут приниматься в расчет для распределения нагрузки.
20
10
R2
10
R5
Z
10
R3
30
R1
15
R4
Рисунок 7.6 – Распределение нагрузки по маршрутам
с различными метриками
На рисунке 7.6 диапазон метрик, для маршрутов от маршрутизатора R5
до сети Z, составляет от 20 до 45. Этот диапазон значений используется в процедуре определения потенциального маршрута. Маршрут считается приемлемым, если следующий маршрутизатор, лежащий на пути, будет ближе к получателю, чем текущий, и метрика всего маршрута лежит в пределах вариации.
Если этих условия соблюдены, то такой маршрут будет считаться приемлемым, и он будет записан в таблицу маршрутизации. Для распределения нагрузки могут быть использованы только приемлемые маршруты.
На рисунке 7.6, имеются три маршрута к сети Z, метрики для этих
маршрутов:
– 30 – верхний маршрут;
– 20 – средний маршрут;
– 45 – нижний маршрут.
136
По умолчанию маршрутизатор R5 помещает в свою таблицу маршрутизации только средний маршрут потому, что он обладает наименьшей метрикой.
Для включения режима балансировки нагрузки по маршрутам с различными метриками воспользуемся командой variance, при этом балансировка
будет осуществляться по маршрутам, чья метрика меньше метрики наилучшего маршрута умноженного на величину variance.
Для включения балансировки между средним и верхним маршрутами
необходимо использовать variance = 2, т.к. 20*2=40, а это больше метрики
верхнего маршрута. Точно также, что бы добавить нижний маршрут необходимо использовать variance = 3.
При включении процесса распределения нагрузки по маршрутам с
разными метриками, маршрутизатор производит распределение пакетов в зависимости от величины variance. По маршруту соответствующему variance =
2, будет отправлено в два раз меньше пакетов относительно количества пакетов отправленного по наилучшему маршруту.
7.6 Расширенная настройка протокола EIGRP
7.6.1 Таймеры протокола EIGRP
Протокол EIGRP не использует периодическую рассылку маршрутной
информации соседним маршрутизаторам. Однако для поддержания соседских
отношений между маршрутизаторами необходимо периодически передавать
Hello пакеты. При получении от соседа Hello пакета маршрутизатор понимает, что сосед продолжает функционировать.
Исходя из этого, в протоколе EIGRP существует два основных таймера:
– таймер рассылки Hello пакетов;
– таймер ожидания Hello пакетов.
По умолчанию таймер рассылки Hello пакетов равняется 60 секундам
для низкоскоростных каналов связи, со скоростями меньшими, чем T1 и сетей
NBMA. Для всех остальных типов сетей интервал рассылки Hello пакетов равен 5 секундам.
Время ожидания получения Hello пакетов должно равняться не менее
трем интервалам рассылки Hello пакетов, следовательно, для низкоскоростных каналов связи данный интервал равняется 180 секундам, а для всех
остальных каналов связи 15 секундам.
При необходимости стандартные значения таймеров можно изменить,
используя команды ip hello-interval eigrp и ip hold-time eigrp . Синтаксис команд приводится в примерах 7.11 и 7.12.
137
Пример 7.11 – Синтаксис команды ip hello-interval eigrp
(config-router)# ip hello-interval eigrp as-number seconds
(config-router)# no ip hello-interval eigrp as-number seconds
Пример 7.12 – Синтаксис команды ip hold-time eigrp
(config-router)# ip hold-time eigrp as-number seconds
(config-router)# no ip hold-time eigrp as-number seconds
Следует помнить, что при изменении стандартных таймеров, для корректной работы протокола EIGRP необходимо соблюдать соотношение
таймеров рассылки Hello пакетов и ожидания Hello пакетов.
Еще одним таймером протокола EIGRP является таймер наступления
состояния SIA для сети, о которой был отправлен запрос. По умолчанию данный таймер равняется трем минутам. В больших сетях передачи данных использующих низкоскоростные каналы связи может понадобиться изменить
данный таймер, используя команду timers active-time. Синтаксис команды
приводится в примере 7.13.
Пример 7.13 – Синтаксис команды timers active-time
(config-router)# timers active-time [time-limit | disabled]
(config-router)# no timers active-time
Описание параметров команды timers active-time приводиться в таблице
7.3.
Таблица 7.3 – Параметры команды timers active-time
Параметр
time-limit
disabled
Описание
Время в минутах, по истечении которого наступает состояние SIA.
Отключение таймера, разрешение
маршрутизатору ожидать получение
ответов бесконечно долгое время.
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
external-distance
Описание
Административное расстояние внутренних (собственных) маршрутов EIGRP. По умолчанию 90.
Административное расстояние внешних маршрутов 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
k1 k2 k3 k4 k5
Описание
Параметр типа сервиса, всегда устанавливается равным 0.
Устанавливаемые весовые коэффициенты.
Например, при использовании в сети передачи данных ненадежных каналов связи, можно установить k5=1, тогда формула расчета метрики примет
вид (7.1):
Metric = (BW + Delay)*(1/R)
где
(7.1)
BW – пропускная способность канала;
Delay – задержка на канале связи;
R – надежность канала связи.
Необходимо подчеркнуть, что модификация весовых коэффициентов
должна производиться на всех маршрутизаторах входящих в автономную систему.
Весовые коэффициенты могут модифицироваться только после тщательного планирования. Изменение значений по умолчанию может препятствовать сходимости сети.
7.6.4 Настройка протокола EIGRP для сетей NBMA
Для функционирования протокола EIGRP в сетях NBMA необходимо
на каждом маршрутизаторе вручную указывать соседей при помощи команды
neighbor, синтаксис команды приводится в примере 7.16.
Пример 7.16 – Синтаксис команды neighbor
(config-router)# neighbor ip-address interface-type interface-number
(config-router)# no neighbor ip-address interface-type interface-number
В данной команде помимо IP адреса соседнего маршрутизатора явно
указывается, за каким интерфейсом он находиться.
140
7.6.5 Использование EIGRP пропускной способности каналов связи
По умолчанию протокол EIGRP использует до 50% объявленной пропускной способности интерфейса. Этот процент можно отрегулировать с помощью команды ip bandwidth–percent eigrp, синтаксис команды приводится в
примере 7.17.
Пример 7.17 – Синтаксис команды ip bandwidth–percent eigrp
(config-if)# ip bandwidth-percent eigrp as-number percent
(config-if)# no ip bandwidth-percent eigrp as-number percent
Параметр percent можно устанавливать в значение, превышающее 100.
Такой подход имеет смысл в тех случаях, когда пропускная способность задана искусственно заниженной в связи с политикой маршрутизации. Очень важно, чтобы канал связи мог выдерживать такие трафики.
7.6.6 Идентификация маршрутизаторов в протоколе EIGRP
Для идентификации маршрутизаторов используется идентификатор
маршрутизатора – router ID (RID). Значение RID устанавливается в момент
запуска процесса маршрутизации EIGRP и не изменяется во время дальнейшей работы процесса маршрутизации. В качестве RID может быть выбран:
– Старший IP адрес любого физического интерфейса маршрутизатора.
Интерфейс может не использоваться в процессе EIGRP маршрутизации, но он
должен находиться в активном состоянии.
– В качестве идентификатора может использоваться логический интерфейс loopback. Данный интерфейс всегда находиться в активном состоянии,
поэтому использование логического интерфейса является наиболее предпочтительным. Если на маршрутизаторе задано несколько логических интерфейсов в качестве идентификатора будет выбран старший IP адрес.
– В случаях если на маршрутизаторе запущено несколько процессов
маршрутизации EIGRP имеется возможность задания идентификатора вручную с помощью команды eigrp router-id. Синтаксис команды eigrp router-id
приводится в примере 7.18.
Пример 7.18 – Синтаксис команды eigrp router-id
(config-router)# eigrp router-id ip-address
(config-router)# no eigrp router-id ip-address
В данном случае в качестве параметра ip-address назначается IP адрес
выбранного loopback интерфейса. Существует два исключения, в качестве
141
RID не могут быть назначены значения 0.0.0.0 и 255.255.255.255.Самым высоким приоритетом при назначении идентификатора обладает ручная настройка, самым низким старший адрес физического интерфейса.
Однажды заданный идентификатор активен все время работы процесса
маршрутизации EIGRP. Если во время работы маршрутизатора интерфейс адрес, которого используется в качестве идентификатора маршрутизатора, переходит в неактивное состояние, идентификатор маршрутизатора не изменяется. Однако при использовании адресов физических интерфейсов в качестве
идентификатора маршрутизатора нельзя гарантировать, что после перезагрузки маршрутизатора будет назначен тот же идентификатор.
Хотя применение RID было представлено еще в версии IOS 12.1, оно не
получило функционального наполнения и не имеет такого значения как RID
для протокола OSPF.
7.7 Тестирование и устранение ошибок в работе протокола EIGRP
Для проверки правильности созданной конфигурации протокола EIGRP
могут быть использованы несколько команд. Наиболее часто используемыми
командами общего назначения являются show ip route и show ip protocols.
Команда show ip route или команда show ip route eigrp отображает таблицу маршрутизации построенную маршрутизатором. Вторая команда отображает только маршруты из таблицы маршрутизации полученные протоколом EIGRP, такие маршруты помечаются буквой «D» (Пример 7.19).
Пример 7.19 – Таблица маршрутизации протокола EIGRP
r2#show ip route eigrp
172.16.0.0/28 is subnetted, 2 subnets
D
172.16.0.16 [90/2304000] via 172.16.0.1, 00:00:27, Serial0/0/0
10.0.0.0/8 is variably subnetted, 16 subnets, 2 masks
D
10.89.1.64/28 [90/1794560] via 10.93.1.18, 00:00:27, Serial0/1/0
D
10.89.1.16/28 [90/1794560] via 10.93.1.2, 00:00:27, Serial0/0/1
D
10.95.1.4/32 [90/1920000] via 10.93.1.2, 00:00:27, Serial0/0/1
D
10.95.1.5/32 [90/1920000] via 10.93.1.18, 00:00:27, Serial0/1/0
D
10.89.1.0/28 [90/1794560] via 10.93.1.2, 00:00:27, Serial0/0/1
D
10.89.0.0/28 [90/1794560] via 172.16.0.1, 00:00:27, Serial0/0/0
D
10.95.0.1/32 [90/1920000] via 172.16.0.1, 00:00:27, Serial0/0/0
D
10.93.1.32/28 [90/1794560] via 10.93.1.18, 00:00:28, Serial0/1/0
[90/1794560] via 10.93.1.2, 00:00:28, Serial0/0/1
При вводе команды show ip protocols отображается информация обо
всех протоколах IP маршрутизации, в том числе и о протоколе EIGRP, сконфигурированных на маршрутизаторе (Пример 7.20).
142
Пример 7.20 – Информация, выводимая командой show ip protocols
r2#show ip protocols
Routing Protocol is "eigrp 200"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100
EIGRP maximum metric variance 1
Redistributing: eigrp 200
EIGRP NSF-aware route hold timer is 240s
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
10.0.0.0
172.16.0.0
Passive Interface(s):
FastEthernet0/0
Routing Information Sources:
Gateway
Distance
Last Update
10.93.1.18
90
00:01:22
10.93.1.2
90
00:01:22
172.16.0.1
90
00:01:22
Distance: internal 90 external 170
Такие сведения могут быть использованы для тестирования
большинства параметров протокола EIGRP. Ниже перечислены островные тестируемые параметры конфигурации:
– Номер автономной системы, в которой запущен протокол EIGRP;
– Значения весовых коэффициентов используемых в AS;
– Используется или нет автоматическое суммирование маршрутов;
– Анонсирует ли маршрутизатор требуемые сети;
– Интерфейсы, через которые не распространяется маршрутная информация;
– С какими маршрутизаторами установлены соседские отношения.
Кроме команд применимых ко всем протоколам маршрутизации существует ряд специальных команд отображающих информацию протокола EIGRP. К такой информации относятся таблицы соседства и топологии, статистическая информация о переданных и полученных служебных пакетах, информация о работе интерфейсов маршрутизатора по обработке служебных пакетов.
Для вывода таблиц соседства и топологии применяются соответственно
команды 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]] [active | 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 eigrp 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 accounting
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 interfaces (Пример 7.28).
Пример 7.28 – Информация, выводимая командой show ip eigrp interfaces
IP-EIGRP interfaces for process 200
Xmit Queue
Mean
Interface
Peers
Un/Reliable SRTT
Se0/0/1
1
0/0
2
Se0/1/0
1
0/0
1
Se0/0/0
1
0/0
1
Pacing Time
Un/Reliable
0/12
0/12
0/12
Multicast
Flow Timer
50
50
50
Pending
Routes
0
0
0
Синтаксис команды show ip eigrp interfaces приводится в примере 7.29.
146
Пример 7.29 – Синтаксис команды show ip eigrp interfaces
show ip eigrp interfaces [interface-type interface-number] [as-number]
В набор инструментов для отладки работы протокола EIGRP запущенного на маршрутизаторе также входит ряд команд debug.
Для вывода информации о передачи служебных пакетов EIGRP используется команда debug eigrp packets. Данная команда отображает все служебные пакеты протокола EIGRP, которые были получены или переданы маршрутизатором. Информация, выводимая данной командой, представлена в примере 7.30.
Пример 7.30 – Информация, выводимая командой debug eigrp packets
r2#debug eigrp packets
EIGRP Packets debugging is on
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)
*Mar 15 13:40:50.151 KRSK: EIGRP: Received HELLO on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:50.151 KRSK:
AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0 peerQ un/rely 0/0
*Mar 15 13:40:50.251 KRSK: EIGRP: Sending HELLO on Serial0/0/1
*Mar 15 13:40:50.251 KRSK:
AS 200, Flags 0x0, Seq 0/0 idbQ 0/0 iidbQ un/rely
0/0
*Mar 15 13:40:51.695 KRSK: EIGRP: Received QUERY on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.699 KRSK:
AS 200, Flags 0x0, Seq 84/71 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 0/0
*Mar 15 13:40:51.699 KRSK: EIGRP: Enqueueing ACK on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.699 KRSK:
Ack seq 84 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Mar 15 13:40:51.703 KRSK: EIGRP: Sending ACK on Serial0/0/1 nbr 10.93.1.2
*Mar 15 13:40:51.703 KRSK:
AS 200, Flags 0x0, Seq 0/84 idbQ 0/0 iidbQ
un/rely 0/0 peerQ un/rely 1/0
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing REPLY on Serial0/0/1 nbr
10.93.1.2 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 77-77
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing UPDATE on Serial0/0/0 iidbQ
un/rely 0/1 serno 78-78
*Mar 15 13:40:51.711 KRSK: EIGRP: Enqueueing UPDATE on Serial0/1/0 iidbQ
un/rely 0/1 serno 78-78
Если необходимо получить расширенную информацию о содержимом
пакетов с маршрутной информацией, таких как Update, Query, Replay необходимо воспользоваться командой debug ip eigrp. Данная команда отображает
получение или отправку всех служебных пакетов EIGRP за исключением
Hello пакетов, и содержащуюся в них информацию. Информация, выводимая
командой, представлена в примере 7.31.
147
Пример 7.31 – Информация, выводимая командой debug ip eigrp
r2#debug ip eigrp
IP-EIGRP Route Events debugging is on
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming QUERY packet
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 routing table not updated thru 10.93.1.2
*Mar 15 13:44:02.023 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): route installed for 10.89.1.0 ()
*Mar 15 13:44:02.039 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming QUERY packet
*Mar 15 13:44:02.039 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/1
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/0
*Mar 15 13:44:02.043 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.047 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.051 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - do advertise out Serial0/0/1
*Mar 15 13:44:02.051 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
*Mar 15 13:44:02.067 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.067 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.071 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.071 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Processing
incoming REPLY packet
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 M 4294967295 - 0 4294967295 SM 4294967295 - 0 4294967295
*Mar 15 13:44:02.179 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 routing table not updated thru 10.93.1.18
*Mar 15 13:44:02.199 KRSK: IP-EIGRP(Default-IP-Routing-Table:200):
10.89.1.0/28 - not in IP routing table
*Mar 15 13:44:02.199 KRSK: IP-EIGRP(Default-IP-Routing-Table:200): Int
10.89.1.0/28 metric 4294967295 - 0 4294967295
Для отображения информации о процессе работы алгоритма DUAL, используется команда debug eigrp fsm. Информация, выводимая командой,
представлена в примере 7.32.
148
Пример 7.32 – Информация, выводимая командой debug eigrp fsm
r2#debug eigrp fsm
EIGRP FSM Events/Actions debugging is on
*Mar 15 14:05:16.051 KRSK: DUAL: rcvquery: 10.93.1.32/28 via 10.93.1.2 metric
4294967295/4294967295, RD is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL: Find FS for dest 10.93.1.32/28. FD is
1794560, RD is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL:
10.93.1.2 metric 4294967295/4294967295
*Mar 15 14:05:16.051 KRSK: DUAL:
10.93.1.18 metric 1794560/28160 found
Dmin is 1794560
*Mar 15 14:05:16.051 KRSK: DUAL: send REPLY(r1/n1) about 10.93.1.32/28 to
10.93.1.2
*Mar 15 14:05:16.051 KRSK: DUAL: RT installed 10.93.1.32/28 via 10.93.1.18
*Mar 15 14:05:16.051 KRSK: DUAL: Send update about 10.93.1.32/28. Reason:
nexthop changed
*Mar 15 14:05:16.051 KRSK: DUAL: Send update about 10.93.1.32/28. Reason:
lost if
*Mar 15 14:05:16.075 KRSK: DUAL: Removing dest 10.93.1.32/28, nexthop
10.93.1.2, infosource 10.93.1.2
*Mar 15 14:05:16.087 KRSK: DUAL: dest(10.93.1.32/28) not active
*Mar 15 14:05:16.087 KRSK: DUAL: rcvupdate: 10.93.1.32/28 via 10.93.1.2 metric
1797120/30720
*Mar 15 14:05:16.087 KRSK: DUAL: Find FS for dest 10.93.1.32/28. FD is
1794560, RD is 1794560
*Mar 15 14:05:16.087 KRSK: DUAL:
10.93.1.18 metric 1794560/28160
*Mar 15 14:05:16.087 KRSK: DUAL:
10.93.1.2 metric 1797120/30720 found
Dmin is 1794560
*Mar 15 14:05:16.087 KRSK: DUAL: RT installed 10.93.1.32/28 via 10.93.1.18
Для отображения детальной информации о процессе формировании
передачи служебных пакетов используется команда debug eigrp transmit. Синтаксис команды debug eigrp transmit приводится в примере 7.33.
Пример 7.33 – Синтаксис команды debug eigrp transmit
debug eigrp transmit [ack] [build] [detail] [peerdown] [sia] [startup]
[strange]
no debug eigrp transmit [ack] [build] [detail] [peerdown] [sia] [startup]
[strange]
Описание параметров команды debug eigrp transmit приводиться в таблице 7.8.
Таблица 7.8 – Параметры команды debug eigrp transmit
Параметр
ack
build
Описание
Информация о пакетах ACK посланных маршрутизатором.
Вывод сообщений об изменениях в таблице топологии.
149
Продолжение таблицы 7.8
Параметр
detail
peerdown
sia
startup
strange
Описание
Вывод детальной информации.
Вывод сообщений генерируемых после потери соседа.
Вывод сообщений SIA.
Вывод сообщений генерируемых после установки соединения с соседом.
Вывод редких сообщений связанных с
обменом служебными пакетами.
При тестировании и устранении ошибок в процессе маршрутизации EIGRP бывает необходимо сбросить соседские отношения с одним, несколькими или со всеми соседними 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
R3
R
R1
R4
Q
Q
R
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
192 .168 .1.0/24
R2
S1
R3
R1
R 172 .16.1.0/24
Unreachable
172 .16.0.0/16
172 .16.1.0/24
R 172 .16.1.0/24
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
Q
R
R1
10.0.0.0/8

R3
Q
R
R2
10.0.0.0/8
R4
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
connected
static
Описание
Ограничивает функции маршрутизатора только получением маршрутов от
других маршрутизаторов. Маршрутизатор сконфигурированный, данной
командой не рассылает другим маршрутизаторам известные ему маршруты.
Любые другие опции при использовании receive–only становятся недоступны, потому что они предусматривают
рассылку маршрутов во внешнюю
сеть.
Опция разрешает рассылку маршрутов
на сети, которые являются непосредственно подключенными к данному
маршрутизатору. Эта опция включается по умолчанию при конфигурации
тупикового маршрутизатора и является наиболее используемой.
Даная опция позволяет маршрутизатору производить рассылку статических
маршрутов из его таблицы маршрутизации. Для корректной работы маршрутизатора в данной конфигурации
необходимо присутствие команды redistribute static в настройках EIGRP
маршрутизатора
156
Продолжение таблицы 8.1
Параметр
Описание
Опция позволяет рассылку суммарных
маршрутов. Суммарные маршруты могут быть настроены вручную при помощи команды summary–address или
автоматически командой auto–summary. Опция summary включается автоматически.
Опция позволяет рассылку маршрутов
полученную от других протоколов
маршрутизации. Для корректной работы маршрутизатора в данной конфигурации необходима настройка механизмов перераспределения маршрутной
информации от других протоколов
маршрутизации
summary
redistributed
Команда eigrp stub может конфигурироваться с несколькими опциями,
которые могут использоваться в любой комбинации, за исключением receiveonly. Опция receive-only используется индивидуально.
При использовании технологии тупиковых маршрутизаторов на вышестоящих маршрутизаторах не могут автоматически создаваться суммарные
маршруты для тупиковых маршрутизаторов. В протоколе EIGRP администратору сети, если это необходимо, приходиться вручную настраивать суммарные маршруты для тупиковых маршрутизаторов.
10.1.1.0/24

Q
R3
R
R1
R4
R2
S
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
Параметр
Описание
Время реакции в секундах на изменение состояния интерфейса. По умолчанию 2 секунды.
Время реакции в миллисекундах на изменение состояния интерфейса. По
умолчанию 50 миллисекунд.
seconds
msec milliseconds
На рисунке 8.5 приводится пример настройки маршрутизаторов с целью
уменьшения времени обнаружения изменений в топологии сети.
GI 1
R1
r1# interface GigabitEthernet 1
ip hello -interval eigrp 1
ip hold-time eigrp 3
carrier-delay msec 0
GI 0
R2
r2# interface GigabitEthernet 0
ip hello-interval eigrp 1
ip hold -time eigrp 3
carrier -delay msec 0
Рисунок 8.5 – Минимизация времени обнаружения изменений
в топологии мети
159
9 Протоколы маршрутизации по состоянию канала
В отличие от протоколов дистанционно-векторной маршрутизации, в
которых маршрутная информация представляется в форме векторов до сетей
получателей. Протоколы маршрутизации по состоянию канала обладают точным знанием топологии сети передачи данных, исходя из которой, они строят
таблицу маршрутизации.
Чтобы лучше понять различие между дистанционно-векторными алгоритмами Беллмана-Форда, алгоритмом DUAL, и алгоритмами маршрутизации
по состоянию канала, взглянем на рисунки 9.1 – 9.3.
22
25
СП2
СП6
СП5
СП3
10
СП7
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
4
18
R4
R1
16
7
R6
10
СП1
12
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
СП6
СП5
10
R4
8
СП3
СП7
18
R1
4
7
R6
10
R5
СП1
12
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
D
4
4
C
2
7
6
E
4
2
8
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
4
A
A
Найденные
4
С
4
*
E
А
0
Кандидаты
>
C
4
>
E
4
Найденные
4
С
12
E
*
B
0
C
4
Кандидаты
>
Шаг 3
А
E
4
B
12
Шаг 4
4
A
С
12
4
E
?
B
A
Найденные
4
8
?
A
C
F
*
А
0
C
4
E
4
Найденные
4
С
12
E
B
B
12
F
8
F
16
Кандидаты
>
8
*
D
0
C
4
E
4
F
8
Кандидаты
>
Шаг 5
А
B
12
D
16
Шаг 6
4
A
4
А
С
12
?
A
B
?
C
E
15
8
16
D
A
Найденные
4
D
F
*
C
4
E
4
B
D
B
?
B
E
8
F
15
12
16→15
С
12
Кандидаты
>
Найденные
4
0
D
?
E
*
А
0
C
4
E
4
B
12
Кандидаты
?
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
10.95.72.27
10.95.72.29
10.95.120.22
10.95.120.23
10.95.12.10
Pri
1
1
1
1
1
State
2WAY/DROTHER
2WAY/DROTHER
FULL/BDR
FULL/DR
FULL/-
Dead Time
00:00:37
00:00:32
00:00:35
00:00:38
00:00:18
Address
10.93.72.41
10.93.72.42
10.93.72.34
10.93.72.35
10.93.18.10
Interface
Vlan325
Vlan325
Vlan325
Vlan325
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
10.95.56.33
10.95.56.34
10.95.56.58
10.95.56.59
ADV Router
10.95.56.33
10.95.56.34
10.95.56.58
10.95.56.59
Age
60
1837
640
1677
Seq#
0x8000127F
0x8000127D
0x80001284
0x8000127C
Checksum
0x00BE67
0x00DD37
0x00E368
0x00E956
Seq#
0x80000207
0x80000207
0x80000204
0x80000204
Checksum
0x0082D9
0x008E14
0x0080D9
0x008014
Link count
2
2
6
6
Net Link States (Area 0)
Link ID
10.93.254.2
10.93.255.158
10.93.254.2
10.93.255.158
ADV Router
10.95.56.33
10.95.56.33
10.95.56.34
10.95.56.34
Age
1606
1606
1606
1606
Summary Net Link States (Area 0)
Link ID
0.0.0.0
0.0.0.0
ADV Router
10.95.56.33
10.95.56.34
Age
60
1837
Seq#
0x80001278
0x80001278
Checksum
0x00E60B
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 не существует.
Для решения данной проблемы необходимо использовать команду autocost 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
Заголовок пакета OSPF
32 бита
8
8
Версия
Тип
8
8
Длина
Идентификатормаршрутизатора
Идентификаторзоны
Контрольнаясумма
Типаутентификации
Аутентификация
Аутентификация
Данныепротокола
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)
Маскаподсети
Данные пакета OSPF
Hello интервал
Опции
Приоритет
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
O
DC
EA
N/P
MC
E
T
Значение
Зарезервировано. Равно 0.
Опция Opaque-LSA. RFC 2370.
Опция Demand Circuit. RFC 1793.
Опция External Attributes LSA, описана в работе Д. Фергюсона
«Сообщения LSA протокола OSPF с внешними атрибутами» (Ferguson D., «The OSPF External Attribute LSA»). Опция имеет статус
в процессе разработки.
Опция NSSA. RFC 1587.
Опция MOSPF. RFC 1584.
Опция ASBR. Указание на то, что маршрутизатор OSPF является
ASBR маршрутизатором.
Опция ToS. Устаревшее. Равно 0.
10.4.2 Суммарная информация о таблице топологии
На рисунке 10.6 приводится формат пакета суммарной информации о
таблице топологии протокола OSPF.
32 бита
8
8
Заголовок пакета
8
OSPF (Тип = 2)
MTU интерфейса
Данные пакета OSPF
8
Опции
Порядковыйномер
Флаги
пакета
Заголовок 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
MS
Значение
Бит инициализации. Установка бита означает, что передается первый пакет с описанием таблицы топологии.
Установка бита означает, что должны последовать другие пакеты
с описанием таблицы топологии. Если бит M равен 0, то поступил
последний пакет.
Установка бита означает, что маршрутизатор является DR маршрутизатором.
10.4.3 Запрос на получение информации о топологическом элементе
На рисунке 10.8 приводится формат пакета запроса на получение информации о топологическом элементе протокола OSPF.
32 бита
8
8
8
Заголовок пакета
OSPF (Тип = 3)
Идентификатор
LSA
Заявивший маршрутизатор
Идентификатор
LSA
Заявивший маршрутизатор
Запрос LSA N
Тип LSA
Запрос LSA 1
Тип LSA
Данные пакета OSPF
8
Рисунок 10.8 – Формат LSR пакета
179
Пакет запроса на получение информации о топологическом элементе
протокола OSPF включает следующие поля:
– Тип LSA. Тип запрашиваемого LSA.
– Идентификатор LSA. Уникальный идентификатор записи LSA.
– Заявивший маршрутизатор. Уникальный идентификатор маршрутизатора, которым был заявлен LSA.
В пакете LSR может содержаться одна или несколько троек полей описывающих требуемые LSA.
10.4.4 Обновление информации о топологических элементах
32 бита
8
8
8
Данные пакета OSPF
Заголовок пакета
8
OSPF (Тип = 4)
Количество 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
Данные пакета OSPF
Заголовок пакета
8
8
OSPF (Тип = 5)
Заголовок 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
Area :1
Init
D:224 .0.0.5
RID:10.0.0.2
Area :1
Hello
Hello
Таблицасоседства
D:224 .0.0.5
RID:10.0.0.1
Area :1
Nei :10.0.0.2
Two-Way
BDR
D:224 .0.0.5
RID:10.0.0.2
Area :1
Nei :10.0.0.1
Таблицасоседства
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 processid. Параметр 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
wildcard-mask
area-id
Описание
Номер сети участвующей в процессе
маршрутизации OSPF.
Обратная маска подсети для сети
участвующей в процессе маршрутизации OSPF.
Номер зоны OSPF, которой принадлежит описанная сеть.
По значению пары network-number wildcard-mask маршрутизатор определяет, какие сети будут участвовать в процессе маршрутизации OSPF и через какие интерфейсы производить рассылку служебных пакетов. По умолчанию рассылка служебных пакетов производиться со всех интерфейсов, попадающих в network-number wildcard-mask, поэтому не следует забывать о ко-
185
манде passive-interface для контроля интерфейсов, с которых производиться
рассылка служебной информации.
Параметр area-id определяет, к какой зоне будет отнесена описываемая
сеть.
Стоит подчеркнуть, что при использовании на маршрутизаторе
нескольких непрерывных подсетей относящихся к одной зоне протокола
OSPF, в процессе маршрутизации не стоит описывать каждую сеть в отдельности, а можно описать сеть с суммарной wildcard-mask. Для работы процесса
маршрутизации не имеет значения, используются суммарные или частные
wildcard-mask, в независимости от этого, топологическая информация будет
распространяться о частных подсетях. Использование суммарных wildcardmask уменьшает количество строк конфигурации маршрутизатора, тем самым, упрощая процесс ее восприятия администратором сети.
В последних версиях ОС 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
area-id
secondaries none
Описание
Номер локального процесса маршрутизации OSPF.
Номер зоны OSPF, к которой принадлежит описанный на интерфейсе IP адрес.
Запрет на объявление в процесс маршрутизации OSPF вторичный IP адресов
настроенных на интерфейсе.
186
Команда ip ospf area имеет больший приоритет, чем команда network
area. Применение данной команды может быть полезно, если на маршрутизаторе необходимо разрешить процесс маршрутизации OSPF только на одном
интерфейсе, либо в том случае если необходимо что бы выбранный интерфейс принадлежал другой зоне протокола OSPF.
Как говорилось ранее, метрика протокола OSPF напрямую зависит от
ширины полосы пропускания канала связи. Поэтому, особенно на последовательных интерфейсах, необходимо вручную задать пропускную способность
канала. Если значение пропускной способности для таких интерфейсов не менять, протокол OSPF будет считать, что пропускная способность канала равна
T1. Если канал работает медленнее, маршрутизатор будет производить неправильный расчет метрик маршрутов. Для задания справочной скорости на канале связи используется команда bandwidth. Синтаксис команды bandwidth
приводится в примере 11.3.
Пример 11.3 – Синтаксис команды bandwidth
(config-if)# bandwidth kbps
Значение kbps определяет задаваемую пропускную способность в килобитах в секунду. Для топологий типа «Точка-Точка», таких как РРР или
HDLC, пропускная способность устанавливается равной скорости линии. Для
интерфейсов типа «Точка-Точка» Frame Relay пропускная способность устанавливается равной согласованной скорости передачи информации (Committed 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#
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
log-adjacency-change
r3#
interface Serial 1
ip address 10.1.1.6 255.255.255.252
ip ospf 1 area 0
E1 10.1.1.0/30
10.1.1.4/30
S1
RIP
R2
E0
R1
S0
R3
r1#
router ospf 1
network 10.1.1.0 0.0.0.7 area 0
log-adjacency-change
Рисунок 11.1 – Пример настройки протокола OSPF
11.2 Управление значением идентификатора маршрутизатора OSPF
Для процесса маршрутизации OSPF идентификатор маршрутизатора
(RID) является очень важным параметром. Идентификатор маршрутизатора
применяется в алгоритмах работы протокола OSPF для однозначной идентификации маршрутизатора.
Идентификатор маршрутизатору назначается при запуске процесса
OSPF. Идентификатором маршрутизатора может быть назначен:
– Старший IP адрес любого физического интерфейса маршрутизатора.
Интерфейс может не использоваться в процессе OSPF маршрутизации, но он
должен находиться в активном состоянии. Поэтому на маршрутизаторе при
запуске процесса OSPF должен быть активен хотя бы один интерфейс, иначе
маршрутизатор выдаст ошибку, представленную в примере 11.6 и процесс не
будет запущен.
– Старший IP адрес логического интерфейса loopback. Логические интерфейсы всегда находиться в активном состоянии, поэтому использование
логического интерфейса является наиболее предпочтительным.
– Вручную. Для ручного задания RID используется команда router-id.
188
Самым высоким приоритетом при назначении идентификатора обладает ручная настройка, самым низким старший адрес физического интерфейса.
Синтаксис команды router-id приводится в примере 11.5
Пример 11.5 – Синтаксис команды router-id
(config-router)# router-id ip-address
(config-router)# no router-id ip-address
В качестве параметра команды router-id может выступать IP адрес либо
число, записанное в формате IP адреса.
Однажды заданный идентификатор активен все время работы процесса
маршрутизации OSPF. Если во время работы маршрутизатора интерфейс, адрес которого используется в качестве RID, переходит в неактивное состояние,
идентификатор маршрутизатора не изменяется. Однако при использовании
адресов физических интерфейсов в качестве идентификатора маршрутизатора
нельзя гарантировать, что после перезагрузки маршрутизатора будет назначен тот же идентификатор, что был ранее. Идентификатор маршрутизатора
также переназначается при перезапуске процесса маршрутизации OSPF.
Исходя из этого использование логических интерфейсов предпочтительнее, во-первых, логический интерфейс всегда активен, во-вторых, он может быть объявлен в процесс маршрутизации, что позволит использовать ping
с других маршрутизаторов, чтобы проверять наличие связи между маршрутизаторами.
При назначении RID, используя команду router-id, на идентификатор
нельзя будет послать ping.
Еще одним плюсом использования реальных IP адресов, будь то адреса
физических или логических интерфейсов является возможность применения
команды ip ospf name-lookup. Данная команда вводится в режиме глобальной
конфигурации маршрутизатора и позволяет при выводе информации содержащей RID заменять его числовое значение DNS именем. Это позволяет
упростить администратору СПД идентифицировать маршрутизаторы OSPF.
При первоначальной конфигурации идентификатора маршрутизатора с
помощью команды router-id необходимо перезапустить процесс маршрутизации OSPF, используя команду clear ip ospf process. В дальнейшем при перезагрузках маршрутизатора идентификатор, заданный командой router-id будет
назначаться автоматически.
Стоит обратить внимание, что если во время запуска процесса OSPF
операционная система не сможет назначить маршрутизатору RID. Например,
по причине того, что в этот момент у маршрутизатора не будет ни одного активного интерфейса, и в конфигурационном файле будет отсутствовать вручную заданный идентификатор. Процесс маршрутизации OSPF запущен не будет, а операционная система выдаст сообщение об ошибке представленное в
примере 11.6.
189
Пример 11.6 – Ошибка назначения RID
%OSPF-4-NORTRID: OSPF process [dec] cannot start. There must be at least one
"up" IP interface, for OSPF to use as router ID
11.3 Настройка аутентификации в протоколе OSPF
В отличие от рассмотренных ранее протоколов маршрутизации, в которых аутентифицируется только часть служебных пакетов, в протоколе OSPF
поле аутентификации вынесено в заголовок служебного пакета, что делает
возможным аутентифицировать каждый служебный пакет протокола OSPF.
Данная возможность делает протокол OSPF более защищенным от нежелательного воздействия по сравнению с рассмотренными ранее протоколами
маршрутизации.
Как и другие протоколы маршрутизации, протокол OSPF поддерживает
два типа аутентификации:
– Аутентификация по паролю;
– Аутентификация при помощи MD5.
Оба типа аутентификации настраиваются отдельно на каждом интерфейсе маршрутизатора, на котором запущен протокол OSPF.
Для задания типа аутентификации используется команда ip ospf authentication. Синтаксис команды 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
null
Описание
Аутентификация с помощью MD5.
Отсутствие аутентификации.
При использовании команды 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
R1
S0
r1#
interface serial 0
ip address 172.16.1.1 255 .255.255.252
ip ospf authentication
ip ospf authentication -key PassWord
S1
R2
r2#
interface serial 1
ip address 172.16.1.2 255.255.255.252
ip ospf authentication
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
key
Описание
Номер используемого ключа.
Тип вводимой строки:
0 нешифрованная строка;
7 шифрованная средствами IOS строка.
Строка для аутентификации.
При использовании аутентификации с помощью MD5, на интерфейсе
можно задать несколько строк, которые могут применяться при аутентификации соседних маршрутизаторов. Эта особенность удобна при необходимости
191
осуществления перехода с одного используемого ключа на другой без разрыва соединения между маршрутизаторами. В других случаях использование
нескольких строк аутентификации не рекомендуется.
Пример настройки аутентификации с помощью MD5 приводиться на
рисунке 11.3.
172 .10.1.0/30
R1
S0
S1
r1#
interface serial 0
ip address 172.16.1.1 255 .255.255.252
ip ospf authentication message -digest
ip ospf message-digest-key 1 md5 SeCrEt
R2
r2#
interface serial 1
ip address 172.16.1.2 255.255.255.252
ip ospf authentication message -digest
ip ospf message-digest-key 1 md5 SeCrEt
Рисунок 11.3 – Аутентификация с помощью MD5 в протоколе OSPF
11.3.1 Проверка функционирования аутентификации
На рисунке 11.4 приводятся сообщения об обнаруженных проблемах в
аутентификации по паролю.
r1#
interface ethernet 0
ip address 10.1.1.1 255.255.255.252
ip ospf authentication
ip ospf authentication -key PassWord
!
interface serial 0
ip address 10.1.1.5 255.255.255.252
ip ospf authentication
ip ospf authentication -key PassWord
r2#
interface ethernet 1
ip address 10.1.1.2 255.255.255.252
ip ospf authentication
ip ospf authentication-key password
r3#
interface Serial 1
ip address 10.1.1.6 255.255.255.252
E1 10.1.1.0/30
R2
10.1.1.4/30
E0
r2#
*Mar 2 08:13:15.562: OSPF: Rcv pkt from 10.1.1.1,
Ethernet 1 : Mismatch Authentication Key - Clear Text
R1
S0
S1
R3
r3#
*Mar 2 08:14:12.450: OSPF: Rcv pkt from 10.1.1.5,
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#
interface serial 0
ip address 172.16.1.1 255 .255.255.252
ip ospf authentication message -digest
ip ospf message-digest-key 1 md5 SeCrEt
r2#
interface serial 1
ip address 172.16.1.2 255.255.255.252
ip ospf authentication message -digest
ip ospf message-digest-key 0 md5 SeCrEt
172 .10.1.0/30
R1
S0
S1
R2
r1#
*Mar 2 08:12:44.372: OSPF: Send with youngest Key 1
r2#
*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,
Serial 0: Mismatch Authentication Key - No message
digest key 0 on interface
*Mar 2 08:19:52.460: OSPF: Rcv pkt from 172.16.1.1,
Serial 1: Mismatch Authentication Key - No message
digest key 1 on interface
Рисунок 11.5 – Сообщения об ошибках аутентификации с помощью MD5
11.4 Настройка маршрута по умолчанию в протоколе OSPF
Протокол OSPF поддерживает возможность распространения маршрута
по умолчанию с главного маршрутизатора сети. Для включения механизма
рассылки маршрута по умолчанию на главном маршрутизаторе в сети необходимо указать команду default-information originate. Синтаксис команды default-information originate приводится в примере 11.10.
Пример 11.10 – Синтаксис команды default-information originate
(config-router)# default-information originate [always] [metric metric-value]
[metric-type type-value] [route-map map-name]
(config-router)# no default-information originate
Описание параметров команды default-information originate приводиться
в таблице 11.5.
193
Таблица 11.5 – Параметры команды default-information originate
Параметр
Описание
Всегда распространять маршрут по
умолчанию, в независимости от алгоритмов автоматического назначения
маршрутов по умолчанию в протоколе
OSPF.
Метрика маршрута.
Значение по умолчанию 10.
Тип внешнего маршрута:
1 – 1 тип внешнего маршрута;
2 – 2 тип внешнего маршрута.
Значение по умолчанию 2.
Указание процессу маршрутизации
распространять маршрут по умолчанию в том случае если выполняется
условие route-map.
always
metric metric-value
metric-type type-value
route-map map-name
Пример настройки маршрута по умолчанию в протоколе OSPF приводится на рисунке 11.6
172 .16.14.0/27
R2
S0
172 .16.14.32/27
172 .16.14.64/27
R3
R4
WAN
R1
router ospf 1
network 172.16.0.0 0.0.255.255 area 0
default-information originate always
ip route 0.0.0.0 0.0.0.0 serial 0
Рисунок 11.6 – Настройка маршрута по умолчанию в протоколе OSPF
11.5 Распределение нагрузки в протоколе OSPF
Как и другие протоколы динамической маршрутизации, протокол OSPF
способен использовать механизм распределения нагрузки по 16 маршрутам с
равной стоимостью. По умолчанию количество маршрутов, по которым может производиться распределение нагрузки, равняется четырем.
194
В отличие от протокола EIGRP протокол OSPF не имеет возможности
производить распределение нагрузки по маршрутам с разной стоимостью.
11.6 Расширенная настройка протокола OSPF
11.6.1 Таймеры протокола OSPF
Протокол OSPF, как и протокол EIGRP не использует периодическую
рассылку маршрутной информации соседним маршрутизаторам. Однако для
поддержания соседских отношений между маршрутизаторами необходимо
периодически передавать Hello пакеты. При получении от соседа Hello пакета
маршрутизатор понимает, что сосед продолжает функционировать.
Исходя из этого, в протоколе OSPF существует два основных таймера:
– таймер рассылки Hello пакетов;
– таймер поддержания соседских отношений.
По умолчанию таймер рассылки Hello пакетов равняется 30 секундам
для сетей NBMA. Для всех остальных типов сетей интервал рассылки Hello
пакетов равен 10 секундам.
Время поддержания соседских отношений должно равняться не менее
четырем интервалам рассылки Hello пакетов, следовательно, для сетей NBMA
данный интервал равняется 120 секундам, а для всех остальных каналов связи
40 секундам.
При необходимости стандартные значения таймеров можно изменить,
используя команды ip ospf hello-interval и ip ospf dead-interval. Синтаксис команд приводится в примерах 11.11 и 11.12.
Пример 11.11 – Синтаксис команды ip ospf hello-interval
(config-if)# ip ospf hello-interval seconds
(config-if)# no ip ospf hello-interval
Пример 11.12 – Синтаксис команды ip ospf dead-interval
(config-if)# ip ospf dead-interval seconds
(config-if)# no ospf dead-interval
Следует помнить, что при изменении стандартных таймеров, для корректной работы протокола OSPF необходимо соблюдать соотношение таймеров рассылки Hello пакетов и поддержания соседских отношений.
Еще одним важным таймером протокола OSPF является таймер повторной передачи записей LSA, получение которых не было подтверждено. По
умолчанию таймер повторной передачи записей LSA равняется 5 секундам.
При необходимости стандартное значение таймера можно изменить, исполь-
195
зуя команду ip ospf retransmit-interval. Синтаксис команды приводится в примере 11.13.
Пример 11.13 – Синтаксис команды ip ospf retransmit-interval
(config-if)# ip ospf retransmit-interval seconds
(config-if)# no ospf retransmit-interval
Изменение данного параметра может понадобиться на высокоскоростных каналах связи для улучшения временных характеристик сходимости сети
или на низкоскоростных каналах связи, где задержка при получении пакетов
LSAck может превышать значение по умолчанию.
Как известно максимальный возраст экземпляра сообщения LSA составляет 30 минут. По истечении этого времени маршрутизатор объявивший,
данное сообщение LSA, должен разослать обновленный экземпляр сообщения. Для корректной работы протокола OSPF необходимо, что бы учитывалось не только время нахождения сообщения LSA в таблице топологии, но и
время, затраченное на его передачу по каналам связи. Для этого в протокол
OSPF был внесен временной параметр, задающий время передачи сообщения
LSA по каналу связи. По умолчанию данный параметр равен 1 секунде. При
необходимости стандартное значение параметра можно изменить, используя
команду ip ospf transmit-delay. Синтаксис команды приводится в примере
11.14.
Пример 11.14 – Синтаксис команды ip ospf transmit-delay
(config-if)# ip ospf transmit-delay seconds
(config-if)# no ospf transmit-delay
11.6.2 Изменение административного расстояния протокола OSPF
По умолчанию административное расстояние протокола OSPF равняется 110.
В некоторых ситуациях, например во время перехода с некоторого протокола маршрутизации на протокол OSPF требуется на время подготовки данного перехода изменить административное расстояние протокола OSPF с целью сделать его менее предпочтительным, чем старый протокол маршрутизации. Для этого используется команда distance ospf. Синтаксис команды приводится в примере 11.15.
Пример 11.15 – Синтаксис команды distance ospf
(config-router)# distance ospf {[intra-area dist1] [inter-area dist2] [external dist3]}
(config-router)# no distance ospf
196
Описание параметров команды distance ospf приводиться в таблице
11.6.
Таблица 11.6 – Параметры команды distance ospf
Параметр
intra-area dist1
inter-area dist2
external dist3
Описание
Административное расстояние внутризональных маршрутов OSPF. По умолчанию 110.
Административное расстояние межзональных маршрутов OSPF. По умолчанию 110.
Административное расстояние внешних маршрутов OSPF. Под внешними
маршрутами понимаются маршруты,
полученные от других протоколов
маршрутизации.
По умолчанию 110.
11.7 Тестирование и устранение ошибок в работе протокола OSPF
Для проверки правильности созданной конфигурации протокола OSPF
могут быть использованы несколько команд. Наиболее часто используемыми
командами общего назначения являются show ip route и show ip protocols.
Команда show ip route или команда show ip route ospf отображает таблицу маршрутизации построенную маршрутизатором. Вторая команда отображает только маршруты из таблицы маршрутизации полученные от протокола
OSPF, такие маршруты помечаются буквой «O» (Пример 11.16).
Пример 11.16 – Таблица маршрутизации протокола OSPF
r3#show ip route ospf
10.0.0.0/8 is variably subnetted, 32 subnets, 3 masks
O
10.89.2.81/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O
10.89.1.81/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O
10.89.2.65/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O
10.89.1.65/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O
10.89.2.113/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O
10.89.1.113/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O
10.89.2.97/32 [110/196] via 10.93.2.18, 00:00:40, Serial2
O
10.89.1.97/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
O
10.89.2.17/32 [110/196] via 10.93.2.2, 00:00:40, Serial1
O
10.89.1.17/32 [110/586] via 10.93.0.17, 00:00:40, Serial0
197
При вводе команды show ip protocols отображается информация обо
всех протоколах IP маршрутизации, в том числе и о протоколе OSPF, сконфигурированных на маршрутизаторе (Пример 11.17).
Пример 11.17 – Информация, выводимая командой show ip protocols
r3#show ip protocols
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 10.95.0.49
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.0.0.0 0.255.255.255 area 0
Routing Information Sources:
Gateway
Distance
Last Update
10.95.0.1
110
00:00:20
10.95.0.49
110
00:00:20
10.95.0.61
110
00:00:20
10.95.0.57
110
00:00:20
10.95.0.33
110
00:00:20
10.95.0.45
110
00:00:20
10.95.0.41
110
00:00:20
Distance: (default is 110)
Полученные сведения могут быть использованы для тестирования
большинства параметров протокола OSPF. Ниже перечислены островные
отображаемые в выводе команды параметры конфигурации:
– Номер локального процесса маршрутизации OSPF;
– Идентификатор маршрутизатора;
– Число и виды зон OSPF, которым принадлежит маршрутизатор;
– Номера сетей и их принадлежность зонам анонсированных протоколом OSPF;
– С какими маршрутизаторами установлены соседские отношения;
– Административное расстояние, назначенное протоколу OSPF.
Кроме команд применимых ко всем протоколам маршрутизации существует ряд специальных команд, отображающих информацию протокола
OSPF. К такой информации относятся таблицы соседства и топологии, статистическая информация о переданных и полученных служебных пакетах, информация о работе интерфейсов маршрутизатора по обработке служебных пакетов.
Для вывода таблицы соседства применяется команда show ip ospf neighbors, синтаксис команды приводится в примере 11.18.
Пример 11.18 – Синтаксис команды show ip ospf neighbors
show ip ospf neighbors [interface][neighbor-id][detail]
198
Описание параметров команды приводиться в таблице 11.7.
Таблица 11.7 – Параметры команды show ip ospf neighbors
Параметр
interface
neighbor-id
detail
Описание
Вывод информации о соседях расположенных за интерфейсом
Вывод информации о соседе с указанным идентификатором
Вывод расширенной информации о соседях
Информация, выводимая командой show ip ospf neighbors, а так же ее
описание приводилось в примере 10.1.
Наиболее интересной является информация, выводимая командой show
ip ospf neighbors detail, которая содержит полную информацию о соседях
OSPF (Пример 11.19).
Пример 11.19 – Полная информация о соседях OSPF
r4#show ip ospf neighbor detail
Neighbor 10.95.0.33, interface address 10.93.1.1
In the area 0 via interface Serial0
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x42
Dead timer due in 00:00:38
Neighbor is up for 00:04:51
Index 1/1, retransmission queue length 0, number of retransmission 1
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 1, maximum is 1
Last retransmission scan time is 0 msec, maximum is 0 msec
Neighbor 10.95.0.45, interface address 10.93.1.34
In the area 0 via interface FastEthernet0
Neighbor priority is 1, State is FULL, 6 state changes
DR is 10.93.1.34 BDR is 10.93.1.33
Options is 0x42
Dead timer due in 00:00:37
Neighbor is up for 00:04:42
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Ниже перечислены островные отображаемые в выводе команды параметры соседских отношений между маршрутизаторами:
– Идентификатор соседа;
– Локальный интерфейс, через который доступен сосед;
– Номер зоны, которой принадлежит сосед;
– Приоритет соседа;
199
– Состояние соседских отношений и сколько раз они изменялись;
– Адреса DR и BDR маршрутизаторов;
– Опции, поддерживаемые соседом (только E);
– Время, оставшееся до разрыва соседских отношений;
– Время поддержания соседских отношений.
Для вывода таблицы топологии применяется команда show ip ospf database, синтаксис команды приводится в примере 11.20.
Пример 11.20 – Синтаксис команды show ip ospf database
show ip ospf [process-id area-id]
show ip ospf [process-id area-id]
show ip ospf [process-id area-id]
show ip ospf [process-id area-id]
show ip ospf [process-id area-id]
show ip ospf [process-id area-id]
router [ip-address]]
show ip ospf [process-id area-id]
originate][link-state-id]
database
database
database
database
database
database
[adv-router [ip-address]]
[database-summary]
[self-originate][link-state-id]
[LSA-type] [link-state-id]
[LSA-type] [link-state-id] [adv-
database [LSA-type] [link-state-id] [self-
Таблица топологии для протокола OSPF является главным источником
информации, по которой маршрутизатор имеет возможность построить таблицу маршрутизации. Вывод полной таблицы топологии представляет очень
большой объем информации, поэтому команда show ip ospf database имеет
возможность выводить частичную информацию необходимую администратору СПД. Описание параметров команды приводиться в таблице 11.8.
Таблица 11.8 – Параметры команды show ip ospf database
Параметр
process-id
area-id
adv-router ip-address
database-summary
LSA-type
link-state-id
self-originate
Описание
Вывод таблицы топологии процесса
маршрутизации OSPF.
Вывод таблицы топологии зоны OSPF.
Вывод LSA, заявленных указанным
маршрутизатором.
Вывод суммарной топологической информации.
Вывод таблицы топологии по их типу:
External – внешние LSA;
Network – LSA сети;
nssa-external – внешние LSA NSSA;
router – LSA маршрутизаторов;
summary – суммарные LSA.
Вывод информации о указанном LSA.
Вывод собственных LSA.
200
Информация, выводимая командой show ip ospf database, а так же ее
описание приводилось в примере 10.2.
Информацию о параметрах работы протокола OSPF на маршрутизаторе
можно получить, воспользовавшись командой show ip ospf.
Статистическую информацию о количестве переданных и полученных
служебных пакетов можно посмотреть, используя команду show ip ospf traffic.
Синтаксис команды приводится в примере 11.21.
Пример 11.21 – Синтаксис команды show ip ospf traffic
show ip ospf [process-id] traffic [interface]
Информация, выводимая данной командой, содержит количество отправленных и полученных служебных пакетов OSPF за время работы процесса маршрутизации или за время прошедшее поле применения команды clear
ip ospf traffic (Пример 11.22).
Пример 11.22 – Информация, выводимая командой show ip ospf traffic
r1#show ip ospf traffic
OSPF statistics:
Rcvd: 159054687 total, 0 checksum errors
158930565 hello, 40 database desc, 10 link state req
64212 link state updates, 59860 link state acks
Sent: 159273144 total
159140414 hello, 37 database desc, 11 link state req
92630 link state updates, 40052 link state acks
OSPF Router with ID (10.95.184.58) (Process ID 88)
OSPF queues statistic for process ID 88:
Hello queue size 0, no limit, drops 0, max size 4, max delay 235ms
Router queue size 0, limit 200, drops 0, max size 2, max delay 235ms
Output queue size 0, no limit, max size 3, max delay 25ms
Interface statistics:
Interface FastEthernet0/1
OSPF packets received/sent
Invalid Hellos
DB-des
Rx: 0
39790618 6
Tx: 0
39785151 8
LS-req
2
2
LS-upd
15650
34989
LS-ack
16959
11878
Total
39823235
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
Rcvd: 79538526 total, 0 errors
79466889 hello, 18 database desc,
37831 link state upds, 33783 link
Sent: 79650010 total
79570321 hello, 17 database desc,
55767 link state upds, 23900 link
88:
5 link state req
state acks, 0 invalid
5 link state req
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 [neighborinterface][neighbor-id]] | traffic [interface-type interface-number]}
Описание параметров команды clear ip ospf приводиться в таблице 11.9.
Таблица 11.9 – Параметры команды clear ip ospf
Параметр
pid
process
redistribution
counters
neighbor
neighbor-interface
Описание
Номер процесса маршрутизации, для
которого будут производиться действия.
Перезапуск процесса OSPF.
Очистка перераспределения производимого процессом маршрутизации
OSPF.
Очистка счетчиков протокола OSPF.
Отчистка статистики о соседях.
Отчистка статистики о соседях за интерфейсом.
203
Продолжение таблицы 11.9
Параметр
neighbor-id
traffic
interface-type interface-number
Описание
Отчистка статистики о соседе.
Отчистка статистики служебного трафика протокола OSPF.
Отчистка статистики служебного трафика прошедшему через выбранный
интерфейс.
В набор инструментов для отладки работы протокола OSPF запущенного на маршрутизаторе также входит ряд команд debug.
Для вывода информации о событиях в работе протокола OSPF, таких
как получение и отправка Hello пакетов, обмен топологической информацией,
запуск алгоритма SPF и других служебных событий используется команда debug ip ospf events. Информация, выводимая данной командой, представлена в
примере 11.26.
Пример 11.26 – Информация, выводимая командой debug ip ospf events
r2#debug ip ospf events
*Jun 10 15:15:47.831 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on FastEthernet0/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 FastEthernet0/0.301 172.16.0.34
*Jun 10 15:15:49.923 KRSK: OSPF: End of hello processing
*Jun 10 15:15:57.831 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/1
from 10.93.1.1
*Jun 10 15:15:59.591 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/0
from 172.16.0.2
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv hello from 1.1.1.1 area 1 from
Serial0/0/0 172.16.0.1
*Jun 10 15:15:59.595 KRSK: OSPF: Send immediate hello to nbr 1.1.1.1, src address 172.16.0.1, on Serial0/0/0
*Jun 10 15:15:59.595 KRSK: OSPF: Send hello to 224.0.0.5 area 1 on Serial0/0/0
from 172.16.0.2
*Jun 10 15:15:59.595 KRSK: OSPF: End of hello processing
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv hello from 1.1.1.1 area 1 from
Serial0/0/0 172.16.0.1
*Jun 10 15:15:59.595 KRSK: OSPF: 2 Way Communication to 1.1.1.1 on
Serial0/0/0, state 2WAY
*Jun 10 15:15:59.595 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x183
opt 0x52 flag 0x7 len 32
*Jun 10 15:15:59.595 KRSK: OSPF: End of hello processing
*Jun 10 15:15:59.595 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x966
opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
*Jun 10 15:15:59.599 KRSK: OSPF: First DBD and we are not SLAVE
*Jun 10 15:15:59.599 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x183
opt 0x52 flag 0x2 len 232 mtu 1500 state EXSTART
*Jun 10 15:15:59.599 KRSK: OSPF: NBR Negotiation Done. We are the MASTER
204
*Jun 10 15:15:59.599 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x184
opt 0x52 flag 0x3 len 232
*Jun 10 15:15:59.603 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x184
opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*Jun 10 15:15:59.603 KRSK: OSPF: Send DBD to 1.1.1.1 on Serial0/0/0 seq 0x185
opt 0x52 flag 0x1 len 32
*Jun 10 15:15:59.607 KRSK: OSPF: Rcv DBD from 1.1.1.1 on Serial0/0/0 seq 0x185
opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
*Jun 10 15:15:59.607 KRSK: OSPF: Exchange Done with 1.1.1.1 on Serial0/0/0
*Jun 10 15:15:59.607 KRSK: OSPF: Synchronized with 1.1.1.1 on Serial0/0/0,
state FULL
*Jun 10 15:15:59.607 KRSK: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on
Serial0/0/0 from LOADING to FULL, Loading Done
*Jun 10 15:15:59.923 KRSK: OSPF: Rcv hello from 3.3.3.3 area 1 from FastEthernet0/0.301 172.16.0.34
*Jun 10 15:15:59.923 KRSK: OSPF: End of hello processing
*Jun 10 15:16:00.091 KRSK: OSPF: Rcv LS UPD from 1.1.1.1 on Serial0/0/0 length
124 LSA count 1
*Jun 10 15:16:00.095 KRSK: OSPF: Rcv LS UPD from 3.3.3.3 on
FastEthernet0/0.301 length 124 LSA count 1
Для просмотра событий связанных с установкой и поддержанием соседских отношений используется команда debug ip ospf adj. Информация, выводимая командой, представлена в примере 11.27.
Пример 11.27 – Информация, выводимая командой debug ip ospf adj
r2#debug ip ospf adj
01:01:23: OSPF: Interface Serial0 going Up
01:01:23: OSPF: Build router LSA for area 0, router ID 10.95.0.33, seq
0x80000005
01:01:24: %LINEPROTO–5–UPDOWN: Line protocol on Interface Serial0, changed
state to up
01:01:33: OSPF: 2 Way Communication to 10.95.0.1 on Serial0, state 2WAY
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15DE opt 0x42 flag 0x7
len 32
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x1A29 opt 0x52 flag 0x7
len 32 mtu 1500 state EXSTART
01:01:33: OSPF: First DBD and we are not SLAVE
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15DE opt 0x52 flag 0x2
len 212 mtu 1500 state EXSTART
01:01:33: OSPF: NBR Negotiation Done. We are the MASTER
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15DF opt 0x42 flag 0x3
len 212
01:01:33: OSPF: Database request to 10.95.0.1
01:01:33: OSPF: sent LS REQ packet to 172.16.0.1, length 12
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15DF opt 0x52 flag 0x0
len 32 mtu 1500 state EXCHANGE
01:01:33: OSPF: Send DBD to 10.95.0.1 on Serial0 seq 0x15E0 opt 0x42 flag 0x1
len 32
01:01:33: OSPF: Rcv DBD from 10.95.0.1 on Serial0 seq 0x15E0 opt 0x52 flag 0x0
len 32 mtu 1500 state EXCHANGE
01:01:33: OSPF: Exchange Done with 10.95.0.1 on Serial0
01:01:33: OSPF: Synchronized with 10.95.0.1 on Serial0, state FULL
01:01:33: %OSPF–5–ADJCHG: Process 1, Nbr 10.95.0.1 on Serial0 from LOADING to
FULL, Loading Done
205
Для вывода информации о приеме или передачи служебных пакетов
OSPF используется команда debug ip ospf packet. Данная команда отображает
краткую информацию о приеме или получении служебного пакета протокола
OSPF. Информация, выводимая командой, представлена в примере 11.28.
Пример 11.28 – Информация, выводимая командой debug ip ospf packet
r2#debug ip ospf packet
01:19:49: OSPF: rcv. v:2 t:1 l:48 rid:10.95.0.45
aid:0.0.0.0 chk:CF99 aut:0 auk: from FastEthernet0
01:19:50: OSPF: rcv. v:2 t:1 l:48 rid:10.95.0.33
aid:0.0.0.0 chk:E6A2 aut:0 auk: from Serial0
Описание информации, выводимой командой debug ip ospf packet, приводится в таблице 11.10.
Таблица 11.10 – Описание информации выводимой командой debug ip
ospf packet
Информация
v:
t:
l:
rid:
aid:
chk:
aut:
auk:
keyid:
seq:
Описание
Версия пакета.
Тип пакета.
Длина пакета.
Идентификатор отправителя.
Идентификатор зоны.
Контрольная сумма.
Тип аутентификации.
Ключ аутентификации.
Идентификатор ключа MD5.
Последовательный номер.
Последней широко используемой командой для отладки работы протокола OSPF, является команда debug ip ospf spf statistic. Команда выводит статистическую информацию, работы алгоритма SPF (Пример 11.29).
Пример 11.29 – Информация, выводимая командой debug ip ospf spf statistic
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
process time
spf_time
wait_interval
End SPF at
Total elapsed time
Intra
Inter
External
R
N
Stub
SN
SA
X5
X7
SPF suspends intra
total
Описание
Абсолютное время запуска SPF.
Среднее время работы процесса SPF.
Время, прошедшее с предыдущего
запуска SPF.
Время ожидания перед началом расчета SPF.
Абсолютное время остановки SPF.
Время, потребовавшееся для запуска
SPF.
Время, затраченное на расчет внутризональных LSA.
Время, затраченное на расчет межзональных LSA.
Время, затраченное на расчет внешних
LSA.
Число LSA – маршрутизаторы.
Число LSA – сети.
Число LSA – тупиковые связи.
Число LSA – суммарные.
Число LSA – на внешние AS.
Число LSA – тип 5.
Число LSA – тип 7.
Число «зависаний» процесса SPF во
время внутризональных запусков.
Общее число «зависаний» процесса
SPF.
207
12 Работа протокола OSPF в сетях различных типов
Алгоритмы функционирования протокола OSPF во многом зависят от
типа сети передачи данных, в которой он запущен. Для протокола OSPF выделяют три основных типа сети:
– Сеть «Точка-Точка»;
– Широковещательная сеть;
– Сеть NBMA.
12.1 Работа протокола OSPF в сетях «Точка-Точка»
Сеть «Точка-Точка» состоит из единственной пары маршрутизаторов. В
качестве примера сетей «Точка-Точка» можно привести выделенные каналы
связи с настроенными протоколами транспортного уровня PPP или HDLC
(Рисунок 12.1).
R1
R2
R3
Рисунок 12.1 – Пример сети «Точка-Точка» в протоколе OSPF
С точки зрения протокола OSPF сети «Точка-Точка» являются самыми
простыми для их представления в общей топологии сети передачи данных. В
таких сетях маршрутизаторы автоматически определяют своего соседа, используя групповую рассылку Hello пакетов по адресу 224.0.0.5. Каждая пара
маршрутизаторов имеет непосредственное соединение между собой, поэтому
нет необходимости проводить выборы DR и BDR маршрутизаторов.
В качестве IP адреса источника в пакет OSPF записывается IP адрес выходного интерфейса маршрутизатора. Возможно, использование ненумерованных интерфейсов при этом в качестве IP адреса источника будет выступать адрес интерфейса маршрутизатора, который был указан в команде ip unnumbered interface.
По умолчанию в протоколе OSPF для сетей «Точка-Точка» устанавливаются Hello и Dead интервалы равные 10 и 40 секунд соответственно.
208
12.2 Работа протокола OSPF в широковещательных сетях
Для широковещательных сетей типа Ethernet или Token Ring протокол
OSPF модифицирует алгоритм обмена служебными пакетами между маршрутизаторами с целью его уменьшения. В отличие от протоколов RIP или EIGRP, в которых каждая пара маршрутизаторов устанавливает и поддерживает
между собой соседские отношения в независимости от типа сети, в протоколе
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
RID = 1
Pri = 5
RID = 5
DR
BDR
Hello
R3
R4
R5
Pri = 5
RID = 2
Pri = 1
RID = 3
Pri = 0
RID = 4
Рисунок 12.3 – Процесс выбора DR и BDR маршрутизаторов
Выборы DR и BDR маршрутизаторов производятся в момент первоначальной установки соседских отношений по следующим правилам:
– Маршрутизатор с наибольшим приоритетом выбирается DR маршрутизатором;
– Маршрутизатор со вторым по величине приоритетом назначается
BDR маршрутизатором;
– Если маршрутизаторы имеют равный приоритет, то в качестве DR
маршрутизатора выбирается маршрутизатор с наибольшим RID, BDR маршрутизатором выбирается маршрутизатор со вторым по величине RID;
– Маршрутизатор, с приоритетом равным нулю, не принимает участия в
выборах DR и BDR маршрутизаторов;
– Если после выбора DR и BDR маршрутизаторов в сегмент сети добавляется маршрутизатор с более высоким приоритетом или большим RID, то
повторные выборы не производятся;
210
– Повторные выборы производятся только после того как DR или BDR
маршрутизаторы становится недоступными.
Для обнаружения того, что DR маршрутизатор становится недоступным, BDR маршрутизатор использует таймер ожидания. Если за время истечения таймера BDR маршрутизатор не получил Hello пакет от DR маршрутизатора, BDR маршрутизатор считает, что DR маршрутизатор стал недоступным и занимает его место. После этого в сегменте сети проводятся повторные
выборы BDR маршрутизатора.
Если маршрутизатор имеет два интерфейса подключенных к разным
сегментам сети, он может быть DR или BDR маршрутизатором в одном сегменте и простым маршрутизатором в другом. Для ручной настройки приоритетов маршрутизаторов используется команда ip ospf priority. Синтаксис команды приводится в примере 12.1.
Пример 12.1 – Синтаксис команды ip ospf priority
(config-if)# ip ospf priority [number]
(config-if)# no ip ospf priority [number]
Значение number задает приоритет маршрутизатора в приделах от 0 до
255, по умолчанию приоритет задается равным 1. По умолчанию в протоколе
OSPF для широковещательных сетей устанавливаются Hello и Dead интервалы равные 10 и 40 секунд соответственно.
12.3 Работа протокола OSPF в сетях NBMA
Существуют технологии построения сетей, поддерживающие множественный доступ, но в которых не применяются широковещательные пакеты.
К таким технологиям относятся сети Frame Relay, ATM и X25. Данные сети
получили название NBMA (non broadcast multi-access) (Рисунок 12.4).
Frame Relay
ATM
X.25
Рисунок 12.4 – Пример сети NBMA в протоколе OSPF
211
В сетях NBMA может быть больше двух маршрутизаторов подключенных к одному логическому сегменту сети, но из-за отсутствия возможности
использования групповых пакетов в таких сетях маршрутизаторы не могут
проводить автоматический поиск соседей и установку с ними соседских отношений.
В сетях NBMA для имитации групповой рассылки пакет копируется и
посылается индивидуально по каждому виртуальному каналу (VC). Такой механизм сильно повышает загрузку маршрутизатора и каналов передачи данных.
По умолчанию в протоколе OSPF для сетей NBMA установлены Hello и
Dead интервалы равные соответственно 30 и 120 секунд.
Сети NBMA в большинстве случаев используют логическую топологию
«звезда», построенную при помощи постоянных (PVC) или коммутируемых
(SVC) виртуальных каналов, но физическая топология сети не поддерживает
групповую рассылку пакетов, которая используется протоколом OSPF, поэтому OSPF не может автоматически устанавливать соседские отношения между
маршрутизаторами в сетях NBMA.
Выбор DR и BDR маршрутизаторов в сетях NBMA невозможен, потому
что для проведения выборов DR и BDR маршрутизаторов все маршрутизаторы принадлежащие сегменту сети должны иметь логическое соединение.
12.4 Режимы работы протокола OSPF в сетях NBMA
В RFC2328 описываются два основных режима функционирования протокола OSPF в сетях NBMA:
– Нешироковещательный (Non broadcast). Режим эмулирует работу протокола OSPF для широковещательных сетей. Для данного режима работы
должны быть вручную настроены отношения соседства между маршрутизаторами и проведено назначение DR и BDR маршрутизаторов.
– Многоточечный (Point-to-multipoint). Режим рассматривает сеть как
совокупность каналов «Точка-Точка». В этой среде маршрутизаторы автоматически определяют своих соседей, но не производят выборы DR и BDR
маршрутизаторов.
Выбор между нешироковещательным и многоточечным режимом работы определяет способ рассылки Hello пакетов и рассылки обновлений топологической информации по NBMA сети.
Главным преимуществом многоточечного режима является минимальная потребность ручной настройки, а главным преимуществом нешироковещательного режима минимальное использование каналов связи.
Компанией Cisco были разработаны дополнительные режимы функционирования протокола OSPF в NBMA сетях неописанные в RFC:
212
– Нешироковещательный многоточечный режим. Этот режим позволяет
в многоточечном режиме статически задавать соседские отношения.
– Широковещательный режим. Интерфейс логически переводится в широковещательный режим и ведет себя, так как если бы маршрутизатор был бы
подключен к широковещательной сети. Требует применение полно-связной
топологии.
– Режим «Точка-Точка». Данный режим используется в тех случаях,
когда в сети NBMA требуется соединить пару маршрутизаторов.
Режим работы протокола OSPF в сети NBMA задается для конкретного
интерфейса при помощи команды ip ospf network. Синтаксис команды приводится в примере 12.2.
Пример 12.2 – Синтаксис команды ip ospf network
(config-if)# ip ospf network {broadcast | non-broadcast | {point-to-multipoint
[non-broadcast] | point-to-point}}
(config-if)# no ip ospf network
Описание параметров команды приводиться в таблице 12.1.
Таблица 12.1 – Параметры команды ip ospf network
Параметр
broadcast
non-broadcast
Описание
Применяет к интерфейсу характеристики широковещательной сети. Использует групповую рассылку Hello
пакетов для автоматического определения соседей. Производятся выборы
DR и BDR маршрутизаторов. Адреса
соседей выдаются из одной подсети.
Требуется полно-связная топология
сети.
Соседние маршрутизаторы должны
быть сконфигурированы вручную.
Производятся выборы DR и BDR
маршрутизаторов. DR и BDR маршрутизаторы должны быть соединены со
всеми остальными маршрутизаторами
сегмента. Адреса соседей выдаются из
одной подсети. Используется в частично-связной топологии сети.
213
Продолжение таблицы 12.1
point-to-multipoint
point-to-multipoint non-broadcast
point-to-point
Использует групповую рассылку Hello
пакетов для автоматического определения соседей. DR и BDR маршрутизаторы не выбираются. Адреса соседей
выдаются из одной подсети. Используется в частично связной топологии.
Соседние маршрутизаторы должны
быть сконфигурированы вручную. DR
и BDR маршрутизаторы не выбираются. Адреса соседей выдаются из одной
подсети.
Алгоритм работы протокола OSPF соответствует правилам работы в сетях
«Точка-Точка».
12.5 Режимы работы протокола OSPF в сетях Frame Relay
12.5.1 Нешироковешательный режим
В нешироковещательном режиме протокол OSPF эмулирует работу широковещательной сети в среде Frame Relay. Производятся выборы DR и BDR
маршрутизаторов, DR маршрутизаторы организуют рассылку обновлений топологической информации по всему сегменту сети Frame Relay. Для автоматического определения соседей и выбора DR и BDR маршрутизаторов необходимо использование в сегменте сети полно-связной топологии.
Если маршрутизаторы включены с сеть с не полно-связной топологией,
они не могут автоматически произвести выборы DR и BDR маршрутизаторов.
Поэтому отношения соседства маршрутизаторов настраивается вручную,
причем DR и BDR маршрутизаторы должны быть соединены со всеми остальными соседями.
При использовании нешироковещательного режима все интерфейсы
маршрутизаторов подключенные к сегменту Frame Relay должны принадлежать одной подсети.
Для рассылки с нешироковешательного интерфейса DR маршрутизатор
скопирует пакету обновлений топологической информации на каждый PVC
настроенный на интерфейсе маршрутизатора. После этого копия обновления
посылается каждому соседнему маршрутизатору определенному на интерфейсе.
214
Для статической настройки соседских отношений между маршрутизаторами в сетях NBMA используется команда neighbor. Синтаксис команды приводится в примере 12.3.
Пример 12.3 – Синтаксис команды neighbor
(config-router)# neighbor ip-address [priority number] [poll-interval seconds]
[cost number] [database-filter all]
(config-router)# no neighbor ip-address [priority number] [poll-interval
seconds] [cost number] [database-filter all]
Описание параметров команды приводиться в таблице 12.2.
Таблица 12.2 – Параметры команды neighbor
Параметр
ip-address
priority number
poll-interval seconds
cost number
database-filter all
Описание
IP соседнего маршрутизатора.
Приоритет соседнего маршрутизатора.
По умолчанию приоритет равен 0.
Интервал времени по истечению, которого будет отправляться Hello пакеты,
если за время ожидания от соседа не
поступило ни одного пакета. В RFC
1247 рекомендовано устанавливать
данный интервал значительно
большим, чем Hello интервал. Значение по умолчанию 120 секунд.
Метрика канала до соседнего маршрутизатора. Если параметр не указан, используется метрика, настроенная на
интерфейсе командой ip ospf cost. Для
сетей NBMA данный параметр не применяется.
Фильтр на исходящие LSA.
На рисунке 12.5 приводится пример статической настройки соседских
отношений между маршрутизаторами.
215
10.10.1.0/29
r2# router ospf 200
network 10.10.1.0 0.0.0.7 area 0
neighbor 10.10.1.1 priority 10
R2
R1(DR)
r3# router ospf 200
network 10.10.1.0 0.0.0.7 area 0
neighbor 10.10.1.1 priority 10
R3
r1# router ospf 200
network 10.10.1.0 0.0.0.7 area 0
neighbor 10.10.1.2 priority 0
neighbor 10.10.1.3 priority 0
Рисунок 12.5 – Статическая настройка соседских отношений
При данной логической топологии сети Frame Relay только маршрутизатор R1 может быть назначен DR маршрутизатором, так как он единственный имеет соединения со всеми остальными маршрутизаторами входящими в
сегмент Frame Relay, для этого ему назначается самый высокий приоритет. В
данном примере BDR маршрутизатор не назначается.
В сетях NBMA команда neighbor может использоваться только на DR и
BRD маршрутизаторах. В топологии «звезда» данная команда используется
только на центральном маршрутизаторе, являющемся для данной топологии
единственно возможным DR маршрутизатором. Это позволяет упростить настройку маршрутизаторов, однако при этом инициировать установку соседских отношений смогут только DR и BDR маршрутизаторы. Применение команды neighbor на удаленных маршрутизаторах позволит им выступать инициаторами установки соседских отношений, но при правильном задании приоритетов не позволит им занять место DR или BDR маршрутизаторов.
10.10.1.0/29
R2
10.10.1.8/30
R4
S0
R1(DR)
r1# show ip ospf neighbor
Neighbor ID
Pri State
10.10.1.2
0
FULL/DROTHER
10.10.1.3
0
FULL/DROTHER
10.10.1.10
1
FULL/-
S1
Dead Time
00:00:32
00:00:35
00:00:18
R3
Address
10.10.1.2
10.10.1.3
10.10.1.10
Interface
Serial1
Serial1
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 представлен пример конфигурации многоточечного режима между тремя маршрутизаторами.
10.10.1.0/29
R1
R2
R3
r2# interface serial 1
encapsulation frame-relay
ip address 10.10.1.2 255.255.255.248
ip ospf network point-to-multipoint
r3# interface serial 1
encapsulation frame-relay
ip address 10.10.1.3 255.255.255.248
ip ospf network point-to-multipoint
r1# interface serial 1
encapsulation frame-relay
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-topoint}
(config)# no interface type number.subinterface-number
Описание параметров команды приводиться в таблице 12.3.
Таблица 12.3 – Параметры команды interface
Параметр
type
number.subinterface-number
multipoint
point-to-point
Описание
Тип физического интерфейса.
Номер интерфейса и подинтерфейса.
Номер интерфейса должен совпадать с
номером физического интерфейса, к
которому принадлежит подинтерфейс.
Номер подинтерфейса может задаваться в пределах от 1 до 4294967293.
Многоточечный подинтерфейс.
Подинтерфейс «Точка-Точка».
На рисунке 12.8 все три маршрутизатора имеют по одному последовательному порту, однако маршрутизатор R1 имеет два логических порта. Каждый логический порт имеет свой собственный IP адрес и работает как интерфейс «Точка-Точка».
218
S1.1
R2
0
0/3
1.
0.
1
.
10
10.10.1.4/30
S1.2
R1
R3
r1# interface serial 1.1 point-to-point
encapsulation frame-relay
ip address 10.10.1.1 255.255.255.252
!
interface serial 1.2 point-to-point
encapsulation frame-relay
ip address 10.10.1.5 255.255.255.252
Рисунок 12.8 – Пример использования подинтерфейсов «Точка-Точка»
Каждый подинтерфейс использует собственную подсеть, благодаря
чему не нужно проводить выборы DR и BDR маршрутизаторов и статическую
настройку списка соседей. На рисунке 12.9 приводится пример использования
многоточечных подинтерфейсов.
R4
10.10.1.0/30
S1.1
R1
S1.2
R2
9
/2
.8
.1
0
.1
10
R3
r1# interface serial 1.1 point-to-point
encapsulation frame-relay
ip address 10.10.1.1 255.255.255.252
!
interface serial 1.2 point-to-multipoint
encapsulation frame-relay
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.
Пример 12.5 – Синтаксис команды show ip ospf interface
show ip ospf interface [interface-type interface-number] [brief]
Описание параметров команды приводиться в таблице 12.4.
Таблица 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 – Процесс установки соседских отношений на широковещательном канале
r1# debug ip ospf adj
.. .. ..
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.
Зона 0 (Backbone )
Зона 1
Зона 2
Рисунок 13.2 – Разделение домена OSPF на три зоны
Иерархическое разделение домена маршрутизации OSPF на множество
зон дает возможность уменьшить объем служебного трафика, вызванного обновлениями топологической информации, и сократить вычисления по алгоритму SPF, которые должны выполнять маршрутизаторы.
В каждой зоне домена маршрутизации обмен обновлениями топологической информации ограничивается только маршрутизаторами принадлежащими данной зоне, и это помогает уменьшить общий размер базы данных состояния каналов. Маршрутизаторы поддерживают таблицы топологии только
тех зон, с которыми они непосредственно соединены. Таким образом, внутренний трафик обновлений топологической информацией ограничивается
только той зоной, в которой он был сгенерирован. Изменения состояния
маршрутов одной зоны не требуют, чтобы маршрутизаторы другой зоны занимались пересчетом этих маршрутов. Благодаря тому, что маршрутизаторы
не должны пересчитывать свои таблицы маршрутизации из-за изменений со-
223
стояний каналов связи в другой зоне, существенно уменьшается объем вычислений по алгоритму SPF, что в свою очередь значительно повышает стабильность сети.
Разделение общего домена маршрутизации OSPF может происходить
любым способом, но обычно такое разделение производиться по географическому принципу, при котором каждая зона определяется ее местоположением. Как говорилось ранее при разделении домена маршрутизации на несколько зон всегда должна существовать так называемая магистральная зона или
Зона 0. Данная зона исполняет роль транзитной зоны для всех остальных зон
и обеспечивает передачу топологической информации между зонами.
13.1 Типы маршрутизаторов OSPF
Протокол OSPF разграничивает функции маршрутизаторов в зависимости от того, какое место в домене маршрутизации они занимают и к какому
числу зон принадлежат. На рисунке 13.3 приводится пример домена маршрутизации OSPF разделенного на зоны, и функций маршрутизаторов которые
они выполняют в зависимости от своего расположения.
Зона 0 (Backbone )
Backbone router
ABR
ABR
Внешняя AS
Зона 1
Internal router
Зона 2
ASBR
Рисунок 13.3 – Типы маршрутизаторов OSPF
Протокол OSPF использует четыре типа маршрутизаторов:
– Внутренние маршрутизаторы (Internal router);
– Магистральные маршрутизаторы (Backbone router);
– Пограничные маршрутизаторы зоны (Area border router - ABR);
– Пограничные маршрутизаторы автономной системы (Autonomous System 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 бита
Заголовок сообщения LSA
8
8
Возраст сообщения
8
8
Опции
Тип
Идентификатор сообщения
Объявляющий маршрутизатор
Порядковыйномер сообщения
Контрольная сумма
Длина
Данные 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
Номер
1
2
3
4
5
6
Тип LSA
Объявление состояние маршрутизатора.
Объявление состояния сети.
Описание
Описывает состояния интерфейсов маршрутизатора.
Перечисляет маршрутизаторы, входящие в широковещательный домен.
Суммарное объ- Описывает суммарные
явление о состоя- маршруты.
нии каналов.
Суммарное объ- Описывает пограничные
явление о состоя- маршрутизаторы автонии каналов.
номной системы.
Объявления
Описывает импортировнешних связей
ванные маршруты из друавтономной сигих AS.
стемы.
Групповые LSA. Описания топологической информации для
группового трафика.
Кем объявляется
Всеми маршрутизаторами.
DR маршрутизаторами.
Пограничными маршрутизаторами зоны
OSPF.
Пограничными маршрутизаторами зоны
OSPF.
Пограничными маршрутизаторами автономной системы.
MOSPF маршрутизаторами.
Данный тип не поддерживается маршрутизаторами Cisco.
227
Продолжение таблицы 13.1
Номер
Тип LSA
Внешние LSA для
NSSA зон.
7
8
9,10,11
VPN LSA для взаимодействия с BGP VPN
v4
Зарезервировано.
Описание
Описывает импортированные маршруты в область NSSA из других
AS.
Описывает импортированные маршруты из
BGP VPN v4.
Кем объявляется
Пограничные
маршрутизаторы
NSSA.
Пограничные
маршрутизаторы
PE.
-
-
– Идентификатор сообщения. Поле является компонентом уникальной
идентификации LSA сообщения. Другими компонентами являются поля «Тип
сообщения» и «Объявляющий маршрутизатор». В зависимости от типа LSA
этому полю присваиваются значения, приведенные в таблице 13.2.
Таблица 13.2 – Значения поля «Идентификатор сообщения»
Тип LSA
1
2
3
4
5и7
Идентификатор сообщения
RID маршрутизатора заявившего LSA.
IP адрес интерфейса DR маршрутизатора подключенного к широковещательному домену.
Суммарный маршрут сети получателя.
RID пограничного маршрутизатора автономной системы.
Сеть получатель.
– Объявляющий маршрутизатор. Поле содержит 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)
Флаги
Количество связей
Идентификаторсвязи
Число ToS
Метрика
ToS
0
Метрика ToS
Данные пакета LSA
Тип связи
Флаги
Связь 1
Данные связи
Количество связей
Идентификаторсвязи
Тип связи
Число ToS
Метрика
ToS
0
Метрика ToS
Связь N
Данные связи
Рисунок 13.6 – Структура сообщения LSA 1 типа
Структура сообщения включает в себя заголовок LSA со значением 1 в
поле «Тип сообщения», далее идут поля данных:
– Флаги. Поле размеров в 16 бит имеет структуру, показанную на рисунке 13.7.
– Количество связей. Поле содержит число связей маршрутизатора описанное в сообщении.
16 бит
0
1
2
0
3
4
5
6
7
V
E
B
0
1
2
3
4
5
6
7
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 маршрутизатора на
1
Точка».
другом конце канала
связи.
Транзитная
IP адрес DR маршрути2
сеть.
затора.
Тупиковая
Сетевой префикс тупи3
сеть.
кового сегмента.
Виртуальная RID маршрутизатора на
связь.
другом конце виртуаль4
ного.
Данные связи
IP адрес интерфейса.
IP адрес интерфейса.
Маска подсети тупикового
сегмента.
IP адрес интерфейса через
который пакеты OSPF отправляются по виртуальному каналу.
13.2.3 Объявление состояния сети (Тип 2)
Объявления состояния сети описывают маршрутизаторы, подключенные к широковещательному сегменту или сегменту NBMA. Они объявляются
DR маршрутизатором выбранным в этом сегменте. Сообщения LSA второго
типа распространяются только в пределах зоны, в которой они объявлены
(Рисунок 13.8).
231
Зона 1
DR
Internal
Internal
LSA 2
Рисунок 13.8 – Область распространения LSA 2 типа
Структура сообщения состояния сети представлена на рисунке 13.9.
32 бита
8
8
8
8
Заголовок LSA (Тип = 2)
Данные пакета LSA
Маска сети
Присоединенныймаршрутизатор
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 )
DR
ABR /R1
Зона 2
BBone
ABR/R2
LSA 3
Internal
LSA 1
RIP
ASBR
LSA 2
LSA 3
LSA 3
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)
Данные пакета LSA
Маска сети
0
Метрика
ToS
Метрика ToS
Рисунок 13.11 – Структура сообщения LSA 3 и 4 типов
13.2.5 Объявления внешних связей (Тип 5 и 7)
Объявления о внешних связях описывают места назначения, расположенные за пределами домена маршрутизации OSPF. Эти сообщения объявляются пограничными маршрутизаторами автономных систем (ASBR), и как
показано на рисунке 13.12, распространяются по всему домену маршрутизации OSPF.
Зона 1
Зона 0 (Backbone)
ABR/DR
Внешняя AS
BBone
Зона 2
ABR/DR
ASBR
Internal
LSA 5
LSA 5
LSA 5
LSA 5
Рисунок 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
Данные пакета LSA
Адрес пересылки
Рисунок 13.13 – Структура сообщения LSA 5 и 7 типов
Структура сообщения включает в себя заголовок LSA со значениями 5
или 7 в поле «Тип сообщения», далее идут поля данных:
– Маска. Поле содержит маску подсети объявляемого внешнего маршрута.
– Бит E. Бит E указывает на тип используемой метрики. Если бит равен
0, то используется метрика 1 типа, если бит равен 1, то метрика 2 типа. О типах метрик протокола OSPF будет рассказано далее.
– Метрика. Поле содержит метрику маршрута к месту назначения.
– Адрес пересылки. Поле содержит IP адрес маршрутизатора, который
должен передавать трафик к внешней сети получателю. Если это поле содержит значение 0, передающий маршрутизатор является пограничным маршрутизатором ASBR, который объявляет данное сообщение LSA.
– Ярлык внешнего маршрута. Поле содержит ярлык внешнего маршрута, который был назначен при импорте маршрутной информации в домен
маршрутизации OSPF.
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
O E1
OSPF inter–area.
Type 1 External routes.
O E2
Type 2 External routes.
Описание
Внутризональный маршрут.
Межзональный маршрут.
Внешний маршрут 1
типа.
Внешний маршрут 1
типа.
13.3.2 Расчет метрики внешних маршрутов
Расчет метрики внешних маршрутов зависит от типа внешнего маршрута.
Для внешних маршрутов 1 типа (E1) метрика вычисляется сложением
внешней метрики маршрута полученной при импортировании маршрута в домен маршрутизации OSPF и метрики каждого канала, который проходит на
своем пути пакет до ASBR маршрутизатора.
Для внешних маршрутов 2 типа (E2) метрика состоит только из внешней метрики и не зависит от метрик внутренних каналов связи.
Пример распространения внешних маршрутов различных типов приводится на рисунке 13.14.
R2 Cost to :
AS1 (E1) viaR 1 = 1675
AS2 (E2) viaR 3 = 1785
Зона 1
Внешняя AS 1
1665
Зона 0 (Backbone)
10
R1
R1 Cost to :
AS1 (E1) viaR 1 = 1665
AS2 (E2) viaR 2 = 1785
R4 Cost to :
AS1 (E1) viaR 3 = 1695
AS2 (E2) viaR 4 = 1785
10
R2
10
R3
1785
Внешняя AS 2
R4
R3 Cost to :
AS1 (E1) viaR 2 = 1685
AS2 (E2) viaR 4 = 1785
Рисунок 13.14 –Распространение внешних маршрутов
Внешние маршруты 2 типа применяются, если во внешнюю автономную систему, на которую они указывают, существует только одна точка входа. Следовательно, производить пересчет метрики маршрута внутри домена
маршрутизации OSPF не имеет смысла, так как внутренняя метрика ни как не
может повлиять на выбор внешнего маршрута.
238
Однако если во внешнюю автономную систему существуют две или более точек входа, причем они могут быть расположены в разных частях домена
маршрутизации OSPF, то для корректной обработки таких внешних маршрутов необходимо их объявление как внешних маршрутов 1 типа. При этом в их
метрике будет учитываться не только внешняя составляющая, но и внутренняя, это позволит маршрутизаторам находящимся в домене OSPF производить корректный выбор между альтернативными внешними маршрутами.
По умолчанию протокол OSPF все внешние маршруты распространяет
как внешние маршруты 2 типа.
13.4 Суммирование маршрутов протоколом OSPF
Использование механизма суммирования маршрутов существенно
уменьшает величину требуемых вычислительных ресурсов для процесса
маршрутизации OSPF. В протоколе OSPF существуют два типа суммирования маршрутов:
– Суммирование межзональных маршрутов;
– Суммирование внешних маршрутов.
13.4.1 Суммирование межзональных маршрутов
Зона 0 (Backbone )
Зона 1
Зона 2
Зона 3
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.
Зона 0 (Backbone)
Зона 1
R1
O
O
O
O
O
O
O
O
O
O
O
O
172.16.8.0
172.16.9.0
172.16.10.0
172.16.11.0
172.16.12.0
172.16.13.0
172.16.14.0
172.16.15.0
172.16.16.0
172.16.17.0
172.16.18.0
172.16.19.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
255.255.255.0
R2
R3
IA 172.16.8.0
255.255.248.0
IA 172.16.8.0
255.255.248.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]
Описание параметров команды приводиться в таблице 13.5.
240
Таблица 13.5 – Параметры команды area range
Параметр
Описание
Идентификатор зоны OSPF, частные
маршруты которой буду агрегированы
в суммарный маршрут.
Адрес и маска подсети объявляемого
суммарного маршрута.
Разрешить объявление суммарного
маршрута и распространение LSA 3
типа.
Запретить объявление суммарного
маршрута для описанного диапазона.
Сделать описанный диапазон скрытым
для всех остальных зон OSPF.
Метрика, назначаемая суммарному
маршруту.
area-id
address mask
advertise
not-advertise
cost cost
Зона 1
c 172 .16.32.0/24
по 172 .16.63.0/24
Зона 0 (Backbone)
R1
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 0 range 172.16.96.0 255.255.224.0
area 1 range 172.16.32.0 255.255.224.0
с 172 .16.96.0/24
по 172 .16.127 .0/24
Зона 2
R2
с 172 .16.64.0/24
по 172 .16.95.0/24
router ospf 200
network 172.16.64.0 0.0.31.255 area 2
network 172.16.127.0 0.0.31.255 area 0
area 0 range 172.16.96.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.
Таблица 13.6 – Параметры команды summary-address
Параметр
address mask
not-advertise
tag tag
Описание
Адрес и маска подсети объявляемого
внешнего суммарного маршрута.
Запретить объявление внешнего суммарного маршрута для описанного
диапазона. Сделать описанный диапазон скрытым для всех зон OSPF.
Ярлык для использования при контроле перераспределения маршрутов.
На рисунке 13.18 приведен пример суммирования маршрутов на ASBR
маршрутизаторе.
242
Зона 1
RIPv 2
10.0.0.0/24
Зона 0 (Backbone)
172 .16.32.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 summary-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
Metric
Type
Tag
Описание
IP адрес и маска подсети внешнего
суммарного маршрута.
Метрика внешнего суммарного маршрута
Тип пакета LSA
Ярлык, присвоенный внешнему суммарному маршруту
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-sostubby area, totally stub NSSA). Данный тип зоны протокола OSPF обладает
всеми свойствами полностью тупиковых зон, однако totally stub NSSA зоны
могут содержать ASBR маршрутизаторы.
14.1.1 Правила тупиковых зон
Зону протокола OSPF можно настроить как тупиковую или полностью
тупиковую, если она удовлетворяет следующим критериям:
– Зона не является магистральной зоной;
– Зона имеет единственную точку выхода в магистральную зону;
– Зона не имеет ASBR маршрутизаторов;
– Зона не содержит виртуальных каналов.
14.2 Тупиковые зоны протокола OSPF
Настройка зоны OSPF как тупиковой зоны уменьшает размер таблиц
топологии на внутренних маршрутизаторах зоны за счет замены пограничными маршрутизаторами внешних сообщений LSA на маршрут по умолчанию.
Процесс распространения топологической информации изображен на рисунке
14.1.
Зона 1 (Stub)
Internal
Зона 0 (Backbone )
ABR
Зона 2 (Standard)
ASBR
ABR
Internal
LSA 3
LSA 3
LSA 3
LSA 3
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)
R1
Зона 0 (Backbone)
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 )
Internal
Зона 0 (Backbone )
ABR
Зона 2 (Standard)
ASBR
ABR
Internal
LSA 3
LSA 3
LSA 3
LSA 5
LSA 5
LSA 5
Default
Внешняя AS
Рисунок 14.3 – Распространение маршрута по умолчанию
в полностью тупиковую зону
Полностью тупиковые зоны минимизируют маршрутную информацию
в большей степени, чем тупиковые зоны, тем самым они повышают стабильность и упрощают масшабируемость сетей передачи данных. Использование
полностью тупиковых зон на маршрутизаторах Cisco предпочтительнее, чем
использование тупиковых зон.
14.3.1 Настройка полностью тупиковой зоны
Чтобы настроить зону как полностью тупиковую, необходимо воспользоваться уже известной командой area stub на всех внутренних маршрутизаторах зоны, а на ABR маршрутизаторе добавить к команде area stub ключевое
слово no-summary. Необходимо помнить, что данное ключевое слово применяется только на ABR маршрутизаторе.
Для изменения метрики автоматически распространяемого маршрута по
умолчанию можно воспользоваться командой area default-cost. Синтаксис команды приводится в примере 14.2.
Пример 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
Параметр
Описание
Номер зоны OSPF, которой принадлежит описанная сеть.
Метрика маршрута.
area-id
cost
Данная команда применяется только для изменения метрики автоматически сгенерированных маршрутов по умолчанию для тупиковых, полностью
тупиковых и NSSA зон протокола OSPF.
router ospf 200
area 1 stub no-summary
area 1 default-cost 5
Зона 1 (Stub)
Зона 0 (Backbone)
R1
R3
R4
R2
router ospf 200
area 1 stub
router ospf 200
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
.. .. ..
10.0.0.0/24 is subnetted, 15 subnets
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
С
10.1.2.0 is directly connected, Serial1
О 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
.. .. ..
Gateway of last resort is 10.66.0.1 to network 0.0.0.0
10.0.0.0/24 is
O IA 10.3.1.0
С
10.1.3.0
О IA 10.2.1.0
С
10.1.2.0
О IA 10.3.3.0
О IA 10.2.2.0
О
10.1.1.0
О IA
О IA
O IA
0 IA
0 IA
C
0*IA
subnetted, 13 subnets
[110/148] via 10.64.0.2, 00:03:12, Ethernet0
is directly connected, Serial0
[110/74] via 10.64.0.2, 00:31:46, Ethernet0
is directly connected, Serial1
[110/148] via 10.64.0.2, 00:03:12, Ethernet0
[110/138] via 10.64.0.2, 00:31:46, Ethernet0
[110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial1
10.3.2.0 [110/212] via 10.64.0.2, 00:03:12, Ethernet0
10.2.3.0 [110/74] via 10.64.0.2, 00:31:46, Ethernet0
10.4.2.0 [110/286] via 10.64.0.2, 00:02:50, Ethernet0
10.4.3.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
10.4.1.0 [110/222] via 10.64.0.2, 00:02:50, Ethernet0
10.64.0.0 is directly connected, Ethernet0
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
.. .. ..
Gateway of last resort is 10.66.0.1 to network 0.0.0.0
10.0.0.0/24 is
С
10.1.3.0
С
10.1.2.0
О
10.1.1.0
subnetted, 4 subnets
is directly connected, Serial0
is directly connected, Serial1
[110/128] via 10.1.3.1, 00:31:46, Serial0
[110/128] via 10.1.2.1, 00:31:46, Serial1
C
10.64.0.0 is directly connected, Ethernet0
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-sostubby 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
LSA 7
BBone
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-originate [metric] [metric-type]][no-summary]
(config-router)# no area area-id [no-redistribution] [default-information-originate [metric] [metric-type]][no-summary]
Описание параметров команды area nssa приводиться в таблице 14.2.
Таблица 14.2 – Параметры команды area nssa
Параметр
Описание
Номер зоны OSPF, которой принадлежит описанная сеть.
Параметр устанавливается в тех случаях, когда ABR и ASBR маршрутизаторы совпадают и требуется распространение импортированных маршрутов
только в стандартные зоны OSPF.
Распространение маршрута по умолчанию при помощи сообщений LSA 7
типа.
Метрика маршрута.
Тип маршрута.
Полностью тупиковая зона NSSA
area-id
no-redistribution
default-information-originate
metric
metric-type
no-summary
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 borderrouter
r2#show ip ospf border-routers
OSPF Process 109 internal Routing Table
Codes: i - Intra-area route, I - Inter-area route
i
i
I
I
192.168.97.53
192.168.103.51
192.168.103.52
192.168.103.52
[10]
[10]
[22]
[22]
via
via
via
via
172.16.1.53,
192.168.96.51,
192.168.96.51,
172.16.1.53,
Serial0,
Serial0,
Serial0,
Serial0,
ABR,
ABR,
ASBR,
ASBR,
Area
Area
Area
Area
0.0.0.1,
0.0.0.1,
0.0.0.1,
0.0.0.1,
SPF
SPF
SPF
SPF
3
3
3
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
Serial0
ABR
Area 0.0.0.1
SPF
Описание
Идентификатор маршрутизатора.
Стоимость канала до маршрутизатора.
IP адрес следующего маршрутизатора
на пути к пограничному маршрутизатору.
Выходной интерфейс на пути к маршрутизатору.
Тип пограничного маршрутизатора.
Идентификатор зоны.
Номер запуска алгоритма SFP на котором был добавлен этот маршрутизатор.
255
15 Виртуальные каналы в протоколе OSPF
Главным правилом при разделении домена маршрутизации OSPF на
несколько зон, является то, что любые две зоны в протоколе OSPF должны
быть соединены через магистральную зону 0 (Рисунок 15.1).
Зона 2
Зона 1
ABR
Зона 0
ABR
Рисунок 15.1 – Правило разделения домена маршрутизации OSPF на зоны
Из рисунка 15.1 видно, что в протоколе OSPF стандартные зоны не могут быть соединены между собой через пограничный маршрутизатор. В некоторых случаях становиться необходимо, создать новую зону в домене маршрутизации, однако организовать прямое соединение с магистральной зоной
либо невозможно, либо организация канала требует значительного времени.
В таких случаях для обеспечения соединения с магистральной зоной
можно создать виртуальный канал. Виртуальный канал задает логический
путь между новой и магистральной зонами. Виртуальный канал может представлять собой как временное, так и постоянное решение обеспечения связности с магистральной зоной.
Виртуальный канал должен удовлетворять двум требованиям:
– Виртуальный канал устанавливается между двумя ABR маршрутизаторами, принадлежащим одной стандартной зоне домена маршрутизации.
– Один из двух ABR маршрутизаторов должен иметь непосредственное
подключение к магистральной зоне, другой к вновь создаваемой зоне.
Пример организации виртуального канала приводиться на рисунке 15.2.
Зона 2
Зона 1
ABR
Виртуальный канал
Зона 0
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] [transmit–delay seconds] [dead–interval seconds] [[authentication–key key] | [message–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
router-id
Описание
Номер зоны OSPF, по которой проходит виртуальный канал.
Идентификатор маршрутизатора на
противоположной стороне виртуального канала.
257
Продолжение таблицы 13.1
Параметр
authentication
message-digest
null
hello-interval seconds
retransmit-interval seconds
transmit-delay seconds
dead-interval seconds
authentication-key key
message-digest-key key-id md5 key
Описание
Определяет метод аутентификации. По
умолчанию применяется аутентификация по паролю.
Аутентификация алгоритмом MD5.
Аутентификация не используется.
Таймер рассылки Hello пакетов по виртуальному каналу.
По умолчанию 10 сек.
Таймер повторной передачи записей
LSA по виртуальному каналу.
По умолчанию 5 сек.
Предполагаемое время необходимое
для передачи одного сообщения LSA
по виртуальному каналу.
По умолчанию 1 сек.
Таймер поддержания соседских отношений по виртуальному каналу.
По умолчанию 40 сек.
Ключ аутентификации при аутентификации по паролю.
Номер ключа и ключ аутентификации
при использовании 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).
Зона 2
Зона 1
R2
Зона 0
Виртуальный канал
router ospf 200
router-id 2.2.2.2
network 10.1.0.0 0.0.255.255 area 1
network 10.2.0.0 0.0.255.255 area 2
area 1 virtual-link 1.1.1.1
R1
router ospf 200
router-id 1.1.1.1
network 10.0.0.0 0.0.255.255 area 0
network 10.1.0.0 0.0.255.255 area 1
area 1 virtual-link 2.2.2.2
Рисунок 15.3 – Использование виртуального канала для соединения стандартной и магистральной зоны OSPF
Чтобы обеспечить соединение с магистральной сетью, необходимо
установить виртуальный канал между маршрутизаторами R2 и R1. Зона 1 будет выступать в качестве транзитной зоны, а маршрутизатор R2 будет точкой
входа в магистральную зону для зоны 2.
Зона 0
Зона 1
R2
Зона 0
Виртуальный канал
router ospf 200
router-id 2.2.2.2
network 10.0.0.0 0.0.255.255 area 0
network 10.1.0.0 0.0.255.255 area 1
area 1 virtual-link 1.1.1.1
R1
router ospf 200
router-id 1.1.1.1
network 10.0.0.0 0.0.255.255 area 0
network 10.1.0.0 0.0.255.255 area 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 virtuallinks
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
OSPF Router with ID (1.1.1.1) (Process ID 2)
Router Link States (Area 0)
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
r3# 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
172 .16.14.16/28
172 .16.14.32/28
R2
17
2.
16
.14
.4
8/2
8
172 .16.14.64/28
R3
8
0/2
.8
14
.
16
2.
17
192 .168 .1.0/28
R1
R5
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
M=N
4
M=N
3
R4
R1
R2
M =M1
M=
N1
R3
Сеть N1,
Протокол маршрутизации
Административноерасстояние
A1>A2
RP1,
RP1 = A1
Сеть N2,
Протокол маршрутизации
Административноерасстояние
A2<A1
M=N
2
RP2,
RP2 = A2
Рисунок 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.
M=N
4
M=N
3
R4
M=M
0
R5
R1
M =M
1
R2
M=
N1
R3
Сеть N1,
Протокол маршрутизации
Административноерасстояние
A1>A2
RP1,
RP1 = A1
Сеть N2,
Протокол маршрутизации
Административноерасстояние
A2<A1
M=N
2
RP2,
RP2 = A2
Рисунок 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
RMk
*
M
M
1
RM1
*
N
RP1,
RP1 = A1
Сеть N,
Протокол маршрутизации
Административноерасстояние
A2<A1
RP2,
RP2 = A2
Nk
RNk
RX2
N
1
RX1
Сеть M,
Протокол маршрутизации
Административноерасстояние
A1>A2
N2
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
R1
r1# router eigrp 1
network 172.16.0.0
distance eigrp 130 170
!
router rip
network 172.16.0.0
F0/0
F0/1 172 .16.0.16/28 F0/0
R2
r2# router eigrp 1
network 172.16.0.0
distance eigrp 130 170
!
router rip
network 172.16.0.0
F0/1 172 .16.0.32/28
R3
r2# router eigrp 1
network 172.16.0.0
distance eigrp 130 170
!
router rip
network 172.16.0.0
Рисунок 17.1 – Совместная работа двух протоколов маршрутизации
без перераспределения маршрутной информации
275
На всех маршрутизаторах входящих в сеть передачи данных параллельно
запущено два протокола маршрутизации – это протоколы RIP и EIGRP. Необходимо обратить внимание на то что, все маршрутизаторы имеют в своей конфигурации строчку distance eigrp 130 170, которая устанавливает административное расстояние протокола EIGRP равным 130, что больше административного расстояния протокола RIP, равного 120.
Рассмотрим таблицу маршрутизации маршрутизатора R1, показанную в
примере 17.1.
Пример 17.1 – Таблица маршрутизации маршрутизатора R1
r1#show ip route
172.16.0.0/28 is subnetted, 3 subnets
R
172.16.0.32 [120/2] via 172.16.0.1, 00:00:18, FastEthernet0/0
R
172.16.0.16 [120/1] 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
P 172.16.0.0/28, 1 successors, FD is 28160
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
172.16.0.0/28 is subnetted, 3 subnets
R
172.16.0.32 [120/2] via 172.16.0.1, 00:00:15, FastEthernet0/0
D
172.16.0.16 [90/30720] via 172.16.0.1, 00:00:16, FastEthernet0/0
C
172.16.0.0 is directly connected, FastEthernet0/0
Действительно в таблице маршрутизации появился один маршрут, полученный по протоколу EIGRP. Данный маршрут относится к единственной
сети получателю, находившемуся в таблице топологии маршрутизатора R1 из
примера 17.2. Интересной особенностью данной сети получателя является то,
что она расположена ровно в одном переходе от маршрутизатора R1. Однако
для сетей получателей расположенных далее одного перехода в таблице
маршрутизации до сих пор указаны маршруты протокола RIP. Это не удивительно, поскольку на маршрутизаторе R2 и далее процесс маршрутизации EIGRP до сих пор имеет большее административное расстояние, чем процесс
маршрутизации RIP. Следовательно, маршрутизатор R2 объявляет посредством протокола EIGRP только непосредственно подключенные к нему сети
получатели, которые в лучшем случае расположены в одном переходе от
маршрутизатора R1.
Если посмотреть таблицу топологии маршрутизатора R1 (Пример 17.4),
можно увидеть, что запись о сети 172.16.0.16 больше не помечена как недоступная.
Пример 17.4 – Таблица топологии маршрутизатора R1 после восстановления административного расстояния протокола EIGRP
show ip eigrp topology
P 172.16.0.16/28, 1 successors, FD is 30720
via 172.16.0.1 (30720/28160), FastEthernet0/0
P 172.16.0.0/28, 1 successors, FD is 28160
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
OSPF Router with ID (172.16.0.2) (Process ID 1)
Router Link States (Area 1)
Link ID
172.16.0.2
172.16.0.17
172.16.0.33
ADV Router
172.16.0.2
172.16.0.17
172.16.0.33
Age
270
271
271
Seq#
0x80000002
0x80000001
0x80000002
Checksum
0x0047EF
0x009BD2
0x006396
Seq#
0x80000001
0x80000001
0x80000001
Checksum
0x0075C9
0x00519F
0x0001CA
Link count
1
2
2
Net Link States (Area 1)
Link ID
172.16.0.0
172.16.0.16
172.16.0.32
ADV Router
172.16.0.2
172.16.0.17
172.16.0.33
Age
270
272
271
Из примера видно, что в таблице топологии построенной протоколом
OSPF, присутствуют записи обо всех маршрутизаторах и сетях получателях
расположенных в рассматриваемой сети передачи данных.
Уберем из настройки процесса маршрутизации OSPF команду distance
ospf intra-area 130, вернув тем самым административное расстояние протокола
OSPF используемое по умолчанию и равное 110.
Посмотрим, как изменится таблица маршрутизации (Пример 17.6).
278
Пример 17.6 – Таблица маршрутизации маршрутизатора R1 после
восстановления административного расстояния протокола OSPF
r1#show ip route
172.16.0.0/28 is subnetted, 3 subnets
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
C
172.16.0.0 is directly connected, 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
eigrp
ospf
bgp
Описание
Перераспределение непосредственно
подключенных к маршрутизатору сетей.
Перераспределение статических маршрутов настроенных на маршрутизаторе.
Перераспределение маршрутной информации из протокола RIP.
Перераспределение маршрутной информации из протокола EIGRP.
Перераспределение маршрутной информации из протокола OSPF.
Перераспределение маршрутной информации из протокола 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
delay
reliability
loading
mtu
Описание
Метрика, назначаемая по умолчанию
для всех перераспределенных маршрутов.
Значение пропускной способности канала связи. Используется для расчета
комбинированной метрики EIGRP.
Значение задержки канала связи. Используется для расчета комбинированной метрики EIGRP.
Значение надежности канала связи.
Используется для расчета комбинированной метрики EIGRP.
Значение загрузки канала связи. Используется для расчета комбинированной метрики EIGRP.
Значение MTU канала связи. Используется для расчета комбинированной
метрики EIGRP.
Если не было использовано ни ключевое слово metric в команде redistribute, ни команда default-metric, то перераспределенным маршрутам присваиваются метрики, установленные по умолчанию для перераспределенных в данный протокол маршрутизации маршрутов. Значения метрик по умолчанию для
перераспределенных маршрутов приводится в таблице 17.4.
282
Таблица 17.4 – Метрики маршрутов используемые по умолчанию при
перераспределении маршрутной информации
Получатель маршрутной
информации
Метрика по умолчанию
RIP
EIGRP
OSPF
BGP
Бесконечность.
Бесконечность.
20.
Исходная метрика маршрута.
17.3 Настройка перераспределения маршрутной информации из присоединенных и статических маршрутов
Пример настройки перераспределения маршрутной информации из
присоединенных и статических маршрутов приводится на рисунке 17.2.
r1# router rip
network 172.16.0.0
redistribute connected
redistribute static
!
ip route 10.0.0.0 255 .255.255.0 Null 0
r2# router rip
network 172.16.0.0
redistribute connected
!
ip route 172.16.1.0 255.255.255.0 FastEthernet 0/0
ip route 192.168.3.0 255.255.255.0 172.16.0.1
F0/0
R1
172 .16.0.0/28
F0/0
R2
F0/1
192 .168 .1.0/28
F0/1
192 .168 .2.0/28
r1#show ip route
.. .. ..
Gateway of last resort is not set
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
.. .. ..
Gateway of last resort is not set
172 .16.0.0/16 is variably subnetted , 2 subnets, 2 masks
S
172.16.1.0/24 is directly connected , FastEthernet 0/0
C
172.16.0.0/28 is directly connected , FastEthernet 0/0
192 .168.1.0/28 is subnetted , 2 subnets
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
10.0.0.0/24 is subnetted, 1 subnets
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 при настройке процесса маршрутизации и в дальнейшем не нужно описывать в процессе маршрутизации новые сети, настраиваемые на маршрутизаторе и удалять неиспользуемые при помощи команд network.
Стоит отметить, что практика такого использования команды redistribute
connected широко распространена в корпоративных сетях передачи данных. Однако такое распространение информации о непосредственно подключенных сетях в протоколы маршрутизации EIGRP и OSPF является совершенно неправильным.
Как упоминалось ранее, в протоколе маршрутизации EIGRP, введено разделение внутренних и внешних маршрутов по административному расстоянию.
Внутренние маршруты протокола EIGRP имеют административное расстояние
равное 90, что позволяет им выигрывать практически у любых других динамических протоколов маршрутизации, тогда как для внешних маршрутов протокол EIGRP по умолчанию устанавливает административное расстояние равным
170 (Рисунок 17.3). Это приводит к тому, что внешние маршруты протокола EIGRP наоборот проигрывают всем остальным динамическим протоколам маршрутизации. Следовательно данная ситуация потенциально может приводить к
возникновению маршрутных петель в домене маршрутизации EIGRP.
284
r1# router eigrp 100
network 172.16.0.0
redistribute connected
S0
r2# router eigrp 100
network 172.16.0.0
redistribute connected
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
.. .. ..
172.16.0.0/28 is subnetted, 1 subnets
C
172.16.0.0 is directly connected , Serial0
192.168.1.0/28 is subnetted, 2 subnets
D EX
192.168.2.0/28 [170/2304000] via 172.16.0.2, 00:00:18, Serial0
C
192.168.1.0/28 is directly connected , FastEthernet 0/1
r2#show ip route
.. .. ..
172 .16.0.0/28 is subnetted, 1 subnets
C
172.16.0.0 is directly connected , Serial0
192 .168.1.0/28 is subnetted , 2 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
network 172.16.0.0 0.0.0.15 area 1
redistribute connected
r2# router ospf 1
network 172.16.0.0 0.0.0.15 area 1
redistribute connected
S0 172 .16.0.0/28
R1
F0/1
192 .168 .1.0/28
S1
R2
F0/1
192 .168 .2.0/28
r1#show ip route
.. .. ..
172.16.0.0/28 is subnetted, 1 subnets
C
172.16.0.0 is directly connected , Serial0
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.
Пример 17.9 – Синтаксис команды redistribute (RIP)
(config-router)#redistribute protocol [process-id] [as-number] [metric metricvalue] [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
Продолжение таблицы 17.5
Параметр
Описание
Номер автономной системы. Используется при перераспределении из протоколов EIGRP или BGP.
Метрика, назначаемая для перераспределенных маршрутов.
Тип перераспределяемых маршрутов.
Может принимать значения:
Internal – внутренний маршрут;
External 1 – внешний маршрут 1 типа;
External 2 – внешний маршрут 2 типа.
Параметр применяется при перераспределении из протокола OSPF.
Ярлык, назначаемый для использования при контроле перераспределения
маршрутов.
Имя маршрутной карты используемой
при перераспределении.
as-number
metric metric-value
match route-type
tag tag-value
route-map map-tag
r1#show ip route
.. .. ..
172 .16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
.. .. ..
192 .168.0.0/28 is subnetted , 5 subnets
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
172 .16.0.0/16
Сеть N2, RIP
192 .168 .0.0/24
OSP F
R IP
R1
R2
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
.. .. ..
172 .16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
.. .. ..
192 .168.0.0/28 is subnetted , 5 subnets
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, и внешние, полученные при перераспределении
маршрутной информации из внешних источников.
17.5 Настройка перераспределения маршрутной информации в протокол EIGRP
Перераспределение маршрутной информации в протокол маршрутизации
EIGRP осуществляется при помощи команды redistribute, синтаксис которой
приводится в примере 17.10.
Пример 17.10 – Синтаксис команды redistribute (EIGRP)
(config-router)#redistribute protocol [process-id] [as-number] [metric metricvalue] [match route-type] [metric metric-value][tag tag-value] [route-map maptag]
(config-router)# no redistribute protocol [process-id] [as-number] [metric
metric-value] [match route-type] [metric metric-value][tag tag-value] [routemap map-tag]
В синтаксисе команды redistribute (EIGRP) присутствует параметр asnumber, данный параметр применяется не только при перераспределении
маршрутной информации из протокола BGP, но и из экземпляра протокола
EIGRP запущенного в другой автономной системе.
На рисунке 17.6 приводится пример настройки перераспределения маршрутной информации в протокол EIGRP из протокола RIP.
288
r1#show ip route
.. .. ..
172 .16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
.. .. ..
192 .168.0.0/28 is subnetted , 5 subnets
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
192 .168 .0.0/24
Сеть N2, EIGRP
172 .16.0.0/16
R IP
OSP F
R1
R2
r1# router eigrp 100
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
.. .. ..
172 .16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
.. .. ..
192 .168.0.0/28 is subnetted , 5 subnets
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
.. .. ..
Рисунок 17.6 – Перераспределение маршрутной информации
в протокол EIGRP
На маршрутизаторе R1 запущены два протокола маршрутизации: протоколы RIP и EIGRP. Маршрутизатор R1 производит перераспределение
маршрутной информации из N1 в N2. Необходимо обратить внимание на то,
что при выполнении перераспределения маршрутизатор R1, не устанавливает
фиксированную метрику, как это было в протоколе RIP, а фиксировано задает
пять переменных, по которым протокол EIGRP в соответствии со своим алгоритмом сможет рассчитать метрику для перераспределенных маршрутов.
Маршрутизатор R2 получает маршруты до сетей получателей из N1 как
внешние маршруты протокола EIGRP, об этом свидетельствует административное расстояние, равное 170 и ярлык «EX», указывающий на механизм получения маршрута, как внешнего маршрута протокола EIGRP.
17.6 Настройка перераспределения маршрутной информации в протокол OSPF
Перераспределение маршрутной информации в протокол маршрутизации
OSPF осуществляется при помощи команды redistribute, синтаксис которой
приводится в примере 17.11. В таблице 17.6 приводятся описания частных параметров команды redistribute (OSPF).
289
Пример 17.11 – Синтаксис команды redistribute (OSPF)
(config-router)#redistribute protocol [process-id] [as-number] [metric metricvalue] [metric-type type-value] [match route-type] [metric metric-value][tag
tag-value] [route-map map-tag] [subnets]
(config-router)# no redistribute protocol [process-id] [as-number] [metric
metric-value] [metric-type type-value] [match route-type] [metric metricvalue][tag tag-value] [route-map map-tag] [subnets]
Таблица 17.6 – Частные параметры команды redistribute (OSPF)
Параметр
metric-type type-value
Описание
Тип внешнего маршрута OSPF, который будет присвоен перераспределенным маршрутам. По умолчанию тип 2.
Производить перераспределение
маршрутов до подсетей. Если данный
параметр не используется, в протокол
OSPF перераспределяются только
маршруты до классовых сетей.
subnets
r1#show ip route
172.16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
C
10.1.0.0/30 is directly connected , Serial0
O
10.1.4.16/28 [110/61] via 10.1.0.2, 01:22:18, Serial0
.. .. ..
Сеть N1, EIGRP
172 .16.0.0/16
Сеть N2, OSPF
10.0.0.0/8
E IG R P
OSP F
R1
R2
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
172.16.0.0/16 is variably subnetted , 10 subnets, 4 masks
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
C
10.1.0.0/30 is directly connected , Serial0
O
10.1.4.16/28 [110/11] via 10.1.2.2, 01:22:18, Serial2
.. .. ..
Рисунок 17.7 – Перераспределение маршрутной информации
в протокол OSPF
290
На рисунке 17.7 приводится пример настройки перераспределения маршрутной информации в протокол 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
единственно правильным способом объявлять группы пользовательских сетей
и сетей управления телекоммуникационным оборудованием в процесс маршрутизации, является способ описания данных сетей при помощи команд network. На рисунке 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.
Таблица 18.1 – Параметры команды passive-interface
Параметр
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-interface с ключом 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.
• список контроля доступа
2
♦ правило списка ACL
2;
♦ правило списка ACL
2;
♦ правило списка ACL
2.
• список контроля доступа
3
♦ правило списка ACL
3.
Рисунок 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-wildcard]
(config)# no access-list access-list-number
Описание параметров команды access-list приводиться в таблице 18.2.
Таблица 18.2 – Параметры команды access-list
Параметр
access-list-number
deny
permit
source
source-wildcard
Описание
Номер списка доступа, к которому
принадлежит описываемое правило.
Отбросить сеть получатель при положительном выполнении указанного
правила.
Пропустить сеть получатель при положительном выполнении указанного
правила.
IP адрес сети, с которой производится
сравнение.
Обратная маска сети, с которой производится сравнение.
Обратная маска (wildcard mask) представляет собой 32 битовую величину, которая разделена на четыре октета, каждый из которых состоит из восьми битов. Если в какой-либо позиции маски стоит бит, равный нулю, то соответствующий бит адреса должен быть проверен. Если же в какой-либо пози-
299
ции бит, равен единице, то соответствующий бит адреса должен быть
проигнорирован (Рисунок 18.7).
IP адрес
10 .
88.
25.
64
00001010 .01011000 .00011001 .01000000
0
0
0
0
0
.
.
.
.
.
0.
0.
0.
255.
1.
0.
0.
255.
255.
0.
0
255
255
255
255
Wildcard
00000000
00000000
00000000
00000000
00000000
.00000000
.00000000
.00000000
.11111111
.00000001
.00000000
.00000000
.11111111
.11111111
.00000000
.00000000
.11111111
.11111111
.11111111
.11111111
1 сеть получатель 10.88.25.64
Все возможные подсети 10.88.25.0/24
Все возможные подсети 10.88.0.0/16
Все возможные подсети 10.0.0.0/8
Все возможные подсети 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.
Таблица 18.3 – Параметры команды passive-interface
Параметр
standard
extended
access-list-name
Описание
Стандартный тип именованного
списка доступа.
Расширенный тип именованного
списка доступа. (Не применяется для
фильтрации маршрутных обновлений)
Имя списка доступа.
Описание параметров команд permit и deny приводиться в таблице 18.4.
Таблица 18.4 – Параметры команд permit и deny
Параметр
sequence-number
source
source-wildcard
Описание
Последовательный номер правила в
списке доступа.
IP адрес сети, с которой производится
сравнение.
Обратная маска сети, с которой производится сравнение.
Еще одной удобной особенностью именованных списков доступа, является возможность редактирования списков доступа, с возможностью добавления
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
> /2 4
1 0.1. 0.0/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 network/length | permit network/length} [ge ge-length] [le le-length]
(config)# no ip prefix-list {list-name | list-number} [seq number] {deny network/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
deny
network/length
permit
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 |interface-number]
(config)# no distribute-list [access-list-number | name| prefix-list {listname | list-number}]] | [route-map map-tag] in [interface-type interface-number]
304
Описание параметров команды приводиться в таблице 18.6.
Таблица 18.6 – Параметры команды distribute-list in
Параметр
access-list-number
name
list-name
list-number
route-map map-tag
interface-type interface-number
Описание
Номер списка доступа, который будет
применяться для фильтрации входящего маршрутного обновления.
Имя списка доступа, который будет
применяться для фильтрации входящего маршрутного обновления.
Имя списка префиксов, который будет
применяться для фильтрации входящего маршрутного обновления.
Номер списка префиксов, который будет применяться для фильтрации входящего маршрутного обновления.
Имя используемой маршрутной карты
при фильтрации маршрутных обновлений. Параметр применяется только для
протокола OSPF.
Тип и номер интерфейса маршрутизатора, к которому применяется правило
фильтрации. Если параметр не указан
правило фильтрации применяется ко
всем интерфейсам маршрутизатора, на
которых запущен соответствующий
протокол маршрутизации.
Синтаксис команды distribute-list out представлен в примере 18.8.
Пример 18.8 – Синтаксис команды distribute-list out
(config-router)# distribute-list {access-list-number | access-list-name | prefix-list {list-name | list-number}]} out [interface-name | routing-process |
as-number]
(config)# no distribute-list {access-list-number | access-list-name | prefixlist {list-name | list-number}]} out [interface-name | routing-process | asnumber]
Описание параметров команды приводиться в таблице 18.7.
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
10.0.0.0/8
S0
172.16.0.0/16
R1
R2
192.168.1.0/24
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
!
access-list 1 permit 172.16.0.0 0.0.255.255
172.16.0.0/28
10.0.0.0/8
R1
S0
172.16.0.0/16
R2
R3
r2# show ip route
.. .. ..
172.16.0.0/28 is subnetted, 3 subnets
O
172.16.0.32 [110/60] via 172.16.0.18, 00:10:35, Serial1
C
172.16.0.16 is directly connected, Serial1
C
172.16.0.0 is directly connected, Serial0
r3# show ip route
.. .. ..
172.16.0.0/28 is subnetted, 3 subnets
O
172.16.0.32 is directly connected, Serial2
C
172.16.0.16 is directly connected, Serial1
C
172.16.0.0 [110/60] via 172.16.0.18, 00:10:35, Serial1
10.0.0.0/8 is variably subnetted, 30 subnets, 2 masks
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
172 .16.14.32/27
172 .16.14.64/27
17
2.
16
.1
4.
22
4/
30
172 .16.12.0/24
S0
172 .16.14.228 /30
30
2/
23
4.
1
.
16
2.
17
172.16.12.0/22
R2
R1
Центральный офис
172.16.0.0/16
172 .16.13.0/24
r1#
router eigrp 200
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
172.16.0.0/16
R1
RIP
192.168.1.0/24
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
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 2 permit 172.16.0.0 0.0.255.255
Рисунок 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
deny
permit
sequence-number
Описание
Имя маршрутной карты.
Отбросить сеть получатель при положительном выполнении выражения.
Пропустить сеть получатель при положительном выполнении выражения.
Порядковый номер выражения в
маршрутной карте.
Условия совпадения описываются внутри выражения маршрутной карты
с помощью команд группы match. Каждая из команд группы match применяется
для установления совпадения по определенному параметру сети получателя. В
примерах с 19.2 по 19.8 приводятся синтаксисы возможных команд группы
match, применяемых при перераспределении маршрутной информации.
Пример 19.2 – Синтаксис команды match interface
(config-route-map)# match interface interface-type interface-number [... interface-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-listnumber... | 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-number... | access-list-name...] | access-list-name [access-list-number...| access-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-listname}[...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-listname}[...access-list-number | ...access-list-name]
(config-route-map)# no match ip route-source {access-list-number | accesslist-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-number]}
(config-route-map)# no match metric {metric-value | external [+- deviationnumber]}
Команда 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
internal
external type-1
external type-2
Описание
Локальный маршрут протокола BGP.
Внутренний маршрут протоколов EIGRP или OSPF.
Внешний маршрут 1 типа OSPF.
Внешний маршрут 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
route-map DEMO permit 20
match n
set m
route-map DEMO permit 30
Да
Нет
n
Да
Нет
-
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
172 .16.0.0/16
192 .168 .1.0/24
192 .168 .2.0/24
192 .168 .4.0/24
192 .168 .4.0/24
192 .168 .5.0/24
Сеть N2, OSPF
10.0.0.0/8
R1
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
!
access-list 1 permit 192.168.1.0 0.0.0.255
access-list 2 permit 192.168.2.0 0.0.0.255
access-list 3 permit 172.16.0.0 0.0.255.255
Рисунок 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 precedence, которые изменяют параметры пакета, используемые механизмами 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
E1
0
10.10.0.0/3
S1
10.10.0.4/
30
E0
R1
R2
R3
r1#
interface ethernet 0
ip policy route -map speed
interface ethernet 1
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
!
access-list 1 permit 10.1.1.0 0.0.0.255
Рисунок 20.1 – Использование маршрутизации по политике
Для разделения трафика, была настроена маршрутная карта, которая
применена к входящему интерфейсу маршрутизатора R1. В данной маршрутной политике применена маршрутная карта с двумя выражениями. Первое
выражение если выполняется поставленное условие, устанавливает IP адрес
маршрутизатора R2, как IP адрес следующего маршрутизатора для обрабатываемого входного пакета, при этом пакет будет отправлен по скоростному каналу связи. Второе выражение маршрутной карты устанавливает для всех
остальных пакетов IP адрес маршрутизатора R3 как выходного маршрутизатора, при этом пакеты будут отправлены по низкоскоростному каналу связи.
В правиле отбора пакетов для передачи по скоростному каналу связи
перечислены IP адреса отправителей рассматриваемых пакетов.
20.4 Проверка маршрутизации по политикам
Для проверки маршрутизации по политикам используются команды из
группы команд show, такие как show ip policy и show ip local policy.
Данные команды выводят все маршрутные политики, настроенные на
маршрутизаторе. Информация, выводимая данными командами, представлена
в примере 20.8.
323
Пример 20.8 – Информация, выводимая командами show ip policy
r1# show ip policy
Interface
Local
Ethernet0/2
Route map
equal
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
(RIP)
IGP
(OSPF)
EGP
(BGP)
IGP
(EIGRP)
IGP
(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 и его Internet провайдера, означает, что 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 65500
AS 65520
EBGP Соседи
R1
R4
Рисунок 22.2 – IBGP и EBGP соседи в протоколе BGP
22.4 Маршрутизация по политикам
Протокол BGP позволяет принимать решения на уровне АС на основании политик. Такая установка политик, или правил маршрутизации, известна
как маршрутизация по политикам.
Протокол BGP позволяет задавать политики для определения того, как
данные будут проходить через автономную систему. Эти политики основываются на атрибутах, которые передаются в маршрутной информации и настраиваются непосредственно на маршрутизаторах.
Протокол BGP определяет, что BGP маршрутизатор может объявлять
одноранговым устройствам, находящимся в соседних автономных системах,
только те маршруты, которые он использует сам. Это правило отражает
поэтапную парадигму маршрутизации, повсеместно используемую в Internet в
настоящее время. Некоторые политики не поддерживаются поэтапной (hopby-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-discriminator).
Кроме того, для протокола BGP компания Cisco ввела новый атрибут –
атрибут «Вес» (WEIGHT).
Коды используемые в маршрутизаторах Cisco для обозначения типов
атрибутов представлены в таблице 22.1
333
Таблица 22.1 – Коды типов атрибутов
Атрибут
Код типа атрибута
Тип 1
Тип 2
Тип 3
Тип 4
Тип 5
Тип 6
Тип 7
Тип 8
Тип 9
Тип 10
ORIGIN
AS-PATH
NEXT-HOP
MED
LOCAL PREFERENCE
ATOMIC AGGREGATE
AGGREGATOR
COMMUNITY
ORIGINATOR-ID
CLUSTER LIST
22.5.3 Атрибут «Путь к AS»
Атрибут «Путь к AS» (AS-PATH) является стандартным обязательным
атрибутом. В случае, когда через автономную систему проходит пакет обновления маршрута, для этого пакета обновления подготавливается номер AS,
иными словами, он помещается в начало списка. В действительности атрибут
AS-PATH представляет собой список номеров автономных систем, которые
проходит маршрут на пути к получателю. При этом номер автономной системы, из которой маршрут был послан, помещается в конец списка.
AS 64520
192 .168 .2.0/24
AS 65500
192 .168 .1.0/24
R1
R2
R3
AS 65000
192 .168 .3.0/24
R4
Путь к сети 192 .168 .1.0/24
равен (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
EBGP Соседи
R3
R1
EBGP Соседи
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 Соседи
R1
EBGP Соседи
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-comparemed.
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 65250
AS 65000
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 < incomplete.
Шаг 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
R2
AS 65500
AS 65500
192 .168 .1.0/24
192 .168 .2.0/24
R3
R4
0
8.
16
2.
19
6
/1
.0
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 приводится в
примере 24.1.
Пример 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-number
Описание параметров команды neighbor remote-as приводиться в таблице 24.1.
Таблица 24.1 – Параметры команды neighbor remote-as
Параметр
ip-address
peer-group-name
as-number
Описание
IP адрес однорангового маршрутизатора.
имя одноранговой группы.
Номер автономной системы, которой
принадлежит описываемый маршрутизатор.
Значение, размещенное в параметре autonomous-system команды neighbor remote-as, определяет, является связь с соседями EBGP или IBGP сеансом.
Если параметр autonomous-system в команде router bgp идентично параметру в
команде neighbor remote-as, тогда протокол BGP инициирует внутренний сеанс. Если значения параметров не равны, протокол BGP инициирует внешний
сеанс
Для того чтобы отключить существующего BGP соседа или соседнюю
одноранговую группу, можно воспользоваться командой neighbor shutdown.
Чтобы активизировать прежде существовавшего соседа или соседнюю одноранговую группу, которая была отключена с помощью данной команды необходимо воспользоваться ей с ключом no.
351
Синтаксис команды neighbor shutdown для протокола BGP приводится в
примере 24.2.
Пример 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 соединения маршрутизатора с его соседями можно воспользоваться командой neighbor update-source.
Синтаксис команды neighbor update-source приводится в примере 24.3.
Пример 24.3 – Синтаксис команды neighbor update-source
(config-router)# neighbor {ip-address | peer-group-name} update-source interface-type interface-number
(config-router)# no neighbor {ip-address | peer-group-name} update-source interface-type interface-number
Описание параметров команды neighbor remote-as приводиться в таблице 24.2.
Таблица 24.2 – Параметры команды neighbor update-source
Параметр
ip-address
peer-group-name
interface-type interface-number
Описание
IP адрес однорангового маршрутизатора.
Имя одноранговой группы.
Тип и номер используемого интерфейса.
352
Команда настройки маршрутизатора network предназначена для предоставления возможности протоколу BGP объявлять сеть, если она имеется в IP
таблице маршрутизации.
Синтаксис команды neighbor shutdown приводится в примере 24.4.
Пример 24.4 – Синтаксис команды network
(config-router)# network {network-number [mask network-mask]} [route-map maptag]
(config-router)# no network {network-number [mask network-mask]} [route-map
map-tag]
Описание параметров команды network приводиться в таблице 24.3.
Таблица 24.3 – Параметры команды network
Параметр
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
r2# router bgp 65000
neighbor 10.1.1.2 remote-as 64520
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. Синтаксис команды приводится
в примере 24.6.
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
summary-only
Описание
Описание объединенного адреса.
Генерирует информацию об AS пути
суммарного маршрута, включающего
все AS перечисленные во всех путях
всех маршрутов которые были суммарным маршрутом.
Задает режим объявления маршрутизатором только суммарного маршрута.
Команда aggregate-address применима к сетям, в которых BGP таблица
уже используется. Это отличается от требования к сетям при рассылке объявлений результатов суммирования командой BGP network, когда сеть уже
должна присутствовать в IP таблице маршрутизации. В этом случае агрегируемые сети должны присутствовать в BGP таблице.
При использовании этой команды без ключевого слова as-set агрегированный маршрут будет объявлен как приходящий из вашей автономной системы, и атрибут ATOMIC AGGREGATE будет установлен таким образом,
чтобы показать, что информации может недоставать. Атрибут ATOMIC
AGGREGATE установлен в том случае, если не задано ключевое слово as-set.
Без ключевого слова summary-only маршрутизатор может по-прежнему
объявлять индивидуальные сети. Это может пригодиться при наличии избыточных каналов к Internet провайдеру. Например, если один Internet провайдер рассылает в объявлениях только суммарные маршруты, в то время как
другой рассылает в объявлениях не только суммарные маршруты, но и
отдельные маршруты, отслеживаться будут эти отдельные маршруты. Если
же Internet провайдер, рассылающий объявления об отдельных маршрутах,
становится недоступным, тогда отслеживаться будут провайдеры, рассылающие в объявлениях только суммированные маршруты.
Только при использовании ключевого слова summary-only командой aggregate-address будет объявлен суммарный маршрут. Путь теперь будет отражать только просуммированные AS, причем любая другая информация о пу-
355
тях станет недоступной. При использовании в команде aggregate-address только ключевого слова as-set информация о пути будет включать номера автономных систем, если существовала команда с ключевым словом summaryonly, она будет удалена. Однако оба ключевых слова можно использовать в
одной команде одновременно; в результате чего будет рассылаться только
суммарный адрес и в маршрутной информации будут перечислены все автономные системы
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
Параметр
*
neighbor-address
soft
in
out
Описание
Сброс всех текущих BGP соседей.
Сброс выбранного BGP соседа.
Производит мягкий сброс BGP соседа.
Производит мягкий сброс входящих
соединений.
Производит мягкий сброс исходящих
соединений.
Команда clear ip bgp используется после каждого изменения настройки
для того, чтобы активизировать внесенные изменения и проинформировать о
них одноранговые маршрутизаторы.
Задавая мягкую перенастройку протокола BGP с помощью ключевого
слова soft, обеспечивается такой режим работы, когда сеансы протокола BGP
не сбрасываются, а маршрутизатор повторно возобновляет посылку всех пакетов обновления маршрутизации. Для генерирования новых входящих пакетов обновления без переустановки сеанса протокола BGP локальный BGPспикер должен сохранять все полученные пакеты обновления без изменения,
независимо от того, принят ли он в соответствии с входящей политикой или с
использованием конфигурационной команды маршрутизатора neighbor softreconfiguration. После первой настройки с помощью команды neighbor soft-re-
356
configuration очистите все текущие BGP-сеансы, чтобы все пакеты обновления были повторно пересланы всем соседям, а затем сохранены в локальном
маршрутизаторе. Этот процесс требует много памяти, и его желательно по
возможности избегать. Исходящая мягкая настройка протокола BGP не приводит к перегрузке памяти.
На рисунке 24.2 показан еще один пример сети, работающей под управлением протокола BGP.
AS 64520
172 .16.10.0/24
192 .168 .2.0/24
AS 65000
172 .16.20.0/24
172 .16.10.0/16
10.1.1.0/30
192 .168 .1.48/30
R1
R2
R3
r1# router bgp 64520
neighbor 10.1.1.1 remote-as 65000
network 172.16.0.0
r2# router bgp 65000
neighbor 10.1.1.2 remote-as 64520
neighbor 192.168.1.50 remote-as 65000
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. Однако после добавления команды aggregateaddress 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 Типы множественной адресации
Конфигурацию множественных соединений с провайдерами услуг Internet можно классифицировать в соответствии с маршрутами, имеющимися к
автономным системам провайдеров. Можно выделить три наиболее популярных способа настройки соединений.
– Все провайдеры 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 в зоне ответственности провайдера Internet и в других автономных системах.
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
R1
R2
Для сети 172 .16.0.0/16
атрибут local preference =800
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.
Пример 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
Параметр
ip-address
peer-group-name
number
Описание
IP адрес однорангового маршрутизатора.
Имя одноранговой группы.
Присваиваемое значение веса.
Конфигурационная команда маршрутизаторов bgp default local-preference предназначена для изменения значения атрибута 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 приводиться
в таблице 25.2.
364
Таблица 25.2 – Параметры команды bgp default local-preference
Параметр
ip-address
peer-group-name
number
Описание
IP адрес однорангового маршрутизатора.
Имя одноранговой группы.
Присваиваемое значение локального
приоритета.
По умолчанию значение атрибута 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
neighbor 10.10.10.2 remote-as 65000
neighbor 10.10.20.1 remote-as 65250
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
.0
10
10
.1
0.
20
.0
/3
0
0.
.1
10
0
/3
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
BGP table version is 7, local router ID is 172.16.10.1
Status codes: s suppressed, d damped, h history,* valid, > best,
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric
LocPrf
Weight
*> 10.10.10.0/24 0.0.0.0
0
32768
*> 10.10.20.0/24 0.0.0.0
0
32768
* 172.20.0.0
10.10.20.1
0
*>
10.10.10.2 0
0
*> 172.25.0.0
10.10.10.2
0
*
10.10.20.1
0
* 172.30.0.0
10.10.10.2
0
*>
10.10.20.1 0
0
i - internal
Path
i
i
65250
65000
65000
65250
65000
65250
65000
i
65500
65500
65250
i
i
1
i
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 remote-as 65000
neighbor 10.10.10.2 weight 100
neighbor 10.10.20.1 remote-as 65250
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
BGP table version is 7, local router ID is 172.16.10.1
Status codes: s suppressed, d damped, h history,* valid, > best,
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric
LocPrf
Weight
*> 10.10.10.0/24 0.0.0.0
0
32768
*> 10.10.20.0/24 0.0.0.0
0
32768
* 172.20.0.0
10.10.20.1
150
0
*>
10.10.10.2 0
100
0
*> 172.25.0.0
10.10.10.2
150
0
*
10.10.20.1
100
0
* 172.30.0.0
10.10.10.2
150
0
*>
10.10.20.1 0
100
0
i - internal
Path
i
i
65250
65000
65000
65250
65000
65250
65000
i
65500
65500
65250
i
i
1
i
i
368
Заключение
Сетевые специалисты утверждают, что 50% знаний в этой динамичной
области техники полностью устаревают за 10 лет. Можно, конечно, спорить о
точном количестве лет и процентов, но факт остается фактом: набор базовых
технологий, представления о перспективности той или иной технологии, подходы и методы решения ключевых задач и даже понятия о том, какие задачи
при создании корпоративных сетей являются ключевыми – все это изменяется очень быстро и часто неожиданно. И примеров, подтверждающих такое положение дел, можно привести достаточно много.
Еще не так давно казалось, что протокол RIP будет постоянно самым
распространенным протоколом маршрутизации. Это было связано, прежде
всего, с его простотой и минимальными требованиями к вычислительным ресурсам маршрутизаторов.
Однако прошло совсем немного времени, и протокол RIP сдал свои позиции более интеллектуальным протоколам маршрутизации, таким как EIGRP и OSPF. Данные протоколы позволяют осуществлять более качественную маршрутизацию трафика, снимают ограничения по размерам сети передачи данных. А их недостатки, такие как значительные требования, к ресурсам маршрутизаторов, компенсируются техническими возможностями современных маршрутизаторов и коммутаторов третьего уровня.
Но, несмотря на обилие примеров, нельзя абсолютизировать изменчивость сетевых технологий. Ведь остаются «другие» 50% - это те знания о сетях передачи данных, которые составляют фундамент образования сетевого
специалиста. Несмотря на свою изменчивость, протоколы маршрутизации используют в своей работе математические задачи и алгоритмы которые были
доказаны и разработаны на заре эры компьютерных сетей.
369
Словарь терминов
A
ААА. См. аутентификация, авторизация и учет.
АСК. 1. Бит подтверждения в сегменте TCP. 2. См. подтверждение (acknowledgment).
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 Algorithm, SPF). Алгоритм маршрутизации, включающий в связное дерево в
первую очередь кратчайшие маршруты. Иногда называется алгоритмом
Дейкстра (Dijkstra).
Алгоритм диффузионного обновления (Diffusing Update Algorithm,
DUAL). Алгоритм сходимости, используемый в расширенном протоколе
IGRP. Обеспечивает отсутствие циклов на протяжении всего маршрута. Позволяет маршрутизаторам, задействованным в изменении топологии, проводить синхронизацию одновременно, не затрагивая маршрутизаторы, на которые не повлияли изменения.
Алгоритм маршрутизации Беллмана-Форда (Bellman-Ford routing algorithm). См. алгоритм дистанционно-векторной маршрутизации.
Алгоритм маршрутизации по состоянию канала (link-state routing algorithm). Алгоритм маршрутизации, в котором каждый маршрутизатор передает в широковещательном режиме информацию, учитывая стоимость достижения соседних маршрутизаторов для всех узлов объединенной сети.
Американский реестр адресов 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 и может быть постоянным (permanent, 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 Protocol, 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 routing 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) или каналам связи (transmission 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 Organization 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 Access, 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 redistribution).
Переход (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-terminating 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 model). Архитектурная модель сети, разработанная 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 Systems, 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. –
Network Working Group, 1994. – 17 p.
17. RFC 1721. Malkin G. / RIP Version 2 Protocol Analysis / G. Malkin. –
Network Working Group, 1994. – 4 p.
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 Working Group, 1996. – 9 p.
24. RFC 1930. Hawkinson J. / Guidelines for creation, selection, and registration of an Autonomous System (AS) / J. Hawkinson, T. Bates. – Network Working 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. –
Network Working Group, 1998. – 15 p.
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