Okay, so I wanted to mess around with TRex, specifically its “side by side” feature. I’d heard about it and it sounded cool, but I’d never actually tried it. Here’s how it went down.
First, I got TRex installed. I already had it on my system, but if you don’t, their documentation is pretty straightforward. It’s mostly just downloading and setting up a few dependencies.
Getting Started
Then I needed some network devices to test with. I don’t have a bunch of physical routers lying around, so I opted to use virtual interfaces. I created two virtual Ethernet pairs (veth pairs) on my Linux box. Super easy to do with the `ip link` command. Something like:
- `ip link add veth0 type veth peer name veth1`
- `ip link add veth2 type veth peer name veth3`
I assigned IP addresses to each of these interfaces, just like you would with any regular network interface. Made sure they were in different subnets, you know, to simulate a real network setup.
Configuring TRex
Next, I dug into the TRex configuration. This is where the “side by side” part comes in. Basically, you tell TRex which interfaces are considered “eastbound” and which are “westbound.” It’s like setting up a virtual network topology within TRex itself.
I opened up the `trex_*` file (or whatever your config file is called) and looked for the interface section. I specified my veth pairs, something like this (this is just a simplified example, the real config might be a bit different):
-
- port_limit: 2
version: 2
interfaces:
- device: "veth0"
dst_mac: "00:11:22:33:44:55"
src_mac: "00:11:22:33:44:56"
- device: "veth2"
dst_mac: "00:66:77:88:99:aa"
src_mac: "00:66:77:88:99:bb"
I did use some random mac address, and didn’t need to setup any destination and src mac addresses, as the traffic will loopback.
Running the Test
With the configuration sorted, I fired up TRex. I used the `t-rex-64 -i` command to start it in interactive mode.
And then I started to learn how to start to send traffic. I selected a simple profile, something like `stl/udp_1pkt_*`, to send some basic UDP traffic.
I then used a simple command to start to send traffic:
- `start -f stl/udp_1pkt_* -m 10 -d 10`
The `-m 10` means to send traffic at 10% of the maximum line rate.
The `-d 10` means sending the traffic for 10 seconds.
And… it worked! I saw the traffic flowing in the TRex console. I could see the packets going out on one interface (say, veth0) and coming back in on the other (veth2). That’s the “side by side” magic happening.
Observations and Tweaking
I played around with different traffic profiles, changing packet sizes, rates, and protocols. I monitored the statistics in the TRex console to see how things were performing. It was pretty neat to watch the traffic flow and see the impact of different configurations.
One thing I noticed was that if I pushed the traffic rate too high, I started to see packet drops. That’s expected, of course, especially with virtual interfaces. It just showed me the limits of my setup.
Overall, it was a fun little experiment. It gave me a better understanding of how TRex works and how the “side by side” feature can be used to test network configurations in a controlled environment. I can definitely see how this would be useful for testing routers, firewalls, or any other network device. And it made the whole process feel way less abstract.