O parte dintr-un bloc public rămâne la sediu, iar o parte se mută în Google Cloud. Acea frază descrie două planuri, nu unul: un plan de anunț pe internet și un plan de redirecționare privată. Tratarea lor ca o singură problemă de rutare este locul unde proiectele BYOIP greșesc.

Obiectele implicate răspund la întrebări diferite, iar doar unul dintre ele se referă la unde merg pachetele mai departe.

Trei obiecte, trei întrebări

Un prefix anunțat public este unitatea pe care Google o anunță pe internet în numele dumneavoastră. Un prefix delegat public este modul în care spațiul importat este alocat resurselor Cloud acceptate. O rută VPC, inclusiv una învățată prin Cloud Router dintr-un VPN, selectează un următor salt privat. Fiecare are propriul domeniu, propriul API și propriul mesaj de eroare.

Versiunea sub formă de tabel este mai scurtă.

ObjectQuestion it answers
Public advertised prefixWhich authorized range Google announces publicly
Public delegated prefixHow imported space is allocated to Cloud resources
VPN or Cloud Router routeWhich private next hop carries a destination

Doar al treilea rând se referă la redirecționarea din interiorul rețelei dumneavoastră.

Ce acoperă avertismentul BYOIP privind suprapunerea

Documentația BYOIP a Google tratează prefixul anunțat ca unitate de anunț și avertizează asupra anunțurilor externe suprapuse, inclusiv un subprefix anunțat în afara Google. Acel avertisment se referă la planul de anunț public. Nu este o afirmație despre fiecare rută privată pe care ați putea-o adăuga.

Delegarea unei alocări mai mici în interiorul unui prefix importat nu vă dă, prin ea însăși, permisiunea de a anunța restul dintr-o altă origine.

Puneți întrebarea în termeni de cine anunță ce. Dacă Google anunță întregul prefix importat, o a doua origine care anunță un subprefix creează exact suprapunerea despre care avertizează documentația, oricât de ordonate ar arăta rutele dumneavoastră VPC.

Ce decide o rută privată

Un prefix învățat printr-un VPN nu este un anunț pe internet, iar nicio cantitate de BGP nu îl va face astfel. Este o intrare într-un tabel de rute VPC care spune ce tunel sau gateway ar trebui să transporte traficul către acea destinație. Dacă acea intrare este eligibilă, selectată sau utilizabilă depinde de regulile proprii de rutare ale VPC-ului.

Potrivirea celui mai lung prefix se aplică în interiorul tabelului de rute, astfel încât o rută VPN mai lungă poate câștiga local fără a schimba nimic la marginea publică.

Împărțirea unui prefix: decizia care vine prima

Dacă arhitectura cere ca jumătate din bloc să fie anunțată dintr-un centru de date și jumătate din Google, stabiliți planul de anunț înainte de a importa orice. Confirmați ce intervale poate anunța Google, care rămân anunțate în altă parte și dacă cele două se suprapun. Apoi proiectați calea privată pentru fiecare destinație și calea ei de întoarcere. Dacă furnizorii nu acceptă împărțirea dorită, schimbați împărțirea în loc să sperați că un prefix VPN mai lung va anula o decizie la marginea publică.

Acea ordine contează pentru că al doilea plan nu poate repara primul.

Verificați ambele planuri separat

Verificați partea publică cu gcloud compute public-advertised-prefixes list și confirmați intervalele și starea lor. Verificați partea privată cu gcloud compute routes list și gcloud compute routers get-status, ceea ce arată ce a schimbat efectiv BGP.

Un set de ieșiri vă spune ce vede internetul. Celălalt vă spune unde merge traficul dumneavoastră. Niciunul nu îl înlocuiește pe celălalt.

Articole similare