Networking requirements for Cloud Volumes ONTAP in Azure

Contributors netapp-bcammett netapp-rlithman

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.

Note 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

    Note 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

    Note 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)

Note 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.

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 groups

You don’t need to create security groups because BlueXP does that for you. If you need to use your own, refer to the security group rules listed below.

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.

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
inbound_ssh

22
TCP

Any to Any

SSH access to the IP address of the cluster management LIF or a node management LIF

1001
inbound_http

80
TCP

Any to Any

HTTP access to the System Manager web console using the IP address of the cluster management LIF

1002
inbound_111_tcp

111
TCP

Any to Any

Remote procedure call for NFS

1003
inbound_111_udp

111
UDP

Any to Any

Remote procedure call for NFS

1004
inbound_139

139
TCP

Any to Any

NetBIOS service session for CIFS

1005
inbound_161-162 _tcp

161-162
TCP

Any to Any

Simple network management protocol

1006
inbound_161-162 _udp

161-162
UDP

Any to Any

Simple network management protocol

1007
inbound_443

443
TCP

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
inbound_445

445
TCP

Any to Any

Microsoft SMB/CIFS over TCP with NetBIOS framing

1009
inbound_635_tcp

635
TCP

Any to Any

NFS mount

1010
inbound_635_udp

635
UDP

Any to Any

NFS mount

1011
inbound_749

749
TCP

Any to Any

Kerberos

1012
inbound_2049_tcp

2049
TCP

Any to Any

NFS server daemon

1013
inbound_2049_udp

2049
UDP

Any to Any

NFS server daemon

1014
inbound_3260

3260
TCP

Any to Any

iSCSI access through the iSCSI data LIF

1015
inbound_4045-4046_tcp

4045-4046
TCP

Any to Any

NFS lock daemon and network status monitor

1016
inbound_4045-4046_udp

4045-4046
UDP

Any to Any

NFS lock daemon and network status monitor

1017
inbound_10000

10000
TCP

Any to Any

Backup using NDMP

1018
inbound_11104-11105

11104-11105
TCP

Any to Any

SnapMirror data transfer

3000
inbound_deny _all_tcp

Any port
TCP

Any to Any

Block all other TCP inbound traffic

3001
inbound_deny _all_udp

Any port
UDP

Any to Any

Block all other UDP inbound traffic

65000
AllowVnetInBound

Any port
Any protocol

VirtualNetwork to VirtualNetwork

Inbound traffic from within the VNet

65001
AllowAzureLoad BalancerInBound

Any port
Any protocol

AzureLoadBalancer to Any

Data traffic from the Azure Standard Load Balancer

65500
DenyAllInBound

Any port
Any protocol

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.

Note 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
inbound_443

443
Any protocol

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
inbound_111_tcp

111
Any protocol

Any to Any

Remote procedure call for NFS

102
inbound_2049_tcp

2049
Any protocol

Any to Any

NFS server daemon

111
inbound_ssh

22
Any protocol

Any to Any

SSH access to the IP address of the cluster management LIF or a node management LIF

121
inbound_53

53
Any protocol

Any to Any

DNS and CIFS

65000
AllowVnetInBound

Any port
Any protocol

VirtualNetwork to VirtualNetwork

Inbound traffic from within the VNet

65001
AllowAzureLoad BalancerInBound

Any port
Any protocol

AzureLoadBalancer to Any

Data traffic from the Azure Standard Load Balancer

65500
DenyAllInBound

Any port
Any protocol

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.

Note 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

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.