+-Serie DS412+ als Netzwerkbrücke
- Ersteller thowe
- Erstellt am
Alle Geräte der +-Serie. Geräte für kleinere und mittlere Unternehmen.
- Status
Wir erledigt und ich teste auch gerade schon fleissig ;-)
Leider passt es nicht, wie gedacht.
Ich bin per eth0 auf der DS. Auf dieser habe ich zusätzlich das WLAN verbunden. Ich kann über beide IPs auf die DS.
Nun habe ich versucht wlan0 zu br0 hinzuzufügen:
ssh auf eth0 und dann:
brctl addbr br0
brctl stp br0 off
brctl addif br0 wlan0
brctl show ergibt:
bridge name bridge id STP enabled interfaces
br0 8000.30144a7a23ab no wlan0
lbr0 8000.30144a7a23ab no
Sieht also alles ok aus, denke ich.
Jetzt:
ifconfig wlan0 0.0.0.0 promisc up
ifconfig br0 192.168.10.250 netmask 255.255.255.0 up
route add default gw 192.168.10.1 dev br0
Es gibt keine Fehlermeldungen. Ich kann aber nicht über br0 (.250) auf die DS. Ein Ping ergibt:
PING 192.168.10.250 (192.168.10.250): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Wer oder was ist eigentlich lbr0?? Das ist neu (ich hatte die DS resetted, bevor ich neu versucht habe)
Leider passt es nicht, wie gedacht.
Ich bin per eth0 auf der DS. Auf dieser habe ich zusätzlich das WLAN verbunden. Ich kann über beide IPs auf die DS.
Nun habe ich versucht wlan0 zu br0 hinzuzufügen:
ssh auf eth0 und dann:
brctl addbr br0
brctl stp br0 off
brctl addif br0 wlan0
brctl show ergibt:
bridge name bridge id STP enabled interfaces
br0 8000.30144a7a23ab no wlan0
lbr0 8000.30144a7a23ab no
Sieht also alles ok aus, denke ich.
Jetzt:
ifconfig wlan0 0.0.0.0 promisc up
ifconfig br0 192.168.10.250 netmask 255.255.255.0 up
route add default gw 192.168.10.1 dev br0
Es gibt keine Fehlermeldungen. Ich kann aber nicht über br0 (.250) auf die DS. Ein Ping ergibt:
PING 192.168.10.250 (192.168.10.250): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Wer oder was ist eigentlich lbr0?? Das ist neu (ich hatte die DS resetted, bevor ich neu versucht habe)
Zuletzt bearbeitet:
Ja klar, eigentlich schon.
Ich habe jetzt alles nochmal zurückgesetzt (auch die DS auf Grundeinstellungen). Folgendes Setup:
Router (Fritzbox, mit DHCP): 192.168.10.1
DS (eth0): 192.168.10.40 (per DHCP)
DS (wlan0): 192.168.10.39 (per DHCP)
Mein Laptop: 192.168.10.22
Ich logge mich per SSH über etho auf die DS und gebe ein:
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
brctl addbr br0
brctl stp br0 off
ifconfig br0 192.168.10.254/24
ifconfig br0 up
brctl show ergibt:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no
Dann packe ich wlan0 zu br0 (und pinge direkt danach dessen br0):
brctl addif br0 wlan0
ifconfig wlan0 0.0.0.0 promisc up
Der Ping funktioniert zuerst NICHT:
PING 192.168.10.254 (192.168.10.254): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
Nach einigen Sekunden funktioniert es dann komischer Weise:
PING 192.168.10.254 (192.168.10.254): 56 data bytes
64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=9.174 ms
Jetz logge ich mich per SSH über br0 (.254) ein. Funktioniert auch.
Nun passiert etwas seltsames! Ohne, dass ich irgendetwas machen würde, bricht nach ca 5 Minuten die Verbindung wieder zusammen. Ich habe lediglich regelmäßig "ll" eingegeben, um zu sehen, ob die Verbindung stabil bleibt.
Zwei Fragen:
1) Was ist da los und was kann ich machen?
2) Wäre die VErbindung stabil, würde ich dann zuerst versuchen die Route zu ändern und dann eth0 ebenfalls zu br0 dazu z packen oder umgekehrt? Bzw: welche Befehle fehlen noch, nachdem ich mich über br0 per SSh eingeloggt habe?
Danke!
ps. gerade gesehen: komischerweise komme ich nun per SSH wieder auf 192.168.10.40 (also eth0). Das kapiere ich komplett nicht.
Ich habe jetzt alles nochmal zurückgesetzt (auch die DS auf Grundeinstellungen). Folgendes Setup:
Router (Fritzbox, mit DHCP): 192.168.10.1
DS (eth0): 192.168.10.40 (per DHCP)
DS (wlan0): 192.168.10.39 (per DHCP)
Mein Laptop: 192.168.10.22
Ich logge mich per SSH über etho auf die DS und gebe ein:
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
brctl addbr br0
brctl stp br0 off
ifconfig br0 192.168.10.254/24
ifconfig br0 up
brctl show ergibt:
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no
Dann packe ich wlan0 zu br0 (und pinge direkt danach dessen br0):
brctl addif br0 wlan0
ifconfig wlan0 0.0.0.0 promisc up
Der Ping funktioniert zuerst NICHT:
PING 192.168.10.254 (192.168.10.254): 56 data bytes
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: Host is down
Request timeout for icmp_seq 1
Nach einigen Sekunden funktioniert es dann komischer Weise:
PING 192.168.10.254 (192.168.10.254): 56 data bytes
64 bytes from 192.168.10.254: icmp_seq=0 ttl=64 time=9.174 ms
Jetz logge ich mich per SSH über br0 (.254) ein. Funktioniert auch.
Nun passiert etwas seltsames! Ohne, dass ich irgendetwas machen würde, bricht nach ca 5 Minuten die Verbindung wieder zusammen. Ich habe lediglich regelmäßig "ll" eingegeben, um zu sehen, ob die Verbindung stabil bleibt.
Zwei Fragen:
1) Was ist da los und was kann ich machen?
2) Wäre die VErbindung stabil, würde ich dann zuerst versuchen die Route zu ändern und dann eth0 ebenfalls zu br0 dazu z packen oder umgekehrt? Bzw: welche Befehle fehlen noch, nachdem ich mich über br0 per SSh eingeloggt habe?
Danke!
ps. gerade gesehen: komischerweise komme ich nun per SSH wieder auf 192.168.10.40 (also eth0). Das kapiere ich komplett nicht.
Zuletzt bearbeitet:
jahlives
Benutzer
- Mitglied seit
- 19. Aug 2008
- Beiträge
- 18.275
- Punkte für Reaktionen
- 4
- Punkte
- 0
Das mit der instabilen Verbindung klingt sehr nach einer Routinggeschichte. Ich vermute mehr als ein Interface haben eine Subnetzroute für dein LAN z.B. wlan0 und br0
Drum mein Vorschlag mit der Direktverbindung zu eth0. Dann hast du unterschiedliche Subnetze. Am Anfang hast du auf zwei Interfaces dasselbe Subnetz eth0 und wlan0. Das ist schon ohne Bridge nicht eindeutig für das Routing des Kernels. Dann kommt noch die Bridge, die auch das selbe Subnetz haben soll.
Es ist wirklich wichtig, dass die Verbindung über welche die Bridge eingerichtet wird ein eigenes Subnetz nutzt, um nicht durch die für die Bridge nötigen Routingänderungen abgeschossen zu werden
Drum mein Vorschlag mit der Direktverbindung zu eth0. Dann hast du unterschiedliche Subnetze. Am Anfang hast du auf zwei Interfaces dasselbe Subnetz eth0 und wlan0. Das ist schon ohne Bridge nicht eindeutig für das Routing des Kernels. Dann kommt noch die Bridge, die auch das selbe Subnetz haben soll.
Es ist wirklich wichtig, dass die Verbindung über welche die Bridge eingerichtet wird ein eigenes Subnetz nutzt, um nicht durch die für die Bridge nötigen Routingänderungen abgeschossen zu werden
Anna_Konda
Benutzer
- Mitglied seit
- 01. Sep 2010
- Beiträge
- 129
- Punkte für Reaktionen
- 0
- Punkte
- 22
Hallo,
hat jemand es geschafft, die Syno als Wifi-Bridge einzurichten?
Ich schaffe es noch immer nicht. Ich habe zwar rausgefunden, dass ich wohl NAT aktivieren muss, was unter DSM 6.X nicht einfach war, aber ich habe https://galaxysd.github.io/linux/20170804/2017-08-04-iptables-on-Synology-DSM-6 eine Lösung gefunden.
Trotz allem klappt es nicht. So sieht mein Setup im Moment aus:
------------------
-----
Weiß jemand, woran ich hänge?
Viele Grüße, Anna
hat jemand es geschafft, die Syno als Wifi-Bridge einzurichten?
Ich schaffe es noch immer nicht. Ich habe zwar rausgefunden, dass ich wohl NAT aktivieren muss, was unter DSM 6.X nicht einfach war, aber ich habe https://galaxysd.github.io/linux/20170804/2017-08-04-iptables-on-Synology-DSM-6 eine Lösung gefunden.
Trotz allem klappt es nicht. So sieht mein Setup im Moment aus:
Rich (BBCode):
#!/bin/sh
################################################## ##
#
# creates a bridge between eth0 and wlan0
# and set the ip address to 192.168.180.222
# sets defaultGateway and resets the interface ip
#
################################################## ##
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
brctl addbr br0
brctl stp br0 off
#iface eth0 inet manual
#iface wlan0 inet manual
ifconfig br0 192.168.180.222 netmask 255.255.255.0 up
#ifconfig br0 dynamic up
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig eth0 0.0.0.0 promisc up
ifconfig wlan0 0.0.0.0 promisc up
route add default gw 192.168.180.1 dev br0
iptables -t nat -A POSTROUTING -s 192.168.180.0/24 -j MASQUERADE
exit
Rich (BBCode):
root@Syno:~# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.803f5d219e98 no eth0
wlan0-----
Rich (BBCode):
br0 Link encap:Ethernet HWaddr 80:3F:5D:21:9E:98
inet addr:192.168.180.222 Bcast:192.168.180.255 Mask:255.255.255.0
inet6 addr: fe80::4099:3fff:fec5:c39c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST DYNAMIC MTU:1500 Metric:1
RX packets:2802 errors:0 dropped:0 overruns:0 frame:0
TX packets:340 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:378029 (369.1 KiB) TX bytes:67964 (66.3 KiB)
eth0 Link encap:Ethernet HWaddr A0:B3:CC:E9:5C:0F
inet addr:169.254.192.23 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: fe80::a2b3:ccff:fee9:5c0f/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2034 errors:0 dropped:0 overruns:0 frame:0
TX packets:424 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:303952 (296.8 KiB) TX bytes:102240 (99.8 KiB)
eth1 Link encap:Ethernet HWaddr A0:B3:CC:E9:5C:0F
inet addr:192.168.180.109 Bcast:192.168.180.255 Mask:255.255.255.0
inet6 addr: 2001:16b8:24e5:3b00:a2b3:ccff:fee9:5c0f/64 Scope:Global
inet6 addr: fd9f:7989:a27d::7d1/64 Scope:Global
inet6 addr: fd9f:7989:a27d:0:a2b3:ccff:fee9:5c0f/64 Scope:Global
inet6 addr: fe80::a2b3:ccff:fee9:5c0f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7646651 errors:0 dropped:0 overruns:0 frame:0
TX packets:1222798 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8618128324 (8.0 GiB) TX bytes:126255037 (120.4 MiB)
Interrupt:18
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:10364 errors:0 dropped:0 overruns:0 frame:0
TX packets:10364 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1690129 (1.6 MiB) TX bytes:1690129 (1.6 MiB)
wlan0 Link encap:Ethernet HWaddr 80:3F:5D:21:9E:98
inet addr:169.254.205.99 Bcast:169.254.255.255 Mask:255.255.0.0
inet6 addr: 2001:16b8:24e5:3b00:823f:5dff:fe21:9e98/64 Scope:Global
inet6 addr: fd9f:7989:a27d:0:823f:5dff:fe21:9e98/64 Scope:Global
inet6 addr: fe80::823f:5dff:fe21:9e98/64 Scope:Link
inet6 addr: fd9f:7989:a27d::41a/64 Scope:Global
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4 errors:0 dropped:1322 overruns:0 frame:0
TX packets:0 errors:0 dropped:25 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:329577666 (314.3 MiB) TX bytes:8195088 (7.8 MiB)Weiß jemand, woran ich hänge?
Viele Grüße, Anna
Keine Ahnung ob das anderen hilft, aber hier mal mein "Ergebnis" bei der DS1618+:
Ich habe alles wie folgt verbunden:
- NAS LAN1 (DHCP) mit Fritz!Box
- NAS LAN2 (DHCP) mit Fritz!Box
- NAS LAN5 (DHCP, 10 Gbit) mit PC LAN10G (10 Gbit)
- PC LAN10G (DHCP, 10 Gbit) mit NAS LAN5 (DHCP, 10 Gbit)
- PC LAN1G (DHCP, 1 Gbit) mit Fritz!Box (die Verbindung verschwindet später wieder)
Die Brücke benötige ich, da ich nur eine Netzwerkdose beim PC habe und ich keinen 10 Gbit Switch kaufen möchte. Es muss also im NAS eine Brücke zwischen der 10 Gbit Buchse (LAN5) und einer der 1 GBit Buchsen (z.B. LAN2) hergestellt werden, damit mein PC weiterhin per DHCP eine IP erhält und ich darüber ins Internet komme. Die Verbindung LAN1G mit der Fritz!Box ist also nur während der Einrichtung der Brücke existent.
Ich habe erst herumprobiert und prompt die falsche IP für die Brücke hinterlegt. Deshalb musste ich diese erst noch mal löschen:
Dann habe ich die Brücke neu erstellt und ihr die IP 192.168.178.6 gegeben:
Dann habe ich eth1 (= LAN Buchse 2) und eth4 (= LAN Buchse 5 von PCIe 10 Gbit Karte) der Brücke hinzugefügt:
Und das gesetzt (keine Ahnung was das macht ^^):
Zuletzt noch das Gateway (IP der Fritz!Box) gesetzt:
Im DSM sind dadurch die LAN Buchsen 2 und 5 verschwunden:
Nun konnte ich das NAS über .88 (per DHCP zugewiesen) und .6 (IP der Brücke) erreichen. Allerdings war weder über .88, noch über .6 eine Geschwindigkeit von über 113 MB/s möglich. Also ich habe ich die Brücke noch mal neu erstellt und diesmal das promisc up dem eth1 gegeben:
Und schon konnte ich auf das NAS über .6 mit 10 Gbit zugreifen
Allerdings ist immer noch etwas komisch:
Wenn ich den Stecker aus LAN1 ziehe, dann kann ich das NAS nicht über .6 erreichen?! (Auch nicht über .88, aber das ist ja logisch) Dabei ist es egal ob ich es über LAN1G oder LAN10G (!?) versuche. Und das, obwohl ich auf LAN10G nach wie vor eine IP zugewiesen bekomme. Dh der mit LAN5 verbundene PC holt sich über LAN2 - also über eine funktionierende Brücke - die IP von der Fritz!Box, aber das NAS selbst kann er nicht erreichen. Dabei hätte ich jetzt erwartet, dass LAN1 überflüssig geworden ist (also nur als Fallback relevant wäre).
Ich habe alles wie folgt verbunden:
- NAS LAN1 (DHCP) mit Fritz!Box
- NAS LAN2 (DHCP) mit Fritz!Box
- NAS LAN5 (DHCP, 10 Gbit) mit PC LAN10G (10 Gbit)
- PC LAN10G (DHCP, 10 Gbit) mit NAS LAN5 (DHCP, 10 Gbit)
- PC LAN1G (DHCP, 1 Gbit) mit Fritz!Box (die Verbindung verschwindet später wieder)
Die Brücke benötige ich, da ich nur eine Netzwerkdose beim PC habe und ich keinen 10 Gbit Switch kaufen möchte. Es muss also im NAS eine Brücke zwischen der 10 Gbit Buchse (LAN5) und einer der 1 GBit Buchsen (z.B. LAN2) hergestellt werden, damit mein PC weiterhin per DHCP eine IP erhält und ich darüber ins Internet komme. Die Verbindung LAN1G mit der Fritz!Box ist also nur während der Einrichtung der Brücke existent.
Ich habe erst herumprobiert und prompt die falsche IP für die Brücke hinterlegt. Deshalb musste ich diese erst noch mal löschen:
Rich (BBCode):
ifconfig br0 down
brctl delbr br0Dann habe ich die Brücke neu erstellt und ihr die IP 192.168.178.6 gegeben:
Rich (BBCode):
brctl addbr br0
brctl stp br0 off
ifconfig br0 192.168.178.6 netmask 255.255.255.0 upDann habe ich eth1 (= LAN Buchse 2) und eth4 (= LAN Buchse 5 von PCIe 10 Gbit Karte) der Brücke hinzugefügt:
Rich (BBCode):
brctl addif br0 eth1
brctl addif br0 eth4Und das gesetzt (keine Ahnung was das macht ^^):
Rich (BBCode):
ifconfig eth4 192.168.178.6 promisc upZuletzt noch das Gateway (IP der Fritz!Box) gesetzt:
Rich (BBCode):
route add default gw 192.168.178.1 dev br0Im DSM sind dadurch die LAN Buchsen 2 und 5 verschwunden:
Nun konnte ich das NAS über .88 (per DHCP zugewiesen) und .6 (IP der Brücke) erreichen. Allerdings war weder über .88, noch über .6 eine Geschwindigkeit von über 113 MB/s möglich. Also ich habe ich die Brücke noch mal neu erstellt und diesmal das promisc up dem eth1 gegeben:
Rich (BBCode):
ifconfig eth1 192.168.178.6 promisc upUnd schon konnte ich auf das NAS über .6 mit 10 Gbit zugreifen
Allerdings ist immer noch etwas komisch:
Wenn ich den Stecker aus LAN1 ziehe, dann kann ich das NAS nicht über .6 erreichen?! (Auch nicht über .88, aber das ist ja logisch) Dabei ist es egal ob ich es über LAN1G oder LAN10G (!?) versuche. Und das, obwohl ich auf LAN10G nach wie vor eine IP zugewiesen bekomme. Dh der mit LAN5 verbundene PC holt sich über LAN2 - also über eine funktionierende Brücke - die IP von der Fritz!Box, aber das NAS selbst kann er nicht erreichen. Dabei hätte ich jetzt erwartet, dass LAN1 überflüssig geworden ist (also nur als Fallback relevant wäre).
Zuletzt bearbeitet:
Ich denke ich konnte das Problem eingrenzen. Heute hatte ich nämlich keine 10 Gbit Verbindung mehr (es steht zwar immer 10 Gbit da, aber netto gehen trotzdem nur 1 Gbit durch) und habe mir daher noch mal per ifconfig alle Werte pro Netzwerk-Schnittstelle ausgeben lassen. Dabei ist mir aufgefallen, dass vereinzelte Ports noch IPv6 Adressen hatten und ich habe auch im PC IPv6 aktiviert. Daher bin ich mal hingegangen und habe erst mal die Brücke wieder gelöscht. Dann habe ich über DSM bei allen Ports IPv6 deaktiviert. Und dann habe ich die Brücke wieder erstellt.
Meine Brücke sieht nun so aus:
Und die Werte aller Netzwerk-Schnittstellen so:
Wie man sieht hat die Brücke immer noch eine IPv6. Obwohl ich diese gezielt wie folgt gelöscht habe, erscheint sie immer wieder neu:
Vermutlich brauche ich für die vollständige Deaktivierung von IPv6 für diese Schnittstelle einen anderen Befehl. Da ich aber wie gesagt beim 10 Gbit Adapter des PCs IPv6 deaktiviert habe, wird sie eh nicht mehr verwendet:
Jedenfalls kann ich nun auch den eth0 (LAN1) Stecker problemlos ziehen. Wer ebenfalls Probleme hat, sollte in jedem Fall erstmal IPv6 deaktivieren und dann weiter testen.
Wie man sehen kann, habe ich diesmal beide Schnittstellen auf Promisc gesetzt:
Die Erklärung zu dieser Option:
https://linuxwiki.de/EthernetBridge
Ich nehme mal an, damit sind Multicast Pakete gemeint?! Jedenfalls habe ich sie für beide Ports aktiviert. Einen Nachteil sehe ich dabei nicht. Soweit ich das verstehe, ist diese Einstellung aber auch gar nicht notwendig.
Zuletzt habe ich auch noch komische Dinge in meiner Routing-Tabelle festgestellt. Ich hatte da zB die Destination 192.168.2.0 für eth4 gesetzt (vermutlich durch meine Spielereien). Jetzt sieht es dagegen so aus:
Korrigiert hatte ich das, in dem ich den fehlerhaften Eintrag entfernt habe wie folgt:
Und wieder hinzugefügt habe ich es, in dem ich die IP des eth4 erneut gesetzt habe:
Und schlussendlich konnte ich dann auch das Gateway dann setzen:
Vorher führte das nämlich zum Fehler "SIOCADDRT: Network is unreachable".
Ich werde das jetzt noch ein paar Tage beobachten und dann schaue ich mal wie ich das in einem Skript umgesetzt bekomme. Das Problem ist nämlich, dass man vorher nicht wissen kann welche Werte aktuell gesetzt sind. Besonders wenn man ein paar mal herumspielt kann einiges falsch eingestellt sein und schon bringt auch das Skript keine Besserung. Sowie ich das aber verstanden habe setzt sich die Synology bei jedem Neustart in Sachen Netzwerk-Schnittstellen zurück (wenn keine Autostart-Skript konfiguriert wurde). Mal sehen was dann alles für Werte existieren. Darauf kann man das Skript dann ja aufbauen lassen. Vielleicht bekomme ich das dann mit IPv6 auch gelöst. Ich brauche es nicht, aber warum nicht auch dieses Problem lösen. Vor allem hätte ich ja gerne mal gewusst warum die Ports eigentlich IPs bekommen. In den ganzen Anleitungen im Netz zum Thema Bridging entfernen alle die IPs mit diesem Befehl:
Das erscheint mir eigentlich logisch zu sein, da man ja nur noch die Bridge über die IP erreicht und nicht den Port. Auch da werde ich noch mal die Tage herumspielen und das Ergebnis mitteilen.
Komisch ist übrigens auch, dass Cloud Sync eine ganze Weile gebraucht hat, um sich mit den Clouds zu verbinden. Ich wollte schon eth0 (LAN1) wieder einstecken, aber nach mehreren Minuten hat er es nun doch hinbekommen und lädt jetzt vermutlich über eth1 (LAN2) hoch.
Übrigens auch wichtig ist es in der Fritz!Box unter Netzwerk alle nicht mehr genutzten Verbindungen zur DiskStation zu löschen. Ansonsten löst nämlich \\DISKSTATION nach wie vor zu der nicht mehr genutzen eth0 (LAN1), also IP 192.168.178.5 auf und das NAS ist nicht über den Explorer erreichbar.
Meine Brücke sieht nun so aus:
Rich (BBCode):
brctl show
bridge name bridge id STP enabled interfaces
br0 8000.0011329f8290 no eth1
eth4Und die Werte aller Netzwerk-Schnittstellen so:
Rich (BBCode):
ifconfig
br0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.6 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 0000::000:32ff:fe9f:0000/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:668663 errors:0 dropped:0 overruns:0 frame:0
TX packets:531475 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40318789 (38.4 MiB) TX bytes:7896566361 (7.3 GiB)
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.5 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:10962738 errors:0 dropped:0 overruns:0 frame:0
TX packets:48922559 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4726403762 (4.4 GiB) TX bytes:72130182281 (67.1 GiB)
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.6 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:28475132 errors:0 dropped:0 overruns:0 frame:0
TX packets:6812635 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:39044541034 (36.3 GiB) TX bytes:6914357045 (6.4 GiB)
eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:169.254.59.92 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth3 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:169.254.35.224 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:54705 errors:0 dropped:0 overruns:0 frame:0
TX packets:332501 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4268817 (4.0 MiB) TX bytes:498986105 (475.8 MiB)
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.10 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:17427855 errors:0 dropped:0 overruns:0 frame:0
TX packets:31960262 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:21490017029 (20.0 GiB) TX bytes:46763352068 (43.5 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:516026 errors:0 dropped:0 overruns:0 frame:0
TX packets:516026 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:110015675 (104.9 MiB) TX bytes:110015675 (104.9 MiB)Wie man sieht hat die Brücke immer noch eine IPv6. Obwohl ich diese gezielt wie folgt gelöscht habe, erscheint sie immer wieder neu:
Rich (BBCode):
ifconfig br0 inet6 del 0000::000:32ff:fe9f:0000/64Vermutlich brauche ich für die vollständige Deaktivierung von IPv6 für diese Schnittstelle einen anderen Befehl. Da ich aber wie gesagt beim 10 Gbit Adapter des PCs IPv6 deaktiviert habe, wird sie eh nicht mehr verwendet:
Jedenfalls kann ich nun auch den eth0 (LAN1) Stecker problemlos ziehen. Wer ebenfalls Probleme hat, sollte in jedem Fall erstmal IPv6 deaktivieren und dann weiter testen.
Wie man sehen kann, habe ich diesmal beide Schnittstellen auf Promisc gesetzt:
Rich (BBCode):
ifconfig eth1 192.168.178.7 promisc up
ifconfig eth4 192.168.178.7 promisc upDie Erklärung zu dieser Option:
https://linuxwiki.de/EthernetBridge
Ich nehme mal an, damit sind Multicast Pakete gemeint?! Jedenfalls habe ich sie für beide Ports aktiviert. Einen Nachteil sehe ich dabei nicht. Soweit ich das verstehe, ist diese Einstellung aber auch gar nicht notwendig.
Zuletzt habe ich auch noch komische Dinge in meiner Routing-Tabelle festgestellt. Ich hatte da zB die Destination 192.168.2.0 für eth4 gesetzt (vermutlich durch meine Spielereien). Jetzt sieht es dagegen so aus:
Rich (BBCode):
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth4
default fritz.box 0.0.0.0 UG 0 0 0 br0
default fritz.box 0.0.0.0 UG 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4Korrigiert hatte ich das, in dem ich den fehlerhaften Eintrag entfernt habe wie folgt:
Rich (BBCode):
route del -net 192.168.2.0 netmask 255.255.255.0 gw 0.0.0.0Und wieder hinzugefügt habe ich es, in dem ich die IP des eth4 erneut gesetzt habe:
Rich (BBCode):
ifconfig eth4 192.168.178.10Und schlussendlich konnte ich dann auch das Gateway dann setzen:
Rich (BBCode):
route add default gw 192.168.178.1 dev eth4Vorher führte das nämlich zum Fehler "SIOCADDRT: Network is unreachable".
Ich werde das jetzt noch ein paar Tage beobachten und dann schaue ich mal wie ich das in einem Skript umgesetzt bekomme. Das Problem ist nämlich, dass man vorher nicht wissen kann welche Werte aktuell gesetzt sind. Besonders wenn man ein paar mal herumspielt kann einiges falsch eingestellt sein und schon bringt auch das Skript keine Besserung. Sowie ich das aber verstanden habe setzt sich die Synology bei jedem Neustart in Sachen Netzwerk-Schnittstellen zurück (wenn keine Autostart-Skript konfiguriert wurde). Mal sehen was dann alles für Werte existieren. Darauf kann man das Skript dann ja aufbauen lassen. Vielleicht bekomme ich das dann mit IPv6 auch gelöst. Ich brauche es nicht, aber warum nicht auch dieses Problem lösen. Vor allem hätte ich ja gerne mal gewusst warum die Ports eigentlich IPs bekommen. In den ganzen Anleitungen im Netz zum Thema Bridging entfernen alle die IPs mit diesem Befehl:
Rich (BBCode):
ifconfig eth1 0.0.0.0Das erscheint mir eigentlich logisch zu sein, da man ja nur noch die Bridge über die IP erreicht und nicht den Port. Auch da werde ich noch mal die Tage herumspielen und das Ergebnis mitteilen.
Komisch ist übrigens auch, dass Cloud Sync eine ganze Weile gebraucht hat, um sich mit den Clouds zu verbinden. Ich wollte schon eth0 (LAN1) wieder einstecken, aber nach mehreren Minuten hat er es nun doch hinbekommen und lädt jetzt vermutlich über eth1 (LAN2) hoch.
Übrigens auch wichtig ist es in der Fritz!Box unter Netzwerk alle nicht mehr genutzten Verbindungen zur DiskStation zu löschen. Ansonsten löst nämlich \\DISKSTATION nach wie vor zu der nicht mehr genutzen eth0 (LAN1), also IP 192.168.178.5 auf und das NAS ist nicht über den Explorer erreichbar.
Zuletzt bearbeitet:
Heute starte ich meinen Rechner neu und komme über LAN10G nicht mal mehr auf die Fritz!Box. Also wieder über LAN1G ins lokale Netz. Dort geht alles. Also per Putty gecheckt was da los sein kann. Über ifconfig sehe ich, dass eth4 (10 Gbit Karte) einfach so die IP 192.168.2.10 erhalten hat:
Die hatte ich tatsächlich mal vor 2 oder 3 Versuchen eingestellt, aber danach immer die 192.168.178.6. Da scheint also irgendeine Routine über DSM zu laufen, welche die IP überschreibt.
Über route sehe ich auch, dass das hinterlegte Standard-Gateway verschwunden ist:
Und nur als Info: Das NAS ist durchgelaufen. Nur meinen PC hatte ich den Tag über ausgeschaltet.
Ich habe nun also die IP wie folgt korrigiert:
Jetzt sieht es so aus:
Nun wollte ich per route das Standard-Gateway dafür setzen:
Aber erneut erhalte ich wieder nur den Fehler:
Ich dachte dann, gut machen wir die Brücke neu, also fahren sie erst mal runter:
Prompt beschwert sich das Kind, dass 192.168.178.6 nicht mehr erreichbar ist (Plex geht nicht mehr). Ich denke mir "Mist" und fahre die Brücke wieder hoch:
Aber denkste. 192.168.178.6 bleibt nun über beide Verbindungen (LAN1G und LAN10G) unerreichbar. Per Putty (ifconfig, btctl) kann ich keine Fehler erkennen bzw es sieht alles genauso aus wie gestern. Nur eben der route-Eintrag fehlt, den ich aber wegen der Fehlermeldung auch nicht hinzufügen kann. Man nervt das.
Warum kann ich denn jetzt für eth4 nicht das Gateway 192.168.178.1 setzen? Mein PC erhält über LAN10G auch keine IP mehr per DHCP, dh die Bridge funktioniert auch nicht mehr.
Also habe ich LAN10G die feste IP 192.168.178.11 gegeben.. nichts. Mal mit 192.168.2.11 versucht... nichts. Immer nur nicht identifiziertes Netzwerk und keine der früheren oder neueren IPs lassen mich das NAS finden.
EDIT: Moment, ich habe doch einen Unterschied festgestellt. Und zwar stand gestern bei eth4 das:
Und jetzt fehlt das "RUNNING":
Also mal runtergefahren:
Und wieder rauf:
RUNNING muss da sein, sonst ist der Treiber quasi gar nicht aktiv:
http://blog.hyfather.com/blog/2013/03/04/ifconfig/
Also habe ich die Brücke doch wieder gelöscht und neu angelegt. Diesmal ist eth4 wieder mit "RUNNING" am Start, aber hat erneut die falsche IP:
Also erneut geändert. RUNNING ist geblieben:
Also route dazu:
Und... tada:
Sieht doch alles supi aus. Über LAN10G bekomme ich auch wieder eine IP per DHCP doch 192.168.178.6 bleibt unerreichbar.
Ich gehe jetzt Fernsehen schauen. Ist doch echt frustrierend.
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.2.10 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:133662059 errors:0 dropped:0 overruns:0 frame:0
TX packets:57330917 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184600596405 (171.9 GiB) TX bytes:69729278354 (64.9 GiB)Die hatte ich tatsächlich mal vor 2 oder 3 Versuchen eingestellt, aber danach immer die 192.168.178.6. Da scheint also irgendeine Routine über DSM zu laufen, welche die IP überschreibt.
Über route sehe ich auch, dass das hinterlegte Standard-Gateway verschwunden ist:
Rich (BBCode):
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1Und nur als Info: Das NAS ist durchgelaufen. Nur meinen PC hatte ich den Tag über ausgeschaltet.
Ich habe nun also die IP wie folgt korrigiert:
Rich (BBCode):
ifconfig eth4 192.168.178.6Jetzt sieht es so aus:
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.6 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:133662059 errors:0 dropped:0 overruns:0 frame:0
TX packets:57330917 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184600596405 (171.9 GiB) TX bytes:69729278354 (64.9 GiB)Nun wollte ich per route das Standard-Gateway dafür setzen:
Rich (BBCode):
route add default gw 192.168.178.1 dev eth4Aber erneut erhalte ich wieder nur den Fehler:
Rich (BBCode):
SIOCADDRT: Network is unreachableIch dachte dann, gut machen wir die Brücke neu, also fahren sie erst mal runter:
Rich (BBCode):
ifconfig br0 downPrompt beschwert sich das Kind, dass 192.168.178.6 nicht mehr erreichbar ist (Plex geht nicht mehr). Ich denke mir "Mist" und fahre die Brücke wieder hoch:
Rich (BBCode):
ifconfig br0 upAber denkste. 192.168.178.6 bleibt nun über beide Verbindungen (LAN1G und LAN10G) unerreichbar. Per Putty (ifconfig, btctl) kann ich keine Fehler erkennen bzw es sieht alles genauso aus wie gestern. Nur eben der route-Eintrag fehlt, den ich aber wegen der Fehlermeldung auch nicht hinzufügen kann. Man nervt das.
Warum kann ich denn jetzt für eth4 nicht das Gateway 192.168.178.1 setzen? Mein PC erhält über LAN10G auch keine IP mehr per DHCP, dh die Bridge funktioniert auch nicht mehr.
Also habe ich LAN10G die feste IP 192.168.178.11 gegeben.. nichts. Mal mit 192.168.2.11 versucht... nichts. Immer nur nicht identifiziertes Netzwerk und keine der früheren oder neueren IPs lassen mich das NAS finden.
EDIT: Moment, ich habe doch einen Unterschied festgestellt. Und zwar stand gestern bei eth4 das:
Rich (BBCode):
UP BROADCAST RUNNING PROMISC MULTICASTUnd jetzt fehlt das "RUNNING":
Rich (BBCode):
UP BROADCAST PROMISC MULTICASTAlso mal runtergefahren:
Rich (BBCode):
ifconfig eth4 downUnd wieder rauf:
Rich (BBCode):
ifconfig eth4 192.168.178.6 promisc upRUNNING muss da sein, sonst ist der Treiber quasi gar nicht aktiv:
http://blog.hyfather.com/blog/2013/03/04/ifconfig/
Also habe ich die Brücke doch wieder gelöscht und neu angelegt. Diesmal ist eth4 wieder mit "RUNNING" am Start, aber hat erneut die falsche IP:
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.2.10 Bcast:192.168.2.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:133662600 errors:0 dropped:0 overruns:0 frame:0
TX packets:57335239 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184600662334 (171.9 GiB) TX bytes:69729833996 (64.9 GiB)Also erneut geändert. RUNNING ist geblieben:
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.6 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:133662620 errors:0 dropped:0 overruns:0 frame:0
TX packets:57335918 errors:3 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184600664238 (171.9 GiB) TX bytes:69729925812 (64.9 GiB)Also route dazu:
Rich (BBCode):
route add default gw 192.168.178.1 dev eth4Und... tada:
Rich (BBCode):
route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth4
default fritz.box 0.0.0.0 UG 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4Sieht doch alles supi aus. Über LAN10G bekomme ich auch wieder eine IP per DHCP doch 192.168.178.6 bleibt unerreichbar.
Ich gehe jetzt Fernsehen schauen. Ist doch echt frustrierend.
Ich habe mich gerade wieder daran versucht und erneut etwas herausgefunden. Also das gestern die IP ständig auf 192.168.2.10 zurückgesprungen ist, lag denke ich tatsächlich an einer festen IP, die ich mal über das DSM gesetzt habe. Jedenfalls habe ich die Brücke gesetzt und im DSM stand sie dann drin:
Auf Grund dessen habe ich mich entschieden allen LAN Ports über das DSM mal feste IP-Adressen zu vergeben wie folgt:
LAN1 (eth0) = 192.168.178.5
LAN2 (eth1) = 192.168.178.6 (mit Netzwerk verbunden)
LAN3 (eth2) = 192.168.178.7
LAN4 (eth3) = 192.168.178.10 (mit Netzwerk verbunden)
LAN5 (eth4) = 192.168.178.11 (mit PC verbunden)
Der anschließend erstellten Brücke habe ich dann 192.168.178.12 gegeben.
Ich habe dann alles eingestellt, schaue auf ifconfig und was sehe ich, eth3 (LAN4) hat plötzlich die IP 192.168.178.6 (also die selbe IP wie eth1 (LAN2). Die habe ich ganz sicher niemals eingestellt. Keine Ahnung warum er sich die gezogen hat. Also habe ich die wieder auf .10 gesetzt:
Eine weitere Inkonstenz konnte ich bei route feststellen. Immer wieder verschwanden die Default Gateway Einstellungen, je nachdem ob man eine IP von eth3 usw änderte. Aber auch jetzt ist das Gateway für br0 verschwunden. Vor ein paar Minuten habe ich es noch gesetzt:
Und während ich den Beitrag schreibe, fehlt es nun wieder:
Vor allem sieht man, dass zu Anfang noch eth3 ein Gateway hatte und jetzt hat eth4 eines?! Jedenfalls habe ich entschieden keine weitere route zu setzen.
Als nächstes habe ich dann auf dem PC wie gehabt LAN1G deaktiviert und bin wieder nur direkt per LAN10G mit dem NAS verbunden. Ich erhalte eine IP, ich kann auf die .6 und .12 zugreifen, aber ich habe nur 1 Gbit Bandbreite, obwohl der Status 10 Gbit meldet. Ich dachte wieder an meine IPv6 Entdeckung aus dem vorherigen Beitrag. Aber ich hatte ja bereits IPv6 deaktiviert. Das war es also doch nicht. Dann habe ich IPv6 wieder in den Netzwerk-Eigenschaften aktiviert und plötzlich lag die Bandbreite wieder an:
Damit steht wohl denke ich fest, dass der Treiber der 10 Gbit Karte einen Bug hat oder aber dass das Routing erst dann korrigiert wird, wenn diese Einstellung verändert wird. Jedenfalls hilft es nicht den Adapter zu deaktivieren oder den Stecker ziehen. Erst wenn man kurz IPv6 de- und aktiviert, resultiert eine direkte Route zwischen PC und NAS und die vollen 10 Gbit liegen an. Beim nächsten Erstellen der Brücke mache ich mal einen tracert über meinen PC. Ich wette, dass im Falle von 1 Gbit alles über die Fritz!Box läuft und nach dem Trick erst die direkte Verbindung zwischen PC und NAS besteht.
Übrigens setze ich jetzt immer grundsätzlich PROMISC für beide Ports der Brücke:
zB war PROMISC auf eth4 noch aktiv und ich kam nicht auf .12. Als ich es dann aber für eth3 setzte, ging DSM sofort auf.
Wie gehabt lasse ich das nun den Tag über so. Heute Abend checke ich dann ob noch alles so ist wie ich es eingestellt habe.
EDIT: Jetzt noch mal der Ist-Zustand bevor ich die DS herunterfahre:
Auf Grund dessen habe ich mich entschieden allen LAN Ports über das DSM mal feste IP-Adressen zu vergeben wie folgt:
LAN1 (eth0) = 192.168.178.5
LAN2 (eth1) = 192.168.178.6 (mit Netzwerk verbunden)
LAN3 (eth2) = 192.168.178.7
LAN4 (eth3) = 192.168.178.10 (mit Netzwerk verbunden)
LAN5 (eth4) = 192.168.178.11 (mit PC verbunden)
Der anschließend erstellten Brücke habe ich dann 192.168.178.12 gegeben.
Ich habe dann alles eingestellt, schaue auf ifconfig und was sehe ich, eth3 (LAN4) hat plötzlich die IP 192.168.178.6 (also die selbe IP wie eth1 (LAN2). Die habe ich ganz sicher niemals eingestellt. Keine Ahnung warum er sich die gezogen hat. Also habe ich die wieder auf .10 gesetzt:
Rich (BBCode):
ifconfig eth3 192.168.178.10Eine weitere Inkonstenz konnte ich bei route feststellen. Immer wieder verschwanden die Default Gateway Einstellungen, je nachdem ob man eine IP von eth3 usw änderte. Aber auch jetzt ist das Gateway für br0 verschwunden. Vor ein paar Minuten habe ich es noch gesetzt:
Rich (BBCode):
ash-4.3# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4
ash-4.3# route add default gw 192.168.178.1 dev br0
ash-4.3# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 br0
default fritz.box 0.0.0.0 UG 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4Und während ich den Beitrag schreibe, fehlt es nun wieder:
Rich (BBCode):
ash-4.3# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth4
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth4
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
ash-4.3#Vor allem sieht man, dass zu Anfang noch eth3 ein Gateway hatte und jetzt hat eth4 eines?! Jedenfalls habe ich entschieden keine weitere route zu setzen.
Als nächstes habe ich dann auf dem PC wie gehabt LAN1G deaktiviert und bin wieder nur direkt per LAN10G mit dem NAS verbunden. Ich erhalte eine IP, ich kann auf die .6 und .12 zugreifen, aber ich habe nur 1 Gbit Bandbreite, obwohl der Status 10 Gbit meldet. Ich dachte wieder an meine IPv6 Entdeckung aus dem vorherigen Beitrag. Aber ich hatte ja bereits IPv6 deaktiviert. Das war es also doch nicht. Dann habe ich IPv6 wieder in den Netzwerk-Eigenschaften aktiviert und plötzlich lag die Bandbreite wieder an:
Damit steht wohl denke ich fest, dass der Treiber der 10 Gbit Karte einen Bug hat oder aber dass das Routing erst dann korrigiert wird, wenn diese Einstellung verändert wird. Jedenfalls hilft es nicht den Adapter zu deaktivieren oder den Stecker ziehen. Erst wenn man kurz IPv6 de- und aktiviert, resultiert eine direkte Route zwischen PC und NAS und die vollen 10 Gbit liegen an. Beim nächsten Erstellen der Brücke mache ich mal einen tracert über meinen PC. Ich wette, dass im Falle von 1 Gbit alles über die Fritz!Box läuft und nach dem Trick erst die direkte Verbindung zwischen PC und NAS besteht.
Übrigens setze ich jetzt immer grundsätzlich PROMISC für beide Ports der Brücke:
Rich (BBCode):
ifconfig eth3 192.168.178.6 promisc up
ifconfig eth4 192.168.178.6 promisc upzB war PROMISC auf eth4 noch aktiv und ich kam nicht auf .12. Als ich es dann aber für eth3 setzte, ging DSM sofort auf.
Wie gehabt lasse ich das nun den Tag über so. Heute Abend checke ich dann ob noch alles so ist wie ich es eingestellt habe.
EDIT: Jetzt noch mal der Ist-Zustand bevor ich die DS herunterfahre:
Rich (BBCode):
ash-4.3# ifconfig
br0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.12 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 0000::000:0000:0000:0000/64 Scope:Link
inet6 addr: 000::000:000:0000:0000/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:812776 errors:0 dropped:0 overruns:0 frame:0
TX packets:241339 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:100013045 (95.3 MiB) TX bytes:4347391767 (4.0 GiB)
eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.5 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 0000::000:0000:0000:0000/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:11580571 errors:0 dropped:0 overruns:0 frame:0
TX packets:50079196 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4814848398 (4.4 GiB) TX bytes:73745340292 (68.6 GiB)
eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.6 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 000::000:000:0000:0000/64 Scope:Global
inet6 addr: 0000::000:0000:0000:0000/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:49126308 errors:0 dropped:0 overruns:0 frame:0
TX packets:44879729 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40999907867 (38.1 GiB) TX bytes:62875687435 (58.5 GiB)
eth2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.7 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
eth3 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.10 Bcast:192.168.178.255 Mask:255.255.255.0
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:2084796 errors:0 dropped:0 overruns:0 frame:0
TX packets:1248069 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2279335363 (2.1 GiB) TX bytes:1658099303 (1.5 GiB)
eth4 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:192.168.178.11 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: 0000::000:0000:0000:0000/64 Scope:Link
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:134012972 errors:0 dropped:0 overruns:0 frame:0
TX packets:61288649 errors:4 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:184643463135 (171.9 GiB) TX bytes:75331805322 (70.1 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1091111 errors:0 dropped:0 overruns:0 frame:0
TX packets:1091111 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:247892823 (236.4 MiB) TX bytes:247892823 (236.4 MiB)
ash-4.3# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default fritz.box 0.0.0.0 UG 0 0 0 eth1
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
ash-4.3# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.000000000000 no eth3
eth4
Zuletzt bearbeitet:
Ich habe jetzt im Aufgabenplaner das folgende Skript hinterlegt:
Fährt man die DS hoch und hat in eth3 oder eth4 keinen Stecker eingesteckt, dann wird keine Brücke erstellt. So kann man im Fehlerfall einfach ein Kabel weglassen und das Erstellen der Brücke verhindern.
Jedenfalls hat das Skript funktioniert. Die Brücke wurde erstellt und der PC erhält auch eine IP. Und erneut gehen nur 1 Gbit statt 10 Gbit durch. Doch diesmal hilft es nicht IPv6 ein- und auszuschalten.
Der tracert auf das NAS sieht auch völlig in Ordnung aus:
Und sowohl Windows und NAS haben auch 10 Gbit/s ausgehandelt:
Da stimmt doch 100%-tig irgendwas nicht mit dem Treiber der Karte.
EDIT: Neueste Treiberversion installiert. Rechner neu gestartet. Es kann 1, 5 und 10 Gbit/s ausgehandelt werden, aber netto gehen immer nur 1 Gbit/s durch. Ja bin ich denn jetzt bekloppt
Rich (BBCode):
#!/bin/sh
# Load the required kernel modules
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
# stop execution if bridge already exists
if ethtool br0 2>/dev/null | grep -q "Link detected: yes"; then
echo "Bridge already exists!"
exit 0;
fi
# stop if first ethernet port is disconnected (trouble fallback)
if ! ethtool eth3 2>/dev/null | grep -q "Link detected: yes"; then
echo "The first bridge port is not connected!"
exit 1;
fi
# stop if second ethernet port is disconnected (trouble fallback)
if ! ethtool eth4 2>/dev/null | grep -q "Link detected: yes"; then
echo "The second bridge port is not connected!"
exit 1;
fi
# add bridge
brctl addbr br0
brctl stp br0 off
# set bridge ip
ifconfig br0 192.168.178.12 netmask 255.255.255.0 up
# add ethernet ports to bridge
brctl addif br0 eth3
brctl addif br0 eth4
# unset ips of ethernet ports and process all network traffic
#ifconfig eth3 0.0.0.0 promisc up
#ifconfig eth4 0.0.0.0 promisc up
# add gateway to bridge
#route add default gw 192.168.178.1 dev br0Fährt man die DS hoch und hat in eth3 oder eth4 keinen Stecker eingesteckt, dann wird keine Brücke erstellt. So kann man im Fehlerfall einfach ein Kabel weglassen und das Erstellen der Brücke verhindern.
Jedenfalls hat das Skript funktioniert. Die Brücke wurde erstellt und der PC erhält auch eine IP. Und erneut gehen nur 1 Gbit statt 10 Gbit durch. Doch diesmal hilft es nicht IPv6 ein- und auszuschalten.
Der tracert auf das NAS sieht auch völlig in Ordnung aus:
Rich (BBCode):
tracert DISKSTATION
Routenverfolgung zu DISKSTATION [192.168.178.12]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms DISKSTATION [192.168.178.12]
Ablaufverfolgung beendet.Und sowohl Windows und NAS haben auch 10 Gbit/s ausgehandelt:
Rich (BBCode):
ethtool eth4
Settings for eth4:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: 10000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: d
Link detected: yesDa stimmt doch 100%-tig irgendwas nicht mit dem Treiber der Karte.
EDIT: Neueste Treiberversion installiert. Rechner neu gestartet. Es kann 1, 5 und 10 Gbit/s ausgehandelt werden, aber netto gehen immer nur 1 Gbit/s durch. Ja bin ich denn jetzt bekloppt
Zuletzt bearbeitet:
Ich bekomme nach wie vor keine 10 GBit durch die Leitung. Ich habe testweise die Brücke weggelassen und mit festen IPs NAS und PC verbunden. Dort bekomme ich die 10 GBit durch. Also liegt es nicht am Kabel und vielleicht doch nicht am Treiber der Karte, sondern irgendwie an der Brücke selbst.
Weitere Notizen / Beobachtungen:
- mit "ip -6 addr flush dev br0" bzw eth3 bzw eth4 kann ich alle IPv6 Adressen löschen (hat aber nichts gebracht)
- ich kann br0 kein Gateway eintragen mit "route add default gw 192.168.178.1 dev br0" wenn in route der Eintrag "192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0" fehlt. Komischerweise fehlt der nur, wenn ich über den Aufgabenplaner bzw mein Skript die Brücke erstelle. Erstelle ich sie manuell mit Putty, dann erscheint dieser Eintrag von alleine.
- das gesetzte Gateway verschwindet nach kurzer Zeit wieder aus der Liste
- wenn ich auf dem PC eine feste IP setze und als Gateway 192.168.178.1 eintrage und die DNS Felder leer lasse, dann kann ich keine Domains auflösen. Er löst aber wieder Domains auf, wenn ich als ersten DNS die 192.168.178.1 eintrage. Das musste ich allerdings noch nie machen, wenn ich meinem PC eine feste IP gebe?!
- ich kann per "ifconfig eth3 0" und "ifconfig eth4 0" die IPv4 Adressen ohne Auswirkungen auf die Brücke löschen
- ich habe testweise per "ifconfig eth4 -promisc" und "ifconfig eth3 -promisc" entfernt und auch das hatte keine Auswirkungen. Danach habe ich die Brücke gelöscht und neu anlegt. Ebenfalls ohne PROMISC und erneut keine Probleme. Das macht auch keinen Sinn, denn ich weiß aus den vorherigen Tests, dass ich das mal setzen musste. Echt verrückt.
- ich habe mit "ip link set br0 address xx:xx:xx:xx:xx:xx" die MAC-Adresse von eth4 gesetzt, da ich gesehen habe, dass egal welchen Port man der Brücke zuerst hinzufügt immer die MAC-Adresse von eth3 übernommen wurde. Ich habe auch mal eine komplett erfundene MAC-Adresse gesetzt.
- in der Fritz!Box zeigt er immer die .10 an, obwohl dies die IP von eth3 ist, die ja nach Erstellen der Brücke eigentlich weg sein sollte. Die .10 kann ich auch nicht anpingen.
EDIT: Jetzt habe ich gerade wieder einen 10 Gbit/s Durchsatz. Warum.. keine Ahnung. Was ich gemacht habe:
1.) Ich habe die Brücke gelöscht
2.) Ich habe im DSM auf allen Ports IPv6 aktiviert (bei eth3 war es aus, bei eth4 an)
3.) Ich habe die Brücke über Putty erstellt
4.) Es fehlte auch diesmal der Eintrag "192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0", also habe ich ihn per "route add -net 192.168.178.0 netmask 255.255.255.0 dev br0" hinzugefügt
5.) Ich habe das Standard-Gateway per "route add default gw 192.168.178.1 dev br0" hinzugefügt
6.) Ich habe in Windows bei den Adapter-Einstellungen IPv6 aktiviert und deaktiviert. Macht keinen Unterschied. Die volle Bandbreite liegt in beiden Fällen an
7.) Ich habe einen ping auf DISKSTATION abgesetzt. Sie löst wie immer auf 192.168.178.12 auf (die IP der Brücke).
8.) Ich habe per SMB von \\192.168.178.12\video und von \\DISKSTATION\video auf den PC kopiert. In beiden Fällen liegt die volle Bandbreite an
9.) Schauen wir uns die IPs von br0 und eth3 an, dann stellen wir fest, dass sich beide die selbe IPv6 Global und MAC-Adresse teilen:
10.) PROMISC ist auf allen Ports nicht aktiv
11.) eth4 sieht normal aus wie immer:
Mal sehen was der nächste Neustart der DS bringt. Ich habe jedenfalls das Skript um den neuen route-Befehl ergänzt und promisc auskommentiert:
Weitere Notizen / Beobachtungen:
- mit "ip -6 addr flush dev br0" bzw eth3 bzw eth4 kann ich alle IPv6 Adressen löschen (hat aber nichts gebracht)
- ich kann br0 kein Gateway eintragen mit "route add default gw 192.168.178.1 dev br0" wenn in route der Eintrag "192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0" fehlt. Komischerweise fehlt der nur, wenn ich über den Aufgabenplaner bzw mein Skript die Brücke erstelle. Erstelle ich sie manuell mit Putty, dann erscheint dieser Eintrag von alleine.
- das gesetzte Gateway verschwindet nach kurzer Zeit wieder aus der Liste
- wenn ich auf dem PC eine feste IP setze und als Gateway 192.168.178.1 eintrage und die DNS Felder leer lasse, dann kann ich keine Domains auflösen. Er löst aber wieder Domains auf, wenn ich als ersten DNS die 192.168.178.1 eintrage. Das musste ich allerdings noch nie machen, wenn ich meinem PC eine feste IP gebe?!
- ich kann per "ifconfig eth3 0" und "ifconfig eth4 0" die IPv4 Adressen ohne Auswirkungen auf die Brücke löschen
- ich habe testweise per "ifconfig eth4 -promisc" und "ifconfig eth3 -promisc" entfernt und auch das hatte keine Auswirkungen. Danach habe ich die Brücke gelöscht und neu anlegt. Ebenfalls ohne PROMISC und erneut keine Probleme. Das macht auch keinen Sinn, denn ich weiß aus den vorherigen Tests, dass ich das mal setzen musste. Echt verrückt.
- ich habe mit "ip link set br0 address xx:xx:xx:xx:xx:xx" die MAC-Adresse von eth4 gesetzt, da ich gesehen habe, dass egal welchen Port man der Brücke zuerst hinzufügt immer die MAC-Adresse von eth3 übernommen wurde. Ich habe auch mal eine komplett erfundene MAC-Adresse gesetzt.
- in der Fritz!Box zeigt er immer die .10 an, obwohl dies die IP von eth3 ist, die ja nach Erstellen der Brücke eigentlich weg sein sollte. Die .10 kann ich auch nicht anpingen.
EDIT: Jetzt habe ich gerade wieder einen 10 Gbit/s Durchsatz. Warum.. keine Ahnung. Was ich gemacht habe:
1.) Ich habe die Brücke gelöscht
2.) Ich habe im DSM auf allen Ports IPv6 aktiviert (bei eth3 war es aus, bei eth4 an)
3.) Ich habe die Brücke über Putty erstellt
4.) Es fehlte auch diesmal der Eintrag "192.168.178.0 0.0.0.0 255.255.255.0 U 0 0 0 br0", also habe ich ihn per "route add -net 192.168.178.0 netmask 255.255.255.0 dev br0" hinzugefügt
5.) Ich habe das Standard-Gateway per "route add default gw 192.168.178.1 dev br0" hinzugefügt
6.) Ich habe in Windows bei den Adapter-Einstellungen IPv6 aktiviert und deaktiviert. Macht keinen Unterschied. Die volle Bandbreite liegt in beiden Fällen an
7.) Ich habe einen ping auf DISKSTATION abgesetzt. Sie löst wie immer auf 192.168.178.12 auf (die IP der Brücke).
8.) Ich habe per SMB von \\192.168.178.12\video und von \\DISKSTATION\video auf den PC kopiert. In beiden Fällen liegt die volle Bandbreite an
9.) Schauen wir uns die IPs von br0 und eth3 an, dann stellen wir fest, dass sich beide die selbe IPv6 Global und MAC-Adresse teilen:
Rich (BBCode):
br0 Link encap:Ethernet HWaddr 00:00:00:00:82:92
inet addr:192.168.178.12 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::203e:0000:0000:f74b/64 Scope:Link
inet6 addr: fd00::211:0000:0000:8292/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134487 errors:0 dropped:0 overruns:0 frame:0
TX packets:408422 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19607792 (18.6 MiB) TX bytes:6008324607 (5.5 GiB)
...
eth3 Link encap:Ethernet HWaddr 00:00:00:00:82:92
inet addr:192.168.178.10 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fd00::211:0000:0000:8292/64 Scope:Global
inet6 addr: fe80::211:0000:0000:8292/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:588748 errors:0 dropped:0 overruns:0 frame:0
TX packets:513984 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:643879170 (614.0 MiB) TX bytes:668674182 (637.6 MiB)11.) eth4 sieht normal aus wie immer:
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:66:6B
inet addr:192.168.178.11 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::211:0000:0000:666b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:281550 errors:0 dropped:0 overruns:0 frame:0
TX packets:4307070 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:47286825 (45.0 MiB) TX bytes:6211401390 (5.7 GiB)Mal sehen was der nächste Neustart der DS bringt. Ich habe jedenfalls das Skript um den neuen route-Befehl ergänzt und promisc auskommentiert:
Rich (BBCode):
#!/bin/sh
################################################################################
# Ethernet bridge for Synology v0.2
#
# notes:
# - let this script run on boot with root privileges
# - this script creates a bridge between LAN4 (eth3, 1G) and LAN5 (eth4, 10G)
# - the bridge gets the IP 192.168.178.12 (change it to your needs)
# - if LAN4 is not connected to a switch it skips bridge creation (fallback in case of troubles)
# - you need to set fixed IPs for LAN4 and LAN5 through DSM that are different from the bridge!
# - if you manually restart the script it will re-create the bridge (maybe useful for debugging purposes)
#
################################################################################
# Load the required kernel modules
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
# remove bridge if it already exists
if ethtool br0 2>/dev/null | grep -q "Link detected: yes"; then
ifconfig br0 down
brctl delbr br0
echo "Already existing LAN-Bridge has been removed!"
fi
# stop if first ethernet port is disconnected (trouble fallback)
if ! ethtool eth3 2>/dev/null | grep -q "Link detected: yes"; then
echo "LAN-Bridge not created. The first bridge port is not connected!"
exit 1
fi
# add bridge
brctl addbr br0
brctl stp br0 off
# set bridge ip
ifconfig br0 192.168.178.12 netmask 255.255.255.0 up
# add ethernet ports to bridge
brctl addif br0 eth3
brctl addif br0 eth4
# process any network traffic
#ifconfig eth3 promisc up
#ifconfig eth4 promisc up
# set bridge mac address to eth4
#ip link set br0 address 00:00:00:00:66:6B
# add routes
route add -net 192.168.178.0 netmask 255.255.255.0 dev br0
route add default gw 192.168.178.1 dev br0
Zuletzt bearbeitet:
Der Rechner und das NAS waren die ganze Zeit an. Trotzdem hat mein PC die Verbindung zum Internet und Intranet verloren. Ich denke es liegt daran, dass nun bei eth4 "RUNNING" fehlt:
Jo, es besteht auch kein Link:
Wenn ich den Stecker am PC ziehe (ist ja direkt mit dem NAS verbunden), dann ändert dies nichts.
Das einzige was funktioniert hat war kurz die Schnittstelle aus- und wieder einschalten:
Es liegen witzigerweise auch wieder 10 Gbit/s voll an. Ich werde das Gefühl nicht los, dass einer der beiden Karten oder Treiber einen Bug haben. Wenn das so weiter geht, kaufe ich mir wohl doch einen 10G Switch. Kann doch echt nicht so schwer sein das zum laufen zu bringen.
Rich (BBCode):
eth4 Link encap:Ethernet HWaddr 00:00:00:00:66:6B
inet addr:192.168.178.11 Bcast:192.168.178.255 Mask:255.255.255.0
inet6 addr: fe80::211:0000:0000:666b/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:297270516 errors:0 dropped:0 overruns:0 frame:0
TX packets:99779918 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:374413588608 (348.6 GiB) TX bytes:35989121637 (33.5 GiB)Jo, es besteht auch kein Link:
Rich (BBCode):
ethtool eth4
Settings for eth4:
Supported ports: [ TP ]
Supported link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Supported pause frame use: Symmetric
Supports auto-negotiation: Yes
Advertised link modes: 100baseT/Full
1000baseT/Full
10000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: g
Wake-on: d
Link detected: noWenn ich den Stecker am PC ziehe (ist ja direkt mit dem NAS verbunden), dann ändert dies nichts.
Das einzige was funktioniert hat war kurz die Schnittstelle aus- und wieder einschalten:
Rich (BBCode):
ifconfig eth4 down
ifconfig eth4 upEs liegen witzigerweise auch wieder 10 Gbit/s voll an. Ich werde das Gefühl nicht los, dass einer der beiden Karten oder Treiber einen Bug haben. Wenn das so weiter geht, kaufe ich mir wohl doch einen 10G Switch. Kann doch echt nicht so schwer sein das zum laufen zu bringen.
Ich gebe offiziell auf. Ich habe mir jetzt einen Netgear GS110EMX bestellt. Ich werde das Gefühl nicht los als hätte der Treiber der Synology Karte einen Bug oder irgendwas auf dem NAS verhindert einen stabilen Betrieb. zB habe ich eben den PC angemacht und konnte wieder nicht ins Internet. Erneut war der eth4 Port des NAS ohne das RUNNING flag. Über down/up konnte ich ihn sofort wieder zum Laufen bringen. 10 Gbit lagen aber diesmal nicht an. Ein reines Glücksspiel was verständlicherweise auf Dauer nervt. Bei dem Switch habe ich zwei 10 Gbit/s Ports, also genau das was ich brauche. Ich hoffe das läuft dann endlich stabil.
Hier noch mal abschließend das Skript was vom Prinzip fehlerfrei funktioniert hat und immer beim Booten des NAS ausgeführt wurde:
Hier noch mal abschließend das Skript was vom Prinzip fehlerfrei funktioniert hat und immer beim Booten des NAS ausgeführt wurde:
Rich (BBCode):
#!/bin/sh
################################################################################
# Ethernet bridge for Synology v0.2
#
# notes:
# - let this script run on boot with root privileges
# - this script creates a bridge between LAN4 (eth3, 1G) and LAN5 (eth4, 10G)
# - the bridge gets the IP 192.168.178.12 (change it to your needs)
# - if LAN4 is not connected to a switch it skips bridge creation (fallback in case of troubles)
# - you need to set fixed IPs for LAN4 and LAN5 through DSM that are different from the bridge!
# - if you manually restart the script it will re-create the bridge (maybe useful for debugging purposes)
#
################################################################################
# Load the required kernel modules
insmod /lib/modules/stp.ko
insmod /lib/modules/bridge.ko
# remove bridge if it already exists
if ethtool br0 2>/dev/null | grep -q "Link detected: yes"; then
ifconfig br0 down
brctl delbr br0
echo "Already existing LAN-Bridge has been removed!"
fi
# stop if first ethernet port is disconnected (trouble fallback)
if ! ethtool eth3 2>/dev/null | grep -q "Link detected: yes"; then
echo "LAN-Bridge not created. The first bridge port is not connected!"
exit 1
fi
# add bridge
brctl addbr br0
brctl stp br0 off
# set bridge ip
ifconfig br0 192.168.178.12 netmask 255.255.255.0 up
# add ethernet ports to bridge
brctl addif br0 eth3
brctl addif br0 eth4
# process any network traffic
#ifconfig eth3 promisc up
#ifconfig eth4 promisc up
# set bridge mac address to eth4
#ip link set br0 address 00:00:00:00:00:6B
# add routes
route add -net 192.168.178.0 netmask 255.255.255.0 dev br0
route add default gw 192.168.178.1 dev br0
- Mitglied seit
- 10. Mai 2015
- Beiträge
- 9.139
- Punkte für Reaktionen
- 1.799
- Punkte
- 314
Hinweis:
Bei diesem Switch erfolgt eine 10 Gbit/s Verbindung nur ausschließlich zwischen diesen beiden 10 Gbit/s Anschlüssen ( Nr 9 + 10) auf der rechten Seite vom Gerät. Die anderen 8 Ports (Nr 1-8) sind "nur" 1 GBit/s Anschlüsse und auch die Verbindung dieser 8 Ports zu den beiden rechten 10 Gbit/s Port erfolgt NUR mit 1 Gbit/s!
Wenn du also am rechten Port 9 deinen PC mit 10 Gbits Netzwerkkarte anschliesst und am rechten Port 10 dein NAS mit der 10 Gbit/s Karte, so sollte dort eine Verbindung zwischen diesem PC und NAS von ~ 400 bis 700 MB/s möglich sein.
Verbindest du ein weiteres Gerät mit dem Switch so ist die max. Verbindungsgeschwindigkeit 113 MB/s!
Ich bin auf deine Praxiserfahrung gespannt ob die Verbindung über den Switch mit den beiden rechten Anschlüssen 9+10 dann stabil läuft und welche tatsächliche Datenrate dann erreicht wird.
@Kurt-oe1kyw
Der Switch ist bereits im Einsatz. Dass er nur zwei 10G Ports hat war mir klar. Mir ging es ja nur um die Verbindung zwischen PC und NAS und das eben zum kleinstmöglichen Preis. Geschossen hatte ich den Switch für unter 150 € als WHD bei Amazon Frankreich. Den 1. Port des Switches habe ich mit meinem restlichen Netz verbunden, so dass NAS und PC ins Intranet / Internet kommen. Darüber greifen aktuell auch die anderen Clients auf das NAS zu. Eventuell verbinde ich aber die restlichen 4 Ports des NAS als LA mit meinem Haupt-Switch (Zyxel GS1900-16). Das kommt aber denke ich erst zum Tragen, wenn die Kids eigene PCs haben. Sonst wüsste ich nicht wo da wirklich Engpässe entstehen könnten.
Jedenfalls lief es schon einige Tage exzellent:
Beim Hochladen kommen ich im Schnitt auf 300 MB/s. Sind halt nur 5400 rpm Platten. Ich freue mich schon auf den Tag wenn SSDs bezahlbarer werden.
Allerdings hatte ich trotzdem schon zwei Erlebnisse, die mich zum Wahnsinn getrieben haben:
1.) Der Synology Drive Server überlastet die Festplatten und drückt damit massiv die Transferrate (Lösung: Deinstalliert)
2.) Obwohl auf nur 6-monatigen Intervall eingestellt, startet doch eben glatt der erweiterte SMART Test und drückt damit die Transferrate auf unter 50 MB/s (Lösung: Abwarten ^^)
Beides kannst du hier nachlesen:
https://www.synology-forum.de/showthread.html?102816-Synology-Drive-überlastet-10G-Karte-in-DS1618
Jedenfalls möchte ich nie mehr ohne. Das ist so als hätte man eine 30TB große SATA SSD im Rechner
Interessant ist übrigens, dass wenn ich eine 1GB Testdatei 2x herunterlade, dass die beim 2. Mal direkt aus dem RAM des NAS kommt. So schnell kann man fast gar nicht den Screenshot machen
Der Switch ist bereits im Einsatz. Dass er nur zwei 10G Ports hat war mir klar. Mir ging es ja nur um die Verbindung zwischen PC und NAS und das eben zum kleinstmöglichen Preis. Geschossen hatte ich den Switch für unter 150 € als WHD bei Amazon Frankreich. Den 1. Port des Switches habe ich mit meinem restlichen Netz verbunden, so dass NAS und PC ins Intranet / Internet kommen. Darüber greifen aktuell auch die anderen Clients auf das NAS zu. Eventuell verbinde ich aber die restlichen 4 Ports des NAS als LA mit meinem Haupt-Switch (Zyxel GS1900-16). Das kommt aber denke ich erst zum Tragen, wenn die Kids eigene PCs haben. Sonst wüsste ich nicht wo da wirklich Engpässe entstehen könnten.
Jedenfalls lief es schon einige Tage exzellent:
Beim Hochladen kommen ich im Schnitt auf 300 MB/s. Sind halt nur 5400 rpm Platten. Ich freue mich schon auf den Tag wenn SSDs bezahlbarer werden.
Allerdings hatte ich trotzdem schon zwei Erlebnisse, die mich zum Wahnsinn getrieben haben:
1.) Der Synology Drive Server überlastet die Festplatten und drückt damit massiv die Transferrate (Lösung: Deinstalliert)
2.) Obwohl auf nur 6-monatigen Intervall eingestellt, startet doch eben glatt der erweiterte SMART Test und drückt damit die Transferrate auf unter 50 MB/s (Lösung: Abwarten ^^)
Beides kannst du hier nachlesen:
https://www.synology-forum.de/showthread.html?102816-Synology-Drive-überlastet-10G-Karte-in-DS1618
Jedenfalls möchte ich nie mehr ohne. Das ist so als hätte man eine 30TB große SATA SSD im Rechner
Interessant ist übrigens, dass wenn ich eine 1GB Testdatei 2x herunterlade, dass die beim 2. Mal direkt aus dem RAM des NAS kommt. So schnell kann man fast gar nicht den Screenshot machen
Zuletzt bearbeitet:
- Mitglied seit
- 10. Mai 2015
- Beiträge
- 9.139
- Punkte für Reaktionen
- 1.799
- Punkte
- 314
Vielen Dank für deine Infos und Praxisberichte, dass mit den 668 MB/s schaut doch schon sehr sehr gut aus.
Auch wenn es "nur" 5.400 upm HDDs sind, ich nehme an WD red, je mehr davon im SHR verbaut sind, desto schneller wird die Datenübertragung, da ja die ankommenden Daten auf die zur Verfügung stehenden Platten aufgeteilt werden.
Du könntest es aber auch mit dem NAS performance tester version 1.7 austesten welche Geschwindigkeiten du erreichen könntest:
http://www.808.dk/?code-csharp-nas-performance
Auch wenn es "nur" 5.400 upm HDDs sind, ich nehme an WD red, je mehr davon im SHR verbaut sind, desto schneller wird die Datenübertragung, da ja die ankommenden Daten auf die zur Verfügung stehenden Platten aufgeteilt werden.
Du könntest es aber auch mit dem NAS performance tester version 1.7 austesten welche Geschwindigkeiten du erreichen könntest:
http://www.808.dk/?code-csharp-nas-performance
Danke für das Tool. Das muss man aber richtig nutzen, in dem man die Dateigröße über der RAM-Größe wählt. Denn sonst hat man mit 350 MB/s write und 1000 MB/s read ziemliche mega Werte ^^
Die Realität ist mit 350 MB/s write und 400 MB/s read doch ein gutes Stück langsamer:
Aber zumindest weiß man, dass das NAS die volle Bandbreite liefern könnte. Es braucht eben "nur" die maximale RAM-Ausstattung und SSDs Ach ja, so sechs Micron 5200 Eco 8TB SSDs wären jetzt was Feines *träum*
Die Realität ist mit 350 MB/s write und 400 MB/s read doch ein gutes Stück langsamer:
Aber zumindest weiß man, dass das NAS die volle Bandbreite liefern könnte. Es braucht eben "nur" die maximale RAM-Ausstattung und SSDs
Ach ja, so sechs Micron 5200 Eco 8TB SSDs wären jetzt was Feines *träum*- Status
Kaffeautomat
Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.
Als Dankeschön schalten wir deinen Account werbefrei.
