Link aggregation und Synology
Hallo zusammen,
ich habe eine Synology älteren Baujahres (415+) und wollte mir darauf immer mal ein Bond einrichten.
Damit dies funktioniert, habe ich mir vor kurzem ein Netgear GS324T Switch zugelegt, der auch link aggregation (LAG) unterstützt.
Die Einrichtung ist theoretisch relativ einfach:
Synology: 802.3ad eingerichtet, feste IP 192.168.0.250
Switch: LAG Gruppe erstellt, aktuell Port 15&16 dafür konfiguriert, feste IP 192.168.0.254
Es funktioniert auch alles, bis zu einem gewissen Punkt.
Sobald ein paar Stunden kein Zugriff auf die Synology erfolgte (z.B. Nachts, auch Wochenende tagsüber wenn man unterwegs ist), ist sie über Netzwerk anschließend nicht mehr erreichbar. Auf die Netzlaufwerke kann nicht mehr zugegriffen werden und ein anpingen ist auch nicht mehr möglich. Auf dem Switch werden trotzdem beide Ports als "Up" angezeigt
Um den Betrieb wieder herzustellen, muss ich entweder kurz ein Kabel der LAG ziehen oder kurz z.B. Port 16 über den Switch deaktivieren. Kurz warten und ich kann alles wieder reinstecken oder aktivieren.
Folgendes Bereits getestet und überprüft:
-Kein Energiesparmodus etc. Die Synology dient nur als Netzwerkspeicher, ohne DHCP, Domain o.ä. Funktionen. Auch wurde sie vor 2~Monaten aufgrund von neuen Festplatten komplett neu aufgesetzt.
- Unterschiedliche Netzwerkports
- Unterschiedliche Firmwares des Switches
- Überprüfung der Protokolle, keine auffälligen Einträge auf dem Switch vorhanden
Switch Konfiguration (relativ der Werkseinstellung, nur die Port Beschriftung habe ich angepasst), ebenfalls i.O. (wurde durch meinen NetSec Arbeitskollegen geprüft)
- Prüfung der Protokolle der Synology kann ich nicht. Hierfür habe ich den Support kontaktiert, der mir allerdings nicht helfen kann(will).
Synology Support meinte ganz dreist "verwenden Sie ansonsten nur eine einzige NIC-Verbindung. Bitte wenden Sie sich an den Routerhersteller, um die richtige Konfiguration zu erhalten" (was auch immer jetzt meine FritzBox damit zu tun haben soll?) Und natürlich wurde mir erklärt wie ich ein Bond einzurichten habe und dass ich ein LAG fähigen Switch benötige. Die haben Quasi überhaupt nicht meinen Text gelesen...
Hat irgendjemand eine Idee wo noch der Fehler liegen könnte? Informationen kann ich bei Bedarf natürlich noch nachliefern...
Wenn jemand einen "besseren" Switch empfehlen könnte, würde ich dies natürlich auch annehmen.
Kriterien: ~24Port, lüfterlos und natürlich managed inkl. lag
Vielen Dank vorab
Gruß
ich habe eine Synology älteren Baujahres (415+) und wollte mir darauf immer mal ein Bond einrichten.
Damit dies funktioniert, habe ich mir vor kurzem ein Netgear GS324T Switch zugelegt, der auch link aggregation (LAG) unterstützt.
Die Einrichtung ist theoretisch relativ einfach:
Synology: 802.3ad eingerichtet, feste IP 192.168.0.250
Switch: LAG Gruppe erstellt, aktuell Port 15&16 dafür konfiguriert, feste IP 192.168.0.254
Es funktioniert auch alles, bis zu einem gewissen Punkt.
Sobald ein paar Stunden kein Zugriff auf die Synology erfolgte (z.B. Nachts, auch Wochenende tagsüber wenn man unterwegs ist), ist sie über Netzwerk anschließend nicht mehr erreichbar. Auf die Netzlaufwerke kann nicht mehr zugegriffen werden und ein anpingen ist auch nicht mehr möglich. Auf dem Switch werden trotzdem beide Ports als "Up" angezeigt
Um den Betrieb wieder herzustellen, muss ich entweder kurz ein Kabel der LAG ziehen oder kurz z.B. Port 16 über den Switch deaktivieren. Kurz warten und ich kann alles wieder reinstecken oder aktivieren.
Folgendes Bereits getestet und überprüft:
-Kein Energiesparmodus etc. Die Synology dient nur als Netzwerkspeicher, ohne DHCP, Domain o.ä. Funktionen. Auch wurde sie vor 2~Monaten aufgrund von neuen Festplatten komplett neu aufgesetzt.
- Unterschiedliche Netzwerkports
- Unterschiedliche Firmwares des Switches
- Überprüfung der Protokolle, keine auffälligen Einträge auf dem Switch vorhanden
Switch Konfiguration (relativ der Werkseinstellung, nur die Port Beschriftung habe ich angepasst), ebenfalls i.O. (wurde durch meinen NetSec Arbeitskollegen geprüft)
- Prüfung der Protokolle der Synology kann ich nicht. Hierfür habe ich den Support kontaktiert, der mir allerdings nicht helfen kann(will).
Synology Support meinte ganz dreist "verwenden Sie ansonsten nur eine einzige NIC-Verbindung. Bitte wenden Sie sich an den Routerhersteller, um die richtige Konfiguration zu erhalten" (was auch immer jetzt meine FritzBox damit zu tun haben soll?) Und natürlich wurde mir erklärt wie ich ein Bond einzurichten habe und dass ich ein LAG fähigen Switch benötige. Die haben Quasi überhaupt nicht meinen Text gelesen...
Hat irgendjemand eine Idee wo noch der Fehler liegen könnte? Informationen kann ich bei Bedarf natürlich noch nachliefern...
Wenn jemand einen "besseren" Switch empfehlen könnte, würde ich dies natürlich auch annehmen.
Kriterien: ~24Port, lüfterlos und natürlich managed inkl. lag
Vielen Dank vorab
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 623026
Url: https://administrator.de/contentid/623026
Ausgedruckt am: 24.11.2024 um 01:11 Uhr
10 Kommentare
Neuester Kommentar
ich hab genau dasselbe Problem, ich hab genau den gleichen Switch, dieselbe Konfiguration mit LAG auf Synology und Switch Seite.
Nur hab ich die DS414, also eine Gernation älter.
Die ist mir fast immer nach längeren Energiesparzuständen eingefroren, sie wachte nicht mehr auf, iSCSI Mountpunkte im ESX waren daraufhin weg, das Webinterface nicht ansprechbar, der SMB Share tot. nur ein Ping ging noch und die blaue Sleep LED. Drückte man den Schalter 5 sekunden lang, dann fing das Ding an schnell zu blinken und das dann auch tagelang.
Ausschalten ging nur über Netzstecker ziehen, danach wieder einachalten, Raid Check für ca. 50 Stunden (4x4 TB verbaut und auch fast voll)
Die Lösung war ein Upgrade auf die zweitneueste DSM Version 6.2.2, seitdem hab ich kein Streß mehr mit dem Einfrieren.
Natürlich hab ich acuh mal mit ein paar SSDs versucht, 2 GBit Datentransferrate hinzukriegen, aber seinerheit (2016) hat kein Microsoft Betriebsystem und auch keine ESX, kein HyperV das LAG so unterstützt daß beide Leitungen parallel benutzt wurden, ich hab mir nen Wolf gefummelt damit.
Am Ende kann die Ds414 auch nicht mehr als 100 MB/Sekunde Datendurchsatz im Raid 5 Betrieb... deshalb war mir LAG am Ende nicht wirklich wichtig.
Nur hab ich die DS414, also eine Gernation älter.
Die ist mir fast immer nach längeren Energiesparzuständen eingefroren, sie wachte nicht mehr auf, iSCSI Mountpunkte im ESX waren daraufhin weg, das Webinterface nicht ansprechbar, der SMB Share tot. nur ein Ping ging noch und die blaue Sleep LED. Drückte man den Schalter 5 sekunden lang, dann fing das Ding an schnell zu blinken und das dann auch tagelang.
Ausschalten ging nur über Netzstecker ziehen, danach wieder einachalten, Raid Check für ca. 50 Stunden (4x4 TB verbaut und auch fast voll)
Die Lösung war ein Upgrade auf die zweitneueste DSM Version 6.2.2, seitdem hab ich kein Streß mehr mit dem Einfrieren.
Natürlich hab ich acuh mal mit ein paar SSDs versucht, 2 GBit Datentransferrate hinzukriegen, aber seinerheit (2016) hat kein Microsoft Betriebsystem und auch keine ESX, kein HyperV das LAG so unterstützt daß beide Leitungen parallel benutzt wurden, ich hab mir nen Wolf gefummelt damit.
Am Ende kann die Ds414 auch nicht mehr als 100 MB/Sekunde Datendurchsatz im Raid 5 Betrieb... deshalb war mir LAG am Ende nicht wirklich wichtig.
Sehr häufig ist das der Energiespar Zustand des NAS. Das taktet dann auch die Port Speed runter ohne den Link zu unterbrechen. Fast alle Billigswitches kommen damit oft nicht klar und können dann keine Frames mehr forwarden die das NAS retriggern könnten aus dem Sparzustand. Ein Teufelskreis....
Das kann in seltenen Fällen auch passieren wenn der Switch sog. "Green Ethernet" Ports hat.
All das müsste (und muss) man deaktivieren sowohl auf NAS als ggf. auch auf Switch Seite.
Bei 802.3ad LACP LAGs werden immer beide Leitungen parallel benutzt. Allerdings mach der Standard bekanntlich ja ein Hashing über die Mac Adressen oder die IP Adressen oder beides. Sprich ein Kommunikationspärchen im Netz benutzt aufgrund ihrer IP/Mac Addr. immer fest nur einen physischen Link.
Bessere Switches rechnen in den Hash Wert noch den TCP/UDP Port mit rein, so das man eine größere Granularität bekommt und damit eine bessere Traffic Verteilung auf die einzelnen LAG Link Member.
Bei sehr wenig Entropie im Netz, also wenig Macs oder IPs oder z.B. einem gerouteten L3 Switch Switch Link der nur eine einzige Mac oder IP hat, ist die Verteilung auf die Links dann Prinzipien bedingt durch den Standard schlechter und niemals fifty fifty bzw. round robin also wie bei einem fiktiven per Paket Balancing.
Das lässt der .ad Standard aus den o.a. Gründen logischerweise technisch durch das Hashing Verfahren ja auch gar nicht zu.
In sofern ist deine Aussage also sachlich nicht richtig, denn alle OS supporten bekanntlich LACP LAGs uneingeschränkt !
Das kann in seltenen Fällen auch passieren wenn der Switch sog. "Green Ethernet" Ports hat.
All das müsste (und muss) man deaktivieren sowohl auf NAS als ggf. auch auf Switch Seite.
kein Microsoft Betriebsystem und auch keine ESX, kein HyperV das LAG so unterstützt daß beide Leitungen parallel benutzt wurden
Das ist natürlich technischer Unsinn oder du hast es technisch etwas ungeschickt ausgedrückt.Bei 802.3ad LACP LAGs werden immer beide Leitungen parallel benutzt. Allerdings mach der Standard bekanntlich ja ein Hashing über die Mac Adressen oder die IP Adressen oder beides. Sprich ein Kommunikationspärchen im Netz benutzt aufgrund ihrer IP/Mac Addr. immer fest nur einen physischen Link.
Bessere Switches rechnen in den Hash Wert noch den TCP/UDP Port mit rein, so das man eine größere Granularität bekommt und damit eine bessere Traffic Verteilung auf die einzelnen LAG Link Member.
Bei sehr wenig Entropie im Netz, also wenig Macs oder IPs oder z.B. einem gerouteten L3 Switch Switch Link der nur eine einzige Mac oder IP hat, ist die Verteilung auf die Links dann Prinzipien bedingt durch den Standard schlechter und niemals fifty fifty bzw. round robin also wie bei einem fiktiven per Paket Balancing.
Das lässt der .ad Standard aus den o.a. Gründen logischerweise technisch durch das Hashing Verfahren ja auch gar nicht zu.
In sofern ist deine Aussage also sachlich nicht richtig, denn alle OS supporten bekanntlich LACP LAGs uneingeschränkt !
Für die Connectivität ist der LAG Support zweifelsfrei da, schon ab Server 2008R2, nur wird da nichts schneller
Wenn ich also 2x1 GBit habe, eine SSD in der DS414 und messe effektiv an einer wie auch immer gestalteten Netzwerkbrücke nur 1 GBit mit einem Diskbenchmark oder Bandbreitentest, dann sind die Datenpakete nicht asynchron verschickt worden, sondern immer brav eins nach dem anderen. Mal eins links, mal eins rechts, aber nicht quasi gleichzeitig, sonst wäre es ja irgendwas zwischen 1 und 2 GBit effektiv geworden und nicht exakt 1 GBit pro Sekunde.
Wenn ich also 2x1 GBit habe, eine SSD in der DS414 und messe effektiv an einer wie auch immer gestalteten Netzwerkbrücke nur 1 GBit mit einem Diskbenchmark oder Bandbreitentest, dann sind die Datenpakete nicht asynchron verschickt worden, sondern immer brav eins nach dem anderen. Mal eins links, mal eins rechts, aber nicht quasi gleichzeitig, sonst wäre es ja irgendwas zwischen 1 und 2 GBit effektiv geworden und nicht exakt 1 GBit pro Sekunde.
Mal eins links, mal eins rechts,
Und genau DAS ist leider ein weit verbreiteter Irrglaube und ist technisch vollkommen falsch !Wie oben schon hinreichend erklärt wurde bestimmt der Hash über die Mac- oder IP Adresse zweier Kommunikationspartner im Netz fest welchen physischen LAG Link die nutzen. Pakete dieser Sessen gehen ALLESAMT immer fest über einen einzigen Link und niemals paketweise abwechselnd !
Round Robin Paket Balancing gibt es generell nicht im LACP LAG Standard ! Nur eine feste, Session basierte Verteilung auf die physischen Links.
Man kann das z.B. auch ganz einfach selber sehen sollte man managebare Switches haben die SNMP können. Mit einem simplen Zählen der Last an den Member Ports kann man das sehen:
RX Dropped Pkts Problem
Zitat von @Stauder:
Hallo zusammen,
ich habe eine Synology älteren Baujahres (415+)
[...]
Vielen Dank vorab
Gruß
Hallo zusammen,
ich habe eine Synology älteren Baujahres (415+)
[...]
Vielen Dank vorab
Gruß
Hallo,
kleiner side-kick:
Bei der 415+ gibt es den bekannten Intel-Bug
siehe z.B. https://www.golem.de/news/intel-c2000-weiter-unklarheit-zur-haeufung-von ...
Leider habe ich davon erst zu spät erfahren und die Kiste ist tatsächlich abgeraucht. Nichts ging mehr. Starts wurden immer abgebrochen. Ein Workaround ist das Einlöten eines 100 Ohm Widerstandes auf dem Mainboard und sicherheitshalber der Austausch der Batterie und neue Wärmeleitpaste auf den Prozessor zu geben. Soll angeblich auch vorsorglich helfen.
Meine persönliche private Bastelerfahrung an einem (dem) außerdienstgestellten defekten Gerät: es funktioniert.
Kosten:
- 5,- € für die Knopfzelle (Juwelierfachgeschäft vor Ort neben dem Supermarkt)
- 0 € für einen 100 Ohm Widerstand (Geschenk eines Elektronik-Ingenieurs aus der Nachbarschaft)
- 0 € für Wärmeleitpaste (lag noch im Regal)
- 35 € für ein 8GB RAM Modul (Ersatz für das 2 GB-Modul)
Zeit:
- 2h Recherche und Videos gucken
- ca. 45 min. fürs Auseinanderbauen, Löten und Zusammenbauen
Gruß
Hierfür muss es einen Grund geben.
Ja, einzig die Synology und deren Bug oder Fehlfunktion. Ist oben ja schon hinreichend erklärt worden. Das es der Switch nie sein kann ist auch klar.Case closed !
Wie kann ich einen Beitrag als gelöst markieren?