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

Inzerce prefixů

Do Cloudflare můžete přinést vlastní veřejné IP adresy a používat je s Magic Transit. Tomu se říká bring your own IP (BYOIP). Tento proces zahrnuje dva odlišné typy prefixů:

1. IP prefixy: Pro každý blok IP adres, který do Cloudflare přinesete, je potřeba záznam IP prefixu. Ten obsahuje oprávnění (Dopis o zmocnění (LOA)), které Cloudflare umožňuje inzerovat síť nebo její podsítě. Můžete také definovat volitelné Číslo autonomního systému (ASN) ↗ aby byl zahrnut do naší inzerované AS path.
2. Prefixy BGP: Ty určují, které prefixy Cloudflare inzeruje ze své globální sítě. Každý IP prefix má ve výchozím nastavení jeden odpovídající prefix BGP. Můžete nakonfigurovat další, konkrétnější prefixy BGP (podsítě daného IP prefixu), a to až do maximální délky prefixu /24.

Cloudflare počítá počet prefixů Magic Transit podle počtu vámi definovaných prefixů BGP. Každý prefix se účtuje samostatně, i když se překrývají. Pokud se například překrývají prefix /16 a jakýkoli /24 v něm se počítají jednotlivě. Onboarding většího agregovaného prefixu automaticky nezahrnuje jeho menší podsítě pro účely inzerce ani fakturace.

Pro velikosti přijímaných prefixů neplatí žádný fakturační limit. Akceptovány jsou však pouze prefixy do /24 se pro onboarding přijímají, protože delší prefixy (například /25, /26) nejsou globálně směrovatelné.

Zadejte všechny IP prefixy, které plánujete začlenit, spolu s ASN, ze kterých je budete inzerovat. Při zadávání prefixů dodržujte následující zásady:

• Prefixy musí obsahovat alespoň 256 IP adres (/24 ve formátu CIDR (Beztřídní směrování mezi doménami ↗) notace). Pokud nesplňujete /24 požadavku na délku prefixu naleznete v Použití IP adresy Cloudflare.
• Záznamy Internet Routing Registry a LOA musí odpovídat prefixům a původním prefixům, které odešlete Cloudflare.
• Při použití souvislých prefixů uvádějte, kde je to možné, agregované prefixy.
• Při použití Route Origin Authorizations (ROA) k podepisování tras pro infrastruktura veřejných klíčů pro zdroje (RPKI) ↗, prefix a zdrojové ASN musí odpovídat údajům odeslaným při onboardingu.
• Pokud nevlastníte ASN, můžete použít Cloudflare Customer ASN (AS13335).

V rámci procesu onboardingu IP prefixu musíte rozhodnout, které ASN bude Cloudflare používat k oznamování vašich prefixů. Pokud zadáte vlastní ASN, Cloudflare přidá hlavní ASN Cloudflare (AS13335) na začátek BGP AS_PATH. Pokud je například vaše ASN AS64496, kdokoli, kdo přímo peeruje s Cloudflare, vidí cestu jako 13335 64496.

Pokud nemáte ASN nebo nechcete své ASN přenést do Cloudflare, můžete použít Cloudflare Customer ASN (AS13335).

Prefixy BGP představují prefix, který Cloudflare oznamuje prostřednictvím anycastu ze své globální sítě. Ve výchozím nastavení vždy existuje alespoň jeden prefix BGP, jenž je totožný s onboardovaným IP prefixem.

Pokud například zapojíte /20 IP prefix do Magic Transitu, můžete ho inzerovat pouze jako /20 protože existuje jen výchozí /20 BGP prefix. Menší dílčí prefixy (například /24s) v rámci tohoto /20 nelze inzerovat samostatně, pokud nejsou nakonfigurované jako samostatné BGP prefixy.

Cloudflare nabízí několik mechanismů pro řízení oznamování a stahování prefixů na vyžádání. Každá metoda se hodí pro jiný scénář nasazení:

• Addressing API: Inzerci prefixů řiďte ručně pomocí volání API. Více informací najdete v Inzerce nebo stažení prefixu BGP.
• BGP peering s route reflectory: Řiďte inzerci pomocí BGP relací ke globálně distribuovaným route reflectorům Cloudflare, a to buď přes internet, nebo přes připojení CNI s Dataplane v1. Pokud tuto možnost potřebujete, obraťte se na svůj tým účtu Cloudflare. Více informací najdete v Řízení BGP pomocí Cloudflare Route Reflectors.
• Network Flow: Automaticky inzerujte prefixy na základě uživatelem definovaných prahových hodnot provozu pozorovaných ve vaší síti. Více informací najdete v Network Flow (dříve Magic Network Monitoring).
• BGP peering se směrovací tabulkou Magic Transit Virtual Network: Automaticky řiďte inzerci prefixů na základě tras BGP získaných přes CNI s Dataplane v2 nebo přes tunely GRE a IPsec (beta, vyžaduje Unified Routing). Viz Řízení BGP pro směrovací tabulku Magic Transit Virtual Network.

Vytvořte Požadavek POST pro přidání BGP prefixu. Například:

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

Prefix lze odstranit pouze se stavem Unapproved stavu. Pro odstranění prefixů s jiným stavem kontaktujte svého administrátora nebo account manažera.

1. Přejděte na Trasy stránce.

2. Z IP prefixy kartě vyhledejte prefix, který chcete upravit, a vyberte Smazat.
3. Potvrďte svou volbu v modálním okně výběrem Smazat.

Použijte Addressing API k řízení počtu, kolikrát Cloudflare prependuje své číslo autonomního systému (ASN) k prefixu. AS13335 můžete prependovat až třikrát v poli AS_PATH aktualizací BGP pro vaše prefixy.

Následující příklad ukazuje, jak třikrát předřadit AS13335 k BGP prefixu:

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 vám pomáhá plynule přesouvat provoz mezi síťovými poskytovateli. Přidáním prependů do inzerce Cloudflare uděláte trasu přes Cloudflare pro některé internetové poskytovatele méně preferovanou. Díky tomu můžete současně inzerovat stejný prefix z alternativního poskytovatele s kratší, výhodnější AS_PATH. Souběžné oznamování od obou poskytovatelů zajišťuje plynulejší migraci provozu a minimalizuje ztrátu paketů při změně poskytovatele.

"asn_prepend_count" parametr přijímá hodnoty od 0 na 3. Vyšší hodnota znamená, že je trasa méně preferovaná. Tento parametr můžete změnit také pomocí BGP. Více informací najdete v Nastavení AS prependů na anycast prefixu pomocí komunit.

Když k přesunu provozu z Magic Transit používáte AS prepending, typický sled událostí vypadá takto:

• Počáteční stav: Cloudflare inzeruje váš prefix s výchozí prioritou ("asn_prepend_count": 0). Cloudflare směruje veškerý provoz do vaší sítě přes globální síť Cloudflare.
• Snížení priority Cloudflare: Prefix aktualizujete přes API a nastavíte počet AS prependů (například "asn_prepend_count": 3). Cloudflare nyní inzeruje váš prefix s delší AS_PATH. Externí sítě aktualizují své BGP tabulky, aby rozpoznaly, že cesta přes Cloudflare má nový, delší AS_PATH.
• Zavedení nového poskytovatele: Stejný prefix začnete inzerovat z alternativního poskytovatele se standardní (kratší) AS_PATH.
• Konečný stav: Externí sítě nyní dostávají dvě inzerce: trasu s prependem přes Cloudflare a trasu bez prependu přes vašeho nového poskytovatele. Externí síť si zvolí cestu podle vlastních pravidel politiky BGP.

Když se chystáte odstranit provoz pro Bring Your Own IP (BYOIP) prefixu z Cloudflare edge, přímé stažení trasy BGP (BGP withdrawal) nese riziko jejího uvíznutí. K tomuto stavu dochází, když trasa uvízne v Default-Free Zone (DFZ) ↗. Páteřní routery, kterým oznámení o stažení trasy uniklo, nadále přeposílají provoz na již neaktivní další skok, což se označuje jako blackhole. Více se o tom dočtete v našem blogovém příspěvku BGP zombies a nadměrný path hunting ↗.

Toto riziko se nejvíce projevuje v případech, kdy globální směrovací tabulka spoléhá na záložní mechanismus směrování od konkrétnějších k méně konkrétním prefixům. Protože je tento mechanismus velmi náchylný k nestabilitě tras, Cloudflare doporučuje vícekrokový proces postupného odstavování provozu.

Při odklánění provozu použijte na Cloudflare i u svého ISP (poskytovatele internetových služeb) stejnou délku prefixu, protože shodná délka prefixu zajišťuje nejefektivnější a nejpředvídatelnější chování.

Následující kroky popisují doporučený vícekrokový proces vyprazdňování provozu, který zajistí čisté přepnutí provozu a zabrání blackholingu.

1. Zahájení oznamování z vaší původní sítě: Začněte inzerovat prefix se stejnou délkou (například 192.0.2.0/24) z vaší lokální infrastruktury k nadřazeným poskytovatelům internetových služeb (ISP). Tím se do globální směrovací tabulky zavede konkurenční trasa stejné délky. Výběr nejlepší cesty podle BGP upřednostní vaši nativní trasu na základě jiných metrik (například kratší délka AS path nebo local preference), což umožní, aby provoz začal odtékat z edge sítě Cloudflare. Mějte na paměti, že část vašeho provozu se nemusí směrovat podle očekávání, protože to závisí na tom, jak váš ISP upřednostňuje trasy (například trasa Cloudflare může být považována za méně preferovanou cestu, pokud není zcela stažena).

2. Počkejte na globální konvergenci BGP: Počkejte určitou dobu (obvykle pět až deset minut), než se nová nativní inzerce plně rozšíří po globální směrovací tabulce a než se trasy ustálí. Toto pasivní čekání zajistí, že se většina provozu přesune do vaší lokální sítě ještě před dalším krokem.

3. Oznamte stažení trasy BGP z edge sítě Cloudflare: Jakmile ověříte, že se provoz úspěšně vyprázdnil, zastavte inzerci prefixu z edge sítě Cloudflare pomocí jedné z metod řízení BGP.

4. Proces vyprazdňování provozu je dokončen.

Pokud používáte CNI s Dataplane v2, tunely GRE nebo IPsec, můžete:

• Vaše prefixy se automaticky stáhnou z globální edge infrastruktury Cloudflare, jakmile ze směrovací tabulky Magic Transit Virtual Network stáhnete všechny odpovídající prefixy naučené přes BGP.
• Vaše prefixy se automaticky oznámí prostřednictvím globální edge infrastruktury Cloudflare, jakmile máte ve směrovací tabulce Magic Transit Virtual Network alespoň jeden odpovídající prefix naučený přes BGP.

Automatické globální inzerování a stažení povolíte aktivací této funkce u BGP prefixu pomocí Addressing API. Například:

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

Jakmile toto nakonfigurujete pro prefix BGP, Cloudflare použije následující logiku:

• Pokud ve směrovací tabulce virtuální sítě Magic Transit neexistuje žádná trasa BGP, která by přesně odpovídala prefixu BGP, Cloudflare tento prefix BGP stáhne.
• Pokud ve směrovací tabulce virtuální sítě Magic Transit existuje alespoň jedna trasa BGP, která přesně odpovídá prefixu BGP, Cloudflare tento prefix BGP oznámí.

BGP prefix z Addressing API a BGP trasa ve směrovací tabulce Magic Transit Virtual Network se musí přesně shodovat (stejný IP prefix a stejná délka prefixu CIDR). Pokud existuje platná trasa k podsíti nebo nadřazené síti, Cloudflare BGP prefix stáhne, pokud neexistuje přesně odpovídající BGP trasa v Magic Transit Virtual Network.

Jako alternativu k nastavení AS prepends na anycast prefixu přes API, můžete pomocí BGP komunit řídit počet AS prepend, které Cloudflare pro váš prefix oznamuje ze svého edge. Hodnoty komunit jsou tyto:

• 13335:50101: Jeden prepend s ASN 13335
• 13335:50102: Dva prependy s ASN 13335
• 13335:50103: Tři prependy s ASN 13335

Pokud potřebujete přejít na svého alternativního poskytovatele služeb, můžete ASN Cloudflare vícekrát prependovat. Cílem obvykle je učinit trasu méně preferovanou a umožnit plynulý přechod k novému poskytovateli. Čím vyšší je počet prependů, tím méně preferované bude připojení Cloudflare, pokud nejsou zavedena žádná jiná pravidla určující prioritu.

Viz upozornění na používání AS prependů kde najdete důležité informace o chování peer zařízení při použití této funkce.

Pro scénáře nasazení na vyžádání můžete prostřednictvím BGP volitelně řídit stav oznamování svého prefixu v globální síti Cloudflare (oznamovaný, nebo stažený). Řízení BGP funguje tak, že navážete relace BGP s globálně distribuovanými Route Reflectors Cloudflare, které zahájí šíření oznámení vašeho prefixu napříč globální sítí Cloudflare. S Route Reflectors Cloudflare můžete peerovat přes internet nebo CNI. CNI peering je dostupný prostřednictvím vašeho account týmu.

Prefixy ze sítě Cloudflare můžete oznamovat podporovanou metodou na vyžádání, například pomocí BGP control, nebo dynamicky přes uživatelské rozhraní, API nebo Network Flow. Při onboardingu svých prefixů typu on-demand určete, zda chcete oznamování řízené pomocí BGP, nebo dynamické oznamování (prostřednictvím dashboardu, API nebo Network Flow).

Naše síťová architektura využívá více redundantních Route Reflectors. Výpadek jednoho z nich nijak neovlivní celkovou odolnost sítě ani předávání provozu. Pro maximální odolnost doporučujeme peerovat se všemi třemi redundantními Route Reflectors Cloudflare.

Pokud chcete začít používat BGP control, kontaktujte tým odpovědný za váš účet a uveďte následující informace:

• IP adresy koncových bodů BGP
• Prefixy, které chcete používat s BGP Control
• Vaše ASN pro relaci BGP

Po obdržení vašich údajů Cloudflare aktualizuje firewallové filtry pro navázání BGP relace a poskytne vám BGP endpointy pro správu vašich prefixů.

Následující příklady ukazují konfigurace peeringu pro Cisco IOS ↗ a Juniper Junos OS ↗ pro nasazení na vyžádání využívající řízení pomocí BGP. Použité IP adresy pocházejí z route reflectorů společnosti Cloudflare a měly by zůstat beze změny.

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

Pokud pro přivedení síťového provozu do Magic Transit používáte CNI s Dataplane v2, tunely GRE nebo IPsec, přečtěte si Informace o BGP se dozvíte, jak pomocí BGP řídit směrování provozu mezi Cloudflare a vaší sítí. Všimněte si, že jde o jinou možnost než použití BGP jako prostředku k řízení stavu inzerce vašeho prefixu.

Magic Transit podporuje jak statické směrování, tak BGP pro směrování provozu ze sítě Cloudflare do vašich nakonfigurovaných výstupních bodů (off-ramp): tunelů GRE, tunelů IPsec nebo CNI. Cloudflare v současné době nepodporuje inzerci cest pro účely traffic engineeringu. Jako osvědčený postup pro snížení latence na posledním úseku zvažte omezení cest na jednotlivé regiony.

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

Výchozí nastavení pro oblasti statických tras je Všechny regiony. Rozsah svého provozu nakonfigurujte v Kód regionu sekci, pokud přidání nebo úprava statickou trasu.

Viz Omezení tras na konkrétní regiony s dalšími informacemi.