How should routing work between an East hub and a West hub in Azure Virtual WAN when Cisco SD-WAN is deployed through a Cisco v8000 NVA, with Cisco FTDv appliances in spoke VNets providing Internet egress? I'm also trying to understand why local VNets and subnets from one hub are not being advertised to the other hub, even though branch sites can reach those networks through OMP.
3 Answers
A common symptom is that each hub can see its own local VNet prefixes, but those prefixes are not being advertised to the other hub. Check the hub route tables, effective routes, connection propagation settings, and the NVA’s advertised prefixes in both regions. The fact that branch sites can reach the networks through OMP suggests the SD-WAN control plane knows the routes, but Azure Virtual WAN may not be receiving or propagating those prefixes between hubs.
Also verify that the NVA platform supports Virtual WAN routing intent and that the feature is configured as part of the design. If it doesn’t support routing intent, hub-to-hub propagation and Internet traffic inspection may not behave as expected.
The hubs should communicate through their normal Virtual WAN mesh, assuming hub-to-hub connectivity is enabled. Once traffic reaches a hub, the SD-WAN environment is treated as a remote network behind the NVA. Keep in mind that default routes generally aren’t automatically shared between regions, so each hub may need an appropriate default route through its local NVA. You may also want to configure SD-WAN path preferences so sites choose the East or West region intentionally instead of sending traffic through both regions equally. The right choice depends on your SD-WAN cost and routing policies.
That matches what I’m seeing: East subnets aren’t visible from the West hub, and West subnets aren’t visible from the East hub, although the branches can reach them through OMP.