A VAST cluster consists of several components that require network connections between them to operate. This document outlines the network ports, their functions, and associated security risks.
From VAST Cluster 5.1.
Management Network
The Management network typically has the following attributes:
It is a network or subnet provided by Top of Rack (ToR) switches that are fully managed by the customer.
It is typically a fully routed subnet on the customer’s networking infrastructure.
Customer controls the IP address allocations, gateways, and all firewall rules.
It is used to reach the customer’s internal services such as Active Directory, LDAP, and DNS. (VAST does not currently support reaching these services via the Data Network.)
It is often able to reach the Internet if allowed by the customer’s firewall.
It is used for delivering VAST CallHome log bundles to VAST’s S3 bucket.
VMS is also running on the Management Network. It runs on one of the CNodes at a time, with its VIP being presented as a Secondary IP on the same interface as the regular Management Network address.
The Management Network is used by VAST CNodes, DNodes, and Cluster Switches.
Several services listen on the Management Network that are not specifically required for use by the VAST systems, but are currently configured to listen on all interfaces. These services are labeled as “Unnecessary” in blue below.
ℹ️ Info
The Docker network (default: 172.17.0.0/16) on each Node is not visible on any external network interface. However, due to the way that routing works, this network can conflict with customer networks that use the same address range. This potential issue should be identified during the Site Survey before deployment. It is being noted here for completeness.
Node Type | Disposition | Port(s) | Service | How they’re used |
|---|---|---|---|---|
CNode | Required | tcp/22 | SSH | The Platform uses SSH to connect between nodes to perform maintenance. |
Unnecessary | tcp/111 udp/632 | rpcbind | Not used internally on this IP. | |
Blocked | tcp/5000 | Docker Registry | Not used internally on this IP. | |
VMS | Access to VMS | tcp/80 tcp/443 | VMS | The VMS Web Service |
Unnecessary | tcp/22 | SSH | Not used internally on this IP. | |
blocked | tcp/5000 | Docker Registry | Not used internally on this IP. | |
Unnecessary | tcp/111 udp/632 | rpcbind | Not used internally on this IP. | |
DNode | Required | tcp/22 | SSH | The Platform uses SSH to connect between nodes to perform maintenance. |
Unnecessary | tcp/111 udp/632 | rpcbind | Not used internally on this IP. | |
Unnecessary | udp/500 udp/4500 | IPsec | Unknown | |
Mellanox Switch | Required | tcp/22 | SSH | The Platform uses SSH to connect between nodes to perform maintenance. |
Unnecessary | tcp/443 | Mellanox Web Admin | This is not used during normal VAST cluster operation; it may be disabled or firewalled as customers require. | |
Required | tcp/60102 | Mellanox Switch HA | Switches in a switch pair must be able to communicate on this port. However, no outside services need to use this port. |
Data Network (Protocols)
The Data Network is the network that the customer’s clients use to access storage services (NFS, S3, SMB) on a VAST cluster. The following generalities are true about this network:
The customer fully manages the Data Network in terms of its IP address allocation, gateway, domain name, firewall rules, etc.
There is no firewall on the Mellanox switches provided by VAST.
The Mellanox switches' uplink connections physically connect to the customer’s switches, and the customer fully manages everything beyond those Mellanox uplink connections.
The customer does NOT generally manage the physical network connections for the Data Network within the VAST cluster; these are often managed by VAST and implemented by using Mellanox switches.
Node Type | Protocol | Port(s) | Service | How they’re used |
|---|---|---|---|---|
CNode | NFS v3 | tcp/111 udp/632 | rpcbind | Used for NFS v3 to coordinate other NFS ports to be used (mount, status, nlockmgr, rquotad). |
tcp/20048 udp/20048 | mount | Used for NFS v3 to perform filesystem mount coordination and actions. | ||
tcp/20106 udp/20106 | status | NSM - the NFS Status Monitor, it allows the client and server to communicate their status. | ||
tcp/20107 udp/20107 | nlockmgr | NLM - the NFS v3 Lock Manager, it coordinates the advisory file locking for the protocol. | ||
tcp/20108 udp/20108 | rquotad | The Remote Quota server advertises quota information for the client to display to the user. | ||
NFS v3, NFS v4.1+ | tcp/2049 udp/2049 tcp/20049 | nfs/tcp nfs/udp nfs/RDMA | NFS v3, NFS v4.1+ Protocols | |
SMB | tcp/445 | smb | SMB Protocol | |
Kafka | tcp/9092 | kafka | Kafka Broker (5.3) | |
NVMe over TCP | tcp/4420 | nvme-over-tcp | Block Protocol NVMe over TCP | |
S3 | tcp/80 tcp/443 | http https | S3 Protocol | |
CNode | Replication VIPs | tcp/49001 tcp/49002 | Unencrypted TLS | VAST Replication uses different ports depending on whether TLS is configured and required. |
CNode | Docker Registry | tcp/5000 | http | Unnecessary; not used on this IP. (Listens on all network interfaces/addresses.) |
DNS VIP
Node Type | Protocol | Port(s) | Service | How they’re used |
|---|---|---|---|---|
CNode | DNS | udp/53 tcp/53 | VAST DNS | Can be placed on a VIP, serves DNS for other VIP Pools. |
IPMI Network
The IPMI Network is the network used for OOB (Out-of-Band) control of the server, which typically utilizes an IPMI device (“Intelligent Platform Management Interface”). Each chassis type may have a different version of this, and different acronyms may be used to describe this functionality, such as “BMC” (“baseboard management controller”) or “iLO” (“Integrated Lights-Out” for HPE). This can be used for:
Reading hardware sensor and log data
Issuing power cycle, power-on, power-off, and reset commands to the hardware
Serial console access (when configured)
Remote visual console access (VNC)
These are typically placed in a dedicated section of the customer’s network using top-of-rack switches specifically designed for this purpose. However, the hardware that provides this functionality can use an outdated OS and is not kept up to date with the latest security patches. To mitigate this, when nodes share a common carrier chassis (CNodes and DNodes within CBoxes and DBoxes), the nodes will often be connected to each other via short Ethernet cables, so that one node can control its partner without connecting the IPMI Network to the customer’s network. This is referred to as Back-To-Back (b2b) IPMI or BMC and is configured during installation.
ℹ️ Info
Since each chassis type has a variation on the IPMI service, the associated open network port tables will be provided in the future. For b2b configurations, open ports are not exposed to any customer network, and this section can be ignored.
Cluster Internal Network
The VAST Cluster Internal Network refers to the private network, typically being assigned IP addresses from ranges such as:
172.16.1.x
172.16.2.x
172.16.3.x
This network is accessible only from CNodes and DNodes and is intended only for inter-node traffic.
Node Type | Port(s) | Service | How they’re used |
|---|---|---|---|
CNode | tcp/4001 udp/4001 | RDMA (Platform) | High-speed, low-latency communication between CNodes and DNodes. Both TCP and UDP will be shown as open/listening, but UDP is specifically used for RDMA. |
tcp/5001 udp/5001 | RDMA (Data) | High-speed, low-latency communication between CNodes and DNodes. Both TCP and UDP will be shown as open/listening, but UDP is specifically used for RDMA. | |
tcp/6001 tcp/6001 | RDMA (Leader) | High-speed, low-latency communication between CNodes and DNodes. Only runs on the current Leader CNode. Both TCP and UDP will be shown as open/listening, but UDP is specifically used for RDMA. | |
tcp/5000 | Docker Registry | Nodes use Docker Registry to deploy Docker Images. | |
tcp/22 | SSH | The Platform uses SSH to connect between nodes to perform maintenance. | |
DNode | tcp/4001 udp/4001 | RDMA (Platform) | High-speed, low-latency communication between CNodes and DNodes. Both TCP and UDP will be shown as open/listening, but UDP is specifically used for RDMA. |
tcp/7001 udp/7001 | RDMA (DBox Data Access) | High-speed, low-latency communication between CNodes and DNodes. Both TCP and UDP will be shown as open/listening, but UDP is specifically used for RDMA. | |
tcp/7777 | Leader Election | Used to facilitate the election of a new Leader. | |
tcp/22 | SSH | The Platform uses SSH to connect between nodes to perform maintenance. |
App CNode applications
Spark On CNode
All the ports mentioned below are for a CNode node type.
(Spark) Component | Port(s) | Service | Spark’s default |
|---|---|---|---|
Worker | tcp/9293 | Http UI | 8081 |
tcp/9493 | Https UI | 8481 | |
Master | tcp/9292 | Http UI | 8080 |
tcp/9492 | Https UI | 8480 | |
tcp/6066 | Rest API | 6066 | |
tcp/2424 | RPC | 7077 | |
History Server | tcp/18080 | Http UI | 18080 |
tcp/18480 | Https UI | 18480 | |
Connect Server | tcp/4040 | Http UI | 4040 |
tcp/4440 | Https UI | 4440 | |
tcp/15002 | GRP API | 15002 | |
Thrift Server | tcp/4041 | Http UI | 4040 |
tcp/4441 | Https UI | 4440 | |
tcp/10000 | Thrift API | 10000 | |
tcp/10001 | Thrift over HTTP API | 10001 |
Additional Resources:
Information on most of the ports can be found in the following links: