Zum Inhalt

Elina Traffic Generator (Elina-TG)

Einführung

Elina Traffic Generator (elina-tg) ist ein leistungsstarkes Befehlszeilenwerkzeug zur Verkehrserzeugung, mit dem sich eine Vielzahl von Anwendungs- und Netzwerkverhalten simulieren lässt. Es kann mehrere gleichzeitige TCP-, UDP- und RTP-Verkehrsströme mit hochgradig konfigurierbaren Parametern erzeugen, darunter Paketgröße, variable Raten, IPv4/IPv6, QoS-Markierungen (DSCP) sowie ausgefeilte und anpassbare Nutzlasten.

Dashboard

Elina-TG kann als eigenständiges Werkzeug für Netzwerktests und QoS-Validierung verwendet werden. Es kann auch neben dem LatenceTech QoS-Agent auf demselben Netzwerkpfad laufen: Elina-TG erzeugt eine anwendungsähnliche Last, während der Agent Latenz, Jitter und Verlust in den Dashboards des Analyzer misst.

Dashboard

Funktionsweise

Elina-TG arbeitet nach einem Client/Server-Modell. Eine „Client“-Instanz liest eine Konfigurationsdatei für die Ströme und sendet Verkehr, während eine „Server“-Instanz diesen Verkehr empfängt, wichtige Metriken wie Paketverlust und Jitter misst und die Ergebnisse aufzeichnet. Das Werkzeug kann in den Modi client, server oder both (für einfache Loopback-Tests auf einer einzelnen Maschine) betrieben werden. Es enthält außerdem einen leistungsstarken Modus schedule zur Orchestrierung komplexer zeitbasierter Testsequenzen sowie einen Modus aggregate zum Zusammenführen der Statistiken mehrerer Läufe.

Konfiguration

Das Release-Paket ist ein eigenständiges Linux-Binary (plus Konfigurationen und Dokumentation). Eine Python-Installation ist nicht erforderlich.

Systemanforderungen:

  • Linux x86_64
  • GLIBC 2.35 oder neuer (z. B. Ubuntu 22.04+ / Debian 12+). Ältere Hosts wie Ubuntu 20.04 (GLIBC 2.31) können das Binary nicht ausführen.

1. Werkzeug herunterladen und entpacken:

wget https://api.latence.ca/software/elina-tg.zip
unzip elina-tg.zip
cd elina-tg-release

2. Binary prüfen:

./elina-tg --help

Rufen Sie ./elina-tg immer aus dem Verzeichnis elina-tg-release auf (es wird nicht zu Ihrem PATH hinzugefügt).

Betriebsmodi

1. Ein einfacher Loopback-Test (Erste Schritte) Dies ist der beste Weg, Ihre Installation zu überprüfen. Dabei laufen Client und Server 15 Sekunden lang auf Ihrer lokalen Maschine.

# Test im ausführlichen Modus ausführen und Ergebnisse speichern
./elina-tg both --duration 15 -v --stats_file meine_ersten_testergebnisse.json

Nach dem Lauf wird eine lesbare Zusammenfassung auf der Konsole ausgegeben, und detaillierte JSON-Statistiken werden in der angegebenen Datei gespeichert.

2. Ein Client/Server-Test (Zwei Maschinen) Dies simuliert Verkehr über eine echte Netzwerkverbindung.

  • Auf der Server-Maschine (zum Beispiel IP 192.168.1.101): Starten Sie den Server, um den in der Basis-Konfigurationsdatei definierten Verkehr zu empfangen.
./elina-tg server --config configs/basic/flows_config_basic.json --listen_ip 0.0.0.0 -v
  • Auf der Client-Maschine: Senden Sie 60 Sekunden lang Verkehr an den Server.
./elina-tg client --config configs/basic/flows_config_basic.json --dest_ip 192.168.1.101 --duration 60 -v

3. Planungsmodus (Automatisierte Testsequenzen) Dieser Modus führt eine Reihe von Client/Server-Aktionen aus, die in einer Planungsdatei definiert sind. Er eignet sich ideal, um komplexe, zeitlich veränderliche Verkehrsmuster zu emulieren.

# Die vordefinierte E-Gaming-Simulation nach ITU-T G.1051 ausführen
./elina-tg schedule --schedule_config configs/itu_g1051_egaming/schedule_config_egaming_g1051.json -v

Befehlszeilenreferenz

./elina-tg <mode> [options]

Modi

  • client — Verkehr aus einer Strömungskonfiguration erzeugen.
  • server — Verkehr empfangen und Statistiken sammeln.
  • both — Client und Server zusammen ausführen (Loopback / Tests auf einem Host).
  • schedule — Eine zeitgesteuerte Sequenz aus einer Planungskonfiguration ausführen (JSON oder CSV).
  • aggregate — Mehrere JSON-Statistikdateien zu einem Bericht zusammenführen.

Häufige Optionen

  • --config FILE — JSON-Strömungskonfiguration (Standard: configs/basic/flows_config_basic.json).
  • --dest_ip IP — Ziel-IP des Clients (Standard: 127.0.0.1).
  • --listen_ip IP — Empfangs-IP des Servers (Standard: 0.0.0.0).
  • --base_port PORT — Basisport der Ströme; jeder Strom verwendet base_port + index, sofern nicht überschrieben (Standard: 5000).
  • --duration SECONDS — Sendedauer des Clients (Standard: 10).
  • --stats_file PATH — JSON-Statistiken schreiben. Bei Angabe eines einfachen Dateinamens wird ein UTC-Zeitstempel angehängt.
  • --stats_interval SECONDS — Alle N Sekunden eine Live-Statistikmomentaufnahme anzeigen (0 = deaktiviert).
  • --ipv6 — IPv6 erzwingen (wird auch automatisch aktiviert, wenn in --dest_ip / --listen_ip eine IPv6-Adresse erkannt wird).
  • -v / -vv — Ausführliche / Debug-Protokollierung. -q — Still.
  • --version — Version anzeigen und beenden.

Planung und Zeitsynchronisierung

  • --start_at DATETIME — Client zu einer bestimmten Uhrzeit starten (ISO 8601 UTC empfohlen, z. B. 2025-08-27T14:30:00Z).
  • --schedule_config FILE — Planungsdatei für den Modus schedule (.json oder .csv).
  • --check_time_sync — Uhrensynchronisierung (NTP und/oder benutzerdefinierte Synchronisierung) vor dem Start prüfen.
  • --time_sync_port_offset OFFSET — Port-Versatz relativ zu base_port für den Synchronisierungsdienst (Standard: -1).
  • --time_sync_threshold SECONDS — Maximal zulässige Uhrenabweichung (Standard: 1.0).
  • --ntp_server_host HOST — Abzufragender NTP-Server (Standard: pool.ntp.org).

Modus aggregate

  • --inputs FILE [FILE ...] — Zusammenzuführende JSON-Statistikdateien.
  • --output FILE — Pfad des aggregierten Berichts (Standard: aggregate_report.json).
./elina-tg aggregate --inputs run1.json run2.json --output campaign_report.json

Referenz der Strömungskonfiguration

Strömungskonfigurationen sind JSON-Objekte. Jeder Schlüssel der obersten Ebene ist eine eindeutige Flow-ID. Ports werden als base_port + flow_index zugewiesen, sofern dest_port_override nicht gesetzt ist. Ein JSON-Schema ist unter configs/schemas/flow-config.schema.json für die Validierung im Editor verfügbar.

Minimales kommentiertes Beispiel (configs/basic/flows_config_basic.json):

{
  "F1_UDP_SIMPLE": {
    "protocol": "UDP",
    "size": 128,
    "rate": 10,
    "type": "BASIC_UDP_PAYLOAD",
    "dscp": 0
  },
  "F2_TCP_SIMPLE": {
    "protocol": "TCP",
    "size": 512,
    "rate": 5,
    "type": "BASIC_TCP_STREAM",
    "concurrent_connections": 5,
    "enable_keepalive": true,
    "start_delay_seconds": 1
  },
  "F3_RTP_AUDIO_SIM": {
    "protocol": "RTP",
    "size": 172,
    "rate": 50,
    "type": "SIMPLE_AUDIO_SIM",
    "dscp": 46,
    "rtp_config": {
      "payload_type": 96,
      "ssrc": "auto",
      "media_clock_rate": 8000,
      "simulated_media_rate": 50
    }
  }
}

Gemeinsame Parameter

  • protocol (erforderlich) — "UDP", "TCP" oder "RTP".
  • size (erforderlich) — Zielgröße des Pakets in Bytes.
  • rate — Statische Pakete pro Sekunde. Verwenden Sie 0 für maximale Geschwindigkeit. Wird ignoriert, wenn rate_profile oder rate_control gesetzt ist. Eines von rate, rate_profile oder rate_control ist erforderlich.
  • type — Benutzerdefinierte Zeichenkette, die zur Identifikation in die Nutzlast eingebettet wird.
  • start_delay_seconds — Verzögerung, bevor dieser Strom zu senden beginnt.
  • dest_port_override — Den automatisch zugewiesenen Zielport ersetzen.
  • dscp — DSCP-Wert (0–63) für die IP-QoS-Markierung.

Ratensteuerung

  • rate_profile — Array von Phasen { "rate", "duration_seconds" }. Ersetzt rate.
  • rate_control — Granulare Steuerung; ersetzt rate und rate_profile:
    • Burst: "mode": "burst" mit packets_per_burst, rate_in_burst_pps, pause_between_bursts_ms
    • Paketabstand: "mode": "ipg" mit ipg_ms

Nutzlast, TCP und RTP

  • payload_config — mode: "random" (Standard), "pattern" (hex) oder "file". Optional incremental_fields, um Zähler an Byte-Offsets einzubetten.
  • tcp_config — concurrent_connections, enable_keepalive, behavior ("stream" oder "request_response") sowie Größe/Timeout/Serververzögerung für den Anfrage-Antwort-Modus.
  • rtp_config (für RTP erforderlich) — payload_type, ssrc ("auto" oder Ganzzahl), media_clock_rate, simulated_media_rate, optional marker_bit_logic.

Erweiterte Funktionen

Server-Echo (Paketreflexion)

Setzen Sie "server_config": { "behavior": "echo" } für einen UDP- oder TCP-Strom, damit der Server die Pakete an den Absender zurückschickt. Nützlich für Round-Trip-Tests.

./elina-tg both --config configs/features/flows_config_echo.json --duration 15 -v

UDP-Sequenzverfolgung (Verlust / Reihenfolge)

Kombinieren Sie die incremental_fields der Nutzlast mit "server_config": { "sequence_tracking": { "enabled": true, "offset": N, "size": 4 } }. Der Server meldet Schätzungen zu Verlust und Reihenfolgefehlern im Statistik-JSON.

./elina-tg both --config configs/features/flows_config_seq_tracking.json --duration 15 -v

Live-Statistiken

Verwenden Sie --stats_interval N, um während eines Laufs alle N Sekunden eine Statistikmomentaufnahme anzuzeigen.

Modus aggregate

Statistiken aus Kampagnen mit mehreren Läufen oder mehreren Knoten zusammenführen:

./elina-tg aggregate --inputs node_a.json node_b.json --output combined.json

CSV-Planungen

--schedule_config akzeptiert sowohl .csv als auch .json. Das Spaltenlayout finden Sie in configs/features/schedule_example.csv (event_id, action, start_UTC_datetime, start_offset_from_previous_end, params_json).

Ergebnisse lesen

Konsolenzusammenfassung

Am Ende eines Laufs client, server oder both (außer mit -q) zeigt Elina-TG eine Übersichtstabelle an:

  • Client — gesendete Pakete, gesendete Bytes und erreichte Rate pro Strom.
  • Server — empfangene Pakete/Bytes pro Port und mittlerer Jitter (UDP-Ankunftsabstand oder RTP nach RFC 3550, je nach Strom).

Während Läufen client / both außerhalb des stillen Modus wird ein Fortschrittsbalken angezeigt.

JSON-Statistikdatei (--stats_file)

Struktur der obersten Ebene:

{
  "overall_simulation_summary": {},
  "client_flow_details": {},
  "server_port_activity": {}
}
  • overall_simulation_summary — Version, Start-/Endzeiten, IP-Familie und verwendete CLI-Argumente (nützlich für die Reproduzierbarkeit).
  • client_flow_details — Pro Flow-ID: Konfigurationsecho sowie packets_sent, bytes_sent, achieved_rate_pps, achieved_bitrate_bps und Zeitfelder.
  • server_port_activity — Pro Port: empfangene Pakete/Bytes, Anzahl der TCP-Verbindungen, optionale Echo-Zähler, UDP-jitter_stats und RTP-Jitter pro SSRC unter ssrc_data. Bei aktivierter Sequenzverfolgung erscheinen hier auch die Schätzungen zu Verlust/Reihenfolge.

Ausführlichkeitsstufen: -q (nur Fehler), Standard (Info + Zusammenfassung), -v (Detail), -vv (Debug).

Die vollständige Liste der Felder finden Sie in documentation/Statistics_Logs.md im Paket.

Die Bibliothek vordefinierter Profile

Elina-TG enthält im Verzeichnis configs/ eine umfangreiche Bibliothek von Simulationsprofilen.
Sie müssen sie an Ihre Anwendungsfälle anpassen.
Sie sind nach Kategorien geordnet:

  • /basic — Einfache Konfigurationen für den Einstieg (Standardströme + minimale Planung).
  • /features — Demos erweiterter Funktionen (Nutzlasten, Burst/IPG, Echo, Sequenzverfolgung, TCP/UDP/RTP-Varianten, Beispiel für eine CSV-Planung).
  • /ipv6 — Beispiele für IPv6-Ströme (und Dual-Stack).
  • /iot — IoT-ähnliche Muster (z. B. Heartbeat eines Wasserzählers und periodische Statistiken über eine Planung).
  • /teams & /zoom — Emulierter Videoanrufverkehr von Microsoft Teams und Zoom mit realistischen QoS-Markierungen.
  • /itu_g1051_egaming — Planerbasierte E-Gaming-Simulation nach ITU-T G.1051.
  • /itu_g1051_dronecontrol — Stark asymmetrischer Steuerungsverkehr für ferngesteuerte Drohnen (Uplink des Piloten + Video-Downlink).

Ausführliche Anleitungen zur Verwendung dieser erweiterten Profile finden Sie in den Leitfäden simulating-*.md im jeweiligen Verzeichnis. Eine Übersicht aller Konfigurationen steht außerdem in configs/README-configs.md.

Ergebnisse in den LatenceTech-Dashboards anzeigen

Elina-TG verbindet sich weder mit dem QoS-Agent noch mit dem Analyzer. Betreiben Sie es neben einem Agent, der bereits denselben Netzwerkpfad misst: Erzeugen Sie eine bestimmte Anwendungslast (zum Beispiel ein Zoom- oder Gaming-Profil) und beobachten Sie, wie sich Latenz, Jitter und Paketverlust in Echtzeit in den Dashboards des Analyzer entwickeln.

Wichtige Hinweise

  • Linux / GLIBC: Das Release-Binary erfordert GLIBC 2.35+ (Ubuntu 22.04 oder neuer). Auf älteren Systemen erscheint ein Fehler wie version 'GLIBC_2.35' not found.
  • Berechtigungen für DSCP/QoS: Auf manchen Systemen erfordert das Setzen von DSCP-Werten erhöhte Rechte (z. B. sudo ./elina-tg ...).
  • Pfade des Planers: Achten Sie bei Verwendung des Planers darauf, dass die Pfade flow_config_file in Ihrer Planungsdatei korrekt und relativ zum Stammverzeichnis des Projekts sind.
  • Ausführliche Dokumentation: Einen vollständigen Überblick über alle Funktionen und das JSON-Schema der Statistiken finden Sie in README.md und documentation/Statistics_Logs.md im Paket.