36
Cisco SG300: Zugriff auf eine IP im anderen VLAN ermöglichen
Hallo.
Ich komme bei diesem Problem nicht weiter und wende mich daher mal an die Wizzards
Wir haben einen Cisco-SG300-Switch im L3-Mode mit diversen VLANs konfiguriert. Die sind bisher alle wunderbar voneinander abgeschottet und können nicht gegenseitig aufeinander zugreifen. Nun soll aber ein Rechner in einem VLAN.50 von allen Rechnern in VLAN.60 erreichbar sein. Daher habe ich bei den ACEs ein paar Regeln hinzugefügt, die das ermöglichen sollen. Leider kommt aber nichts an und der Rechner läßt sich auch nicht anpingen.
Zum Aufbau: Im Moment handelt es sich nur zwei VMs, die beide auf einem Proxmox-Server laufen. Die eine hängt in VLAN.60 und die andere in VLAN.50. That’s all – dazwischen ist der Hypervisor und der Layer3-Swtich.
In Bild 1 sieht man die Regeln für VLAN.50. Es soll zusätzlich der Zugriff auf die IP 10.30.10.100 gewährt werden (Regel 13)
Da der L3 ja nicht stateful arbeitet, habe ich die gleiche Regel auch umgekehrt in VLAN.60 eingetragen, was man in Bild 2 sehen kann (Regel 92)
Dennoch komme ich nicht auf den Server 10.30.10.100. Kein Ping kommt durch usw. (Es ist ein Win10-Server, dessen Firewall ich auch bereits komplett deaktiviert habe)
Zum Testen, ob es an den ACE/ACL Regeln liegt, hatte ich bereits eine neue ACE erstellt, die alles zulässt (Protokoll beliebig, Quelle beliebig, Ziel beliebig) und habe diese Regel an meine beiden VLANs 50 und 60 gebunden. Und siehe da: Jetzt können sie sich anpingen! Das Prinzip funktkioniert also.
Daher sollte an meinen ACE-Regeln liegen, die im Moment eingetragen sind. Ich sehe den Fehler aber weiterhin nicht.
Wer hat einen brauchbaren Tipp?
Danke!
Ich komme bei diesem Problem nicht weiter und wende mich daher mal an die Wizzards
Wir haben einen Cisco-SG300-Switch im L3-Mode mit diversen VLANs konfiguriert. Die sind bisher alle wunderbar voneinander abgeschottet und können nicht gegenseitig aufeinander zugreifen. Nun soll aber ein Rechner in einem VLAN.50 von allen Rechnern in VLAN.60 erreichbar sein. Daher habe ich bei den ACEs ein paar Regeln hinzugefügt, die das ermöglichen sollen. Leider kommt aber nichts an und der Rechner läßt sich auch nicht anpingen.
Zum Aufbau: Im Moment handelt es sich nur zwei VMs, die beide auf einem Proxmox-Server laufen. Die eine hängt in VLAN.60 und die andere in VLAN.50. That’s all – dazwischen ist der Hypervisor und der Layer3-Swtich.
In Bild 1 sieht man die Regeln für VLAN.50. Es soll zusätzlich der Zugriff auf die IP 10.30.10.100 gewährt werden (Regel 13)
Da der L3 ja nicht stateful arbeitet, habe ich die gleiche Regel auch umgekehrt in VLAN.60 eingetragen, was man in Bild 2 sehen kann (Regel 92)
Dennoch komme ich nicht auf den Server 10.30.10.100. Kein Ping kommt durch usw. (Es ist ein Win10-Server, dessen Firewall ich auch bereits komplett deaktiviert habe)
Zum Testen, ob es an den ACE/ACL Regeln liegt, hatte ich bereits eine neue ACE erstellt, die alles zulässt (Protokoll beliebig, Quelle beliebig, Ziel beliebig) und habe diese Regel an meine beiden VLANs 50 und 60 gebunden. Und siehe da: Jetzt können sie sich anpingen! Das Prinzip funktkioniert also.
Daher sollte an meinen ACE-Regeln liegen, die im Moment eingetragen sind. Ich sehe den Fehler aber weiterhin nicht.
Wer hat einen brauchbaren Tipp?
Danke!
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: 383921
Url: https://administrator.de/contentid/383921
Ausgedruckt am: 04.12.2024 um 08:12 Uhr
36 Kommentare
Neuester Kommentar
Hallo,
Bist du sicher das deine Subnetzmasken so passen? Das habe ich noch nie so gesehen. Und wenn man von den Bildchen auch noch die überschriften wegschneidet machst du es uns nicht leichter.
Gruß,
Peter
Zitat von @White-Rabbit2:
In Bild 1 sieht man die Regeln für VLAN.50. Es soll zusätzlich der Zugriff auf die IP 10.30.10.100 gewährt werden (Regel 13)
In Bild 1 sieht man die Regeln für VLAN.50. Es soll zusätzlich der Zugriff auf die IP 10.30.10.100 gewährt werden (Regel 13)
Dennoch komme ich nicht auf den Server 10.30.10.100. Kein Ping kommt durch usw.
Nun was sagt denn das Logging oder ein Wirshark mitschnitt?(Es ist ein Win10-Server, dessen Firewall ich auch bereits komplett deaktiviert habe)
Es gibt keinen Win 10 Server und das deaktivieren einer Firewall ist neanderthalermethode.Gruß,
Peter
@Pjordorf:
Bei Cisco ist es üblich, dass in ACLs eine Wildcard-Maske angegeben wird, die invers geschrieben wird.
Wenn du ein /24-Präfix abdecken willst, ist 0.0.0.255 also tatsächlich richtig.
Kontrolliere mal, ob auf Client und Server jeweils der Cisco als Gateway konfiguriert ist.
Falls ja, prüfe auf dem Server mal mit Wireshark nach, ob deine Ping-Anfragen da ankommen und beantwortet werden.
Bei Cisco ist es üblich, dass in ACLs eine Wildcard-Maske angegeben wird, die invers geschrieben wird.
Wenn du ein /24-Präfix abdecken willst, ist 0.0.0.255 also tatsächlich richtig.
Kontrolliere mal, ob auf Client und Server jeweils der Cisco als Gateway konfiguriert ist.
Falls ja, prüfe auf dem Server mal mit Wireshark nach, ob deine Ping-Anfragen da ankommen und beantwortet werden.
Hallo,
Gruß,
Peter
Zitat von @LordGurke:
@Pjordorf:
Bei Cisco ist es üblich, dass in ACLs eine Wildcard-Maske angegeben wird, die invers geschrieben wird.
Wenn du ein /24-Präfix abdecken willst, ist 0.0.0.255 also tatsächlich richtig.
OK, verstanden und korrigiert. Danke.@Pjordorf:
Bei Cisco ist es üblich, dass in ACLs eine Wildcard-Maske angegeben wird, die invers geschrieben wird.
Wenn du ein /24-Präfix abdecken willst, ist 0.0.0.255 also tatsächlich richtig.
Gruß,
Peter
Die bestehenden Regeln sind auch etwas unsinnig. Mal am Beispiel von VLAN 50:
Die Frage stellt sich welches IP Netz in VLAN 50 aktiv ist ?? Leider macht der TO dazu keine Aussage
Nach Reihenfolge wäre es so:
Daraus kann man raten das vermutlich das 10.30.10.0 /24er Netz das VLAN 50 IP Netz ist...??
Folglich müssen dann zwangsweise ALLE Endgeräte aus diesem VLAN Segment eine 10.30.10.x Quell IP Adresse haben !
Ansonsten sind die regeln aber syntaktisch richtig.
Liegt vermutlich daran das die Winblows Firewall doch noch aktiv ist und ICMP (Ping) wie üblich per Default blockt. Zusätzlich blockt sie per default ja auch noch jeglichen Fremdtraffic aus anderen IP Netzen.
Wireshark wäre hier dein Freund, oder....
Indem du mal mit einer Regel das gesamte Netz VLAN 50 und 60 freigibst jeweils auf beiden Interfaces und dann statt VM Host einfach mal das Switch Layer 3 Interface anpingst.
Klappt das fehlerfrei (wovon mal mal ausgehen kann) dann kannst du dir sicher sein das es an der Firewall liegt !
Die Frage stellt sich welches IP Netz in VLAN 50 aktiv ist ?? Leider macht der TO dazu keine Aussage
Nach Reihenfolge wäre es so:
- 1. Lässt vom VLAN 50 Zugriff mit jeglicher Quell IP auf das 10.16.1.0er Netz zu.
- 2. Lässt vom VLAN 50 Zugriff mit jeglicher Quell IP aus dem 10.30.10.0er Netz auf das 10.30.10.0er Netz zu.
- 3. Lässt vom VLAN 50 Zugriff mit Host IP 10.30.10.100 auf das 10.30.20.0er Netz zu.
- 4. Verbietet vom VLAN 50 Zugriff mit jeglicher Quell IP auf das 10.0.0.0 /16 Netzsegment
Daraus kann man raten das vermutlich das 10.30.10.0 /24er Netz das VLAN 50 IP Netz ist...??
Folglich müssen dann zwangsweise ALLE Endgeräte aus diesem VLAN Segment eine 10.30.10.x Quell IP Adresse haben !
- Regel 1 jegliche Quell Adressen zuzulassen ist also falsch und zudem auch unsicher !
- Regel 2 ist kompletter Blödsinn, denn Traffic aus dem eigenen VLAN Segment landet niemals am Layer 3 Port des Switches. Der bleibt logischerweise im VLAN Segment und kommt dort niemals am L3 Interface an. Folglich ist diese regel überflüssiger Unsinn und kann entfallen.
- Regel 3 wäre OK wenn .100 der VM Host ist
- Regel 4 ist ebenfalls OK
Ansonsten sind die regeln aber syntaktisch richtig.
Liegt vermutlich daran das die Winblows Firewall doch noch aktiv ist und ICMP (Ping) wie üblich per Default blockt. Zusätzlich blockt sie per default ja auch noch jeglichen Fremdtraffic aus anderen IP Netzen.
Wireshark wäre hier dein Freund, oder....
Indem du mal mit einer Regel das gesamte Netz VLAN 50 und 60 freigibst jeweils auf beiden Interfaces und dann statt VM Host einfach mal das Switch Layer 3 Interface anpingst.
Klappt das fehlerfrei (wovon mal mal ausgehen kann) dann kannst du dir sicher sein das es an der Firewall liegt !
Hallo.
Ok, ich habe die Regeln nochmal durchgesehen -- und ja: ich hatte tatsächlich vergessen anzugeben, welche IP wohin gehört. Aber ihr habt es richtig rekonstruiert.
Also: Subnetz 10.30.10.0/24 ist VLAN 50 und 10.30.20.0/24 ist VLAN 60
Der Server 10.30.10.100 in VLAN.50 soll für das gesamte 10.30.20.0/24 zur Verfügung stehen.
Was mich wundert: Wenn ich die Bindung an diese Regeln aufhebe und *alles* zulasse (wie oben beschrieben: neue ACE mit Port, Quelle Ziel auf beliebig) klappt auch der PING. Von daher muss es ja offenbar an den ACE-Regeln und nicht an den den Firewall-Regeln liegen.
Ich kann das auch "live" machen: Sobald ich z.B. VLAN 50 wieder mit seinen ursprünglichen Settings verbinde, kommt der ping auch in dem Moment nicht mehr durch. Genauso, wenn ich das mit VLAN 60 mache.
Nun habe ich tatsächlich gerade mal das gemacht, was du oben vorgeschlagen hast: Regel 2 (die mit dem angeblichen Blödsinn) entfernt -- Ergebnis: Ich kann keine IP mehr im eigenen Segment anpingen (auch nicht das gateway im eigenen Subnet), bin aber weiterhin online! (z.B. https läuft ...)
Danach habe Regel 3 so aufgebohrt wie du meintest und jeweils das komplette andere Subnet anstelle der nur einen einzigen IP freigeben. Ergebnis: Damit geht es halbwegs. Der Ping kommt aber dann jeweils nur bis zu beiden Gateway-IPs des Routers aber nicht bis zum Client. Verstehe ich nicht. Erst wenn ich wieder alles auf beliebig stelle, geht es sofort wieder.
Schöne Grüße.
Ok, ich habe die Regeln nochmal durchgesehen -- und ja: ich hatte tatsächlich vergessen anzugeben, welche IP wohin gehört. Aber ihr habt es richtig rekonstruiert.
Also: Subnetz 10.30.10.0/24 ist VLAN 50 und 10.30.20.0/24 ist VLAN 60
Der Server 10.30.10.100 in VLAN.50 soll für das gesamte 10.30.20.0/24 zur Verfügung stehen.
Was mich wundert: Wenn ich die Bindung an diese Regeln aufhebe und *alles* zulasse (wie oben beschrieben: neue ACE mit Port, Quelle Ziel auf beliebig) klappt auch der PING. Von daher muss es ja offenbar an den ACE-Regeln und nicht an den den Firewall-Regeln liegen.
Ich kann das auch "live" machen: Sobald ich z.B. VLAN 50 wieder mit seinen ursprünglichen Settings verbinde, kommt der ping auch in dem Moment nicht mehr durch. Genauso, wenn ich das mit VLAN 60 mache.
Nun habe ich tatsächlich gerade mal das gemacht, was du oben vorgeschlagen hast: Regel 2 (die mit dem angeblichen Blödsinn) entfernt -- Ergebnis: Ich kann keine IP mehr im eigenen Segment anpingen (auch nicht das gateway im eigenen Subnet), bin aber weiterhin online! (z.B. https läuft ...)
Danach habe Regel 3 so aufgebohrt wie du meintest und jeweils das komplette andere Subnet anstelle der nur einen einzigen IP freigeben. Ergebnis: Damit geht es halbwegs. Der Ping kommt aber dann jeweils nur bis zu beiden Gateway-IPs des Routers aber nicht bis zum Client. Verstehe ich nicht. Erst wenn ich wieder alles auf beliebig stelle, geht es sofort wieder.
Schöne Grüße.
Was ist ACE ?? Normalerweise ist das ein Saft...Orangen mit Karotten ?!
Kann das sein das du fälschlicherweise diese ACL auf die Layer 2 Switchports gelegt hast statt auf das Layer 3 Interface des Switches ?
Dann wäre das falsche Verhalten zu erklären ! Und auch das restliche komische Verhalten.
Lokale Layer 2 Traffic rennt doch nicht durchs Router Interface. Das das Blödsinn ist und wäre sollte auch sicher dir einleuchten. Es muss da ja nur rüber wenn es in fremde IP netze will.
Fillterst du allerdings auf Layer 2 am Switchport dann greift das.
Genau diese ACL auf einem SG250 (L3 Port !) funktioniert hier fehlerlos !
Ergebnis: Ich kann keine IP mehr im eigenen Segment anpingen
Dann ist grundsätzlich etwas falsch bei dir im Setup !!!Kann das sein das du fälschlicherweise diese ACL auf die Layer 2 Switchports gelegt hast statt auf das Layer 3 Interface des Switches ?
Dann wäre das falsche Verhalten zu erklären ! Und auch das restliche komische Verhalten.
Lokale Layer 2 Traffic rennt doch nicht durchs Router Interface. Das das Blödsinn ist und wäre sollte auch sicher dir einleuchten. Es muss da ja nur rüber wenn es in fremde IP netze will.
Fillterst du allerdings auf Layer 2 am Switchport dann greift das.
Genau diese ACL auf einem SG250 (L3 Port !) funktioniert hier fehlerlos !
zu den Abkürzungen: Access Control Lists (ACLs) und Access Control Entries (ACEs). Ich schmeiße das ständig durcheinander, weil es im Switch auch direkt untereinander steht.
Wo sehe ich das mit dem Layer 2? Es sollte alles auf Layer3 stehen.
Ich sehe in der Übersicht jedenfalls eindeutig:
Systembetriebsmodus: L3-Modus
Ich habe es gerade noch weiter eingrenzen können. Wenn ich VLAN.60 an die o.g. eingegrenzten Settings binde und VLAN.50 von "beliebig" auf die Eingrenzung umstelle, passiert's. In dem Moment kommt der PING dann nicht mehr bis zum Client durch. ping geht aber weiterhin mit den Gateway-Adressen. Danke nochmal für einen Tipp...
Wo sehe ich das mit dem Layer 2? Es sollte alles auf Layer3 stehen.
Ich sehe in der Übersicht jedenfalls eindeutig:
Systembetriebsmodus: L3-Modus
Ich habe es gerade noch weiter eingrenzen können. Wenn ich VLAN.60 an die o.g. eingegrenzten Settings binde und VLAN.50 von "beliebig" auf die Eingrenzung umstelle, passiert's. In dem Moment kommt der PING dann nicht mehr bis zum Client durch. ping geht aber weiterhin mit den Gateway-Adressen. Danke nochmal für einen Tipp...
Hi.
Die Sache mit dem Layer 2 hat mir keine Ruhe gelassen ... daher habe ich nochmal auf dem Hypervisor (hier Proxmox) gesucht und festgestellt, dass das bond0, über das die VMs mit dem Layer3-Switch verbunden sind in diesem Modus läuft:
Es gibt es aber eine zusätzliche und bisher nicht eingetragene Einstellung:
und auch
(wobei mir der Unterschied noch nicht ganz klar ist).
Ich habe es noch nicht ausprobiert .... aber wenn da das Problem liegt, kann ich lange auf dem Switch suchen.... ?!
Die Sache mit dem Layer 2 hat mir keine Ruhe gelassen ... daher habe ich nochmal auf dem Hypervisor (hier Proxmox) gesucht und festgestellt, dass das bond0, über das die VMs mit dem Layer3-Switch verbunden sind in diesem Modus läuft:
auto bond0
iface bond0 inet manual
slaves eth1 eth2 eth3 eth4
bond_miimon 100
bond_mode 802.3ad
#4-fach-bond0 / LAG1Es gibt es aber eine zusätzliche und bisher nicht eingetragene Einstellung:
bond_xmit_hash_policy layer2+3bond_xmit_hash_policy layer3+4Ich habe es noch nicht ausprobiert .... aber wenn da das Problem liegt, kann ich lange auf dem Switch suchen.... ?!
802.3 ad Link Aggregation mit LACP basiert auf einem Hashing Verfahren. Über einen Hash wird entschieden auf welchem physischen Link der 2 Ports der Datentraffic übertragen wird.
Der Hash wird entweder berechnet aus:
Wichtig ist das LACP aktiviert ist sonst wird der LAB auf dem Switch nicht gebildet ! Der Switch MUSS auch zwingend für einen LAG konfiguriert sein.
Guckst du auch hier:
Netzwerk Management Server mit Raspberry Pi
Inkl. Screenshot des SG Switches.
Der Hash wird entweder berechnet aus:
- "Layer 2+3" = Mac Adresse und IP Adresse
- "Layer 3+4" = IP Adresse und TCP oder UDP Port
Wichtig ist das LACP aktiviert ist sonst wird der LAB auf dem Switch nicht gebildet ! Der Switch MUSS auch zwingend für einen LAG konfiguriert sein.
Guckst du auch hier:
Netzwerk Management Server mit Raspberry Pi
Inkl. Screenshot des SG Switches.
Hi. Ja, das LAG funktioniert ja bereits. Sorry, das war etwas unklar formuliert.
Mir ging es jetzt eher um die Frage, was der Hypervisor macht/reagiert, wenn die "layer 2+3" Option ganz fehlt. Es würde ja alles zusammen passen. Ich habe auch mittlerweile gelesen, dass der Modus 3+4 nicht 100%ig mit 803.ad kompatibel ist?!? Kann aber nicht beurteilen, welcher Modus für uns dann ggf der bessere bzw notwendige ist.
Mir ging es jetzt eher um die Frage, was der Hypervisor macht/reagiert, wenn die "layer 2+3" Option ganz fehlt. Es würde ja alles zusammen passen. Ich habe auch mittlerweile gelesen, dass der Modus 3+4 nicht 100%ig mit 803.ad kompatibel ist?!? Kann aber nicht beurteilen, welcher Modus für uns dann ggf der bessere bzw notwendige ist.
2+3 ist mehr oder minder Standard bei den meisten Switch Herstellern. 3+4 schafft eine etwas mehr granularere verteilung auf den Links je nach Traffic Profil.
Das hängt aber immer von Anwendungen und Anzahl und Struktur von IP Adressen und Mac Adressen im netz ab.
Es ist auch egal ob die eine Seite den Hash so oder die andere Seite so berechnet.
Der Switch (oder host auf der anderen Seite) merkt sich immer nur die Mac Adressen und forwardet die auf dem physischen Link den der Hash vorgegeben hat. Der geht also immer nach dem physischen Port.
Es gibt kein Balancing, deshalb ist die Verteilung bei solchen LAGs niemals homogen.
Was der Hypervisor macht/reagiert, wenn die "layer 2+3" Option ganz fehlt muss dir das Handbuch des Hypervisors beantworten. Da kann man nur spekulieren... Ist das vmWare ?? Dann gilt das:
https://kb.vmware.com/s/article/1004048
Das hängt aber immer von Anwendungen und Anzahl und Struktur von IP Adressen und Mac Adressen im netz ab.
Es ist auch egal ob die eine Seite den Hash so oder die andere Seite so berechnet.
Der Switch (oder host auf der anderen Seite) merkt sich immer nur die Mac Adressen und forwardet die auf dem physischen Link den der Hash vorgegeben hat. Der geht also immer nach dem physischen Port.
Es gibt kein Balancing, deshalb ist die Verteilung bei solchen LAGs niemals homogen.
Was der Hypervisor macht/reagiert, wenn die "layer 2+3" Option ganz fehlt muss dir das Handbuch des Hypervisors beantworten. Da kann man nur spekulieren... Ist das vmWare ?? Dann gilt das:
https://kb.vmware.com/s/article/1004048
Es ist Proxmox -- dahinter steckt ein "ganz normales" Debian. Ich kann aber im Schwesterforum nochmal danach fragen. Vielen Dank bis hierhin.
Ich nehme an, dass das Problem hier liegt und der Hypervisor nur Layer2 macht ...
Ich nehme an, dass das Problem hier liegt und der Hypervisor nur Layer2 macht ...
Mit "nur L2" meinst du das Hashing im LAG oder was ?
Routen tut ja ein Hypervisor niemals...muss er ja nicht. Auch nicht in deinem Design.
Wenn du allerdings VMs in unterschidlichen VLANs hast dann muss es einen vSwitch auf dem Hyper
Routen tut ja ein Hypervisor niemals...muss er ja nicht. Auch nicht in deinem Design.
Wenn du allerdings VMs in unterschidlichen VLANs hast dann muss es einen vSwitch auf dem Hyper
Ok, ich habe die Option "3+4" gestern Abend auf dem Proxmox-Server eingetragen und die Kiste neu gestartet. Jetzt klappt es tatsächlich! Das Problem ist gelöst ... super! Besten Dank.
Tja, das war offenbar doch noch nicht des Rätsels Lösung. Heute Morgen dachte ich noch: Super! Problem gelöst -- aber dann stellte ich fest, dass damit plötzlich auch der Zugriff von einem weiteren VLAN auf die IP möglich war, für die definitiv keine Regel existiert (bzw alles verboten). Ich habe es daher zunächst auf Layer2 zurückgestellt ... dafür gehen mir jetzt die Ideen aus, wonach ich suchen soll .
Hallo aqui.
Kannst du mir nochmal sagen, was du mit der Aussage meintest:
Ich habe es so eingestellt, dass die ACL nur an die VLANs gebunden sind. Ports sind nicht einzeln nochmals an die Regeln gebunden.
Ist das der Fehler? Oder muss das bond.0 (4er LAG) nochmal selbst an die ACL gebunden werden??
Zudem habe ich es so verstanden, dass mit der Umstellung auf den L3-Mode jeder Port im L3 Modus arbeitet, daher verstehe ich auch den zweiten Teil deiner Antwort nicht (bzw wüsste gerne, wo ich das prüfen kann)
Besten Dank nochmal für Klärung ;)
Kannst du mir nochmal sagen, was du mit der Aussage meintest:
Zitat von @aqui:
Kann das sein das du fälschlicherweise diese ACL auf die Layer 2 Switchports gelegt hast statt auf das Layer 3 Interface des Switches ?
Dann wäre das falsche Verhalten zu erklären ! Und auch das restliche komische Verhalten.
Kann das sein das du fälschlicherweise diese ACL auf die Layer 2 Switchports gelegt hast statt auf das Layer 3 Interface des Switches ?
Dann wäre das falsche Verhalten zu erklären ! Und auch das restliche komische Verhalten.
Ich habe es so eingestellt, dass die ACL nur an die VLANs gebunden sind. Ports sind nicht einzeln nochmals an die Regeln gebunden.
Ist das der Fehler? Oder muss das bond.0 (4er LAG) nochmal selbst an die ACL gebunden werden??
Zudem habe ich es so verstanden, dass mit der Umstellung auf den L3-Mode jeder Port im L3 Modus arbeitet, daher verstehe ich auch den zweiten Teil deiner Antwort nicht (bzw wüsste gerne, wo ich das prüfen kann)
Besten Dank nochmal für Klärung ;)
Die dem VLAN zugeordenten Ports arbeiten rein nur auf Layer 2 Basis (Mac Adresse) können aber, entsprechende Konfig vorausgesetzt, auch auf Layer 3 Filtern.
Normal tun sie das nicht, denn in der regel filtert man den IP Traffic immer am Router Bein, sprich also am virtuellen L3 Interface was der Switch in dieses VLAN via Backplane hängt.
Du musst natürlich den 4er LAG auf dem Switch als "Dynamic LAG" einrichten. Der dann damit erzeugte virtuelle "ch1" Port (ch = Channel von Ciscos Port Channel) muss auf den Status "Active" gehen wenn am anderen Ende auch ein LACP LAG angeschlossen ist. Wenn er das nicht tut ist der LAG nicht aktiv !
Dem ch1 Port weisst du dann entweder Tagged oder untagged einem VLAN zu. Der Switch pushed dann diese ch1 Konfig automatisch auf alle 4 Ports !
Siehe hier: Netzwerk Management Server mit Raspberry Pi (Screenshot SG Switch !)
Bei L3 Switches ist es wie bei L2 Switches: Die Ports die du fest einem VLAN zuordnest, egal ob tagged oder untagged, bilden eine vollkommen von den Restports getrennte Switchdomain. Sprich sie sind vollkommen separiert, quasi also als ob du einen physisch getrennten Switch verwendest.
In dieser separierten Switchdomain arbeiten die zugeordneten Ports rein auf Layer 2 (Forwarding nach mac Adresse).
Der L3 Switch "hängt" in diese L2 Doamin über die Backplane ein virtuelles Router Bein. Genau so als ob du an einen Port einen Router klemmst. Dieser Port hält die IP Adresse und hier muss auch die Filterliste aktiviert werden.
Klar, denn nur hier wird ja der Layer 3 IP Traffic verwurstet.
Irgendwo ist vermutlich was faul in deiner LAG Konfig. Möglich auch das du von einer Seite tagged gehst aber untagged auf der anderen was dann natürlich fehlschlägt. Dazu müsste man auch die Serverseite kennen.
In diesem Tutorial findest du mehr dazu was Server anbetrifft:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Du solltest ggf. mal hier die LAG Konfig und auch deren ch1 Settings posten als Screenshot.
Normal tun sie das nicht, denn in der regel filtert man den IP Traffic immer am Router Bein, sprich also am virtuellen L3 Interface was der Switch in dieses VLAN via Backplane hängt.
Ich habe es so eingestellt, dass die ACL nur an die VLANs gebunden sind.
Das wäre auch so genau richtig....Oder muss das bond.0 (4er LAG) nochmal selbst an die ACL gebunden werden??
Nein, das wäre auch nicht möglich, da Bonding ja rein eine Layer 2 Technik ist (Mac basierend)Du musst natürlich den 4er LAG auf dem Switch als "Dynamic LAG" einrichten. Der dann damit erzeugte virtuelle "ch1" Port (ch = Channel von Ciscos Port Channel) muss auf den Status "Active" gehen wenn am anderen Ende auch ein LACP LAG angeschlossen ist. Wenn er das nicht tut ist der LAG nicht aktiv !
Dem ch1 Port weisst du dann entweder Tagged oder untagged einem VLAN zu. Der Switch pushed dann diese ch1 Konfig automatisch auf alle 4 Ports !
Siehe hier: Netzwerk Management Server mit Raspberry Pi (Screenshot SG Switch !)
Zudem habe ich es so verstanden, dass mit der Umstellung auf den L3-Mode jeder Port im L3 Modus arbeitet
Nein, das ist vollkommen falsch !Bei L3 Switches ist es wie bei L2 Switches: Die Ports die du fest einem VLAN zuordnest, egal ob tagged oder untagged, bilden eine vollkommen von den Restports getrennte Switchdomain. Sprich sie sind vollkommen separiert, quasi also als ob du einen physisch getrennten Switch verwendest.
In dieser separierten Switchdomain arbeiten die zugeordneten Ports rein auf Layer 2 (Forwarding nach mac Adresse).
Der L3 Switch "hängt" in diese L2 Doamin über die Backplane ein virtuelles Router Bein. Genau so als ob du an einen Port einen Router klemmst. Dieser Port hält die IP Adresse und hier muss auch die Filterliste aktiviert werden.
Klar, denn nur hier wird ja der Layer 3 IP Traffic verwurstet.
Irgendwo ist vermutlich was faul in deiner LAG Konfig. Möglich auch das du von einer Seite tagged gehst aber untagged auf der anderen was dann natürlich fehlschlägt. Dazu müsste man auch die Serverseite kennen.
In diesem Tutorial findest du mehr dazu was Server anbetrifft:
VLANs über 802.1q Trunk auf Windows und Linux Rechnern realisieren
Du solltest ggf. mal hier die LAG Konfig und auch deren ch1 Settings posten als Screenshot.
Hi Aqui.
Wow -- recht herzlichen Dank für deine unermüdliche Arbeit und die sehr guten Erklärungen!!! Das bringt mich wirklich weiter. (Ich mache die IT hier "nebenbei" und muss mir das ganze (Halb)wissen selbst aneignen .. . da sind solche Erklärungen Gold wert!)
Also ich habe auf den Cisco geschaut und gesehen, dass...
Es gibt also ausschließlich statische IPs und keine dynamische.
Die LAG-Einstellungen auf der Cisco-Seite sehen mir aber richtig aus:
Auf der Proxmox-Seite sieht es im Moment so aus:
und dann kommen die ganzen anderen vmbridges, die alle (bis auf die Nummer) identisch aussehen wie:
Die VMs im Proxmox greifen dann auf die vmbr2 ... zu; das dürfte dann ja untagged sein!
Wow -- recht herzlichen Dank für deine unermüdliche Arbeit und die sehr guten Erklärungen!!! Das bringt mich wirklich weiter. (Ich mache die IT hier "nebenbei" und muss mir das ganze (Halb)wissen selbst aneignen .. . da sind solche Erklärungen Gold wert!)
Also ich habe auf den Cisco geschaut und gesehen, dass...
Die LAG-Einstellungen auf der Cisco-Seite sehen mir aber richtig aus:
Auf der Proxmox-Seite sieht es im Moment so aus:
auto bond0
iface bond0 inet manual
slaves eth1 eth2 eth3 eth4
bond_miimon 100
bond_mode 802.3ad
bond_xmit_hash_policy layer2
#4-fach-bond0 / LAG1
auto vmbr0
iface vmbr0 inet static
address 192.168.10.255
netmask 255.255.255.0
gateway 192.168.10.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxage 0
bridge_ageing 0
bridge_maxwait 0
# direkt an FritzBoxund dann kommen die ganzen anderen vmbridges, die alle (bis auf die Nummer) identisch aussehen wie:
auto vmbr2
iface vmbr2 inet manual
bridge_ports bond0.2
bridge_stp off
bridge_fd 0
bridge_maxage 0
bridge_ageing 0
bridge_maxwait 0
#Subnet 1Die VMs im Proxmox greifen dann auf die vmbr2 ... zu; das dürfte dann ja untagged sein!
Es gibt also ausschließlich statische IPs und keine dynamische.
Sehr gut. So sollte es auch sein auf einem Router ! Die LAG-Einstellungen auf der Cisco-Seite sehen mir aber richtig aus:
Das stimmt soweit was den LAG selber anbetrifft.Die Kardinalsfrage ist jetzt ob das daraus resultierende Interface "LAG1" jetzt tagged oder untagged gesetzt ist für die VLANs die darüber laufen sollen ??
Da fehlt leider der Screenshot.
Die VMs im Proxmox greifen dann auf die vmbr2 ... zu; das dürfte dann ja untagged sein!
Ja, aber vmbr2 MUSS selber tagged sein !Klar, denn der Server muss ja dort den VLAN Tag 2 mitsenden damit der Switch wieder entscheiden kann in welches VLAN dieser Traffic geforwardet werden soll um ins richtige VLAN und damit auch zur richtigen VLAN Gateway IP am Layer 3 Switch zu kommen.
Nur so kann das Paket vom Proxmox ja wieder dem richtigen VLAN auf der Switchseite zugeordnet werden !
Wenn du ganz sicher gehen willst ob der Server auch wirklich richtig tagged dann siehst du dir den Server Port mal mit dem Wireshark Sniffer an !
Hier mal am Beispiel eines VLAN 14 Tags wie es im Wireshark aussehen muss:
Ohne entsprechenden VLAN Tag kann ja sowohl der Switch als auch der Server die Pakete nicht mehr dem richtigen VLAN oder Serverport zuweisen. Klar, ohne Tag keine Info....
Du musst also sicherstellen das:
- Der Switchport "LAG1" getaggt ist für alle VLANs die an den Server gehen sollen
- Der Server alle virtuellen VLAN Interfaces auch tagged
Es ist zu vermuten das hier bei dir der Fehler liegt das du dort mit dem Tagging am LAG1 Interface irgendwas falsch machst.
Du hast ja hier vermutlich eine Kombination zw. VLAN Tagging und Bonding auf dem Server, oder ?
Sprich das Bonding Interface hat Subinterfaces bond0:10, bond0:20...usw. für die VLANs 10 und 20 als Beispiel hier mal. Ist dem so sendet dann das Bonding Interfaces entsprechende VLAN Tags mit und der LAG1 Port muss dann am Switch Tagged eingestellt sein für diese VLANs.
Das native bond0 Interface ist immer untagged und geht ins VLAN 1. Auch am Switch, das ist Default.
Wenn der Server nur Endgerät in einem einzigen VLAN ist dann entfällt dort natürlich das Tagging auf dem bond0 Interface.
Da fehlt leider der Screenshot.
Hier ist er:
Der Zugriff innerhalb der VMs klappt ja problemlos. Das sieht dann z.B. so aus:
Ich stelle da z.B. direkt vmbr2 ein und erhalte die richtige IP im richtigen Subnet. Bisher klappte auf diesem Weg immer alles ... nicht richtig?
Ich stelle da z.B. direkt vmbr2 ein und erhalte die richtige IP im richtigen Subnet. Nicht richtig?
Doch. Das ist dann ein Indiz das es richtig funktioniert.Kannst du dann auch entsprechend die Switch Gateway (VLAN) IP anpingen ?
Und....auch die Gateway anderer VLAN Interfaces auf dem Switch ?
Ggf. letzteres mal mit einem Traceroute um zu sehen das das die richtigen IP L3 Hops nimmt !
Ja, in kann in jedem VLAN sein Gateway (und alle Clients, die sich im Segment befinden) anpingen. Das klappt alles. Ich komme auf kein anderes GW in anderen VLANs/Subnetzen, da die ja per ACL auch nicht erlaubt sind.
Ein traceroute auf einen Server (im erlaubten anderen Subnetz) sieht z.B. so aus (aus dem Subnet 10.16.2.0/24 --> 10.16.1.0/24)
Ein traceroute auf einen Server (im erlaubten anderen Subnetz) sieht z.B. so aus (aus dem Subnet 10.16.2.0/24 --> 10.16.1.0/24)
Dieser Port hält die IP Adresse und hier muss auch die Filterliste aktiviert werden.
Hast du da auch den Befehl vial CLI im Kopf? Kann ich nochmal prüfen...Ja, in kann in jedem VLAN sein Gateway (und alle Clients, die sich im Segment befinden) anpingen.
OK.Ich komme auf kein anderes GW in anderen VLANs/Subnetzen, da die ja per ACL auch nicht erlaubt sind.
Deaktiviere mal diese ACLs und checke mal ob du aus allen VLANs auch die Gateways der anderen VLANs anpingen kannst.Das verifiziert ja erstmal sicher das dein Layer 3, sprich das Routing auf dem L3 Switch sauber funktioniert.
Nur damit wir sicher diese Option ausschliessen können.
Wenn das alles klappen sollte ohne ACLs, dann kann dein Fehler ja logischerweise rein nur in den Switch ACLs und deren Regelwerk liegen, klar !
Hier gibts ne gute Übersicht:
https://community.cisco.com/t5/small-business-switches/cisco-sg300-10-ho ...
und für die ACLs:
https://sbkb.cisco.com/CiscoSB/ukp.aspx?vw=1&docid=7ffabcdfa21e4e53a ...
Bei Applies to an interface musst du natürlich hier das VLAN Interface angeben !
Hi.
Ich hatte ja bereits eine weitere Regel erstellt:
"Quelle beliebig, Protokoll beliebig, Ziel beliebig" und diese ACL an die beiden VLANs gebunden. Damit ging es sofort. Ich konnte kreuz und quer pingen... (daher kann es imho auch nicht noch die Win-FW sein, die dazwischen funkt).
Gerade habe ich das hier gefunden (Buzzword “sg300 bug”) —> Beitrag in einem Forum:
“In Layer 3 Mode the switch will route between VLANs. The default VLAN 1 becomes the gateway for any additional VLANs.” Kann das das Problem sein? Wir nutzen VLAN.1 eigentlich nirgendwo!!
Ich hatte ja bereits eine weitere Regel erstellt:
"Quelle beliebig, Protokoll beliebig, Ziel beliebig" und diese ACL an die beiden VLANs gebunden. Damit ging es sofort. Ich konnte kreuz und quer pingen... (daher kann es imho auch nicht noch die Win-FW sein, die dazwischen funkt).
Gerade habe ich das hier gefunden (Buzzword “sg300 bug”) —> Beitrag in einem Forum:
“In Layer 3 Mode the switch will route between VLANs. The default VLAN 1 becomes the gateway for any additional VLANs.” Kann das das Problem sein? Wir nutzen VLAN.1 eigentlich nirgendwo!!
Dein zitierter Beitrag im Forum zeigt ja schon das Grundproblem des Users dort.
Er hat das VLAN 10 überhaupt nicht als Layer 3 Interface konfiguriert in seinem Setup !!!
Dann ist es ja logisch das das sofort scheitert !!
Ein show ip route hätte dann auch das VLAN 10 Interface zeigen müssen ala:
C 192.168.10.0/24 is directly connected, vlan 10 Das "C" steht für directly CONNECTED
Der zitierte Foren TO hat auf seinem Switch eine vollkommen blödsinnige und natürlich völlig falsche statische Route via VLAN 1 konfiguriert.
Bei solch einer unsinnigen Konfig ist es also klar das das scheitern muss.
Vergiss also besser diesen Forums Eintrag. Der TO dort hatte wohl wenig bis gar keine Ahnung von IP Routing und der Umsetzung auf Layer 3 Switches.
Da wäre es ja mal ganz spannend wie dein show ip route Output aussieht ?
Übrigens ist es auch sinnfrei eine "Quelle beliebig, Protokoll beliebig, Ziel beliebig" Regel zu implementieren. Du hättest einfach die Regeln löschen oder deaktivieren müssen.
Der Switch routet auch ohne jegliche Regel fehlerlos, was ja auch sein Default ist.
Irgendwo muss in deinem Switch Setup noch ein Kardinalsfehler lauern....
Er hat das VLAN 10 überhaupt nicht als Layer 3 Interface konfiguriert in seinem Setup !!!
Dann ist es ja logisch das das sofort scheitert !!
Ein show ip route hätte dann auch das VLAN 10 Interface zeigen müssen ala:
C 192.168.10.0/24 is directly connected, vlan 10 Das "C" steht für directly CONNECTED
Der zitierte Foren TO hat auf seinem Switch eine vollkommen blödsinnige und natürlich völlig falsche statische Route via VLAN 1 konfiguriert.
Bei solch einer unsinnigen Konfig ist es also klar das das scheitern muss.
Vergiss also besser diesen Forums Eintrag. Der TO dort hatte wohl wenig bis gar keine Ahnung von IP Routing und der Umsetzung auf Layer 3 Switches.
Da wäre es ja mal ganz spannend wie dein show ip route Output aussieht ?
Übrigens ist es auch sinnfrei eine "Quelle beliebig, Protokoll beliebig, Ziel beliebig" Regel zu implementieren. Du hättest einfach die Regeln löschen oder deaktivieren müssen.
Der Switch routet auch ohne jegliche Regel fehlerlos, was ja auch sein Default ist.
Irgendwo muss in deinem Switch Setup noch ein Kardinalsfehler lauern....
Hi. Ok, dann war das auch nicht die Ursache -- ich stochere im Nebel
Hier kommt das, was unser L3 dazu meint:
VLAN.11 ist bei uns ein VLAN auf das alle Subnetze zugreifen können müssen. Das ist der einzige Eintrag, der aus der Reihe fällt.
Das funktioniert auch in allen Subnetzen; der Zugriff ist gewährleistet.
Dass ich die ACL auch ganz hätte weglassen können, war klar. Ich könnte aber diese Regel jetzt Stück für Stück einschränken und dann schauen, ab wann es scheitert. Blöd am SG300 finde ich, dass man die Regeln nicht ändern kann, solange sie an ein VLAN o.ä. gebunden sind. Daher muss man immer zunächst die Bindung aufheben, kann die Regeln dann ändern, nur um sie anschließend wieder an das VLAN zu binden. Viel Herumgeklicke...
Hier kommt das, was unser L3 dazu meint:
cisco-sg300-28# show ip route
Maximum Parallel Paths: 1 (1 after reset)
IP Forwarding: enabled
Codes: > - best, C - connected, S - static
S 0.0.0.0/0 [1/1] via 10.16.1.254, 108:00:34, vlan 11
C 10.16.1.0/24 is directly connected, vlan 11
C 10.16.2.0/24 is directly connected, vlan 2
C 10.20.100.0/24 is directly connected, vlan 100
C 10.20.200.0/24 is directly connected, vlan 200
C 10.30.10.0/24 is directly connected, vlan 50
C 10.30.20.0/24 is directly connected, vlan 60
C 10.30.51.0/24 is directly connected, vlan 51
C 10.30.52.0/24 is directly connected, vlan 52
C 10.30.53.0/24 is directly connected, vlan 53
C 192.168.1.0/24 is directly connected, vlan 1 Das funktioniert auch in allen Subnetzen; der Zugriff ist gewährleistet.
Dass ich die ACL auch ganz hätte weglassen können, war klar. Ich könnte aber diese Regel jetzt Stück für Stück einschränken und dann schauen, ab wann es scheitert. Blöd am SG300 finde ich, dass man die Regeln nicht ändern kann, solange sie an ein VLAN o.ä. gebunden sind. Daher muss man immer zunächst die Bindung aufheben, kann die Regeln dann ändern, nur um sie anschließend wieder an das VLAN zu binden. Viel Herumgeklicke...
VLAN.11 ist bei uns ein VLAN auf das alle Subnetze zugreifen können müssen.
Und dort im VLAN 11 ist vermutlich dann auch der Internet Router mit der IP Adresse 10.16.1.254, richtig ?Das "S" (Static) ist dann die statische Default Route ins Internet.
Soweit ist das alles richtig...sofern denn die 10.16.1.254 der Internet Router ist.
Ich könnte aber diese Regel jetzt Stück für Stück einschränken und dann schauen, ab wann es scheitert.
Nein, das geht nicht.Du kannst nicht zuerst alles erlauben und dann einschränken. Die Reihenfolge ist nicht trivial hier.
Im Regelwerk gilt immer "First match wins !".
Bedeutet sobald eine Regel einen Match hat, also positiv "passt", werden alle folgenden Regeln NICHT mehr abgearbeitet.
Ein permit any any muss also immer erst am Schluss, NACH den deny ... Regeln stehen !
Soweit ist das alles richtig...sofern denn die 10.16.1.254 der Internet Router ist.
Ja, so ist es. Das ist ein IPFire, der das erledigt.Wie gesagt: Es lief ja bisher auch alles. Das Problem mit dem Routing habe ich erst bemerkt, als ich die Ausnahme von oben eintragen wollte, die einen Zugriff zusätzlich innerhalb von zwei VLANs ermöglichen sollte. Dabei kam dann ja auch zutage, dass auch der Zugriff im gleichen Subnetz klappen sollte und nicht erst per Regel erlaubt werden muss. Ich nehme an, dass beides eng zusammen hängt und damit zu tun hat, dass "etwas" über L3 läuft, was eigentlich auf L2 gehört oder umgekehrt?
Du kannst nicht zuerst alles erlauben und dann einschränken. Die Reihenfolge ist nicht trivial hier.
Ne, so meinte ich das auch nicht. Es war so gedacht: Regel "permit all" einschränken und schauen bis zu welchem Punkt es nicht mehr geht.
Ja, das hängt zusammen und dort ist vermutlich auch der grundsätzliche Fehler.
Der Zugriff von Endgeräten in einem gemeinsamen VLAN hat niemals was mit dem L3 Interface zu tun ! Warum auch ?
Der Traffic bleibt ja im lokalen VLAN und die Geräte regeln das ausschliesslich nur auf Mac Adress Basis.
Kein IP Paket kommt so je beim VLAN Interface an !
Deshalb ja der Verdacht das du die ACL eben fälschlicherweise auf die Layer 2 VLAN Switchports aktiviert hast statt auf dem VLAN Interface wo sie eigentlich hingehören.
Denn die ACL soll ja nur greifen wenn IP Pakete das lokale VLAN verlassen und damit in andere VLANs oder das Internet gehen. Nur dann werden sie ja über das L3 Interface (VLAN Interface) des Switches geroutet.
Bedenke auch das das Regelwerk am Interface nur inbound arbeitet also alles was vom Draht in das L3 Interface (VLAN Interface) hineingeht.
Am Beispiel eines SG250 wo es sauber klappt sieht das so aus:
(VLAN 1 darf überall hin außer VLAN 100)
1.) ACL einrichten
2.) Regelwerk erstellen:
3.) Ans VLAN Interface binden:
Der Zugriff von Endgeräten in einem gemeinsamen VLAN hat niemals was mit dem L3 Interface zu tun ! Warum auch ?
Der Traffic bleibt ja im lokalen VLAN und die Geräte regeln das ausschliesslich nur auf Mac Adress Basis.
Kein IP Paket kommt so je beim VLAN Interface an !
Deshalb ja der Verdacht das du die ACL eben fälschlicherweise auf die Layer 2 VLAN Switchports aktiviert hast statt auf dem VLAN Interface wo sie eigentlich hingehören.
Denn die ACL soll ja nur greifen wenn IP Pakete das lokale VLAN verlassen und damit in andere VLANs oder das Internet gehen. Nur dann werden sie ja über das L3 Interface (VLAN Interface) des Switches geroutet.
Bedenke auch das das Regelwerk am Interface nur inbound arbeitet also alles was vom Draht in das L3 Interface (VLAN Interface) hineingeht.
Am Beispiel eines SG250 wo es sauber klappt sieht das so aus:
(VLAN 1 darf überall hin außer VLAN 100)
1.) ACL einrichten
2.) Regelwerk erstellen:
3.) Ans VLAN Interface binden:
Aha -- jetzt sehe ich einen Unterschied!
Deine Default-Action im letzten Bild ist "Deny any" ... ich aber habe da aber "Permit any" (was auch irgendwie Quatsch ist, wenn man's bedenkt...?!).
Aber kann unser seltsames Routing-Verhalten daran liegen?
Deine Default-Action im letzten Bild ist "Deny any" ... ich aber habe da aber "Permit any" (was auch irgendwie Quatsch ist, wenn man's bedenkt...?!).
Aber kann unser seltsames Routing-Verhalten daran liegen?
Deine Default-Action im letzten Bild ist "Deny any" ...
Ja, das ist auch bei anderen Herstellern und Ciscos Catalys Serie immer Default.Gut möglich das du mit der "inversen Logik" dir da ein Problem schaffst. Damit ist die ganze ACL Logik dann ja umgedreht.
Teste das mal...
Dein Routing ist ja nicht seltsam. Ohne ACL rennt es ja wie es soll, da ist also alles OK. Irgendwas stimmt mit deinen ACLs nicht.
Hi. Ich habe für die beiden VLANs gerade die Bindung an die Regeln auf "Deny any" geändert. Leider geht ein ping weiterhin nicht durch. Sobald ich es für beide VLANs wieder auf "alles erlaubt" umstelle, kommt der ping sofort wieder an.
Es ist zum Verzweifeln.
Hier nochmal die derzeitigen Regeln (ingress) der beiden VLANs:
Wie schon mehrfach erwähnt: Regeln 91 und 11 brauche ich hier, damit das Subnet die Rechner im eigenen Subnet sehen kann.
Und die Regeln 92 und 12 sind diejenigen, die einfach nicht greifen wollen... ich hatte die auch bereits umgekehrt formuliert bzw zugeordnet, aber so scheint es ja im Prinzip richtig zu sein?!?
Daher nochmal die Rückfrage zu deiner Vermutung:
Es ist zum Verzweifeln.
Hier nochmal die derzeitigen Regeln (ingress) der beiden VLANs:
Extended IP access list VLAN50
permit ip 10.30.20.0 0.0.0.255 10.16.1.0 0.0.0.255 ace-priority 89
permit ip 10.30.20.0 0.0.0.255 10.30.20.0 0.0.0.255 ace-priority 91
permit ip 10.30.10.0 0.0.0.255 10.30.20.0 0.0.0.255 ace-priority 92
deny ip any 10.0.0.0 0.255.255.255 ace-priority 95
Extended IP access list VLAN60
permit ip 10.30.10.0 0.0.0.255 10.16.1.0 0.0.0.255 ace-priority 10
permit ip 10.30.10.0 0.0.0.255 10.30.10.0 0.0.0.255 ace-priority 11
permit ip 10.30.20.0 0.0.0.255 10.30.10.0 0.0.0.255 ace-priority 12
deny ip any 10.0.0.0 0.255.255.255 ace-priority 20Wie schon mehrfach erwähnt: Regeln 91 und 11 brauche ich hier, damit das Subnet die Rechner im eigenen Subnet sehen kann.
Und die Regeln 92 und 12 sind diejenigen, die einfach nicht greifen wollen... ich hatte die auch bereits umgekehrt formuliert bzw zugeordnet, aber so scheint es ja im Prinzip richtig zu sein?!?
Daher nochmal die Rückfrage zu deiner Vermutung:
Deshalb ja der Verdacht das du die ACL eben fälschlicherweise auf die Layer 2 VLAN Switchports aktiviert hast statt auf dem VLAN Interface wo sie eigentlich hingehören.
Wo kann ich das sehen? Gerne auch per CLI...
Hallo,
https://en.wikipedia.org/wiki/Ping_(networking_utility)
https://lists.debian.org/debian-user/1999/11/msg01434.html
Gruß,
Peter
Zitat von @White-Rabbit2:
Hi. Ich habe für die beiden VLANs gerade die Bindung an die Regeln auf "Deny any" geändert. Leider geht ein ping weiterhin nicht durch.
ICMP per regel denn erlaubt?Hi. Ich habe für die beiden VLANs gerade die Bindung an die Regeln auf "Deny any" geändert. Leider geht ein ping weiterhin nicht durch.
https://en.wikipedia.org/wiki/Ping_(networking_utility)
https://lists.debian.org/debian-user/1999/11/msg01434.html
Wie schon mehrfach erwähnt: Regeln 91 und 11 brauche ich hier, damit das Subnet die Rechner im eigenen Subnet sehen kann.
Normalerweise können sich Rechner im eigenen Netz (z.B. 10.30.20.0/24) gegenseitig erreichen ohne das ein Router nötig ist.Gruß,
Peter
ICMP per regel denn erlaubt?
... ich habe es natürlich auch mit https:// probiert ... komme auch damit nicht durch.Normalerweise können sich Rechner im eigenen Netz (z.B. 10.30.20.0/24) gegenseitig erreichen ohne das ein Router nötig ist.
Ja, und genau da steckt in meinem Setup offenbar irgendwo ein Fehler, den ich nicht orten kann.
Hallo,
https://en.wikipedia.org/wiki/HTTPS#Difference_from_HTTP
Gruß,
Peter
Zitat von @White-Rabbit2:
... ich habe es natürlich auch mit https:// probiert ... komme auch damit nicht durch.
ICMP bzw. Ping hat nichts aber auch gar nichts mit HTTP oder HTTPS zu tun.... ich habe es natürlich auch mit https:// probiert ... komme auch damit nicht durch.
https://en.wikipedia.org/wiki/HTTPS#Difference_from_HTTP
Gruß,
Peter
Ping hat nichts aber auch gar nichts mit HTTP oder HTTPS zu tun.
Das ist schon klar. Ich meinte damit nur: neben ping <ip> habe ich aucheinen Browser mit <https://ip> bemüht, was aber nichts geändert hat
