--- title: "RFC 2889 benchmarking: switch forwarding, MAC learning, congestion | TEST4NET" description: "RFC 2889 as we run it in CloudLAB: full-mesh zero-loss throughput on every port, 30-second trials, head-of-line blocking, address capacity and learning rate, errored frames, broadcast. Test plan and report." --- [Skip to content](https://test4net.com/methodologies/rfc-2889#main-content) [![TEST4NET](https://test4net.com/hubfs/test4net-logo-fixed-2.svg)](https://test4net.com/?hsLang=en) - Services - Products - Resources - Company - [English](https://test4net.com/methodologies/rfc-2889) - [Русский](https://test4net.com/ru/methodologies/rfc-2889) - [Հայերեն](https://test4net.com/hy/methodologies/rfc-2889) [News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en) - [English](https://test4net.com/methodologies/rfc-2889) - [Русский](https://test4net.com/ru/methodologies/rfc-2889) - [Հայերեն](https://test4net.com/hy/methodologies/rfc-2889) What we test By technology Industries [Load & Performance Testing Throughput, sessions and latency up to and past the rated limit](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing Features against the spec, RFC compliance with evidence](https://test4net.com/services#functional) [Interoperability Testing Multi-vendor behaviour, before it reaches production](https://test4net.com/services#interop) [Security & Resilience Testing NGFW, IPS and VPN efficacy and performance with threats on the wire](https://test4net.com/services#security) [Test Plan & Methodology Design What to test, how, and what counts as a pass](https://test4net.com/services#test-plan) [Test Automation & CI/CD Regression suites wired into your release pipeline](https://test4net.com/services#automation) [Training Programs Hands-on courses for your test engineers](https://test4net.com/services#training) [Equipment Repair Diagnostics and repair of test equipment](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en) Routing & Switching RFC 2544 and RFC 2889 on real ports, 1G to 100G Firewalls & NGFW RFC 9411 throughput with inspection switched on SD-WAN & WAN Path selection and QoS under emulated WAN conditions Cloud & NFV Virtual appliances and cloud services under load 5G & Mobile Core Transport and core functions under subscriber traffic Wi-Fi Wi-Fi 6 clients and access points, Wi-Fi 7 in progress Storage & Infrastructure Storage networks and servers under realistic I/O AI / Switching Fabric (RoCEv2) Lossless Ethernet for GPU clusters: PFC, ECN, fabric load All technologies Telecom Operators Pre-deployment acceptance and vendor comparison Network & Security Vendors Independent validation of your product claims System Integrators Proof for the customer before the rollout Enterprise & Banks Upgrades and new platforms checked before production All industries Not sure where to start? Test plan and quote in 1–3 business days Tell us what you run and what worries you. We propose the tests, tools and timeline. [Request a test plan](https://test4net.com/contacts?hsLang=en) CloudLAB How It Works Pick a scenario, run it in the live lab, get the report Equipment & Capabilities L2-3 to 100G, L4-7 past 200G, Wi-Fi, WAN emulation Access Plans Hourly sessions, subscriptions, dedicated racks Hosted DUT Testing Ship the box or upload the VM, we run the tests [Open the CloudLAB portal](https://lab.test4net.com) Our tools Traffic Generator L4-7 and security traffic past 200 Gbit/s, app mix library WANemu Delay, jitter, loss and bandwidth shaping per link [Book a demo](https://test4net.com/contacts?hsLang=en) New: our own test tools Our own tools, in beta this autumn Built in our lab, priced per gigabit. Join the beta list and see them first. [Join the beta list](https://test4net.com/contacts?hsLang=en) Read Technologies / Protocols Methodologies [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) FAQ How the lab, sessions and reports work BGP Route exchange, policy and convergence OSPF & IS-IS IGP adjacency, flooding and SPF timing MPLS & Segment Routing LDP, RSVP-TE and SR-MPLS label paths EVPN / VXLAN Overlay fabrics, MAC/IP routes, multi-homing IPsec & IKEv2 Tunnel setup, rekeying and throughput TLS / HTTPS Handshakes, cipher suites and inspection RoCEv2 Lossless Ethernet, PFC and ECN for AI fabrics Wi-Fi 6 / 6E / 7 802.11ax/be, OFDMA, MLO and roaming All protocols [RFC 2544 Throughput, latency, frame loss and back-to-back](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889 LAN switch benchmarking: forwarding, MAC learning, congestion](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511 Firewall and NGFW performance benchmarking](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) RFC 6349 TCP throughput and buffer delay testing RFC 5180 IPv6 benchmarking methodology ITU-T Y.1564 Ethernet service activation: CIR, EIR, KPIs per service ITU-T Y.1731 Ethernet OAM: delay, jitter, loss and SLA monitoring TR-398 Wi-Fi in-premises performance test plan All methodologies Read [Case studies, test insights and lab notes Blog](https://test4net.com/blog?hsLang=en) [What is changing in network testing and infrastructure Industry News](https://test4net.com/news?hsLang=en) How the lab, sessions and reports work FAQ [About Us Independent lab in Armenia, team and history](https://test4net.com/about?hsLang=en) [Why TEST4NET What you get that vendor slides never show](https://test4net.com/why-test4net?hsLang=en) Lab & Certifications Bench capacity, methods and the standards we test against Partners Test tool vendors and IT partners we work with [Contacts Talk to an engineer, not a sales bot](https://test4net.com/contacts?hsLang=en) [Support portal](https://test4net.com/support?hsLang=en) - Services What we test [Load & Performance Testing](https://test4net.com/services/load-performance-testing?hsLang=en) [Functional & Conformance Testing](https://test4net.com/services#functional) [Interoperability Testing](https://test4net.com/services#interop) [Security & Resilience Testing](https://test4net.com/services#security) [Test Plan & Methodology Design](https://test4net.com/services#test-plan) [Test Automation & CI/CD](https://test4net.com/services#automation) [Training Programs](https://test4net.com/services#training) [Equipment Repair](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=en) By technology Routing & Switching Firewalls & NGFW SD-WAN & WAN Cloud & NFV 5G & Mobile Core Wi-Fi Storage & Infrastructure AI / Switching Fabric (RoCEv2) All technologies Industries Telecom Operators Network & Security Vendors System Integrators Enterprise & Banks All industries [Not sure where to start? Test plan and quote in 1–3 business days](https://test4net.com/contacts?hsLang=en) - Products CloudLAB How It Works Equipment & Capabilities Access Plans Hosted DUT Testing [Open the CloudLAB portal](https://lab.test4net.com) Our tools Traffic Generator WANemu [Book a demo](https://test4net.com/contacts?hsLang=en) [New: our own test tools Our own tools, in beta this autumn](https://test4net.com/contacts?hsLang=en) - Resources Read [Blog](https://test4net.com/blog?hsLang=en) [Industry News](https://test4net.com/news?hsLang=en) FAQ Technologies / Protocols BGP OSPF & IS-IS MPLS & Segment Routing EVPN / VXLAN IPsec & IKEv2 TLS / HTTPS RoCEv2 Wi-Fi 6 / 6E / 7 All protocols Methodologies [RFC 2544](https://test4net.com/methodologies/rfc-2544?hsLang=en) [RFC 2889](https://test4net.com/methodologies/rfc-2889?hsLang=en) [RFC 9411 / RFC 3511](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) RFC 6349 RFC 5180 ITU-T Y.1564 ITU-T Y.1731 TR-398 All methodologies Read [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=en) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=en) FAQ How the lab, sessions and reports work - Company [About Us](https://test4net.com/about?hsLang=en) [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en) Lab & Certifications Partners [Contacts](https://test4net.com/contacts?hsLang=en) [News](https://test4net.com/news?hsLang=en) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=en) Methodology · LAN switch benchmarking # RFC 2889: the switch test where every port talks to every port RFC 2544 measures a port pair. RFC 2889 loads the whole switch: fully meshed traffic on N ports, congestion on purpose, a MAC table filled until it floods. 10 tests, 30-second trials, forwarding rate reported against the theoretical line. This page shows the method as we run it in CloudLAB and what the report contains. - Fully meshed traffic: each port sends to all others in round robin, so the whole fabric carries load at once - A congestion block of 4 ports exposes head-of-line blocking and backpressure in one 30 s trial - 10 tests: 4 meshed patterns, congestion, forward pressure, address capacity, learning rate, errored frames, broadcast [Get an RFC 2889 test plan](https://test4net.com/methodologies/rfc-2889#lead-form) [Jump to the 10 tests](https://test4net.com/methodologies/rfc-2889#tests) ZERO-LOSS THROUGHPUT % OF LINE RATE PER PORT · RFC 2889 §5.1 PORT PAIR · RFC 2544 24-PORT FULL MESH · RFC 2889 LINE RATE · 100% 50% 71% 86% 96% 100% 100% 100% 100% FABRIC-BOUND: BUFFER + 24 LOOKUPS PER SLOT 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B Every port to every port, or the claim is untested A typical 24-port result. In a port pair the switch holds line rate at every size. In a full mesh at 64 bytes the fabric and the shared buffer serve 24 lookups per slot, and the number drops to 71%. The datasheet printed the first chart. Where it fits ## A switch is sold on the fabric, so test the fabric RFC 2889 extends RFC 2544 to LAN switching devices: same frame sizes, same test template, but the traffic goes through all ports at once and the test list covers what a switch does besides forwarding: learns addresses, handles congestion, drops bad frames and replicates broadcasts. ### Top-of-rack and campus switches Any device that switches at the MAC layer: a 48×25 GbE leaf, a 100 GbE spine, a campus access stack, a storage switch. Full mesh and many-to-one are the patterns their buyers actually run. ### 'Non-blocking' and 'wire speed' claims Both claims come from a port pair or from the ASIC datasheet. A 24-port mesh at 64 bytes checks the switching matrix, the buffer and the lookup engine together, which is the only way to confirm them. ### Routers and firewalls go elsewhere L3 forwarding belongs to RFC 2544 and RFC 5180; firewalls and NGFW to RFC 9411. RFC 2889 is the right tool when MAC learning, VLANs and congestion decide the result. Test bed ## N tester ports, one clock, one switch Every DUT port under test has a tester port behind it. One instrument clocks all of them, so all ports start within 300 ms, every frame carries a signature and a timestamp, and the flood count is taken on every port, including the ones that should have stayed silent. HARDWARE TESTER · PORTS 1 … N/2 TX + RX ON EVERY PORT · ONE CLOCK FRAME STREAM, PER PORT 64 · 128 · 256 · 512 · 1024 · 1280 · 1518 B 1 to 256 MAC addresses per port Round robin to all other ports, fixed order Signature field + timestamp in every frame ALL PORTS START WITHIN 300 ms N/2 PORTS BIDIRECTIONAL DUT · LAN SWITCH ONE FABRIC · ONE MAC TABLE · N PORTS STORE & FORWARD CUT-THROUGH 802.1Q · VLAN FLOW CONTROL AGING TIME AS AGREED STP · LLDP · SNMP OFF OR FILTERED N/2 PORTS COUNTED · TIMED HARDWARE TESTER · PORTS N/2+1 … N RX + TX · SAME INSTRUMENT, SAME CLOCK PER-PORT COUNTING Received: right port + right signature Flood count: frames on the wrong port DUT's own frames (STP, LLDP) excluded Timestamp delta: latency, every frame RECEIVED ≠ FLOODED ≠ MISFORWARDED LEARNING FIRST, VERIFIED a learning frame per address at 50 fps, one verification frame each, zero floods required · aging time \> learning + 30 s trial + setup ### Hardware tester, 8 to 48 ports Ports at 1, 10, 25, 100 and 400 GbE on one chassis. Each port has its own MAC addresses, 1 to 256, and sends to all other ports in round robin as §5.1.3 requires. Software generators cannot hold 48 ports at 64 bytes within 1% of each other, so we do not use them for this RFC. ### The switch, as it will be deployed Production configuration: VLANs, STP mode, flow control, aging time, QoS, port security. All of it exported to the report. Protocols the switch itself transmits (STP, LLDP, SNMP) are turned off or filtered out of the counts, as §5.7 advises. ### Meshed traffic with a signature Frame sizes 64 to 1518 bytes, 802.1Q tagged frames to 1522 if the switch takes them, a signature field after byte 56 in every frame. Received means the right destination port and the right signature. Anything else is a flood or a misforward and is counted as such. ### Learning first, and verified Before every trial the tester sends a learning frame for each address, at 50 frames per second or slower if the switch needs it, then checks that nothing floods. Aging time on the switch is set longer than learning plus the trial plus setup, or the addresses expire mid-run and the result is a flood count instead of a forwarding rate. Test conditions ## 8 parameters the RFC asks you to fix before the first frame RFC 2889 adds no frame sizes; it adds traffic shape. Every value below goes into the test plan and into the report, because changing one of them changes the number. | Parameter | RFC 2889 value | Range | What it changes | | --- | --- | --- | --- | | Frame size | 64, 128, 256, 512, 1024, 1280, 1518 B | tagged to 1522 B; jumbo by agreement | Lookups per second: 64 B is 14.88 million per 10 GbE port | | Interframe gap | 96 bits, the medium minimum | 88 bits in the forward pressure test only | Below 96 bits the offered load exceeds the MOL by 1 byte per frame | | Intended load (ILoad) | % of MOL per port | searched from 100% down | Full mesh at 100% on N ports oversubscribes nothing; many-to-one does, on purpose | | Burst size | 1 frame (constant load) | 1 to 930 frames | Bursts hit the buffer; constant load hits the lookup engine | | Addresses per port | 1 | 1, 2, 4 … 256 (powers of 2) | More addresses, more table lookups per frame, random source and destination pairs | | Trial duration | 30 s | 1 to 300 s | Short enough for 10 tests × 7 sizes, long enough to fill the buffers | | Learning rate | 50 frames/s or lower | per switch | Too fast and the table misses entries; every miss becomes a flood | | Aging time | longer than learning + trial + setup | per switch | Addresses that age out mid-trial turn forwarding into flooding | RFC 2544 runs a 60-second trial; RFC 2889 recommends 30 seconds because 10 tests across 7 frame sizes and several traffic patterns would otherwise take days. Where a tender needs 60 s trials for the meshed throughput, we run them and say so in the report. ### Always in our runs - Learning verified before every trial (§3) - Signature field per port (§4) - Round-robin destinations, fixed order (§5.1.3) - All ports start within 300 ms (§5.1.3) - Flood count on every port (§5.1.4) - Loopback pre-test of the bed Learning checked, a signature per port, round-robin destinations that do not change under congestion, flood counts everywhere. This is what the RFC marks MUST, and what separates a forwarding rate from a guess. ### Agreed per project - 2 to 256 addresses per port (§5.1.2) - Burst sizes 1 to 930 frames (§5.1.2) - Half-duplex legacy ports (§5.1.2) - Tagged frames to 1522 B (§4) - Two switches over one uplink (§5.3) - Jumbo frames to 9216 B Each of these moves the number. 256 addresses per port on a full mesh is the hardest case the RFC describes and the one we recommend for a leaf switch; bursts of 930 frames are how a storage network looks to a switch. The 10 tests ## What RFC 2889 measures, section by section Each test runs for every frame size. The first 4 load the fabric with different traffic shapes; 5.5 and 5.6 provoke it; 5.7 and 5.8 size the MAC table; 5.9 and 5.10 check what the switch does with frames it should drop and frames it must copy. 1. 5.1Meshed traffic ### Fully meshed throughput, frame loss and forwarding rate Every port sends to every other port in round robin at the same intended load. A search finds the throughput: the highest load with zero loss on all ports. The forwarding rate is also recorded at the maximum offered load (FRMOL) and at its peak (MFR), because a switch that drops 2% at 100% may still forward more frames than at 95%. Output: throughput, FR, FRMOL and MFR per frame size, plotted against the theoretical line 2. 5.2Meshed traffic ### Partially meshed one-to-many and many-to-one One port sends to N ports, then N ports send to one. The second half is the storage and backup pattern: N sources into one port, bursty by nature. Burst size and ILoad are set so the sum stays under the receiving port, or over it when the buyer wants the buffer measured. Output: throughput and frame loss per direction and per frame size, burst size cited 3. 5.3Meshed traffic ### Partially meshed, two switches over one uplink Two DUTs with many access ports and a single uplink between them, traffic from the ports of one switch to the ports of the other. The uplink is the bottleneck by design; the test shows whether the switches share it fairly and how much they lose when the access traffic exceeds it. Output: throughput, frame loss and forwarding rate across the uplink, per frame size 4. 5.4Meshed traffic ### Partially meshed unidirectional traffic Half of the ports transmit, the other half only receive, all streams one way. This is the pattern of a replication or a mirroring site and the easiest one for a switch, so a loss here is a loss everywhere. It also separates the forwarding path from the receive path on the same port. Output: throughput and forwarding rate per frame size; usually the best number the switch gets 5. 5.5Congestion ### Congestion control: head-of-line blocking and backpressure A block of 4 ports. Source A sends at 100%, alternating between an uncongested and a congested receiver; source B sends 100% to the congested one. The uncongested port should get every frame: loss there is head-of-line blocking. The congested port receives 150% and should lose 33%: zero loss there means the switch applied backpressure (flow control) and slowed the sources. Output: frame loss on the uncongested and the congested port; verdict: HOLB present or not, backpressure present or not 6. 5.6Congestion ### Forward pressure and maximum forwarding rate Two parts. The forwarding rate is measured while the intended load steps up from the throughput to the MOL; the highest value is the MFR. Then frames are sent with an 88-bit gap instead of 96, overloading the input by 1 byte per frame. A forwarding rate above the MOL on the output means the switch transmits with an illegal gap: forward pressure detected. Output: MFR with the ILoad cited; FR at 88-bit IFG; 'Forward pressure detected' when FR exceeds the MOL 7. 5.7Address table ### Address caching capacity 3 ports: learning, test and monitoring. The learning port offers N source addresses, the test port then sends N frames back to them. If the monitoring port sees any frame, or the learning port receives fewer than sent, the table was full at N. A binary search between 0 and the vendor's maximum, with a full aging pause between iterations, ends on the real capacity. Output: addresses supported per port, with the flood count per iteration on all 3 ports 8. 5.8Address table ### Address learning rate Same 3-port setup, address count fixed at the capacity found in 5.7, learning frame rate varied. The highest rate at which every address is learned, with zero floods on the monitoring port, is the learning rate. It decides how long a switch stays blind after a topology change or a wave of VM migrations. Output: learning frames per second with 0 floods; table of rate, frames offered, frames forwarded, flood count 9. 5.9Integrity ### Errored frames filtering 5 frame types sent through the switch: oversize (over 1518 B), undersize (under 64 B), CRC error, dribble bits and alignment error. Undersize, CRC and alignment errors must not come out of the other side; oversize should not, unless tagged frames to 1522 B are supported; dribble bits must be corrected and the frame forwarded. A pass or fail for each, with counts kept for the record. Output: pass / fail × 5, frame counts attached; a cut-through switch is the usual candidate for a fail on CRC 10. 5.10Integrity ### Broadcast forwarding and latency One port sends broadcast frames at a set load; every other port measures forwarding rate and loss. Then a single broadcast frame is sent and the latency to each receiving port is measured. Broadcast replication is a separate function in the ASIC, and 1 port in 48 that gets the frame 40 µs late is what this test is for. Output: broadcast forwarding rate and loss per frame size; latency per receive port Procedure ## How a run goes, from the empty bed to the signed report 5 stages. The meshed tests take most of the lab time; the congestion block and the address tests take most of the engineering. 1. 00 ### Bed without the DUT Tester ports looped through the same cables, optics and panel. Full mesh at 64 bytes must return 100% with zero loss and zero floods, or the bed is fixed first. 2. 01 ### Learning, then proof Aging time read from the switch and set above learning + 30 s + setup. Learning frames per address at 50 fps. A verification frame per address; any flood and learning is repeated slower. 3. 02 ### Meshed trials Full mesh, one-to-many, many-to-one, unidirectional. Binary search for throughput per frame size, then FR at MOL and the MFR sweep. 30 s trials, all ports started within 300 ms. 4. 03 ### Congestion and pressure The 4-port block for HOLB and backpressure on every frame size, then the 88-bit IFG run. Counters are read on the switch after each trial and compared with the tester. 5. 04 ### Table, filters, broadcast Binary search for address capacity with an aging pause per iteration, learning rate sweep at that capacity, the 5 errored frame types and the broadcast pair. Report assembled the same day. CONGESTION CONTROL · 4-PORT BLOCK · RFC 2889 §5.5 100% OF MOL PER SOURCE · 30 s · EVERY FRAME SIZE SOURCE A · 100% 1st frame to the uncongested port, 2nd to the congested one, repeat SOURCE B · 100% every frame to the congested port same frame count as source A 50% → UNCONGESTED 50% → CONGESTED 100% → CONGESTED DUT OUTPUT QUEUES UNCONGESTED · 50% IN, 50% OUT +50% CONGESTED · 150% IN, 100% OUT Where does the 50% go: dropped here, or elsewhere? 50% OUT 100% OUT, LINE RATE UNCONGESTED PORT receives 50% of source A's frames expected loss: 0 CONGESTED PORT offered 150%, can carry 100% expected loss: 33% LOSS ON THE UNCONGESTED PORT = HEAD-OF-LINE BLOCKING 0 LOSS ON THE CONGESTED PORT = BACKPRESSURE (FLOW CONTROL) 33% CONGESTED, 0 UNCONGESTED = CLEAN OUTPUT QUEUING The congestion block as the RFC draws it: two sources, two receivers, 150% of line rate into one of them. Where the loss lands tells you how the switch is built. On the congested port only: a clean output-queued design. On both: head-of-line blocking from a shared input buffer. Nowhere: flow control that slowed your sources down. ### 4 numbers that decide pass or fail - 0 Frames lost on the uncongested port of the congestion block. Any loss there is head-of-line blocking, and a switch with HOLB lets one busy server slow down a port that has nothing to do with it. - 33% Expected loss on the congested port at 150% offered load without flow control. 0% means backpressure: the switch paused the sources instead of dropping frames. Neither is wrong by itself; the report says which one you have. - ≤ MOL Forwarding rate on the output port while the input is fed with an 88-bit gap. A rate above the MOL means the switch forwards with an illegal gap, which the next device may count as errors. - 0 Frames on the monitoring port during the address tests. One frame there means the table was full and the switch flooded, which is how a 'supports 32K MACs' claim becomes 16,384 in practice. ### Anatomy of a 30-second trial - **Learning**A learning frame per address at 50 fps, aging timers reset, DUT given time to finish flooding. - **Verification**One frame per address; a flood on any port sends the trial back to learning. - **Trial, 30 s**All ports transmitting within 300 ms of each other; frames counted as received or flooded per port, timestamps kept. - **Drain and counters**2 s for in-flight frames, tester counts frozen, switch interface counters read and attached. Report ## What you get after the run One PDF per switch with every number the RFC asks for and the context to repeat the run. Raw tester exports and the switch configuration are attached. ### Results, per frame size - Full mesh throughput, FRMOL and MFR, plotted against the theoretical line - One-to-many, many-to-one and unidirectional throughput with burst size and ILoad cited - Congestion block: loss on both receive ports, HOLB and backpressure verdicts - Forward pressure: FR at 88-bit IFG against the MOL - Address capacity and learning rate with the flood counts per iteration - Errored frames: 5 pass/fail lines; broadcast forwarding rate and per-port latency ### Context, so the run can be repeated - Switch model, hardware revision, software version and the full configuration export - Port map: which tester port on which DUT port, speed, optics, VLAN membership - Addresses per port, learning rate, aging time and burst size for every test - Tester model, firmware and port speeds; loopback pre-test result - DUT-originated frames (STP, LLDP, SNMP) and how they were excluded from the counts - Trial duration and start skew between ports, per test RFC 2889 · TEST REPORT 24 × 25 GbE · FULL MESH · 30 s TRIALS 5.1Full mesh throughput, 64 B 5.1Full mesh throughput, 1518 B 5.5Head-of-line blocking, 64 B 5.5Backpressure 5.6Forward pressure, 88-bit IFG 5.7Address caching capacity 5.8Address learning rate 5.9Errored frames filtering 71.4% 100% 9% lost none ≤ MOL 16,384 1,200/s 4 of 5 26.6 Mfps per port of 37.2 · datasheet: wire speed, non-blocking 2.03 Mfps per port · 0 lost of 1.46 G sent uncongested port lost 9% · shared input buffer congested port lost 33% at 150% offered · no flow control FR 37,202,380 fps at 88-bit gap · MOL 37,202,381 datasheet: 32K · floods on Mport from 16,385 · 15 iterations 16,384 addresses, 0 floods · 1,500/s floods 212 CRC-errored frames forwarded in cut-through mode ATTACHED CONFIG EXPORT PORT MAP GRAPHS PER SIZE COUNTERS · PCAP Values are illustrative. Your report carries your numbers, per frame size and per traffic pattern. ### When there are 2 candidates - One test plan, one bed, one tester for both switches; results in a single table with the same traffic patterns and addresses per port - A page per difference that matters: where one switch floods, blocks or loses first - A short recommendation that names the better switch for your traffic, and the test where it was decided From practice ## Non-blocking on paper, 71% in the mesh A customer was choosing a 48-port 25 GbE leaf for a storage fabric and had an RFC 2544 report from the vendor: wire speed on every frame size, port pair, bidirectional. We ran RFC 2889 on 24 ports. Full mesh at 1518 bytes: 100%. Full mesh at 64 bytes: 71% of line rate, 29% of the frames gone. The congestion block explained it. 9% loss on the uncongested port: head-of-line blocking from a shared input buffer. For a storage fabric with many-to-one bursts all day, that is one busy host slowing down the rest. The second candidate lost 33% on the congested port and 0 on the other, exactly what the RFC expects from a switch without HOLB. It cost 12% more and was the one they bought. The fabric is the product. Test the fabric. SAME SWITCH · 64 B · TWO TRAFFIC SHAPES PORT PAIR · THE RFC 2544 RUN 37.2 Mfps of 37.2 per port · wire speed, as printed 100% 24-PORT FULL MESH · THE RFC 2889 RUN 26.6 Mfps of 37.2 per port · 29% of frames lost at line rate 71% LOSS ON THE UNCONGESTED PORT 9% Head-of-line blocking: one busy host slowed down the other 23. What we run ## RFC 2889 as a service, in CloudLAB or on your site A hardware tester with enough ports for your switch, an engineer who has run this RFC on vendor gear for 20 years, and a report you can put in a tender. ### Benchmark of one switch All 10 tests or the 4 meshed ones, on your frame sizes, addresses per port and VLAN layout, with as many ports as the switch has. Physical unit cabled in Armenia or shipped to us. Results in your browser while the run is in progress. [Request a test plan](https://test4net.com/contacts?hsLang=en) ### Shortlist of 2 or 3 Same plan, same bed, same day for each candidate. A results table that puts full mesh, HOLB and address capacity side by side, and names where the cheaper one is good enough. [Compare candidates](https://test4net.com/contacts?hsLang=en) ### Acceptance before rollout Your switch, your configuration, your traffic patterns, run as pass or fail against the numbers in the contract. Done before the invoice, with the vendor welcome to watch. [Set up an acceptance run](https://test4net.com/contacts?hsLang=en) ### Your engineers, our bed CloudLAB access to the tester ports with the RFC 2889 plan loaded. Run it yourself, as many times as you need, with our engineer on chat. [Log in to CloudLAB](https://lab.test4net.com/) - Independent: we sell the test, the vendor sells the switch - Hardware tester on every port, one clock, 300 ms start skew or better - Every number in the report is reproducible from the attached plan and exports ### Read next - [MethodologyRFC 2544: zero-loss benchmark for switches and routers](https://test4net.com/methodologies/rfc-2544?hsLang=en) - [MethodologyRFC 9411: firewall and NGFW benchmarking with every feature on](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=en) - [Why TEST4NETWhy an independent bench beats a vendor demo](https://test4net.com/why-test4net?hsLang=en) FAQ ## Questions we get before an RFC 2889 run We have the vendor's RFC 2544 report. Is RFC 2889 really different? RFC 2544 loads one port pair; RFC 2889 loads all ports at once and adds congestion, MAC table and filtering tests. A switch passes 2544 on the port ASIC alone. It passes 2889 on the fabric, the shared buffer and the lookup engine together. 'Non-blocking' is a 2889 claim, and most datasheets only ran 2544. Do you test all 48 ports? As many as the tester has at that speed, typically 16 to 32 at 25 GbE and 8 to 16 at 100 GbE. The RFC lets the mesh run on any subset; the report says which ports. For a 'non-blocking' claim we fill the ASIC's full bandwidth, which takes fewer ports at 100 GbE than at 10. Why 30-second trials when RFC 2544 says 60? The RFC recommends 30 s and allows 1 to 300. With 10 tests, 7 frame sizes and several traffic patterns, 60 s trials would double a 2-day run. Buffers of modern switches fill within milliseconds, so 30 s is enough to see loss. If a tender quotes 60 s, we run 60 s. The switch floods during the test. Whose fault is it? Usually the setup: learning frames offered too fast, aging time shorter than the trial, or a hashing scheme that cannot store the chosen MAC pattern. The RFC covers all 3, so we slow learning to 50 fps, set aging above the trial and change the address format before we blame the switch. If it still floods at N addresses, that is the capacity number. Head-of-line blocking or backpressure: which is worse? HOLB is worse for most networks. It means a congested port makes an unrelated port lose frames, so one busy server slows its neighbours. Backpressure means the switch pauses the sources instead of dropping, which suits a storage network and hurts a latency-sensitive one. The report shows which you have; the choice is yours. Does RFC 2889 apply to 100 GbE and 400 GbE switches? Yes. The RFC was written around 10, 100 and 1000 Mbit/s but defines every parameter relative to the medium: minimum IFG, MOL, frame sizes from RFC 2544. We run it at 25, 100 and 400 GbE with the same procedure. The only adjustment is the step size near the MOL, where the tester's gap resolution sets the limit. ## Put the switch in the mesh Send the model or the shortlist, the port count and speed, and the traffic pattern you run: storage, campus, leaf-spine. You get an RFC 2889 test plan back: tests, addresses per port, lab days and price. Test. Compare. Decide. [Request a test plan](https://test4net.com/methodologies/rfc-2889#lead-form) [Log in to CloudLAB](https://lab.test4net.com/) 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](https://wa.me/37491612709) We use what you send only to answer you. See our [Privacy Policy](https://test4net.com/privacy-policy?hsLang=en). [Send the shortlist](https://test4net.com/methodologies/rfc-2889#lead-form) [![TEST4NET LLC](https://test4net.com/hubfs/test4net-logo-fixed.svg)](https://test4net.com?hsLang=en) Independent testing and validation for telecom, information security and cloud infrastructure – real insights, not assumptions. [mailto:sales@test4net.com](mailto:sales@test4net.com) #### Navigate - [Home](https://test4net.com/?hsLang=en) - [Why TEST4NET](https://test4net.com/why-test4net?hsLang=en) - [About us](https://test4net.com/about?hsLang=en) - [Contact](https://test4net.com/contacts?hsLang=en) - [Blog](https://test4net.com/blog?hsLang=en) - [Industry News](https://test4net.com/news?hsLang=en) #### Get in touch Sales [sales@test4net.com](mailto:sales@test4net.com) Support [support.test4net.com](https://support.test4net.com) © 2026 TEST4NET LLC. All rights reserved. [Privacy Policy](https://test4net.com/privacy-policy?hsLang=en) [Legal](https://test4net.com/legal?hsLang=en) ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#organization", "@type" : "Organization", "address" : { "@type" : "PostalAddress", "addressCountry" : "AM", "addressLocality" : "Yerevan", "postalCode" : "0033", "streetAddress" : "3 Hakob Hakobyan Street (Mergelyan Hub)" }, "alternateName" : "TEST4NET", "contactPoint" : { "@type" : "ContactPoint", "availableLanguage" : [ "en", "ru", "hy" ], "contactType" : "sales", "email" : "sales@test4net.com", "telephone" : "+374-60-88-88-99" }, "description" : "Independent, vendor-neutral lab for testing network and cybersecurity products — NGFW, WAF, IPS, DLP and SASE — and an authorized distributor of test, measurement and network infrastructure solutions.", "email" : "sales@test4net.com", "foundingDate" : "2024", "image" : "https://test4net.com/hubfs/og-t4n.png", "logo" : "https://test4net.com/hubfs/test4net-logo-fixed-2.svg", "name" : "TEST4NET LLC", "sameAs" : [ "https://www.linkedin.com/company/test4net/", "https://t.me/TEST4NET", "https://www.facebook.com/people/Test4net-LLC/61591470856077/" ], "telephone" : "+374-60-88-88-99", "url" : "https://test4net.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#website", "@type" : "WebSite", "inLanguage" : "en", "name" : "TEST4NET", "potentialAction" : { "@type" : "SearchAction", "query-input" : "required name=search_term_string", "target" : { "@type" : "EntryPoint", "urlTemplate" : "https://test4net.com/hs-search-results?term={search_term_string}" } }, "publisher" : { "@id" : "https://test4net.com/#organization" }, "url" : "https://test4net.com/" } ```