Multi-protocol traffic generator (Seagull fork for FreeBSD, TRex ?)

Sergei_Shablovsky

Sergei_Shablovsky

Hi FreeBSD Gurus!

Please recommend me a multi-Protocol traffic generator tool like Seagull.

I more interesting in automation and profilings, like Saegull have. BTW Seagull is very powerful tool!

Thank You all!

P.S. I read on official page that “Seagull entirely coded in C++”, so may be possible to someone compiling it for 12.X or 13.X ?

Platforms supported​

  • Linux: Seagull supports Linux. It has been successfully tested with Debian, RedHat Advanced Server 2.1, RedHat Enterprise Linux 3.0, Suse 9.3 and Fedora core 3. It should be no problem for Seagull to work on other Linux platforms by compiling Seagull from the sources.
  • HPUX 11i (PA-RISC and IA64): supported.
  • HPUX 11.23 (PA-RISC and IA64): supported.
  • Windows/cygwin: supported, only for IP-based protocols (for functional testing and limited load testing).

UPDATE
—————————————————-++

I found the Seagull fork on GitHub:

This repo was cloned from Seagull's svn repo on SourceForge on 2015-04-22.

Goal of this Repo​

I wanted to build and use Seagull on Ubuntu for Diameter protocol testing. I came across a lot of roadblocks that needed to be surmounted, primarily compiler errors when I tried to build it on anything modern, say CentOS 7 or Ubuntu 14.04.

The primary goal with this repo is to provide patches to the Subversion revision 422 of Seagull to make it build and work on Ubuntu 15.04 and CentOS 7.1 (1503).
 
roccobaroccoSC said:
You can use benchmarks/iperf. It measures network throughput:

Code: 
user@server $ iperf -s
user@client $ iperf -c server
Click to expand...

Thank You!

iperf3 is more suitable for internal tuning the infrastructure, for example in DC

I ask about more sophisticated tool.

From official Seagull page:

Seagull is a powerful traffic generator for functional, load, endurance, stress and performance/benchmark tests for almost any kind of protocol.

In addition, its openness allows to add the support of a brand new protocol in less than 2 hours - with no programming knowledge. For that, Seagull comes with several protocol families embedded in the source code:

  • Binary/TLV (Diameter, Radius and many 3GPP and IETF protocols)
  • External library (TCAP, SCTP)
  • Text (XCAP, HTTP, H248 ASCII)

Protocols are then implemented on top of those protocol families using user editable XML dictionaries. Those dictionaries describe how messages and parameters are encoded, allowing a great flexibility.

A Seagull scenario - written in XML - describes the messages that are sent and received. It also indicate the behavior to adopt in case a message is unexpected or a check on a parameter fails.

Entirely coded in C++, Seagull is optimized for performances.

Ready to install packages are available for HP-UX (PARisc and IPF/IA64), Linux and Win32 (Cygwin). Seagull can also be compiled from the source code.

Seagull supports currently the following protocols:

  • Diameter base ( RFC 3588) and any Diameter relating application - IMS Cx, Dx, Ro, Rf, Sh over TCP or SCTP or TLS over IPv4 or IPv6.
  • TCAP ITU and ANSI and any protocol over TCAP (Camel, GSM MAP, IS41, Win, ...) either over SS7 (E1/T1) or SIGTRAN. For that, it relies on HP OpenCall SS7.
  • XCAP over HTTP over IPv4
  • HTTP over IPv4
  • H248/Megaco ASCII form over UDP or TCP or SCTP/IPv4
  • Radius (subset) over IPv4.

Seagull has the following features:

  • Multi-protocol traffic generator
  • Command line tool with text interface
  • Protocols of the same family are described in an XML, user editable, dictionary (messages, parameters)
  • Existing protocol families: Binary/TLV (Type, Length, Value), Raw binary, Text, external API (first implementation: HP OpenCall SS7)
  • Support of IP (UDP/TCP), SCTP, SSL/TLS and SS7/TCAP transports
  • Portable programming (tested and supported on Linux x86, ia64, HPUX, SunOS and Windows)
  • Scenarios are described using XML files
  • Multi-threaded for performances and reliability
  • Dynamically adjustable scenario rate
  • Uniform, Poisson or Best-effort scenario arrival distribution
  • Remote-control (scenario-rate set, counter dump) through standard HTTP interface
  • Pause and restart of traffic
  • Support of automated traffic profile (varying scenario rate)
  • Smooth (no new scenarios then wait for ongoing scenarios to end) or brutal end
  • Scenario display with message counters
  • Scenarios have init (executed once), main (repeated for traffic) sections
  • Scenarios have default sections for defense in case of unexpected messages
  • A scenario can be mono (most cases) or multi-protocol
  • Message and parameters checking possible (disabled by default)
  • Support of parameter injection following a CSV like database
  • Multiple Seagull instances can be synchronized in the middle of scenario
  • Intra scenario synchronization using a synchronization protocol (example application provided in Java language)
  • Statistics: timer between two messages, scenario length, scenario rate, successful scenarios, failed scenarios (with reason)
  • Protocol decoding and hexadecimal dump
  • Trace files with or without timestamps (for performances and automation)
  • ...

iperf3 just like “from another Earth” :)
 
This seems like a mostly dead project. The latest download image on sourceforge is over 10 years old. Why don't you try porting it yourself if you really need it?
 
bakul said:
This seems like a mostly dead project. The latest download image on sourceforge is over 10 years old.
Click to expand...
You are right. Old project and no activity a long time.

bakul said:
Why don't you try porting it yourself if you really need it?
Click to expand...
Have no sufficient knowledge to doing this professionally (because must be a lot of corrections needed).

Anyway, Seagull be better (I have a doubts about this) than most from this list (for example) http://www.testingtoolsguide.net/listing-category/load-testing/.

If anyone know better tool with ability to fine tuning on all levels from packet up to protocol structure - please suggest me. I would be thankful!
 
Sergei_Shablovsky said:
For anyone who interested in network testing, there are another great open source tool TRex Realistic Traffic Generator https://trex-tgn.cisco.com/
Click to expand...
Hi Sergei,

I spent about an hour playing with the source for the latest version of TRex. It is written in Python which made me hopeful. However there are a ton of LINUX dependencies (for instance didn't know amd64 was a 64 bit machine type, was looking in the non-existant /proc/modules to see what network devices existed, required bash shell etc). I suspect with a whole lot of rewrite it could address the differences for FreeBSD but it is not a project I have an inclination to do.

Bob
 
bgrant said:
Hi Sergei,

I spent about an hour playing with the source for the latest version of TRex. It is written in Python which made me hopeful. However there are a ton of LINUX dependencies (for instance didn't know amd64 was a 64 bit machine type, was looking in the non-existant /proc/modules to see what network devices existed, required bash shell etc).
Click to expand...
Dear Bob, thank You for detail answering!
I’m a little bit newbie in FreeBSD, so not really know the history/lifecycle of applications in BSD's ecosystem.
Is that You describe indicate that TRex are not well designed, or not well maintained (so, may be unstable work, unpredictable work, errors in code, no code control at all, wrong results, etc...)

bgrant said:
I suspect with a whole lot of rewrite it could address the differences for FreeBSD but it is not a project I have an inclination to do.
Click to expand...
What tool You suggest to using for complexity network testing ? (TRex, Seagull, PacketSender, etc...)

Thank You, have a nice day!
 
Sergei_Shablovsky said:
[...] Is that You describe indicate that TRex are not well designed, or not well maintained (so, may be unstable work, unpredictable work, errors in code, no code control at all, wrong results, etc...)
Click to expand...
Not any of the above (except maybe the designed part). When people write a tool they often have a target in mind. In the case of TRex the tool writer was targeting Debian and/or RedHat which are different Linux flavors but have a common OS Kernel. (For all I know they originally wrote for one of those distributions and later made the slight tweaks to run also on the other one) When looking at the author's shell and Python scripts I see an occasional if OS=ubuntu and if OS=redhat so they can do different things for the two different Linux distributions.

For speed TRex uses some Kernel modules and has a C build directory for the modules. As far as I know (and I'm pretty sure) there is no way to load Linux kernel modules on FreeBSD and the OS Kernel internals are totally different between Linux and FreeBSD as they are completely different OS trees. This means a total rewrite of those kernel modules to make them loadable on the FreeBSD kernel.

A possible alternative is to look in the Python code and see if there is a way to use some higher level feature or existing FreeBSD kernel module to get the same functionality.

A design from the beginning for multiple platforms usually has (in this case C example) ifdef FreeBSD blah blah blah ifdef Ubuntu blah blah blah in its source code files. Inside of each ifdef block is a set of small functions that implement a needed feature for the package in that system's application or kernel programming interface. Even so, sometimes changes in a particular operating system will require modifications to that code in the OS specific ifdef and then there is usually a more complicated set of ifdefs that check both OS and version before or after a particular version to provide backward compatibility.

If someone took on porting TRex to FreeBSD the right way would be to write code to check if on FreeBSD and make any changes inside if statements with the hope that Cisco would take the changes upstream in their code repository. Of course, they or the FreeBSD porter would need to check on RedHat and Debian to make sure the changes hadn't broken it there. Not a trivial exercise.
Sergei_Shablovsky said:
What tool You suggest to using for complexity network testing ? (TRex, Seagull, PacketSender, etc...)
Click to expand...
I hope someone else with knowledge will answer. I'm more of a programmer than a network engineer (although I have worn that hat in the past). For my purposes, mtr, iperf3, ping(8), and tcpdump fill most of my needs for network troubleshooting and base throughput checks.

I did a search on FreeBSD's FreshPorts site and found a couple of network performance testing ports: benchmarks/netperfmeter and benchmarks/nuttcp. You might try various keywords in the search page to see if there are others to be found.

Actually, I recommend browsing the benchmarks (only 111 ports) port directory. I ran across benchmarks/netperf which might be closer to what you want. Unfortunately the net subdirectory has thousands of ports so if there is a test set there it will be buried.

I hope this helps.

Bob
 
bakul said:
Looking at the github repo for trex-core, it is written in cpp & is quite huge (800K+ lines). You may be better off exploring https://scapy.net (though it too may have linux dependencies).
Click to expand...
Thank You for suggestions. I’ll do.

bakul said:
What protocols do you want to test and what sort of scenarios?
Click to expand...
Primary all protocols that around office needs and general web: mostly audio streaming, web/hosting, sip, web video calls, web surfing, Skype/FaceTime, IoT, etc.
No any specific, like used inside cellular operators networks or inside financial transactions networks...

Scenarios ... to write shortly and not break NDA: are mix of connects with low delay/jitter and high delay/jitter/packet loss, with spontaneous increasing user numbers x20, x50, x100 times in certain time of day.

P.S. As You may see in TRex test profiles examples on GitHub, some profiles include tuning for Netflix, YouTube, Skype... ;)
Generally looks like most of that tests CISCO made for their platform for cellular providers 8-10 years ago :)
I hope exist a lot of special TRex tests for modern cellular network conditions, and 99,999% of this test are unpublished, under NDA and highly secured. ;) But who know, we all here have experience when well-reputable and big companies using VERY outdated software inside shining modern rack-boxes :)
 
bgrant said:
I'm more of a programmer than a network engineer (although I have worn that hat in the past).
Click to expand...
So could You be so please to take a look on that 36 public repo list on GitHub and choose which may be useful for purpose like SeaGull & TRex used.

github.com

Build software better, together

GitHub is where people build software. More than 83 million people use GitHub to discover, fork, and contribute to over 200 million projects.
github.com github.com


bgrant said:
For my purposes, mtr, iperf3, ping(8), and tcpdump fill most of my needs for network troubleshooting and base throughput checks.
Click to expand...
Happy man :)
 
Sorry, I don’t have the cycles to look through too many sites but you made me click and it is an interesting GitHub site. I happened to look at mgen and then checked and there is a port already in the FreeBSD ports site net/mgen. Also as bakul mentioned scapy sounds interesting and it is also in FreeBSD ports net/scapy just FYI though scapy in FreeBSD ports is depreciated due to a crypto port that is no longer maintained.

I’m sure I’ll see you around the forums. Good luck finding your SeaGull/TRex replacement.
 
bakul said:
You may be better off exploring https://scapy.net (though it too may have linux dependencies).
Click to expand...
Need to note, the analytics of measurements, collecting that measurements results for future comparing (this mean some sort of database) - very important.
Also profiling the testing with quick access to profiles and their results - the same important as usability of constructing packets. Even may be more important.
 
bgrant said:
Hi Sergei,

I spent about an hour playing with the source for the latest version of TRex. It is written in Python which made me hopeful. However there are a ton of LINUX dependencies (for instance didn't know amd64 was a 64 bit machine type, was looking in the non-existant /proc/modules to see what network devices existed, required bash shell etc). I suspect with a whole lot of rewrite it could address the differences for FreeBSD but it is not a project I have an inclination to do.

Bob
Click to expand...
Dear Bob!

At the first lay me say BIG THANKS about diving in this case! Respect! ;)

Could You be so please trying to predict which problems may happened when installing and using for production testing TRex and Seagull on same REHL bare-metal server with 40Gb Mellanox or Intel NICs ?
(I mean some drivers, overall system settings conflicts, etc…)
 
You must log in or register to reply here.
Back
Top