DS als Switch nutzen bei DSM 6.0 - Bridge zwischen eth0 und eth1

[Hagen2000]

Hallo zusammen,

ich habe mit einer älteren DSM-Version schon erfolgreich die beiden LAN-Ports meiner DS214+ "gebrückt". Mit DSM 6.0 will mir das nicht gelingen. Mit dem Script wie z.B. unter http://www.synology-forum.de/showthread.html?62709-DS-als-Switch-nutzen beschrieben verliert die DS die Netzwerkverbindung. Ich kann die Netzwerkverbindung aufrecht erhalten, wenn ich für eth0 die IP-Adresse nicht auf 0.0.0.0 setze, aber die DS selbst hat dann offenbar Probleme, das Default-Gateway zu erreichen. So schlägt z.B. die Prüfung auf DSM-Updates fehl.

Hat das schon jemand unter DSM 6.0 zum Laufen bekommen?

Im QNAP-Forum habe ich ein ähnliches Script gefunden (siehe http://forum.qnap.com/viewtopic.php?t=45759), hier werden allerdings noch bestimmte Dienste nach dem Einrichten der Bridge neu gestartet. Ist so etwas bei der Synology DS auch notwendig?

Vielen Dank für jeden Tipp!

 

[jahlives]

Beim Einrichten einer Bridge verliert man immer die Verbindung. Das liegt in der Natur der Bridge. Das passiert in dem Moment wo man das Interface, wo die aktuelle Verbindung drüber läuft, an die Bridge bindet. Dann zeigen z.B. alle Routen ins Leere. Eine Bridge lässt sich via ssh oder telnet schlecht einrichten. Unter /etc/sysconfig/network-scripts/ befinden sich die ifcfg Configfiles des Netzwerkes. Grundsätzlich dürfte man dort auch Bridges konfigurieren können. Der Aufbau der Files orientiert sich an Redhat. Für eine Bridge habe ich diesen Weg nie probiert bei einer DS, aber für vlan Konfigs geht es. Müsste also auch für Bridges gehen. IP Adresse kommt auf das Bridge Interface. Die beiden Members mit BOOTPROTO="none" und BRIDGE="deinBridgeInterface" konfigurieren. Die Bridge selber als TYPE="Bridge" https://access.redhat.com/documenta...networkscripts-interfaces_network-bridge.html

Dieser Weg hat einen Hacken: ein Fehler in der Konfig und das Teil hat kein Netzwerk mehr oder bootet nimmer. Stell unbedingt sicher dass die nötigen Module geladen werden (z.B. bridge und stp). Vielleicht erstmal nur ein Interface bridgen und auf dem zweiten noch eine Notfall IP Konfig drauf haben

 

[Hagen2000]

Vielen Dank schonmal für die fundierten Hinweise.

Mit dem Verlust der Netzwerkverbindung habe ich mich etwas unklar ausgedrückt. Dass ich die laufende Verbindung verliere, ist eigentlich klar. Aber ich kann danach eben auch keine neue Verbindung unter der IP-Adresse der Bridge aufbauen. Die DS ist nach Laufenlassen des Scripts praktisch tot und muss neu gebootet werden. Wie gesagt, vor zwei Jahren hatte das mit dem Script gut funktioniert.

Wenn ich das richtig verstehe, dann setze ich mit den ifcfg-Configfiles deutlich früher im Systemstart an als mit einem Script im /usr/local/etc/rc.d/create-bridge.sh-Verzeichnis?

Wo müsste ich denn dann die Kernel-Module laden, die müssen ja vermutlich vor der Verarbeitung der ifcfg-Scripts laufen?

Und wie komme ich im "Desaster"-Fall wieder auf die DS - funktioniert das Verfahren mit der Reset-Taste / 4 Sekunden drücken?

 

[jahlives]

Aber ich kann danach eben auch keine neue Verbindung unter der IP-Adresse der Bridge aufbauen.

das klingt für mich danach als ob die Bridge keine Ahnung hat welches Netz an ihren Interfaces anliegt. Wahrscheinlich weil keine Netzwerkrouten gesetzt wurden.
Bei meiner Test-DS (DSM6) sind die nötigen Module ohne weiteres Zutun bereits geladen. Prüf das mit

lsmod | grep bridge

Allerdings wird die Bridge bei meiner Testmaschine nicht automatisch hochgefahren. Ich muss manuell mit brctl und ifconfig nachhelfen. Da bin ich aber gerade dran ein bissl zu testen

 

[Hagen2000]

Also bei meiner DS ist das Bridge-Modul standardmäßig nicht geladen. Aber angeblich unterstützt DSM ja einen WLAN-Adapter und baut dann für diesen eine Bridge auf (ich glaube nur für eth0 und das WLAN). Möglicherweise hast Du einen WLAN-Adapter angeschlossen und daher ist das Bridge-Modul bereits geladen. Man könnte dann auch mit

[sudo] brctl show

sehen, ob bereits eine Bridge existiert.

Bei mir werden das Bridge-Modul und das STP-Modul durch mein Script in /usr/local/etc/rc.d geladen, das schaut momentan so aus:

#!/bin/sh
#
#Put this file to /usr/local/etc/rc.d/create-bridge.sh
#
################################################## ##
#
# creates a bridge between eth0 and eth1
# and sets the ip address to 192.168.178.18
# sets defaultGateway and resets the interface ip
# NOTE: Must be executed as root!
#
################################################## ##
case $1 in
start)
        # To give time for remote login in case of trouble...
	sleep 60
	# Load the required kernel modules
	insmod /lib/modules/stp.ko
	insmod /lib/modules/bridge.ko
	# Create bridge
	brctl addbr br0
	brctl stp br0 off
	# Add the ethernet interfaces
	#brctl addif br0 eth0
	#brctl addif br0 eth1
	#ifconfig eth0 0.0.0.0 promisc up
	#ifconfig eth1 0.0.0.0 promisc up
	#ifconfig br0 192.168.178.18 netmask 255.255.255.0 up
	#route add default gw 192.168.178.1 dev br0
	;;
stop)
	;;
*)
	echo usage: start bridge between eth0 and eth1
	;;
esac

Wie Du siehst, sind die entscheidenden Schritte noch auskommentiert, da - wenn interaktiv eingegeben - sich die DS verabschiedet.

Das mit der fehlenden Route klingt plausibel.
Gebe ich die obigen Schritte händisch ein und verwende für eth0 statt 0.0.0.0 die IP-Adresse 192.168.178.18, bricht die ssh-Sitzung nicht ab (192.168.178.18 ist die normale IP-Adresse meiner DS). Für die Bridge habe ich dann eine andere freie IP-Adresse verwendet. Dann kann ich über die Bridge-IP sogar eine eigene ssh-Sitzung starten. Das schaut also erstmal ganz gut aus, aber ein

route

erzeugt für einige Sekunden einen Hänger, was auf ein fehlendes DNS deutet bzw. eine fehlende Default-Route (route -n hängt nicht). Ein ping zu Google schlägt ebenfalls fehl.

Das Laden von Modulen scheint unter DSM anders zu funktionieren als bei Redhat, das Verzeichnis /etc/sysconfig/modules existiert schonmal nicht (siehe https://access.redhat.com/documenta...ment_Guide/sec-Persistent_Module_Loading.html).

 

[jahlives]

hm dann lädt wohl das docker Packet bei mir die Module. Händisch bzw via Script geht dies sicher auch

modprobe /usr/lib/modules/stp.ko
modprobe /usr/lib/modules/bridge.ko

bei einer Bridge sollte (darf) nur ein Interface eine IP Adresse haben v.a. wenn man mehrere IPs aus dem selben Subnetz nimmt. Alles andere wird früher oder später massive und schwer zu diagnostizierende Probleme geben. Normalerweise gibt man der Bridge selber die IP. Ich wette ein Bier, dass es bei interaktiver Eingabe knallt sobald du den brctl addif machst. Das ist so, sobald man das Interface wo die aktive Verbindung drüber läuft der Bridge hinzufügt.

Leider geht das Laden der Bridge via Konfigfiles bei der DS ned (oder ich habe es zumindest noch nicht geschafft)

 

[jahlives]

hier mein aktuell funzendes Script. Allerdings mit einer Bridge für zwei ungenutzte Interfaces (also z.B. keine default Route drauf).

#/bin/sh


/sbin/modprobe /usr/lib/modules/stp.ko  >/tmp/bridge.log 2>&1
/sbin/modprobe /usr/lib/modules/bridge.ko  >>/tmp/bridge.log 2>&1
sleep 1
/bin/brctl addbr br0 >>/tmp/bridge.log 2>&1
/bin/brctl stp br0 off >>/tmp/bridge.log 2>&1
/bin/brctl setfd br0 0 >>/tmp/bridge.log 2>&1
/sbin/ifconfig eth1 up >>/tmp/bridge.log 2>&1
/sbin/ifconfig eth2 up >>/tmp/bridge.log 2>&1
/bin/brctl addif br0 eth1 >>/tmp/bridge.log 2>&1
/bin/brctl addif br0 eth2 >>/tmp/bridge.log 2>&1
/sbin/ip addr add 192.168.2.1/24 dev br0 >>/tmp/bridge.log 2>&1
/sbin/ifconfig br0 up >>/tmp/bridge.log 2>&1
sleep 2
/sbin/ip route add 192.168.2.0/24 dev br0  >>/tmp/bridge.log 2>&1

 

[Hagen2000]

Ok - das entspricht ja im Wesentlichen meiner Variante.

modprobe stützt sich eigentlich auf eine Datei mit Abhängigkeiten ab, die es aber auf der DS offenbar nicht gibt (modules.dep.bin, siehe auch hier: http://askubuntu.com/questions/20070/whats-the-difference-between-insmod-and-modprobe). Deshalb würde ich hier das Low-Level-Utility insmod vorziehen.

Hast Du noch einen Tipp, wie ich die Kernel-Module automatisch laden lassen kann, so dass sie vor Verarbeitung der ifcfg-Configfiles schon vorhanden sind?

 

[jahlives]

insmod erzeugt aber eine Fehlerausgabe wenn das Modul schon geladen ist. Das ist bei mir wegen dem Dockerpaket bereits der Fall. Den insmod oder modprobe kannst du grundsätzlich in einem der Startscripte machen. ifcfg kann man scheinbar für eine Bridge nicht nutzen. Von dem her ist es egal wenn die Module ganz am Ende geladen werden

 

[Hagen2000]

Danke, das wusste ich nicht.

Schau mal das Script /etc/rc.network an. Es schaut eher so aus, als ob eine Bridge schon nativ vom DSM unterstützt wird, wobei noch ein synowifid mit im Spiel ist (siehe Zeile 697 im zuvor genannten Script). Auch interessant sind die Scripts im Ordner /usr/syno/etc/wifi! Ich vermute, dass der synowifid dann auch für das Laden der Module bridge.ko und stp.ko zuständig ist. Interessant ist auch, dass bei der DS213air eine Bridge zwischen eth0, eth1, wlan0 und wlan1 aufgebaut wird, obwohl die DS213air nur eine LAN-Schnittstelle hat. wlan0 und wlan1 dürften dann für das normale und das Gast-WLAN zuständig sein - aber das sind erstmal nur Vermutungen.

Die Lösung wird also sein, passende ifcfg-Dateien zu erstellen, so dass das rc.network-Script damit klarkommt! Vermutlich muss man das Script auch noch patchen um die zwei Module für die Bridge und Spanning Tree Protocol nachzuladen...

 

[Thasom]

Hallo Hagen2000,

ich habe den gleichen Anwendungsfall und eine Skriptlösung aus diesem Forum hatte bis zum Upgrade auf DSM6.0 prima funktioniert.
Hast du eine Lösung für DSM6.0 hinbekommen?

 

[Hagen2000]

Hallo Thasom,

leider nicht. Ich habe das dann nicht weiter verfolgt sondern eine zweite Netzwerkverbindung in den Raum gezogen, in dem die DS steht. Glücklicherweise hatte ich noch zwei Adernpaare in einer Cat 5-Leitung frei und die habe ich zu einem 100Mbit-Anschluss umfunktioniert - was für den Anwendungsfall ausreichend war bzw. ist.
Das hilft Dir natürlich nicht wirklich weiter.

Es soll ja gehen, die beiden Netzwerkanschlüssen per Routing miteinander zu verbinden. Allerdings hat man dann eben zwei Subnetze und das passt natürlich dann auch nicht für jeden Anwendungsfall.

Eine Lösung würde mich auch noch interessieren.