01Layer Data-Diode

Move data forward. Keep your boundary intact.

01Layer combines application message brokers, one-way transport, optional encryption, and destination-side publishing. Move logs, flow records, telemetry, and events with physical isolation at the fiber or logical enforcement in the data plane.

Explore deployment options Discuss your architecture

Data moves from a protected environment through an 01Layer Data Diode to monitoring, analytics, and messaging systems, with no reverse service path.

1G to 100G

Purpose-built physical Data Diode interfaces with SR/LR/ER optics.

Physical and logical

Independent or integrated enforcement across hardware, virtual, and cloud environments.

Application-aware transfer

Syslog, Kafka, SNMP, and IPFIX broker paths in one service environment.

Replication and availability

1-to-N destination replication, virtual IP failover, and heartbeat monitoring.

Four deployment models

Choose how you enforce the boundary. Scale from there.

The 01Layer Data Diode solution covers the physical interface, the forward-only service path, and the application workflow on both sides. Select the model that matches your security requirements and deployment environment.

01 / Physical Data Diode

Isolation at the fiber.

A purpose-built iNIC-DD interface connects the protected source's transmit port to the destination's receive port over one fiber. No return strand is installed.

Use when the boundary must be physically transmit-only and directly inspectable. Supported DD port rates span 1G, 10G, 25G, 40G, and 100G.

Explore the hardware boundary

02 / Logical Data Diode

Control in the data plane.

NextIO separates sender and receiver roles and permits the approved source-to-destination service edge across standard, virtual, or cloud interfaces.

Use where a Tx-only hardware interface cannot be installed. Routes, security groups, network policy, and the service graph work together to enforce the allowed direction.

Explore cloud and virtual deployment

03 / Fully integrated solution

From application message to destination delivery.

Combine application brokers, diode framing, optional encryption, receiving, and message publishing in a complete one-way pipeline.

Use NextIO service enforcement together with iNIC-DD when the design calls for independent controls in both the data plane and the physical interface.

Follow the transfer architecture

04 / High-density deployment

More boundaries. More processing capacity.

FlowDirector and Service Nodes support architectures with many Data Diode connections, separating traffic delivery from application processing.

FlowDirector interface options reach up to 128 × 100Gb or 32 × 400Gb in 1U, with Service Nodes providing the processing layer.

Explore FlowDirector and Service Nodes

Physical Data Diode / iNIC-DD

A transmit path that operates without a return fiber.

Standard Ethernet interfaces typically depend on received light or link-partner state. The iNIC-DD ASIC/FPGA state machine keeps the transmit path operational without an Rx strand, so the source can send through a physically one-way optical boundary.

The protected source's iNIC-DD transmits over a single forward fiber to destination Rx; no reverse optical strand exists. — Source Tx connects to destination Rx. Operators can inspect the boundary and confirm that the reverse fiber is absent. Open full-size diagram.

Purpose-built transmission

The hardware maintains the transmit path without received light, instead of relying solely on software policy applied to a duplex connection.

Multi-rate connectivity

Tri-speed 1G/10G/25G and high-speed 40G/100G Data Diode ports support SR, LR, and ER optics.

Inspectable direction

The absent return strand makes the source-to-destination optical path directly verifiable at the security boundary.

Logical Data Diode / NextIO

Bring one-way service control to virtual and cloud networks.

Cloud networks do not expose a removable Tx/Rx fiber pair. Place the DD Sender and DD Receiver in separate trust zones, VPCs, VNets, or virtual appliances, then define only the approved forward service path.

Application exchanges terminate at local brokers. The cross-zone path carries one-way diode traffic rather than an end-to-end application session. Open full-size diagram.

Separate the roles: Place sender and receiver in distinct trust zones and use standard ports, virtual NICs, or cloud network attachments.
Align the network controls: Permit the approved source-to-destination path in NextIO, routes, security groups, and network policy. Omit the reverse service edge.
Adapt reply-dependent protocols: Use local brokers, proxies, static addressing, or UDP record transport where normal application protocols expect a response.
Choose the transport: Use UDP on an isolated private path, or ESP AES-256-GCM when the transfer requires payload confidentiality.

Two distinct forms of enforcement. Logical Data Diode controls the service path on physically bidirectional infrastructure. Physical Data Diode removes the return optical channel. They can be deployed independently or combined.

The complete transfer architecture

Local application sessions. One-way boundary crossing.

01Layer terminates application communication independently on each side. Accepted messages are prepared, transferred, validated, and republished without an acknowledgement, control session, or application return channel crossing the boundary.

Accept the application message
The source-side message broker accepts the local application exchange and passes each approved message to an upstream queue for the Data Diode Sender.
Frame and protect
The sender assigns stream and message identity, segments the message to the configured MTU, adds framing and integrity controls, and applies encryption when enabled.
Cross the one-way boundary
The Data Diode port or virtual port emits the forward-only stream. An absent return fiber, a forward-only NextIO service edge, or both enforce its direction.
Validate and reconstruct
The receiver matches the configured transport, validates headers and fragments, decrypts when required, and reassembles complete messages within configured resource limits.
Publish at the destination
The application message sender delivers reconstructed output to the destination service. Any application acknowledgements remain local to that side of the boundary.

Data Diode Sender

Convert each message into a bounded transfer stream.

Accept one upstream message queue and emit to one transfer path.
Assign a 32-bit stream ID and monotonic message ID; segment to the output MTU.
Apply header integrity, optional message and fragment CRC32C, optional VLAN tagging, and one-way heartbeats.
Transmit using plain IPv4/UDP or ESP AES-256-GCM.

Data Diode Receiver

Release complete, validated messages.

Match the configured UDP destination port or ESP SPI and stream allow-list.
Check headers, optional CRCs, encryption state, fragment bounds, duplicates, and overlaps.
Reassemble within time, inflight-message, fragment-count, and memory limits.
Release complete messages to the downstream queue; reject and count invalid or incomplete work.

Kafka Message Broker + Kafka Message Sender

Keep your Kafka workflow. Preserve network separation.

Send logs, telemetry, and events from protected networks to a central Kafka platform. Source-side Logstash sends to a local Kafka-compatible broker; destination-side publishing is re-established only after the one-way transfer.

Logstash feeds Kafka Message Broker on the protected side. Encryption, a physical Data Diode, decryption, and Kafka Message Sender deliver reconstructed messages to the target Kafka cluster. — The physical Data Diode Kafka architecture: source-side reception, encryption, one-way transfer, decryption, and controlled publishing to the target cluster. Open full-size diagram.

Why the broker and sender are separate

Traditional Kafka uses bidirectional TCP sessions, broker metadata exchange, acknowledgements, and authentication handshakes. Those exchanges cannot run end to end across a physical Data Diode. FlowMagic terminates Kafka-style communication locally at the source and creates a separate producer connection at the destination. The diode transport remains one-way.

Source / Kafka Message Broker

A local endpoint for existing collection workflows.

Deploy close to Logstash in the source network.
Expose a Kafka-compatible receiving interface so Logstash can retain its familiar Kafka output configuration.
Accept JSON log and event payloads without direct TCP/Kafka connectivity to the remote cluster.
Prepare messages for one-way transport with sequencing, integrity checks, and transfer metadata.

Destination / Kafka Message Sender

A controlled producer for the target cluster.

Receive the transferred stream and validate sequence, format, and integrity.
Reconstruct Kafka-ready event payloads and publish them to the configured brokers and topics.
Support TLS and SASL authentication for destination-side Kafka delivery.
Expose sent, dropped, delayed, duplicated, malformed, and integrity-failed message status.

Explore the Kafka Message Broker reference

Availability and operational visibility

Operate the transfer, not just the boundary.

01Layer combines directional control with destination replication, broker availability, and component-level visibility so teams can inspect both the service design and its behavior.

1-to-N geo replication

Replicate one-way traffic to multiple local or geographically distributed destinations, with control over redundant delivery.

Application broker availability

Virtual IP failover and heartbeat monitoring support application message brokers through node, network, or site-level outages.

Visible transfer outcomes

Review message, byte, fragment, drop, CRC, timeout, queue, control, and cryptographic counters at the component level.

Validate the complete deployment

Confirm direction. Verify the permitted forward path and test that the reverse path is denied. Record the service graph and hardware port mapping.
Resolve addressing. Configure the destination or gateway MAC address where ARP or route discovery cannot complete across the one-way path.
Check message handling. Review sequencing, integrity, drops, delays, duplicates, and payload schema against representative traffic and downstream consumer expectations.
Check destination delivery. For Kafka, validate brokers, topics, TLS, and SASL settings on the receiving side.

Sender / receiver reference

A defined transport and operating envelope.

The service defines message identity, framing, integrity checks, and reassembly limits explicitly. Invalid or incomplete transfers are rejected and counted.

Data Diode Sender/Receiver operating parameters
Area	Supported behavior
Transport	Plain IPv4/UDP or ESP AES-256-GCM, with optional 802.1Q VLAN tagging.
Framing	Version 1, 56-byte diode header containing stream/message identity, fragment mapping, timestamp, flags, and header CRC32C.
Configured bounds	512–9,216 byte output MTU; 64 KB–4 MB message profiles; up to 65,535 fragments per message.
Reassembly controls	Configured limits for time, inflight messages, fragment count, and memory; validation of duplicates, overlaps, and fragment bounds.
Failure handling	Oversize, malformed, CRC-failed, replayed, overlapping, timed-out, or resource-constrained work is rejected and counted.
Observability	Per-component message, byte, fragment, drop, CRC, timeout, queue, control, and cryptographic counters.

Data Diode architecture reference Sender/receiver component manual Kafka broker and sender reference

Where the architecture fits

Connect protected operations to the teams that depend on them.

Security logs to the SOC

Forward logs and security events from protected networks into centralized SOC, SIEM, and Kafka collection pipelines.

OT/ICS telemetry

Deliver industrial telemetry to enterprise analytics while preserving the approved one-way boundary around the source environment.

Cross-domain audit and events

Export audit logs and operational events between separated environments in government, financial, healthcare, and critical infrastructure deployments.

Bring your security boundary into the conversation.

Work with our team to map your data sources, destinations, and enforcement requirements to a Data Diode deployment.

Request Architecture Review