Beiträge von Dragon

    Derzeit dienen die Uplinks noch als Fallback wenn alles andere wegbricht.

    Erst einmal Danke für deine schnelle Antwort, Felix. Allerdings sieht es für mich so aus als wären die Uplinks zu Core-Backbone bereits seit Anfang des Monats nicht mehr aktiv (Routing wahlweise über DE-CIX, Telia oder H*etzner). Auch die IP-Adressen 80.255.14.22 und 80.255.15.162 verweisen nicht mehr auf gw-cb30.nbg.netcup.net btw. gw-cb40.nbg.netcup.net.

    Warten bis sich der Kunde meldet, der diese Zahlung getätigt hat. Spätestens wenn unsere Erinnerungen raus gehen, meldet sich der Kunde ja (in der Regel).

    Der ein oder andere Kunde kann sich bestimmt nicht vorstellen, warum die Überweisung nicht zugeordnet worden konnte... :rolleyes:


    Darf ich nochmal wegen Core-Backbone nachhaken? Die Frage ist hier wohl zwischen den vielen anderen Beiträgen untergegangen. Die Anbindung zu Core-Backbone wurde zugunsten von Anexia aufgegeben? Auf eurer Website ist das nämlich noch aufgeführt.

    Wer uns ärgern will überweist uns 23,88 Euro mit dem Verwendungszweck "Webhosting" vom Konto seiner Frau, die nicht bei uns Kundin ist. Das passiert leider gar nicht so selten.

    Und was macht ihr dann? Hoffen, dass es eine passende Rechnung offen ist? Ihr könnt ja nicht einmal den Kunden kontaktieren, wenn ihr die Überweisung nicht zuordnen können.

    Es sieht allerdings nicht so aus als wären die Links zwischen netcup und Core-Backbone noch aktiv. Core-Backbone routet nun lieber über H*etzner.

    Stimmt, die Latenzen nach Frankfurt sind wieder besser, die nach Wien wieder schlechter. In Richtung NTT und Telia passt aber irgendwas nicht.

    NTT Frankfurt:

    Code
    1. PING ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141) 56(84) bytes of data.
    2. 64 bytes from ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141): icmp_seq=1 ttl=55 time=13.9 ms
    3. 64 bytes from ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141): icmp_seq=2 ttl=55 time=13.8 ms
    4. 64 bytes from ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141): icmp_seq=3 ttl=55 time=14.7 ms
    5. 64 bytes from ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141): icmp_seq=4 ttl=55 time=13.8 ms

    Telia Frankfurt:

    Code
    1. PING ffm-bb3-link.telia.net (62.115.133.34) 56(84) bytes of data.
    2. 64 bytes from 62.115.133.34: icmp_seq=1 ttl=244 time=23.8 ms
    3. 64 bytes from 62.115.133.34: icmp_seq=2 ttl=244 time=24.0 ms
    4. 64 bytes from 62.115.133.34: icmp_seq=3 ttl=244 time=23.8 ms
    5. 64 bytes from 62.115.133.34: icmp_seq=4 ttl=244 time=23.9 ms

    [netcup] Felix : Kann es sein, dass diese Änderung nach hinten los ging? Die Latenzen nach Frankfurt sind deutlich gestiegen, weil anscheinend jetzt über Wien geroutet wird.

    Das wurde wahrscheinlich umgestellt nachdem netcup den Standort in Frankfurt in Betrieb genommen hatte und von dort direkt eine Leitung zur Telekom legen konnte.

    [netcup] Felix

    In der Pressemitteilung ist statt einem Link noch ein Platzhalter enthalten. http://Netzwerk und Hardware gibt es erstaunlicherweise nicht. ;)


    Gibt es eigentlich aktuell Probleme im Anexia-Netz zwischen Nürnberg und Wien? Es wird seit den Wartungsarbeiten am Montag in beide Richtungen über Frankfurt geroutet. Beispiel aus dem Looking Glass von Telia (Wien):

    Es ist echt krass wenn die Techniker schneller sind als das Marketing. Oft ist das ja eher anders herum. Unser Netzwerk wurde seit Ende 2017 massiv aufgerüstet. Jetzt ist die neue Network-Map endlich fertig, welche die Leistung unserer Techniker aufzeigt:


    https://www.netcup.de/ueber-ne…ardware-infrastruktur.php

    Die neue Netzwerk-Karte sieht schick aus :thumbup:, aber die extrem in die Breite gezogene Karte im Hintergrund stört mich irgendwie.


    Stimmt die Angabe mit 3 x 10 GBit/s Core Backbone? Das ist nicht in der Karte verzeichnet und passt von der Kapazität nicht zu den anderen einfach-redundanten Transits.


    PS: Was wird am Montag bei den Wartungsarbeiten am Netzwerk gemacht? Die neuen Transits scheinen ja schon aktiv zu sein.

    Könnte natürlich sein, dass hier die Session(s) hin und wieder mal flappen, beide die gleiche Gewichtung haben und deshalb immer die Route genommen wird, mit der höchsten Uptime.

    Wobei das neueste Peering wohl die geringste Uptime haben sollte. ;) Grundsätzlich scheint jedenfalls Frankfurt bevorzugt werden, auch bei österreichischen Providern (sofern am DE-CIX/ECIX präsent).

    Vor allem bei Anexia sieht man gerne Pfade über Frankfurt und Wien im traceroute, hier scheinen beide Standorte exakt gleich gewichtet zu sein. Das sieht dann etwas chaotisch aus, wie in folgendem Beispiel:

    Code
    1. traceroute to lg.telia.net (80.239.194.151), 30 hops max, 60 byte packets 1 gw02.netcup.net (46.38.225.3) 0.425 ms 0.350 ms 0.374 ms
    2. 2 ae3-4018.bbr01.anx84.nue.de.anexia-it.net (144.208.211.26) 0.367 ms 0.359 ms 0.355 ms
    3. 3 ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136) 10.701 ms ae2-0.bbr02.anx25.fra.de.anexia-it.net (144.208.208.141) 3.953 ms ae2-0.bbr02.anx03.vie.at.anexia-it.net (144.208.208.136) 10.693 ms
    4. 4 ae0-0.bbr01.anx25.fra.de.anexia-it.net (144.208.208.143) 3.996 ms 4.108 ms ae0-0.bbr01.anx03.vie.at.anexia-it.net (144.208.208.133) 10.627 ms
    5. 5 win-b2-link.telia.net (62.115.14.116) 3.670 ms 3.650 ms ae1-0.bbr01.anx04.vie.at.anexia-it.net (144.208.208.135) 10.627 ms
    6. 6 ae0-0.bbr02.anx04.vie.at.anexia-it.net (144.208.208.129) 10.593 ms 10.567 ms 10.746 ms
    7. 7 win-b2-link.telia.net (62.115.13.118) 10.422 ms s-bb3-link.telia.net (213.155.130.49) 30.659 ms s-bb4-link.telia.net (62.115.112.99) 23.198 ms
    8. 8 s-b5-link.telia.net (62.115.137.159) 25.578 ms win-bb4-link.telia.net (62.115.137.200) 19.614 ms win-bb3-link.telia.net (62.115.120.108) 12.553 ms
    9. 9 ioc-x1-104.telia.net (80.239.194.151) 26.769 ms ffm-bb3-link.telia.net (62.115.137.202) 13.637 ms ffm-bb4-link.telia.net (62.115.138.22) 13.409 ms


    Weitere Theorie die vermutlich eher zutreffen könnte, HE bietet grundsätzlich kostenfreien IPv6-Transit über IX an, ECIX ist hiermit günstiger als der kostenpflichtige Upstream über v6 direkt bei netcup.

    Das spielt bei einem Ziel bei HE allerdings keine Rolle. Bei anderen IPv6-Zielen präferiert netcup in der Tat oft HE.