Contoso Ltd. hat eine Hub-Spoke-Topologie in East US: ein Hub-VNet (Hub-VNet) mit einer NVA und zwei Spoke-VNets (Spoke-A und Spoke-B). Spoke-A ist mit Hub-VNet und Spoke-B ist mit Hub-VNet gepeert. Ingenieure stellen fest, dass VMs in Spoke-A VMs in Spoke-B über die Peering-Verbindungen nicht erreichen können. Welche Erklärung beschreibt am besten, warum direkter Spoke-zu-Spoke-Datenverkehr das Hub-Peering nicht durchläuft und was Contoso tun muss, um die Spoke-zu-Spoke-Kommunikation zu ermöglichen, ohne alle Peers neu zu gestalten?

VNet-Peering ist nicht transitiv. Das bedeutet, dass Spoke-A zwar mit Hub-VNet kommunizieren kann und Spoke-B ebenfalls mit Hub-VNet, aber Spoke-A nicht direkt über das Hub-VNet mit Spoke-B kommunizieren kann. Um Spoke-zu-Spoke-Kommunikation in einer Hub-Spoke-Topologie zu ermöglichen, muss der Datenverkehr explizit über den Hub geleitet werden. Dies erfordert eine Netzwerk Virtual Appliance (NVA) im Hub-VNet (oder ein VPN/ExpressRoute-Gateway) und benutzerdefinierte Routen (UDRs) in den Spoke-VNets. Diese UDRs weisen die Spokes an, Datenverkehr für andere Spokes an die NVA im Hub zu senden. Die anderen Optionen sind falsch: "Transit Peering" ist kein Azure-Feature. Netzwerksicherheitsgruppen (NSGs) steuern den Datenverkehr innerhalb eines VNets oder zwischen VNets, ermöglichen aber kein transitives Routing. Die Abonnementzugehörigkeit des Hubs hat keinen Einfluss auf die Transitivität des VNet-Peerings.