README.md

Cisco ThousandEyes

Das Ziel der ThousandEyes (1000) deployments ist es, Messungen über das Netzwerk durchführen zu können. Zu diesem Zweck gibt es mehrere Möglichkeiten, etwa Endpoint Agents, Enterprise Agents und Cloud Agents. Ihr Einsatzbereich unterscheidet sich. Etwa wird der Endpoint Agent wirklich beim End User installiert, der Cloud Agent werden in der Cloud installiert.

Enterprise Agents

Konkret geht es hier um Enterprise Agents, für welche die Turris MOX Systeme eingesetzt werden sollen. Diese werden im Netzwerk verteilt, um wirklich vor Ort nützliche Informationen sammeln zu können. Schlussendlich hat sich eine Installation auf den Turris MOX Systemen als nicht praktikabel herausgestellt, dafür aber wurde ein Enterprise Agent auf dem Privatrechner und einem Cisco C9300 Switch aufgesetzt.

Ergebnisse

Ein paar Tests auf der ThousandEyes Plattform haben sich durchführen lassen. Dafür wurden Cloud Agents (e.g. Austria/Vienna, Czech Republic/Prague, Germany/Berlin, New York/NY), aber auch Enterprise Agents mit BrowserBot (thinkpad-test) oder ohne (thousandeyes0) eingesetzt.

Hier ist thinkpad-test der Name des Privatrechners und thousandeyes0 der hostname des Switch.

Test 1: TISS DNS Test

Test 2: Sekundärer interner DNS Server (128.131.4.3)

Test 3: HTTP Server Test (www.tu-wien.ac.at)

Test 4: Netzwerk Test (www.tuwien.ac.at)

Installation Cisco C9300 Switch

hostname: thousandeyes0

password: Yearly2overture5repost9upfront

Im Grunde ist eine Installation auf dem Switch entsprechend der online Dokumentatation oder gleich auf der app.thousandeyes.com Plattform beschrieben.

Die Vorraussetzungen sind, dass der Switch eine entsprechende Netzwerkkonfiguration hat. Konkret wird auf der Cisco Catalyst 9k Series App Plattform ein Docker container hinzugefügt. Für die Installation benötigt man, um sich von der ThousandEyes Plattform die notwendigen Dateien zu holen:

• Zugang zu app.thousandeyes.com
• eine funktionierende und online Netzwerkverbindung am Switch
• aktivierte und funktionierende Lizenz (DNA advantage)
  • zu aktivieren nachdem Internetzugriff verfügbar ist durch: license boot level network-advantage addon dna-advantage

Sollte das richtige Installation Target auf der ThousandEyes Plattform ausgewählt sein, dann sollte eine Reihe an Befehlen angeführt werden die sich kopieren lassen. Je nachdem, wie der Internetzugang konfiguriert ist und durch welche VLANs der app traffic erlaubt sein soll, muss man das virtuelle Interface (e.g. AppGigabitEthernet1/0/1) so konfigurieren, dass die Applikation selbst auch wirklich einen Internetzugang hat. Ohne Internetzugang kann die Applikation nicht synchronisieren.

Cisco C9300 Switch App Konfiguration

In Folge lässt sich einsehen, mit welcher Konfiguration der ThousandEyes Enterprise Agent getestet wurde.

app-hosting appid c9300_test
 app-vnic AppGigabitEthernet trunk
  guest-interface 0
 app-default-gateway 128.130.15.129 guest-interface 0
 app-resource docker
  prepend-pkg-opts
  run-opts 1 "-e TEAGENT_ACCOUNT_TOKEN=jvlpclflwbnkud939l5xggsg63sgwr69"
  run-opts 2 "--hostname thousandeyes0"
 name-server0 128.130.4.3
 name-server1 128.131.4.3
 start
app-hosting appid guestshell
 app-vnic management guest-interface 0
 start

Turris MOX Untersuchung Installationsmöglichkeiten

Anfänglich wurden keine besseren Installationsmöglichkeiten identifiziert, als die entsprechenden Binaries aus dem Raspberry Pi 4 Image zu entnehmen und an die richtige Stelle zu platzieren.

Image Durchsuchung

Genug Speicherplatz sollte vorhanden sein (komprimiert 1.6 GB, unkomprimiert 4.3 GB).

image=thousandeyes-pa-*.rpi4.img

# prepare for mount
fdisk -l "$image" # important: look for linux partition start sector as well as the amount of bytes per sector
sectorbytes=512   # from fdisk output, change if necessary
start=526336      # from fdisk output, change if necessary

# perform actual mount
sudo mkdir -p /mnt/img
sudo mount -v -o offset=$(echo "$sectorbytes * $start" | bc) -t ext4 "$image" /mnt/img/

# if everything worked correctly, you are now free to explore the mounted image
cd /mnt/img
sudo find | grep -i thousandeyes

Durch inspizieren des Image stellt sich heraus, dass das offizielle Package repository für ThousandEyes für jeweils x86 als auch aarch64 unter http://apt.thousandeyes.com/ zu finden ist. Speziell befinden sich viele te-* Packages unter http://apt.thousandeyes.com/pool/main/t/te-agent/ welche alle Teil von dem ThousandEyes Angebot sind.

Untersuchung Debian Packages

Die Debian Packages können auch inspiziert werden, wie etwa te-agent Version 1.209.0 (aarch64). Dabei lassen sich Debian Packages wie folgt öffnen:

ar x te-agent_*arm64.deb
tar --use-compress-program=unzstd -xvf control.tar.zst
tar --use-compress-program=unzstd -xvf data.tar.zst

Das Debian Package enthält bereits die vorgesehene file structure. Daher sollte eine erfolgreiche Installation der Packages möglich sein mithilfe von 2 Schritten:

• Installation aller dependencies wie sie stehen im file control (aus control.tar.zst)
• Replikation der file structure, mit Rücksicht auf etwa /usr, /var, /etc, /lib sowie Nichtvorhandensein von systemd am Zielsystem

Unklar ist, welche Packages notwendig sind, ob alle dependencies installiert werden können auf OpenWRT und was genau notwendig ist, um einen Enterprise Agent in ThousandEyes einzupflegen.

*.deb zu *.ipk

Das verwendete Format des opkg package manager von OpenWRT ist das sogenannte ipk Format. Das Format ist nicht exakt das selbe wie ein deb (Debian) package, aber da das ipk Format vom deb Format abgeleitet worden ist sind sie nahezu ident. Es ist möglich sie zu konvertieren, jedoch gibt es viele Tücken die es zu beachten gilt.

Ein repository für einfache conversion scripts wurde angelegt auf TU gitlab. Andere Scripts lassen sich ebenso finden, wie in dem ipkg-utils repository auf github, aber diese scheinen für unterschiedliche Versionen desk ipk Formats ausgelegt zu sein. Ganz unabhängig was verwendet wird, die Wahrscheinlichkeit auf Probleme zu stoßen die man mühselig manuell behandeln muss ist sehr hoch.

Bisher scheint es noch keinen besseren Weg zu geben, als Debian packages auf diese Art und Weise zu missbrauchen. Die Packages heißen teilweise zwischen Debian und OpenWRT anders, was die dependency resolution unmöglich macht. Um die Packages dennoch zu installieren, muss man entweder die Debian package names abbilden können auf die OpenWRT package names, oder dependencies gleich komplett ignorieren indem aus dem control file innerhalb des Package die dependency list leer gesetzt wird. Wenn man die dependencies entfernt um die dependency resolution zu überspringen, muss selbstverständlich jede dependency manuell aufgesucht, die Versionen abgeglichen und zusammen aufgesetzt werden. Ein weiteres Problem ist dass die file structure Unterschiede zwischen Debian und OpenWRT dazu führen, dass Dateien wie etwa libraries nicht unbedingt dort landen so sie landen sollten.

Der große Vorteil, sollte dieser Prozess automatisiert werden, wäre ein Vorhandensein eines Prozess mit welchem Debian packages eingespielt werden können. Vorallem ließe sich dieser Prozess wiederholen, wenn es etwa Updates zum ThousandEyes Enterprise Agent gibt.

(update 18.3.) Nach weiteren Versuchen die Debian packages zu installieren, stellt sich heraus, dass Turris MOX Geräte und OpenWRT musl als C library verwenden und dass die Debian packages, die eine hard dependency auf glibc haben, generell ABI-incompatible sind und vermutlich nie zum laufen gebracht werden können. Nicht nur hat te-agent selbst eine hard dependency auf glibc, sondern auch dependencies auf libraries wie etwa libssl3, welche selbst stark auf glibc angewiesen ist.

An dieser Stelle sollte entweder ThousandEyes dazu angeregt werden, OpenWRT builds anzustreben, da nur mit Zugriff zum source code und neuen builds eine entsprechende binary produziert werden kann. Oder andere targets müssen gewählt werden.

Laptop Installation

Nachdem ein Deployment auf Turris MOX sich als praktisch unmöglich herausstellt, solange kein Support für musl basierte ARMv8 Systeme bereitgestellt wird, wurde ein ThousandEyes Enterprise Agent deployment auf einem Privatrechner versucht. Eine gute Option für derartige Installationen ist Docker. Durch Docker findet kein tieferer Eingriff in das System statt und distributions welche nicht offiziell unterstützt werden können benutzt werden, aber das Zielsystem muss auch über entsprechend mehr Hardwareressourcen verfügen.

Dabei muss lediglich auf app.thousandeyes.com ein Enterprise Agent hinzugefügt werden. Beim Hinzufügen werden mehrere Optionen angeboten, daraus lässt sich Docker aussuchen und nach Eingabe der Parameter für den Enterprise Agent lassen sich die Befehle problemlos kopieren und der Agent läuft dann bereits. Im Grunde wird hier in die zu kopierenden Befehle bereits ein token inkludiert, mithilfe dessen ThousandEyes ermitteln kann, um welchen Enterprise Agent es sich hier handelt und welche Tests durchzuführen sind.

Turris MOX Inbetriebnahme

Die Inbetriebnahme ist entsprechend der Anleitung von Ondrej Hosek durchführbar. Eventuell gibt es leichte Abweichungen je nachdem was tatsächlich konfiguriert werden soll.

Überblick

Das Turris MOX hat einen WAN Port über das SFP Modul und einen LAN Port neben dem Stecker für die Stromversorgung. Über den LAN Port soll der Turris MOX mit dem "neuen" servicenet verbunden werden. Der WAN Port wurde vorerst im Büro an eine Buchse angehängt.

LAN (servicenet) 192.168.53.2/23 (255.255.254.0)

WAN (TP-DF0324-12) 128.130.15.135/25 (255.255.255.128)

Passwörter

hostname: turrisp1

root: flop5ardently9cheek3turban

web: unlined8moonlike4uncurious1groovy

Turris MOX D (SFP module)

Dabei sollte der Turris MOX in Konfiguration D aufgesetzt werden, nämlich mit einem zusätzlichen SFP Port. Normalerweise würde an der Stelle ein optisches SFP Modul eingesetzt werden. Für die Konfiguration im Zuge des Praktikums wurde das Turris MOX über ein Kupfer SFP Modul aufgesetzt. Dabei stellt sich heraus, dass TurrisOS erst ab gewissen TurrisOS Versionen SFP Module unterstützt, etwa das Kupfermodul mit TurrisOS 5.2+ (https://wiki.turris.cz/en/public/sfp). Die out of the box TurrisOS Version ist TurrisOS 4.0.

ping-exporter

Bei ping-exporter verfolgt man genau die Anleitung. Daher, man installiert ping-exporter über den Befehl opkg install ping-exporter.ipk. Dabei sollte bei der Installation ein Service angelegt werden unter /etc/init.d/ping-exporter sowie eine Konfiguration unter /opt/ping-exporter/config.toml und die ARM aarch64 binary unter /opt/ping-exporter/ping-exporter.

Verwendung

Wenn ping-exporter entsprechend den eigenen Anforderungen konfiguriert wird, lässt sich das Programm verwenden, um über HTTP requests Statusinformationen zu ping output, tcp exchanges und dns queries abzufragen.

Vom Turris MOX ausgehend lässt sich eine Abfrage wie folgt durchführen:

curl http://localhost:9099/ping_exporter/ping?target=128.130.228.40

Wichtig ist, dass die targets der Statusabfrage in der whitelist stehen.

Netzwerk Konfiguration

cat /etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd15:9abf:b55a::/48'

config interface 'wan'
        option ifname 'eth1'
        option proto 'static'
        list dns '128.130.4.3'
        list dns '128.131.4.3'
        option ipaddr '128.130.15.134'
        option netmask '255.255.255.128'
        option gateway '128.130.15.129'
        option name 'tp-df0324-13'
        option disabled '0'

config interface 'lan'
        option type 'bridge'
        option macaddr 'd8:58:d7:00:b6:8b'
        option ifname 'eth0 '
        option proto 'static'
        option ip6assign '60'
        option _turris_mode 'unmanaged'
        option netmask '255.255.254.0'
        list dns '192.168.34.30'
        list dns '192.168.34.31'
        option ipaddr '192.168.53.2'

Firewall Konfiguration

Die Firewall Konfiguration passiert ebenso entsprechend der bestehenden Anleitung.