34 Ethernet: PoE and Operations

34.1 Start With the Situation

The cable and Ethernet speed are selected, but the powered devices still share a limited switch budget. The team must calculate usable power, allow for losses, and prove the link remains supportable after deployment.

34.2 Overview

This route turns PoE calculations, failure modes, and field observations into an operations-ready Ethernet record.

This is part 2 of 2. Review Ethernet: Links and Standard Selection when you need the first route.

34.3 Learning Objectives

By the end of this chapter, you will be able to:

• calculate a PoE switch power budget
• identify Ethernet reliability and cabling failure modes
• record deployment evidence and escalation triggers

34.4 Chapter Roadmap

Follow the original sections below in order. They begin at the reviewed split boundary and keep every worked example, figure, check, and supporting banner with the section that owns it.

34.5 How the PoE Budget Calculator Works

Planning a PoE deployment requires matching the switch’s total power budget to the devices it must power. The interactive calculator below is the primary learning activity; this table explains the same logic without making learners read a long code listing.

Why this matters: A 48-port PoE switch might advertise 370 W total budget but support 30 W per port. If you connect 24 devices at 15 W each (360 W), the switch is near capacity and cannot support another powered device at full draw. Always calculate the aggregate budget, not just per-port limits.

PoE planning is the power version of speed negotiation: the port, switch budget, cable route, and device peak draw all have to agree at the same time.

34.6 Ethernet Reliability Contract

Ethernet is often chosen for IoT when the deployment needs predictable delivery more than mobility. A switched full-duplex link gives each device a dedicated path to a switch port, so the design removes radio contention and the old shared-medium collision model.

That reliability is not automatic. It depends on cable length, terminations, switch capacity, power budget, VLAN design, grounding, UPS coverage, and testing. A good Ethernet design records those constraints before the device is mounted high on a wall or bolted into a cabinet.

The practical contract is broader than “plug in a cable.” The device needs a cable plant that can hold the negotiated speed, a switch port with enough power and buffering, a labeled path through patch panels, and an upstream route that will not be saturated by video, telemetry, firmware updates, or management traffic. A stationary sensor may have a stable copper link while the service still fails because the closet switch lost UPS power or because several cameras share an undersized uplink.

For IoT teams, Ethernet is usually the right answer when physical access is possible and the device must be observable for years. The cable gives technicians a place to test continuity, pair order, length, link speed, duplex mode, PoE class, and error counters. Those measurements turn connectivity into evidence that can be reviewed before blaming firmware, cloud services, or radio coverage.

This is why the access-link decision should be made with facilities, network operations, and device owners in the same review. The cable route, switch closet, breaker panel, and maintenance window all become part of the connectivity design.

Pause at Figure 34.1 before carrying ethernet reliability contract forward. Its visual vocabulary joins Ethernet Wired Connectivity for IoT to Reliable, High-Bandwidth Communication via RJ45 Cables, which frames ethernet iot topology showing sensor and plc devices connected through cat5e or cat6 cables to an ethernet switch, gateway uplink, and poe-capable.

At Ethernet Wired Connectivity for IoT in Figure 34.1, compare the diagram with Reliable, High-Bandwidth Communication via RJ45 Cables; then locate IoT Sensor Node. That labelled check bounds ethernet iot topology showing sensor and plc devices connected through cat5e or cat6 cables to an ethernet switch, gateway uplink, and poe-capable. For ethernet reliability contract, retain IoT Sensor Node as evidence for the resulting choice.

34.7 Ethernet Deployment Record

A practical Ethernet record shows that the physical link, power budget, and network service all match the device’s job. This matters because most field failures are not caused by the Ethernet standard itself; they are caused by underspecified installation details.

Start the record at the device and walk outward. Capture the device model, MAC address, expected data rate, required PoE standard, cable category, measured run length, patch-panel label, switch, port number, VLAN, IP addressing source, gateway path, and owner. Then attach evidence: cable certification or tester results, observed negotiated speed and duplex, switch PoE allocation, baseline error counters, and a short load calculation for the uplink. This makes the installation auditable when a technician replaces a switch, moves a patch lead, or adds another high-bandwidth device to the same closet.

The record should also state the design margin. A PoE installation that passes at idle can still fail when heaters, pan-tilt motors, infrared illuminators, or radios enter peak draw. A gigabit access port can still become a bottleneck if many devices converge through a single 1 Gb/s uplink. Treat these margins as acceptance criteria during commissioning, not as notes to investigate after the deployment is already in service.

The deployment record is where the earlier choices become accountable. If the field evidence does not match the planned speed, power, and route, the release should pause before the device becomes hard to reach.

34.8 Duplex Fixes Collisions Only

Modern switched Ethernet does not use CSMA/CD on full-duplex links, so classic Ethernet collisions are gone. The failure modes move elsewhere: damaged pairs, marginal connectors, cable attenuation, duplex or speed mismatch, oversubscribed uplinks, PoE overload, spanning-tree loops, and unmanaged broadcast traffic.

Industrial Ethernet and TSN add another layer: timing becomes a scheduled resource. The physical link can be healthy while the system still fails if time-aware shapers, VLAN priority, clock synchronization, or switch queueing are misconfigured.

At link-up, auto-negotiation exchanges advertised capabilities and chooses speed, duplex, and flow-control behavior. A bad pair, poor termination, or marginal connector may still produce a link, but the port can downshift, flap, or accumulate frame check sequence and CRC errors under load. These symptoms are physical-layer evidence. They should be checked against cable length, bend radius, connector quality, electromagnetic exposure, and the actual speed reported by both ends of the link.

Above the cable, switching behavior decides whether the reliable access link remains useful. MAC address learning directs frames to the right port, VLAN tags separate traffic domains, and spanning tree or rapid spanning tree prevents loops when redundant paths exist. If those controls are wrong, broadcast storms, blocked ports, or accidental VLAN leaks can break devices whose local link lights still look healthy. PoE adds another hidden state machine: the powered device and power sourcing equipment classify load, apply power, and must survive inrush and peak draw without exhausting the switch budget.

An 802.1Q VLAN tag is a four-byte field inserted into the Ethernet frame after the source MAC address. The tag uses EtherType 0x8100, carries priority bits for traffic handling, and uses a 12-bit VLAN identifier, which gives 4096 possible codes before reserved values and operational policy reduce the usable set. Access ports usually send ordinary untagged frames for one assigned VLAN; trunk ports carry tagged frames for multiple VLANs. A configured native VLAN is the compatibility exception on many trunks: frames for that VLAN cross the trunk without a tag, so the native VLAN must be documented and kept consistent to avoid accidental leakage or confusing packet captures.

VLANs earn their place in an IoT deployment record as an isolation control, not just an addressing convenience. A building with HVAC controllers and room sensors alongside a point-of-sale system is a good concrete case: put HVAC controls and HVAC sensors on one VLAN and the POS terminals and card-payment server on another. Both groups can share the same physical switches and cable plant, but a broadcast storm, a misconfigured device, or a compromised sensor on the HVAC VLAN cannot reach payment traffic, and vice versa — the switch enforces the boundary instead of every device on the wire being trusted equally. The same reasoning applies to any IoT device class: keep cameras, gateways, or sensor fleets on their own VLAN, separate from corporate or guest traffic, so a compromised or noisy device has a smaller blast radius and broadcast domain rather than the whole site. For very large or multi-tenant sites where 4096 VLAN IDs alone are not enough, IEEE 802.1ad (“QinQ”) stacks a second 802.1Q tag outside the first, letting a provider network carry each customer’s or building’s full VLAN range inside one outer service-provider VLAN.

Long cable routes add a security and maintenance problem that a short patch lead hides. A submarine fiber, campus backbone, buried sensor trunk, or utility-corridor Ethernet run can fail because the cable is cut, crushed, flooded, bent past its radius limit, tapped, or damaged by construction and wildlife. Treat those runs as field infrastructure: record the route, burial or conduit protection, splice points, inspection owner, and the expected signal margin before the service depends on it.

Physical tapping is part of that review. A conductive tap makes direct electrical contact with a copper conductor; an inductive tap couples to electromagnetic fields and may be harder to notice because it does not require the same visible break. Optical fiber changes the details but not the principle: a bend, splice, or clamp can leak or disturb signal energy. Countermeasures start with physical inspection and route control, then add protective conduit, pressurized or monitored enclosures where justified, faster bitrate or optical-power baselines that make loss changes visible, and alarms on unexpected error, attenuation, or spectrum changes.

Time-domain reflectometry (TDR) turns cable troubleshooting into a measurement instead of a guess. The tester sends a pulse down the line and measures reflected energy. The delay estimates distance to the anomaly; the shape helps distinguish an open cut, short, bad termination, moisture intrusion, crushed section, splice, or tap. The same idea explains why a wave pulse reflects differently at a soft boundary than at a hard boundary: impedance changes decide what returns to the tester.

Environmental protection belongs in the same record. Rodents may chew cable jackets, insects may attack fills or seals, birds may nest on aerial routes, and water can enter damaged sheath or poor glands. A robust design uses the right sheath, armored or wrapped sections where needed, sealed joints, strain relief, slack loops, drip paths, and periodic inspection. The important lesson for IoT is operational: do not call a wired link “reliable” until the physical route has a diagnostic method and a maintenance plan.

For deterministic industrial traffic, the failure pattern can be even subtler. Time-Sensitive Networking features such as IEEE 802.1AS time synchronization and IEEE 802.1Qbv time-aware scheduling depend on compatible devices, clock design, queue configuration, and profile discipline across the path. A single unmanaged switch, gateway boundary, or unverified queue policy can destroy timing even though ordinary pings and file transfers appear normal.

34.9 Summary

Ethernet remains the gold standard for wired IoT connectivity, offering unmatched reliability and performance for stationary devices.

34.10 What’s Next?