Network Automation in Industrial Environments

IT and OT networks are different

In a factory or a mine, the network carries more than email and web traffic. Controllers, HMIs, cameras, sensors and safety-related systems depend on it. Network automation in such an environment has to take these differences seriously rather than copying office IT practices one to one.

Aspect	IT network	OT network
Primary priority	Confidentiality and data integrity	Availability and process safety
Equipment lifetime	A few years	Often much longer
Change windows	Relatively flexible	Tied to planned shutdowns
Traffic	Diverse and bursty	Predictable, sometimes latency-sensitive
Physical environment	Server room	Dust, vibration, temperature, humidity

The practical consequence: in OT, every automated change must be predictable, reversible and coordinated with operations. Automation is a tool for consistency, not a license to change things more often.

Industrial networks also carry their own protocols and topologies. Fieldbus-over-Ethernet protocols such as PROFINET, EtherNet/IP or Modbus TCP may react sensitively to latency, multicast storms or a switch restarting at the wrong moment. Ring topologies with redundancy protocols are common on production lines and in mines, and a careless change to spanning tree or ring settings can interrupt a whole segment. Before automating anything, it is worth knowing exactly which devices are process-critical, who owns them and which vendor restrictions apply, for example firmware versions approved by a machine supplier.

Segmentation: zones and conduits

The IEC 62443 series introduces the concepts of zones and conduits. A zone groups assets with similar security requirements, for example one production line or one pumping station. A conduit is the controlled communication path between zones, through which only the traffic that is actually needed may pass.

• Separate the office network from control networks, with an intermediate layer (an industrial DMZ) for data servers and remote access.
• Use VLANs and firewall rules to restrict communication between zones.
• Document which system talks to which system, and over which protocol.

Automation adds real value here. Firewall rules and VLAN definitions can be generated from one structured source, so segmentation stays consistent across all sites instead of slowly drifting through manual edits.

Configuration management, backups and templating

The first and lowest-risk automation step is regular configuration backup of every device. A scheduled job connects to each device, retrieves the configuration and stores it in a versioned repository such as Git. Every change then becomes visible and comparable, which is invaluable when troubleshooting after an incident.

Source of truth

The next step is a source of truth: a structured inventory of devices, addresses, VLANs and site roles. Configurations are generated from this data with templates instead of being edited by hand on each device. The inventory also answers basic questions quickly, such as which firmware runs where.

Templating

With a template engine such as Jinja2, you can write one template for a "production line access switch" and vary only the site-specific variables. Tools such as Ansible, Netmiko or NAPALM push these configurations to devices or compare them with the running state to detect deviations.

Drift detection

In practice, configuration drift is often the first real benefit. A nightly comparison between the intended configuration and the actual running state reveals undocumented changes, temporary test settings that were never removed, or a device that was replaced with factory defaults. These findings can be reported first and corrected later in a planned window, which keeps the process transparent for operations staff.

Scripting on MikroTik RouterOS and Cisco IOS

MikroTik RouterOS

RouterOS includes its own scripting language, a scheduler and, in recent versions, a REST API. A text export is created with a command such as /export file=site-a-config, and a binary backup with /system backup save name=site-a. The text export is better suited for diffing and version control, while the binary backup is useful for restoring the same device.

Cisco IOS

On Cisco IOS, an automation tool typically reads show running-config and show version over SSH. The archive feature can keep configuration versions on the device, and on many releases configure replace allows returning to a known-good configuration.

On both platforms the key principle is the same: read the current state before changing anything, show the difference, apply the change, then verify the result. Scripts should fail safely and stop when something unexpected happens.

Monitoring and remote site connectivity

• SNMP: interface status, CPU load, temperature and traffic; preferably SNMPv3 with authentication and encryption.
• Syslog: central collection of events such as link failures, logins and configuration changes.
• NetFlow/IPFIX: visibility into who talks to whom and how much, which helps detect unexpected traffic between zones.

Network monitoring data can be shown next to process data, for example on a ThingsBoard dashboard, so that network problems and equipment stops can be correlated.

Good alerting matters more than the volume of collected data. Thresholds should reflect the normal behavior of each segment, alerts should go to the people who can act on them, and recurring false alarms should be fixed rather than ignored. A baseline recorded during normal operation makes it much easier to spot changes later.

Remote sites such as mines, pumping stations or substations are commonly connected with IPsec or WireGuard VPN tunnels. Tunnel configuration, key rotation and health checks lend themselves well to automation and make consistent settings across sites far easier to maintain.

Change management, risks and rollout

Automation increases speed, and it increases the speed of mistakes too. A faulty template can disconnect several sites at once. These measures reduce that risk:

• Peer review of every change before execution.
• Dry runs that show the exact differences.
• Staged application: one device, then one site, then the rest.
• Coordination with operations and execution in agreed maintenance windows.
• A rollback plan and separate out-of-band management access for critical equipment.
• Protection of the credentials and access rights of the automation system itself, which is a sensitive asset.

A sensible rollout path:

1. Device inventory and zone mapping.
2. Automated, versioned configuration backups.
3. Central monitoring with SNMP and syslog.
4. Compliance checks against templates, without applying changes.
5. Automation of repetitive, low-risk changes.
6. Gradual extension to more complex changes.

Conclusion

Network automation in industrial environments works when it respects OT priorities: visibility and backups first, then compliance, and only then controlled automated change. More information is available on the network automation and industrial monitoring service pages. To discuss the network of a specific site, please use the contact page.