16
Ruckus ICX Stack mit ISSU oder MCT?
Hallo,
Ich habe hier zwei 7750-48F herumliegen und soll diese demnächst verbauen. Die beiden sollen eine redundate Core-/Aggregation-Ebene bilden. Derzeit nur Layer-2-Betrieb vorgesehen.
Einsatzzweck kurz und knapp beschrieben: Core, redundant, Access-Switches sollen alle per 1/10Gbit LWL und LAG angebunden werden, VLAN-Routing übernimmt eine vorgeschaltene entsprechend dimensionierte pfSense-Büchse.
Nun zur Frage, im Endeffekt schon aus dem Titel zu vernehmen: Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Meine Gedanken dazu:
Noch etwas das ich übersehe?
Gruß
Ich habe hier zwei 7750-48F herumliegen und soll diese demnächst verbauen. Die beiden sollen eine redundate Core-/Aggregation-Ebene bilden. Derzeit nur Layer-2-Betrieb vorgesehen.
Einsatzzweck kurz und knapp beschrieben: Core, redundant, Access-Switches sollen alle per 1/10Gbit LWL und LAG angebunden werden, VLAN-Routing übernimmt eine vorgeschaltene entsprechend dimensionierte pfSense-Büchse.
Nun zur Frage, im Endeffekt schon aus dem Titel zu vernehmen: Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Meine Gedanken dazu:
- tendiere eher zu MCT
- ISSU kann schief gehen, wenn die Firmware einen Bug hat, dann würde gesamter Stack unter Umständen nicht mehr laufen
- Konfiguration von MCT etwas umfangreicher, aber voll im Rahmen
Noch etwas das ich übersehe?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3441869040
Url: https://administrator.de/forum/ruckus-icx-stack-mit-issu-oder-mct-3441869040.html
Ausgedruckt am: 22.12.2024 um 09:12 Uhr
16 Kommentare
Neuester Kommentar
Stacking hat hier Vorteile. MCT ist lediglich nur eine virtuelle LACP LAG Redundanz aber kein Fullstack.
Damit ist dann ISSU möglich aber einzeln pro Core und nicht als ein Prozess was nur mit Stacking bzw. horizontal Stacking klappt wenn du damit beide Geräte meinst.
Bei MCT agieren die Geräte sowohl im L2 (außer LACP LAG) als auf im L3 weiter als 2 physisch getrennte Switches und du müsstest beide dann immer einzeln updaten was bei einem Fullstack nicht der Fall ist.
Deine Sorgen sind übrigens unbegründet. Auch im Stacking verlierst du ja niemals den Primary und Secondary Flash. Du kannst also auch da immer wieder auf die alte Version zurück wenn du das Update intelligent machst.
Einfache Logik... 😉
Achte darauf das du auf das latest recommendete Patch Release gehst bevor du in Produktion gehst! Aktuell ist derzeit 08.0.95g (g Patch)
Damit ist dann ISSU möglich aber einzeln pro Core und nicht als ein Prozess was nur mit Stacking bzw. horizontal Stacking klappt wenn du damit beide Geräte meinst.
Bei MCT agieren die Geräte sowohl im L2 (außer LACP LAG) als auf im L3 weiter als 2 physisch getrennte Switches und du müsstest beide dann immer einzeln updaten was bei einem Fullstack nicht der Fall ist.
Deine Sorgen sind übrigens unbegründet. Auch im Stacking verlierst du ja niemals den Primary und Secondary Flash. Du kannst also auch da immer wieder auf die alte Version zurück wenn du das Update intelligent machst.
Einfache Logik... 😉
Achte darauf das du auf das latest recommendete Patch Release gehst bevor du in Produktion gehst! Aktuell ist derzeit 08.0.95g (g Patch)
1
Frage beantwortet sich doch von allein. MCT.
Nun hast du schon Hardware die sowas kann, dann sollte es auch konfiguriert werden. Dauert auch nur zwei Minuten.
Stapeln kann man 300 Euro Switches. Die Hersteller können das Feature richtig zur Kasse bitten. Zu Recht, es lässt grundsätzliche Probleme und Limitierungen nicht aufkommen.
Und zum Routen eigenen sich die Switches ebenfalls vorzüglich.
Nun hast du schon Hardware die sowas kann, dann sollte es auch konfiguriert werden. Dauert auch nur zwei Minuten.
Stapeln kann man 300 Euro Switches. Die Hersteller können das Feature richtig zur Kasse bitten. Zu Recht, es lässt grundsätzliche Probleme und Limitierungen nicht aufkommen.
Und zum Routen eigenen sich die Switches ebenfalls vorzüglich.
Zwei Kommentare, zwei völlig gegensetzliche Meinungen.
Die Frage beantwortet sich doch von selbst: Wenn sie MCL können, dann gibt es gar keinen Grund etwas anders zu konfigurieren.
Hallo,
am Start sind dann nimm die auch für das LAN (VLAN) Routing (L3). Die sind mittels 3 x 40 GBit/s an der
Rückwand fett angebunden und die pfSense Firewall ist dann eben "nur" für das WAN Routing zuständig.
Single-Tier MCT Architecture
Use the Ruckus ICX 7850-48F or ICX 7850-48FS as the MCT cluster device
MCT clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, ICX 7650, and ICX 7750 switches
Two-Tier MCT Architecture
Use the Ruckus ICX 7850-32Q or ICX 7850-48FS as MCT Cluster 1
Use the Ruckus ICX 7850-48F as MCT Cluster A and Cluster B, or use the Ruckus ICX 7750 to lower the cost
Clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, and ICX 7650 switches
Ruckus Multi-Chassis-Trunking
Dobby
Die beiden sollen eine redundate Core-/Aggregation-Ebene bilden. Derzeit nur Layer-2-Betrieb vorgesehen.
Die haben doch an der Rückseite sechs 40 GBit/s Ports zum Stapeln oder? Ruckus ICX-7750-48F Stacking Beispiel Nimm die doch einfach dazu und gut ist es. Besser kannst Du es beinahe nicht haben!VLAN-Routing übernimmt eine vorgeschaltene entsprechend dimensionierte pfSense-Büchse.
Das würde ich auf gar keinen Fall machen wollen! Also wenn schon Campus Switche mit "volle Pulle Karacho"am Start sind dann nimm die auch für das LAN (VLAN) Routing (L3). Die sind mittels 3 x 40 GBit/s an der
Rückwand fett angebunden und die pfSense Firewall ist dann eben "nur" für das WAN Routing zuständig.
Nun zur Frage, im Endeffekt schon aus dem Titel zu vernehmen:
Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer
sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Welche Switche hast Du und was kann man damit machen.Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer
sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Single-Tier MCT Architecture
Use the Ruckus ICX 7850-48F or ICX 7850-48FS as the MCT cluster device
MCT clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, ICX 7650, and ICX 7750 switches
Two-Tier MCT Architecture
Use the Ruckus ICX 7850-32Q or ICX 7850-48FS as MCT Cluster 1
Use the Ruckus ICX 7850-48F as MCT Cluster A and Cluster B, or use the Ruckus ICX 7750 to lower the cost
Clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, and ICX 7650 switches
Ruckus Multi-Chassis-Trunking
Dobby
Zitat von @108012:
Hallo,
am Start sind dann nimm die auch für das LAN (VLAN) Routing (L3). Die sind mittels 3 x 40 GBit/s an der
Rückwand fett angebunden und die pfSense Firewall ist dann eben "nur" für das WAN Routing zuständig.
Single-Tier MCT Architecture
Use the Ruckus ICX 7850-48F or ICX 7850-48FS as the MCT cluster device
MCT clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, ICX 7650, and ICX 7750 switches
Two-Tier MCT Architecture
Use the Ruckus ICX 7850-32Q or ICX 7850-48FS as MCT Cluster 1
Use the Ruckus ICX 7850-48F as MCT Cluster A and Cluster B, or use the Ruckus ICX 7750 to lower the cost
Clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, and ICX 7650 switches
Ruckus Multi-Chassis-Trunking
Dobby
Hallo,
Die beiden sollen eine redundate Core-/Aggregation-Ebene bilden. Derzeit nur Layer-2-Betrieb vorgesehen.
Die haben doch an der Rückseite sechs 40 GBit/s Ports zum Stapeln oder? Ruckus ICX-7750-48F Stacking Beispiel Nimm die doch einfach dazu und gut ist es. Besser kannst Du es beinahe nicht haben!VLAN-Routing übernimmt eine vorgeschaltene entsprechend dimensionierte pfSense-Büchse.
Das würde ich auf gar keinen Fall machen wollen! Also wenn schon Campus Switche mit "volle Pulle Karacho"am Start sind dann nimm die auch für das LAN (VLAN) Routing (L3). Die sind mittels 3 x 40 GBit/s an der
Rückwand fett angebunden und die pfSense Firewall ist dann eben "nur" für das WAN Routing zuständig.
Nun zur Frage, im Endeffekt schon aus dem Titel zu vernehmen:
Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer
sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Welche Switche hast Du und was kann man damit machen.Ist es besser auf Stacking zu gehen und bei Fimware Upgrades mit ISSU zu arbeiten oder auf Nummer
sicher gehen und auf MCT (Multi-Chassis Trunking) setzen?
Single-Tier MCT Architecture
Use the Ruckus ICX 7850-48F or ICX 7850-48FS as the MCT cluster device
MCT clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, ICX 7650, and ICX 7750 switches
Two-Tier MCT Architecture
Use the Ruckus ICX 7850-32Q or ICX 7850-48FS as MCT Cluster 1
Use the Ruckus ICX 7850-48F as MCT Cluster A and Cluster B, or use the Ruckus ICX 7750 to lower the cost
Clients can be Ruckus ICX 7150, ICX 7250, ICX 7450, and ICX 7650 switches
Ruckus Multi-Chassis-Trunking
Dobby
Das Problem ist, das ich zwischen den VLANs umfangreich filtere. Das ist über die CLI etwas sehr aufwendig bei Ruckus ICX. Wenn ich nur plump paar VLANs routen müsste, einfach um das Netz zu skalieren, würde ich ebenfalls die Switches als Router verwenden.
Meist du die Switche die jetzt eingebaut werden sollen? Das sind ICX7750-48F-E2.
Leider hab ich hier drei Hersteller im Haus. Für Access-Ebene meist Cisco (SG300, SG350X und SG200) und Mikrotik, selten mal ein ICX7150 oder ICX7250. Für ganz kleine Außenstellen oder Räume wo unterverteilt werden muss, sitzen dann auch mal Netgear-Schrippen in irgendeiner Ecke. Also sogar vier Hersteller. Die sind halt noch aus vergangenen Zeiten. Das wird auch leider immer nur gestückelt ausgetauscht, so wie immer gerade Geld locker gemacht wird oder überhaupt etwas lieferbar ist.
Zukünftig will ich es auf insgesamt zwei Hersteller beschränken. Alleine das ist schon eine Herausforderung.
Mein Ziel ist es mittelfristig nur noch maximal zwei Hersteller im Hause zu haben. Ruckus und Mikrotik.
1
@aqui:
Du demonstrierst zum wiederholten Mal, dass Du vor allzu pauschalen und deshalb inhaltlichen oft zweifelhaften Empfehlungen auch dann nicht zurückschreckst, wenn Du von der Materie keine Ahnung oder zumindest die Problemlage nicht verstanden hast. Leider lassen sich viele unbedarfte Forenteilnehmer davon blenden, dass Du Deine "Weissheiten" mit einem überbordenden Brustton der Überzeugung vorträgst. Wünschenswert wäre statt dessen aber ein Überzeugen durch nachvollziehbare Expertise!
Es wurde hier (von anderen) bereits mehrfach versucht, Dir näher zu bringen, dass Stacking nicht nur Vorteile, sondern auch evidente Nachteile hat. Bei einem vernunftbegabten Menschen sollte dies irgendwann dazu führen, dass man die eigene Position mal kritisch hinterfragt und sich mit den Argumenten der Gegenseite inhaltlich auseinandersetzt.
@Fenris14:
Wie immer im Leben erfordert die Entscheidung ein Abwägen zwischen Vor- und Nachteilen. Nicht selten ist es die sprichwörtliche Wahl zwischen "Pest und Cholera".
Mit dem, was Du bislang dargelegt hast, könnte ich mit reinem Gewissen noch keine Empfehlung geben. Deshalb nur ein paar grundsätzliche Erwägungen von mir:
Wenn ständige Verfügbarkeit und Wiederstandsfähigkeit des Systems höchste Priorität haben, dann wäre Stacking eher nicht das Mittel der Wahl - und zwar nicht nur, weil Firmwareupdates nicht in allen Konstellationen ohne Serviceunterbrechung möglich sind.
Redundanz und Verfügbarkeit lassen sich auch mittels Techniken wie MCT, STP, VRRP usw. erreichen, ohne dass man sich die Nachteile einer gemeinsamen Control-Plane wie beim Stacking einhandeln müsste. Dafür steigt aber leider die Komplexität - insbesondere bei einer L3-Konfiguration mit mehreren Routing-Instanzen (VRF). Bei einem relativ statischen System ohne häufige Konfigurationsänderungen würde ich mich hiervon aber nicht abschrecken lassen.
Wenn das System im operativen Betrieb hingegen häufiger Änderungen unterliegt, welche zudem vielleicht noch durch relativ unerfahrendes Personal des Kunden selbst durchgeführt werden sollen und im Zweifel ein wirklich mal unumgängliches Firmwareupdate eine kurze Downtime hervorrufen darf, dann würde ich zum Stacking tendieren, denn dann überwiegen die Vorteile der hieraus folgenden Komplexitätsreduktion.
Gruß
sk
Du demonstrierst zum wiederholten Mal, dass Du vor allzu pauschalen und deshalb inhaltlichen oft zweifelhaften Empfehlungen auch dann nicht zurückschreckst, wenn Du von der Materie keine Ahnung oder zumindest die Problemlage nicht verstanden hast. Leider lassen sich viele unbedarfte Forenteilnehmer davon blenden, dass Du Deine "Weissheiten" mit einem überbordenden Brustton der Überzeugung vorträgst. Wünschenswert wäre statt dessen aber ein Überzeugen durch nachvollziehbare Expertise!
Es wurde hier (von anderen) bereits mehrfach versucht, Dir näher zu bringen, dass Stacking nicht nur Vorteile, sondern auch evidente Nachteile hat. Bei einem vernunftbegabten Menschen sollte dies irgendwann dazu führen, dass man die eigene Position mal kritisch hinterfragt und sich mit den Argumenten der Gegenseite inhaltlich auseinandersetzt.
@Fenris14:
Wie immer im Leben erfordert die Entscheidung ein Abwägen zwischen Vor- und Nachteilen. Nicht selten ist es die sprichwörtliche Wahl zwischen "Pest und Cholera".
Mit dem, was Du bislang dargelegt hast, könnte ich mit reinem Gewissen noch keine Empfehlung geben. Deshalb nur ein paar grundsätzliche Erwägungen von mir:
Wenn ständige Verfügbarkeit und Wiederstandsfähigkeit des Systems höchste Priorität haben, dann wäre Stacking eher nicht das Mittel der Wahl - und zwar nicht nur, weil Firmwareupdates nicht in allen Konstellationen ohne Serviceunterbrechung möglich sind.
Redundanz und Verfügbarkeit lassen sich auch mittels Techniken wie MCT, STP, VRRP usw. erreichen, ohne dass man sich die Nachteile einer gemeinsamen Control-Plane wie beim Stacking einhandeln müsste. Dafür steigt aber leider die Komplexität - insbesondere bei einer L3-Konfiguration mit mehreren Routing-Instanzen (VRF). Bei einem relativ statischen System ohne häufige Konfigurationsänderungen würde ich mich hiervon aber nicht abschrecken lassen.
Wenn das System im operativen Betrieb hingegen häufiger Änderungen unterliegt, welche zudem vielleicht noch durch relativ unerfahrendes Personal des Kunden selbst durchgeführt werden sollen und im Zweifel ein wirklich mal unumgängliches Firmwareupdate eine kurze Downtime hervorrufen darf, dann würde ich zum Stacking tendieren, denn dann überwiegen die Vorteile der hieraus folgenden Komplexitätsreduktion.
Gruß
sk
Das ist absolut richtig das alles 2 Seiten hat, keine Frage. Deshalb gibt es ja auch solche besonnenen Forenteilnehmer wie dich die dann auch sachlich korrekt beide Seiten betrachten und Vor- und Nachteile abwägen. Genau das was ein Forum ja ausmacht! Schade das du deine Anmerkungen dann mit unangebrachten Beleidigungen koppelst nach dem Motto mache andere klein damit du selbst groß bist, aber nundenn. Manchmal ist man halt Hund und manchmal Eiche....in einem Forum hält man sowas auch aus.
Zugegebenermaßen ist die Antwort oben auch schlecht und zu euphorisch formuliert, weil sie einzig nur auf die FW Upgrade Prozedur abzielte die nur ein kleiner Teilaspekt dieser Thematik ist. Das war natürlich kurzsichtig.
Die Beschreibung des TOs ist eben nicht zielgerichtet auf das was ihm wichtig ist und es hatte den Anschein das ISSU und Failoverzeit für ihn die Hauptintention ist und da hat Full Stacking eben leichte Vorteile in einem horizontal Stack. MLAG Lösungen gehen eben immer mit einem größeren Konfig Aufwand einher da es L3 Redundanzen erfordert (HSRP, VRRP) usw. Richtige Spanning Tree Anforderungen tun ein Übriges. Du hast es ja oben alles schon genau und ausführlich geschildert.
Zugegebenermaßen ist die Antwort oben auch schlecht und zu euphorisch formuliert, weil sie einzig nur auf die FW Upgrade Prozedur abzielte die nur ein kleiner Teilaspekt dieser Thematik ist. Das war natürlich kurzsichtig.
Die Beschreibung des TOs ist eben nicht zielgerichtet auf das was ihm wichtig ist und es hatte den Anschein das ISSU und Failoverzeit für ihn die Hauptintention ist und da hat Full Stacking eben leichte Vorteile in einem horizontal Stack. MLAG Lösungen gehen eben immer mit einem größeren Konfig Aufwand einher da es L3 Redundanzen erfordert (HSRP, VRRP) usw. Richtige Spanning Tree Anforderungen tun ein Übriges. Du hast es ja oben alles schon genau und ausführlich geschildert.
Jetzt sind "Spanning Tree Problematiken" zu erwarten?
Genau deshalb ist Multi Chassis Blabla erste Wahl, weil es keine STP Problematiken gibt, wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Es wurde auch niemand beleidigt nur nett mitgeteilt, dass jemand charakterliche Probleme hat und keine Ahnung.
Genau deshalb ist Multi Chassis Blabla erste Wahl, weil es keine STP Problematiken gibt, wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Es wurde auch niemand beleidigt nur nett mitgeteilt, dass jemand charakterliche Probleme hat und keine Ahnung.
MCT ist active/active mit load balancing (wenn man möchte) und failover falls ein Kabel oder Switch defekt sind.
Bei MCT gibt es zwei Versionen, Single TIER und Two TIER, single Tier kann hier nicht zum Einsatz kommen!
Und bei Two Tier braucht man unbedingt Switche der Firma Ruckus mit die das auch unterstützen!
an den Core anschließen und nur die Core Switche mittels der Ports an der Rückseite verbinden (stapeln).
davon betroffen, je mehr Routingpunkte Du hast um so weniger schadet der Ausfall eines davon!
Selbst in einem Stapel (Ring) wenn ein Switch ausfällt und alle Layer3 sind übernimmt immer ein
anderer Switch die Masterfunktion.
Dobby
Bei MCT gibt es zwei Versionen, Single TIER und Two TIER, single Tier kann hier nicht zum Einsatz kommen!
Und bei Two Tier braucht man unbedingt Switche der Firma Ruckus mit die das auch unterstützen!
Jetzt sind "Spanning Tree Problematiken" zu erwarten?
Wenn @fenris aber Switche von sehr vielen unterschiedlichen Herstellern hat, kann er diese nur mittels LAGan den Core anschließen und nur die Core Switche mittels der Ports an der Rückseite verbinden (stapeln).
Genau deshalb ist Multi Chassis Blabla erste Wahl, weil es keine STP Problematiken gibt,
wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Nur eben mit den Switche von Ruckus und selbst die müssen kompatible zueinander (untereinander) sein.wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Es wurde auch niemand beleidigt nur nett mitgeteilt, dass jemand charakterliche Probleme hat und keine Ahnung.
Weil jemand eine andere Meinung vertritt sagt das noch lange nichts über seinen Charakter und/oder seinen Wissenstand aus. (Meine Meinung dazu)Das Problem ist, das ich zwischen den VLANs umfangreich filtere.
Wenn Du nur einen Routingpunkt hast und der fällt Dir (Euch) dann einmal aus, ist das ganze Netzwerkdavon betroffen, je mehr Routingpunkte Du hast um so weniger schadet der Ausfall eines davon!
Selbst in einem Stapel (Ring) wenn ein Switch ausfällt und alle Layer3 sind übernimmt immer ein
anderer Switch die Masterfunktion.
Das ist über die CLI etwas sehr aufwendig bei Ruckus ICX. Wenn ich nur plump paar VLANs routen müsste,
einfach um das Netz zu skalieren, würde ich ebenfalls die Switches als Router verwenden.
Der hat aber die Power und ein Webinterface ist auch vorhanden.einfach um das Netz zu skalieren, würde ich ebenfalls die Switches als Router verwenden.
Dobby
1Zitat von @108012:
MCT ist active/active mit load balancing (wenn man möchte) und failover falls ein Kabel oder Switch defekt sind.
Bei MCT gibt es zwei Versionen, Single TIER und Two TIER, single Tier kann hier nicht zum Einsatz kommen!
Und bei Two Tier braucht man unbedingt Switche der Firma Ruckus mit die das auch unterstützen!
an den Core anschließen und nur die Core Switche mittels der Ports an der Rückseite verbinden (stapeln).
davon betroffen, je mehr Routingpunkte Du hast um so weniger schadet der Ausfall eines davon!
Selbst in einem Stapel (Ring) wenn ein Switch ausfällt und alle Layer3 sind übernimmt immer ein
anderer Switch die Masterfunktion.
Dobby
MCT ist active/active mit load balancing (wenn man möchte) und failover falls ein Kabel oder Switch defekt sind.
Bei MCT gibt es zwei Versionen, Single TIER und Two TIER, single Tier kann hier nicht zum Einsatz kommen!
Und bei Two Tier braucht man unbedingt Switche der Firma Ruckus mit die das auch unterstützen!
Jetzt sind "Spanning Tree Problematiken" zu erwarten?
Wenn @fenris aber Switche von sehr vielen unterschiedlichen Herstellern hat, kann er diese nur mittels LAGan den Core anschließen und nur die Core Switche mittels der Ports an der Rückseite verbinden (stapeln).
Genau deshalb ist Multi Chassis Blabla erste Wahl, weil es keine STP Problematiken gibt,
wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Nur eben mit den Switche von Ruckus und selbst die müssen kompatible zueinander (untereinander) sein.wenn Hersteller ordentlich arbeitet und Betreiber richtig konfiguriert.
Es wurde auch niemand beleidigt nur nett mitgeteilt, dass jemand charakterliche Probleme hat und keine Ahnung.
Weil jemand eine andere Meinung vertritt sagt das noch lange nichts über seinen Charakter und/oder seinen Wissenstand aus. (Meine Meinung dazu)Das Problem ist, das ich zwischen den VLANs umfangreich filtere.
Wenn Du nur einen Routingpunkt hast und der fällt Dir (Euch) dann einmal aus, ist das ganze Netzwerkdavon betroffen, je mehr Routingpunkte Du hast um so weniger schadet der Ausfall eines davon!
Selbst in einem Stapel (Ring) wenn ein Switch ausfällt und alle Layer3 sind übernimmt immer ein
anderer Switch die Masterfunktion.
Das ist über die CLI etwas sehr aufwendig bei Ruckus ICX. Wenn ich nur plump paar VLANs routen müsste,
einfach um das Netz zu skalieren, würde ich ebenfalls die Switches als Router verwenden.
Der hat aber die Power und ein Webinterface ist auch vorhanden.einfach um das Netz zu skalieren, würde ich ebenfalls die Switches als Router verwenden.
Dobby
Das ist natürlich ein Punkt. Zurzeit wäre in diesem Konstrukt die pfSense ein SPoF. Unabhängig vom Einbau der Switche, ist dort aber ebenfalls eine Erweiterung geplant. Ich mache hier viel mit Hairpinning, da wird kaum etwas dem Zufall überlassen. Das alles in der CLI oder auf dem alten Webinterface (das neue habe ich in Sachen Routing nicht probiert) einzugeben, dürfte eine Monats-Aufgabe werden.
Derzeit wäre bei einem Ausfall der Austausch aber innerhalb von Minuten erledigt. Vergleichbare Hardware wäre vorhanden:
- pfSense-Image aufspielen
- letzte Config hochladen und restore
- ggfs. Netzwerkschnittstellen mappen
@Fenris14: die pfSense muss ja kein SPoF bleiben. Die kann man sicherlich auch redundant auslegen.
@108012: bzgl. der Architekturen Single-Tier vs. Two-Tier liest Du besser nochmal Deine eigenen Quellen und überlegst, worum es bei diesen Designkonzepten geht
@108012: bzgl. der Architekturen Single-Tier vs. Two-Tier liest Du besser nochmal Deine eigenen Quellen und überlegst, worum es bei diesen Designkonzepten geht
Die kann man sicherlich auch redundant auslegen.
Thema CARP: https://docs.netgate.com/pfsense/en/latest/recipes/high-availability.htm ...Zumindestens mit einem LACP LAG anbinden.
Ich werde doch jetzt mal zwei Wochen Tests dran hängen und beide Varianten durchspielen, am besten gleich mit Routing und Filtering. Im Endeffekt wäre die pfSense der Falschenhals des Netzwerks. Sie hat zwar 10Gbit SFP+ Anschlüsse, aber das Problem durch die vielen Filter-Regeln bricht der Durchsatz auch sehr stark ein. Was auch logisch ist.
Gerade in der Nacht mal getestet. Ich komme nach aktuellen Stand auf einen Durchsatz bei Inter-VLAN-Kommunikation mit Iperf auf maximal ca 7 Gbit/s. Trotz Xeon D-2100 mit acht Kernen und 32Gb RAM. Zwar vermeide ich in meinem Design prinzipiell große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora der Phantomschmerzen will ich mir nicht öffnen.
Gerade in der Nacht mal getestet. Ich komme nach aktuellen Stand auf einen Durchsatz bei Inter-VLAN-Kommunikation mit Iperf auf maximal ca 7 Gbit/s. Trotz Xeon D-2100 mit acht Kernen und 32Gb RAM. Zwar vermeide ich in meinem Design prinzipiell große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora der Phantomschmerzen will ich mir nicht öffnen.
Im Endeffekt wäre die pfSense der Falschenhals des Netzwerks.
Aber nicht Deine 8 Core Variante! Die Intel Xeon D-2100 mit 8 Cores gehen alle durchgehend bis 3,00 GHzdas reicht dicke für 10 GBit/s Verbindungen, aber wenn man noch 15 Pakete am laufen hat und zwei davon
mit wirklich vielen Rules oder Listen (Snort oder Suricata & pfBlocker-ng) kann das auch mal etwas langsamer
anmuten.
Sie hat zwar 10Gbit SFP+ Anschlüsse, aber das Problem durch die vielen Filter-Regeln bricht der Durchsatz
auch sehr stark ein. Was auch logisch ist.
Bei 10 GBit/s bekommst Du (Wir alle) in der Regel und im realen Leben bzw. Einsatz nicht die ganzenauch sehr stark ein. Was auch logisch ist.
10 GBit/s zu "sehen".
- messen um die 9,60 GBit/s
- mit mehreren VLANs um die ~7,00 GBit/s
- Normaler Netzwerkverkehr um die 4,6 GBit/s
- mit DPI, MacSec und Radius zusammen um die ~ 2,0 GBit/s
Gerade in der Nacht mal getestet. Ich komme nach aktuellen Stand auf einen Durchsatz bei Inter-VLAN-
Kommunikation mit Iperf auf maximal ca 7 Gbit/s.
Das ist nicht weniger und nicht mehr als andere Benutzer u.a. im pfSense Forum behaupten zu messen.Kommunikation mit Iperf auf maximal ca 7 Gbit/s.
Trotz Xeon D-2100 mit acht Kernen und 32Gb RAM. Zwar vermeide ich in meinem Design prinzipiell
große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora
der Phantomschmerzen will ich mir nicht öffnen.
Und die pfSense läuft nur als VM drauf?große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora
der Phantomschmerzen will ich mir nicht öffnen.
Dobby
Zitat von @108012:
das reicht dicke für 10 GBit/s Verbindungen, aber wenn man noch 15 Pakete am laufen hat und zwei davon
mit wirklich vielen Rules oder Listen (Snort oder Suricata & pfBlocker-ng) kann das auch mal etwas langsamer
anmuten.
10 GBit/s zu "sehen".
- messen um die 9,60 GBit/s
- mit mehreren VLANs um die ~7,00 GBit/s
- Normaler Netzwerkverkehr um die 4,6 GBit/s
- mit DPI, MacSec und Radius zusammen um die ~ 2,0 GBit/s
Dobby
Im Endeffekt wäre die pfSense der Falschenhals des Netzwerks.
Aber nicht Deine 8 Core Variante! Die Intel Xeon D-2100 mit 8 Cores gehen alle durchgehend bis 3,00 GHzdas reicht dicke für 10 GBit/s Verbindungen, aber wenn man noch 15 Pakete am laufen hat und zwei davon
mit wirklich vielen Rules oder Listen (Snort oder Suricata & pfBlocker-ng) kann das auch mal etwas langsamer
anmuten.
Sie hat zwar 10Gbit SFP+ Anschlüsse, aber das Problem durch die vielen Filter-Regeln bricht der Durchsatz
auch sehr stark ein. Was auch logisch ist.
Bei 10 GBit/s bekommst Du (Wir alle) in der Regel und im realen Leben bzw. Einsatz nicht die ganzenauch sehr stark ein. Was auch logisch ist.
10 GBit/s zu "sehen".
- messen um die 9,60 GBit/s
- mit mehreren VLANs um die ~7,00 GBit/s
- Normaler Netzwerkverkehr um die 4,6 GBit/s
- mit DPI, MacSec und Radius zusammen um die ~ 2,0 GBit/s
Gerade in der Nacht mal getestet. Ich komme nach aktuellen Stand auf einen Durchsatz bei Inter-VLAN-
Kommunikation mit Iperf auf maximal ca 7 Gbit/s.
Das ist nicht weniger und nicht mehr als andere Benutzer u.a. im pfSense Forum behaupten zu messen.Kommunikation mit Iperf auf maximal ca 7 Gbit/s.
Trotz Xeon D-2100 mit acht Kernen und 32Gb RAM. Zwar vermeide ich in meinem Design prinzipiell
große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora
der Phantomschmerzen will ich mir nicht öffnen.
Und die pfSense läuft nur als VM drauf?große sequentielle Kopiervorgänge von einem VLAN ins andere, aber sinnlos die Büchse der Pandora
der Phantomschmerzen will ich mir nicht öffnen.
Dobby
Nein, läuft Bare-Metal. Kann schon sein, wie du es sagst. Sind immerhin um die 20 VLANs mit pro Schnittstelle mindestens 20 Rules, DHCP, DNS, 5x IPSEC, 1x OpenVPN-Server mit circa 20 Clientverbindungen, 3x OpenVPN-Clientverbindung, BGP-Routing per FRR mit ungefähr 5 Neighbours, HaProxy, pfblocker... solche Sachen halt. Nicht gerade üppig, aber immerhin Reserven.
CPU-technisch kommt er selten ins Schwitzen, wie es bei Handling der Netzwerkschnittstellen aussieht und wie es sich bei Latenzen auswirkt, ist halt fraglich. Kann man irgendwie alles testen, entspricht dann aber meistens eher nicht realen Einsatzbedingungen.
