Интегрированные сети ISDN
         

Атрибуты класса aut-num



Рисунок .23. Атрибуты класса aut-num

6.1. Атрибут import: Спецификация политики импорта

В RPSL политика импорта определяется двумя выражениями импортной политики. Каждое выражение импортной политики специфицируется с помощью атрибута import. Атрибут import имеет следующий синтаксис:

import: from <peering-1> [action <action-1>] . . .
  from <peering-N> [action <action-N>]
  accept <filter>

Спецификация действия является опционной. Семантика атрибута import выглядит следующим образом: набор маршрутов, который соответствует <filter> импортируется от всех партнеров в <peerings>, в то время как импортируемые маршруты <peering-M>, <>ction-M> реализуются.

Например



aut-num: AS1

import: from AS2 action pref = 1; accept { 128.9.0.0/16 }

Этот пример утверждает, что маршрут 128.9.0.0/16 воспринят от AS2 с предпочтением 1. Далее рассматривается спецификация действий (action).

6.1.1. Спецификация действия (Action)

Действия политики в RPSL устанавливают или модифицируют атрибуты маршрутов, таких как предпочтение маршрута, добавляет атрибут BGP community или устанавливает атрибут MULTI-EXIT-DISCRIMINATOR. Действия политики могут также инструктировать маршрутизаторы по выполнению специальных операций, таких как гашение осцилляций маршрутов.

Атрибуты маршрутной политики, чьи значения могут быть модифицированы посредством действий политики, специфицированы в словаре RPSL. Каждое действие при записи в RPSL завершаются символом точка с запятой (';'). Имеется возможность формировать составные действия политики путем последовательного их перечисления. В этом случае действия выполняются в порядке слева направо. Например,

aut-num: AS1

import: from AS2 action pref = 10; med = 0; community.append(10250, 3561:10);

  accept { 128.9.0.0/16 }

устанавливает pref = 0, med = 0, и затем добавляет 10250 и 3561:10 к атрибуту прохода community BGP. Атрибут pref является инверсным по отношению к атрибуту local-pref (т.e.
local-pref == 65535 - pref). Маршрут с атрибутом local- pref всегда предпочтительнее, чем без него.

aut-num: AS1

import: from AS2 action pref = 1;
from AS3 action pref = 2;
accept AS4
Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 с предпочтением 1 и от AS3 с предпочтением 2 (маршруты с более низкими предпочтениями имеют больший приоритет, чем с большими значениями).

aut-num: AS1

import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;
from AS2 action pref = 2;
accept AS4  
Выше приведенный пример утверждает, что маршруты AS4 получены от AS2 для направления 1.1.1.1-1.1.1.2 с предпочтением 1, а для любого другого направления от AS2 с предпочтением 2.



6.2. Атрибут export: Спецификация экспортной политики



Аналогично выражение экспортной политики специфицируется с помощью атрибута export. Атрибут export имеет следующий синтаксис:

export: to <peering-1> [action <action-1>]
. . .
to <peering-N> [action <action-N>]
announce <filter>
Спецификация действия является опционной. Семантика атрибута export выглядит следующим образом: набор маршрутов, который соответствует <filter> пересылается всем партнерам, специфицированным в <peerings>, в то время как экспортируемые маршруты из <peering-M>, <action-M> реализуются.

Например

aut-num: AS1

export: to AS2 action med = 5; community .= { 70 }; announce AS4

В этом примере, маршруты AS4 объявляются автономной системе AS2 со значением атрибута med, равным 5 и атрибута community = 70.

Пример:

aut-num: AS1

export: to AS-FOO announce ANY

В этом примере, AS1 объявляет все свои маршруты автономным системам AS из набора AS-FOO.



6.3. Другие маршрутные протоколы, мультипротокольные маршрутные протоколы и обмен маршрутами между протоколами



Более сложный синтаксис атрибутов import и export выглядит следующим образом:

import: [protocol <protocol-1>] [into <protocol-2>]

from <peering-1> [action <action-1>] . . .
from <peering-N> [action <action-N>] accept <filter>
<


/p> export: [protocol <protocol-1>] [into <protocol-2>]

to <peering-1> [action <action-1>] . . .
to <peering-N> [action <action-N>] announce <filter>
Этот синтаксис используется там, где при описании политики других протоколов маршрутизации могут использоваться спецификации опционных протоколов, или для введения маршрутов одного протокола в другой протокол, или для многопротокольной маршрутной политики. Корректные имена протоколов определены в словаре. <protocol-1> является именем протокола, чьими маршрутами производится обмен. <protocol-2> представляет собой имя протокола, который принимает данные об этих маршрутах. Как <protocol-1> так и <protocol-2> являются протоколами по умолчанию для IEGP (Internet Exterior Gateway Protocol), в настоящее время его функцию выполняет BGP. В последующем примере все маршруты interAS передаются протоколу RIP.

aut-num: AS1

import: from AS2 accept AS2

export: protocol BGP4 into RIP to AS1 announce ANY

В следующем примере, AS1 воспринимает маршруты AS2, включая любые адресные префиксы больше префиксов маршрутов AS2, но не передает эти дополнительные префиксы протоколу OSPF.

aut-num: AS1

import: from AS2 accept AS2^+

export: protocol BGP4 into OSPF to AS1 announce AS2

В следующем примере, AS1 передает свои статические маршруты (маршруты, которые являются членами набора AS1:RS-STATIC-ROUTES) маршрутному протоколу interAS и дважды добавляет AS1 к своему маршрутному набору AS.

aut-num: AS1

import: protocol STATIC into BGP4 from AS1 action aspath.prepend(AS1, AS1);
accept AS1:RS-STATIC-ROUTES
В следующем примере, AS1 воспринимает другой набор уникастных маршрутов для реверсивной мультикастной переадресации из AS2:

aut-num: AS1

import: from AS2 accept AS2

import: protocol IDMR

from AS2 accept AS2:RS-RPF-ROUTES



6.4. Разрешение неопределенности



Допускается, чтобы один и тот же обмен (peering) был описан в более чем одной спецификации партнерства в пределах выражения политики.


Например:

aut-num: AS1

import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 2;
from AS2 1.1.1.2 at 1.1.1.1 action pref = 1;
accept AS4
Это не ошибка, хотя такая запись определенно не желательна. Чтобы убрать неопределенность, используется действие (action), соответствующее первой спецификации партнерства. То есть маршруты воспринимаются с предпочтением, равным 2. Это правило называется правилом порядка спецификаций.

Рассмотрим пример:

aut-num: AS1

import: from AS2 action pref = 2;
from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5;
accept AS4
где обе спецификации партнерства перекрывают маршруты 1.1.1.1-1.1.1.2, хотя вторая спецификация более специфична. Здесь также используется правило порядка спецификаций, выполняется только действие (action) "pref = 2". В действительности, вторая пара пиринговых действий бесполезна, так как первая пара пиринговых действий покрывает действие второй. Если требуется политика, при которой эти маршруты воспринимались данным пирингом с предпочтением 1 и с предпочтением 2 для всех остальных пирингов, пользователь должен специфицировать следующее:

aut-num: AS1

import: from AS2 1.1.1.2 at 1.1.1.1 action pref = 1; dpa = 5;
from AS2 action pref = 2;
accept AS4  
Допускается также, чтобы более чем одно выражение политики покрывало один и тот же набор маршрутов в рамках одного пиринга. Например:

aut-num: AS1

import: from AS2 action pref = 2; accept AS4

import: from AS2 action pref = 1; accept AS4

В этом случае, также используется правило порядка спецификаций. То есть маршруты AS4 от AS2 воспринимаются с предпочтением 2. Если фильтры перекрываются, но не тождественны:

aut-num: AS1

import: from AS2 action pref = 2; accept AS4

import: from AS2 action pref = 1; accept AS4 OR AS5

маршруты AS4 воспринимаются от AS2 с предпочтением 2 и, тем не менее, маршруты AS5 также воспринимаются, но с предпочтением 1.

Ниже приведено общее правило порядка спецификации для разработчиков программ RPSL.


Рассмотрим два расширения политики:

aut-num: AS1

import: from peerings-1 action action-1 accept filter-1

import: from peerings-2 action action-2 accept filter-2

Вышеприведенные выражения политики эквивалентны следующим трем выражениям, где нет неопределенности:

aut-num: AS1

import: from peerings-1 action action-1 accept filter-1

import: from peerings-3 action action-2 accept filter-2 AND NOT filter-1

import: from peerings-4 action action-2 accept filter-2

где peerings-3 – это набор маршрутов, которые покрываются как peerings-1, так и peerings-2, а peerings-4 – набор маршрутов, которые покрываются peerings-2, но не покрываются peerings-1 ("filter-2 AND NOT filter-1" соответствует маршрутам, которые согласуются с filter-2, но не с filter-1).

Пример:

aut-num: AS1

import: from AS2 1.1.1.2 at 1.1.1.1
action pref = 2;
accept {128.9.0.0/16}
import: from AS2
action pref = 1;
accept {128.9.0.0/16, 75.0.0.0/8}
Рассмотрим два пиринга с AS2, 1.1.1.1-1.1.1.2 и 9.9.9.1- 2.2.2.2. Оба выражения политики покрывают 1.1.1.1-1.1.1.2. Для этого пиринга, маршрут 128.9.0.0/16 воспринимается с предпочтением 2, а маршрут 75.0.0.0/8 воспринимается с предпочтением 1. Пиринг 9.9.9.1-2.2.2.2 покрывается только вторым выражением политики. Следовательно, как маршрут 128.9.0.0/16 так и маршрут 75.0.0.0/8 воспринимаются с предпочтением 1 пирингом 9.9.9.1-2.2.2.2. Заметим, что аналогичное правило разрешения неопределенности применимо к выражениям политики по умолчанию и экспортной политики (рассылка маршрутной информации).



6.5. Атрибут default. Спецификация политики по умолчанию



Политика маршрутизации по умолчанию специфицируется с помощью атрибута default. Атрибут default имеет следующий синтаксис:

default: to <peering> [action <action>] [networks <filter>]

Спецификации <action> и <filter> являются опционными. Семантика выглядит следующим образом: Спецификация <peering> указывает на AS (и маршрутизатор, если он имеется) по умолчанию; спецификация <action>, если присутствует, указывает на различные атрибуты конфигурации по умолчанию.


Например, относительное предпочтение, если определено несколько маршрутов по умолчанию; а спецификация <filter>, если имеется, является фильтром политики. Маршрутизатор использует политику по умолчанию, если он получает от партнера маршруты, которые удовлетворяют требованиям фильтра <filter>.

В следующем примере, AS1 маршрутизируется по умолчанию через AS2.

aut-num: AS1

default: to AS2

В следующем примере, марштутизатор 1.1.1.1 в AS1 маршрутизуется по умолчанию через 1.1.1.2 в AS2.

aut-num: AS1

default: to AS2 1.1.1.2 at 1.1.1.1

В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и AS3, но предпочитает AS2, а не AS3.

aut-num: AS1

default: to AS2 action pref = 1;

default: to AS3 action pref = 2;

В следующем примере, AS1 маршрутизуется по умолчанию через AS2 и использует 128.9.0.0/16 в качестве сети по умолчанию.

aut-num: AS1

default: to AS2 networks { 128.9.0.0/16 }



6.6. Спецификация структурированной политики



Политики импорта и экспорта (рассылки и приема маршрутной информации) могут быть структурированы. Применение структурированной политики рекомендуется для продвинутых пользователей RPSL. Синтаксис спецификации структурированной политики выглядит следующим образом:

<import-factor> ::= from <peering-1> [action <action-1>]
. . .
from <peering-N> [action <action-N>]
accept <filter>;
<import-term> ::= <import-factor> |
LEFT-BRACE
<import-factor>
. . .
<import-factor>
RIGHT-BRACE
<import-expression> ::= <import-term> |
<import-term> EXCEPT <import-expression> |
<import-term> REFINE <import-expression>  
import: [protocol <protocol1>] [into <protocol2>]
<import-expression>
В конце <import-factor> должна быть точка с запятой. Если спецификация политики не структурирована эта точка с запятой является опционной. Синтаксис и семантика для <import-factor> определена в разделе 6.1. <import-term> представляет собой либо последовательность <import-factor>, заключенную в фигурные скобки, либо один <import-factor>.


Семантика <import-term> заключается в объединении <import-factor> с использованием правила порядка спецификаций. <import-expression> представляет собой либо один <import-term>, либо <import-term>, за которым следуют ключевые слова "except" и "refine", с завершающим <import-expression>. Заметим, что данное определение допускает вложенные выражения. Следовательно, могут существовать исключения к исключениям, уточнения к уточнениям или даже уточнения к исключениям и т.д.

Семантика для оператора except имеет вид. Результатом операции исключения является еще один член <import-term>. Результирующий набор политики содержит описание политики правой стороны, но его фильтры модифицированы так, что остаются только маршруты, соответствующие левой стороне. Политика левой стороны, в конце концов, включается, а ее фильтры модифицируются так, чтобы исключить маршруты, соответствующие левой стороне. Заметим, что фильтры модифицированы во время этого процесса, но действия скопированы один к одному. При нескольких уровнях вложения операции (принять или уточнить) выполняются справа налево.

Рассмотрим следующий пример:

import: from AS1 action pref = 1; accept as-foo;
except {
from AS2 action pref = 2; accept AS226;
except {
from AS3 action pref = 3; accept {128.9.0.0/16};
}

}

где маршрут 128.9.0.0/16 порождается AS226, а AS226 является членом набора AS as-foo. В этом примере, маршрут 128.9.0.0/16 воспринят от AS3, любой другой маршрут (не 128.9.0.0/16) порожденный AS226 воспринимается от AS2, и любые другие маршруты AS из as-foo получены от AS1. Можно прийти к тому же заключению, используя алгебраические выкладки, определенные выше. Рассмотрим спецификацию внутреннего исключения:

from AS2 action pref = 2; accept AS226;

except { from AS3 action pref = 3; accept {128.9.0.0/16};}

Эквивалентно

{ from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};

from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};}



Следовательно, исходное выражение эквивалентно:

import: from AS1 action pref = 1; accept as-foo;
except { from AS3 action pref = 3; accept AS226 AND {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16}; }
который эквивалентен

import: { from AS3 action pref = 3;
accept as-foo AND AS226 AND {128.9.0.0/16};
from AS2 action pref = 2;
accept as- foo AND AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1;
accept as-foo AND NOT
(AS226 AND NOT {128.9.0.0/16} OR AS226 AND {128.9.0.0/16}); }
Так как AS226 находится в as-foo и 128.9.0.0/16 заключен в AS226, выражение упрощается:

import: {
from AS3 action pref = 3; accept {128.9.0.0/16};
from AS2 action pref = 2; accept AS226 AND NOT {128.9.0.0/16};
from AS1 action pref = 1; accept as-foo AND NOT AS226;
}
В случае оператора refine, результирующий набор формируется с помощью декартова произведения для двух сторон следующим образом. Для каждой политики l левой стороны и для каждой политики r правой стороны, пиринг результирующей политики является пересечением множеств пирингов r и l. Фильтр результирующей политики соответствует пересечению фильтров l и r. Действие результирующей политики есть действие l, за которым следует действие r. Если общие пиринги отсутствуют, или если множество пересечения фильтров является пустым, результирующая политика не формируется. Рассмотрим следующий пример:

import: { from AS-ANY action pref = 1; accept community(3560:10);
from AS-ANY action pref = 2; accept community(3560:20);
} refine { from AS1 accept AS1;
from AS2 accept AS2;
from AS3 accept AS3; }
Здесь любому маршруту с community 3560:10 присваивается предпочтение 1 а любому маршруту с community 3560:20 присваивается предпочтение 2 вне зависимости от того, откуда они импортированы. Однако только маршруты AS1 импортированы из AS1, и только маршруты AS2 импортированы из AS2, и только маршруты AS3 импортированы из AS3, ни один маршрут не импортирован из каких-либо других AS.


К тому же заключению можно прийти, используя алгебраические методы, описанные выше. То есть, это пример эквивалентен:

import: {
from AS1 action pref = 1; accept community(3560:10) AND AS1;
from AS1 action pref = 2; accept community(3560:20) AND AS1;
from AS2 action pref = 1; accept community(3560:10) AND AS2;
from AS2 action pref = 2; accept community(3560:20) AND AS2;
from AS3 action pref = 1; accept community(3560:10) AND AS3;
from AS3 action pref = 2; accept community(3560:20) AND AS3; }
Рассмотрим следующий пример:

import: {
from AS-ANY action med = 0; accept {0.0.0.0/0^0-18};
  } refine {
from AS1 at 1.1.1.1 action pref = 1; accept AS1;
from AS1 action pref = 2; accept AS1; }
где воспринимаются только маршруты с длиной от 0 до 18, а значение med сделано равным 0, для того чтобы блокировать влияние med на все пиринги. Кроме того, из AS1 импортируются только маршруты AS1, а маршруты автономной системы AS1, импортированные от 1.1.1.1, предпочтительнее других пирингов. Это эквивалентно:

import: {
from AS1 at 1.1.1.1 action med=0; pref=1;
  accept {0.0.0.0/0^0-18} AND AS1;
from AS1 action med=0; pref=2;
  accept {0.0.0.0/0^0-18} AND AS1; }
Описанный выше синтаксис и семантика применима также к структурированным описаниям экспортной политики с ключевым словом "from", замененным на "to", а "accept" – на "announce".




Содержание раздела