GCP BYOIP: offentlig annonsering är inte en privat rutt
Att dela ett BYOIP-prefix mellan plats och moln kräver två planer. Separera den offentliga annonseringen, delegeringen och det privata nästa hoppet.
En del av ett offentligt block stannar på platsen och en del flyttar in i Google Cloud. Den meningen beskriver två planer, inte en: en plan för annonsering på internet och en plan för privat vidarebefordran. Att behandla dem som ett enda routingproblem är där BYOIP-designer går fel.
De inblandade objekten svarar på olika frågor, och bara ett av dem handlar om vart paketen tar vägen härnäst.
Tre objekt, tre frågor
Ett offentligt annonserat prefix är den enhet som Google annonserar till internet i ditt namn. Ett offentligt delegerat prefix är hur importerat utrymme tilldelas stödda Cloud-resurser. En VPC-rutt, inklusive en som lärs in via Cloud Router från en VPN, väljer ett privat nästa hopp. Var och en har sin egen räckvidd, sitt eget API och sitt eget felmeddelande.
Tabellversionen är kortare.
| Object | Question it answers |
|---|---|
| Public advertised prefix | Which authorized range Google announces publicly |
| Public delegated prefix | How imported space is allocated to Cloud resources |
| VPN or Cloud Router route | Which private next hop carries a destination |
Bara den tredje raden handlar om vidarebefordran inne i ditt nätverk.
Vad BYOIP-överlappningsvarningen täcker
Googles BYOIP-dokumentation behandlar det annonserade prefixet som en annonseringsenhet och varnar för överlappande externa annonseringar, inklusive ett subprefix som annonseras utanför Google. Den varningen handlar om den offentliga annonseringsplanen. Det är inte ett påstående om varje privat rutt du kan lägga till.
Att delegera en mindre tilldelning inne i ett importerat prefix ger dig inte i sig tillstånd att annonsera resten från ett annat ursprung.
Ställ frågan i termer av vem som annonserar vad. Om Google annonserar hela det importerade prefixet skapar ett andra ursprung som annonserar ett subprefix exakt det överlapp som dokumentationen varnar för, hur prydliga dina VPC-rutter än ser ut.
Vad en privat rutt avgör
Ett prefix som lärs in via en VPN är inte en internetannonsering, och ingen mängd BGP gör det till en. Det är en post i en VPC-rutttabell som säger vilken tunnel eller gateway som ska bära trafiken för den destinationen. Om posten är kvalificerad, vald eller användbar beror på VPC:ns egna routingregler.
Längsta prefixmatchning gäller inne i rutttabellen, så en längre VPN-rutt kan vinna lokalt utan att något ändras vid den offentliga kanten.
Att dela ett prefix: beslutet som kommer först
Om arkitekturen kräver att halva blocket annonseras från ett datacenter och halva från Google, avgör annonseringsplanen innan du importerar något. Bekräfta vilka intervall Google får annonsera, vilka som förblir annonserade någon annanstans och om de två överlappar. Designa sedan den privata vägen för varje destination och dess returväg. Om leverantörerna inte stöder den delning du vill ha, ändra delningen i stället för att hoppas att ett längre VPN-prefix åsidosätter ett beslut vid den offentliga kanten.
Den ordningen spelar roll eftersom den andra planen inte kan reparera den första.
Verifiera båda planerna separat
Kontrollera den offentliga sidan med gcloud compute public-advertised-prefixes list och bekräfta intervallen och deras status. Kontrollera den privata sidan med gcloud compute routes list och gcloud compute routers get-status, vilket visar vad BGP faktiskt utbytte.
En uppsättning utdata berättar vad internet ser. Den andra berättar vart din trafik tar vägen. Ingen av dem ersätter den andra.