AGL Component Library By Precision AGL Academy

Network Redundancy Switch

A high‑availability industrial Ethernet switch that provides automatic failover and network redundancy for critical AGL communication links. Deployed in ring or dual‑homing topologies, the Network Redundancy Switch ensures uninterrupted data flow between the ALCMS, remote substations, and field equipment, even in the event of a cable break or switch failure, with recovery times as fast as 10‑50 ms.

Network Redundancy Switch

Image disclaimer: For identification and illustration only. It may show a product by another manufacturer and may not depict the exact item described; it is not a statement of any product’s quality, approval or performance. Third-party image and trademark rights belong to their owners. See full notice.

Overview

What Is It?

A Network Redundancy Switch (also known as a redundant Ethernet switch, high‑availability switch, or industrial redundancy switch) is a managed industrial Ethernet switch that incorporates advanced redundancy protocols to ensure uninterrupted network connectivity in the event of a link or device failure. In AGL applications, where communication between the ALCMS, CCRs, remote I/O, and field equipment is mission‑critical, network redundancy is essential to maintain control and monitoring capabilities during cable breaks, switch failures, or maintenance activities.

Key characteristics of the Network Redundancy Switch include:

  • Redundancy Protocols: Supports industry‑standard redundancy protocols such as Ethernet Ring Protection Switching (ERPS, ITU‑T G.8032), Rapid Spanning Tree Protocol (RSTP), Multiple Spanning Tree Protocol (MSTP), Parallel Redundancy Protocol (PRP), and High‑availability Seamless Redundancy (HSR).
  • Fast Failover: Provides sub‑second (typically 10‑50 ms) recovery time, ensuring minimal disruption to time‑sensitive control traffic.
  • Ring Topology Support: Enables the construction of resilient ring networks with automatic loop detection and protection switching.
  • Dual Homing: Supports dual‑homing connections to two separate switches or networks, providing redundant uplinks for critical nodes.
  • Redundant Power Supplies: Includes dual, hot‑swappable power inputs (24 VDC) to eliminate single points of failure.
  • Wide Operating Temperature: Industrial‑grade design for -40°C to +75°C operation, suitable for outdoor substations and equipment shelters.
  • Comprehensive Management: Provides SNMP, web GUI, and CLI for configuration, monitoring, and diagnostics, including ring status, failover logs, and performance statistics.

In airfield lighting systems, the Network Redundancy Switch is deployed at critical aggregation points — such as the main control room, substations, and equipment shelters — to create a resilient fibre optic backbone. It ensures that a single cable cut or switch failure does not compromise AGL control and monitoring, supporting the high availability requirements of 24/7 airfield operations.

Purpose

Purpose & Function

The redundancy switch exists because a single cable cut or switch failure should never be able to leave an operator unable to see or control part of the airfield lighting system — and on a live airfield, a backhoe strike, rodent damage, or a failed port is a matter of when, not if. Without redundancy protocols, that kind of routine failure would silently sever the ALCMS's connection to whatever equipment sat on the far side of it, and the operator might not even know they'd lost visibility until something else went visibly wrong. Sub-second failover is the specific number that matters here: it's fast enough that a brief link interruption resolves before it can cause a control action to be missed or a status update to go stale, effectively making the network as reliable as the fixtures it connects rather than a weak link beneath them.

Application

Where Is It Used?

Network Redundancy Switches are deployed in all critical points of the AGL communication infrastructure where high availability is required. Key applications include:

  • ALCMS Core Network: Providing redundant connectivity between the ALCMS server, workstations, and the airfield fibre backbone.
  • CCR Substation Aggregation: Aggregating multiple CCR communication links and providing a redundant fibre uplink to the control room.
  • Runway Edge Cabinet Rings: Creating resilient ring networks along the runway to connect edge cabinets, ensuring no single cable break isolates a segment.
  • Approach Lighting Systems: Providing redundant Ethernet connectivity to approach light sequencers and flasher units.
  • RWSL (Runway Status Light) System: Ensuring reliable, low‑latency communication between RWSL processing units and field controllers.
  • Inter‑building Links: Providing redundant fibre connections between terminal buildings, ATC towers, and maintenance facilities.
  • Critical Sensor Networks: Ensuring uninterrupted data from weather stations, visibility sensors, and RVR systems.
Placement

Installation & Location

Redundancy switches are mounted in 19-inch equipment racks or wall-mounted DIN-rail enclosures at each network aggregation point — the main control room, CCR substations, and field equipment shelters — rather than out in the open at individual fixtures. Fibre optic runs connect each switch to its neighbours around the ring, typically routed in dedicated ducting alongside but physically separate from the AGL power circuits to avoid electromagnetic interference and to keep a single trench excavation from risking both power and data continuity at once. Dual 24 VDC power inputs are fed from separate circuits or UPS-protected sources so a single power failure cannot take the switch down along with its data path, and the enclosure is selected for the ambient conditions of its location — sealed and temperature-rated for an unconditioned substation, standard rack-mount for a climate-controlled control room. Ring topology design means the physical cable route between switches is planned to avoid a single duct run or conduit carrying more than one segment of the same ring, so that one excavation or cable fault cannot break the ring in two places at once.

Function

How Does It Work?

The Network Redundancy Switch operates by implementing redundancy protocols that automatically detect and recover from network failures. Key functional aspects include:

  • Ring Protection (ERPS/RSTP): In a ring topology, the switch uses ERPS (G.8032) or RSTP to designate one switch as the "ring master" (for ERPS) or the root bridge (for RSTP). The protocol continuously monitors the ring integrity by sending and receiving health messages. If a link or switch fails, the protection mechanism re‑routes traffic around the ring, typically within 10‑50 ms (ERPS) or 1‑2 seconds (RSTP).
  • Dual Homing / Link Aggregation: The switch supports multiple uplinks (e.g., two fibre links to different core switches) and can use Link Aggregation (LACP) or active‑standby failover. In the event of an uplink failure, traffic is automatically switched to the backup link.
  • Redundant Power Inputs: The switch includes two independent power inputs (24 VDC) with diode‑or'ing or active load sharing. If one power supply fails, the other continues to power the switch without interruption.
  • Fast Recovery Mechanisms: The switch monitors link status and protocol states, and upon detecting a failure, immediately updates the forwarding tables and re‑routes traffic. For ERPS, the recovery is triggered by the ring master, which sends a flush message to all switches to clear their MAC address tables and recompute the forwarding path.
  • Diagnostics and Monitoring: The switch provides comprehensive monitoring of ring status, link state, power supply health, and traffic statistics via SNMP, web GUI, or CLI. Alarms (e.g., ring broken, power supply failure) can be sent to the ALCMS via SNMP traps or alarm contacts.
  • Traffic Prioritization (QoS): To ensure that critical control traffic (e.g., PLC commands) is not delayed during failover, the switch supports IEEE 802.1p and DiffServ QoS, prioritising high‑priority frames.

The switch is typically configured via a web interface or command line, with redundancy settings tailored to the network topology (ring, dual‑homing, or hybrid). It is designed for hot‑swappable power supplies and fanless operation for high reliability.

Resilience

Ring Failover & Control Logic

Ring Continuously Monitored

ERPS/RSTP health messages sent between switches

Link Healthy
Traffic flows via primary path around the ring
Normal Operation
Link / Switch Fails
Protection mechanism reroutes traffic within 10–50 ms
No Data Loss — Automatic Recovery
Construction

Physical Construction

The switch is built in a rugged extruded-aluminium or steel DIN-rail enclosure with a wide industrial temperature rating, using shielded RJ-45 connectors with integrated magnetics for the copper ports and soldered SFP cages for fibre uplinks, keeping copper and optical interfaces electrically isolated from one another. Internal electronics are conformally coated to resist dust, humidity, and airborne contaminants typical of unconditioned equipment cabinets, and the redundant 24 VDC power inputs terminate at screw-clamp terminals, with optional hot-swappable dual PSU modules available on higher-end models so a single power-path failure doesn't interrupt ring or chain communication. A dedicated alarm relay contact is brought out to a separate terminal so a ring break or switch fault can be wired directly into an external annunciator circuit independent of the network itself. The enclosure includes a chassis earth stud for bonding to the cabinet ground bus, and where deployed outside a conditioned cabinet, the unit is upgraded to a sealed field enclosure with cable glands for each cable entry point.

Specification

Technical Parameters

ParameterTypical Value
Number of Ports8, 16, 24 (copper 10/100/1000BASE‑T) + 2‑4 SFP (fiber) slots
SFP Support100BASE‑FX, 1000BASE‑SX/LX, 1000BASE‑ZX (copper or fiber SFP)
Redundancy ProtocolsERPS (G.8032), RSTP/MSTP, PRP, HSR (select models), LACP
Failover Time< 50 ms (ERPS), < 2 sec (RSTP)
Ring Topology SupportUp to 254 nodes per ring (ERPS), flexible ring/chain/mesh
Switching CapacityUp to 128 Gbps (non‑blocking)
Forwarding RateUp to 95 Mpps (for 24‑port Gigabit switch)
MAC Table Size8K‑32K entries
VLAN SupportIEEE 802.1Q VLAN (up to 4094 VLANs)
QoSIEEE 802.1p, DiffServ (DSCP), 8 priority queues
Security Features802.1X (RADIUS), ACL, port security, SSH/HTTPS
Redundant Power Inputs2 x 24 VDC (18‑32 VDC), hot‑swappable (optional dual PSU modules)
Power Consumption15‑40 W (depending on port count and SFP load)
Operating Temperature-40°C to +75°C (industrial grade)
Storage Temperature-40°C to +85°C
Protection ClassIP30 (DIN‑rail mount), IP40 (ruggedized)
MountingDIN rail (EN 60715, 35mm) or rack mount (optional)
DiagnosticsStatus LEDs (power, ring, link/activity), system log, SNMP traps, alarm relay contacts
CertificationsCE, FCC, UL, IEC 61000‑6‑2 (EMC immunity), IEC 61850 (substation), IEC 62443 (cybersecurity)
Power Supply

Electrical Requirements

RequirementTypical Value
Circuit TypeLow-voltage DC auxiliary supply — network switch, not part of the airfield series circuit
Power Supply2 x 24VDC (18–32VDC), hot-swappable dual PSU (redundant)
Power Consumption15–40W depending on port count and SFP load
Cable TypeCat5e/6 copper, fibre optic (SFP)
Earthing/GroundingDIN-rail/rack chassis bonded to the cabinet earth bus
Fault ProtectionRedundant PSU failover; alarm relay contacts on power/link loss
StandardsIEC 61000-6-2 (EMC immunity), IEC 62443 (cybersecurity)
Compliance

Applicable Standards

ITU‑T G.8032

Ethernet Ring Protection Switching (ERPS) — standard for sub‑50ms ring recovery

IEEE 802.1D/1w/1s

Spanning Tree Protocol (STP/RSTP/MSTP) — redundancy and loop prevention

IEC 61850

Communication networks for power utility automation (redundancy requirements)

FAA AC 150/5345‑56

Specification for AGL control and monitoring equipment (network redundancy)

Prerequisites

Installation Requirements

Rack/DIN-Rail Mounting at Aggregation Point
Mechanical

Mount at the network aggregation point — control room, CCR substation, or field equipment shelter — rather than at individual fixtures.

Ring Fibre Routing
Optical

Route fibre runs around the ring in dedicated ducting, physically separate from AGL power circuits to avoid electromagnetic interference and single-trench risk.

Dual Power Input Wiring
Electrical

Feed dual 24 VDC power inputs from separate sources before commissioning.

Redundancy Protocol Configuration
Software

Configure the ring or redundancy protocol and VLAN/QoS settings before failover testing begins.

Pre-Commissioning Sign-off
Documentation

Record mounting location, fibre routing, and protocol configuration as-built before ring failover testing.

Verification

Testing & Commissioning

Redundancy Protocol Configuration Check
Pre-Energisation

Confirm ring or redundancy protocol settings (e.g., RSTP, MRP) match the network topology drawing before the switch is commissioned.

Ring Failover Test
Final Acceptance

Physically break a network link and confirm traffic reroutes within the specified recovery time, then confirm restoration on reconnection.

Redundant Power Input Test
Pre-Energisation

Confirm the switch continues operating without interruption on loss of either power input.

VLAN & QoS Configuration Verification
Final Acceptance

Confirm VLAN segmentation and traffic-priority settings match the network design before handover.

SFP & Fibre Port Verification
Installation

Measure optical power levels on fibre ports and confirm they fall within the link budget before connecting.

Documentation & As-Built Sign-off
Final Acceptance

Record failover timing, VLAN configuration, and optical power readings in the commissioning dossier.

Upkeep

Inspection & Maintenance

Ring Failover Test
Annual

Simulate a link break to confirm ERPS/RSTP failover completes within the specified time and traffic reroutes without loops.

Redundant Power Input Test
Semi-annual

Remove each 24 VDC input in turn to confirm the switch continues running on the remaining supply without a service interruption.

SFP & Fiber Port Inspection
Annual

Clean fiber connectors and check optical power levels on SFP modules, since contamination is a common cause of degraded ring links.

VLAN & QoS Configuration Review
Annual

Confirm VLAN assignments and QoS priority queues still match the commissioned network design, especially after any device addition.

Security & Access Control Review
Annual

Verify 802.1X, ACLs, and port security settings remain correctly configured, and confirm SSH/HTTPS management access is current.

Terminal & Connector Tightness Check
Annual

Re-torque DIN-rail terminal and RJ-45 connections to spec, since loose terminations can cause intermittent link flapping.

Firmware & System Log Review
Semi-annual

Check for validated firmware updates and review the system log and SNMP traps for recurring link errors.

Status Indicator Function Test
Quarterly

Confirm power, ring, and link/activity LEDs respond correctly, and verify alarm relay contacts trip during a simulated fault.

Field Notes

Common Field Issues

Ring Misconfiguration

Incorrect ring port assignment, missing ring master configuration, or mismatched ring version (ERPS vs. RSTP) can prevent the ring from forming or cause loops. Always follow the manufacturer's configuration guidelines and verify ring status using the switch's management interface.

Failover Timeouts

If the failover time is too long (e.g., > 1 second), some time‑sensitive control protocols (e.g., Profinet IRT, EtherCAT) may time out. Use ERPS for sub‑50 ms failover and tune the watchdog timers to match the application's requirements.

Power Supply Failure

Even with dual power inputs, a failure of both supplies or a common upstream power issue can cause the switch to lose power. Ensure that each power input is fed from a separate, independent power source (e.g., different UPS units) to achieve true redundancy.

Firmware Incompatibility

Mixing switches from different vendors or different firmware versions on the same ring can cause interoperability issues with redundancy protocols. Use switches from the same family and maintain consistent firmware versions across the ring.

Physical Cable Damage

While redundancy protects against single failures, multiple cable breaks or a cut at a common point (e.g., a trench) can still cause network segmentation. Design the ring to route cables via diverse physical paths where possible.

Traffic Flooding During Failover

During failover, the switch may flush its MAC address table, causing a temporary flood of unknown unicast frames. This can increase network load. Use rapid failover protocols and ensure the network has sufficient bandwidth headroom to handle the flood.

Alarm Suppression

In a ring, a single failure can trigger alarms from multiple switches (e.g., link‑down on both ends). Configure alarm suppression to avoid flooding the ALCMS with redundant alarms. Many switches support a "ring alarm" that only triggers when the entire ring is broken.

Diagnostics

Troubleshooting Guide

Ring Fails to Form or Network Loop Detected
Likely Cause
Incorrect ring port assignment, missing ring master configuration, or mismatched ring protocol (ERPS vs. RSTP) between switches.
Diagnostic Steps
Check ring status and port role on the switch's management interface; verify ring master and port configuration against the manufacturer's guidelines on every switch in the ring.
Corrective Action
Correct the ring port assignment and protocol configuration to match across all switches, and re-verify ring status shows a healthy, closed ring.
Time-Sensitive Control Protocol Drops Out During Failover
Likely Cause
Failover time exceeds the tolerance of a time-sensitive protocol (e.g., Profinet IRT, EtherCAT) running over the ring.
Diagnostic Steps
Measure actual failover time using the switch's diagnostics or a test link break; compare against the control protocol's timeout tolerance.
Corrective Action
Switch to a faster redundancy protocol such as ERPS for sub-50 ms failover, and tune watchdog timers on the affected control protocol to match.
Switch Loses Power Despite Dual Power Inputs
Likely Cause
Both power inputs are fed from a common upstream source or UPS, defeating the intended redundancy.
Diagnostic Steps
Trace both power feeds back to their source; confirm they originate from genuinely independent supplies/UPS units.
Corrective Action
Re-wire the power feeds so each input is fed from a separate, independent source to achieve true power redundancy.
Redundancy Protocol Unstable in a Mixed-Vendor Ring
Likely Cause
Firmware or vendor incompatibility between switches sharing the same ring.
Diagnostic Steps
Check firmware versions and vendor/model consistency across all switches in the ring; review vendor documentation for known interoperability issues.
Corrective Action
Standardise on switches from the same family with consistent, tested firmware versions across the ring.
Network Segmentation Despite Ring Redundancy
Likely Cause
Multiple cable breaks, or a single break at a point where diverse paths converge (e.g., a shared trench).
Diagnostic Steps
Inspect the physical cable route for common points of failure; check whether ring cabling shares ducts or trenches at any point.
Corrective Action
Re-route sections of the ring to use physically diverse paths, minimising shared failure points.
Network Congestion Immediately After a Failover Event
Likely Cause
MAC address table flush during failover causing a temporary flood of unknown unicast frames.
Diagnostic Steps
Monitor network utilisation during and immediately after a failover event; check whether the flood correlates with table-flush behaviour in switch logs.
Corrective Action
Use a faster failover protocol to shorten the flood window, and ensure adequate bandwidth headroom is designed into the ring.
ALCMS Flooded With Alarms From a Single Ring Fault
Likely Cause
Multiple switches reporting link-down independently for the same underlying fault, without alarm suppression configured.
Diagnostic Steps
Review alarm history for correlated link-down events from multiple switches at the same time; check whether ring-level alarm suppression is enabled.
Corrective Action
Configure ring-level alarm suppression (e.g., a single 'ring broken' alarm) so a single fault doesn't flood the ALCMS with redundant alarms.
Reliability

Failure Modes & Root Causes

Ring Misconfiguration
High Severity
Root Cause
An incorrect redundancy protocol setting, a mismatched ring ID, or a port assigned to the wrong role during commissioning or a later change.
Effect
The ring fails to form, or a network loop is detected, either of which can bring down communication across the entire ring rather than just one segment.
Detection Method
Redundancy protocol configuration check and a ring failover test to confirm the ring actually forms and heals as designed.
Failover Timeout
High Severity
Root Cause
A failover convergence time that's too slow for the time-sensitive control traffic riding the ring, or a protocol setting left at its default rather than tuned for the application.
Effect
A time-sensitive control protocol drops out during failover, even though the ring does eventually recover.
Detection Method
Ring failover test measuring actual convergence time against the requirement for the control protocol running on the ring.
Power Supply Failure (One of Dual Inputs)
Medium Severity
Root Cause
Ageing power supply components or a fault on one of the switch's two redundant power feeds.
Effect
The switch loses power despite dual power inputs, if the fault isn't caught before the second feed also fails or is itself interrupted.
Detection Method
Redundant power input test confirming both feeds independently support the switch and that a loss of either is correctly alarmed.
Firmware Incompatibility in a Mixed-Vendor Ring
Medium Severity
Root Cause
Switches from different vendors implementing the same redundancy protocol standard with subtly different behaviour or timing.
Effect
The redundancy protocol becomes unstable in a mixed-vendor ring, showing symptoms like intermittent segmentation despite every switch appearing individually healthy.
Detection Method
Firmware and system log review across all switches in the ring, cross-checked for protocol-version compatibility.
Physical Cable / SFP Damage
Medium Severity
Root Cause
Fibre or copper cable damage, or a degraded SFP transceiver, at any point around the ring.
Effect
Network segmentation occurs despite ring redundancy if two points fail before the first is repaired, or intermittent faults appear at the damaged point.
Detection Method
SFP and fibre port inspection, and a terminal and connector tightness check at each ring node.
Traffic Flooding During Failover
Medium Severity
Root Cause
A large broadcast domain or an under-tuned QoS configuration causing a traffic surge as the network relearns paths after a failover event.
Effect
Network congestion immediately after a failover event, and the ALCMS flooded with alarms from what was really a single ring fault.
Detection Method
VLAN and QoS configuration review, and observation of network behaviour during a controlled ring failover test.
Precautions

Safety & Operational Notes

Isolate One Power Input Before Internal Work
Electrical Safety

With dual power inputs, de-energise and lock out both supplies before opening the switch for internal work; assuming the switch is dead because one input is off is a common miscue on redundant-power equipment.

Verify Ring Configuration Before Going Live
Verification

Confirm the redundancy protocol, ring ID, and port roles are correctly set after commissioning or any change; a misconfiguration can prevent the ring from forming or create a network loop that brings down the whole ring rather than just one segment.

Test Actual Failover Time
Verification

Run a ring failover test and measure the actual convergence time against the requirement for the time-sensitive control protocols riding the ring, since a default setting that is too slow can drop control traffic during failover even though the ring eventually recovers.

Confirm Redundancy Restored Before Closing Out
Operational

After any port or cabling change, confirm the ring has healed and full redundancy is restored, rather than just confirming the network is currently passing traffic on the primary path.

ESD Precautions
Electrical Safety

Use anti-static handling precautions when servicing the switch or its modules, since electrostatic discharge can damage switching electronics with no immediate outward sign of failure.

PPE & Grounding
Personnel Safety

Confirm the switch enclosure is bonded/grounded per the electrical design, and use standard PPE appropriate to the panel it is mounted in.

Confirm Fallback Before Taking a Unit Down
Operational

Verify the ring or redundant path can carry the traffic before removing a switch for service, since this device is specifically relied upon to keep ALCMS/CCR communication alive during a link or device failure.

Restore to Compliant State
Compliance

Confirm both power inputs are live, the ring is fully formed, and a failover test passes before closing out the work.

Field Insight

Engineering & Expert Notes

Mixed Redundancy Protocols on One Ring Rarely Interoperate Cleanly
Design

Combining switches configured for different redundancy protocols, or even different vendors' implementations of the same protocol, on a single ring often works fine under normal conditions but produces unpredictable recovery behaviour during an actual fault. Standardise protocol and, where possible, vendor within a given ring rather than mixing to save cost on one segment.

Verify Failover Time Under Real Load, Not Just at Idle
Testing

A ring that recovers in the advertised sub-50ms window during a quiet acceptance test can take noticeably longer under the traffic load of a busy operational network with many active nodes. Test failover timing under realistic traffic conditions, since that's the scenario the redundancy actually needs to perform in.

Redundant Ring Cabling Needs Physical Path Diversity, Not Just Logical Redundancy
Installation

A ring topology only protects against a single break if the two paths around the ring are actually routed through physically separate ducts or trenches; a ring where both halves happen to run through the same conduit for part of the route offers far less real protection than the topology diagram suggests.

Repeated Micro-Failovers Are a Symptom, Not Background Noise
Troubleshooting

A ring that shows frequent brief failover events, each individually too short to cause a noticeable outage, is often an early sign of an intermittent connector, a marginal fibre splice, or EMI on one segment; log and trend failover event frequency rather than dismissing sub-second events as inconsequential.

Managed Switch Access Deserves the Same Hardening as Any Other Critical Node
Cybersecurity

The switches carrying control and monitoring traffic for the entire AGL network are themselves a high-value target if compromised; disable unused management interfaces, change default credentials, and keep firmware current on redundancy switches with the same discipline applied to the PLC or SCADA interface.

Document Ring Topology Changes as They Happen, Not at the Next Audit
Documentation

A ring modified during a field project to add a new node or reroute a segment, without a corresponding update to the network diagram, leaves the next person troubleshooting a fault working from an inaccurate picture of the actual topology. Update topology documentation at the time of the change.

Quick Answers

Frequently Asked Questions

Short answers about the Network Redundancy Switch: what it is, how it works, typical specifications, standards, maintenance and common faults.

Q1What is a Network Redundancy Switch?

A Network Redundancy Switch (also known as a redundant Ethernet switch, high‑availability switch, or industrial redundancy switch) is a managed industrial Ethernet switch that incorporates advanced redundancy protocols to ensure uninterrupted network connectivity in the event of a link or device failure. In AGL applications, where communication between the ALCMS, CCRs, remote I/O, and field equipment is mission‑critical, network redundancy is essential to maintain control and monitoring capabilities during cable breaks, switch failures, or maintenance activities.

Q2What is the purpose of a Network Redundancy Switch?

The redundancy switch exists because a single cable cut or switch failure should never be able to leave an operator unable to see or control part of the airfield lighting system — and on a live airfield, a backhoe strike, rodent damage, or a failed port is a matter of when, not if.

Q3Where is a Network Redundancy Switch used and installed?

Network Redundancy Switches are deployed in all critical points of the AGL communication infrastructure where high availability is required. Key applications include: ALCMS Core Network: Providing redundant connectivity between the ALCMS server, workstations, and the airfield fibre backbone. CCR Substation Aggregation: Aggregating multiple CCR communication links and providing a redundant fibre uplink to the control room. Runway Edge Cabinet Rings: Creating resilient ring networks along the runway to connect edge cabinets, ensuring no single cable break isolates a segment.

Q4How does a Network Redundancy Switch work?

The Network Redundancy Switch operates by implementing redundancy protocols that automatically detect and recover from network failures. Key functional aspects include: Ring Protection (ERPS/RSTP): In a ring topology, the switch uses ERPS (G.8032) or RSTP to designate one switch as the "ring master" (for ERPS) or the root bridge (for RSTP). The protocol continuously monitors the ring integrity by sending and receiving health messages.

Q5What are the typical technical parameters of a Network Redundancy Switch?

Typical values are — Number of Ports: 8, 16, 24 (copper 10/100/1000BASE‑T) + 2‑4 SFP (fiber) slots; SFP Support: 100BASE‑FX, 1000BASE‑SX/LX, 1000BASE‑ZX (copper or fiber SFP); Redundancy Protocols: ERPS (G.8032), RSTP/MSTP, PRP, HSR (select models), LACP; Failover Time: < 50 ms (ERPS), < 2 sec (RSTP); Ring Topology Support: Up to 254 nodes per ring (ERPS), flexible ring/chain/mesh; Switching Capacity: Up to 128 Gbps (non‑blocking); Forwarding Rate: Up to 95 Mpps (for 24‑port Gigabit switch); MAC Table Size: 8K‑32K entries; VLAN Support: IEEE 802.1Q VLAN (up to 4094 VLANs); QoS: IEEE 802.1p, DiffServ (DSCP), 8 priority queues.

Q6What are the electrical requirements for a Network Redundancy Switch?

Typical requirements are — Circuit Type: Low-voltage DC auxiliary supply — network switch, not part of the airfield series circuit; Power Supply: 2 x 24VDC (18–32VDC), hot-swappable dual PSU (redundant); Power Consumption: 15–40W depending on port count and SFP load; Cable Type: Cat5e/6 copper, fibre optic (SFP); Earthing/Grounding: DIN-rail/rack chassis bonded to the cabinet earth bus; Fault Protection: Redundant PSU failover; alarm relay contacts on power/link loss; Standards: IEC 61000-6-2 (EMC immunity), IEC 62443 (cybersecurity).

Q7Which standards apply to a Network Redundancy Switch?

The main references are ITU‑T G.8032 — Ethernet Ring Protection Switching (ERPS) — standard for sub‑50ms ring recovery; IEEE 802.1D/1w/1s — Spanning Tree Protocol (STP/RSTP/MSTP) — redundancy and loop prevention; IEC 61850 — Communication networks for power utility automation (redundancy requirements); FAA AC 150/5345‑56 — Specification for AGL control and monitoring equipment (network redundancy). Always verify the current edition and your aerodrome's approved requirements.

Q8How often should a Network Redundancy Switch be inspected and maintained?

Typical maintenance tasks and intervals are: Ring Failover Test (annual); Redundant Power Input Test (semi-annual); SFP & Fiber Port Inspection (annual); VLAN & QoS Configuration Review (annual); Security & Access Control Review (annual); Terminal & Connector Tightness Check (annual); Firmware & System Log Review (semi-annual); Status Indicator Function Test (quarterly). Your airport's approved maintenance programme takes precedence.

Q9How do I troubleshoot common Network Redundancy Switch faults?

Common symptoms covered are: Ring Fails to Form or Network Loop Detected; Time-Sensitive Control Protocol Drops Out During Failover; Switch Loses Power Despite Dual Power Inputs; Redundancy Protocol Unstable in a Mixed-Vendor Ring; Network Segmentation Despite Ring Redundancy; Network Congestion Immediately After a Failover Event; ALCMS Flooded With Alarms From a Single Ring Fault. For example, for "Ring Fails to Form or Network Loop Detected": Likely Cause: Incorrect ring port assignment, missing ring master configuration, or mismatched ring protocol (ERPS vs. RSTP) between switches. Diagnostic Steps: Check ring status and port role on the switch's management interface; verify ring master and port configuration against the manufacturer's guidelines on every switch in the ring. Corrective Action: Correct the ring port assignment and protocol configuration to match across all switches, and re-verify ring status shows a healthy, closed ring.

Go Further

Go Beyond the Component. Understand the Complete AGL System.

You have explored the component. Now understand how it works within the complete Airfield Ground Lighting system.

Learn AGL from fundamentals to design, installation, testing, photometry, commissioning, maintenance and troubleshooting through structured technical training at Precision AGL Academy.

Build practical knowledge. Understand the circuit. Read the standards. Troubleshoot with confidence.

Your next step in AGL starts here.

The Learning Pathway
Learn Understand Design Test Maintain Document Apply Certify

Need expert guidance on Network Redundancy Switch selection, ring design, or failover configuration for your AGL network?

Precision AGL Academy provides advice on redundancy protocols, topology design, failover tuning, and best practices for resilient AGL communication infrastructure.