Messages

1

German - Deutsch / HowTo: Vodafone VDSL mit ZyXel VMG3006-D70A

« on: December 23, 2021, 12:00:55 pm »

Moin zusammen,

stiller Leser hier. Der Thread richtet sich an alle dümmlinge (wie auch mich) die sich zu fein sind, eine Anleitung zu lesen, weil Sie der Meinung sind, es sowieso zu wissen. WISST IHR NICHT.

Wir betreiben bei uns eine Opnsense Business Edition (in Version 21.10.1) und haben seit dem 1.10 einen Kabelanschluss. Seit dem 17.12 zusätzlich noch einen VDSL-Anschluss von Vodafone (über Telekom).
Wollte extra keine Fritte, sondern ein anständiges Modem - das gab es mit dem Anschluss auch so zur Auswahl.
Geliefert wurde dann wenig später ein ZyXel VMG3006-D70A ... wow denke ich! Damit kann ich arbeiten. Die kenne ich ja schon....

Ausgepackt, angeschlossen.... es synchronisiert sich. DSL link up. SUPER dachte ich mir.
Mit der sense verbunden, vorab alles ordentlich konfiguriert (VLAN7 angelegt, VLAN auf den NIC gelegt, PPPoE Daten eingegeben und eben mit dem VLAN-Interface verbunden)... failed - also VLAN7 gelöscht, wieder probiert... failed. Kann sich nicht verbinden.
Andauernd nur nichtssagende Logeintrage. Weiter geforscht und auf einen Thread gestoßen, wo jemand erst Erfolg hatte, nachdem er sich ein neues PW für die PPPoE-Einwahl vergeben hat. Ebenfalls probiert- kein Erfolg.

Denke mir so ein Scheiss.... Da ich selber nicht im Büro bin (300KM weit weg) habe ich meine Kollegin Vorort mit dem Laptop in der Hand in den Serverraum verbannt und sie sich mit dem ZyXel verbinden lassen.... ALLES IN ORDNUNG mit der Zyxel Box (Statusseite hat mich grüngrinsend angestrahlt mit VERBUNDEN). Firmwareversion 15xx.... komisch dachte ich mir, denn ein Firmwareupdate auf 17xx schlug auch Fehl.
Da fing es langsam an bei mir zu klingeln (Providerbox etc.), nachdem ich es schon auf die Sense schieben wollte (die neuste Firmware vom Hersteller ist nämlich Version 17xxx) - also nochmal intensivst google bemüht und mir die Inbetriebnahme von Vodafone für den Zugang durchgelesen. Und siehe da. Es gibt tatsächlich einen Eintrag für den VMG3006-D70A:
siehe https://www.vodafone.de/media/downloads/pdf/hb-install-business-adsl-vdsl-glasfaser-.pdf Abschnitt 2.2.

Die VMG3006-D70A hat von Vodafone eine eigene Firmware verpasst bekommen, wo man anhand vom verwendeten LAN-Port das VLAN-Tagging bestimmen kann (Port3 Tagging im Kundenrouter, Port4 Tagging im Modem) - wo hat das Kabel dringesteckt (in Port2!!!!!!!). Denn laut Zyxel-Handbuch kann man Port 2-4 beliebig verwenden und das VLAN-Tagging im Webmenü einstellen (das geht nämlich auf der providerbox nicht).

Kabel in Port 3 gesteckt, Kollegin mit einer Büroklammer die Box resetten lassen (MUSS so gemacht werden lt. Anleitung, wenn man Initial "verkackt" hat) und siehe da - 15 Minuten später - alles da (mit VLAN7 in der Sense).

Also Leute: Erspart euch ca 4h sinnlose Sucharbeit und führt irgendwelche fixes durch, in der Hoffnung es behebt das Problem (Stichwort Cargokult), nehmt euch die 5 Minuten und studiert das scheiss Manual. (friendly reminder)

2

German - Deutsch / Re: Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

« on: May 31, 2021, 02:47:10 pm »

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.

3

German - Deutsch / Re: Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

« on: May 31, 2021, 02:05:57 pm »

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?

4

German - Deutsch / Re: Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

« on: May 31, 2021, 11:38:14 am »

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?

5

German - Deutsch / Re: Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

« on: May 28, 2021, 11:58:15 am »

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

6

German - Deutsch / Re: Umzug ins RZ: multiwan/HA bei redundanter Anbindung Verständnisproblem

« on: May 27, 2021, 06:25:06 pm »

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)

7

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

« on: May 27, 2021, 03:06:02 pm »

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