Keysight IXIA-C One#
What is IXIA-C?
Ixia-c is a modern, powerful and API-driven traffic generator designed to cater to the needs of hyperscalers, network hardware vendors and hobbyists alike.
Users can pull ixia-c-one container image from Github Container Registry.
The corresponding node in containerlab is identified with
keysight_ixia-c-one kind in the topology file. Upon boot up, it comes up with:
- management interface
eth0configured with IPv4/6 addresses as assigned by the container runtime
- hostname assigned to the node name
- HTTPS service enabled on port 443 (for client SDK to push configuration and fetch metrics)
Managing ixia-c-one nodes#
ixia-c-one is a "docker in docker" container hosting two kinds of ixia-c containers internally:
- API endpoint container that also manages configuration across multiple test ports. This container has the name
- A set of containers acting as test ports (i.e., for generating or processing traffic, emulating protocols, etc.). Each container represents a traffic generator's port and gets created for each endpoint defined in the containerlab file.
These containers are named
Xmatches the interface number given in the clab file.
Request and response to the API endpoint are driven by Open Traffic Generator API and can be exercised in the following two ways:
Using SDK is the preferred way of interacting with OTG devices. Implementations listed in the SDK chapter below provide references to SDK clients in different languages along with examples.
Test case designers create test cases using SDK in one of the supported languages and leverage native language toolchain to test/execute the tests. Being API-first, Open Traffic Generator compliant implementations provide full configuration flexibility over the API.
SDK clients use HTTPS to interface with the OTG API.
The example below demonstrates how gosnappi - A Go-based SDK client - can be used to configure/run a traffic test and evaluate results.
IPv4 Forwarding test is setup in the following way:
OTG 22.214.171.124 -----> 126.96.36.199 DUT 188.8.131.52 ------> OTG 184.108.40.206
Static Route on DUT:
220.127.116.11/24 -> 18.104.22.168
TCP flow from OTG:
10.10.10.1 -> 22.214.171.124+
- install go and init a module
- Download gosnappi release. gosnappi version needs to be compatible to a given release of ixia-c and can be checked at https://github.com/open-traffic-generator/ixia-c/releases
- download a basic IPv4 forwarding test
- run the test with the MAC address of the
126.96.36.199interface, which is located on the DUT as per the test diagram.
ixia-c-one container uses the following mapping for its linux interfaces:
eth0- management interface connected to the containerlab management network
- The other interfaces (eth1, eth2, etc) are the data interfaces acting as traffic generation ports
When containerlab launches ixia-c-one node, it will set IPv4/6 addresses as assigned by docker to the
eth0 interface and ixia-c-one node will boot with that addresses configured.
eth1+ have to be configured with IP addressing manually if needed (as in the Layer3 forwarding test example). IP addresses are required when the test port needs to reply to ARP/ND queries from the Device Under Test. These addresses can be configured on non-
Examples below show how test designer can configure IP address on eth1 data port of a parent container named
- Note the relative path for
./ifcfgscript. This is important, as there is a global script that is available by the
Features and options#
The free version of Ixia-c supports generation of L2 and L3 traffic to test forwarding of Ethernet, IPv4 and IPv6 traffic by switches and routers. For technical support and queries, please log requests at open-traffic-generator/ixia-c or contact us via Slack.
The commercial version of Ixia-c supports ARP/ND/Auto destination MAC resolution in data traffic, IPv4 and IPv6 BGP with IPv4 and IPv6 Routes and ISIS with IPv4 and IPv6 routes1.
The following labs feature Keysight ixia-c-one node:
Known issues or limitations#
- For L3 traffic tests using the free version , there is no in-built support of ARP and ND.
This can be worked around by manually setting IP address on the receive interface (as explained in Interfaces mapping section above) and by learning the MAC of the connected DUT using external means such as gnmi/ssh/reading it from CLI and using it when generating packets.
This limitation will be removed in the ixia-c-one free version in future releases where it is planned to support ARP/ND Request and Reply for emulated interfaces.
Please contact Keysight support for further information regarding this if needed. ↩