Skip to content

Two vendors on one bench before they meet in your network

We put your device next to the implementations it will talk to: emulated peers of several vendors from the bench generators and real second-vendor boxes in the same rack. Every pair runs your configuration and your software versions, through session setup, policy, failover and the negative cases where one side sends an option the other does not expect. You get a compatibility matrix with a pass or a fail per pair, the logs of both sides and a fix list for the vendor. From 1 week.

Request an interop test What we pair
Compatibility matrix, one device role
ABCD
BGP session, policy, 1M routes
OSPF and IS-IS adjacency, SPF
EVPN type 2 and multi-homing
IPsec IKEv2 setup and rekey
Failover between the two sides

PassPass with a noteFail

  • From 1 weekfor one device role and up to 4 peers
  • 1G to 100Gports on the bench, both sides cabled
  • 2 logs per pairyour side and the peer side, in the report
  • Your versionsthe firmware you will deploy, on both ends
The pair on the bench
Emulated peers several implementations BGP OSPF IS-IS EVPN IPsec Your device Second vendor real box in the rack Your configuration Your software versions Logs of both sides

Why a second implementation

Three things a single-vendor lab cannot show you

A conformance test proves the device follows the RFC. An interoperability test proves it works with the implementation on the other end of the cable, which reads the same RFC in its own way.

  1. Optional fields and defaults

    Both sides are compliant, one sends a capability the other ignores, and the session stays up with half the routes. The RFC allows both readings; only a pair test shows which one your network gets.

  2. Timers that never match

    Hello, hold, DPD and rekey timers have vendor defaults that differ by a factor of 3. The pair works on a quiet bench and flaps under load. We run the pair with the timers of your templates and with traffic.

  3. The failover nobody rehearsed

    A link is pulled between two vendors and each one converges by its own rules. The gap in milliseconds is a property of the pair, and it goes into the report per pair.

What we pair

Six protocol areas, each with its own negative cases

The pairs come from your network diagram: the device under test against every implementation it will peer with. For each area the table shows what is checked and which negative cases are part of the run.

AreaPairs on the benchWhat is checkedNegative cases
01Routing BGP, OSPF and IS-IS against emulated peers and a second-vendor router Session setup, address families, policy, route exchange, convergence after a link loss Unknown capabilities, unexpected attributes, MTU mismatch, authentication mismatch
02MPLS and segment routing LDP, RSVP-TE and SR-MPLS between two implementations Label exchange, label stack depth, LSP setup, fast reroute between the two sides Unsupported TLVs, SID conflicts, label range mismatch
03EVPN and VXLAN A leaf of one vendor with spines and leaves of another Route types 2, 3 and 5, multi-homing, MAC mobility, ARP suppression, traffic across the overlay Different ESI handling, sequence number conflicts, inconsistent VNI to VRF mapping
04IPsec and IKEv2 Gateways of two vendors, 1 to 5,000 tunnels IKE and child SA setup, cipher negotiation, rekey, NAT traversal, DPD, traffic inside Mismatched proposals, fragmentation, rekey collisions, lifetime defaults
05TLS and HTTPS Clients and servers of several stacks through a proxy or firewall TLS 1.2 and 1.3 handshakes, cipher selection, certificates, inspection with traffic inside Unsupported extensions, 0-RTT, renegotiation, certificate chains of 3 and 4
06Wi-Fi Access points with clients of several chipsets, 10 to 200 clients Association, WPA3 and WPA2 mixed, roaming with 802.11r, k and v, throughput per client Legacy data rates, band steering refusals, PMF mismatch

Routing, MPLS and EVPN pairs run against emulated peers and against a real second-vendor device when you ship one or we have it in the rack. Security and Wi-Fi pairs run against the emulated clients and servers of the bench.

How a project runs

Four steps from the network diagram to the fix list

  1. 1

    Pairs

    Day 1

    Your diagram and device list become a pair list: who peers with whom, over which protocol, with which configuration template

    Pair list and quote

  2. 2

    Bench

    Days 2–3

    Your device in the rack or your virtual appliance on our hosts, the second vendor cabled next to it, emulated peers configured from your templates

    Bench diagram, port map, both configurations

  3. 3

    Run

    Days 3–5

    Every pair through setup, policy, scale, failover and the negative cases, with traffic. Each fail is reproduced once more with captures on both sides

    Matrix filled in, captures per fail

  4. 4

    Report

    Day 5 and later

    The matrix, the evidence per pair, the configurations of both ends and a fix list written for the vendor: what to change, on which side, with the capture that shows why

    Report, fix list, one call with the vendor on request

Typical scenarios

Where the pair test pays for itself

A second vendor arrives in the core, a tender asks for a mixed estate, an integrator has to sign for a network built from three price lists. Three cases from projects of this type, with the numbers rounded and no client named.

Composite scenarios from projects of this type. Numbers are realistic and not from one client.

Vendor swap in the core
A new router model replaces half of the core, the other half stays. BGP comes up, 1M routes load, and a community attribute set by the old side is silently dropped by the new one. Found on the bench in the policy pass, fixed with one line of configuration before the cutover.
Mixed fabric from a tender
Leaves from one vendor, spines from another, both EVPN-compliant. All-active multi-homing works until a link in the ESI fails and the two sides disagree on the mass withdraw. The pair test shows a 4-second half-black hole; the tender report says which side to fix.
Site-to-site VPN estate
Gateways of two vendors, a few hundred tunnels. Setup passes, the rekey of the IKE SA fails on one direction after the lifetime expires, every 8 hours in production. On the bench it fails in an afternoon, with the proposals of both sides in the capture.

The report

A matrix, and behind every cell the evidence

The first page is the matrix: pairs down the side, implementations across, a pass, a fail or a pass with a note in every cell. Every cell links to a record with the configuration of both ends, the captures and the counter values at the moment of the fail.

What the record of one pair holds

Configurations
The device under test and the peer, as they ran, so the vendor can reproduce the case without a call.
Captures
A capture per fail from each end of the cable: the option one side sent and what the other side did with it.
Numbers
Routes received, sessions up, tunnels established, convergence gap in milliseconds, per pair and per run.
Fix list
What to change, on which side, in which version it is known to be fixed when the vendor has said so.

Functional and conformance testing Routers and switches on the bench How we test BGP, EVPN, IPsec and more

P-03 EVPN and VXLAN Fail

Mass withdraw after an ESI link failure, leaf A with spine B

Pair
Leaf under test (vendor A, your firmware) against spine and peer leaf of vendor B, all-active multi-homing on one ESI
Procedure
5,000 MAC addresses learned behind the ESI, traffic from the emulated hosts across the overlay, one ESI link pulled, forwarding timed per flow
Result
Mass withdraw sent per MAC instead of per ESI; gap of 4 s on the worst flow, 2.1 s median; 0 ms expected by the design
Evidence
Captures on both ends, BGP EVPN table of the peer before and after, per-flow loss from the generator
Fix
Leaf side: enable the ESI-based withdraw the vendor lists for this release; retest passed with a gap of 180 ms

Questions before the pair list

What buyers and integrators ask first

Do you have the second vendor's device, or do we ship it?

Both happen. Routing, switching and security devices of the common vendors are often in the rack already; if not, you ship the second device to the lab or run it as a virtual appliance on our hosts. Emulated peers of several implementations are always available from the bench generators.

How is this different from a conformance test?

Conformance checks one device against the standard. Interoperability checks two implementations against each other, with your configuration on both. Many projects run both: conformance first to find the clear defects, then pairs to find what only appears between two readings of the same RFC. The conformance service is described on its own page.

Which configuration runs on the bench?

Yours. We take the templates from both sides of the pair, with the timers, authentication, policy and address families of production. A test on default settings would show you a pair that never exists in your network.

What if the two vendors blame each other?

The report carries the capture from each end of the cable, so the option sent and the reaction to it are both on record. The fix list says which side changes what. On request we join the call with both vendors and walk through the capture.

Can you test more than two vendors at once?

Yes. One device role against up to 4 peer implementations fits the 1-week project; a tender with several roles and 3 or more vendors is planned as a matrix with its own schedule, usually 2 to 3 weeks.

Can we watch the run?

You get a CloudLAB login for the project: the bench, the generator statistics and the console of your device in a browser, live, while the pairs run. Your engineer can repeat any case after the project.

Send the network diagram and the two device lists. The pair list and the quote come back in a day.

From 1 week for one device role. The second vendor's device comes from the rack, from you or as a virtual appliance.

Request an interop test All services

Send the shortlist

You have the method. Now get the numbers.

Name the models 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.