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/virtual-wan/about-nva-hub.md
+57-1Lines changed: 57 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -113,7 +113,63 @@ When you create an NVA in a Virtual WAN hub, you must choose the number of NVA I
113
113
NVAs in Virtual WAN are deployed to ensure you always are able to achieve at minimum the vendor-specific throughput numbers for a particular chosen scale unit. To achieve this, NVAs in Virtual WAN are overprovisioned with additional capacity in the form of multiple instances in a 'n+1' manner. This means that at any given time you might see aggregate throughput across the instances to be greater than the vendor-specific throughput numbers. This ensures if an instance is unhealthy, the remaining 'n' instance(s) can service customer traffic and provide the vendor-specific throughput for that scale unit.
114
114
115
115
If the total amount of traffic that passes through an NVA at a given time goes above the vendor-specific throughput numbers for the chosen scale unit, events that might cause an NVA instance to be unavailable including but not limited to routine Azure platform maintenance activities or software upgrades can result in service or connectivity disruption. To minimize service disruptions, you should choose the scale unit based on your peak traffic profile and vendor-specific throughput numbers for a particular scale unit as opposed to relying on best-case throughput numbers observed during testing.
116
-
116
+
117
+
### Hub address space
118
+
119
+
Every Virtual WAN hub is deployed with a hub address space. The minimum recommended hub address space is /23. Virtual WAN automatically carves out subnets within the hub to deploy different services within the Virtual WAN hub such as Azure Firewalls, NVAs and gateway connectivity services.
120
+
121
+
There are a limited number of IP addresses available in the Virtual WAN hub that can be assigned to the internal or external subnet of NVA deployments. The number of IP addresses allocated to either the internal or external subnet of NVAs is static for all Virtual WAN hubs deployed with a specific address size, irrespective of whether or not customers utilize or plan to utilize all services in the Virtual WAN hub. Service-level allocation can't be modified.
122
+
123
+
The following table describes the number of IP addresses available for NVA deployments for different hub address sizes.
124
+
125
+
|Hub Address Space|IP addresses available for NVA internal subnet| IP addresses available for NVA external subnet|
126
+
|--|--|--|
127
+
|/23 or smaller|11| 11|
128
+
|/22|27|27|
129
+
|/21|59| 59|
130
+
|/20 or larger| 123| 123|
131
+
132
+
#### <aname="ipconsumed" ></a> Consumed IP addresses
133
+
134
+
>[NOTE]
135
+
> Select your hub address space with scalability taken into consideration as the subnets allocated to NVAs can't be re-sized. Actions such as deploying multiple NVAs in the hub or adding additional IP configurations to existing NVAs requires sufficient available IP addresses.
136
+
137
+
The number of IP addresses that are consumed by a single NVA deployment is calculated separately for the internal and external interfaces. NVAs deployed in the same hub consume IP addresses from the same subnet as other NVAs and therefore all NVAs in the same hub contribute towards to hub's limit.
138
+
139
+
The following table shows the number of NVA instances deployed for different scale units.
140
+
141
+
|Scale Unit| Instances|
142
+
|--|--|
143
+
|2-20|2|
144
+
|30-40|3|
145
+
|60|4|
146
+
|80|5|
147
+
148
+
**Internal Interface**
149
+
150
+
* For NVA deployments that are **not** compatible for [Internet Inbound](how-to-network-virtual-appliance-inbound.md), **1 IP address** is assigned to the Internal Load Balancer. **2 IP addresses** are consumed if the NVA deployments is compatible for [Internet-Inbound](how-to-network-virtual-appliance-inbound.md). Reference [Internet-Inbound](how-to-network-virtual-appliance-inbound.md) for documentation on how to verify your NVA's compatability status.
151
+
* One IP address is consumed per NVA instance. This IP address is assigned to each NVAs internal NIC. You may add [additional IP configurations](how-to-network-virtual-appliance-add-ip-configurations.md) to the internal NIC. One additional IP configuration results in one additional private IP address consumed per NVA instance.
152
+
153
+
**Example**:
154
+
155
+
* 60 scale unit NVA (4 instances)
156
+
* Internet-inbound compatible
157
+
* 3 IP configurations on the internal interface.
158
+
159
+
In this example, 14 IP addresses are consumed in the internal subnet. 12 IP addresses are assigned to the internal interface. 2 additional IP addresses are consumed by the load balancer.
160
+
161
+
**External Interface**
162
+
163
+
One IP address is consumed per NVA instance. This IP address is assigned to the external NIC as part of a private and public IP tuple. You can assign [additional IP configurations](how-to-network-virtual-appliance-add-ip-configurations.md) to the external NIC to add additional private and public IP tuples. One additional IP configuration results in one additional IP address consumed per NVA instance.
164
+
165
+
**Example**:
166
+
167
+
* 60 scale unit NVA (4 instances)
168
+
* 2 IP configurations on the internal interface.
169
+
170
+
In this example, 8 IP addresses are consumed in the external subnet. 8 IP addresses are assigned to the internal interface.
171
+
172
+
117
173
## <aname="configuration"></a>NVA configuration process
118
174
119
175
Partners have worked to provide an experience that configures the NVA automatically as part of the deployment process. Once the NVA is provisioned into the virtual hub, any additional configuration that might be required for the NVA must be done via the NVA partners portal or management application. Direct access to the NVA isn't available.
Copy file name to clipboardExpand all lines: articles/virtual-wan/how-to-nva-hub.md
+12Lines changed: 12 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,6 +48,18 @@ To deploy a Network Virtual Appliance in a Virtual WAN Hub, the user or service
48
48
49
49
These permissions need to be granted to the Azure Marketplace Managed Application to ensure deployments succeed. Other permissions may be required based on the implementation of the deployment workflow developed by your NVA partner.
50
50
51
+
## Hub address space
52
+
53
+
Each Virtual WAN hub has a fixed subnet size used for NVA deployments. The number of IP addresses available for consumption is statically defined for all hub address sizes.
54
+
55
+
Ensure your Virtual WAN hub has sufficient IP addresses to allow for scalability and future network deployment updates:
56
+
57
+
* Deploy additional NVAs (more than one) in the hub.
58
+
* Add additional IP configurations to your NVA interfaces.
59
+
* Re-size your NVA (increase scale unit).
60
+
61
+
For more information on how Virtual WAN allocates IP addresses to NVAs in the hub, see [hub address space for NVAs documentation](about-nva-hub.md#hub-address-space).
62
+
51
63
## Assigning Permissions to Azure Managed Application
52
64
53
65
Network Virtual Appliances that are deployed via Azure Marketplace Managed Application are deployed in a special resource group in your Azure tenant called the **managed resource group**. When you create a Managed Application in your subscription, a corresponding and separate **managed resource group** is created in your subscription. All Azure resources created by the Managed Application (including the Network Virtual Appliance) are deployed into the **managed resource group**.
0 commit comments