1.4 Switching and Forwarding

The previous section covered TCP/IP — how packets are addressed and routed across networks. But before a packet can be routed, it needs to travel across the local network segment. That is the job of the switch. Understanding how a switch makes forwarding decisions explains why VLANs work, why MRP topology changes flush the MAC table, and why a duplex mismatch causes intermittent problems with no error messages.

Why Switches Replaced Hubs

A hub is a Layer 1 device. It receives a signal on one port and repeats it on every other port. Every device on a hub shares the same collision domain. When two devices transmit simultaneously, a collision occurs. Both stop, wait a random time, and retry. As the number of devices grows, collisions become more frequent and throughput collapses.

A switch is a Layer 2 device. It receives a frame, reads the destination MAC address, and forwards the frame only to the port where that device lives. Each port is its own collision domain. Full-duplex operation eliminates collisions entirely. A 24-port switch gives each device a dedicated 1 Gbps path, not a shared one.

To forward a frame to the right port, the switch needs to know which device is on which port. It learns this through the MAC address table.

The MAC Address Table

Every switch maintains a MAC address table (also called a CAM table, for Content Addressable Memory). It maps MAC addresses to switch ports.

The table is stored in TCAM (Ternary Content Addressable Memory) hardware. TCAM searches all entries simultaneously in a single clock cycle, regardless of table size. This is why a switch forwards frames at line rate even with thousands of MAC entries.

When a frame arrives, the switch reads the source MAC and records it in the table with the incoming port and VLAN. This is MAC learning. When the switch looks up the destination MAC and finds it, it forwards the frame to that port only. When it does not find it, it floods the frame to all ports in the VLAN.

Entries expire after the aging timeout (default: 300 seconds). When a device moves to a different port, the old entry persists until it ages out. During that window, frames go to the wrong port. MRP topology changes flush the MAC table immediately for exactly this reason — without flushing, traffic goes to the wrong port for up to 300 seconds after a ring failover.

The MAC table has a finite size. What happens when it fills up matters for both security and performance.

What Happens When the Table Is Full

When the TCAM is full, the switch cannot learn new MAC addresses. It falls back to flooding all unknown unicast frames to all ports in the VLAN. The switch behaves like a hub. Every device on the VLAN receives every frame.

This is the mechanism behind MAC flooding attacks. An attacker sends frames with thousands of fake source MACs, fills the table, and then receives all traffic on the segment. Table sizes vary by hardware: entry-level switches (RS20) hold around 8,000 entries, mid-range (MICE) around 16,000, and high-end (MACH) 64,000 or more.

Beyond the MAC table, the switch also introduces a small but measurable delay when forwarding each frame. This matters for MRP convergence calculations.

Store-and-Forward Latency

In store-and-forward mode, the switch receives the entire frame, checks the FCS, and then forwards it. The forwarding latency is:

latency = (frame_size_bits / link_speed_bps) + processing_time

For a 1518-byte frame at 1 Gbps: approximately 17 µs per hop. For a 10-switch ring at 1 Gbps with 64-byte frames: approximately 55 µs total. This is why ring size has minimal impact on MRP convergence time — the switching latency is negligible compared to the MAC flush time of around 50 ms.

One practical consequence of store-and-forward is that the switch checks the FCS before forwarding. Corrupt frames are discarded at the switch, not passed on to the PLC. This is the right behavior for OT networks, but it means CRC errors on a ring port are a silent problem — the PLC never sees them, only the switch counter increments.

Auditing Switch Ports

A duplex mismatch on a ring port causes intermittent CRC errors and poor throughput. Checking each switch manually takes time. The following script connects to all switches in a ring via SSH and reports any port with half-duplex or unexpected speed settings:

# pip install netmiko
from netmiko import ConnectHandler
import re

SWITCHES = [
    {"host": "192.168.1.100", "name": "SW-Cell1-MRM"},
    {"host": "192.168.1.101", "name": "SW-Cell1-MRC1"},
]

def get_port_status(host: str) -> list[dict]:
    conn = ConnectHandler(device_type="hirschmann_ssh", host=host,
                          username="admin", password="private")
    output = conn.send_command("show interfaces status")
    conn.disconnect()
    ports = []
    for line in output.splitlines():
        m = re.match(r"(\S+)\s+(up|down)\s+(\S+)\s+(full|half)", line, re.I)
        if m:
            ports.append({"port": m.group(1), "status": m.group(2),
                          "speed": m.group(3), "duplex": m.group(4)})
    return ports

for sw in SWITCHES:
    ports = get_port_status(sw["host"])
    issues = [p for p in ports if p["duplex"] == "half" or p["status"] == "down"]
    if issues:
        print(f"\n{sw['name']} — issues:")
        for p in issues:
            print(f"  {p['port']:8s}  {p['status']:6s}  {p['speed']:10s}  {p['duplex']}")
    else:
        print(f"{sw['name']}  OK")

Any port showing half duplex needs immediate attention. Set speed and duplex explicitly on both ends of that link. Any port that is down on a ring switch is a potential ring failure.

Key Takeaways

TCAM enables line-rate forwarding

The MAC table is stored in hardware that searches all entries in one clock cycle. This is why switches forward at wire speed regardless of table size.

MAC flush is critical after MRP failover

Without MAC table flushing after a topology change, traffic goes to the wrong port for up to 300 seconds. Verify that MRP_TopologyChange propagates to all ring members.

What Comes Next

Switching operates within a single network segment. The next chapter covers VLANs — how to divide a single physical switch into multiple logical segments, which is the foundation of every industrial network security design.

References

• IEEE 802.1AB-2016 — Station and Media Access Control Connectivity Discovery (LLDP)
• Lopes, K. (2023). Netmiko Documentation. https://github.com/ktbyers/netmiko
• Hirschmann. (2023). Reference Manual — HiOS-2S/3S/3A Switches. Belden/Hirschmann.