М.В. ДИБРОВ МАРШРУТИЗАТОРЫ Учебное пособие Красноярск 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 суммируются в таблицах маршрутизации, чт