Contents x
      Release Notes Archive
      • 25 Feb 2024
      • 67 Minutes to read
      • Print
      • Dark
        Light
      Contents

      Release Notes Archive

      • Updated on 25 Feb 2024
      • 67 Minutes to read
      • Print
      • Dark
        Light
      Article Summary

      Release Notes v23.12

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      • Product naming updates
        To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

        2. Changes in this Release

        2.1. New Features

        • Multi Nic support in Edge iNode
        • Exclusive NIC access for Service
        • iNode Geo location configuration and Map
        • Device Discovery(beta)
        2.2. Enhancements
        • Provision to Create/Edit iNode and Network in bulk.

        2.3. Bug Fixes

        Nil

        3. Prerequisites

        3.1. Cloud Requirements

        The following cloud platforms are supported:

        • Amazon AWS
        • Microsoft Azure
        • VMware vSphere v6.x
        • Google Cloud

        3.1.1. Virtual iNode Compute Requirements

        2 vCPU, 2GB RAM, 10GB HDD, Public IP address

        3.2. Hardware Requirements

        • The following hardware platforms are supported for iNode Edge:
          • ADLINK MXE-211
            • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
          • Advantech UNO 2484G
          • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
          • Dell PowerEdge R240 server platform
          • Lanner LEC-7230M-J11A
          • Lanner NCA-1510D
          • Mobile broadband support requires AT&T or Verizon micro SIM
          • Lanner NCA-1510A
          • Supermicro SYS-E50-9AP

        4. Issues

        4.1. Limitations

        1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
        2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
        3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
        4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
        5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
        6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
        7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
        8. Volume created for SkySpark license is required to have a filename with extension ".props".
        9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
        10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
        11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
        12. The maxium size of the downloaded Service logs is limited to 10 MB.
        13. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
        14. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
        15. Editing a Secret requires the Service to be restarted to take effect.
        16. Service addressing can be set only when adding the network and can not be changed later by editing the network.
        17. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
        18. In the hardware monitoring, the Power supply status and its temperature is not reported.
        19. When configuring timezone settings for the container, application container packager has to ensure that "tzdata" and "date" packages are installed in the container image to take effect.
        20. When configuring timezone settings for the container, please add the label "_iotium_core_service=true" to the Core services to ensure they aren't affected by container time zone setting. Services without "_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.
        21. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Orchestrator User interface is that of the proxy IP.
        22. Firewall rules cannot be applied for the Inter Traffic Routing within edge iNode.
        23. One-Arm mode is not supported with Multi NIC
        24. Intense scan report shows offline hosts also.
        25. Scan status is updated after 3 mins.
        26. Inter TAN Routing  is not supported for dynamic TAN

        4.2. Known Problems

        1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode's network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
        2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
        3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
        4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
        5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
        6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
        7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
        8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
        9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
        10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
        11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
        12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
        13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
        14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
        15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don't synchronize time with the NTP service.
        16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
        17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
        18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.
        19. iNode conversion to cluster is not supported if dynamic addressing mode TAN networks exists in iNode.
        20. Threat Intelligence enable/disable is not logged in activity log.
        21. Parent org dashboard may not show the threats detected in child org.
        22. Bulk User create/edit will be performed in the organization of the logged in user.
        23. Threat detected in child org is not consolidated in parent org's dashboard.
        24. Device Discovery enable/disable is not audited.
        25. iNode’s location will be plotted randomly when an invalid address is entered.
        26. Device Discover is not supported in cluster
        27. Scan report of a scan config will be deleted when the scan config is deleted.
        28. Bacnet information is not available in downloaded report.
        29. Device discovery config is not allowed for 10 mins from TAN network edit.

      Release Notes v23.09

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      • Product naming updates
        To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

        2. Changes in this Release

        2.1. New Features

        • Provision to Create/Edit users in bulk.
        • Marketplace highlighted in SE portal.
        • Cloud images supported for Vedge including AWS,GCP,Azure and VMware,support to create one TAN network.
        2.2. Enhancements
        • Provision to attach Service to multiple TAN networks.
        • TI Improvements.
        • Exponential cert expiry notification.
        • Master re-election on interface link failure.
        • Availability of iNode's interface details in SE portal, when iNode is in NEW state.

        2.3. Bug Fixes

        Nil

        3. Prerequisites

        3.1. Cloud Requirements

        The following cloud platforms are supported:

        • Amazon AWS
        • Microsoft Azure
        • VMware vSphere v6.x
        • Google Cloud

        3.1.1. Virtual iNode Compute Requirements

        2 vCPU, 2GB RAM, 10GB HDD, Public IP address

        3.2. Hardware Requirements

        • The following hardware platforms are supported for iNode Edge:
          • ADLINK MXE-211
            • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
          • Advantech UNO 2484G
          • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
          • Dell PowerEdge R240 server platform
          • Lanner LEC-7230M-J11A
          • Lanner NCA-1510D
          • Mobile broadband support requires AT&T or Verizon micro SIM
          • Lanner NCA-1510A
          • Supermicro SYS-E50-9AP

        4. Issues

        4.1. Limitations

        1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
        2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
        3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
        4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
        5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
        6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
        7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
        8. Volume created for SkySpark license is required to have a filename with extension ".props".
        9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
        10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
        11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
        12. The maxium size of the downloaded Service logs is limited to 10 MB.
        13. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
        14. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
        15. Editing a Secret requires the Service to be restarted to take effect.
        16. Service addressing can be set only when adding the network and can not be changed later by editing the network.
        17. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
        18. In the hardware monitoring, the Power supply status and its temperature is not reported.
        19. When configuring timezone settings for the container, application container packager has to ensure that "tzdata" and "date" packages are installed in the container image to take effect.
        20. When configuring timezone settings for the container, please add the label "_iotium_core_service=true" to the Core services to ensure they aren't affected by container time zone setting. Services without "_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.
        21. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Orchestrator User interface is that of the proxy IP.
        22. Firewall rules cannot be applied for the Inter Traffic Routing within edge iNode.

        4.2. Known Problems

        1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode's network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
        2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
        3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
        4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
        5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
        6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
        7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
        8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
        9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
        10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
        11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
        12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
        13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
        14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
        15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don't synchronize time with the NTP service.
        16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
        17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
        18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.
        19. iNode conversion to cluster is not supported if dynamic addressing mode TAN networks exists in iNode.
        20. Threat Intelligence enable/disable is not logged in activity log.
        21. Parent org dashboard may not show the threats detected in child org.
        22. Bulk User create/edit will be performed in the organization of the logged in user.
        23. Threat detected in child org is not consolidated in parent org's dashboard.

      Release Notes v23.08

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      • Product naming updates
        To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

        2. Changes in this Release

        2.1. New Features

        • Threat Intelligence.
        2.2. Enhancements
        • Virtual FQDN 
        • Deprecation notice in redirect message

        2.3. Bug Fixes

        Nil

        3. Prerequisites

        3.1. Cloud Requirements

        The following cloud platforms are supported:

        • Amazon AWS
        • Microsoft Azure
        • VMware vSphere v6.x
        • Google Cloud

        3.1.1. Virtual iNode Compute Requirements

        2 vCPU, 2GB RAM, 10GB HDD, Public IP address

        3.2. Hardware Requirements

        • The following hardware platforms are supported for iNode Edge:
          • ADLINK MXE-211
            • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
          • Advantech UNO 2484G
          • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
          • Dell PowerEdge R240 server platform
          • Lanner LEC-7230M-J11A
          • Lanner NCA-1510D
          • Mobile broadband support requires AT&T or Verizon micro SIM
          • Lanner NCA-1510A
          • Supermicro SYS-E50-9AP

        4. Issues

        4.1. Limitations

        1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
        2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
        3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
        4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
        5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
        6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
        7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
        8. Volume created for SkySpark license is required to have a filename with extension ".props".
        9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
        10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
        11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
        12. The maxium size of the downloaded Service logs is limited to 10 MB.
        13. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
        14. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
        15. Editing a Secret requires the Service to be restarted to take effect.
        16. Service addressing can be set only when adding the network and can not be changed later by editing the network.
        17. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
        18. In the hardware monitoring, the Power supply status and its temperature is not reported.
        19. When configuring timezone settings for the container, application container packager has to ensure that "tzdata" and "date" packages are installed in the container image to take effect.
        20. When configuring timezone settings for the container, please add the label "_iotium_core_service=true" to the Core services to ensure they aren't affected by container time zone setting. Services without "_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.
        21. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Orchestrator User interface is that of the proxy IP.
        22. Firewall rules cannot be applied for the Inter Traffic Routing within edge iNode.

        4.2. Known Problems

        1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode's network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
        2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
        3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
        4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
        5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
        6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
        7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
        8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
        9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
        10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
        11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
        12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
        13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
        14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
        15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don't synchronize time with the NTP service.
        16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
        17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
        18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.
        19. iNode conversion to cluster is not supported if dynamic addressing mode TAN networks exists in iNode.
        20. Threat Intelligence enable/disable is not logged in activity log.
        21. Parent org dashboard may not show the threats detected in child org.

      Release Notes v23.06

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

      2. Changes in this Release

      2.1. New Features

      • Support for iNode High Availability, to eliminate the Edge iNode as a single point of failure.
      • Support to convert an Edge iNode into a cluster.
      • iNode configuration retention during iNode replacement.
      • Inter TAN routing within Edge iNode.
      2.2. Enhancements
      • Custom Branding of SE portal - Customers can now customize their organization’s SE portal by uploading images.
      • Clustering Enhancements - Support for creating multiple TAN networks in a cluster.

      2.3. Bug Fixes

      Some of the notable bug fixes:

      1. Representational Network can be configured for static route to allow remote networks with or without conflict.

      3. Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      • The following hardware platforms are supported for iNode Edge:
        • ADLINK MXE-211
          • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
        • Advantech UNO 2484G
        • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
        • Dell PowerEdge R240 server platform
        • Lanner LEC-7230M-J11A
        • Lanner NCA-1510D
        • Mobile broadband support requires AT&T or Verizon micro SIM
        • Lanner NCA-1510A
        • Supermicro SYS-E50-9AP

      4. Issues

      4.1. Limitations

      1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      8. Volume created for SkySpark license is required to have a filename with extension ".props".
      9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      12. The maxium size of the downloaded Service logs is limited to 10 MB.
      13. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      14. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      15. Editing a Secret requires the Service to be restarted to take effect.
      16. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      17. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      18. In the hardware monitoring, the Power supply status and its temperature is not reported.
      19. When configuring timezone settings for the container, application container packager has to ensure that "tzdata" and "date" packages are installed in the container image to take effect.
      20. When configuring timezone settings for the container, please add the label "_iotium_core_service=true" to the Core services to ensure they aren't affected by container time zone setting. Services without "_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.
      21. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Orchestrator User interface is that of the proxy IP.
      22. Firewall rules cannot be applied for the Inter Traffic Routing within edge iNode.

      4.2. Known Problems

      1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode's network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
      6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
      9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
      10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
      11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
      12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
      13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
      14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
      15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don't synchronize time with the NTP service.
      16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
      17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
      18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.
      19. iNode conversion to cluster is not supported if dynamic addressing mode TAN networks exists in iNode.


      Release Notes v22.10

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

      2. Changes in this Release

      2.1. New Features

      • Facilitates detection and notification of duplicate IP addresses between the iNode TAN interface/TAN Services, and IP addresses for entities and devices that are south of the iNode.
      • Extension to "Security Policy" capabilities to allow users to specify firewall rules in the Service to Device and Device to Service directions within a TAN network.
      • Support for Virtual Edge on the Amazon Web Services (AWS).
      2.2. Enhancements
      • Extension to time-server configuration to allow user to specify a NTP Server’s FQDN while setting a timer-server on the iNode.
      • Enhancement to allow Org Admins to enforce Multi Factor Authentication for all users in an Org.
      • Multiple Secure Edge User Interface look-and-feel improvements

      2.3. Bug Fixes

      Some of the notable bug fixes:

      1. WAN interface MAC address changes on iNode reboot.
      2. In a rare scenario, application logs in the iNode are not rotated and this was filling up the filesystem.
      3. User-Agent on the tunnel request is set to default.

      3. Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      • The following hardware platforms are supported for iNode Edge:
        • ADLINK MXE-211
          • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
        • Advantech UNO 2484G
        • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
        • Dell PowerEdge R240 server platform
        • Lanner LEC-7230M-J11A
        • Lanner NCA-1510D
        • Mobile broadband support requires AT&T or Verizon micro SIM
        • Lanner NCA-1510A
        • Supermicro SYS-E50-9AP

      4. Issues

      4.1. Limitations

      1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Secure Edge to be updated to Alive.
      2. When connecting iNodes from the Secure Edge the first time, both iNodes should be in the Alive status.
      3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      8. Volume created for SkySpark license is required to have a filename with extension ".props".
      9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      10. When Standalone Mode is activated for an iNode from the Secure Edge, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      12. The maxium size of the downloaded Service logs is limited to 10 MB.
      13. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      14. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      15. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.
      16. Editing a Secret requires the Service to be restarted to take effect.
      17. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      18. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      19. In the hardware monitoring, the Power supply status and its temperature is not reported.
      20. When configuring timezone settings for the container, application container packager has to ensure that “tzdata“ and “date“ packages are installed in the container image to take effect.
      21. When configuring timezone settings for the container, please add the label “_View_core_service=true“ to the Core services to ensure they aren’t affected by container time zone setting. Services without “_View_core_service=true" label will be restarted and will come up with the container timezone that is configured.
      22. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Secure Edge User interface is that of the proxy IP.

      4.2. Known Problems

      1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      2. If no service log has been generated in the last 24 hours, the Service Logs window in the Secure Edge will not show any logs even if there are logs generated earlier.
      3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
      6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
      9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
      10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
      11. View CLI login expires after idle session timeout; View CLI throws 401 error unless user logs into the Secure Edge using View CLI again.
      12. When you modify network or add Custom Security Policy to a network using View CLI, existing static routes are removed.
      13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
      14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
      15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don’t synchronize time with the NTP service.
      16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Secure Edge for iNodes with debian distro.
      17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Secure Edge.
      18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.


      Release Notes v22.05

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

      2. Changes in this Release

      2.1. New Features

      • Service access from the WAN interface (for select customers) allows users to access the edge services via the iNode WAN interface.
      • Support for Virtual Edge on the Google Cloud Platform (GCP).
      • Per container memory limit - This allows a per container memory limit; this will cause the container to exit once the container goes above the specified memory limit.
      • Alert enhancements - Allows users to subscribe to alerts based on resource (scope iNodes or Clusters) labels. Users can subscribe to alerts on a subset of iNodes.
      2.2. Enhancements
      • Time zone setting for containers – iNode wide Time zone setting (for containers to inherit) from the Orchestrator User Interface.
      • Webhook addition for alerts – Users can add and test a webhook from the Orchestrator User Interface.
      • Priority buckets for User Services are used to assign priorities to user services which then control the sequence of Service launches.
      • Added the ability for an org admin role using the org policies to create Child organization.
      • Multiple Orchestrator User Interface look-and-feel improvements.

      2.3. Bug Fixes

      Some of the notable bug fixes:

      1. In a rare scenario, application logs in the iNode were not rotated and this was filling up the filesystem.
      2. Unable to subscribe to alerts for all services under an iNode from the Orchestrator User Interface.
      3. When a Service is upgraded, and along with it a change in the attached secret data, the updated secret was not pulled in.

      3. Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      • The following hardware platforms are supported for iNode Edge:
        • ADLINK MXE-211
          • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
        • Advantech UNO 2484G
        • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
        • Dell PowerEdge R240 server platform
        • Lanner LEC-7230M-J11A
        • Lanner NCA-1510D
        • Mobile broadband support requires AT&T or Verizon micro SIM
        • Lanner NCA-1510A
        • Supermicro SYS-E50-9AP

      4. Issues

      4.1. Limitations

      1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      8. Volume created for SkySpark license is required to have a filename with extension ".props".
      9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      12. The iNode CLI command to configure NTP server only allows you to specify IP addresses; does not allow you to specify FQDN for NTP server.
      13. The maxium size of the downloaded Service logs is limited to 10 MB.
      14. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      15. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      16. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.
      17. Editing a Secret requires the Service to be restarted to take effect.
      18. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      19. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      20. In the hardware monitoring, the Power supply status and its temperature is not reported.
      21. When configuring timezone settings for the container, application container packager has to ensure that “tzdata“ and “date“ packages are installed in the container image to take effect.
      22. When configuring timezone settings for the container, please add the label “_iotium_core_service=true“ to the Core services to ensure they aren’t affected by container time zone setting. Services without “_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.
      23. When configuring a proxy for the Virtual Edge on GCP, the public IP displayed in the iNode details page on the Orchestrator User interface is that of the proxy IP.

      4.2. Known Problems

      1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
      6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
      9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
      10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
      11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
      12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
      13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
      14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
      15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don’t synchronize time with the NTP service.
      16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
      17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
      18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.


      Release Notes v21.10

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.

      2. Changes in this Release

      2.1. New Features

      • Node CLI from the orchestrator – Allows to configure and view iNode CLI from the orchestrator via API.
      • Hardware Monitoring (for select customers, specific hardware) – iNode System parameters (Temperature Status, Fan Status, NIC status, Storage status) via API.
      • Time zone setting for containers (for select customers) – iNode wide Time zone setting (for containers to inherit) via API.
      • Alert enhancements - Allows users to edit earlier configured alerts, also reduced minimum threshold levels for triggering Alerts to 1 Minute.
      • Download default SSH key from orchestrator - For iNodes in new state, users can download the default SSH key from the orchestrator.
      2.2. Enhancements
      • Reduced iNode boot time – Optimized the iNode startup sequence.
      • Expose current metrics usage - The current usage stats of Filesystem, CPU and memory are now available as part of the existing stats API endpoint.
      • Service static IP retention upon iNode IP change - Services configured with static IP will now retain their IP’s upon iNode IP change, though If subnet of the iNode IP for the specific network changes, onus would be on the user to reconfigure the Service IP addresses accordingly.
      • DNS downtime reduction post fail over -DNS downtime post fail over is brought down to less than 10 seconds.
      • Periodic prune to remove unused containers and images to reduce disk usage.
      • Ability to force remove dangling images from the orchestrator.
      • Priority buckets for Services, to control the sequence of Service launches. Currently restricted to Core services, to ensure Core services are launched in a specific sequence, and launched before user services.
      • Multiple Orchestrator User Interface look-and-feel improvements.

      2.3. Bug Fixes

      Some of the notable bug fixes:

      1. All the images used by the services are not displayed on orchestrator, there was a cap of 50 images. Now all images are displayed.
      2. ARP increased to 16K. The neigh table limits were limiting to 1024, this is increased to 16K.
      3. In a rare scenario resultant of a race condition the remote network connections were disconnected from the virtual iNode. The underlying race condition is corrected and the remote networks no longer disconnect.
      4. The organization level maximum number of services were limited to 32 per iNode, this limit is now configurable and extended to 64.
      5. Orchestrator was not displaying more than 25 services in the metrics page, this is now fixed and orchestrator displays all the services in the iNode.
      6. Orchestrator was not displaying more than 25 images in the images page, this is now fixed and orchestrator displays all the images in the iNode.
      7. Orchestrator was not displaying the singleton services at the iNode level, this is now fixed and orchestrator displays singleton services at the iNode master level.
      8. Orchestrator was not displaying singleton services metrics in the iNode master metrics page, this is now fixed and Orchestrator displays singleton metrics in the iNode master metrics page.
      9. Mechanism to delete stale iNode application logs to limit the log files from filling up the filesystem.

      3. Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      • The following hardware platforms are supported for iNode Edge:
        • ADLINK MXE-211
          • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
        • Advantech UNO 2484G
        • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
        • Dell PowerEdge R240 server platform
        • Lanner LEC-7230M-J11A
        • Lanner NCA-1510D
        • Mobile broadband support requires AT&T or Verizon micro SIM
        • Lanner NCA-1510A
        • Supermicro SYS-E50-9AP

      4. Issues

      4.1. Limitations

      1. On rebooting iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      8. Volume created for SkySpark license is required to have a filename with extension ".props".
      9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      12. The iNode CLI command to configure NTP server only allows you to specify IP addresses; does not allow you to specify FQDN for NTP server.
      13. The maxium size of the downloaded Service logs is limited to 10 MB.
      14. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      15. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      16. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.
      17. Editing a Secret requires the Service to be restarted to take effect.
      18. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      19. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      20. In the hardware monitoring, the Power supply status and its temperature is not reported.
      21. When configuring timezone settings for the container, application container packager has to ensure that “tzdata“ and “date“ packages are installed in the container image to take effect.
      22. When configuring timezone settings for the container, please add the label “_iotium_core_service=true“ to the Core services to ensure they aren’t affected by container time zone setting. Services without “_iotium_core_service=true" label will be restarted and will come up with the container timezone that is configured.

      4.2. Known Problems

      1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
      6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
      9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
      10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
      11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
      12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
      13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
      14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
      15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don’t synchronize time with the NTP service.
      16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
      17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.
      18. When you create a dynamic Edge iNode network, you will need to edit the network to connect to a remote network.


      Release Notes v21.03

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.


      2. Changes in this Release

      2.1. New Features

      • One-Arm Mode (for select customers) – Allows a single port on the iNode to act as both uplink (northbound) and downlink (southbound) interface, as opposed to the default configuration which requires at least two separate ports.
      • Dynamic Network Addressing Mode – Hosts and services on your local network can now get dynamic IP addresses from a DHCP server.
      • ioTium Core Services (for select customers) – A collection of fundamental services useful for your hosts and services on the local network: Kea – DHCP and DDNS server, PowerDNS – DNS server, PostgreSQL – Database, NTP – NTP server
      • iNode Cluster (for select customers) – A group of Edge iNodes that together offer high availability capability with stateful failover to eliminate the Edge iNode as a single point of failure.
      • diag iNode CLI command – Helps diagnose iNode-ioTium Orchestrator connectivity issues.

      2.2. Enhancements


      • iNode Resource Usage Alert – Trigger an alert when the iNode’s CPU, Memory, or Filesystem usage crosses a threshold.
      • Custom Branding of ioTium Orchestrator (for select customers) – You can now specify a font family of your choice for the Orchestrator to use.
      • Service Logs – Logs for the previous exited container are also available in the Orchestrator.
      • iNode Diagnostic – You can now choose the level of iNode diagnostic data to collect and send to troubleshoot issues with the iNode.
      • iNode Time Synchronization Status – The list of configured time servers and the server iNode is currently synchronized to is available in the Orchestrator.
      • Alert Notification via Webhook (for select customers) – You can now use the Orchestrator User Interface to specify a webhook to notify you when an alert is triggered.
      • Multiple Orchestrator User Interface look-and-feel improvements.

      2.3.Bug Fixes


      Some of the notable bug fixes:

      1. During routine maintenance, in a specific scenario the services on Edge iNodes were deleted and recreated, causing loss of contents of the volume mounted on the services.
      2. When multiple Edge iNode networks are connected to a single Virtual iNode network, on the Virtual iNode network side a few remote network connection statuses are reported as NOT AVAILABLE.
      3. When multiple Edge iNode networks are connected to a single Virtual iNode network, a new remote network connection or reconnecting an existing remote network connection may fail. The remote network connection logs may also have high disk usage.
      4. Orchestrator may report incorrect iNode status in certain scenarios.
      5. Service may fail to run when using a private registry to pull image for the service.
      6. In standalone mode, if you’re running a service with image pull policy ALWAYS, and you reboot the iNode when there is no uplink connection, the service remains in PENDING state even after the uplink connection is restored.
      7. Orchestrator does not show the remote network connection status if the iNode name and the iNode network name are long.
      8. Deleting a service when the iNode is UNREACHABLE may cause the service to remain in DELETING state.
      9. Unable to copy the custom route shown in the Orchestrator when you mouse-over the info icon displayed next to a remote network in the Networks tab of the iNode details page.
      10. The Filesystem usage chart shown in the Orchestrator is blank for a specific version of the iNode.
      11. If a static route for a routed segment behind the Edge iNode is wrongly added with iNode’s IP address as the gateway IP address, then the route for the Default Destination is not set on the Edge iNode.
      12. In standalone mode, creating a service with a pull secret may fail.
      13. If you create a service, enable standalone mode and the iNode connection to Orchestrator becomes flaky, in a specific scenario the service may not be created.
      14. When you add a volume (secret) to a service, the files in the volume are mounted with wrong permission.

      3.Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements


      The following hardware platforms are supported for iNode Edge:

      • ADLINK MXE-211
        • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
      • Advantech UNO 2484G
      • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
      • Dell PowerEdge R240 server platform
      • Lanner LEC-7230M-J11A
      • Lanner NCA-1510D
      • Mobile broadband support requires AT&T or Verizon micro SIM
      • Lanner NCA-1510A
      • Supermicro SYS-E50-9AP

      4.Issues

      4.1. Limitations

      1. On rebooting iNode, depending on the number of container images in the iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      2. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      3. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      4. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      5. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      6. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      7. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      8. Volume created for SkySpark license is required to have a filename with extension ".props".
      9. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      10. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      11. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      12. The iNode CLI command to configure NTP server only allows you to specify IP addresses; does not allow you to specify FQDN for NTP server.
      13. The maxium size of the downloaded Service logs is limited to 10 MB.
      14. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      15. When using iNode CLI, if you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      16. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.
      17. Editing a Secret requires the Service to be restarted to take effect.
      18. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      19. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.

      4.2. Known Problems

      1. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      2. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      3. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      4. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      5. When you use the iNode CLI and configure a name server, iNode uses this name server in addition to the DHCP server provided name servers if any.
      6. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      7. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      8. If the Edge iNode network uses Representational network, traffic from a routed segment behind the Virtual iNode is not routed to the Edge iNode network.
      9. If the Edge iNode network uses Representational network, traffic from the Virtual iNode network is not routed to a routed segment behind the Edge iNode network.
      10. Static routes to allow remote networks will not work if static routes with Representational Network is configured.
      11. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the Orchestrator using ioTium CLI again.
      12. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing static routes are removed.
      13. When you reboot an iNode with numerous services, depending on your Edge iNode hardware it may take several minutes for the services to come back up.
      14. In an iNode cluster if all the candidates in the master election have the same priority, the candidate with the highest IP address may not always be elected as the master.
      15. In an iNode cluster with the NTP core service deployed as a singleton, services running on the backup iNodes don’t synchronize time with the NTP service.
      16. The list of configured time servers and the server iNode is currently synchronized to is not available in the Orchestrator for iNodes with debian distro.
      17. In an iNode cluster with a singleton service in UNKNOWN state because of an error condition, the message from the container is not available in the Orchestrator.


      Release Notes v20.05

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.


      2. Changes in this Release

      2.1. New Features

      • Alert Notification via Webhook – You can now use webhooks to build or set up your integrations which subscribe to alerts from the ioTium Orchestrator.
      • Download Activity Log and Event Log – The event log lists events raised as part of the run-time operation of your iNode, iNode network, and Services. The activity log lists the user-initiated control and management actions that modify your ioTium Orchestrator resources. You can now download the event log and activity log.
      • Restart Service from ioTium Orchestrator (for select customers) – From the Orchestrator you can now restart your service running on an Edge iNode.

      2.2. Enhancements


      • iNode and Service Metrics – You can now view both iNode metrics and service container metrics in the same chart, additional metrics widgets in the Metrics Dashboard page, and additional charts in the Metrics Overview page.
      • Custom Branding of ioTium Orchestrator – You can now customize the from email address for all emails that the Orchestrator sends you. Also, now the emails the Orchestrator sends you and the event/activity logs you download use your company’s logo.

      2.3.Bug Fixes


      Some of the notable bug fixes:

      • If you use the standalone mode, in a specific scenario the Orchestrator displays incorrect standalone mode expiry timer in the iNode details page.

      3.Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      The following hardware platforms are supported for iNode Edge:

      • ADLINK MXE-211
        • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
      • Advantech UNO 2484G
      • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
      • Dell PowerEdge R240 server platform
      • Lanner LEC-7230M-J11A
      • Lanner NCA-1510D
      • Mobile broadband support requires AT&T or Verizon micro SIM
      • Lanner NCA-1510A
      • Supermicro SYS-E50-9AP

      4.Issues

      4.1. Limitations

      1. Orchestrator-iNode management traffic (for status, logs, metrics, etc.) is by default approximately 223 MB per month for a hardware Edge iNode with no services running. If you turn Data Saving Mode on and choose to send metrics from iNode once in 5 minutes, the management traffic decreases to approximately 85 MB per month. If you choose to not send the metrics at all, the number decreases to approximately 36 MB per month.
      2. When an Edge iNode network is connected to a Virtual iNode network, approximately 35 MB per month is used to maintain high availability connection.
      3. If the data plan expires for mobile broadband uplink, the show interface CLI command displays badly formatted error.
      4. On rebooting iNode, depending on the number of container images in the iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      5. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      6. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      7. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      8. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      9. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      10. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      11. Volume created for SkySpark license is required to have a filename with extension ".props".
      12. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      13. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      14. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      15. To connect Edge iNode network(s) to Virtual iNode network(s), both Edge and Virtual iNodes must be at version 1820.y.z or later.
      16. The iNode CLI command to configure NTP server only allows you to specify IP addresses; does not allow you to specify FQDN for NTP server.
      17. The maxium size of the downloaded Service logs is limited to 10 MB.
      18. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      19. When using iNode CLI, If you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      20. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.

      4.2. Known Problems

      1. Editing a Secret requires the Service to be restarted to take effect.
      2. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      3. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      4. In the Dashboard the iNodes that are being rebooted are counted twice under ALIVE count as well as REBOOTING count. Once the reboot is complete, the count is correctly updated.
      5. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      6. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      7. The Verizon mobile broadband uplink interface information displayed in the Orchestrator does not include Operator, APN, Band, and Signal quality. Also, sometimes the status of the interface is not updated properly.
      8. When using private registry to pull image for your Service, if the authentication to the private registry fails the Service will be stuck in UNKNOWN state. Please delete the Service, provide the correct credentials in the image pull secret, and add the Service again.
      9. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      10. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      11. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      12. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      13. When you configure static route to TAN routed segment via Configured TAN Gateway, Default Destination routes are not installed on Edge iNode.
      14. When you configure Representational Network for Edge iNode’s Network, traffic from a segmented APP cloud is not routed to TAN.
      15. When you configure Representational Network for Edge iNode’s Network, traffic from APP cloud is not routed to Segmented TAN.
      16. Static routes to allow remote networks will not work if Static routes with Representational Network is configured.
      17. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the orchestrator using ioTium CLI again.
      18. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing Static routes are removed.


      Release Notes v20.02

      1. Introduction

      This document provides information on the features, improvements, and known issues in this release.

      Product naming updates
      To better unify branding across all of our technologies, we have changed our product names from ioTium to View Secure Edge, and ioTium Orchestrator to Secure Edge Portal. These updates are now reflected in our product UIs and in our documentation.


      2. Changes in this Release

      2.1. New Features

      • Custom Branding of ioTium Orchestrator - You can now customize your organization’s ioTium Orchestrator account to match your company’s branding standards. Custom branding is enabled for your company’s account by ioTium based on your Subscription Agreement. For more information about getting this feature enabled, please contact your Account Manager.
      • Event Log - The event log lists events raised as part of the run-time operation of your iNode, iNode network, and Services. If you have an Admin role in your company’s ioTium Orchestrator account, you’ll be able to view the event log.
      • Activity Log - The activity log lists the user-initiated control and management actions that modify your ioTium Orchestrator resources. If you have an Admin role in your company’s ioTium Orchestrator account, you’ll be able to view the activity log.
      • iNode and Service Metrics - You can view metrics on resource usage and performance of an iNode and the services running on it. The metrics includes CPU, memory, and filesystem utilization, as well as network and serial interface traffic.
      • Static Routes - You can now create static routes on Edge iNode to allow hosts in remote networks behind the Virtual iNode to reach specific routed segments behind the Edge iNode.
      • New Edge iNode hardware support - The following hardwares are now supported:

        • Lanner NCA-1510D

        • Lanner NCA-1510A

        • Supermicro SYS-E50-9AP

      2.2. Enhancements


      • Multiple Orchestrator User Interface look-and-feel improvements.
      • Reduced management traffic - Reduced Orchestrator-iNode management traffic and remote network connection management traffic.

      2.3.Bug Fixes


      Some of the notable bug fixes:

      • If there is no alert for iNode status at the Org level but there is an alert for iNode status for a specific iNode, the alert may be triggered when the status of any iNode in the Org changes.
      • On an iNode with service running and standalone mode enabled, performing edit network would require standalone mode to be disabled and re-enabled for the service to continue working.
      • The iNode Uptime displayed is incorrect when the iNode becomes ALIVE in the Orchestrator for the first time; after a reboot the Uptime is updated correctly.The iNode status should be ALIVE in Orchestrator when you change the DNS servers configuration for an existing service.
      • When you try to delete unused container images it sometimes fails, leading to high storage utilization.
      • After you provision an iNode, in a particular case the Orchestrator may not show the iNode information or the iNode may become UNREACHABLE.
      • Connecting to a remote network may fail if you frequently connect and disconnect your Edge iNode network to a remote network or try to connect multiple Edge iNode networks to the same remote network.
      • When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently.
      • Your service can get stuck in PENDING state on a small set of iNodes that went through a specific software upgrade path.
      • If you configure your iNode to operate in standalone mode and it loses connectivity to the Orchestrator, if you reboot your iNode or the standalone mode timer expires, your service data may get deleted.

      3.Prerequisites

      3.1. Cloud Requirements

      The following cloud platforms are supported:

      • Amazon AWS
      • Microsoft Azure
      • VMware vSphere v6.x
      • Google Cloud

      3.1.1. Virtual iNode Compute Requirements

      2 vCPU, 2GB RAM, 10GB HDD, Public IP address

      3.2. Hardware Requirements

      The following hardware platforms are supported for iNode Edge:

      • ADLINK MXE-211
        • Mobile broadband support requires SIMCom SIM7100A mobile broadband module
      • Advantech UNO 2484G
      • Dell Edge Gateway 5000 (Model: LBEE5ZZ1EN)
      • Dell PowerEdge R240 server platform
      • Lanner LEC-7230M-J11A
      • Lanner NCA-1510D
      • Mobile broadband support requires AT&T or Verizon micro SIM
      • Lanner NCA-1510A
      • Supermicro SYS-E50-9AP

      4.Issues

      4.1. Limitations

      1. Orchestrator-iNode management traffic (for status, logs, metrics, etc.) is by default approximately 223 MB per month for a hardware Edge iNode with no services running. If you turn Data Saving Mode on and choose to send metrics from iNode once in 5 minutes, the management traffic decreases to approximately 85 MB per month. If you choose to not send the metrics at all, the number decreases to approximately 36 MB per month.
      2. When an Edge iNode network is connected to a Virtual iNode network, approximately 35 MB per month is used to maintain high availability connection.
      3. If the data plan expires for mobile broadband uplink, the show interface CLI command displays badly formatted error.
      4. On rebooting iNode, depending on the number of container images in the iNode it could take approximately 5 minutes after the reboot for the iNode status in Orchestrator to be updated to Alive.
      5. When connecting iNodes from the Orchestrator the first time, both iNodes should be in the Alive status.
      6. While launching Virtual iNode in Microsoft Azure, uploading the VHD file might take a long time depending on your network connection.
      7. When multiple Edge iNode networks are connected to a Virtual iNode network, allowing Inter Remote Network Traffic does not work if any of the Edge iNode networks use Representational network.
      8. When representational network is used and there is ongoing traffic between the Edge iNode network and an Virtual iNode network, the ongoing traffic is not resumed after rebooting either iNode.
      9. When many Edge iNode networks are connected to one Virtual iNode network, for Inter Remote Network Traffic to work the Default Destination should be set to the remote Virtual iNode network.
      10. If the Default Destination is set to a remote network and there is ongoing traffic from local network to Internet, changing Default Destination to WAN Network will drop the Internet traffic unless the ongoing traffic is restarted.
      11. Volume created for SkySpark license is required to have a filename with extension ".props".
      12. If Proxy is configured on a Virtual iNode, connecting the Virtual iNode network to an Edge iNode network will fail unless Port Forwarding is enabled on the Proxy Server.
      13. When Standalone Mode is activated for an iNode from the Orchestrator, the iNode needs to be ALIVE for at least one minute for the change to take effect.
      14. If the public IP address of iNode changes, connection to the remote network, if any, will automatically disconnect and reconnect.
      15. To connect Edge iNode network(s) to Virtual iNode network(s), both Edge and Virtual iNodes must be at version 1820.y.z or later.
      16. The iNode CLI command to configure NTP server only allows you to specify IP addresses; does not allow you to specify FQDN for NTP server.
      17. The maxium size of the downloaded Service logs is limited to 10 MB.
      18. If the Default Destination is set to a remote network, you should configure public DNS servers as the DNS servers for your services.
      19. When using iNode CLI, If you configure a static IP address for the iNode Ethernet uplink interface but don’t configure a name server, iNode may become unreachable until you configure a name server.
      20. Representational Network can not be configured for static route to allow remote networks, unless there is a conflict.

      4.2. Known Problems

      1. Editing a Secret requires the Service to be restarted to take effect.
      2. Service addressing can be set only when adding the network and can not be changed later by editing the network.
      3. If the Default Destination is set to WAN Network, outbound traffic from the local network destined to Internet or LAN will not match any custom security policy applied to the local network.
      4. In the Dashboard the iNodes that are being rebooted are counted twice under ALIVE count as well as REBOOTING count. Once the reboot is complete, the count is correctly updated.
      5. When Edge iNode’s uplink is connected via mobile broadband and you want to change the IP address of iNode’s network 2 ethernet interface (eth1), it should not be in the same subnet as the uplink network.
      6. If no service log has been generated in the last 24 hours, the Service Logs window in the Orchestrator will not show any logs even if there are logs generated earlier.
      7. The Verizon mobile broadband uplink interface information displayed in the Orchestrator does not include Operator, APN, Band, and Signal quality. Also, sometimes the status of the interface is not updated properly.
      8. When using private registry to pull image for your Service, if the authentication to the private registry fails the Service will be stuck in UNKNOWN state. Please delete the Service, provide the correct credentials in the image pull secret, and add the Service again.
      9. When you edit a running Service and change its image, until the Service restarts after pulling the new image the iNode reports wrong status for the Service.
      10. When you try to view or download service logs, a 504 timeout error may be thrown if there are multiple services writing logs frequently and the iNode uplink connection is slow. This is typically temporary; please retry after some time.
      11. Metrics graph does not show any break, if iNode loses management connectivity for a moment.
      12. Metrics graph and interface traffic rate on iNode details page will take few minutes to display after provisioning the iNode.
      13. When you configure static route to TAN routed segment via Configured TAN Gateway, Default Destination routes are not installed on Edge iNode.
      14. When you configure Representational Network for Edge iNode’s Network, traffic from a segmented APP cloud is not routed to TAN.
      15. When you configure Representational Network for Edge iNode’s Network, traffic from APP cloud is not routed to Segmented TAN.
      16. Static routes to allow remote networks will not work if Static routes with Representational Network is configured.
      17. ioTium CLI login expires after idle session timeout; ioTium CLI throws 401 error unless user logs into the orchestrator using ioTium CLI again.
      18. When you modify network or add Custom Security Policy to a network using ioTium CLI, existing Static routes are removed.
      Was this article helpful?