Rimscout und USA-Reise
Im März 2024 war ich beim MVP Summit 2024 in Redmond bei Microsoft und natürlich hat mein Computer mit Rimscout auch dort Daten gesammelt. Auf dieser Seite stelle ich einige Ergebnisse dieser Woche vor.
Anreise
Ich bin schon am Samstag, den 9.3.2024 mit der Bahn nach Frankfurt gefahren, weil ich den Stress vermeiden wollte, morgens pünktlich zum Abflug um 10:10 zu sein. Mit Park and Rail ist das entspannt, ich kann noch etwas arbeiten und dass aus 3:45 geplante Zeit dann aufgrund dreier Störungen, für die die Bahn wirklich nichts kann, dann 6 Stunden wurden, hat mich nicht weiter gestört. Aber schon die Anreise und die erste Nacht im Hotel hat gezeigt.
Sie sehen in der "Health"-Übersicht gut, dass der PC morgens noch im Home-Office aktiv war und ab ca.17:30 dann die Verbindung "durchwachsen" war. Das WLAN im ICE war zwar gut, was Sie z.B. am DNS-Server-Check gut sehen konnten. Ich habe mir dann noch mal ein paar Details angeschaut und auch hier ist schön zu sehen, dass morgens das Gateway und auch der Exchange Online Endpunkt (Outlook.office.com) superschnell zu erreichen ist.
Während der Fahrt im ICE ist die WiFi-Empfangsstärke konstant bei 87% und auch das Gateway (hellblau) mit 15ms im üblichen Rahmen. Aber die Latenzzeit zu Exchange Online ist mit 263ms natürlich deutlich höher weiterhin schnell zu erreichen. Erst abends im Hotel habe ich dann wieder geringere Latenzzeiten. Die schwächere WLAN-Empfangsstärke (um 81%) hat noch keinen negativen Einfluss aber sie schwankt mehr als im ICE. Im ICE sitzen ja auch die meisten Menschen in ihrem Ort und die Antennen könnten sich über das Dach erstrecken, während im Hotel die APs wohl im Flur verbaut sind und damit mein eigener Körper als auch die von anderen vorbeilaufenden Gästen einen Einfluss haben könnten.
Flug und Bus
Ich habe den Versuchungen widerstanden, im Flugzeug per WLAN online zu gehen und die Daten zu messen. Das hebe ich mir für den nächsten Flug auf. Der Platz ist im Economy-Bereich schon beschränkt. Auch auf dem Wege vom Flugzeug durch die "Immigration Control" und dann per Bus bis zum Hotel habe ich den Notebook nicht aufgemacht. Es beginnt also erst wieder im Hotel.
Microsoft und Hotel
Das nächste Diagramm zeigt meine Aktivitäten über die Woche und den Wechsel zwischen Microsoft Gäste-Netzwerk und Hotel-WLAN. Hier kommt nun natürlich die Zeitzone mit dazu, da Rimscout alle Zeiten zur besseren Vergleichbarkeit auf "UTC" normiert und dann wieder bei der Anzeige die Zeitzone des Browsers nutzt. Da ich in Redmond aber mit UTC-7 (also 8 Stunden hinter Deutschland mit UTC+1) war, sind alle Zeiten noch verschoben.
In der großen Übersicht sehen wir aber im Grund nur, dass die WLAN-Stärke generell gut war aber Teams UDP knapp unter 100ms und Teams TCP sogar über 100ms war. Ich habe dann meine Zeitzone angepasst und eine Tagesansicht generiert:
Am 13. März 2024 habe ich wohl meinen Notebook im Hotel nachts nicht ausgeschaltet, denn er hat bis ca. 07:00 Messdaten erfasst. Tatsächlich habe ich in der Zeit ab ca. 04:00auch gearbeitet, da das Aufstehen durch den Jetlag ja einfach ist (entspricht 12:00 Mittags in Europa) und so die Umstellung nach dem Rückflug weniger stressig ist. Zwischen ca. 07:00 und 08:00 war der Notebook offline (Frühstück, Anfahrt zu Microsoft), ehe der Laptop dann bei Microsoft im Gäste-WLAN und den Vorträgen aktiv war. Hier gibt es dann durch die Pausenzeiten immer mal wieder "Offline"-Phasen. Interessant ist, dass ich im Hotel eine "öffentliche IP-Adresse" ermitteln konnte, die auch auf PING reagierte, während bei Microsoft die öffentliche IP-Adresse nicht per PING erreichbar war.
Interessant sind auch die Einblicke bei der Betrachtung von Latenzzeiten zum Default Gateways, erste Public IP des ISP und dem Microsoft Connection test. Das Hotel-WLAN ist schneller als das Microsoft Gäste-WLAN.
Es gibt anscheinend sogar noch Unterschiede zwischen den Gebäuden. Am eigentlichen WLAN sollte es aber nicht gelegen haben, denn die Empfangsstärke war gut:
Allerdings ist die Latenzzeit des "Default Gateways" bei Microsoft etwas höher als im Hotel. ich würde das schon als Hinweis daran sehe, dass das WLAN deutlich mehr durch die 1500+ MVPs belastet wurde, als ein Hotel mit wenigen Gästen.
Rückreise
Zurück ging es am Samstag, den 16. März 2024 gegen 14:50 von SEATAC nach Frankfurt. Morgens bin ich für meine Verhältnisse sehr früh wieder im Hotel aufgestanden und dann mit einigen anderen MVPs im Bus (RapidRide B und ExpressBus 560) nach Seattle gefahren. In der Zeit war ich mit dem PC "offline" aber am Gate in SEATAC hatte ich dann genug Zeit, sowohl per kostenfreien WLAN (SEATAC) als auch per Tethering mit meinem Smartphone und LTE-Verbindung (Ubigi.com) online zu sein.
Morgens war ich noch im Hotel online und ab ca. 12:15 hieß es sich die Zeit am Gate zu vertreiben. Hier habe ich mich dann zuerst in SEATAC-WLAN eingewählt aber dann den Datenvertrag des Mobiltelefons genutzt. Da waren noch einige GB drauf, die am nächsten Tag sowieso verfallen würden.
Sie sehen quasi kontinuierlich eine WLAN-Signalstärke nahe 100%, was logisch ist, solange das Smartphone direkt neben dem Notebook lag. Auch die Antwortzeit des Default Gateways, was hier ebenfalls mein iPhone als "Default Gateway/NAT-Router" war, überrascht nicht. Der MSConnect-Test (Orange) ist aber schon fast durchgängig über 100ms und auch die die Antwortzeit von Microsoft Teams über UDP (hellblau) ist hoch. Das Stammdatenblatt zeigt mir auch, dass die Exchange Online Verbindung zu "SJC" (Jan Jose, Kalifornien, https://en.wikipedia.org/wiki/San_Jose_International_Airport) geht während der Teams TURN-Service zu "eastus" verweist.
In der Zeit von 12:55 bis 13:00 habe ich die Verbindung auf WLAN (SEATAC) gewechselt und sie sehen sofort die niedrigeren Antwortzeiten und anscheinend einen sehr nahestehenden "Microsoft Network Connectivity"-Endpunkt. Teams kommt zumindest an die 100ms-Marke heran.
Das Teams DataCenter ist weiterhin eastus2 während Exchange Online sich nun aber zu EAT (https://de.wikipedia.org/wiki/Pangborn_Memorial_Airport) verbindet, was deutlich näher ist. Ein Überblick über die in der Zeit per DNS aufgelösten und verwendeten TURN-Server zeigt aber, dass der Client durchaus auch andere Datacenter von Microsoft vorgeschlagen bekommen hat.
Aufgrund der schlechten Latenzzeit hat Rimscout alle vier Server meistens "gelb" gemacht und nur wenige als gut genug bewertet, um keine Warnung zu senden. Hier kann man nun natürlich geteilter Meinung sein, ob die von Microsoft geforderten 100ms so streng ausgelegt werden müssten. Ein "Travveling User" mit LTE oder öffentlichem WLAN ist sicher ein schlechtes Beispiel aber bei einem Assessment an regulären Standorten sollten Sie sogar noch niedrigere Werte fordern. Insofern sind 100ms schon ein guter Wert und die Audio-Qualität über diese Leitung war auch nur bedingt gut.
Beifang
Das speziell das Gästenetzwerk von Microsoft etwas "besonders" ist, kann ich aus weiteren Auswertungen sehen. Rimscout erfasst per Traceroute einmal den Weg ins Internet und ermittelt die erste öffentliche IP-Adresse. In den meisten Umgebungen ist dies dann die IP-Adresse des Routers zum Internet oder manchmal auch die externe Firewall beim Kunden. Bei Microsoft hingegen sehe ich sehr viele Adressen aus dem gleichen Subnetz.
Hier scheint Microsoft über verschiedene IP-Adressen im 131.107.6.0-er Netz (https://ipinfo.io/131.107.6.0) zu routen, welches Microsoft zugeordnet ist. Die Adresse 50.225.11.65 (https://ipinfo.io/50.225.11.65) war der Anteil im Hotel, da die Auswertung immer über den Tag geht.
Eine zweite Auswertung zeigt mir an, welche IP-Adresse im Internet von mir ankommt. Dazu nutzt Rimscout unseren eigenen "What is my IP"-Service und auch hier sieht das Bild anders aus, als ich es von Kunden gewohnt bin:
Das Netzwerk 167.220.0.0/17 (https://ipinfo.io/167.220.0.0) gehört ebenfalls Microsoft und das sind wohl die öffentlichen NAT-Adressen meines Clients zu verschiedenen Zeiten.
Microsoft reagiert wohl auf damit auf das 65535 Port-Limit für ausgehende Verbindungen, was ich aufgrund der Anzahl von Anwendern und der Nutzung von "Cloud-Diensten" auch verstehen kann.
Weiterhin konnte ich sehen, dass ich im Gäste-WLAN die ganze Zeit immer den gleichen DNS Server (10.104.224.20) genutzt habe. Ohne es nun weiter zu untersuchen, dürfte es sich um einen Cluster mit hochverfügbaren Diensten handelt. Auch das Default Gateway (10.24.0.1) war in allen Gebäuden gleich. So ein Beifang ist interessant aber hat letztlich keine große Aussagekraft hinsichtlich eines Netzwerk Assessment.
Rimscout ausprobieren
Wenn Sie nun neugierig auf Rimscout geworden sind und ihr eigenes Netzwerk und Clients genauer untersuchen wollen, dann ist dies sehr einfach. Unter www.rimscout.com können Sie weitere Informationen erhalten, eine Instanz zum Test buchen und natürlich können Sie auch auch erreichen.
