Der Fehler liegt darin, das die Regeleinträge für beide VLANs vertauscht gehören.
Gruß von WeitDahinten
Wie meinst du das? Laut Anleitung soll es so sein, dass die kleinste Nummer zuerst abgearbeitet wird und dann “first match wins”?!
Genau. Das ist eine der Regeln nach denen Switch ACLs verarbeitet werden. Eine weitere ist die Bindung einer ACL an eine Schnittstelle. Die Doku sagt:
ACL-Bindung
Wenn eine ACL an eine Schnittstelle gebunden ist (Port, LAG oder VLAN), werden ihre ACE-Regeln auf Pakete angewendet, die an dieser Schnittstelle ankommen.
d. h. Switch ACLs können nur in eingehender Richtung (inbound/ingress) an eine Schnittstelle gebunden werden (im Gegensatz dazu können Router ACLs sowohl eingehend als auch ausgehend gebunden werden).
Wenn also Daten von VLAN A nach VLAN B erlaubt werden sollen dann muß VLAN B das erlauben.
VLAN 60 muß also einen Eintrag enthalten, das alle Daten von 10.30.10.100/32 (Quelle) nach 10.30.20.0/24 (Ziel) erlaubt werden. Im Beispiel steht es aber genau umgekehrt (Quelle und Ziel sind vertauscht). Dasselbe gilt für VLAN 50. Auch hier sind Quelle und Ziel vertauscht.
Folglich gibt es zwei Möglichkeiten das Problem zu lösen.
- Beide Einträge in der ACL belassen aber Quelle und Ziel tauschen oder
- Beide Einträge in den ACLs tauschen
Die 2. Lösungsmöglichkeit habe ich in meinem Beitrag gemeint.
Gruß von WeitDahinten
OK, danke für die Klärung. (Ich hatte gedacht, dass du die Reihenfolge von oben nach unten meintest – die scheint ja zu stimmen)
Ich werde das nochmal testen. Im Moment habe ich alles wieder auf den ursprünglichen Zustand zurück gesetzt (getrennte Subnetze/VLANs). Dazu noch ein Firmware Upgrade und einen Neustart. Kann gerade nicht weiter testen aber ich melde mich später nochmal…
Michael
kleiner Nachtrag:
Lösungsvariante 2 ist aufwendiger als Variante 1. Daher ist Variante 1 die sinnvollere.
Hallo WeitDahinten,
Der SG300 kann m.E. grundsätzlich nur inbound filtern, egal ob Layer 2 oder 3 ACLs. Das Kommando dazu lautet:
service-acl input ... im Interface Conf Mode …
und
show interfaces access-lists ...
Grüße
Muss der SG300 neu gestartet werden, wenn man an den ACL-Regeln und vor allem an der VLAN-Bindung etwas ändert? Im Moment kommt mir das so vor??!
Ein Neustart hat noch nie geschadet.
Gruß
Roland
Nein, das ist bei dieser Konfigänderung nicht nötig. Bei Moduswechsel (L2/L3), Firmware-Aktualisierung oder Jumbo-Frame Unterstützung ist ein Neustart nötig.
Kann bitte jemand, der VLAN & Subnetting aktiviert hat, auf dem Server den Befehl
route -nloslassen? Bei mir liefert das:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0Da taucht also noch die alte Netzmaske .240. von vor der Umstellung auf – scheint falsch zu sein, doch woran liegt es bzw welche Servereinstellung stimmt da nicht?
Gerade gesehen: Auch auf dem IP-Fire steckt noch eine alte Route von vor der Umstellung (2. Zeile) – warum/woher?
20:03/0 ipfire ~ # route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.1 0.0.0.0 UG 0 0 0 red0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 green0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 green0
172.16.16.0 0.0.0.0 255.255.255.0 U 0 0 0 blue0
172.16.17.0 0.0.0.0 255.255.255.0 U 0 0 0 orange0
172.16.18.0 172.16.18.2 255.255.255.0 UG 0 0 0 tun0
172.16.18.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 red0
Schöne Grüße,
Michael
Lieber Michael,
ich habe die 6.2, die von einer 5.x über 6.1 upgedatet wurde.
Bei mir sieht die Routingtabelle des Servers so aus:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
Ich glaube, wenn man kein subnetting hat, ist das so korrekt. Das müsste ich aber auch nachsehen.
Auf dem IpFire sieht die Tabelle so aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.12.1 0.0.0.0 UG 0 0 0 red0
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 green0
172.16.16.0 0.0.0.0 255.255.255.0 U 0 0 0 blue0
172.16.18.0 172.16.18.2 255.255.255.0 UG 0 0 0 tun0
172.16.18.2 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
192.168.12.0 0.0.0.0 255.255.255.0 U 0 0 0 red0
192.168.12.1 0.0.0.0 255.255.255.255 UH 0 0 0 red0
L.G.,
Christoph G.
Hallo.
Ja, ohne Subnetting ist das so richtig wie bei dir.
Meine Frage ist eher, warum ich den alten Eintrag trotz Umstellung noch habe bzw welche Einstellung fehlt, damit alles so ist, wie es mit Subnetting sein sollte.
Ich bin damals bei der Umstellung dem Wiki Artikel gefolgt.
Schöne Grüße
Michael
Hallo Michael,
Kann bitte jemand, der VLAN & Subnetting aktiviert hat, auf dem Server
den Befehlroute -n|
loslassen? Bei mir liefert das:
Kernel-IP-Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0 10.16.0.0 10.16.1.253
255.240.0.0 UG 0 0 0 eth0 10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0|Da taucht also noch die alte Netzmaske .240. von vor der Umstellung auf
– scheint falsch zu sein,
nein: ist richtig.
Du hast ja das alte 255.240.0.0 Netz „gesubnettet“ also unterteilt.
Die Netzwerkmaske ist also schon richtig: dein Netz (das gesammte) ist
255.240.0.0 „groß“.
doch woran liegt es bzw welche
Servereinstellung stimmt da nicht?
ich denke, es ist alles OK.
Be mir sieht es auch so aus:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
0.0.0.0 10.16.1.254 0.0.0.0 UG 100 0 0 eth0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.16.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
Das ist ja auch korrekt: die Default Route (0.0.0.0) ist auf den IPFire
gerichtet: willst du also irgenwohin, was nicht in deinem Netz ist, mußt
du über den IPFire raus.
Willst du in dein Netz: und hier steht korrekterweise die 255.240.0.0,
dann mußt du dich an 10.16.1.253 wenden: das ist die IP des L3 Switches
in deinem Servernetz: also die „route“ für den internen Verkehr.
Sieht gut aus.
LG
Holger
Hi Holger. Das ist ja beruhigend.
Hätte mich auch gewundert, wenn das hier nicht stimmt.
Was ich jetzt von verschiedenen Stellen gehört habe: die Regeln im L3 für den Zugriff von einem Subnetz in das gleiche Subnetz sollen angeblich überflüssig sein (oben die Regeln 91 und 11). Aber ich habe keinen Zugriff auf andere Clients im gleichen Segment, wenn ich diese Regeln lösche. Das sollte so nicht sein, da das eigentlich auf Layer2 Ebene läuft und gar nicht über den L3-Router müsste…
Ich suche weiter…
Michael
Hallo Michael,
Was ich jetzt von verschiedenen Stellen gehört habe: die Regeln im L3
für den Zugriff von einem Subnetz in das gleiche Subnetz sollen
angeblich überflüssig sein.
… sowas ignorier ich.
Die Einrichtung der Subnets wurde mit Beratung durch einen Freund von
uns, der absoluter „Switchprofi“ ist und selber Cisco FoBis gibt, gemacht.
Ich vertraue ihm: er weiß was er tut und er weiß auch genau, was wir
benötigen (in der Schule).
Deswegen: da schlafe ich ganz wunderbar mit, auch wenn „verschiedene
Stellen“ was anderes sagen.
LG
Holger
Hi Holger, ist denn bei dir die ACL auch nötig, die den Zugriff auf das eigene Subnetz erlaubt oder läuft es bei dir auch ohne? Ich bin nach wie vor nicht ganz sicher, ob ich nun einen Fehler in meiner Konfiguration habe oder woran es nun liegt, dass der L3 sich so verhält. Aufgefallen ist dieses Routing-Problem ja erst, als ich die eine Ausnahme in die ACLs aufnehmen wollte… (beide Probleme hängen aber sehr wahrscheinlich direkt zusammen)
Dass der grundsätzliche Aufbau des L3-Switches sehr solide durchdacht ist, würde ich dabei nie in Frage stellen! Es ist halt eher so, dass in meinem Setup vermutlich ein Fehler steckt, den ich bisher nicht eingrenzen kann…
Schöne Grüße,
Michael
Hallo Michael,
Hi Holger, ist denn bei dir die ACL auch nötig, die den Zugriff auf das
eigene Subnetz erlaubt oder läuft es bei dir auch ohne?
… warum sollte ich das testen?
Ich habe es eingerichtet, wie es vorgeschrieben ist, durch Leute, die
davon mehr verstehen als ich: da werde ich mich hüten dran rum zu schrauben.
LG
Holger
Hi Holger. Du verstehst mich falsch. Die Regeln, die den Zugriff innerhalb eines Subnetzes “auf sich selbst” erlauben, stehen in der ursprünglichen Doku gar nicht drin (oben wie erwähnt Regeln 91 und 11). Ich musste die bei mir ergänzen, damit der Zugriff zB vom Schüler-PC auf den Lehrer-PC überhaupt möglich war. Es kann also sehr gut sein, dass diese Regeln bei dir gar nicht existieren – es aber trotzdem bei dir klappt.
Als wir damals umgestellt haben, hatte ich das angemerkt und es wurde daraufhin als Hinweis ins neue Wiki übernommen.
Hast du denn noch Kontakt zu dem Cisco-Experten? Vielleicht kann er es mit einem Blick sehen und beantworten 
Schöne Grüße
Michael