1.2 Ethernet and MAC Addressing

The previous section introduced the OSI model as a shared language for describing network behavior. This section covers Ethernet — the actual Layer 1 and 2 technology that every industrial network runs on. Before you can understand VLANs, MRP rings, or PROFINET, you need to understand how an Ethernet frame is built and how MAC addresses work.

Why Ethernet Won

In the 1980s, Token Ring (IBM), ARCNET, and Ethernet competed for dominance. Token Ring was technically superior in one way: it guaranteed each device a turn to transmit, eliminating collisions entirely. Ethernet used CSMA/CD, which meant collisions were possible and throughput degraded under load.

Ethernet won because it was cheaper, simpler, and fast enough. Token Ring required a dedicated ring controller and expensive NICs. Ethernet ran on cheap coaxial cable and later on twisted pair. When full-duplex switched Ethernet arrived in the 1990s, collisions became impossible on point-to-point links, and Token Ring’s last technical advantage disappeared.

Today, Ethernet is the universal Layer 2 technology. Industrial protocols including PROFINET, EtherNet/IP, and MRP all run on standard IEEE 802.3 hardware. The industrial additions are at the software and protocol level, not the physical layer. To understand those additions, you first need to understand the Ethernet frame itself.

The Ethernet Frame

An Ethernet II frame has this structure:

Field	Size	Content
Preamble	7 bytes	10101010 10101010 ... — clock synchronization
SFD	1 byte	10101011 — frame start marker
Destination MAC	6 bytes	Target device hardware address
Source MAC	6 bytes	Sender hardware address
EtherType	2 bytes	Payload protocol identifier
Payload	46 to 1500 bytes	The data being carried
FCS	4 bytes	CRC-32 error detection

Key terms:

• EtherType — a 2-byte field identifying the payload: 0x0800 = IPv4, 0x8100 = 802.1Q VLAN, 0x8892 = PROFINET RT, 0x88E3 = MRP
• FCS (Frame Check Sequence) — a 32-bit CRC appended to every frame; the receiver discards frames with a mismatched FCS
• MTU (Maximum Transmission Unit) — the maximum payload size; 1500 bytes for standard Ethernet

The minimum frame size is 64 bytes. Frames shorter than 64 bytes are runts and the switch discards them. The maximum frame size is 1518 bytes, or 1522 bytes with an 802.1Q VLAN tag. The FCS field is what makes error detection possible — but it only detects errors, it does not correct them.

How CRC-32 Works

The FCS is not a simple checksum. It is a CRC-32 (Cyclic Redundancy Check) computed over the entire frame from Destination MAC through the end of the payload.

The sender treats the frame bytes as a large binary number and divides it by a fixed 33-bit polynomial (0x104C11DB7). The 32-bit remainder is the CRC. The sender appends it as the FCS.

The receiver performs the same division over the received frame including the FCS. If the result equals a fixed constant (0xC704DD7B), the frame is intact. If not, the receiver discards the frame silently.

This matters in OT networks because a switch that receives a frame with a bad FCS increments its CRC error counter and discards the frame. The PLC never knows the frame was lost. In a PROFINET RT network with a 4 ms cycle time, even one CRC error per second causes visible jitter. Check CRC error counters first when diagnosing intermittent communication problems.

The FCS covers the payload but not the MAC addresses. The MAC addresses themselves are the addressing mechanism — and they have a structure that carries more information than just “who sent this.”

MAC Addresses

A MAC address (Media Access Control address) is a 48-bit hardware identifier assigned to every network interface. It is written as six hexadecimal pairs: 00:A0:57:1B:2C:3D.

Bits	Field	Example	Assigned by
0 to 23	OUI	00:A0:57	IEEE to manufacturer
24 to 47	NIC-specific	1B:2C:3D	Manufacturer

The first byte encodes two important flags:

• Bit 0 (I/G bit): 0 = unicast, 1 = multicast or broadcast. Switches flood frames with this bit set to all ports in the VLAN.
• Bit 1 (U/L bit): 0 = universally administered (burned in by manufacturer), 1 = locally administered (manually assigned or generated by software)

This is why multicast addresses always have an odd first byte: 01:80:C2:00:00:0E (LLDP), 01:15:4E:00:00:01 (MRP), 01:80:C2:00:00:00 (STP). The I/G bit is set, so switches flood them to every port in the VLAN by design.

Key terms:

• OUI (Organizationally Unique Identifier) — the first 24 bits of a MAC address, assigned to the manufacturer by IEEE. 00:A0:57 and 00:80:63 are Hirschmann OUIs.
• I/G bit — the least-significant bit of the first byte; 0 = unicast, 1 = multicast or broadcast

When you see an unknown MAC address in a switch table or a packet capture, the I/G bit tells you immediately whether it is a device or a protocol. The OUI tells you the manufacturer. The following script applies both checks:

def decode_mac(mac: str) -> dict:
    first_byte = int(mac.split(":")[0], 16)
    oui = ":".join(mac.split(":")[:3]).upper()
    known_ouis = {"00:A0:57": "Hirschmann", "00:80:63": "Hirschmann",
                  "00:0C:29": "VMware", "52:54:00": "QEMU/KVM"}
    return {
        "type":   "broadcast" if mac.upper() == "FF:FF:FF:FF:FF:FF"
                  else "multicast" if first_byte & 0x01 else "unicast",
        "scope":  "local" if first_byte & 0x02 else "universal",
        "vendor": known_ouis.get(oui, "unknown"),
    }

for mac in ["01:15:4e:00:00:01", "00:a0:57:1b:2c:3d", "02:00:00:00:00:01"]:
    info = decode_mac(mac)
    print(f"{mac}  {info['type']:12s}  {info['scope']:10s}  {info['vendor']}")

01:15:4e:00:00:01  multicast     universal   unknown      <- MRP protocol frame
00:a0:57:1b:2c:3d  unicast       universal   Hirschmann   <- known device
02:00:00:00:00:01  unicast       local        unknown      <- VM or container NIC

A multicast MAC you did not configure is a protocol running on the segment that you did not expect. A locally administered unicast MAC on a production port is a virtual machine or container, not a PLC. Beyond identifying frames by address, the physical link itself can introduce problems that are invisible at higher layers.

Duplex Mismatch

Full-duplex allows simultaneous send and receive. All modern switches and NICs operate in full-duplex. Collisions are impossible on a full-duplex point-to-point link.

A duplex mismatch occurs when one side is full-duplex and the other is half-duplex. The half-duplex side detects what it interprets as collisions. Throughput drops to around 30% of line rate. The link stays up. No error messages appear in logs. The only visible symptoms are high collision counters on the half-duplex side and poor throughput.

Set speed and duplex explicitly on ports connected to PLCs and other industrial devices. Do not rely on auto-negotiation for critical industrial connections. To verify what a port has negotiated:

ethtool eth0 | grep -E "Speed|Duplex"
# Speed: 1000Mb/s
# Duplex: Full

If Duplex shows Half on a port that should be full-duplex, set it explicitly on both ends. With the physical layer understood, the next step is to verify which protocols are actually present on a segment.

Identifying Protocols on a Live Segment

When commissioning a new ring or diagnosing a ring that shows as open, the first question is: are the expected protocol frames actually present on the segment? The following script captures frames for 10 seconds and counts them by EtherType:

from scapy.all import sniff, Ether
from collections import Counter
import time

NAMES = {0x0800: "IPv4", 0x0806: "ARP", 0x8100: "802.1Q",
         0x8892: "PROFINET RT", 0x88CC: "LLDP", 0x88E3: "MRP"}

counts: Counter = Counter()

def count_frame(pkt):
    if pkt.haslayer(Ether):
        etype = pkt[Ether].type
        counts[NAMES.get(etype, f"0x{etype:04x}")] += 1

sniff(iface="eth0", prn=count_frame, timeout=10, store=False)

for name, n in sorted(counts.items(), key=lambda x: -x[1]):
    print(f"  {name:20s}  {n:6d}")

If you see no MRP frames on a ring port, either MRP is not configured on the Ring Manager or the ring port is in the wrong VLAN. If you see PROFINET RT frames but the PLC reports communication errors, the problem is at Layer 3 or above.

Key Takeaways

CRC errors point to the physical layer

A frame with a bad FCS is discarded silently. Rising CRC error counters on a port mean a cable, SFP, or EMI problem on that specific port. Check counters before opening Wireshark.

The I/G bit controls flooding

Switches flood frames with the I/G bit set. MRP, LLDP, and STP all use multicast MACs. They reach every switch on the segment by design.

Set speed and duplex explicitly

A duplex mismatch drops throughput to 30% with no error messages. Set speed and duplex explicitly on all ports connected to PLCs and industrial devices.

What Comes Next

Ethernet delivers frames between directly connected devices on the same segment. That is not enough. A PLC in one cabinet needs to reach a SCADA server in another building. That requires IP addressing and routing — the Layer 3 and 4 protocols that move data across multiple network segments. This section covers the TCP/IP stack that makes that possible.

References

• IEEE 802.3-2022 — IEEE Standard for Ethernet
• Spurgeon, C. E., and Zimmerman, J. (2014). Ethernet: The Definitive Guide (2nd ed.). O’Reilly Media.