ASTF Client/Server Modes

[brad...@gmail.com]

My goal is to be able to use T-Rex to test end-to-end connectivity between sites, so I will have a separate T-Rex server and client.

I'm getting closer but still missing some pieces of the puzzle.

Right now I am testing in VirtualBox with 3 VM's, one for T-Rex server, one a Linux Router, and one a T-Rex client (see topology attached).

To test the routing, I used the kernel driver for the interfaces and assigned IP addresses and configured default gateway, and confirmed that 10.1.1.2 could ping 10.2.2.2, confirming the router is working. I unbinded the interfaces from the kernel driver and binded them back to igb_uio for use with TRex.

Server trex_cfg.yaml:
- version: 2
interfaces: [dummy, '00:08.0']
low_end: true
port_info:
- ip: 10.1.1.2
default_gw: 10.1.1.1

platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3]

Client trex_cfg.yaml:
- version: 2
interfaces: ['00:08.0', dummy]
low_end: true
port_info:
- ip: 10.2.2.2
default_gw: 10.2.2.1

platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3]

I'd like to run a simple test between the client and server to learn how this works, so I am trying "astf/http_simple.py". I see in this file it is using 16.0.0.0/24 for the client network and 48.0.0.0/24 for the server network, so I have added a route 10 48.0.0.0/24 via 10.1.1.2 and a route for 16.0.0.0/24 via 10.2.2.2 to my router.

Am I on the right path?

I've tried on my server:
./t-rex-64 -f astf/http_simple.py -d 600 --astf --astf-server-only --nc

One my client:
./t-rex-64 -f astf/http_simple.py -d 600 --astf --astf-client-mask 1 --nc

I run a packet capture on my router and I do see the router receiving http packets from the client, source 16.0.0.x dest 48.0.0.x, but I don't see any replies from the server. Upon further investigation I see that my router is sending ARP requests for who has 10.2.2.2 and is getting no response, so these packets are not making it to the T-Rex server. Do I need to add static ARP entries to my router or should the TRex server be answering these ARP requests?

Kind regards,

Brad

[hanoh haim]

Hi Brad,

You are in the right direction.

Try ASTF interactive mode and it should work.

More other you can add Linux stack for the interface port (trex_cfg.yaml) which will work better with emulatation layer.

See here:

https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_emulation_stacks

Thanks,

Hanoh

--
You received this message because you are subscribed to the Google Groups "TRex Traffic Generator" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trex-tgn+u...@googlegroups.com.
To post to this group, send email to trex...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/9b24ecaa-c147-4bcc-8462-4925633d84e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Hanoh

Sent from my iPhone

[brad...@gmail.com]

Glad to hear I am on the right track!
I updated my config's on both client and server to use the linux_based stack:

Example ppdated client trex_cfg.yaml:

- version: 2
interfaces: ['00:08.0', dummy]

stack: linux_based

low_end: true
port_info:
- ip: 10.2.2.2
default_gw: 10.2.2.1

platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3]

The behavior didn't seem to change. Closer inspection of the packet capture from the router reveals what is happening:

1. When I start the trex server, the TRex server sends an ARP request asking who has 10.1.1.1 (tell 10.1.1.2). The router replies, and also updates it's own ARP cache accordingly, so the router now has the MAC of the 10.1.1.2 in it's ARP cache.
2. When I start the trex client, the TRex client sends an ARP request asking who has 10.2.2.1 (tell 10.2.2.2). The router replies, and also updates it's own ARP cache accordingly, so the router now has the MAC of the 10.2.2.2 in it's ARP cache.
3. HTTP traffic from 16.0.0.x starts being recieved by the router from the TRex client, is forwarded to the TRex server, the router recieves replies from 48.0.0.x, and forwards them to the TRex client. This goes on for about 8 seconds, however:
4. 5 seconds in, the router sends an ARP request to the TRex client, who has 10.2.2.2, tell 10.2.2.1. The TRex client doesn't respond to the ARP request.
5. The router tries to ARP 10.2.2.2 again 3 times, once per second, and after the 3rd time, clears it's ARP cache entry for 10.2.2.2. Now the router stops being able to forward the traffic from 16.0.0.xz to the TRex server.


I would like to try the interactive mode as you mentioned, but I am unsure how to this with a separate client/server.

What command do I run on the server? Is it: ./t-rex-64 -i --astf --astf-server-only

What command do I run on the client? Is it: ./t-rex-64 -i --astf --astf-client-mask 1

Then what? Do I need to run two trex-console sessions, one to the server, one to the client? Then execute the test from both consoles? Or do I only need to trex-console into the client to run the tests?

[hanoh haim]

In both you should run 

./t-rex-64 -i --astf

From the Console (after connecting) you should start with  mask CLI. Both should have the same profile.

Please use the latest v2.48

Thanks,

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/ce6337c7-4b78-4f57-9065-1778a5f745d2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[brad...@gmail.com]

I run with the client mask on the client, and from the server console i run with --servers-only?

When I try this now I can see continuously bidirectional traffic being forwarded, no issues with ARP on the router anymore.

One problem still I think: I am seeing a red drop rate on the client only in TUI, is this expected when running a separate client/server or is this indicating some problem? I don't see any resource contention and this http_simple.py has very low pps/kbs, so I'm not sure why i would be seeing some drops, any ideas?


Global Statistitcs

connection : localhost, Port 4501 total_tx_L2 : 1.67 Kb/sec ▲
version : ASTF @ v2.48 total_tx_L1 : 2.09 Kb/sec ▲
cpu_util. : 0.78% @ 1 cores (1 per port) total_rx : 1.37 Kb/sec ▲
rx_cpu_util. : 0.0% / 0 pkt/sec total_pps : 2.67 pkt/sec
async_util. : 0.32% / 997.92 B/sec drop_rate : 298.8 b/sec
queue_full : 0 pkts
Thanks for all of your help!

[hanoh haim]

You should ignore it. It was designed for the mode where TRex is acting as both sides (C/S) in your case it is not relevant.

May I asked why iperf is not good enogth for your requirement? TRex was designed for high scale traffic/clients/servers is mind. The “low_end” mode is for training purposes (docker)

Thanks,

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/16f81b2d-56cd-4dbf-8fc9-706e23104b8e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[brad...@gmail.com]

Absolutely. I was looking for a testing program where I could use different traffic profiles, iPerf is a great tool and we use it often, but can only really tell us the maximum bandwidth we can use with perfect conditions (max payload packets). I wanted to see how it performs with IMIX, and that is how I found TRex.

I am using low_end mode for my Virtual Box environment for training/learning purposes, though if it is suitable for my needs (testing <100Mbps) then I might keep it, it would be very convenient to have TRex on a couple of laptops for performing end-to-end tests. If low_end mode becomes the bottleneck then we can put it on better hardware.

[hanoh haim]

Hi 

1. Stack emulation works only in interactive, 

2. you might want to consider using PF_Packet interface 

https://trex-tgn.cisco.com/trex/doc/trex_manual.html#_linux_interfaces

100Mb/sec is nothing, even low-end and PF_PAcket driver (Linux) can do that 

thanks

Hanoh

To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/30f8dec4-1a05-46df-916b-57d04efa9591%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

[brad...@gmail.com]

So, I fixed my issues with ARP but it turned out that even though I saw both TX/RX, the trafficw wasn't what I expected it was SYN from the client, and "RST, ACK" from the server, over and over again.

I finally found the problem. I had my server interface listed first, which was the only way I was getting the TRex server to respond to ARP requests:

- version: 2
interfaces: ['00:0a.0', dummy]

stack: linux_based
low_end: true
port_info:

- ip: 10.1.1.2
default_gw: 10.1.1.1

Fixing the interface order resulted in, once again, no ARP response from the server:

- version: 2
interfaces: [dummy, '00:0a.0']

stack: linux_based
low_end: true
port_info:

- ip: 10.1.1.2
default_gw: 10.1.1.1

Here is why, I was actually assigning 10.1.1.2 to the dummy interface! Changing the config to what is shown below fixed all of my problems:

- version: 2
interfaces: [dummy, '00:0a.0']

stack: linux_based
low_end: true
port_info:

- ip: 10.9.9.9
default_gw: 10.9.9.99

- ip: 10.1.1.2
default_gw: 10.1.1.1

The documentation doesn't provide examples of how to configure the dummy interface, but it does tell you the port_info is configured in order of interfaces. I don't really want/need 10.9.9.9 assigned to my dummy interface, but it doesn't really matter.

Is there a more "proper" way to configure a dummy interface with no IP?