TNs Blog

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.

Mit GPRS ins Internet

nospam@example.com (TN) — Mon, 06 Oct 2008 23:44:12 +0200

Vor einigen Monaten waren im Jura Ferien angesagt, wo die Vermieter bewusst keine Internet-Anbindung für ihre Gäste anbieten wollten. Also habe ich da meine alte Lösung wieder ausgegraben, um via GPRS und meinem MacBook ins Internet zu gehen. Ich habe eigentlich nicht viel gesurft, SBB Fahrpläne nachgucken und e-mails lesen war so die Hauptnutzung. Die Rechnung von Orange für die paar wenigen Megabytes chrotten langsames Surfen war dann aber doch gegen hundert Franken angewachsen. Die Preise in der Schweiz für Datenübertragung via Mobilfunk sind schlichtweg eine Frechheit, ebenso wie jene für Sprachtelefonie nebenbei gesagt. Zum Glück gibts es andere Ferienorte, wo mit WLAN die Ferienanbindung dann doch mit vernünftigen Kosten ausgeht.

WAAS und MSAS laufen, EGNOS kommt nicht vom Fleck

nospam@example.com (TN) — Fri, 11 Jul 2008 22:07:58 +0200

Neben dem Positionierungssystem GPS gibt es ja auch noch die Systeme, welche zur Verbesserung der Navigation Korrekturdaten aussenden. Diese nennt man "Satellite Based Augmentation Systems" oder eben kurz SBAS. Diese Systeme sind vorwiegend von der Luftfahrt-Branche getrieben, also von der ICAO und entsprechenden nationalen Organisationen. Das Amerikanische WAAS ist bereits seit einigen Jahren in Betrieb. Es liefert auch sehr gute Korrekturen um die GPS Position zu verbessern. Das japanische MSAS ist nach Rückschlägen (Verlust eines Satelliten) seit dem 27. September 2007 voll operationell. Nur die Europäer mit ihrem EGNOS scheinen irgendwie nicht vom Fleck zu kommen. Seit Jahren sind die Europäer am testen und ausprobieren, die Korrekturen für die Ionosphäre und die Orbit-Korrekturen, welche sie versenden, haben aber nicht die Güte, wie sie WAAS zum Beispiel zeigt,
daher sind in der Regel keine Positionsverbesserungen zu erwarten. Auch die Bahndaten, welche die Position der EGNOS-Satelliten vermittelt, sind in der Regel kilometerweit daneben. Da wurden doch glatt auch schon mal Bahndaten von den Satelliten versendet, welche den Satelliten in den Erdmittelpunkt platzieren würden.
Mir scheint, in Europa ist die Technik ein Opfer der Politik, welche zwar viel schönredet, aber kein Projekt vernünftig vom Fleck bringt. Wenn die Europäer mit dem geplanten Navigationssystem Galileo ebenso zaghaft und politik-verworren vorwärts machen, wird das Galileo wohl erst im 2020 wirklich funktionieren. Die Europäer werden wahrscheinlich von den Japanern mit dem QZSS und den Chinesen mit ihrem COMPASS überholt werden.

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.

GPS Satellit mit PRN 32 aktiv

nospam@example.com (TN) — Wed, 27 Feb 2008 11:26:21 +0100

Wie bereits angekündigt, aber einige Tage verspätet wurde der GPS Satellit mit PRN 32 gestern Abend auf "useable" umgestellt. Heute konnte man ihn nun auf dem GPS Empfänger erstmals als Teil der Navigationslösung bewundern. Spätestens jetzt zeigt sich, welche Hersteller einen Programmierfehler nicht ausgebügelt hatten in der Vergangenheit, wenn deren Gerät mit der Nummer 32 Probleme hat.

GPS Satellit mit PRN 32

nospam@example.com (TN) — Wed, 06 Feb 2008 09:44:55 +0100

Jetzt ist es endlich soweit, der GPS Satellit mit der PRN 32 wird voraussichtlich am 19. Februar als benutzbar markiert, wie aus diesem NANU zu erfahren ist. Damit kommt ein alter Satellit (SVN23) zu neuen Ehren.
Vor fast einem Jahr wurde der ehemalige Satellit 23 auf 32 umgestellt, blieb aber als unbrauchbar markiert, wohl um zu prüfen, ob auch alle Empfänger mit diesem Satelliten kein Problem haben. Die Furcht war wohl auf vermuteten oder bekannten Softwarefehlern von Empfängern begründet. Schon bald werden wohl ganze 32 GPS Satelliten aus dem All ihre Navigationssignale senden, da im März ja ein neuer Satellit mit PRN 7 in Orbit gebracht werden wird.

Neuer GPS Satellit bereits in Gebrauch

nospam@example.com (TN) — Fri, 04 Jan 2008 16:17:13 +0100

Am 20. Dezember wurde der GPS Satellit mit PRN 29 in seine Bahn gebracht, was Rocket Science Blog als Weihnachtsgeschenk bezeichnet.

Vorgestern wurde der Satellit bereits zum Gebrauch eingeschaltet, wie aus dem GPS NANU zu entnehmen ist. Damit beträgt die aktuelle Konstellation derzeit wieder 31Satelliten.

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.

Panna Cotta und andere feine Spezialitäten selbstgemacht

nospam@example.com (TN) — Fri, 13 Jul 2007 22:23:12 +0200

Wenn man mal schnell eine schweizer Spezialität sucht, also ein Rezept nach dem man kochen kann, dann ist man bei dieser Seite über schweizer Kochrezepte schnell fündig. Wollte ich doch eben schnell mal gucken, wie man jetzt eine Panna Cotta kocht, und schon werde ich morgen mich daran laben.