Hi.
Ich hatte lange damit zu kämpfen, dass ich auf unserem Layer3-Switch ACL Regeln zwischen zwei VLANs nutzen wollte, was jedoch nicht geklappt hat.
Nach langer Suche auf dem Switch stellte sich dann heraus, dass das Problem auch auf dem Hypervisor liegen kann. Da wir eine 4-fach-Leitung vom Switch zum L3-Switch als bond.0 (LACP bzw 802.3ad) einsetzen, muss hier die Option
bond_xmit_hash_policy layer2+3
oder aber
bond_xmit_hash_policy layer3+4
Vielleicht kann das jemand gebrauchen – uns hat das hier Tage und Nerven gekostet, da die Regeln im Swtich offenbar richtig angelegt waren aber die Kommunikation zwischen den VLANs trotzdem nicht klappen wollte…
Hmm – jetzt habe ich den Proxmox-Server mit der eingetragenen Option neu gestartet und siehe da: Der Zugriff von einem VLAN in ein anderes klappt. Was mir nicht einleuchtet: Jetzt klappen plötzlich auch andere Zugriffe, die eigentlich verboten sein sollten. Ich werde vorerst zurückkehren zu layer2 bis ich weiß, was da los ist. Kann es sein, dass der Proxmox-Server in diesem Modus selbst routet und das nicht mehr nur dem Switch überlässt???
ich glaube nicht, dass diese Optionen etwas mit dem Funktionieren der ACLs zu tun hatten/haben. Hier geht es darum, an Hand welcher Parameter die Frames (LAG = Layer 2) auf die Leitungen verteilt werden. Die Einstellung muss auf beiden Seiten gleich sein. Der Cisco SG300 kann MAC und IP/MAC. Auf der Linux Seite entspricht das den Optionen Layer2 (Standard) und Layer 2+3, würde ich sagen. Aus meiner Sicht sollte also Layer2 (Linux) + MAC Adress (Cisco) verbleiben.
Hoffe, keinen Mist zu erzählen,
Grüße
Bertram
PS: Das Schlimme an diesen Parametern ist, dass das Netz i.d.R. ein bisschen funktioniert, d.h. es gibt Verluste, aber es geht grundsätzlich, wenn die Parameter nicht übereinstimmen. Ein beliebtes Problem bei Cisco und ESX …
OK. Was mit der Option extrem merkwürdig ist: es gibt plötzlich andere Zugriffe auf IP Adressen in anderen Subnetzen, die es eigentlich nicht geben kann.
Ich verstehe nicht, warum der L3 Switch (plötzlich?) Zugriffe erlaubt, die per ACL eindeutig verboten sind.
Wie kann man so ein Problem vernünftig debuggen??
Schöne Grüße.
Ich würde temporär die Protokollierung der Regel(n) aktivieren und schauen, welche Regel greift … Ein L3- Switch ist leider keine Firewall und damit recht unkomfortabel, wenn gefiltert werden muss. Komplexe Netzstrukturen würde ich damit nicht bauen …
Auch das habe ich bereits gemacht – finde das debug-Protokoll aber nirgendwo. Unter “Ram Speicher” / “Flash-Speicher” wird trotz aktivierter Protokollierung nichts angezeigt
Der Proxmox selbst hat ja auch Firewall Einstellungen (auch pro VM). Da haben wir hier aber nichts eingetragen…
ich hab von alle dem wenig Ahnung, möchte aber mal laut mitdenken.
Also: der L3 Switch hat alles richtig gemacht, außer dem routen (dem
Rückweg nur, oder?) in das eine (neue) Subnetz.
Dann hat michael an dem bond eine Einstellung geändert.
Daraufhin war der L3 mehr oder weniger “außen vor”: er hat plötzlich
nicht mehr geregelt.
Nun sagt morpweb: “Der Cisco SG300 kann MAC und IP/MAC.”
Ich verstehe das als “anhand IP oder MAC” (filtern).
Nun nehme ich also an, dass das Umstellen am bond bewirkt hat, dass da
was auf der Strecke bleibt, was der L3 braucht.
Mein Vorschlag wäre:
vorherigen Zustand des bond (bei dem fast alles ging) wieder herstellen
Einlesen um zu verstehen wo hier der Hase im Pfeffer liegen könnte
Hi.
Ja, ich versuche das Problem weiter einzugrenzen – stoße aber weiterhin auf sehr sonderbare Effekte, die ich mir im Moment weder erklären noch weiter eingrenzen kann.
Ein Bsp: Ich habe die ACL-Regeln wieder auf den ursprünglichen Zustand gesetzt, so dass alle Subnetze wieder komplett voneinadner getrennt sind. Zudem habe ich auch das bond wieder auf die Option “layer2” zurückgestellt. Also “Gehen Sie zurück auf Los!” … und was soll ich sagen: Es gehen weiterhin pings durch, die es nicht geben darf. So kann ich von einem Subnetz (VLAN.50 mit IP-Bereich 10.30.10.0/24) ein paar IP-Adressen in anderen VLANs erreichen – aber eben nicht alle. Ein traceroute geht aber nicht durch und Wireshark meldet auch nichts, was mich weiterbringen würde.
Seltsam ist auch, dass ich einen Switch im (abgeschotteten) Management-Subnetz für die Switche erreiche. Der hat die IP 10.16.2.80 und antwortet in allen Subnetzen auf das PING und https://
Auch das darf überhaupt nicht sein – aber wie gesagt: wie grenzt man das ein?
Ideen:
Switch defekt? (Neustart hat nichts bewirkt)
ARP Cache? Durch das hin- und herstellen der ACL-Regeln auf diversen Switches noch alte Einstellungen aktiv?
Evtl irgenwas in Sachen IPv6? (Wireshark hatte da einmal kurz eine Adresse drin – aber der ping reagiert ja auf die IPv4 Adresse)
ich denke, an dieser Stelle wird es notwendig, nicht alle Dinge in einen Topf zu werfen. Besser ist Holgers Ansatz: Problem für Problem und Schicht für Schicht …
Schicht 2: bond, lag …
Hier geht es darum, anhand welcher Parameter die Frames auf die Leitungen verteilt werden (Load Balancing): auf Basis der MAC (Layer 2) oder auf Basis MAC/IP (Layer 2+3). Das hat nichts mit Filterung zu tun. Diese Einstellung muss auf beiden Seiten gleich sein.
Leider ist es oft so, dass die Verbindung bei falschen Einstellungen ein wenig funktioniert. Des Weiteren wird es sicher auch Auswirkungen auf Dinge in höheren Schichten wie L3-Interfaces und gebundenen ACLs haben. Habe das noch nie getestet …
Um hier zu einer Lösung zu kommen, sollte jedes Problem formuliert und dann Schicht für Schicht durchgegangen werden.
Schicht 2: LAGs bzw Bonds, VLANs
Schicht 3+4: virtuelle L3 Interfaces der VLANs, jeweils 2 ACLs mit Verknüpfung an 2 L3 Interfaces (Traffic Inbound)
Das Logging der ACLs muss zum Laufen gebracht werden, damit wir sehen, welche Regel getroffen hat!
Da kommt nicht viel an … Oder muss man tatsächlch einen Remote Log Server definieren???
Anders gefragt: ping-Anfragen werden da offenbar nicht gelogged … was muss man machen, damit etwas gelogged wird?
Zwei weitere winzige Puzzleteilchen:
1.) Im Proxmox den IPFire einfach mal auf “suspend” geschaltet (“aus”). Pings gehen weiterhin durch – also läuft die Kommunikation tatsächlich außerhalb des IPFire!
