Contoso Ltd. ma topologię hub-spoke we wschodnich Stanach Zjednoczonych (East US): VNet huba (Hub-VNet) z NVA oraz dwa VNety spoke (Spoke-A i Spoke-B). Spoke-A jest połączony peeringiem z Hub-VNet, a Spoke-B jest połączony peeringiem z Hub-VNet. Inżynierowie zauważają, że maszyny wirtualne w Spoke-A nie mogą dotrzeć do maszyn wirtualnych w Spoke-B przez połączenia peeringowe. Które wyjaśnienie najlepiej opisuje, dlaczego bezpośredni ruch spoke-to-spoke nie przechodzi przez peering huba, i co Contoso musi zrobić, aby umożliwić komunikację spoke-to-spoke bez przebudowy wszystkich peeringów?

Poprawna odpowiedź wyjaśnia, że peering VNet nie jest tranzytywny. Oznacza to, że VNety Spoke-A i Spoke-B, choć oba połączone peeringiem z Hub-VNet, nie mogą komunikować się bezpośrednio ze sobą za pośrednictwem huba bez dodatkowej konfiguracji. Aby umożliwić komunikację spoke-to-spoke, ruch musi być jawnie kierowany przez NVA w hubie. Wymaga to skonfigurowania tras zdefiniowanych przez użytkownika (UDR) w każdym VNecie spoke, aby wskazywały NVA huba jako następny przeskok dla ruchu przeznaczonego do innych spoke'ów. Pozostałe opcje są nieprawidłowe: Peering VNet nie blokuje domyślnie ruchu east-west, ale po prostu nie zapewnia tranzytywności. Nie ma funkcji "Transit Peering" w Azure. Współdzielona sieciowa grupa zabezpieczeń (NSG) nie umożliwia komunikacji między VNetami; NSG kontrolują ruch wewnątrz VNetów i podsieci, a nie routing między VNetami. Azure nie kieruje automatycznie ruchu spoke-to-spoke przez hub na podstawie subskrypcji; routing tranzytywny zawsze wymaga jawnej konfiguracji.