Google PCNE: Łączność hybrydowa, Cloud Router i BGP — Przewodnik do nauki

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Część Google Professional Cloud Network Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Łączność hybrydowa w Google Cloud umożliwia prywatną, kontrolowaną komunikację między sieciami VPC a sieciami zewnętrznymi, takimi jak lokalne centra danych lub inne chmury. Podstawowe elementy składowe to bramy HA VPN i Cloud VPN, Cloud Router z BGP do dynamicznego routingu oraz Interconnect z VLAN attachments. Projekty muszą równoważyć przepustowość, opóźnienia, niezawodność, złożoność operacyjną i koszty, jednocześnie przestrzegając deterministycznego zachowania routingu i izolacji domen awarii. Ta sekcja omawia logikę projektowania i działania, typowe tryby awarii oraz systematyczne rozwiązywanie problemów.

Łączność hybrydowa: HA VPN, Cloud Router i Interconnect

HA VPN i Cloud VPN
- HA VPN to regionalna, wysoko dostępna sieć IPsec VPN, która obsługuje IKEv2 i wymaga Cloud Router do dynamicznego routingu (eBGP). Brama HA VPN ma dwa interfejsy; aby uzyskać SLA i ECMP, należy zbudować dwa tunele na każdym interfejsie do odrębnych punktów końcowych peera.
- Classic Cloud VPN obsługuje IKEv1 lub IKEv2 oraz tunele statyczne lub oparte na trasach; nie obsługuje umowy SLA dla HA VPN. Używaj go tylko wtedy, gdy peery nie obsługują BGP lub musisz używać selektorów opartych na politykach.
- Brama peera (peer gateway) to zdalne urządzenie/adres IP VPN. W przypadku HA VPN zdefiniuj bramę peera z jednym lub wieloma publicznymi adresami IP, aby modelować odrębne interfejsy lub urządzenia w celu zapewnienia redundancji.
- Projektowanie pod kątem SLA: Aby kwalifikować się do umowy SLA na poziomie 99,99% dla HA VPN, należy wdrożyć redundantne tunele na niezależnych urządzeniach lub interfejsach on-premises i używać dynamicznego routingu. Classic VPN nie jest objęty umową SLA.
- Skalowanie przepustowości: Pojedynczy tunel IPsec ma ograniczoną przepustowość. Użyj ECMP na wielu tunelach, aby zwiększyć zagregowaną przepustowość. Można to osiągnąć, kończąc dodatkowe tunele na unikalnych publicznych adresach IP peera.
Cloud Router i BGP
- Cloud Router to regionalna usługa płaszczyzny sterowania, która ustanawia sesje BGP z tunelami VPN lub VLAN attachments usługi Interconnect i dynamicznie wymienia trasy.
- Tryb routingu dynamicznego (na poziomie VPC) określa, gdzie nauczone trasy dynamiczne są użyteczne i które trasy podsieci VPC są rozgłaszane:
  - Regional: nauczone trasy dynamiczne są poznawane i używane/importowane tylko w tym samym regionie.
  - Global: nauczone trasy dynamiczne są poznawane i używane/importowane we wszystkich regionach; wszystkie trasy podsieci VPC (globalnie) są rozgłaszane do peerów.
Dedicated Interconnect i Partner Interconnect
- Dedicated Interconnect zapewnia fizyczne obwody 10 Gb/s lub 100 Gb/s bezpośrednio do Google w obiekcie kolokacyjnym. Otrzymujesz Letter of Authorization – Connecting Facility Assignment (LOA‑CFA), aby umożliwić połączenia krosowe (cross-connects). Tworzysz VLAN attachments (interconnect attachments), które mapują tagi 802.1Q na regionalną łączność L3 powiązaną z Cloud Router.
- Partner Interconnect zapewnia logiczną łączność za pośrednictwem dostawcy usług. Żądasz VLAN attachments od partnera; przepustowość jest dostarczana na brzegu sieci partnera. Nadal należy powiązać te załączniki z Cloud Router w celu obsługi BGP.
- Redundancja i SLA: Użyj dwóch załączników w tym samym regionie, umieszczonych w odrębnych domenach dostępności brzegowej (edge availability domains) (i na odrębnych fizycznych łączach Interconnect, jeśli ma to zastosowanie), aby osiągnąć wyższe poziomy SLA (np. 99,99%). Pojedynczy załącznik lub łącze obniża SLA. W przypadku Partner Interconnect, ogólne SLA zależy również od partnera.
Połączenia krosowe (cross-connects) i VLAN attachments
- Połączenia krosowe to fizyczne połączenia światłowodowe między Twoją szafą/sprzętem a szafą Google w pomieszczeniu krosowym (meet-me room). Przedstaw LOA-CFA swojemu dostawcy, aby je zrealizować.
- VLAN attachments to logiczna demarkacja L2 do regionu VPC. Każdy załącznik:
  - Jest powiązany z dokładnie jedną siecią VPC i regionem za pośrednictwem Cloud Router.
  - Jest konfigurowany w parach w celu zapewnienia redundancji i ECMP.
  - Przenosi tylko ruch L3; brak rozszerzenia L2.

Krótki przykład:

Utwórz Cloud Router i BGP dla załącznika lub peera HA VPN:

undefined

Routing i zachowanie BGP

Routing dynamiczny a statyczny
- Routing dynamiczny z Cloud Router zapewnia automatyczne uczenie się tras, konwergencję i ECMP. Skaluje się i zmniejsza obciążenie operacyjne w miarę rozrastania się sieci.
- Routing statyczny jest odpowiedni, gdy peery nie obsługują BGP lub dla wąsko zdefiniowanych, deterministycznych ścieżek. W VPC trasy statyczne mają priorytet numeryczny; niższe wartości są preferowane wśród tras statycznych o tej samej długości prefiksu.
- Wybór trasy w VPC:
  - Wygrywa najdłuższe dopasowanie prefiksu.
  - Trasy podsieci nie mogą być nadpisywane przez trasy niestandardowe.
  - Dla równych długości prefiksów, trasy statyczne są wybierane według najniższego priorytetu. Wśród tras dynamicznych, Cloud Router już rozstrzygnął najlepsze ścieżki przed ich zainstalowaniem. Domyślna trasa systemowa jest najmniej preferowana.
Sesje BGP, rozgłaszanie oraz import/eksport
- Cloud Router domyślnie eksportuje podsieci VPC lub niestandardowy zestaw prefiksów. W razie potrzeby można rozgłaszać 0.0.0.0/0 lub agregować prefiksy, ale takie działanie przyciąga ruch on-prem w kierunku chmury, jeśli pozwalają na to polityki; projektuj to świadomie.
- Cloud Router importuje wszystkie dozwolone prefiksy on-prem i instaluje je jako trasy dynamiczne zgodnie z trybem routingu dynamicznego VPC.
- Priorytet rozgłaszanej trasy per-peer pozwala wpływać na to, jak routery on-prem preferują jedną ścieżkę Google nad drugą; niższa wartość priorytetu przekłada się na bardziej preferowany MED w kierunku peera.
ASN-y, MED i tryb active-standby
- Używaj unikalnego prywatnego numeru ASN dla każdej domeny administracyjnej, chyba że uzasadnione jest użycie publicznych ASN-ów. W przypadku wielu routerów on-prem łączących się z tą samą siecią VPC dla tych samych prefiksów:
  - Aby włączyć ECMP lub spójną najlepszą ścieżkę (best-path), używaj tego samego zdalnego numeru ASN on-prem na wszystkich routerach rozgłaszających te same prefiksy. Różne zdalne ASN-y mogą uniemożliwić instalację tras o równym koszcie na Cloud Router.
  - Dla trybu active/standby, manipuluj wartością MED (niższa jest bardziej preferowana) po stronie on-prem lub dostosuj priorytet rozgłaszanej trasy per-peer w Cloud Router, aby strona on-prem preferowała ścieżkę podstawową. AS-path prepending jest alternatywą, ale mniej precyzyjnym narzędziem.
Projektowanie wielościeżkowe (multipath)
- Cloud Router wspiera ECMP na wielu równorzędnych ścieżkach BGP zarówno dla załączników HA VPN, jak i Interconnect. Zapewnij równe atrybuty (długość AS-path, MED, local-pref) i różne adresy następnego przeskoku (next hop). W przypadku HA VPN, kończ tunele na różnych adresach IP peerów. W przypadku Interconnect, używaj redundantnych załączników.

Odporność, wykrywanie i usługi wyjściowe (egress)

BFD i wykrywanie awarii
- BFD przyspiesza wykrywanie awarii dla sesji BGP na HA VPN i Interconnect. Włącz BFD po obu stronach z kompatybilnymi interwałami, aby osiągnąć wykrywanie w czasie poniżej sekundy lub kilku sekund, w zależności od potrzeb stabilności. Połącz z IKE DPD na tunelach IPsec. Upewnij się, że urządzenia peer są w stanie przetwarzać częstszy ruch kontrolny.
- Uważaj na asymetryczne wykrywanie: agresywne ustawienia BFD w połączeniu z przeciążonymi łączami mogą powodować niestabilność sesji (flapping); zacznij od konserwatywnych timerów i monitoruj.
Wzorce topologii redundantnych
- HA VPN: Użyj jednej bramy HA VPN na region i zakończ tunele na dwóch różnych urządzeniach lub interfejsach on-prem. Zbuduj co najmniej cztery tunele (dwa na interfejs) i jeden Cloud Router na region. Utrzymuj spójne zdalne ASN-y, oferując ECMP.
- Interconnect: Użyj co najmniej dwóch załączników w każdym regionie w różnych strefach dostępności brzegowej (edge availability domains). W przypadku Dedicated Interconnect, w miarę możliwości wdrażaj łącza na różnych urządzeniach brzegowych i w różnych obiektach.
Cloud NAT, adresy zewnętrzne i ruch wyjściowy (egress) dla prywatnych obciążeń
- Cloud NAT to regionalna, zarządzana usługa ruchu wyjściowego (egress) dla zasobów bez zewnętrznych adresów IP. Nie wykonuje SNAT dla instancji, które mają zewnętrzne adresy IP; te wychodzą z sieci bezpośrednio. Wybierz podsieci lub wszystkie podsieci w regionie, aby objąć prywatne obciążenia.
- Dostosuj pule adresów IP NAT do liczby jednoczesnych połączeń i portów efemerycznych; wybierz ręczną lub automatyczną alokację IP. Włącz logowanie w celach diagnostycznych.
- Aby uzyskać prywatny dostęp do interfejsów API Google:
  - Wewnątrz VPC: włącz Private Google Access na podsieciach, aby maszyny wirtualne bez zewnętrznych adresów IP mogły docierać do interfejsów API Google za pośrednictwem wirtualnych adresów IP Google.
  - Z lokalizacji on-prem: użyj punktów końcowych Private Service Connect dla interfejsów API Google oraz hybrydowego DNS, aby klienci on-prem mogli rozwiązywać nazwy i docierać do API przez prywatne łącza hybrydowe, omijając internet.
- Jeśli domyślna trasa wskazuje na zaporę sieciową innej firmy, ale chcesz, aby prywatne obciążenia omijały ją w celu uzyskania dostępu do interfejsów API Google, użyj Private Service Connect lub zainstaluj trasy statyczne o wyższym priorytecie dla opublikowanych zakresów IP interfejsów API Google, kierujące do domyślnej bramy internetowej, w połączeniu z Private Google Access na podsieciach.
Integracja hybrydowego DNS
- Używaj prywatnych stref Cloud DNS do rozwiązywania nazw wewnątrz VPC. Rozszerz działanie na środowisko on-prem za pomocą:
  - Przekierowanie przychodzące (inbound forwarding): resolwery on-prem przekazują zapytania do Cloud DNS dla prywatnych stref hostowanych w VPC.
  - Przekierowanie wychodzące (outbound forwarding): resolwery w VPC przekazują zapytania dla wybranych domen do serwerów DNS on-prem.
  - Strefy peeringowe (peering zones) do rozwiązywania nazw między sieciami VPC w środowiskach Shared VPC lub wieloprojektowych.
- Aby zapewnić prywatną osiągalność API, utwórz prywatną strefę mapującą nazwy hostów API na punkty końcowe Private Service Connect lub na odpowiednie prywatne adresy VIP Google w przypadku korzystania z Private Google Access i upewnij się, że te nazwy są rozwiązywalne ze środowiska on-prem za pomocą przekierowywania DNS.

Planowanie i rozwiązywanie problemów

Kompromisy między przepustowością, opóźnieniem i kosztem
- VPN: najszybszy do wdrożenia, najniższy stały koszt, ograniczona przepustowość na tunel, wyższy narzut na CPU/krypto na bit i zazwyczaj wyższe opóźnienie w porównaniu z łączami prywatnymi.
- Dedicated Interconnect: najwyższa przepustowość i najniższy koszt na bit przy przewidywalnym opóźnieniu; wyższe koszty stałe i dłuższy czas realizacji (połączenia krosowe, kolokacja).
- Partner Interconnect: rozwiązanie pośrednie; wykorzystuje zasięg dostawcy; SLA i opóźnienie zależą od ścieżki partnera.
- Umieszczaj załączniki i bramy regionalnie blisko obciążeń, aby zminimalizować opóźnienie. Użyj Shared VPC do centralizacji łączności w projekcie hosta, obsługując jednocześnie wiele projektów usług.
- Weź pod uwagę symetrię ruchu, wymagania dotyczące inspekcji i domeny awarii. Unikaj pojedynczych punktów awarii w lokalnej infrastrukturze ostatniej mili i na ścieżkach dostawcy.
Systematyczna diagnoza problemów z tunelem, BGP i routingiem
1. Ustanawianie tunelu
  - Weryfikuj zgodność wersji IKE: HA VPN wymaga IKEv2; jeśli peer obsługuje tylko IKEv1 lub VPN oparty na politykach, użyj Classic VPN.
  - Sprawdź wspólne klucze tajne, propozycje (szyfrowanie, grupy DH), NAT‑T i osiągalność portów UDP 500/4500.
  - Potwierdź adresy IP peerów i upewnij się, że każdy tunel wskazuje na oddzielny interfejs peera w celu zapewnienia redundancji.
2. Kondycja sesji BGP
  - Potwierdź stany BGP na obu końcach; sprawdź status Cloud Router. Jeśli BFD jest włączone, ale sesje są niestabilne (flapping), złagodź timery.
  - Zweryfikuj konfigurację ASN; niedopasowane oczekiwania mogą uniemożliwić ECMP lub spowodować niespodziewany wybór najlepszej ścieżki.
  - Upewnij się, że adresacja IP dla sesji BGP używa poprawnych adresów link‑local lub RFC1918 skonfigurowanych na interfejsie tunelu lub załącznika.
3. Wymiana i propagacja tras
  - Sprawdź tryb anonsowania Cloud Router (DEFAULT vs CUSTOM). Upewnij się, że oczekiwane podsieci lub agregaty są eksportowane.
  - Sprawdź trasy otrzymane na Cloud Router; oceń AS‑path, MED. Jeśli zamierzeniem jest konfiguracja aktywny/zapasowy, upewnij się, że MED lub priorytet anonsowanej trasy odzwierciedlają ten zamiar.
  - Zweryfikuj tryb routingu dynamicznego VPC (REGIONAL vs GLOBAL), aby nauczone trasy pojawiały się tam, gdzie są potrzebne. Pamiętaj, że trasy podsieci nie mogą być nadpisane.
  - W przypadku konfliktów, jeśli trasa statyczna i dynamiczna pasują do tej samej długości prefiksu, wygrywa trasa statyczna o najniższym priorytecie. Dostosuj lub usuń nakładające się trasy statyczne, jeśli jest to niezamierzone.
4. Walidacja płaszczyzny danych
  - Użyj VPC Flow Logs i logów Cloud NAT, aby potwierdzić ścieżkę ruchu wychodzącego i translację adresów. Jeśli VM nadal wychodzi z własnym zewnętrznym IP, usuń ten zewnętrzny adres IP, aby wymusić użycie NAT.
  - W przypadku Interconnect, zweryfikuj stan operacyjny załącznika i upewnij się, że oba załączniki są administracyjnie włączone i powiązane z właściwym Cloud Router.
  - Potwierdź, że reguły zapory sieciowej zezwalają na ruch BGP i aplikacji; pamiętaj, że zakresy źródłowe health checków Google muszą mieć dostęp do backendów load balancera.
5. Szczegóły uruchomienia Interconnect
  - Uzyskaj LOA‑CFA z konsoli lub poprzez kontakt e‑mail z NOC. Przed uruchomieniem BGP potwierdź z dostawcą poziomy sygnału świetlnego na połączeniu krosowym i tagowanie VLAN.

Praktyczny scenariusz problemowy

Firma Contoso Manufacturing migruje obciążenia ERP do Google Cloud, utrzymując jednocześnie działanie lokalnych fabryk. Wymagania: prywatna łączność 20 Gbps z przełączaniem awaryjnym w czasie poniżej sekundy, scentralizowane sterowanie routingiem, ruch wychodzący z lokalizacji on‑premise do chmury w trybie aktywny/zapasowy, prywatny dostęp do Google APIs bez użycia publicznego internetu oraz minimalny narzut operacyjny.

Podejście:

Wdróż dwa łącza Dedicated Interconnect w tym samym obszarze metropolitalnym, w różnych brzegowych domenach dostępności i obiektach; utwórz dwa załączniki VLAN na region (główny i zapasowy) i powiąż je z regionalnym Cloud Router.
- Uzasadnienie: Dedicated Interconnect zapewnia wymaganą zagregowaną przepustowość i przewidywalne opóźnienie. Redundantne łącza i załączniki izolują awarie i kwalifikują do wyższego SLA. Wiele załączników umożliwia ECMP i konserwację bez utraty ruchu.
Skonfiguruj jeden Cloud Router na region z dwoma peerami BGP — po jednym na załącznik — i włącz BFD.
- Uzasadnienie: Pojedynczy router upraszcza zarządzanie płaszczyzną sterowania, jednocześnie wspierając ECMP przez wiele następnych przeskoków (next hops). BFD skraca czas wykrywania awarii do kilku sekund, poprawiając RTO konwergencji dla aplikacji ERP.
Ustandaryzuj zdalny ASN on‑premise na obu brzegowych routerach fabrycznych, które peerują z Google, i anonsuj identyczne prefiksy z każdego z nich.
- Uzasadnienie: Dopasowane zdalne numery ASN pozwalają Cloud Router na instalowanie tras o równym koszcie i równoważenie obciążenia, gdy jest to pożądane. Gdyby użyto różnych numerów ASN, tylko jeden zestaw tras mógłby zostać zainstalowany, co uniemożliwiłoby multipath.
Zaimplementuj preferencję aktywny/zapasowy z on‑premise do Google używając MED, a z Google do on‑premise używając priorytetu anonsowanej trasy Cloud Router; ustaw niższe wartości na ścieżkach głównych.
- Uzasadnienie: Polityka obustronna zapewnia deterministyczną kierunkowość: fabryki preferują główny obszar metropolitalny, aby dotrzeć do chmury, a VPC firmy Contoso preferuje główne DC fabryki dla ruchu powrotnego. Unika to niezamierzonej asymetrii.
Włącz Private Service Connect dla Google APIs w Shared VPC i utwórz prywatną strefę DNS mapującą nazwy hostów API na endpoint PSC; skonfiguruj przekierowanie przychodzące (inbound forwarding) w Cloud DNS, aby lokalne resolwery DNS mogły prywatnie rozwiązywać te nazwy.
- Uzasadnienie: PSC zapewnia prywatny dostęp do Google APIs wewnątrz VPC. Hybrydowy DNS sprawia, że te endpointy są osiągalne z fabryk przez Interconnect, eliminując ekspozycję na internet i zależności od zapory sieciowej dla usług wspierających ERP.
Jako backup VPN, dodaj bramę HA VPN w każdym regionie z dwoma tunelami do różnych urządzeń on‑premise; włącz BFD na sesjach BGP i zezwól na ECMP.
- Uzasadnienie: Jeśli Interconnect ulegnie awarii, HA VPN utrzymuje prywatną osiągalność. Podwójne tunele na urządzenie utrzymują ciągłość SLA i przepustowości, a BFD przyspiesza przełączanie awaryjne.
Dla prywatnego ruchu wychodzącego obciążeń do internetu i miejsc docelowych innych niż Google, skonfiguruj regionalny Cloud NAT na podsieciach ERP; nie przypisuj zewnętrznych adresów IP do maszyn wirtualnych.
- Uzasadnienie: Cloud NAT skaluje translację adresów bez narzutu na zarządzanie VM i zachowuje prywatną adresację. Usunięcie zewnętrznych adresów IP gwarantuje, że NAT jest używany i upraszcza kontrolę ruchu wychodzącego.
Zweryfikuj routing i przełączanie awaryjne za pomocą testów etapowych: odłącz jeden załącznik, następnie jeden router on‑premise, a potem zasymuluj degradację łącza; monitoruj BGP, BFD i SLO aplikacji. Dostosuj timery BFD, jeśli wystąpią niestabilności (flaps).
- Uzasadnienie: Kontrolowane wstrzykiwanie błędów weryfikuje, czy projekt spełnia cele odzyskiwania po awarii i zapobiega niespodziankom w środowisku produkcyjnym. Dostosowanie timerów równoważy stabilność i responsywność.