Planung von VLANs

[Hunduster]

Hallo zusammen,

ich würde gerne in unserem Netzwerk mit VLANs arbeiten. Vorab muss ich sagen, dass ich ein wesentlich besserer Serveradmin als Netzwerkadmin bin und daher nicht die tiefergehenden Kenntnisse habe

Also, wir sind ein Unternehmen mit rund 50 Mitarbeitern an 3 Niederlassungen. Die Niederlassungen sind über ein MPLS Netzwerk miteinander verbunden. Die Router hierzu sind vom Provider gestellt und lassen keine direkte Konfiguration von mir zu.

Im Einsatz haben wir ausschließlich HP ProCurve Switche welche VLANs unterstützen.

Ich würde das Netzwerk nun gerne in 3 VLANS aufteilen:

VLAN1=Server

VLAN2=Clients

VLAN3=Peripherie

So, nun meine ich aus meiner mangelnden Kenntnis, dass ich für jedes VLAN ein Standardgateway brauche. Nun wäre doch die erste Überlegung, ob unser Router vom Provider Subinterfaces unterstützt, richtig? Der Provider sagt ist kein Problem allerdings kostet uns die Konfiguration durch den Provider an die 500€.

Nun war meine andere Überlegung, da wir ohnehin vor haben eigene Hardwarefirewalls anzuschaffen (Watchguard) hier entsprechende Modelle auszuwählen, die VLAN unterstützen und auch die Konfiguration von Subinterfaces.

Ich muss allerdings auch sicher gehen, dass die Niederlassungen noch auf die einzelnen VLANs zugriff haben, der ganze Rotz also geroutet wird.

Naja, ich denke ich brauch von Euch einen kleinen Crashkurs in Sachen VLAN zumal ich auch das mit Tagged und Untagged nie richtig verstanden habe egal wie oft ich mir das durchlese :upps

[bLinDy*]

soooviele frage auf einmal

Nun wäre doch die erste Überlegung, ob unser Router vom Provider Subinterfaces unterstützt, richtig? Der Provider sagt ist kein Problem allerdings kostet uns die Konfiguration durch den Provider an die 500€.

das ist richtig. die subinterfaces dienen als standardgateway für alle clients die sich in diesem vlan befinden.

Ich muss allerdings auch sicher gehen, dass die Niederlassungen noch auf die einzelnen VLANs zugriff haben, der ganze Rotz also geroutet wird.

das ist ja kein thema. wenn du auf deiner firewall subinterfaces anlegst, kommt das paket ja aus dem richtigen vlan auf der firewall an, wird über das wan geroutet und die firewall an deinem anderen standort kann auf grund des arp tables das packet in das richtige vlan wieder zustellen. (merke auf layer 3, also routing, existieren keine vlans)

Naja, ich denke ich brauch von Euch einen kleinen Crashkurs in Sachen VLAN zumal ich auch das mit Tagged und Untagged nie richtig verstanden habe egal wie oft ich mir das durchlese :upps

das ist eigentlich ganz einfach. endgeräte sollten eingentlich nicht mit tags umgehen können, was einige schlaue netzwerkkarten trotzdem tun. grundsätzlich ist es so. wenn du zwei switches hast und beide switches die vlans 1,2 und 3 kennen, dann muss ja sicher gestellt sein, dass wenn ein paket aus dem vlan 3 den switch A verlässt auch auf switch B im vlan 3 landet. das wird über einen sogenannten trunk realisiert.

Switch A <--TRUNK--> Switch B

wenn du einen trunkport definierst passiert eigentlich nichts weiter als das wenn ein paket aus dem vlan 3 kommt, der switch dem paket den tag "VLAN 3" aufsetzt und über den trunk jagd. der switch B sieht den tag, nimmt ihn ab (!) und gibt das paket in das vlan 3 ab. am port wo das paket den switch in richtung pc verlässt darf kein tag mehr drauf sein, da das endgerät im unklaren über die nutzung von vlans ist und meist diesen tag auch nicht verstehen kann.

ich hoffe das war verständlich.

Bearbeitet 7. Mai 2012 von bLinDy*

[DocInfra]

Ich würde das Netzwerk nun gerne in 3 VLANS aufteilen:

VLAN1=Server

VLAN2=Clients

VLAN3=Peripherie

Reichen dir die drei VLANs? Wie sieht es mit zukünftigen Erweiterungen aus? DMZ, Guest WLAN o.ä.? Was für Subnetze nutzt du?

So, nun meine ich aus meiner mangelnden Kenntnis, dass ich für jedes VLAN ein Standardgateway brauche. Nun wäre doch die erste Überlegung, ob unser Router vom Provider Subinterfaces unterstützt, richtig? Der Provider sagt ist kein Problem allerdings kostet uns die Konfiguration durch den Provider an die 500€.

Sicherlich möglich, aber schlechte Wahl. Wenn ein Client auf einen Server zugreifen will, dann geht der Verkehr durch den Router. Wie ist der angebunden? 100 Mbit an deinem Core-Switch? Keine gute Idee. Lass das besser den Switch machen.

Nun war meine andere Überlegung, da wir ohnehin vor haben eigene Hardwarefirewalls anzuschaffen (Watchguard) hier entsprechende Modelle auszuwählen, die VLAN unterstützen und auch die Konfiguration von Subinterfaces.

Sicherlich eine gute Idee um VLANs über die Firewall zu ziehen, aber die Firewall routen zu lassen, ist keine gute Idee.

Ich muss allerdings auch sicher gehen, dass die Niederlassungen noch auf die einzelnen VLANs zugriff haben, der ganze Rotz also geroutet wird.

Willst du z.B. das VLAN 1 mit den Clients über alle Standorte ziehen? Ein Subnetz?

Naja, ich denke ich brauch von Euch einen kleinen Crashkurs in Sachen VLAN zumal ich auch das mit Tagged und Untagged nie richtig verstanden habe egal wie oft ich mir das durchlese :upps

Untagged = nur ein VLAN auf dem Port

Tagged = mehrere VLANs pro Port

Ein VLAN kann Untagged auf einem Port sein, sollen weitere VLANs auf den Port musst du diese tagged setzen. Da du über Inter-Switch-Links i.d.R. mehrere VLANs ziehst, musst du diese Uplinks in den entsprechenden VLANs tagged setzen.

Ich würde pro Standort die drei VLANs implementieren, aber jeweils mit unterschiedlichen Subnetzen. So könntest du in der HV drei Class-C Netze verwenden, in den Standorten aber ein Class-C unterteilen (je nach Anzahl der Komponenten). Routing sollte der Switch übernehmen. Je nach Größte der Standorte solltest du auf die Verfügbarkeit achten und die Core-Switches redundant auslegen (auch auf Layer 3, Stichwort VRRP).

Was für ProCurve Switches setzt du ein?

[Crash2001]

[...]Untagged = nur ein VLAN auf dem Port

Tagged = mehrere VLANs pro Port

Ein VLAN kann Untagged auf einem Port sein, sollen weitere VLANs auf den Port musst du diese tagged setzen. Da du über Inter-Switch-Links i.d.R. mehrere VLANs ziehst, musst du diese Uplinks in den entsprechenden VLANs tagged setzen.

Auch ein Port, der nur in einem vlan ist, kann tagged sein. Muss ja nur ein Trunk sein, bei dem nur ein vlan erlaubt ist.

Ansonsten gilt, dass auf einem Trunk alle vlans getaggt sind (bei 802.1q das native vlan nicht, bei ISL hingegen schon).

ISL sollte man nicht mehr nutzen, wenn es eine andere Möglichkeit gibt, sondern wenn dann den dot1q (802.1q) Standard, da dies nicht herstellerspezifisch und nicht proprietär ist, sondern normiert ist und somit mehrere Hersteller problemlos miteinander gemischt werden können.

[DocInfra]

Auch ein Port, der nur in einem vlan ist, kann tagged sein. Muss ja nur ein Trunk sein, bei dem nur ein vlan erlaubt ist.

Klugsche*****.

ISL sollte man nicht mehr nutzen, wenn es eine andere Möglichkeit gibt, sondern wenn dann den dot1q (802.1q) Standard, da dies nicht herstellerspezifisch und nicht proprietär ist, sondern normiert ist und somit mehrere Hersteller problemlos miteinander gemischt werden können.

Ich komme ausd er ProCurve Welt - da gibt es kein ISL Protokoll mehr. ISL ist für mich ein gängiger Begriff für Inter-Switch Links.

[NicholasRush]

Ich würde in jeder Niederlassung einen Router einsetzen, der vor Ort zwischen den Vlans Routet um den Netzwerkverkehr zwischen den Niederlassungen zu entlasten. Ich gehe mal davon aus, das jede Niederlassung über eine eigene Internetverbindung verfügt. Die Switches untereinander müssen über die MLPS Verbindung tagged laufen (sofern der Provider es zulässt). In jeder Niederlassung wird dann über den Router vor Ort geroutet, außerdem würde ich dann auch den Broadcast im Switch einschränken, weil ja die Switches über die MLPS Leitungen ja tagged kommunizieren. Eine weitere möglichkeit wäre von den 3 Niederlassungen den Datenverkehr über die 3 Router laufen zu lassen ( nicht die vom Provider) die dann über die MLPS Leitung miteinander kommunizieren. Das wäre dann Routerlastiger.

Das ganze ist als Vorschlag zu verstehen, das ganze hier ist nur ein 5min gedanke. Also wenn etwas unklar oder falsch sein sollte nicht gleich böse sein.