Hi Colin -
Great question. CDot 8.3 family changed a number of things with respect to various networking services you mentioned.
Services can be generally categorized by scope - that is cluster scoped (or cluster wide) services, node scoped services, and SVM (vServer) scoped services. Prior to cDot 8.3, SVM scoped services such as DNs, LDAP, Active Directory, etc. could use cluster or node level management interfaces to query the appropriate service. In 8.3+, SVM scoped services must use a network interface associated only with the SVM. For that reason, there are now three possible types of management interfaces to consider - cluster, node, and SVM.
SVM scoped services need an SVM based interface. It is best practice to define a "management" interface with protocol "none". Such an interface will be the default to use for SVM scoped services. If a specific management interface is not defined, SVMs will use any other "data" interface available. SVM scoped services include DNS client (for the SVM), LDAP, AD, NIS, and the data protocols of course.
Node scoped services use a node management network interface. Node scoped services include NTP, SNMP, SMTP (for autosupport if configured to send email), SSH server for connection to a node specifically, HTTPS server, HTTP/S outbound (again for autosupport), DNS client (for the node), FTP client (might be used for software updates, sending support logs, etc.). Some of these are optional depending on your use case - for example I use an internal utility FTP server for software/firmware updates because it's simpler, so I have to allow FTP client out from my node management interfaces.
Cluster scoped services use a cluster management network interface. Cluster scoped services are SSH server for connection to the "cluster" by name, and the HTTPS server for cluster management functions.
A Node service processor should allow SSH inbound of course. There is also a configureable API-service port for the SPs, default is port 50000 per documentation. This service can be disabled. The SP also supports the Remote Support Agent function which is a service that can enable automatic upload of information to Netapp Support when incidents occur. It basically works by periodically connecting to a designated Netapp server over the web via HTTPS protocols to see if Netapp Support needs anything. When an incident has occurred, the RSA connects more frequently - about once every five minutes for a while if memory servers. Netapp support engineers can post that they'd like a specific log or autosupport to help solve an incident, and the RSA mechanism can then automatically upload that log. RSA uses web protocols and can also work through a proxy server to access the internet if desired. If you plan for using RSA the key thing to understand is that Netapp cannot access your kit directly, nor can they pull any data from your SVMs. RSA just makes getting the data that you'd normally send to Netapp more easily available in cases where a person isn't immediately available to do it. There's a whole guide on network setup for RSA available on the support site.
That's the quick summary - there is a lot more detail information of course available in the 8.3.1 documentation.
Hope this helps you.
Bob Greenwald
Lead Storage Engineer
Huron Legal | Huron Consulting Group
