Just want to clarify interface (NIC) binding options with Ignition…
If I want to utilize three separate subnets for Ignition comms as follows:
Subnet A: Server to server (Redundancy) comms.
Subnet B: OPC to PLC comms.
Subnet C: Gateway to Client comms.
I would use the Network Bind Interface option under redundancy config to set up the Subnet A binding.
I would use the Server Endpoint address under OPC-UA settings for Subnet B binding.
Gateway comms can’t be “bound” to an interface, but I would could shut off Autodetect HTTP Address and specify my Subnet C interface to advertise gateway availability only on the Subnet C NIC.
Also asking… is it correct to say we can’t currently bind the mobile interface to a NIC separate of the gateway?
And also - I’m no network engineer, so forgive me… what would be the advantages/disadvantages of using separate NIC bindings rather than putting a hardware router in front of a single interface and routing these subnets in?
There’s no real “one answer fit’s all” to your network question. You could go either way, or anywhere in between. Seek IT support if they have the equipment and expertise - this is their domain.
As far as good practice goes, you might consider the 3 interface approach. It’s just the most separate, which is good for security, but really just tends to lead to a much cleaner design. You may have business requirements for specific nodes besides your Ignition Gateway to be able to inter-communicate between A/B/C. In this case a savvy IT department would route specific types of traffic in some organized way through known “chokepoints” - router(s), firewalls, IDS systems, etc. They might even create a permanent VPN, encryped GRE tunnel, etc. In the case one step down on the desirability level, all equipment (A/B/C) may be connected to the same switches, but on different subnets and VLANs. Inter-VLAN routing can allow specific devices to communicate with each other on different subnets by going through a router or layer 3 switch. There are varying degrees of loose versus secure setups. About the worst way to go would be to use 1 set of interconnected switches that everything is plugged into and 1 network adapter on your Ignition gateway with multiple IP addresses bound to it. Hacky situations like this can lead to serious accidental problems and be very difficult to administer.
It may make sense for your gateway to have 2 physical interfaces, 1 dedicated to the PLC network and the other used for both server and client communication. Perhaps you have a router feeding you the traffic for your PC networks, perhaps not.
The router and 1 NIC in the Ignition gateway could work for you. Ideally, then, the router has 3 physical interfaces to each of the networks. It becomes a point of failure for the gateway, which may be acceptable. The speed of that link is also a potential bottleneck for all communication functions to the Ignition gateway. If any of the nodes on different networks are connecting to the same switches (meaning the router could get away with only 1 or 2 interfaces), then hopefully they’re at least on separate VLANs. Segmenting traffic is the whole reason you decided to go with the A/B/C scheme in the first place.
Then again in a REALLY HIGH security setting, it would probably be the most defensible for some kind of trusted gateway setup (router and other equipment with those 3 or more physical interfaces) passing all the traffic to the Ignition gateway. This way could make it harder for a compromised Ignition gateway to have open access to all 3 networks. An attacker would more likely have to break into the trusted gateway setup.
Probably not the most satisfactory answer, but hopefully it painted a picture of some options. This methodology extends to remote databases and remote client access. Your network architect/admin should be able to go to town with your clearly defined higher level requirements.