Using t-rex-64 command or using console start command
1,913 views
Skip to first unread message
AndersKn
Feb 9, 2016, 3:40:58 AM2/9/16
to TRex Traffic Generator
Hi!
I’ve used TRex to run traffic and come to the conclusion that when running t-rex using the "t-rex-64" command (according to t-rex manual, i.e. providing the .yaml file to this command), it is limited to using PCAP files with TCP/IP/Ethernet or UDP/IP/Ethernet (at least no other protocol on top of IP is supported). T-rex contains both the client and the server and t-rex assumes that DUT doesn’t change the addressing information (IP addresses and ports) in the packet.
According to the "TRex console - commands proposal" documentation, I started t-rex interactively ("t-rex-64 –i") and started the console.
From the console I used the "start" command (providing the .yaml file to this command), which seems to work also with PCAP files other than TCP/IP/Ethernet or UDP/IP/Ethernet. When using the "start" command, t-rex also seems to accept receiving packets, even though the addressing information has been changed by the DUT.
My questions are:
What is the difference between using t-rex with the "t-rex-64" command and using the "start" console command in interactive mode?
When I look at the .yaml files used in the 2 cases, they look different. I also get less information when using the console start command, lacking e.g. latency and jittering information.
Regards
Anders
I’ve used TRex to run traffic and come to the conclusion that when running t-rex using the "t-rex-64" command (according to t-rex manual, i.e. providing the .yaml file to this command), it is limited to using PCAP files with TCP/IP/Ethernet or UDP/IP/Ethernet (at least no other protocol on top of IP is supported). T-rex contains both the client and the server and t-rex assumes that DUT doesn’t change the addressing information (IP addresses and ports) in the packet.
According to the "TRex console - commands proposal" documentation, I started t-rex interactively ("t-rex-64 –i") and started the console.
From the console I used the "start" command (providing the .yaml file to this command), which seems to work also with PCAP files other than TCP/IP/Ethernet or UDP/IP/Ethernet. When using the "start" command, t-rex also seems to accept receiving packets, even though the addressing information has been changed by the DUT.
My questions are:
What is the difference between using t-rex with the "t-rex-64" command and using the "start" console command in interactive mode?
When I look at the .yaml files used in the 2 cases, they look different. I also get less information when using the console start command, lacking e.g. latency and jittering information.
Regards
Anders
hanoh haim
Feb 9, 2016, 3:54:05 AM2/9/16
to AndersKn, TRex Traffic Generator
Hi Anders,
--
The documented TRex is the Stateful one.
The power of this mode that it create a realistic traffic for Stateful features (NAT/FW/DPI).
It is limited for simple IPv4/ IPv6 TCP/UDP L7 applications.
The new one is the Stateless support which is not documented yet and it is under dev.
The stateless is more for Switch/Router L2/l3 tests and it is not limited with packet type. But it is not Stateful.We hope to release it soon.
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/9b7f597b-37e7-462d-a69b-bf852a5e295b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Hanoh
Sent from my iPhoneanders.k...@gmail.com
Feb 9, 2016, 5:22:16 AM2/9/16
to TRex Traffic Generator
Hi!
Even though the new one (stateless one) is more for Switch/Router L2/l3 tests, it seems like it can also be used for generating traffic towards a DUT which terminates the traffic and generates something else back.
I.e. when using stateless mode, packets will be received successfully by t-rex even though the received packet is something else than what is sent from t-rex. Maybe the received packet doesn't even have to be an IP packet.
As I have understood, this is not the case in stateless mode. At least the addresses/ports (IP/UDP/TCP) must be unchanged by the DUT, in order to be received successfully by t-rex.
Is this correct?
Can I get also latency and jitter information when using stateless mode or is it only when using stateful mode?
Regards
Anders
Den tisdag 9 februari 2016 kl. 09:54:05 UTC+1 skrev hanoh haim:
> Hi Anders,
> The documented TRex is the Stateful one.
> The power of this mode that it create a realistic traffic for Stateful features (NAT/FW/DPI).
> It is limited for simple IPv4/ IPv6 TCP/UDP L7 applications.
>
>
> The new one is the Stateless support which is not documented yet and it is under dev.The stateless is more for Switch/Router L2/l3 tests and it is not limited with packet type. But it is not Stateful.
Even though the new one (stateless one) is more for Switch/Router L2/l3 tests, it seems like it can also be used for generating traffic towards a DUT which terminates the traffic and generates something else back.
I.e. when using stateless mode, packets will be received successfully by t-rex even though the received packet is something else than what is sent from t-rex. Maybe the received packet doesn't even have to be an IP packet.
As I have understood, this is not the case in stateless mode. At least the addresses/ports (IP/UDP/TCP) must be unchanged by the DUT, in order to be received successfully by t-rex.
Is this correct?
Can I get also latency and jitter information when using stateless mode or is it only when using stateful mode?
Regards
Anders
Den tisdag 9 februari 2016 kl. 09:54:05 UTC+1 skrev hanoh haim:
> Hi Anders,
> The documented TRex is the Stateful one.
> The power of this mode that it create a realistic traffic for Stateful features (NAT/FW/DPI).
> It is limited for simple IPv4/ IPv6 TCP/UDP L7 applications.
>
>
hanoh haim
Feb 9, 2016, 5:27:40 AM2/9/16
to anders.k...@gmail.com, TRex Traffic Generator
See inline
On Tuesday, 9 February 2016, <anders.k...@gmail.com> wrote:
--
Could you say what do you want to test?
On Tuesday, 9 February 2016, <anders.k...@gmail.com> wrote:
Hi!
Even though the new one (stateless one) is more for Switch/Router L2/l3 tests, it seems like it can also be used for generating traffic towards a DUT which terminates the traffic and generates something else back.
I.e. when using stateless mode, packets will be received successfully by t-rex even though the received packet is something else than what is sent from t-rex. Maybe the received packet doesn't even have to be an IP packet.
As I have understood, this is not the case in stateless mode. At least the addresses/ports (IP/UDP/TCP) must be unchanged by the DUT, in order to be received successfully by t-rex.
Is this correct?
In Stateful The packet change is limited only for NAT changes (inside/outside). In Stateless there are less limitations
Can I get also latency and jitter information when using stateless mode or is it only when using stateful mode?
Yes. We are working on stats per stream by hardware and Jitter/Latency. This part is a WIP
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/fe707cbe-eace-4cf6-b94f-e5b66a423afb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
AndersKn
Feb 9, 2016, 9:16:49 AM2/9/16
to TRex Traffic Generator
Hi!
I want t-rex to send non UDP/TCP traffic towards DUT (traffic is terminated in DUT) and I want the DUT to send some other non UDP/TCP traffic back to T-rex.
This means that I want t-rex to be able to handle outgoing and incoming traffic which doesn't need to be related to each other, neither address/port wise (i.e. addresses/port can have been swapped), maybe not even protocol wise.
Do I understand correctly that jitter/latency statistics will be provided through the stats and streams console commands but that it isn't yet implemented.
I want t-rex to send non UDP/TCP traffic towards DUT (traffic is terminated in DUT) and I want the DUT to send some other non UDP/TCP traffic back to T-rex.
This means that I want t-rex to be able to handle outgoing and incoming traffic which doesn't need to be related to each other, neither address/port wise (i.e. addresses/port can have been swapped), maybe not even protocol wise.
Do I understand correctly that jitter/latency statistics will be provided through the stats and streams console commands but that it isn't yet implemented.
hanoh haim
Feb 9, 2016, 12:42:30 PM2/9/16
to AndersKn, TRex Traffic Generator
Hi Andres,
It seems you need the Stateless mode. You can continue playing with that but it is still not finished.
Yes the per stream Rx stats will be provided throw Console/API/GUI
Can you say what is the type of the packet you are using ?
From the Rx stats/latency/jitter point of view, there are two modes of filters
1. ipv4/ipv6 - id field ( each stream can set this id and there is a filter in rx on packet/jitter)
2.Any payload offset - mask
The first filter is for short packet.
Do you expect in your case the transmitted packet magic in different offset of the receive packet.
To view this discussion on the web visit https://groups.google.com/d/msgid/trex-tgn/c1940aab-56d7-4cca-8578-238ce6c51a61%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages