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

Řízení provozu

Jakmile provoz vstoupí do sítě Cloudflare, musí se dostat na správné místo ve vaší infrastruktuře: do konkrétního datového centra, kanceláře nebo cloudového prostředí. To, jak Cloudflare tato směrovací rozhodnutí dělá, řídí traffic steering.

Cloudflare Virtual Network je privátní překryvná síť vašeho účtu, která se rozprostírá napříč všemi datacentry Cloudflare po celém světě. Tato překryvná síť poskytuje:

• Doručování Magic Transit pro Odepření služby (DoS) a Cloudflare Network Firewall filtrovaný internetový provoz z datového centra, kam provoz vstoupil, do vaší veřejně adresované edge/hraniční sítě.
• Přenos paketů Cloudflare WAN mezi tunely IPsec/GRE, interkonekty, Cloudflare Load Balancer, a Zero Trust připojení, jako například Cloudflare One Client, Remote Browser Isolation, Access, a Gateway.

Cloudflare Virtual Network podporuje směrování provozu Cloudflare WAN přes anycast tunely pomocí GRE a Internet Protocol Security (IPsec) nebo CNI s Dataplane v2. Do směrovací tabulky Cloudflare Virtual Network můžete přidávat položky prostřednictvím konfigurace statických tras nebo prostřednictvím tras získaných přes BGP peering (beta). Provoz lze také směrovat automaticky podle sledovaného stavu toku.

Ve směrovací tabulce Cloudflare Virtual Network jsou povoleny následující rozsahy adres IPv4:

• RFC 1918 ↗ adresní prostor, konkrétně 10.0.0.0/8, 172.16.0.0/12, a 192.168.0.0/16.

Pokud používáte Cloudflare WAN společně s Cloudflare Tunnel, zohledněte při výběru statických tras pro Cloudflare WAN rozsahy IP adres použité ve statických trasách Cloudflare Tunnel. Další informace najdete v Cloudflare Tunnel.

U prefixů mimo RFC 1918 kontaktujte svého manažera zákaznických služeb Cloudflare.

Pokud provoz neodpovídá žádné trase nakonfigurované ve virtuální síti, Cloudflare použije výchozí chování podle typu cílové adresy:

• Veřejné (směrovatelné na internetu) adresy: Provoz opouští síť směrem do internetu.
• Soukromé adresy (RFC 1918 ↗ nebo CGNAT/RFC 6598 ↗): provoz je zahozen (null routed), protože privátní adresy nejsou na veřejném internetu směrovatelné a Cloudflare nemá bez odpovídající trasy jak je doručit.

Cloudflare WAN směruje provoz po trasách tunelů podle priority jednotlivých záznamů tras.

• Nižší hodnoty mají vyšší prioritu.
• Pokud se hodnoty priority pro položky prefixů shodují, Cloudflare použije equal-cost multi-path (ECMP) přeposílání paketů ke směrování provozu. Statickým trasám můžete přiřadit volitelnou hodnotu váhy, abyste upravit distribuci tunelů ECMP.
• Směrování Cloudflare používá longest-prefix match. Konkrétnější statická trasa (jako /30) má vždy přednost před méně specifickým pravidlem (jako /29), bez ohledu na prioritu tunelu, pokud neodstraníte konkrétnější trasu.
• Pokud mají trasy BGP a statické trasy stejný prefix a stejnou prioritu, Cloudflare uplatňuje prioritu tak, že upřednostní statické trasy před trasami BGP. Ručně nakonfigurované statické trasy tak mají přednost, pokud jim výslovně nesnížíte prioritu.

Hodnota priority pro statické trasy se konfiguruje přímo jako součást objektu trasy v Cloudflare dashboard nebo prostřednictvím API. Například:

V tomto příkladu tunely s prioritou 100 mají přednost před tunely s prioritou 200 protože nižší čísla mají vyšší prioritu.

Volitelně můžete přiřadit váhy pro efektivnější rozložení provozu mezi více tunelů. Hodnoty vah určují podíl provozu, přičemž tunely s vyšší váhou dostávají více provozu. Maximální hodnota váhy je 256.

V následujícím příkladu TUNNEL_2_IAD pravděpodobně obdrží dvakrát tolik provozu než TUNNEL_1_IAD.

Kromě priority ovlivňuje způsob směrování provozu i omezení statických tras na konkrétní zeměpisné oblasti. Více informací najdete v Omezení tras na konkrétní regiony pro další podrobnosti.

Když BGP oznámí trasu, Cloudflare ji automaticky přidá do směrovací tabulky Cloudflare Virtual Network s výchozí prioritou 100 která se vztahuje na všechny regiony. Pokud však existuje statická trasa se stejným prefixem a stejnou prioritou, statická trasa má vždy přednost před trasou BGP. Nastavte pro statické trasy jinou prioritu (vyšší nebo nižší než 100) v závislosti na tom, čemu chcete dát přednost. Nižší hodnoty mají vyšší prioritu.

Pokud navíc existuje více tras BGP se stejnou délkou prefixu a stejnou prioritou, ECMP mezi nimi rozděluje provoz pomocí směrování equal-cost multi-path (ECMP).

Cloudflare podporuje řízení provozu pomocí BGP komunit a AS prependingu. Tyto techniky směrování provozu můžete využít k nastavení priorit tras a k optimalizaci provozu napříč více interkonekty.

Výchozí priorita trasy BGP je 100. Tuto základní prioritu lze upravit pomocí komunit. Pokud je například trasa označena komunitou 13335:60010 jeho priorita je nastavena na 10. Díky tomu má vyšší prioritu než výchozí 100 protože jsou upřednostňovány nižší číselné priority.

Podporované hodnoty komunity pro nastavení základní priority trasy jsou:

• 13335:60010: Nastavte základní prioritu trasy na 10
• 13335:60050: Nastavte základní prioritu trasy na 50
• UNSET: Nastavte základní prioritu trasy na 100
• 13335:60150: Nastavte základní prioritu trasy na 150
• 13335:60200: Nastavte základní prioritu trasy na 200
• 13335:60901: Nastavte základní prioritu trasy na 501000
• 13335:60902: Nastavte základní prioritu trasy na 1001000

Nastavení více základních prioritních komunit ve stejné aktualizační zprávě prefixu představuje chybnou konfiguraci. V takovém případě Cloudflare upřednostní nejvyšší prioritu (nejnižší celočíselnou hodnotu).

Za každou další zmínku vašeho ASN v přijaté AS path Cloudflare přidá 10 k základní prioritě trasy. Zvýšením čísla priority se trasa stává méně preferovanou.

Pokud je například vaše ASN 65000 pak BGP UPDATE ke Cloudflare bude:

# 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 upravuje prioritu trasy při použití AS prepending s komunitami. Pokud je například trasa označená štítkem 13335:60150, základní priorita je nastavena na 150. Pokud své ASN prependujete dvakrát, Cloudflare přidá 10 pro každé prepend, čímž se zvyšuje priorita trasy na 180.

Automatic Return Routing (ARR) umožňuje Cloudflare sledovat síťové toky z lokalit připojených k vaší síti Cloudflare WAN (dříve Magic WAN) a zajišťuje, že se zpětný provoz vrátí na připojení, na kterém byl přijat, aniž by bylo nutné nastavovat statické nebo dynamické trasy. Tato funkce vyžaduje novou Režim Unified Routing (beta).

Namísto spoléhání na statické nebo dynamické trasy pro zpětnou cestu se Cloudflare WAN učí toky a pamatuje si, přes které připojení daný tok dorazil. Pro odpovídající zpětný provoz pak Cloudflare WAN použije tento naučený stav k volbě dalšího uzlu. Díky tomu se zjednodušuje konfigurace, snižuje počet tras, které musíte spravovat, a zachovává symetrie stavového provozu.

ARR poskytuje tyto výhody:

• Odstraňuje potřebu zpětných tras: U podporovaných typů provozu, jako jsou nová připojení TCP (TCP SYN), UDP a provoz ICMP echo, již Cloudflare WAN nevyžaduje záznam ve směrovací tabulce pro návrat provozu do původního tunelu nebo interconnectu.
• Zachovává symetrické směrování pro toky provozu: Odpovědi na daný tok (například relaci TCP) se vracejí přes stejné připojení Cloudflare WAN, které přeneslo počáteční požadavek, což je důležité pro stavové firewally a middleboxy.
• Podporuje překrývající se adresní prostor IP: Vzhledem k tomu, že návratová cesta je vázána na naučený stav připojení, a nikoli na cílový prefix ve směrovací tabulce, dokáže Automatic Return Routing podporovat scénáře, kdy různé pobočky používají překrývající se privátní adresní prostor.
• Funguje pro každé připojení zvlášť: Rozhodujete, které tunely IPsec / GRE nebo síťová propojení mají toto chování používat, a to povolením funkce na každém připojení.

Když na připojení s povoleným ARR dorazí provoz způsobilý pro Automatic Return Routing (ARR), Cloudflare WAN vytvoří záznam toku, který zaznamenává:

• Zdrojová a cílová IP adresa
• Příslušné porty nebo identifikátory v závislosti na protokolu
• Připojení (tunel nebo interconnect), přes které provoz přišel

U všech dalších paketů, které odpovídají tomuto toku a vyžadují další hop, Cloudflare WAN:

1. Kontroluje shodu s tokem Automatic Return Routing.
2. Pokud shoda existuje, směruje paket zpět do stejného připojení, ve kterém byl tok zjištěn, místo aby se dotazoval směrovací tabulky Cloudflare Virtual Network.

Počáteční požadavek z vaší sítě do internetu stále používá nakonfigurované statické nebo BGP trasy. ARR ovlivňuje pouze zpáteční cestu podporovaného provozu poté, co je tok provozu rozpoznán.

Automatic Return Routing platí, pokud:

• Provoz je přijímán na tunelu nebo síťovém interkonektu, kde je funkce povolena.
• Přijatý provoz je jeden z těchto typů:
  • Nová TCP spojení (TCP SYN)
  • UDP
  • požadavky ICMP echo (ping)
• Provoz směřuje na:
  • Odchozí internetový provoz přes Cloudflare
  • Cloudflare One Client
  • Privátní síť připojená k Cloudflare přes Cloudflare Tunnel
  • Privátní síť připojená k Cloudflare přes Cloudflare Mesh

V tomto počátečním vydání ARR nemění směrování provozu mezi připojeními Cloudflare WAN (například provoz z jednoho tunelu IPsec/GRE nebo interconnectu do druhého). Tento provoz se nadále řídí vámi nakonfigurovanými trasami Cloudflare WAN.

Režim Unified Routing je novější datová rovina Cloudflare One, která pro všechny podporované typy připojení používá jedinou směrovací infrastrukturu. Provoz v režimu Unified Routing směruje napříč Cloudflare One Client, Cloudflare Tunnel, IPsec, GRE a Cloudflare Network Interconnect (CNI) v rámci jednoho systému, což usnadňuje nastavení vašich připojení Cloudflare One.

V dashboardu Cloudflare WAN se režim směrování zobrazuje tam, kde spravujete trasy:

• Režim směrování: Unified : váš účet používá sjednocenou datovou rovinu a podporuje nové funkce směrování.
• Režim směrování: Legacy : váš účet používá předchozí datovou rovinu a nepodporuje všechny sjednocené funkce směrování.

Unified Routing představuje budoucnost vyhrazeného overlaye virtuální sítě, který pohání síťovou konektivitu Magic Transit a Cloudflare One.

Zákazníci Cloudflare One mají několik důvodů zvážit přechod na Unified Routing, protože je předpokladem pro řadu nových funkcí:

• Automatic Return Routing
• BGP přes IPsec/GRE
• Zdrojové IP adresy Cloudflare pomocí privátního IP prostoru s přizpůsobitelným rozsahem IPv4
• Přizpůsobitelné rozsahy IPv4 pro Cloudflare One Client
• Podpora IPv6
• Vylepšený výkon mezi Cloudflare One Client a IPsec/GRE/CNI
• Podpora pro Cloudflare Mesh a připojení IPsec/GRE/CNI v rámci stejného účtu.

Na účty používající režim Unified Routing se vztahují následující omezení. Tento seznam se bude postupně zkracovat, jak Cloudflare přidává podporu dalších funkcí.

Unified Routing je aktuálně v uzavřené beta verzi. Chcete-li se zaregistrovat:

• Stávající zákazníci Cloudflare WAN nebo Magic Transit: Cloudflare doporučuje vyzkoušet novou funkci pro váš případ použití v neprodukčním účtu. Pro povolení Unified Routing kontaktujte svůj account team.
• Noví zákazníci: Pro povolení Unified Routing v proof-of-concept pro váš případ použití kontaktujte svůj account team.

Pokud váš účet používá jak trasy Zero Trust (Cloudflare Tunnel, Cloudflare Mesh), tak trasy WAN (IPsec, GRE, CNI), chování výběru trasy závisí na vašem režim směrování.

Unified Routing využívá jedinou směrovací fabric pro všechny typy připojení. Výběr trasy důsledně používá pravidlo longest-prefix-match u všech typů provozu a metod připojení.

Pokud mají trasy stejnou délku prefixu, mají trasy Zero Trust přednost před trasami WAN.

Pro scénáře s překrývajícím se IP prostorem mezi pobočkami povolte Automatic Return Routing zajistit, aby se vratný provoz dostal ke správnému originu.

U účtů používajících Legacy Routing závisí výběr trasy na zdroji provozu.

U účtů používajících pouze Zero Trust je provoz Cloudflare One Client směrován výhradně podle směrovací tabulky IP adres Zero Trust, a to na základě logiky longest-prefix-match.

Pokud má váš účet povolený Cloudflare WAN, provoz z Cloudflare One Client se řídí stejným chováním při výběru trasy jako provoz site-to-site s Gateway. Pokud chcete, aby se Cloudflare One Client nadále choval, jako by WAN nebyla povolena, obraťte se na svůj account team.

U provozu mezi připojeními WAN (IPsec na IPsec, GRE na GRE a CNI na CNI), který nevyžaduje filtrování Gateway, platí v rámci směrovací tabulky WAN pravidlo nejdelší shody prefixu. Tento provoz nijak neinteraguje se směrováním Zero Trust.

Když Síťové zásady Gateway jsou uplatněny na provoz WAN mezi lokalitami, výběr trasy se řídí těmito pravidly:

Starší směrování používá dvě směrovací komponenty:

• Směrování Zero Trust (zajišťuje Cloudflare One Client, Cloudflare Tunnel a Cloudflare Mesh)
• směrování WAN (zajišťuje IPsec, GRE a CNI)

Provoz mezi systémy se řídí stejnými pravidly jako provoz site-to-site s Gateway. Specifičtější trasa Zero Trust funguje správně, u specifičtější trasy WAN však není zaručeno, že bude vybrána.

Doporučení: Pokud je překryv nutný, přejděte na Unified Routing nebo kontaktujte tým pro váš účet.

Chcete-li zjistit režim směrování pro váš účet:

1. Přejděte na Trasy.

2. Zkontrolujte banner v horní části stránky:
   • Váš účet používá režim Unified Routing. : Váš účet používá Unified Routing.
   • Sjednocené směrování je k dispozici. : Váš účet používá Legacy Routing.

Chcete-li migrovat na Unified Routing, kontaktujte svůj account team.

Pokud máte k síťovému segmentu více cest připojení a chcete uplatňovat různou prioritizaci tras podle toho, kde provoz vstupuje do sítě Cloudflare, můžete trasy omezit na konkrétní regiony datových center Cloudflare. To se hodí, pokud provozujete vlastní anycast síť a chcete, aby provoz koncových uživatelů dorazil do síťové lokality nejblíže danému uživateli.

Když trasu omezíte na region datového centra Cloudflare, zobrazí se pouze ve směrovací tabulce Cloudflare Virtual Network v daném regionu, spolu se všemi globálními trasami bez omezení na region. Stanovení priority tras a logika ECMP platí jak pro trasy omezené na region, tak pro globální trasy.

Při použití tras s rozsahem na úrovni regionu zajistěte, aby všechny prefixy měly trasy pokrývající všechny regiony. Jinak může provoz dorazit do regionu Cloudflare, který není pokryt žádnou trasou, a Cloudflare jej v takovém případě zahodí.

Následující tabulka ukazuje na příkladu, jak u tras použít geografické omezení:

Pokud existuje více tras ke stejnému prefixu se stejnou prioritou a tyto trasy jsou přiřazeny různým zeměpisným oblastem (například WNAM a ENAM), provoz vstupující do sítě v konkrétní oblasti, například WNAM, opouští síť (egress) přes trasu přiřazenou stejné oblasti.

Cloudflare má devět zeměpisných regionů:

Nakonfigurujte rozsah svého provozu v Kód regionu sekci při přidávání nebo úpravě statické trasy. Přečtěte si Vytvořit statickou trasu a Upravte statickou trasu s dalšími informacemi.

Equal-cost multi-path routing používá haše vypočítané z paket ↗ data, aby určila zvolenou trasu. Hash vždy vychází ze zdrojové a cílové IP adresy. U paketů TCP a UDP zahrnuje hash i zdrojový a cílový port. Algoritmus ECMP dělí hash každého paketu počtem rovnocenných dalších skoků (next hops). Modulo (zbytek po dělení) pak určuje, kterou trasou paket půjde.

Používání ECMP má několik důsledků:

• Směrování na cesty se stejnou cenou je pravděpodobnostní.
• Pakety ve stejné relaci se stejným zdrojem a cílem mají stejný hash. Tyto pakety také používají stejný další skok.
• Změna počtu dalších skoků se stejnou cenou může vést k tomu, že provoz začne používat jiné tunely. Stát se to může například při dynamické změně priorit vyvolané událostmi kontroly stavu.

Díky tomu ECMP zajišťuje vyvažování zátěže mezi tunely se stejným prefixem a prioritou.

Tento diagram znázorňuje, jak ECMP rovnoměrně rozděluje provoz mezi dvě cesty se stejným prefixem a prioritou.

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}}

Selhání routeru zákazníka

Když kontroly stavu Cloudflare WAN zjistí, že je Tunnel 2 nezdravý, Cloudflare WAN dynamicky sníží prioritu této trasy, takže jedinou trasou s nejvyšší prioritou zůstává Tunnel 1. Cloudflare WAN díky tomu odklání provoz od Tunnelu 2 a veškerý provoz směřuje na 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

Selhání zprostředkujícího poskytovatele internetových služeb (ISP)

Když Cloudflare WAN zjistí, že je nezdravý i Tunnel 1, sníží se priorita i této trasy a nejvyšší prioritu tak získá trasa přes Tunnel 3. V takovém případě veškerý provoz směřuje na 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

Když Cloudflare WAN zjistí, že jsou Tunnel 1 a Tunnel 2 opět zdravé, znovu upraví prioritu těchto tras a tok provozu se vrátí do normálu.

Protože je ECMP pravděpodobnostní, algoritmus směruje přibližně stejný počet toků přes každý tunel. Při rozhodování, kam nasměrovat další paket, však nebere v úvahu množství provozu již odeslaného přes daný tunel.

Uvažujme například scénář s mnoha připojeními TCP s velmi nízkou šířkou pásma a jedním připojením TCP s velmi vysokou šířkou pásma. Pakety připojení s vysokou šířkou pásma mají stejný hash, a proto využívají stejný tunel. V důsledku toho tento tunel využívá větší šířku pásma než ostatní.

Používání BGP peeringu se směrovací tabulkou Cloudflare One nebo Magic Transit Virtual Network vám umožňuje:

• Automatizujte proces přidávání a odebírání sítí a podsítí.
• Využijte funkce detekce selhání a obnovení relace.

Díky této funkci můžete:

• Navažte relaci eBGP mezi svými zařízeními a službou Cloudflare WAN při připojení přes tunely CNI, GRE nebo IPsec.
• Zabezpečte relaci ověřováním MD5, abyste zabránili nesprávné konfiguraci.
• Dynamicky vyměňujte trasy mezi svými zařízeními a směrovací tabulkou Cloudflare Virtual Network.

Následující tabulka popisuje aktuální dostupnost BGP a doporučené případy použití pro jednotlivé způsoby připojení.

Cloudflare Virtual Network provádí jednoprůchodové směrovací rozhodnutí pro každý paket už v datacentru Cloudflare, které daný paket zpracuje jako první (ingress uzel). Díky tomu platí, že i když paket prochází více uzly v páteřní síti Cloudflare, jeho trasa se pro maximální efektivitu určí hned v okamžiku vstupu.

Vaše relace BGP přes IPsec, GRE nebo CNI se naváže s datacentrem Cloudflare nejbližším vašemu peer zařízení BGP. Trasy zjištěné zde se musí šířit do globální edge sítě Cloudflare, aby řídily způsob směrování provozu v rámci celé sítě.

• Doba konvergence: Globální konvergence tras se obvykle dokončí do 20 sekund.
• Viditelnost: Naučené trasy a stav jejich šíření můžete sledovat prostřednictvím Cloudflare dashboardu nebo API.

Cloudflare Virtual Network využívá pro šíření tras centralizovanou řídicí rovinu, která funguje podobně jako BGP Route Reflector. Tato architektura odděluje fyzickou relaci BGP od globální distribuce tras:

• Ukončení relace: Relace BGP peeringu jsou ukončeny v edge lokalitě Cloudflare nejbližší vašemu routeru.
• Konverze SDN: Ingress aktualizace BGP se převádí na stav Software-Defined Networking (SDN) a přenášejí se do centralizované relay funkce.
• Globální šíření: Relay šíří tyto instrukce do všech datacenter Cloudflare po celém světě a aktualizuje lokální Forwarding Information Base (FIB) na každé pobočce.

Datová rovina (data plane) Cloudflare je navržena pro vysokou dostupnost. Pokud edge lokalita ztratí spojení s centralizovaným relay serverem, systém přejde do režimu Edge Resiliency Mode, který napodobuje chování Non-Stop Forwarding (NSF):

• Kontinuita předávání: Edge lokality nadále směrují provoz pomocí poslední známé funkční směrovací tabulky (FIB). Provoz v datové rovině zůstává nepřerušen.
• Uchování neaktuálních tras: Vzhledem k tomu, že je FIB v tomto režimu zmrazená, rozhodnutí o předávání zůstávají aktivní, i když relace BGP s vaším routerem flapuje nebo se resetuje.
• Průběžné sledování stavu: Zatímco jsou aktualizace BGP zmrazené, kontroly stavu tunelu zůstávají aktivní. Tyto kontroly se odesílají ze všech datacenter Cloudflare, což umožňuje edge síti v libovolném vstupním uzlu zjistit, zda nedošlo k výpadku fyzického připojení k vašemu routeru. Pokud kontrola stavu selže, vstupní uzel na edge síti sníží prioritu dané cesty, čímž zabrání odeslání provozu do černé díry i přes zmrazený stav směrování.
• Zmrazení aktualizací: V tomto stavu je globální řídicí rovina zmrazena. Nové aktualizace BGP přijaté z vašeho routeru se budou ukládat lokálně na edge a nebudou se globálně šířit, dokud se neobnoví připojení k centralizovanému relay.

Jakmile se obnoví konektivita mezi Cloudflare edge a centralizovaným relay serverem, systém automaticky opustí režim Edge Resiliency Mode a provede stavovou resynchronizaci:

1. Synchronizace RIB-to-relay: Edge odešle relay všechny aktuálně uchovávané aktualizace BGP (aktuální stav RIB).
2. Globální aktualizace: Relay tyto aktualizace sladí a případné změny šíří do zbytku globální sítě Cloudflare.
3. FIB unfreeze: Lokální směrovací tabulky na edge se odemknou a aktualizují nejnovějšími ověřenými směrovacími instrukcemi.

BGP peering v Cloudflare WAN probíhá se směrovací tabulkou Cloudflare Virtual Network (nikoli s globální internetovou sítí Cloudflare). Sousedé BGP nakonfigurovaní podle tohoto návodu budou dostávat oznámení o všech prefixech ve směrovací tabulce Cloudflare Virtual Network a navíc o veškerých dalších prefixech nakonfigurovaných na on-rampu Seznam oznámených prefixů.

Pokud místo toho chcete provést veřejný peering s Cloudflare ASN 13335 v některém z datacenter Cloudflare, přečtěte si Nastavení PNI a peeringu. V současné době není možné sdílet BGP peering Cloudflare Virtual Network a PNI na stejném fyzickém portu interconnectu.

Cloudflare přeposílá trasy přijaté z vašeho zařízení do směrovací tabulky Cloudflare Virtual Network, kterou využívají Cloudflare WAN i Magic Transit.

Všechny trasy ve směrovací tabulce Cloudflare Virtual Network se inzerují partnerům BGP. Každý partner BGP obdrží ke každé trase prefixu i úplný AS_PATH, se zvolenou stranou Cloudflare ASN ↗ připojen na začátek. Díky tomu může peer přesně provést prevence smyček ↗.

Relace BGP peeringu mohou peerovi oznamovat dosažitelné prefixy a odvolávat dříve oznámené prefixy. Toto šíření netrvá déle než několik minut.

Cloudflare používá následující časovače, které nelze konfigurovat:

• Časovač Hold: Určuje maximální dobu, po kterou BGP peer čeká na zprávu keepalive, update nebo notification, než prohlásí relaci BGP za nefunkční. Cloudflare použije nižší z hodnot, tento výchozí hold timer, nebo hodnotu přijatou od peeru ve zprávě open.
• Časovač keepalive: Systémy BGP si vyměňují zprávy keepalive, aby zjistily, zda je peer router dostupný. Pokud nejsou zprávy keepalive přijaty během hold timeru, relace se považuje za down, což znamená, že peer už není na úrovni protokolu BGP dosažitelný.
• Graceful restart timer: Sleduje, jak dlouho router čeká, než peer obnoví relaci BGP po zahájení graceful restart. Pokud se peer v tomto čase znovu nepřipojí, router prohlásí relaci za nedostupnou a odstraní zastaralé trasy.

BGP multipath je podporován. Pokud se BGP naučí stejný prefix na dvou různých interkonektech, Cloudflare rozloží provoz určený pro tento prefix mezi jednotlivé interkonekty podle standardního chování ECMP.

BGP Graceful Restart je podporován v pasivním režimu (helper/aware). Cloudflare udržuje stav předávání pro souseda, který se restartuje.

Podpora BGP má v současnosti následující omezení:

• ASN účtu Cloudflare a ASN vašeho zařízení se musí lišit. Podporováno je pouze eBGP.
• Cloudflare vždy vkládá trasy s prioritou 100.
• Bidirectional Forwarding Detection (BFD) není podporováno.
• Pokud používáte BGP s IPsec/CNI (beta verze), musíte na straně Cloudflare nastavit ASN na 13335. Privátní ASN zatím nejsou podporována.

Musíte povolit starší kontroly stavu vedle BGP. To je klíčové pro zjištění, zda je konkrétní datacentrum Cloudflare z vašeho zařízení dosažitelné. Tunnel health checks upravit priority tras pro dynamicky získané trasy BGP.

Cloudflare ve výchozím nastavení vyvažuje zátěž a směruje provoz na základě charakteristik síťové vrstvy (IP adresa, port atd.). Pokud používáte Cloudflare WAN Connector, můžete provoz směrovat i na základě známých aplikací. Zásady rozpoznávající aplikace usnadňují správu a umožňují jemnější řízení toků provozu.

Další informace najdete v tématu Aplikace a typy aplikací.