[Документация Yandex Cloud](../../index.md) > [Yandex Cloud Router](../index.md) > [Сценарии использования](index.md) > Приоритизация трафика из on-premises по направлению (Active-Standby)

# Приоритизация трафика из On-Prem по направлению (Active-Standby)

Для приоритизации трафика по направлению в рамках услуги Cloud Interconnect можно использовать методы:

* [Longest Prefix Match (LPM)](#lpm1)
* [BGP AS-Path Prepend](#prepend1)

Метод Longest Prefix Match имеет больший приоритет в алгоритме выбора лучшего маршрута на маршрутизаторах по сравнению с методом BGP AS-Path Prepend. Рекомендуется выбрать только один из предложенных методов и не применять оба метода одновременно.

## Метод Longest Prefix Match (LPM) {#lpm1}

Ниже представлен пример схемы с приоритизацией трафика через два приватных соединения, организованных через две точки присутствия, с помощью метода Longest Prefix Match.

Короткий префикс из инфраструктуры клиента `10.0.0.0/8` анонсируется по протоколу BGP клиентским маршрутизатором через точку присутствия `NORD` в направлении Yandex Cloud.

Два длинных (более специфичных) префикса из инфраструктуры клиента `10.0.0.0/9` и `10.128.0.0/9` анонсируются по протоколу BGP клиентским маршрутизатором через точку присутствия `M9` в направлении Yandex Cloud.

![cic-routing-2](../../_assets/interconnect/cic-routing-2.svg)

Анонсы через точку присутствия `M9` будут восприниматься в Yandex Cloud как более специфичные (приоритетные).

Таким образом, для всего трафика из облачных подсетей `172.16.1.0/24`, `172.16.2.0/24` и `172.16.3.0/24` в направлении инфраструктуры клиента будет выбираться приватное подключение в направлении точки присутствия `M9`. В случае отказа данного подключения трафик будет автоматически переключен на приватное подключение в направлении точки присутствия `NORD`.


## Метод BGP AS-Path Prepend {#prepend1}

Ниже представлен пример схемы с приоритизацией трафика через два приватных соединения, организованных через две точки присутствия, с помощью метода BGP AS-Path Prepend.

Идея метода **BGP AS-Path Prepend** описана [в этом документе](https://datatracker.ietf.org/doc/html/rfc4271#section-5.1.2).

Префикс `10.0.0.0/8` анонсируется из инфраструктуры клиента по протоколу BGP клиентским маршрутизатором R1 через точку присутствия `M9` в направлении Yandex Cloud. По умолчанию значение атрибута BGP AS-Path будет равно `65001`, а длина пути AS-Path (количество значений номеров автономных систем) будет равна 1.

Этот же префикс `10.0.0.0/8` анонсируется из инфраструктуры клиента по протоколу BGP другим клиентским маршрутизатором R2 через точку присутствия `NORD` в направлении Yandex Cloud.

Перед тем как анонсировать префикс, политика BGP-маршрутизации на маршрутизаторе R2 добавляет номер автономной системы клиента (BGP ASN) в значение BGP-атрибута AS-Path, и оно станет равным `65001 65001`, а длина пути AS-Path станет равна 2. Это изменение делает префикс с такой длиной AS-Path менее предпочтительным для внешних BGP-маршрутизаторов.

![cic-routing-7](../../_assets/interconnect/cic-routing-7.svg)

Таким образом, со стороны Yandex Cloud для префикса `10.0.0.0/8` будет выбран наилучший маршрут через точку присутствия `M9`, а маршрут через точку присутствия `NORD` будет резервным, поскольку длина пути AS-Path у него будет больше.

Для всего трафика из облачных подсетей `172.16.1.0/24`, `172.16.2.0/24` и `172.16.3.0/24` в направлении инфраструктуры клиента будет выбираться приватное подключение в направлении точки присутствия `M9`. В случае отказа данного подключения трафик будет автоматически переключен на приватное подключение в направлении точки присутствия `NORD`.