Атрибуты класса 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);
устанавливает 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".
Содержание раздела