TNs Blog - Internet

Unechtes Multihoming

nospam@example.com (TN) — Wed, 30 Jun 2010 22:52:54 +0200

Letzthin bin ich über ein neues Gerät gestolpert, welches eine alte Idee des unechten Multihoming nun käuflich und pfannenfertig ermöglicht. Das Gerät von Viprinet macht mehrere Uplinks zu einem kombinierten Uplink, es benötigt natürlich eine Gegenstelle, den sie "Hub" nennen, welche diese individuellen VPN terminiert und das Bundling der Links macht.
Schöne Idee, allerdings etwas teuer. Aber sogar UMTS Uplinks können damit einbezogen resp. gebündelt werden.

Dynamisches Routing mit zwei Providern für Arme

nospam@example.com (TN) — Fri, 20 Mar 2009 22:03:16 +0100

Nun also der versprochene Beitrag zur technischen Umsetzung des automatischen outbound routings.
Ich habe also einen Uplink zu Provider A, dort eine statische IP Adresse 192.0.2.18, das Gateway des Providers hat die IP Adresse 192.0.2.17, Netzmaske 255.255.255.252.
Bei Provider B habe ich einen statischen 8-er Block, also z.B. 172.17.2.16/29, der Router zum Provider hat die IP Adresse 172.17.2.17, ich nutze für meinen Rechner daher 172.17.2.18 mit Netzmaske 255.255.255.248.

Nun richte ich als Router für mein internes Netzwerk ein NET5501 von Soekris ein, das hat 4 Netzwerk Ports. Dort baue ich ein Harddisk ein und installiere darauf ein Debian Lenny.

Vorbereitend müssen wir in /etc/iproute2/rt_tables zwei Tabellen definieren, wir nennen sie ispa und ispb:



#

# reserved values

#

255 local

254 main

253 default

0 unspec

#

# local

#

1   ispa

2   ispb

Ein Auszug aus /etc/network/interfaces für eth0, eth1, und eth2:



# Internes privates Netzwerk

auto eth0

iface eth0 inet static

        address 192.168.1.1

        netmask 255.255.255.0

        broadcast 192.168.1.255

        network 192.168.1.0



# Uplink zu Provider B

auto eth1

iface eth1 inet static

        address 172.17.2.18

        netmask 255.255.255.248

        broadcast 172.17.2.23

        network 172.17.2.16

        up /sbin/ip route add 172.17.2.16/29 dev eth1 src 172.17.2.18 table ispb

        up /sbin/ip route add 192.168.1.0/24 dev eth0 table ispb

        up /sbin/ip route add default via 172.17.2.17 table ispb

        up /sbin/ip rule add from 172.17.2.18 table ispb priority 200

        up /sbin/ip route flush cache



# Uplink zu Provider A

auto eth2

iface eth2 inet static

        address 192.0.2.18

        netmask 255.255.255.252

        broadcast 192.0.2.19

        network 192.0.2.16

        up /sbin/ip route add 192.0.2.16/30 dev eth2 src 192.0.2.18 table ispa

        up /sbin/ip route add 192.168.1.0/24 dev eth0 table ispa

        up /sbin/ip route add default via 192.0.2.17 table ispa

        up /sbin/ip rule add from 192.0.2.18 table ispa priority 100

        up /sbin/ip route flush cache

Man beachte, das kein Eintrag für ein Default-gateway eingetragen wurde, den das default-gateway will ich später aus dem dynamische Routing erhalten.
Es gibt jedoch für beide Interfaces Richtung Provider die Regeln welche bewirken, dass eine Verbindung von aussen auf die jeweilige statische IP Adresse, wieder von dieser IP Adresse via dieses Interface weggeschickt wird. Zugriffe auf die externen Adressen von einem Rechner aus meinem LAN muss natürlich wieder ins LAN, daher jeweils die zusätzliche route via eth0.

Nun kommt das dynamische Routing. Dazu brauche ich einen Host irgendwo draussen im Internet, wo ich vollen Zugriff habe. Ich gebe jenem Host mal die IP Adresse 172.22.22.22. Um die Verbindung zu diesem Host via beide Uplink Provider zu überwachen, muss ich eine Verbindung herstellen, welche durch das automatische Routing unbeeinflusst bleibt. Dies wird gelöst durch zwei OpenVPN Tunnels. Mein Router agiert als OpenVPN Server, wobei zwei verschiedene Konfigurationen auf jeweils einem Interface konfiguriert sind.

Es gibt also eine Datei /etc/openvpn/server-ispa.conf



local 192.0.2.18

port 1194

proto udp

dev tun

ca myCA.pem

cert myCert.pem

key myKey.pem

dh dh1024.pem

server 10.10.255.0 255.255.255.0

client-config-dir ccd

route 10.10.255.4 255.255.255.252

keepalive 5 45

tls-auth ta.key 0

cipher AES-128-CBC

comp-lzo

persist-key

persist-tun

Ebenso eine Datei /etc/openvpn/server-ispb.conf wo nur folgende Zeilen anders sind:



local 172.17.2.18

server 10.10.254.0 255.255.255.0

route 10.10.254.4 255.255.255.252

Im Verzeichnis /etc/openvpn/ccd machen wir noch zwei Dateien ispa-link:



ifconfig-push 10.10.255.5 10.10.255.6

und ispb-link:



ifconfig-push 10.10.254.5 10.10.254.6

Man muss natürlich die Zertifikate machen für die beiden OpenVPN-Links, was ich hier nicht weiter ausführe.

Damit kriegen wir auf unserem Router zwei weitere Netzwerk-Interfaces tun0 und tun1, welche jeweils je einen VPN Link via Provider A und Provider B zulassen.

Auf dem Rechner 172.22.22.22 im Internet setzen wir nun zwei OpenVPN Client-Konfigurationen auf,
also Datei /etc/openvpn/client-ispa.conf:



client

dev tun

proto udp

remote 192.0.2.18 1194

resolv-entry infinite

nobind

persist-key

persist-tun

ca myCA.pem

cert client-ispa-cert.pem

key client-ispb-key.pem

tls-auth ta.key 1

cipher AES-128-CBC

comp-lzo

Entsprechend natürlich auch eine Datei client-ispb.conf, wo folgende Dinge entsprechend ersetzt werden:



remote 172.17.2.18 1194

cert client-ispb-cert.pem

key client-ispb-key.pem

Nun haben wir also zwei dedizierte Verbindungen von Host 172.22.22.22 zu den beiden Interfaces 172.17.2.18 und 192.0.2.18 vom multihomed Router. Ueber diese Verbindungen werden nun BGP Verbindungen konfiguriert. Dazu wird auf beiden Hosts quagga installiert.

Auf dem Rechner 172.22.22.22 im Internet konfigurieren wir nur bgpd.conf:



hostname extern.example.domain

password veryhard



router bgp 64590

 bgp router-id 172.22.22.22

 neighbor 10.10.255.1 remote-as 64591

 neighbor 10.10.255.1 update-source 10.10.255.5

 neighbor 10.10.255.1 default-originate

 neighbor 10.10.255.1 route-map set-nexthop-ispa out

 neighbor 10.10.255.1 filter-list 1 in

 neighbor 10.10.255.1 filter-list 1 out

 neighbor 10.10.255.1 ebgp-multihop

 neighbor 10.10.254.1 remote-as 64591

 neighbor 10.10.254.1 update-source 10.10.254.5

 neighbor 10.10.254.1 default-originate

 neighbor 10.10.254.1 route-map set-nexthop-ispb out

 neighbor 10.10.254.1 filter-list 1 in

 neighbor 10.10.254.1 filter-list 1 out

 neighbor 10.10.254.1 ebgp-multihop



route-map set-nexthop-ispa permit 10

 set ip next-hop 192.0.2.17



route-map set-nexthop-ispb permit 10

 set ip next-hop 172.17.2.17



ip as-path access-list 1 deny .*

Auf unserem Router für das LAN sieht die BGP Konfiguration ebenso aus, ausser, dass natürlich die IP-Adressen und AS Nummern entsprechend anders rum sind:



hostname router.example.domain

password veryhard



router bgp 64591

 bgp router-id 192.168.1.1

 neighbor 10.10.255.5 remote-as 64590

 neighbor 10.10.255.5 update-source 10.10.255.1

 neighbor 10.10.255.5 route-map set-nexthop-ispa in

 neighbor 10.10.255.5 filter-list 1 out

 neighbor 10.10.255.5 ebgp-multihop

 neighbor 10.10.254.5 remote-as 64590

 neighbor 10.10.254.5 update-source 10.10.254.1

 neighbor 10.10.254.5 route-map set-nexthop-ispb in

 neighbor 10.10.254.5 filter-list 1 out

 neighbor 10.10.254.5 ebgp-multihop



route-map set-nexthop-ispa permit 10

 set ip next-hop 192.0.2.17

 set local-preference 120



route-map set-nexthop-ispb permit 10

 set ip next-hop 172.17.2.17

 set local-preference 110



ip as-path access-list 1 deny .*

Hier müssen wir auch ein zebra.conf machen, und zebra laufen lassen:



hostname router.example.domain

password veryhard



interface eth0

 description internal



interface eth1

 description ispb



interface eth2

 description ispa

Der Router erhält nun via BGP die default Route, wobei er mit Vorzug Provider A wählt aufgrund der local-preference. Wenn einer der beiden Links nun wegfällt, wird automatisch der andere genommen.

Das lokale LAN muss natürlich noch mit NAT versehen werden, dazu werden auf dem Router folgende Einträge gemacht:



iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT --to-source 172.17.2.18 

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth2 -j SNAT --to-source 192.0.2.18

Damit hat nun das interne LAN ein Multihoming für Arme. Der einzige Nachteil ist, dass bestehende Sessions einen Leitungsunterbruch nicht überleben.

Multihoming für Arme

nospam@example.com (TN) — Fri, 06 Mar 2009 01:37:02 +0100

Nachdem hier früher schon einmal Multihoming diskutiert wurde, habe ich mir wiederum ein Multihoming für Arme ausgedacht. Multihoming heisst, man ist via zwei verschiedene Internetdienstanbieter (ISP) mit dem Internet verbunden.
Ziel dieser Uebung ist:

Outbound den internen Traffic ins Internet via ISP1 oder ISP2 zu routen, mit Vorzug über jenen mit mehr Bandbreite, und beim Ausfall vom einen ISP automatisch wechseln auf den anderen.
Inbound die Dienste mittels DNS Round Robin zu verteilen, resp. redundant angebunden zu haben. Dies geht vorzüglich für DNS und e-mail, und in etwas reduziertem Masse auch für WWW-Dienste.

Nun also habe ich zwei Internetleitungen via zwei verschiedene Anbieter, vornehmlich mit statischer IP Adresse, jeweils die günstigste Variante. Nun macht aber kein Provider sauberes Multihoming, geschweige denn einen BGP Peer für kleine Fische wie mich. Solche echte Dinge gibt es nur für teurere Leitungen.
Inbound via DNS Dinge zu lösen (Punkt 2 oben) ist noch relativ einfach, da muss man nur einem Host auf zwei Netzwerk-Interfaces jeweils eine IP Adresse von je einem Provider geben, und das im DNS natürlich entsprechend abbilden. Wie man mit "ip route" das dann richtig konfiguriert steht unter anderem im Linux Advanced Routing & Traffic Control gut beschrieben.
Für den Punkt 1 von oben (automatisch outbound routen) muss nun also eine Lösung her. Mittels eines Routing-Protokolls, welche den Link zum Provider überwachen kann und bei Unterbruch automatisch die Route entfernt, könnte man das lösen. Da würde sich zum Beispiel BGP anbieten. Dabei gibt es jedoch einige knifflige Probleme zu lösen. Wie dies gelöst werden kann schreibe ich in einem weiteren Beitrag später.

Der Traum vom Glas ins Heim

nospam@example.com (TN) — Thu, 11 Dec 2008 00:12:37 +0100

Fibre to the home ist mal wieder im Gespräch, weil die Stadt Zürich ihren Glasausbau vorantreibt. Leider bleiben aber alle Nicht-Stadt-Orte aussen vor. Ich frage mich nur, wie man sagen kann, dass der Glasausbau als teuer bezeichnet werden kann, wenn man dann sich überlegt, einen Home-User Anschluss für unter 100 Franken anzubieten, während statische IP Angebote um Faktoren teurer sind. Eine statische IP macht ja nicht zwingend mehr Traffic. Eine LAN-Verbindung ins Datacenter und etwas Ueberbuchung im Transit wären da durchaus drinn, auch wenn das im erwähnten Artikel als unsinnig verneint wird.

Neues VoIP DECT Telefon ausprobiert

nospam@example.com (TN) — Mon, 30 Jun 2008 20:47:50 +0200

In der Firma haben wir verschiedene Drahtlos-Lösungen für VoIP ausprobiert. Unser Befund ist, dass Lösungen mit DECT Technologie nach wie vor besser tauglich sind als zum Beispiel WLAN, vor allem wenn sich der abzudeckende Bereich über ein grösseres Areal und mehrere Stockwerke erstreckt. Die analogen DECT Lösungen ergeben jedoch nur halbe Lösungen, da beim VoIP-analog Adapter wichtige Funktionen von VoIP verlorengehen. Nun hat Snom ein VoIP DECT Telefon herausgegeben, welches wir im operativen Einsatz testeten und für gut befunden haben, inklusive DECT Repeater. Die WLAN VoIP Telefone und SIP-analog Adapter werden daher bereits wieder ausgemustert.

Schweizer VoIP Provider mit IAX Anbindung

nospam@example.com (TN) — Sat, 22 Mar 2008 09:43:04 +0100

Um einen früheren Eintrag etwas zu revidieren will ich hier meine Erfahrungen mit dem VoIP Provider insphone ergänzen. Der bietet jetzt nämlich wie e-fon auch einen IAX-Trunk an, damit man die eigene IAX an die Welt anbinden kann. Das funktioniert wunderbar, inbound wie outbound, und man kann gleich noch seine Fixnetz-Nummer als Caller ID angeben, damit die Angerufenen die gewohnte und bekannte eigene Telefonnummer zu Gesicht bekommen.

Mit IAX die Telefonzentrale anbinden ist nämlich viel einfacher und sicherer, weil IAX in sich schon Verschlüsselung und Komprimierung enthält, und weil dazu nur ein einziger UDP Port verwendet wird, was die Behandlung in Firewalls viel einfacher macht.

Asterisk Telefonzentrale mit ISDN Anschluss

nospam@example.com (TN) — Wed, 02 Jan 2008 01:08:36 +0100

Endlich habe ich es geschafft, meine Telefonzentrale auf Basis von Asterisk zum laufen zu bringen.

Die Hardware besteht aus einem alten Pentium Computer, dem ich eine ISDN Karte von Beronet verpasst habe.
Als Software habe ich Debian Etch installiert. Dann noch die mISDN Treiber für die Beronet-Karte compiliert und Asterisk für chan_misdn befähigt. Das ging am besten mit dem Script von Beronets Homepage selbst.

Weil ich zu faul für einen Handarbeit-Dialplan bin, habe ich Apache2, MySQL und FreePBX installiert, um ein angenehmes Bedienungsinterface zu haben. Jetzt funktioniert so ziemlich alles, von raustelefonieren, reintelefonieren, intern telefonieren, und Konferenzschaltungen machen. Für die Caller ID guckt mir das Asterisk die Telefonnummer gleich in meiner Adressdatenbank nach. Für das Telefonbuch muss ich noch eine solche Verbindung zur Datenbank erst schaffen.

VoIP Provider meistens Bastelbuden

nospam@example.com (TN) — Wed, 26 Sep 2007 21:31:00 +0200

Im Zuge der ersten Erfahrungen mit Voice over IP macht man sich natürlich auf die Suche nach einem Provider, der einem die Amtsleitung bietet. Wie ich feststellen musste, gibt es allein in der Schweiz eine Unzahl VoIP Provider, die sich beim näheren Hinschauen jedoch als Kleinstunternehmen oder gar Bastelbuden bezeichnen lassen.

Die meisten Anbieter bieten eine Anbindung via SIP an, nur wenige wie zum Beispiel e-fon bieten auch eine Anbindung via IAX an, was für Leute, die eine Heimtelefonanlage mit Asterisk bauen natürlich interessant ist.

Bei den Preismodellen gehen die Anbieter ebenfalls verschiedene Wege. Nach meiner Rechnung kann man mit VoIP erst ab monatlichen Telefonrechnungen von über hundert Franken spürbar Geld sparen, wenn man eine gute Qualität von Telefonie will. Ausser vielleicht mit dem Cablecom Angebot wo man aber nicht die Technologie voll ausnutzen kann.

Erste Erfahrungen mit VoIP Telefonie Providern ergeben ein eher ernüchterndes Bild. Bei OnePhone habe ich ein SIP Konto ausprobiert. Neben guten Telefonaten hatte ich auch einmal ein Telefonat, welches mir mitten im Gespräch einfach gekappt wurde, bei einem anderen Gespräch hörte ich die Gegenstelle plötzlich für ca. 20 Sekunden nicht mehr, dann kam die Leitung zurück, und die Gegenstelle informierte mich, dass ihr da eine andere Stimme "oh sorry" gesagt habe. Vorfälle, die nicht gerade Vertrauen erwecken.

Erste Erfahrungen mit einer IAX Anbindung via e-fon hinterliess bisher schon einen besseren Eindruck. Via IAX hat man beliebig viele Leitungen, was für Firmen durchaus interessant ist. IAX ist mir sowieso viel sympathischer als Anbindung als dieser etwas kränkliche SIP Standard, nur schon, weil sich mit IAX ein QoS viel einfacher realisieren lässt.

Was für Erfahrungen haben wohl andere den mit Schweizern VoIP Providern gemacht?

Update März 2010: e-fon bietet leider keine IAX Anbindung mehr an, und kippt daher aus dem Radar.

Die analoge Telefonleitung in VoIP zum klingeln bringen

nospam@example.com (TN) — Sun, 29 Jul 2007 21:45:26 +0200

Wie schon erwähnt, habe ich eine analog Telefonleitung mit Asterisk zum laufen gebracht. Nach der Konfiguration von Asterisk für den Linksys SPA3102 folgen hier noch einige Details zur Konfiguration des SPA3102 selbst.
Zunächst nutze ich nur das WAN Interface des SPA3102, dem ich in meinem LAN eine private IP Adresse per DHCP zuweise. Die Router-Funktion nutze ich nicht, weil ich dafür schon andere Router habe.
Bei der Voice Konfiguration habe ich folgende Werte speziell gesetzt:
Im Tab "Line 1" wird die SIP Konfiguration für das anschliessbare analoge Telefon gesetzt: also SIP Port 5060, bei Proxy die IP Adresse meines Asterisk-Servers, z.B. 192.168.10.1, und bei Display Name, User ID, Auth ID und natürlich Passwort die Angaben, wie sie auch im Asterisk konfiguriert sind.
Im Tab "PSTN Line" kommen ebenfalls die Angaben der Asterisk Konfiguration rein, also hier mit SIP Port 5061. Zudem braucht es hier einen Dialplan, damit bei einem Anruf auf der analogen Linie auch der Asterisk das mitbekommt. Ich habe darum im Feld "Dial Plan 2" den Eintrag "(S0<:192.168.10.1>)" ohne Gänsefüsschen, wobei 192.168.10.1 die IP Adresse meines Asterisk Servers ist. Zudem weiter unter bei "PSTN-To-VoIP Gateway Setup" die Werte "PSTN-To-VoIP Gateway Enable: yes" und "PSTN Caller Default DP: 2". Damit kann ich nun also via meine analoge Leitung meinen Asterisk anrufen. Die umgekehrte Richtung habe ich noch nicht versucht, weil ich meinen Asterisk noch nicht fertig konfiguriert habe.

VoIP und analoge Telefonleitung kombinieren

nospam@example.com (TN) — Fri, 13 Jul 2007 10:01:59 +0200

Um meine Asterisk-Telefonzentrale mit meinem analogen Telefonanschluss zu verbinden, habe ich ein Gerät gefunden, das einen FXO nach SIP umsetzt. Der SPA3102 von Linksys kommt mit einem FXO und einem FXS Anschluss, das heisst, ich kann damit ein analoges Telefon an meine Asterisk-Telefonzentrale anbinden, sowie der Telefonzentrale einen Fixnet Anschluss geben.
Dieses Gerät nun mit Asterisk zu verbinden war gar nicht so einfach. Schliesslich ist es mir aber doch gelungen, und die nötigen Parameter seien hier nun festgehalten. In der Datei sip.conf der Asterisk-Konfiguration waren folgende Einträge nötig:

[spa3102fxo]
type=friend
username=spa3102fxo
secret=spa3102fxo
canreinvite=no
context=incoming
host=dynamic
defaultip=10.11.12.13 ; IP used until peer registers
nat=no
port=5061
disallow=all
allow=ulaw
allow=gsm
dtmfmode=rfc2833

[spa3102fxs]
type=friend
regexten=44
callerid="Analog" <44>
username=spa3102fxs
secret=spa3102fxs
canreinvite=no
context=athome
host=dynamic
defaultip=10.11.12.13
nat=no
port=5060
disallow=all
allow=ulaw
allow=gsm
dtmfmode=rfc2833

Wichtig zu beachten ist, dass die beiden SIP Kanäle verschiedene Ports brauchen, die sind in der Regel beim SPA3102 bereits so konfiguriert.

Voice over IP, die vielleicht billigere Telefonie

nospam@example.com (TN) — Wed, 07 Mar 2007 22:18:01 +0100

Man hört immer mehr von Voice over IP mit den Stichworten SIP, Asterisk, und damit einhergehendem Bandbreitenmanagement (QoS). Gerade letzteres ist aber nicht so trivial und kann auf unterschiedlichen Wegen gelöst werden. Welches nun das richtige Produkt mit dem richtigen QoS ist, bleibt mir noch zu erforschen.
Auf alle Fälle kann man mit der Telefonzentrale Asterisk ganz interessante Dinge tun. Man kann zum Beispiel damit Sprachaufnahmen machen, oder eine gesprochene Menüführung zu eigenen Informationen (wollte schon immer mal meinen Computer anrufen können, damit er mir sagt, wieviele e-mails von wem den eingegangen sind). Mit Angeboten wie jene der drei Lieblingsnummern von Orange Optima, welche jederzeit gratis angerufen werden können, und einem geschickten Rerouting via eigenen Asterisk Server und VoIP lässt sich damit aber auch elegant wirklich Geld sparen.
Und zwar nicht nur zuhause sondern auch vom Mobiltelefon aus.

Geprellte Internet Businesskunden

nospam@example.com (TN) — Tue, 30 Jan 2007 23:53:36 +0100

Jeder kleine Businesskunde muss sich mit den neuesten Schachzügen von Cablecom und Swisscom FWS geprellt und abgezockt vorkommen, wie auf meine Anfrage hin auch richtig bemerkt wurde. Während Privatkunden sich für weniger als hundert Stutz im Megabit-Bereich tummeln, werden Businesskunden für viel Geld und wenig Bandbreite gerupft. Wie lange kann dieses Spiel so wohl noch gespielt werden?

Cablecom bietet Up- und Downstream im Megabit-Bereich

nospam@example.com (TN) — Tue, 09 Jan 2007 13:12:15 +0100

Cablecom bietet neuerdings einen 10Mbps/1Mbps Anschluss für läppische 65 Franken an, wenn man das Ding "nur" für einen Privatanschluss braucht. Das Business-Angebot hat sich indes in den letzten zwei Jahren gar nicht bewegt, womit sich meine alte Feststellung einmal mehr bestätigt. Die 10 Mbps Downstream sind damit schon fast vergleichbar mit Fredys Fibre to the home Sonderangebot für direkte Nachbarn, nur der Upstream und die AGB sind natürlich bei Cablecom noch weit weg von dem, was sie sein sollten. Bleibt zu hoffen, dass die anderen Provider, allen voran Swisscom Fixnet Wholesale, darauf reagiert, und zwar mit einer Preissenkung, da höhere Bandbreiten ja nicht mehr möglich sind.

Zu wenig Tempo für zu viele Surfer

nospam@example.com (TN) — Fri, 20 Oct 2006 20:48:24 +0200

Das Konsummagazin K-Tipp hat eine Analyse von verschiedenen Internet Providern durch das CNLAB machen lassen. Getestet wurden Tele2, Bluewin, Sunrise, VTX/Tiscali, Cablecom, green.ch, und solnet, wobei nur die ersten drei die Marke gut erreichen. Die Auswahl der Provider dünkt mich ein wenig willkürlich, da die besseren Provider hier irgendwie fehlen. Bei meinem Provider Init7 habe ich zum Beispiel noch nie einen Datenstau erlebt, das heisst Engpässe waren für mich noch nie spürbar. Vielleicht sollte ich öfters bei CNLAB meine Verbindung testen? Doch CNLAB sitzt im ASN von Cablecom, und wird damit wohl auch deren Stauprobleme haben. Deren Speedtest ist jedoch im ASN von Hostpoint, dessen Upstream-Provider auch mein Provider ist.

Schweizer Internet Blog weg vom Internet

nospam@example.com (TN) — Fri, 13 Oct 2006 21:53:00 +0200

Huch, was ist den mit dem Blog von Fredy passiert?

Warning: mysql_connect(): Too many connections in /virtual/blogg.ch/include/db/mysql.inc.php on line 156
Warning: mysql_select_db(): Too many connections in /virtual/blogg.ch/include/db/mysql.inc.php on line 157
Warning: mysql_select_db(): A link to the server could not be established in /virtual/blogg.ch/include/db/mysql.inc.php on line 157 DATABASE_ERROR

Da kann man ja frei spekulieren.

sein Serendipity upgrade ist nicht wie beim Politblog reibungslos verlaufen

er erlebt gerade den sogenannten Slashdot-Effekt

sein Datenbank-Server ist abgeraucht

Na mal schauen, wann denn der Internet-Blog sein Internet wieder findet.