Een nutsbedrijf wil dat al het spoke-to-spoke verkeer een centrale NVA doorkruist die is geïmplementeerd in de Virtual WAN-hub. Ze probeerden UDR's aan te maken in de spoke VNet's met een next hop die naar het IP-adres van de hub-firewall wijst, maar de spoke-subnetten respecteren die UDR's niet. Waarom gebeurt dit en wat is de juiste manier om spoke-to-spoke verkeer door de hub NVA te forceren?

De correcte optie beschrijft de juiste methode voor het routeren van spoke-to-spoke verkeer via een NVA in een Azure Virtual WAN-hub. UDR's (User Defined Routes) in spoke VNet's beïnvloeden de door Virtual WAN beheerde transitroutes niet direct. Om verkeer via de NVA te forceren, moet een aangepaste routetabel worden geconfigureerd op de Virtual WAN-hub zelf. Deze routetabel bevat statische routes (bijvoorbeeld 0.0.0.0/0 of specifieke subnetten) die naar het privé-IP-adres van de NVA wijzen. Door deze routetabel te koppelen aan de VNet-verbindingen van de spokes, wordt al het verkeer dat de hub doorkruist, inclusief spoke-to-spoke verkeer, via de NVA gestuurd voor inspectie. De andere opties zijn onjuist: UDR's worden niet geblokkeerd door Azure, maar ze zijn niet de juiste methode om transit via de Virtual WAN-hub te beïnvloeden. Service chaining is een concept dat niet van toepassing is op deze specifieke configuratie. BGP inschakelen op spoke VNet's is niet nodig voor dit scenario en statische UDR's kunnen wel werken in andere contexten, maar niet op de manier die hier wordt voorgesteld voor Virtual WAN. Globale VNet-peering is niet de primaire methode voor routering binnen Virtual WAN; de hub-architectuur is hiervoor ontworpen. UDR's in een gepeerd hub VNet zouden de Virtual WAN-routering niet overschrijven.