fff-layer3-vxmesh: join multple client nets with vxlan #82

jkimmel · 2021-01-20T09:45:26+01:00

jkimmel commented

2021-01-20 09:45:26 +01:00

Easily span a layer 2 network over a small group of, not necessarily
adjacent, routers.

This patch introduces a new vxmesh configuration section. It takes
care of setting up a shared client network using vxlan among all
configured routers.

As a result, clients can finally roam between the routers of the mesh.
It integrates well with the underlying layer 3 routing to make best use
of the infrastructure available. This way the network is not depending
on a contiguous layer 2 spanning tree topology and can make use of all
fallback mechanisms of the layer 3 underlay.

This example config ...

config gateway
	option peer_ip6 '2001:0db8::1' # required

...

config vxmesh
	option proto 'vxlan|vxlan6' # required
	option vid   '42'           # required

	# ...
	# any vxlan options can be included
	# ...

	# list of peers for headend replication
	list peer '2001:0db8::1'    # list can include the ip of the router
	list peer '2001:0db8::2'    # this way the complete config section
	list peer '2001:0db8::3'    # can be copied to all routers in the
	list peer '2001:0db8::4'    # group
	...

... will generate ...

config interface client
	...
	# append and remove the vxmesh0 entry
	# depending on whether a vxmesh is configured
	ifname '... vxmesh0'
	...

...

config interface 'vxmesh0'
	option proto 'vxlan6'
	option vid '42'

config vxlan_peer
	option vxlan 'vxmesh0'
	option dst '2001:0db8::2'

config vxlan_peer
	option vxlan 'vxmesh0'
	option dst '2001:0db8::3'

config vxlan_peer
	option vxlan 'vxmesh0'
	option dst '2001:0db8::4'

It will also take care and configure the
dhcp.@dnsmasq[0].authoritative setting depending on whether a vxmesh
is enabled or not.

Signed-off-by: Johannes Kimmel fff@bareminimum.eu

Easily span a layer 2 network over a small group of, not necessarily adjacent, routers. This patch introduces a new `vxmesh` configuration section. It takes care of setting up a shared client network using vxlan among all configured routers. As a result, clients can finally roam between the routers of the mesh. It integrates well with the underlying layer 3 routing to make best use of the infrastructure available. This way the network is not depending on a contiguous layer 2 spanning tree topology and can make use of all fallback mechanisms of the layer 3 underlay. This example config ... ``` config gateway option peer_ip6 '2001:0db8::1' # required ... config vxmesh option proto 'vxlan|vxlan6' # required option vid '42' # required # ... # any vxlan options can be included # ... # list of peers for headend replication list peer '2001:0db8::1' # list can include the ip of the router list peer '2001:0db8::2' # this way the complete config section list peer '2001:0db8::3' # can be copied to all routers in the list peer '2001:0db8::4' # group ... ``` ... will generate ... ``` config interface client ... # append and remove the vxmesh0 entry # depending on whether a vxmesh is configured ifname '... vxmesh0' ... ... config interface 'vxmesh0' option proto 'vxlan6' option vid '42' config vxlan_peer option vxlan 'vxmesh0' option dst '2001:0db8::2' config vxlan_peer option vxlan 'vxmesh0' option dst '2001:0db8::3' config vxlan_peer option vxlan 'vxmesh0' option dst '2001:0db8::4' ``` It will also take care and configure the `dhcp.@dnsmasq[0].authoritative` setting depending on whether a vxmesh is enabled or not. Signed-off-by: Johannes Kimmel <fff@bareminimum.eu>

jkimmel added the

labels 2021-01-20 09:45:40 +01:00

ChristianD commented

2021-01-20 16:54:50 +01:00

Erstmal, die Idee ist toll. Ich hab aber so einige Fragen dazu um das ganze Kontrukt zu verstehen.

MTU
Ich hab auf Anhieb jetzt nichts gefunden das du etwas an der MTU machst. Ich gehe daher mal davon aus, das vxlan Interface wird so groß wie vxlan durch 1500byte passt. Was passiert nun wenn die Router die in der vxlan Group sind z.b. per wireguard (davon ausgehend das wireguard außen herum fragmentieren nicht funktioniert) verbunden sind? Gehts dann innen für die Clients kaputt?
RA und DHCP
Ich gehe mal davon aus, das jeder Router in der vxlan Group sein eigenes v4 und v6 Netz haben sollte:
2.1) Bei IPv4 DHCP antwortet einfach der schnellste DHCP Server und gut, das dürfte kein Problem sein und beim roamen werden die Daten halt durchs vxlan zum richtigen Router geschickt.
2.2) Bei IPv6 werden aber wohl alle RAs genommen oder? D.h. der Client hat u.U. viele Public Adressen? Soweit ich weiß fängt er dann das würfeln an wohin er den Traffic schickt. D.h. der Traffic wird sich immer auf alle Router in der vxlan Group verteilen. Ist das soweit richtig?

Das wars erstmal was mir auf Anhieb eingefallen ist, ich muss mir das ganze nochmal genauer angucken

Erstmal, die Idee ist toll. Ich hab aber so einige Fragen dazu um das ganze Kontrukt zu verstehen. 1) MTU Ich hab auf Anhieb jetzt nichts gefunden das du etwas an der MTU machst. Ich gehe daher mal davon aus, das vxlan Interface wird so groß wie vxlan durch 1500byte passt. Was passiert nun wenn die Router die in der vxlan Group sind z.b. per wireguard (davon ausgehend das wireguard außen herum fragmentieren nicht funktioniert) verbunden sind? Gehts dann innen für die Clients kaputt? 2) RA und DHCP Ich gehe mal davon aus, das jeder Router in der vxlan Group sein eigenes v4 und v6 Netz haben sollte: 2.1) Bei IPv4 DHCP antwortet einfach der schnellste DHCP Server und gut, das dürfte kein Problem sein und beim roamen werden die Daten halt durchs vxlan zum richtigen Router geschickt. 2.2) Bei IPv6 werden aber wohl alle RAs genommen oder? D.h. der Client hat u.U. viele Public Adressen? Soweit ich weiß fängt er dann das würfeln an wohin er den Traffic schickt. D.h. der Traffic wird sich immer auf alle Router in der vxlan Group verteilen. Ist das soweit richtig? Das wars erstmal was mir auf Anhieb eingefallen ist, ich muss mir das ganze nochmal genauer angucken

rohammer commented

2021-01-20 19:47:21 +01:00

Hi lemmi,
feine Sache!
Mir ist da der Vorteil, das alles in die /etc/config/gateway zu schreiben, nicht ganz klar. Bis auf das dhcp Ding ist das fast eine Kopie aus der config/network.
Das wird doch die Ausnahme sein, dass das jemand konfiguriert. Waere da nicht ein schoener Wikieintrag (den man so und so machen muss) wie man das "normal" konfiguriert ausreichend?
Andererseits egal, man muss es ja nicht benutzen und kann den Kram gleich in die config/network tippen.

Hi lemmi, feine Sache! Mir ist da der Vorteil, das alles in die /etc/config/gateway zu schreiben, nicht ganz klar. Bis auf das dhcp Ding ist das fast eine Kopie aus der config/network. Das wird doch die Ausnahme sein, dass das jemand konfiguriert. Waere da nicht ein schoener Wikieintrag (den man so und so machen muss) wie man das "normal" konfiguriert ausreichend? Andererseits egal, man muss es ja nicht benutzen und kann den Kram gleich in die config/network tippen.

jkimmel commented

2021-01-20 22:30:35 +01:00

@ChristianD

MTU:
TL;DR du brauchst 1570er MTU, sonst gehts leider nur so halb.
Der Aufbau macht nur in einem Netz mit genuegend grosser (1570) MTU Sinn. Bisher hatte ich noch keine Geraete, die das nicht schaffen und es muesste jetzt auch mit b5b0557f13 Wireguard fragmentieren koennen.
PMTUD funktioniert tatsaechlich, also Unicast bricht quasi nicht, aber Multicast traffic wird es nicht ueberleben.
Alternative ist das client netz auf 1430 herunterzuschrauben.
Adressvergabe
1. DHCP
  Jeder Router braucht seine eigene IPv4, kann aber im selben Subnetz wie die anderen arbeiten. DHCP muss dann entweder ein Geraet uebernehmen, oder man muss die DHCP Ranges unter den Routern aufteilen.
2. RA
  Ja das ist das schoene an IPv6. Einfach auf jedem router die gleiche Subnetzanycastadresse konfigurieren und fertig. Ich untersuch noch, wie ich mit ip6tables die Prioritaet der RAs filtern kann, sodass der naechste Router immer die hoechste Prio hat. Hier gewinnt aber auch in der Regel der Router, der am schnellsten aufloest.

@rohammer

Also ich glaube du unterschaetzt, wie viel behaemmerte Fehler ich schon gemacht habe um nur 3 Geraete sauber zu konfigurieren. Aktuell muss man n verschiedene configs in /etc/config/network sauber halten, das auch noch an mehrere Stellen, und natuerlich noch den Mist in /etc/config/dhcp nicht vergessen.

Dagagen nur einen Block auf ein paar Kisten kopieren ist einfach so viel angenehmer und laesst sich schoener automatisieren (was wirklich wichtig ist, weil man macht das mit dem vxlan ja eigentlich erst, weil man mindestens 3 oder mehr Geraete hat).

Darueber hinaus bin ich weiterhin der Meinung, dass wir am besten nur eine Source of Truth haben sollten und man moeglichst nichts in den anderen Dateien zu pfuschen hat.

Ich wuerde noch gern in der Zukunft die MTU fuer saemtliche Peerings automatisiert anpassen, die DHCP Ranges berechnen (siehe 2.1. oben), moeglicherweise einige sinnvolle Defaults setzen (z.B. no-checksumming, falls das etwas bringt beispielsweise) und wie in 2.2. angedeutet etwas schlauere Sachen mit den RAs basteln, um den Traffic besser zu steuern.

Ganz weit am Horizont ist noch das vxlan mit babel zu verheiraten, sodass quasi nur noch BUM Traffic ueber das vxlan muss, der Rest mit Hostrouten direkt zum richtigen Router findet, damit auch mehrer Uplinks sauber genutzt werden koennen, ohne vxlan tunneln zu muessen.

Jedenfalls fand ich den Patch so gerade noch handlich. Er tut schon was sinnvolles und man kann erkennen, wo die Reise hin soll. :)

@ChristianD 1. MTU: *TL;DR du brauchst 1570er MTU, sonst gehts leider nur so halb.* Der Aufbau macht nur in einem Netz mit genuegend grosser (1570) MTU Sinn. Bisher hatte ich noch keine Geraete, die das nicht schaffen und es muesste jetzt auch mit b5b0557f13050d89e67baab1d13785982b43f5f3 Wireguard fragmentieren koennen. `PMTUD` funktioniert tatsaechlich, also Unicast bricht quasi nicht, aber Multicast traffic wird es nicht ueberleben. Alternative ist das client netz auf 1430 herunterzuschrauben. 2. Adressvergabe 1. DHCP Jeder Router braucht seine eigene IPv4, kann aber im selben Subnetz wie die anderen arbeiten. DHCP muss dann entweder ein Geraet uebernehmen, oder man muss die DHCP Ranges unter den Routern aufteilen. 2. RA Ja das ist das schoene an IPv6. Einfach auf jedem router die gleiche Subnetzanycastadresse konfigurieren und fertig. Ich untersuch noch, wie ich mit ip6tables die Prioritaet der RAs filtern kann, sodass der naechste Router immer die hoechste Prio hat. Hier gewinnt aber auch in der Regel der Router, der am schnellsten aufloest. @rohammer Also ich glaube du unterschaetzt, wie viel behaemmerte Fehler ich schon gemacht habe um nur 3 Geraete sauber zu konfigurieren. Aktuell muss man `n` verschiedene configs in `/etc/config/network` sauber halten, das auch noch an mehrere Stellen, und natuerlich noch den Mist in `/etc/config/dhcp` nicht vergessen. Dagagen nur einen Block auf ein paar Kisten kopieren ist einfach so viel angenehmer und laesst sich schoener automatisieren (was wirklich wichtig ist, weil man macht das mit dem vxlan ja eigentlich erst, weil man mindestens 3 oder mehr Geraete hat). Darueber hinaus bin ich weiterhin der Meinung, dass wir am besten nur eine `Source of Truth` haben sollten und man moeglichst nichts in den anderen Dateien zu pfuschen hat. Ich wuerde noch gern in der Zukunft die MTU fuer saemtliche Peerings automatisiert anpassen, die DHCP Ranges berechnen (siehe `2.1.` oben), moeglicherweise einige sinnvolle Defaults setzen (z.B. no-checksumming, falls das etwas bringt beispielsweise) und wie in `2.2.` angedeutet etwas schlauere Sachen mit den RAs basteln, um den Traffic besser zu steuern. Ganz weit am Horizont ist noch das vxlan mit babel zu verheiraten, sodass quasi nur noch [BUM Traffic](https://en.wikipedia.org/wiki/Broadcast,_unknown-unicast_and_multicast_traffic) ueber das vxlan muss, der Rest mit Hostrouten direkt zum richtigen Router findet, damit auch mehrer Uplinks sauber genutzt werden koennen, ohne vxlan tunneln zu muessen. Jedenfalls fand ich den Patch so gerade noch handlich. Er tut schon was sinnvolles und man kann erkennen, wo die Reise hin soll. :)

rohammer reviewed 2021-01-21 01:34:49 +01:00

src/packages/fff/fff-vxmesh/Makefile Outdated

						
				@ -0,0 +1,31 @@

				include $(TOPDIR)/rules.mk

				PKG_NAME:=fff-vxmesh

rohammer commented

2021-01-21 01:34:49 +01:00

Hier waere es gut, wenn layer3 noch im Namen waere, damit klar ist, dass es nichts mit dem node-mesh zu tun hat.

jkimmel commented

2021-01-21 05:08:52 +01:00

done.

jkimmel marked this conversation as resolved

rohammer reviewed 2021-01-21 01:36:07 +01:00

src/packages/fff/fff-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +32,4 @@

					while uci -q delete network.@vxlan_peer[-1]; do :; done

					# remove vxmesh0 entry from the client bridge and remove extra whitespaces

					uci -q set network.client.ifname="$(uci -q get network.client.ifname | sed s/vxmesh0// | xargs echo)"

rohammer commented

2021-01-21 01:36:07 +01:00

echo ist default bei xargs.

jkimmel marked this conversation as resolved

rohammer reviewed 2021-01-21 01:47:10 +01:00

src/packages/fff/fff-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +68,4 @@

					}

					# copy main options over

					uci -q set network.vxmesh0=interface

rohammer commented

2021-01-21 01:47:10 +01:00

Das Quoten der Option bei uci set ist nicht ueberall gleich im Skript. Mal mit, mal ohne Apostroph.
Und bei Variablen manchmal mit Anfuehrungszeichen, manchmal ohne.

Das Quoten der Option bei uci set ist nicht ueberall gleich im Skript. Mal mit, mal ohne Apostroph. Und bei Variablen manchmal mit Anfuehrungszeichen, manchmal ohne.

jkimmel commented

2021-01-21 05:09:39 +01:00

Hoffe, hab alles erwischt.

jkimmel marked this conversation as resolved

jkimmel changed title from ~~fff-vxmesh: join multple client nets with vxlan~~ to fff-layer3-vxmesh: join multple client nets with vxlan

2021-01-21 05:06:42 +01:00

jkimmel force-pushed vxmesh from 3e96acf079 to 3cc2da2fed

2021-01-21 05:08:30 +01:00

Compare

ChristianD commented

2021-01-21 13:25:15 +01:00

Danke für die Erklärung, man muss da also schon ein wenig aufpassen, sollte später unbdingt mit in die Doku

Darueber hinaus bin ich weiterhin der Meinung, dass wir am besten nur eine Source of Truth haben sollten und man moeglichst nichts in den anderen Dateien zu pfuschen hat.

Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok.

Danke für die Erklärung, man muss da also schon ein wenig aufpassen, sollte später unbdingt mit in die Doku > Darueber hinaus bin ich weiterhin der Meinung, dass wir am besten nur eine `Source of Truth` haben sollten und man moeglichst nichts in den anderen Dateien zu pfuschen hat. Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok.

jkimmel force-pushed vxmesh from 50bc77988f to 975856c336

2021-01-28 10:09:16 +01:00

Compare

jkimmel commented

2021-01-28 10:09:36 +01:00

rebased

jkimmel force-pushed vxmesh from 975856c336 to 5db5f72f34

2021-01-28 10:22:39 +01:00

Compare

jkimmel commented

2021-01-28 10:23:26 +01:00

PKG_BUILD_DIR entfernt.

`PKG_BUILD_DIR` entfernt.

jkimmel force-pushed vxmesh from 5db5f72f34 to 057e4d538f

2021-02-15 12:58:10 +01:00

Compare

jkimmel commented

2021-02-15 13:03:37 +01:00

rebased auf 20210211-beta

rebased auf [20210211-beta](/freifunk-franken/firmware/releases/tag/20210211-beta)

Mindmaster commented

2021-02-15 13:13:18 +01:00

First-time contributor

Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok.

Dann müsste aber auch die MTU in die gateway config

Und die Peeradressee sollte automatisch ins Babel aufgenommen werden

> Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok. Dann müsste aber auch die MTU in die gateway config Und die Peeradressee sollte automatisch ins Babel aufgenommen werden

ChristianD commented

2021-02-15 19:13:20 +01:00

@Mindmaster

Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok.

Dann müsste aber auch die MTU in die gateway config

Ja

Und die Peeradressee sollte automatisch ins Babel aufgenommen werden

Ja

:)

@Mindmaster >> Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok. > >Dann müsste aber auch die MTU in die gateway config Ja > >Und die Peeradressee sollte automatisch ins Babel aufgenommen werden Ja :)

jkimmel commented

2021-02-16 08:29:11 +01:00

@Mindmaster

Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok.

Dann müsste aber auch die MTU in die gateway config

Siehe 67e4c31c4bf685396ed8fc171793d8d00433014c

Achtung, das ist nur halbgar fuer den Moment. Es fehlt noch der Automatismus die MTU beim Parent Interface bei VLANs anzupassen. Diese muss noch manuell in der /etc/config/network eingetragen werden.

Fuer dieses Feature braeuchte ich noch etwas Hilfe, wie man das am schlausten generisch fuer alle Devices sauber loest.

Wenn wir eine vernuenftige Loesung gefunden haben, gibts natuerlich einen Separaten PR un der Patch fliegt hier wieder raus.

Und die Peeradressee sollte automatisch ins Babel aufgenommen werden

Siehe #87
Wird aber vermutlich komplett umgebaut und auf dauer mindestens die peer_ip6 option enternft. Statt dessen wird man eine Liste von routerIP oder routerIP6 (oder wie wir dann das auch immer nennen wollen) konfigurieren koennen, unter welchen der Router direkt erreichbar sein soll.

@Mindmaster > > Da stimme ich voll und ganz zu, sowas soll über die /etc/config/gateway gemacht werden, andere files sollten keinesfalls angefasst werden, dann ist z.b. der Kram auch Updatefest. Für mich ist der Aufbau so absolut ok. > > Dann müsste aber auch die MTU in die gateway config Siehe 67e4c31c4bf685396ed8fc171793d8d00433014c Achtung, das ist nur halbgar fuer den Moment. Es fehlt noch der Automatismus die MTU beim Parent Interface bei VLANs anzupassen. Diese muss noch manuell in der `/etc/config/network` eingetragen werden. Fuer dieses Feature braeuchte ich noch etwas Hilfe, wie man das am schlausten generisch fuer alle Devices sauber loest. Wenn wir eine vernuenftige Loesung gefunden haben, gibts natuerlich einen Separaten PR un der Patch fliegt hier wieder raus. > Und die Peeradressee sollte automatisch ins Babel aufgenommen werden Siehe #87 Wird aber vermutlich komplett umgebaut und auf dauer mindestens die `peer_ip6` option enternft. Statt dessen wird man eine Liste von `routerIP` oder `routerIP6` (oder wie wir dann das auch immer nennen wollen) konfigurieren koennen, unter welchen der Router direkt erreichbar sein soll.

adschm reviewed 2021-02-16 18:00:00 +01:00

src/packages/fff/fff-babeld/files/etc/layer3.d/40-babel Outdated

						
				@ -62,1 +63,4 @@

						# get mtu

						if mtu=$(uci -q get gateway.$name.mtu); then

							mtu="$mtu"

adschm commented

2021-02-16 18:00:00 +01:00

Das wird doch schon in der ersten zeile gesetzt, also reicht hier doch

mtu=$(uci -q get gateway.$name.mtu) || mtu=1500

Das wird doch schon in der ersten zeile gesetzt, also reicht hier doch `mtu=$(uci -q get gateway.$name.mtu) || mtu=1500`

jkimmel commented

2021-02-17 06:39:36 +01:00

Jo, war kopiert von den Bloecken davor. Ich mach noch einen separaten commit, der die anderen zwei Optionen auch so umbaut.

jkimmel commented

2021-02-17 06:49:26 +01:00

#125

jkimmel marked this conversation as resolved

adschm reviewed 2021-02-16 18:01:58 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +45,4 @@

					# check if a vxmesh config is available, otherwise quit

					if ! uci -q get gateway.@vxmesh[0] > /dev/null; then

						return 0

					fi

adschm commented

2021-02-16 18:01:58 +01:00

Hatte ich jetzt auch als One-liner gemacht, so lange kein output dazu muss:

uci -q get gateway.@vxmesh[0] > /dev/null || return 0

Hatte ich jetzt auch als One-liner gemacht, so lange kein output dazu muss: `uci -q get gateway.@vxmesh[0] > /dev/null || return 0`

jkimmel marked this conversation as resolved

adschm reviewed 2021-02-16 18:02:36 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +51,4 @@

					proto="$(uci -q get gateway.@vxmesh[0].proto)"

					case "$proto" in

						vxlan6)

							peerip="$(uci -q get gateway.@gateway[0].peer_ip6)";;

adschm commented

2021-02-16 18:02:36 +01:00

Die ;; vielleicht in die zeile darunter schieben, wie beim default case.

jkimmel marked this conversation as resolved

adschm reviewed 2021-02-16 18:08:53 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +76,4 @@

					uci -q set network.vxmesh0="interface"

					for option in $fields; do

						if value="$(uci -q get gateway.@vxmesh[0]."$option")"; then

							uci -q set network.vxmesh0."$option"="$value"

adschm commented

2021-02-16 18:08:53 +01:00

Beachte hierbei, dass
uci set network.abc.def=""
dasselbe ist wie
uci del network.abc.def

Ggf. kann man also die condition entfernen:
uci set network.vxmesh0."$option"="$(uci -q get gateway.@vxmesh[0]."$option")"

das -q bei set sollte weg.

Beachte hierbei, dass uci set network.abc.def="" dasselbe ist wie uci del network.abc.def Ggf. kann man also die condition entfernen: `uci set network.vxmesh0."$option"="$(uci -q get gateway.@vxmesh[0]."$option")"` das -q bei set sollte weg.

jkimmel commented

2021-02-17 07:12:38 +01:00

Ah ok. Ich wollte verhindern, dass leere optionen gesetzt werden, wenn das get failed. Aber dann tut der Einzeiler ja das gleiche.

jkimmel marked this conversation as resolved

adschm reviewed 2021-02-16 18:12:42 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +146,4 @@

					# with multiple routers in the network, there shouldnt be an authoritative

					# dhcp server

					uci -q set dhcp.@dnsmasq[0].authoritative="0"

adschm commented

2021-02-16 18:12:42 +01:00

-q weg, nächste zeile auch.

jkimmel commented

2021-02-17 07:16:09 +01:00

Hab die anderen -q auch noch weggeworfen.

Hab die anderen `-q` auch noch weggeworfen.

jkimmel marked this conversation as resolved

rohammer reviewed 2021-02-16 22:29:25 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +84,4 @@

					for peer in $otherpeers; do

						# exclude peerip from the local router, so packets aren't sent to

						# itself

						[ "$peer" = "$peerip" ] && continue

rohammer commented

2021-02-16 22:29:25 +01:00

Das ist hier wohl nicht mehr noetig. Oben grep -v $peerip

jkimmel commented

2021-02-17 07:16:33 +01:00

Danke :)

jkimmel marked this conversation as resolved

rohammer reviewed 2021-02-16 22:35:49 +01:00

src/packages/fff/fff-layer3-vxmesh/files/etc/layer3.d/60-vxmesh Outdated

						
				@ -0,0 +137,4 @@

								set babeld.@filter[-1].if="$ifname"

								set babeld.@filter[-1].addedbyautoconfig="true"

								set babeld.@filter[-1].action="deny"

							EOF

rohammer commented

2021-02-16 22:35:49 +01:00

werden die Filter irgendwo wieder geloescht, wenn sich otherpeers aendern?

jkimmel commented

2021-02-17 06:23:10 +01:00

Jap, das macht https://git.freifunk-franken.de/freifunk-franken/firmware/src/tag/20210211-beta/src/packages/fff/fff-babeld/files/etc/layer3.d/40-babel#L87 bzw. https://git.freifunk-franken.de/freifunk-franken/firmware/src/tag/20210211-beta/src/packages/fff/fff-babeld/files/lib/functions/fff/babel#L103 .
Deswegen set babeld.@filter[-1].addedbyautoconfig="true"

Jap, das macht https://git.freifunk-franken.de/freifunk-franken/firmware/src/tag/20210211-beta/src/packages/fff/fff-babeld/files/etc/layer3.d/40-babel#L87 bzw. https://git.freifunk-franken.de/freifunk-franken/firmware/src/tag/20210211-beta/src/packages/fff/fff-babeld/files/lib/functions/fff/babel#L103 . Deswegen `set babeld.@filter[-1].addedbyautoconfig="true"`

jkimmel commented

2021-02-17 06:49:41 +01:00

#125

jkimmel marked this conversation as resolved

jkimmel force-pushed vxmesh from 67e4c31c4b to faa182eb51

2021-02-17 06:47:58 +01:00

Compare

jkimmel force-pushed vxmesh from faa182eb51 to d50feeab07

2021-02-17 07:16:50 +01:00

Compare

jkimmel added a new dependency 2021-02-17 07:17:05 +01:00

#125 fff-babeld: add MTU option to babelpeers

jkimmel added a new dependency 2021-02-17 07:56:20 +01:00

#124 OpenWrt: bump to 19.07.7

jkimmel removed a dependency 2021-02-17 07:56:26 +01:00

#124 OpenWrt: bump to 19.07.7

jkimmel added a new dependency 2021-02-17 07:56:48 +01:00

#87 fff-babeld: redistribute all peer_ip and peer_ip6 addresses

jkimmel added a new dependency 2021-08-11 16:59:33 +02:00

#136 fff-layer3-config: Add routerip option

jkimmel removed a dependency 2021-08-11 16:59:40 +02:00

#136 fff-layer3-config: Add routerip option

jkimmel added a new dependency 2021-08-11 17:00:49 +02:00

#136 fff-layer3-config: Add routerip option

jkimmel removed a dependency 2021-08-11 17:00:56 +02:00

#87 fff-babeld: redistribute all peer_ip and peer_ip6 addresses

jkimmel commented

2024-03-12 12:29:59 +01:00

Es sieht so aus als würde bird endlich EVPN Support mit VXLAN bekommen. Das wäre die eigentliche Lösung über viele Router hinweg ein L2 zu spannen und würde das Roaming Problem damit auch für die Layer 3 Firmware lösen.
So oder so ist dieser PR schon eigentlich länger hinfällig, weil sich zu viel in der Zwischenzeit geändert hat.
Sobald Bird wirklich soliden EVPN Support mitbringt, können wir das noch einmal anpacken.

Es sieht so aus als würde bird endlich [EVPN Support mit VXLAN](https://gitlab.nic.cz/labs/bird-tools/-/tree/master/netlab/cf-evpn-bgp) bekommen. Das wäre die eigentliche Lösung über viele Router hinweg ein L2 zu spannen und würde das Roaming Problem damit auch für die Layer 3 Firmware lösen. So oder so ist dieser PR schon eigentlich länger hinfällig, weil sich zu viel in der Zwischenzeit geändert hat. Sobald Bird wirklich soliden EVPN Support mitbringt, können wir das noch einmal anpacken.

jkimmel removed a dependency 2024-03-12 12:31:40 +01:00

#125 fff-babeld: add MTU option to babelpeers

jkimmel closed this pull request

2024-03-12 12:31:44 +01:00