updated

Author: siddomala

articles/route-server/hub-routing-preference.md

@@ -29,6 +29,9 @@ When Route Server has multiple routes to an on-premises destination prefix, Rout
     > Routing preference doesn't allow users to set preference between routes learned over VPN and NVA connections. If the same routes are learned over VPN and NVA connections, Route Server will prefer the route with the shortest BGP AS path.
     - **AS Path**: Prefer routes with the shortest BGP AS path length, irrespective of the source of the route advertisement.
 
+> [!Note]
+> For a given set of destination route-prefixes, if the ExpressRoute routes are preferred and the ExpressRoute connection subsequently goes down, then routes advertised from on-premises via S2S VPN or NVAs will be preferred for traffic destined to the same route-prefixes. When the ExpressRoute connection is restored, traffic destined for these route-prefixes might continue to prefer the S2S VPN or NVA paths. To prevent this from happening, you need to configure your on-premises device to utilize AS-Path prepending for the routes being advertised to your S2S VPN Gateway and SD-WAN NVA, as you need to ensure the AS-Path length is longer for VPN/NVA routes than ExpressRoute routes.
+
 ## Next step
 
 > [!div class="nextstepaction"]

articles/route-server/route-server-faq.md

@@ -51,6 +51,8 @@ No. If you have deployed a virtual network with an IPv6 address space and later
 
 You can peer a virtual network with an IPv6 address space to Route Server's virtual network, and IPv4 connectivity with this peered dual-stack virtual network will continue to function. IPv6 connectivity with this peered virtual network is not supported. 
 
+If you advertise IPv6 prefixes from on-premises, this will break IPv4 connectivity for your Azure resources. 
+
 
 ## Routing
 

articles/virtual-wan/virtual-wan-faq.md

@@ -383,6 +383,8 @@ The recommended Virtual WAN hub address space is /23. Virtual WAN hub assigns su
 
 IPv6 isn't supported in the Virtual WAN hub and its gateways. If you connect a spoke VNet with an IPv6 address range to the Virtual WAN hub, then only IPv4 connectivity with this spoke VNet will function. IPv6 connectivity with this spoke VNet is not supported. 
 
+If you advertise IPv6 prefixes from on-premises, this will break IPv4 connectivity for your Azure resources. 
+
 For the point-to-site User VPN scenario with internet breakout via Azure Firewall, you'll likely have to turn off IPv6 connectivity on your client device to force traffic to the Virtual WAN hub. This is because modern devices, by default, use IPv6 addresses.
 
 ### What is the recommended API version to be used by scripts automating various Virtual WAN functionalities?