Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

[Side2005]

Hallöchen,

bei uns gehts demnächst vom eigenen Serverraum (Abstellkammer *hust*) in ein RZ.

Wir bekommen vom RZ-Betreiber 2xRJ45 redundante Anbindung ans WAN sowie 3x static public ips in einem /29 Netz. Hier müsste ich mal nachfragen, ob beide feeds das gleiche Netz routen, oder ein RJ45-Feed 2x IPs routet und der zweite Feed eine einzelne IP. Wie ist das normalerweise?
Hier habe ich noch ein Verständnisproblem, weil ich mich bis jetzt nur mit einem DSL-modem mitsamt einer einzigen IP rumschlagen musste, die nur an eine einzelne OPNSense durchgereicht wird.
Wie wird sowas normalerweise im RZ gehandhabt? Das /29-Netz ist ein "Provider Aggregatable Address Space" und ist "Provider Independent".

Frage ist: wie macht man's richtig, um alle SPOFs zu elimieren?
Drei Szenarien fliegen bei mir im Kopf, wobei ich Szenario 1 bzw. Szenario 2 am besten finde (KiSS). Szenario2 präferiert, da die Firewalls jeweils auch redundant angebunden sind (eine LAG über die gestackten Switche funktioniert laut FS.com - Modell S5860-20SQ) und somit die physischen NICs an den FWs "in sich" keine SPOFs darstellen.

Als Hardware für die FWs werden wahrscheinlich 2x M11SDV-4C-LN4F zum einsatz kommen, sprich 4xi350 NICs.

Wie man an Szenario 3 sieht, fehlt mir hier die Vorstellung. Ich will die Switches zwischen den WAN-feeds und den Firewalls verhindern. So richtig gedacht - sprich Szenario 2 is the way to go?

Bilder von Szenarien:
https://imgur.com/a/WDU91Lu

Bei Fragen bitte fragen 

Vielen Dank und Grüße
Side2005

[JeGr]

Hi,

> Wir bekommen vom RZ-Betreiber 2xRJ45 redundante Anbindung ans WAN sowie 3x static public ips in einem /29 Netz. Hier müsste ich mal nachfragen, ob beide feeds das gleiche Netz routen, oder ein RJ45-Feed 2x IPs routet und der zweite Feed eine einzelne IP. Wie ist das normalerweise?

Wenn der RZ Betreiber nicht gerade arg komisch drauf ist und die redundante Anbindung SEHR seltsam interpretiert, dann ist der Normalfall, dass eine Ader aktiv, eine Standby ist und nur dann Traffic hat/führt wenn der Upstream nen Schwenk auf ein anderes Gerät macht. Also sollte im Normalfall >90% der Zeit der Saft aus der active Ader kommen. Da man Netze normalerweise sauber auflegt, gehe ich davon aus, dass sein Cluster vornedran auch 2-3 Adressen braucht und daher auch nen aktiven/passiven Knoten hat. Je nachdem welcher Hersteller braucht er da 1-3 Adressen für.

Da du aber nicht weißt, welche Ader Daten führt oder nicht - weil du im günstigsten Fall gar nicht mitbekommen solltest, dass er nen Schwenk macht, sollte man die beiden RJ45 auf nem Switch auflegen und dort seinen eigenen CARP Cluster mit dem WAN ebenfalls hin verstrippen.

> Wie wird sowas normalerweise im RZ gehandhabt? Das /29-Netz ist ein "Provider Aggregatable Address Space" und ist "Provider Independent".

Ist ja eigentlich egal, er wird sich eine IP davon klauen - bspw. 192.0.2.1/29 und du kannst dann bspw. 4,5 und 6 auf den Cluster verteilen (4,5 auf die Nodes, 6 als CARP VIP bspw.) Eigentlich sind dann noch 2 IPs frei - da kommts drauf an ob die der Provider braucht.

Szenario 3 wäre dann auch das Richtige von der WAN Seite. Wenn dus ohne SPOF bauen willst, brauchst du vorne am Upstream 2 kleine Switche und legst die wie in einem "H" auf. Aktive Leitung und Firewall 1 auf Switch 1, dann Kabel von Switch 1->2 und an Switch 2 dann WAN Standby und Firewall 2 hin.

Alle anderen Szenarien sind aus CARP Sicht quatsch, weil du dann auf dem WAN keinen Failover machen kannst da die Standby Leitung inaktiv ist und sich die Firewalls übers WAN nicht sehen. Außerdem könntest du keine Updates auf der Standby Firewall (einfach) machen, etc. etc. - also schlicht: machs nicht

Beim Netz hinter den Firewalls:

Es sind 2 Gigabit Links. Sind die NUR für Redundanz oder wirklich auch wegen Bandbreite? Wenns um Bandbreite geht ist der Aufbau sonst suboptimal.

Bei reiner Redundanz: Zum einen musst du vorher sicher sein, dass deine Switches auch wirklich LACP ÜBER mehrere Switche unterstützen (nicht jede machen das!) und da auch nen LACP ordentlich drüber hinbekommen. Ansonsten wäre es unnötig. Zum Anderen ist die Frage ob man wirklich auf Teufel komm raus verhindern will, dass ein Failover der Firewalls passiert. Warum - dafür HAT man sie ja gerade!

Vielfach sehe ich Multi-Gigabit LACP oder 2x10G als LACP Bündel und dann über Kreuz aufgelegt um "Redundanz" zu haben. Redundanz für was? Man hat bereits 2 Firewalls. Gammelt der eine Switch ab, wird auf die 2. geschwenkt und man hat dort VOLLE Bandbreite (2x / 4x 1G oder 2x10G bspw.). Macht man aber den Stunt mit mehrfach Kreuzverkabeln, hat man bei einem Ausfall reduzierte Leistung, weil das lagg dann eben nur noch 2x oder 1x Gigabit (oder 10G) hat, aber es gibt keinen Failover, denn das Interface arbeitet ja noch sauber. Die andere Firewall hätte aber volle Kapazität und könnte bspw. 2G/4G/20G statt 1/2/20 liefern.

Da prallen die Service/Server Sicht (redundant anbinden damit jederzeit der Dienst funktioniert) auf die "Durchsatz" Sicht: Firewalls haben im Normalfall jetzt weniger Services laufen, sondern brauchen Durchsatz und Performance. Hätte man also ~50VLANs mit ordentlich Traffic zwischen den Netzen da laufen und da bricht ein 10G Link von zweien weg, ist das spürbar! langsamer. Darum sollte man beachten was man wo wie redundant verkabelt, dass man sich nicht vor lauter Redundanz die Performance kaputt konfiguriert

Cheers

[Side2005]

Vielen Dank für deine Antworten. Super 


> Wenn der RZ Betreiber nicht gerade arg komisch drauf ist und die redundante Anbindung SEHR seltsam interpretiert, dann ist der Normalfall, dass eine Ader aktiv, eine Standby ist und nur dann Traffic hat/führt wenn der Upstream nen Schwenk auf ein anderes Gerät macht. Also sollte im Normalfall >90% der Zeit der Saft aus der active Ader kommen. Da man Netze normalerweise sauber auflegt, gehe ich davon aus, dass sein Cluster vornedran auch 2-3 Adressen braucht und daher auch nen aktiven/passiven Knoten hat. Je nachdem welcher Hersteller braucht er da 1-3 Adressen für.

Alles klar, da muss ich dann nochmal nachhaken

>Beim Netz hinter den Firewalls:
Es sind 2 Gigabit Links. Sind die NUR für Redundanz oder wirklich auch wegen Bandbreite? Wenns um Bandbreite geht ist der Aufbau sonst suboptimal.

Es handelt sich bloß um Redundanz. Der Up/Downstream ist auch vorerst nur eine 100/100mbit Leitung (muss von mir auf die Geschwindigkeit gedrosselt werden, muss ich noch schauen wie man das in der *sense konfiguriert. Die Summe aus WAN A und WAN B darf 100mbit nicht überschreiten).

>Bei reiner Redundanz: Zum einen musst du vorher sicher sein, dass deine Switches auch wirklich LACP ÜBER mehrere Switche unterstützen (nicht jede machen das!) und da auch nen LACP ordentlich drüber hinbekommen. Ansonsten wäre es unnötig. Zum Anderen ist die Frage ob man wirklich auf Teufel komm raus verhindern will, dass ein Failover der Firewalls passiert. Warum - dafür HAT man sie ja gerade!

Es handelt sich um 2xS5860-20SQ der Firma FS.com. Dort habe ich extra ein Ticket beim Support eröffnet und um Klarstellung von LACP/LAG über 2 switches gebeten. Dort wurde mir explizit Mitgeteilt, dass NIC-A(Server-I) auf Switch-1 und NIC-B(Server I) auf Switch 2 aufgelegt werden kann und automatisch ein Failover auf Switch2 stattfindet, sobald Switch1 kaputt ist. Die Funktion war mir besonders wichtig, da im RZ ein Proxmox-Ceph-Cluster Einzug finden wird - und das eher günstigere Switches sind, die redundant betrieben werden können. Evtl. ist es aber "Overkill" für die Firewalls, da mit 2xFW schon kein SPOF mehr existiert.


>Vielfach sehe ich Multi-Gigabit LACP oder 2x10G als LACP Bündel und dann über Kreuz aufgelegt um "Redundanz" zu haben. Redundanz für was? Man hat bereits 2 Firewalls. Gammelt der eine Switch ab, wird auf die 2. geschwenkt und man hat dort VOLLE Bandbreite (2x / 4x 1G oder 2x10G bspw.). Macht man aber den Stunt mit mehrfach Kreuzverkabeln, hat man bei einem Ausfall reduzierte Leistung, weil das lagg dann eben nur noch 2x oder 1x Gigabit (oder 10G) hat, aber es gibt keinen Failover, denn das Interface arbeitet ja noch sauber. Die andere Firewall hätte aber volle Kapazität und könnte bspw. 2G/4G/20G statt 1/2/20 liefern.

Ich glaub ich verstehe, worauf du hinaus willst. 2x FW mit 2x Switches davor/danach ist schon Redundant.
Ich verstehe aber noch nicht ganz, was du mit "volle Kapazität" meinst. Dir schwebt vor, pro FW 2x Verbindung zu EINEM Switch, anstatt 2x Verbindung zu unterschiedlichen. Korrekt? Also das LACP nicht über zwei Switches, sondern eine LAG pro switch pro fw? Wie Szenario 5, nur mit 2x Linien zw. jeweils FW01/SW03 und FW02/SW04?

> Da prallen die Service/Server Sicht (redundant anbinden damit jederzeit der Dienst funktioniert) auf die "Durchsatz" Sicht: Firewalls haben im Normalfall jetzt weniger Services laufen, sondern brauchen Durchsatz und Performance. Hätte man also ~50VLANs mit ordentlich Traffic zwischen den Netzen da laufen und da bricht ein 10G Link von zweien weg, ist das spürbar! langsamer. Darum sollte man beachten was man wo wie redundant verkabelt, dass man sich nicht vor lauter Redundanz die Performance kaputt konfiguriert.

Da gebe ich dir vollkommen Recht.
Habe mal als Anhang Szenario 4+5 hochgeladen. Szenario 5 wäre ohne SPOFs und "most" KiSS(keep it simple, stupid), richtig? Szenario 4 wäre auch ohne SPOF, würde aber durch die Kreuzverkabelung mehr komplexität ins System bringen (und auch mehr Ports verbrauchen )


Nochmal Danke, sehr hilfreicher Input

Szenario 4+5:
https://imgur.com/a/45j4ENZ

Grüße


Edit:
"Die Summe aus WAN A und WAN B darf 100mbit nicht überschreiten" ist natürlich quatsch, wenn man davon ausgehen kann, dass es sich hier um active/backup handelt. (und kein loadbalancing)

[JeGr]

Es handelt sich um 2xS5860-20SQ der Firma FS.com. Dort habe ich extra ein Ticket beim Support eröffnet und um Klarstellung von LACP/LAG über 2 switches gebeten. Dort wurde mir explizit Mitgeteilt, dass NIC-A(Server-I) auf Switch-1 und NIC-B(Server I) auf Switch 2 aufgelegt werden kann und automatisch ein Failover auf Switch2 stattfindet, sobald Switch1 kaputt ist. Die Funktion war mir besonders wichtig, da im RZ ein Proxmox-Ceph-Cluster Einzug finden wird - und das eher günstigere Switches sind, die redundant betrieben werden können. Evtl. ist es aber "Overkill" für die Firewalls, da mit 2xFW schon kein SPOF mehr existiert.

Ja, trotzdem Vorsicht und nochmal nachhaken, ob das "nur" Failover ist oder DEFINTIV LACP! Das ist ein Unterschied und verhält sich signifikant anders und man möchte keine komischen Verhalten haben weil NICs spinnen!

Ich verstehe aber noch nicht ganz, was du mit "volle Kapazität" meinst. Dir schwebt vor, pro FW 2x Verbindung zu EINEM Switch, anstatt 2x Verbindung zu unterschiedlichen. Korrekt? Also das LACP nicht über zwei Switches, sondern eine LAG pro switch pro fw? Wie Szenario 5, nur mit 2x Linien zw. jeweils FW01/SW03 und FW02/SW04?

Richtig, da die meisten Switche eben LACP/Channelbond (wie es Cisco nennt) etc. NICHT ordentlich über 2 unterschiedliche Switche können, sondern nur so ein solala-Failover-Gedöns, was aber kein LACP ist. Daher oben der Punkt, nochmal genau rückzufragen. Die meisten Switche können das nämlich auch nur dann, wenn der Stack sich eh wie ein "Ganzes" verhält und nicht als einzelne Switche (also sowas wie ein Fabric, Juniper Stack, etc.).

Der Punkt ist: 2x auf den gleichen Switch/die gleiche Backplane zu verkabeln und dann ordentlich LACP bringt effektiv eben (in deinem Beispiel) 2Gbps möglicher Gesamtdurchsatz (von mehreren Quellen etc. etc. wie eben LACP funktioniert), während Failover nur 1Gbps hat. Zusätzlich bekommt man bei unzureichender Überwachung nicht mal mit, dass ein Link down ist, denn die Firewall macht keinen Failover und wer nicht am Switch jeden Port via SNMP o.ä. sauber überwacht sieht es nicht. Hatten wir jetzt gerade erst genauso mit 2x10G Links mit X Verkabelung statt H. Der wusste gar nicht dass jemand am Switch gepfuscht hatte und der eine Link down war. Hat keiner gesehen. Erst ein ifconfig lagg0 auf der Konsole hat gezeigt: Holla, ist ja nur ix1 auf collecting/active, der ix0 nicht. Doof.

Und ein Failover ist - wenn der Cluster sauber konfiguriert ist und funktioniert - ja nichts, was man auf Teufel komm raus vermeiden muss, sondern durchaus was, was man haben will damit man eben Fehlersituationen bemerkt bzw. Probleme erkennt und dafür hat man ja dann auch die 2. HW im Rack hängen. Wenn ich alles baue, dass ich die 99,9% der Zeit nicht brauche, dafür aber dann bei Switch Problemen jedes Mal Bandbreite verliere oder ggf. sogar in komische MAC/ARP Probleme reinlaufe weil LACP/Failover NICs spinnen, dann hab ich da mehr Probleme als wenn die Kisten einfach linear verstrippt wären und nen Failover gemacht hätten

Daher genau planen WAS man will und WARUM

Edit: Sorry Anhang nicht gesehen. Ich würde tatsächlich Variante 5 nehmen, aber 4 ist wie oben beschrieben durchaus legitim wenn man wirklich mehr Redundanz will, die Switches das auch wirklich sauber mitmachen und alles fluffig funktioniert. Sonst möchte man eher #5 machen

[Side2005]

Ja, trotzdem Vorsicht und nochmal nachhaken, ob das "nur" Failover ist oder DEFINTIV LACP! Das ist ein Unterschied und verhält sich signifikant anders und man möchte keine komischen Verhalten haben weil NICs spinnen!

Nochmal nachgehakt, folgendes Bildchen hat mir die nette Frau vom Support hinterlassen
https://imgur.com/a/0UGgBP8

Edit: Sorry Anhang nicht gesehen. Ich würde tatsächlich Variante 5 nehmen, aber 4 ist wie oben beschrieben durchaus legitim wenn man wirklich mehr Redundanz will, die Switches das auch wirklich sauber mitmachen und alles fluffig funktioniert. Sonst möchte man eher #5 machen

Ich werde mal die X-Verkabelung ausprobieren (habe zum Glück noch ellenlang Zeit, alles Testbetrieb-mäßig auszuprobieren). Falls mir da etwas komisch vorkommt werde ich aber sofort auf die vorgeschlagene "H"-Verkabelung umstellen.


Fragt sich noch, welche Switches auf der WAN-Seite eingesetz werden sollten. Hier benötige ich keine VLANs, LAGs oder ähnliches. Nimmt man in einem solchen Fall einfach 2x "billige" 5-Port Switches (GS305v3 z.B.) oder sollte doch etwas "teureres"?

Grüße

[Side2005]

Fragt sich noch, welche Switches auf der WAN-Seite eingesetz werden sollten. Hier benötige ich keine VLANs, LAGs oder ähnliches. Nimmt man in einem solchen Fall einfach 2x "billige" 5-Port Switches (GS305v3 z.B.) oder sollte doch etwas "teureres"?

Habe mich doch für 2x große managed 1U-Switches entschieden und werden den WAN-traffic auf einem eigenen VLAN laufen lassen. Oder spricht da etwas gegen?

[JeGr]

> Habe mich doch für 2x große managed 1U-Switches entschieden und werden den WAN-traffic auf einem eigenen VLAN laufen lassen. Oder spricht da etwas gegen?

Nö, Upstream Switche sind meist kleiner/günstiger weil nichts groß drauf laufen muss. Out of band Management und ggf. ein Monitoring Feature/Port sind nicht verkehrt, aber sonst müssen die nicht viel ab können außer sauber ihren Traffic schieben und das so fix wie möglich

Ansonsten wie gesagt bin ich eher Freund davon, das intern nicht als LAGG laufen zu lassen, sondern einfach via H-Verkabelung zu nutzen. Jeder Layer wie LAGG/LACP bringt nur wieder zusätzlichen Aufwand und Debugging Kram mit rein. Wenn man drauf verzichten kann ist das nie verkehrt. Und bei Bandbreite ist es eh mehr wert, dann mit zwei Adern auf den gleichen Switch zu gehen. Und da es nur Gigabit ist... naja. Kann man sich zum Spielen natürlich durchaus mal aufsetzen und testen. Ich würde es wie gesagt sein lassen wenn es sich vermeiden lässt.

[Side2005]

Nö, Upstream Switche sind meist kleiner/günstiger weil nichts groß drauf laufen muss. Out of band Management und ggf. ein Monitoring Feature/Port sind nicht verkehrt, aber sonst müssen die nicht viel ab können außer sauber ihren Traffic schieben und das so fix wie möglich

Du sagst einmal "nö, kein problem dass mit VLANs zu realisieren", sagst aber dann im gleichen Atemzug, dass upstream Switche nichts können müssen, also es sich also doch um einen einfachen, unmanaged switch handeln kann. (wie z.B. der hier angesprochene GS305v3?). Verstehe ich also nicht ganz

Zur Verdeutlichung:
Plan ist, 2x24-Port RJ45-Gbit Switches zu nehmen, die fürs Corosync-VLAN (für CEPH) und das management-VLAN zuständig sind - und da eben noch ein 3. VLAN drüber laufen zu lassen, welches dann für das Upstream-LAN/CARP-Netz zuständig ist. Spricht da nichts gegen?

[JeGr]

Kommst du mit deinen eigenen Aussagen durcheinander? Ich hab doch nirgends was von VLANs geschrieben. Zudem beißen sich die Aussagen nicht. Wenn auf nem Switch NICHTS außer dem Upstream liegt, brauch ich da auch nicht zwingend VLANs. Warum? Also müssen die nicht viel können. Und 08/15 Switche können heute fast alle schon basic VLAN Features, daher ist das kein Kaufargument mehr. Würde halt nicht gerade die billigsten Dinger nehmen, die beim Schief anschauen schon abfaulen Aber ansonsten ist das relativ egal solang sie deine Upstream Capacity auf der Backplane ordentlich wuppen.

> Plan ist, 2x24-Port RJ45-Gbit Switches zu nehmen, die fürs Corosync-VLAN (für CEPH) und das management-VLAN zuständig sind - und da eben noch ein 3. VLAN drüber laufen zu lassen, welches dann für das Upstream-LAN/CARP-Netz zuständig ist. Spricht da nichts gegen?

Da kommst DU jetzt mit völlig neuen Sachen. Auf dem Upstream läuft nichts außer Upstream. Da jetzt plötzlich noch Corosync von Proxmox draufzulegen und Management drauf zu feiern ist was komplett anderes. Wäre für uns ein No-Go. Upstream ist Upstream. Done. Alles andere packst du hinter deine Firewalls, dafür sind die da.

Warum jetzt plötzlich Infrastruktur und Security relevantes Zeug plötzlich vor die Firewall hängen? Macht für mich keinen Sinn. VLAN hin oder her, das sind Sachen die man auf den Geräten und den Switchen dahinter braucht, nicht auf denen davor. Denn wenn du so anfängst, dann kannst du auch gleich argumentieren: "ich brauch ja eh keine zweiten Switche, ich kann ja auch alles mit VLANs auf den vorhandenen Switchen machen". Wenn die eh LACP und Schnickschnack können, dann können die ja gleich alles machen

[Side2005]

Da kommst DU jetzt mit völlig neuen Sachen. Auf dem Upstream läuft nichts außer Upstream. Da jetzt plötzlich noch Corosync von Proxmox draufzulegen und Management drauf zu feiern ist was komplett anderes. Wäre für uns ein No-Go. Upstream ist Upstream. Done. Alles andere packst du hinter deine Firewalls, dafür sind die da.

Sorry, ich bin gedanklich schon ein Wochenende weiter
Habe mir gedacht dadurch Rackunits einsparen zu können, da sowieso schon als Switche vorhanden. Aber ist natürlich richtig. Macht von der Securityseite nicht viel Sinn.

Soll also 2x Upstream switche, 2x "Core" switche und 2x managementswitche werden

Nochmals danke für deine Unterstützung.

[JeGr]

> Soll also 2x Upstream switche, 2x "Core" switche und 2x managementswitche werden

Und wenn du OOB Management willst, bräuchte das Mgmt Netz dahinter noch irgendwas notfallmäßiges zur Internet Einwahl (oder man kann evtl. nen Deal mit dem ISP machen für ne kleine abgespeckte Line die eh kaum benötigt wird). Aber das nur zum Bedenken. Treffe ich in der Praxis eher selten an und wenn dann meist in Locations wo man nicht einfach mal so hinfährt.