10
VLAN Routing L3 Switch
Hallo liebes Forum,
ich habe ein Problem beim Einrichten des VLAN Routings.
Die Netzwerkstruktur habe ich vereinfacht als Bild angehängt.
VLAN 10 und 20 sind auf allen Switchen angelegt.
Auf Switch 0 habe ich die Interfaces für die beiden VLANs angelegt und eine entsprechende IP vergeben.
Die Ports zwischen den Switchen sind als Trunk definiert mit den VLANs als Tagged.
Die Ports an denen die Clients hängen sind als Access Ports konfiguriert und mit dem entsprechenden VLAN als untagged versehen.
Die Kommunikation innerhalb der VLANs funktioniert von allen Endgeräten zu allen anderen Endgeräten in dem VLAN.
Nun meine Frage: Was muss ich nun konfigurieren wenn ich möchte das Clients aus VLAN 10 mit VLAN 20 kommunizieren können, aber VLAN 20 nich mit VLAN 10 ? Ich hatte mich schon mit einer Access-Liste versucht die ich auf Switch 0 configuriert habe, das hatte aber nicht funktioniert.
Bisher habe ich keine Default Gateways an den Clients eingerichtet.
Ich habe schon mal das Internet durchgestöbert aber immer nur beispiele gefunden wo jemand alles an einem Switch konfiguriert hat oder mit einem weiteren Router gearbeitet wurde.
Gruß und danke für eure Hilfe.
D3adm4n
ich habe ein Problem beim Einrichten des VLAN Routings.
Die Netzwerkstruktur habe ich vereinfacht als Bild angehängt.
VLAN 10 und 20 sind auf allen Switchen angelegt.
Auf Switch 0 habe ich die Interfaces für die beiden VLANs angelegt und eine entsprechende IP vergeben.
Die Ports zwischen den Switchen sind als Trunk definiert mit den VLANs als Tagged.
Die Ports an denen die Clients hängen sind als Access Ports konfiguriert und mit dem entsprechenden VLAN als untagged versehen.
Die Kommunikation innerhalb der VLANs funktioniert von allen Endgeräten zu allen anderen Endgeräten in dem VLAN.
Nun meine Frage: Was muss ich nun konfigurieren wenn ich möchte das Clients aus VLAN 10 mit VLAN 20 kommunizieren können, aber VLAN 20 nich mit VLAN 10 ? Ich hatte mich schon mit einer Access-Liste versucht die ich auf Switch 0 configuriert habe, das hatte aber nicht funktioniert.
Bisher habe ich keine Default Gateways an den Clients eingerichtet.
Ich habe schon mal das Internet durchgestöbert aber immer nur beispiele gefunden wo jemand alles an einem Switch konfiguriert hat oder mit einem weiteren Router gearbeitet wurde.
Gruß und danke für eure Hilfe.
D3adm4n
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1297556949
Url: https://administrator.de/contentid/1297556949
Printed on: April 25, 2024 at 14:04 o'clock
10 Comments
Latest comment
Ich hatte mich schon mit einer Access-Liste versucht die ich auf Switch 0 configuriert habe, das hatte aber nicht funktioniert.
Wie sieht denn deine Access Liste aus und auf welchen L3 Interface hast du diese plaziert ?Bedenke das ACLs in der Regel nur inbound greifen, sprich also VOM Draht IN das L3 IP Interface
Bisher habe ich keine Default Gateways an den Clients eingerichtet.
Ooops...how come ? Gut, ohne ein lokales Gateway ist generell KEINE vlanübergreifende Kommunikation möglich, aber das ist dir sicher klar.immer nur beispiele gefunden wo jemand alles an einem Switch konfiguriert hat
Das ist auch generell üblich so und best Practise. Aus Layer 3 Sicht arbeiten die beiden Cores als ein Gateway. Ob man das physisch mit einem Full Stack realisiert oder als separate Switches im VRRP Verbund ist egal. Wichtig ist nur das die beiden L3 Switches als ein Gateway agieren.Das ist in einem Netzwerk Design essentiell wichtig, denn ansonsten hättest du einen Stillstand wenn einer der L3 Switches ausfällt. Stack oder VRRP ist also zwingend wenn Redundanz ein Thema ist !
Ein klassisches Design dazu sieht so aus:
Ein VRRP Design dazu ist hier beschrieben:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Du musst dich also entscheiden:
- Mit L3 Redundundanz = Stack oder HA Design mit VRRP
- Ohne L3 Redundnaz = Nur ein Switch darf L3 machen
1
Zitat von @aqui:
Ich habe es mit den Standard Access-Listen versucht:Ich hatte mich schon mit einer Access-Liste versucht die ich auf Switch 0 configuriert habe, das hatte aber nicht funktioniert.
Wie sieht denn deine Access Liste aus und auf welchen L3 Interface hast du diese plaziert ?access-list 10 permit 192.168.10.0 0.0.0.255
access-list 20 permit 192.168.10.0 0.0.0.255
access-list 20 permit 192.168.20.0 0.0.0.255
Liste 10 auf das Interface VLAN 10 als IN und Liste 20 als IN auf Interface VLAN 20.
So können die Clients aktuell untereinandern kommunizieren aber VLAN 10 kann nicht nach VLAN 20, da bekomme ich ein timeout.
Bedenke das ACLs in der Regel nur inbound greifen, sprich also VOM Draht IN das L3 IP Interface
Ja, ich habe nun die IP des jeweiligen VLAN Interfaces als Gateway bei den Clients eingetragen und es kann jeder mit jedem kommunizieren. Dafür brauche ich dann die funktionierende ACL damit die Clients aus VLAN 20 nicht nach VLAN 10 kommunizieren können. VLAN 10 soll aber mit VLAN 20 kommunizieren können.Bisher habe ich keine Default Gateways an den Clients eingerichtet.
Ooops...how come ? Gut, ohne ein lokales Gateway ist generell KEINE vlanübergreifende Kommunikation möglich, aber das ist dir sicher klar.immer nur beispiele gefunden wo jemand alles an einem Switch konfiguriert hat
Das ist auch generell üblich so und best Practise. Aus Layer 3 Sicht arbeiten die beiden Cores als ein Gateway. Ob man das physisch mit einem Full Stack realisiert oder als separate Switches im VRRP Verbund ist egal. Wichtig ist nur das die beiden L3 Switches als ein Gateway agieren.Das ist in einem Netzwerk Design essentiell wichtig, denn ansonsten hättest du einen Stillstand wenn einer der L3 Switches ausfällt. Stack oder VRRP ist also zwingend wenn Redundanz ein Thema ist !
Ein klassisches Design dazu sieht so aus:
Ein VRRP Design dazu ist hier beschrieben:
Mikrotik VLAN Konfiguration ab RouterOS Version 6.41
Du musst dich also entscheiden:
- Mit L3 Redundundanz = Stack oder HA Design mit VRRP
- Ohne L3 Redundnaz = Nur ein Switch darf L3 machen
aber VLAN 10 kann nicht nach VLAN 20, da bekomme ich ein timeout.
Welche ACL ist denn am IP Port VLAN 20 aktiv ??Bedenke immer das ACL nicht stateful sind ! Die sind keine Firewall. Das hast du vermutlich im jugendlichen Leichtsinn übersehen, kann das sein ?!
Du musst also sicherstellen das die Rückroute aus VLAN 20 dort auch passieren muss.
Dort muss also sowas stehen wie permit source vlan20 destination vlan 10 sonst bleibt die Rückroute da hängen !
damit die Clients aus VLAN 20 nicht nach VLAN 10 kommunizieren können.
Da widersprichst du dich dann !! Du sagst doch oben das du von VLAN 10 auf VLAN 20 willst. Wenn du die Rückroute aber nicht durchlässt ist nix mit vlan 10 nach 20 logisch. Das ist ja auch genau das Verhalten was du siehst...!hier geht es nur um ein kleines Netzwerk bei dem erstmal keine Redundanz vorgesehen ist,
OK dann auch nur ein zentraler Layer 3 Switch !!Den 2ten Switch dann rein nur als L2 Switch konfigurieren ! Keinerlei IP Interfaces in den VLANs !!
Zitat von @aqui:
Bedenke immer das ACL nicht stateful sind ! Die sind keine Firewall. Das hast du vermutlich im jugendlichen Leichtsinn übersehen, kann das sein ?!
Du musst also sicherstellen das die Rückroute aus VLAN 20 dort auch passieren muss.
Dort muss also sowas stehen wie permit source vlan20 destination vlan 10 sonst bleibt die Rückroute da hängen !
Access Liste 20 ist am Interface für VLAN 20 aktiv.aber VLAN 10 kann nicht nach VLAN 20, da bekomme ich ein timeout.
Welche ACL ist denn am IP Port VLAN 20 aktiv ??Bedenke immer das ACL nicht stateful sind ! Die sind keine Firewall. Das hast du vermutlich im jugendlichen Leichtsinn übersehen, kann das sein ?!
Du musst also sicherstellen das die Rückroute aus VLAN 20 dort auch passieren muss.
Dort muss also sowas stehen wie permit source vlan20 destination vlan 10 sonst bleibt die Rückroute da hängen !
An den Hin und Rückweg hatte ich tatsächlich schon gedacht, das wollte ich mit den zwei Einträgen in der ACL 20 bewirken.
damit die Clients aus VLAN 20 nicht nach VLAN 10 kommunizieren können.
Da widersprichst du dich dann !! Du sagst doch oben das du von VLAN 10 auf VLAN 20 willst. Wenn du die Rückroute aber nicht durchlässt ist nix mit vlan 10 nach 20 logisch. Das ist ja auch genau das Verhalten was du siehst...!hier geht es nur um ein kleines Netzwerk bei dem erstmal keine Redundanz vorgesehen ist,
OK dann auch nur ein zentraler Layer 3 Switch !!Den 2ten Switch dann rein nur als L2 Switch konfigurieren ! Keinerlei IP Interfaces in den VLANs !!
das wollte ich mit den zwei Einträgen in der ACL 20 bewirken.
Geht so nicht, denn ACL wirken immer nur inbound also VOM Netzwerk Draht IN das IP Interface hinein.Das ist mit einer ACL unmöglich, du brauchst also zwingend 2. Eine fürs eine VLAN IP Interface und die andere fürs andere.
begrenzen kann ohne die Clients in VLAN 10 zu beschränken
Ja gibt es natürlich.Deine Vorgaben waren:
- VLAN 10 darf alles
- VLAN 20 darf nicht ins VLAN 10 sonst alles
- VLAN 10 Interface keine Regel (Default muss dann auf permit any any eingestellt sein)
- VLAN 20 =>
deny ip 192.168.20.0 0.0.0.255 192.168.10.0
permit ip 192.168.20.0 0.0.0.255 any
- Fertisch
- Die erste Regel erlaubt Rücktraffic aus VLAN 20 ins VLAN 10 mit gesetztem ACK Bit so das TCP Verbindungen die aus dem VLAN 10 ins VLAN 20 initiiert wurden zurück ins VLAN 10 können
- Alles andere ins VLAN 10 blockt Regel 2
- Regel 3 erlaubt VLAN 20 zum Rest der IP Welt.
Zitat von @aqui:
Das ist mit einer ACL unmöglich, du brauchst also zwingend 2. Eine fürs eine VLAN IP Interface und die andere fürs andere.
Deine Vorgaben waren:
deny ip 192.168.20.0 0.0.0.255 192.168.10.0
permit ip 192.168.20.0 0.0.0.255 any
das wollte ich mit den zwei Einträgen in der ACL 20 bewirken.
Geht so nicht, denn ACL wirken immer nur inbound also VOM Netzwerk Draht IN das IP Interface hinein.Das ist mit einer ACL unmöglich, du brauchst also zwingend 2. Eine fürs eine VLAN IP Interface und die andere fürs andere.
begrenzen kann ohne die Clients in VLAN 10 zu beschränken
Ja gibt es natürlich.Deine Vorgaben waren:
- VLAN 10 darf alles
- VLAN 20 darf nicht ins VLAN 10 sonst alles
- VLAN 10 Interface keine Regel (Default muss dann auf permit any any eingestellt sein)
- VLAN 20 =>
deny ip 192.168.20.0 0.0.0.255 192.168.10.0
permit ip 192.168.20.0 0.0.0.255 any
- Fertisch
- Die erste Regel erlaubt Rücktraffic aus VLAN 20 ins VLAN 10 mit gesetztem ACK Bit so das TCP Verbindungen die aus dem VLAN 10 ins VLAN 20 initiiert wurden zurück ins VLAN 10 können
- Alles andere ins VLAN 10 blockt Regel 2
- Regel 3 erlaubt VLAN 20 zum Rest der IP Welt.
Ich habe es nun so ausprobiert, kann aber aus VLAN 10 nicht nach VLAN 20 da bekomme ich einen timeout, nur intern geht es. Mache ich noch etwas falsch ? Von VLAN 20 nach VLAN 10 bekomme ich ein host unreachable.
Konfig:
interface Vlan10
mac-address XXXX.XXXX.XXXX
ip address 192.168.10.1 255.255.255.0
ip access-group 110 in
!
interface Vlan20
mac-address XXXX.XXXX.XXXX
ip address 192.168.20.1 255.255.255.0
ip access-group 120 in
!
access-list 120 permit tcp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 established
access-list 120 deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255
access-list 120 permit ip 192.168.20.0 0.0.0.255 any
access-list 110 permit ip any any
Bedenke das der Zugriff aus dem VLAN 10 auf das VLAN 20 ausschliesslich nur für TCP basierte Protokolle funlktioniert und NICHT für UDP oder andere Protokolle wie ICMP (Ping, traceroute etc.)
Eine HTTP oder SSH Verbindung z.B. von einem Absender aus 10 und Ziel in 20 sollte damit sauber funktionieren !
Die 110er wäre sinnvoller wenn sie access-list 110 permit ip 192.168.10.0 0.0.0.255 any lauten würde, denn du willst ja nur VLAN 10 Traffic freigeben, oder ?
So mit deiner Schrotschussregel sind alle IPs erlaubt. OK, ist eher kosmetisch.
Eine HTTP oder SSH Verbindung z.B. von einem Absender aus 10 und Ziel in 20 sollte damit sauber funktionieren !
Die 110er wäre sinnvoller wenn sie access-list 110 permit ip 192.168.10.0 0.0.0.255 any lauten würde, denn du willst ja nur VLAN 10 Traffic freigeben, oder ?
So mit deiner Schrotschussregel sind alle IPs erlaubt. OK, ist eher kosmetisch.
Zitat von @aqui:
Bedenke das der Zugriff aus dem VLAN 10 auf das VLAN 20 ausschliesslich nur für TCP basierte Protokolle funlktioniert und NICHT für UDP oder andere Protokolle wie ICMP (Ping, traceroute etc.)
Eine HTTP oder SSH Verbindung z.B. von einem Absender aus 10 und Ziel in 20 sollte damit sauber funktionieren !
Die 110er wäre sinnvoller wenn sie access-list 110 permit ip 192.168.10.0 0.0.0.255 any lauten würde, denn du willst ja nur VLAN 10 Traffic freigeben, oder ?
So mit deiner Schrotschussregel sind alle IPs erlaubt. OK, ist eher kosmetisch.
Bedenke das der Zugriff aus dem VLAN 10 auf das VLAN 20 ausschliesslich nur für TCP basierte Protokolle funlktioniert und NICHT für UDP oder andere Protokolle wie ICMP (Ping, traceroute etc.)
Eine HTTP oder SSH Verbindung z.B. von einem Absender aus 10 und Ziel in 20 sollte damit sauber funktionieren !
Die 110er wäre sinnvoller wenn sie access-list 110 permit ip 192.168.10.0 0.0.0.255 any lauten würde, denn du willst ja nur VLAN 10 Traffic freigeben, oder ?
So mit deiner Schrotschussregel sind alle IPs erlaubt. OK, ist eher kosmetisch.
Oh mann, da hätte ich drauf kommen können mit dem tcp, war wohl schon zu spät :D
Habe das jetzt nochmal abgeändert:
Extended IP access list 120
10 permit tcp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 established
15 permit icmp 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 echo-reply
20 deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255 (8 match(es))
30 permit ip 192.168.20.0 0.0.0.255 any
Extended IP access list 110
10 permit ip 192.168.10.0 0.0.0.255 any
Regel 110 ist ja nur auf das Interface VLAN10 angewendet daher wirklich nur kosmetisch, habs aber berücksichtigt ;)
Hast du vll noch eine gute Erklärung für die in und out Anwendung von ACLs auf die Schnittstellen ? Am besten mit einer Zeichnung. 100%tig klar ist mir das noch nicht.
Hast du vll noch eine gute Erklärung für die in und out Anwendung von ACLs auf die Schnittstellen ?
Das ist eigentlich kinderleicht und eine Zeichnung braucht man dafür nicht.- IN = filtert VOM Netzwerkdraht IN das IP Interface hinein. D.h. Der Switch prüft alles was von außen (Netzwerk) in ihn "hinein" will.
- OUT = filtert AUS dem Interface hinaus IN den Netzwerkdraht. Der Switch prüft mit der ACL also alles was ihn verlassen will auf das Netzwerk.
Die OUT Logik sollte man wenn möglich immer vermeiden ! Einerseits ist dieser Traffic ja schon unützerweise im Switch drin und dort verarbeitet worden um dann ausgehen gefiltert zu werden.
Normal will man zu filternden Traffic ja schon niemals "im" Switch haben.
Zudem kommt dazu das Outbound ACLs fast immer in CPU abgearbeitet werden im Gegensatz zu Inbound wo das im Switch ASIC in Silizium passiert. Entsprechend lahm ist dann die Abarbeitung bei Outbound ACLs. Zudem, was schlimmer ist, wird der Switch in der Performance damit massiv belastet.
Es gibt auch fast keinerlei sinnvolle Szenarien für Outbound Filterung. Viele billige Websmart Switches supporten oft auch nur inbound ACLs. Auf dem Cisco ist aber beides möglich. Ist ja ein Cisco...
Fazit:
Immer nur inbound filtern !
Danke für die Hilfe und die Erklärung 
