Belastungstests von Netzwerken mit dem Datenverkehr-Generator Cisco TRex


 

Bei der Entwicklung eines aktuellen Routers haben wir die Netzwerkleistung mit einem nützlichen Open-Source-Tool getestet - dem Netzwerkdatenverkehr-Generator Cisco TRex. Was für ein Werkzeug ist das? Wie wird es verwendet? Und was kann es für Entwicklungsingenieure leisten? Nachfolgend finden Sie Antworten auf diese Fragen.

 

1. Was ist Cisco TRex?

Es handelt sich um einen Open-Source-Software-Verkehrsgenerator, der auf standardmäßigen Intel DPDK-basierten Prozessoren läuft und zustandsabhängige/zustandslose Modi unterstützt. Das Produkt ist leicht verständlich und vollständig skalierbar.

Die englischsprachige Dokumentation für dieses Tool ist auf der Website verfügbar.

TRex ermöglicht es, verschiedene Arten von Datenverkehr zu generieren und die empfangenen Daten zu analysieren, wobei MAC- und IP-Schicht unterstützt werden. Es ist möglich, die Paketgröße und die Anzahl der Pakete einzustellen und die Datenrate zu steuern.

Die Arbeit mit dem Generator wurde in einer Linux-Umgebung durchgeführt.

Eines der wichtigsten Merkmale des TRex-Generators ist die Verwendung der DPDK-Technologie, mit der die Leistungsengpässe des Linux-Netzwerkstacks umgangen werden. Das DPDK (Data Plane Development Kit) umfasst eine Reihe von Bibliotheken und Treibern für die schnelle Paketverarbeitung, die es ermöglichen, den Linux-Netzwerkstack bei der Paketverarbeitung zu umgehen und direkt mit dem Netzwerkgerät zu kommunizieren.

Das DPDK verwandelt einen Allzweckprozessor in einen Paketweiterleitungsserver. Diese Transformation macht teure Switches und Router überflüssig. Das DPDK schränkt jedoch die Verwendung auf bestimmte Netzwerkadapter ein, die Liste der unterstützten Hardware finden sie hier - es ist Intels beliebteste Plattform, d.h. es wird Hardware unterstützt, die mit den Linux-Treibern e1000, ixgbe, i40e, ice, fm10k, ipn3ke, ifc, igc funktioniert.

Der Betrieb eines TRex-Servers mit 10 Gbit/s setzt einen Multi-Core-Prozessor mit mindestens 4 Kernen voraussetzt, vorzugsweise eine Intel-CPU mit Unterstützung für gleichzeitiges Multi-Threading (Hyper-Threading).

 

2. TRex herunterladen und starten

1) Laden Sie das Archiv vom Server trex-tgn.cisco.com herunter: trex-tgn.cisco.com/trex/release/

[bash]>wget --no-cache https://trex-tgn.cisco.com/trex/release/latest
[bash]>tar -xzvf latest

Entpacken Sie das Archiv in das Home-Verzeichnis des Benutzers /home/user, wobei user für den Benutzernamen steht.


2) Konfiguration der Schnittstellen zum Senden und Empfangen von Daten

Für die Konfiguration können Sie das Dienstprogramm dpdk_setup_ports.py verwenden, das im TRex-Paket enthalten ist. Die von TRex verwendeten Netzwerkschnittstellen können auf MAC- oder IP-Ebene konfiguriert werden. Starten Sie das Dienstprogramm im interaktiven Modus: sudo ./dpdk_setup_ports.py -i

Im ersten Schritt verwerfen wir die MAC-basierte Konfiguration (Möchten Sie eine MAC-basierte Konfiguration verwenden? (j/N) n).

Der zweite Schritt besteht darin, ein Paar von Netzwerkschnittstellen auszuwählen, die wir benutzen wollen. In unserem Fall verfügt die Netzwerkkarte Intel X710 über 4 Netzwerkschnittstellen, wir werden Slot 1 und Slot 4 der Netzwerkkarte verwenden.
 



Im dritten Schritt bietet das System an, automatisch eine geschlossene Konfiguration zu erstellen, bei der die Daten Port 1 verlassen und bei Port 2 ankommen (und zurück), und zwar auf demselben PC. Wir mussten dieses Schema aufgeben und ein Routing-Schema mit 2 PCs einrichten.

Im vierten und fünften Schritt stimmen wir dem Speichern der Konfiguration in der Datei /etc/trex_cfg.yaml zu.

Betrachten wir als Beispiel die Konfiguration auf IP-Ebene für das folgende Verbindungsschema:


 

Die Konfigurationsdatei ist hier zu finden: /etc/trex_cfg.yaml. Nachfolgend sehen Sie eine einfache Konfigurationsdatei für eine Netzwerkkarte mit 2 Ports und einer CPU, die 8 Threads unterstützt:

### Config file generated by dpdk_setup_ports.py ###
- version: 2 interfaces: ['01:00.0', '01:00.3']
port_info:
- ip: 192.168.253.106
default_gw: 192.168.253.107
- ip: 192.168.254.106
default_gw: 192.168.254.107
platform:
master_thread_id: 0
latency_thread_id: 1
dual_if:
- socket: 0
threads: [2,3,4,5,6,7]

In der Konfiguration verwendete Adressen:

  • '01:00.0', '01:00.3' — Name der verwendeten Eth-Schnittstellen im Linux-System.
  • ip: 192.168.253.106 — IP-Adresse des TRex-Servers, von dessen Port der Datenverkehr erzeugt wird.
  • default_gw: 192.168.253.107 — IP-Adresse des PC-Prüflings (DUT … Device under test), der an Port 1 getestet wird
  • ip: 192.168.254.106 — IP-Adresse des TRex-Servers, an dessen Port der Verkehr nach Durchlaufen der QOS-Regeln zurückgesendet wird
  • default_gw: 192.168.253.107 — IP-Adresse des PC-Prüflings mit Port 2

Achtung! Das TRex-System verbietet bei der Generierung des Datenflusses die Verwendung desselben Subnetzes, das auch vom System verwendet wird. Daher werden für die Paketgenerierung die Subnetze 16.0.0.0 und 48.0.0.0 benutzt.


3) Konfiguration der Schnittstellen auf dem Remote-Rechner

Es ist notwendig, die Paketweiterleitung und die Routen so zu konfigurieren, dass das System (DUT), durch das der Verkehr geleitet wird, weiß, wo es Pakete empfangen und wohin es diese senden soll.

Wir konfigurieren die Routing-Regeln auf dem PC-Prüfling (DUT):

sudo echo 1 > /proc/sys/net/ipv4/ip_forward
sudo route add -net 16.0.0.0 netmask 255.0.0.0 gw 192.168.253.106
sudo route add -net 48.0.0.0 netmask 255.0.0.0 gw 192.168.254.106


4) Starten des TRex-Servers im ASTF-Modus (Advance Stateful):

cd v2.XX

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

Wenn der TRex-Server erfolgreich gestartet wurde, werden Informationen über die zum Testen verwendeten Ethernet-Ports angezeigt:

The ports are bound/configured.
port : 0
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
port : 1
------------
link : link : Link Up - speed 10000 Mbps - full-duplex
promiscuous : 0
number of ports : 2
max cores for 2 ports : 1
tx queues per port : 3


5) Starten der TRex-Konsole

cd v2.XX
./trex-console
start -f astf/http_simple.py -m 1

start (options):
-a (all ports)
-port 1 2 3 (ports 1 2 3)
-d duration (-d 100 -d 10m -d 1h)
-m stream strength (-m 1 -m 1gb -m 40%)
-f load from disk the streams file

Öffnen Sie die Konsole in einem separaten Fenster, um die Generierung des Datenflusses aus den vorgefertigten Beispielen zu starten (der Ordner mit den ASTF-Beispielen befindet sich im TRex-Archiv):

Nach erfolgreichem Start werden in der TRex-Serverkonsole die Statistiken zum Verkehrsfluss angezeigt:

Global stats enabled
Cpu Utilization : 0.3 % 0.6 Gb/core
Platform_factor : 1.0
Total-Tx : 759.81 Kbps
Total-Rx : 759.81 Kbps
Total-PPS : 82.81 pps
Total-CPS : 2.69 cps

Expected-PPS : 0.00 pps
Expected-CPS : 0.00 cps
Expected-L7-BPS : 0.00 bps

Active-flows : 2 Clients : 0 Socket-util : 0.0000 %
Open-flows : 641

 

3. Entwicklung und Test mit TRex automatisieren

Während der Entwicklung eines Netzwerk-Routers haben wir viele Tests für TRex geschrieben, so dass die Frage aufkam, wie man diese mit Python automatisch ausführen kann. So haben wir es organisiert:

Wir haben den TRex-Server im STL-Modus (Stateless) gestartet:

cd v2.XX
sudo ./t-rex-64 -i --stl

Es muss eine Umgebungsvariable für Python festgelegt werden, da TRex in Verbindung mit Python arbeitet.

export PYTHONPATH=/home/<user>/v2.XX/automation/trex_control_plane/interactive,

wobei <user> durch den Nutzename und das Homeverzeichnis ersetzt werden muss und v2.XX die heruntergeladene und in dieses Verzeichnis entpackte Version der TRex-Software ist

Wir haben den Traffic-Generator mit Python gestartet. Die Konfigurationsdatei ist unten abgebildet.

python example_test_2bidirectstream.py

Erwartete Ausgabe:

Transmit: 10000.24576MByte/s Receive: 10000.272384MByte/s
Stream 1 TX: 4487179200 Bit/s RX: 4487179200 Bit/s
Stream 2 TX: 2492873600 Bit/s RX: 2492873600 Bit/s
Stream 3 TX: 1994294400 Bit/s RX: 1994294400 Bit/s
Stream 4 TX: 997147200 Bit/s RX: 997147200 Bit/s

Sehen wir uns dieses Beispiel genauer an:

Zuerst wird eine Verbindung zum TRex-Server hergestellt, in diesem Fall zum gleichen Rechner hergestellt, auf dem auch der Server läuft.

  • base_pkt_dir_a, base_pkt_dir_b, base_pkt_dir_c, base_pkt_dir_d sind die Paketvorlagen mit Quell- und Zieladressen sowie Quell- und Zielports. In diesem Beispiel werden 4 Datenflüsse erzeugt, 2 in die eine Richtung und 2 in die entgegengesetzte Richtung.
  • s1, s2, s3, s4 - von der STLStream-Klasse werden die Parameter des generierten Flusses angefordert, wie Stream-ID und Bitrate, in unserem Fall ID1=4.5 Gbps, ID2=2.5 Gbps, ID3=2 Gbps, ID4=1 Gbps.

Konfigurationsdatei des Datenflusses example_test_2bidirectstream.py

# get TRex APIs
from trex_stl_lib.api import *

c = STLClient(server = '127.0.0.1')
c.connect()

try:
# create a base packet with scapy
base_pkt_dir_a = Ether()/IP(src="16.0.0.1",dst="48.0.0.1")/UDP(dport=5001,sport=50001)
base_pkt_dir_b = Ether()/IP(src="48.0.0.1",dst="16.0.0.1")/UDP(dport=50001,sport=5001)

base_pkt_dir_c = Ether()/IP(src="16.0.0.2",dst="48.0.0.2")/UDP(dport=5002,sport=50002)
base_pkt_dir_d = Ether()/IP(src="48.0.0.2",dst="16.0.0.2")/UDP(dport=50002,sport=5002)

# pps : float
# Packets per second
#
# bps_L1 : float
# Bits per second L1 (with IPG)
#
# bps_L2 : float
# Bits per second L2 (Ethernet-FCS)
packet_size = 1400

def pad(base_pkt):
pad = (packet_size - len(base_pkt)) * 'x'
return pad

s1 = STLStream(packet=STLPktBuilder(base_pkt_dir_a/pad(base_pkt_dir_a)), mode=STLTXCont(bps_L2=4500000000), flow_stats=STLFlowStats(pg_id=1))
s2 = STLStream(packet=STLPktBuilder(base_pkt_dir_b/pad(base_pkt_dir_b)), mode=STLTXCont(bps_L2=2500000000), flow_stats=STLFlowStats(pg_id=2))
s3 = STLStream(packet=STLPktBuilder(base_pkt_dir_c/pad(base_pkt_dir_c)), mode=STLTXCont(bps_L2=2000000000), flow_stats=STLFlowStats(pg_id=3))
s4 = STLStream(packet=STLPktBuilder(base_pkt_dir_d/pad(base_pkt_dir_d)), mode=STLTXCont(bps_L2=1000000000), flow_stats=STLFlowStats(pg_id=4))

my_ports = [0, 1]

c.reset(ports = [my_ports[0], my_ports[1]])

# add the streams
c.add_streams(s1, ports = my_ports[0])
c.add_streams(s2, ports = my_ports[1])
c.add_streams(s3, ports = my_ports[0])
c.add_streams(s4, ports = my_ports[1])

# start traffic with limit of 10 seconds (otherwise it will continue forever)
# bi direction
testduration = 10
c.start(ports=[my_ports[0], my_ports[1]], duration=testduration)
# hold until traffic ends
c.wait_on_traffic()

# check out the stats
stats = c.get_stats()

# get global stats
totalstats = stats['global']
totaltx = round(totalstats.get('tx_bps'))
totalrx = round(totalstats.get('rx_bps'))
print('Transmit: {}MByte/s Receive: {}MByte/s'.format((totaltx / 1000000), (totalrx / 1000000)))
c.clear_stats(ports = [my_ports[0], my_ports[1]])

# get flow stats
totalstats = stats['flow_stats']
stream1 = totalstats[1]

stream2 = totalstats[2]
stream3 = totalstats[3]
stream4 = totalstats[4]
totaltx_1 = stream1.get('tx_pkts')
totalrx_1 = stream1.get('rx_pkts')
print('Stream 1 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_1['total'] / testduration * packet_size * 8),
(totalrx_1['total'] / testduration * packet_size * 8)))
totaltx_2 = stream2.get('tx_pkts')
totalrx_2 = stream2.get('rx_pkts')
print('Stream 2 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_2['total'] / testduration * packet_size * 8),
(totalrx_2['total'] / testduration * packet_size * 8)))
totaltx_3 = stream3.get('tx_pkts')
totalrx_3 = stream3.get('rx_pkts')
print('Stream 3 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_3['total'] / testduration * packet_size * 8),
(totalrx_3['total'] / testduration * packet_size * 8)))
totaltx_4 = stream4.get('tx_pkts')
totalrx_4 = stream4.get('rx_pkts')
print('Stream 4 TX: {} Bit/s RX: {} Bit/s'.format((totaltx_4['total'] / testduration * packet_size * 8),
(totalrx_4['total'] / testduration * packet_size * 8)))
except STLError as e:
print(e)

finally:
c.disconnect()

 

Fazit

Bei der Vorbereitung dieses Tutorials für Habr haben wir einen Prüfling (DUT) mit 4 Threads konfiguriert und getestet, Thread-Informationen gesammelt und globale Statistiken erstellt.

Das oben beschriebene Beispiel benutzt zur Ausführung Python, um das Testen und Debuggen von Netzwerkgeräten und Softwareprodukten mit TRex automatisieren können - in einer Schleife oder durch sequentielle Ausführung von Tests in Python.

Ist Cisco TRex also besser oder schlechter als andere ähnliche Traffic-Generatoren? Zum Beispiel das beliebte Client-Server-Programm iperf? Im Anwendungsfall TRex wurde das Einrichten und Arbeiten mit Datenflüssen beschrieben. Beide Test- und Debugging-Tools haben ihre Stärken: iperf eignet sich für schnelle Funktionsprüfungen im laufenden Betrieb, während TRex bei der Automatisierung von Tests und der Entwicklung komplexer Netzwerkgeräte und -systeme hervorragende Dienst leistet. TRex bietet sich für Aufgaben an, bei denen die Konfiguration von Multithreading-Streams wichtig ist, um jeden Datenfluss für eine bestimmte Aufgabe zu konfigurieren und die Ausgabeergebnisse zu analysieren.

TRex ermöglicht die Erstellung von Vorlagen für nahezu jede Art von Datenverkehr und deren Erweiterung zur Generierung groß angelegter DDoS-Angriffe, einschließlich TCP-SYN-, UDP- und ICMP-Streams. Durch die Möglichkeit, massive Verkehrsströme zu erzeugen, können Sie Angriffe von verschiedenen Clients auf mehrere Zielserver simulieren.

Wenn Sie dieses Tool noch nicht ausprobiert haben, sollten Sie es sich unbedingt ansehen.

 

Unsere Projekte

 

Industrielle Schalter Wir haben eine neue Produktlinie von 1-Gbit / 10-Gbit / s-Ethernet-Switches entwickelt, die in einem industriellen Temperaturbereich (–20 bis + 70 ° C) arbeiten.

AI application for set-top box: searching and buying products from video streaming

KI App für In-Video-Shopping Wir haben auf STBs die erste KI-Anwendung entwickelt und installiert, mit der Sie Kleidung direkt aus dem Videostream suchen und kaufen können

digital signal processing module for wireless communication systems

DSP + FPGA platform Wir haben eine Plattform mit einer offenen Architektur für drahtlose Kommunikationssysteme entwickelt, die auf der SDR-Technologie basiert

A model range of industrial managed gigabit switch equipment with 8 and 16 ports
Industrieschalter L2 Wir haben Referenzdesigns für industriell verwaltete Switches mit 10Gbase-X- und 10/100 / 1000Base-T-Ports erstellt
Network traffic analyzer with Bypass function
BYPASS Network Analyzer Wir haben Prototypen eines Netzwerkverkehrsanalysators zum Einstellen einer Netzwerkverbindungslücke erstellt (BYPASS-Funktion).
a series of managed 16- and 24-port Gigabit switches based on Realtek 83xx chipset
L2-Switch mit PoE-Unterstützung Das Promwad-Entwicklungsteam entwickelte einen benutzerdefinierten verwalteten L2-Switch, der auf dem Realtek 83xx-Chipsatz und dem Linux-Kernel basiert
DECT base station, VolP gateway, WiFi router, Office PBX, Server
Modem 7-in-One-Gerät Wir haben einen fortschrittlichen VoIP-Modem-Router entwickelt und für die Massenproduktion vorbereitet, der alle Arten von Bürokommunikation bietet
we developed a specialized Embedded Linux distribution for routers and other network devices

OpenWRT für RealtekWir haben eine spezielle Embedded Linux-Distribution für Router und eine anpassbare Weboberfläche entwickelt, um LuCi-basiert zu verwalten

VoIP broadband router design
VoIP-Breitbandrouter Unsere Ingenieure haben einen Teilnehmer-Router für die Bereitstellung von Voice-over-IP-Diensten in Breitbandnetzen entwickelt
we created a reference design of a set-top box DVB-T/C + IPTV, which is intended for rapid platform development and launch of a series of new digital devices
IPTV + T / C Hybrid-Set-Top-Box Wir haben ein Referenzdesign für eine Set-Top-Box mit schneller Plattformentwicklung und Einführung einer Reihe neuer digitaler Geräte erstellt
promwad have designed a digital IPTV STB with DVB-T and DVB-S/S2 support, based on the SMP8654 processor by SigmaDesigns

IPTV STB mit DVB-T / S / S2Wir haben eine digitale IPTV-STB mit DVB-T- und DVB-S / S2-Unterstützung entwickelt, die auf dem SMP8654-Prozessor von SigmaDesigns basiert

we have developed a computer for networks with a client-server architecture that transfers basic processes to a remote server

AK1100 thin clientWir haben ein neues schlüsselfertiges Produkt entwickelt, den AK1100 Thin Client, der auf dem Prozessor Marvell Sheeva 88F6282 basiert

IPTV STB design for SmartLabs
SmartLabs IPTV set-top box Wir haben eine Reihe von IPTV-Set-Top-Boxen entwickelt, die eine Lizenzabdeckung für alle proprietären Codierungsstandards für Audio und Video gewährleisten
we developed a video registration device for digitalization, storage and distribution of audio and video streams on request from 4 analogue sources

JPEG2000 4-Kanal-RecorderAuf Anfrage haben wir ein Videoregistrierungsgerät zur Speicherung und Verteilung von Audio- und Videostreams aus 4 analogen Quellen entwickelt

we developed a multifunction mini-server for solving a wide range of tasks in IP networks, functions as a computer or a server

IP-Plug ARM Mini-ServerWir haben den Multifunktions-Miniserver entwickelt, um eine Vielzahl von Aufgaben in IP-Netzwerken zu lösen, die als Computer oder Server fungieren