The short answer
How to Assign IP Addresses on a Control Network
To assign IP addresses on a control network, choose a private range that will not collide with vendor defaults or home routers, give each site and each security zone its own /24 subnet, lay out fixed blocks inside every subnet for gateways, switches, controllers, I/O, instruments, servers, and laptops, assign static addresses to every device that takes part in control, record every address in an IP schedule with the device, MAC address, location, VLAN, and switch port, and verify with ping and the ARP table that no address is duplicated.
Key points
- Plan the whole system first; a network addressed one device at a time cannot be segmented or routed later.
- One /24 per zone per site. The second and third octets say where and what; the last octet says which.
- Static addresses on controllers, I/O, drives, instruments, and servers. No DHCP pool on a control VLAN.
- Avoid 192.168.0.0/24 and 192.168.1.0/24; they collide with vendor defaults, cellular modems, and VPN clients.
- The IP schedule is part of the drawings. An address that is not on the schedule does not exist.
- Verify with ping and ARP from inside the subnet; a duplicate address shows up as two MAC addresses answering.
What you need
- The list of sites, zones, and every network device with its role
- The existing addresses of anything already installed, from the device displays or a network scan
- Access to the switch and firewall configuration
- The programming software for each controller and a laptop with an Ethernet port
- A spreadsheet or the project network schedule template
- Label material for the devices and the drawings
Procedure
- 1
Inventory what exists
List every device that has or will have an address: controllers, I/O adapters, drives, instruments with Ethernet, switches, firewalls, radios, cellular modems, servers, HMIs, printers, cameras. Record the current address, mask, gateway, and MAC of anything already running. Read the address from the device itself, not from memory.
- 2
Choose the private range
Use the 10.0.0.0/8 range for anything larger than one panel. It gives 65,000 subnets and does not collide with the 192.168.x.x defaults used by vendor equipment, cellular modems, home routers, and VPN clients. Keep 192.168.x.x for temporary bench work and out-of-box device defaults only.
- 3
Assign a subnet per zone per site
Give each site a number and each security zone a number, and form the subnet as 10.SITE.ZONE.0/24. A plant with a control zone, a supervisory zone, and a management zone at site 5 uses 10.5.10.0, 10.5.20.0, and 10.5.99.0. Remote sites follow the same pattern with their own site number, so a site-to-site VPN can route without address translation.
- 4
Lay out fixed blocks inside every subnet
Reserve the same host ranges in every subnet, per the table below, so that the last octet identifies the device class anywhere in the system. A technician who sees 10.7.10.21 knows it is a controller at site 7 in the control zone without looking anything up.
- 5
Assign static addresses
Every controller, I/O adapter, drive, instrument, server, and switch gets a static address from its block. Set it in the device, set the mask to 255.255.255.0, and set the gateway only if the device must talk across subnets; a device with no gateway cannot be reached from another subnet, which is a feature for I/O and a fault for a server.
- 6
Handle the devices that insist on DHCP
A few devices ship with DHCP on and no way to set a static address until they get one. Use a DHCP reservation tied to the MAC on the management network for the first configuration, then set the static address. Do not leave a DHCP pool active on a control VLAN; an address that changes at lease renewal is an intermittent communication failure waiting to happen.
- 7
Set the switch and firewall interfaces
The firewall interface for each subnet takes .1, the gateway address. Switch management addresses go in the management subnet, not in the control subnet, so a switch is reachable only through the management VLAN.
- 8
Write the schedule
One row per address: address, hostname or tag, device model, MAC, location, VLAN, switch and port, and a note. Include the spare blocks so nobody invents an address. Put the schedule with the network drawing and revise both together.
- 9
Label
The address goes on the device label, on the network drawing, and in the switch port description. A controller whose address is visible on its label is diagnosed in seconds; one whose address is in a laptop somewhere is diagnosed in an hour.
- 10
Verify
From a laptop inside each subnet, ping every address on the schedule and confirm the ARP table shows one MAC per address. Ping every spare address and confirm nothing answers. Then check reachability across subnets only where the firewall rules intend it.
Block layout inside each /24
| Last octet | Use | Note |
|---|---|---|
| .1 | Gateway (firewall or router interface) | Same in every subnet |
| .2 to .9 | Switches and network infrastructure | Management addresses normally live in the management subnet; these are for switches that must be reachable locally |
| .10 to .49 | Controllers and PLC communication modules | Primary controller at .10 or .11, redundant partner adjacent |
| .50 to .99 | Remote I/O adapters and drives | In order of the drawing; adapter, then its drives |
| .100 to .149 | Instruments and analyzers with Ethernet | Match the loop number where possible |
| .150 to .199 | Servers, HMIs, historians, workstations | Redundant servers adjacent |
| .200 to .239 | Engineering laptops and temporary devices | Reserved addresses, not a pool |
| .240 to .254 | Spare | Never assigned without updating the schedule |
Checking for duplicates
A duplicate address is intermittent by nature: whichever device answered ARP last gets the traffic. Check from a laptop in the same subnet.
ping 10.5.10.21
arp -a | findstr 10.5.10.21
REM one line with one MAC is correct
REM ping the address, unplug the device you think it is, ping again
REM if it still answers, something else has the addressOn a managed switch, the MAC address table shows the port for each MAC. Two MACs claiming one address show up in the switch log as an IP conflict on some platforms, and always show up as two different ports answering the same address over time.
Verification
- Every device on the schedule answers ping from inside its subnet with one MAC in the ARP table.
- No spare or unassigned address answers.
- Cross-subnet traffic works only where a firewall rule permits it, and fails everywhere else.
- The controller, HMI, historian, and I/O all reconnected after any readdressing.
- The schedule, the network drawing, the device labels, and the switch port descriptions agree.
Frequently asked questions
- Why not just use 192.168.1.x like the vendor defaults?
- Because everything else uses it too. A cellular modem, a laptop on a home network over VPN, a vendor tool, and a new device out of the box all default into 192.168.0.x or 192.168.1.x, and every one of them collides with a control network that lives there. A 10.x.x.x plan avoids every collision and gives room to number sites and zones.
- Can two remote sites use the same subnet?
- Only if they will never be connected. Two sites at 192.168.1.0/24 cannot be joined by a VPN or a central SCADA without address translation, which is confusing to troubleshoot. Give every site its own subnet from the start; it costs nothing.
- Should the gateway be set on every device?
- Set it where the device must communicate outside its subnet: servers, HMIs, controllers that report to a central SCADA. Leave it blank on remote I/O adapters, drives, and instruments that only talk to the local controller; without a gateway they cannot be reached from, or reach, another subnet even if a firewall rule is wrong.
- What about IPv6?
- Turn it off on control devices and workstations where the option exists, and do not plan around it. Control equipment overwhelmingly uses IPv4, and an IPv6 stack left enabled on a workstation is an unmanaged path that no firewall rule was written for.
Related topics
- How to Configure VLANs on a Control NetworkTurn a zone plan into switch configuration: a VLAN per zone with its own subnet, access ports for devices, tagged trunks between switches, a native VLAN that carries nothing, a separate management VLAN, and routing between VLANs only through the firewall.
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Firewall Rule DesignWriting the rule set for a control network boundary: default deny, one rule per conduit with its reason, hosts not subnets, protocol and port and function, direction and initiator, logging on every rule, and the review that removes forgotten rules.
- How to Troubleshoot an Ethernet ConnectionWork an Ethernet problem one layer at a time: link light and cable, then speed, duplex, and VLAN on the switch port, then address, mask, and gateway, then the application port through the firewall. Each layer has a one-minute test that rules it in or out.
- EtherNet/IPHow EtherNet/IP moves control data: CIP over standard Ethernet, implicit I/O connections on a requested packet interval, explicit messaging, producer and consumer tags, and what the network has to provide.
- How to Test FiberTest a fiber link at acceptance and at fault: inspect and clean every connector, measure end-to-end loss with a light source and power meter in both directions and at the operating wavelengths, and record everything with the fiber schedule.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.