Merge pull request #300922 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: Taojunshen

articles/container-apps/gpu-serverless-overview.md

@@ -76,7 +76,7 @@ Access to this feature is only available after you have serverless GPU quota. Yo
 
 ## Supported regions
 
-Serverless GPUs are available in preview in the *West US 3*, *Australia East*, and *Sweden Central* regions.
+Serverless GPUs are available in the *West US 3*, *Australia East*, and *Sweden Central* regions.
 
 ## Use serverless GPUs
 

articles/oracle/oracle-db/oracle-database-network-plan.md

@@ -80,20 +80,43 @@ The following table describes required configurations of supported network featu
 |Connectivity from an Oracle database cluster to a [private endpoint](../../private-link/private-endpoint-overview.md) in a different spoke virtual network connected to a virtual WAN|Yes| Yes|
 |NSG support on the Private link | No| Yes| 
 | Connectivity to serverless Apps like Azure functions via private endpoints | No| Yes|
+| Azure SLB and ILB support for Oracle database cluster traffic  | No | No |
 |Dual stack (IPv4 and IPv6) virtual network|Only IPv4 is supported| Only IPv4 is supported|
 | Service tags support| No | Yes | 
 
 > [!NOTE]
 > When using NSGs (Network Security Groups) on the Azure side, ensure that any security rules configured on the Oracle (OCI) side are reviewed to avoid conflicts. While applying security policies on both Azure and OCI can enhance the overall security posture, it also introduces additional complexity in terms of management and requires careful manual synchronization between the two environments. Misalignment between these policies could lead to unintended access issues or operational disruptions. 
 
-> [!IMPORTANT]
-> For traffic destined to Oracle Database@Azure, when routing traffic through a Network Virtual Appliance (NVA) or firewall to Oracle Database@Azure, the UDR prefix must be at least as specific as the delegated subnet of the instance.
-> If the delegated subnet for your instance is x.x.x.x/27, configure the UDR on the Gateway Subnet as:  
-> x.x.x.x/27 (same as the subnet) ✅  
-> x.x.x.x/32 (more specific) ✅  
-> x.x.x.x/24  (too broad) ❌ 
 
+ ### UDR requirements for routing traffic to Oracle Database@Azure
+When routing traffic to Oracle Database@Azure through a Network Virtual Appliance (NVA)/firewall, the User-Defined Route (UDR) prefix **must be at least as specific as the subnet delegated to the Oracle Database@Azure instance**. Broader prefixes may cause traffic to be dropped.
+ 
+ If the delegated subnet for your instance is x.x.x.x/27, configure the UDR on the Gateway Subnet as:  
+ | Route Prefix | Routing Outcome |
+ |--------------|-----------------|
+ |x.x.x.x/27 | (same as the subnet) ✅ | 
+ |x.x.x.x/32 |(more specific) ✅| 
+ |x.x.x.x/24 | (too broad) ❌ |
 
+#### Topology-specific guidance
+**Hub-and-spoke topology**
+- Define the UDR on the gateway subnet.
+- Use a route prefix of `x.x.x.x/27` or more specific.
+- Set the next hop to your NVA/Firewall.
+
+**Virtual WAN (VWAN)**
+- **With Routing Intent**:
+  - Add the delegated subnet prefix (`x.x.x.x/27`) to the Routing Intent’s list of prefixes.
+
+- **Without Routing Intent**:
+  - Add a route to the VWAN's route table for `x.x.x.x/27` and point the next hop to the NVA/firewall.
+
+> [!Note]
+>   When **advanced network features are not enabled**, and for **traffic originating from the Oracle Database@Azure delegated subnet that needs   to traverse a gateway** (for example, to reach on-premises networks, AVS, other clouds, etc.), you must configure specific UDRs on the delegated subnet.  
+>These UDRs should define the specific destination IP prefixes and set the next hop to the appropriate NVA/firewall in the hub.  
+> Without these routes, outbound traffic may bypass required inspection paths or fail to reach the intended destination.
+
+ 
 
 ## FAQ 
 ### What are advanced network features?