Contoso Ltd. heeft een hub-spoke-topologie in East US: een hub VNet (Hub-VNet) met een NVA en twee spoke VNets (Spoke-A en Spoke-B). Spoke-A is gepeerd met Hub-VNet en Spoke-B is gepeerd met Hub-VNet. Engineers merken dat VM's in Spoke-A geen VM's in Spoke-B kunnen bereiken via de peering-verbindingen. Welke verklaring beschrijft het beste waarom direct spoke-naar-spoke-verkeer de hub-peering niet doorkruist, en wat Contoso moet doen om spoke-naar-spoke-communicatie mogelijk te maken zonder alle peers opnieuw te architectureren?

VNet-peering is niet transitief, wat betekent dat gepeerde VNets alleen direct met elkaar kunnen communiceren en niet als doorgeefluik kunnen fungeren voor verkeer naar andere gepeerde VNets. In dit scenario kunnen VM's in Spoke-A de VM's in Spoke-B niet bereiken via de hub, omdat de peering tussen Hub-VNet en Spoke-A, en Hub-VNet en Spoke-B, geen transitieve routering mogelijk maakt tussen Spoke-A en Spoke-B. Om spoke-naar-spoke-communicatie mogelijk te maken zonder directe spoke-peering, moet u een NVA (Network Virtual Appliance) in de hub gebruiken en User Defined Routes (UDR's) op de spokes configureren. Deze UDR's sturen verkeer bestemd voor het andere spoke VNet naar de NVA in de hub, die vervolgens het verkeer doorstuurt. De optie over 'Transit Peering' is onjuist; er bestaat geen dergelijke functie in Azure VNet-peering. Het delen van NSG's of het verplaatsen van de hub naar een ander abonnement lost het fundamentele transitiviteitsprobleem van VNet-peering niet op.