Intermittent Modbus Timeouts After a Wireless Bridge
At a 60 MW solar site, 42 string inverters and three trackers communicate over Modbus TCP to a SCADA server. The OT LAN is one flat VLAN, 10.20.8.0/24, with static addresses. After a wireless bridge was added for a maintenance tablet, the SCADA server logs Modbus timeouts every 35 to 45 minutes, each lasting 20 to 90 seconds. The site electrician found two devices answering for 10.20.8.67: a tracker controller and the new tablet. The switch is unmanaged, and no one has a current IP register. The vendor says the PLC scan interval is 500 ms and the SCADA timeout is 3 seconds. Operations wants to change the SCADA timeout to 10 seconds and move on. The site has a four-hour maintenance window tonight and no spare managed switch on site.
1. What does the 10.20.8.0/24 subnet tell you about the size and behavior of this broadcast domain?
Read the worked answer
A /24 provides 256 addresses. Two are reserved for the network and broadcast addresses, leaving 254 usable host addresses. All 42 inverters, three trackers, the SCADA server, the tablet, and any other devices are in one broadcast domain unless there is hidden VLAN separation.
That matters because a single flat /24 means every ARP request and broadcast is delivered to every device, and any duplicate address can affect the whole segment. With 46 or more devices, the site has already consumed a meaningful share of the usable range, and without an IP register the risk of overlap is high. The correct conclusion is not that /24 is too small numerically; it is that the site lacks address management and segmentation. A /26 would provide 62 usable addresses and could isolate a cell or area, but the immediate problem is the duplicate 10.20.8.67 and the unmanaged switch, not subnet exhaustion.
2. Diagnose the likely cause of the timeouts and evaluate the proposal to raise the SCADA timeout to 10 seconds.
Read the worked answer
The duplicate address is the strongest lead. Two devices answering for 10.20.8.67 will cause ARP cache instability: the SCADA server may send requests to the tracker controller and receive replies from the tablet, or the upstream switch may learn the MAC address on different ports. Modbus TCP sessions can then reset, time out, or receive responses from the wrong device. The intermittent 35-to-45-minute pattern fits a wireless client rejoining, ARP refresh, or roaming event rather than a steady overload.
Raising the timeout from 3 to 10 seconds treats the symptom. It may reduce logged failures, but it increases the time before SCADA detects a real communications loss and can mask a duplicate-IP or wireless instability problem. It also does not fix wrong-device responses.
The immediate action is to assign the tablet an unused, documented address outside the controller range, clear the SCADA ARP cache, and verify that only one MAC answers for the old address. Use the maintenance window to document every static address and check for other duplicates. Do not change the scan interval or timeout until the duplicate is removed.
3. What should be done tonight, and what should be planned for the next 30 days?
Read the worked answer
Tonight, with no spare managed switch, focus on safe, reversible fixes:
- Give the tablet a new static address from a documented maintenance range, for example 10.20.8.200, after confirming it is unused by ARP and ping.
- Clear the ARP cache on the SCADA server and affected controllers, or reboot only the communications interfaces if the vendor permits.
- Confirm with a packet capture that 10.20.8.67 resolves to one MAC and that Modbus reads succeed through at least three scan cycles.
- Record the change and leave the SCADA timeout at 3 seconds unless the vendor explicitly approves otherwise.
Within 30 days, replace the unmanaged switch with a managed switch and create separate VLANs for inverters, trackers, and SCADA/engineering. Build an IP address register and reserve static ranges. Enable port security, ARP inspection where supported, and monitoring for duplicate IP and MAC flapping. The judgment is to fix the addressing and segmentation first; changing protocol timers is not a network defense.