Previous: 4.4.11.6 Автономные системы    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет
    Next: 4.4.11.8 Язык описания маршрутной политики RPSL

Содержанием политики маршрутизации являются правила обмена маршрутной информацией между автономными системами (RIPE-181.txt). Не следует путать "маршрутную политику" и просто "политику", между ними такое же различие, как между "милостивым государем" и "государем". Способы их описания разнятся столь же значительно. При описании обычной политики одной из главных задач является сокрытие истинных намерений, а одним из средств - многословие. При описании же маршрутной политики важна лаконичность и четкость. В Интернет для решения этой задачи выработан стандарт, краткое изложение которого на конкретных примерах будет приведено ниже. Объектами маршрутной политики являются автономные системы (AUT-NUM) и маршруты (route). Существует два акта маршрутной политики:

оповещение (announce) и
восприятие (accept).

Эти акты определяют взаимодействие с ближайшими соседями. Совокупность информации, выданной всеми маршрутизаторами региональной сети, описывает ее граф. Следует иметь в виду, что в пределах автономной системы (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<целое положительное число в интервале 1-65535>)

as-in: from AS3 10 accept AS3 AS4

(описание воспринимаемой маршрутной информации от других AS-партнеров. Формат описания:

from accept <выражение маршрутной политики>;
здесь - относится к AS-соседям; - положительное целое число, характеризующее относительную ценность маршрутов, чем меньше cost, тем предпочтительнее маршрут; ключевые слова from (от) и accept (воспринимает) могут отсутствовать.)

Маршрутная политика (<выражение маршрутной политики>) может иметь следующие форматы.

1. Список из одного или нескольких кодов AS, AS-макро или список маршрутов. Список маршрутов записывается в префиксной форме, в качестве разделителей используются запятые и фигурные скобки.
2. Список ключевых слов. В настоящее время определено ключевое слово ANY, которое говорит о том, что речь может идти о любых соседних AS.
3. Логическое выражение, включающее в себя объекты типа 1 или 2, объединенные операторами AND, OR, NOT, которые в данном случае, строго говоря, не являются Булевыми. Так например, AS1 OR AS2 означает все маршруты AS1 или AS2. Или AS1 AND HepNet означает маршрут AS1, принадлежащий объединению HepNet. NOT AS3 означает любой маршрут кроме маршрутов AS3.

Приоритеты операторов распределены в следующем порядке: для оператора () слева направо; для NOT - справа на лево; для AND и OR - слева направо.

В отсутствии логических операторов элементы списка (AS, AS-макро, объединения и списки маршрутов) предполагаются объединенными оператором OR.

as-out: to AS3 announce AS1 AS2

(описание сформированной маршрутной информации, рассылаемой другим AS-партнерам). Формат описания:

to announce <выражение маршрутной политики>;
ключевые слова to {указатель адресата} и announce
{указатель списка доступных AS} могут и отсутствовать.)
относится к AS-соседям.

interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref= 5) accept AS3
interas-in: from AS3 193.0.1.1/32 193.0.1.2/32 (pref=15) accept AS4
interas-in: from AS3 193.0.1.5/32 193.0.1.6/32 (pref=10) accept AS4
...

interas-in: описывает локальные предпочтения для соединений с другими AS. Это описание имеет формат:

from <местный-rid> <соседний-rid> <предпочтение>
accept <выражение маршрутной политики>

Ключевые слова from (от) и accept (воспринимает) могут отсутствовать. - автономная система, описанная в as-in. <местный-rid> - (идентификатор местного маршрутизатора) содержит IP-адрес пограничного маршрутизатора, политика которого описывается. <соседний-rid> содержит IP-адрес соседнего маршрутизатора, от которого воспринимается маршрутная информация, описанная в <выражении маршрутной политики>. IP-адреса имеют префиксный формат (описание префиксного формата см. выше в конце раздела 1.4.11.4 [бесклассовая интердоменная маршрутизация - CIDR]).

Предпочтение описывается, как = <значение>; ключевое слово должно обязательно присутствовать. В настоящее время стандарт поддерживает только один вид - "pref". <значение> может принимать один из следующих видов:

<стоимость> - положительное число, служащее выражением относительной ценности исследуемых маршрутов. Чем меньше <стоимость> - тем предпочтительнее маршрут. <стоимость> имеет смысл при сравнении атрибутов interas-in и совершенно не применима для сравнения с атрибутами as-in.

Любой маршрут, описанный в interas-in и неупомянутый в AS-IN, предполагается отвергнутым. Система диагностики выдаст при этом сигнал ошибки. Атрибуты interas-out сходны с interas-in, также как as-out и as-in.

Если мы рассмотрим соответствующие атрибуты interas-out для AS3, то увидим следующее:

aut-num: AS3
as-in: from AS2 10 accept AS1 A2
as-out: to AS2 announce AS3 AS4
interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=5) announce AS3
interas-out: to AS2 193.0.1.2/32 193.0.1.1/32 (metric-out=15) announce AS4
interas-out: to AS2 193.0.1.6/32 193.0.1.5/32 (metric-out=10) announce AS4
...

Оператор interas-out: имеет формат:

to aut-num> <местный-rid> <соседний-rid> [<метрика>]
announce <выражение маршрутной политики>

Ключевые слова IN и announce могут и отсутствовать. Остальные фрагменты оператора идентичны описанным выше.

<метрика> является необязательным параметром и описывается как:

(=<величина>), следует заметить, что в данном случае наличие скобок "()" и ключевого слова (тип метрики) обязательно. В настоящее время поддерживается только один тип метрики "metric-out". Параметр <величина> может иметь следующий вид:

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

Атрибут as-exclude отмечает список транзитных AS, маршруты через которые должны быть исключены из рассмотрения. Формат использования:

exclude to , ключевые слова exclude и to не являются обязательными. - описывает транзитные AS. В качестве можно использовать одно из:

, AS макро, ANY (любой) или community.

Атрибут default указывает на маршрут по умолчанию. Формат атрибута:

,

где указывает на AS-партнера, путь к которому и предлагается в качестве маршрута по умолчанию. Атрибут - положительное целое число, характеризующее уровень приоритета предлагаемого маршрута. AS-macro является удобным средством группировать автономные системы. AS-макро могут использоваться в <выражениях маршрутной политики> для атрибутов as-in и as-out. В качестве примера можно привести:

aut-num: AS786
as-in: from AS1755 100 accept AS-EBONE AND NOT AS1104
as-out: to AS1755 announce AS786
.......

Здесь присутствует as-macro с именем AS-EBONE, описание которого может выглядеть как:

as-macro: AS-EBONE (имя AS-макро)
descr: ASes routed by EBONE (AS, маршрутизируемые в EBONE)
as-list: AS2121 AS1104 AS2600 AS2122 (список AS)
as-list: AS1103 AS1755 AS2043
guardian: [email protected] (администратор EBONE)
......

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

aut-num: AS786
as-in: from AS1755 100 accept (AS2121 OR AS1104 OR AS2600 OR AS2122
as-in: from AS1755 100 accept AS1103 OR AS1755 OR AS2043)AND NOT AS1104
......

Community - это группа маршрутов, которые не могут быть представлены одной AS или группой AS. Это может быть полезно при описании доступа к супер-ЭВМ, это может быть группа маршрутов, используемых для специальных целей, возможно объединение в группу для получения сетевой статистики. Такие группы не обмениваются маршрутной информацией. Группа Community может использоваться в качестве объекта маршрутной политики автономных систем. Примерами объектов типа community могут служить HEPNET (объединение сетей для физики высоких энергий), NSFNET (Национальная Научная сеть США), опорная московская оптоволоконная сеть.

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

Previous: 4.4.11.6 Автономные системы    UP: 4.4.11 Протоколы маршрутизации (обзор, таблицы маршрутизации, вектор расстояния)
Down: 4.5 Процедуры Интернет    Next: 4.4.11.8 Язык описания маршрутной политики RPSL