Hello Peter Stieber
When you're working with Azure Virtual WAN (vWAN), you might notice that some routes in your Virtual Network (VNet) show the next hop as routeServiceVip, while others show the VPN Gateway's private IP. This behavior is expected and depends on how Azure is handling the routing behind the scenes.
RouteServiceVip is a special internal IP address used by Azure to represent the Route Service inside the vWAN Virtual Hub. Think of it as Azure’s internal traffic controller that:
- Lives in the RouteServiceSubnet of the Virtual Hub.
- Learns routes from VPN and ExpressRoute gateways using iBGP.
- Shares routing information across hubs using a secure internal network.
When a VNet is connected to a vWAN hub, and Azure decides to route traffic through this Route Service, you'll see routeServiceVip as the next hop. It means Azure is managing the route centrally through the hub.
Azure decides the next hop based on several factors:
This typically depends on how the route was learned and the routing configuration:
- If a route is learned via BGP from a VPN site and the VPN gateway is directly involved in the path, the next hop may be the VPN gateway's private IP address.
- If the route is propagated through the Route Service, especially in scenarios with multiple hubs or complex routing policies, the routeServiceVip is used as the next hop.
The decision is influenced by:
- Routing intent and propagation settings in the vWAN hub.
- Route table associations and labels.
- Hub routing preference (HRP) logic, which prioritizes:
- Longest prefix match
- Local routes over inter-hub
- Static routes over BGP
- ER over VPN
- Shorter AS path
Scenario | Next Hop |
---|---|
Route learned directly from VPN Gateway | VPN Gateway Private IP |
Route propagated via Route Service | routeServiceVip |
Route from ExpressRoute or inter-hub | Often routeServiceVip |
Static route defined in hub | Depends on setup |
If you're troubleshooting or designing your routing setup, it is advisable to review:
The route tables linked to your connections.
The propagation settings in your vWAN hub.
Any custom routing policies or intents you have configured.
Share the below information for more understanding:
Are you able to change the IP assignment to Static successfully?
Is the Basic Public IP currently linked to any other services or resources apart from the virtual network gateway?
What specific error messages are you receiving during the disassociation or upgrade process?
Hope the above answer helps! Please let us know do you have any further queries. Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.