Das längste Thema

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

  • huch ja, falscher Monat, bin von ausgegangen da Felix ja was von gestern Abend gesprochen hatte ^^

    Bei den Verbindungen beim NGINX kann es gut auch sein, dass es nicht geschlossene sind, wegen bspw. Netzwerk fehlen.

    schon öfters gesehen :)

  • Traffic zu Google läuft jetzt wieder direkt von Nürnberg nach Frankfurt! :)


    Code
    root@v22017014*********:~# mtr -zw4c1 google.de
    Start: Fri Apr 20 11:26:33 2018
    HOST: v22017014*********                                 Loss%   Snt   Last   Avg  Best  Wrst StDev
      1. AS19754037.120.184.2                                0.0%     1    0.4   0.4   0.4   0.4   0.0
      2. AS47147 ae3-4018.bbr01.anx84.nue.de.anexia-it.net   0.0%     1    0.5   0.5   0.5   0.5   0.0
      3. AS47147 ae2-0.bbr02.anx25.fra.de.anexia-it.net      0.0%     1    4.0   4.0   4.0   4.0   0.0
      4. AS15169 209.85.149.86                               0.0%     1    3.9   3.9   3.9   3.9   0.0
      5. AS15169 108.170.251.193                             0.0%     1    3.9   3.9   3.9   3.9   0.0
      6. AS15169 216.239.54.61                               0.0%     1    3.7   3.7   3.7   3.7   0.0
      7. AS15169 fra16s18-in-f131.1e100.net                  0.0%     1    3.8   3.8   3.8   3.8   0.0
  • 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
    PING ae-5.r20.frnkge04.de.bb.gin.ntt.net (129.250.2.141) 56(84) bytes of data.
    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
    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
    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
    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
    PING ffm-bb3-link.telia.net (62.115.133.34) 56(84) bytes of data.
    64 bytes from 62.115.133.34: icmp_seq=1 ttl=244 time=23.8 ms
    64 bytes from 62.115.133.34: icmp_seq=2 ttl=244 time=24.0 ms
    64 bytes from 62.115.133.34: icmp_seq=3 ttl=244 time=23.8 ms
    64 bytes from 62.115.133.34: icmp_seq=4 ttl=244 time=23.9 ms
  • Fragt spf eigentlich nur den "@ TXT <spf>" record ab? Also kann ich als "sub TXT <spf2>" anlegen, ohne dass dies den Mailversand von der Domain beeinflusst? (Soll zum includen dienen, habe das gerne alles auf einer Domain)

  • Hat zufällig jemand eine Idee, warum mein OpenWrt immer eine Route zu einer bestimmten IPv4-Adresse (/32 dev <UPLINK>) selber anlegt?


    Die Ziel-IP wird für OpenVPN und einen 6in4 Tunnel benutzt. Ich kann das Anlegen der Route aber nicht reproduzieren im laufenden Betrieb, egal welche Dienste oder Schnittstellen ich neu starte.


    Die Route bleibt bis zur manuellen Löschung bestehen, oder bis die dazugehörende Schnittstelle deaktiviert wird.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Hat zufällig jemand eine Idee, warum mein OpenWrt immer eine Route zu einer bestimmten IPv4-Adresse (/32 dev <UPLINK>) selber anlegt?


    Die Ziel-IP wird für OpenVPN und einen 6in4 Tunnel benutzt. Ich kann das Anlegen der Route aber nicht reproduzieren im laufenden Betrieb, egal welche Dienste oder Schnittstellen ich neu starte.


    Die Route bleibt bis zur manuellen Löschung bestehen, oder bis die dazugehörende Schnittstelle deaktiviert wird.

    Hallo,

    Ich tippe mal auf die interne OVPN-Config - bevor die irgendwelche Routen ändert, und sich selbst das Wasser abschneidet.


    Viele Grüße

    margau

  • Ich tippe mal auf die interne OVPN-Config

    Wäre auch meine Vermutung, aber wieso kann ich es dann nicht reproduzieren? restart/stop/start vom Dienst zeigt keine neue Route an, wenn sie zuvor manuell gelöscht wurde.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich tippe mal auf die interne OVPN-Config

    Scheint nicht der Fall zu sein. Es wird eindeutig durch den Start vom 6in4 Interface ausgelöst und nicht von OpenVPN. Ich kann es auf einem anderen Gerät mittlerweile reproduzieren – auch im laufenden Betrieb. Bleibt nur noch die Frage, wie man dieses Verhalten abstellen kann. So sinnvoll das in 99% der Fälle ist, bei meinem speziellen Setup nervt es gerade gewaltig. Wenn die Route wenigstens durch ein explizites ifdown/ifup gelöscht oder aktualisiert werden würde, wäre es nicht so schlimm, aber so ist das ein Murks…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Bleibt nur noch die Frage, wie man dieses Verhalten abstellen kann.

    Wozu lange ärgern, einfach Quick & Dirty… ^^


    Die vollständige Version gibt es hier: https://github.com/froonix/ope…ug.d/iface/59-sit-routing

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    2 Mal editiert, zuletzt von KB19 ()