Klient z branży użyteczności publicznej chce, aby cały ruch spoke-to-spoke przechodził przez centralny NVA wdrożony w huba Virtual WAN. Próbowano utworzyć UDR w sieciach VNet spoke ze wskazaniem następnego przeskoku na adres IP firewalla huba, ale podsieci spoke nie honorują tych UDR. Dlaczego tak się dzieje i jaki jest prawidłowy sposób wymuszenia ruchu spoke-to-spoke przez NVA huba?

Poprawna odpowiedź wyjaśnia, że UDR-y w sieciach spoke VNet nie mają wpływu na zarządzany tranzyt Virtual WAN. Virtual WAN używa własnych tabel tras w hubie do kierowania ruchu. Aby wymusić ruch spoke-to-spoke przez NVA, należy utworzyć niestandardową tabelę tras wirtualnego huba. Ta tabela powinna zawierać statyczne trasy (np. 0.0.0.0/0 dla całego ruchu lub bardziej szczegółowe trasy dla podsieci spoke) wskazujące prywatny adres IP NVA jako następny przeskok. Następnie tę niestandardową tabelę tras należy skojarzyć z połączeniami spoke, co spowoduje, że hub będzie kierował ruch z tych spoke przez NVA. Pozostałe opcje są nieprawidłowe: UDR nie są blokowane, ale po prostu nie wpływają na routing w Virtual WAN w ten sposób. Service chaining nie jest mechanizmem do wymuszania tranzytu przez NVA w tym kontekście. Włączenie BGP w spoke VNet nie jest wymagane ani wystarczające do wymuszenia tranzytu przez NVA huba w Virtual WAN. Statyczne UDR w hubie są skutecznym sposobem. Globalny peering VNet nie jest wymagany ani zalecany w Virtual WAN, ponieważ hub Virtual WAN zapewnia łączność. UDR w sparowanej sieci VNet huba nie rozwiążą problemu, ponieważ to hub Virtual WAN zarządza routingiem.