Networks
Ethernet is the backbone of every modern network — from the cable plugged into your laptop to the 400 Gb/s fibre links connecting data centres across continents. This guide takes you from first principles — what is a bit, how does a signal travel on copper — through every layer of Ethernet technology: physical media, frame structure, switching, VLANs, spanning tree, link aggregation, Power over Ethernet, industrial variants, and data-centre architecture. Every hidden mechanism, every edge case, every real-world brand and reference is covered. By the end you will understand not just how to use Ethernet, but why every design decision was made.
Ethernet is a family of computer networking technologies defined by IEEE standard 802.3. It operates at Layer 1 (Physical) and Layer 2 (Data Link) of the OSI model, handling how raw bits are placed on a medium and how frames are addressed and delivered between devices on the same network segment. Understanding Ethernet from the ground up — the physics of signalling, the geometry of collision domains, and the mathematics of frame timing — gives you the ability to diagnose any Ethernet problem and design any Ethernet system from first principles.
Enter source and destination MAC addresses to build a real Ethernet II frame. See the byte layout, calculated sizes, and efficiency metrics live.
Calculate real-world throughput including Ethernet overhead, protocol headers, and link efficiency at any frame size and link speed.
Ethernet was invented by Robert Metcalfe and David Boggs at Xerox PARC in 1973. The original Ethernet ran at 2.94 Mb/s on a thick coaxial cable (10BASE5, "Thicknet"), where all stations shared a single bus and had to contend for access. The IEEE 802.3 standard (1983) formalised 10 Mb/s Ethernet. The progression: 10BASE5 coax (1983) → 10BASE2 thinnet coax (1985) → 10BASE-T twisted pair (1990, star topology) → 100BASE-TX Fast Ethernet (1995) → 1000BASE-T Gigabit (1999) → 10GBASE-T / 10GBASE-SR (2002–2006) → 25/40/100 GbE (2010–2015) → 200/400 GbE (2017–2020) → 800GbE / 1.6 TbE (emerging 2024+). Each generation preserved backward-compatible frame format while radically changing the physical layer.
// Ethernet speed milestones and key IEEE standards
//
// Standard Speed Year Medium Max Length
// ─────────────────────────────────────────────────────────────
// 10BASE5 10 Mb/s 1983 RG-8 coax 500m segment
// 10BASE2 10 Mb/s 1985 RG-58 coax 185m segment
// 10BASE-T 10 Mb/s 1990 Cat3 UTP (2 pair) 100m
// 100BASE-TX 100 Mb/s 1995 Cat5 UTP (2 pair) 100m
// 100BASE-FX 100 Mb/s 1995 Multimode fibre 2000m
// 1000BASE-T 1 Gb/s 1999 Cat5e UTP (4 pair) 100m
// 1000BASE-SX 1 Gb/s 1998 OM1/OM2 MMF 550m
// 1000BASE-LX 1 Gb/s 1998 SMF 5km
// 10GBASE-T 10 Gb/s 2006 Cat6A UTP 100m
// 10GBASE-SR 10 Gb/s 2002 OM3 MMF 300m
// 10GBASE-LR 10 Gb/s 2002 SMF 10km
// 25GBASE-T 25 Gb/s 2016 Cat8 UTP 30m
// 25GBASE-SR 25 Gb/s 2014 OM4 MMF 100m
// 40GBASE-SR4 40 Gb/s 2010 OM3 MMF (8 fibres) 100m
// 100GBASE-LR4 100 Gb/s 2010 SMF (4λ WDM) 10km
// 400GBASE-DR4 400 Gb/s 2018 SMF (4λ PAM-4) 500m
// 800GBASE-R 800 Gb/s 2023 SMF (emerging) 2km
//
// Key IEEE 802.3 amendments:
// 802.3i (1990): 10BASE-T
// 802.3u (1995): Fast Ethernet
// 802.3z (1998): 1000BASE-X fibre
// 802.3ab (1999): 1000BASE-T copper
// 802.3ae (2002): 10 Gigabit Ethernet
// 802.3at (2009): PoE+ (30W)
// 802.3bz (2016): 2.5/5GBASE-T
// 802.3bt (2018): PoE++ (90W)
// 802.3bs (2017): 200GbE / 400GbE
// 802.3ck (2022): 100G/200G/400G electrical interfaces
// 802.3df (2023): 800GbE (in development)
An Ethernet frame is the fundamental unit of data transmission at Layer 2. Every field has a specific purpose, and understanding each one is essential for protocol analysis, debugging, and security. The frame as seen on the wire includes a preamble and SFD not visible in most capture tools. The payload carries one packet from a higher-layer protocol (IP, ARP, IPv6). The FCS provides error detection. The minimum payload is 46 bytes (padding added if needed to reach 64-byte minimum frame size). The maximum is 1500 bytes (standard MTU) or 9000 bytes (jumbo frame, non-standard but universally supported).
// Ethernet II (DIX) frame structure — byte-by-byte
//
// ┌──────────┬──────────┬──────────┬─────────┬───────────┬─────────┐
// │ Preamble │ SFD │ Dst MAC │ Src MAC │EtherType │ Payload │ FCS
// │ 7 bytes │ 1 byte │ 6 bytes │ 6 bytes│ 2 bytes │46-1500B │ 4 bytes
// └──────────┴──────────┴──────────┴─────────┴───────────┴─────────┘
//
// PREAMBLE (7 bytes = 56 bits):
// 10101010 10101010 10101010 10101010 10101010 10101010 10101010
// Alternating 1/0 bits: clock synchronisation between TX and RX
// Receiver uses preamble to lock PLL (Phase-Locked Loop) to transmitter clock
// NOT captured by most packet sniffers (stripped by NIC hardware)
//
// SFD — Start Frame Delimiter (1 byte):
// 10101011 (preamble pattern but ends in 11 instead of 10)
// Signals: 'next byte is the start of the destination MAC address'
//
// DESTINATION MAC (6 bytes = 48 bits):
// Byte format: OUI (3 bytes, Organisationally Unique Identifier) + NIC ID (3 bytes)
// OUI assigned by IEEE to each manufacturer — searchable at ieee.org
// Special values:
// FF:FF:FF:FF:FF:FF → Broadcast (all devices receive)
// 01:xx:xx:xx:xx:xx → Multicast (bit 0 of byte 0 = 1)
// 00:xx:xx:xx:xx:xx → Unicast (bit 0 of byte 0 = 0)
// Locally administered bit: bit 1 of byte 0
// 0 = globally unique (OUI assigned)
// 1 = locally administered (MAC randomisation, VMs, etc.)
//
// SOURCE MAC (6 bytes):
// Always a unicast address (cannot be a broadcast source)
// Used by switches for MAC learning (source MAC → ingress port mapping)
//
// ETHERTYPE (2 bytes) — in Ethernet II:
// Values ≥ 0x0600 = EtherType (protocol identifier)
// Values ≤ 0x05DC = IEEE 802.3 length field (legacy, rarely used today)
// Common EtherTypes:
// 0x0800 IPv4
// 0x0806 ARP
// 0x86DD IPv6
// 0x8100 IEEE 802.1Q VLAN tag (adds 4 bytes before payload)
// 0x8847 MPLS unicast
// 0x88CC LLDP (Link Layer Discovery Protocol)
// 0x8809 LACP (Link Aggregation Control Protocol)
// 0x88E5 MACsec (802.1AE encryption)
// 0x88F7 PTP (Precision Time Protocol, IEEE 1588)
// 0x8906 FCoE (Fibre Channel over Ethernet)
//
// PAYLOAD (46–1500 bytes):
// Minimum 46 bytes enforced by padding (zeroes) to reach 64-byte frame minimum
// Maximum 1500 bytes = standard MTU (Maximum Transmission Unit)
// Jumbo frames: MTU 9000 bytes — must be configured on all devices end-to-end
//
// FCS — Frame Check Sequence (4 bytes):
// CRC-32 polynomial: 0x04C11DB7
// Computed over: Destination MAC + Source MAC + EtherType + Payload
// Any bit flip in these fields → FCS mismatch → frame discarded
// FCS errors in Wireshark: often means NIC is doing checksum offload
// (NIC calculates FCS in hardware — Wireshark sees frames before NIC adds FCS)
//
// INTER-FRAME GAP (IFG):
// 12 bytes (96 bit times) of silence between consecutive frames
// Allows receiver to reset for next frame
// At 1 Gb/s: 96 ns gap
// At 10 Gb/s: 9.6 ns gap (reduced in some standards for efficiency)
//
// EFFICIENCY calculation:
// Header overhead = 8 (pre+SFD) + 6 + 6 + 2 + 4 + 12 (IFG) = 38 bytes
// Max payload = 1500 bytes
// Efficiency = 1500 / (1500 + 38) = 97.5% for max-size frames
// Min payload = 46 bytes → Efficiency = 46 / (46 + 38) = 54.8%
// → Always use large payloads (or jumbo frames) to maximise efficiency
A MAC (Media Access Control) address is a 48-bit identifier assigned to every network interface. The first 24 bits are the OUI (Organisationally Unique Identifier) assigned by the IEEE to a manufacturer — searching an OUI tells you who made a device. The last 24 bits are the interface identifier, assigned by the manufacturer. Modern operating systems use MAC randomisation (iOS 14+, Android 10+, Windows 10 2004+) to protect privacy: a random MAC is generated per network to prevent tracking across SSIDs. This breaks DHCP reservations and MAC-based ACLs, requiring network administrators to be aware of it.
// MAC address structure and analysis
//
// Example: 00:1A:2B:3C:4D:5E
// └─OUI─┘ └─NIC ID─┘
//
// Bit 0 of byte 0 (LSB of first octet):
// 0 = Unicast
// 1 = Multicast
//
// Bit 1 of byte 0:
// 0 = Globally Unique (OUI-assigned, 'burned-in')
// 1 = Locally Administered (VM-assigned, random, or manual)
//
// Common OUI examples:
// 00:1A:2B → Cisco Systems
// 00:50:56 → VMware (virtual machines)
// 00:0C:29 → VMware Workstation
// B8:27:EB → Raspberry Pi Foundation
// DC:A6:32 → Raspberry Pi Trading
// 00:11:22 → Ciena Corporation
// 3C:5A:B4 → Google Inc (Chromecast)
// 44:38:39 → Cumulus Networks
//
// Special multicast MACs:
// 01:00:5E:xx:xx:xx → IPv4 multicast
// (map from IP: bits 0-22 of IP multicast addr → bits 0-22 of MAC)
// 33:33:xx:xx:xx:xx → IPv6 multicast (last 32 bits of IPv6 addr)
// 01:80:C2:00:00:00 → STP BPDUs (Spanning Tree)
// 01:80:C2:00:00:02 → LACP PDUs
// 01:80:C2:00:00:03 → 802.1X PAE (port authentication)
// 01:80:C2:00:00:0E → LLDP
// 01:00:0C:CC:CC:CC → Cisco CDP (proprietary)
//
// MAC Randomisation detection and mitigation:
// Detection: OUI prefix changes per connection, locally administered bit=1
// iOS: Rotating random MAC per SSID (fixed per SSID in iOS 14–17)
// iOS 17.4+: 'Rotate MAC Weekly' option — MAC changes every 7 days per SSID
// Android 10+: random stable MAC per SSID by default
// Windows 11: random MAC per network by default
//
// Impact on networks:
// - DHCP reservations (MAC→IP) break unless using username/cert
// - MAC-based ACLs on switch ports bypass
// - Network Access Control (NAC) using MAC must use 802.1X instead
// - DHCP pool exhaustion risk (each reconnect = new lease)
//
// Mitigations:
// - Use 802.1X (username/password/certificate) for access control
// - Use DHCP option 61 (client-identifier) for reservations
// - Educate users to disable MAC randomisation for corporate SSIDs
The physical layer (OSI Layer 1) defines how bits are encoded as electrical signals, light pulses, or radio waves, and specifies the cables, connectors, distances, and signal integrity requirements. Understanding the physical layer is essential for installation, troubleshooting cable faults, selecting the right transceiver for your distance, and avoiding the hidden problems of signal integrity — crosstalk, attenuation, impedance mismatch — that cause intermittent errors and reduced throughput.
Model cable attenuation, NEXT, and return loss against TIA-568 limits. See if your cable run will pass certification.
Calculate the optical power budget for a fibre link. Check if transmitter power minus losses leaves enough margin at the receiver.
Ethernet over copper uses Unshielded Twisted Pair (UTP) or Shielded Twisted Pair (STP/FTP/SFTP) cable. The cable category determines the bandwidth and maximum Ethernet speed it supports. Twisting pairs together cancels electromagnetic interference (EMI) and crosstalk: the twist rate (turns per metre) is different for each pair to prevent inter-pair coupling. Cat5e supports 1 Gb/s to 100m. Cat6 supports 10 Gb/s to 55m. Cat6A supports 10 Gb/s to 100m. Cat8 supports 40 Gb/s to 30m for data-centre use. TIA-568 (USA) and ISO/IEC 11801 (international) are the cabling standards.
// Copper cable categories — full specification table
//
// Category Bandwidth Max Ethernet Max Length Std Pairs Shielding
// ─────────────────────────────────────────────────────────────────────
// Cat3 16 MHz 10BASE-T 100m 2 or 4 UTP
// Cat5 100 MHz 100BASE-TX 100m 4 UTP
// Cat5e 100 MHz 1000BASE-T 100m 4 UTP
// Cat6 250 MHz 10GBASE-T 55m 4 UTP or STP
// Cat6A 500 MHz 10GBASE-T 100m 4 UTP or STP
// Cat7 600 MHz 10GBASE-T 100m 4 S/FTP (each pair)
// Cat7A 1000 MHz 40GBASE-T 100m 4 S/FTP
// Cat8.1 2000 MHz 40GBASE-T 30m 4 U/FTP
// Cat8.2 2000 MHz 40GBASE-T 30m 4 F/FTP
//
// UTP/STP variants:
// UTP = Unshielded Twisted Pair
// FTP = Foil-shielded overall (Foiled TP)
// STP = Braided shield overall
// SFTP = Braided + foil overall
// S/FTP= Braided overall + foil per pair (Cat7/8)
//
// Pair assignment (TIA-568B, most common in USA/EU):
// Pair 1: White/Blue + Blue → pins 4+5
// Pair 2: White/Orange + Orange → pins 1+2
// Pair 3: White/Green + Green → pins 3+6
// Pair 4: White/Brown + Brown → pins 7+8
//
// 1000BASE-T pair usage:
// All 4 pairs transmit AND receive simultaneously (full-duplex each pair)
// Pair 1-2: TX+RX via hybrid cancellation
// Pair 3-6: TX+RX via hybrid cancellation
// Pair 4-5: TX+RX via hybrid cancellation
// Pair 7-8: TX+RX via hybrid cancellation
//
// Key signal impairments:
// Attenuation: Signal loss per 100m, increases with frequency
// Cat6A limit at 500 MHz: ≤ 20.9 dB/100m
// NEXT (near-end crosstalk): Coupling from TX pair → adjacent pair at same end
// Limit: > 44.3 dB @ 100 MHz (Cat5e)
// FEXT (far-end crosstalk): Coupling measured at far end
// Return Loss: Reflected energy from impedance mismatch (target: 100Ω ±15%)
// Delay Skew: Difference in propagation time between fastest/slowest pair
// Limit: ≤ 45ns/100m (Cat5e/6), 50% margin on Cat6A
//
// Cable qualification: use a Fluke Networks DSX-8000 or DTX CableAnalyzer
// Tests: Wire map, Length, Attenuation, NEXT, ELFEXT, Return Loss, Delay/Skew
// Pass/Fail vs selected standard (TIA-568B, ISO/IEC 11801 Class EA)
Optical fibre carries light pulses rather than electrical signals, enabling much longer distances and complete immunity to electromagnetic interference. Multimode fibre (MMF) has a larger core (50 or 62.5 µm) that allows multiple light modes to propagate — cheaper VCSELs can be used but modal dispersion limits distance. Single-mode fibre (SMF) has a 9 µm core — only one light mode propagates, eliminating modal dispersion and enabling distances from 2km to >80km. The SFP (Small Form-factor Pluggable) transceiver ecosystem allows the same switch port to support dozens of different optical standards by swapping the module.
// Fibre types and specifications
//
// MULTIMODE FIBRE (colour: aqua OM3/OM4, lime-green OM5):
// Standard Core/Clad Bandwidth 10GbE 25GbE 100GbE
// OM1 62.5/125µm 200 MHz·km 33m - -
// OM2 50/125µm 500 MHz·km 82m - -
// OM3 50/125µm 2000 MHz·km 300m 70m 100m
// OM4 50/125µm 4700 MHz·km 400m 100m 150m
// OM5 50/125µm 28000 MHz·km 400m 100m 400m (SWDM4)
//
// SINGLE-MODE FIBRE (colour: yellow):
// G.652D (OS2): Standard SMF, 9µm core — most common
// 10GBASE-LR: 10km, 1310nm DFB laser
// 10GBASE-ER: 40km, 1550nm DFB + optical amplifier
// 100GBASE-LR4: 10km, 4× WDM (1295/1300/1305/1310nm)
// G.657A1/A2: Bend-insensitive SMF — for in-building routing
// Can be bent to 10mm radius without significant loss
// vs standard SMF: bend radius limit 30mm
//
// TRANSCEIVER FORM FACTORS:
// SFP (1.06Gb/s–2.5Gb/s): 1GbE copper/fibre, Fast Ethernet
// SFP+ (1–10Gb/s): 10GbE, also 8G FC, 16G FC
// SFP28 (25Gb/s): 25GbE
// QSFP (4×1G or 4×10G=40G): 40GbE (4 lanes)
// QSFP+ (40Gb/s): 40GbE QSFP+SR4, QSFP+LR4
// QSFP28 (100Gb/s): 100GbE (4×25G lanes)
// QSFP56 (200Gb/s): 200GbE (4×50G PAM-4 lanes)
// QSFP-DD (400Gb/s): 400GbE (8×50G PAM-4 lanes)
// OSFP (400Gb/s–800Gb/s): 800GbE (8×100G)
//
// LASER SAFETY CLASSES:
// Class 1: Eye-safe at all times (all pluggable transceivers)
// Class 1M: Eye-safe if not viewed with optical instruments
// Class 3B: Potentially hazardous — long-haul amplified DWDM systems
// Rule: NEVER look into a fibre end of an active transceiver!
// Use: fibre power meter with appropriate probe, or optical attenuator
//
// TRANSCEIVER BRANDS:
// Cisco: Cisco-branded SFP-10G-SR, SFP-10G-LR — interop locked
// Juniper, Arista: similar vendor lock (use 'service unsupported-transceiver')
// Third-party: Finisar/II-VI, Lumentum, InnoLight, Eoptolink
// Cost comparison: Cisco SFP-10G-SR ~$300 vs generic ~$15
// Note: 3rd-party may not be supported under vendor warranty
// DAC (Direct Attach Copper): passive twinax cable with SFP+/QSFP28 ends
// 10GbE DAC: up to 7m, ~$10–30, zero latency, no optics
// 25GbE DAC: up to 5m, ~$20–50
// 100GbE QSFP28 DAC: up to 5m, ~$30–80
Autonegotiation (IEEE 802.3u clause 28 for copper; clause 37 for 1000BASE-X) is the mechanism by which two Ethernet devices agree on the highest common speed and duplex mode. For 100BASE-TX and 1000BASE-T, autoneg uses Fast Link Pulses (FLP) — a burst of Normal Link Pulses encoding a 16-bit word (the "Link Code Word") advertising supported modes. Both sides exchange advertisements and select the highest common mode using a priority table. Mismatched autoneg is one of the most common causes of network problems: if one side forces 100/full and the other autonnegs, the autoneg side will fall back to half-duplex, causing collision errors and reduced throughput.
// Autonegotiation — Link Code Word (802.3 Fig 28-2)
// Transmitted as burst of Fast Link Pulses (FLP)
// 16-bit word exchanged between partners:
//
// Bit 15-11: Next Page (NP) + Ack (ACK) + Remote Fault (RF) + Reserved
// Bit 10-5: Technology Ability Field (TAF) — advertised modes
// Bit 4-0: Selector Field = 00001 (IEEE 802.3)
//
// Technology Ability Field bits:
// TAF Bit Capability Advertised
// ─────── ───────────────────────
// A0 10BASE-T
// A1 10BASE-T Full-Duplex
// A2 100BASE-TX
// A3 100BASE-TX Full-Duplex
// A4 100BASE-T4
// A5 Pause (flow control)
// A6 Asymmetric Pause
// (1000 Mb/s uses separate 802.3ab Next Page advertisement)
//
// Priority resolution (highest wins):
// 1. 1000BASE-T Full-Duplex (highest)
// 2. 1000BASE-T Half-Duplex
// 3. 100BASE-TX Full-Duplex
// 4. 100BASE-T4
// 5. 100BASE-TX Half-Duplex
// 6. 10BASE-T Full-Duplex
// 7. 10BASE-T Half-Duplex (lowest)
//
// CRITICAL: Autoneg failure modes
//
// Scenario: Switch port = forced 100/Full-Duplex
// NIC = autoneg enabled
// Switch: no FLPs sent → NIC sees link but no autoneg
// NIC: interprets silence as 100BASE-TX (parallel detection)
// assumes half-duplex (no autoneg partner → cannot negotiate FD)
// Result: DUPLEX MISMATCH!
// Switch = Full-Duplex, NIC = Half-Duplex
//
// Symptoms of duplex mismatch:
// - Late collision errors (collisions after 64 bytes) on half-duplex side
// - Input errors, CRC errors on full-duplex side
// - Low throughput (5–20% of expected)
// - Intermittent connection drops under load
//
// Diagnosis (Cisco IOS):
// show interfaces fa0/1 | include duplex|collision|CRC
// → 'Half-duplex' + non-zero 'late collisions' = duplex mismatch
//
// Fix: ALWAYS leave BOTH sides on autoneg, OR force BOTH sides identically
// interface GigabitEthernet0/1
// duplex auto
// speed auto
// (do NOT mix forced on one side + auto on the other)
//
// 10GbE and above: no autoneg for half-duplex (always full-duplex)
// 10GBASE-T autoneg: uses clause 73 baseband autoneg at 10Mb/s
An Ethernet switch is a Layer 2 device that connects multiple network segments. Unlike hubs (which flood all frames to all ports), switches learn which devices are connected to which port and forward frames only to the correct destination — reducing unnecessary traffic and eliminating collisions. Understanding how switching works internally — CAM tables, switching modes, STP, and VLANs — is essential for designing and troubleshooting any enterprise or industrial network.
Configure four switches with priority and MAC addresses. Watch the Root Bridge election and see which ports become Root Ports, Designated Ports, or Alternate Ports.
Select a VLAN ID and priority. See the 4-byte 802.1Q tag inserted into the Ethernet frame in real time — every bit explained.
The Content Addressable Memory (CAM) table maps MAC addresses to switch ports. When a frame arrives, the switch records the source MAC and ingress port (MAC learning). For the destination MAC, if found in the CAM table, the frame is forwarded to the corresponding port (unicast forwarding). If not found, the frame is flooded to all ports in the same VLAN (unknown unicast flooding). CAM table entries age out after 300 seconds (default) if no traffic is seen. The CAM table has a finite size (typically 8k–128k entries for enterprise switches, 256–4k for small switches). CAM table overflow (CAM flooding attack) causes a switch to flood all unknown unicast frames like a hub — a significant security vulnerability.
// Switch forwarding logic — pseudocode
//
function process_frame(frame, ingress_port):
// 1. Source MAC learning
cam_table[frame.src_mac][vlan_id] = {
port: ingress_port,
timestamp: now()
}
// 2. Destination lookup
if frame.dst_mac == 'FF:FF:FF:FF:FF:FF':
// Broadcast — flood all ports in same VLAN except ingress
flood_to_vlan(frame, vlan_id, except=ingress_port)
elif is_multicast(frame.dst_mac):
// Multicast — flood unless IGMP snooping active
if igmp_snooping_enabled:
forward_to_mcast_group(frame, frame.dst_mac, vlan_id)
else:
flood_to_vlan(frame, vlan_id, except=ingress_port)
elif frame.dst_mac in cam_table and vlan_id in cam_table[frame.dst_mac]:
entry = cam_table[frame.dst_mac][vlan_id]
if entry.port == ingress_port:
// Source = destination port: discard (port security or loop)
drop(frame)
else:
// Known unicast: forward to single port
forward_to_port(frame, entry.port)
else:
// Unknown unicast: flood
flood_to_vlan(frame, vlan_id, except=ingress_port)
// CAM table aging
function cam_aging_timer(): // runs every second
for entry in cam_table:
if now() - entry.timestamp > aging_time: // default 300s
delete entry
// CAM OVERFLOW ATTACK (MAC flooding / Dsniff macof tool):
// attacker sends frames with random source MACs → fills CAM table
// switch falls back to flooding all frames (like a hub)
// attacker sniffs all traffic on the segment
//
// Mitigation:
// Port security — limit max MACs per port (Cisco IOS):
// interface FastEthernet0/1
// switchport mode access
// switchport port-security maximum 2
// switchport port-security violation restrict // or shutdown/protect
// switchport port-security mac-address sticky // learn first 2, lock them
// Dynamic ARP Inspection (DAI): validates ARP against DHCP snooping table
// DHCP Snooping: tracks legitimate IP→MAC mappings from DHCP exchanges
A switch can use three forwarding modes differing in latency and error handling. Store-and-Forward: the entire frame is received and the FCS checked before forwarding — any corrupt frame is dropped at the switch. Latency equals the time to receive the complete frame. Cut-Through: the switch starts forwarding after reading only the destination MAC (first 14 bytes) — much lower latency but corrupt frames are forwarded. Fragment-Free (Modified Cut-Through): waits for 64 bytes (past the collision window) before forwarding — filters collision fragments but not FCS errors. Enterprise and data-centre switches use Store-and-Forward. Some low-latency switches (Arista, Mellanox) offer cut-through mode for HPC applications.
// Switching mode latency comparison
//
// Store-and-Forward latency = frame_size_bits / link_speed
// 1518-byte frame (max) at 1 Gb/s:
// latency = (1518 × 8) / 1,000,000,000 = 12.144 µs + switching_delay
// 1518-byte frame at 10 Gb/s:
// latency = (1518 × 8) / 10,000,000,000 = 1.214 µs + switching_delay
// 64-byte frame at 1 Gb/s:
// latency = (64 × 8) / 1,000,000,000 = 0.512 µs + switching_delay
//
// Cut-Through latency = constant (only destination MAC read)
// At 1 Gb/s: destination MAC (6 bytes) read time = 48 ns
// + PHY serialisation delay (~100 ns)
// Total cut-through latency: ~200–500 ns regardless of frame size
// At 10 Gb/s: ~50–200 ns
//
// Fragment-Free latency:
// 64 bytes at 1 Gb/s = 512 ns (always, regardless of frame size)
//
// Latency comparison at 1 Gb/s (min/max frame):
// Mode Min frame (64B) Max frame (1518B)
// Store-and-Forward 0.512 µs + Δ 12.144 µs + Δ
// Cut-Through 0.20 µs (fixed) 0.20 µs (fixed)
// Fragment-Free 0.512 µs (fixed) 0.512 µs (fixed)
//
// Real switch latency data (approximate, manufacturer specs):
// Cisco Catalyst 9300 (SaF): 4.8 µs at 1GbE
// Cisco Nexus 9300 (SaF): 2.0 µs at 10GbE
// Arista 7060 (SaF): 0.8 µs at 100GbE
// Arista 7130 (Cut-Through): 200 ns at 10GbE
// Mellanox SN2100 (Cut-Thru): 150 ns at 100GbE
// Microsemi VSC7514 (Cut-Thru): 600 ns at 1GbE (industrial)
//
// When does switching mode matter?
// HPC/clustering: yes — 200ns vs 5µs is significant at scale
// Enterprise LAN: no — application latency >> switching latency
// Storage (NVMe-oF, iSCSI): yes — latency affects IOPS
// Industrial PROFINET/EtherNet/IP: yes — cycle time budget is tight
Spanning Tree Protocol (STP, IEEE 802.1D) prevents Layer 2 loops by creating a loop-free logical topology from a physically redundant network. Without STP, a broadcast frame would loop forever, saturating all links. STP elects a Root Bridge, calculates shortest paths, and blocks redundant ports. RSTP (802.1w) reduces failover from 30–50s to 1–3s using rapid agreement. MSTP (802.1s) runs multiple STP instances for different VLAN groups. Modern alternatives: TRILL, SPB (802.1aq), and increasingly Layer 3 routing to the access layer with ECMP eliminate STP entirely from the data path.
Port States in STP: Blocking (not forwarding, listening for BPDUs), Listening (sending and receiving BPDUs, not learning), Learning (learning MACs, not forwarding), Forwarding (normal operation). Port Roles: Root Port (best path to Root Bridge), Designated Port (best port on each segment toward Root), Blocked/Alternate Port (backup). Bridge Priority determines Root Bridge election — lowest priority wins (configurable in multiples of 4096, range 0–61440, default 32768).
// STP configuration and tuning — Cisco IOS
//
// Root Bridge election:
// Bridge ID = Bridge Priority (2B) + MAC Address (6B)
// Lowest Bridge ID = Root Bridge
// Default priority = 32768; configure primary root:
// spanning-tree vlan 10 priority 4096 // explicitly
// spanning-tree vlan 10 root primary // macro (sets to 24576 or lower)
//
// Port cost values (802.1D revised 2004):
// 10 Mb/s: 100
// 100 Mb/s: 19
// 1 Gb/s: 4
// 10 Gb/s: 2
// 100 Gb/s: 1
//
// RSTP port roles (802.1w):
// Root Port: Best path to Root Bridge (one per switch)
// Designated Port: Best port on each LAN segment
// Alternate Port: Backup to Root Port — immediately unblocks on RP failure
// Backup Port: Backup Designated Port (same switch, same segment)
//
// RSTP convergence speed:
// Link failure: Alternate port unblocks immediately (< 100ms)
// Non-edge port failure: rapid agreement with neighbour (~1-3s)
// Edge port (PortFast): goes straight to Forwarding immediately
//
// PortFast — only on access ports connected to end devices:
// interface GigabitEthernet0/10
// spanning-tree portfast ! Skip Listening+Learning (15s+15s saved)
// spanning-tree bpduguard enable ! Shutdown if BPDU received (loop protection)
//
// BPDU Guard: shuts down a PortFast port if it receives a BPDU
// (prevents rogue switches plugged in by users)
// BPDU Filter: stops sending/receiving BPDUs on a port (use with caution!)
// Root Guard: prevents a port from becoming a Root Port (enforce root position)
// Loop Guard: prevents Alternate Port from becoming Designated if BPDUs stop
//
// Show commands:
// show spanning-tree vlan 10
// show spanning-tree vlan 10 detail
// show spanning-tree interface gi0/1 detail
// debug spanning-tree events
//
// Topology Change (TC) behaviour:
// When a port changes state, a Topology Change Notification (TCN) floods
// All switches flush their CAM tables to the TC timer (default 15s)
// → massive unknown unicast flooding for 15s!
// Common cause of 'slow network' spikes — use RSTP to reduce TC impact
Virtual LANs (VLANs) segment a physical switch into multiple logical switches, each with its own broadcast domain. A 24-port switch can carry 24 VLANs, each isolated from the others. VLANs are identified by a 12-bit VLAN ID (1–4094 usable). IEEE 802.1Q adds a 4-byte tag to the Ethernet frame header. Access ports carry one untagged VLAN (for end devices). Trunk ports carry multiple VLANs tagged (for switch-to-switch or switch-to-router links). Inter-VLAN routing requires a Layer 3 device (router or Layer 3 switch): "router-on-a-stick" (one physical link with subinterfaces) or SVIs (Switched Virtual Interfaces) on a multilayer switch.
// VLAN configuration — Cisco IOS (Layer 2 switch)
//
// Create VLANs:
vlan 10
name SALES
vlan 20
name ENGINEERING
vlan 30
name MANAGEMENT
vlan 99
name NATIVE
//
// Access port (end device — PC, IP phone, printer):
interface GigabitEthernet0/5
switchport mode access
switchport access vlan 10
switchport nonegotiate ! Disable DTP (Dynamic Trunking Protocol)
spanning-tree portfast
spanning-tree bpduguard enable
//
// Trunk port (switch-to-switch, switch-to-router):
interface GigabitEthernet0/1
switchport mode trunk
switchport trunk encapsulation dot1q ! (on older IOS, newer defaults to dot1q)
switchport trunk native vlan 99 ! Native VLAN for untagged frames
switchport trunk allowed vlan 10,20,30,99 ! Whitelist — only needed VLANs
switchport nonegotiate ! Disable DTP
//
// SECURITY: Disable unused ports:
interface range GigabitEthernet0/20-24
switchport mode access
switchport access vlan 999 ! 'Unused' VLAN — nothing routed here
shutdown
//
// VLAN HOPPING ATTACKS — two methods:
// 1. Switch Spoofing: attacker enables DTP, forms trunk, accesses all VLANs
// Mitigation: 'switchport nonegotiate' on all access ports
// 2. Double Tagging: attacker sends double-tagged frame (outer=native VLAN)
// Switch strips outer tag, forwards inner-tagged frame to target VLAN
// Mitigation: never use VLAN 1 as native; set native VLAN to unused VLAN 99
//
// Inter-VLAN routing — Layer 3 switch (SVIs):
ip routing ! Enable Layer 3 routing on multilayer switch
interface Vlan10
ip address 10.10.10.1 255.255.255.0
no shutdown
interface Vlan20
ip address 10.10.20.1 255.255.255.0
no shutdown
interface Vlan30
ip address 10.10.30.1 255.255.255.0
no shutdown
//
// Router-on-a-stick (when using a separate router):
interface GigabitEthernet0/0.10
encapsulation dot1q 10
ip address 10.10.10.1 255.255.255.0
interface GigabitEthernet0/0.20
encapsulation dot1q 20
ip address 10.10.20.1 255.255.255.0
Power over Ethernet delivers DC electrical power alongside data over standard Ethernet cables, eliminating the need for a separate power supply for devices such as IP cameras, VoIP phones, Wi-Fi access points, door access controllers, LED lighting, and more. Understanding PoE — the different standards, detection and classification mechanisms, power budgets, and heat implications — is critical for network designers and anyone deploying PoE-powered devices.
Add devices to your PoE switch. See total power demand, remaining budget, and cable loss at your run length. Detects budget overrun instantly.
Three IEEE standards define PoE. 802.3af (PoE, 2003): 15.4W at PSE, 12.95W at PD, uses 2 pairs. 802.3at (PoE+, 2009): 30W at PSE, 25.5W at PD, uses 2 pairs. 802.3bt (PoE++, 2018): Type 3 = 60W at PSE, 51W at PD; Type 4 = 100W at PSE, 71.3W at PD; uses all 4 pairs. The gap between PSE power and PD power is the cable loss: at 100m, a Cat5e cable can dissipate up to 8W at full 802.3bt Type 4 load. Cable gauge affects this — Cat6A with 23 AWG conductors has lower resistance than Cat5e 24 AWG.
// PoE standards comparison
//
// Standard PSE Power PD Power Pairs Max Current PD Classes
// ─────────────────────────────────────────────────────────────────
// 802.3af 15.4 W 12.95 W 2 350 mA/pair 0–3
// 802.3at 30.0 W 25.50 W 2 600 mA/pair 0–4
// 802.3bt T3 60.0 W 51.00 W 4 600 mA/pair 0–6
// 802.3bt T4 100.0 W 71.30 W 4 960 mA/pair 0–8
//
// PD Classification classes (802.3bt):
// Class Max PD Power PSE Required
// 0 12.95 W 15.4 W (legacy default)
// 1 3.84 W 4.0 W
// 2 6.49 W 7.0 W
// 3 12.95 W 15.4 W
// 4 12.95 W 30.0 W (PoE+)
// 5 40.0 W 45.0 W (4-pair T3)
// 6 51.0 W 60.0 W (4-pair T3)
// 7 62.0 W 75.0 W (4-pair T4)
// 8 71.3 W 100.0 W (4-pair T4)
//
// Cable resistance at 100m (two conductors, round-trip):
// 24 AWG Cat5e: 0.188 Ω/m × 2 × 100m = 37.6 Ω
// 23 AWG Cat6A: 0.150 Ω/m × 2 × 100m = 30.0 Ω
//
// Power loss at 802.3bt Type 4 (960 mA per pair pair):
// Cat5e: P = I² × R = (0.96)² × 37.6 = 34.7 W lost per pair!
// → NOT suitable for full 4-pair 802.3bt at 100m with Cat5e 24AWG
// Cat6A: P = (0.96)² × 30.0 = 27.6 W per pair
// → In 4-pair mode: 2 pairs deliver power: (0.48A each) better!
// Actual 802.3bt: current split across 4 pairs: 960mA PSE total → 240mA/pair
// (simplified: higher voltage = lower current = less loss)
// PSE voltage range: 44–57V (class 0–4), 50–57V (class 5–8)
//
// PoE switch budget management:
// Total budget = Σ(allocated PD power) ≤ PSE maximum budget
// Cisco Catalyst 9300-24P: 370W PoE budget, 24 ports
// Average per port: 370W / 24 = 15.4W → fine for PoE cameras
// If deploying PoE++ class 8 devices: 100W each → max 3-4 simultaneous
// Always check switch datasheet for actual PoE budget
//
// PoE detection sequence (IEEE 802.3bt):
// 1. Discovery: PSE applies 2.7–10V, measures current
// PD must present 25kΩ signature resistor → PSE detects valid PD
// 2. Classification: PSE applies voltage pulses, PD responds with class marks
// 4-event or 5-event classification handshake for 802.3bt
// 3. Power On: PSE applies full voltage, PD starts up
// 4. Maintenance: LLDP or CDP negotiation for fine-grained power allocation
// Cisco LLDP-MED: PD requests exact wattage → PSE reserves only that much
Designing a PoE network requires careful attention to power budgets, switch placement, cable runs, and thermal management. The golden rule: verify the total PD power demand against the switch PoE budget before ordering. High-power PoE (802.3bt) generates significant heat in the cable and in the switch — a 48-port PoE++ switch can dissipate 500W+ in heat, requiring data-centre-grade cooling if mounted in an IDF closet. Cable routing affects power delivery: longer cables = more resistance = more loss = less power at the PD. Measure actual cable length (not estimated), account for patch cords at both ends.
// PoE network design checklist
//
// Step 1: Inventory all PD devices and their power class:
// Device Class Max PD Power
// ─────────────────────────────────────────
// VoIP phone 3 12.95W
// Wi-Fi AP (Wi-Fi 6) 4 25.50W
// Wi-Fi AP (Wi-Fi 6E/7) 6 51.00W (802.3bt T3)
// IP camera, basic 1 3.84W
// IP camera, PTZ/heated 4 25.50W
// Access controller 3 12.95W
// PoE LED luminaire 6-8 40-71W (802.3bt T4)
//
// Step 2: Calculate required switch PoE budget:
// Example floor with 48 ports:
// - 20× IP phone @ 12.95W = 259.0W
// - 10× Wi-Fi 6 AP @ 25.50W = 255.0W
// - 10× IP camera @ 3.84W = 38.4W
// - 8× access ctrl @ 12.95W = 103.6W
// Total required: 656W
// → Cisco Catalyst 9300-48P: 740W budget ✓
// → Standard 370W switch: INSUFFICIENT
//
// Step 3: Check cable runs for high-power devices:
// Wi-Fi 6E AP at 51W, 80m Cat6A run:
// PD voltage @ class 6 = 42.5–57V, nominal 50V
// Current = 51W / 50V = 1.02A (2-pair mode)
// Cat6A resistance: 30Ω / 100m × 80m = 24Ω
// Loss = 1.02² × 24 = 24.97W per pair — too high!
// In 4-pair mode: current per pair = 0.51A
// Loss = 0.51² × 24 = 6.24W per pair × 2 pairs = 12.5W total loss
// PSE must provide: 51W + 12.5W = 63.5W
// → Need 802.3bt T3 (60W class 6 PSE) or T4 (100W class 8 PSE)
//
// Step 4: Thermal management for high-density PoE switch:
// Example: 48× class 4 (25.5W each) = 1224W PD load
// Typical efficiency: 90% → switch PSU draws: 1360W
// Switch waste heat: 136W + PSU waste + chip waste ≈ 200-300W total
// IDF closet cooling: ensure HVAC rated for 400W minimum for 1 PoE switch
// Stack of 4 switches: 800-1200W heat in one rack!
//
// PoE midspan injectors (when switch has no PoE):
// Single-port: Phihong POE50U-1AF: 50W, 1 port, ~$30
// Multi-port: Phihong PSA16U-480/10: 480W, 16×30W, ~$300
// 19" rackmount: Cisco AIR-PWRINJ6: 30W 1-port, for AP deployment
//
// PoE extenders (extend past 100m):
// Axis T8129: PoE+ 30W, 100m extension, ~$80
// Works by acting as PD on incoming cable + PSE on outgoing cable
// Total cable path: 100m + 100m = 200m to endpoint
// Voltage drop doubles — ensure adequate budget
The relentless demand for bandwidth from cloud computing, video streaming, AI training, and distributed storage has driven Ethernet speeds from 1 Gb/s to 400 Gb/s in two decades — and 800 Gb/s is emerging. Each speed generation required new physical layer technology, new encoding schemes, and new form-factor transceivers. Understanding the differences between copper and optic options, DAC vs AOC vs optical, NRZ vs PAM-4 signalling, and the evolving transceiver ecosystem is essential for data-centre and high-performance network design.
Select your required speed, fibre type, and distance to find the appropriate transceiver standard and form factor. Includes real product references.
Design a Clos network fabric. Adjust spine count, leaf count, and uplink bandwidth to calculate total fabric capacity, east-west bandwidth, and oversubscription ratio.
10GbE (IEEE 802.3ae, 2002) uses 64B/66B encoding (vs 8B/10B in 1GbE) for 97% efficiency. 40GbE uses 4 lanes of 10G (40GBASE-SR4: 4× 10G over 8 fibres, MPO connector). 25GbE uses a single 25G lane — more efficient than 40GbE per port in server-to-ToR switch links. 100GbE uses 4 lanes of 25G (100GBASE-SR4) or 10 lanes of 10G (100GBASE-SR10, less common). 400GbE uses 8 lanes of 50G PAM-4. PAM-4 (Pulse Amplitude Modulation, 4 levels) encodes 2 bits per symbol, doubling the data rate at the same symbol rate — but halves the noise margin, requiring more complex DSP and Forward Error Correction (FEC).
// Encoding efficiency comparison
//
// 10BASE-T: Manchester encoding
// Symbol rate = 2× data rate (1 symbol = 1 clock cycle)
// 20 Msymbols/s for 10 Mb/s → 50% efficiency including overhead
//
// 100BASE-TX: 4B5B + MLT-3
// 4B5B: 4 data bits → 5 encoded bits (80% efficiency)
// MLT-3: 3-level line code on 125 MHz signal → 100 Mb/s
// Actual efficiency: 80% × 125/100 = 80% code rate
//
// 1000BASE-T: PAM-5 + Trellis coded
// PAM-5: 5 voltage levels, log2(5) = 2.32 bits/symbol
// 4 pairs × 125 Msym/s × 2 bits/sym = 1000 Mb/s
// Trellis coding uses 1 extra bit for error correction
// Net: 2 data bits/symbol per pair
//
// 10GBASE-R: 64B/66B encoding
// 66-bit block: 64 data bits + 2 sync bits
// Code rate = 64/66 = 97.0%
// Symbol rate = 10.3125 Gbaud (10G / 0.97)
// Line rate on fibre: 10.3125 Gbaud NRZ
//
// 25GBASE-R: 64B/66B, single lane
// Line rate = 25.78125 Gbaud NRZ
//
// 40GBASE-SR4: 4 lanes × 10GBASE-R
// 4× 10.3125 Gbaud lanes
// 8 fibres total (4 TX + 4 RX), MPO-12 connector
//
// 100GBASE-SR4: 4 lanes × 25GBASE-R
// 4× 25.78125 Gbaud NRZ lanes
// 8 fibres (4 TX + 4 RX), MPO-12 connector
//
// 400GBASE-DR4: PAM-4 encoding (new at 400GbE!)
// PAM-4: 4 amplitude levels (00, 01, 10, 11)
// 2 bits/symbol → half the baud rate for same data rate
// BUT: noise margin reduced from 100% to ~33% between levels
// FEC (Forward Error Correction) is MANDATORY at 400GbE:
// KR FEC (clause 74): lightweight, for 10/25GbE over short copper
// RS-FEC (clause 91/108): Reed-Solomon(544,514) for 25G+ with PAM-4
// RS-FEC adds latency (~100-200ns) but fixes >1e-5 raw BER → 1e-12
//
// 400GBASE-DR4 specs:
// 4 lanes × 100 Gbaud PAM-4 = 4 × 106.25 Gbaud = 425 Gbaud total
// 4 SMF fibres, 500m reach
// Uses QSFP-DD or OSFP form factor
//
// 800GbE (IEEE 802.3df, emerging 2024):
// 8 lanes × 100 Gbaud PAM-4 = 800 Gb/s net
// Or 8 lanes × 112 Gbaud PAM-4 with RS-FEC
// Form factors: OSFP, QSFP-DD800
// Early deployments: hyperscale DC spine links (Meta, Google, Microsoft)
Modern data centres use a Clos network topology (spine-leaf / fat-tree) that scales linearly: adding more spine switches adds bandwidth, adding more leaf switches adds ports. Every leaf switch connects to every spine switch, creating equal-cost paths between any two servers. ECMP (Equal-Cost Multi-Path) routing distributes flows across all paths simultaneously. VXLAN (Virtual Extensible LAN) encapsulates Layer 2 frames in UDP to extend Layer 2 segments across a Layer 3 fabric, enabling VM mobility and multi-tenant isolation across thousands of physical hosts — solving the 4094 VLAN limit.
// Spine-Leaf data centre architecture
//
// Classic 2-tier Clos (Spine-Leaf):
//
// Server Server Server Server ... (N servers per leaf)
// | | | |
// [Leaf 1 switch — 48× 25GbE downlinks, 8× 100GbE uplinks]
// [Leaf 2 switch — 48× 25GbE downlinks, 8× 100GbE uplinks]
// [Leaf 3 switch — 48× 25GbE downlinks, 8× 100GbE uplinks]
// | | | | | | |
// [Spine 1] [Spine 2] [Spine 3] [Spine 4] [Spine 5]...
// (each spine: 64× 100GbE ports)
//
// Bandwidth calculation (example: 4 spine, 10 leaf):
// Uplink bandwidth from each leaf: 8× 100GbE = 800 Gb/s
// Downlink bandwidth to servers: 48× 25GbE = 1200 Gb/s
// Oversubscription ratio: 1200/800 = 1.5:1 (acceptable)
// Total east-west bandwidth: 4 spine × 64× 100G / 2 = 12.8 Tb/s
//
// VXLAN overlay for multi-tenancy:
// VNID (VXLAN Network Identifier): 24 bits → 16 million VNIs
// Solves 4094 VLAN limit of 802.1Q
//
// VXLAN encapsulation adds:
// 8B VXLAN header + 8B UDP + 20B IP + 14B Outer Ethernet = 50B overhead
// MTU requirement: 1500 (inner) + 50 (VXLAN) = 1550B
// → MUST enable jumbo frames (MTU ≥ 9000) on underlay fabric!
//
// BGP EVPN as VXLAN control plane (RFC 7432):
// Traditional VXLAN: flood-and-learn (like original Ethernet)
// BGP EVPN: MAC/IP route advertisement → unicast VXLAN
// Benefits: no flooding, scalable MAC learning, multi-homing
// Implementation:
// Arista EOS: 'vxlan vlan 10 vni 10010'
// Cisco NX-OS: 'vni 10010 l2' under EVPN instance
// Nokia SR Linux: EVPN native since inception
// FRRouting: open-source BGP-EVPN implementation
//
// Real hardware (hyperscale data centre):
// Leaf switch: Arista 7050CX3-32S (32×100GbE, 2× 10GbE mgmt)
// Spine switch: Arista 7800R3 (576×100GbE, modular)
// Super-spine: Arista 7900 (4.8 Tb/s, for 3-tier fabrics)
// Alternatives:
// Cisco Nexus 9000 series (N9K-C93180YC-FX: 48×25G+6×100G)
// Juniper QFX10000 series
// Broadcom Trident4 ASIC (bare-metal): Dell Z9432F, EdgeCore 7726
// NVIDIA Spectrum-4: 51.2 Tb/s switching capacity (SN5600)
Standard Ethernet was designed for best-effort data delivery — it does not guarantee when a frame will arrive. Industrial automation requires deterministic communication: a motor drive must receive its velocity setpoint within a fixed time window every cycle, or the machine will malfunction. Industrial Ethernet protocols adapt standard Ethernet hardware to meet these requirements — using hardware timestamping, priority queuing, time-slotted transmission, and synchronised clocks. Understanding the difference between standard, real-time, and isochronous real-time Ethernet is essential for industrial network design.
Check if your cycle time budget is achievable for PROFINET RT/IRT or EtherCAT. Enter your device count, data volume, and required update rate.
PROFINET (Process Field Network) is the leading industrial Ethernet standard in Europe, developed by PROFIBUS International (PI) and standardised in IEC 61158 and IEC 61784. It runs on standard Ethernet hardware and uses three communication classes: NRT (Non-Real-Time, standard TCP/IP), RT (Real-Time, direct Ethernet frames, 1–10ms cycles), and IRT (Isochronous Real-Time, hardware-synchronised, ≤ 1ms cycles, ≤ 1µs jitter). PROFINET uses GSDML (General Station Description Markup Language) files — XML device descriptions that engineering tools (TIA Portal, STEP 7) use to configure devices automatically.
// PROFINET communication classes
//
// ── NRT (Non-Real-Time) ──────────────────────────────────────
// Uses: standard TCP/IP (port 34964 = 0x88A4 for PN-IO)
// Cycle time: 100ms–∞ (best effort)
// Use for: device configuration, diagnostics, web server, SNMP
// No special switch requirements
//
// ── RT (Real-Time) ───────────────────────────────────────────
// Uses: Ethernet frames directly (EtherType 0x8892)
// Bypasses TCP/IP stack → low latency
// Cycle time: 1–512ms (configurable)
// Jitter: ≤ 1ms
// Switch requirement: standard managed switch (no special HW)
// VLAN priority: CoS 6 (802.1p) on all RT frames
// Most PROFINET IO applications use RT class
//
// ── IRT (Isochronous Real-Time) ───────────────────────────────
// Uses: time-slotted Ethernet with hardware synchronisation
// PTP (IEEE 1588v2) clock sync: ≤ 1µs accuracy between devices
// Cycle time: 250µs–4ms
// Jitter: ≤ 1µs (hardware-enforced)
// Switch requirement: PROFINET IRT-capable ASIC (Siemens SCALANCE,
// Hirschmann MICE, Phoenix Contact FL SWITCH)
// Transmission window: time is divided into:
// IRT window (red phase): deterministic, for IRT frames
// Open window (green phase): standard Ethernet (RT/NRT)
// Use for: servo drives, CNC axes, motion coordination
//
// Siemens PROFINET device naming:
// Every device has a 'Device Name' (ASCII, ≤ 240 chars)
// Assigned by engineering tool or via DCP (Discovery and Config Protocol)
// DCP runs on Ethernet multicast 01:0E:CF:00:00:00
// TIA Portal → 'Assign device name' → sends DCP Set-Name frame
// Device uses name to request its IP from the controller
//
// PROFINET topology discovery:
// LLDP (IEEE 802.1AB) used to discover physical topology
// Siemens TIA Portal shows physical connection map
// Neighbor detection enables automatic configuration checks
//
// GSD/GSDML files:
// Manufacturer-supplied XML file: describes device parameters,
// modules, submodules, supported cycle times, alarm types
// Download from manufacturer website, import into TIA Portal
// Example: Siemens ET200SP → GSDML-V2.4-Siemens-ET200SP-20231201.xml
//
// Real devices (PROFINET):
// Controllers: Siemens S7-1500 (S7-1518: 1000 IO devices, 125µs IRT)
// IO devices: Siemens ET200SP, ET200MP, Weidmüller U-Remote,
// Phoenix Contact Axioline, Beckhoff EK1100 (EtherCAT bridge)
// Drives: Siemens SINAMICS S120 (IRT servo), SINAMICS G120 (RT)
// Switches: Siemens SCALANCE X308-2M (IRT, managed, -40°C)
// Hirschmann MICE (managed, IRT option)
// Phoenix Contact FL SWITCH 2208 (IRT capable)
EtherNet/IP (Ethernet Industrial Protocol) is dominant in North America, developed by Rockwell and standardised by ODVA. It uses standard TCP/IP and UDP, with the CIP (Common Industrial Protocol) application layer — the same protocol as DeviceNet and ControlNet but over Ethernet. EtherCAT (Ethernet for Control Automation Technology), developed by Beckhoff, uses a unique "processing on the fly" mechanism: frames pass through each slave sequentially, each slave reading/writing its data in nanoseconds without buffering — achieving < 100µs cycle times. TSN (Time-Sensitive Networking, IEEE 802.1) adds determinism to standard Ethernet through time-slotted scheduling (802.1Qbv), frame preemption (802.1Qbu), and clock synchronisation (802.1AS = gPTP) — enabling a single network for both IT and OT traffic.
// EtherNet/IP — CIP communication
//
// EtherNet/IP protocol stack:
// Application: CIP (Common Industrial Protocol)
// Transport: TCP (explicit messaging) or UDP (implicit/I/O)
// Network: IP
// Link: Ethernet (standard 802.3)
//
// CIP Implicit I/O (cyclic, real-time):
// UDP/IP multicast, port 2222
// Cycle time: 1–3200ms (typical 2–10ms for motion)
// I/O Assembly objects: input (consumed), output (produced)
// EDS (Electronic Data Sheet) file: equivalent of GSDML
//
// CIP Explicit Messaging (acyclic, request/response):
// TCP, port 44818
// Used for: parameterisation, diagnostics, recipe download
//
// Rockwell Logix5000 tag-based addressing:
// No fixed I/O addresses — tags map to CIP objects
// RSLogix 5500 / Studio 5000 automatically maps EDS modules
//
// ═══════════════════════════════════════════════════════════════
// EtherCAT — 'Processing on the fly'
//
// Master sends one large frame containing all slaves' data
// Each EtherCAT slave reads/writes its segment as frame passes
// Frame returns to master with all inputs filled
// No store-and-forward per slave — processing time: nanoseconds
//
// EtherCAT frame: EtherType 0x88A4
// Each datagram within frame: address, data offset, length
// Topology: Line (daisy-chain), Ring (redundancy), Star (with junction)
// Standard Cat5e UTP — no special cable needed
// Distance: 100m between nodes (Cat5e), 20m (EtherCAT+EL9800 LVDS)
//
// EtherCAT performance:
// 1000 I/O per cycle: 30µs cycle time achievable
// Distributed Clock: hardware sync ≤ 1µs jitter
// Jitter control: SYNC0/SYNC1 signals from master clock
//
// EtherCAT slaves (Beckhoff EtherCAT Terminals):
// EK1100: EtherCAT coupler (converts to E-Bus)
// EL1008: 8× digital input 24VDC, 3ms filter
// EL2008: 8× digital output 24VDC, 0.5A
// EL3004: 4× analog input ±10V, 12-bit
// EL4002: 2× analog output ±10V, 12-bit
// EL6695: EtherCAT bridge (connects two EtherCAT networks)
//
// ═══════════════════════════════════════════════════════════════
// TSN — Time-Sensitive Networking
//
// TSN standards family:
// IEEE 802.1AS: gPTP — generalised Precision Time Protocol
// Clock sync accuracy: < 1µs across 15 hops
// Used by: PROFINET IRT, EtherCAT DC, AVB audio
// IEEE 802.1Qbv: Time-Aware Shaper (TAS)
// Time gate schedule: each queue has open/closed time windows
// Deterministic transmission: zero jitter for scheduled traffic
// IEEE 802.1Qbu + 802.3br: Frame Preemption
// Low-latency traffic can interrupt a non-preemptible frame
// Preemption reduces worst-case latency for highest-priority traffic
// IEEE 802.1Qcc: Configuration model (CNC, CUC)
// Centralised Network Configuration: stream reservation
// IEEE 802.1CB: Frame Replication and Elimination (FRE)
// Redundant paths with seamless failover (PRPv2 over TSN)
//
// TSN hardware (available 2023+):
// Intel Core Tiger Lake/Alder Lake: built-in TSN gPTP controller
// Siemens SCALANCE X200 IRT: TSN-capable managed switch
// Cisco IE3400: TSN industrial switch (802.1AS, 802.1Qbv)
// Hirschmann RSP20-16: RSTP + TSN option
// Texas Instruments SITARA AM64x: TSN-enabled SoC for PLC
// NXP S32G: automotive Ethernet + TSN processor
Ethernet networks face both accidental misconfigurations and deliberate attacks at Layer 2. Unlike IP-layer attacks that are well-known, Layer 2 attacks — MAC flooding, ARP spoofing, VLAN hopping, Spanning Tree manipulation, DHCP starvation — are less understood but equally dangerous. Defending against them requires a combination of switch security features, monitoring tools, and network segmentation. Management and visibility are equally critical: you cannot secure or troubleshoot what you cannot see.
Simulate common Layer 2 attacks and their countermeasures. See the attack traffic, the switch response, and whether the defence is effective.
ARP Spoofing (Poisoning): an attacker sends gratuitous ARP replies mapping their MAC to a legitimate IP, poisoning the ARP caches of other hosts — all traffic destined for the victim IP is redirected through the attacker (man-in-the-middle). Mitigation: Dynamic ARP Inspection (DAI) on the switch validates ARP packets against a DHCP snooping table. DHCP Starvation: attacker sends DISCOVER packets with random MACs, exhausting the DHCP pool — no new devices can get an IP. Mitigation: DHCP snooping rate limiting. VLAN Hopping: two methods (switch spoofing, double tagging) allow an attacker to send frames into a VLAN they should not have access to. Mitigation: disable DTP, use dedicated unused native VLAN.
// Layer 2 security configuration — Cisco IOS
//
// ── DHCP SNOOPING ────────────────────────────────────────────
ip dhcp snooping ! Enable globally
ip dhcp snooping vlan 10,20,30 ! Enable per-VLAN
no ip dhcp snooping information option ! Disable option 82 (usually)
! Trusted ports: only uplinks to DHCP servers/routers
interface GigabitEthernet0/1 ! Uplink to router
ip dhcp snooping trust
! Untrusted: all access ports (default)
interface range GigabitEthernet0/5-24
ip dhcp snooping limit rate 15 ! Max 15 DHCP packets/second
! Exceeding rate → port disabled (rate-limit violation)
// ── DYNAMIC ARP INSPECTION (DAI) ─────────────────────────────
ip arp inspection vlan 10,20,30
ip arp inspection log-buffer entries 1024
interface GigabitEthernet0/1 ! Trusted: uplink
ip arp inspection trust
! All access ports: untrusted (default)
! DAI checks each ARP against DHCP snooping binding table
! Invalid ARP (MAC/IP not matching binding) → DROP + log
// ── 802.1X PORT-BASED AUTHENTICATION ─────────────────────────
aaa new-model
aaa authentication dot1x default group radius
aaa authorization network default group radius
dot1x system-auth-control
interface GigabitEthernet0/10
authentication port-control auto ! Enable 802.1X on port
dot1x pae authenticator
spanning-tree portfast
! Device must authenticate via RADIUS before port opens
! Supports: EAP-TLS (certificates), PEAP (username/password)
! Works with: Cisco ISE, Microsoft NPS, FreeRADIUS
// ── STORM CONTROL (broadcast/multicast/unicast rate limiting) ─
interface GigabitEthernet0/10
storm-control broadcast level 10 ! Max 10% of link for broadcasts
storm-control multicast level 10
storm-control unicast level 80 ! Max 80% for unknown unicast
storm-control action shutdown ! Shutdown port on violation
storm-control action trap ! Send SNMP trap
// ── MACsec (IEEE 802.1AE) — Layer 2 Encryption ───────────────
! MACsec encrypts Ethernet frames hop-by-hop (switch port to switch port)
! Provides: confidentiality, integrity, replay protection
! EtherType 0x88E5 identifies MACsec frames
! Adds: 16-byte SecTAG + 16-byte ICV = 32B overhead
! MKA (MACsec Key Agreement, 802.1X-2010) negotiates keys
!
! Cisco: MACsec on Catalyst 9000 (hardware, line-rate encryption)
key chain KC1 macsec
key 01
key-string 0123456789ABCDEF0123456789ABCDEF
cryptographic-algorithm aes-128-cmac
mka policy MKA_POLICY
macsec-cipher-suite gcm-aes-128
interface GigabitEthernet0/1
macsec
mka policy MKA_POLICY
mka pre-shared-key key-chain KC1
Network monitoring at Layer 2 requires understanding several tools. SNMP (Simple Network Management Protocol): polls switch MIBs for counters (errors, utilisation, CPU, temperature). LLDP (Link Layer Discovery Protocol, IEEE 802.1AB): devices advertise their capabilities and physical location — allows topology auto-discovery. CDP (Cisco Discovery Protocol): proprietary equivalent to LLDP. RSPAN / ERSPAN: Remote SPAN copies frames from a monitored port to a monitoring station across the network — essential for capturing traffic on remote switches. NetFlow/sFlow: sample flow statistics (src/dst IP, port, bytes) for traffic analysis without full packet capture.
// Network monitoring — SNMP, SPAN, LLDP
//
// ── LLDP CONFIGURATION ───────────────────────────────────────
lldp run ! Enable globally (Cisco IOS)
! Each port sends LLDPDUs every 30s (default)
! LLDP TLVs advertised:
! Chassis ID, Port ID, TTL
! System Name, System Description
! Port Description
! System Capabilities (Bridge, Router, WLAN AP...)
! Management Address (IP)
! IEEE 802.1 extension: VLAN name, Port VLAN ID
! IEEE 802.3 extension: MAC/PHY config (speed/duplex)
! LLDP-MED (Media Endpoint Discovery): PoE power, VLAN
show lldp neighbors detail ! Show discovered neighbors
show lldp neighbors ! Summary table
// ── SNMP v3 (secure, authenticated + encrypted) ───────────────
snmp-server group MONITORING v3 priv
snmp-server user NMSUSER MONITORING v3
auth sha AUTHPASSWORD1234
priv aes 128 PRIVPASSWORD5678
snmp-server host 10.10.99.10 version 3 priv NMSUSER
snmp-server enable traps
! Key OIDs for Ethernet monitoring:
! ifInErrors (1.3.6.1.2.1.2.2.1.14): input errors
! ifOutErrors (1.3.6.1.2.1.2.2.1.20): output errors
! ifInDiscards (1.3.6.1.2.1.2.2.1.13): input drops
! ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6): 64-bit byte counter
! dot3StatsFCSErrors: CRC/FCS errors (in/out)
! entPhySensorValue: temperature, fan speed
// ── SPAN / RSPAN / ERSPAN (packet capture) ───────────────────
! Local SPAN: copy frames to a local monitoring port
monitor session 1 source interface GigabitEthernet0/5 both
monitor session 1 destination interface GigabitEthernet0/24 encapsulation replicate
! GigabitEthernet0/24 → Wireshark laptop
! RSPAN: copy across network to a remote switch port
vlan 999
remote-span
monitor session 2 source interface GigabitEthernet0/5 rx
monitor session 2 destination remote vlan 999
! On remote switch:
monitor session 1 source remote vlan 999
monitor session 1 destination interface GigabitEthernet0/48
! ERSPAN (Encapsulated, supports routing across IP networks):
monitor session 3 type erspan-source
source interface GigabitEthernet0/5 both
destination
erspan-id 1
ip address 10.10.99.20 ! Wireshark host IP
// ── WIRESHARK FILTERS for Ethernet analysis ──────────────────
! Show only STP BPDUs:
stp
! Show LLDP frames:
lldp
! Show LACP:
slow (EtherType 0x8809)
! Show ARP:
arp
! Show 802.1Q tagged frames:
vlan
! Find broadcast storms:
eth.dst == ff:ff:ff:ff:ff:ff
! Show frames larger than 1500 bytes (jumbo):
frame.len > 1514
! Find CRC errors (if NIC not offloading FCS):
eth.fcs_bad == 1
! MAC address filter:
eth.addr == 00:1a:2b:3c:4d:5e
! Find slow or duplicate ARP:
arp.duplicate-address-detected
Ethernet troubleshooting follows a disciplined top-down or bottom-up approach through the OSI layers. Most problems are at Layer 1 (bad cable, wrong speed/duplex, faulty SFP) or Layer 2 (VLAN misconfiguration, STP loop, MAC table issue). A systematic methodology — verify physical first, then data-link, then network — prevents wasting hours debugging a software issue that is actually a bent pin in a patch cable.
Answer questions about your symptoms to follow the systematic troubleshooting methodology. Reaches the likely root cause and specific commands to verify.
Enter Cisco IOS 'show interfaces' counter values. The analyser diagnoses the likely fault from the error pattern.
Layer 1 problems are the most common and most overlooked. Symptoms: link LED not lit, port in err-disabled state, CRC errors, input errors, intermittent drops. Tools: cable tester (wiremap), cable certifier (Fluke DSX), optical power meter, OTDR (for fibre breaks), TDR (time-domain reflectometer for copper). Common faults: wrong patch cable (crossover vs straight, Cat5 vs Cat6A for 10GbE), too-long cable run (> 100m), damaged connector (bent pins), dirty fibre connector (use inspection scope + IEC 61300-3-35 for pass/fail), wrong SFP type (SMF transceiver on MMF cable = no link).
// Layer 1 troubleshooting — systematic checks
//
// STEP 1: Check link state
show interfaces GigabitEthernet0/5
! Desired output:
! GigabitEthernet0/5 is up, line protocol is up
! Hardware is Gigabit Ethernet, address is 0023.eadf.1234
! MTU 1500, BW 1000000 Kbit/s, DLY 10 usec
! duplex full, speed 1000Mb/s, media type RJ45
! input errors: 0, CRC: 0, frame: 0, overrun: 0, ignored: 0
!
! Problem indicators:
! 'is down, line protocol is down' → no cable or link
! 'is up, line protocol is down' → L2 issue (STP blocking? LACP?)
! 'err-disabled' → port security/BPDU guard triggered
! CRC errors > 0 → cable fault, noise, duplex mismatch
! input errors > 0 → bad cable, dirty fibre, SFP fault
! 'half-duplex' when expecting full → duplex mismatch!
// STEP 2: Check error counters
show interfaces GigabitEthernet0/5 counters errors
! Errors and their causes:
! CRC (FCS) errors: bad cable, dirty connector, EMI, duplex mismatch
! Frame errors (framing): duplex mismatch, bad NIC driver
! Runts (< 64B): collision fragments, duplex mismatch on half-duplex segment
! Giants (> 1518B): jumbo frames on non-jumbo port, or Ethernet header bug
! Late collisions (after 64B): duplex mismatch SURE sign — HDP sees collision, FDP doesn't back off
! Input drops: ingress buffer overflow (overloaded port or QoS issue)
! Output drops: egress buffer overflow (congestion)
// STEP 3: Optical power measurement (fibre links)
! Use calibrated optical power meter
! Measure at RX of each end
! Acceptable RX power: depends on transceiver type
! 1000BASE-SX: -9.5 dBm minimum, -3 dBm maximum (overload!)
! 10GBASE-SR: -11.1 dBm minimum, 0.5 dBm maximum
! 10GBASE-LR: -14.4 dBm minimum, 0.5 dBm maximum
! If RX < minimum: check:
! Dirty connector → clean with IEC 61300-3-35 grade D probe
! Wrong fibre type (SMF transceiver on MMF)
! Fibre break (use OTDR to locate)
! Too many connectors/splices (budget exceeded)
! If RX > maximum: add inline attenuator
// STEP 4: Cable certification results interpretation
! Fluke DSX-8000 test result failures:
! FAIL — NEXT (Near-End Crosstalk):
! Cause: pairs not maintained to connector (untwisted too far)
! Fix: re-terminate with max 13mm untwisted per TIA-568B
! FAIL — Return Loss:
! Cause: impedance mismatch — wrong keystone jack, cable kink, crush
! Fix: replace patch panel port or cable run
! FAIL — Wire Map:
! Cause: miswired pair (split pair), open wire, short
! Fix: re-terminate both ends, verify 568A or 568B consistently
! FAIL — Length:
! Cause: run exceeds 90m (permanent link) or 100m (channel)
! Fix: relocate IDF or add intermediate switch
! FAIL — Delay Skew:
! Cause: mixed cable types in one run, or very cheap cable
! Fix: replace cable — cannot be terminated around
Layer 2 problems are often more dramatic than Layer 1 — a broadcast storm can bring down a network in seconds, affecting hundreds of devices simultaneously. Symptoms include: network unreachable, switch CPU at 100%, all port LEDs blinking rapidly, SNMP traps flooding the NMS. STP loops are the most common catastrophic Layer 2 failure. VLAN misconfiguration is the most common cause of "I can ping the gateway but not the server" type issues. CAM table issues can cause security problems (unknown unicast flooding) or connectivity loss (MAC table overflow).
// Layer 2 troubleshooting — loops, STP, VLAN
//
// ── DETECTING A BROADCAST STORM ─────────────────────────────
show interfaces | include broadcast|input rate
! If broadcast rate >> 1000 packets/second on many ports → storm
! Identify source VLAN:
show interfaces | include Vlan|broadcast
! Find the physical loop:
show mac address-table dynamic ! CAM rapidly changing?
show spanning-tree detail | include ieee|from|is executing
! Look for Topology Change counter incrementing rapidly
// ── STP ISSUES ───────────────────────────────────────────────
show spanning-tree summary
! Check Root Bridge is where you expect it:
show spanning-tree vlan 10
! Root ID section shows current Root Bridge (MAC + priority)
! If wrong switch is Root: set correct switch to priority 4096
spanning-tree vlan 10 priority 4096
! Find ports in blocked/alternate state:
show spanning-tree vlan 10 | include BLK|ALT
! These ports will unblock on failure — verify they are correct
! STP convergence debugging:
debug spanning-tree events
! Shows port state changes, TC notifications, root bridge changes
! Excessive TCs indicate flapping link → find and fix physical fault
// ── VLAN TROUBLESHOOTING ─────────────────────────────────────
! 'I can ping the switch but not a device on VLAN 20'
! Step 1: Verify VLAN exists on both switches:
show vlan brief
! VLAN 20 should appear as 'active' — if missing: create it
! VLAN not in 'show vlan brief' = NOT active on this switch
! Step 2: Verify trunk is passing VLAN 20:
show interfaces trunk
! Look at 'VLANs allowed and active in management domain'
! VLAN 20 must appear; if not, check 'allowed vlan' config
! Step 3: Verify access port is in correct VLAN:
show interfaces GigabitEthernet0/10 switchport
! 'Access Mode VLAN: 20 (VLAN0020)' — correct
! 'Access Mode VLAN: 1 (default)' — WRONG! Reconfigure
! Step 4: Verify MAC is learned in correct VLAN:
show mac address-table vlan 20
! Device MAC should appear with correct port
! If missing: device hasn't sent a frame, or port VLAN wrong
// ── USEFUL CLEARING COMMANDS ─────────────────────────────────
clear mac address-table dynamic ! Flush entire CAM table
clear mac address-table dynamic vlan 20 ! Flush one VLAN
clear mac address-table dynamic interface gi0/5 ! Flush one port
clear spanning-tree detected-protocols ! Force STP re-negotiation
clear ip arp inspection statistics ! Reset DAI counters
errdisable recovery cause bpduguard ! Auto-recover errdisabled ports
errdisable recovery interval 30 ! Recovery timer (seconds)
The Ethernet ecosystem spans silicon vendors, switch manufacturers, transceiver makers, cabling vendors, and test equipment suppliers. Here are the key players in each category with real product references.
| Standard | Speed | Medium | Max dist. | Encoding | Pairs/Fibres | IEEE clause |
|---|---|---|---|---|---|---|
| 10BASE-T | 10 Mb/s | Cat3 UTP | 100m | Manchester | 2 pairs | clause 14 |
| 100BASE-TX | 100 Mb/s | Cat5 UTP | 100m | 4B5B+MLT-3 | 2 pairs | clause 25 |
| 1000BASE-T | 1 Gb/s | Cat5e UTP | 100m | PAM-5 | 4 pairs | clause 40 |
| 1000BASE-SX | 1 Gb/s | OM1/OM2 MMF | 550m | NRZ 8B10B | 2 fibres | clause 38 |
| 1000BASE-LX | 1 Gb/s | SMF | 5 km | NRZ 8B10B | 2 fibres | clause 38 |
| 10GBASE-T | 10 Gb/s | Cat6A UTP | 100m | 128DSQ | 4 pairs | clause 55 |
| 10GBASE-SR | 10 Gb/s | OM3 MMF | 300m | NRZ 64B/66B | 2 fibres | clause 49 |
| 10GBASE-LR | 10 Gb/s | SMF | 10 km | NRZ 64B/66B | 2 fibres | clause 49 |
| 25GBASE-SR | 25 Gb/s | OM4 MMF | 100m | NRZ 64B/66B | 2 fibres | clause 112 |
| 40GBASE-SR4 | 40 Gb/s | OM3 MMF | 100m | NRZ 64B/66B | 8 fibres (MPO) | clause 86 |
| 100GBASE-SR4 | 100 Gb/s | OM4 MMF | 100m | NRZ 64B/66B | 8 fibres (MPO) | clause 95 |
| 100GBASE-LR4 | 100 Gb/s | SMF WDM | 10 km | NRZ 64B/66B (4λ) | 2 fibres | clause 88 |
| 400GBASE-DR4 | 400 Gb/s | SMF PAM-4 | 500m | PAM-4 RS-FEC | 8 fibres (MPO) | clause 124 |
| 400GBASE-LR4 | 400 Gb/s | SMF PAM-4 | 10 km | PAM-4 RS-FEC (4λ) | 2 fibres | clause 126 |
Test your understanding of Ethernet from fundamentals to data-centre architecture. All questions are engineer-grade: multiple plausible answers, detailed explanations.