Reference network architectures

Reference network architectures

Introduction

When it comes to the implementation of Crosser Node(s) into your infrastructure, the question is where it makes sense to implement and where you can access the required source/destination-systems. In many cases, this is easier said than done. Thanks to the flexibility of the Crosser solution and capabilities like Node-to-Node communication, you have plenty of options to remain compliant with security requirements and still take advantage of all Crosser features.This article will provide you with some ideas how customers have implemented Crosser Node(s) in different infrastructures.
Keep in mind that in all cases, the Node must be able to reach cloud.crosser.io via HTTPs port 443 in order to communicate.
Fore installation requirements of the Crosser Node, please see following article: https://support.crosser.io/portal/en/kb/articles/requirements#Hardware_requirements

Flat network

The probably easiest and simplest infrastructure that you can find is a single network. This is barely seen in industrial production sites or factories, but you might face this situation in a lab environment, or when your use case only requires you to interact with devices or services within your network.

The only firewall requirement in this setup is that the Node must be able to contact cloud.crosser.io via HTTPs port 443.

Infrastructure with DMZ network

More common are infrastructures with DMZ zones. In DMZs you usually face a bit more loosened network requirements and connectivity into at least two different network segments that do not have the possibility to communicate directly.
In infrastructures like this, the Node is often connected to two networks where one allows connectivity to sources and the other network which provides access to data destinations.
Beside the access to destination systems, also the network access to cloud.crosser.io is often only available from within these dedicated zones.


In this case, you need to make sure to open up the required communication protocols from the DMZ to the private network. Beside that, make sure that you can reach the public network as well from the DMZ so your Node can connect to cloud.crosser.io and potentially other external services.
The downside of this approach is that you must allow communication into your ‘private network’ from the DMZ. In many industrial environments, this is a no-go and will not be allowed since the guidelines often accept outbound traffic from the private network. Fortunately, there is also a solution to this which is explained next.

Infrastructure with network levels

If inbound connectivity to your data sources is restricted, you have to put a Crosser Node in the same network level in order to be able to connect to your required sources. Once you can connect to your data sources from that level, you might run into the limitation that you can not connect to your destination systems anymore from this network level. If that is the case, you can utilize the Node-to-Node communication concept to use a Node as some sort of Aggregator or Bridge to the outside world.

Keep in mind that in this concept the Node in the private network still needs access to cloud.crosser.io via HTTPs.

Infrastructure with distributed assets

When you have to deal with a setup where your Node(s) run on Edge Gateways or similar in distributed environments/assets, your main challenge is usually to get outbound connectivity to your services.
On the southbound-side, you usually do not find any firewall, hence the connectivity to sources is most likely easy to set up without any network configuration.

In this scenario, we highly recommend using protocols like HTTPs / REST to send out the payload data to your destination. Especially if your network connection to the outside world is not that reliable (ie. Cellular), protocols like MQTT and AMQP are not recommended.



    • Related Articles

    • Node to Node communication

      Introduction When talking about digitalization in the industry, security often comes up as one of the main concerns. Usually production environments are decoupled from other areas to prevent unauthorized actions. To realize this, a common practice is ...

    • Crosser Node 2.5.3

      Crosser Node 2.5.3 May 2022 Bugfix - Prevent Crash When Getting ChannelClosedExceptions When running remote sessions with unstable network connections the node host process could crash due to not handling a ChannelClosed exception in a proper way.

    • Using the Python Bridge module

      Introduction Crosser offers two ways to run Python code from within a flow: the IronPython and the Python Bridge modules. The Crosser flow engine is built in .NET and Python is not a native .NET language. The IronPython module uses a Python ...

    • Requirements

      Requirements Hardware requirements CPU: 64-bit x86 or 32 / 64 bit ARM RAM: Minimum 500MB free (in addition to OS and Docker requirements) Disk: Minimum 300MB free (in addition to OS and Docker requirements) Software requirements The Crosser node is ...

    • SDK version management, multiple accounts

      Crosser Cloud - SDK version management, multiple accounts January 5, 2022 Same email address with multiple accounts It is now possible to use the same email address to login to multiple accounts. If multiple accounts are associated with the same ...