technik:gateways:routing

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
technik:gateways:routing [20.09.2015 - 15:01] – lamdotechnik:gateways:routing [28.04.2019 - 11:38] (aktuell) – Externe Bearbeitung 127.0.0.1
Zeile 3: Zeile 3:
 Um nicht auf jedem Gateway zwingend alle Segmente als L2 vorhalten zu müssen, ist ein L3-Routing zwischen den Segmenten erforderlich. Da statische Routen schlecht skalieren, kommt OSPF als Routing-Protokoll zum Einsatz. Die L3-Verbindung erfolgt über ein Tinc-VPN. Um nicht auf jedem Gateway zwingend alle Segmente als L2 vorhalten zu müssen, ist ein L3-Routing zwischen den Segmenten erforderlich. Da statische Routen schlecht skalieren, kommt OSPF als Routing-Protokoll zum Einsatz. Die L3-Verbindung erfolgt über ein Tinc-VPN.
  
 +https://github.com/freifunk-stuttgart/tinc-ffsbb
 ===== Konfiguration ===== ===== Konfiguration =====
  
 ==== Vorbereitung: Einrichtung Tinc ==== ==== Vorbereitung: Einrichtung Tinc ====
  
-Tinc, VLAN-Support und bridge-utils installieren:+Tinc und bridge-utils installieren:
 <code> <code>
-apt-get install tinc vlan bridge-utils+apt-get install tinc bridge-utils
 </code> </code>
  
Zeile 15: Zeile 16:
 <code> <code>
 cd /etc/tinc cd /etc/tinc
-mkdir ffsVPN +mkdir ffsbb 
-mkdir ffsVPN/hosts/+mkdir ffsbb/hosts/
 </code> </code>
  
Zeile 32: Zeile 33:
 Mode = switch Mode = switch
  
-name = gw<gwnum> # z.B. gw10 +name = $HOST
- +
-# Kommentare ARE: +
-#Mode = switch +
-#Forwarding = off +
-#IndirectData = no +
-#DirectOnly = yes+
 </file> </file>
  
-In ''/etc/tinc/ffsVPN/hosts/'' liegen die Schlüsseldateien der Tinc-GWs.+In ''/etc/tinc/ffsbb/hosts/'' liegen die Schlüsseldateien der Tinc-GWs.
  
 Die Schlüsseldatei generieren Die Schlüsseldatei generieren
 <code> <code>
-tincd -n ffsVPN -K 4096+tincd -n ffsbb -K 4096
 </code> </code>
-und die Addresse ergänzen, z.B. ''/etc/tinc/ffsVPN/hosts/gw10'':+und die Addresse ergänzen, z.B. ''/etc/tinc/ffsbb/hosts/gw10'':
 <file> <file>
 Cipher = blowfish Cipher = blowfish
 Address = gw10.freifunk-stuttgart.de Address = gw10.freifunk-stuttgart.de
 +Port = 11100 
 +PMTUDiscovery = yes 
 +Digest = sha256 
 +ClampMSS = yes
 -----BEGIN RSA PUBLIC KEY----- -----BEGIN RSA PUBLIC KEY-----
 MIICCgKCAgEA4G/ek8KZuHFZPVuNK5HsQvCPAe/lhzYp2ERqVUWa1jHnnG/5fk1E MIICCgKCAgEA4G/ek8KZuHFZPVuNK5HsQvCPAe/lhzYp2ERqVUWa1jHnnG/5fk1E
Zeile 67: Zeile 65:
 </file> </file>
  
-Das tinc-Interface konfigurieren (''/etc/network/interfaces.d/ffsVPN''):+Das tinc-Interface konfigurieren (''/etc/network/interfaces.d/ffsbb''):
 <file> <file>
-allow-hotplug ffsVPN +allow-hotplug ffsbb 
-auto ffsVPN +auto ffsbb 
-iface ffsVPN inet manual +iface ffsbb inet static 
-        pre-up ifconfig $IFACE up +        tinc-net ffsbb 
-        post-up ifup $IFACE.100 +        tinc-mlock yes 
-        pre-down ifdown $IFACE.100 +        tinc-pidfile /var/run/tinc.ffsbb.pid
-        post-down ifconfig $IFACE down +
- +
-auto ffsVPN.100 +
-allow-hotplug ffsVPN.100 +
-iface ffsVPN.100 inet static+
         address 10.191.255.<gwnum>/24    # Z.B. 10.191.255.10         address 10.191.255.<gwnum>/24    # Z.B. 10.191.255.10
         netmask 255.255.255.0         netmask 255.255.255.0
         broadcast 10.191.255.255         broadcast 10.191.255.255
-        vlan-raw-device ffsVPN + post-up         /sbin/ip rule add iif $IFACE table stuttgart priority 7000 || true 
- post-up         /sbin/ip rule add iif $IFACE table ffs priority 7000 + pre-down        /sbin/ip rule del iif $IFACE table stuttgart priority 7000 || true
- pre-down        /sbin/ip rule del iif $IFACE table ffs priority 7000+
  
 </file> </file>
Zeile 91: Zeile 83:
 Routing-Tabellen anlegen, dazu zwei Zeilen zu ''/etc/iproute2/rt_tables'' hinzufügen: Routing-Tabellen anlegen, dazu zwei Zeilen zu ''/etc/iproute2/rt_tables'' hinzufügen:
 <code> <code>
-70 ffs+70 stuttgart 
 +71      nodefault
 42 icvpn 42 icvpn
-</code> 
- 
-Um das VPN automatisch zu starten, den entsprechenden Eintrag zu ''/etc/tinc/nets.boot'' hinzufügen: 
-<code> 
-ffsVPN  
 </code> </code>
  
Zeile 109: Zeile 97:
 </code> </code>
  
-Da FFS z.Z. noch keinen IPv6-Upstream hat, erfolgt die Einrichtung zuerst nur für IPv4, weshalb zunächst nur der IPv4-Daemon benötigt und der IPv6-Daemon daher deaktivert wird: +Die Konfiguration von bird erfolgt über den Generator https://github.com/freifunk-stuttgart/FfsConfigGenerator, hier nur exemplarisch:
-<code> +
-systemctl disable bird6 +
-</code> +
- +
-Die Konfiguration von bird erfolgt über ''/etc/bird/bird.conf'':+
 <file> <file>
 router id 10.191.255.<gw>;      # z.B. 10.191.255.10 router id 10.191.255.<gw>;      # z.B. 10.191.255.10
 +
 +# Define a route filter...
 +filter ffs_filter {
 +    if net ~ 172.21.0.0/16 then accept;
 +    if net ~ 10.190.0.0/15 then accept;
 +    else reject;
 +}
  
 protocol kernel { protocol kernel {
Zeile 123: Zeile 113:
         scan time 20;           # Scan kernel routing table every 20 seconds         scan time 20;           # Scan kernel routing table every 20 seconds
         export all;             # Default is export none         export all;             # Default is export none
 +        import all;
         kernel table 70;        # Kernel table to synchronize with (default: main)         kernel table 70;        # Kernel table to synchronize with (default: main)
         export filter {         # Propagate routes with low metric into kernel table         export filter {         # Propagate routes with low metric into kernel table
Zeile 128: Zeile 119:
                 accept;                 accept;
         };         };
- 
 } }
  
Zeile 143: Zeile 133:
         ecmp no;                # Kein Equal-Cost-Multipath, um Problemen mit unterschiedlichen         ecmp no;                # Kein Equal-Cost-Multipath, um Problemen mit unterschiedlichen
                                 # Uplinks aus dem Weg zu gehen                                 # Uplinks aus dem Weg zu gehen
-        import all; +        import filter ffs_filter;  # filtert alle andern IPs 
-        export filter { +        export filter ffs_filter;  # filtert alle andern IPs 
-                accept; +
-        };+
         area 0.0.0.0 {          # Backbone-Area         area 0.0.0.0 {          # Backbone-Area
             external{             external{
Zeile 152: Zeile 141:
             };             };
  
-           interface "ffsVPN.100" {   # Run OSPF over VPN+           interface "ffsbb" {   # Run OSPF over VPN
                 cost            100;                 cost            100;
                 hello           10;                 hello           10;
Zeile 164: Zeile 153:
            };            };
  
-           interface "br*" {    # Don't run OSPF over interface, but propagate networks +#           interface "br*" {    # Don't run OSPF over interface, but propagate networks 
-                stub yes; +#                cost 1000; 
-           };+#                stub yes; 
 +#           }; 
 +#           interface "ffs-br" {    # Don't run OSPF over interface, but propagate networks 
 +#                cost 1000; 
 +#                stub yes; 
 +#           }; 
 +           stubnet 172.21.28.0/22;      # eigener DHCP Range Segment 0 
 +           stubnet 10.190.48.0/21;      # eigener DHCP Range Segment 1 
 +           stubnet 10.190.112.0/21;     # eigener DHCP Range Segment 2 
 +           stubnet 10.190.176.0/21;     # eigener DHCP Range Segment 3 
 +           stubnet 10.190.240.0/21;     # eigener DHCP Range Segment 4           
        };        };
 }; };
Zeile 172: Zeile 171:
 </file> </file>
  
 +==== Wie funktioniert das ganze? ====
 +
 +Über das VPN bauen die bird-Instanzen OSPF-Adjacencies auf und tauschen darüber Informationen über die bekannten Netze aus. Jede OSPF-Instanz berechnet dann für sich, wie dieses Netz am besten erreicht werden kann. Da OSPF ein Link-State-Protokoll ist und alle Instanzen die gleichen Informationen haben und den gleichen Algorithmus verwenden, kommt es dabei auch nicht zu Loops.
 +
 +Bird ist so konfiguriert, dass es zwei Arten von Routen propagiert:
 +  - Statische Kernel-Routen in der stuttgart-Tabelle. Hierüber können andere Gateways den lokalen Uplink (egal, ob per VPN oder über lokale Ausleitung realisiert) nutzen, ohne dass das auf den anderen GWs konfiguriert werden muss.
 +  - Lokal auf den Interfaces br* konfigurierte Netze. Hierüber werden die am lokalen GW vorhandenen Segmente netzweit propagiert
 +
 +OSPF unterstützt prinzipiell Equal-Cost-Multipath, d.h. wenn ein Netz über mehrere Wege zu gleichen Kosten erreicht werden kann, kann ein Load-Balancing über diese Pfade erfolgen. Das ist hier aber deaktiviert, da am Uplink NAT erfolgt und daher keine echte Ende-zu-Ende-Verbindung zwischen FFS-Client und einem Ziel im Internet besteht. Würden hier unterschiedliche Pfade über unterschiedliche NAT-Boxen zum Einsatz kommen, kann es zu Problemen kommen.
 +
 +Die von bird berechnete Route zum entfernten Netz wird mit Metric 100 in die Routing-Tabelle übernommen. 
  • technik/gateways/routing.1442761316.txt.gz
  • Zuletzt geändert: vor 5 Jahren
  • (Externe Bearbeitung)