3
Adapter Teaming - Trunk - Layer 3
DHCP VLAN-übergreifend? Trunking 2+1GBit?
Hallo!
Zum Artikel "Fiktive Netze" auf heise Netze - Fiktive Netzwerke (ich nehme an, einige von Euch haben ihn gelesen) habe ich weitere Fragen, die mir hoffentlich der eine oder andere Profi beantworten kann:
Ich beabsichtige, unseren Server (Win 2003 Domänencontroller mit Intel® PRO/1000 PT Quad Port Server Adapter evtl. auch "nur" die Dual-Port-Ausführung) an den im oben genannten Artikel Linksys-SRW224 anzuschließen. Gibt es einen vergleichbaren Switch auch mit mehreren GBit-Ports? Evtl. den Linksys-SRW224G4?
Alle GBit-Ports des Switches binde ich in ein VLAN, jeden der 4 Computerräume, Lehrerzimmer, Schülerzeitung.... auch in je 1 VLAN (100MBit).
Drei Fragen:
- Ist es von der Theorie her richtig, dass ich mein Schulnetz dann mit 2x1GBit = 2 GBit betreibe (Load Balancing {oder nennt man das Trunking?} kann die Intel-Karte ja)?
- Ausschließlich auf dem Server läuft ein DHCP+DNS+RIS+ISA. Klappt das Zuweisen z.B. einer DHCP-Adresse an einen neuen Client automatisch, d.h. weiß der DHCP, dass er nun eine Anfrage mit einer IP aus z.B. Bereich3 für VLAN3 vergeben muss? Oder bräuchte ich in jedem VLAN einen DHCP - das will ich aber eigentlich nicht. Hintergrund: Ich installiere alle Clients per RIS, dazu ist es natürlich notwendig, dass die Clients per PXE-Boot eine IP erhalten.
- Ist sonst mit weiteren Hindernissen bzgl. der obigen Konfiguration zu rechnen, oder spielt sich das Tagging zwischen GBit-VLAN am Switch und Server praktisch unsichtbar und selbstständig ab?
Vielen Dank für Eure Bemühungen - ich hoffe, Ihr nehmt Euch ein paar Minuten Zeit und könnt mir weiterhelfen.
Mit bestem Dank,
joeE
Zum Artikel "Fiktive Netze" auf heise Netze - Fiktive Netzwerke (ich nehme an, einige von Euch haben ihn gelesen) habe ich weitere Fragen, die mir hoffentlich der eine oder andere Profi beantworten kann:
Ich beabsichtige, unseren Server (Win 2003 Domänencontroller mit Intel® PRO/1000 PT Quad Port Server Adapter evtl. auch "nur" die Dual-Port-Ausführung) an den im oben genannten Artikel Linksys-SRW224 anzuschließen. Gibt es einen vergleichbaren Switch auch mit mehreren GBit-Ports? Evtl. den Linksys-SRW224G4?
Alle GBit-Ports des Switches binde ich in ein VLAN, jeden der 4 Computerräume, Lehrerzimmer, Schülerzeitung.... auch in je 1 VLAN (100MBit).
Drei Fragen:
- Ist es von der Theorie her richtig, dass ich mein Schulnetz dann mit 2x1GBit = 2 GBit betreibe (Load Balancing {oder nennt man das Trunking?} kann die Intel-Karte ja)?
- Ausschließlich auf dem Server läuft ein DHCP+DNS+RIS+ISA. Klappt das Zuweisen z.B. einer DHCP-Adresse an einen neuen Client automatisch, d.h. weiß der DHCP, dass er nun eine Anfrage mit einer IP aus z.B. Bereich3 für VLAN3 vergeben muss? Oder bräuchte ich in jedem VLAN einen DHCP - das will ich aber eigentlich nicht. Hintergrund: Ich installiere alle Clients per RIS, dazu ist es natürlich notwendig, dass die Clients per PXE-Boot eine IP erhalten.
- Ist sonst mit weiteren Hindernissen bzgl. der obigen Konfiguration zu rechnen, oder spielt sich das Tagging zwischen GBit-VLAN am Switch und Server praktisch unsichtbar und selbstständig ab?
Vielen Dank für Eure Bemühungen - ich hoffe, Ihr nehmt Euch ein paar Minuten Zeit und könnt mir weiterhelfen.
Mit bestem Dank,
joeE
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: 45781
Url: https://administrator.de/contentid/45781
Printed on: April 23, 2024 at 11:04 o'clock
3 Comments
Latest comment
Oha...viele Fragen auf einmal...
Erstmal zum Server Trunking:
Das Trunking oder besser gesagt um keine Zweifel in der Nomenklatur zu schaffen, da es mehrere Ausdrücke gibt dafür ein "Link Aggregation" also das Zusammenfassen mehrerer Links zum Erhöhen der Bandbreite, muss auf beiden Seiten geschehen also auf der Server Seite (die NIC muss entsprechend konfiguriert sein mit Teaming etc.) UND auf der Switch Seite. D.h. der Switch muss also solche Link Aggregation supporten entweder statisch oder nach dem Standard IEEE 802.3ad. Ob er das kann steht in den Features im Handbuch des Switches.
Kann der Switch es nicht, kannst du keine Links zur Bandbreitenerhöhung bündeln !!
Dein VLAN Konzept ist in der Grundlage richtig. Normalerweise führt man dann alle Etagen (oder bei dir Raum...) Links über Trunks (hier getaggte Links) auf den zentralen Switch.
"Trunks" bezeichnet hier aber IEEE 802.1q getaggte Links, also Switch Verbindungen auf denen der Switch die unterschiedlichen VLAN IDs (nummern) in einem Tag an den Ethernet Frame anhängt.
Das sind reine Interswitch Links, da normale Endgeräte damit nichts anfangen können und auch solcherart manipulierte Frames nicht lesen können ohne entsprechende Treiber auf den NICs.
Das VLAN Tagging spielt sich dann unsichtbar ab aber eben NUR wenn die Links auch fürs Tagging aktiviert sind sowohl am Switch als auch am Server über die Treiber Einstellungen, sonst natürlich nicht !!
Wenn du reine Layer 2 Switches hast, kannst du erstmal überhaupt nicht kommunizieren zwischen diesen VLANs, denn diese sind zwar physisch auf einem Switch aber vollkommen getrennt und tauschen keine Packete aus was ja auch der Sinn von VLANs ist.
Normalerweise hat man dann als zentralen Switch einen Layer 3 (Routing) fähigen Switch, der die Verbindung zwischen den VLANs schafft.
Dieser Switch kann dann über sog. "helper Adressen" zentral DHCP und Bootp Requests (die brauchst du für PXE) an einen Server weiterleiten. Dieser "sieht" anhand das Ursprungs VLANs aus welchem Segment es kommt und vergibt eine entsprechende IP Adresse. Ein einzelner zentraler DHCP Server bzw. PXE Server reicht also vollkommen aus.
Nach deiner Beschreibung sieht es aber so aus also ob du das VLAN übergreifende Routing Geschäft nicht einem L3 Switch sondern dem Server übertragen willst über eine nach 802.1q getaggte Trunk Leitung. Das funktioniert natürlich auch, sofern der Kartentreiber 802.1q Tagging supportet, was er aber auch m.E. macht.
Dieser Link kann dann auch wieder ein aggregierter Link aus mehreren GiG Verbindungen sein, wie gesagt sofern Switch und Karte das supporten.
Nachteil einer solchen serverbasierten VLAN Konstellation ist immer das der Server dann zentrales Element ist das die Kommunikation im Netz sicherstellt. Ist der mal abgeschaltet oder wird gewartet, ist eine Kommunikation der VLANs unmöglich. Ein unabhängiger Layer 3 fähiger Switch zentral ist da die technisch eindeutig bessere Lösung !
Aber auch die Server Lösung führt natürlich zum Erfolg !
Erstmal zum Server Trunking:
Das Trunking oder besser gesagt um keine Zweifel in der Nomenklatur zu schaffen, da es mehrere Ausdrücke gibt dafür ein "Link Aggregation" also das Zusammenfassen mehrerer Links zum Erhöhen der Bandbreite, muss auf beiden Seiten geschehen also auf der Server Seite (die NIC muss entsprechend konfiguriert sein mit Teaming etc.) UND auf der Switch Seite. D.h. der Switch muss also solche Link Aggregation supporten entweder statisch oder nach dem Standard IEEE 802.3ad. Ob er das kann steht in den Features im Handbuch des Switches.
Kann der Switch es nicht, kannst du keine Links zur Bandbreitenerhöhung bündeln !!
Dein VLAN Konzept ist in der Grundlage richtig. Normalerweise führt man dann alle Etagen (oder bei dir Raum...) Links über Trunks (hier getaggte Links) auf den zentralen Switch.
"Trunks" bezeichnet hier aber IEEE 802.1q getaggte Links, also Switch Verbindungen auf denen der Switch die unterschiedlichen VLAN IDs (nummern) in einem Tag an den Ethernet Frame anhängt.
Das sind reine Interswitch Links, da normale Endgeräte damit nichts anfangen können und auch solcherart manipulierte Frames nicht lesen können ohne entsprechende Treiber auf den NICs.
Das VLAN Tagging spielt sich dann unsichtbar ab aber eben NUR wenn die Links auch fürs Tagging aktiviert sind sowohl am Switch als auch am Server über die Treiber Einstellungen, sonst natürlich nicht !!
Wenn du reine Layer 2 Switches hast, kannst du erstmal überhaupt nicht kommunizieren zwischen diesen VLANs, denn diese sind zwar physisch auf einem Switch aber vollkommen getrennt und tauschen keine Packete aus was ja auch der Sinn von VLANs ist.
Normalerweise hat man dann als zentralen Switch einen Layer 3 (Routing) fähigen Switch, der die Verbindung zwischen den VLANs schafft.
Dieser Switch kann dann über sog. "helper Adressen" zentral DHCP und Bootp Requests (die brauchst du für PXE) an einen Server weiterleiten. Dieser "sieht" anhand das Ursprungs VLANs aus welchem Segment es kommt und vergibt eine entsprechende IP Adresse. Ein einzelner zentraler DHCP Server bzw. PXE Server reicht also vollkommen aus.
Nach deiner Beschreibung sieht es aber so aus also ob du das VLAN übergreifende Routing Geschäft nicht einem L3 Switch sondern dem Server übertragen willst über eine nach 802.1q getaggte Trunk Leitung. Das funktioniert natürlich auch, sofern der Kartentreiber 802.1q Tagging supportet, was er aber auch m.E. macht.
Dieser Link kann dann auch wieder ein aggregierter Link aus mehreren GiG Verbindungen sein, wie gesagt sofern Switch und Karte das supporten.
Nachteil einer solchen serverbasierten VLAN Konstellation ist immer das der Server dann zentrales Element ist das die Kommunikation im Netz sicherstellt. Ist der mal abgeschaltet oder wird gewartet, ist eine Kommunikation der VLANs unmöglich. Ein unabhängiger Layer 3 fähiger Switch zentral ist da die technisch eindeutig bessere Lösung !
Aber auch die Server Lösung führt natürlich zum Erfolg !
Vielen Dank für die ausführliche Beschreibung.
Nach genauer Durchsicht habe ich festgestellt, dass sowohl der von mir anvisierte Switch, als auch die NIC 802.3ad beherrschen.
DHCP-Relay:
Vereinfacht stellt sich an meinem zentralen Switch folgendes dar:
VLAN1: Raumswitch PC-Raum1
VLAN2: Raumswitch PC-Raum2
VLAN3: Server
Der Server besitzt eine weitere NIC, die mit einem weiteren Router in Richtung WWW verbunden ist, d.h. der gesamte Internet-Traffic läuft über den (ISA-)Server.
Ich würde jetzt Tagging an den Ports von VLAN3 und an der Server-NIC aktivieren und für jedes VLAN einen eigenen DHCP-Bereich am Server erstellen.
- Woher weiß der DHCP-Server aber, aus welchem Bereich er eine IP vergeben soll? Dass also Tag1 den DHCP-Bereich 1 zur Folge hat, denn nur mit der richtigen Netzwerkadresse erreicht der Client später sein entsprechendes Gateway an VLAN1????
- Was ist zu tun, damit ein Client aus VLAN1 beim Booten eine Antwort auf seinen DHCP-Request erhält, denn nur so lassen sich meine Clients per RIS installieren.
Bei meinem anvisierten Switch finde ich in der Produktbeschreibung hierzu nur:
*
Management, sonstiges:
RFC854 Telnet (Konfiguration über Menü), Secure Shell (SSH) und
Telnet-Management,Telnet Client, SSL-Sicherheit für Web-Schnittstelle,
Switch-Protokoll, DHCP Client, BootP, SNTP, Xmodem-Upgrade,
Kabeldiagnose, Ping,Traceroute
Bis zu 256 VLANs auf Port-Basis und nach 802.1q werden unterstützt.
Eindämmung von Datenstürmen – Broadcast,Multicast und Unknown Unicast
Layer 2
VLAN VLANs auf Port-Basis und nach 802.1q, Private VLAN Edge (PVE),
Management VLAN
HOL Blocking Verhinderung von Head of Line (HOL) Blocking
Mini Jumbo Frame Unterstützung für Frames mit bis zu 1600 Bytes
Dynamic VLAN GVRP* – dynamische VLAN-Registrierung
Sind da die entsprechenden "Zauberworte" dabei?
Danke,
joeE
Nach genauer Durchsicht habe ich festgestellt, dass sowohl der von mir anvisierte Switch, als auch die NIC 802.3ad beherrschen.
DHCP-Relay:
Vereinfacht stellt sich an meinem zentralen Switch folgendes dar:
VLAN1: Raumswitch PC-Raum1
VLAN2: Raumswitch PC-Raum2
VLAN3: Server
Der Server besitzt eine weitere NIC, die mit einem weiteren Router in Richtung WWW verbunden ist, d.h. der gesamte Internet-Traffic läuft über den (ISA-)Server.
Ich würde jetzt Tagging an den Ports von VLAN3 und an der Server-NIC aktivieren und für jedes VLAN einen eigenen DHCP-Bereich am Server erstellen.
- Woher weiß der DHCP-Server aber, aus welchem Bereich er eine IP vergeben soll? Dass also Tag1 den DHCP-Bereich 1 zur Folge hat, denn nur mit der richtigen Netzwerkadresse erreicht der Client später sein entsprechendes Gateway an VLAN1????
- Was ist zu tun, damit ein Client aus VLAN1 beim Booten eine Antwort auf seinen DHCP-Request erhält, denn nur so lassen sich meine Clients per RIS installieren.
Bei meinem anvisierten Switch finde ich in der Produktbeschreibung hierzu nur:
*
Management, sonstiges:
RFC854 Telnet (Konfiguration über Menü), Secure Shell (SSH) und
Telnet-Management,Telnet Client, SSL-Sicherheit für Web-Schnittstelle,
Switch-Protokoll, DHCP Client, BootP, SNTP, Xmodem-Upgrade,
Kabeldiagnose, Ping,Traceroute
Bis zu 256 VLANs auf Port-Basis und nach 802.1q werden unterstützt.
Eindämmung von Datenstürmen – Broadcast,Multicast und Unknown Unicast
Layer 2
VLAN VLANs auf Port-Basis und nach 802.1q, Private VLAN Edge (PVE),
Management VLAN
HOL Blocking Verhinderung von Head of Line (HOL) Blocking
Mini Jumbo Frame Unterstützung für Frames mit bis zu 1600 Bytes
Dynamic VLAN GVRP* – dynamische VLAN-Registrierung
Sind da die entsprechenden "Zauberworte" dabei?
Danke,
joeE
Nein, so kann das nicht ganz klappen. Du musst einen Tagged Port vom zentralen Switch zum Server einrichten also den Server auf einen Port stecken der Daten vom VLAN 1, 2 und 3 an den Server übergibt. Der Treiber gibt dem Server dann 3 virtuelle IP Adressen so das der Server dann aus sicht der Anwender mit je einem Bein in jedem VLAN hängt. Das Problem des DHCP Relay stellt sich so nicht für dich.
Dein Szenario mit einem VLAN 3 dediziert für den Server kann man nur realisieren wenn dein zentraler Switch ein Layer 3 (Routing) fähiger Switch ist. Der hat dann virtuell je ein Layer 3 "IP Bein" in jedem VLAN und routed darüber. Der Switch würde dann über die Helper Adressen einen Bootp Request den er an diesem Interface von einem Endgerät empfängt an den Server als Unicast forwarden. Die Quelladresse überschreibt der Switch dann mit seiner Adresse des VLAN Segments. Der DHCP Server wiederum sieht in der Quelladresse die IP Adresse des Ursprungs VLAN und kann die IP Adresse aus seinem Pool zuordnen...
Dein Szenario mit einem VLAN 3 dediziert für den Server kann man nur realisieren wenn dein zentraler Switch ein Layer 3 (Routing) fähiger Switch ist. Der hat dann virtuell je ein Layer 3 "IP Bein" in jedem VLAN und routed darüber. Der Switch würde dann über die Helper Adressen einen Bootp Request den er an diesem Interface von einem Endgerät empfängt an den Server als Unicast forwarden. Die Quelladresse überschreibt der Switch dann mit seiner Adresse des VLAN Segments. Der DHCP Server wiederum sieht in der Quelladresse die IP Adresse des Ursprungs VLAN und kann die IP Adresse aus seinem Pool zuordnen...
