Einer unserer Kunden machte uns darauf aufmerksam, dass es möglicherweise Paketverluste im Hochschulinternen Rechnernetz (HIRN) gibt. Das Szenario stellte sich wie folgt dar: Der Monitorserver des Kunden sendet ICMP echo requests an viele Zielrechner und wertet dann die Antworten aus. Das Fehlerbild ergab erst einmal kein Muster, da eine Vielzahl von Zielen mit unterschiedlichen Fehlerraten betroffen waren.
Wir mussten jetzt also die Frage klären wo, wann und warum diese Fehler auftreten. Da sich der Quellrechner im Datacenter befindet, sind wir in der Lage mittels ERSPAN den Datenverkehr direkt an einem Switchport zu analysieren.
ERSPAN steht für „Encapsulated Remote Switched Port Analyzer“ und man ist damit in der Lage den zu analysierenden Datenverkehr an eine beliebige Stelle zu transportieren und zentral zu analysieren.
Auf dem Analyserechner wird als erstes das packet-capture gestartet und alles eingesammelt, was GRE-gekapselt ist:
tcpdump -i vtnet0 -n -C 2000 -w case-4711 "ip proto 0x2f"
Da auf der Quellseite wenig Filtermöglichkeiten bestehen, werden die gesammelten Daten in 2-Gigabyte-Blöcke aufgeteilt und später gefiltert.
Die Quelle ist ein physischer Server, der direkt an einen Switch des HIRN angeschlossen ist. Dort wird eine ERSPAN-Quelle eingerichtet:
monitor session 1 type erspan-source description analyze-case-4711 erspan-id 30 vrf default destination ip 192.168.2.227 source interface port-channel51 both
Für einen der Tests wurde die Monitor-Session für 2 Stunden aktiviert. Aus den gesammelten Daten werden alle Pakete entfernt, die nicht ICMP oder ICMPv6 enthalten und dann in einem packet-capture zusammengefasst:
for f in case-13* ; do tshark -r $f -w tmp_$f -Y "icmp or icmpv6"; done mergecap -w case-13-icmp.pcap tmp_case-13* rm tmp_case-13*
Aus dem resultierenden packet-capture sucht man sich jetzt alle ICMP echo requests heraus und ermittelt (via IP/ID/SEQ) zu jedem das passende echo reply. Die Nutzung von tshark hat hier zwei entscheidende Vorteile:
Zum einen entpackt tshark bei der Ausgabe auf STDOUT das GRE und das ERSPAN und zeigt direkt das Original-Paket von der Quelle an und zum anderen erledigt es auch gleich die Arbeit der o.g. Zuweisung von echo request zu echo reply. Eine Ausgabe sieht bspw. so aus:
1229 1658404789.430723 2001:db8:e:edd1::34:133 → 2001:db8:9:edd0::232:204 ICMPv6 180 Echo (ping) request id=0xa669, seq=0, hop limit=64 1230 1658404789.430730 2001:db8:9:edd0::232:204 → 2001:db8:e:edd1::34:133 ICMPv6 180 Echo (ping) reply id=0xa669, seq=0, hop limit=63 (request in 1229) 7980 1658404802.744268 10.213.47.146 → 10.213.15.150 ICMP 160 Echo (ping) request id=0xa856, seq=0/0, ttl=64 7983 1658404802.744321 10.213.15.150 → 10.213.47.146 ICMP 160 Echo (ping) reply id=0xa856, seq=0/0, ttl=127 (request in 7980)
Diese Ausgabe wird per Script entsprechend ausgewertet. Damit die Ausgabe übersichtlich bleibt werden folgenden Regeln angewendet:
Damit ergibt sich dann etwa folgendes Bild:
ICMP stats Test 13: Start time: Thu Jul 21 13:59:49 2022 Stop time: Thu Jul 21 15:59:59 2022 # target hosts: 833 # requests: 62152 (65276) # replies: 61618 Ratio: 99.14% (94.40%) Hosts with more than one dropped packet: 2001:db8:9:ed1f::ac8:4604 20/125 84.00% 2001:db8:9:ed1f::ac8:460d 41/125 67.20% 2001:db8:9:ed1f::ac8:4802 95/115 17.39% 2001:db8:9:ed1f::ac8:480b 107/120 10.83% 2001:db8:9:ed1f::ac8:480c 45/130 65.38% 2001:db8:9:ed10::a93:298b 15/125 88.00% 2001:db8:9:ed10::a93:298c 25/130 80.77%
Bis auf sehr wenige Ausnahmen (7 von 833 Hosts) gibt es keine Paketverluste. Die auf dem Monitorserver auftretenden Paketverluste müssen also auf dem Monitorserver selbst passieren. Die Auswertung hat allerdings bei sieben Zielen teilweise massive Paketverluste gezeigt. Hier gilt es jetzt zu ermitteln wo auf dem Weg diese Pakete verloren gehen.
Da es sich in diesem Fall um eine virtuelle Maschine in einer VMware-Umgebung handelt kommen wir nicht so „nah“ an das Ziel wie bei einer physischen Maschine. Ausserdem hat die VMware-Umgebung zwei Standorte und damit zwei Anbindungen an das HIRN. Auf den Switches mit den VMware-Anbindungen wird wie oben beschrieben auch jeweils eine ERSPAN-Session eingerichtet, diesmal mit den IDs 32 und 33 und dann der Sammler und alle drei Sessions gestartet. Das Ergebnis erhält man schlußendlich in case-14-icmp.pcap.
In dieser Datei sind jetzt noch alle drei Monitor-Sessions enthalten. Für eine Auswertung teilen wir diese auf. Da es aktuell irrelevant ist, in welchem Teil der VMware-Umgebung sich der Zielhost befindet, teilen wir unser pcap in zwei Teile auf:
tshark -r case-14-icmp.pcap -w case-14-icmp_src.pcap -Y "erspan.spanid == 30" tshark -r case-14-icmp.pcap -w case-14-icmp_dst.pcap -Y "erspan.spanid != 30"
Wirft man diese beiden Paketmitschnitte dem Auswertungsscript vor, erhält man folgendes Bild:
ICMP stats (test 14: tap at source): Start time: Sun Jul 24 12:56:37 2022 Stop time: Sun Jul 24 13:20:02 2022 # target hosts: 837 # requests: 27408 (28318) # replies: 27342 Ratio: 99.76% (96.55%) Hosts with more than one dropped packet: 10.160.233.249 28/32 12.50% 192.168.85.135 28/32 12.50% 2001:db8:9:ed1f::ac8:460d 13/25 48.00% 2001:db8:9:ed1f::ac8:4802 21/25 16.00% 2001:db8:9:ed1f::ac8:480b 16/20 20.00% 2001:db8:9:ed1f::ac8:480c 10/25 60.00% 2001:db8:9:ed10::a93:298b 5/25 80.00% --------------------------------------------------- ICMP stats (test 14: tap at destination vlan): Start time: Sun Jul 24 12:56:41 2022 Stop time: Sun Jul 24 13:19:59 2022 # target hosts: 64 # requests: 1029 (1900) # replies: 1009 Ratio: 98.06% (53.11%) Hosts with more than one dropped packet: 2001:db8:9:ed10::a93:298b 5/25 80.00%
Auch diese Auswertung bestätigt, dass der Paketverlust nicht im HIRN stattfindet, sondern entweder in der Netzwerkinfrastruktur der VMware-Umgebung oder im Zielhost selbst.