|
2 | 2 | title: Azure Arc resource bridge (preview) network requirements
|
3 | 3 | description: Learn about network requirements for Azure Arc resource bridge (preview) including URLs that must be allowlisted.
|
4 | 4 | ms.topic: conceptual
|
5 |
| -ms.date: 12/06/2022 |
| 5 | +ms.date: 01/30/2023 |
6 | 6 | ---
|
7 | 7 |
|
8 | 8 | # Azure Arc resource bridge (preview) network requirements
|
9 | 9 |
|
10 | 10 | This article describes the networking requirements for deploying Azure Arc resource bridge (preview) in your enterprise.
|
11 | 11 |
|
| 12 | +## Configuration requirements |
| 13 | + |
| 14 | +### Static Configuration |
| 15 | + |
| 16 | +Static configuration is recommended for Arc resource bridge because the resource bridge needs three static IPs in the same subnet for the control plane, appliance VM, and reserved appliance VM (for upgrade). The control plane corresponds to the `controlplanenedpoint` parameter, the appliance VM IP to `k8snodeippoolstart`, and reserved appliance VM to `k8snodeippoolend` in the `createconfig` command that creates the bridge configuration files. If using DHCP, reserve those IP addresses, ensuring they are outside the DHCP range. |
| 17 | + |
| 18 | +### IP Address Prefix |
| 19 | + |
| 20 | +The subnet of the IP addresses for Arc resource bridge must lie in the IP address prefix that is passed in the `ipaddressprefix` parameter of the `createconfig` command. The IP address prefix is the IP prefix that is exposed by the network to which Arc resource bridge is connected. It is entered as the subnet's IP address range for the virtual network and subnet mask (IP Mask) in CIDR notation, for example `192.168.7.1/24`. Consult your system or network administrator to obtain the IP address prefix in CIDR notation. An IP Subnet CIDR calculator may be used to obtain this value. |
| 21 | + |
| 22 | +### Gateway |
| 23 | + |
| 24 | +The gateway address provided in the `createconfig` command must be in the same subnet specified in the IP address prefix. |
| 25 | + |
| 26 | +### DNS Server |
| 27 | + |
| 28 | +DNS Server must have internal and external endpoint resolution. The appliance VM and control plane need to resolve the management machine and vice versa. All three must be able to reach the required URLs for deployment. |
| 29 | + |
| 30 | +## General network requirements |
| 31 | + |
12 | 32 | [!INCLUDE [network-requirement-principles](../includes/network-requirement-principles.md)]
|
13 | 33 |
|
14 | 34 | [!INCLUDE [network-requirements](includes/network-requirements.md)]
|
15 | 35 |
|
16 | 36 | ## Additional network requirements
|
17 | 37 |
|
18 |
| -In addition, resource bridge (preview) requires [Arc-enabled Kubernetes endpoints](../network-requirements-consolidated.md#azure-arc-enabled-kubernetes-endpoints). |
| 38 | +In addition, resource bridge (preview) requires connectivity to the [Arc-enabled Kubernetes endpoints](../network-requirements-consolidated.md?tabs=azure-cloud). |
| 39 | + |
| 40 | +> [!NOTE] |
| 41 | +> The URLs listed here are required for Arc resource bridge only. Other Arc products (such as Arc-enabled VMware vSphere) may have additional required URLs. For details, see [Azure Arc network requirements](../network-requirements-consolidated.md). |
| 42 | +
|
| 43 | +## SSL proxy configuration |
| 44 | + |
| 45 | +Azure Arc resource bridge must be configured for proxy so that it can connect to the Azure services. This configuration is handled automatically. However, proxy configuration of the management machine isn't configured by the Azure Arc resource bridge. |
| 46 | + |
| 47 | +There are only two certificates that should be relevant when deploying the Arc resource bridge behind an SSL proxy: the SSL certificate for your SSL proxy (so that the host and guest trust your proxy FQDN and can establish an SSL connection to it), and the SSL certificate of the Microsoft download servers. This certificate must be trusted by your proxy server itself, as the proxy is the one establishing the final connection and needs to trust the endpoint. Non-Windows machines may not trust this second certificate by default, so you may need to ensure that it's trusted. |
| 48 | + |
| 49 | +## Exclusion list for no proxy |
| 50 | + |
| 51 | +The following table contains the list of addresses that must be excluded by using the `-noProxy` parameter in the `createconfig` command. |
| 52 | + |
| 53 | +| **IP Address** | **Reason for exclusion** | |
| 54 | +| ----------------------- | ------------------------------------ | |
| 55 | +| localhost, 127.0.0.1 | Localhost traffic | |
| 56 | +| .svc | Internal Kubernetes service traffic (.svc) where _.svc_ represents a wildcard name. This is similar to saying \*.svc, but none is used in this schema. | |
| 57 | +| 10.0.0.0/8 | private network address space | |
| 58 | +| 172.16.0.0/12 |Private network address space - Kubernetes Service CIDR | |
| 59 | +| 192.168.0.0/16 | Private network address space - Kubernetes Pod CIDR | |
| 60 | +| .contoso.com | You may want to exempt your enterprise namespace (.contoso.com) from being directed through the proxy. To exclude all addresses in a domain, you must add the domain to the `noProxy` list. Use a leading period rather than a wildcard (\*) character. In the sample, the addresses `.contoso.com` excludes addresses `prefix1.contoso.com`, `prefix2.contoso.com`, and so on. | |
| 61 | + |
| 62 | +The default value for `noProxy` is `localhost,127.0.0.1,.svc,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16`. While these default values will work for many networks, you may need to add more subnet ranges and/or names to the exemption list. For example, you may want to exempt your enterprise namespace (.contoso.com) from being directed through the proxy. You can achieve that by specifying the values in the `noProxy` list. |
19 | 63 |
|
20 | 64 | ## Next steps
|
21 | 65 |
|
|
0 commit comments