BYOIP hos Cloudflare: dine egne IP-præfikser på Cloudflares netværk

Et dokumenteret API-forløb tjekker præfikset mod IRR, RPKI og et ejerskabstoken, og derefter binder du det til de tjenester, der skal bruge adresserne.

Hvad Cloudflare accepterer

Fra Cloudflares dokumentation, den dag vi tjekkede:

• Hvem. Enterprise-konti, hvis kontrakt omfatter BYOIP. Account-teamet bekræfter det, og kontoens tjenestekonfiguration, før du går i gang.
• Størrelse. En /24 eller større for IPv4; for IPv6 en /48 op til en /32.
• Register. ARIN, RIPE NCC, APNIC eller et af de øvrige regionale registre. Intet om PA-, PI- eller legacy-adresser.
• Hvem der er origin. AS13335 i det dokumenterede forløb; til dit eget ASN spørger du account-teamet. Kunder, der allerede er på Cloudflares AS209242, kan beholde det, men nye kunder bruger AS13335.
• Hvor. Alle Cloudflares lokationer.
• Tjenester. Magic Transit, Spectrum, CDN'et samt Gateway DNS locations og dedikerede egress-IP'er. Magic Transit har sit eget forløb, er “not a self-serve product” (oversættelse: “ikke et selvbetjeningsprodukt”) og kan kun være standardbindingen for et helt præfiks. Et præfiks bruges til CDN-ingress eller CDN-egress, ikke begge.
• Pris. Ikke offentliggjort. Vilkårene siger, at adresserne skal bruges “solely in connection with the Customer's domains that are receiving Cloudflare's Enterprise Services” (oversættelse: “udelukkende i forbindelse med kundens domæner, der modtager Cloudflares Enterprise Services”).
• Tid. Mindst fem timers BGP-klargøring, før du annoncerer, og fire til seks timer, før hver service binding er udbredt. Konfigurationen af Magic Transit “takes around one day to roll out” (oversættelse: “tager omkring en dag at rulle ud”).

Før du går i gang

Cloudflare kan ikke tage et præfiks ind, hvis et tjek af registrering, IRR, RPKI eller ejerskab fejler. Forbered disse:

Et route-objekt, der passer præcist. Ét route-objekt pr. præfiks, du tager ind, for præcis det præfiks, med den origin, Cloudflare vil bruge: AS13335 i standardforløbet. Til at tjekke det foreslår Cloudflare IRR Explorer eller whois -h rr.ntt.net 203.0.113.0/24.

En korrekt ROA for samme origin. Cloudflare beder dig verificere den i sin RPKI Portal og i en anden kilde, som Routinator (RPKI og ROA'er).

En letter of agency (LOA), Cloudflares navn for Letter of Authorization, som transitudbyderne kræver. Cloudflare genererer den for dig, når du sætter delegate_loa_creation til true, hvilket bygger på ROA'en og ejerskabstjekket. En manuel LOA skal være en PDF og bør være på virksomhedens brevpapir med en håndskrevet underskrift, men Cloudflare accepterer en digital underskrift, hvis det er tydeligt, hvem der har skrevet under. Transitudbydere kan afvise en JPG eller PNG, og manuel behandling kan forsinke forløbet.

Et sted til valideringstokenet: beskrivelsen (descr) eller remarks i det tilsvarende route-objekt, eller en cf-validation-TXT-post i hver reverse DNS-zone for præfikset.

Et konto-ID og et API-token med rettighederne til IP Prefixes.

Trin for trin

Dette er Cloudflares dokumenterede forløb for præfikser, der ikke bruges med Magic Transit, som har sit eget forløb via account-teamet.

01Tilføj præfikset til den konto, der skal eje det:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes" \
  --request POST --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"cidr":"203.0.113.0/24","asn":13335,"delegate_loa_creation":true}'

Gem id og ownership_validation_token fra svaret.

02Offentliggør tokenet. Tilføj cf-validation: <token> i route-objektet, eller TXT-posten i reverse-zonerne.

03Validér. Send en POST til .../prefixes/$PREFIX_ID/validate. Når tjekkene af IRR, RPKI og ejerskab er godkendt, viser præfiksets felt approved "V", og du kan fjerne tokenet. Fejler et tjek, viser præfiksets detaljer status som missing, invalid eller mismatch_asn.

04Bind præfikset til en tjeneste. Hvert præfiks skal have en standard-service binding over hele præfikset; mere specifikke bindinger kan sende dele af det til CDN'et eller Spectrum. Cloudflare opretter BGP-præfikset i trukket tilbage-tilstand. Regn med mindst fem timer, og vent, til alle bindinger er aktive.

05Annoncér:

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
  --request PATCH --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --json '{"on_demand":{"advertised":true}}'

Cloudflare siger, at annoncering typisk tager to til syv minutter, og tilbagetrækning omkring 15.

06Til CDN'et opretter du et address map, når præfikset er annonceret, så proxyede DNS-poster svarer med dine adresser.

Faldgruber

• Et dækkende route-objekt er ikke nok. Cloudflare vil have et route-objekt, der passer præcist til hvert præfiks, du tager ind, med den rigtige origin.
• Bindinger tager timer, og trafikken lider imens. Cloudflare siger, at tjenesterne for de berørte adresser sandsynligvis forstyrres, mens en binding udbredes. Sæt bindinger op, før du annoncerer, og ændr dem uden for travle timer.
• To netværk, der annoncerer. Når du flytter et aktivt præfiks, så lad Cloudflare annoncere først, tjek det i et looking glass under AS13335, og træk så din egen annoncering tilbage. Lader du din blive stående, kan noget trafik gå uden om Cloudflare.
• 15-minuttersreglen. Efter at have ændret et præfiks' annoncering skal du vente mindst 15 minutter, før du ændrer det igen; API'et afviser tidligere kald med fejl 1004 (HTTP 429, rate_limit_exceeded).

Hvis du lejer blokken

Cloudflares tjenestespecifikke vilkår, senest opdateret den 28. september 2026, dækker det direkte. Er du ikke den juridiske ejer af adresserne, “must obtain written authorization from the legal owner” (oversættelse: “skal du indhente skriftlig tilladelse fra den juridiske ejer”), for at Cloudflare kan annoncere dem, og trækker ejeren den tilbage, kan Cloudflare stoppe med at annoncere dem. Indehaveren tager sig også af registersiden: ROA'en for AS13335, route-objektet med AS13335 som origin og valideringstokenet i det objekt, som kun indehaverens maintainer kan redigere. Vilkårene kræver korrekte WHOIS-data og gyldige IRR- og RPKI-poster til enhver tid, så en lejeaftale, der ophører, eller en ROA, der ændres, kan tage præfikset af Cloudflare.

Hvor RTM Networks passer ind

Vi lejer /24'er og større ud fra vores egne RIPE NCC-adresser og sælger blokke i RIPE NCC-, ARIN- og APNIC-regionerne. For adresser, du lejer af os, opretter vi ROA'en og det præcise route-objekt for AS13335, tilføjer Cloudflares valideringstoken i det og underskriver din Letter of Authorization, så trinene i API'et er det, der er tilbage til dig (lej IPv4). Er BYOIP ikke med i din Cloudflare-kontrakt, eller har du brug for færre end 256 adresser, annoncerer vi en blok og leverer den til din server over GRE eller WireGuard, ned til en enkelt adresse (GRE- og WireGuard-tunneler). Andre udbydere: BYOIP-guider.