Networking requirements for Cloud Volumes ONTAP in Azure
Set up your Azure networking so Cloud Volumes ONTAP systems can operate properly.
Requirements for Cloud Volumes ONTAP
The following networking requirements must be met in Azure.
Outbound internet access
Cloud Volumes ONTAP nodes require outbound internet access for NetApp AutoSupport, which proactively monitors the health of your system and sends messages to NetApp technical support.
Routing and firewall policies must allow HTTP/HTTPS traffic to the following endpoints so Cloud Volumes ONTAP can send AutoSupport messages:
-
https://support.netapp.com/aods/asupmessage
-
https://support.netapp.com/asupprod/post/1.0/postAsup
If an outbound internet connection isn't available to send AutoSupport messages, BlueXP automatically configures your Cloud Volumes ONTAP systems to use the Connector as a proxy server. The only requirement is to ensure that the Connector's security group allows inbound connections over port 3128. You'll need to open this port after you deploy the Connector.
If you defined strict outbound rules for Cloud Volumes ONTAP, then you'll also need to ensure that the Cloud Volumes ONTAP security group allows outbound connections over port 3128.
After you've verified that outbound internet access is available, you can test AutoSupport to ensure that it can send messages. For instructions, refer to ONTAP docs: Set up AutoSupport.
If BlueXP notifies you that AutoSupport messages can't be sent, troubleshoot your AutoSupport configuration.
IP addresses
BlueXP automatically allocates the required number of private IP addresses to Cloud Volumes ONTAP in Azure. You need to make sure that your networking has enough private IP addresses available.
The number of LIFs that BlueXP allocates for Cloud Volumes ONTAP depends on whether you deploy a single node system or an HA pair. A LIF is an IP address associated with a physical port. An SVM management LIF is required for management tools like SnapCenter.
An iSCSI LIF provides client access over the iSCSI protocol and is used by the system for other important networking workflows. These LIFs are required and should not be deleted. |
IP addresses for a single node system
BlueXP allocates 5 or 6 IP addresses to a single node system:
-
Cluster management IP
-
Node management IP
-
Intercluster IP for SnapMirror
-
NFS/CIFS IP
-
iSCSI IP
The iSCSI IP provides client access over the iSCSI protocol. It is also used by the system for other important networking workflows. This LIF is required and should not be deleted. -
SVM management (optional - not configured by default)
IP addresses for HA pairs
BlueXP allocates IP addresses to 4 NICs (per node) during deployment.
Note that BlueXP creates an SVM management LIF on HA pairs, but not on single node systems in Azure.
NIC0
-
Node management IP
-
Intercluster IP
-
iSCSI IP
The iSCSI IP provides client access over the iSCSI protocol. It is also used by the system for other important networking workflows. This LIF is required and should not be deleted.
NIC1
-
Cluster network IP
NIC2
-
Cluster Interconnect IP (HA IC)
NIC3
-
Pageblob NIC IP (disk access)
NIC3 is only applicable to HA deployments that use page blob storage. |
The above IP addresses do not migrate on failover events.
Additionally, 4 frontend IPs (FIPs) are configured to migrate on failover events. These frontend IPs live in the load balancer.
-
Cluster management IP
-
NodeA data IP (NFS/CIFS)
-
NodeB data IP (NFS/CIFS)
-
SVM management IP
Secure connections to Azure services
By default, BlueXP enables an Azure Private Link for connections between Cloud Volumes ONTAP and Azure page blob storage accounts.
In most cases, there's nothing that you need to do—BlueXP manages the Azure Private Link for you. But if you use Azure Private DNS, then you'll need to edit a configuration file. You should also be aware of a requirement for the Connector location in Azure.
You can also disable the Private Link connection, if required by your business needs. If you disable the link, BlueXP configures Cloud Volumes ONTAP to use a service endpoint instead.
Connections to other ONTAP systems
To replicate data between a Cloud Volumes ONTAP system in Azure and ONTAP systems in other networks, you must have a VPN connection between the Azure VNet and the other network—for example, your corporate network.
For instructions, refer to Microsoft Azure Documentation: Create a Site-to-Site connection in the Azure portal.
Port for the HA interconnect
A Cloud Volumes ONTAP HA pair includes an HA interconnect, which allows each node to continually check whether its partner is functioning and to mirror log data for the other’s nonvolatile memory. The HA interconnect uses TCP port 10006 for communication.
By default, communication between the HA interconnect LIFs is open and there are no security group rules for this port. But if you create a firewall between the HA interconnect LIFs, then you need to ensure that TCP traffic is open for port 10006 so that the HA pair can operate properly.
Only one HA pair in an Azure resource group
You must use a dedicated resource group for each Cloud Volumes ONTAP HA pair that you deploy in Azure. Only one HA pair is supported in a resource group.
BlueXP experiences connection issues if you try to deploy a second Cloud Volumes ONTAP HA pair in an Azure resource group.
Security group rules
BlueXP creates Azure security groups that include the inbound and outbound rules that Cloud Volumes ONTAP needs to operate successfully. You might want to refer to the ports for testing purposes or if you prefer your to use own security groups.
The security group for Cloud Volumes ONTAP requires both inbound and outbound rules.
Looking for information about the Connector? View security group rules for the Connector |
Inbound rules for single node systems
When you create a working environment and choose a predefined security group, you can choose to allow traffic within one of the following:
-
Selected VNet only: the source for inbound traffic is the subnet range of the VNet for the Cloud Volumes ONTAP system and the subnet range of the VNet where the Connector resides. This is the recommended option.
-
All VNets: the source for inbound traffic is the 0.0.0.0/0 IP range.
Priority and name | Port and protocol | Source and destination | Description |
---|---|---|---|
1000 |
22 |
Any to Any |
SSH access to the IP address of the cluster management LIF or a node management LIF |
1001 |
80 |
Any to Any |
HTTP access to the System Manager web console using the IP address of the cluster management LIF |
1002 |
111 |
Any to Any |
Remote procedure call for NFS |
1003 |
111 |
Any to Any |
Remote procedure call for NFS |
1004 |
139 |
Any to Any |
NetBIOS service session for CIFS |
1005 |
161-162 |
Any to Any |
Simple network management protocol |
1006 |
161-162 |
Any to Any |
Simple network management protocol |
1007 |
443 |
Any to Any |
Connectivity with the Connector and HTTPS access to the System Manager web console using the IP address of the cluster management LIF |
1008 |
445 |
Any to Any |
Microsoft SMB/CIFS over TCP with NetBIOS framing |
1009 |
635 |
Any to Any |
NFS mount |
1010 |
635 |
Any to Any |
NFS mount |
1011 |
749 |
Any to Any |
Kerberos |
1012 |
2049 |
Any to Any |
NFS server daemon |
1013 |
2049 |
Any to Any |
NFS server daemon |
1014 |
3260 |
Any to Any |
iSCSI access through the iSCSI data LIF |
1015 |
4045-4046 |
Any to Any |
NFS lock daemon and network status monitor |
1016 |
4045-4046 |
Any to Any |
NFS lock daemon and network status monitor |
1017 |
10000 |
Any to Any |
Backup using NDMP |
1018 |
11104-11105 |
Any to Any |
SnapMirror data transfer |
3000 |
Any port |
Any to Any |
Block all other TCP inbound traffic |
3001 |
Any port |
Any to Any |
Block all other UDP inbound traffic |
65000 |
Any port |
VirtualNetwork to VirtualNetwork |
Inbound traffic from within the VNet |
65001 |
Any port |
AzureLoadBalancer to Any |
Data traffic from the Azure Standard Load Balancer |
65500 |
Any port |
Any to Any |
Block all other inbound traffic |
Inbound rules for HA systems
When you create a working environment and choose a predefined security group, you can choose to allow traffic within one of the following:
-
Selected VNet only: the source for inbound traffic is the subnet range of the VNet for the Cloud Volumes ONTAP system and the subnet range of the VNet where the Connector resides. This is the recommended option.
-
All VNets: the source for inbound traffic is the 0.0.0.0/0 IP range.
HA systems have less inbound rules than single node systems because inbound data traffic goes through the Azure Standard Load Balancer. Because of this, traffic from the Load Balancer should be open, as shown in the "AllowAzureLoadBalancerInBound" rule. |
Priority and name | Port and protocol | Source and destination | Description |
---|---|---|---|
100 |
443 |
Any to Any |
Connectivity with the Connector and HTTPS access to the System Manager web console using the IP address of the cluster management LIF |
101 |
111 |
Any to Any |
Remote procedure call for NFS |
102 |
2049 |
Any to Any |
NFS server daemon |
111 |
22 |
Any to Any |
SSH access to the IP address of the cluster management LIF or a node management LIF |
121 |
53 |
Any to Any |
DNS and CIFS |
65000 |
Any port |
VirtualNetwork to VirtualNetwork |
Inbound traffic from within the VNet |
65001 |
Any port |
AzureLoadBalancer to Any |
Data traffic from the Azure Standard Load Balancer |
65500 |
Any port |
Any to Any |
Block all other inbound traffic |
Outbound rules
The predefined security group for Cloud Volumes ONTAP opens all outbound traffic. If that is acceptable, follow the basic outbound rules. If you need more rigid rules, use the advanced outbound rules.
Basic outbound rules
The predefined security group for Cloud Volumes ONTAP includes the following outbound rules.
Port | Protocol | Purpose |
---|---|---|
All |
All TCP |
All outbound traffic |
All |
All UDP |
All outbound traffic |
Advanced outbound rules
If you need rigid rules for outbound traffic, you can use the following information to open only those ports that are required for outbound communication by Cloud Volumes ONTAP.
The source is the interface (IP address) on the Cloud Volumes ONTAP system. |
Service | Port | Protocol | Source | Destination | Purpose |
---|---|---|---|---|---|
Active Directory |
88 |
TCP |
Node management LIF |
Active Directory forest |
Kerberos V authentication |
137 |
UDP |
Node management LIF |
Active Directory forest |
NetBIOS name service |
|
138 |
UDP |
Node management LIF |
Active Directory forest |
NetBIOS datagram service |
|
139 |
TCP |
Node management LIF |
Active Directory forest |
NetBIOS service session |
|
389 |
TCP & UDP |
Node management LIF |
Active Directory forest |
LDAP |
|
445 |
TCP |
Node management LIF |
Active Directory forest |
Microsoft SMB/CIFS over TCP with NetBIOS framing |
|
464 |
TCP |
Node management LIF |
Active Directory forest |
Kerberos V change & set password (SET_CHANGE) |
|
464 |
UDP |
Node management LIF |
Active Directory forest |
Kerberos key administration |
|
749 |
TCP |
Node management LIF |
Active Directory forest |
Kerberos V change & set Password (RPCSEC_GSS) |
|
88 |
TCP |
Data LIF (NFS, CIFS, iSCSI) |
Active Directory forest |
Kerberos V authentication |
|
137 |
UDP |
Data LIF (NFS, CIFS) |
Active Directory forest |
NetBIOS name service |
|
138 |
UDP |
Data LIF (NFS, CIFS) |
Active Directory forest |
NetBIOS datagram service |
|
139 |
TCP |
Data LIF (NFS, CIFS) |
Active Directory forest |
NetBIOS service session |
|
389 |
TCP & UDP |
Data LIF (NFS, CIFS) |
Active Directory forest |
LDAP |
|
445 |
TCP |
Data LIF (NFS, CIFS) |
Active Directory forest |
Microsoft SMB/CIFS over TCP with NetBIOS framing |
|
464 |
TCP |
Data LIF (NFS, CIFS) |
Active Directory forest |
Kerberos V change & set password (SET_CHANGE) |
|
464 |
UDP |
Data LIF (NFS, CIFS) |
Active Directory forest |
Kerberos key administration |
|
749 |
TCP |
Data LIF (NFS, CIFS) |
Active Directory forest |
Kerberos V change & set password (RPCSEC_GSS) |
|
AutoSupport |
HTTPS |
443 |
Node management LIF |
support.netapp.com |
AutoSupport (HTTPS is the default) |
HTTP |
80 |
Node management LIF |
support.netapp.com |
AutoSupport (only if the transport protocol is changed from HTTPS to HTTP) |
|
TCP |
3128 |
Node management LIF |
Connector |
Sending AutoSupport messages through a proxy server on the Connector, if an outbound internet connection isn't available |
|
Configuration backups |
HTTP |
80 |
Node management LIF |
http://<connector-IP-address>/occm/offboxconfig |
Send configuration backups to the Connector. Learn about configuration backup files. |
DHCP |
68 |
UDP |
Node management LIF |
DHCP |
DHCP client for first-time setup |
DHCPS |
67 |
UDP |
Node management LIF |
DHCP |
DHCP server |
DNS |
53 |
UDP |
Node management LIF and data LIF (NFS, CIFS) |
DNS |
DNS |
NDMP |
18600–18699 |
TCP |
Node management LIF |
Destination servers |
NDMP copy |
SMTP |
25 |
TCP |
Node management LIF |
Mail server |
SMTP alerts, can be used for AutoSupport |
SNMP |
161 |
TCP |
Node management LIF |
Monitor server |
Monitoring by SNMP traps |
161 |
UDP |
Node management LIF |
Monitor server |
Monitoring by SNMP traps |
|
162 |
TCP |
Node management LIF |
Monitor server |
Monitoring by SNMP traps |
|
162 |
UDP |
Node management LIF |
Monitor server |
Monitoring by SNMP traps |
|
SnapMirror |
11104 |
TCP |
Intercluster LIF |
ONTAP intercluster LIFs |
Management of intercluster communication sessions for SnapMirror |
11105 |
TCP |
Intercluster LIF |
ONTAP intercluster LIFs |
SnapMirror data transfer |
|
Syslog |
514 |
UDP |
Node management LIF |
Syslog server |
Syslog forward messages |
Requirements for the Connector
If you haven't created a Connector yet, you should review networking requirements for the Connector as well.