[Berlin-wireless] Technik-Idee / Frage / Begrenzung der Clients pro AP - DHCP und BATMAN

[Sven Roederer]

Harald,

selarate Router mit jeweils eigenem VPN-uplink - das ist das setup, was
ich hier mit meinem Nachbar habe.
Dadurch haben wir getrennte IP-Netze (Layer3) aber duch BATMAN sind die
dann auf beiden Router vorhanden aus Layer2-sicht.
WEnn jetzt ClientA mit RouterA assoziert und einen DHCP-Request macht,
antwortet der DHCP-server, der schneller ist. Im allgemeinen von
RouterA. WEnn jetzt DHCP-A nix sagt oder nicht verfügbar ist, antwortet
DHCP-B und verteilt seine IP-Konfiguration. Da die IP-Netze verschieden
sind, gibt'S natürlich auch verschiedene Default-Gateways (i.a. der
Router selbst).

Man kann jetzt natürlich auf allen ROutern das gleiche IP-Netz
configurieren und jeden nur einen bestimmten BEreich der Adressen
verteilen lassen, dass es keine Doppelvergabe gibt.
So hätte man wahrscheinlich eine Redundanz der DHCP-Server. Mit der
"DHCP-option 3" [1] könnte man aich alle clients auf eine zentrale
default-route senden (oder sogar mehrere)


[1] -
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml)


On 09.01.2016 14:37, Harald Stürzebecher wrote:
> Geht das in der Praxis, wenn die Router jeweils mit eigenen VPN-Keys
> eingerichtet sind, damit sie auch eigenständig arbeiten könnten?
> 
> Ich hätte jetzt damit gerechnet, dass jeder DHCP "seinen" Router als
> Gateway nennt, unabhängig davon, mit welchem AP der Client verbunden
> ist. Dann läuft der Traffic erst mal zum entsprechenden Router und von
> dort in den Uplink. Solange der Uplink - z.B. über VPN - nur 10 oder 20
> MBit/s schafft, wird das zwar in der Praxis nicht stören, wäre IMHO
> trotzdem nicht optimal.
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 213 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20160109/70e7ca58/attachment.sig>