NTP-serverbelasting meten met Wireshark
Wireshark 3 biedt een onopvallende, maar zeer belangrijke nieuwe functie. De analysetool kan nu de latentie van NTPservers achterhalen. Dat klinkt als een niche onderwerp, maar is zowel voor bedrijven als thuisgebruikers handig. Zo konden we de ontwikkelaars overtuigen die functie te implementeren.
De voorgeschiedenis: servers voor het Network Time Protocol (NTP) waren altijd al interessant. Voor de eerste stappen is een Raspberry Pi met een DCF77- of GPS-ontvanger al voldoende. Een dergelijke combinatie kan bij een lokaal netwerk voor de precieze tijd zorgen. Die kun je ook mee laten doen aan het NTP-pool-project, zodat zijn tijd ook aan andere internetdeelnemers kan worden geleverd.
Maar wat als een Raspberry Pi crasht door de tig-duizend time-requests of hij door de belasting alleen vertraagde antwoorden geeft – ook al zijn die nog acceptabel? Hoe houdt een commerciële NTPappliance zoals van specialist Meinberg zich onder die condities? Of een krachtigere server?
Zoeken op internet of zelf aan het rekenen slaan zal je niet veel helpen, je moet dat zelf analyseren. Bij dergelijke netwerkanalyses is Wireshark daar meestal de juiste tool voor. Met die tool kun je door de uitgebreide analysemogelijkheden elk netwerkprotocol
scheiden van de grote datastroom. Maar zelfs na lang zoeken zul je er achter komen dat er eigenlijk geen functie is die je simpel en meteen het tijdverschil kan geven tussen een NTP-request en het bijbehorende antwoord.
Beide typen berichten zijn bij Wireshark te herkennen aan de hand van de ntp.flags.mode [1]. Client-messages zijn gekenmerkt door ntp.flags.mode == 3 en server-messages met ntp.flags.mode == 4. Daarbij is de verstreken tijd tussen het versturen van de vraag en het ontvangen van het antwoord van belang. Het probleem daarbij is dat die twee logisch bij elkaar horende pakketten bij een trace eigenlijk zelden op volgorde voorkomen.
Daarom is ook de algemene functie ‘Delta Time’, die de tijdafstand tussen twee pakketten aangeeft, niet bruikbaar. Daar heb je alleen wat aan als de vraag en het antwoord in een tracefile na elkaar volgen. Er waren inmiddels al wel adequate functies voor DNS (dns.time) en voor HTTP (http.time), maar blijkbaar nog niet voor NTP?
Dat was een goede reden eens contact op te nemen met de Wireshark-ontwikkelaars om een featurerequest te sturen. We hadden geen idee hoe moeilijk dat zou zijn, omdat we zelf geen programmeur zijn en naast het idee en een beschrijving er niet veel aan toe kunnen voegen. Het was maar te hopen dat iemand uit de community dat probleem op zou pikken.
Tot onze grote verrassing verliep dat (na een paar weken wachten) echter geheel anders: er namen meteen drie respectabele ‘Core Developers’ deel aan de discussie en die zagen in het idee de antwoordtijden te analyseren meteen ook een bredere toepassing: ‘Nice feature, we need this for many more protocols, but let’s start with ntp.’
Zo gezegd zo gedaan: een van de volgende ‘automated builds’, oftewel een testversie, kreeg al de analysefunctie ‘ntp.delta_time’. Wow! En sinds versie 3.0 behoort die tot de standaardfuncties van Wireshark. We konden nu eindelijk de responstijden van onze NTP-servers in de NTP-pool vergelijken.
Het analyseren van de NTP-delta-time is daarbij op meerdere plekken te gebruiken: Wireshark laat in het algemeen extra berekende waarden zien bij ‘Packet Details’ tussen rechthoekige haakjes. Via een gebruikersgedefinieerde kolom met het veld ‘ ntp. delta_time’ is die aan de pakketlijst toe te voegen – heel handig voor het overzicht. En met het commando ‘I/O-Graph’ in het menu ‘Statistics’ kun je de data grafisch laten weergeven. Met hulp van de Y-as en de
Y-velden geeft Wireshark de responstijden van een NTP-server op de tijd-as weer. Een beeld zegt tenslotte meer dan duizend woorden.
De oudere Delta-Time-functies kun je gewoon blijven gebruiken. Is je DNS-resolver aan de langzame kant? Kijk dan eens naar ‘dns.time’. Worden de webpagina’s van je oude Raspberry Pi met een slakkengang opgebouwd? Ga eens te rade bij ‘http.time’. En omdat de eerste steen gelegd is, kunnen in de toekomst meer protocollen van dergelijke functies voorzien worden.
Als je de pakketten niet op de ntp-client logt, wijken de gemeten waarden wel af van de daadwerkelijke tijdsduur. Die discrepantie wordt des te groter naarmate het station waar je de data van logt verder van de client verwijderd is. Maar als het om een inschatting van de performance van een server gaat, speelt dat geen rol. In plaats daarvan moet je zo dicht mogelijk bij de server zelf meten om latentieschommelingen door extra netwerkelementen als routers te minimaliseren. Ook de kwaliteit van de opgeslagen tracefile is van belang. Als je betrouwbare packet-captures nodig hebt, die alle pakketten een voor een in de juiste volgorde bevatten met een nauwkeurig tijdstempel, dan kom je niet om een professionele netwerk-tap heen. Daar is bijvoorbeeld de ProfiShark 1G geschikt voor. Die gebruikt USB 3.0 om traces op de pc op te slaan – hij gebruikt dan verder dus geen andere netwerkpoorten en vormt ook geen extra belasting voor de netwerkkaart van de pc.
Bij de jaarlijkse Wireshark-conferentie eind 2018 (SharkFest), kwamen we in gesprek met een paar Core-ontwikkelaars. Ze waren allemaal erg geïnteresseerd en gemotiveerd om Wireshark voorwaarts te stuwen. Aan de andere kant kunnen ze allemaal niet weten met welke details de Wireshark-gebruikers zich bezighouden. De algemene teneur was dan ook dat als gewone systeembeheerders als jij en wij nog ideeen of feature-requests hebben, dan graag! De ontwikkelaars kunnen niet wachten om nieuwe functies te implementeren en bugs te verhelpen. We zullen zelf in de toekomst in elk geval sneller aan de bel trekken bij ontbrekende functies of incomplete protocolanalyses.
Literatuur
[1] RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification, https://tools.ietf.org/ html/rfc5905