A credible ERPS convergence figure comes from a traffic generator that counts frames lost during a real fibre pull, not from a ping window and not from the datasheet. The number you can defend at handover is "we lost N frames at 512-byte frames and 50% load", because frames are what the application loses.
Rayin (Shenzhen Rayin Technology) is a manufacturer of GPON OLTs and industrial Ethernet switches.
Ping is a reachability probe with second-scale resolution on default settings; a traffic generator has millisecond resolution and counts actual loss. Use the generator for the acceptance figure and the application for the sanity check.
Measured restoration time is always longer than the datasheet because the datasheet figure excludes link-down detection, configured hold-off and guard timers, and FDB re-learning. Budget for all four.
Six numbers make an acceptance record reproducible: topology, injected fault, offered load and frame size, frames lost, post-switchover ring state, and the tool plus firmware that produced the reading.
ITU-T G.8032 defines Ethernet ring protection switching: one link is blocked in the idle state, and when a link fails the two adjacent nodes send R-APS messages around the ring, the ring protection link owner unblocks its port, and traffic runs the other way. Three timers shape the result — a hold-off timer, a guard timer and a wait-to-restore timer — and the widely quoted design target is recovery inside 50 ms for rings within the ring size limits the recommendation sets. That is the whole mechanism; everything below is about proving it on your ring rather than restating it.
Note
If you need the protocol explained rather than measured, read the ring protection overview first. This article assumes the ring is already built and you are standing in front of it with a test set.
Three methods are used in the field, and they disagree by an order of magnitude. The disagreement is not error — each one measures a different thing.
| Method | What it actually measures | Resolution | Verdict for acceptance |
|---|---|---|---|
| Traffic generator (RFC 2544 style) | Frames transmitted minus frames received across the switchover window | Milliseconds, and it counts loss directly | Primary. This is the number that belongs on the sheet |
| ICMP ping, default 1 s interval | Whether the far end answered on the next probe | ±1 s at best, and only if the OS honours the interval | Not acceptable. A 50 ms event is invisible at 1 s granularity |
Ping with a short interval (-i 0.01) | Round-trip continuity at 10 ms granularity | ~10 ms, but the reply is generated by the device CPU | Supporting evidence only; CPU load moves the result |
| Application check (camera stream, PLC heartbeat) | What the operator sees | Depends on the application's own timeout | Required sanity check, not the acceptance figure |
The reason ping is unreliable is not just the interval. An ICMP reply is handled by the switch CPU, so on a managed industrial switch already polling SNMP or handling a topology change, the reply you are timing is competing for CPU with the event you are measuring. A traffic generator measures in the forwarding plane, which is where your process traffic lives.
This is the question that starts arguments on site, and it has a clean answer: the datasheet figure is the protocol's switching time, not the end-to-end service interruption.
| Gap | Typical contribution (industry-typical) | Where it comes from |
|---|---|---|
| Link-down detection | Microseconds to a few milliseconds | The PHY has to declare loss of signal before the node sends R-APS; slow-loss-of-signal optics push this out |
| Hold-off timer | 0 ms if left at default; configured values are set in 100 ms steps up to seconds | Present so a lower-layer protection scheme can act first; a non-zero value is added straight to the outage |
| R-APS propagation and FDB flush | A few milliseconds, growing with ring size | Each node forwards the R-APS message and flushes its filtering database, then re-learns MAC addresses |
| Guard timer | 500 ms at the default setting | Applied after the fault clears to stop stale R-APS messages from reopening a recovered link |
| Wait-to-restore timer | Minutes at the default setting | Applied only on the restore path, not on the failure path, so it should not appear in a failure test |
Two of these are configuration, not physics. Your restoration time budget therefore has four line items, and only one of them is the protocol. If your measured failure time is 550 ms and the guard timer is at its 500 ms default, the ring may be switching correctly and you are timing the recovery from a previous test — run five iterations with a clean idle period between them and take the worst.
Yes, and recording which one you did is part of a reproducible result.
| Injection method | What it exercises | When to use it |
|---|---|---|
| Pull the fibre at the patch panel | The real failure mode: optics lose signal, the node declares signal fail | Default choice; this is what a digger does |
shutdown on the ring port | A local software event that bypasses optical detection | Useful control test; if the two differ by more than a few milliseconds, suspect slow loss-of-signal detection |
| Pull one fibre of a pair | Asymmetric failure; some deployments see a unidirectional condition | Only if you are validating behaviour deliberately — it is the hardest case to interpret |
| Reboot a ring node | Two links fail at once; a protected ring survives one fault, not two | Documented as a known limitation, not as a convergence test |
Single-ring tests are the easy case. Three configurations reliably produce worse numbers than the single-ring figure suggests.
| Configuration | Symptom | Mitigation |
|---|---|---|
| Intersecting rings sharing a link | One fault changes two rings at once; the shared node handles two R-APS instances | Test each ring independently first, then test the shared link failure explicitly |
| ERPS ring interconnected with an RSTP cloud | The ring recovers in tens of milliseconds, then the spanning-tree domain takes far longer to re-converge | Measure end to end, not ring-internal; the RSTP side usually dominates |
| Very large rings | Per-node forwarding delay accumulates around the loop | Compare measured time against the ring size limits your vendor states for the feature |
| Sub-rings on a ladder network | The sub-ring reports to the major ring; a fault can be reported twice | Verify with traffic flowing on both the major ring and the sub-ring simultaneously |
Six fields, filled in on site, signed by both parties. Anything less and the result cannot be reproduced three months later when someone claims the ring "used to be faster".
| Field | Example entry | Why it is needed |
|---|---|---|
| 1. Topology as built | 6 nodes, Node A port 1/1 is RPL owner, longest span 3.2 km | Ring size and RPL placement change the result |
| 2. Injected fault | Fibre pulled at Node C, west span, near end | Pull vs shutdown is not the same test |
| 3. Offered load and frame size | 50% line rate, 512-byte frames | Loss count is only meaningful at a stated load |
| 4. Frames lost / outage | 312 frames lost, 4.9 ms outage | The acceptance number itself |
| 5. Post-switchover state | RPL unblocked, traffic on east path, no second fault | Proves the ring actually re-formed |
| 6. Tool, firmware and time | Generator model, switch firmware version, date and time | Makes the record auditable |
Run the test at least five times and record all five, not the average. The worst run is the one your customer will experience.
What is a good ERPS convergence number to write into a contract?
Write a measured figure with its conditions, not a bare millisecond value: "no more than X frames lost at 512-byte frames and 50% line rate, measured with a traffic generator over five consecutive fibre pulls." A bare "50 ms" clause is unenforceable because nobody agrees which timer configuration it assumes.
Why does my ping show one second of loss when the ring recovers in milliseconds?
Because the default ping interval on most operating systems is one second, so a 50 ms outage either disappears or shows as a single lost reply. Repeat with a 10 ms interval and treat the result as supporting evidence only, since the reply is generated by the device CPU.
Should the guard timer be changed before an acceptance test?
Leave it at its default 500 ms unless the design deliberately sets otherwise, and leave a clean idle period of at least the guard interval between test runs. Shortening it to make the acceptance number look better hides stale R-APS handling that will surface in service.
Does a larger ring always mean slower convergence?
Generally yes, because R-APS messages traverse every node and each hop adds forwarding delay, but the dominant term is usually link-down detection and configured timers rather than hop count. Measure on the real ring instead of extrapolating from a bench test.
Can I use a laptop running iperf instead of a traffic generator?
You can use it to confirm that traffic resumes, but iperf numbers are produced by a general-purpose CPU and vary with frame size, socket buffer and processor load, so they are not reproducible enough for an acceptance record. Use them for the sanity check and a dedicated generator for the figure.
A ring that recovers is not the same as a ring you have proven recovers. Inject the fault the way it will really happen, measure in the forwarding plane, record all five runs with their conditions, and write the six fields down before anyone leaves site. Rayin publishes the ring protection capabilities of its managed industrial switch lines with the timer defaults stated, so those six fields can be filled in from the configuration rather than guessed.
Frame Size and MTU: When Jumbo Frames Actually Help a Switch
Redundancy Protocols Compared: RSTP, ERPS, LACP and Dual Homing
Port Flapping and Suppression: Isolating a Bad Fibre Contact
The protocol behaviour, timer semantics and test-method statements above come from public industry sources — ITU-T G.8032 (Ethernet ring protection switching, including the R-APS mechanism and the hold-off, guard and wait-to-restore timers), RFC 2544 (benchmarking terminology and frame size sets) and IEEE 802.1Q/IEEE 802.1D (spanning tree behaviour when a ring interconnects with an STP domain). The method, worked examples and wording are written by Sara, who checked each figure against those sources before publication. Anything presented as an industry-typical value is labelled as such; nothing here is a measured figure from a Rayin product unless it says so.
About the author: Sara — Sara is a Customer Manager at Rayin with over 10 years of experience in the communications field. In her free time, she enjoys badminton and swimming.
About Rayin: Shenzhen Rayin Technology Co., Ltd. — Company Profile
