|
|
4.4.11.7 Маршрутная политика Семенов Ю.А. (ГНЦ ИТЭФ) |
|
Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики: оповещение (announce) и Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (AS) может работать только один внутренний протокол маршрутизации (IGP), а обмен маршрутной информацией между автономными системами происходит в соответствии с внешним протоколом маршрутизации (EGP). Эта идея продемонстрирована на рис. 4.4.11.4.1. ЭВМ (или узлы) A1,B1,C1,D1 и маршрутизатор G-1 составляют одну автономную систему, а A2,B2,C2,D2,E2 и маршрутизатор G-2 - вторую.
Рис. 4.4.11.4.1. Схема связи автономных систем Пусть имеются две автономные системы ASX и ASY, обменивающиеся маршрутной информацией. ASX знает, как можно достичь сети Net1, которая может и не принадлежать ASX. Аналогично ASY знает, как послать пакет для сети Net2. net1 .... ASX <----> ASY ...... Net2 Для того чтобы пакеты попали из Net1 в Net2 через ASX и ASY, автономная система ASX должна анонсировать сеть Net1 автономной системе ASY, используя один из внешних протоколов маршрутизации (EGP или BGP), а ASY должна воспринять эту информацию и использовать. Предметом маршрутной политики в этом случае является решение ASX послать маршрутную информацию ASY, а также решение ASY эту информацию принять и использовать. Не существует никаких правил, которые бы вынуждали ASX и ASY к принятию таких решений. Таким образом, протокол маршрутизации определяет формат маршрутной информации, способ ее пересылки и хранения, но решения о ее посылке той или иной AS, а также решение об использовании маршрутной информации, поступающей извне остаются в руках администратора AS. Так как все существующие протоколы маршрутизации используют при работе с пакетами только адрес места назначения, разделить поток пакетов кроме как по этому параметру не возможно. Если пакеты с одним и тем же адресом места назначения попали в общий маршрутизатор, AS или канал связи, они обречены далее двигаться вместе. Особый случай составляет топология, при которой две as имеют много возможных маршрутов связи с различными политиками маршрутизации.
Рис. 4.4.11.4.2 Под каналом в данном случае подразумевается любая среда коммуникации - Ethernet, FDDI и т.д.. Может так случиться, что AS2 предпочитает использовать канал 2 только для обмена с AS4. А канал 1 используется для связи с AS3 и в качестве резервного маршрута (back-up) к AS4 в случае выхода из строя канала 2. Для описания маршрутной политики используются атрибуты interas-in и interas-out. Эти атрибуты позволяют описать локальные решения AS, основанные на ее предпочтениях, так как это делается в протоколах BGP-4 или IGRP. Пример такого описания представлен ниже: aut-num: AS2 - (номер автономной системы, формат: as-in: from AS3 10 accept AS3 AS4 (описание воспринимаемой маршрутной информации от других AS-партнеров. Формат описания: from Маршрутная политика (<выражение маршрутной политики>) может иметь следующие форматы.
Приоритеты операторов распределены в следующем порядке: для оператора () слева направо; для NOT - справа на лево; для AND и OR - слева направо. В отсутствии логических операторов элементы списка (AS, AS-макро, объединения и списки маршрутов) предполагаются объединенными оператором OR. as-out: to AS3 announce AS1 AS2 (описание сформированной маршрутной информации, рассылаемой другим AS-партнерам). Формат описания: to interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5) accept AS3 interas-in: описывает локальные предпочтения для соединений с другими AS. Это описание имеет формат: from Ключевые слова from (от) и accept (воспринимает) могут отсутствовать. Предпочтение описывается, как <стоимость> - положительное число, служащее выражением относительной ценности исследуемых маршрутов. Чем меньше <стоимость> - тем предпочтительнее маршрут. <стоимость> имеет смысл при сравнении атрибутов interas-in и совершенно не применима для сравнения с атрибутами as-in. Любой маршрут, описанный в interas-in и неупомянутый в AS-IN, предполагается отвергнутым. Система диагностики выдаст при этом сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как as-out и as-in. Если мы рассмотрим соответствующие атрибуты interas-out для AS3, то увидим следующее: aut-num: AS3 Оператор interas-out: имеет формат: to aut-num> <местный-rid> <соседний-rid> [<метрика>] Ключевые слова IN и announce могут и отсутствовать. Остальные фрагменты оператора идентичны описанным выше. <метрика> является необязательным параметром и описывается как: ( Атрибут as-exclude отмечает список транзитных AS, маршруты через которые должны быть исключены из рассмотрения. Формат использования: exclude Атрибут default указывает на маршрут по умолчанию. Формат атрибута: где aut-num: AS786 Здесь присутствует as-macro с именем AS-EBONE, описание которого может выглядеть как: as-macro: AS-EBONE (имя AS-макро) В результате описание маршрутной политики будет выглядеть как: aut-num: AS786 Community - это группа маршрутов, которые не могут быть представлены одной AS или группой AS. Это может быть полезно при описании доступа к супер-ЭВМ, это может быть группа маршрутов, используемых для специальных целей, возможно объединение в группу для получения сетевой статистики. Такие группы не обмениваются маршрутной информацией. Группа Community может использоваться в качестве объекта маршрутной политики автономных систем. Примерами объектов типа community могут служить HEPNET (объединение сетей для физики высоких энергий), NSFNET (Национальная Научная сеть США), опорная московская оптоволоконная сеть. Существует еще несколько атрибутов, которые помогают получить вспомогательную информацию. Более детальное описание форматов и алгоритмов решения проблем реализации различных политик маршрутизации читатель может найти в ссылке в начале раздела. |
Previous:
4.4.11.6 Автономные системы
UP:
4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
|
