Backbone / Routing Q&A

  • Hallo zusammen, ich habe hier, insbesondere in den letzten Tagen, ein kleines Routing / Latenzproblem mit einem anderen Hoster.

    Wir betreiben Infrastruktur bei Netcup und einigen anderen Anbietern, darunter auch dem im gleichen Rechenzentrum mit dem roten "H". Seit Januar und ganz schlimm auch wieder in den letzten Tagen, läuft das Peering sehr instabil. IP4 und IPv6 gleichermaßen. Normalerweise ist die Latenz zwischen 0,5 und 2,5 Millisekunden, zu den Ausfallzeiten steigt die Latenz auf 80-120 Millisekunden und Paketloss setzt ein:

    Route Netcup zu H*****:

    Code
    1. HOST: ncdb-m Loss% Snt Last Avg Best Wrst StDev
    2. 1.|-- 2a03:4000:4e::2 0.0% 1000 5.9 2.7 0.2 82.5 9.8
    3. 2.|-- 2a00:11c0:47:3::32 0.0% 1000 1.9 1.4 0.3 58.6 4.9
    4. 3.|-- 2a00:11c0:47:1:47::139 0.1% 1000 0.4 5.5 0.3 111.7 13.5
    5. 4.|-- 2a00:11c0:47:1:47::141 7.4% 1000 3.4 7.0 3.3 108.4 10.4
    6. 5.|-- decix-gw.h*****.com 0.3% 1000 10.5 6.9 1.1 81.1 8.8
    7. 6.|-- core12.nbg1.h*****.com 19.7% 1000 99.3 98.3 4.4 143.3 16.7
    8. 7.|-- 2a01:4f8:0:e0c0::a0c2 1.4% 1000 102.3 83.6 1.2 229.2 38.6
    9. 8.|-- hxapp 82.9% 1000 49.3 10.2 0.6 49.3 13.8


    Andere Richtung:

    Code
    1. HOST: hxapp Loss% Snt Last Avg Best Wrst StDev
    2. 1.|-- 172.31.1.1 0.0% 1000 5.0 5.2 3.2 26.7 1.2
    3. 2.|-- 15902.your-cloud.host 0.0% 1000 0.3 0.2 0.1 0.9 0.0
    4. 3.|-- static.65.139.12.49.clien 0.0% 1000 13.1 57.2 1.1 795.8 112.7
    5. 4.|-- static.88.198.252.165.cli 0.0% 1000 0.9 4.6 0.7 102.6 11.9
    6. 5.|-- core12.nbg1.h*****.com 0.0% 1000 2.2 2.3 0.4 31.2 3.9
    7. 6.|-- juniper4.dc2.nbg1.h****** 0.0% 1000 0.4 0.6 0.3 26.2 1.4
    8. 7.|-- xe-65-0-2-900.bbr02.anx84 78.6% 1000 93.3 75.2 22.1 111.8 25.9
    9. 8.|-- netcup-gw.bbr02.anx84.nue 1.5% 1000 93.4 95.1 19.7 1560. 53.3
    10. 9.|-- ncdb-m 1.6% 1000 97.0 92.5 18.2 1449. 48.8


    Das treibt uns etwas in die Verzweiflung, da unsere Systeme zwar für eine gewisse Zeit mit höheren Pings klar kommen, aber das gepaart mit Paketloss bringt die Datenbank-Replikation zum Erliegen und die Loadbalancer melden reihenweise ausgefallene Backends. Falls es hilft, kann ich gerne auch noch ein paar Zeiten hinzufügen, in denen es besonders schlimm war. Kann hier jemand evtl. mal schauen, was hier schief läuft?

    Besten Dank im Voraus und viele Grüße!

  • Hallo peterbo - danke für deine Meldung. Wir haben in den letzten Tagen leider immer wieder Probleme mit "H", Traffic wird uns auf unüblichen Wegen (via N-IX, statt über unseren PNI) zugestellt. Wir laufen dem leider im Moment reaktiv hinterher, vom H-NOC bekommen wir keine Rückmeldung. Wir haben jetzt grade noch mal etwas Traffic Engineering betrieben, kannst du bitte noch mal prüfen, ob das Problem noch besteht?

  • Gibt es eigentlich Pläne für ein private Peering mit Vodafone? Die Präfixe von Vodafone West (ehemals Unitymedia/KabelBW) werden mittlerweile auch vom AS3209 announced und damit in absehbarer Zeit aus dem Netz von Liberty Global verschwinden. UPC in Österreich ist ja auch schon länger verkauft, womit das AS6830 auch dort Bedeutung verlieren wird.

  • Hallo peterbo - danke für deine Meldung. Wir haben in den letzten Tagen leider immer wieder Probleme mit "H", Traffic wird uns auf unüblichen Wegen (via N-IX, statt über unseren PNI) zugestellt. Wir laufen dem leider im Moment reaktiv hinterher, vom H-NOC bekommen wir keine Rückmeldung. Wir haben jetzt grade noch mal etwas Traffic Engineering betrieben, kannst du bitte noch mal prüfen, ob das Problem noch besteht?

    Hallo Theo,
    besten Dank für die schnelle Antwort und den klasse Support!


    Derzeit läuft es wieder stabil. Ab dem 27.3 hat sich die Situation insgesamt wieder verbessert; Seit dem 1.1.21 meldet das Monitoring allerdings schon 20 Ausfallperioden des Peerings. Mittlere Länge der nicht-Nutzbarkeit (=Latenz >100ms und Paketloss, gemessen von 20+ H*** Maschinen und 4 Zielen bei Netcup) sind 15 Minuten, mit Spitzen von 45 Minuten. 5 Minuten können wir das kompensieren, danach fangen die Loadbalancer das Rotieren an. Insgesamt verlieren wir da also etwas das Vertrauen in die Stabilität - mit schlechteren Latenzen kommt die Topologie klar, aber Paketloss ist der Killer. Der Support von H* hält sich da leider sehr in Grenzen, hoffe aber sehr, dass dies auf deren Seite auch bald etwas höher priorisiert wird.

    Vielen Dank für Deinen Einsatz!!
    Peter

    Nachtrag mit Antwort des Supports (H):

    >der PNI zu Netcup/Anexia ist an dem ausgefallenen Router.

    >Deswegen ging dieser kurzfristig ueber den N-IX.

    >Heute geht dieser wieder direkt ueber den PNI.

    Allerdings wurde nicht beantwortet, warum dies seit dem 1.1. schon so oft vorkam bzw. ob nur jedesmal der defekte Router wiederbelebt (Abstauben und streicheln?), oder endlich mal getauscht wird/wurde; Oder noch besser: Redundant gemacht wurde.

  • Hallo Theo,
    besten Dank für die schnelle Antwort und den klasse Support!

    Danke, das hört man gerne! Wir versuchen hier so viel mitzulesen und zu unterstützen!

    Wir haben natürlich auch keine Einsicht in die H-Infrastruktur, aber grundsätzlich ist unsere PNI-Kapazität zu "H" absolut ausreichend. Letztens gab es - wie dir der "H"-Support der auch bestätigt hat - Probleme bei "H" an einem Router/Switch, an dem unser PNI hängt. An unserem "Counterpart" gab es soweit keine Wartungen oder Ausfälle. Wir haben jetzt noch mal Kontakt mit "H" aufgenommen und werden unsere PNI-Kapazitäten vorbeugend noch weiter aufbohren, auf 2x100GE über zwei Router verteilt, sodass es zukünftig keine Probleme mehr geben wird, wenn ein Router sowohl bei uns als auch bei "H" Probleme macht.


    Ich hoffe, das beantwortet deine Frage soweit.

  • Hallo Theo,


    vielen Dank für's Kümmern und die Mühe!

    Wir haben jetzt noch mal Kontakt mit "H" aufgenommen und werden unsere PNI-Kapazitäten vorbeugend noch weiter aufbohren, auf 2x100GE über zwei Router verteilt, sodass es zukünftig keine Probleme mehr geben wird, wenn ein Router sowohl bei uns als auch bei "H" Probleme macht.

    Ganz großes Tennis, da bleibt kein Wunsch offen!


    Vielen Dank für die tolle Arbeit. Ich werde berichten, wie sich das in den nächsten Monaten entwickelt, aber ich weiß schon einmal Bescheid, dass das Problem dann sicher nicht auf NC/Anexia-Seite liegt. :)

    Viele Grüße

    Peter

  • Danke peterbo - Feedback (positiv wie kritisch) ist immer schön!


    Vielleicht noch als allgemeine Information: Wir haben in den vergangenen Tagen unsere beiden Backbone-Router in Nürnberg ausgetauscht und neue Juniper MX10003 mit insgesamt 2.4 Tbps Gesamt-Kapazität eingebaut. Auch die Bandbreiten nach Frankfurt und Wien haben wir verdoppelt, in Kürze folgt der PNI zu "H" mit 200 Gbps. Wir peeren außerdem seit einiger Zeit am Nürnberg Internet Exchange. Alle Details findet ihr wie immer hier: https://peeringdb.com/net/13902.


    Bei Fragen rund ums Routing könnt ihr euch natürlich gerne an uns wenden!

  • Hi! My server not reachable via ping/ssh from outside network. I have not made any changes on the server. Firewall is disabled.




    I can connect to the server via SCP VNC Terminal, but all outgoing connections resets from this server to outside hosts. Any idea? Support remains silent.

  • Hi! My server not reachable (v22017115148355749) IP: 185.183.159.65


    1 static.88-198-46-33.clients.your-server.de 88.198.46.33 de 0.290 ms 0.278 ms 0.289 ms
    2 core24.fsn1.hetz ner.com 213.239.245.241 de 0.288 ms
    core23.fsn1.hetz ner.com 213.239.245.237 de 3,178 ms 3,167 ms
    3 juniper5.nbg1.hetz ner.com 213.239.252.249 de 2,605 ms 2,600 ms 2,584 ms
    4th ae7-0.bbr02.anx84.nue.de.anexia-it.net 144.208.211.56 at 2,689 ms 2,682 ms 2,665 ms
    5 * * *
    6th * * *
    7th * * *
    8th * * *
    9 * * *

    No reply for 5 hops. Assuming we reached firewall.


  • Hi! My server not reachable via ping/ssh from outside network. I have not made any changes on the server. Firewall is disabled.

    Hi! My server not reachable (v22017115148355749) IP: 185.183.159.65


    Thank you for your reports about this. This has been resolved now. You may also contact our emergency support in cases like this for a faster resolution outside of the usual business hours:

    https://www.netcup.eu/kontakt/telefonsupport.php

  • Das haben wir schon, via VIX und DE-CIX! Gibt es hier konkrete Probleme/Wünsche?

    interessant, dann sind die Latenzzeiten dem Umstand geschuldet,

    dass es mit der sogenannten Kirche ums Kreuz geht, sprich:

    von mir zum VIX gehts nach Osten: von Linz nach Wien

    dann vom VIX zu netcup gehts nach Westen: von Wien nach Nürnberg
    ( ich mein die Leitung geht doch irgendwie bei Linz vorbei od. nicht? ;) )

    im traceroute sieht das so aus


    pasted-from-clipboard.png

    Hop 1 ist mein eigener Router, Hop 2 ist der Router den mein ISP in der Whg. installiert hat

    (hat WANseitig eine public IPv4)

    und Hop 3 steht im RZ des ISPs; Hop 1-3 sind jeweils RFC1918 IPv4-Adressen

  • interessant, dann sind die Latenzzeiten dem Umstand geschuldet,

    dass es mit der sogenannten Kirche ums Kreuz geht, sprich:

    von mir zum VIX gehts nach Osten: von Linz nach Wien

    dann vom VIX zu netcup gehts nach Westen: von Wien nach Nürnberg
    ( ich mein die Leitung geht doch irgendwie bei Linz vorbei od. nicht? ;)

    Das ist leider korrekt, wir tauschen Datenverkehr mit dem genannten Provider nur in Wien und Frankfurt aus. Sprich, der Trace ist korrekt!

  • Das ist halt die Konsequenz, wenn Daten nur an wenigen großen Knoten ausgetauscht werden. In Deutschland läuft viel über Frankfurt (was immerhin einigermaßen zentral liegt), in Österreich viel über Wien. Der DE-CIX in München wäre noch zwischen Frankfurt und Wien, aber dort sind kaum österreichische Provider angeschlossen.

  • Das ist halt die Konsequenz, wenn Daten nur an wenigen großen Knoten ausgetauscht werden. In Deutschland läuft viel über Frankfurt (was immerhin einigermaßen zentral liegt), in Österreich viel über Wien. Der DE-CIX in München wäre noch zwischen Frankfurt und Wien, aber dort sind kaum österreichische Provider angeschlossen.

    Ja, das ist in der Tat korrekt. Wir peeren immer so lokal wie möglich und sofern es auch technisch sinnvoll ist. Bspw. in Österreich neben dem VIX auch am AAIX, in Deutschland am Stuttgart-IX und am Nürnberg-IX.