How we test MPLS and segment routing: label paths under a traffic load

MPLS is where the control plane and the forwarding plane most often disagree. The LSP is up in the CLI and the packets still go somewhere else. We test the two together: every label path on the bench carries traffic, and the generator reports what came out of the far end, with which labels and after how many milliseconds.

The bench

The device under test is a P or a PE router, physical or virtual, on 1G to 100G ports. The generator emulates the surrounding core: LDP neighbours, RSVP-TE head and tail ends, IS-IS or OSPF with segment routing extensions, BGP for VPNv4, VPNv6 and EVPN services. For an SR design the generator pushes label stacks of the depth the design needs, with adjacency and prefix SIDs and, where used, binding SIDs and flex-algo.

Services ride on top: L3VPN with hundreds of VRFs, L2VPN pseudowires, EVPN over MPLS, each with its own traffic and its own QoS marking. The configuration comes from your template.

What we check

• Label distribution: LDP and RSVP-TE sessions by the hundred, time to allocate and install labels, behaviour when a session restarts
• SR-MPLS: label stacks of 3, 5 and more labels pushed by the generator, with forwarding verified per label at the egress; maximum SID depth of the DUT measured, not read off the datasheet
• Traffic engineering: explicit paths, bandwidth constraints, preemption between LSPs, and whether the packets follow the path the controller thinks they do
• Services: L3VPN with hundreds of VRFs and thousands of routes per VRF, L2VPN with MAC learning, EVPN routes of each type, each with traffic and with QoS checked at the egress
• Protection: TI-LFA, RSVP fast reroute and BGP PIC; the gap in milliseconds per flow when a link or a node fails, with the protection on and off
• Scale: the number of labels, LSPs and VRFs the box holds before something stops being installed, found by ramping up, not by reading the limit
• MTU and QoS: large frames with the full label stack, DSCP to EXP mapping, policing and shaping per LSP

What usually breaks

Label stacks. A box advertises a maximum SID depth of 10 and forwards correctly up to 5; from 6 on the packets reach the wrong next hop or get dropped by a hashing stage that does not look that deep. The SR controller is unaware and keeps computing 7-label paths.

A second case: fast reroute that is slower than the failure. TI-LFA promises 50 ms, the measured gap on the first flow is 50 ms and on the 400th VRF it is 3 seconds, because the backup path is installed per prefix and the box does it in sequence. The datasheet quotes the first flow.

The third is QoS across the label edge. EXP bits copied correctly on push, lost on a penultimate hop pop with a certain combination of features, and the voice class rides best effort through the last hop. Visible only when the service runs with real traffic and the marking is read at the egress.

What is in the report

Session and label installation times. The measured SID depth. A protection table per scenario and per service: event, flows affected, gap per flow, median and worst. Service verification per VRF and per pseudowire, with the egress marking. The scale ramp as a curve. Device configuration, emulated core, firmware and port speeds, so the vendor can repeat any line.

Where to start

Send us the device model, the firmware you plan to run and the topology it will sit in. We answer with a test plan: the items, the bench layout and the dates. The plan is free, the report is yours to keep and to show to the vendor. Write to us or look at what else the bench does.