Show HN: Wie ist mein Computer zu meinem Server gelangt?

 (how-did-i-get-here.net)
4 Punkte von GN⁺ 2023-12-06 | 1 Kommentare | Auf WhatsApp teilen
  • Wenn ein Besucher die Website öffnet, führt der Server traceroute auf die öffentliche IP aus und zeigt den Weg, den Pakete über Router und Netzwerke nehmen, wie Live-Text an
  • Das eigene Tool ktr erhöht schrittweise den TTL-Wert von ICMP-Paketen, sammelt Fehlerantworten für jeden Hop und fragt gleichzeitig Netzwerkinformationen pro Hop ab
  • Die Bildaktualisierung wird nicht mit JavaScript umgesetzt, sondern indem HTML und CSS fortlaufend in eine offene HTTP-Antwort gestreamt werden, sodass die Ergebnisse während des Ladens der Seite nach und nach erscheinen
  • Der angezeigte Pfad ist ein umgedrehter Reverse-Traceroute, den der Server zur IP des Besuchers sendet; wegen Unterschieden im bidirektionalen Routing muss er nicht vollständig mit dem tatsächlichen Pfad übereinstimmen
  • Internetpfade entstehen durch BGP-Peering zwischen autonomen Systemen (AS) und die Verbreitung von Routing-Tabellen; der Traffic bewegt sich entlang miteinander verbundener Netzwerke

Personalisierter traceroute, der bei jedem Aufruf erzeugt wird

  • Der grüne Text oben auf der Seite ist kein gespeichertes Beispiel, sondern ein on-the-fly erzeugter traceroute, der während des Ladens der Website auf den jeweiligen Besucher zugeschnitten wird
  • traceroute zeigt die Reise des Computers des Besuchers oder seiner Pakete durch das Internet bis zu dem Server, der diese Website hostet
  • Ein Beispielpfad beginnt am Router des Besuchers, läuft durch das Netzwerk des ISP, durch mehrere weitere Netzwerke, gelangt in das interne Netzwerk von Hetzner und erreicht schließlich den Server
    • Der erste Router antwortet möglicherweise nicht auf ping; hinter öffentlichen Routern oder einem VPN ist das üblich
    • Unterwegs kann (no response) erscheinen, und nicht jeder Server antwortet jederzeit
  • Namen wie core3.sto.hetzner.com entstehen dadurch, dass für die im traceroute gefundene IP 213.239.252.74 eine Reverse-DNS-Abfrage ausgeführt wird, um sie in einen menschenlesbaren Namen umzuwandeln
    • Reverse-DNS-Namen dienen meist dazu, Debugging zu erleichtern, und lassen sich oft nicht wieder auf die ursprüngliche IP zurückabbilden

ktr und ICMP-basierter traceroute

  • Für die Umsetzung der Website wird das eigene traceroute-Programm ktr verwendet
    • Auch der Quellcode der Website ist auf GitHub veröffentlicht
    • ktr streamt die Ergebnisse in Echtzeit und fragt Informationen zu den einzelnen Hops parallel ab
  • Beim Internet-Routing wählt der Computer oder Router, der ein Paket verarbeitet, das nächste Weiterleitungsgerät aus, und dieser Prozess setzt sich fort, bis ein Router erreicht ist, der direkt an das Ziel senden kann
  • Die Implementierung von ktr verwendet ICMP
    • ICMP ist ein Protokoll, das für das Senden diagnostischer Informationen im Internet entworfen wurde
    • Fast alle mit dem Internet verbundenen Geräte unterstützen ICMP
  • Das TTL(time to live)-Feld in ICMP-Paketen ist keine echte Zeitangabe, sondern ein Countdown-Wert
    • Jedes Mal, wenn ein Router ein ICMP-Paket weiterleitet, muss er den TTL-Wert um 1 verringern
    • Wenn TTL 0 erreicht, stoppt der Router die Weiterleitung des Pakets und sendet eine Fehlermeldung über das Erreichen der maximalen Hop-Zahl an die ursprüngliche Quell-IP
  • traceroute sendet ICMP-Pakete mit schrittweise erhöhtem TTL von 1, 2, 3 usw. und sammelt die von jedem Hop zurückkommenden Fehlerantworten
    • Die Fehlerpakete enthalten Diagnoseinformationen wie die IP-Adresse des Geräts, das den Fehler gesendet hat
    • So lässt sich der ungefähre Pfad eines Pakets durch das Internet nachverfolgen

Eine Oberfläche, die ohne JavaScript wie Echtzeit wirkt

  • Die Seite funktioniert auch bei deaktiviertem JavaScript
    • Aus Sicht des Browsers sieht es so aus, als würde die Website langsam laden
    • Für den Benutzer wirkt es, als würde traceroute in Echtzeit erscheinen
  • Beim Aufruf erhält der Server eine HTTP-Anfrage von der IP-Adresse des Besuchers und startet sofort traceroute zu dieser IP
  • Der Server sendet zuerst den Anfang der HTTP-Antwort und hält die Verbindung dann offen
    • ktr übermittelt traceroute-Updates an den Server
    • Der Server rendert das entsprechende HTML und sendet es an den Computer des Besuchers
    • Wenn traceroute fertig ist, sendet er den restlichen Text und Inhalt der Website und schließt dann die Verbindung
  • Dass die traceroute-Zeilen nicht nach unten, sondern scheinbar nach oben hin schrittweise aktualisiert werden, liegt an eingefügten CSS-Blöcken
    • Eine Webseite kann grundsätzlich nur nach vorn geladen werden
    • Bei jeder Aktualisierung der traceroute-Anzeige wird zusätzlich CSS eingefügt, das die vorherige Anzeige ausblendet
    • Da der Browser CSS bereits während des Ladens rendert, wirkt es so, als würde der Bildschirm im Laufe der Zeit bearbeitet

Grenzen von Reverse-Traceroute

  • Der von der Seite gezeigte Pfad ist nicht vollständig identisch mit dem „Pfad, den die Pakete des Besuchers zum Server genommen haben“
  • Um den tatsächlichen Pfad zu berechnen, müsste traceroute vom Computer des Besuchers zum Server ausgeführt werden können
  • Die Implementierung führt traceroute vom Server zum Computer des Besuchers aus und zeigt das Ergebnis dann umgedreht an
    • Deshalb wirkt der traceroute oben so, als würde er in umgekehrter Reihenfolge geladen
  • Reverse-Traceroute opfert einen Teil der Genauigkeit
    • Wenn sich Pakete in die entgegengesetzte Richtung bewegen, können die Geräte andere Routing-Entscheidungen treffen
    • Schon wenn ein einziges Gerät anders entscheidet, kann sich der restliche Pfad ändern
  • Trotzdem ist der Pfad grob ähnlich; die Unterschiede liegen wahrscheinlich vor allem darin, welchen bestimmten Router ein Paket sieht

Autonome Systeme und WHOIS-Abfragen

  • Die im traceroute auftauchenden „Netzwerke“ beziehen sich auf autonome Systeme (AS)
    • Ein AS ist eine Menge privat miteinander verbundener Router und Server
    • In der Regel gehören sie demselben Unternehmen
  • Die Eigentümer eines AS bestimmen die Form des Internets, indem sie auswählen, mit welchen anderen AS sie sich verbinden
    • Der Internet-Traffic bewegt sich durch AS mit gegenseitigen Peering-Vereinbarungen
  • Das Internet wirkt wie ein offenes Netzwerk, ist in Wirklichkeit aber ein Netzwerk von firmeneigenen Netzwerken, dessen Zugang und Kontrolle von Finanztransaktionen und Bürokratie beeinflusst werden
  • Wer ein eigenes autonomes System möchte, kann bei einer der fünf Regional Internet Registries (RIR) eine ASN beantragen
    • Ohne Rückhalt durch ein Unternehmen oder ohne genügend Internet-Kontaktpunkte ist eine Annahme unwahrscheinlich
    • Zahlen wie AS4766 im traceroute sind ASNs
  • ktr verwendet das WHOIS-Protokoll, um Informationen über das AS zu erhalten, dem die IP jedes Hops gehört
    • Mehrere Organisationen verfolgen, welches AS welche IP-Adressen umfasst
    • Viele Organisationen bieten ASN-Abfragen per WHOIS an
  • Zur Ermittlung von Unternehmensinformationen wird auch PeeringDB verwendet
    • PeeringDB enthält Informationen zu etwa einem Drittel aller autonomen Systeme
    • Zusammen mit den Suchergebnissen und mehreren hundert Zeilen if-Anweisungen werden Erklärungen für den Weg durch die Netzwerke erzeugt
  • Die WHOIS-Protokollspezifikation legt fast keine Struktur fest
    • Sie definiert im Wesentlichen nur, dass eine TCP-Verbindung aufgebaut, die Abfrage gesendet, die Information zurückgegeben und die Verbindung anschließend beendet wird
    • Die tatsächliche Struktur von WHOIS-Antworten ist eher eine vom Serveradministrator geschaffene Konvention, und auch die benötigten Feldnamen können variieren, etwa origin oder originas
    • Der Parser von ktr ist weniger ein strenger Parser als eher ein Verfahren, bei dem ein Mensch WHOIS-Ergebnisse liest und die benötigte ASN herausfiltert

Wie BGP Internetpfade erzeugt

  • Router an den Netzgrenzen entscheiden, an welches nächste Netzwerk ein Paket gesendet wird, und derselbe Prozess wiederholt sich, bis das Netzwerk mit dem Zielgerät erreicht ist
  • Diese Grenzrouter tauschen über das Border Gateway Protocol(BGP) Informationen über erreichbare Netzwerke aus
    • BGP ist das Protokoll, das die Form des Internets erzeugt
    • Normale Benutzer können nicht direkt mit BGP sprechen
  • Eine frühe Version von BGP wird in RFC 1105 beschrieben, das 1989 von Cisco- und IBM-Ingenieuren veröffentlicht wurde
    • Nachdem bei einem ARPANET-Prototyp von 1969 Nachrichten teilweise übertragen worden waren, begannen verschiedene Universitäten, Behörden und Unternehmen, ihre eigenen Netzwerke aufzubauen und miteinander zu verbinden
    • 1990 erschien BGP v2
    • 1994 wurde BGP v4 als RFC 1654 festgelegt
    • BGP v4 wurde 1995 und 2006 überarbeitet und gepatcht und wird weiterhin für die Pfadauswahl in den miteinander verbundenen Netzwerken des modernen Internets verwendet

BGP-Pfade, Peering und Routing-Tabellen

  • Ein Border Gateway, also ein Router an der Grenze eines autonomen Systems, verwaltet eine Routing-Tabelle, die alle ihm bekannten BGP-Pfade auflistet
  • Jeder BGP-Pfad beschreibt einen ASN-Pfad, dem gefolgt werden kann, um ein AS zu erreichen, das eine bestimmte Menge von IP-Adressen kontrolliert
  • BGP-Pfade entstehen durch Peering-Beziehungen zwischen AS
    • Wenn die Border Gateways zweier AS peeren, kann Traffic zwischen diesen beiden Routern fließen
    • Sie teilen die ihnen bekannten BGP-Pfadinformationen miteinander, damit sie aktuell bleiben
  • Wenn beispielsweise Router A in AS0001 und Router B in AS0002 physisch verbunden sind und peeren sollen, tauschen sie BGP-Nachrichten aus, um eine BGP-Session aufzubauen
    • Router A erfährt dabei, dass Wege zu BGP-Pfaden, die mit AS0002 beginnen, über Router B führen
    • Router B erhält die entsprechenden Informationen in Gegenrichtung
  • Peers teilen die ihnen bekannten Pfade durch Route Advertisement
    • Wenn Router A Router B alle ihm bekannten Pfade mitteilt, fügt Router B Pfade, die mit AS0001 beginnen, seiner Routing-Tabelle hinzu
    • Wenn ein anderer Peer von Router A einen neuen Pfad ankündigt, gibt Router A ihn auch an Router B weiter
  • Während sich diese Ankündigungen durch das gesamte AS-Netzwerk verbreiten, erfährt jedes Border Gateway einen oder mehrere AS-Pfade zu praktisch jeder erreichbaren IP im Internet
  • Wenn ein Router ein Paket an eine bestimmte IP senden will, sucht er in seiner Routing-Tabelle nach einem Pfad zu dem AS, das diese IP kontrolliert
    • Anschließend wählt er mithilfe verschiedener Heuristiken den „besten“ Pfad aus
    • Zu diesen Heuristiken gehören die Suche nach dem kürzesten Pfad sowie hart kodierte Präferenzen oder Abneigungen gegenüber bestimmten AS
    • Der Router sendet das Paket an den Gateway-Router, der mit dem ersten AS des gewählten Pfads peert

traceroute-Ergebnisse aus BGP-Sicht lesen

  • Der AS-Pfad im Beispiel-traceroute lautet AS4766 → AS201011 → AS24940
  • Irgendwann erreicht das Paket einen Router in AS4766, und dieser Router peert mit einem Router in AS201011
    • Der Router entscheidet anhand seiner Routing-Tabelle, dass die Ziel-IP über einen Pfad erreichbar ist, der mit AS201011 beginnt
    • Danach sendet er das Paket an den verbundenen Router in AS201011 weiter
  • Auch innerhalb derselben ASN können mehrere Hops erscheinen
    • Wie bei den sechs Hops durch Hetzner Online zeigt traceroute nicht nur die Grenzrouter von AS, sondern alle Router, durch die das Paket gelaufen ist
  • Router innerhalb eines AS können interne Pfade gegenüber externen BGP-Pfaden bevorzugen, wenn sie einen effizienten internen Weg kennen
    • Interne Pfade können über internes BGP, andere interne Routing-Protokolle oder per Hardcoding gelernt werden
  • Entscheidend für die Erreichbarkeit im Internet sind nicht die internen Hops, sondern die Peering-Vereinbarungen zwischen verschiedenen AS

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-06
Hacker-News-Kommentare

  • Hallo, ich bin Lexi. Ich bin 17, und mein aktuelles Interesse ist es, tiefer zu verstehen, wie Computer funktionieren, und das auf neue Weise zu zeigen.
    Vor ein paar Monaten habe ich https://cpu.land veröffentlicht, und die zugehörige Diskussion findet sich unter https://news.ycombinator.com/item?id=37062422.
    Nach cpu.land war der Druck groß, noch etwas riesig Großes zu machen, aber ich hatte keine Idee, die mich wirklich angezogen hat. Also habe ich an verschiedenen privaten Projekten herumprobiert und dabei, eher zufällig beim Lernen darüber, wie das Internet funktioniert, ein traceroute-Programm von Grund auf gebaut, das in Echtzeit auf eine Website gestreamt wird.
    So etwas hatte ich im Web noch nie gesehen, und ich fand, es sei eine ziemlich neue und coole Art, die Struktur des Internets zu visualisieren, also habe ich es ausgearbeitet und eine schöne Website daraus gemacht.
    Dabei habe ich viel Interessantes über BGP und die Struktur des Internets gelernt, also habe ich das traceroute-Tool mit einem Artikel kombiniert, der dieses Wissen teilt.
    Ich arbeite noch daran weiter, und der Code wird mit Sicherheit irgendwo kaputtgehen, also sagt mir gern Bescheid, wenn ihr Vorschläge habt.
    Und warum Rust: Ich halte die Wahl der Programmiersprache nicht für besonders wichtig, aber ich wollte schnell ein zuverlässiges Low-Level-Programm schreiben, und mir gefielen die grundlegenden Bausteine der Fehlerbehandlung in Rust.

    • Wenn du sagst: „So etwas habe ich im Web noch nie gesehen“, dann such mal nach looking glass bgp, da findest du ähnliche Dinge.
      Eines der ersten CGI-Programme, die ich vor fast 30 Jahren gebaut habe, war ein Perl-Skript, das traceroute umhüllt und die Ergebnisse per Server-Push streamt.
      Alles Alte wird irgendwann wieder neu, aber die Präsentation auf der Website ist trotzdem sehr gut.
      Zur Einordnung: Die IPv4-TTL ist formal in Sekunden angegeben, aber kein Router braucht mehr als 1 Sekunde, und der minimale Verringerungswert ist 1, daher wird sie praktisch als Hop-Zahl verwendet. Middleboxes, die lieber verborgen bleiben wollen, verringern sie manchmal überhaupt nicht.
      Außerdem verwendet traceroute unter Linux/Unix standardmäßig UDP zu hohen, gewöhnlich geschlossenen Ports statt ICMP für die Probe-Pakete, weil UDP historisch seltener gedroppt oder gefiltert wurde als ICMP.
      Zu fragen, wie traceroute funktioniert, ist eine meiner Interviewfragen, aber die meisten wissen es nicht, und selbst wenn, ist der Erkenntniswert der Frage eher gering. Ich habe oft erlebt, dass Leute trotz vieler TCP/IP-Fragen nicht von den ersten Prinzipien aus denken können; ob sie es trotzdem herleiten können, finde ich jedoch eine vernünftige Frage zum Problemlösen.
      Beispiel: https://www.bgplookingglass.com/
      https://www.oreilly.com/openbook/cgi/ch06_06.html
    • Tolles Projekt. Ich habe einen ernst gemeinten und einen lockeren Vorschlag.
      Ich frage mich, ob du mit TCP oder UDP statt ICMP genauere Ergebnisse bekommen könntest. Klassisches traceroute hat ja auch eine UDP-Option, mtr [1] kann TCP oder UDP verwenden, und tcptraceroute [2] kann TCP verwenden.
      Und es wäre der perfekte Ort für ein Talking-Heads-Zitat: „And you may ask yourself, well, how did I get here?“ [3]
      [1] https://github.com/traviscross/mtr
      [2] https://linux.die.net/man/1/tcptraceroute
      [3] https://en.wikipedia.org/wiki/Once_in_a_Lifetime_(Talking_He...
    • Du machst schon jetzt viel coolere Dinge, als ich mit 17 gemacht habe. Wenn dir „I, Robot“ gefallen hat, kann ich Ted Chiangs Stories of Your Life and Others empfehlen. Der Film Arrival basiert auf einer der Geschichten aus diesem Band.
    • Das ist eine gute Website zur Erklärung von traceroute und daher nützlich. Ich könnte sie verwenden, wenn ich mehreren Technikern, die für die Wartung des Firmennetzwerks geschult werden, den Nutzen von traceroute erkläre.
      Wenn du jetzt nur noch herausfindest, wie traceroute an jedem Hop funktioniert, bis es von einem bestimmten Workstation aus den Cisco-Access-Switch des Unternehmens, den Core-Switch, den BGP-Tunnel zum AWS Transit Gateway und schließlich die VPC-Routing-Tabelle einer EC2-Instanz erreicht, darfst du dich wohl Netzwerkverantwortlicher nennen.
    • Sehr cool. Ich hatte kurz Angst, dass man einen Tor-Circuit sehen könnte.
      Leider ignorieren zu viele Nodes traceroute-Pakete, daher sah es nur so aus, als ob mein Exit-Node sich mit Linode verbindet und Linode sich mit deinem Computer verbindet.
      Bei normalem traceroute in Vorwärtsrichtung ist es ähnlich: Router antworten, Server antworten, und mit etwas Glück sieht man vielleicht einen Node aus dem ISP-Netzwerk. Der Rest ist ziemlich dicht.

  • Du sagst: „BGP ist das Protokoll, das dem Internet seine Form gibt, und man kann es nicht direkt sprechen“, aber tatsächlich ist es überraschend einfach, als Privatperson eine ASN zu bekommen und BGP zu sprechen.
    Wenn dich der Bau solcher Tools interessiert, wäre das vielleicht einen Versuch wert. Falls du Interesse hast: Ich habe früher einen Einführungsartikel dazu geschrieben: https://qt.ax/asn

  • Das ist weniger „wie mein Computer deinen Server erreicht“ als vielmehr die umgekehrte Richtung davon, wie dein Server meinen Computer erreicht. Bidirektionales Routing dürfte in den meisten Fällen ziemlich unterschiedlich sein.

    • Im Artikel gibt es tatsächlich einen Abschnitt Front to Back, Back to Front, der genau darauf eingeht.
      Kurz gesagt: Meiner Erfahrung nach sind die durchlaufenen Netzwerke meist sehr ähnlich, und unabhängig von der Richtung ist das Thema relevant und interessant.
    • In der Zeit der bang paths machte es Spaß, die bang path des Absenders mit der bang path für Antworten zu vergleichen und daraus abzuleiten, welche Unterschiede in den Netzwerkverbindungen die Asymmetrie verursachten.

  • Es gibt einen interessanten Artikel dazu, wie traceroute funktioniert. Ein Punkt, den Menschen außerhalb des Netzwerkbereichs oft übersehen, ist, dass traceroute nicht unbedingt symmetrisch ist. Der Rückweg kann anders sein
    https://archive.nanog.org/sites/default/files/traceroute-201...

    • Heute gab es in Ägypten wegen eines Problems bei Telecom Egypt einen Internetausfall, und traceroute zum selben Ziel nahm 8 verschiedene Pfade
      Das ist ungefähr doppelt so viel ECMP, wie ich bisher im Internet gesehen habe
      Und auch der Traffic vom Kairoer Büro zum britischen Core und der Traffic in die Gegenrichtung nahmen unterschiedliche Pfade. London→Cairo ist direkt und hat weiterhin starke Verluste, aber Cairo→London geht jetzt über ntt und sieht okay aus. Wenn es bis morgen nicht behoben ist, müssen wir vielleicht die Local Preference ändern
    • Selten, aber auch der Datenpfad selbst kann asymmetrisch sein. Ein Beispiel wären Satelliten mit terrestrischem Uplink
    • Danke, werde ich lesen. Diese Dualität wurde auch im Artikel behandelt

  • Es hieß, „WHOIS ist ein interessantes Protokoll, um einen Parser dafür zu bauen“, aber in Wirklichkeit ist das nahezu unmöglich
    Antworten sind im Wesentlichen Freitext, und Server antworten möglicherweise gar nicht. Ich habe es auch versucht, und vor 10 Jahren konnte ich einen Ad-hoc-Parser bauen, der für 90 % der Adressen oder Domains funktionierte, aber der Rest war nicht handhabbar
    Heute ist es noch schlimmer, und fast alles verbirgt sich hinter Datenschutzabschirmungen. Man behauptet, damit PII zu schützen, aber WHOIS-Einträge sollten ursprünglich keine persönlichen Daten enthalten, sondern Kontaktdaten von Netzwerkbetreibern
    Ich halte das für die Schuld von ICANN. ICANN hatte eine Regel, dass Netzwerke öffentliche WHOIS-Server bereitstellen müssen, hat sie aber nicht durchgesetzt und inzwischen abgeschafft

    • Müssen in WHOIS nicht E-Mail, Telefonnummer und echte Adresse stehen? Bei Unternehmen ist das vielleicht keine PII, aber bei WHOIS für eine private Website sehe ich nicht, wie das keine personenbezogenen Daten sein soll
    • RDAP enthält einen Teil der WHOIS-Informationen in einem maschinenlesbaren JSON-Format. Nicht alles, aber ich halte es für besser
      Allerdings betreibt nicht jeder einen RDAP-Server. Es wäre gut, wenn ICANN/IANA oder irgendjemand das durchsetzen würde
      Auch Informationen über Netzwerkbetreiber können PII sein. Meine Daten sind PII, und ich besitze einen Domainnamen, also bedeutet es, PII in WHOIS einzutragen, wenn ich meine Daten in WHOIS eintrage
      Datenschutzdienste leiten mir einfach alles weiter, außer Spam
      Bei Unternehmen sehe ich keinen guten Grund, Datenschutzdienste zu erlauben, aber noch gehören nicht alle Domains Großkonzernen
    • Zu dem Punkt, dass man einen Ad-hoc-Parser bauen kann, der für 90 % der Adressen oder Domains passt, während der Rest kryptisch ist: Könnte generative KI dabei heute nicht helfen? Etwa im Stil von „Hier ist ein WHOIS, extrahiere mir die Informationen, die ich haben will“

  • Statt eines separaten ICMP-ECHO-Trace könnte man noch einen Schritt weitergehen und die bestehende HTTP-TCP-Verbindung zwischen Client-Browser und Webserver nutzen
    Damit könnte man dann clientseitiges NAT oder zustandsbehaftete Firewalls passieren

    • Interessant. Ich frage mich, wie das mit echtem traceroute funktionieren würde
    • Das nennt man parasitic traceroute

  • Es gibt frühere Arbeiten zu Reverse Traceroute
    https://research.cs.washington.edu/networking/astronomy/reve...
    Artikel: http://www.cs.washington.edu/homes/ethan/papers/reverse_trac...
    Video: http://www.usenix.org/multimedia/nsdi10katz-bassett

  • Es ist auch gut zu wissen, dass Pakete einer TCP-Session auf dem Weg durchs Internet oft asymmetrische Pfade nehmen. Meiner Erfahrung nach waren die häufigsten Gründe kostenbezogene Geschäftsregeln und menschliche Fehler
    Wenn man bedenkt, wie IP funktioniert, ist das an sich kein besonderes Problem, aber es kann das Verständnis von Routing erschweren

    • Eine interessante Anekdote dazu
      Boise State University und die University of Idaho liegen an entgegengesetzten Enden des Bundesstaats Idaho. Die nördliche UIdaho liegt näher an Spokane und die meisten Verbindungen kommen aus Seattle; Boise liegt näher an Salt Lake und ist oft über Portland oder Salt Lake City angebunden
      Der mittlere Teil des Bundesstaats zwischen beiden ist gebirgig, daher gab es kaum große Verbindungen, aber früher hatte UofIdaho einen kleinen Link für entfernte Unterrichtsräume im Süden
      Irgendwann Ende der 90er stellten ein BSU-Netzwerkingenieur und ein UofI-Ingenieur fest, dass sie im selben Gebäude Switches und Routing-Hardware stehen hatten, und verbanden die beiden mit einem Ethernet-Kabel
      Das Ergebnis war katastrophal. Die beiden Netzwerke begannen, einander BGP anzukündigen, und diese Verbindung wurde im gesamten Internet bekannt. Plötzlich gab es einen sehr kurzen Sprung zwischen den Netzwerken Richtung Seattle und denen Richtung Salt Lake City, und die arme kleine T1-Leitung war völlig ausgelastet
      Interessanterweise geschah das nur in eine Richtung. Boise kündigte den Pfad an, Idaho jedoch nicht, sodass der Traffic praktisch nur in eine Richtung kaputtging
      Natürlich wurde das Kabel wieder gezogen, und selbst Jahre später, als ich bei UofIdaho arbeitete, war allgemein bekannt, dass man die beiden Netzwerke niemals wieder verbinden durfte. Ironischerweise leitete ich damals ein Programm, um I2 an beiden Universitäten aufzubauen

  • Auf meinem Gerät sind die Zwischenstationen zwischen meinem Gerät und dem Server überhaupt nicht sichtbar. Nur als Hinweis

    • Stimmt, sorry. Wegen Hacker News ist der Server ziemlich stark ausgelastet
      Ich arbeite gerade daran und hoffe, dass es bald besser funktioniert. Bis dahin erhöhe ich die Timeouts; das Laden dauert dann zwar länger, sollte aber besser funktionieren
    • Vielleicht funktioniert es besser, wenn man HN nicht aus dem Linode-Rechenzentrum heraus ansieht :P

  • mtr ist ebenfalls erwähnenswert. Ich nutze es viel häufiger als traceroute
    Es hilft bei der Diagnose von sporadischem Paketverlust und vermittelt ein besseres Gefühl für den durchschnittlichen Verlauf eines Flows
    Dieser Artikel von APNIC erklärt mtr und wie man die Ergebnisse liest, ausführlicher und behandelt auch, wie MPLS den tatsächlichen Pfad verschleiern kann
    https://blog.apnic.net/2022/03/28/how-to-properly-interpret-...
    Auch die Verfolgung per UDP ist manchmal nützlich, und man sollte wissen, dass viele Router unter Last ICMP selektiv verwerfen
    Guter Artikel, und auch sprachlich sehr gelungen