ZPE Cloud is a cloud-based management and monitoring solution specifically designed to efficiently oversee Nodegrid devices. By registering all Nodegrid devices with the ZPE Cloud, you can establish a singular point of access, facilitating comprehensive control over the entire infrastructure— making remote management a seamless and efficient experience easing the troubleshooting processes and effectively minimizing downtime.
ZPE Cloud places a strong emphasis on security and adopts a Zero Trust-based access policy incorporating features such as multi-factor authentication and role-based access control. The development life cycle follows a secure approach through thorough code analysis, zero CVE policy, encrypting both data at rest and data in motion, and so on. The platform holds industry-leading certifications including SOC2 Type 2 and FIPS140-3, ensuring a high level of security.
Pre-requisites
To enable your device to establish communication with the ZPE Cloud, ensure that the following configuration requirements are met. If your device is situated behind a firewall or within a corporate environment, it is crucial to verify that the required firewall rules have been configured correctly to permit incoming and outgoing traffic to and from the ZPE Cloud services.
OS version: The Nodegrid appliance needs to be on v4.2.13 or newer. If the upgrade is needed, see the Upgrading a Nodegrid Device section.
Hardware: For NSC models, if the unit has TPM 1.2, TPM needs to be enabled. For more information, see How to enable TPM on BIOS. For other TPM versions, the TPM is enabled by default. For SR family, NSCP and units (including NSCs) built from 2020 onwards, TPM 1.2 is not used anymore.
Access and Firewall: Configure the Firewall Rules: ZPE Cloud uses some hostnames, IP addresses, ports, protocols and tls versions that the Firewall rules may block. This can prevent the Nodegrid appliances from connecting to the Cloud and/or utilizing specific ZPE Cloud features.
Network requirements: Make sure all the Network pre-requirements are fulfilled, such as delay, jitter, packet loss, and timeouts. More details on the Network recommendation’s section bellow.
Refer to the following table for information on the services.
Supported Services Details
ZPE Cloud uses port 443 in all its services and supports TLS 1.2 and TLS 1.3. The protocols used by the services are TCP-based more details on the table bellow.
Info
TPM 1.2 supports maximum of TLS 1.2 and custom chiphers “ALL:!LOW:!MEDIUM:!RSA:!PSK:!DH:!ARIA:!SHA:!SHA1:!AESCCM:!ECDSA”. TPM 2.0 supports TLS 1.3 and higher.
TPM is used by second-tier-ca.zpecloud.com, device-api.zpecloud.com and broker.astarte.zpecloud.com services. New OS is not using second-tier-ca.zpecloud.com (since v6.0.0) and device-api.zpecloud.com is on the process not to be used anymore. broker.astarte.zpecloud.com will continue using TPM.
US ZPE Cloud Servers
Hostname(s) | IPv6 Address | IPv4 Address | Protocol | Usage |
second-tier-ca.zpecloud.com | 2600:1901:0:6091:: | 34.49.235.253 | HTTPS |
|
api.astarte.zpecloud.com | 2600:1901:0:53ce:: | 34.49.39.37 | HTTPS |
|
access.zpecloud.com | 2600:1901:0:ab8f:: | 34.49.235.61 | WSS |
|
broker.astarte.zpecloud.com | 2600:1901:0:5abb:: | 34.49.26.197 | MQTTS |
|
www.zpecloud.com api.zpecloud.com proxy-access.zpecloud.com zpecloud.com | 2600:1901:0:910b:: | 34.120.236.72 | HTTPS |
|
European ZPE Cloud Servers
Hostname(s) | IPv6 Address | IPv4 Address | Protocol | Usage |
second-tier-ca.zpecloud.eu device-api.zpecloud.eu device-apiv2.zpecloud.eu | 2600:1901:0:b0cb:: | 34.128.171.100 | HTTPS |
|
api.astarte.zpecloud.eu | 2600:1901:0:7123:: | 34.49.228.213 | HTTPS |
|
access.zpecloud.eu | 2600:1901:0:e8af:: | 34.128.152.77 | WSS |
|
broker.astarte.zpecloud.eu | 2600:1901:0:9065:: | 34.36.11.79 | MQTTS |
|
www.zpecloud.eu api.zpecloud.eu proxy-access.zpecloud.eu zpecloud.eu | 2600:1901:0:ec0d:: | 34.111.34.34 | HTTPS |
|
Recommended Network Properties for ZPE Cloud
To ensure ZPE Cloud performs as expected, your Nodegrid device’s network must meet the following configuration requirements to avoid issues such as device remote access delays or failures, delayed software upgrade times, connection instability, and failed data transfers.
Info
From v6.0.18 until v6.0.32, an upgrade of Nodejs created a new default option to HTTP connections, causing the Remote Access client inside the Nodegrid OS to not be able to connect to the Remote Access server at ZPE Cloud if the network delay is higher than 250ms. This way, connection over Cellular and far away from GCP Load balancer instances may not be able to use the Remote Access service. The recommendation is to upgrade to at least v6.0.33, which contains a fix for the issue.
Parameter | Recommended Value | Challenge Value (slowness) | Maximum Value |
---|---|---|---|
Latency | <=80ms | <=500ms | 5000ms |
Jitter | <=20ms | <=300ms | - |
Packet-loss | <=1% | <=20% | 30% |
Bandwidth | >=20Mb | - | - |
Rate | - | >= 128kbps | - |
Note
Remote Access uses way more network traffic than other services. Under 5000ms delay the Device will not be able to connect to ZPE Cloud in any cirscuntance, being then shown as Offline and not being able to use Remote Access or communicate with ZPE Cloud.
To ensure a seamless experience with ZPE Cloud, it is important to maintain a well-configured and reliable network. A stable connection ensures quick and successful remote access, smooth software updates, and consistent connection stability without frequent reconnections. The network link connecting to a Nodegrid device plays a vital role, as it serves as the bridge between your managed devices and ZPE Cloud. For the best results, ensure this link is robust and dependable. Additionally, when accessing ZPE Cloud through a browser, a strong network connection for Nodegrid will further enhance performance and usability.
Service timeouts
When strong network connections are not available, Nodegrid has resilience to connect to ZPE Cloud and provide services to work on slower and weaker network connections, but the services have a limitation on timeouts to best detect network failures and fault connections or servers. This way, the network connection should be reliable at least to reach the following timeout conditions:
Service | Time (minutes) | Time (seconds) | Details |
---|---|---|---|
Nodegrid WEB GUI timeout | 6 minutes | 360 seconds | Apache service will keep established connections running this longer before considering it timed out. |
ZPE Cloud Connect connect timeout | 2 minutes | 120 seconds | Time for a Device to connect to ZPE Cloud and show Online before considering the connection try timed out and retry the connection request |
ZPE Cloud Connect keep-alive timeout | ½ minutes | 30 seconds | Time for the Device connected and Online on ZPE Cloud to receive an application confirmation (ping-pong) from ZPE Cloud server that the established connection and application session is still active. |
ZPE Cloud Remote Access connect timeout | 2 minutes | 120 seconds | Time for a Device to try connecting to Remote Access service before considering it timed out and retrying the connection request. During this time, the Remote Access keeps at ‘Waiting device’ page. Nodegrid WEB GUI interface is shared over this tunnel after the connection is established. |
ZPE Cloud Remote Access heartbeat timeout (keep-alive) | 1 minute | 60 seconds | Time for the Device connected to Remote Access to receive an application confirmation (heartbeat) from ZPE Cloud server that the established connection and application session is still active. |
Info
From v6.0.33 onwards, Remote Access connect timeout has been defined as 120s. Versions prior to the mentioned supported versions (e.g., v5.10.x, v5.8.x and previous EOL versions) does not have a explicit connect timeout, relying on keep-alive timeout, meaning the underground connect timeout matched heartbeat’s 60s.