Key takeaways
- Ring topologies (like O-Ring) protect against a single cable cut, but their millisecond-level health check makes them oversensitive to the brief packet loss that constant vehicle vibration causes.
- On rolling stock, vibration-induced micro packet loss can trigger repeated, unnecessary ring topology switching — a condition known as flapping — which disrupts normal traffic forwarding.
- Port Trunk (link aggregation) provides redundancy at the physical link level without relying on a timing-sensitive health-check protocol, so brief vibration-induced packet loss has nothing to trigger.
- Port Trunk keeps working correctly even when port assignments are crossed or reversed — a common outcome of train coupling, decoupling, and re-marshalling.
- Hardware Bypass protects against a different failure mode: complete device power loss. It reroutes traffic around a powered-off unit at the hardware level, with no protocol involved.
- Together, Port Trunk and Hardware Bypass form ORing's recommended redundancy architecture for rail vehicle onboard networks.
Why does rolling stock need a redundant onboard network?
Modern train vehicles run CCTV, passenger information systems, PA/intercom, HVAC monitoring, and diagnostic data over a shared onboard Ethernet backbone. A single switch or cable failure on that backbone can take down camera feeds or passenger information across an entire carriage, so onboard network designs generally need some form of built-in redundancy — a path traffic can fail over to when part of the network goes down.
How does Ring (O-Ring) redundancy work?
One switch is configured as the Ring Master with two ring ports: Ring Port 1 set to Forwarding, and Ring Port 2 set to Backup. The Ring Master continuously sends a health-check packet, roughly once every millisecond, that must travel around every switch in the ring and return. As long as it returns, the ring is healthy and Ring Port 2 stays in Backup. If it doesn't come back, the protocol treats the ring as broken and switches Ring Port 2 to Forwarding to restore connectivity.
Figure 1. O-Ring in normal operation: Ring Port 1 forwarding, Ring Port 2 in backup.
[Alt text for CMS image field — not part of body copy] O-Ring topology diagram showing a Ring Master switch with Ring Port 1 forwarding and Ring Port 2 in backup standby state.
Why does vehicle vibration break Ring redundancy on trains?
Trains vibrate constantly while running, and that vibration can cause very brief packet loss on a physical link — often lasting a fraction of a second. Ordinary applications never notice it. But O-Ring's 1 ms health check has almost no tolerance for it: if a single check packet fails to complete the loop because of vibration, the protocol assumes a cable has failed and switches Ring Port 2 to Forwarding.
Figure 2. Vibration-induced packet loss is misdetected as a break, and Ring Port 2 switches to Forwarding.
[Alt text for CMS image field — not part of body copy] Diagram showing vehicle vibration causing brief packet loss on a ring link, with Ring Port 2 misdetecting it as a break and switching to forwarding.
Once the vibration passes, the next check packet gets through, and the ring switches Ring Port 2 back to Backup.
Figure 3. Once the packet loss clears, Ring Port 2 switches back to Backup.
[Alt text for CMS image field — not part of body copy] Diagram showing Ring Port 2 returning to backup standby state after the vibration-induced packet loss clears.
Because vibration is continuous while the train is moving, this misdetect-switch-back-misdetect cycle repeats constantly. The ring spends more time reconverging its topology than forwarding ordinary traffic — a redundancy mechanism meant to protect the network ends up destabilizing it instead.
How does Port Trunk (link aggregation) solve the vibration problem?
ORing's alternative approach replaces the ring's timing-sensitive health check with Port Trunk, a link-aggregation technique similar to IEEE 802.3ad. Two physical cables run in parallel between each pair of switches, with Port Trunk enabled on both ends so the pair operates as one aggregated logical link without forming a loop.
Figure 4. Port Trunk in normal operation (top) and failing over when one cable is cut (bottom).
[Alt text for CMS image field — not part of body copy] Diagram of Port Trunk link aggregation between two switches, showing both cables active in normal operation and one cable failing while the other keeps forwarding.
Both cables carry traffic simultaneously. If one is cut or degraded, the other keeps forwarding without any protocol-level "is it broken?" decision to make. Because Port Trunk isn't polling for failure every millisecond, a few milliseconds of vibration-induced packet loss on one strand has nothing to trigger — there is no topology to switch.
How does Port Trunk handle train coupling, reversal, and re-marshalling?
Rolling stock is frequently coupled, decoupled, reversed, and re-marshalled into different consists, which can leave the physical port mapping between two switches crossed or swapped from what was originally planned. Port Trunk keeps working correctly in every one of these cases:
- Two switches using different, correspondingly matched Trunk Groups on each side
- Two switches using the same-named Trunk Group on both sides
- Either of the above with the physical ports crossed — for example, an upper port on one switch wired to a lower port on the other
Figure 5. Port Trunk still aggregates correctly across different Trunk Group pairings, including crossed ports.
[Alt text for CMS image field — not part of body copy] Diagram showing two switches with different Port Trunk Group assignments connected directly and with crossed ports, both aggregating correctly.
Figure 6. Port Trunk still aggregates correctly when both switches use the same Trunk Group naming, including crossed ports.
[Alt text for CMS image field — not part of body copy] Diagram showing two switches with matching Port Trunk Group assignments connected directly and with crossed ports, both aggregating correctly.
As long as the two cables between a switch pair fall within their configured Trunk Group, aggregation and failover keep working — no reconfiguration is required when a consist is turned around or coupled to a different set of vehicles. That flexibility maps directly onto how rail operations actually work.
How does Hardware Bypass protect against a failed or powered-down device?
Port Trunk protects against a broken or degraded cable, but it can't help if an entire switch loses power or fails outright — there's no working device left to forward through. Hardware Bypass addresses that separately: when a unit loses power or crashes, a hardware relay inside it automatically shorts the incoming and outgoing ports together, physically routing traffic to the next device in line instead of relying on that unit's internal switching logic.
Figure 7. Hardware Bypass in normal operation (top) and automatically rerouting traffic when a device loses power (bottom).
[Alt text for CMS image field — not part of body copy] Diagram of Hardware Bypass technology showing normal traffic flow through three devices and automatic bypass routing when the middle device loses power.
In a normal state, traffic passes through each device's switching engine as usual. When a device fails, Hardware Bypass activates within the hardware itself — not through a software or protocol decision — so failover happens without waiting on any control-plane process.
Which ORing switches support Port Trunk and Hardware Bypass for rail applications?
ORing's rail-grade managed switch families combine both features on M12-locking, wide-voltage hardware built for the vibration, temperature, and power conditions found on rolling stock. Model numbers containing "-BP" integrate Hardware Bypass — for example the TPS-3082GT-M12X-BP1-MV and TGPS-9084GT-M12X-BP2-WV series — and ORing's managed switch line broadly supports Port Trunk / link aggregation across its onboard product range. These switches are already deployed in onboard networks including Taiwan's Puyuma Express and Taipei Metro's Wenhu Line, and in high-speed rail passenger information systems, giving this architecture a track record in exactly the vibration environment this article describes.
For a configuration recommendation for your own rolling stock project, contact ORing's engineering team.
Frequently asked questions
Is Port Trunk the same as Ring redundancy?
No — they solve redundancy differently. Ring redundancy relies on a control-plane health-check protocol to detect a break and switch traffic to a backup path, which can take the whole ring's topology out of sync while it reconverges. Port Trunk aggregates two physical links into one logical link at the hardware/link layer, so there is no ring-wide reconvergence step and it isn't sensitive to the brief, repeated packet loss vibration causes.
Does running two cables between switches with Port Trunk create a loop?
No, as long as Port Trunk (link aggregation) is correctly enabled on both ends. The two ports are treated as members of one aggregated link rather than two independent paths, so the pair doesn't form a Layer 2 loop the way two ordinary uplinks would.
What happens if the train is reversed or the consist is re-coupled?
Port Trunk keeps working even if that changes which physical port lines up with which on the other switch, including cases where the two links' ports end up crossed. See "How does Port Trunk handle train coupling, reversal, and re-marshalling?" above.
Does Hardware Bypass require software or a protocol to activate?
No — it's a hardware relay function inside the switch. It engages when the device loses power or fails, independent of any network protocol, so it doesn't depend on the rest of the network being in a particular state to work.
Can Port Trunk and Hardware Bypass be used together?
Yes. In ORing's recommended rail architecture, Port Trunk protects against a cable fault between two switches, and Hardware Bypass protects against the complete failure of a switch itself — together they cover both failure modes without relying on a timing-sensitive ring protocol.
Related resources
(Existing ORing Knowledge Base articles — link each to its live URL when publishing.)
