9
Link Aggregation mit balance-rr (RoundRobin) mit Cisco Switch für max. Bandbreite?
Hi zusammen!
Eine Frage an die Cisco Experten:
Ich habe folgende Hardware:
- Cisco Catalyst 2960-S
- QNAP mit 2*1GB LAN
- Arch Linux Workstation
- Centos7 Backup Server
- Bandlaufwerk
- OpenWRT Router
- FritzBox für ClientWLAN und WAN
Ich würde das gerne folgendermaßen konfigurieren:
Der Vollständigkeit halber habe ich alles mit auf das Diagramm, auch wenn für die Frage nur alles hinter dem OpenWRT interessant ist.
Nun habe ich das Problem, dass der Switch zwar Link Aggregation kann, aber kein balance-rr unterstützt und ich somit nur max. 1GBits/s bekommen würde.
Mir geht es dabei in erster Linie darum, im inneren Netzwerk möglichst viel Bandbreite für das Arbeiten auf NFS Shares und für das wöchentliche Backup auf Band zu haben.
Das EtherChannel des Cisco bringt mich, zumindest so wie es überall beschrieben ist, dabei nicht weiter, da das die Bandbreite effektiv nur für mehrere Clients erhöht.
Das NAS und auch die Workstation können ja ohne Probleme mit balance-rr konfiguriert werden...
Nun die Preisfrage:
Kennt jemand eine Möglichkeit, das so mit dem Cisco zu realisieren?
Oder evtl. mit einer anderen Netzwerkkomponente?
Den Cisco hab ich halt schon rumliegen, aber wenn es damit absolut nicht machbar sein sollte bin ich auch für Alternativen offen!
Vielen Dank!
Eine Frage an die Cisco Experten:
Ich habe folgende Hardware:
- Cisco Catalyst 2960-S
- QNAP mit 2*1GB LAN
- Arch Linux Workstation
- Centos7 Backup Server
- Bandlaufwerk
- OpenWRT Router
- FritzBox für ClientWLAN und WAN
Ich würde das gerne folgendermaßen konfigurieren:
Der Vollständigkeit halber habe ich alles mit auf das Diagramm, auch wenn für die Frage nur alles hinter dem OpenWRT interessant ist.
Mir geht es dabei in erster Linie darum, im inneren Netzwerk möglichst viel Bandbreite für das Arbeiten auf NFS Shares und für das wöchentliche Backup auf Band zu haben.
Das EtherChannel des Cisco bringt mich, zumindest so wie es überall beschrieben ist, dabei nicht weiter, da das die Bandbreite effektiv nur für mehrere Clients erhöht.
Das NAS und auch die Workstation können ja ohne Probleme mit balance-rr konfiguriert werden...
Nun die Preisfrage:
Kennt jemand eine Möglichkeit, das so mit dem Cisco zu realisieren?
Oder evtl. mit einer anderen Netzwerkkomponente?
Den Cisco hab ich halt schon rumliegen, aber wenn es damit absolut nicht machbar sein sollte bin ich auch für Alternativen offen!
Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 319812
Url: https://administrator.de/contentid/319812
Printed on: April 19, 2024 at 17:04 o'clock
9 Comments
Latest comment
Guten Morgen,
mehr Bandbreite bedeutet 10Gbit/s besorgen.
Gruß
Anton
mehr Bandbreite bedeutet 10Gbit/s besorgen.
Gruß
Anton
1
Hi und danke für deine Antwort!
10GbE wär natürlich schön, liegt aber momentan leider nicht drin.
Vor allem, weil ich ja ALLES neu bräuchte.
Was mich ein bisschen ärgert, dei NAS kann balance-rr, die Workstation auch.
Nur Cisco meint, das nicht unterstützen zu müssen.
10GbE wär natürlich schön, liegt aber momentan leider nicht drin.
Vor allem, weil ich ja ALLES neu bräuchte.
Was mich ein bisschen ärgert, dei NAS kann balance-rr, die Workstation auch.
Nur Cisco meint, das nicht unterstützen zu müssen.
Was für eine Übertragungsrate hast du denn aktuell ? KOnfig der NAS wär noch interessant. Was für ne NAS und was für Platten .
Die Frage ist auch. WELCHES Link Aggregation du willst . Beim Addaptive Load Balancing brauchst am Switch nichts weiter einstellen .
Beim LACP ist das schon aufwändiger . Unsere Workstations arbeiten alle mit 1Gbit Anbindung und reicht selbst im CAD Bereich dicke.
Ausser unsere Backupstruktur haben wir nun auf 10GbE aufgerüstet.
Von daher ist es in erster Linie interessant wie perfomant dein aktuelles Netz ist und du die 1Gbit/s überhaupt ausnutzt, bevor du mit Link Aggregation und sowas anfängst.
Gruss
Die Frage ist auch. WELCHES Link Aggregation du willst . Beim Addaptive Load Balancing brauchst am Switch nichts weiter einstellen .
Beim LACP ist das schon aufwändiger . Unsere Workstations arbeiten alle mit 1Gbit Anbindung und reicht selbst im CAD Bereich dicke.
Ausser unsere Backupstruktur haben wir nun auf 10GbE aufgerüstet.
Von daher ist es in erster Linie interessant wie perfomant dein aktuelles Netz ist und du die 1Gbit/s überhaupt ausnutzt, bevor du mit Link Aggregation und sowas anfängst.
Gruss
1
Also, momentan hängt hinter dem OpenWRT nur die Workstation.
Einführung von NAS, Backup Server, Bandroboter und Switch plane ich eben grade.
Das NAS ist ein QNAP TS-509 Pro mit 5x2TB 7200RPM HDDs im Raid5.
BackupServer wird ein älterer DELL mit CentOS7 und wahrscheinlich Bacula.
Bandroboter ist auch ein älterer DELL, Ultrium 3 oder 4.
Aus meiner Workstation sollen alle drehenden Platten raus fliegen
und ich möchte dann teilweise auch direkt auf den NFS mounts arbeiten.
Mindestens einmal die Woche wird das NAS komplett auf Band gesichert.
Deswegen wollte ich im inneren Netzwerk so viel Bandbreite wie möglich haben.
Unter Linux hätte ich eben die Adapter zusammen gefasst im Mode 0 (balance-rr), um möglichst viel Bandbreite auch bei einzelnen Transfers zu haben.
Nur macht da wohl der Cisco Switch nicht mit. Den für LACP / IEEE 802.3ad zu konfigurieren wäre nicht das Problem, nur erhöht dfas nicht die Bandbreite zwischen einzelnen Geräten, da LoadBalancing nur per stream gemacht wird und nciht per Paket.
Ich hoffe nun eben, dass es eventuell Tricks gibt, um mit dem Cisco die Bandbreite so zu erhähen, dass es für meine Konfiguration hilfreich ist.
Gerade das Backup würde davon profitieren.
Und natürlich auch beim zwischenspeichern größerer Datenmengen, um diese lokal zu bearbeiten und dann wieder zurück aufs NAS zu schieben.
Ausserdem geht es auch ein bisschen ums Prinzip. Ich möchte halt soviel rausholen wie möglich.
Einführung von NAS, Backup Server, Bandroboter und Switch plane ich eben grade.
Das NAS ist ein QNAP TS-509 Pro mit 5x2TB 7200RPM HDDs im Raid5.
BackupServer wird ein älterer DELL mit CentOS7 und wahrscheinlich Bacula.
Bandroboter ist auch ein älterer DELL, Ultrium 3 oder 4.
Aus meiner Workstation sollen alle drehenden Platten raus fliegen
und ich möchte dann teilweise auch direkt auf den NFS mounts arbeiten.
Mindestens einmal die Woche wird das NAS komplett auf Band gesichert.
Deswegen wollte ich im inneren Netzwerk so viel Bandbreite wie möglich haben.
Unter Linux hätte ich eben die Adapter zusammen gefasst im Mode 0 (balance-rr), um möglichst viel Bandbreite auch bei einzelnen Transfers zu haben.
Nur macht da wohl der Cisco Switch nicht mit. Den für LACP / IEEE 802.3ad zu konfigurieren wäre nicht das Problem, nur erhöht dfas nicht die Bandbreite zwischen einzelnen Geräten, da LoadBalancing nur per stream gemacht wird und nciht per Paket.
Ich hoffe nun eben, dass es eventuell Tricks gibt, um mit dem Cisco die Bandbreite so zu erhähen, dass es für meine Konfiguration hilfreich ist.
Gerade das Backup würde davon profitieren.
Und natürlich auch beim zwischenspeichern größerer Datenmengen, um diese lokal zu bearbeiten und dann wieder zurück aufs NAS zu schieben.
Ausserdem geht es auch ein bisschen ums Prinzip. Ich möchte halt soviel rausholen wie möglich.
aber wenn es damit absolut nicht machbar sein sollte bin ich auch für Alternativen offen!
Der Satz entlockt einem schon ein gewisses Schmunzeln. Du hast einen Premium Switch zu dem es eigentlich keinerlei Steigerung mehr gibt bei Features und Funktionen und fragst nach einer Alternative....Nundenn....
Wie du ja sicherlich weisst sind im Ethernet Bereich Balancing Standards immer IEEE 802.3ad bezogen. Das ist der Standard auf dem alles beruht.
Ethernet bietet keinerlei garantierte Laufzeiten oder überhaupt die Garantie das Frames am anderen Ende ankommen, dafür gibt es Mechanismen im TCP/IP Protokoll nicht aber auf dem L2 Layer selber.
Folglich basieren alle L2 Balancing Verfahren immer auf einem Hashing... Das bedingt dann die Ethernet Technik als logische Konsequenz.
Damit ist aber auch klar das du zu Recht bemerkst das die Lastverteilung durch das Hashing auf Basis der Paketadressen niemals homogen ist. Damit muss man generell im Ethernetbereich leben.
Per Paket Round Robin ist also per se eine Utopie weil die Übertragungstechnik das nicht hergibt.
Das ist auch ein Grund warum dein Balanced RR auf dem Linux Server natürlich fehlschlagen musste.
Guckst du auch hier:
Netzwerk Management Server mit Raspberry Pi
Wichtig auch das du den Cisco zwingend in den LACP Modus versetzt, denn im Default arbeiten die Catalyst Switches mit Ciscos proprietärem PaGP. Damit würde jeder Link Aggregation Versuch mit non Cisco Equipment so oder so scheitern.
Was du machen kannst ist im Cisco den Hashing Algorithmus etwas zu tunen. Z.B. ihn auf IP Basis statt Mac Basis zu machen und den UDP und TCP Port in die Berechnung einzubeziehen.
Wunder darfst du allerdings bei sehr wenigen IP Adressen bzw. Clients da nicht erwarten. Es wird aber ein Balancing geben wenn auch nur wenig.
Du kannst dir das auchd em Cisco ja sehr einfach mal ansehen per SNMP wenn du die Portchannel Member mal über einen Tag oder über das Backup grafisch beobachtest.
Ein Tool mit dem das im Handumdrehen gemacht ist ist z.B. der SNMP Traffic Grapher:
http://leonidvm.chat.ru
http://www.wtcs.org/informant/stg.htm
Damit kannst du sehen wie granular und effizient die Verteilung in deinem Umfeld ist.
Ansonsten hilft nur eine "Fat Pipe" wie oben schon gesagt, sprich also der Sprung auf 10G.
1Zitat von @aqui:
Naja, PoE und Routing zwischen VLANs wär noch nice 2 have, das kann dieser leider nicht.aber wenn es damit absolut nicht machbar sein sollte bin ich auch für Alternativen offen!
Der Satz entlockt einem schon ein gewisses Schmunzeln. Du hast einen Premium Switch zu dem es eigentlich keinerlei Steigerung mehr gibt bei Features und Funktionen und fragst nach einer Alternative....Aber prinzipiell hast du Recht, das ist ein tolles Gerät. Aber wenn er das was ich brauche eben nicht unterstützt, dann ist es nur logisch auch Alternativen in Erwägung zu ziehen.
Was nützt mir ein Mercedes, wenn der Koferraum zu klein ist? Wäre man mit einem Fiat Transporter dann nicht besser bedient?
Ich werde ihn sehr wahrscheinlich trotzdem behalten. Muss nur einen Platz dafür suchen oder eine Box bauen.
So neben mir auf dem Schreibtisch ist er definitiv zu laut. Kam mir gar nicht so laut vor.
Nundenn....
Wie du ja sicherlich weisst sind im Ethernet Bereich Balancing Standards immer IEEE 802.3ad bezogen. Das ist der Standard auf dem alles beruht.
Ethernet bietet keinerlei garantierte Laufzeiten oder überhaupt die Garantie das Frames am anderen Ende ankommen, dafür gibt es Mechanismen im TCP/IP Protokoll nicht aber auf dem L2 Layer selber.
Folglich basieren alle L2 Balancing Verfahren immer auf einem Hashing... Das bedingt dann die Ethernet Technik als logische Konsequenz.
Damit ist aber auch klar das du zu Recht bemerkst das die Lastverteilung durch das Hashing auf Basis der Paketadressen niemals homogen ist. Damit muss man generell im Ethernetbereich leben.
Per Paket Round Robin ist also per se eine Utopie weil die Übertragungstechnik das nicht hergibt.
Wieso bieten es diverse NAS und auch allgemein der Linux Bonding Treiber dann an?Wie du ja sicherlich weisst sind im Ethernet Bereich Balancing Standards immer IEEE 802.3ad bezogen. Das ist der Standard auf dem alles beruht.
Ethernet bietet keinerlei garantierte Laufzeiten oder überhaupt die Garantie das Frames am anderen Ende ankommen, dafür gibt es Mechanismen im TCP/IP Protokoll nicht aber auf dem L2 Layer selber.
Folglich basieren alle L2 Balancing Verfahren immer auf einem Hashing... Das bedingt dann die Ethernet Technik als logische Konsequenz.
Damit ist aber auch klar das du zu Recht bemerkst das die Lastverteilung durch das Hashing auf Basis der Paketadressen niemals homogen ist. Damit muss man generell im Ethernetbereich leben.
Per Paket Round Robin ist also per se eine Utopie weil die Übertragungstechnik das nicht hergibt.
Es gibt auch Switches die das können, diverse von Mikrotik z.B.
Das ist auch ein Grund warum dein Balanced RR auf dem Linux Server natürlich fehlschlagen musste.
Guckst du auch hier:
Netzwerk Management Server mit Raspberry Pi
Sehr cooler Artikel!Guckst du auch hier:
Netzwerk Management Server mit Raspberry Pi
Wichtig auch das du den Cisco zwingend in den LACP Modus versetzt, denn im Default arbeiten die Catalyst Switches mit Ciscos proprietärem PaGP. Damit würde jeder Link Aggregation Versuch mit non Cisco Equipment so oder so scheitern.
Ja, LACP, bzw. channel mode active ist klar.Was du machen kannst ist im Cisco den Hashing Algorithmus etwas zu tunen. Z.B. ihn auf IP Basis statt Mac Basis zu machen und den UDP und TCP Port in die Berechnung einzubeziehen.
IP ja, Ports können die 2xxx leider nicht, nur die größeren.Wunder darfst du allerdings bei sehr wenigen IP Adressen bzw. Clients da nicht erwarten. Es wird aber ein Balancing geben wenn auch nur wenig.
Du kannst dir das auchd em Cisco ja sehr einfach mal ansehen per SNMP wenn du die Portchannel Member mal über einen Tag oder über das Backup grafisch beobachtest.
Ein Tool mit dem das im Handumdrehen gemacht ist ist z.B. der SNMP Traffic Grapher:
http://leonidvm.chat.ru
http://www.wtcs.org/informant/stg.htm
Damit kannst du sehen wie granular und effizient die Verteilung in deinem Umfeld ist.
Danke, muss ich mal schauen, ob ich das unter Linux MRTG zum Laufen bekomme.Du kannst dir das auchd em Cisco ja sehr einfach mal ansehen per SNMP wenn du die Portchannel Member mal über einen Tag oder über das Backup grafisch beobachtest.
Ein Tool mit dem das im Handumdrehen gemacht ist ist z.B. der SNMP Traffic Grapher:
http://leonidvm.chat.ru
http://www.wtcs.org/informant/stg.htm
Damit kannst du sehen wie granular und effizient die Verteilung in deinem Umfeld ist.
Für einzelne übertragungen sieht man auch an den LEDs ganz gut, welche Ports aktiv sind.
Ansonsten hilft nur eine "Fat Pipe" wie oben schon gesagt, sprich also der Sprung auf 10G.
Ist eben grade leider keine Option.Ich werde versuchen, die vorhandene Technik auszureizen.
Momentahn größter Flaschenhals ist die CPU der NAS, vor Allem beim Schreiben auf RAID, aber auch beim Lesen.
Interessant ist folgendes:
Den höchsten Durchsatz erreiche ich bis jetzt, wenn ich EtherChannel ohne Protokoll (mode on) konfiguriere und die Ports dann mit RoundRobin befeuere (Einstellung balance-rr an NAS und Workstation.
Dann sind laut LEDs auch alle Ports aktv bei der Übertragung.
So konnte ich über NFS lesend von Raid0 bei einer 10GB Datei im Durchschnitt 100MB/s erreichen.
Mehr Tests (Mit Feintuning des NFS z.B.) folgen nächste Woche, sobald ich CPU und RAM im NAS auf gerüstet habe.
Momentan ist der SingleCore Celeron echt ein Problem, er hat zwar HT aber das reisst hier nix.
Ein 3.06GHz Core2Duo sorgt dann für etwas mehr Dampf.
Config:
SWITCH:
#sh run
interface Port-channel2
description nas
!
interface Port-channel4
description workstation
!
interface GigabitEthernet0/1
channel-group 2 mode on
!
interface GigabitEthernet0/2
channel-group 2 mode on
!
interface GigabitEthernet0/5
channel-group 4 mode on
!
interface GigabitEthernet0/6
channel-group 4 mode on
!
interface GigabitEthernet0/7
channel-group 4 mode on
#sh etherchannel summary
Number of channel-groups in use: 2
Number of aggregators: 2
Group Port-channel Protocol Ports
------+-------------+-----------+-----------------------------------------------
2 Po2(SU) - Gi0/1(P) Gi0/2(P)
4 Po4(SU) - Gi0/5(P) Gi0/6(P) Gi0/7(P)
WORKSTATION:
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 50
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: enp0s25
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: bc:5f:f4:f8:b7:50
Slave queue ID: 0
Slave Interface: enp6s0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 98:de:d0:00:df:4e
Slave queue ID: 0
Slave Interface: enp7s0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 98:de:d0:01:31:1a
Slave queue ID: 0
# ifconfig
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 172.20.30.10 netmask 255.255.255.0 broadcast 172.20.30.255
inet6 fd0e:edc9:384:0:be5f:f4ff:fef8:b750 prefixlen 64 scopeid 0x0<global>
inet6 fe80::be5f:f4ff:fef8:b750 prefixlen 64 scopeid 0x20<link>
ether bc:5f:f4:f8:b7:50 txqueuelen 1000 (Ethernet)
RX packets 35963004 bytes 52226357377 (48.6 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 19834727 bytes 1510015749 (1.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp0s25: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether bc:5f:f4:f8:b7:50 txqueuelen 1000 (Ethernet)
RX packets 11727384 bytes 16929085983 (15.7 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10931167 bytes 4471166373 (4.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 20 memory 0xf3500000-f3520000
enp6s0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether bc:5f:f4:f8:b7:50 txqueuelen 1000 (Ethernet)
RX packets 20522348 bytes 25215302948 (23.4 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 10960814 bytes 4470486152 (4.1 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
enp7s0: flags=6211<UP,BROADCAST,RUNNING,SLAVE,MULTICAST> mtu 1500
ether bc:5f:f4:f8:b7:50 txqueuelen 1000 (Ethernet)
RX packets 33604003 bytes 48305181782 (44.9 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 21010487 bytes 16029613061 (14.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0PoE und Routing zwischen VLANs wär noch nice 2 have, das kann dieser leider nicht.
Mit einem externen Router kannst du das ja "nachrüsten" 
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
So neben mir auf dem Schreibtisch ist er definitiv zu laut.
So ein Gerät gehört ja auch in den Keller, mindestens aber in die Besenkammer wo ein Patchpanel ist was die Verdrahtung auf deine Doppeldosen im Haus hält !!Es gibt auch Switches die das können, diverse von Mikrotik z.B.
Das ist Blödsinn !Sorry aber diese basieren einzig und allein nur auf 802.3ad, und das ist ein standardtisiertes Balancing Verfahren über Hashes.
Das macht kein Switch hersteller der Welt anders...auch nicht Mikrotik.
Die Algorithmen zum Berechnen des Hashes variiert jeder Hersteller um die Granularität etwas zu erhöhen indem TCP oder UDP Ports mit eingerechnet werden mehr aber auch nicht.
Klar gibt es auch eine sessionbasierte Round Robin Verteilung so gut wir nur aber auf der Betreibssystem Seite.
Das ist dann aber nicht standardkonform und erzwingt auf der Switchseite dann statisches Link Aggregation bzw. die feste statische Zuweisung von Aggregation Ports.
LACP geht logischerweise nicht, denn das supportet die andere Seite nicht in Verbindung mit proprietären Balancing Verfahren.
Der gravierende Nachteil der daraus resultiert ist ein asymetrisches Balancing, denn Sessions auf OS Seite werden mit einem völlig anderen Verfahren verteilt als Sessions auf der Switch Seite.
Ob das vorteilhaft ist oder nicht für ein Netzwerk muss der Admin selber entscheiden. Ideal ist es wenigstens nicht. Von der Inhomogenität in Konfig und Administration mal erst gar nicht zu reden...
Abgesehen davon supporten nur die Premium Hersteller statische LAGs. Das Gros (>95%) der Billighersteller kann es gar nicht erst so das auch Gednaken über solche Konfig dann eh obsolet sind.
Hast du über diese Tatsachen auch mal nachgedacht ?!
ob ich das unter Linux MRTG zum Laufen bekomme.
Das ist mit den Ciscos ein Kinderspiel. Funktioniert sofort ! Das STG Tool macht das aber auch und es ist weniger Aufwand wenn man es nur mal temporär benutzen will.. Zudem kann man es mehrfach parallel starten so das man mehrere Ports gleichzeitig monitoren kann.wenn ich EtherChannel ohne Protokoll (mode on) konfiguriere
Das ist genau das Szenario von oben. Statische LAG Ports und das andere Ende macht Round Robin.Wäre auch in deiner Situation mit so wenig Endgeräten die technisch beste Lösung. Irgendwelche Asymetrien sind da völlig irrelevant. Sei froh das der Catalyst statische LAGs kann
1Zitat von @aqui:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Ja, wenn ich das benötige, nehme ich z.B. meinen OpenWRT. PoE und Routing zwischen VLANs wär noch nice 2 have, das kann dieser leider nicht.
Mit einem externen Router kannst du das ja "nachrüsten" VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
So neben mir auf dem Schreibtisch ist er definitiv zu laut.
So ein Gerät gehört ja auch in den Keller, mindestens aber in die Besenkammer wo ein Patchpanel ist was die Verdrahtung auf deine Doppeldosen im Haus hält !!Das ist aber auch nur mein Testaufbau momentan. Mir ist vorher nur nie aufgefallen, WIE laut der ist wenn man ihn dauerhaft neben sich hat.
Ich denke ich werde vom Büro aus hinter der Fußleiste in den Keller runter gehen und unten und oben jeweils ein 8x Patchpanel verbauen.
Dann kann der Switch zu Server und Bandroboter (die zwei machen noch viel mehr Krach) in den Keller.
Es gibt auch Switches die das können, diverse von Mikrotik z.B.
Das ist Blödsinn !Sorry aber diese basieren einzig und allein nur auf 802.3ad, und das ist ein standardtisiertes Balancing Verfahren über Hashes.
Das macht kein Switch hersteller der Welt anders...auch nicht Mikrotik.
Die Algorithmen zum Berechnen des Hashes variiert jeder Hersteller um die Granularität etwas zu erhöhen indem TCP oder UDP Ports mit eingerechnet werden mehr aber auch nicht.
Klar gibt es auch eine sessionbasierte Round Robin Verteilung so gut wir nur aber auf der Betreibssystem Seite.
Das ist dann aber nicht standardkonform und erzwingt auf der Switchseite dann statisches Link Aggregation bzw. die feste statische Zuweisung von Aggregation Ports.
LACP geht logischerweise nicht, denn das supportet die andere Seite nicht in Verbindung mit proprietären Balancing Verfahren.
Der gravierende Nachteil der daraus resultiert ist ein asymetrisches Balancing, denn Sessions auf OS Seite werden mit einem völlig anderen Verfahren verteilt als Sessions auf der Switch Seite.
Ob das vorteilhaft ist oder nicht für ein Netzwerk muss der Admin selber entscheiden. Ideal ist es wenigstens nicht. Von der Inhomogenität in Konfig und Administration mal erst gar nicht zu reden...
Abgesehen davon supporten nur die Premium Hersteller statische LAGs. Das Gros (>95%) der Billighersteller kann es gar nicht erst so das auch Gednaken über solche Konfig dann eh obsolet sind.
Hast du über diese Tatsachen auch mal nachgedacht ?!
Ja habe ich. Mir ist auch klar, dass die unterschiedlichen Laufzeiten der Pakete beim RR problematisch sein können. Das ist auch der Grund, warum Cisco das eigentlich nicht unterstützt, bzw. warum der Standard 802.3ad das nicht abdeckt.Der gravierende Nachteil der daraus resultiert ist ein asymetrisches Balancing, denn Sessions auf OS Seite werden mit einem völlig anderen Verfahren verteilt als Sessions auf der Switch Seite.
Ob das vorteilhaft ist oder nicht für ein Netzwerk muss der Admin selber entscheiden. Ideal ist es wenigstens nicht. Von der Inhomogenität in Konfig und Administration mal erst gar nicht zu reden...
Abgesehen davon supporten nur die Premium Hersteller statische LAGs. Das Gros (>95%) der Billighersteller kann es gar nicht erst so das auch Gednaken über solche Konfig dann eh obsolet sind.
Hast du über diese Tatsachen auch mal nachgedacht ?!
Aber genau deswegen mache ich ja die ganzen Tests
ob ich das unter Linux MRTG zum Laufen bekomme.
Das ist mit den Ciscos ein Kinderspiel. Funktioniert sofort ! Das STG Tool macht das aber auch und es ist weniger Aufwand wenn man es nur mal temporär benutzen will.. Zudem kann man es mehrfach parallel starten so das man mehrere Ports gleichzeitig monitoren kann.wenn ich EtherChannel ohne Protokoll (mode on) konfiguriere
Das ist genau das Szenario von oben. Statische LAG Ports und das andere Ende macht Round Robin.Wäre auch in deiner Situation mit so wenig Endgeräten die technisch beste Lösung. Irgendwelche Asymetrien sind da völlig irrelevant. Sei froh das der Catalyst statische LAGs kann
Ob die dann wirklich Paket basiertes RR machen,
Das ist technisch unmöglich, denn der Standard hat keinen Recovery Modus wenn es Laufzeit Problematiken gibt !Es geht immer und einzig nur Session basiertes Balancing.
Kein Hersteller auf der Welt weder Cisco noch irgend ein anderer macht bei einer Standard Ethernet Infrastruktur per Paket Balancing.
In der Router Welt gibts das mit MPPP (Multilink PPP) aber das ist eben Routing und kein Switching...ganz andere Baustelle also.
Einzig DCB oder Fabric basierende Switches (z.B. Brocade / Broadcom VDX) mit TRILL oder SPB können das innerhalb der Fabric aber niemals zur Ethernet Peripherie.
Mikrotik mein hier ganz sicher Session basierendes Round Robin was ja mit Static LAGs geht. Nur dumm wenn dann auf der anderen Seite jemand ist der keine static LAGs kann
Soviel zum Thema proprietäre Verfahren....
1
