← Cloudflare Magic Transit / magic-transit / 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.

Magic Transit Virtual Network je virtuální overlay síť, soukromá pro váš účet, která zahrnuje všechna datová centra Cloudflare po celém světě. Tato overlay 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ů Magic Transit mezi tunely IPsec/GRE, interconnecty, Cloudflare Load Balancer, a Zero Trust připojení, jako například Cloudflare One Client, Remote Browser Isolation, Access, a Gateway.

Magic Transit Virtual Network umožňuje směrovat provoz Magic Transit prostřednictvím anycastových tunelů pomocí GRE a Internet Protocol Security (IPsec) nebo CNI s Dataplane v2. Do směrovací tabulky Magic Transit Virtual Network můžete přidávat záznamy prostřednictvím konfigurace statických tras nebo pomocí tras získaných přes BGP peering (beta).

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

• BYOIP veřejný adresní prostor, který jste zapojili do Cloudflare Magic Transit.
• Cloudflare pronajaté IP adresy přiřazené k vašemu účtu.

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.

Magic Transit směruje provoz podél tunelových cest na základě priorit záznamů cest.

• 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 Magic Transit 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.

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 Magic Transit 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.

U zákazníků Magic Transit je hlavním důvodem ke zvážení Unified Routing možnost vyhodnotit BGP pro tunely IPsec/GRE, což závisí na Unified Routing.

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 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 oblast datacenter Cloudflare, zobrazí se pouze ve směrovací tabulce Magic Transit Virtual Network v dané oblasti, spolu se všemi globálními trasami, které nemají žádné omezení na oblast. Prioritizace tras a logika ECMP se uplatňují jak u tras omezených na oblast, tak u globálních tras.

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.

Aby mohl Cloudflare směrovat váš provoz ze své globální sítě do vašich datových center přes anycast tunely, musíte zadat své prefixy a tunely, na které mají být namapovány. Jako vodítko použijte následující tabulku.

Minimální oznamovaný prefix je /24, ale protože Cloudflare používá anycastové tunely jako vnější obal pro váš provoz, může Cloudflare směrovat prefixy v rámci tohoto /24 k různým koncovým bodům tunelu. Můžete například odesílat x.x.x.0/29 do Data Center 1 a x.x.x.8/29 do Data Center 2. To se hodí, pokud pracujete v prostředí s omezenými IP zdroji.

Pokud máte více zapojených /24 podsítě, které patří do většího souvislého bloku, můžete nakonfigurovat souhrnnou statickou trasu pro odpovídající supersíť (jako /23 nebo /22) místo přidávání každé /24 jednotlivě. Díky tomu není nutné konfigurovat každý /24 trasu, protože veškerý provoz bude směrován přes stejné GRE tunely.

Pokud máte například dva tunely:

• 192.0.2.0/24
• 192.0.3.0/24

Tyto údaje můžete shrnout do jednoho 192.0.2.0/23.

Viz Přidejte tunely se dozvíte více o konfiguraci GRE tunelů.

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 Magic Transit zjistí, že Tunnel 2 je nefunkční, Magic Transit dynamicky sníží prioritu této trasy, takže jedinou trasou s nejvyšší prioritou zůstane Tunnel 1. Provoz se tak přesměruje z Tunnelu 2 a veškerý provoz poteče přes 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ž Magic Transit zjistí, že Tunnel 1 je také nefunkční, sníží se priorita i této trasy, takže nejvyšší prioritu získá trasa přes Tunnel 3. V takovém případě veškerý provoz směřuje přes 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

Jakmile Magic Transit zjistí, že Tunnel 1 a Tunnel 2 jsou opět funkční, 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:

• Pokud jste připojeni prostřednictvím tunelů CNI, GRE nebo IPsec, vytvořte relaci eBGP mezi svými zařízeními a službou Magic Transit.
• Zabezpečte relaci ověřováním MD5, abyste zabránili nesprávné konfiguraci.
• Dynamicky si vyměňujte trasy mezi svými zařízeními a směrovací tabulkou Magic Transit Virtual Network.

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

Magic Transit Virtual Network provádí směrovací rozhodnutí pro každý paket jediným průchodem, a to v datovém centru Cloudflare, které paket zpracuje jako první (vstupní uzel). Díky tomu je cesta paketu určena už při vstupu do sítě, i když prochází více uzly v rámci páteřní sítě Cloudflare, což zajišťuje maximální efektivitu.

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.

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

• 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.
• Hraniční inzerce Magic Transit: Během tohoto zmrazeného stavu se vaše prefixy BYOIP budou nadále inzerovat na globální edge síti Cloudflare. Stav inzerce můžete ručně změnit přes API nebo dashboard.

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.

Partnerství BGP (BGP peering) u Magic Transit probíhá s tabulkou směrování Magic Transit Virtual Network (nikoli s globální internetovou sítí Cloudflare). Partneři BGP nakonfigurovaní podle tohoto návodu budou dostávat inzerci všech prefixů v tabulce směrování Magic Transit Virtual Network a také všech dalších prefixů nakonfigurovaných ve vstupním bodě (on-ramp) 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 Magic Transit Virtual Network a PNI na stejném fyzickém portu interconnectu.

Cloudflare redistribuuje trasy přijaté z vašeho zařízení do směrovací tabulky Magic Transit Virtual Network.

Všechny trasy ve směrovací tabulce Magic Transit Virtual Network se oznamují partnerům BGP. Každý partner BGP obdrží ke každé trase prefixu také kompletní 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.

U zákazníků Magic Transit je BGP s tabulkou tras Magic Transit Virtual Network oddělené od oznamování anycast prefixů na hraně Cloudflare. Stažení anycast musí být řízeno stávajícími metodami popsanými v Inzerce prefixů.

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.