Facebook Videos ruckeln

Bei meinem Internetzugang zu Hause habe ich seit einiger Zeit das Problem, dass Videos auf Facebook angefangen haben zu ruckeln. Wie jeder sich das sicherlich gut vorstellen kann, ist das ziemlich unschön und es ist insbesondere noch nerviger, wenn man über einen langsamen Kupferanschluss, sonder über einen schnellen FTTH Anschluss verfügt.

Zuerst dachte ich, dass es ein Routing Issue bei meinem ISP sein könnte. Nach einer Konversation auf Twitter mit meinem ISP (hier nochmals ein „Danke“ für den schnellen und kompetenten Support) stellte sich heraus, dass es ein DNS Problem zu sein scheint. Offensichtlich liefert mein lokaler DNS Resolver (ich betreibe aus diversen Gründen meinen eigenen Resolver) in meinem LAN eine andere IP als Antwort, als der Resolver von meinem ISP.

Schauen wir uns dazu mal den DNS Eintrag zu www.facebook.com mal genauer an:

$ dig www.facebook.com AAAA
 
; <<>> DiG 9.9.8-P3 <<>> www.facebook.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4636
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5
 
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.facebook.com. IN A
 
;; ANSWER SECTION:
www.facebook.com. 2315 IN CNAME star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 38 IN AAAA 2a03:2880:f000:13:face:b00c:0:1823
 
;; AUTHORITY SECTION:
c10r.facebook.com. 2079 IN NS a.ns.c10r.facebook.com.
c10r.facebook.com. 2079 IN NS b.ns.c10r.facebook.com.
 
;; ADDITIONAL SECTION:
a.ns.c10r.facebook.com. 2519 IN AAAA 2a03:2880:fffe:b:face:b00c:0:99
a.ns.c10r.facebook.com. 2511 IN A 69.171.239.11
b.ns.c10r.facebook.com. 2152 IN AAAA 2a03:2880:ffff:b:face:b00c:0:99
b.ns.c10r.facebook.com. 2111 IN A 69.171.255.11
 
;; Query time: 1 msec
;; SERVER: 2a02:168:9800::4d#53(2a02:168:9800::4d)
;; WHEN: So Feb 28 12:14:46 CET 2016
;; MSG SIZE rcvd: 213

Wie man sehen kann, ist www.facebook.com ein CNAME auf star-mini.c10r.facebook.com. Die für c10r.facebook.com zuständigen Name Server sind a.ns.c10r.facebook.com und b.ns.c10r.facebook.com.

Kommt von meinem Resolver die Anfrage für star-mini.c10r.facebook.com an a.ns.c10r.facebook.com, so erhalte ich die IP 2a03:2880:f000:13:face:b00c:0:1823, welche nach Miami führt. So ist es auch nicht weiter verwunderlich, dass die Videos auf Facebook ruckeln, wenn die Daten von der anderen Seite des Atlantiks kommen. Zumal ist die Latenz mit 125 ms recht hoch.

Stelle ich den gleichen Request an Resolver meines ISPs (ns10.init7.net), so erhalte ich die IP 2a03:2880:f01c:21b:face:b00c:0:25de als Antwort. Diese IP steht in Frankfurt und bis dort hin ist die Latenz nur 7 ms.
Die gleiche Antwort erhalte ich auch vom zweiten DNS Resolver meines ISPs, ns20.init7.net.

Der Resolver ns20.init7.net scheint im Datacenter Layer One in Zürich zu stehen, also unmittelbar zu meinem Server, wo auch dieses Blog gehostet ist.

$ traceroute6 -Ia ns20.init7.net
traceroute6 to ns20.init7.net (2001:1620:2777:2::20) from 2001:1620:20a4::9, 64 hops max, 16 byte packets
 1 [AS13030] gw-dogan-init7.dogan.ch 42.454 ms 2.511 ms 7.324 ms
 2 [AS13030] ns20.init7.net 0.556 ms 0.553 ms 0.415 ms

In der Tat wirklich nahe. Kommt nun der Request von meinem Server im Layer One Datacenter, so erhalte ich die IP 2a03:2880:2040:7f21:face:b00c:0:25de zurück und die führt mich in die USA.

Dies ist wirklich spannend. Obwohl bis jetzt alle Requests aus dem gleichen AS und sogar aus dem gleichen Netz kamen, lieferte Facebook mir jedes mal eine andere IP zurück, wobei nur die Antwort der Resolver meines ISP, ns10.init7.net und ns20.init7.net, zum jeweils nächsten Facebook Server verwiesen.

Wie sieht es mit anderen ISPs und Resolvern aus?

Der Google Public DNS Resolver liefert mir die IP 2a03:2880:f008:1e:face:b00c:0:25de zurück (abgefragte aus AS 13030), welche in Mailand steht. 34 ms Latenz. Eine brauchbare Antwort.

Bei Swisscom sieht es ebenfalls ähnlich aus wie bei Init7: Stellt man den Request an den Resolver dns2.bluewin.ch, bekommt man die IP 2a03:2880:f007:1e:face:b00c:0:25de zurück und man landet in Wien. Stellt man den Request direkt an a.ns.c10r.facebook.com, bekommt man 2a03:2880:fffe:b:face:b00c:0:99 zurück und man landet in den USA.

Interessant ist es bei Solnet: Bei einer Anfrage an den Resolver soho.solnet.ch wird man nach Frankfurt (2a03:2880:f01c:21b:face:b00c:0:25de) geschickt. Bei einer direkten Anfrage an a.ns.c10r.facebook.com geht es nach Warschau (2a03:2880:fffe:b:face:b00c:0:99). Die Latenz nach Warschau ist mit 28 ms immer noch in einem sehr guten Rahmen.

Einzig beim Kieler Provider TNG bekommt man immer das gleiche Resultat: Egal ob man den Resolver des ISP oder a.ns.c10r.facebook.com fragt, man wird nach Frankfurt geleitet (2a03:2880:f01c:21b:face:b00c:0:25de).

 

Workaround

Möchte bzw. kann man nicht auf den eigenen Resolver verzichten und möchte nicht mit ruckelnden Videos auf Facebook konfrontiert werden, so kann man als Workaround die Anfragen für facebook.com und fbcdn.net an einen anderen Resolver schicken. Ich habe mich entschieden, die Anfragen an den Resolver meines ISPs weiter zu leiten – dazu ist in der unbound.conf folgende Anpassung notwendig:

forward-zone:
 name: "facebook.com."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"
 
forward-zone:
 name: "fbcdn.net."
 forward-addr: "2001:1620:2777:1::10"
 forward-addr: "2001:1620:2777:1::20"

Wie man sehen kann, konnte ich so die Latenz von 125 ms auf angenehme 7 ms reduzieren:

www_facebook_com_last_864000

Fazit

Bei allen ISPs wurde jeweils a.ns.c10r.facebook.com (der zuständige autoritative DNS server für  10r.facebook.com, Anycast) nach Frankfurt geroutet. Die erhaltene Antwort schickt jedoch den Browser mal in die USA oder mal nach Europa. Wird der Browser in die USA geschickt, kann das zu Problemen beim Abspielen von Videos auf Facebook führen. Dieses Verhalten ist für mich nicht nachvollziehbar und aus meiner Sicht scheint das Content Delivery Network von Facebook zu funktionieren. Einen Fehler mit Anycast oder Routing würde ich jedoch hier ausschliessen.

Generell ist zu empfehlen, wenn immer möglich den Resolver des ISPs zu verwenden.

Diesen Umstand habe ich dem technischen Support von Facebook gemeldet. Updates, werde ich wieder hier in meinem Blog posten.

Update  (1. März 2016)

Daniel Stirnimann hat mich darauf aufmerksam gemacht, dass das von mir beobachtete Verhalten ebenfalls mit Ripe Atlas beobachtet werden kann. In der folgenden Grafik wurde ping6 star-mini.c10r.facebook.com vom Atlas Probe ausgeführt, wobei der Hostname von der Probe selber aufgelöst wurde:
atlas_m1_ownresolve_ping

In der zweiten Grafik wurde ebenfalls ping6 star-mini.c10r.facebook.com ausgeführt, der Hostname wurde jedoch durch den Resolver des ISPs aufgelöst:
atlas_m2_ispresolve_ping

Wie man sehen kann ist das Resultat sehr unterschiedlich. Offensichtlich scheint Facebook Resolver von ISPs und kleinere Resolver anders zu behandeln

 

Anmerkung zu IPv4 & IPv6

Es gibt keinen Unterschied zu IPv4 und IPv6. Die Antworten zum A und AAAA Record stehen jeweils im Zusammenhang.

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Allgemein

Dateien nach UTF-8 konvertieren

Mit iconv können Dateien bequem auf UTF-8 konvertiert werden.

iconv -f <Quellkodierung> -t <Ausgabekodierung> <Datei> > <NeueDatei>

Beispiel:

$ iconv -f ISO-8859-1 -t UTF-8 muttrc > /tmp/muttrc
Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in FreeBSD

Solaris 10 Zone von Solaris 10 auf Solaris 11 Hostsystem migrieren

Solaris 11 unterstützt Solaris 10 branded Zones und bietet so eine Möglichkeit, bestehende Solaris 10 Zonen mit einem geringen Aufwand auf ein Solaris 11 Host System zu migrieren. Obwohl die Zone weiterhin sich wie eine Solaris 10 Zone verhalten wird, macht so eine Migration durchaus Sinn, da sich insbesondere die Administration der Zonen unter Solaris 11 wesentlich vereinfacht und man von neuen Funktionen wie der Netzwerkvirtualisierung profitieren kann. Insbesondere die Netzwerkvirtualisierung vereinfacht vieles, da sich die Zonen nicht. mehr einen IP Stack teilen müssen.

In diesem Beispiel gehe ich nicht darauf ein, wie eine Zone auf eine auf einen exklusiven IP Stack umkonfiguriert wird mittels Netzwerkvirtualisierung. Hierfür möchte ich auf ein hervorragendes Whitepaper von Oracle hinweisen: Exploring Network Virtualization With Oracle Solaris Zones on Oracle Solaris 11 Express

Bevor es los geht, muss man sich einer Einschränkung bewusst sein: Es können nur Full Root Zonen migriert werden!Die mit Solaris 10 eingeführten Sparse Zonen, wo Pakete vererbt wurden und Teile des System geteilt wurden ist in der Theorie sicher eine gute Idee gewesen. In der Praxis stellte sich jedoch heraus, dass der Umgang mit Sparse Zonen sehr problematisch ist, weshalb Oracle mit Solaris 11 nur noch Full Root Zonen unterstützt.

Als Vorbereitung muss auf dem bestehenden Solaris 10 System die Zone heruntergefahren werden. So bald die Zone ausgeschaltet ist, kann daraus ein Backup mit cpio erstellt werden. Hierfür, begibt man sich auf der Shell in das Verzeichnis, wo die Zone installiert ist (z.B. /zones ).

# find dognchgresv01 -print | cpio -oP@ | gzip >dognchgresv01.cpio.gz

Anschliessend kopiert man das File dognchgresv01.cpio.gz auf die neue Solaris 11 Maschine.

Auf der Solaris 11 muss als erstes die Unterstützung für Solaris 10 Branded Zones installiert werden:

# pkg install SUNWs10brand

Anschliessend kann die Zone erstellt und konfiguriert werden:

# zonecfg -z dognchgresv01 
dognchgresv01: No such zone configured
Use 'create' to begin configuring a new zone.
zonecfg:dognchgresv01> create -t SUNWsolaris10
zonecfg:dognchgresv01> set zonepath=/zones/dognchgresv01/zoneroot
zonecfg:dognchgresv01> add net
zonecfg:dognchgresv01:net> set address=192.168.42.171
zonecfg:dognchgresv01:net> set physical=nge0
zonecfg:dognchgresv01:net> end
zonecfg:dognchgresv01> verify
zonecfg:dognchgresv01> commit
zonecfg:dognchgresv01> exit

Anmerkung
Wenn die bestehende Solaris 10 Zone über ZFS Datasets verfügt, müssen diese getrennt auf das neue System kopiert werden. Wie das geht, habe ich in einem früheren Blog Artikel beschrieben.

Um das Dataset dann einzubinden, muss die Zonenkonfigration entsprechend angepasst werden:

zonecfg:dognchgresv01> add dataset
zonecfg:dognchgresv01:dataset> set name=rpool1/zones/dognchgresv01/dataset01
zonecfg:dognchgresv01:dataset> end

Sobald die Zone konfiguriert ist, kann mit dem cpio Backup die neue Zone erstellt werden:

# zoneadm -z dognchgresv01 attach -a dognchgresv01.cpio.gz

Zum Abschluss muss die migrierte Zone nur noch gebootet werden:

# zoneadm -z dognchgresv01 boot
Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Solaris

TLSv1.2 mit Firefox

Firefox unterstützt seit der Version 24 TLSv1.2. Während TLSv1.2 bei Chrome standardmässig aktiv ist, muss man TLSv1.2 bei Firefox manuell einschalten. Leider gibt es hierfür keinen Menupunkt und muss im about:config manuell eingeschaltet werden.

In der URL Bar

about:config

eingeben und die Warnung bestätigen.
Anschliessend nach

security.tls.version.max

suchen.

Die Zahlenkodierung lautet hier:

0: SSL 3.0 
1: TLS 1.0 
2: TLS 1.1 
3: TLS 1.2

Setzt man den Wert von 1 (default) auf 3, spricht Firefox auch TLSv1.2.

Die gleiche Zahlenkodierung gilt auch für security.tls.version.min um die minimale TLS/SSL Version zu setzen. Default ist hier 0, also SSLv3.0.

Quelle: Security.tls.version.*, mozillaZine

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Netzwerk

Smokeping & nginx auf FreeBSD

Smokeping wechselte mit der Version 2.5 von mit der auf dem CGI Protkoll basierenden Erweiterung SpeedyCGI auf FastCGI. Somit ist es nun möglich, Smokeping direkt mit nginx über spawn-fcgi zu betreiben ohne die umständlichen Workarounds wie SimpleCGI oder FcgiWRAP.

Für Installation werden folgende Pakete benötigt:

  • www/nginx
  • net-mgmt/smokeping
  • www/spawn-fcgi

Ist Smokeping über /usr/local/etc/smokeping/config konfiguert und gestartet worden, kann es zu Konfiguation des Webserver übergehen.

Der Smokeping FastCGI Prozess wird über spawn-fcgi gestartet und die Kommunikation zum FastCGI Prozess erfolgt über einen Unix Socket /tmp/smokeping-fastcgi.sock. Hierfür sind folgende Einträge in der /etc/rc.conf nötig:

spawn_fcgi_enable="YES"
spawn_fcgi_app="/usr/local/smokeping/htdocs/smokeping.fcgi"
spawn_fcgi_bindsocket="/tmp/smokeping-fastcgi.sock"

Anschliessend kann spawn-fcgi gestartet werden:

# /usr/local/etc/rc.d/spawn-fcgi start

Mit dem folgenden Eintrag in der Server Sektion der /usr/local/etc/nginx/nginx.conf ist Smokeping über die URL /smokeping/ erreichbar:

location /smokeping/ {
         alias /usr/local/smokeping/htdocs/;
         index smokeping.fcgi;
}
location /smokeping/smokeping.fcgi {
         fastcgi_pass unix:/tmp/smokeping-fastcgi.sock;
         include /usr/local/etc/nginx/fastcgi_params;
}
Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in FreeBSD, Netzwerk

UTF-8 mit FreeBSD

Während viele Linux Distributionen seit Jahren UTF-8 als default Zeichensatz haben, ist dies bei FreeBSD nicht der Fall. UTF-8 als default Zeichensatz macht durchaus Sinn und kann äusserst einfach eingeschaltet werden.

Die verfügbare Locale kann man sich wie folgt anzeigen lassen:

# locale-a

Für die Schweiz heisst die Locale de_CH.UTF-8. Diese muss nun in der /etc/login.conf im default Profil eingetragen werden.

:charset=UTF-8:\
:lang=de_CH.UTF-8:

Zum Abschluss muss die von System verwendete Daten aktuallisiert werden:

# cap_mkdb /etc/login.conf

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in FreeBSD

pfSense mit Swisscom FTTH

Wer zu den glücklichen zählt und bereits einen Glasanschluss von Swisscom zu Huase, dürfte von der Swisscom einen Centro Router (Update 30. Mai 2015: einen Internet Box Router) erhalten. Für die meisten Benutzer dürfte dieser Router vollkommen ausreichen. Möchte man jedoch die Möglichkeiten des FTTH Anschlusses voll ausschöpfen, bietet sich da pfSense an, eine auf FreeBSD basierende Firewall Distribution.

Um den Glas Anschluss überhaupt mit pfSense benutzen zu können, benötigt man einen Media Converter (1310 nm TX/1550 nm RX, Simplex Single Mode Fiber), wie beispielsweise den Planet FT-806A20, welchen man bei Techmania für gut 100 Fr. bekommt.

Zusätzlich zum Media Converter benötigt man ein Interface, welches VLAN Tagging beherrscht, wie z.B. die Intel 1000 Karten.

Hat man die Hardware zusammen, kann es zur Konfiguration gehen:Auf dem WAN Interface ein VLAN mit der ID 10 konfigurieren. Der Traffic nach draussen darf ausschliesslich nur über das VLAN ID 10 gehen.

Anschliessend muss die DHCP Option 60 korrekt gesetzt werden. Leider kann man mit der akutellen pfSense 2.1 Version diese Option nicht übers Webinterface setzen, weshalb diese Option manuell gesetzt werden muss. Hierfür editieren wir das File /etc/inc/interfaces.inc und suchen die Stelle, wo das dhclient.conf erstellt wird.

$dhclientconf .= <<<EOD
interface "{$wanif}" {
timeout 60;
retry 1;
select-timeout 0;
initial-interval 1

In die Interface Definition setzt man die DHCP Option:

send dhcp-class-identifier "100008,0001,,pfSense dhclient 2.1";

Und so sollte die Stelle dann aussehen

$dhclientconf .= <<<EOD
interface "{$wanif}" {
send dhcp-class-identifier "100008,0001,,pfSense dhclient 2.1";
timeout 60;
retry 1;
select-timeout 0;
initial-interval 1

Zum Abschluss muss die Firewall neu gestartet werden.
Wenn alles korrekt gemacht wurde, sollte nun die Option 60 korrekt gesendet werden.

Screenshot from 2013-10-15 141210

Anmerkung

  • Wenn man die NanoBSD Version verwendet, muss das / zuerst read/write gemountet werden. Wie das geht, ist hier beschrieben.
  • Schliesst man die pfSense direkt an den FTTH Anschluss und schickt DHCP Requests ohne die Option 60, wird der Anschluss für ca. 60 Minuten gesperrt.

 

Update (30. Mai 2015)

Um Gigabit Speed zu nutzen, benötigt man einen TP-Link MC220L Media-Converter, den man für für weniger als 30 Franken bekommt – siehe Toppreise.

Im Gegensatz zum weiter oben erwähnten 100 MBit Media Converter Planet FT-806A20, benötigt man beim TP-Link MC220L ein SFP Modul, welches man sich extra beschaffen muss. Wenn man von der Swisscom den Internet Box Router erhalten hat, kann man das mitgelieferte SFP Modul im TP-Link MC220L benutzen.

Falls man kein SFP Modul hat, muss man sich eines mit den oben genannten Spezifikationen beschaffen. Die Wellenlänge ist für 100 MBit und Gigabit die gleiche.

Für die Konfiguration von pfSense für Swisscom TV und 6rd für IPv6, hat TuxOne einen einen Beitrag in seinem in seinem Blog erstellt.

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in FreeBSD, pfSense

WeSunSolve.net geschlossen

WeSunSolve.net, eine Seite welche SunSolve ähnelte um Solaris Patches zu suchen, musste diesen Monat aufgrund einer Anfrage Oracle seine Tore schliessen. Schade.

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Solaris

IPv6 Entwicklungsland Schweiz

Heute fand der zweite von der Internet Societe organisierte World IPv6 Launch Day statt. Ziel dieser Veranstaltung ist es nicht nur IPv6 in einem grösseren Ausmass testen zu können, sondern auch darauf hinzuweisen, dass es langsam mit IPv4 Adressen knapp wird.
Während die bekannten Internet  wie Google, Yahoo, Akamai und Facebook an diesem Test teilnehmen, habe ich den heutigen Tag zum Anlass genommen, mir die Situation in der Schweiz anzusehen.

Angefangen habe ich mit den grössen der Schweizer Wirtschaft, den Unternehmen welche im Swiss Market Index gelistet sind:

ABB
Actelion
Adecco
Credit Suisse
Givaudan
Holcim
Julius Bär
Nestlé
Novartis
Richemont
Roche
SGS
Swatch Group
Swiss Re
Swisscom
Syngenta
Transocean
UBS
Zurich

Die Swisscom war heute als einziges SMI Unternehmen per IPv6 erreichbar.

Weiter ging es mit Internet Providern, Hostern und anderen Internet nahen Organisationen:

Sunrise
Orange
Cablecom
Init7
Quickline
Cyberlink
Solnet
VTX
Cyon
Hostpoint
Switch

Zum Schluss einige viel besuchte Schweizer Webseiten:

NZZ
20 Minuten
Tages Anzeiger
Le Matin
SBB
Bund
Migros
Coop

Gerade mal 4 Unternehmen bzw. Organisationen waren heute neben IPv4 auch mit IPv6 erreichbar. Dieses ernüchternde Resultat zeigt, dass es in der Schweiz IPv4 in vielen Unternehmungen nach wie vor keine hohe Priorität hat, obwohl die IANA keine IPv4 Adressen mehr zu vergeben hat.

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Allgemein

Solaris HCL hat ein neues zu Hause

Oracle hat im Zuge der Abschaltung der sun.com Domain der Hardware Compatibility Lists ein neues zu Hause gegeben und ist neu unter http://www.oracle.com/webfolder/technetwork/hcl/index.html erreichbar.

Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone
Veröffentlicht in Solaris