You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/oracle/oracle-db/oracle-database-network-plan.md
+20-12Lines changed: 20 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,10 +11,12 @@ ms.date: 12/12/2023
11
11
# Network planning for Oracle Database@Azure
12
12
In this article, learn about network topologies and constraints in Oracle Database@Azure.
13
13
After you purchase an offer through Azure Marketplace and provision the Oracle Exadata infrastructure, the next step is to create your virtual machine cluster to host your instance of Oracle Exadata Database@Azure. The Oracle database clusters are connected to your Azure virtual network via a virtual network interface card (virtual NIC) from your delegated subnet (delegated to `Oracle.Database/networkAttachment`).
14
-
## Network Features
15
-
### Default Network Features
16
-
Default network features enable basic network connectivity for both new and existing ODAA deployments. These features are available across all supported ODAA regions and provide the foundational networking required for your deployment
17
-
### Advanced Network Features
14
+
## Network features
15
+
There are two types of network features: default and advance.
16
+
17
+
### Default network features
18
+
Default network features enable basic network connectivity for both new and existing Oracle Database@Azure deployments. These features are available across all supported Oracle Database@Azure regions and provide the foundational networking required for your deployment
19
+
### Advanced network features
18
20
Advanced network features enhance the virtual networking experience, offering improved security, performance, and control—similar to standard Azure VMs. These features are currently in public preview and available in the following regions:
19
21
* Australia East
20
22
* Central US
@@ -24,10 +26,10 @@ Advanced network features enhance the virtual networking experience, offering im
24
26
* UK South
25
27
* UK West
26
28
>[!NOTE]
27
-
>Advanced network features are currently supported only for new ODAA deployments.
28
-
> Existing virtual networks with previously created ODAA delegated subnets will not support these features at this time. Support for existing deployments is planned for later this year.
29
+
>Advanced network features are currently supported only for new Oracle Database@Azure deployments.
30
+
> Existing virtual networks with previously created Oracle Database@Azure delegated subnets will not support these features at this time. Support for existing deployments is planned for later this year.
29
31
>Registration Required:
30
-
> To use advanced network features, you must first register using the commands below before creating your virtual network for the ODAA deployment.
32
+
> To use advanced network features, you must first register using the commands below before creating your virtual network for the Oracle Database@Azure deployment.
@@ -42,15 +44,15 @@ The following table describes the network topologies that are supported by each
42
44
|Connectivity to an Oracle database cluster in a local virtual network| Yes | Yes |
43
45
|Connectivity to an Oracle database cluster in a peered virtual network (in the same region)|Yes |Yes |
44
46
|Connectivity to an Oracle database cluster in a spoke virtual network in a different region with a virtual wide area network (virtual WAN) |Yes | Yes |
45
-
|Connectivity to an Oracle database cluster in a peered virtual network (cross-region or global peering) without a virtual WAN\* | No| Yes |
47
+
|Connectivity to an Oracle database cluster in a peered virtual network in different region (Global Peering) | No| Yes |
46
48
|On-premises connectivity to an Oracle database cluster via global and local Azure ExpressRoute |Yes| Yes|
47
49
|Azure ExpressRoute FastPath |No | Yes|
48
50
|Connectivity from on-premises to an Oracle database cluster in a spoke virtual network over an ExpressRoute gateway and virtual network peering with a gateway transit|Yes | Yes|
49
51
|On-premises connectivity to a delegated subnet via a virtual private network (VPN) gateway | Yes | Yes|
50
52
|Connectivity from on-premises to an Oracle database in a spoke virtual network over a VPN gateway and virtual network peering with gateway transit| Yes | Yes|
51
53
|Connectivity over active/passive VPN gateways| Yes |Yes|
52
54
|Connectivity over active/active VPN gateways| No | Yes|
53
-
|Connectivity over active/active zone-redundantgateways| Yes | Yes|
55
+
|Connectivity over zone-redundant, zonal ExpressRoute gateways| Yes | Yes|
54
56
|Transit connectivity via a virtual WAN for an Oracle database cluster provisioned in a spoke virtual network| Yes |Yes|
55
57
|On-premises connectivity to an Oracle database cluster via a virtual WAN and attached software-defined wide area network (SD-WAN)|No|Yes|
56
58
|On-premises connectivity via a secured hub (a firewall network virtual appliance) |Yes|Yes|
@@ -71,16 +73,22 @@ The following table describes required configurations of supported network featu
71
73
|Load balancers for Oracle database cluster traffic|No| Yes|
72
74
|Dual stack (IPv4 and IPv6) virtual network|Only IPv4 is supported| Only IPv4 is supported|
73
75
> [!NOTE]
74
-
> If you want to configure a route table (UDR route) to control the routing of packets through a network virtual appliance or firewall destined to an Oracle Database@Azure instance from a source in the same VNet or a peered VNet, the UDR prefix must be more specific or equal to the delegated subnet size of the Oracle Database@Azure instance. If the UDR prefix is less specific than the delegated subnet size, it isn't effective.
76
+
> For Traffic Destined to Oracle Database@Azure
77
+
>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.
75
78
>
76
-
> For example, if your delegated subnet is `x.x.x.x/24`, you must configure your UDR to `x.x.x.x/24` (equal) or `x.x.x.x/32` (more specific). If you configure the UDR route to be `x.x.x.x/16`, undefined behaviors such as asymmetric routing can cause a network drop at the firewall.
79
+
> If the delegated subnet for your instance is x.x.x.x/27, configure the UDR on the Gateway Subnet as:
80
+
> x.x.x.x/27 (same as the subnet) ✅
81
+
> x.x.x.x/32 (more specific) ✅
82
+
> x.x.x.x/24 (too broad) ❌
83
+
84
+
77
85
## FAQ:
78
86
### What are advanced network features?
79
87
Advanced network features enhance your virtual networking experience by providing better security, performance, and control—similar to standard Azure virtual machines. With this feature, customers can use native VNet integrations like Network Security Groups (NSG), User-Defined Routes (UDR), Private Link, Global VNet Peering, and ExpressRoute FastPath without needing any workarounds.
80
88
### Will advanced network features work for existing deployments?
81
89
Not at the moment. Support for existing deployments is on our roadmap, and we’re actively working to enable it. Stay tuned for updates in the near future.
82
90
### Do I need to self-register to enable advanced network features for new deployments?
83
-
Yes. To take advantage of advanced network features for new deployments, you must complete a registration process. Please run the registration commands before creating a new VNet and delegated subnet for your ODAA deployments.
91
+
Yes. To take advantage of advanced network features for new deployments, you must complete a registration process. Please run the registration commands before creating a new VNet and delegated subnet for your Oracle Database@Azure deployments.
84
92
### How can I check if my deployment supports advanced network features?
85
93
Currently, there’s no direct way to verify whether a VNet supports advanced network features. We recommend tracking your feature registration timeline and associating it with the VNets created afterward. You can also use the Activity Log blade under the VNet to review creation details—but note, logs are only available for the past 90 days by default.
0 commit comments