← Cloudflare Magic Transit / magic-transit / how-to

Анонсирование префиксов

Вы можете использовать в Magic Transit собственные публичные IP-адреса, подключив их к Cloudflare. Это также называется bring your own IP (BYOIP). Этот процесс включает два отдельных типа префиксов:

1. IP-префиксы: Для каждого блока IP-адресов, который вы переносите в Cloudflare, требуется запись IP-префикса. IP-префикс включает разрешение (Letter of Agency (LOA)) который позволяет Cloudflare анонсировать сеть или её подсети. Вы также можете задать необязательный Номер автономной системы (ASN) ↗ для включения в анонсируемый нами AS path.
2. BGP-префиксы: Они определяют, какие префиксы Cloudflare анонсирует из своей глобальной сети. По умолчанию каждому IP-префиксу соответствует один BGP-префикс. Вы можете настроить дополнительные, более специфичные BGP-префиксы (подсети IP-префикса), вплоть до максимальной длины префикса /24.

Cloudflare подсчитывает количество префиксов Magic Transit исходя из числа определенных вами BGP-префиксов. Каждый префикс тарифицируется отдельно, даже если они перекрываются. Например, как /16 и любой /24 внутри него учитываются по отдельности. Подключение более крупного агрегированного префикса автоматически не включает его меньшие подсети для целей анонсирования или биллинга.

Ограничений по тарификации на размер принимаемых префиксов нет. Однако принимаются только префиксы размером до /24 принимаются для подключения, поскольку более длинные префиксы (например, /25, /26) не маршрутизируются глобально.

Укажите все IP-префиксы, которые вы планируете подключить, а также ASN, с которых будете их анонсировать. При указании префиксов соблюдайте следующие правила:

• Префиксы должны включать не менее 256 IP-адресов (/24 в формате CIDR (Бесклассовая междоменная маршрутизация ↗) нотации). Если вы не соответствуете /24 требованиям к длине префикса см. Использование IP-адреса Cloudflare.
• Записи Internet Routing Registry и LOA должны соответствовать префиксам и исходным префиксам, которые вы отправляете в Cloudflare.
• При использовании смежных префиксов по возможности указывайте агрегированные префиксы.
• При использовании Route Origin Authorizations (ROAs) для подписи маршрутов для инфраструктура открытых ключей для ресурсов (RPKI) ↗, префикс и исходный ASN должны совпадать с данными, указанными в заявке на подключение.
• Если у вас нет собственного ASN, можно использовать клиентский ASN Cloudflare (AS13335).

В рамках подключения префикса IP-адресов необходимо определить, какой ASN Cloudflare будет использовать для анонсирования ваших префиксов. Если вы указываете собственный ASN, Cloudflare добавляет основной ASN Cloudflare (AS13335) в начало BGP AS_PATH. Например, если ваш ASN AS64496, любой, кто устанавливает прямой пиринг с Cloudflare, видит путь как 13335 64496.

Если у вас нет ASN или вы не хотите переносить свой ASN в Cloudflare, вы можете использовать Cloudflare Customer ASN (AS13335).

BGP-префиксы представляют собой префиксы, которые Cloudflare анонсирует через anycast из глобальной сети Cloudflare. По умолчанию всегда есть хотя бы один BGP-префикс, идентичный подключённому префиксу IP-адресов.

Например, если вы подключаете /20 IP-префикс в Magic Transit, его можно анонсировать только как /20 потому что есть только стандартный /20 BGP-префикс. Более мелкие подпрефиксы (например, /24s) в пределах /20 нельзя анонсировать по отдельности, если они не настроены как отдельные BGP-префиксы.

Cloudflare предлагает несколько механизмов для управления анонсированием и отзывом on-demand-префиксов. Каждый метод подходит для своего сценария развертывания:

• Addressing API: Управляйте анонсированием префиксов вручную с помощью вызовов API. См. Анонсирование или отзыв BGP-префикса.
• Пиринг BGP с Route Reflectors: Управляйте анонсами через сессии BGP к глобально распределённым route reflector Cloudflare, либо через интернет, либо через подключение CNI с Dataplane v1. Если вам нужна эта функция, обратитесь к своей команде по работе с аккаунтом Cloudflare. См. Управление BGP с помощью Cloudflare Route Reflectors.
• Сетевой поток: Автоматически анонсируйте префиксы на основе заданных вами пороговых значений трафика, зафиксированных в вашей сети. См. Сетевой поток (ранее Magic Network Monitoring).
• Пиринг BGP с таблицей маршрутизации Magic Transit Virtual Network: Автоматически управляйте анонсированием префиксов на основе маршрутов BGP, полученных через CNI с Dataplane v2, либо через туннели GRE и IPsec (бета версия, требует Unified Routing). См. Управление BGP для таблицы маршрутизации Magic Transit Virtual Network.

Создайте Запрос POST чтобы добавить префикс BGP. Например:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes" \
	--request POST \
	--header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
	--header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
	--json '{
		"cidr": "192.0.2.0/24"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
	--header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
	--json '{
		"on_demand": {
				"advertised": true
		}
	}'

Префикс можно удалить только со статусом Не утверждено статус. Чтобы удалить префиксы с другим статусом, обратитесь к администратору или менеджеру по работе с клиентами.

1. Перейдите в Маршруты страницу.

2. Из раздела IP-префиксы вкладке найдите префикс, который хотите изменить, и выберите Удалить.
3. Подтвердите выбор в модальном окне, выбрав Удалить.

Используйте Addressing API для управления количеством добавлений Cloudflare своего номера автономной системы (ASN) к префиксу. Вы можете добавить AS13335 не более трёх раз в AS_PATH обновлений BGP для ваших префиксов.

Ниже приведён пример трёхкратного добавления AS13335 в начало AS-пути для BGP-префикса:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
	--header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
	--json '{
		"asn_prepend_count": 3
	}'

AS prepending помогает плавно переносить трафик между сетевыми провайдерами. Добавляя prepend к анонсу Cloudflare, вы делаете маршрут через Cloudflare менее предпочтительным для некоторых интернет-провайдеров. Это позволяет одновременно анонсировать тот же префикс от альтернативного провайдера с более коротким и предпочтительным AS_PATH. Одновременное анонсирование от обоих провайдеров обеспечивает более плавную миграцию трафика и минимизирует потерю пакетов при смене провайдера.

"asn_prepend_count" параметр принимает значения от 0 к 3. Более высокое значение делает маршрут менее предпочтительным. Вы также можете изменить этот параметр через BGP. См. Использование BGP-сообществ для настройки AS prepend на anycast-префиксе.

При использовании AS prepending для переноса трафика с Magic Transit обычно происходит следующая последовательность событий:

• Исходное состояние: Cloudflare анонсирует ваш префикс с приоритетом по умолчанию ("asn_prepend_count": 0). Cloudflare направляет весь трафик в вашу сеть через глобальную сеть Cloudflare.
• Понизить приоритет Cloudflare: вы обновляете префикс через API, чтобы задать количество AS prepend (например, "asn_prepend_count": 3). Теперь Cloudflare анонсирует ваш префикс с более длинным AS_PATH. Внешние сети обновят свои таблицы BGP, чтобы учесть, что путь Cloudflare теперь имеет новый, более длинный AS_PATH.
• Подключить нового провайдера: вы начинаете анонсировать тот же префикс от альтернативного провайдера со стандартным (более коротким) AS_PATH.
• Итоговое состояние: Теперь внешние сети получают два анонса: маршрут через Cloudflare с prepend и маршрут без prepend через вашего нового провайдера. Внешняя сеть выберет путь в соответствии со своими правилами политики BGP.

Когда вы готовитесь прекратить приём трафика для Использование собственного IP (BYOIP) префикс с периферийной сети Cloudflare, прямой отзыв маршрута BGP несёт риск появления зависшего маршрута BGP. Такое состояние возникает, когда маршрут зависает в Зона без маршрута по умолчанию (DFZ) ↗. Магистральные маршрутизаторы, которые не получили анонс отзыва маршрута, продолжают направлять трафик на уже неактивный next-hop, это явление известно как blackhole. Подробнее об этом можно прочитать в нашем блоге BGP-зомби и избыточный path hunting ↗.

Этот риск особенно заметен в сценарии, где глобальная таблица маршрутизации использует откат от более специфичных префиксов к менее специфичным. Поскольку такой механизм отката крайне подвержен нестабильности маршрутов, Cloudflare рекомендует поэтапный процесс вывода трафика.

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

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

1. Инициировать анонсирование из вашей исходной сети: Начните анонсировать префикс той же длины (например, 192.0.2.0/24) от вашей локальной инфраструктуры к вышестоящим интернет-провайдерам (ISP). Это действие добавляет в глобальную таблицу маршрутизации конкурирующий маршрут той же длины. Механизм выбора лучшего пути BGP отдаст предпочтение вашему исходному маршруту на основании других метрик (например, более короткого AS path или local preference), в результате чего трафик начнёт постепенно уходить от периферийной сети Cloudflare. Обратите внимание, что часть вашего трафика может маршрутизироваться не так, как ожидается, поскольку это зависит от того, какие маршруты предпочитает ваш интернет-провайдер (например, маршрут Cloudflare может считаться менее предпочтительным, если он отозван не полностью).

2. Дождитесь глобальной конвергенции BGP: Подождите некоторое время (обычно от пяти до десяти минут), пока новый нативный анонс полностью не распространится по глобальной таблице маршрутизации и маршруты не сойдутся. Этот период ожидания гарантирует, что большая часть трафика перейдёт на вашу локальную сеть до перехода к следующему шагу.

3. Сигнализируйте об отзыве BGP-маршрута из периферийной сети Cloudflare: После того как вы убедитесь, что трафик успешно перенаправлен, используйте один из методов управления BGP, чтобы прекратить анонсирование префикса с edge-сети Cloudflare.

4. Процесс дренирования завершён.

Если используется CNI с Dataplane v2, GRE- или IPsec-туннели, можно:

• Автоматически отзывать ваши префиксы из глобальной периферийной инфраструктуры Cloudflare, когда вы отзываете из таблицы маршрутизации Magic Transit Virtual Network все совпадающие префиксы, полученные по BGP.
• Автоматически анонсировать ваши префиксы через глобальную периферийную инфраструктуру Cloudflare, если в таблице маршрутизации Magic Transit Virtual Network есть хотя бы один совпадающий префикс, полученный по BGP.

Чтобы включить автоматическое глобальное анонсирование и отзыв, включите эту функцию для BGP-префикса с помощью Addressing API. Например:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "X-Auth-Email: $CLOUDFLARE_EMAIL" \
	--header "X-Auth-Key: $CLOUDFLARE_API_KEY" \
	--json '{
		"auto_advertise_withdraw": true
	}'

После того как вы настроите это для BGP-префикса, Cloudflare применяет следующую логику:

• Если в таблице маршрутизации виртуальной сети Magic Transit нет ни одного маршрута BGP, точно совпадающего с префиксом BGP, Cloudflare отзывает этот префикс BGP.
• Если в таблице маршрутизации виртуальной сети Magic Transit есть хотя бы один маршрут BGP, точно совпадающий с префиксом BGP, Cloudflare анонсирует этот префикс BGP.

BGP-префикс Addressing API и BGP-маршрут таблицы маршрутизации Magic Transit Virtual Network должны совпадать точно (одинаковые IP-префикс и длина префикса CIDR). Если существует действующий маршрут до подсети или надсети, Cloudflare отзывает BGP-префикс, если нет ни одного точно совпадающего BGP-маршрута Magic Transit Virtual Network.

В качестве альтернативы настройке AS prepends для anycast-префикса через API, вы можете использовать BGP community, чтобы контролировать количество AS prepend, которые Cloudflare анонсирует со своего edge для вашего префикса. Значения community:

• 13335:50101: Добавляет prepend один раз с ASN 13335
• 13335:50102: Добавляет prepend два раза с ASN 13335
• 13335:50103: Добавляет prepend три раза с ASN 13335

Если необходимо переключиться на альтернативного поставщика услуг, можно несколько раз добавить ASN Cloudflare в начало пути (prepend). Обычно это делается для того, чтобы сделать маршрут менее предпочтительным и обеспечить плавный переход к новому поставщику. Чем больше количество prepend, тем менее предпочтительным будет соединение Cloudflare при отсутствии других правил приоритизации.

См. предостережение об AS prepend для получения важной информации о поведении пиров при использовании этой функции.

Для сценариев развёртывания по требованию вы можете по желанию использовать BGP, чтобы управлять статусом анонсирования своего префикса в глобальной сети Cloudflare (анонсирован он или отозван). Управление через BGP работает так: вы устанавливаете BGP-сессии с глобально распределёнными Route Reflectors Cloudflare, которые запускают распространение анонса вашего префикса по всей глобальной сети Cloudflare. Пиринг с Route Reflectors Cloudflare возможен через интернет или CNI. Пиринг через CNI доступен через вашу команду по работе с клиентами.

Вы можете анонсировать префиксы из сети Cloudflare одним из поддерживаемых методов по требованию, например через BGP control, либо динамически через интерфейс, API или Сетевой поток. При подключении ваших префиксов по запросу укажите, нужен ли вам анонс, управляемый через BGP, или динамический анонс (через дашборд, API или Network Flow).

Наша сетевая архитектура использует несколько резервных Route Reflectors. Отказ любого отдельного reflector не влияет на общую отказоустойчивость сети или пересылку трафика. Для максимальной отказоустойчивости мы рекомендуем настроить пиринг со всеми тремя резервными Route Reflectors Cloudflare.

Чтобы начать использовать BGP control, обратитесь в свою команду по работе с аккаунтом и предоставьте следующую информацию:

• IP-адреса конечных точек BGP
• Префиксы для использования с BGP-управлением
• Ваш ASN для сессии BGP

После получения ваших данных Cloudflare обновит фильтры брандмауэра, чтобы установить BGP-сессию, и предоставит вам конечные точки BGP для управления префиксами.

В следующих примерах показаны конфигурации пиринга для Cisco IOS ↗ и Juniper Junos OS ↗ для развёртываний по требованию с использованием управления BGP. Используемые IP-адреса принадлежат route reflector Cloudflare, их следует оставить без изменений.

ip route {{ <YOUR-MAGIC-TRANSIT-PREFIX> }} Null0
ip prefix-list magic-transit-prefix seq 5 permit {{ <YOUR-MAGIC-TRANSIT-PREFIX> }}

route-map cloudflare-magic-transit-out permit 1
match ip address prefix-list magic-transit-prefix
!
route-map cloudflare-magic-transit-out deny 99

route-map reject-all deny 99

router bgp {{ <YOUR-ASN> }}
neighbor 141.101.67.22 remote-as 13335
neighbor 141.101.67.22 ebgp-multihop 64
neighbor 141.101.67.22 timers 60 900
neighbor 162.158.160.22 remote-as 13335
neighbor 162.158.160.22 ebgp-multihop 64
neighbor 162.158.160.22 timers 60 900
neighbor 173.245.63.66  remote-as 13335
neighbor 173.245.63.66  ebgp-multihop 64
neighbor 173.245.63.66  timers 60 900
!
address-family ipv4 unicast
redistribute static
neighbor 141.101.67.22 route-map cloudflare-magic-transit-out out
neighbor 141.101.67.22 route-map reject-all in
neighbor 162.158.160.22 route-map cloudflare-magic-transit-out out
neighbor 162.158.160.22 route-map reject-all in
neighbor 173.245.63.66  route-map cloudflare-magic-transit-out out
neighbor 173.245.63.66  route-map reject-all in
exit-address-family

set protocols bgp group CF_ROUTE_REFLECTORS neighbor 162.158.160.22 description "CF RR#1 SIN"
set protocols bgp group CF_ROUTE_REFLECTORS neighbor 173.245.63.66 description "CF RR#2 IAD"
set protocols bgp group CF_ROUTE_REFLECTORS neighbor 141.101.67.22 description "CF RR#3 CDG"
set protocols bgp group CF_ROUTE_REFLECTORS peer-as 13335
set protocols bgp group CF_ROUTE_REFLECTORS import REJECT-ALL
set protocols bgp group CF_ROUTE_REFLECTORS export BGP-CONTROL-OUT

set policy-options policy-statement REJECT-ALL then reject
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-filter 104.245.62.0/24 exact
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from protocol static
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-type internal
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> then accept
set policy-options policy-statement BGP-CONTROL-OUT then reject

@rtr01> show configuration routing-instances STAGE protocols bgp group CF_ROUTE_REFLECTORS
type external;
multihop {
    ttl 64;
}
local-address {{customer router IP}}
import NONE;
export NONE;
peer-as 13335;
local-as {{customer AS}} loops 2;
neighbor 162.158.160.22 {
    description "CF RR#1 SIN";
}
neighbor 173.245.63.66 {
    description "CF RR#2 IAD";
}
neighbor 141.101.67.22 {
    description "CF RR#3 CDG";
}

Если для передачи трафика в Magic Transit используется CNI с Dataplane v2, GRE- или IPsec-туннели, см. Информация о BGP чтобы узнать, как использовать BGP для маршрутизации трафика между Cloudflare и вашей сетью. Обратите внимание, что это отличается от использования BGP как способа управления статусом анонсирования вашего префикса.

Magic Transit поддерживает как статическую маршрутизацию, так и BGP для направления трафика из сети Cloudflare к настроенным off-ramp (туннели GRE, туннели IPsec или CNI). В настоящее время Cloudflare не поддерживает анонсирование маршрутов в целях traffic engineering. Чтобы снизить задержку на последнем участке пути, рекомендуется ограничивать маршруты по регионам.

У Cloudflare девять географических регионов:

Значение по умолчанию для регионов статических маршрутов: Все регионы. Настройте область применения для вашего трафика в Код региона раздел, когда добавление или редактирование статический маршрут.

См. Ограничение маршрутов конкретными регионами, где это описано подробнее.