Cisco Live 2017 - Python API Workshop
Certain tests may require support for dynamic setup before actually generating the traffic.
A general dynamic topology might look like this:
Let's focus on a concrete example:
Assume a topology where devices are using DHCP to lease IP addresses from a DHCP server.
We would like to create 100 clients with leased addresses and then generate high speed traffic
to a DUT.
Up until now it was not possible to generate dynamic tests.
But with the latest release (2.24) TRex now supports a new feature called *services*.
What is a service ?
A service is an instance of a service type which contains an internal state machine.
When created, a service will be at an INIT state of it's internal state machine pointed through a task.
When executed, the service will advance through its state machine and will eventually contain the result of the run.
For example, an ARP service instance will contain an object with a request for ARP resolution
of a specific IPv4 address.
When executed, the ARP object will contain the result of the ARP request - on success it will contain the HW address
associated with the IPv4 address in the network.
In the following chart, the diamond shapes describes a service type and the circles service instance.
The chart shows 3 ARP instances that were created, and each one is given a specific IPv4 address to resolve.
Service execution mode
Services instances are executed in parallel to provide high scale.
This means that from a test perspective, it is very easy to scale up to ~1000 services (for example 1000 DHCP clients)
without significantly impacting the test run time.
Basic test flow
When using services to generate dynamic tests the test flow might look like this:
Deep dive to Python API
Before getting our hands dirty, few definitions:
- service context - an object associated with a specific port and can execute services in parallel
- service instance - an instance of a service type that has a specific task (e.g. resolving IP address)
Step 1: import the service object and create a context
Here we import the DHCP service and create a context associated with port 0.
Step 2: create service instances
We create 100 clients with random MACs as DHCP request instances.
Step 3: move to service mode and execute the context
We move to service mode and then execute all the service instances in parallel on port 0.
Step 4: examine the results
We examine the results, filtering out any failed DHCP requests (NACK, timeout and etc.)
Step 5: use the results to generate traffic
Using the results acquired from the service execution, we generate streams from the clients
Quick look on how the output looks like:
You can also debug the services by providing verbose level to each instance.
then, examine, the results:
What else can I do with services ?
There are two main usages for services:
- Dynamic Tests
- Control Plane Tests
Services can be used to test control plane such as DHCP servers.
Although the performance might be significantly lower, there are two main advantages for using TRex to test control plane:
- Flexibility - services are implemented in Python over Scapy and can be easily enhanced, expanded and inspected
- Parallelism - services are executed in parallel using TRex high speed traffic utilization thus allowing to support many services altogether
Which services are already implemented ?
We have the following services already implemented:
and are available to use.
Behind the hood
TRex services are implemented using SimPy:
To learn more go to:
https://simpy.readthedocs.io/en/latest/
More resources
Services Documentation
Python API Cisco Live Las Vegas 2017 Workshop
If you want to learn more, join us at Cisco Live Las Vegas 2017 Python API Workshop !
Cisco Live 2017 - Python API Workshop