Po utworzeniu podsieci VPC 10.1.0.0/16, 10.2.0.0/16 i 10.3.1.0/24, lokalna baza danych pod adresem 10.2.1.25 przestała odbierać ruch. Router lokalny rozgłasza 10.0.0.0/8. Jaka jest najbardziej prawdopodobna przyczyna?

Poprawna odpowiedź to "Priorytet ma bardziej specyficzna trasa podsieci VPC." W Google Cloud Platform (GCP) routing opiera się na zasadzie najdłuższego prefiksu (longest prefix match). Oznacza to, że jeśli istnieje wiele tras do tego samego miejsca docelowego, wybrana zostanie trasa z najbardziej szczegółowym (dłuższym) prefiksem. W tym przypadku, router lokalny rozgłasza trasę 10.0.0.0/8, która jest bardzo ogólna i obejmuje całą przestrzeń adresową 10.0.0.0/8. Po utworzeniu podsieci VPC 10.2.0.0/16, GCP automatycznie tworzy trasę do tej podsieci. Trasa 10.2.0.0/16 jest bardziej szczegółowa niż 10.0.0.0/8, więc ruch przeznaczony dla adresów w zakresie 10.2.0.0/16, w tym 10.2.1.25, jest kierowany do nowo utworzonej podsieci VPC zamiast do sieci lokalnej. Pozostałe opcje są mniej prawdopodobne: "Priorytet ma mniej specyficzna trasa podsieci VPC" jest nieprawidłowe, ponieważ GCP zawsze preferuje bardziej szczegółowe trasy. "Router lokalny nie rozgłasza trasy serwera bazy danych" jest mało prawdopodobne, ponieważ router rozgłasza 10.0.0.0/8, co obejmuje adres bazy danych. "Utworzono regułę zapory sieciowej w chmurze blokującą ruch do lokalnej bazy danych" jest możliwe, ale mniej prawdopodobne jako bezpośrednia przyczyna po utworzeniu podsieci VPC, ponieważ problem dotyczy routingu, a nie blokowania ruchu po dotarciu do celu.