reudnetz/public-wiki
14
0
Fork 0
Code Issues 20 Pull requests Releases Wiki Activity
public-wiki/technikzeugs/theorie/Das-theoretische-Netz.md

6.3 KiB
Raw Blame History

Auf dieser Seite wird die angepeilte Infrastruktur möglichst genau beschrieben.

Die einfache Konfiguration

Genereller Überblick

Anschluss beim ISP --> Der Server --> Der Switch --> PoE --> Nanostation 1 (Bridgemode) --)) Nanostation 2 (Routermode) --> PoE --> Ethernetanschluss

Der Server

DHCP Server für das ganze Netz

Der Switch

Unkritsch. Glasfaser auf Gigabit-Ethernet. Vermutlich macht es keinen Sinn einen PoE-Switch zu Benutzen

Nanostation 1 (Bridge)

WLAN und LAN im sind im selben Netz. Die Station holt sich ihre IP vom DHCP-Server. Sie gibt den Traffic nur durch.

  • Network Mode: Bridge
  • Wireless Mode: Accesspoint
  • LAN Address: DHCP
  • FallbackIP: lassen wir die so? bzw. wollen wir überall die selbe Nutzen

Nanostation 2 (Router)

Diese Nanostation funktioniert als DHCP Relay. Sie nimmt die DHCP-Requests von der Seite des Ethernetanschlusses entgegen und leitet sie direkt an den DHCP-Server weiter. So werden Braodcasts vermieden und hinter der Nanostation benimmt sich alles wie ein Subnetz ohne das ein NAT notwendig ist.

  • Network Mode: Router
  • Wireless Mode: Station
  • LAN Address: DHCP
  • FallbackIP: lassen wir die so? bzw. wollen wir überall die selbe Nutzen
  • LAN: Relay
    • DHCP Server IP: klar oder?
    • Agent ID: kann leer bleiben oder eine Info über die Station enthalten

etwas Komplizierter für den Anfang

Statt dem direkten Anschluss vom ISP benutzen wir VPN über einen Schlandkabelanschluss:

Genereller Überblick

Interwobz --> VNP Server ---Schlandkabelnetz---> VPN Server --> DHCP Server --> der Rest wie oben…

Der Server

Macht in diesem Fall VPN und DHCP. Für wenige Verbindungen reicht ein PlasteRouter aus.

Mesh?

Wie würde ein Meshnetz optimalerweise aussehen?

Alternativen:

1-1-zitat equi, wir verwenden momentan ne abgeschwächte form von 3. Laut ben wird das eventuell problematisch wass die routing-performance auf der Nanostation 2 (Routermodus) angeht. Das sollte mal gebenchtmarkt werden. Ansonsten hat L2.5 auch noch seinen charme, aber dafür müssten wir nen bestimmtes modul in den ubiquity-kernel laden, welches die nicht mitliefern, und welches es auch sonst nicht einfach so zu hohlen gibt, namentlich gretap, eventuell kann man das aber selbst kompilieren, oder bei denen anrufen, müsste man auch mal schauen.

  • L2 / VLAN-switched Netz "1 User = 1 802.1Q VLAN" = momentaner Westnetz-Aufbau

    • Hardware im Rest des Netzes braucht nur Ethernet-Funktionen
    • wenig Bugs in kaufbaren Geräten (z.B. Managed Switches)
    • einfach für 1 User mehrere Ports zu schalten, auch an völlig verschiedenen Stellen im Netz
    • optimaler Trafficflow bei mehreren Ports für 1 user
    • zentralisiertes Routing einfach zu managen
    • zentralisiertes DHCP ohne relay
    • VLANs müssen an vielen Stellen geconfigt werden => besonders scheisse wenn das Netz nicht "sternförmig" ist
    • suboptimaler Trafficflow zwischen Usern (zum Router + zurück)
    • Ethernet-Loops möglich, STP stinkt
    • mittelmässige Debuggingfeatures auf Ethernet-Ebene

  • L2.5 / IP-tunneled L2 "1 User = 1 Extended Ethernet Bridge" = VXLAN, GREtap (in billig), VPLS (in teuer/professionell) Ethernet-Frames werden am Netzwerkrand/User-Schnittstelle in Tunnel eingepackt und laufen als Eth<-IP<-Eth<-IP durch den Backbone

    • Backbone kann frei auf- und umgebaut werden
    • Flexibler Backbone impliziert gute Redundanzmöglichkeiten
    • einfach für 1 User mehrere Ports zu schalten, auch an völlig verschiedenen Stellen im Netz
    • zentralisiertes Routing an Tunnelendpunkt
    • zentralisiertes DHCP ohne relay 0 erhöhte MTU im Backbone nötig (allgemein kein Problem) 0 mittelmässiges Debugging (User kann kein traceroute im Backbone)
    • bei VXLAN/GREtap suboptimaler Trafficflow wenn mehrere Ports für 1 User (zentraler Router und zurück). VPLS hat das problem nicht dank Split-Horizon-Bridging, gibts nur (noch) nicht in Open Source.
    • in kaufbaren Geräten nicht bezahlbar, höchstens Mikrotik (kann VPLS)
    • für Linux-Möhren muss der Support im Kernel an sein, was bei Ubiquiti beim Standardkernel nicht ist -_-
    • kaufbare Geräte z.T. mit Bugs und Antifeatures im IP-Routing

  • L3 / Routed Edge "1 Port = 1 IP-Netz" = Routing in mehr oder weniger Reinform

    • Backbone kann frei auf- und umgebaut werden
    • Flexibler Backbone impliziert gute Redundanzmöglichkeiten
    • generell gut optimierbarer Trafficfluss
    • traceroute 4 life
    • mehrere IP-Netze pro User wenn mehrere Ports
    • NAT schwieriger zu managen wenns zwischen Usern applizieren soll
    • dezentrales Routing, komplexes IP-Management
    • DHCP entweder direkt auf Edge-Geräten oder mit Relay
    • kaufbare Geräte teuer (aber noch bezahlbar)
    • kaufbare Geräte z.T. mit Bugs und Antifeatures im IP-Routing

Homenet + Babels

wie schon geschrieben habe ich etwas mit Freifunk Daniel geplaudert. Dabei auch über Redundanz der Antennen sowie OpenSource auf den Antennen selbst gesprochen. Ein weiteres Szenario was ich durchdenken könnten:

  • Wir besorgen und besage Ubnt EdgeRouter für ~100€ das Stück.

  • Installieren OpenWrt und Homenet

    • Wie gut funktioniert das? Haben wir Anwendungsfälle zu anschauen?

  • Im Interface Menü lässt sich neben Static und DHCP Server nun auch Homenet auswählen

  • Auf unserer Antennen Infastruktur wird ebenfalls OpenWRT installiert

  • Damit das gut geht nutzen wir statt Loco besser die von Daniel empfohlenen Antennen

    • Die Antennen finde ich auch unabhängig vom Rest interessant.

  • Routing machen die Geräte dann selbst, wir bauen immer mehr Antennen überall hin und wenn mal was ausfällt sollte automatisch ein Plan B umgeroutet werden.

    • Naja, ich würde tatsächlich ungern ein Netz mit potentiell ausfallenden Routen bauen. Das macht für unsere Anwendung nicht so viel Sinn. Einfache Redundanz erfüllt das bei uns ja auch.

  • Laut D. lässt sich das ganze gut Debuggen, mit Netzgraphen (wie ich es verstanden habe)

  • Weitere Services wie Hosting von Service X machen wir auf weiteren Servern die wir ans Netz anstecken.

  • Was haltet ihr davon?

  • Wie können wir solche Modelle testen? Wieviel und welche Hardware brauchen wir, wie viel Aufwand an umflashen und aufbauen ist nötig, bis wir ein Benchmark bekommen?