Probleme mit Mobilen (Android) Devices seit Rheinland Backbone in Münster

Community Münsterland
21

Vielleicht ist es ja das Problem, dass in Münster das DNS einfach nur kaputt ist, zwei von drei Resolvern antworten nicht (sind auch nicht pingbar):

18:55:19.825259 IP6 2a03:2260:115:0:517b:212c:857:94b.57451 > 2a03:2260:115::4.53: 40091+ A? www.msftncsi.com. (34)
18:55:22.507100 IP6 2a03:2260:115:0:517b:212c:857:94b.59978 > 2a03:2260:115::4.53: 29468+ A? e10.whatsapp.net. (34)
18:55:30.613868 IP6 2a03:2260:115:0:517b:212c:857:94b.59978 > 2a03:2260:115::4.53: 29468+ A? e10.whatsapp.net. (34)
18:55:33.786990 IP6 2a03:2260:115:0:517b:212c:857:94b.54957 > 2a03:2260:115::4.53: 63144+ A? www.msftncsi.com. (34)
18:55:38.589387 IP6 2a03:2260:115:0:517b:212c:857:94b.54959 > 2a03:2260:115::4.53: 8400+ A? e10.whatsapp.net. (34)
19:38:01.260401 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.57117 > 2a03:2260:115::4.53: 50154+ AAAA? firmware.ffms. (31)
19:38:01.260780 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.57117 > 2a03:2260:115::5.53: 50154+ AAAA? firmware.ffms. (31)

Beide Hosts: 2a03:2260:115::4 und 2a03:2260:115::5 werden als DNS Server announced, funktionieren aber nicht.

Ich sehe gerade, jetzt gibt es einen 2a03:2260:115::2 der auch nicht funktioniert:

15:12:19.247551 IP6 2a03:2260:115:0:12fe:edff:feaf:bbbc.54787 > 2a03:2260:115::2.53: 39628+ A? firmware.ffms. (31)

Die durch die DNS Dysfunktionalität eintretende Entschleunigung dürfte die „User Experience“ nicht sehr gut ausfallen lassen.

Andere Dineste (System Upgrade) stehen nun ohnen DNS da und funktionieren gar nicht mehr:

# autoupdater
wget: bad address 'firmware.ffms'
There seems to have gone something wrong downloading the manifest from http://firmware.ffms/firmware/experimental/sysupgrade
No usable mirror found.
22

Kann ich bestätigen. Gestern habe ich mich noch geärgert, dass die das Update auf 5.0 noch nicht veröffentlicht haben. Jetzt bin ich ganz froh.

1 „Gefällt mir“
23

Version 5 macht jetzt wohl IPv6. Alle nichtantwortenden Resolver werden per IPv6 ICMP Router Advertisement (Type 134) announced:

15:52:23.868806 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 88) fe80::9085:a3ff:fe6c:730 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 88
    hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): 2a03:2260:115::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
      rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a03:2260:115::2
      mtu option (5), length 8 (1):  1280
      source link-address option (1), length 8 (1): de:cd:41:45:f9:9d
15:52:23.918032 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::94c2:e1ff:fe61:9974 > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
    hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): fd68:e2ea:a53::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
      prefix info option (3), length 32 (4): 2a03:2260:115::5/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
      rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a03:2260:115::5
      mtu option (5), length 8 (1):  1280
      source link-address option (1), length 8 (1): 0a:4f:0b:db:d6:fc
15:52:24.041943 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 120) fe80::942a:a5ff:fed5:aa4a > ff02::1: [icmp6 sum ok] ICMP6, router advertisement, length 120
    hop limit 64, Flags [other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
      prefix info option (3), length 32 (4): fd68:e2ea:a53::/64, Flags [onlink, auto], valid time 86400s, pref. time 14400s
      prefix info option (3), length 32 (4): 2a03:2260:115::/64, Flags [onlink, auto, router], valid time 86400s, pref. time 14400s
      rdnss option (25), length 24 (3):  lifetime 600s, addr: 2a03:2260:115::4
      mtu option (5), length 8 (1):  1280
      source link-address option (1), length 8 (1): 6e:43:81:b5:c2:a1
24

Schlussendlich war das ganze ein IPv6 Routing Problem.
Das Routing ist jetzt gefixt und von unseren Testgeräten aus war funktioniere jetzt alles.

@labmaster @heerde könnt Ihr das von Eurer Seite bestätigen ?

2 „Gefällt mir“
25

Was genau ist der fix und auf welcher Ebene? Sitze in Stuttgart und habe vermutlich das gleiche Problem mit meinen 5.0 Geräten…eine Beschreibung der Lösung wäre toll.

Gruß

T

26

Ja, klappt alles soweit lokal und global. Eine einzigste Sache geht noch nicht:

# ping -c 3 ntp.ffms
PING ntp.ffms (fd68:e2ea:a53::11): 56 data bytes
--- ntp.ffms ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss

Wie sieht der Fix denn konkret aus? Tabelle 42 korrekt befüllt?

1 „Gefällt mir“
27

Kann auch bestätigen, dass es auf meinem Nexus 4 mit Android 5 nun wieder funktioniert.

2 „Gefällt mir“
28

Die IPv6 Routen auf den Gateways wurden von bird nicht richtig befüllt.

Wir haben die bird6.conf entsprechend überarbeitet und die Routen werden jetzt passend gesetzt.
Die Dokumentation kannst du hier in unserem Wiki finden.

Die Routing Tabelle auf den Gateways ist jetzt vollständig:

2a01:4f8:150:8ff8::/64 dev eth0  proto bird  metric 1024
2a03:2260:0:3e::/64 dev tun-ffrl-fra  proto bird  metric 1024
2a03:2260:0:3f::/64 dev tun-ffrl-dus  proto bird  metric 1024
2a03:2260:115::/48 dev br0  metric 1024
default via fe80::200:5efe:b942:c201 dev tun-ffrl-fra  proto bird  metric 1024
29

Super. Habe ich mir mal angeschaut. Dabei ist mir folgendes aufgefallen. Ihr bindet das gesamte /48 Subnet an br0. (Ein /48 ist sehr groß, nämlich 2^16 = 65 536 /64-Subnetze.) Das ist so nicht empfohlen. (IPv6 ist an diversen Stellen subtil anders als IPv4.) Laut RFC5375 „3.1. Considerations for /64 Prefixes“:

Based on RFC 3177, 64 bits is the prescribed subnet prefix length to allocate to interfaces and nodes. … Note that RFC 3177 strongly prescribes 64-bit subnets for general usage, and that stateless autoconfiguration on most link layers (including Ethernet) is only defined for 64-bit subnets. While in theory it might be possible that some future autoconfiguration mechanisms would allow longer than 64-bit prefix lengths to be used, the use of such prefixes is not recommended at this time.

Best Practice ist soweit wie ich mich erinnere folgendendes Vorgehen:

Anlegen einer Blackhole Route für sein eigenes /48-Subnet. Am besten gleich, wenn das lo-Interface konfiguriert wird:

iface lo inet loopback
    up ip route add blackhole 2a03:2260:115::/48 dev ${IFACE}

Dann einfach das br0 Interface als /64 konfigurieren:

iface br0 inet6 static
        address 2a03:2260:115::z
        netmask 64

Die anderen übrigen Netzte 2a03:2260:115:1::/64 - 2a03:2260:115:ffff/64 können dann per Routing woanders hin geroutet werden und dort genutzt. Da diese Routen more specific sind, übersteueren sie die blackhole-Route.

1 „Gefällt mir“
30

Ja das klingt durchaus sinnvoll.

Ich werde das mal abstimmen ob wir das so übernehmen können.

31

Jap, oder halt unmittelbar im Bird / Quagga…