wiki/Technik/Routing/Fussgaengerzonenproblem-Zusammenfassung.page

---
toc: no
title: Überblick bzw. der Versuch einer Zusammenfassung
...

zu dem Beitrag [Gullivers Reisen durch das FF-Routing - oder: Vom Fußgängerzonenproblem zur IGP-Kopplung](Fussgaengerzonenproblem)

# Problemlage 

WLAN mesh Chaos und die lange Fußgängerzone

1. Lösung: [1 IGP für das ganze FF-Netz](https://mesh-j-4.free.de/~ffdo/wiki/Technik/Routing/Fussgaengerzonenproblem#fu%C3%9Fg%C3%A4ngerzonenproblem---erste-l%C3%B6sung-1-igp-f%C3%BCr-das-ganze-ff-netz)  
           1 IGP für ein ganzes FF-Netz funktioniert, aber skaliert nicht beliebig.

2. Lösung: [2 IGPs](Fussgaengerzonenproblem#Fußgängerzonenproblem - zweite Lösung: 2 IGPs)  
           Die Möglichkeit, zwei oder mehr IGPs zu verwenden, um das Fussgängerzonenproblem zu lösen, hängt von der Fähigkeit der beteiligten IGPs ab, externe Routinginformationen zu nutzen.

(BTW, auch bei B.A.T.M.A.N. könnte man dank BLA mehrere Instanzen über einen normalen (realen oder virtuellen) L2-Switch zusammenschalten. Selbst ohne Metrikübermittlung wäre dann das Routing zwischen den Instanzen optimal, muss aber immer über den Switch laufen. Bei dieser Konstruktion teilt man das Routing des Netzes zwar in zwei oder mehr Bereiche auf, sodass der Routingtraffic in jeder Instanz nur mit der Größe der Instanz wächst, nicht mit der Größe des gesamten Netzes - abgesehen von allen MAC Adressen aus den anderen Instanzen, die in den B.A.T.M.A.N. Tabellen auf den Routern im Innern der Instanz als clients der Router am Switch erscheinen (“externe Routen”). Mglw. könnte so eine Kopplung auch durch die Präsenz zweier Instanzen innerhalb eines Routers erfolgen: “As of 2010.2.0 it is possible to let a single mesh node participate in mutliple mesh clouds at the same time which makes it necessary to assign interfaces to individual mesh clouds and having multiple batX interfaces.” (B.A.T.M.A.N. Doku)

Fazit: Mglw. könnte man mit BLA größere B.A.T.M.A.N. Netze bauen als mit einer einzelnen Instanz, aber wer bitteschön will denn noch größere Broadcastdomänen, wie sie hierbei - mit Hilfe des Switches - zustandekämen? Allerdings besteht ein interessanter Aspekt des Routings auf Layer 2 darin, dass interessierte Freifunkerinnen unmittelbar eine Verbindung auf Layer 2 zueinander aufbauen können, was die Nutzungsmöglichkeiten einer freien Netzwerkinfrastruktur erweitert. Doch dafür müssen wohl andere Lösungen untersucht werden, als die Ausdehnung des L2 Routing auf das FF-Kabelnetz.)

## Ein Konzept für die Kopplung von IGP Instanzen

[Globale Metrik auch bei unterschiedlichen IGPs?](Fussgaengerzonenproblem#Globale Metrik auch bei unterschiedlichen IGPs?)

So machen’s die Großen[tm]:

- [BGP - MED](Fussgaengerzonenproblem#BGP - MED)    
  BGP-MED ist eine echte Option, kann aber in der Praxis Probleme machen, insb. beim Skalieren.

- [OSPF areas](Fussgaengerzonenproblem#OSPF areas)  
  OSPF areas sind ein optimierter Kandidat um größere Netze so zu strukturieren, dass der Routingtraffic minimiert wird. Doch leider taugt OSPF nicht für WLAN adhoc Meshes:-(

## And the winner is …

… [die Integration verschiedener Routingprotokolle unter Verwendung einer globalen Metrik](Fussgaengerzonenproblem#And the winner is …). (Mit “global” ist hier (noch;) nicht die ganze Welt(herrschaft;;) gemeint, sondern alle Teile eines (heterogenen) FF-Netzes, die Routinginformationen (und ergo Datenpakete) direkt mit mindestens einem anderen Teil des betrachteten FF-Netzes austauschen.

## So geht’s also auch: 

[Mit einer open source routing suite](Fussgaengerzonenproblem#So geht’s also auch: mit einer open source routing suite)

[Was ist der Unterschied zwischen IGP-Kopplung und OSPF areas?](Fussgaengerzonenproblem#Was ist der Unterschied zwischen IGP-Kopplung und OSPF areas?)

- Die OSPF backbone area
- backbone area und Schleifenfreiheit
- backbone area als Panopticon

[Entspricht IGP-Kopplung einem DV Protokoll?](Fussgaengerzonenproblem#Entspricht IGP-Kopplung einem DV Protokoll?)

- counting-to-infinity :-(
- backbone area rettet !-)
- feasibility conditions
- route starvation ?

IGP-Kopplung scheint global wie ein DV Routing zu funktionieren. In seiner bisher diskutierten naiven Form unterliegt IGP-Kopplung daher dem counting-to-infinity Problem, aber nicht der route starvation. Es reicht als naives DV Protokoll aber nicht an Babel, OSPF oder BGP heran. Die offene Frage nach einer notwendigen Bedingung für global optimales Routing lässt sich also mit gutem Bauchgefühl im Bermudadreieck zwischen naivem Bellman-Ford und backbone area bzw. BGP an den anderen Ecken des Dreicks vermuten.

# Laborstudie: Kopplung von IGP-Instanzen mit kompatibler Metrik zu einer gemeinsamen Routingdomäne mit global kürzesten Wegen und Toleranz gegen Partitionierungen.

in arbeit