Ich hatte lange Zeit ein schwer fassbares Problem mit meinem Netzwerk.
Ich habe den Router und den Zugriffspunkt gewechselt und kabelgebundene drahtlose Verbindungen hergestellt, um nach einem Leistungsdieb zu suchen, ohne der Frage, was mit meinem Setup nicht stimmt, näher zu kommen.
Das Problem ist so vage wie „das Netzwerk fühlt sich langsam an“ und kein bestimmtes Symptom des Problems war hartnäckig genug, um die Grundursache zu finden.
Meine aktuelle Infrastruktur besteht aus:
Eine pfsense-virtuelle Maschine, die auf esxi läuft. Derzeit läuft nur diese VM auf dem Host (Proliant ML110, Core 2 Duo), um die anderen VMs als Leistungsfresser zu eliminieren. Der Server hat zwei Netzwerkkarten, eine für WAN und eine für LAN.
Drei Procurve 1800/1810 8- und 24-Port-Switches. Zwei VLANs, eines für LAN und eines für WAN.
Ein Ubiquiti Unifi UAP-AC.
Dieses Netzwerk versorgt etwa 20 Einheiten mit Konnektivität.
Gestern gab es ein hartnäckigeres Problem, bei dem ich einen Film auf Netflix nicht starten konnte. Ein bisschen googeln brachte michHiernachdem mir der Netflix-Support mitgeteilt hatte, dass das Problem nicht bei ihnen, sondern bei meinem ISP liege.
Die Beschreibung dort trifft gut auf meine Probleme zu, der Start der App ist sehr langsam, die Wiedergabe funktioniert nicht immer.
Ich habe versucht, das Apple-TV abzustecken und mein Macbook mit demselben Kabel anzuschließen. Auf dem Computer funktionierte Netflix problemlos. Bei einem Geschwindigkeitstest mit demselben Kabel konnte ich feststellen, dass meine Bandbreite 100 Megabit in beide Richtungen beträgt. Als ich das Apple-TV wieder anschloss, funktionierte Netflix nicht.
Durch die Änderung des VLAN am Port, an dem das Apple-TV angeschlossen ist, vom LAN zum WAN wurde eine direkte Verbindung zum Internet über eine öffentliche IP hergestellt, mit der der Film problemlos gestreamt werden konnte.
Die Wiedergabe im LAN schlug erneut fehl. Ich trennte alles außer dem Apple-TV und dem Uplink vom Switch. Ging zum Switch mit dem eingehenden Internet und trennte alles außer den beiden PFSense-Ports, der Verbindung zum Glasfaserkonverter und dem Uplink zum Switch mit dem Apple-TV. Danach konnte die Wiedergabe gestartet werden.
Folglich dachte ich, ich müsste in der Lage sein, den Störenfried zu lokalisieren, indem ich alles wieder anschließe und sehe, welches Kabel die Wiedergabe unterbricht. Bei keinem klappte es. Als alles wieder angeschlossen war, funktionierte alles wieder.
Das ist meine Erfahrung jedes Mal, wenn ich versuche, herauszufinden, warum meine Verbindung schlecht funktioniert. Bei 100 bidirektionalen Megabits sollte es ziemlich flott sein, aber ich habe das WLAN auf meinem Handy mehrmals ausgeschaltet, weil 4G schneller ist. Der Speedtest zeigt immer 100 Megabits an.
Besonders schwierig scheint das Streaming zu sein, die Spiegelung meines Bildschirms über Airplay ist praktisch nutzlos. Das Abspielen von Musik mit derselben Technologie funktioniert, aber es kommt häufig zu Wiedergabestörungen.
Während gestern das Umgehen der Firewall darauf hindeutete, dass die Firewall der Betrüger ist, ist heute das Gegenteil der Fall:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
real 2m23.383s
user 0m0.046s
sys 0m0.253s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..100}; do ping -c 1 -s 1600 -M dont google.se > /dev/null; done
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
real 0m52.497s
user 0m0.054s
sys 0m0.253s
Um außerdem zu versuchen, die MTU für das Netzwerk zu überprüfen (gemäß der Theorie des Apple-Forums), habe ich versucht, mit verschiedenen Paketgrößen einen Ping aus dem WAN durchzuführen. Meine Tests zeigten, dass große Pakete das Netzwerk nicht gut durchquerten:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1500 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (64.233.163.94) 1500(1528) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.015s
user 0m0.003s
sys 0m0.003s
Einige Experimente scheinen zu bestätigen, dass die MTU im WAN tatsächlich 1500 beträgt:
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1472 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.497/4.497/4.497/0.000 ms
PING google.se (216.58.209.131) 1472(1500) bytes of data.
72 bytes from arn09s05-in-f3.1e100.net (216.58.209.131): icmp_seq=1 ttl=59 (truncated)
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 4.454/4.454/4.454/0.000 ms
real 0m0.034s
user 0m0.003s
sys 0m0.003s
$ ip addr show dev eth0 | grep "inet\b" && time for i in {1..2}; do ping -c 1 -s 1473 google.se ; done
inet 80.216.153.211/22 brd 80.216.155.255 scope global eth0
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
PING google.se (216.58.209.131) 1473(1501) bytes of data.
--- google.se ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms
real 0m20.018s
user 0m0.001s
sys 0m0.007s
Im LAN liegt der Haltepunkt bei derselben Paketgröße, aber ich muss manuell angeben, dass ich keine Fragmentierung zulasse, damit das Paket nicht kaputtgeht:
$ ip addr show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 68:b5:99:e7:07:a8 brd ff:ff:ff:ff:ff:ff
inet 10.11.12.162/24 brd 10.11.12.255 scope global eth0
valid_lft forever preferred_lft forever
inet6 fe80::6ab5:99ff:fee7:7a8/64 scope link
valid_lft forever preferred_lft forever
$ ping -c 1 -s 3000 google.se
PING google.se (83.255.235.35) 3000(3028) bytes of data.
3008 bytes from 83.255.235.35: icmp_seq=1 ttl=61 time=82.3 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 82.324/82.324/82.324/0.000 ms
$ ping -c 1 -s 1472 -M do google.se
PING google.se (83.255.235.123) 1472(1500) bytes of data.
1480 bytes from cache.google.com (83.255.235.123): icmp_seq=1 ttl=61 time=74.7 ms
--- google.se ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 74.779/74.779/74.779/0.000 ms
$ ping -c 1 -s 1473 -M do google.se
PING google.se (83.255.235.35) 1473(1501) bytes of data.
ping: local error: Message too long, mtu=1500
--- google.se ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
Ich verstehe nicht, was mit meinem Netzwerk nicht stimmt, und ich weiß nicht, wie ich es weiter beheben kann. Bitte helfen Sie mir, meine Fehlerbehebung neu zu strukturieren, damit ich das Netzwerk ein für alle Mal von Geistern befreien kann.
BEARBEITEN, bezüglich meiner DNS-Einstellungen:
Wenn ich das richtig verstehe, bedeutet das, dass Googles Resolver nur als Fallback verwendet werden, wenn der vom ISP per DHCP zugewiesene Nameserver nicht verfügbar ist. Ist das richtig? Oder frage ich zufällig einen weit entfernten Nameserver nach Adressen?
Wie Sie unten sehen können, versucht pfsense zunächst, die Namensauflösung selbst durchzuführen, fragt dann und drittens den ISP und greift erst als vierte und fünfte Option auf Google zurück. Was mir durchaus vernünftig erscheint?
Das Apple TV hat per DHCP zugewiesene Netzwerkeinstellungen und verwendet das Gateway als Nameserver. Der DHCP-Server hat keine dedizierten DNS-Einstellungen, erbt aber die obige Nameserverliste:
BEARBEITEN, bezüglich der For-Schleife:
Der Grund dafür, dass ich Ping 100 Mal statt einmal mit 100 Paketen ausführe, ist/war, dass jedes Mal eine Namensauflösung durchgeführt werden soll, da es beim manuellen Ausführen von Ping sehr unterschiedlich lange zu dauern schien, bis es „gestartet“ war. Ich dachte, dass ich dieses Gefühl vielleicht deutlicher machen könnte, wenn ich die Aktion mit 100 multipliziere.
Vorausgesetzt, Ubuntu hat die folgende Konfiguration:
$ grep nameserver /etc/resolv.conf
nameserver 127.0.1.1
Dieser Gedanke ist vielleicht ein bisschen albern, aber …
BEARBEITEN, bezüglich Apple TV:
Ich habe das Apple TV auf die Werkseinstellungen zurückgesetzt. Ich habe das Gerät mehrmals vom Strom getrennt (manchmal mit nicht ganz so geringer Wut im Blut).
BEARBEITEN, pfSense:
Ich habe pfSense neulich auf die Werkseinstellungen zurückgesetzt und nur die wichtigsten Teile davon wieder aktiviert (DNS, DHCP, NAT, statische DHCP-Leases, ein paar Portweiterleitungen), aber gestern stoppte Netflix trotzdem mitten im Stream. Das Problem verschwand jedoch wieder, sodass ein Neustart des Films funktionierte.
Ich frage mich, ob Netflix DNS während des Streamens benötigt. Es fühlt sich an, als ob das bis dahin bereits erledigt sein sollte.
Und da der Server die neueste pfsense-Version (2.2.2) verwendet, verwendet erungebundenstandardmäßig.
Dass der Resolver die Auflösungen erfolgreich zwischenspeichert, lässt sich durch zwei aufeinanderfolgende Suchvorgänge mit dem Diagnosetool überprüfen:
Die unterschiedlichen Antworten verwirren mich jedoch.
BEARBEITEN, MTU:
Die MTU ist auf automatisch eingestellt.
BEARBEITEN, ATV-Geschwindigkeitstest:
Wenn man einen Geschwindigkeitstest auf dem Apple TV durchführt, wird auf dem pfsense das folgende Diagramm angezeigt:
Danach meldet das Apple TV „Test erfolgreich abgeschlossen“, aber nur für den Bruchteil einer Sekunde, dann ändert es sich zu:
Ich kann Netflix trotz des Fehlers nutzen.
Antwort1
Stellen Sie sicher, dass Sie den DNS-Server Ihres lokalen Internetdienstanbieters und nicht einen entfernten DNS-Dienst verwenden.
Die meisten Inhalte, die Sie auf Ihr Apple TV herunterladen oder streamen können, kommen über das Akamai CDN (Apple ist schon seit Ewigkeiten einer der größten Kunden von Akamai). Akamai findet den CDN-Edge-Knoten (Server), der Ihnen am nächsten ist, basierend darauf, woher Ihre DNS-Suche kommt, und Ihre DNS-Suche kommt im Allgemeinen von dem lokalen rekursiven/auflösenden DNS-Server, den Sie für die Verwendung Ihres Client-Geräts konfiguriert haben.
Stellen Sie sicher, dass Ihr Apple TV so eingestellt ist, dass es die DNS-Server Ihres lokalen ISPs verwendet und nicht einige möglicherweise weit entfernte Server wie Google DNS (8.8.8.8 und 8.8.4.4) oder Level 3 (4.2.2.x) oder OpenDNS oder ähnliche. Beachten Sie, dass Ihr Apple TV seine DNS-Einstellungen möglicherweise über DHCP erhält und Ihr DHCP-Server möglicherweise ein Prozess auf Ihrem Router/Gateway ist. Wenn der DHCP-Server Ihrem Apple TV mitteilt, die private IP-Adresse Ihres NAT-Gateways (oder einer anderen lokalen Firewall oder eines Routers) als DNS-Adresse zu verwenden, bedeutet dies, dass Ihr NAT-Gateway als DNS-Proxy fungiert. Wenn Sie dies weiterhin tun möchten, stellen Sie sicher, dass dieses NAT-Gateway die DNS-Server Ihres lokalen ISPs alses istDNS-Server.
Durch die Verwendung eines lokalen DNS-Servers weist Akamai Ihren Client an, Download-/Stream-Anfragen von Ihrem nächstgelegenen Akamai-Server in Schweden zu stellen und nicht etwa von einem Server in der Nähe eines Google-Rechenzentrums in den USA, wo sich der 8.8.8.8-DNS-Server von Google befindet.
[Auch wenn das nicht die richtige Antwort für Sie ist, kann es für andere, die diese Frage stellen, die richtige Antwort sein. Deshalb lasse ich sie trotzdem hier stehen.]