Probleme beim Benutzen von Webseiten und Diensten über FFRL-Tunnel

Technik FFRL Backbone
21

Es wäre hilfreich, die Probleme von den Symptomen möglichst exakt zu umreissen, um dann zu schauen, an welcher Stelle die Probleme bestehen.

Ich könnte mir vorstellen

  • Peering FFRL in Richtung x und y
  • unterschiedliches Routing für NAT-IPv4s, die in Berlin oder in Frankfurt(?) nativ beheimatet sind
  • Packetloss in der IPv6-Anbindung des FFRL
  • pmtu/mssclamping-foo abhängig vom Supernode der Community.

mtr dediziert auf -4 und -6 zu fraglichen Zielen könnte helfen. Notfalls auch noch noch Paketgrößen -s forcen.

22

Ich versuche es nachvollziehbar zu dokumentieren.

23

Lippe ist gem. Münsteraner Ansible aufgesetzt: brX für Domäne X, NAT auf die FFRL-IP, d. h. es müßte aus allen Domänen gleich gut oder schlecht tun. (2 GWs, alle haben alle 4 Domänen, Tunneldigger.)

24

4 Gateways

GW1: Domäne 1+2
GW2: Domäne 1+2
GW3: Domäne 3+4
GW4: Domäne 3+4

Ansonsten stimmt die Beschreibung von wusel.

1 „Gefällt mir“
25

Moment, Du sagst Probleme bei Dom 3&4, die liegen aber nur auf GW 3&4 — nutzen die den gleichen FFRL-Endpunkt wie 1&2? Siehe Hinweis von @adorfer.

26

Ich kenne kenne die IPv4er nicht, wir haben Communities die IPs aus verschiedenen Orten haben, siehe

27

Nein, die haben unterschiedliche Exit-Tunnel.

28

Ja, aber geht das über den gleichen Weg via FFRL ins Internet?

Je GW: traceroute -s FFRLIP 9.9.9.9 => Weg jeweils identisch?

29

Wenn der Bird(4) den Traffic nach Düsseldorf priorisiert und der FFRL das erstmal nach Berlin schickt (weil dort die Exit-IP liegt), oder je nach Peering die Antworten über Berlin kommen, dann kann das je nach Peering-Foo zu anderen AS zu „komischen Effekten“ führen, die nur einzelne Exit-IPs betreffen.
(Und potentiell natürlich auch weitere Effekte, wenn’s richtig schlecht läuft)

P.S. mir ist ist klar, dass es jetzt noch n weitere Ausnahmen gibt. Die möchte ich jetzt aber nicht spekulativ alle aufführen, da sie kaum zur Wahrheitsfindung beitragen in diesem Moment.

30

Muss ich gleich testen, ich poste das Ergebnis hier.

31

Ack. @collimas, Gegencheck: von den Hosts aus traceroute auf die Exit-IPs, dann siehst Du, worüber die reinkommen? (FFRL hat sein /21 IIRC in 3 /24 mit Standortpräferenz aufgeteilt.)

32

Sehr interessant wäre, ob IPv6 auch betroffen ist oder nur „anders“.

33

Wenn Euer github-Repo aktuell ist, haben GW01/02 IPs aus DUS, GW03/04 aus FRA (185.66.193 vs 185.66.194) …

1 „Gefällt mir“
34

Ist aktuell.

35

Problem sollte nach Abschaltung der IPv4-BGP-Sessions zum FFRL für die FRA-IPs nun erstmal vom Tisch sein, da klemmt(e) mindestens das Routing zu Netcup (da läuft die Lippische Karten-VM); zumindest vom Testbed aus (je 1 Linux-VM „hinter“ (eigene Bridge auf dem Host) 1 Gluon-VM für Domäne 1 und 3) geht’s nun wieder:

root@fflip-dom3-vm:~# traceroute karte.freifunk-lippe.de
traceroute to karte.freifunk-lippe.de (193.31.25.58), 30 hops max, 60 byte packets
 1  10.15.32.4 (10.15.32.4)  11.909 ms  11.865 ms  11.991 ms
 2  185.66.195.0 (185.66.195.0)  26.556 ms * *
 3  * * *
 4  * * *
…
18  * * *^C

root@gw04 ~ # birdc disable ffrl_dus1; birdc disable ffrl_dus2; birdc disable ffrl_ber1; birdc disable ffrl_ber2
root@gw03 ~ # birdc disable ffrl_dus1; birdc disable ffrl_dus2; birdc disable ffrl_ber1; birdc disable ffrl_ber2

root@fflip-dom3-vm:~# traceroute karte.freifunk-lippe.de
traceroute to karte.freifunk-lippe.de (193.31.25.58), 30 hops max, 60 byte packets
 1  10.15.32.4 (10.15.32.4)  12.173 ms  12.144 ms  12.100 ms
 2  192.168.1.8 (192.168.1.8)  13.426 ms  13.385 ms  13.338 ms
 3  * * *
 4  dtag.l105.community-ix.de (185.1.74.27)  33.325 ms  33.285 ms  55.006 ms
 5  217.239.48.2 (217.239.48.2)  37.879 ms  57.218 ms  40.390 ms
 6  gw-dtag.fra.netcup.net (80.157.204.242)  38.843 ms  35.782 ms  35.747 ms
 7  v22018083421772444.goodsrv.de (193.31.25.58)  35.705 ms  33.899 ms  33.860 ms

IPv6 scheint nicht betroffen, oder wenn, dann anders (und die Karte hat nur IPv4-DNS-Einträge).

Was sagen die Nutzer, @collimas? Bzw. was von …

… ist noch akut/reproduzierbar?

Lesson learned:

  • Setup-Beschreibung immer wieder hinterfragen, „die Probleme treten auch nur in 2 von 4 Domänen auf - alle Gateways sind identisch konfiguriert“ hat sich im Detail dann ja als nur quasi korrekt bzw. mißverständlich herausgestellt :wink:

    • Links auf Quelle für gescriptete Setups (Puppet, Ansible, …) können da hilfreich sein

  • Bei Upstreams, die geospezifische IPs vergeben (neben FFRL auch FFNW?) prüfen, ob die IPs wirklich alle aus einer Lokation stammen (sollten sie aus Redundanzgründen lieber nicht). Merksatz: Unterschiede außerhalb des letzten Oktetts (IPv4) oder in den ersten 48 Bit (IPv6) könnten auf unterschiedliche Lokationen hindeuten.

  • FTR: Traceroute zeigt nur, daß Winz-Pakete die Strecke passieren können. Für konkretere Aussagen müßte ein größerer Download (100 MB auswärts) aus dem fraglichen Zielnetz heruntergeladen werden (MTU/MSS-Probleme).

36

Soweit ich das überprüfen konnte, treten momentan keine Probleme mehr auf!

1 „Gefällt mir“