So, mit zwei Minuten Verspätung, mit dem wirklich sehr kreativen Adapter, den wir hier gebaut haben, haben wir jetzt endlich den nächsten Talk, How to build an ISP, vom Falk. Einführung wird er selber machen, viel Spaß.

Eins gleich vorweg, wenn ihr Fragen habt, oder euch Abkürzungen nicht klar sind, Hand heben, Frage stellen, auch bitte während des Talks. Ich möchte nicht, dass ihr zwischendurch irgendwie durch irgendwelche Abkürzungen stolpert, oder Fachbegriffe stolpert, und dann den Rest einfach nur noch...

Das bin ich sinnvoll. Ja, ich kann tatsächlich mal über ein Kundenprojekt reden, und zwar, wer bin ich? Ich kümmere mich eigentlich von vorne bis hinten um Infrastruktur. Bei der Profi-AG, das ist so ein Konsult, so ein klassisches Systemhaus, wir machen auch ein bisschen Beratung und so weiter,

und ich mache halt vor dem Netzwerk über Linux irgendwie alles. So, wir bauen uns einen ISP, warum bauen wir uns einen ISP? Internet hinterm Deich. Ich wohne so ungefähr 50 Kilometer südlich von Hamburg, da gibt es so einen schönen großen Fluss, der nennt sich die Elbe,

und rechts und links ist ein Deich. Das Ganze ist relativ sumpfig und so ein bisschen dünn besiedelt, was dazu führt, dass die Telekom da einfach keine Kabel hinlegt. Die Leute, die da wohnen, haben üblicherweise so ein... Wenn sie Glück haben, 768 Kilobit DSL,

vielleicht irgendwie zwei ISDN-Leitungen, oder irgendwie so zwei bis vier Megabit LTE. So, der 16-jährige Nachwuchs üblicherweise fängt irgendwann an, Fortnite oder sowas zu installieren, kommt irgendwie so ein Stück vorm Balken, und dann sagt das LTE, sie haben ihr Datenvolumen verbraucht.

Das ist irgendwie nicht schön. Und dann hat sich jemand gedacht, wir tun der ganzen Gemeinde mal was Gutes, wir kaufen uns mal ein Mast, so fing das Ganze nämlich an, wir haben da mal so ein Mast.

Die Idee ist, die Vierlande und Marschlande halt mit Internet per Funk zu versorgen. Zum Glück ist das Ganze relativ flach, das heißt, wenn man kommt mit einem zentralen Mast relativ weit, das Aufbauen sieht dann so aus. Man nehme ein Stück Feuerwehrleiter,

damit man das Zeug da oben draufgeschraubt kriegt, während der Mast ausgefahren ist. Und man sollte sich sicher sein, dass man das da oben wirklich drauf haben will, weil wenn das da einmal oben ist, kriegt man das so schnell nicht wieder runter. Weil wenn ich so einen einzufahrenden Mast habe, habe ich das Problem, ich muss die Kabel irgendwo festmachen. Was passiert, wenn ich den Mast einfahre,

die Kabel immer noch fest und irgendwann ab? Das ist doof, gerade bei Glasfasern. Ihr seht da oben, das ist alles noch so relativ dicht gedrängt, das waren die ersten Anfänge, das waren so die ersten Fehler, die wir gemacht haben, weil acht Sektorantennen kann man da oben ja draufschrauben, das passt ja vom Öffnungswinkel,

schrauben wir sie alle dicht aufeinander. Was passiert, Ubiquiti denkt man eigentlich, sollte das Radio ein Gehäuse haben, wo kein RF rauskommt. Eigentlich. Das führt dann irgendwann zu solchen Stielblüten, ich weiß nicht, ob ihr das sehen könnt, aber wir haben das Ganze so ein bisschen auseinandergezogen

und haben für die Radios erstmal so kleine Pappgehäuse gebaut und dieses Pappgehäuse dann nach nebenan zum Schlosser gegeben, um das Ganze aus Blech zu bauen und dann hinten auf die Radios draufgedengelt und plötzlich hatten wir so ungefähr 15 dB weniger Störleistung.

Also das hat schon einiges gebracht. Um mit dem Ganze jetzt mal anzufangen, wir brauchen auch so ein paar Bausteine, wenn man so einen Internet Service Provider aufbauen will. Wir haben einmal organisatorisches. Ich muss eine Abrechnung haben, weil ich mache das Ganze nicht für Spaß, ich will letzten Endes irgendwo damit Geld verdienen.

Ich brauche Supportprozesse, weil meine Kundschaft hat irgendwann Fragen, da gehen Dinge kaputt, Router funktionieren nicht mehr, vielleicht qualmt auch aus irgendwelchen Gründen die Antenne oder das Internet ist langsam. Ich sollte nach Möglichkeit LIL werden, weil dadurch komme ich an so Ressourcen wie IP-Adressen.

Local Internet Registry. Eine Frage, was heißt LIL? LIL heißt Local Internet Registry, das heißt, ich bin vollwertiges Mitglied beim RIPE, der Organisation, die Internet Ressourcen in Europa vergibt und kriege damit 1024 IP-Adressen zugewiesen.

V4. V6 kriege ich irgendwie einen ganzen Schwung voll. Slash 29, das möchte ich jetzt nicht rechnen. Das ist auf jeden Fall ausreichend, aber V4 ist halt, ich habe 1000 und damit ist Schluss. So, damit kriege ich mit so ein bisschen Glück meinen Netpool irgendwie für meine Kunden bedient und das war's dann.

Nichtsdestotrotz sollte man halt LIL werden, weil zum einen man nimmt am Internet teil und kann der Gemeinschaft ein bisschen was zurückgeben, zum anderen hat man die Ressourcen und kann sie selber an die Kunden weiter delegieren, ohne auf einen dritten Dienstleister warten zu müssen. Dann gibt es in Deutschland eine ganz hässliche Sache, diese Bundesnetzagentur.

Die kommt dann nämlich irgendwann dahin, wenn man irgendwie so ein Gewerbe anmeldet und sagt, du bist also Kommunikationsdienstleister, fällt uns das Telekommunikationsgesetz. Und nach § 190 hast du verpflichtend, ein Sicherheitskonzept abzugeben. Und das bitte, bevor du in den Produktivbetrieb gehst. Sonst wird es irgendwann sehr, sehr schnell, sehr teuer.

Die Jungs reagieren da ziemlich uneinspannt drauf. Klar, kann man sich vorstellen, die wollen natürlich wissen, das ist ein ISP, da sind Kundendaten drin, da sind Kundendaten möglicherweise, die möglicherweise wegkommen können. Da hängen private Rechner dran, dass wir immer nach Möglichkeit geschützt haben.

Also zumindest diese ganzen Datenabrechnungsprozesse und eventuell Verkehrsdaten und so weiter. Dann kommen wir zu den Dingen, die Spaß machen, Technik. Wir haben uns da so ein paar Sachen überlegt.

Wir wollten möglichst wenig Router und Graffel im Feld haben und haben uns gesagt, wir machen diese gesamte Aggregation im Data Center. Wir geben lieber ein paar Euro mehr aus für Darkfibers und ziehen das gesamte Zeug ins Data Center, virtualisieren das da weg und machen das Ganze gemütlich irgendwo auf eine Virtualisierungsplattform.

Anstatt irgendwo Router nach draußen zu stellen, also sprich irgendwie für 10.000 Euro Equipment irgendwo aufs Feld zu stellen und hoffen, dass da der Strom nicht ausfällt. Das kriege ich in einem Data Center deutlich besser gelöst. Ich brauche bei dem Ganzen so ein stabiles Layer 3 Underlay.

Das heißt, ich möchte meine Fahde nach Möglichkeit geroutet haben, damit ich mehrere davon benutzen kann und nicht so komische Krücken bauen muss, wie LACP über Warnstrecken. Weil 10G reichen nicht, nimmst du eine zweite Strecke dazu. Was machst du üblicherweise im Data Center? Du machst LACP an. Auf Weitverkehrsstrecken

nicht das Beste. Link Aggregation Control Protocol. Das heißt, ich mache aus zwei, zwei von meinen Röhren eine für den Switch zum Beispiel. Dann war die Vorgabe so wenig schwarze Magie wie möglich.

Es gibt auch Leute, die müssen es letzten Endes irgendwo betreiben und wenn es nachts um drei irgendwie knallt, dann sollte man das reparieren können. Wir haben über das Ganze ein eVPN-Overlay gezaubert.

Was eVPN ist, erkläre ich nachher nochmal. Das nennt sich EthernetVPN. Es ist alles automatisiert. Das war die Prämisse. Das heißt, wenn so eine Kiste umkippt, will ich auf den Knopf drücken können und dann ist sie wieder da. Und zwar genau in dem Zustand, wie sie vorher war, mit derselben Konfiguration. Wer Dinge händisch ändert, kriegt die Hand abgehackt.

Wie gesagt, wir machen das Ganze nicht nur zum Spaß. Wir wollen ein bisschen Geld verdienen. Deswegen kommt die Wireless Hardware erstmal von Ubiquiti. Das ist für den Start auf jeden Fall brauchbar. Wenn das Ganze nachher professioneller wird, muss man mal gucken, ob man irgendwo in Richtung 60 Gigahertz

oder ähnliches geht. Aber für den Start ist das 5 Gigahertz Zeug von Ubiquiti tatsächlich tauglich. Und wir machen alles über Ethernet. Das heißt, keine komischen Sachen wie ATM oder ähnliches altes Zeug. Das sollte man sich nach Möglichkeit raushalten.

Das heißt, auch über die Duck Fibers geht ganz normal Ethernet. Warum Aggregation im Data Center? Wir haben uns da so ein paar Server hingestellt und Open Nebula darauf installiert. Open Nebula ist eine Virtualisierungsplattform,

die mir aus Images auf Klick oder per API Maschinen generiert. Das heißt, ich kann Klicken sagen, ich hätte gerne 10 Stück davon. Dann macht das irgendwie Schnirrk, rappelt ein bisschen auf der Festplatte und nachher habe ich da 10 virtuelle Maschinen, die alle gleich aussehen, weil sie zum selben Image geklont werden. Damit machen wir was, das nennt sich Network Function Virtualization.

Das ist ein schönes Buzzword. Da könnte man auch gleich SDN dran schreiben. Was wir halt tun, wir machen unsere ganzen Access-Konzentratoren. CPEs für Geschäftskunden sind virtuelle Maschinen. Das heißt, wir ziehen quasi per VXLAN den Port von der Antenne bis ins Data Center durch

und haben dann statt irgendwie dem Router vor Ort beim Kunden die Antenne und alles andere läuft irgendwo im Data Center. Sagen wir, üblicherweise, wenn ich einen Geschäftskunden habe, der hat irgendwo so ein Cisco 1800, Cisco 1900, da stehen so eine kleine blau-weiße Kiste, die lustig vor sich hin blinkt.

Da sind dann so ein paar Kabel dran, so ein komisches Gammelnetzteil und wenn man Glück hat, ist da auch ein richtiges Enchoco-Netzteil dran. Aber so haben wir gesagt, wir ziehen das als CPE hin, weil wir können zum einen die Konfiguration deutlich einfacher automatisieren,

als wenn wir uns mit 27 verschiedenen Routerplattformen umschlagen. Ich sag mal so, gerade bei den kleinen Dingern muss ich ja nicht zwingend was hinstellen. Oder ich sag mal, so eine APO kostet, Max, was kostet eine APO, 300 Euro? Eine kleine 200. Das heißt, ich muss für eine CPE 200 Euro ausgeben,

plus nochmal die Antenne, die ich sowieso brauche. Diese 200 Euro für die CPE kann ich mir sparen, ich virtualise das Ding einfach. Hab damit auch noch ein bisschen mehr Ausfallsicherheit, als wenn das Ding beim Kunden steht. Latenzmäßig gibt sich das nicht viel? Weil der Traffic, wenn er über die CPE geht, sowieso nach draußen will. Damit muss er sowieso über die Leitung raus.

Und damit fallen dann halt so Sachen weg wie, der Kunde hat ein Problem und ja, welche Lampen blinken denn an seinem Router? Ich kann halt auf den Router direkt per SSH draufgucken, kann sehen, kriege ich das lokale Netz. Wenn ich Glück hab, komme ich sogar bis auf die Antenne vor Ort, wenn sie nicht abgefackelt ist.

Das heißt, ich kann dann auch direkt gucken, kann sagen, okay, bis zum Internetport, den wir dir übergeben, ist alles in Ordnung. Das Problem liegt irgendwo bei dir, lieber Kunde. Und hab dann nicht diesen Riesentanz mit, ich komme nicht an die CPE, weil vielleicht jemand den Stecker rausgezogen hat, um Staubsauger einzustecken oder ähnliche Dinge.

Und wie gesagt, ich kriege das Zeug jetzt innerhalb von Minuten provisioniert. Ich brauche nicht irgendwie jemanden, der mir mal eben drei Router einrichtet, dann in der VRF, die die Vollroute vergisst. Und ähnliche Sachen, die schiefgehen können.

So, nochmal etwas größeres Bild von dem Mast, Wireless Aggregation. Das heißt, wie kriege ich eigentlich jetzt meine Kunden daran? Wir haben oben insgesamt acht von den Sektorantennen, die das Ganze abdecken. Die Spiegel da unten sind point-to-point links, also ab links zu anderen Standorten oder anderen Türen.

Das Ganze ist redundant mit Glas, also so ein Mast binden wir redundant mit Glasfaser an. Wir haben ein geroutetes Anderlein-Netzwerk, eigentlich auch total unspektakulär.

So, da hängen dann zwei Router dran, die machen zur einen Seite HSRP, zur anderen Seite machen sie OSPF auf den ganzen Rest des Netzes, sprich einstecken geht, wenn einer umfällt, schade, passiert dann halt. Aber eigentlich total langweilig. Wir fahren aber eine MTU von 9000, das heißt, wir erlauben da große Pakete.

Das heißt, im normalen Netz habe ich eine MTU von 1500. Wenn ich diese 1500er Pakete jetzt eingepackt in irgendwas anderes transportieren möchte, muss mein Transportnetz eine größere MTU haben, also in diesem Falle 9000. Ja, bitte. Erzählst du gleich noch, hört man das, erzählst du gleich noch ein bisschen was zu der Technik, die du da verbaut hast?

Denn man hat da jetzt gerade einen Edge-Point gesehen, kommt da noch mehr zu? Ne, zur Technik kommt eigentlich nicht viel. Okay, dann würde mich tatsächlich noch mal interessieren, was da jetzt für Hardware hängt. Also ich sehe da oben einen Edge-Point, das wäre ein 16-Port-Switch. Genau, da oben hängt ein Edge-Point, das ist ein 16-Port-Switch mit

Ubiquiti Power over Ethernet, die da 24 Volt, glaube ich, machen. Wir gehen da auch mit 48 Volt Gleichstrom hoch und einer Glasfaser und da sind dann entsprechend die ganzen Antennen angeschlossen. Das heißt, wir gehen eigentlich mit zwei Glasfasern einmal Strom nach oben an den Mast.

Das heißt, das ist der Router, von dem du gerade sprachst? Nein, der Router steht unten dran in einem kleinen Container. Das da oben ist nur reines Layer-2. Ubiquiti Airfibers.

Müsste jetzt auch genau gucken, was da drunter steckt, das Wireless-Zeug hat dann jemand anders gemacht, tatsächlich. Aber die Airfibers, ja.

Die Frage war, was machen wir mit dem Parasiten-Vögel Marder? Der Marder krabbelt da eigentlich nicht rauf. Die Rohre am Boden sind in Stahlrohre gezogen, also die Kabel am Boden sind in Stahlrohre gezogen. Und ja, ich glaube, für Vögel ist es zumindest sehr uninteressant.

Nö, bis jetzt nicht. Ja, Blitzschutz machen wir. Da kommt oben noch tatsächlich, das Foto ist noch ein bisschen älter, da ist oben jetzt ein Blitzschutz drauf.

Wir haben nach unten auch eine Glasfaser, damit es nicht durchschlägt. Und das entsprechende Gleichspannungs-Netzteil ist halt ein bisschen entkoppelt. Da war eben noch eine Frage. Schon erledigt?

Jo, wo waren wir stehen geblieben? Hier war eine Wireless Aggregation. Jetzt möchte der Kunde irgendwie auch noch ans Netz kommen. Verrückt, ich weiß, aber damit verdient man dann letztendlich Geld. Das sogenannte Netzabschlussgerät ist eine Ubiquiti NanoBeam, so ein kleines Tellerchen.

Da fällt irgendwie hinten, ich glaube, zweimal Ethernet raus oder einmal Ethernet. Das Ding möchte am liebsten per Power over Ethernet versorgt werden. Und das kriegt der Kunde dann entweder an den Schornstein oder an die Hauswand geschraubt. So, und ab da darf er dann seine

Fritzbox, Router, was auch immer anhängen. Upstream vom Kunden wird zum Mast hin in ein eigenes Faulern geschmissen. Damit wir die Kunden so ein bisschen auseinanderhalten können, layer 2 mäßig. Damit wir wissen, okay, was ist denn Privatkunde? Was sind Geschäftskunden?

Ich sehe, der Max greift zum Mikrofon. Frag doch mal. Der ist gerade nicht ganz sicher, ob er es richtig verstanden hat. Ihr macht ein WLAN zwischen der Sektorantenne und jeder NanoBeam. Nee, sogar mehrere. Okay, das heißt, die NanoBeams konfiguriert auch ihr? Richtig.

Und der Kunde kommt da nicht drauf? Richtig. Der Kunde kriegt seinen Antecht WLAN. Kommt nicht auf die NanoBeam, kann da auch nichts um- oder verstellen. Was ja gerade so frequenzmäßig dann interessant ist. Weil wir die entsprechend auch festnageln wollen. Wir müssen die Dinger monitorn und so weiter. Da wollen wir nicht, dass der Kunde drin rumspielt.

Und üblicherweise macht der Privatkunde dann bei seiner Fritzbox hinten dran PPP over Ethernet. Warum wir PPP over Ethernet machen, erzähle ich nachher noch mal ein bisschen detaillierter. Aber wir müssen halt die Kunden irgendwie authentifizieren, auseinanderhalten, irgendwas.

Und da bietet sich tatsächlich PPP over Ethernet an. Ist halt ein bisschen getunnelt, aber es gibt Schlimmeres. Businesskunden machen kein PPP over Ethernet. Die kriegen halt einfach ein Stückchen Ethernet, was da rausfällt. Falk? Ja? IPv6? Ja, sicher. Auch PPP over E?

DHCPv6 PD. Okay. Also IPv6 machen wir nicht über PPP. Also ja, schon über PPP over Ethernet. Aber der Kunde kann sich per DHCPv6, wie wir heute Morgen gehört haben, ein größeres Präfix holen, wenn er mehr Netze braucht. Die Jumbo-Frames, die ihr im Backbone habt, die habt ihr aber jetzt nicht zum Kunden durchgereicht.

Ihr macht eine 1500er MTU drauf und zieht davon die Encapsulation fürs PPP over E dann ab. Genau. Der Kunde kriegt halt tatsächlich am Ethernet 1500 übergeben, macht seinen PPP over Ethernet, hat dann letztendlich eine MTU von 1492. Also kommen noch mal acht weit weg. Aber ich sag mal, das funktioniert an jedem Detakt DSL-Anschluss seit gefühlt Jahren.

Ja. Wie kriegen wir diese ganzen VLANs, die wir jetzt auf so einem Mast zusammengebaut haben, irgendwie ins Data Center? Weil wenn wir VLANs benutzen, ist ja bei 4096 Ende.

Das wäre ja doof. Also haben wir da so zwei kleine Kisten sitzen, lustigerweise auch hier APUs, die die VLANs aufnehmen und in VXLANs einpacken. Das heißt, meine 4096 VLANs habe ich nur lokal auf meinem einen Mast.

Die kommen gar nicht ins Data Center oder irgendwo an, sondern ich nutze dann mein geroutetes Transportnetz. Und dafür dann halt VXLAN, EVPN im Overlay. Was ist VXLAN? Da habe ich jetzt schon relativ oft drüber geredet. Purmens MPLS, entwickelt von Cisco, Arista, VMWare, ist jetzt ein RFC-Standard.

VMWare benutzt es mittlerweile nicht mehr, die machen Geneve. Ich habe jetzt statt meiner 12-bit-VLAN-ID ein 24-bit-VXLAN-Identifier, ein VNI. Das heißt, ich habe global galaktisch 16 Millionen VLANs.

Damit sollte ich erst mal eine Weile hinkommen. Zur Not kann ich immer noch VLANs in VXLANs einpacken. Was VXLAN macht, das encapsuliert Ethernet-Frames in ODP-Pakete. Das heißt, was ein Kunde mir per Ethernet schickt, packt das in ODP ein,

hat plötzlich ein schönes Layer-3-Paket und kann das zielgerichtet durch die Gegend schieben. Dazu gibt es sogenannte Virtual Tunnel Endpoints, sprich immer die Enden von diesen Tunneln. Die nennen sich VTAPs.

So, wie kommt der ganze Käse jetzt zusammen? Wir nehmen VXLAN als Overlay-Protokoll, man könnte auch MPLS nehmen. Die ganzen MAC-Adressen, die hinter meinem VXLAN-Tunnel liegen, plus meine VTAP-Adressen auf der Gegenseite, stecke ich mit EVPN ins BGP.

Warum nehme ich BGP? BGP kann beliebige Routen und Pfade durch die Gegend schieben. Das in einer Menge sitzt, glaube ich, bei der Routing-Tabelle im Internet. Da sind wir bei 800.000 Präfixen, ungefähr.

Und wenn ich dann mal so eine Million MAC-Adressen im Netz habe, stört das BGP nicht wirklich. Das ist dann halt so. Damit kann ich halt jeder MAC-Adresse meinen Endpunkt zuordnen.

So, und plötzlich, ich kann meine gesamten Links im Backbone benutzen. Das heißt, habe ich 2, 3, 4, 5 mehr Gigabit Traffic als meine eine Leitung hergibt. Kann ich die durch Equal-Cost-Multi-Pass mitbenutzen.

Das heißt, ich kann dann Load-Sharing machen. Entweder per Flow, per Packet, per was auch immer. Ich habe mehr als 4096 VLANs in meinem Netz verfügbar. Das heißt, wenn ich einen Kunden habe, der sagt, hey, ich hätte gerne zwischen meinen drei Standorten ein VLAN. Warum auch immer man das haben möchte. Kunden sind seltsam manchmal.

Dann kann man denen das relativ einfach schalten, indem man ihnen das selbe VLAN steckt. Und plötzlich habe ich eine Layer 2 Regibility von links nach rechts über ein geroutetes Netz. Das Ganze ist mit Linux und Bordmitteln relativ einfach zu bauen. Also, einfach.

Ich kann den ganzen Krempel in Ansible templaten. Und wenn ich IP-RAU2 benutze, was die Jungs und Mädels von Cumulus gebaut haben, kann mein ETC-Network-Interfaces auch plötzlich mit so Sachen wie VXLAN-Interfaces umgehen. Wenn ihr euch von letztem Jahr den dunklen Magie im Netzwerk-Stack-Talk nochmal anguckt,

da ging es unter anderem über VLAN-Aware-Bridges in Linux. Das kann man da auch benutzen. Das heißt, ich kann in meiner Linux-Bridge VLANs und VXLANs in eine Bridge stecken und zusammen genubbeln.

Und damit habe ich schon meine ganze Magie von VLANs und VXLANs stecken. Das lässt sich tatsächlich über dieses bisschen zusammentüdeln. Weil ich hier oben sagen kann, auf welches VLAN das VXLAN kommt. Und hier unten stecke ich das Ganze einfach nur in eine Bridge.

Und habe damit dann vielleicht noch einen Upstream-Port, wenn es nötig ist. Ein bisschen variablenmäßig sieht die Konfiguration so aus. Ich habe mein Loopback-Interface. Das brauche ich für meine BGP-Sessions.

Ich habe mein normales Interface in Richtung Backbone. Sprich, das ENP1 ist Null. Mit einem relativ kleinen Netz dran. Gut, Gateway-MTU. Und unten kann ich dann einfach meine VXLAN auf VLAN-Mappings definieren.

Und wenn ich das für jeden Standort getan habe, fällt das Ganze einfach aus dem Konfig-Management. Das heißt, Kiste kaputt. Ok, schön, neue APU aus dem Regal ziehen. Einmal in Debian-Boot ein Enzipel drüber laufen lassen, fertig.

Ich füge irgendeinen Kunden hinzu. Entweder ich generiere mir die Variablen irgendwann dynamisch. Oder wie Max das zum Beispiel mit Netbox gemacht hat. Oder ich habe es momentan halt noch statisch. Kriege aber damit tatsächlich eine nachvollziehbare Konfiguration hin. Wann, wer, welches VLAN wo reingesteckt hat.

Und warum vielleicht auch noch. Ein bisschen was noch zum Underlay. Wir nehmen OSPF als internes Routing-Protokoll. Da sind wir faul. Weil das ist irgendwie ansteckend und geht. OSPFv2 für IPv4.

OSPFv3 für IPv6. BGP nehmen wir, um alle MAC-Adressen im Overlay bekannt zu geben. Und das gesamte BGP läuft über zentrale Route-Reflektoren. Das macht zum einen die Konfig sehr einfach. Ich habe zwei Route-Reflektoren, auf die sich alle connecten.

Ich zeige meinem Router die Route-Reflektoren. Fertig. Ansonsten bräuchte ich einen Full-Mesh zwischen allen Routern. Das eskaliert sehr schnell. Deswegen will man Route-Reflektoren. Ich habe damit einen zentralen Punkt, auf dem die Routen ausgetauscht werden.

Das ganze Zeug kann ich auch alles im Data Center lagern. Ist das eine Frage? Ja. Frage, wo die Konfig herkommt. Das sind Router, die sind unten an den Antennen. Ich muss das Ganze irgendwo einpacken.

Aber danach habe ich einen ganz normalen Transport. Die reden mit den anderen Routern im Data Center. So, ein bisschen was zu OSPF.

OSPF, jedem Begriff. Wahrscheinlich nicken? OSPF ist ein Interior Gateway Protocol. Das heißt, das ist dafür ausgelegt, innerhalb eines autonomen Systems zu laufen. Das kann nicht ganz so viele Routen ab. Das Limit ist ungefähr bei 65.000.

Dann ist da eine sehr harte Schicht im Schacht. Wir sind wieder faul. Wir nutzen nur Area 0, weil wir relativ wenige Router haben. So 60 bis 80 Router pro Area funktionieren noch ganz gut. Darüber sollte man dann gucken, dass man sich mal andere Konzepte ausbaut.

Aber da sind wir noch nicht. Das machen wir dann, wenn wir dahin kommen. OSPF ist ein Link-State-Protokoll. Das heißt, jeder Router sieht den gesamten Zustand des Netzes. Der weiß, welcher andere Router, welcher andere Links angeschlossen hat. Und kann daraus autark seine Topologie berechnen.

Dann kommen wir noch mal zum BGP. Die Router sind alle im selben autonomen System. In dem Fall 65.000, da haben wir ein privates genommen. Für das Overlay-Netzwerk. Die BGP-Sessions baue ich zwischen Loopback-Adressen auf. Warum Loopback-Adressen? Wenn ich mehrere redundante Pfade von so einem Router weg habe,

also zwei oder drei, und ich das auf meine Link-Adressen konfiguriere, und mir der Link runterfällt, ist die Session weg. Das ist doof. Ich will zu einem Route-Reflektor immer nur eine Session konfigurieren, aber nicht drei. Deswegen nehme ich mein Loopback-Interface als Absenderadresse.

Und habe immer einen Weg von meinem Loopback-Interface zu meinem Route-Reflektor. Damit ist es mir egal, ob irgendwie ein oder zwei redundante Links wegfallen. Ich kriege immer noch meine Routing-Verbindung hin. Und finde meine alternierenden Wege.

Die Frage ist, warum sind die Router im selben AS? Wir können die auch in unterschiedliche AS tun. Aber da wir das mit Raudreflektoren nutzen wollen,

sind wir auf IBGP festgenagelt. Ansonsten müssten wir halt entsprechende Peerings bauen und hätten wieder mehr Verbindungen. Weil so habe ich an jedem Punkt des Netzes, kann ich mal einfach irgendwo einen Router hochziehen, den auf die Raudreflektoren werfen, und es funktioniert.

Und die unterliegenden Pfade kriege ich über OSPF. Weil ich habe ja im IBGP nur meine MAC-Adressen drin. Da sind ja gar keine IP-Adressen drin. Ich könnte IBGP machen, bräuchte aber so ein

Routereflektor. Und das verkompliziert die ganze Sache wieder ein bisschen. Da ist noch eine Frage. Was ist ein Raudreflektor? Steht da unten schon drin. Wenn ich IBGP habe, darf ich keine Fahrtattribute

an so einer empfangenden Route verändern. Das heißt, Router kriegt eine Route und behält die. Und schickt sie nicht wieder raus. Weil er sonst möglicherweise Loops erzeugen könnte. Die einzige Ausnahme dazu sind Raudreflektoren. Weil die wissen nämlich, von wem sie die Route bekommen haben. Und geben sie an alle anderen in demselben

autonomen System weiter. Ansonsten bräuchte ich ja ein entsprechendes Full Mesh. Also müsste jeden Router mit jedem peeren, damit die Routen entsprechend gelernt werden. Und deswegen Raudreflektoren. Wir haben ein bisschen geguckt, mit was wir das bauen.

Wir haben uns Bart angeguckt. Wir haben festgestellt, Bert kann kein eVPN. Also haben wir Freerange Routing genommen. Das ist die ganze Konfig. Mehr Magie ist das nicht. Ich habe mein Loopback-Interface, auf dem ich OSPF spreche. Ich habe mein Interface zum Core, auf dem ich OSPF spreche.

Ich habe meine BGP-Konfiguration, die meine Fabric Neighbors definiert. Und als Absenderadresse das Loopback-Interface hat. Und ich mache auf dem entsprechenden Interface,

also auf der entsprechenden BGP-Session, machen wir IPv4 Unicast an, um möglicherweise Arbs durch die Gegend schieben zu können. Und wir machen Layer 2 VPN an. Und sagen, ich habe eine BGP-Konfiguration. Und wir sagen, wir wollen alle VXLan Interfaces

da reingeschoben haben. Und damit ist das Overlay fertig. Jeder, der im selben AS ist, kennt die entsprechenden Nachbarn. Kennt die entsprechenden Bizeps. Und das funktioniert eigentlich sehr gut, bis jetzt. Im Moment läuft das Ganze noch im Testbetrieb

mit ungefähr 30 Kunden. Wird aber gerade mehr. Wir bauen da jetzt im halben Jahr dran rum. Halbes, Dreiviertel. Es gab ein paar initiale Schwierigkeiten. Der erste Mast war ein bisschen zu niedrig. Da waren plötzlich so Dinge wie Bäume im Weg. Im Frühling plötzlich wachsen und Blätter kriegen.

Gerade so bei 5 Gigahertz ist so Line of Sight ein bisschen schwierig. So, dann habe ich versprochen, ich erzähle noch ein bisschen was zu PPP over Ethernet. Warum wir das machen.

Die Frage war, wie viel wir in dem halben Jahr ausgegeben haben. Kann ich nicht sagen. Schätzungsweise 200.000 Euro zusammen mit Gehältern und alles.

Vielleicht mehr. Ich weiß es nicht. Es ist auf jeden Fall gewaltig in Vorleistung. Wobei man dazu wahrscheinlich dazu sagen muss, um gerade hier rein zu grätschen, dass die Hardware wahrscheinlich der geringste Anteil ist. Die Hardware ist der geringste Anteil. Also das Computerzeug und so.

Der Mast war relativ teuer, weil da so ein LKW mit dran war. Dann vieles. Gehälter, Büro usw. Was da mit dranhängt. Hardware an sich. Fast nicht in Summe 20.000 Euro.

So. Aber nochmal um zum PPP over Ethernet zurückzukommen. Hatten ganz einfach einen Grund. Was haben die meisten Leute zu Hause? Eine Fritzbox. Eine Fritzbox macht entweder DHCP oder sie kann PPP over Ethernet. Das können sie ziemlich gut.

Bei DHCP habe ich das Problem, was mache ich mit einem Kunden, der nicht zahlt? Brauche ich ihm die Antenne ab? Das ist ja auch ein bisschen albern. Oder was mache ich mit einem Kunden, der gekündigt hat? Gut, dann muss ich dann irgendwann die Antenne abbauen. So kann ich einfach den User-Account deaktivieren,

wenn ich PPP over Ethernet mache. Und der Kunde kann sich nicht mehr einwählen. Und ich kann über PPP over Ethernet ein paar mehr Sachen mitgeben als über DHCP. Bei DHCP brauche ich entsprechend ein Layer-2-Netz bis zum Kunden. Wo halt auch der DHCP-Server drin läuft.

Wo dann alle Kunden drin sind. Und plötzlich sehen die Kunden sich auch noch gegenseitig. Oder ich muss für jeden Kunden tatsächlich eine VLAN bauen. Und das wird dann ein bisschen anstrengend. Du hast es ja auch unterschlagen gerade. Bei PPP hättest du auch die Möglichkeit, den Kunden, wenn er nicht zahlt, auf eine Catch-all-Seite zu leiten.

Im Prinzip, ihm darauf hinzuweisen, dass er ausstehende Rechnung hat. Genau, das könnte man auch noch machen. Andere Möglichkeiten wären halt noch 802.1x. Das können aber die meisten Plaster-Router nicht. Fritz-Boxen auch nicht. Das wird zumindest schwierig. Dann gäbe es noch eine Möglichkeit IP over Ethernet.

Kann auch wieder keiner. Können so ein paar Mikrotik-Boxen, soweit ich weiß. Aber wir wollen dem Kunden ja freistellen, welchen Router er benutzen darf. So, wenn ich dann auch dem Kunden zusätzlich noch einen Router hinstellen muss,

können wir das auch gleich in der Antenne machen. Nochmal CPE, Custer Promises Equipment. Und das Zeug, das beim Kunden vor Ort steht. Noch ein paar Sachen, die für PPP over Ethernet sprechen. Ich kann den Kunden in der Bandbreite reduzieren.

Das heißt, wenn der Kunde nur 25 Megabit bucht, kann ich ihn direkt am Konzentrator wegschäpen. Und ich muss es nicht erst bis zum Endkunden transportieren, damit die Antenne dann irgendwann das Shaping kriegt. Sondern ich kann das direkt vorne wegschäpen. Ich kann so ein bisschen kontrollieren,

wer die Dienste nutzen darf. Wir haben im Moment pro Mast 2 Gigabit. Wie viel Bandbreite haben wir pro Sektorantenne? Wir haben im Moment pro Antenne runter 1 Gigabit.

Ablink von dem Standort sind momentan 2 Gigabit. Das kriegen wir doch nicht voll. Das ist Dark Fiber. Das heißt, wenn es da zu eng wird, kommt 2 mal 10 Gigabit hin. Das sollte dann auch reichen.

Was geht realistisch über so eine Antenne? Das kommt darauf an, wie weit du weg bist. Wie hoch die Luftfeuchtigkeit ist. Ob da gerade ein Vogel durchfliegt oder nicht. Auf jeden Fall 200-300 Megabit.

Es geht dann runter bis auf 80-100 Megabit, wenn man so 5 km weg ist. Aber es ist immer noch schneller als das LTE oder das Gammel DSL vor Ort. Genau, das ist auf einem Sektor.

Noch eine Frage von? Es wurde gefragt, ob die Latenz erträglich ist. Was definierst du als erträglich? Du hast über einen VDSL 100, hast du 20 Millisekunden Latenz.

Bei einem Wi-Fi Link hast du üblicherweise 3 Millisekunden. Du bist deutlich besser mit der Latenz unterwegs. Wenn natürlich viel auf dem Sektor los ist, geht die Latenz nach oben. Weil der Sektor sagt, du darfst jetzt reden. Das ist ein Scherzmedium in dem Fall. Aber das Problem habe ich auch im Kabelnetz.

Monitorst du die physischen Parameter pro Sektor irgendwo? Du siehst im Prinzip, ob du Congestion hast oder ob du den Sektor aufteilen musst. Genau, wir sehen, wie voll der Sektor ist, wie viel Airtime wir zur Verfügung haben, ob die Airtime pro Kunde runtergeht. Das monitorn wir.

Der Backbone? Die Anbindung ist auf 5 GHz und nicht auf 2,4. Ja, die Anbindung ist auf 5 GHz. Habt ihr unten Mechanismus überlegt, was passiert, wenn der Kunde mit seiner Fritzbox neben eurem Downlink steht und auf derselben Frequenz? 80 MHz, 5 GHz oder 160?

Wir hoffen, dass er weit genug weg ist von dem Nanobin. Aber das wird er wahrscheinlich schon merken. Aber ihr habt jetzt nicht in den Endgeräten so einen Remote-Managementzugang, dass du beim Kunden eurem CPE einloggen kannst und gucken kannst, wie Spektrum aussieht vor Ort.

Doch, ich kann mich auf unserem CPE einloggen. Also auf dem Nanobin tatsächlich. Ich kann dann mit den entsprechenden BigQuery-Tools gucken, wie sieht das Spektrum aus, wer benutzt welchen Kanal. Ich kann dann im Zweifelsfall dem Kunden auch sagen, hey, nimm einen anderen. Das Ganze ist halt noch sehr manuell. Da gibt es noch nicht viel Automatik.

Wo war ich stehen geblieben? Warum PPP over Ethernet? Genau, Kontrolle über die Dienste nutzen darf. Das heißt, auch wenn sich jemand, wenn irgendwo mal so ein PreCerti wegkommt oder ein 802.6-Zertifikat und sich jemand in das entsprechende WLAN hängt, dann sieht er maximal PPP over Ethernet-Traffic.

Wenn er Glück hat und mit snifft, dann kriegt er vielleicht noch irgendwo einen Broadcast zu fassen, wo ein Username oder ein Passwort drin steht. Da muss er nur noch mal tatsächlich viel Glück haben, weil so oft fällt die Verbindung nicht weg. Dadurch kann man auch ganz gut kontrollieren, wer das Netz nutzen darf und wer Bandbreite nutzen darf.

Das heißt aber, das sind die SSID von deiner Basisstation zum CPE, dass ihr da einen Share-Ziegel-WPA-PSK2 drauf habt. Der ist dann aber für alle Access Points gleich? Der ist zumindest dann für den Sektor gleich. Das heißt also, innerhalb des Sektors, wenn du im JTAG draufgehst, könntest du im Prinzip das Ding auslesen? Ja. Also klar genug irgendwie Willen vorausgesetzt

und kriminelle Energie geht das alles. Oder Spieltrieb, klar. Aber ich sag mal, da muss man dann irgendwo noch mal ein bisschen auf die Vernunft der Leute setzen.

Spannende Frage. Wie machen wir PPP über Ethernet? Normalerweise machen das so große Blechkisten. Da steht ein Juniper oder Cisco drauf. Die machen das Ganze auch in Hardware. Wir machen das auf so kleinen Linux VMs. Die kriegen ihr Layer-2-Netz per VXLAN zugeführt. Und wenn eine Kiste voll ist,

kann man im Zweifelsfall ein VLAN in ein weiteres VXLAN aufteilen und dann eine zweite daneben stellen. Oder eine dritte, eine vierte und so weiter. Das kann ich innerhalb von 10 Minuten machen. Vorteil von dieser ist immer virtuellen CPE. Kiste irgendwie performt nicht mehr richtig

oder hat zu viel Last, stellen wir eine zweite daneben, eine dritte, eine vierte und so weiter. Da gibt es eine schöne Software für, die nennt sich Excel PPP-D. Wird hauptsächlich irgendwo in Russland benutzt, habe ich das Gefühl, weil Dreiviertel des Forums auf Russisch sind. Die Software ist total unterdokumentiert.

So sieht die Config-Datei aus. Schön, und was machen die ganzen Optionen? Wenn man sich da mal so ein bisschen reinfrickelt und Beispiele und Sourcecode liest und ganz viel Google Translate bemüht, kriegt man dann heraus, was das Ding alles kann. Ich kann zum Beispiel Stumpfradios

für die Authentifizierung. Ich kann damit tatsächlich per Radios sogar ein Shaping einbauen, der dann die Linux integrierten Shaper-Tools wie TC und so was und Talk-and-Bucket-Filter benutzt. Das Ding macht selber DHCPv6-PD, also Prefix Delegation,

indem ich ihm einfach einen Range gebe, auf dem er DHCPv6 spielt. Das ist eigentlich ein schönes Stück Software. Funktioniert auch sehr stabil. Ist halt nur leider unterdokumentiert. Da müsste man mal was tun, um mal was in die Community zurückzugeben.

Dann haben wir noch ziemlich zum Schluss die Adressproblematik. Was mache ich als neuer Lir? Ich kriege 1024 Adressen. Das mache ich, wenn ich mehr als 1024 Kunden habe und ich brauche noch ein paar für meine Infrastruktur. Dann muss ich leider so hässliche Dinge machen

wie Carrier-Grade-Nut, weil es bleibt mir nichts anderes übrig. Und ich muss natürlich Dual-Stack machen, also sprich IPv6. Das ist wiederum total fluffig, weil IPv6 kann ich überall einfach anschalten. Gerade mit modernen CPEs, wie wir heute Morgen gesehen haben, sind es irgendwie drei Mausklicks und dann geht es.

Oder bei der Fritzbox ist es auf jeden Fall einer, IPv6 aktivieren. Das heißt, da ist irgendwie ganz dringend mal auf Content-Provider-Seite die Transition auf IPv6 notwendig. Die wichtigen Leute, also die meistbesuchten Sites wie YouTube, Google, Netflix

haben mittlerweile alle V6. Ich glaube, in der Facebook hat das auch noch. Gibt es irgendwas Großes, was kein V6 hat? Twitter hat keinen V6. GitHub hat keinen V6.

Azure hat keinen V6. Amazon hatte lange Zeit auch keinen IPv6. Mittlerweile scheint das aber für einige Loadbalancer zu funktionieren. Jetzt haben wir relativ viel über die Technikgeräte. Was machen wir sonst noch so? Wir machen Monitoring.

Logging muss halt auch sein. Ich will wissen, was da draußen im Feld läuft. Das mache ich mit der Singer 2. Wenn die Geräte quaken, will ich auch wissen, dass sie gequakt haben und will mir das im Zweifelsfall zentral angucken können. Monitoring mache ich mit der Singer 2.

Die ganze Konfiguration daraus fällt aus dem Ansible, mit dem ich sowieso alles andere aufsetze. Ich kann ja gleich das Monitoring damit aufsetzen, weil dann kenne ich schon alle Maschinen. Die Singer sammelt für uns ein bisschen Performance-Daten, sprich Interface-Auslastung, Platten-Auslastung, Pink-Siden, den ganzen Sums.

Das Ganze wandert in der Influx-DB und daraus kann ich mir hübsche Grafahner der Sports bauen. Das ist sehr management-kompatibel, wenn man einen Zeiger für die Internet-Anbindung hat. Wenn das rot ist, musst du mehr Geld einwerfen.

BGP-OSPF-Verbindungen, Neighbor-States-Monitoren, Festplatten-Führstände, Erreichbarkeiten. Logging. Wozu brauche ich Logging? Wenn etwas kaputt geht, tut es das an mehreren Stellen.

Meistens komme ich auch nicht mehr auf das Gerät drauf, das gerade kaputt gegangen ist. Wenn ich Glück habe, kriege ich noch die letzten 3 Syslog-Meldungen mit, die da sagen, CPU-Overtemperature oder irgendwas Ähnliches. Oder Hilfe Mardabis. Zentrales Logging ist wichtig.

Ich hoffe, dass ihr in eurer Firma überall einen Syslog- oder Eventlog-Collector habt, der so etwas tut. Was noch wichtig ist, alle Dienste sollten auf UTC laufen. Oder zumindest auf einer einheitlichen Zeitzone. Das kann sonst zu sehr verwirrenden Effekten führen, wenn man so durch Logs guckt. Weil einige Zeitstempel irgendwie 2 Stunden vorher sind.

Deswegen sollte man sich von vornherein auf eine Zeitzone einigen. Am einfachsten geht UTC, weil man da auch bei Geräten, die man so aus der Kiste nimmt, gar nichts mehr konfigurieren muss. Die laufen meistens auf UTC. Zum Sammeln haben wir Greylock 2 mit einem Elastix-Dutch dahinter.

Ich habe ein schönes grafisches Interface, wo ich immer meine ganzen Regeln zusammenklicken kann. Ich habe eine grafische Log-Auswertung. Und ich kann mir entsprechend Alarmierungsregeln zusammenbauen. Das heißt bei bestimmten Events schickt mir mal eine E-Mail oder eine Telegram-Nachricht oder ähnliches.

So weit Fragen. Da hinten. Was kostet denn so ein Ablink, wenn ich den jetzt sage? 100 MBit möchte ich haben bei dir? Was bezahle ich da? Ich glaube, es waren um die 30, 40 Euro.

Telekom konkurrenzfähige Preise. Ist das dann symmetrisch? Üblich aber so schon. Es lässt sich ja annehmen, dass Kunden viel Scheiße bauen. Also illegalen Kunden ziehen. Was macht ihr, wenn ein Rechteinhaber nach Kundendaten klagt?

Loggt ihr die Verbindungen, die die Kunden aufbauen? Oder sagt ihr dann, wir können nichts? Wir sind dazu verpflichtet, zumindest die IP-Adresse des Kunden für 60 Tage zu loggen. Oder wo er sich eingewählt hat. Bei CGNet können wir natürlich nicht viel tun, weil das kann irgendwie eine Handvoll Kunden sein, die dahinter waren.

Das hat nichts damit zu tun. Das Problem ist, was du jetzt beschreibst, ist ein Legal-Problem. Die Bundesnetzagentur und ihre Gretzgeber sind da sehr eindeutig. Ab einer bestimmten Größe des ISPs musst du automatische Interfaces zur Verfügung stellen, wo die Strafverfolgungsbehörden die Daten direkt rausziehen können.

Das ist das, was unter dem Oberbegriff Sienabox läuft. Da können Sie live die Daten-Streams rausziehen. Alle Datenleitungen in Deutschland sind überwacht. Glasfaserleitungen, die rausgehen aus Deutschland, sind auch alle überwacht. Oder zumindest die Möglichkeit da, sie zu tappen. Das ist auf jeden Fall immer vorhanden. Was er hat, ist aber ein kleiner Mini-ISP.

Der Gesetzgeber sagt, wenn er ausleiten muss, wenn jemand Rechte verletzt hat, dann kann er dafür Geld verlangen. Er kann also sagen, der technische Aufwand, den er treiben muss, den kann er sich dafür bezahlen lassen. In der Realität sieht es so aus,

dass die meisten Anfragen, die mir untergekommen sind, eigentlich alle nach den 60 Tagen gekommen sind. Dann hast du einen mit den Schultern gezuckt und gesagt, Leute, ich habe es gelöscht. Ich kann dir dazu nichts mehr sagen. Da sind dann auch die Kommissare, die dich zum Teil anrufen, irritiert, dass du die Daten nicht so lange vorhältst. Die Wahrscheinlichkeit, dass da was passiert,

ist praktisch null. Die großen Inhaber, die abmahnen Rechtsanwälte, benutzen die APIs, die auch von großen Carriern zur Verfügung gestellt werden, um Massenabmahnung zu machen. Die gehen da rein mit 10.000 illegalen IP-Adressen, die illegalen Content gezogen haben,

jagen das Ding auf die API, da fährt eine Excel-Tabelle raus, da wird ein Serienbrief gemacht und zack gehen die Abmahnungen raus. Er hat 30 Kunden im Augenblick und wir wünschen ihm natürlich, dass er 3.000 bekommt, aber auch mit 3.000 ist er nicht verpflichtet, solche APIs einzurichten. Deswegen ist er völlig uninteressant im Augenblick für die Abmahnindustrie, weil es einfach viel zu teuer ist.

Er müsste 250 Euro wahrscheinlich nehmen für jeden einzelnen Vorgang, für jede einzelne Abmahnung und wenn du weißt, wo liegen die jetzt? Bei 400 Euro? Die Win-Marge für die Rechtsanwälte ist einfach nicht da. Also machen sie es nicht. Es ist einfach nur eine große Geldverdienmaschine. Ich hoffe, ich habe die Frage so ein bisschen beantwortet. Wir können auch gerne nachher nochmal weiter drüber sprechen.

Wir haben all diese großen, und nachdem die Abmahnungen... Wir haben eigentlich jetzt 3 oder 4 Abmahnungen in Deutschland

und in Europa 3 oder 4 großen, die, ich würde sagen, 80 bis 90% aller Abmahnungen haben. Unterstützen Sie Ihren lokalen ISP. Und ja, tun Sie es, denn wenn sie sterben, haben Sie die einzige Chance, auf das Internet zu kommen, dass Sie die großen abnehmen müssen. Und Sie wissen nie, was sie mit Ihrem Verkehr tun.

Und das andere? Open Nebula. Wieso Open Nebula? Hast du da Präferenzen gegenüber anderen Virtualisierungskonzepten? Ich kriege es in 10 Minuten funktionierend aufgesetzt.

Also deine persönliche Präferenz ist, es ist wie gefühlt meine persönliche Präferenz. Es ist deutlich simpler und einfacher als ein OpenStack. Es ist freies Software, es geht einfach an LibWirt dran. Mit Proxmox habe ich nicht so viel Erfahrung. Und wie gesagt, das ist...

Du brauchst echte VMs und keine Docker-Container. Ich brauche echte VMs und keine Docker-Container, weil ich brauche Netzwerk-Interfaces. Da hinten war noch einer. Das Sicherheitskonzept von Freifunk Nord greift hier nicht. Weil er als Gewerbetreiber Personendaten an seinem System hält. Und das ist da überhaupt nicht berücksichtigt.

Danke für den Vortrag. Kannst du mal kurz erklären, wie das geografisch bei euch aussieht? Ihr habt jetzt einen Masten in der Mitte.

Habt ihr da zwei anderen Masten noch dran gemacht? Wir haben erst mal einen Masten in der Mitte. Und dann noch... Jetzt müsste ich lügen an einer Mühle. Ein paar Kilometer weiter noch mal eine Schüssel mit ein paar Sektor-Antennen. Wir suchen uns halt tatsächlich hohe Punkte noch in der Gegend aus. Also die Ausdehnung ist dann so 10-15 Kilometer insgesamt? Genau, erst mal 10-15 Kilometer.

Und dann geht es halt zum nächsten Mast, zum nächsten Mast, zum nächsten Mast. Und die Masten mit Glasfaser anbinden wollt ihr nicht? Je nachdem, wie es möglich ist. Wenn ich Matschboden habe, dann legt mir da keiner Glasfaser rein. Also die lasst ihr daneben auch? Ja, entweder wir lassen sie legen oder eventuell hast du einen Carrier vor Ort, wo du die Glasfaser mit benutzen kannst.

Oder du musst halt tatsächlich ein Wireless-Uplink machen. Okay, danke. So, sind da noch weitere Fragen jetzt? Letzte Chance. Ich hätte noch eine. Warum habt ihr euch gegen Gerätunnel entschieden und habt Faulanz gemacht auf dem Sektor-Antenn?

Gute Frage, weil das erstmal für uns logischer klang. Okay, die meisten Wi-Fi-Projekte benutzen im Moment Gerätunnels. Okay. Für diese Anwendungen, weil die besser skalieren. Aber ich war etwas überrascht mit dem Faulanz.

Also wir haben sowieso Client-Isolation drin auf dem Sektor. Und ich kann natürlich zu jedem Wireless-Client noch extra einen Gerätunnel ziehen. Aber ich sage mal, für die Anwendungszwecke, die wir haben, sind Faulanz erstmal ausreichend. Und ich würde mal vermuten, es schmeißt mindestens zwei Faulanz zu jeder Nanobeam.

Eins für Management, eins für Client-Traffic, oder? Richtig. Gut, dann war das die letzte Frage. Vielen Dank, Falk.