Ostinato Traffic Generator for Network Engineers

MTU Sweep Test

2026-02-24T00:00:00+00:00

The Path Maximum Transmission Unit (MTU) is the largest packet size that can traverse a network path without fragmentation. If packets are larger than the path MTU, they get fragmented or dropped. This leads to performance issues and connectivity problems. Knowing the path MTU is essential when configuring MPLS tunnels, VPNs, or troubleshooting network connectivity.

To find out the MTU for a network path, you can use a sweep test. Some platform have a ping sweep command e.g. here’s Juniper’s RSVP LSP ping sweep -

ping mpls rsvp <lsp-name> sweep

If you want to do something similar in Ostinato, here’s how -

Using the GUI

Using the GUI, create a UDP stream towards the destination IP address
In the IP header, enable the Don’t Fragment (DF) configuration
Verify the stream is working by sending a few packets and ensuring that the packets are received at the destination
Now, set the frame length mode to Increment with suitable minimum and maximum frame lengths
Make sure you set the number of packets to at least frameLengthMax - frameLengthMin + 1
Change the packet rate from the default 1 packet/second to 1000 packets/second so that the transmit is faster and the test completes faster
Send all packets
On the receiver, capture the packets and note the frame length of the packets that are received

The highest frame length that is received is the MTU for the network path.

Note that the Ostinato stream’s frame length includes FCS while Wireshark’s frame length does not - so make sure to adjust for those 4 bytes!

Some tips -

If there’s a firewall in between the sender and receiver, set the UDP ports to values that are allowed by the firewall - this is why reachability verification in step 3 is important
If the highest frame length that is received is same as the maximum frame length (after adjusting for the 4-byte FCS), the MTU may be higher than the maximum frame length - so try increasing the maximum frame length and re-running the test.
Varying the frame length in the stream will lead to multiple flows being generated - if the number of flows exceeds your license limit, you may need to run the test multiple times with different min/max frame lengths

Using the Python API

Instead of sending packets for all frame lengths from minimum to maximum, you can send a single packet with the minimum and maximum frame lengths and then use a binary search to find the MTU.

This approach avoid generating multiple flows and is therefore more efficient.

You can use the GUI to first verify reachability of the stream (similar to step 3 in the GUI approach above) then use the Python API for the binary search algo with just start/stop transmit/capture commands - see Python API Easy Start for more details on how to do this.

MTU Sweep Test was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on February 24, 2026.

Why Ostinato TX uses only one core - or does it?

2026-02-10T00:00:00+00:00

I have a multi-core CPU, but Ostinato is using only one core while the rest are idle

This is a question we get asked often.

This observation is not entirely true, though.

The Ostinato TX code is single-threaded and therefore only one core is used - for one port.

If you have multiple ports and you start transmit on them in parallel, then Ostinato will use one core per transmitting port.

Why single-core TX per port?

So why does a single port TX not use more cores?

To start with, it’s historical - Ostinato was first written in 2007 and at that time multi-core CPUs were not yet commonplace.

Subsequently though, we did revisit this design and did some research to see if we can improve the performance of a single port TX using multiple cores.

Here’s what we found.

As a cross-platform tool, Ostinato uses libpcap for packet transmission. libpcap by itself is not multi-threaded. Also, the underlying OS mechanisms (different for each OS) used by libpcap are not generally designed for multi-threading.

We could still open the same port multiple times (one per thread) and transmit on them in parallel. But this would lead to contention in the kernel’s network stack and likely not improve the performance much.

Instead, we took a different approach - rather than attempting a 2x or 3x performance improvement, we did a 10x (and more!) performance improvement by using packet acceleration technology.

Turbo Transmit - the multi-core solution

Ostinato Turbo Transmit uses the in-kernel packet acceleration technology - AF_XDP built into the Linux kernel.

You may be familiar with DPDK (Data Plane Development Kit) which is a kernel bypass library for accelerating packet processing. While we did a prototype using DPDK, we productized Turbo Transmit using AF_XDP instead.

Ostinato does not use DPDK for Turbo Transmit.

AF_XDP (and DPDK for that matter) does not have the contention issue because it targets NICs (typically 10G or higher) which have multiple hardware queues. By distributing the queues across multiple cores and using a Linux driver that supports AF_XDP, we can achieve higher throughput for both Tx and Rx - without any contention.

Launched for 10G ports in 2021, Ostinato now uses the same Turbo Transmit technology to scale and support line rate on 100G and 400G ports.

You need an add-on Turbo license to use this feature. Also, this is a Linux-only feature.

You may not need the Turbo license though - the base license, which uses max-one-core-per-port code for TX, may actually be sufficient for your use case.

How to increase TX rate with single-core TX

The trick is to increase the packet size.

Like most networking devices and software, the Ostinato TX processing is primarily pps (packets per second) bound and independent of the packet size.

The larger the packet size, the higher the TX bitrate.

The default packet size for Ostinato streams is 64 bytes (the smallest possible Ethernet frame size). If packet size does not matter to you, increase the packet size to a larger size - up to the maximum possible Ethernet frame size (1518 bytes) or jumbo frames (9000 bytes). This will likely give you the higher Tx throughput you are looking for.

See The cheat-code for high throughput for more details.

Operating System Note: Please use Ostinato on Linux or MacOS for higher performance. Ostinato on Windows is not as performant due to the underlying Windows platform limitations.

Conclusion

For higher throughput, use the largest packet size possible.

If you want higher throughput for smaller packets, use the Turbo Transmit feature.

You can also review other performance related guides.

Why Ostinato TX uses only one core - or does it? was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on February 10, 2026.

Emulating multiple networks on a single port

2026-01-27T00:00:00+00:00

A few months ago, we got this question from Ide - a network engineer working on a multicast demo.

I’m running low on [Ostinato] server interfaces—I’ve used all four and only have one left. I need to simulate two receivers on different VLANs using this single interface.

Would it be possible to configure this [Ostinato] server interface as a trunk port to the switch and assign VLAN 111 (IP: 10.11.11.11) and VLAN 222 (IP: 10.12.12.12) in Ostinato? This way, I can set this port as a receiver and configure IGMP joins for two different multicast groups—for example, 239.1.1.1 on VLAN 111 and 239.2.2.2 on VLAN 222.

If this is feasible, could you guide me on how to set it up?

The answer is yes, it is possible to emulate multiple networks (identified by different VLAN IDs) on a single port using Ostinato.

Not only is it possible, it’s actually quite easy to do.

For anyone else wanting to do something similar, here’s how you can do it.

Topology

Here’s the logical test topology the user wants to emulate -

And here’s the actual physical test topology where Ostinato will emulate both the VLANs and the receivers -

Device Configuration

Configure two different devices on the same port with the required VLANs and IP addresses -

Stream Configuration

Create two IGMP streams with the above IP as source IP and the multicast group as destination.

For a step-by-step guide on setting up IGMP streams and configuring multicast data traffic, check out the resources available under IGMP.

Port Configuration

Double click the port to set Transmit mode to interleaved instead of sequential (interleaved -> all streams sent together instead of one after other)

Trunk VLAN Configuration

The Ostinato/Drone port does not require any Trunk VLAN configuration.

However, you do need to configure the Trunk VLAN on the DUT switch.

Not just IGMP

Note that this example is specific to IGMP and multicast. You can use the same technique to emulate multiple networks on a single port for other scenarios and use-cases as well.

Do reach out to us if you have any questions or need any help.

Emulating multiple networks on a single port was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on January 27, 2026.

Why Ostinato traffic is not reaching the destination

2026-01-13T00:00:00+00:00

Many first-time Ostinato users encounter the issue of traffic not reaching their destination. This is a common issue and there are a few reasons why this might happen.

This guide will walk you through the most common reasons why your traffic might not be reaching your destination and how to fix them.

Double-check the IP address in the stream configuration

This one trips up even experienced engineers!

If you use Ostinato emulated devices to simulate a source or destination device, the default IP address used is in 198.18.x.x range. This looks deceptively similar to the 192.168.x.x private IP range which most network engineers are familiar with and use in their testing. They look similar, but they are different in both the octets!

198.18.x.x != 192.168.x.x

Ensure you are using the correct IP address in the stream configuration.

Error and Warning Logs

Make sure to review the error and warning logs in the Ostinato GUI to see if there are any clues as to why your traffic might not be reaching your destination.

If you see any error or warning logs, jump to the relevant section below to troubleshoot the issue.

ERROR: Source MAC Resolve failure

By default, Ostinato streams are set to resolve the source and destination MAC addresses based on the source and destination IP address set in the stream configuration.

Specifically, the source IP (along with any VLAN tags) MUST match either the IP address assigned to the port by the OS or an emulated device IP address. Make sure this is the case. For VLAN-tagged traffic, ensure stream and device VLANs match - see generate VLAN tagged traffic for how VLANs work in Ostinato and review the KB article Source MAC Resolve Failed for troubleshooting steps.

Destination MAC resolve will be attempted only if the source MAC resolve is successful. Ensure you fix your source MAC resolve failure before moving forward.

ERROR: Destination MAC Resolve failure

Only if the source MAC resolve is successful, Ostinato will attempt to resolve the destination MAC address based on the destination IP address (along with any VLAN tags).

Ensure the destination IP address (along with any VLAN tags) matches the IP address (and expected VLAN tags) of the destination device. If you determine these are correct and match the destination device, run a packet capture on the local port to monitor ARP requests and responses.

If you don’t see any ARP requests being sent out by the local port, in the Ostinato GUI devices tab - clear the ARP cache and retry ARP resolution.

If you see ARP requests in the packet capture, but no ARP response, start a packet capture on the destination device to monitor ARP requests and responses. Verify the following -

ARP requests are reaching the destination device
The destination device is responding to the ARP requests with a valid ARP response
Contents of ARP requests and responses are valid
VLAN Tags match the expected VLAN tags

Please note that, if the destination (or source) MAC address is not resolved, Ostinato will still send the traffic stream with src/dst MAC set to 0 - which will be dropped by the next hop in the path. Therefore, ensure you fix your source and/or destination MAC resolve failure before moving forward.

Ostinato TX port statistics are not increasing

By default, Ostinato transmits 10 packets per stream and then stops. Depending on the packet rate, the TX may have finished and the current send rates may show as zero when you check them.

While troubleshooting, you might want to have a continuous stream of traffic - this can be achieved by setting the stream’s Goto to Goto First (instead of Stop) - so that the stream loops continuously.

After making and applying the change, check the TX port statistics again - the send rates should now be increasing.

Still not reaching the destination?

If you have followed all the steps above and the traffic is still not reaching the intended destination, you need to put on your network engineering hat and start troubleshooting the issue.

Here are a few things you can try and check -

Verify using stats that Ostinato generated packets are going out of the local port
Verify using packet capture on the local port that Ostinato generated packets have the correct source and destination MAC and IP addresses
Verify each node on the path that the packets are being forwarded. You can use packet capture on the node; if packet capture is not available, send a specific rate of traffic from Ostinato. At each node check the traffic rates on ingress and egress ports to check if the node is forwarding or dropping the traffic.

If you are still not able to reach your destination, you can post on the Ostinato Forum and get help from the community.

Why Ostinato traffic is not reaching the destination was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on January 13, 2026.

Streams vs Flows in Ostinato

2025-12-16T00:00:00+00:00

Some Ostinato users get confused between streams and flows.

These are fundamental concepts and it’s important to understand the difference between them.

This post will help you do that.

What is a stream?

A stream is what you - as a user - configure in Ostinato. It defines the properties of the traffic to be generated. e.g. the type of traffic, the source and destination IP addresses, the port, the protocol, the rate, the duration, etc.

You configure the various properties of the stream when creating a new stream or editing an existing stream using the stream configuration dialog.

The term stream is commonly used for a similar purpose in most traffic generators.

What is a flow?

Traditionally in networking, a flow is a sequence of packets that share the same properties. e.g. the same source and destination IP addresses, the same port, the same protocol etc.

The standard 5-tuple used in NAT e.g. is -

(source IP, source port, destination IP, destination port, protocol = TCP/UDP)

The 5-tuple is essentially a unique identifier for a sequence of packets that share the same properties. Once a flow is identified, the packets in the flow are treated as a single entity and are processed similarly.

Note that VLAN tags, MPLS labels etc. can also be part of the flow identifier. Or ICMP ID fields etc.

It really depends on the use case and application.

But at it’s core, it is about identifying a sequence of packets that share the same properties.

Ostinato flows

A flow in Ostinato is also similar - but more granular.

As a synthetic traffic generator, Ostinato classifies every unique packet as a separate flow. Any packet field that varies will generate multiple flows. A few examples will make it clearer -

This stream with incrementing destination IP address will generate 16 flows - one for each destination IP address.

This stream with incrementing VLAN ID will generate 4 flows - one for each VLAN ID.

Note that in the above examples, we assume that only one packet field is varying - the rest are kept constant.

If you have multiple packet fields varying, the number of flows will be the lowest common multiple (LCM) of the number of flows for each varying packet field.

For our above examples, if you have both the destination IP address and the VLAN ID varying, the number of flows will be LCM (16, 4) = 16.

A single Ostinato stream can generate multiple flows.

This makes it easy to generate a large number of flows from a single stream for use cases like testing NAT or NAT scale, load-balancing and load-balancing problems, or MAC learning and L2 switch testing.

This understanding of streams and flows will help you plan your testing scenarios more effectively. Do reach out to us if you have any questions or need any help.

Streams vs Flows in Ostinato was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on December 16, 2025.

Python API Easy Start

2025-11-28T00:00:00+00:00

Ostinato user Stephen asked -

If I setup on the Ostinato manager GUI the streams and emulated devices, but I would like to start, stop, and log a test with the Python API is that possible?

So, basically I would use the manager GUI to define my test parameters (streams, emulated devices, etc.), but use the Python API to help automate the test and logging.

Yes, that is an easy way to get started with the Python API without having to figure out the full stream and protocol configuration API details.

Here are some more details on this approach.

Save the Ostinato GUI configuration as a session file.

Write a simple Python script using the following Ostinato Python APIs -

startTransmit()
stopTransmit()
getStats()
getStreamStatsDict()

Here’s an example - using the above mentioned Ostinato Python APIs to start/stop transmit and log the stats.

from ostinato.core import DroneProxy, ost_pb

import time

# Get ...
drone = DroneProxy('localhost')

# ... set ...
tx_port = ost_pb.PortIdList()
tx_port.port_id.add().id = 1;

rx_port = ost_pb.PortIdList()
rx_port.port_id.add().id = 2;

all_ports = ost_pb.PortIdList()
all_ports.port_id.extend(tx_port.port_id)
all_ports.port_id.extend(rx_port.port_id)

guids = ost_pb.StreamGuidList()
guids.port_id_list.extend(all_ports)

tx_config = ost_pb.TransmitConfig()
tx_config.port_id_list.extend(tx_port.port_id)

# ... GO!
drone.clearStats(all_ports)

drone.startTransmit(tx_config)
time.sleep(30)
drone.stopTransmit(tx_port)

stats = drone.getStats(all_ports)
stream_stats = drone.getStreamStatsDict(guids)

print(stats)
print(stream_stats)

This script assumes that the Drone has already been configured using the Ostinato GUI.

If you are using v2.0 or higher, instead of sleep, you can set tx_config.tx_duration and waitForTransmitFinish -

tx_config = ost_pb.TransmitConfig()
tx_config.port_id_list.extend(tx_port.port_id)
tx_config.tx_duration = 30 # seconds
...
drone.startTransmit(tx_config)
waitForTransmitFinish(tx_port)

Note that the Ostinato session file CANNOT be loaded via the Python API. It can only be loaded in the GUI.

Also, the session file is not portable across setups if the drone hostname/IP is different and/or the port names are different.

This is a quick and easy way to get started with the Ostinato Python API.

Full scripting - easy start

If you want full automation, without having to use the GUI to configure the Drone, but also want to avoid writing a python script from scratch, here’s a modified approach.

Use the GUI to configure everything. Then go to Ports > Save Port Configuration and select the output format as Python script. You can then modify the script to add your own logic to automate the test.

You will need to save a python script for each Tx/Rx test port and then modify/combine them to build an automated test suite.

Python API Easy Start was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on November 28, 2025.

Error: Source mac resolve failed for one or more streams

2025-11-13T00:00:00+00:00

Source mac resolve failed for one or more streams - Device matching stream’s source IP not found

New Ostinato users who encounter this error often get confused.

This kb/src-mac-resolve-failed article will explain what it means and how to fix it.

Root cause

When you create a new Ostinato stream, by default the source and destination Mac addresses are set to Resolve

This configuration setting tells Ostinato to auto populate the source and destination MAC addresses in the packet based on the source and destination IP addresses configured in the traffic stream.

How does Ostinato do that?

It uses the stream’s source IP address to find the source device. To do that, it will look up the list of devices configured on the same port and find a device with the same source IP address as configured in the stream.

Once it knows the source device (which can be the physical port itself or an emulated device), it will use the source device’s MAC address to populate the source MAC address in the packet.

If a source device is not found, Ostinato is not able to resolve the source MAC address and will display this error.

Note that without first identifying a source device for the stream, Ostinato cannot do a destination MAC address resolution using ARP/NDP either since it needs to know the gateway IP address to do that.

How to fix it?

Follow these steps to troubleshoot and fix the issue -

Note the source IP address configured in the stream
Go to the Devices > Information tab and look for a device with the same source IP address
If you find a device, carefully check if the source IP is exactly the same as the one configured in the stream
If you don’t find a device, create an emulated device with this source IP address
Apply the changes and verify the error is not seen now

TIP: If you have multiple streams with different source IP addresses, you can disable all streams and enable them one by one, click Apply button after each enable to see which stream is causing the issue.

VLAN tagged traffic

For VLAN tagged traffic, the VLAN ID in the stream MUST match the VLAN ID in the device configuration. In other words, the device must also be configured with the same VLAN ID(s).

For Q-in-Q or multiple VLAN tags, ALL the VLAN IDs in the stream must match the number, order and values of the VLAN IDs in the device configuration - including the TPIDs.

For how to configure VLAN tagged streams and devices in Ostinato, see generate VLAN tagged traffic.

Example

Here’s an example showing a stream with a source IP address that matches a device configured -

Note that the source IP address in the stream is exactly the same as the device IP address configured.

Here’s another example with Q-in-Q VLAN tagged traffic -

Note that apart from the same source IP address, the VLAN IDs in the stream is exactly the same as the VLAN IDs in the device configuration - in number, order, values and TPIDs.

Common pitfall

When creating devices with IPv4, Ostinato uses the IP address 198.18.x.y by default - this is a reserved range of IP addresses for benchmarking and testing purposes.

192.168.x.y is a reserved range of IP addresses for local network use.

Both these IP address can look similar at first glance and may trigger this error if you used the default IP address in the device configuration and set the stream source IP address to 192.168.x.y!

Error: Source mac resolve failed for one or more streams was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on November 13, 2025.

How to create SRv6 traffic using Ostinato

2025-10-23T00:00:00+00:00

Segment Routing over IPv6 (SRv6) enables source routing by encoding path information directly in IPv6 packet headers. It uses the Segment Routing Header (SRH) - IPv6 extension header to carry a list of segments (identified by a segment-id SID) that define the network path. Each segment represents a network instruction, allowing precise control over packet forwarding through the network.

We’ll not go into more details about SRv6 here - if you are here you likely already know what it is and how it works.

What you want to know is how to create SRv6 traffic.

Ostinato doesn’t support SRv6 natively, but we can use a Ostinato protocol script to create the SRH.

Let’s start with the SRv6 packet structure.

SRv6 Packet Structure

A SRv6 packet is a IPv6 packet with a SRv6 header (SRH) following the IPv6 header.

+----------+------+-----+--------//-------+
| Ethernet | IPv6 | SRH |     Payload     |
+----------+------+-----+--------//-------+

The SRH structure is specified in RFC8754 as follows -

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Next Header   |  Hdr Ext Len  | Routing Type  | Segments Left |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Last Entry   |     Flags     |              Tag              |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |            Segment List[0] (128-bit IPv6 address)             |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                                                               |
 |                             ...
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |            Segment List[n] (128-bit IPv6 address)             |
 |                                                               |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 //                                                             //
 //         Optional Type Length Value objects (variable)       //
 //                                                             //
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To create a SRv6 packet in Ostinato, follow these steps -

Create a new stream and select the protocols Mac | EthII | IPv6 | UDP | Payload
Go to Advanced mode of selecting protocols and insert Userscript in between IPv6 and UDP
Configure other protocol fields (e.g. IPv6 src/dest) and stream fields (e.g. frame size)

SRv6 Protocol Script

Go to Protocol Data tab and enter the below script in the UserScript header.

const sids = [
    0x0001020304050607, 0x08090a0b0c0d0e1f,
    0x0001020304050607, 0x08090a0b0c0d0e2f,
    0x0001020304050607, 0x08090a0b0c0d0e4f,
    0x0001020304050607, 0x08090a0b0c0d0e4f,
    0x0001020304050607, 0x08090a0b0c0d0e5f
 ];

protocol.name = "SRv6 SRH"

protocol.protocolFrameSize = function() { return 8 + sids.length*8; }

protocol.protocolId = function(id_type)
{
    if (id_type == Protocol.ProtocolIdIp)
        return 43;
    return 0;
}

protocol.protocolFrameValue = function(index)
{
    var segmentsLeft = sids.length/2-1;
    var tag = 0xabcd;

    var pfv = new Array(protocol.protocolFrameSize());

    // next header (8)
    pfv[0] = protocol.payloadProtocolId(Protocol.ProtocolIdIp);

    // hdr ext len (8)
    pfv[1] = sids.length; // 2 quad-words per SID

    // routing type (8)
    pfv[2] = 4;

    // segments left (8)
    pfv[3] = segmentsLeft;

    // last entry (8)
    pfv[4] = sids.length/2-1;

    // flags (8)
    pfv[5] = 0;

    // Tag (16)
    pfv[6] = (tag >>  8) & 0xFF;
    pfv[7] = (tag >>  0) & 0xFF;

    return pfv;
}

Change the sids array to the list of SRv6 segments you want to use.

Each element in the sids array is a 128-bit IPv6 address
The tag is a 16-bit value that is used to identify the SRv6 packet

⚜️ If you want to understand what the script does, see the Ostinato User-Script documentation.

Apply the stream changes and start transmitting the SRv6 packets.

SRv6 Packet Verification

To verify the SRv6 packets, start a packet capture and view them in Wireshark.

You should see the SRv6 packets with the SRH and the segments.

Something not as expected? Reach out to us.

How to create SRv6 traffic using Ostinato was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on October 23, 2025.

Labbing with Ostinato - Minus the VNC pain

2025-09-09T00:00:00+00:00

Ostinato’s primary mode of configuration and monitoring is through the GUI.

When using Ostinato for labbing (irrespective of the labbing platform - GNS3, EVE-NG, CML, Containerlab, etc.), the GUI is displayed via VNC.

While usable, the VNC experience can sometimes feel a bit - wanting.

But you are not stuck with just VNC - there’s another option.

You can use Ostinato for Windows/MacOS GUI on your laptop and connect to the Ostinato node in the lab over the management network – thanks to the Ostinato controller-agent architecture.

🛒 You may need to purchase a separate license for Ostinato on Windows or MacOS

This guide will show you how to use the Ostinato GUI on Windows/MacOS to configure, control and monitor the Ostinato nodes in your virtual lab.

TLDR - Connect the Ostinato node in your virtual lab to the external/mgmt network and then use Ostinato GUI on your Windows/MacOS laptop to access it.

Here are detailed steps.

Step 1 - Connect the Ostinato node to the host network

Here are instructions to do so for all the supported labbing platforms.

CML

Add the External Connector node to the lab
Configure the just added ext-conn-0 node to use bridge mode (not NAT mode)
Add a link betweeen the ext-conn-0 node and the Ostinato node
Make sure to select the eth0/mgmt interface on the Ostinato node for the link

Start the lab, open the Ostinato console and run ifconfig eth0 to verify that the Ostinato node is assigned a DHCP IP address.

EVE-NG

Add a new Network to the lab of type Management(Cloud0)
Add a link betweeen the network node and the Ostinato node
Make sure to select the eth0/mgmt interface on the Ostinato node for the link

Start the lab, open the Ostinato console and run ifconfig eth0 to verify that the Ostinato node is assigned a DHCP IP address.

GNS3

Add a new NAT node to the lab
Add a link betweeen the NAT node and the Ostinato node
Make sure to select the eth0/mgmt interface on the Ostinato node for the link

Start the lab, connect to the Ostinato VNC, open a terminal and run ifconfig eth0 to verify that the Ostinato node is assigned a DHCP IP address.

Containerlab

Edit your clab.yml file to add the below port mappings for the Ostinato node.

. . .
topology:
  nodes:
    ost:
      kind: linux
      image: ostinato/ostinato:{tag}
      ports:
        - 5900:5900/tcp
        - 7878:7878/tcp
      binds:
        - .:/root/shared
. . .

Deploy the lab with the usual clab deploy
Use VNC to connect to the Ostinato node using the <host-ip>:5900 address – even if you plan to connect to the Ostinato node over the management network using a Windows/MacOS native GUI, you need to first connect via VNC – this is due to the way Ostinato integration for containerlab is implemented

📛 To connect to the Containerlab Ostinato node from the GUI, use the Host’s IP address in the next step - this is because we have mapped the container’s ports to the host ports

During lab deployment, if you see an error like bind: address already in use - it means that the port 7878 is already in use. Maybe a native instance of Drone is running on the host or some other application on the host is using port 7878. You can change the port mapping to a different port e.g. 8878:7878 and redeploy the lab. With this mapping, you should use port 8878 when connecting from the GUI.

Step 2 - Connect from GUI to the Ostinato node

Run a ping from your laptop to the Ostinato node to verify that the connection is working.

🔁 If ping is not working - troubleshoot this connectivity before proceeding

Once you verify connectivity, use File | New PortGroup from the Ostinato GUI running on your laptop and enter the IP address of the Ostinato node. You should see the Ostinato node in the Ostinato port list. The ports listed under the port group are the ports on the Ostinato node in your lab.

You can now use the Ostinato GUI on your laptop to configure, control and monitor the Ostinato node.

🔥 If ping is working, but Ostinato GUI is not able to connect to the Ostinato node - check if the firewall is blocking TCP port 7878. If required, add a rule to allow traffic on this port.

Labbing with Ostinato - Minus the VNC pain was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on September 09, 2025.

How to cheat and get more traffic tester ports

2025-08-19T00:00:00+00:00

Traffic generators and testers are great tools for testing network functionality and performance.

But they are expensive – some prohibitively so!

Network Testers and QA engineers have always found workarounds and solutions to get more bang for their buck and work with limited resources.

One such ingenious solution is the Snake Test Topology to use just two traffic generator ports to test ALL 32 (or 48 or 96) ports of a switch at line rate.

This post explains another oldie but goodie solution to get more traffic generator and tester ports - using a switch as a port multiplexer to fan-out the traffic generator ports.

The concept is simple - send VLAN-tagged traffic from a single traffic generator port to a switch trunk port; the switch demultiplexes the traffic based on the VLAN tag (1 VLAN tag = 1 switch port) and sends it out of the corresponding access port after stripping the VLAN tag. The switch ports are connected to the various devices under test.

Here’s an example test topology using only 2 traffic generator ports to test a DSLAM AND 48 CPE devices - from back in the day.

This example can be easily extended to a PON or other FTTH deployment, even wireless APs and wifi routers! The concept remains just as applicable.

Using a switch to multiplex and demultiplex test traffic is an effective way to get more traffic generator and tester ports without having to buy more hardware.

Limitations

Like every workaround, this approach has its limitations though.

Results

Packet drops within the switch may affect the results
The single traffic generator port may not be able to break down the incoming aggregate traffic into individual VLANs to account for individual port stats
You may need to fetch statistics from the switch ports
Traffic passing through a switch introduces additional latency and potential jitter compared to direct connections
You may not be able to get latency/jitter stats for individual ports - you may only get aggregate stats for the switch trunk port

Complexity

While VLAN configuration on the switch is simple, it is still additional configuration compared to direct port connections
Configuring multiple VLAN-tagged streams on a single traffic generator port makes it harder to manage and correlate which stream targets which port compared to using individual tester ports
The switch must be performant enough to handle the aggregate traffic from all access VLAN ports and the trunk port in both directions
Port related operations such as link state up/down, speed and duplex, etc. need to be done on the switch ports and not the traffic generator port - the traffic generator will be unaware of these changes
Existing scripting/automation frameworks may need to be modified to support this approach

Debugging

Troubleshooting becomes more complex when traffic is multiplexed through VLANs, making it harder to isolate issues
Correlating the traffic streams to the switch access ports is more complex than using individual tester ports

Conclusion

The port fan-out using a switch is a good workaround to get more test ports - but it is not without its limitations.

One way to remove the limitations is to use affordable and cost-effective software traffic testers like Ostinato on COTS hardware with real full-featured traffic tester ports rather than having to work with an external switch and switch ports.

Finally, we would be remiss if we didn’t mention that although Ostinato is much more economical than the competition, it may still be too expensive for someone. If so, you can use this same approach to fan-out Ostinato traffic generator ports!

How to cheat and get more traffic tester ports was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on August 19, 2025.

How to persist Ostinato config in Containerlab

2025-08-05T00:00:00+00:00

When using Ostinato for Containerlab, you might want to save and restore your Ostinato session across lab restarts.

This guide is specific for Containerlab. See the guide for GNS3 EVE-NG or CML if you are using those platforms.

As we know containers are ephemeral by design. When you destroy a container, all its data is lost.

Unless, you mount a host directory as a volume to the container!

Here’s what you need to do in 4 easy steps.

Step 1 - Edit clab.yml file

Edit the Ostinato node section in your clab.yml file to add a volume mount (called bind in containerlab).

. . .
topology:
  nodes:
    ost:
      kind: linux
      image: ostinato/ostinato:{tag}
      ports:
        - 5900:5900/tcp
        - 7878:7878/tcp
      binds:
        - .:/root/shared
. . .

The above bind configuration mounts the host current directory . as a volume to the container. Inside the container it can be accessed at /root/shared.

Run (or restart) the lab with the usual clab (re)deploy command.

Step 2 - Configure Ostinato and save session file

Configure Ostinato using the GUI as usual.

Then use File | Save Session to save the Ostinato session configuration to a file. Make sure you save it in the /root/shared directory.

If you make further changes to the Ostinato session, you can save it again to the same file.

Step 3 - Destroy lab and verify session file is saved

When you destroy the lab, the session file will remain saved on the host’s current directory - you can run ls to verify.

Step 4 - Run lab again and restore session

Next time you run the lab, use File | Open Session from the Ostinato GUI to open the session file from the same /root/shared directory.

All the Ostinato configuration will be restored.

That’s all there is to it!

You can now destroy and re-deploy your lab as many times as you want without losing your Ostinato session - just remember to save the session file in the /root/shared directory.

A future Ostinato version will auto save the session configuration file so that you don’t have to remember to do it.

How to persist Ostinato config in Containerlab was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on August 05, 2025.

One node to test them all

2025-07-22T00:00:00+00:00

When creating lab topologies with multiple devices (nodes), we often see Ostinato users use multiple Ostinato nodes in the topology. Here’s an example DMVPN topology with multiple Ostinato nodes.

For a traffic generator like Ostinato, this is not necessary. Not just unnecessary, it’s inconvenient.

This guides will explain what to do instead.

Single Ostinato node

One ring to rule them all (Lord of the Rings, JRR Tolkien)

Just like the iconic one ring, you can use a single Ostinato node to test multiple devices in a lab topology (unlike the one ring, the Ostinato node is not evil!).

How to use a single Ostinato node?

Use multiple ports on a single Ostinato node and connect each Ostinato test port to other devices in the topology.

The same topology above can be created with a single Ostinato node with 3 ports as shown below.

Advantages

The advantages of this approach is that you can use one single Ostinato GUI for your lab to do all the following -

Configure all test ports with test devices and streams
Control (start/stop transmit and capture) on one or more test ports as required
Monitor the real-time traffic statistics and pkt/bit rates on all test ports
Use stream statistics to analyze packet drops, latency, jitter, etc.
Save and load the configuration of the node and all its ports as a single Ostinato session file

No more switching between multiple GUIs - one for each Ostinato node! Phew!

Here’s a screenshot of the single Ostinato node GUI with multiple ports for this same topology.

To set helpful names like Hub, Spoke A, Spoke B to each port, edit the port description to make it more meaningful and relevant to your lab and topology.

This makes it easier to identify the port and the test device it is connected to.

Using a single Ostinato node (with multiple ports) makes it easier to manage your lab and test traffic.

Topology Diagram

One downside of using a single Ostinato node with multiple ports is that the topology diagram may become a bit messy and cluttered.

Depending on what your labbing platform allows, you can do one or more of the following to make the diagram more readable -

You can draw the Ostinato links so that it does not cross other nodes/links
You can hide the Ostinato links in the diagram
You can add multiple dummy nodes (shapes) to the topology to represent the endpoint nodes being emulated by the single Ostinato node

Multiple Ostinato nodes

Note that, you can still use multiple Ostinato nodes - if you want to. e.g. if you don’t have enough test ports on the single node.

You can make managing multiple nodes easier by using a single Ostinato GUI externally and connecting to the Ostinato nodes over the management network.

This is better than multiple Ostinato GUIs and switching between them, but has limitations compared to a single Ostinato node e.g. you can’t do stream stats accounting between ports on different Ostinato nodes.

How does a single node with multiple ports work?

If you are used to using multiple VPC (virtual PC) nodes or Linux nodes to act as hosts or iperf end-points to create lab topologies, you might be wondering how can a single Ostinato node with multiple ports with IP addresses on the same or different subnets work?

The reason is that Ostinato does not use the OS networking stack. The IP addresses assigned using device emulation are not visible to the OS networking stack. Ostinato crafts packets and sends them out directly on the network interface bypassing the OS networking stack. This makes Ostinato test traffic independent of the OS, network stack and IP addresses assigned to the interfaces by the OS.

This also makes Ostinato test ports independent of each other.

You might find this comparison of iperf vs Ostinato architecture interesting reading.

Do you have any suggestions to improve your Ostinato labbing experience? Let us know!

One node to test them all was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on July 22, 2025.

Generate VLAN tagged traffic

2025-07-15T00:00:00+00:00

VLANs are quite fundamental in most networks today and a great solution for traffic isolation - e.g. to carry different types of traffic (web, VoIP etc.) on the same physical LAN infrastructure or isolate and identify tenants in multi-tenant WAN networks.

VLAN tagged

To craft and transmit VLAN tagged packets in Ostinato is easy.

Just create a stream and when selecting protocols, set VLAN to Tagged.

Next, in the Protocol Data tab, set the VLAN Id and optionally other fields like priority and CFI/DEI.

That’s it!

Dual VLAN aka QinQ

For double tagged VLAN packets, just select Stacked instead of Tagged in the VLAN selection and configure both VLANs under Protocol Data.

If you want to use a different TPID for SVLAN, you can do that as well -

More VLAN Tags

Want more than 2 VLAN tags in the packet? We’ve got you covered!

Switch to Protocol Selection | Advanced and insert multiple VLAN headers in the protocol stack between MAC and Eth II.

You can configure values for all the VLAN tags as usual in the Protocol Data tab.

VLAN tagged streams with Device Emulation

If you are using emulated devices and VLAN tagged streams, ensure that the VLANs in the streams MUST match the VLANs used by the devices

Without the above matching, Ostinato will not be able to identify the source device for a stream and hence Source/Destination Mac resolution will fail (you can still use fixed mac addresses in your stream).

See Source MAC resolve failed and traffic not reaching destination for troubleshooting.

See Matching Streams with Devices to understand how streams are matched with devices.

Multiple VLANs

If you want to generate VLAN tagged packets with varying VLAN values, you can use the Variable Fields tab to generate VLAN IDs in incrementing, decrementing or random sequences.

💡 If you are generating incrementing/decrementing VLAN values, make sure you have the same varying sequence in the device group configuration too - applicable only if using device emulation. A random sequence of VLANs will not work with device emulation - for obvious reasons.

If something is not clear or if there is something more you want to do with VLANs, let us know!

Generate VLAN tagged traffic was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on July 15, 2025.

Testing IMIX traffic with Ostinato

2025-06-27T00:00:00+00:00

What is IMIX traffic?

IMIX (Internet Mix) is a standardized traffic pattern that simulates real-world internet traffic in a test environment. It consists of packets of different sizes mixed in specific proportions to represent typical internet traffic.

The concept emerged from studying actual internet traffic patterns and creating a simplified model that could be used for testing network devices and applications.

Why is IMIX traffic important?

Network testing with fixed-size packets doesn’t reflect real-world conditions. Here’s why IMIX matters:

Real-world simulation: Internet traffic consists of various packet sizes - from small TCP ACKs to large data transfers
Better performance metrics: Testing with IMIX provides more accurate throughput and latency measurements
Device stress testing: Different packet sizes stress different components of network devices. See how packet size affects throughput
Network planning: IMIX helps in capacity planning and network design decisions

You can use IMIX when running bandwidth tests with Ostinato to simulate real-world traffic across a circuit.

IMIX traffic profiles

While IMIX is widely used in the networking industry, it’s important to note that it’s a de-facto standard, not a de-jure one. This means it evolved through common usage rather than formal standardization.

Standard IMIX

The most common IMIX profile uses a 7:4:1 packet ratio. In Ostinato, we use -

Packet Size	No of Packets	Percentage
64	7	58.33%
594	4	33.33%
1518	1	8.33%

While this packet ratio (7:4:1) is commonly used across the industry, there can be variations in the packet sizes and load distribution among different vendors.

These variations in packet sizes don’t significantly impact test results as long as you

Document which profile you’re using
Use the same profile consistently across your tests
Account for the differences when comparing results across different tools

You can create your own profile also if that better suits your needs.

IMIX Genome

The IMIX genome concept, introduced in RFC 6985, provides a standardized way to specify the exact repeating sequence of packet sizes in a test. The genome notation uses letters to represent standard packet sizes.

Size (Bytes)	Genome Code Letter
64	a
128	b
256	c
512	d
1024	e
1280	f
1518	g
2112	h
9000	i
16000	j
MTU	z

For example, a sequence of three 64-byte packets followed by two 1280-byte packets and one 1518-byte packet would be written as

IMIX - aaaffg

This notation ensures test conditions can be precisely documented and reproduced.

Generating IMIX with Ostinato

Generating standard IMIX

Ostinato makes it incredibly easy to generate standard IMIX traffic

Create a new stream
In the Frame Length section, simply select IMIX from the dropdown
Under Stream Control section, set the stream to Goto first
Configure other stream parameters as needed
Start transmission

Generating other IMIX profiles

For custom IMIX profiles, follow these steps

Set the port Transmit Mode to Interleaved
Create a stream for the first packet size
Set the appropriate frame length for the stream
Configure packet rate to the number of packets of that size per second
Configure other stream parameters as needed
Duplicate the stream for other packet sizes in the profile
Edit the duplicated streams to change the frame length and packet rate appropriately

After configuring all the streams, you will notice that the port’s aggregate packet rate is the sum of all the stream packet rates - which would be very low.

You can change it to the desired rate by changing the port’s aggregate packet rate - the packet ratio for the streams will still be maintained. Do not change the individual stream packet rates - only the port’s aggregate packet rate!

For IMIX - aaaffg, here’s the stream configuration that you should configure -

Stream	Frame Length	Packet Rate
1	64	3 packets/sec
2	1280	2 packets/sec
3	1518	1 packets/sec

After configuring the streams to the above mentioned values, the port’s aggregate packet rate will display 6.000 pps (3+2+1). You can change it to any other value – the packet ratio for the streams will still be maintained. Do not change the individual stream packet rates - only the port’s aggregate packet rate!

How to verify IMIX?

To verify your IMIX traffic pattern:

Capture traffic using Wireshark or similar tools
Use Wireshark Statistics > Packet Lengths
Compare the distribution with your intended IMIX profile
Look for any anomalies in the distribution

Notice that the packet lengths shown in Wireshark statistics are for ranges of packet sizes and not the exact packet sizes.

If you need to verify the exact packet sizes, you can use the following bash script - the script usestshark and bc.

Also, packet captures by Wireshark and other tools typically don’t include the 4-byte FCS (Frame Check Sequence) in the packet length. So the script adjusts the packet length by subtracting 4 from the packet length.

#!/bin/bash
# Usage: ./imix_count.sh capture.pcap
# Bash script to count packets by size (adjusted for FCS) and compute percentages

if [[ $# -ne 1 ]]; then
    echo "Usage: $0 <pcap_file>"
    exit 1
fi

# Uncomment to debug
#set -x

PCAP_FILE="$1"

SIZES=(64 594 1518)
declare -A COUNTS

TOTAL=0
TSHARK=tshark

# First pass: count packets per size (adjusted for FCS)
for SIZE in "${SIZES[@]}"; do
    ADJ_SIZE=$((SIZE - 4)) # Adjust for FCS
    COUNT=$($TSHARK -r "$PCAP_FILE" -Y "frame.len == $ADJ_SIZE" | wc -l)
    COUNTS[$SIZE]=$COUNT
    TOTAL=$((TOTAL + COUNT))
done

echo ""

if [[ $TOTAL -eq 0 ]]; then
    echo "No matching packets found."
    exit 0
fi

# Output: count and percentage on same line
printf "%8s %10s %8s\n" "Size(B)" "Count" "Percentage"
echo "------------------------------------"

for SIZE in "${SIZES[@]}"; do
    COUNT=${COUNTS[$SIZE]}
    PCT=$(echo "scale=2; 100 * $COUNT / $TOTAL" | bc)
    printf "%8s %10s %8s%%\n" "$SIZE" "$COUNT" "$PCT"
done

Change the SIZES array to the packet sizes you want to verify.

Here’s a sample output -

$ ./imix-count.sh imix-capture.pcap
 Size(B)      Count Percentage
------------------------------------
      64       6923    58.33%
     594       3956    33.33%
    1518        989     8.33%

Remember to capture a significant number of packets to get statistically meaningful results!

Testing IMIX traffic with Ostinato was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on June 27, 2025.

Test slow traffic rates to avoid big problems

2025-06-10T00:00:00+00:00

When testing network devices, we focus on the high speed traffic rates (10Gps or more) for performance and QOS testing and low speed traffic rates like 100 or 1000 packets per second (pps) for functional testing.

What’s often overlooked is testing with extremely slow rates. Rates at which protocol keep-alives time out leading to an uintended state machine transition (think BGP marking a peer as down due to lack of timely keepalives). Multi-player online games often require a minimum traffic rate to maintain state in the server. ARP aging may cause traffic drops. Mac aging may cause L2 floods. Policers and shapers may perform incorrectly at low rates due to the nature of their algo. DHCP request timeouts may cause the device going offline.

You get the idea.

But it’s not just about negative testing.

There’s a whole class of IEEE 802.3 slow protocols designed to operate at a fixed, slow rate of 1 packet every 30 seconds or so. Some examples of these protocols are -

Protocol	Description	Typical Traffic Rate
Link Aggregation Control Protocol (LACP)	Used to automatically negotiate and manage link aggregation (port channels)	1 packet/sec (fast mode) 1 packet/30 sec (normal mode)
Link Layer Discovery Protocol (LLDP)	Helps network devices discover and advertise their capabilities to neighbors	1 packet/30 sec
Operation, Administration, and Maintenance (OAM)	Provides link monitoring and remote fault indication	1 packet/sec
Port Authentication (802.1X)	Handles port-based network access control	1 packet/30 sec during authentication 1 packet/60 sec for keep-alive

These protocols are deliberately designed to operate at slow rates to minimize their impact on network bandwidth while still maintaining critical network functions.

Testing Slow Protocols with Ostinato

Apart from generating high speed traffic (100Gbps or even faster!), Ostinato can generate traffic at very low rates too. This is useful for scenarios like -

Testing slow protocol implementations
Verifying protocol state machines at boundary conditions
Validating timeout behavior
Stress testing protocol handlers

To configure Ostinato to generate slow traffic rates, you need to set the paccket rate (packets/sec) to a decimal value < 1.

To calculate slow traffic rates, use the below formula -

Packet Rate = 1 / (Time between packets in seconds)

Here are some examples -

Rate	Calculation
1 packet/sec	1 / 1 = 1
1 packet every 30 sec	1 / 30 = 0.0333
1 packet every 60 sec	1 / 60 = 0.0167
1 packet every 5 minutes	1 / (5 * 60) = 0.0033
1 packet every hour	1 / (60 * 60) = 0.000278

Best Practices for Slow Rate Testing

Duration Matters: Run tests long enough to observe timeout behaviors (hours or days)
Background Traffic: Consider mixing slow protocol traffic with regular traffic
Resource Monitoring: Watch for memory leaks that only appear with long-running sessions

Test slow traffic rates to avoid big problems was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on June 10, 2025.

Extending Ostinato with Linux Virtual Interfaces

2025-05-21T00:00:00+00:00

Introduction

Linux has a unique way of implementing some network protocols, especially tunneling protocols, as virtual network interfaces. This approach provides a unified way to configure and test various protocols using standard Linux networking tools.

In this post, we’ll explore this concept and show how to use these interfaces with Ostinato to test various protocols that are not natively supported by Ostinato.

Understanding Linux Virtual Network Interfaces

In Linux, many network protocols are implemented as virtual network interfaces rather than just protocol stacks. This means protocols like MACsec, IPsec, VXLAN, and others appear as regular network interfaces in the system. You can configure them using the standard ip command with protocol specific parameters.

This approach offers several advantages for network testing.

Protocols appear as standard Linux network interfaces
Use existing Linux networking commands
Easy integration with other networking features
Test protocols in a more realistic environment

Here are some of the protocols implemented as virtual interfaces in the Linux kernel (Run man ip-link and look for the allowed values for the type param to see the full list) -

Tunneling Protocols
- IPIP - IP-in-IP tunneling
- SIT - IPv6-in-IPv4 tunneling
- GRE - Generic Routing Encapsulation
- VXLAN - Virtual Extensible LAN
- GTP - GPRS Tunneling Protocol
- Geneve - Generic Network Virtualization Encapsulation
Security Protocols
- MACsec (802.1AE) - MAC-layer security
Container/Virtualization Networking
- IPVLAN - Lightweight L2 container networking
- MACVLAN - Multiple MAC addresses on single interface
- VETH - Virtual Ethernet pairs
- TAP/TUN - Virtual network devices
Industrial Protocols
- HSR/PRP - High-availability Seamless Redundancy/Parallel Redundancy Protocol
Bridging and Aggregation
- Bridge - Network bridging
- Bonding - Link aggregation
- VLAN - Virtual LAN interface
Special Purpose
- Dummy - Dummy network interface

Since these are virtual interfaces, they are typically ‘stacked’ on top of a physical interface. For example, a MACsec interface is typically stacked on top of a physical interface like eth0.

Depending on the protocol, the virtual interface may either be an ethernet interface (e.g. macsec) or an IP interface (e.g. GTP).

The tunneling and security protocols also typically have a similar peer. The peer would be stacked similarly if it is running Linux or can be a vendor device with their own proprietary protocol stack.

How to use Virtual Network Interfaces with Ostinato

Since the virtual interfaces are standard Linux interfaces, Ostinato will list them in its port list. Both the virtual interface and the physical interface would appear in Ostinato’s port list.

You MUST configure traffic streams on the virtual interface (NOT the physical interface).

If the virtual interface is an ethernet interface, you can create standard ethernet streams.

However, if the virtual interface is an IP interface, you can create a standard Ethernet/IP stream and then using the Advanced Protocol Selection mode, remove the Ethernet header so that the packet starts directly from the IP header.

What about the protocol headers?

The Linux virtual interface will take care of adding the protocol specific headers for you. That’s why you just need to configure an Ethernet or IP stream on the virtual interface.

That’s the beauty of this approach - you can use the same topology and approach for all these protocols that are implemented as Linux Virtual Network Interfaces.

Example: Using MACsec Interface with Ostinato

Let’s look at a practical example using MACsec.

Create MACsec Interface

ip link add link eth0 macsec0 type macsec

ip link set macsec0 up

Configure MACsec Parameters

ip macsec add macsec0 tx sa 0 pn 1 on key 01 0123456789abcdef0123456789abcdef

ip macsec add macsec0 rx address <peer-mac-address> port 1 sa 0 pn 1 on key 01 0123456789abcdef0123456789abcdef

Configure Ostinato Stream
- Select the macsec0 interface in the Ostinato GUI
- Create a standard Ethernet stream - don’t worry about macsec header, the macsec interface will add it
- Set up rest of the stream protocols and rates as needed
Create and configure the peer If the DUT is the macsec peer, you can proceed to running the test. However, if the DUT is a middle box, you must create a similar MACsec interface on the peer side.
Run Test
- Start traffic generation
- Monitor interface statistics
- Verify MACsec encryption/decryption
- Check for any errors

Extending to Other Protocols

The same topology and approach can be used for other protocols implemented as virtual interfaces. Here are some key considerations:

Protocol-specific Requirements
- Some protocols may require specific kernel modules
- Each protocol has specific configuration parameters (check the man page for ip link)
- Each protocol has their own specific headers
Common Testing Parameters
- Frame size/MTU
- Traffic rate
- Protocol-specific fields
- Error conditions
Monitoring and Validation
- Interface statistics
- Protocol-specific counters
- Error rates
- Performance metrics

Open-source projects

Beyond the Linux kernel, there are also many open source projects that implement other protocols and applications as virtual interfaces. Some examples are -

StrongSWAN - IPsec
UERANSIM - 5G RAN
srsRAN - 4G/5G RAN
Wireguard - VPN
and others

These could also be used along with Ostinato with a similar approach.

Extending Ostinato with Linux Virtual Interfaces was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on May 21, 2025.

Testing DMVPN with Ostinato

2025-05-13T00:00:00+00:00

What is DMVPN?

DMVPN (Dynamic Multipoint VPN) is a Cisco-developed solution that creates a secure, scalable overlay network. It combines the benefits of IPSec VPN and mGRE (Multipoint Generic Routing Encapsulation) tunnels.

DMVPN solves several challenges in traditional VPN deployments:

Dynamic tunnel establishment: Tunnels are created on-demand between sites
Spoke-to-spoke communication: Direct communication between branch offices without going through the hub
Zero-touch deployment: New sites can join the network without manual configuration
Scalability: Supports hundreds or thousands of sites with minimal configuration

A typical DMVPN network has three components:

Hub: The central router that maintains the control plane
Spokes: Branch office routers that connect to the hub
NHRP (Next Hop Resolution Protocol): Manages the dynamic mapping of tunnel endpoints

DMVPN operates in three phases:

Phase 1: All traffic flows through the hub (hub-and-spoke)
Phase 2: Direct spoke-to-spoke tunnels with hub routing
Phase 3: Direct spoke-to-spoke tunnels with spoke routing

This architecture makes DMVPN ideal for large-scale enterprise networks. It provides flexibility, scalability, and efficient bandwidth utilization.

Here’s a DMVPN topology (picture courtesy Cisco)

Test topology

To test DMVPN, we extend the above topology by connecting Ostinato to the LAN side of the hub and spoke routers.

If you are labbing this, you can use a single Ostinato node with multiple links as shown below - this will make it easier to see all traffic in a single GUI with all 3 ports.

If you are testing this in production or a geographically distributed environment, you can use multiple Ostinato drone agents as shown below. All the ostinato drone agents are managed by a single Ostinato GUI controller over a out-of-band management network.

If you don’t have out-of-band management access to the hosts running the drone agents, you can run both the Ostinato GUI controller and the drone agent on each node - you will have 3 Ostinato GUI windows - one per node.

Test Configuration

Since the Ostinato node(s) are connected to the LAN side of the routers, we don’t need to worry about the WAN side of the DMVPN and the overlay/underlay IP addresses.

Configure an emulated device on each of those ports on the Ostinato side. Here’s an example for the Ostinato ethernet port connected to Spoke A -

Configure similar devices on the other Ostinato ports/nodes with the appropriate IP addresses.

Then create IP traffic streams on each port towards the Hub and other Spoke. e.g. for the Ostinato ethernet port connected to Spoke A, create two streams -

Stream 1 (Spoke A to Hub): 192.168.1.100 –> 192.168.0.100
Stream 2 (Spoke A to Spoke B): 192.168.1.100 –> 192.168.2.100

You can create similar streams for other spoke-spoke and spoke-hub pairs.

To test the DMVPN, send the traffic streams and verify that the DMVPN is working correctly - use the Ostinato port stats window and monitor the traffic rates on the TX and RX ports -

You can also use per-stream statistics if exact packet loss, latency/jitter is of interest.

Test Scenarios

Here are some important scenarios to test your DMVPN setup:

Initial Tunnel Establishment
- Verify direct spoke-to-spoke tunnel creation
- Measure tunnel setup time
- Check packet loss during tunnel establishment
- Verify NHRP registration and resolution
- Monitor IPsec SA establishment
Phase Transition Testing
- Test Phase 1 hub-and-spoke operation
- Verify Phase 2 direct tunnel creation
- Validate Phase 3 routing capabilities
- Check NHRP shortcuts and routing table updates
Failover Testing
- Simulate WAN link failure between spokes
- Verify traffic fallback to hub-and-spoke mode
- Test recovery when direct tunnel is restored
- Monitor NHRP cache timeout behavior
Performance Testing
- Measure throughput with different packet sizes
- Test with mixed TCP and UDP traffic
- Check latency and jitter using stream statistics
Scale Testing
- Add multiple spoke sites gradually
- Monitor hub resource utilization
- Test maximum number of concurrent tunnels
QoS and MTU
- Test with different DSCP markings
- Verify large packets and fragmentation
- Check QoS prioritization across tunnels
- Account for IPsec and GRE overhead in MTU

Testing DMVPN with Ostinato was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on May 13, 2025.

Testing a home router

2025-04-29T00:00:00+00:00

Home Router

A typical home router consists of a bunch of wired and wireless ports towards the LAN and one port towards the WAN connected to the service provider.

The LAN ports are typically 100/1000M Ethernet and 802.11 Wireless.

The WAN port depends on the last mile technology used by the service provider e.g. DSL, PON or Fibre and sometimes even Ethernet.

Internally the home router consists largely of two major forwarding blocks - a Bridge to forward traffic between the LAN devices and a NAT to exchange traffic from the LAN devices and the Internet.

The LAN side bridge also has a companion DHCP server to allocate IP addresses to the devices connected to the LAN ports.

The WAN side has a companion DHCP client to request and receive an IP address from the service provider.

Testing the home router

To verify the functionality of the router, you can use the following test topology with Ostinato running on a PC or server acting as the traffic tester.

If the traffic tester supports only Ethernet and WiFi ports, you will need to connect suitable equipment like DSLAM or OLT/ONU between the WAN port and the traffic tester Ethernet port to convert the WAN Traffic to Ethernet.

IP address configuration

By default, the home router will use DHCP to acquire an IP address from the service provider and assign local IP addresses to the LAN ports.

However, Ostinato currently does not support DHCP and you will need to use the Ostinato device emulation feature to manually configure the IP addresses of the devices manually.

A sample configuration is shown below.

Testing the bridge

Generate traffic from one (or more) LAN ports towards the other LAN ports and verify that the traffic is correctly forwarded.

Some possible test cases are

Verify two hosts on the LAN ports are able to ping each other
Verify Unicast traffic between two hosts at various rates and packet sizes
Verify broadcast traffic is forwarded to all other LAN ports
Verify unknown unicast traffic is flooded to all other LAN ports
Verify traffic between wired and wireless ports
Verify both IPv4 and IPv6 traffic
Verify latency and jitter between LAN ports is insignificant

For all bridge tests, verify that the trafic is NOT forwarded to the WAN port.

Testing the NAT

If you are new to NAT, you can read more about it in NAT Overview and Fundamentals.

Generate traffic from one of the LAN ports towards the WAN port and verify that the traffic is correctly forwarded to the Internet.

Some possible test cases are

Use ping to verify a host on the LAN port can reach a public IP address on the Internet
Use a traffic analyzer like Wireshark to verify that NAT changes the IP address and L4 port numbers
Verify traffic at various rates and packet sizes
Verify both IPv4 and IPv6 traffic
Verify latency and jitter between WAN and LAN port is within acceptable limits

For all NAT tests, verify that the incoming traffic from the WAN port is correctly forwarded to only one LAN port.

Testing security features

If the router supports security features like firewall, you can use Ostinato to generate traffic that should be blocked by the firewall and verify that the firewall correctly blocks (or allows) the traffic.

Testing the Quality of Service (QOS)

To verify the Quality of Service (QOS) functionality of the router, you can use Ostinato to generate traffic with different DSCP (DiffServ Code Point) values for IPv4 and Traffic Class values for IPv6. This allows you to test how the router prioritizes traffic based on these values. For a detailed guide on how to verify network QOS using Ostinato, refer to How to Verify Network QOS Using Ostinato.

Are there other home router features that you’d like to test and need help with? Reach out to us!

Testing a home router was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on April 29, 2025.

FPGA Testing with Ostinato

2025-04-15T00:00:00+00:00

The worlds of networking and FPGA design have become increasingly intertwined. Modern FPGAs are now powering everything from high-speed network interfaces to complex packet processing pipelines and industrial automation systems. Whether you’re implementing a custom Ethernet MAC, building a network security appliance, or developing a specialized network function, your FPGA design needs thorough testing and verification.

Ostinato can help you with that.

No need for expensive and complex test equipment. A simple PC and a network interface card (NIC) is all you need to run Ostinato and test your FPGA design.

Let’s explore how Ostinato can be used across different aspects of FPGA development.

Network Interface Testing

At the heart of many FPGA designs is the network interface. Whether you’re implementing a standard Ethernet MAC or a custom network interface, you need to verify its functionality under various conditions. Ostinato’s ability to generate traffic patterns (valid and invalid) at various rates including line rate makes it ideal for this purpose.

You can use Ostinato to test your FPGA’s network interface by

Creating specific packet patterns to test basic functionality
Generating traffic at different rates to verify performance
Testing error handling with malformed packets
Verifying flow control mechanisms

The Stream Configuration, Port Configuration and Port Statistics features are particularly useful here, allowing you to create specific packet patterns, monitor interface performance and identify potential issues.

Protocol Implementation Verification

When implementing network protocols in FPGAs, it’s essential to ensure they handle all protocol requirements and edge cases correctly.

You can use Ostinato to verify your FPGA’s protocol implementation by

Testing support for various network protocols to ensure compatibility and correct processing
Verifying protocol conformance using standard test patterns to ensure the FPGA processes packets as expected
Injecting errors into packet streams to test the FPGA’s error handling capabilities
Validating protocol timing requirements by measuring the timing of packet processing and ensuring it meets specifications

Ostinato’s Stream Configuration allows you to craft protocol packets as per your specific requirements. You can also use the Ostinato Hexdump and userscript features to add support for custom or unimplemented protocols.

You can also import, edit and replay PCAP files.

Please note that Ostinato is stateless and does not support stateful protocols yet.

Performance Analysis

FPGA designs often need to meet strict performance requirements. Ostinato helps you measure and analyze:

Throughput at different packet sizes
Latency under various load conditions
Jitter in packet processing
Resource utilization impact

For line rate support, you can use the Turbo Transmit add-on and run standard RFC 2544 tests using the Performance Benchmark automated test suite.

Security Testing

For FPGAs implementing security functions, Ostinato can help verify:

Firewall rule implementations
DDoS protection mechanisms
Security protocol handling

Test Automation

Modern FPGA development requires automated testing. Ostinato’s Python API allows you to do all that you can using the Ostinato GUI and more that is not possible using the GUI.

Create automated test scenarios
Integrate with your verification environment
Generate test reports
Perform regression testing

Use with Emulated Designs

Ostinato can integrate with FPGA/ASIC designs running on emulation via a speedbridge. This integration allows for comprehensive testing and verification of your design in a controlled environment before deploying it on actual hardware.

Detect issues early in the development cycle, reducing the risk of costly errors later on
Enjoy a flexible testing environment where you can easily modify and test different configurations and scenarios without the need for physical hardware changes
Use Ostinato to generate and send traffic to the emulated design, configuring specific traffic patterns, rates, and protocols to match your testing requirements
Ensure your design correctly implements and handles various network protocols by simulating different protocol scenarios

By leveraging Ostinato in an emulated environment, you can enhance the reliability and performance of your FPGA/ASIC designs, ensuring they are ready for deployment in real-world applications.

Troubleshooting

Craft specific test patterns to reproduce issues
Replay known-to-cause-problem PCAP files to help identify and fix issues with your FPGA design

Case Studies

Here are some publicly available case studies that have used Ostinato for their FPGA development and troubleshooting.

Want to discuss how Ostinato can help your FPGA/ASIC development? Reach out to us!

FPGA Testing with Ostinato was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on April 15, 2025.

Generate HSR/PRP traffic using a custom protocol script

2025-03-26T00:00:00+00:00

If you are using Ostinato on Linux, see “How to generate HSR/PRP traffic on Linux” - it is easier than using the custom protocol user-script described in this guides

In this post we will see how to generate the industrial-ethernet protocols HSR/PRP traffic using Ostinato custom protocol user-script.

The Ostinato custom protocol user-script is a powerful tool that allows you to generate traffic for any protocol - even if it is not supported by Ostinato natively.

All you need to do is write a few lines of Javascript code. We will show the code for HSR/PRP in this post that you can simply copy-paste into your Ostinato user-script.

HSR (High-availability Seamless Redundancy)

Let’s begin with the frame format for HSR.

HSR is added as a header to an Ethernet frame similar to VLAN tags.

+-----------------+---------+---------+-----+
| Ethernet Header | HSR Tag | Payload | FCS |
+-----------------+---------+---------+-----+

The HSR tag is 6 bytes long and contains the following fields.

+----------+-------------+------------+-----------------+
|  Path Id |  Frame Size | Seq Number | Payload EthType |
|  4 bits  |    12 bits  |   16 bits  |     16 bits     |
+----------+-------------+------------+-----------------+

First create a Ostinato stream with all the protocols that you need, except the HSR protocol.

e.g. Mac | Ethernet | IP | UDP | Pattern Payload

Then switch to the advanced mode of protocol selection and insert {Script} between the Ethernet and IP protocols.

For the user-script, copy the following code and paste it into the user-script field.

protocol.name = "HSR"

protocol.protocolFrameSize = function() { return 6; }

protocol.protocolFrameValue = function(index)
{
    var pathId = 0x1; // Change if required

    var frameSz = protocol.protocolFramePayloadSize(index)+6;
    var type = protocol.payloadProtocolId(Protocol.ProtocolIdEth);

    var pfv = new Array(6);

    pfv[0] = pathId << 4 | (frameSz & 0xF00) >> 8;
    pfv[1] = frameSz & 0xFF;

    // Seq # will be set/incremented by variable fields; set to zero here
    pfv[2] = 0;
    pfv[3] = 0;

    pfv[4] = (type >> 8) & 0xFF;
    pfv[5] = type & 0xFF;

    return pfv;
}

protocol.protocolId = function(type)
{
    if (type == Protocol.ProtocolIdEth)
        return 0x892f;
    return 0;
}

The code is pretty much self-explanatory. In case of any questions, please refer to the Ostinato custom protocols’ user-script documentation.

You can change the pathId value as required.

For incrementing the sequence number with every packet, we will use the Variable Fields feature as shown below.

Protocol: HSR
Field: Custom
Type: Counter16
Offset: 2
Mode: Increment

Here’s a sample HSR stream that you can download and open in Ostinato.

PRP (Parallel Redundancy Protocol)

PRP is added as a trailer (RCT - Redundancy Control Trailer) instead of a header. Let’s look at the frame format first.

+-----------------+---------+---------+-----+
| Ethernet Header | Payload | PRP RCT | FCS |
+-----------------+---------+---------+-----+

The PRP RCT is 6 bytes long and contains similar fields as the HSR tag but in a different order.

+-------------+--------+------------+------------+
|  Seq Number | Lan Id | Frame Size | PRP Suffix |
|   16 bits   | 4 bits |   12 bits  |  16 bits   |
+-------------+--------+------------+------------+

The PRP suffix is a fixed value of 0x88fb.

To create a PRP packet, first create a Ostinato stream with all the protocols that you need, except the PRP protocol.

e.g. Mac | Ethernet | IP | UDP | Pattern Payload

Then switch to the advanced mode of protocol selection and insert {Script} at the very end - after the Pattern payload protocol (DATA).

For the user-script, copy the following code and paste it into the user-script field.

protocol.name = "PRP"

protocol.protocolFrameSize = function() { return 6; }

protocol.protocolFrameValue = function(index)
{
    var lan = 0xA;
    var frameSz = protocol.protocolFrameOffset(index)+4-12;

    var pfv = new Array(4);

    // Seq # will be set/incremented by variable fields; don't care here
    pfv[0] = 0;
    pfv[1] = 0;

    pfv[2] = lan << 4 | (frameSz & 0xF00) >> 8;
    pfv[3] = frameSz & 0xFF;

    pfv[4] = 0x88;
    pfv[5] = 0xfb;

    return pfv;
}

You can change the lan value as required.

For incrementing the sequence number with every packet, we will again use the Variable Fields feature as we did for HSR (but with a different offset value)

Protocol: PRP
Field: Custom
Type: Counter16
Offset: 0
Mode: Increment

A few more PRP adjustments

In case of PRP, we need to adjust the IP/UDP length to ignore the PRP RCT.

A quick way to figure out the adjustments to make is to send the packets as it is, capture in Wireshark and note down the following values:

IP Total Length
UDP Length

Then overwrite the value of the above fields in Ostinato by subtracting 6 (PRP RCT length) from each of the values as shown in Wireshark.

We also need to override the UDP checksum as shown above. Again send the packets after adjusting the IP/UDP lengths, capture in Wireshark and note down the value that Wireshark says is the expected checksum and use that to fill the UDP checksum field.

📌 Please note that if you change the Ostinato stream frame length, you will need to adjust the IP/UDP length and checksum overrides accordingly.

Here’s a sample PRP stream that you can download and open in Ostinato.

Generate HSR/PRP traffic using a custom protocol script was originally published by Ostinato at Ostinato Traffic Generator for Network Engineers on March 26, 2025.