What is the Ethernet protocol?
The term Ethernet protocol does not describe one application command language. In technical terms, Ethernet is a family of IEEE 802.3 specifications that define how Ethernet frames are carried by a MAC and by physical-layer technologies. It covers the rules needed to move frames over defined copper, fiber and other Ethernet media, but it does not decide what a PLC register means, which speed command a drive should execute, or which tag an HMI should display. Those meanings belong to higher-level protocols and applications. [1]
That distinction matters in automation. An RJ45 connector tells you very little about protocol compatibility by itself. EtherNet/IP, PROFINET and EtherCAT all make use of Ethernet technology, yet they do not exchange control data in the same way. Ethernet is also not another name for TCP/IP.
What does Ethernet actually define?
A useful way to think about Ethernet is as the transport foundation inside a plant network. The application message may be a recipe download, an I/O update or a drive parameter request; Ethernet's core job is to provide the MAC/frame mechanism and the physical means to carry that data. IEEE's Ethernet scope includes a common MAC, speed-specific PHY specifications, management elements and additional capabilities associated with selected physical interfaces. [1]
| Part | What Ethernet provides | What it does not provide by itself |
|---|---|---|
| PHY / Physical Layer | Rules for encoding and transmitting bits over a defined medium, with speed, signalling and link characteristics that depend on the PHY. | It does not define the meaning of a PLC variable. |
| MAC | Layer-2 frame transmission and reception using Ethernet MAC addresses. | It is not IP routing. |
| Frame | A Layer-2 container with destination/source MAC information, type/length information, payload and FCS. | It does not interpret the application data carried in the payload. |
| FCS | Helps a receiver detect a corrupted frame. | It does not repair the frame or request an Ethernet-level retransmission. |
| Link rate | The physical data rate supported by a particular Ethernet PHY and link. | It does not guarantee a PLC scan time or a deterministic control cycle. |
For the physical media side, see Ethernet cable types; for link rates, see Ethernet speeds; and for the device interface itself, see Ethernet cards and NICs. This page focuses on how those pieces fit into the protocol architecture rather than repeating them.
How does a PLC message travel over Ethernet?
Imagine an HMI requesting a temperature value from a PLC. The HMI application first creates a message in its application protocol. If that protocol runs over TCP/IP, such as Modbus TCP, the application data is encapsulated by TCP and IP. The Ethernet interface then places the resulting network-layer packet into the payload of an Ethernet frame. The classic specification for carrying IPv4 datagrams over Ethernet is RFC 894. [2]
If an IPv4 device needs to reach another host on the same local network, it may use ARP to resolve a protocol address to an Ethernet hardware address. ARP is not a built-in function of IEEE 802.3; it is a separately specified protocol that can be carried over Ethernet. RFC 826 describes this address-resolution process. [3] So the statement “Ethernet converts IP addresses into MAC addresses” is too broad.
Once the frame is ready, the PHY transmits the bits on the physical medium. If the path includes an Ethernet switch, the switch forwards Layer-2 traffic based on MAC information. The receiving interface checks the frame, including its FCS, and passes the payload upward. IP, TCP/UDP and the application protocol then perform their own separate jobs. For an end-to-end walkthrough, see How does Ethernet work? and, for forwarding and delivery, How is data transmitted in an Ethernet network?.
Ethernet, IP, TCP and the application protocol are different layers
A common networking mistake is to call everything travelling through the cable “the Ethernet protocol.” In a conventional TCP/IP application, responsibilities are separated roughly as follows:
| Layer / function | Examples | Main question it answers |
|---|---|---|
| Application | Modbus TCP, EtherNet/IP CIP messages, OPC UA and others | “What does this data mean, and which service or variable is being requested?” |
| Transport | TCP or UDP | “How is end-to-end data transport handled; do we need connection state, ordering or retransmission?” |
| Network | IPv4 / IPv6 | “Which IP destination and route should the packet use?” |
| Data Link | Ethernet MAC | “Which Layer-2 destination should receive this frame on the local link?” |
| Physical | 100BASE-TX, 1000BASE-T, fiber PHYs and others | “How are the bits signalled over this physical medium?” |
Industrial Ethernet does not always follow that entire stack for cyclic control traffic. EtherCAT, for example, can place its process-data payload directly in a standard Ethernet frame identified by EtherType 0x88A4, without requiring TCP/IP or UDP/IP for the normal cyclic path. The EtherCAT Technology Group documents this directly. [6] PROFINET Real-Time traffic can similarly use EtherType 0x8892 and bypass the IP stack for time-critical communication. [8]
What is the difference between a MAC address and an IP address?
A MAC address is used for Ethernet Layer-2 delivery. An IP address is a logical network-layer address used for routing between IP networks. A switch forwarding frames from its MAC address table and a router forwarding packets from its IP routing table are performing different jobs. For manufacturer-assigned versus locally administered addresses, unicast/multicast/broadcast and related details, see What is an Ethernet or MAC address?.
It is also misleading to say that every Ethernet interface has a permanently fixed, globally unique address that can never change. Interfaces may use locally administered addresses and software-controlled addressing. A MAC address is not an authentication mechanism either. Access control, segmentation and cryptographic protection are separate subjects covered in Ethernet network security.
Why does EtherType matter?
The Type/Length field in an Ethernet frame is interpreted according to the frame format in use. In Ethernet II framing, the EtherType value tells the receiver which higher-level protocol should receive the payload. Classic IPv4 encapsulation uses 0x0800. [2] Other examples include 0x0806 for ARP, 0x88A4 for EtherCAT and 0x8892 for PROFINET RT.
This does not mean Ethernet “understands” the application carried inside the frame. EtherType is essentially a dispatch identifier. The detailed field layout, size rules and VLAN-related changes belong in the dedicated Ethernet frame structure guide.
FCS detects corruption; it does not repair or retransmit a frame
The Frame Check Sequence (FCS) at the end of an Ethernet frame helps the receiver detect whether the frame was corrupted in transit. A frame that fails that check is normally discarded. Ethernet MAC does not provide an application-style acknowledgement for the bad frame and does not automatically ask the sender to transmit the same frame again.
If retransmission is required, another layer or protocol may provide it. TCP has its own reliable-delivery mechanisms; UDP does not. Industrial real-time protocols may instead use cyclic refresh, watchdogs, sequence handling or protocol-specific recovery strategies. That is why FCS is not error correction, and Ethernet by itself is not an end-to-end reliable delivery service.
Why CSMA/CD is not the normal explanation for a modern switched link
CSMA/CD was important on shared, half-duplex Ethernet media. Devices sharing the same medium could collide and needed rules for detecting and recovering from those collisions. Modern Ethernet links are commonly point-to-point and full-duplex through switches. On a normal full-duplex link, both ends can transmit and receive at the same time, and classic collision handling is not used. Cisco's duplex documentation notes that collisions are not expected on full-duplex interfaces. [4]
So the textbook sentence “a station listens to the cable and transmits only when it is idle” should not be used as a universal description of Ethernet in a current PLC-switch-HMI network. It describes the shared-medium history, not the everyday behaviour of a switched full-duplex connection.
Where do switches, VLANs and 802.1Q fit?
Ethernet switching is part of the practical Layer-2 network, but bridging and VLAN behaviour are substantially specified in the IEEE 802.1 family rather than being one monolithic 802.3 feature. IEEE 802.1Q covers bridged networks and VLANs. [5] It is therefore better to separate “Ethernet MAC/PHY,” “switching/bridging,” and “network security” when troubleshooting or designing a plant network.
The same principle applies to Power over Ethernet. PoE adds power-delivery capabilities to selected Ethernet physical interfaces, but it does not define the industrial application protocol. A PoE-powered device is not automatically an EtherNet/IP, PROFINET or EtherCAT device.
Why the same cable does not mean the same industrial protocol
Two devices may both use an RJ45 connector and standard Ethernet cabling yet still be incompatible at the control-protocol level. A PLC configured for EtherNet/IP and a drive configured only for PROFINET do not suddenly speak the same I/O language because both ports have link LEDs.
ODVA describes EtherNet/IP as CIP adapted to Ethernet technology using standard TCP/IP and UDP/IP mechanisms for different types of communication. [7] PROFINET can use IP-based communication for configuration and diagnostics while using a direct Ethernet Real-Time path for time-critical traffic. [8] EtherCAT uses its own frame-processing model. These are all Ethernet-based technologies, but their protocol behaviour is different.
For a broader map, see protocols that can operate over Ethernet and the main industrial communication section. Device families are also separated into PLCs, HMIs and SCADA so that a protocol claim can be checked at the actual device level rather than assumed from the connector.
The link LED is on, but communication still fails — what should you check?
This is where separating Ethernet layers becomes useful. A lit link LED is strong evidence that a physical link has been established, but it does not prove that the application protocol is working. A practical troubleshooting order is:
1. Are link speed and duplex compatible, and are the cable, connector and switch port healthy?
2. Are the devices in the expected Layer-2/VLAN domain?
3. If the protocol is IP-based, are IP address, subnet mask and gateway settings correct?
4. For same-subnet IPv4 communication, is address resolution working?
5. Do both devices actually support the same industrial/application protocol?
6. Are protocol-specific names, ports, connections, EDS/GSDML/ESI files or I/O mappings correct?
7. If communication works but is slow, is the bottleneck the physical link, the application cycle, switch queuing, controller scan time or another part of the system?
That last question is especially important. Ethernet link speed and machine control-cycle time are different measurements. Moving from 100 Mb/s to 1 Gb/s does not, by itself, make a PLC program or servo loop ten times faster.
In one paragraph
Ethernet is the IEEE 802.3 family that provides the physical and MAC/frame foundation for wired networking. It handles Layer-2 frame delivery and defined physical links, while IP addressing, TCP/UDP transport and the meaning of PLC or HMI data belong to other protocols. Modern switched full-duplex links should not be explained as if every transmission still used shared-medium CSMA/CD. FCS detects corrupted frames but does not provide Ethernet-level retransmission. In industrial automation, always check the actual protocol supported by both devices rather than assuming compatibility from the connector or cable.
Related Ethernet guides
What is Ethernet? • How does Ethernet work? • Ethernet frame structure • MAC addresses • Switch vs. hub • Protocols over Ethernet • Ethernet data transmission • Ethernet speeds • Ethernet cable types • Maximum cable length • Gigabit Ethernet • PoE • Ethernet security • Advantages and disadvantages
Technical sources
- IEEE SA, IEEE 802.3 / Standard for Ethernet: scope of Ethernet MAC, PHY and related capabilities. IEEE source ↩
- RFC 894, A Standard for the Transmission of IP Datagrams over Ethernet Networks: IPv4 encapsulation in Ethernet frames. RFC Editor ↩
- RFC 826, An Ethernet Address Resolution Protocol: mapping protocol addresses to Ethernet hardware addresses. RFC Editor ↩
- Cisco, Ethernet auto-negotiation and half/full-duplex guidance: duplex mode and collision behaviour. Cisco technical document