1.4 Switching and Forwarding

The previous section covered TCP/IP — how packets are addressed and routed across networks. Before a packet is routed, the packet needs to travel across the local network segment. The switch handles that job. 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 issues with no log messages.

Why Switches Replaced Hubs

A hub is a Layer 1 device. A hub receives a signal on 1 port and repeats the signal on every other port. Every device on a hub shares the same collision domain. When 2 devices transmit simultaneously, a collision occurs. Both devices 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. A switch receives a frame, reads the destination MAC address, and forwards the frame only to the port where that device lives. Each port is a separate collision domain. Full-duplex operation eliminates collisions entirely. A 24-port switch gives each device a dedicated 1 Gbps path, not a shared path.

To forward a frame to the right port, the switch needs to know which device is on which port. The switch 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). The table 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. TCAM is the reason 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 the source MAC in the table with the incoming port and VLAN. This process is MAC learning. When the switch looks up the destination MAC and finds a match, the switch forwards the frame to that port only. When no match exists, the switch 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 the entry ages out. During that window, frames go to the wrong port. MRP topology changes flush the MAC table immediately for 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. The behavior when the table fills up matters for both security and performance.

What Happens When the Table Is Full

When the TCAM is full, the switch has no capacity to learn new MAC addresses. The switch 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 delay 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 the frame. The forwarding latency is:

latency = (frame_size_bits / link_speed_bps) + processing_time

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

1 practical consequence of store-and-forward: the switch checks the FCS before forwarding. Corrupt frames are discarded at the switch, not passed on to the PLC. This is the correct behavior for OT networks. However, CRC issues on a ring port are a silent issue — the PLC never sees the CRC issues. Only the switch counter increments.

Auditing Switch Ports

A duplex mismatch on a ring port causes intermittent CRC issues 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 discontinuity.

Key Takeaways

TCAM enables line-rate forwarding

The MAC table is stored in hardware that searches all entries in 1 clock cycle. Switches forward at wire speed regardless of table size.

MAC flush is needed 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. VLANs are 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.