GCP BYOIP: iepenbiere oankundiging is gjin privee-rûte
In BYOIP-prefiks tusken lokaasje en wolk ferdiele freget twa plannen. Skied it iepenbiere oankundigjen, de delegaasje en de privee folgjende hop.
In part fan in iepenbier blok bliuwt op lokaasje en in part ferhuzet nei Google Cloud. Dy sin beskriuwt twa plannen, net ien: in plan foar oankundigjen op it ynternet en in plan foar privee trochstjoering. Se as ien inkeld routingprobleem behannelje is wêr’t BYOIP-ûntwerpen misgeane.
De belutsen objekten beantsje ferskillende fragen, en mar ien fan har giet oer wêr’t de pakketten folgjende hinne geane.
Trije objekten, trije fragen
In iepenbier oankundige prefiks is de ienheid dy’t Google út jo namme op it ynternet oankundiget. In iepenbier delegearre prefiks is hoe’t ymportearre romte oan stipe Cloud-brûken tawiisd wurdt. In VPC-rûte, ynklusyf ien dy’t oer Cloud Router fan in VPN leard is, kiest in privee folgjende hop. Elk hat syn eigen berik, syn eigen API en syn eigen flaterberjocht.
De tabelferzje is koarter.
| 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 |
Allinnich de tredde rige giet oer trochstjoering binnen jo netwurk.
Wat de BYOIP-oerlapwarskôging omfettet
De BYOIP-dokumintaasje fan Google behannelt it oankundige prefiks as in oankundigingsienheid en warskôget foar oerlappende eksterne oankundigingen, ynklusyf in subprefiks dat bûten Google oankundige wurdt. Dy warskôging giet oer it plan foar iepenbier oankundigjen. It is gjin útspraak oer elke privee-rûte dy’t jo tafoegje meie.
In lytsere tawizing binnen in ymportearre prefiks delegearje jout jo op himsels gjin tastimming om de rest fan in oare oarsprong ôf oan te kundigjen.
Stel de fraach yn termen fan wa’t wat oankundiget. As Google it hiele ymportearre prefiks oankundiget, makket in twadde oarsprong dy’t in subprefiks oankundiget krekt de oerlaap dy’t de dokumintaasje warskôget foar, hoe skjin jo VPC-rûtes der ek útsjen.
Wat in privee-rûte beslút
In prefiks dy’t oer in VPN leard is, is gjin oankundiging op it ynternet, en gjin hoemannichte BGP sil dêr ien fan meitsje. It is in yngong yn in VPC-rûtetabel dy’t seit hokker tunnel as gateway it ferkear foar dat bestimming drage moat. Oft dy yngong geskikt, keazen of brûkber is, hinget ôf fan ’e eigen routingregels fan ’e VPC.
De oerienkomst fan ’e langste prefiks jildt binnen de rûtetabel, dus in langere VPN-rûte kin lokaal winne sûnder eat oan ’e iepenbiere râne te feroarjen.
In prefiks ferdiele: de beslissing dy’t earst komt
As de arsjitektuer freget dat de helte fan it blok fan in datacenter en de oare helte fan Google ôf oankundige wurdt, beslis dan it oankundigingsplan foardat jo eat ymportearje. Befêstigje hokker berikken Google oankundigje mei, hokker earne oars oankundige bliuwe, en oft de beide oerlappe. Untwerp dan it privee paad foar elke bestimming en syn weromwei. As de oanbieders de ferdieling dy’t jo wolle net stypje, feroarje dan de ferdieling ynstee fan te hoopjen dat in langer VPN-prefiks in beslissing oan ’e iepenbiere râne oerskriuwt.
Dy folchoarder is fan belang, want it twadde plan kin it earste net reparearje.
Kontrolearje beide plannen apart
Kontrolearje de iepenbiere kant mei gcloud compute public-advertised-prefixes list en befêstigje de berikken en har status. Kontrolearje de privee kant mei gcloud compute routes list en gcloud compute routers get-status, wat sjen lit wat BGP feitlik útwiksele hat.
Ien set útfier fertelt jo wat it ynternet sjocht. De oare fertelt jo wêr’t jo ferkear hinne giet. Gjin fan beide ferfangt de oare.