← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-wan / reference

Управление трафиком

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

Cloudflare Virtual Network представляет собой оверлейную виртуальную сеть, приватную для вашего аккаунта и охватывающую все дата-центры Cloudflare по всему миру. Эта оверлейная сеть обеспечивает:

• Доставка Magic Transit для Отказ в обслуживании (DoS) и Cloudflare Network Firewall отфильтрованный интернет-трафик от дата-центра входа, где трафик поступил в сеть, до вашей публично адресуемой граничной сети (edge/border network).
• Передача пакетов Cloudflare WAN между туннелями IPsec/GRE, интерконнектами, Cloudflare Load Balancer, а также Zero Trust подключения, такие как Cloudflare One Client, Remote Browser Isolation, Доступ, а также Gateway.

Cloudflare Virtual Network поддерживает маршрутизацию трафика Cloudflare WAN через anycast-туннели с использованием GRE и Internet Protocol Security (IPsec) или CNI с Dataplane v2. Вы можете добавлять записи в таблицу маршрутизации Cloudflare Virtual Network с помощью настройки статических маршрутов или маршрутов, полученных через пиринг BGP (beta). Также трафик может маршрутизироваться автоматически на основе отслеживаемого состояния потока.

В таблице маршрутизации Cloudflare Virtual Network разрешены следующие диапазоны адресов IPv4:

• RFC 1918 ↗ адресное пространство, а именно 10.0.0.0/8, 172.16.0.0/12, а также 192.168.0.0/16.

При совместном использовании Cloudflare WAN и Cloudflare Tunnel учитывайте диапазоны IP-адресов, используемые в статических маршрутах Cloudflare Tunnel, при выборе статических маршрутов для Cloudflare WAN. Дополнительную информацию см. в Cloudflare Tunnel.

По вопросам префиксов за пределами RFC 1918 обратитесь к своему менеджеру по обслуживанию клиентов Cloudflare.

Если трафик не соответствует ни одному маршруту, настроенному в виртуальной сети, Cloudflare применяет поведение по умолчанию в зависимости от типа адреса назначения:

• Публичные (доступные из интернета) адреса: Трафик выходит в интернет.
• Частные адреса (RFC 1918 ↗ или CGNAT/RFC 6598 ↗): трафик отбрасывается (null routing), так как приватные адреса не маршрутизируются в публичном интернете, а у Cloudflare нет пути для их доставки без подходящего маршрута.

Cloudflare WAN направляет трафик по маршрутам туннелей в соответствии с приоритетами маршрутных записей.

• Чем меньше значение, тем выше приоритет.
• Если значения приоритета для записей префикса совпадают, Cloudflare использует многопутевая маршрутизация с равной стоимостью (ECMP) переадресацию пакетов для маршрутизации трафика. Вы можете применить необязательное весовое значение к статическим маршрутам, чтобы изменить распределение туннелей ECMP.
• Маршрутизация Cloudflare применяет правило longest prefix match. Более специфичный статический маршрут (например, /30) всегда имеет приоритет над менее специфичным (например, /29), независимо от приоритета туннеля, если вы не удалите более специфичный маршрут.
• Когда у маршрутов BGP и статических маршрутов совпадают префикс и приоритет, Cloudflare соблюдает приоритет, отдавая предпочтение статическим маршрутам перед маршрутами BGP. Это гарантирует, что вручную настроенные статические маршруты сохраняют приоритет, если вы явно не понизите его для них.

Значение приоритета для статических маршрутов настраивается непосредственно как часть объекта маршрута в Cloudflare панели управления или через API. Например:

В этом примере туннели с приоритетом 100 имеют приоритет перед туннелями с приоритетом 200 так как меньшие значения имеют более высокий приоритет.

При необходимости можно назначить веса, чтобы эффективнее распределять трафик между несколькими туннелями. Значения веса определяют долю трафика: чем выше вес, тем больше трафика получает туннель. Максимальное значение веса составляет 256.

В следующем примере TUNNEL_2_IAD скорее всего, получит вдвое больше трафика, чем TUNNEL_1_IAD.

Помимо приоритета, привязка статических маршрутов к определённым географическим регионам также влияет на то, как направляется трафик. См. Ограничение маршрутов конкретными регионами для дополнительных сведений.

Когда BGP анонсирует маршрут, Cloudflare автоматически добавляет его в таблицу маршрутизации Cloudflare Virtual Network с приоритетом по умолчанию, равным 100 который применяется к все регионы. Однако если существует статический маршрут с тем же префиксом и приоритетом, статический маршрут всегда имеет приоритет над маршрутом BGP. Задайте другой приоритет для статических маршрутов (больше или меньше, чем 100) в зависимости от того, чему вы хотите отдать приоритет. Чем меньше значение, тем выше приоритет.

Кроме того, если существует несколько маршрутов BGP с одинаковой длиной префикса и приоритетом, ECMP распределяет трафик между ними, используя маршрутизация с равной стоимостью по нескольким путям (ECMP).

Cloudflare поддерживает traffic engineering с помощью BGP community и AS prepending. С помощью этих методов маршрутизации можно задавать приоритеты маршрутов и выполнять traffic engineering сразу через несколько интерконнектов.

Приоритет маршрута BGP по умолчанию равен 100. Этот базовый приоритет можно скорректировать с помощью community. Например, если маршрут помечен community 13335:60010 его приоритет установлен на 10. Это делает его приоритет выше значения по умолчанию, равного 100 так как более низким числовым значениям приоритета отдаётся предпочтение.

Для настройки базового приоритета маршрута поддерживаются следующие значения community:

• 13335:60010: Задайте базовый приоритет маршрута равным 10
• 13335:60050: Задайте базовый приоритет маршрута равным 50
• UNSET: Задайте базовый приоритет маршрута равным 100
• 13335:60150: Задайте базовый приоритет маршрута равным 150
• 13335:60200: Задайте базовый приоритет маршрута равным 200
• 13335:60901: Задайте базовый приоритет маршрута равным 501000
• 13335:60902: Задайте базовый приоритет маршрута равным 1001000

Указание нескольких community с базовым приоритетом в одном сообщении об обновлении префикса является ошибкой конфигурации. В этом случае Cloudflare отдаёт предпочтение наивысшему приоритету (наименьшему целочисленному значению).

За каждое дополнительное упоминание вашего ASN в полученном AS-пути Cloudflare добавляет 10 к базовому приоритету маршрута. При увеличении номера приоритета маршрут становится менее предпочтительным.

Например, если ваш ASN 65000 то BGP UPDATE к Cloudflare будет:

# No change to base priority.
AS_PATH: 65000 65200

# Add 10 to base priority for 1 prepend of 65000
AS_PATH: 65000 65000 65200

# Add 20 to base priority for 2 prepend of 65000
AS_PATH: 65000 65000 65000 65200

Cloudflare корректирует приоритет маршрута при использовании AS prepending с сообществами (communities). Например, если маршрут помечен 13335:60150, базовый приоритет устанавливается равным 150. Если вы дважды применяете prepend к своему ASN, Cloudflare добавляет 10 для каждого prepend, увеличивая приоритет маршрута до 180.

Automatic Return Routing (ARR) позволяет Cloudflare отслеживать сетевые потоки из подключенных к Cloudflare WAN (ранее Magic WAN) точек, обеспечивая маршрутизацию обратного трафика через то же соединение, по которому он был получен, без необходимости в статических или динамических маршрутах. Для этой функции требуется новый Режим Unified Routing (beta).

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

ARR предоставляет следующие преимущества:

• Устраняет необходимость в обратных маршрутах: Для поддерживаемых типов трафика, таких как новые TCP-соединения (TCP SYN), UDP и ICMP echo, Cloudflare WAN больше не требует записи в таблице маршрутизации для возврата трафика в исходный туннель или интерконнект.
• Обеспечивает симметричную маршрутизацию потоков: Ответы для заданного потока (например, TCP-сессии) возвращаются через то же WAN-подключение Cloudflare, через которое проходил исходный запрос. Это важно для межсетевых экранов с отслеживанием состояния и промежуточных устройств.
• Поддерживает перекрывающиеся диапазоны IP-адресов: Так как обратный путь привязан к изученному состоянию соединения, а не к префиксу назначения в таблице маршрутизации, функция Automatic Return Routing поддерживает сценарии, в которых разные площадки используют пересекающееся частное адресное пространство.
• Работает для каждого подключения: вы сами решаете, для каких туннелей IPsec / GRE или сетевых соединений использовать это поведение, включив эту функцию на каждом подключении.

Когда трафик, для которого доступна функция Automatic Return Routing (ARR), поступает по соединению с включенной ARR, Cloudflare WAN создает запись потока, которая фиксирует:

• IP-адреса источника и назначения
• Соответствующие порты или идентификаторы, в зависимости от протокола
• Подключение (туннель или Interconnect), через которое поступил трафик

Для всех последующих пакетов, соответствующих этому потоку и требующих следующего перехода, Cloudflare WAN:

1. Проверяет наличие соответствующего потока Automatic Return Routing.
2. Если совпадение найдено, пакет направляется обратно в то же соединение, в котором был изучен поток, вместо обращения к таблице маршрутизации Cloudflare Virtual Network.

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

Automatic Return Routing применяется в следующих случаях:

• Трафик поступает через туннель или сетевое соединение, для которого включена эта функция.
• Полученный трафик представляет собой один из следующих типов:
  • Новые TCP-подключения (TCP SYN)
  • UDP
  • ICMP echo-запросы (ping)
• Трафик предназначен для:
  • Исходящий интернет-трафик через Cloudflare
  • Cloudflare One Client
  • Частная сеть, подключённая к Cloudflare через Cloudflare Tunnel
  • Частная сеть, подключённая к Cloudflare через Cloudflare Mesh

В этом первом выпуске ARR не изменяет маршрутизацию трафика между подключениями Cloudflare WAN (например, трафика из одного туннеля IPsec/GRE или интерконнекта в другой). Такой трафик по-прежнему следует настроенным маршрутам Cloudflare WAN.

Режим Unified Routing представляет собой более новую плоскость данных Cloudflare One, которая использует единую инфраструктуру маршрутизации для всех поддерживаемых типов подключений. В режиме Unified Routing трафик направляется через Cloudflare One Client, Cloudflare Tunnel, IPsec, GRE и Cloudflare Network Interconnect (CNI) в рамках единой системы, что упрощает настройку подключений Cloudflare One.

В панели управления Cloudflare WAN режим маршрутизации отображается там же, где вы управляете маршрутами:

• Режим маршрутизации: Unified : ваш аккаунт работает на едином уровне данных и поддерживает новые функции маршрутизации.
• Режим маршрутизации: Legacy : ваш аккаунт использует предыдущий уровень данных и не поддерживает все функции единой маршрутизации.

Unified Routing представляет собой будущее выделенной overlay-сети, которая обеспечивает работу Magic Transit и сетевого подключения Cloudflare One.

У клиентов Cloudflare One есть несколько причин перейти на Unified Routing, поскольку это условие для ряда новых возможностей:

• Automatic Return Routing
• BGP через IPsec/GRE
• Исходные IP-адреса Cloudflare с использованием приватного IP-пространства с настраиваемым диапазоном IPv4
• Настраиваемые диапазоны IPv4 для Cloudflare One Client
• Поддержка IPv6
• Улучшена производительность между Cloudflare One Client и IPsec/GRE/CNI
• Поддержка Cloudflare Mesh и подключений IPsec/GRE/CNI в рамках одного аккаунта.

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

Unified Routing сейчас доступен в режиме closed beta. Чтобы зарегистрироваться:

• Существующие клиенты Cloudflare WAN или Magic Transit: Cloudflare рекомендует оценить новую функциональность применительно к вашему сценарию использования в непроизводственном аккаунте. Обратитесь в свою команду по работе с аккаунтом, чтобы включить Unified Routing.
• Новые клиенты: Обратитесь в свою команду по работе с аккаунтом, чтобы включить Unified Routing в рамках proof-of-concept для вашего сценария использования.

Если ваш аккаунт использует одновременно маршруты Zero Trust (Cloudflare Tunnel, Cloudflare Mesh) и маршруты WAN (IPsec, GRE, CNI), поведение выбора маршрута зависит от вашего режим маршрутизации.

Unified Routing использует единую маршрутизирующую fabric для всех типов подключений. Выбор маршрута последовательно применяет longest-prefix-match для всех типов трафика и способов подключения.

Если у маршрутов одинаковая длина префикса, маршруты Zero Trust имеют приоритет над маршрутами WAN.

Для сценариев с пересекающимся IP-пространством между площадками включите Automatic Return Routing чтобы обратный трафик достигал нужного источника.

Для аккаунтов, использующих Legacy Routing, выбор маршрута зависит от источника трафика.

Для аккаунтов, использующих только Zero Trust, трафик Cloudflare One Client маршрутизируется исключительно по таблице IP-маршрутизации Zero Trust, по принципу наиболее длинного совпадения префикса (longest-prefix-match).

Если в вашем аккаунте включен Cloudflare WAN, трафик от Cloudflare One Client следует той же логике выбора маршрута, что и трафик между сайтами через Gateway. Обратитесь в свою команду по работе с клиентами, если хотите, чтобы Cloudflare One Client продолжал вести себя так, будто WAN не включён.

Для трафика между подключениями WAN (IPsec к IPsec, GRE к GRE и CNI к CNI), не требующего фильтрации Gateway, в таблице маршрутизации WAN применяется правило наиболее длинного совпадения префикса. Такой трафик не взаимодействует с маршрутизацией Zero Trust.

Когда Политики Network Gateway применяются к трафику WAN между площадками, выбор маршрута выполняется по следующим правилам:

Устаревшая маршрутизация использует два компонента маршрутизации:

• маршрутизация Zero Trust (обрабатывает Cloudflare One Client, Cloudflare Tunnel и Cloudflare Mesh)
• Маршрутизация WAN (обрабатывает IPsec, GRE и CNI)

На межсистемный трафик распространяются те же правила, что и на трафик между сайтами через Gateway. Более специфичный маршрут Zero Trust работает корректно. Для более специфичного WAN-маршрута выбор не гарантирован.

Рекомендация: Если требуется перекрытие, перейдите на Unified Routing или обратитесь в команду по работе с аккаунтом.

Чтобы определить режим маршрутизации для вашей учетной записи:

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

2. Проверьте баннер в верхней части страницы:
   • Ваш аккаунт использует режим Unified Routing. : В вашем аккаунте используется Unified Routing.
   • Единая маршрутизация доступна. : В вашем аккаунте используется Legacy Routing.

Чтобы перейти на Unified Routing, обратитесь в свою команду по работе с аккаунтом.

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

Если вы ограничиваете маршрут регионом дата-центра Cloudflare, он отображается только в таблице маршрутизации Cloudflare Virtual Network этого региона вместе со всеми глобальными маршрутами, не имеющими региональной привязки. Логика приоритизации маршрутов и ECMP применяется как к маршрутам, привязанным к региону, так и к глобальным.

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

В следующей таблице приведён пример использования географической привязки для маршрутов:

Если для одного и того же префикса существует несколько маршрутов с одинаковым приоритетом и эти маршруты закреплены за разными географическими регионами (например, WNAM и ENAM), трафик, поступающий в сеть в конкретном регионе (например, в WNAM), выходит через маршрут, закреплённый за этим же регионом.

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

Настройте область действия для своего трафика в Код региона раздел при добавлении или изменении статического маршрута. См. Создать статический маршрут и Измените статический маршрут, где это описано подробнее.

Equal-cost multi-path routing использует хеши, рассчитанные на основе пакет ↗ данные для определения выбранного маршрута. Хеш всегда использует IP-адреса источника и назначения. Для пакетов TCP и UDP хеш также включает порты источника и назначения. Алгоритм ECMP делит хеш каждого пакета на количество равнозначных следующих переходов. Модуль (остаток от деления) определяет маршрут, по которому пойдет пакет.

Использование ECMP имеет ряд последствий:

• Маршрутизация по путям с одинаковой стоимостью выполняется по вероятностному принципу.
• Пакеты одной сессии с одинаковыми источником и назначением имеют одинаковый хеш. Такие пакеты также используют один и тот же следующий переход.
• Изменение числа равнозначных next hop может привести к тому, что трафик пойдёт через другие туннели. Например, к этому же может привести динамическая смена приоритетов, вызванная событиями проверки работоспособности.

Благодаря этому ECMP обеспечивает балансировку нагрузки между туннелями с одинаковым префиксом и приоритетом.

Эта диаграмма показывает, как ECMP равномерно распределяет трафик между двумя маршрутами с одинаковым префиксом и приоритетом.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has three tunnel routes, with traffic equally distributed across two paths.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z("Load balancing for some <br> priority tunnels uses ECMP <br> (hashing on src IP, dst IP, <br> scr port, dst port)") --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"GRE Tunnel 1 / <br> priority 1 / <br> ~50% of flows"/] --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/"GRE Tunnel 2 / <br> priority 1 / <br> ~50% of flows"/] --> J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/GRE Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 3}}

Отказ маршрутизатора клиента

Когда проверки работоспособности Cloudflare WAN показывают, что Tunnel 2 неработоспособен, Cloudflare WAN динамически понижает приоритет этого маршрута, и единственным маршрутом с наивысшим приоритетом остаётся Tunnel 1. В результате Cloudflare WAN направляет трафик в обход Tunnel 2, и весь трафик идёт через Tunnel 1.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has Tunnel 2 unhealthy, and all traffic prioritized to Tunnel 1.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Tunnel health is <br> determined by <br> health checks that <br> run from all Cloudflare <br> data centers) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"Tunnel 1 / <br> priority 1 / <br> ~100% of flows"/]:::green --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black

Сбой промежуточного интернет-провайдера (ISP)

Когда Cloudflare WAN определяет, что Tunnel 1 тоже неработоспособен, приоритет этого маршрута также понижается, и маршрут с наивысшим приоритетом остаётся только у Tunnel 3. В этом случае весь трафик направляется через Tunnel 3.

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has Tunnel 1 and 2 unhealthy, and all traffic prioritized to Tunnel 3.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Lower-priority tunnels <br> are used when <br> higher-priority tunnels <br> are unhealthy) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP]  -- Intermediary <br> network issue -->  F[/Tunnel 1 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP]  -- Intermediary <br> network issue -->  G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] -->  H[/Tunnel 3 / <br> priority 2 / <br> 100% of flows/]:::green --> K{{Customer <br> data center/ <br> network 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black

Когда Cloudflare WAN определяет, что Tunnel 1 и Tunnel 2 снова работоспособны, он пересматривает приоритеты этих маршрутов, и трафик возвращается к обычному распределению.

Поскольку ECMP работает по вероятностному принципу, алгоритм направляет через каждый туннель примерно одинаковое количество потоков. Однако при выборе туннеля для следующего пакета он не учитывает объём трафика, уже отправленного через этот туннель.

Например, рассмотрим сценарий с множеством TCP-соединений с очень низкой пропускной способностью и одним TCP-соединением с очень высокой пропускной способностью. Пакеты соединения с высокой пропускной способностью имеют одинаковый хеш и поэтому используют один и тот же туннель. В результате этот туннель задействует больше пропускной способности, чем остальные.

Использование пиринга BGP с таблицей маршрутизации Virtual Network в Cloudflare One или Magic Transit позволяет:

• Автоматизируйте процесс добавления и удаления сетей и подсетей.
• Используйте функции обнаружения сбоев и восстановления сессии.

С помощью этой функции вы можете:

• Установите сеанс eBGP между своими устройствами и службой Cloudflare WAN при подключении через туннели CNI, GRE или IPsec.
• Защитите сессию с помощью аутентификации MD5, чтобы избежать ошибок конфигурации.
• Динамически обменивайтесь маршрутами между вашими устройствами и таблицей маршрутизации Cloudflare Virtual Network.

В следующей таблице показана текущая доступность BGP для разных способов подключения и рекомендуемые сценарии использования.

Cloudflare Virtual Network принимает решение о маршрутизации каждого пакета за один проход в дата-центре Cloudflare, который первым обрабатывает этот пакет (ingress-узел). Благодаря этому даже при прохождении пакета через несколько узлов магистральной сети Cloudflare его путь для максимальной эффективности определяется уже в момент входа.

Ваша сессия BGP через IPsec, GRE или CNI устанавливается с дата-центром Cloudflare, ближайшим к вашему устройству BGP-пира. Маршруты, полученные таким образом, должны распространяться на всю глобальную сеть Cloudflare, чтобы определять маршрутизацию трафика по всей сети.

• Время сходимости: Глобальная конвергенция маршрутов обычно завершается в течение 20 секунд.
• Видимость: вы можете отслеживать изученные маршруты и статус их распространения через панель управления Cloudflare или API.

Cloudflare Virtual Network использует для распространения маршрутов централизованную плоскость управления, работающую по принципу, схожему с BGP Route Reflector. Такая архитектура отделяет физический сеанс BGP от глобального распространения маршрутов:

• Завершение сессии: Сессии пиринга BGP завершаются на периферийном узле Cloudflare, ближайшем к вашему маршрутизатору.
• Преобразование SDN: Входящие обновления BGP преобразуются в состояние программно-определяемой сети (SDN) и передаются централизованной функции ретрансляции.
• Глобальное распространение: Relay распространяет эти инструкции на все дата-центры Cloudflare по всему миру, обновляя локальную базу пересылки (FIB) на каждой площадке.

Data plane Cloudflare спроектирован с расчетом на высокую доступность. Если edge-локация теряет связь с централизованным relay, система переходит в Edge Resiliency Mode, имитируя поведение Non-Stop Forwarding (NSF):

• Непрерывность пересылки: Периферийные узлы продолжают маршрутизировать трафик, используя последнюю работоспособную таблицу пересылки (FIB). Трафик плоскости данных не прерывается.
• Удержание устаревших маршрутов: Так как в этом режиме FIB заморожена, решения о пересылке трафика остаются активными, даже если базовая сессия BGP с вашим маршрутизатором становится нестабильной или сбрасывается.
• Непрерывный мониторинг работоспособности: пока обновления BGP заморожены, проверки работоспособности туннеля продолжают выполняться. Они отправляются из всех дата-центров Cloudflare, поэтому периферия в любом входном узле может обнаружить обрыв физического соединения с вашим маршрутизатором. Если проверка работоспособности не проходит, входной узел на периферии снижает приоритет этого конкретного пути, чтобы трафик не терялся в никуда, несмотря на замороженное состояние маршрутизации.
• Заморозка обновлений: В этом состоянии глобальная плоскость управления заморожена. Новые обновления BGP, получаемые от вашего маршрутизатора, будут сохраняться локально на периферии и не будут распространяться глобально, пока не восстановится соединение с централизованным ретранслятором.

Как только соединение между периферией Cloudflare и централизованным ретранслятором восстанавливается, система автоматически выходит из режима Edge Resiliency и выполняет пересинхронизацию с отслеживанием состояния:

1. Синхронизация RIB-to-relay: Периферия Cloudflare передаёт на relay все текущие удерживаемые обновления BGP (текущее состояние RIB).
2. Глобальное обновление: Relay согласует эти обновления и распространяет любые изменения на остальную часть глобальной сети Cloudflare.
3. FIB unfreeze: Локальные таблицы пересылки на периферии Cloudflare размораживаются и обновляются последними проверенными инструкциями маршрутизации.

Пиринг BGP для Cloudflare WAN устанавливается с таблицей маршрутизации виртуальной сети Cloudflare (а не с глобальной интернет-сетью Cloudflare). Узлы BGP, настроенные по этому руководству, будут получать анонсы всех префиксов из таблицы маршрутизации виртуальной сети Cloudflare, а также любых дополнительных префиксов, настроенных в on-ramp Список анонсируемых префиксов.

Если вместо этого вы хотите настроить публичный пиринг с Cloudflare ASN 13335 в одном из дата-центров Cloudflare, см. Настройка PNI и пиринга. В настоящее время нельзя использовать пиринг BGP Cloudflare Virtual Network и PNI на одном физическом порту Interconnect.

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

Все маршруты в таблице маршрутизации Cloudflare Virtual Network анонсируются узлам BGP. Каждый узел BGP получает каждый маршрут префикса вместе с полным AS_PATH, с выбранной стороной Cloudflare ASN ↗ добавляется в начало, чтобы peer мог точно выполнить предотвращение петель ↗.

Сессии пиринга BGP могут анонсировать соседу доступные префиксы и отзывать ранее анонсированные префиксы. Это распространение занимает не более нескольких минут.

Cloudflare использует следующие таймеры, которые нельзя настроить:

• Таймер ожидания: Задаёт максимальное время, в течение которого BGP-пир ожидает получения сообщения keepalive, update или notification, прежде чем объявить сессию BGP неактивной. Cloudflare использует меньшее из двух значений: таймер ожидания по умолчанию и значение, полученное от пира в сообщении OPEN.
• Таймер Keepalive: Системы BGP обмениваются keepalive-сообщениями, чтобы определить, доступен ли пиринговый маршрутизатор. Если keepalive-сообщения не получены в течение таймера ожидания, сессия считается неактивной, что означает, что пир больше не доступен на уровне протокола BGP.
• Таймер Graceful Restart: Показывает, сколько времени маршрутизатор ожидает, пока peer восстановит сессию BGP после инициирования graceful restart. Если peer не переподключается за это время, маршрутизатор объявляет сессию неактивной (down) и удаляет устаревшие маршруты.

BGP multipath поддерживается. Если BGP получает один и тот же префикс через два разных интерконнекта, Cloudflare распределяет трафик, предназначенный для этого префикса, по каждому интерконнекту в соответствии со стандартным поведением ECMP.

BGP Graceful Restart поддерживается в пассивном режиме (helper/aware). Cloudflare сохраняет состояние пересылки для перезапускающегося соседа.

В настоящее время поддержка BGP имеет следующие ограничения:

• ASN аккаунта Cloudflare и ASN вашего устройства должны отличаться. Поддерживается только eBGP.
• Cloudflare всегда добавляет маршруты с приоритетом 100.
• Bidirectional Forwarding Detection (BFD) не поддерживается.
• При использовании BGP с IPsec/CNI (бета-версия) необходимо задать на стороне Cloudflare ASN, равный 13335. Приватные ASN пока не поддерживаются.

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

По умолчанию Cloudflare распределяет и направляет трафик на основе характеристик сетевого уровня (IP-адрес, порт и так далее). При использовании Cloudflare WAN Connector трафик можно также направлять с учетом известных приложений. Политики с учетом приложений упрощают управление и дают более точный контроль над потоками трафика.

Подробнее см. в Приложения и типы приложений.