--- title: Capturing and Analyzing OT Network Traffic Workflow description: Explore effective strategies for capturing and analyzing OT network traffic with Copper TAPs, IOTA, and Wireshark to enhance visibility and performance. image: https://insights.profitap.com/hubfs/Sc-Flowchart-with-lines-blue-04.jpg --- [![Profitap](https://insights.profitap.com/hubfs/profitap-logo-white-rev1.png "Profitap")](https://www.profitap.com) - [Solutions](https://www.profitap.com/solutions/) - Products - Resources - Company - - - - # Profitap Blog ### Recent Posts ### Categories - [Network Monitoring (77)](https://insights.profitap.com/topic/network-monitoring) - [Insights (38)](https://insights.profitap.com/topic/insights) - [IOTA (32)](https://insights.profitap.com/topic/iota) - [Copper TAPs (31)](https://insights.profitap.com/topic/copper-taps) - [ProfiShark (24)](https://insights.profitap.com/topic/profishark) - [Fiber TAPs (23)](https://insights.profitap.com/topic/fiber-taps) - [Data Center (17)](https://insights.profitap.com/topic/data-center) - [Network Packet Brokers (14)](https://insights.profitap.com/topic/network-packet-brokers) - [Network Visibility and Cybersecurity (14)](https://insights.profitap.com/topic/network-visibility-and-cybersecurity) - [Network Security (13)](https://insights.profitap.com/topic/network-security) - [News (13)](https://insights.profitap.com/topic/news) - [Product Update (11)](https://insights.profitap.com/topic/product-update) - [Field Service (10)](https://insights.profitap.com/topic/field-service) - [Case Study (3)](https://insights.profitap.com/topic/case-study) - [OIDA (3)](https://insights.profitap.com/topic/oida) - [Events (2)](https://insights.profitap.com/topic/events) - [Heroes of Packet Analysis (2)](https://insights.profitap.com/topic/heroes-of-packet-analysis) - [Solutions for Government and Defense (2)](https://insights.profitap.com/topic/solutions-for-government-and-defense) - [Power and Utilities Solutions (1)](https://insights.profitap.com/topic/power-and-utilities-solutions) - [Solutions for Logistics (1)](https://insights.profitap.com/topic/solutions-for-logistics) - [cloud (1)](https://insights.profitap.com/topic/cloud) see all ### Archives - [September 2026 (1)](https://insights.profitap.com/archive/2026/09) - [August 2026 (4)](https://insights.profitap.com/archive/2026/08) - [July 2026 (1)](https://insights.profitap.com/archive/2026/07) - [June 2026 (1)](https://insights.profitap.com/archive/2026/06) - [May 2026 (3)](https://insights.profitap.com/archive/2026/05) - [April 2026 (2)](https://insights.profitap.com/archive/2026/04) - [March 2026 (3)](https://insights.profitap.com/archive/2026/03) - [February 2026 (3)](https://insights.profitap.com/archive/2026/02) - [January 2026 (3)](https://insights.profitap.com/archive/2026/01) - [November 2025 (1)](https://insights.profitap.com/archive/2025/11) - [October 2025 (4)](https://insights.profitap.com/archive/2025/10) - [September 2025 (1)](https://insights.profitap.com/archive/2025/09) - [August 2025 (2)](https://insights.profitap.com/archive/2025/08) - [July 2025 (3)](https://insights.profitap.com/archive/2025/07) - [May 2025 (1)](https://insights.profitap.com/archive/2025/05) - [March 2025 (2)](https://insights.profitap.com/archive/2025/03) - [February 2025 (3)](https://insights.profitap.com/archive/2025/02) - [January 2025 (2)](https://insights.profitap.com/archive/2025/01) - [December 2024 (1)](https://insights.profitap.com/archive/2024/12) - [November 2024 (2)](https://insights.profitap.com/archive/2024/11) - [October 2024 (1)](https://insights.profitap.com/archive/2024/10) - [September 2024 (3)](https://insights.profitap.com/archive/2024/09) - [August 2024 (8)](https://insights.profitap.com/archive/2024/08) - [July 2024 (7)](https://insights.profitap.com/archive/2024/07) - [June 2024 (1)](https://insights.profitap.com/archive/2024/06) - [May 2024 (6)](https://insights.profitap.com/archive/2024/05) - [April 2024 (1)](https://insights.profitap.com/archive/2024/04) - [March 2024 (3)](https://insights.profitap.com/archive/2024/03) - [February 2024 (2)](https://insights.profitap.com/archive/2024/02) - [January 2024 (1)](https://insights.profitap.com/archive/2024/01) - [December 2023 (2)](https://insights.profitap.com/archive/2023/12) - [November 2023 (1)](https://insights.profitap.com/archive/2023/11) - [July 2023 (1)](https://insights.profitap.com/archive/2023/07) - [June 2023 (1)](https://insights.profitap.com/archive/2023/06) - [April 2023 (1)](https://insights.profitap.com/archive/2023/04) - [February 2023 (1)](https://insights.profitap.com/archive/2023/02) - [January 2023 (1)](https://insights.profitap.com/archive/2023/01) - [December 2022 (1)](https://insights.profitap.com/archive/2022/12) - [October 2022 (1)](https://insights.profitap.com/archive/2022/10) - [April 2022 (1)](https://insights.profitap.com/archive/2022/04) - [March 2022 (1)](https://insights.profitap.com/archive/2022/03) - [February 2022 (2)](https://insights.profitap.com/archive/2022/02) - [January 2022 (1)](https://insights.profitap.com/archive/2022/01) - [December 2021 (2)](https://insights.profitap.com/archive/2021/12) - [October 2021 (2)](https://insights.profitap.com/archive/2021/10) - [September 2021 (1)](https://insights.profitap.com/archive/2021/09) - [August 2021 (1)](https://insights.profitap.com/archive/2021/08) - [June 2021 (1)](https://insights.profitap.com/archive/2021/06) - [May 2021 (1)](https://insights.profitap.com/archive/2021/05) - [March 2021 (2)](https://insights.profitap.com/archive/2021/03) - [February 2021 (1)](https://insights.profitap.com/archive/2021/02) - [January 2021 (2)](https://insights.profitap.com/archive/2021/01) - [November 2020 (1)](https://insights.profitap.com/archive/2020/11) - [September 2020 (1)](https://insights.profitap.com/archive/2020/09) - [August 2020 (1)](https://insights.profitap.com/archive/2020/08) - [July 2020 (2)](https://insights.profitap.com/archive/2020/07) - [June 2020 (2)](https://insights.profitap.com/archive/2020/06) - [April 2020 (2)](https://insights.profitap.com/archive/2020/04) - [March 2020 (2)](https://insights.profitap.com/archive/2020/03) - [February 2020 (4)](https://insights.profitap.com/archive/2020/02) - [September 2019 (1)](https://insights.profitap.com/archive/2019/09) - [August 2019 (1)](https://insights.profitap.com/archive/2019/08) - [May 2019 (2)](https://insights.profitap.com/archive/2019/05) - [April 2019 (1)](https://insights.profitap.com/archive/2019/04) - [March 2019 (1)](https://insights.profitap.com/archive/2019/03) - [February 2019 (1)](https://insights.profitap.com/archive/2019/02) - [December 2018 (2)](https://insights.profitap.com/archive/2018/12) - [October 2018 (2)](https://insights.profitap.com/archive/2018/10) - [August 2018 (1)](https://insights.profitap.com/archive/2018/08) - [July 2018 (2)](https://insights.profitap.com/archive/2018/07) - [June 2018 (1)](https://insights.profitap.com/archive/2018/06) - [May 2018 (4)](https://insights.profitap.com/archive/2018/05) - [April 2018 (1)](https://insights.profitap.com/archive/2018/04) - [March 2018 (2)](https://insights.profitap.com/archive/2018/03) - [February 2018 (1)](https://insights.profitap.com/archive/2018/02) - [January 2018 (1)](https://insights.profitap.com/archive/2018/01) - [December 2017 (1)](https://insights.profitap.com/archive/2017/12) - [November 2017 (2)](https://insights.profitap.com/archive/2017/11) - [October 2017 (1)](https://insights.profitap.com/archive/2017/10) - [July 2017 (1)](https://insights.profitap.com/archive/2017/07) - [May 2017 (2)](https://insights.profitap.com/archive/2017/05) - [February 2016 (1)](https://insights.profitap.com/archive/2016/02) - [December 2015 (2)](https://insights.profitap.com/archive/2015/12) - [June 2015 (2)](https://insights.profitap.com/archive/2015/06) - [May 2015 (3)](https://insights.profitap.com/archive/2015/05) see all ### Stay up to date [Follow @Profitap](https://twitter.com/Profitap) [Return to Blog](https://insights.profitap.com/) # Capturing and Analyzing OT Network Traffic Workflow - [Tweet](https://twitter.com/share) *A Practical Guide with Copper TAPs, IOTA, and Wireshark* ### **Introduction** Operational Technology networks have always been built around one priority: keeping the process running. In IT, a brief outage is an inconvenience. On the plant floor, a disruption can mean lost production, damaged equipment, or hours of recovery work. As OT networks grow more complex and converge with IT infrastructure, reliable non-intrusive visibility into what is actually happening on the wire has become a day-to-day necessity. You need it for tracking down intermittent errors, confirming that devices behave as configured, monitoring long-term network health, and catching performance degradation before it turns into a failure. The protocols running on these networks are not uniform. Some are hard real-time: they operate on fixed, deterministic schedules with microsecond-level cycle times, and any deviation is a fault condition. Profinet IRT and TSN with time-aware scheduling fall into this category. Others are soft real-time, where timing is bounded but the system tolerates some variation without failing. Modbus TCP and Profinet RT are typical examples. That distinction has direct consequences for how and where you capture traffic, what hardware you use, and what the resulting data actually tells you. This article walks through a practical capture and analysis workflow built around Profitap Copper TAPs, the IOTA traffic capture and analysis appliance, the ProfiShark capture device, and Wireshark. We cover three protocol families that span the current range of OT deployments: Modbus TCP, Profinet RT and IRT, and TSN. ![undefined-Aug-17-2026-01-08-02-7374-PM](https://insights.profitap.com/hs-fs/hubfs/undefined-Aug-17-2026-01-08-02-7374-PM.png?width=770&height=438&name=undefined-Aug-17-2026-01-08-02-7374-PM.png) ## **2. Capture Approach: TAPs vs. SPAN Ports** ### **2.1 Why Not a SPAN Port?** The usual alternative to a dedicated tap is a SPAN port, a switch feature that mirrors traffic from one or more ports to a designated monitoring port. In IT environments, this is often the path of least resistance. In OT, it usually is not a viable option, and where it still gets used, it tends to be a costly one. On switched networks, configuring a SPAN port means reconfiguring the switch. In a production environment, that means stopping the machine, which usually requires a maintenance window. On top of the scheduling overhead, SPAN adds processing load to the switch itself, and in a hard real-time context, that load is a real concern.![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-24-01-9820-PM.png?width=400&height=285&name=undefined-Jun-30-2026-12-24-01-9820-PM.png) There is a deeper problem, too: switches rarely operate deterministically. A SPAN port is designed to copy all (or most) packets from a predefined port. It is built to reproduce the data, not the network's timing behavior. So precise, predictable time measurements through a SPAN port are not achievable, and you end up with significant variance in your measured values. In cases where timing is the actual issue, for example, CAM synchronization of drives, this often masks the real root cause or sends the investigation off in the wrong direction. The partial exception is switches used in TSN and time-synchronized networks. They understand timing to a degree, but that understanding applies to normal network operation, not necessarily to the SPAN copy mechanism. A special variety of SPAN port shows up in hubbed networks. These do not use a switch at all but rather 10 Mbit/100 Mbit network hubs. Ethernet Powerlink, for instance, runs on a shared-medium model in which every device on the segment sees all traffic. Any open port is effectively a free monitoring point, so you can treat it as a non-configurable SPAN port (though not in the sense of the original specification). The catch is placement. Timing and propagation delay matter in these environments, so where you connect your monitoring equipment changes what you observe and how accurately it reflects the timing at other points in the network. Given all of this, SPAN should be treated as a fallback, not a first choice. The preferred approach is a dedicated TAP.   ### **2.2 Copper TAPs** A Copper TAP sits inline on the cable between two devices and presents the full-duplex traffic, both directions at once, to a monitoring port, without injecting any frames into the live link. From the network's point of view, nothing has changed. From the monitoring point of view, you have complete, unfiltered access to everything on that link. One detail that often gets glossed over: TAPs do introduce latency. The extra cable length, the physical signal path through the TAP, and the connector interfaces all add a small but measurable delay. For soft real-time protocols, that is generally inconsequential. For hard real-time protocols, it can be the difference between a network that runs and one that faults. Choosing the right TAP for the line speed and timing budget matters, and the protocol sections below cover this in detail. The "no fingerprint" quality of a passive TAP is genuine: it generates no frames, and no MAC address appears on the network. But the TAP is physically present in the cable plant, and that physical presence, specifically its added delay, is detectable by any protocol that measures network characteristics at startup. Copper TAPs come in different line speeds, and in OT, that distinction matters. Most production networks today still run at 100 Mbit/s; IRT is a prominent example. Migration to 1 Gbit/s is happening but slowly, and anything beyond 1 Gbit/s is not yet realistic for most plant floors. A TAP behaves differently at 100 Mbit/s than at 1 Gbit/s, both in the latency it adds and in how that latency interacts with the timing requirements of whatever protocol is on the link.![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-23-59-6231-PM.png?width=400&height=306&name=undefined-Jun-30-2026-12-23-59-6231-PM.png) If the lowest possible latency during analysis is a hard requirement, because of the application or the protocol the machine uses, and the machine runs on a 100 Mbit/s network (Profinet IRT being the obvious case), then use a pure 100 Mbit Copper TAP such as the C1D-100 rather than a Gigabit Copper TAP. The 100 Mbit/s model has a second benefit: it is purely passive, so there is no handover or switchover delay on power-on or power-off. A useful question to ask when planning a capture: Are you measuring time or measuring throughput? A Copper TAP faithfully reproduces the on-wire timing of every frame, so it works equally well for latency and jitter analysis as for throughput monitoring. These are two different diagnostic jobs. Timing problems and capacity problems call for different analysis approaches, and knowing which one you are chasing shapes how you configure the capture and what you look for in the results.   ### **2.3 IOTA** IOTA is a portable, self-contained capture and analysis appliance built for exactly the kind of in-the-field diagnostic work OT environments demand. It connects directly to the monitoring port of a Copper TAP, records both directions at line rate, and applies 9-nanosecond hardware timestamping to every frame. That timestamp precision is what makes timing and delay analysis meaningful in the first place. Software timestamps from a general-purpose OS add jitter of their own, and that jitter would swamp the measurements you are trying to take. IOTA can also be used directly as an inline capture device instead of the Copper TAP, provided the added inline latency is acceptable (more on that below). Worth noting in that case: there is a switch-over time during power loss, which can cause unwanted machine behavior such as a standstill or shutoff. That has to be accounted for when deploying IOTA this way.![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-24-01-0284-PM.png?width=400&height=259&name=undefined-Jun-30-2026-12-24-01-0284-PM.png) Beyond raw capture, IOTA provides built-in protocol analysis for industrial protocols, local storage for long captures, and remote access, so analysis does not require a laptop physically attached on the production floor. For many diagnostic tasks, IOTA's on-board analysis is enough on its own, with no export to Wireshark needed. > **Two IOTA deployment modes**  > > ![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-24-00-4318-PM.png?width=800&height=328&name=undefined-Jun-30-2026-12-24-00-4318-PM.png) ### **2.4 Network Configuration and the TAP** Every industrial protocol goes through a startup phase. The details differ, but the purpose is consistent. The network is scanned for attached devices; each device's configuration is verified; network characteristics such as cable lengths, switch delays, and propagation times are measured and validated; and the findings are checked against a preconfigured model. This phase also confirms that every device runs under the same configuration and application logic: I/O mappings, parameter sets, cycle times, and expected topology. A mismatch between what is configured and what is measured is a fault, not a warning. The network will not run.![protocol strickness profitap Sep 17, 2026, 12\_01\_50 PM-1](https://insights.profitap.com/hs-fs/hubfs/protocol%20strickness%20profitap%20Sep%2017%2c%202026%2c%2012_01_50%20PM-1.png?width=400&height=400&name=protocol%20strickness%20profitap%20Sep%2017%2c%202026%2c%2012_01_50%20PM-1.png) Modbus TCP handles this loosely; timeouts and retry counts define acceptable response behavior. Profinet RT and IRT handle it rigorously; the project file defines the expected topology in detail, and the devices verify it at startup. TSN handles it continuously; the network measures worst-case latency paths and recalculates its guarantees as conditions change. The implication for monitoring hardware is straightforward. A Copper TAP inserted after commissioning changes the physical characteristics of the network measured against. How much that matters depends on the protocol and its tolerance for deviation. For soft real-time protocols, it is rarely a problem. For hard real-time protocols, it can stop the network from starting at all. This single constraint drives the hardware and method decisions in every protocol section that follows. --- ## **3. Protocol Deep Dives** ### **3.1 Modbus TCP** Modbus TCP is one of the oldest and most widely deployed protocols in industrial automation. It is a straightforward request/response protocol over TCP, usually on port 502, in a master/slave model where a SCADA server or HMI polls one or more PLCs or field devices at regular intervals. It is soft real-time: poll cycles run from milliseconds to seconds, and the system tolerates variation in response timing within configurable limits. From a capture standpoint, Modbus TCP is the least demanding of the three protocols here. Startup and configuration are handled implicitly through TCP connection setup and the application's own poll logic; there is no topology measurement for a TAP to disturb. A standard Copper TAP placed between the master and any slave gives complete, clean visibility with no risk to the running system. IOTA's built-in Modbus TCP analysis covers the most common diagnostic needs without a Wireshark export: function code decoding, response code parsing, transaction ID matching to correlate requests with responses, and request-to-response timing. For most field diagnostics, such as checking whether a device responds correctly, seeing what a master is actually requesting, or spotting exception responses, that is enough. When you need to dig deeper, export the capture to Wireshark and apply the Modbus display filter for the full payload: coil and register values, individual bit and word reads, and the complete sequence of transactions over time. Sorting by response time or filtering for exception responses narrows down intermittent issues that never surface in higher-level diagnostics. > **Wireshark, Modbus TCP capture.** Wireshark capture filtered with modbus, showing a request/response pair with the function code and transaction ID highlighted. ![Wireshark screenshhot from Roland Knall](https://insights.profitap.com/hs-fs/hubfs/Wireshark%20screenshhot%20from%20Roland%20Knall.png?width=1624&height=1006&name=Wireshark%20screenshhot%20from%20Roland%20Knall.png) ### **3.2 Profinet RT and IRT** Profinet is the dominant industrial Ethernet standard in European automation, and it comes in two variants with very different characteristics. Profinet RT (Real-Time) uses standard Ethernet frames for cyclic data exchange. It is soft real-time: cycle times are in the low milliseconds, and although timing matters, there is enough tolerance that a standard Copper TAP poses no problem. A TAP on a Profinet RT link gives clean access to cyclic data frames, device discovery (DCP), and any alarms or diagnostic messages without affecting network operation. Profinet IRT (Isochronous Real-Time) is another matter entirely. IRT reaches sub-millisecond deterministic cycle times through hardware-level synchronization, which requires FPGA-based switching and precise clock distribution across every device. It is hard real-time, and the startup phase shows it. During commissioning, every device measures the actual cable lengths and switch delays in the topology and compares them against the parameters in the engineering project. The network only goes operational if the measured topology matches the configured model within tight tolerances. Any deviation, including the delay added by a Copper TAP inserted after commissioning, can fault the network at startup. The specific impact depends on the TAP and the link speed: - **100M Copper TAP (fully passive):** Adds a small amount of latency (roughly the equivalent of an extra 5–10 cm of cable) and is the better choice for IRT. It is also a purely passive solution. 1G analysis hardware still works here, connecting to the monitoring side of the TAP without issue. [https://www.profitap.com/industrial-fast-ethernet-copper-tap/](https://www.profitap.com/industrial-fast-ethernet-copper-tap/) - **1G Copper TAP:** Adds roughly 480 ns of latency on 1 Gbit/s links, and over 780 ns on 100 Mbit/s links. Since IRT networks are predominantly 100 Mbit/s, the added delay frequently pushes the measured topology outside the project's configured tolerances. [https://www.profitap.com/industrial-gigabit-copper-tap/](https://www.profitap.com/industrial-gigabit-copper-tap/)   **Mitigation by design:** Profinet IRT projects let engineers configure permitted delay margins per network segment. If monitoring access is anticipated up front, those margins can be set wide enough to absorb a TAP's latency. The measured topology then lands inside the allowed window, and the network runs normally. This is the cleanest solution, but it takes a deliberate decision and a change to the machine configuration before deployment. Retrofitting it onto a running production system means taking the machine offline to modify the project. Where that is not feasible, and no SPAN port already exists in the switch infrastructure, non-intrusive capture on an IRT network is not possible without modifying the project. Where capture is possible, IOTA's 9-nanosecond timestamping makes the results genuinely useful. IRT cycle times range from 250 µs to 1 ms, confirming that frames arrive inside their scheduled windows, spotting drift, or detecting gradual timing degradation all need timestamp resolution that general-purpose tools cannot deliver. One thing to keep in mind: the timestamp IOTA generates is not the timestamp at the moment of capture on the TAP, but the moment the frame was received on the IOTA side. The big advantage over a SPAN port is that there is no store-and-forward or buffering, so the latency is deterministic and, in most cases, can be ignored. In Wireshark, Profinet IRT traffic is visible through the pn\_rt, pn\_dcp, and pn\_rpc display filters. IOPS and IOCS status bits in the cyclic frames show the health of individual I/O channels. Alarm and diagnostic frames carry device-level fault information. Adding a delta time column makes cycle jitter immediately visible. > **IRT timing window with and without TAP.** A timeline showing an IRT cycle (e.g. 250 µs) with the scheduled transmission window. > ![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-23-59-3228-PM.png?width=800&height=242&name=undefined-Jun-30-2026-12-23-59-3228-PM.png) ### **3.3 TSN (Time-Sensitive Networking)** Time-Sensitive Networking is an evolving suite of IEEE 802.1 standards that brings deterministic, guaranteed-latency delivery to standard Ethernet. The core mechanisms include 802.1AS for generalized Precision Time Protocol (gPTP) clock synchronization, 802.1Qbv for scheduled traffic using a time-aware shaper and gate control list, 802.1Qbu and 802.3br for frame preemption, and 802.1CB for seamless frame replication and redundancy. TSN is coming to OT because it lets deterministic industrial traffic and standard IT traffic share the same physical infrastructure: one cable plant, one switch fabric, guaranteed delivery for the time-sensitive streams, and best-effort delivery for everything else. Like Profinet IRT, TSN networks measure the network as part of their operation. The key difference is how they react to changes. Rather than comparing a measured topology against a fixed project model and faulting on any deviation, TSN continuously measures worst-case end-to-end latency and recalculates whether the configured timing guarantees can still be met. As long as the worst-case latency stays inside the bounds the application needs, the network adapts and keeps running. That makes TSN considerably more tolerant of hardware added after commissioning. Inserting a Copper TAP changes the propagation delay on that segment, and the TSN measurement reflects the change. But if the TAP's latency keeps the worst-case path inside the application's timing budget, the network accommodates it without any project modification. The resulting measurements are not a perfect picture of the unmonitored network, since the TAP's delay is baked into what the network measures, but for most diagnostic purposes, that is not a significant concern. The second advantage of TSN for monitoring is traffic diversity. Because TSN converges IT and OT on the same wire, a TAP and IOTA capture everything: the scheduled industrial streams, clock synchronization traffic, standard IP traffic, IPv6, DHCP, DNS, and any other application-layer activity. That gives a complete picture of the converged network that an isolated OT-only capture cannot. In Wireshark, the ptp display filter surfaces the gPTP synchronization sequence (Sync, Follow\_Up, Delay\_Req, and Delay\_Resp messages), which you can use to verify clock accuracy and trace synchronization problems back to their source. Gate control list compliance can be checked by correlating IOTA's hardware timestamps against the configured transmission windows. Frame preemption appears as mPacket fragments that Wireshark can reassemble. 802.1Q priority tagging and VLAN assignments are visible in the Ethernet header of every frame. ![](https://insights.profitap.com/hs-fs/hubfs/undefined-Jun-30-2026-12-24-00-0452-PM.png?width=700&height=498&name=undefined-Jun-30-2026-12-24-00-0452-PM.png)   > **Wireshark, gPTP sequence.** A ptp capture showing the Sync → Follow\_Up → Delay\_Req → Delay\_Resp exchange in sequence.![Screenshot Wireshark From Roland](https://insights.profitap.com/hs-fs/hubfs/Screenshot%20Wireshark%20From%20Roland.png?width=1624&height=1006&name=Screenshot%20Wireshark%20From%20Roland.png) ### **Best Practice: Plan for Monitoring from the Start** Across all three protocols, the most practical route to non-disruptive monitoring is to plan for it during design. When the initial machine configuration is being built, before commissioning and before the project is locked, accounting for monitoring hardware costs almost nothing. Leaving slightly wider delay margins on segments where a TAP might eventually go means you can add monitoring hardware later without touching the running system. This matters most for IRT, where the alternative is a maintenance window and a project change. The same principle applies, with less urgency, to RT and TSN: knowing in advance where the monitoring points will be makes the actual capture work faster and less disruptive. --- ## **4. A Practical OT Monitoring Workflow** The following steps reflect a typical diagnostic capture on an OT network: 1. **Identify the link and assess the protocol.** Determine whether the traffic is hard or soft real-time. This decides which capture method is viable and which TAP to use. 2. **Choose the capture method.** Use a Copper TAP wherever the protocol and timing budget allow. If a SPAN port is the only option, for example, on an IRT network where the project cannot be modified, confirm one already exists. Configuring a SPAN port on a switched OT network means machine downtime. 3. **Install the TAP or connect to the SPAN port.** Copper TAP installation is inline and does not interrupt the link. 4. **Connect IOTA and start capturing.** Enable hardware timestamping from the start; it cannot be added to a capture afterward. 5. **Use IOTA's built-in analysis first.** Function codes, response codes, request-to-response timing, and protocol-level health indicators are available immediately. For many diagnostics, that is sufficient. 6. **Export to Wireshark when deeper inspection is needed.** Apply the appropriate display filters, add a delta time column for timing work, and use conversation statistics to find unexpected talkers or traffic patterns. ![Full-Flowchart-with-blue lines-bg-05](https://insights.profitap.com/hs-fs/hubfs/Full-Flowchart-with-blue%20lines-bg-05.jpg?width=800&height=1000&name=Full-Flowchart-with-blue%20lines-bg-05.jpg) --- ## **5. Conclusion** Copper TAPs and IOTA together give the kind of access OT network diagnostics actually requires: passive, non-intrusive, hardware-timestamped, and deployable on the production floor without disrupting the process. The combination covers a wide range of work, from basic Modbus TCP health checks to nanosecond-level timing verification on Profinet IRT and TSN, using the same hardware in different configurations depending on what the protocol needs. The key variable is not the tool; it is the protocol. Modbus TCP is forgiving: the TAP goes in, and the capture starts. Profinet IRT is demanding: the TAP's latency must stay within the project's allowed margins, and when it does not, the options are limited. TSN sits between the two, measuring and adapting, which makes post-commissioning monitoring practical while still requiring awareness of what the measurement reflects. Wireshark picks up the analysis where IOTA's built-in tools leave off, and for packet-level deep dives into industrial protocol behavior, it is the right choice. But the capture infrastructure, the TAP and IOTA, is what makes that analysis possible, accurate, and safe to perform in a live production environment. The broader takeaway is a design principle: building monitoring access into the initial machine configuration is far cheaper than retrofitting it. A slightly wider delay margin in the IRT project, a spare SPAN port in the TSN switch, a TAP point marked on the network diagram: any of these makes the next diagnostic session faster and the network more maintainable over its operational life. # [![IOTA-CTA-2025-orignal-01](https://no-cache.hubspot.com/cta/default/2954816/interactive-193707744430.png)](https://insights.profitap.com/hs/cta/wi/redirect?encryptedPayload=AVxigLJHQmLqCvWSQNDmvMRy5WbWxFMpLgrySIhW2TTbnYl4tCui9mACysPBSN7QJlO8AbHEMmno2r1FeYZaA7iYDIsFZfV%2FiJhytbEtFgUc6PkZoAtWD3NvnVn3HEZkeIeHLGmrT35yZ60NWXheo7RTJ%2BGrmmP5fEHyuutXfkYazR16x0Vh6M%2B6jvG3OQ%3D%3D&webInteractiveContentId=193707744430&portalId=2954816) - [Tweet](https://twitter.com/share) by [Profitap](https://insights.profitap.com/author/profitap) | Sep 25, 2026 | [Copper TAPs](https://insights.profitap.com/topic/copper-taps), [Network Monitoring](https://insights.profitap.com/topic/network-monitoring) [**Packet Capture & Analysis**](https://www.profitap.com/iota/) - [IOTA 1G](https://www.profitap.com/iota-1g/) - [IOTA 1G+](https://www.profitap.com/iota-1g-plus/) - [IOTA 10G](https://www.profitap.com/iota-10g/) - [IOTA 10G+](https://www.profitap.com/iota-10g-plus/) - [IOTA 10 CORE](https://www.profitap.com/iota-10-core/) - [IOTA 10 CORE+](https://www.profitap.com/iota-10-core-plus/) - [IOTA 100 CORE](https://www.profitap.com/iota-100-core/)   [**ProfiShark**](https://www.profitap.com/profishark-network-taps/) - [ProfiShark 100M](https://www.profitap.com/profishark-100m/) - [ProfiShark 1G](https://www.profitap.com/profishark-1g/) - [ProfiShark 1G+](https://www.profitap.com/profishark-1g-plus/) - [ProfiShark 10G](https://www.profitap.com/profishark-10g/) - [ProfiShark 10G+](https://www.profitap.com/profishark-10g-plus/)   [**Accessories**](https://www.profitap.com/accessories/) - [Transceivers](https://www.profitap.com/transceivers/) - [Data Diodes](https://www.profitap.com/data-diodes/) - [Connectivity](https://www.profitap.com/accessories/#connectivity/) [**Network Traffic Aggregators**](https://www.profitap.com/network-traffic-aggregators/) - [XX-720G](https://www.profitap.com/xx-720g-network-packet-broker/) - [XX-1800G](https://www.profitap.com/xx-1800g-network-packet-broker/) - [XX-3200G](https://www.profitap.com/xx-3200g-network-packet-broker/)   [**Network Packet Brokers**](https://www.profitap.com/network-packet-brokers/) - [X3-Series](https://www.profitap.com/x3-series-advanced-network-packet-brokers/) - [X2-2010G](https://www.profitap.com/x2-2010g-network-packet-broker/) - [X2-3200G](https://www.profitap.com/x2-3200g-network-packet-broker/) - [X2-6400G](https://www.profitap.com/x2-6400g-network-packet-broker/) - [X2-12800G](https://www.profitap.com/x2-12800g-network-packet-broker/)   **NPB Features** - [Data Masking](https://www.profitap.com/data-masking/) - [Timestamping](https://www.profitap.com/timestamping/) - [Packet Deduplication](https://www.profitap.com/packet-deduplication/) - [Tunneling & De-tunneling](https://www.profitap.com/tunneling-de-tunneling/) - [Packet Slicing](https://www.profitap.com/packet-slicing/) - [GTP IP Filtering](https://www.profitap.com/gtp-ip-filtering/) [**Network TAPs**](https://www.profitap.com/network-taps/) - [Secure TAPs](https://www.profitap.com/secure-data-access/) - [Fiber TAPs](https://www.profitap.com/fiber-taps/) - [Copper TAPs](https://www.profitap.com/copper-taps/) - [Aggregation TAPs](https://www.profitap.com/aggregation-taps/) - [Bypass TAPs](https://www.profitap.com/bypass-taps/) - [Regeneration TAPs](https://www.profitap.com/regeneration-taps/) - [Replication TAPs](https://www.profitap.com/replication-taps/)   **Cloud Visibility** - [VMware](https://www.profitap.com/vtap/) - [Kubernetes](https://www.profitap.com/cloud-tap/) - [AWS EKS](https://www.profitap.com/cloud-tap/) - [Azure VM](https://www.profitap.com/cloud-tap/#azure)   **Centralized Management** - [IOTA CM](https://www.profitap.com/iota-cm/) - [Supervisor](https://www.profitap.com/supervisor/)   [**Solutions**](https://www.profitap.com/solutions/) - [Performance analysis & diagnostics](https://www.profitap.com/performance-analysis-and-diagnostics-solutions/) - [Network troubleshooting](https://www.profitap.com/network-troubleshooting-solutions/) - [Packet forensics](https://www.profitap.com/packet-forensics-solutions/) - [Network security](https://www.profitap.com/network-security-solutions/) - [ICS/OT network monitoring](https://www.profitap.com/ics-ot-network-monitoring-solutions/) [**About Us**](https://www.profitap.com/our-story/) - [Our Story](https://www.profitap.com/our-story/) - [Events](https://www.profitap.com/events/) - [Careers](https://jobs.profitap.com/) - [News](https://news.profitap.com/)   **Resources** - [Knowledge Base](https://kb.profitap.com/) - [Software & Drivers](https://resources.profitap.com/) - [Product Portfolio](https://www.profitap.com/portfolio/) - [Blog](https://insights.profitap.com/) - [Library](https://www.profitap.com/library/) - [Product Updates](https://www.profitap.com/product-updates/) - [Academy](https://www.profitap.com/academy/)   **Partners** - [Partner with Us](https://www.profitap.com/partner-with-us/) - [Our Partners](https://www.profitap.com/our-partners/) - [Locate a Reseller](https://www.profitap.com/locate-a-reseller/)   **Contact** - [Contact Us](https://www.profitap.com/contact-us/) - [Professional Services](https://www.profitap.com/professional-services/) - [Get a Quote](https://www.profitap.com/get-a-quote/) --- © 2026 Profitap HQ B.V. and its licensors. All Rights Reserved — Profitap HQ B.V., High Tech Campus 84, 5656 AG Eindhoven, The Netherlands | [Privacy Policy](https://www.profitap.com/privacy-policy/) | [Terms and Conditions](https://www.profitap.com/terms-and-conditions/) ```json { "@context" : "http://schema.org", "@type" : "Blog", "author" : { "@type" : "Person", "name" : "Profitap" }, "dateModified" : "September 25, 2026, 9:06:45 AM", "datePublished" : "2026-09-25 09:06:45", "description" : "Explore effective strategies for capturing and analyzing OT network traffic with Copper TAPs, IOTA, and Wireshark to enhance visibility and performance.", "headline" : "Capturing and Analyzing OT Network Traffic Workflow", "image" : { "@type" : "ImageObject", "url" : "https://2954816.fs1.hubspotusercontent-na1.net/hubfs/2954816/Sc-Flowchart-with-lines-blue-04.jpg" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://cdn2.hubspot.net/hubfs/2954816/Logos/Profitap-logo-black-orange-whitebg.png" }, "name" : "Profitap HQ B.V." } } ```