L2 Convergence Measurement (UDP)
The L2 Convergence Measurement (UDP) plugin measures how long traffic is interrupted during network switchovers and failures: a link going down, a node reboot, an MC-LAG or ESI-LAG switchover, routing convergence. The client sends UDP flows with sequence numbers, and the server receives them and finds loss events from gaps in the sequence: when a flow stopped, when it recovered, and how many packets were lost.
Besides the convergence time, the plugin counts duplicate and reordered packets, receives and reassembles IP fragments, and in QoS-DUT mode shows the rate, loss, latency, and jitter per class of service.
Add both sides of the plugin to the task: a client entry and a server entry (see L2 Convergence Measurement (server)). In the client entry Targets, select the network of the server entry.
How the convergence time is measured
Each flow numbers its packets. The server expects the next number of the flow; when a number arrives with a gap, a loss event starts. The event starts at the reception time of the last packet before the gap and ends at the reception time of the first packet after it. The event duration is the convergence time of this flow, and the number of skipped sequence numbers is the number of lost packets.
- The measurement accuracy equals the interval between packets of one flow: 1 ms at a PPS per flow of 1000, 100 µs at 10,000. Choose a rate that makes this interval well below the expected outage.
- Flows are measured independently. If the DUT spreads traffic over paths by hashing, different flows can show different times: the dashboard summary gives the mean, minimum, and maximum time over all events, and the per-flow breakdown shows which flows were affected.
- You can trigger a failure during the task with an action, for example an interface or BGP session flap (see Actions), or perform it on the DUT manually.
Client settings
Table 182 — L2 Convergence Measurement settings
| Tab | Setting | Description |
|---|---|---|
| Sources | Agent, interface, and network | Where the flows are sent from. The interface can be an aggregate of several agent ports; see Port aggregation (LAG) |
| Targets | Network | The network of the server entry |
| IP header (L3) | TTL, DSCP, ECN | IP header fields of all flows. When QoS-DUT mode with the DSCP mark type is enabled, DSCP is set per class |
| Speed parameters | Flow count | Number of independent UDP flows, each with its own combination of IP addresses and ports. At least 1 flow |
| PPS per flow | How many packets per second each flow sends. The total client rate equals Flow count × PPS per flow | |
| Flows per second | Ramp-up rate: how many new flows start every second. 0 means all flows start sending at once | |
| Plugin parameters | Payload | Size and content of the UDP datagram: 16 to 9682 bytes, random or specified data. The frame size follows from the payload size: for IPv4 without VLAN, the frame without FCS is 42 bytes larger than the payload |
| IP fragment reassembly on the receiver | See IP fragmentation | |
| QoS-DUT mode | See QoS-DUT mode | |
| Duration | Must cover the failure and the recovery with a margin |
Duplicate and reordered packets
Failover test methodologies require reporting not only loss but also traffic duplicates during link, Leaf, Spine, and MC-LAG failures. The server compares the number of each packet with the last 64 numbers of its flow:
- Duplicate: a packet with a number already received in this flow. Causes include a loop, flooding while MAC addresses are relearned, and double delivery in ESI-LAG or MC-LAG.
- Reordered packet: a packet that arrives after the next number of the same flow. The sequence gap has already counted such a packet as lost in the event, so Total packets lost exceeds the actual loss by the number of reordered packets.
Both counters are shown in the Duplicates and packet order row of the dashboard: totals for the selected range and a per-interval chart that makes it easy to line bursts up with the failure moments. Tasks run before these counters existed show "No data".
IP fragmentation
This mode checks that a router fragments traffic between segments with different MTUs (for example, 9000 and 1500 bytes) and that the packets reach the receiver.
- Convergence datagrams have the DF flag cleared, so a DUT with a smaller egress MTU fragments them.
- A datagram larger than 1472 bytes (IPv4) leaves as one jumbo frame: the agent enables jumbo frames on the client and server ports itself. The maximum payload size is 9682 bytes, a datagram in a jumbo frame with an MTU of 9710. Every port on the path up to the fragmentation point must pass jumbo frames.
- The receiver always reassembles untagged IPv4 fragments. The IP fragment reassembly on the receiver switch also enables reassembly for frames whose VLAN tags or MPLS labels the NIC did not remove. The switch is set on the client, and the setting is passed to the server automatically.
- Loss, order, and duplicates are counted over reassembled datagrams. Fragments that were not assembled into a datagram within 2 s, did not fit into the reassembly table, or were invalid are counted as dropped; a datagram lost this way also shows up as loss in the convergence events.
The counters are shown in the IP fragmentation row of the dashboard: fragments received, datagrams reassembled, and fragments dropped. Many devices fragment packets in the CPU rather than in the hardware path, so choose a moderate rate for the fragmented flow: at a high rate the DUT may drop packets before it fragments them.
QoS-DUT mode
This mode checks how the DUT shares a link between classes of service: strict priority, weighted queues (WRR, DWRR), per-class policers. Enable it with the QoS-DUT mode switch on the Plugin parameters tab of the client entry.
| Setting | Description |
|---|---|
| Mark type | DSCP (0 to 63, in the IP header), PCP (0 to 7, in the 802.1Q tag, requires a VLAN on the source), or EXP (0 to 7, in the MPLS label, requires an MPLS tunnel) |
| Classes | Up to 8 classes. The class number is set by the row order (Class 0, Class 1, and so on) and matches the number on the dashboard. Each class has its own mark |
| Target link load, % | A reference value for the report: how much the total rate of the classes exceeds the DUT capacity. The rate itself is set by Flow count and PPS per flow |
Flows are assigned to classes round-robin: flow N goes to class N modulo the number of classes, and the class mark is written into every frame of the flow. To give the classes an equal load, set Flow count to a multiple of the number of classes. The interface warns when several classes share one mark (the DUT cannot tell them apart) or when there are fewer flows than classes (the extra classes stay empty).
DUT queues come into play only under congestion, so the total rate of the classes must exceed the DUT egress capacity: for example, limit the egress port with a shaper or send traffic to a slower port. Example: two classes of 3 Gbit/s each, marked DSCP 46 and DSCP 0, with the DUT egress limited by a 4 Gbit/s shaper. With strict priority, the DSCP 46 class passes in full (3 Gbit/s) and the other class gets the remainder (about 0.9 Gbit/s). With WRR 50/50, each class gets about 2 Gbit/s.
The server entry receives the QoS settings from the client entry; you do not need to set them on the server. Latency and jitter per class are measured only with a common clock, that is, when the client and the server run on the same agent. If they run on different agents, these charts stay empty, while rate and loss are counted as usual.
Results
The results are shown on the L2 Convergence (UDP) dashboard on the task Metrics tab.
| Row | What it shows |
|---|---|
| Summary | Number of events, mean, maximum, and minimum convergence time, total packets lost |
| Traffic | Client transmit rate and server receive rate |
| Duplicates and packet order | Duplicate and reordered packets: totals for the range and a per-interval chart |
| IP fragmentation | Fragments received, datagrams reassembled, and fragments dropped: totals and a per-interval chart |
| Per-flow breakdown | Number of events, mean convergence time, and loss per flow |
| Event details | Event table: time, agent, flow, convergence time, packets lost, loss start, and recovery |
| QoS by class | For tasks in QoS-DUT mode: the "Class summary" table (sent, received, lost, loss share, mean and maximum latency, mean jitter) and charts of transmit and receive rate, loss, latency, and jitter per class. Only classes in which the client transmitted traffic are shown |
Other metrics are described in Metrics.