Skip to content

Methodology · Switch and router benchmarking

RFC 2544: the zero-loss benchmark for switches and routers

RFC 2544 has been the standard forwarding-plane test since 1999: 7 frame sizes, 60-second trials and a single rule for throughput, zero frames lost. This page shows the method as we run it in CloudLAB, where the datasheet number usually comes from, and what you get in the report.

  • 7 frame sizes, 64 to 1518 bytes, each tested on its own: the 64-byte column is the honest one
  • Throughput is found by binary search; 1 lost frame in a 60 s trial fails the step
  • 6 tests in the RFC: throughput, latency, frame loss, back-to-back, system recovery and reset
Get an RFC 2544 test plan Jump to the 6 tests
ZERO-LOSS THROUGHPUT % OF LINE RATE · RFC 2544 §26.1 LINE RATE · 100% 50% 41% 68% 99% 100% 100% 100% 100% PPS-BOUND: THE LOOKUP ENGINE 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B Zero frames lost, or the step does not count

A typical L3 result. The wire is never the limit at 1518 bytes. At 64 bytes the forwarding engine has to look up 14.88 million packets per second on a 10 GbE port, and that is where the real number lives.

Where it fits

One method, one question: how many frames per second can the box forward without losing one?

RFC 2544 (Benchmarking Methodology for Network Interconnect Devices) uses the terms of RFC 1242 and treats the device as a black box: frames in on one port, frames out on another, counters on both sides. Stateless, L2 and L3, lab only.

What it measures

The forwarding plane: throughput, latency, frame loss and back-to-back burst capacity per frame size, plus recovery and reset time. Switches, routers, L3 ASICs, virtual routers, SD-WAN boxes in pass-through mode, DPUs.

What it does not measure

Anything stateful or anything on a live network. Firewalls and NGFWs go to RFC 9411, a carrier Ethernet service to ITU-T Y.1564, TCP behaviour to RFC 6349. RFC 6815 says it in the title: running RFC 2544 on a production network is considered harmful.

The family around it

RFC 2889 adds LAN-switch specifics: address learning, congestion control, head-of-line blocking, full mesh. RFC 5180 carries the same tests to IPv6. RFC 3918 covers multicast. We combine them into one test plan when the device calls for it.

Free template

RFC 2544 test plan template

The plan we fill in before every switch and router run, as a PDF: device and test bed, the 6 tests with their parameters, a results sheet for all 7 frame sizes, a line-rate reference table and the report checklist.

  • Ready to attach to a tender or an RFP
  • The same parameters and pass criteria for every vendor and every lab
  • The mistakes that change the result, listed at the end

PDF in English. We ask only for your email.

Testbed

2 tester ports, 1 device, counters on both ends

RFC 2544 §4 wants a tester that sends and receives on the same instrument, so every frame is counted on both sides with one clock. A software generator on a server does not meet that bar; a hardware port does.

HARDWARE TESTER · PORT A TX + RX · ONE CLOCK FOR BOTH SIDES FRAME STREAM 64 · 128 · 256 · 512 · 1024 · 1280 · 1518 B Sequence number + hardware timestamp per frame 256 source and destination addresses per port Learning frames first, counters cleared, 60 s trial 1 GbE · 10 · 25 · 100 · 400 GbE PORTS BIDIRECTIONAL DUT SWITCH · ROUTER · L3 ASIC · VIRTUAL ROUTER Production configuration, exported to the report Interface counters read after every trial BLACK BOX · FRAMES IN, FRAMES OUT STORE & FORWARD CUT-THROUGH L2 · L3 IPv4 · IPv6 · VLAN ACL · QoS AS IN PROD PHYSICAL OR VNF ON OUR HOSTS COUNTED · TIMED HARDWARE TESTER · PORT B RX + TX · SAME INSTRUMENT AS PORT A PER-FRAME VERIFICATION Sent vs received: lost frames, per trial Sequence check: misordered and duplicated CRC and payload check: corrupted frames Timestamp delta: latency, every frame LOSS ≠ MISORDER ≠ CRC ERROR LOOPBACK PRE-TEST FIRST port A to port B through the same cables and optics · 64-byte throughput must be 100% with zero loss before the DUT goes in

Tester

Hardware ports from Keysight, Spirent or Xena at the speed of the DUT interface, 1 GbE to 400 GbE. Each frame carries a sequence number and a hardware timestamp; the receiver checks both, so misordered, duplicated and corrupted frames are separated from lost ones.

Device under test

Configured the way you will run it: VLANs, routing table, ACLs, QoS if enabled in production. One configuration for the whole run, exported and attached to the report. Software version and hardware revision on the first page.

Traffic

Frame sizes 64, 128, 256, 512, 1024, 1280 and 1518 bytes, bidirectional by default (RFC 2544 §14), 256 MAC or IP addresses per port (§12) so the box has to look up, not cache. Learning frames go first (§8), then the trial starts and the counters are cleared.

Pre-test: the bed without the device

We connect the tester ports back-to-back through the same cables, optics and patch panel and run the full 64-byte throughput search. The expected answer is 100% of line rate with zero loss. If it is anything else, the bed is repaired before the DUT goes in, because every loss we would see later must belong to the device and not to a dirty LC connector.

Test conditions

Frame sizes, line rates and the modifiers that make the run realistic

RFC 2544 §9 fixes the frame sizes for Ethernet. The table shows the maximum frames per second a port can carry at each size (20 bytes of preamble and inter-frame gap per frame are included). A device that forwards all of them at every size is at wire speed.

Frame size 1 GbE
frames/s		 10 GbE
frames/s		 100 GbE
frames/s		 Payload share of wire
64 B1,488,09514,880,952148,809,52476.2%
128 B844,5958,445,94684,459,45986.5%
256 B452,8994,528,98645,289,85592.8%
512 B234,9622,349,62423,496,24196.2%
1024 B119,7321,197,31811,973,18098.1%
1280 B96,154961,5389,615,38598.5%
1518 B81,274812,7438,127,43898.7%

Frames per second at 100% of line rate, Ethernet: size plus 8 bytes of preamble and 12 bytes of inter-frame gap, divided into the port rate. 64-byte frames carry 76% of the wire in frame bits and 24% in overhead, which is why a 10 GbE port at 64 bytes is a 14.88 Mpps problem and a 7.6 Gbit/s answer at best.

Always in our runs

  • Bidirectional traffic (§14)
  • Trial duration 60 s (§24)
  • Learning frames before each trial (§8)
  • 256 addresses per port (§12)
  • Sequence, CRC and payload check on RX
  • Loopback pre-test of the bed

Bidirectional traffic on all pairs, a 60-second trial per step, learning frames before each trial, sequence and CRC checks on every received frame. This is the minimum RFC 2544 asks for, and the minimum for a number we are willing to sign.

Added by agreement

  • 1% broadcast frames (§11.1)
  • SNMP query every second (§11.2)
  • 25 filters, last one permits (§11.3)
  • Full mesh, multiple port pairs (RFC 2889)
  • IPv6 frame sizes (RFC 5180)
  • Jumbo frames to 9216 B

The RFC 2544 §11 modifiers that vendors' own tests tend to skip: 1% broadcast frames mixed in, a management (SNMP) query every second, 25 filter rules with only the last one permitting the flow. They cost performance on some silicon and nothing on other silicon, which is exactly what you want to know before buying.

The 6 tests

RFC 2544 §26: what each test asks and what number comes out

Each test runs for every frame size. The first 4 are the standard set in tenders and datasheets; recovery and reset are the two most people forget, and the two that describe what your network feels during a failover.

  1. 26.1Standard set

    Throughput

    The highest offered rate at which the DUT forwards every frame. Binary search per frame size: start at line rate, halve on loss, split the interval until the resolution is reached. One frame lost in the 60-second trial and the step fails. Reported in frames per second and as a share of line rate, with a graph over frame size.

    Zero loss, per frame size · resolution 0.1% of line rate or 1 fps, whichever you specify
  2. 26.2Standard set

    Latency

    At the throughput rate, a 120-second stream with one tagged frame at the 60-second mark; the DUT's latency is the time between that frame going in and coming out. Store-and-forward devices are measured last-bit-in to first-bit-out (LIFO), cut-through devices first-bit-in to first-bit-out (FIFO). 20 repetitions, average reported.

    Per frame size, at the throughput rate · we add min, max and every-frame histograms on top
  3. 26.3Standard set

    Frame loss rate

    What the box drops when you overload it. Traffic at 100% of line rate, then down in steps of 10% or finer until 2 consecutive trials show zero loss. The shape of the curve says more than the number: a clean knee is a well-behaved queue, an early slope is a scheduler or a lookup engine giving up.

    Loss in percent of offered frames, per rate step · graph per frame size
  4. 26.4Standard set

    Back-to-back frames

    A burst of frames with the minimum legal inter-frame gap. The test finds the longest burst the DUT absorbs without losing a frame, which is a direct measure of its buffering. At least 2 seconds per burst, 50 repetitions, average burst length reported in frames and in time.

    Burst length per frame size · the one number that predicts microburst behaviour
  5. 26.5Resilience

    System recovery

    How long the DUT needs to get back to normal after being overloaded. Traffic at 110% of the measured throughput (or at line rate) for 60 seconds, then dropped to 50%. The recovery time runs from the rate change to the last lost frame. Boxes that shed load gracefully recover in microseconds; boxes with deep, slow queues take milliseconds and lose a lot on the way.

    Time from rate drop to last frame lost · per frame size
  6. 26.6Resilience

    Reset

    Time from a reset, hardware or software, to the first forwarded frame. Traffic at the throughput rate, the DUT is power-cycled or reloaded, and the gap between the last frame before and the first frame after is the number. It is the reboot time your NOC will live with, measured instead of quoted.

    Seconds from reset to first forwarded frame · smallest frame size, hardware and software reset separately

Procedure

How a trial runs, and why 60 seconds is the floor

RFC 2544 §23 and §24 describe the trial; everything else is repetition. 5 moves for each test and each frame size, with the counters cleared and checked between them.

  1. 00

    Bed without the DUT

    Loopback through the same cables and optics. 64-byte throughput must return 100% of line rate with zero loss, or the bed is fixed first.

  2. 01

    Learning frames

    The tester sends frames from every address the trial will use so that the DUT's MAC table or ARP cache is complete. Without this the first seconds of a trial count flooding and misses as the device's fault.

  3. 02

    Trial, 60 seconds

    Counters cleared, traffic at the offered rate for 60 s minimum (§24). Then 2 seconds of silence for residual frames to drain and 5 seconds for the DUT to settle before the next step (§23).

  4. 03

    Search and repeat

    Throughput converges by binary search; latency runs 20 times, back-to-back 50 times. Every step keeps its own counters, so a single flaky trial is visible instead of averaged away.

  5. 04

    Next frame size

    The whole loop again for 128, 256, 512, 1024, 1280 and 1518 bytes. A full 4-test run on one port pair is 3 to 5 hours of tester time; that is the price of numbers with a standard behind them.

BINARY SEARCH · THROUGHPUT, 64 B, 10 GbE OFFERED LOAD, % OF LINE RATE · 60 s PER TRIAL 100% 75% 50% 25% TRUE ZERO-LOSS RATE · 83.6% 100% · 16.4% LOST 50% · 0 75% · 0 87.5% · 3.9% LOST 81.3% · 0 84.4% · 12 FRAMES 82.8% · 0 83.6% · 0 · RESULT TRIAL 1 TRIAL 2 TRIAL 3 TRIAL 4 TRIAL 5 TRIAL 6 TRIAL 7 TRIAL 8 8 trials × (60 s + 2 s drain + 5 s settle) ≈ 9 minutes for one frame size · result: 83.6% of line rate = 12,440,476 frames/s

Binary search on a 10 GbE port, 64-byte frames. 8 trials of 60 seconds each: red steps lost at least one frame, green steps lost none. The last green step within the 0.1% resolution is the throughput. Vendors who run 2-second trials get a higher number from the same box; the buffers hide the loss for the first few seconds.

The 4 numbers that decide whether a step counts

  • 0

    Frames lost in a throughput trial. Not 0.01%, not 'within noise'. RFC 1242 defines throughput as the rate with no loss, and a searched rate with an accepted loss is a different test with a different name.

  • 60 s

    Minimum trial duration (§24). Long enough for buffers to fill, for CPU-based forwarding to heat up, and for a 1-in-a-million loss to show up 890 times at 64 bytes on 10 GbE.

  • 7

    Frame sizes per test (§9). Skipping the small ones is the most common way to make a slow box look fast; the RFC allows adding sizes, not dropping them.

  • 20 / 50

    Repetitions for latency and for back-to-back (§26.2, §26.4). One trial is an anecdote. The spread across the repetitions goes into the report next to the average.

Anatomy of one trial (RFC 2544 §23)

  • LearningFrames from every source address, DUT tables populated, tester waits for the DUT to finish flooding.
  • Clear countersTX and RX counters and timestamps reset on the tester; DUT interface counters read and stored for cross-checking.
  • Trial, 60 s or moreOffered load at the step rate. The only measured interval: frames sent, received, lost, misordered, and latency per frame.
  • Drain and settle2 s to collect frames still in flight, then 5 s of silence before the next step so one trial cannot leak into the next.

The report

What you get back, and what you can do with it

RFC 2544 §26 asks for a table and a graph per test and per frame size. We add the context that turns the table into a decision: what was configured, what the bed itself measured, and where the box fell short of the datasheet.

Numbers, per frame size

  • Throughput in frames per second and as a share of line rate, with the search resolution
  • Latency: RFC 2544 average over 20 runs plus min, max and per-frame distribution
  • Frame loss rate at every offered load from 100% down to the zero-loss step
  • Back-to-back burst length in frames and in microseconds, average of 50
  • System recovery time and reset time (hardware, software), where ordered
  • Misordered, duplicated and CRC-error frames counted separately from loss

Context, so the numbers hold up

  • DUT model, hardware revision, software version and the full configuration export
  • Tester model, port type, optics, firmware; the loopback pre-test result
  • Frame format and protocol: L2 only, IPv4, IPv6, VLAN-tagged, with the header layout
  • Modifiers in effect: bidirectional, address count, broadcast share, management load, filters
  • Datasheet claim next to the measured value for each test, with the gap in percent
  • Raw counters per trial and packet captures of the failing steps
RFC 2544 · TEST REPORT 10 GbE · BIDIRECTIONAL · 60 s TRIALS 26.1Throughput, 1518 B 26.1Throughput, 64 B 26.2Latency, 64 B, store & forward 26.3Frame loss at 100%, 64 B 26.4Back-to-back, 64 B 26.5System recovery, 64 B 100% 83.6% 4.8 µs 16.4% 18,900 fr 0.42 ms 812,743 fps · 0 lost of 48.8 M sent · datasheet: wire speed 12,440,476 fps · datasheet: 14,880,952 fps · gap 16.4% avg of 20 · min 4.1 · max 7.9 · LIFO at the throughput rate clean knee at 84% · 0 loss from 83.6% down · 2 trials confirmed avg of 50 · 1.27 ms of line-rate burst absorbed · buffer ≈ 1.2 MB 110% for 60 s, then 50% · last lost frame at +0.42 ms ATTACHED DUT CONFIG EXPORT GRAPHS PER SIZE LOOPBACK PRE-TEST RAW COUNTERS · PCAP Values are illustrative. Your report carries your numbers, per frame size and per modifier set.

If you are comparing 2 or more boxes

  • One test plan, one bed, one tester for all candidates; results in a single table with the same frame sizes and modifiers
  • A plain recommendation: which unit meets your requirement, at which frame size it stops, and by how much
  • The test plan itself, formatted for a tender annex so the winner can be re-verified on delivery

From practice

Wire speed at 1518 bytes, 38% at 64 bytes. Same box, same datasheet.

A customer had a shortlist of 2 aggregation routers and a datasheet for each that said 'wire-speed forwarding on all ports'. Both were true, at 1518 bytes. Through the 7 frame sizes on our bed, one of them held line rate down to 128 bytes and reached 92% at 64. The other fell off a cliff below 512 bytes and forwarded 38% of line rate at 64 bytes with 62% loss, bidirectional, no modifiers.

Their traffic profile, from a NetFlow export, had 47% of frames under 128 bytes: VoIP, DNS, TCP ACKs, monitoring. The cheaper box would have been the slower one by a factor of 2.4 on the day it went into production. The test took 2 lab days and cost less than the price difference between the two units.

Test with your frame sizes, not the vendor's.

SAME BOX · TWO FRAME SIZES 1518 B · THE DATASHEET RUN 812,743 fps of 812,743 · wire speed, as printed 100% 64 B · THE PRODUCTION RUN 5.65 Mfps of 14.88 Mfps · 62% of frames lost at line rate 38% SIZING GAP 2.6× 47% of the customer's frames were under 128 bytes. The box was sized for the other 53%.

How we run it for you

RFC 2544 in CloudLAB: a test plan, a bed and a report with a signature

The method is public. The tester, the bed, the discipline to run 60-second trials at 7 frame sizes and the experience to read a loss curve are what you rent from us.

Benchmark of one device

The 4 standard tests or all 6, on your frame sizes and modifiers, on a hardware tester matched to the port speed. Physical unit cabled in Armenia or your virtual router on our hosts. Results in your browser while the run is in progress.

Request a test plan

Shortlist comparison

2 to 5 candidates through the same plan on the same bed, with the datasheet claim next to each measured value. The output is a ranked table and a recommendation you can put in front of procurement.

Compare candidates

Test plan for your tender or acceptance

A written RFC 2544 procedure with your frame sizes, rates, pass criteria and report format, ready to attach to an RFP or an acceptance protocol. We can then run the acceptance on delivery, or your team can, with our plan.

Order a test plan

Run it yourself in CloudLAB

Reserve a tester port pair by the hour, plug in your device or upload your VNF, use our RFC 2544 automation and download the report. Our engineers are on the chat when a result looks off.

Log in to CloudLAB
  • Independent: we sell the test, the vendor sells the box
  • Hardware testers with per-frame timestamps, so latency and loss are measured, not estimated
  • Every run repeatable: plan, configuration and raw counters are yours to keep

Related reading

FAQ

Questions we get before an RFC 2544 run

The vendor already published RFC 2544 results. Why test again?

Because the published run chose the frame sizes, the trial length, the configuration and the modifiers, and rarely says which. Our run uses yours. When the two agree, you have a confirmed number for the tender. When they differ, you have found out before the invoice.

Can you run RFC 2544 on our production network or over a carrier link?

No. RFC 6815 explains why: the throughput search deliberately overloads the path and drops real traffic. For a service link the right method is ITU-T Y.1564, which tests at the contracted CIR and EIR and never above; it is on our menu as well.

Is a throughput result with 0.01% loss acceptable?

Under RFC 2544, no: throughput is the zero-loss rate by definition. Some testers offer a 'search with acceptable loss'; it produces a higher number and a different metric. We report the RFC value and, if you ask, the loss-tolerant value next to it, labelled as such.

Our device is a firewall. Is RFC 2544 the right test?

Only for its raw forwarding path with security features off, which is not how you will run it. For a firewall or NGFW use RFC 9411: HTTP and HTTPS transactions, TLS inspection and IPS enabled. We run both when a tender asks for a packet number and a decision needs the real one.

How long does a full run take and what do you need from us?

4 tests, 7 frame sizes, bidirectional, on one port pair: 3 to 5 hours of tester time, 1 to 2 lab days including setup and the report. We need the device (or its virtual image), the configuration you intend to run, the port speed and the frame sizes or traffic profile you care about.

IPv6, VLAN tags, MPLS, jumbo frames?

IPv6 follows RFC 5180 with the same tests and its own frame sizes. VLAN and MPLS headers are added to the frame format and stated in the report. Jumbo frames up to 9216 bytes are added as extra sizes when your network uses them; the RFC allows adding sizes, never dropping the 7.

Put the datasheet on the bed

Send us the model or the shortlist, the port speed and the frame sizes your traffic actually uses. You get back an RFC 2544 test plan with tests, modifiers, lab days and price. Test. Compare. Decide.

Request a test plan Log in to CloudLAB

Send the shortlist

You have the method. Now get the numbers.

Send the shortlist and the KPIs that matter. An engineer replies within one business day with a test plan draft and a quote.

Prefer to chat? Message an engineer on WhatsApp

We use what you send only to answer you. See our Privacy Policy.