26228
23.04.2018
6288
9
0
Grundsätzliche Verständnisfragen VLAN - LLDP - Routing
Hallo zusammen,
hier mal wieder eine Anfrage aus der beliebten Reihe "Hobby-Admins in Unternehmen". Stop...noch keine virtuellen Tomaten werfen.
Wir erhalten im Herbst endlich unsere neue symetrische Leitung mit 100 Mbit, nachdem wir uns jahrelang mit einem T-DSL 6000 herum geplagt haben.
Sobald das alles läuft möchten wir gerne in einem 2. Schritt auf IP-Telefonie umsteigen. Intern ist das bereits der Fall, nach außen gehts allerdings
über 2 ISDN-Anlagenanschlüsse, die ja über kurz oder lang nicht mehr existieren werden.
Aktuelle Situation:
1 x Router Lancom 1781 VA mit WAN = T-DSL 6000 und LAN = Netz 192.168.1.X
1 x Switch Lancom GS-1224P
1 x Telekom F470UC baugleich Unify Openscape Office MX als TK-Anlage
6 x Openstage 60 G HFA
7 x Windows 10 Client
1 x Server 2016 Essentials (AD, DHCP, DNS und diverse Freigaben)
Die Clients erhalten ihre IP per DHCP aus 192.168.1.20 bis 192.168.1.40. Anderes Netzwerk-Gedöns wie Drucker, NAS, Kameras, USV etc.
hat feste IP's ab 192.168.1.41.
Die TK-Anlage hat fest 192.168.1.101 und die Telefone 192.168.1.102 und folgende.
Geplante Änderungen:
Zu Testzwecken hab ich ein Netz 192.168.2.X im Router schon mal angelegt. Ich würde gerne die Telefone und die TK-Anlage dieses Netz setzen und diesem Netz eine andere VLAN-ID, z.B. 2, geben Im Konfig-Menü der Telefone steht hierzu 1. LLDP-MED mit DHCP, 2. DHCP, 3. Manuelles VLAN mit DHCP und 4. Manuelle Einstellungen zur Verfügung.
Meine bescheidene Vermutung bzw. Fragen / Unklarheiten dazu wäre dann:
1. Der TK-Anlage gebe ich die feste IP 192.168.2.101 (Subnet 255.255.255.0), aktiviere IEEE802.1p/q-Tagging und weise die VLAN-ID 2 zu.
2. In der TK-Anlage steht Layer2-QoS auf Sprach-/Fax-/Modem-Payload = 5, Signalisierungsdaten =3, Netzwerksteuerung = 0 -> das lasse ich vermutlich so?
3. Auf der TK-Anlage aktiviere ich den DHCP-Server -> kommen sich DHCP-Server in unterschiedlichen VLAN's in die Quere, wenn ein Routing zwischen den beiden Netzen vorhanden ist oder gibts da keine Probleme?
4. In den Telefonen aktiviere ich Manuelles VLAN mit DHCP und weise allen Telefonen die VLAN-ID 2 zu.
5. In den Telefonen steht Layer2-QoS auf den gleichen Werten, Layer3-QoS = Ja, Voice = EF, Signaling = AF31 (bei Layer 3 hab ich keine Ahnung, was die Werte bedeuten). Lasse ich vermutlich so?
6. Im Switch setze ich den VLAN-Mode auf "tag-based" und lasse alle Ports auf der Default-VID 1 (warum 1?), da das Tagging die Telefone und die TK-Anlage direkt übernehmen?
Weiterhin lasse ich im Switch die VLAN Port Konfiguration bei allen Ports auf Packet Type = all und Role = Access? QoS im Switch aktiviere ich dann mit Werten, die zur TK-Anlage und den Telefonen passen.
7. Im Router gibt es das Netz "Intranet" mit 192.168.1.X und VLAN-ID 0 (per Default) und das Netz "VOIPNET" mit 192.168.2.X und VLAN-ID 2. Aber VLAN-ID 0 bedeutet doch, das in einem Netz mit dieser ID jedes Paket ankommt? Muss das dann nicht auf VLAN-ID 1 lauten?
8. Im Router gibt es außer der Default-Route nach "draußen" ( 255.255.255.255 / 0.0.0.0) noch die Route 192.168.1.0 auf Router 192.168.1.1 und die Route 192.168.2.0 auf Router 192.168.2.1, damit
die beiden Netze untereinander kommunizieren können. Die TK-Anlage in Netz "VOIPNET" muss von den Clients im Netz "INTRANET" erreichbar sein für eine CT-Anwendung und die TK-Anlage aus "VOIPNET" muss doch sicher den DNS im "INTRANET" erreichen können?
Vorab vielen Dank für die Hilfestellung und Tipps, wie man es anders bzw. besser machen könnte.
Gruß Arno
hier mal wieder eine Anfrage aus der beliebten Reihe "Hobby-Admins in Unternehmen". Stop...noch keine virtuellen Tomaten werfen.
Wir erhalten im Herbst endlich unsere neue symetrische Leitung mit 100 Mbit, nachdem wir uns jahrelang mit einem T-DSL 6000 herum geplagt haben.
Sobald das alles läuft möchten wir gerne in einem 2. Schritt auf IP-Telefonie umsteigen. Intern ist das bereits der Fall, nach außen gehts allerdings
über 2 ISDN-Anlagenanschlüsse, die ja über kurz oder lang nicht mehr existieren werden.
Aktuelle Situation:
1 x Router Lancom 1781 VA mit WAN = T-DSL 6000 und LAN = Netz 192.168.1.X
1 x Switch Lancom GS-1224P
1 x Telekom F470UC baugleich Unify Openscape Office MX als TK-Anlage
6 x Openstage 60 G HFA
7 x Windows 10 Client
1 x Server 2016 Essentials (AD, DHCP, DNS und diverse Freigaben)
Die Clients erhalten ihre IP per DHCP aus 192.168.1.20 bis 192.168.1.40. Anderes Netzwerk-Gedöns wie Drucker, NAS, Kameras, USV etc.
hat feste IP's ab 192.168.1.41.
Die TK-Anlage hat fest 192.168.1.101 und die Telefone 192.168.1.102 und folgende.
Geplante Änderungen:
Zu Testzwecken hab ich ein Netz 192.168.2.X im Router schon mal angelegt. Ich würde gerne die Telefone und die TK-Anlage dieses Netz setzen und diesem Netz eine andere VLAN-ID, z.B. 2, geben Im Konfig-Menü der Telefone steht hierzu 1. LLDP-MED mit DHCP, 2. DHCP, 3. Manuelles VLAN mit DHCP und 4. Manuelle Einstellungen zur Verfügung.
Meine bescheidene Vermutung bzw. Fragen / Unklarheiten dazu wäre dann:
1. Der TK-Anlage gebe ich die feste IP 192.168.2.101 (Subnet 255.255.255.0), aktiviere IEEE802.1p/q-Tagging und weise die VLAN-ID 2 zu.
2. In der TK-Anlage steht Layer2-QoS auf Sprach-/Fax-/Modem-Payload = 5, Signalisierungsdaten =3, Netzwerksteuerung = 0 -> das lasse ich vermutlich so?
3. Auf der TK-Anlage aktiviere ich den DHCP-Server -> kommen sich DHCP-Server in unterschiedlichen VLAN's in die Quere, wenn ein Routing zwischen den beiden Netzen vorhanden ist oder gibts da keine Probleme?
4. In den Telefonen aktiviere ich Manuelles VLAN mit DHCP und weise allen Telefonen die VLAN-ID 2 zu.
5. In den Telefonen steht Layer2-QoS auf den gleichen Werten, Layer3-QoS = Ja, Voice = EF, Signaling = AF31 (bei Layer 3 hab ich keine Ahnung, was die Werte bedeuten). Lasse ich vermutlich so?
6. Im Switch setze ich den VLAN-Mode auf "tag-based" und lasse alle Ports auf der Default-VID 1 (warum 1?), da das Tagging die Telefone und die TK-Anlage direkt übernehmen?
Weiterhin lasse ich im Switch die VLAN Port Konfiguration bei allen Ports auf Packet Type = all und Role = Access? QoS im Switch aktiviere ich dann mit Werten, die zur TK-Anlage und den Telefonen passen.
7. Im Router gibt es das Netz "Intranet" mit 192.168.1.X und VLAN-ID 0 (per Default) und das Netz "VOIPNET" mit 192.168.2.X und VLAN-ID 2. Aber VLAN-ID 0 bedeutet doch, das in einem Netz mit dieser ID jedes Paket ankommt? Muss das dann nicht auf VLAN-ID 1 lauten?
8. Im Router gibt es außer der Default-Route nach "draußen" ( 255.255.255.255 / 0.0.0.0) noch die Route 192.168.1.0 auf Router 192.168.1.1 und die Route 192.168.2.0 auf Router 192.168.2.1, damit
die beiden Netze untereinander kommunizieren können. Die TK-Anlage in Netz "VOIPNET" muss von den Clients im Netz "INTRANET" erreichbar sein für eine CT-Anwendung und die TK-Anlage aus "VOIPNET" muss doch sicher den DNS im "INTRANET" erreichen können?
Vorab vielen Dank für die Hilfestellung und Tipps, wie man es anders bzw. besser machen könnte.
Gruß Arno
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 371954
Url: https://administrator.de/forum/grundsaetzliche-verstaendnisfragen-vlan-lldp-routing-371954.html
Ausgedruckt am: 29.04.2025 um 03:04 Uhr
9 Kommentare
Neuester Kommentar
Stop...noch keine virtuellen Tomaten werfen.
Das machen wir doch nieeee hier 
Zu deinen Fragen...
1.)
Das musst du nur machen wenn du eine reine Layer 2 Priorisierung machst im Voice Bereich. Die .1p Bits (PCP) sind immer Teil des .1q VLAN Tags, damit erzwingt dann einen Layer 2 Priorisierung immer einen .1q Tag.
Die Grafik hier veranschaulicht das:
https://de.wikipedia.org/wiki/IEEE_802.1Q#Tags_im_Ethernet-Frame
Häufig machen die Anlagen auch eine Layer 3 Priorisierung mit DSCP. Da sist dann statt im L2 Tag im Layer 3 IP Header. Damit entfällt dann der Tag auf allen Voice Endgeräten und sie können dann entweder statisch oder per LLDP Med dynmaisch untagged ins VLAN 2
Hängt also letztlich ab ob du an der Anlage zwingend L2 Priorisierung machst. Ansonsten kannst du ohne Tag arbeiten.
2.)
Ja, solltest du so lassen. Mal sollte nicht auf das höchst mögliche gehen, denn das nutzt der Switch für Control Protokolle.
https://en.wikipedia.org/wiki/IEEE_P802.1p
5 ist der höchste Wert für Voice im L2
3.)
Nein ! DHCP arbeitet mit UDP Broadcasts und wie jeder Netzwerker weiss (auch Hobby Netzwerker !) werden UDP Broadcasts sytembedingt NICHT von Routern übertragen !
Du kannst also entweder den Router oder der Anlage DHCPs im VLAN 2 Segment verteilen lassen.
4.)
Sagtest du nicht selber oben du arbeitest mit LLDP MED ?? Warum lässt du dann nicht LLDP diesen Dienst tun, dafür ist es doch da !
Du kannst es natürlich auch kompliziert machen und das manuell machen nach dem Motto "Warum einfach machen wenn es umständlich auch geht !" (Die Tomaten werden schon sichtbar... !
)5.)
Tja...siehe Punkt 1 !!! Du musst klären WAS du an Priorisierung machst. Eins geht nur L2 oder L3. Beides wäre Blödsinn. Ein Switch oder Router könnte ja niemals wissen welche Priorisierung du denn jetzt meinst !
Entscheide dich also und konfiguriere genau so die Voice Endgeräte und zwar durchgängig !
6.)
Uhhh...Besser noch mal die Schulbank drücken und den Grundkurs VLAN dir reinziehen:
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Jetzt machst du VLAN Raten im freien Fall. Deshalb keinen weiteren Kommentar zu diesem Punkt und schnell vergessen.
Tagging ist immer beidseitig !! Wenn eine Seite tagged muss die andere Seite das auch. Wie sollte das denn sonst gehen ? Auch der Empfänger muss ja den Tag irgendwie lesen können um das Paket wieder einem VLAN zuordnen zu können.
Fazit: VLAN Technik nochmal lesen und verstehen !!
QoS im Switch musst du sehen WAS du machst L2 oder L3 und entsprechend den Switch so konfigurieren.
Achtung hier: Billige Layer 2 only Swoitches können manchmal keine Info im Layer 3 lesen (müssen sie ja auch nicht !) Achte hier darauf beim Kauf das so einer auch L3 Infos wie DSCP lesen kann wenn er rein nur ein L2 Switch ist !
7.)
Eine VLAN ID 0 ist Blödsinn. Das ist nicht definiert im 802.1q Standard und damit technischer Bullshit !
Die Default VLAN ID ist immer 1. Alles andere ist Quatsch.
8.)
Ja, ist normal in der Routing Tabelle stehen in der Regel auch die Local connected Netzwerke. 192.168.1.0 ist auf das Interface 192.168.1.1 gemappt. Bischen doppelt gemoppelt aber durchaus Standard und sollte dir keine Sorgen machen.
Nebenbei haben IP Netze niemals so sinnfreie Namen wie "VOIPNET" oder "INTRANET". Das ist Unsinn und sind Platzhalter als Namen für Leute die sich keine IP Adressen merken können oder gar nicht wissen was das ist.
Ein IP Netz ist immer das Netzwerk und alle Bits im Hostteil der Adresse sind 0. Die klassische Nomenklatur für IP Netze !
Dann mal fröhliches Netzwerk Basteln ! Viel zu verbessern rein am Design gibt es nicht. Ist ja auch ein simples Popelnetzwerk wo man nun wahrlich nicht viel falsch machen kann
Hallo,
Zusätzlich zu den Tipps von @aqui solltest du dir überlegen ob du den IP Bereich 192.168.x.x nicht besser in 10.x.x.x änderst...
Macht es für verschiedene zukünftige Erweiterungen wie VPN einfacher
Brammer
Zusätzlich zu den Tipps von @aqui solltest du dir überlegen ob du den IP Bereich 192.168.x.x nicht besser in 10.x.x.x änderst...
Macht es für verschiedene zukünftige Erweiterungen wie VPN einfacher
Brammer
Guter Einwand ! Siehe dazu auch hier:
VPNs einrichten mit PPTP
VPNs einrichten mit PPTP
Puuh...bin ich froh, das ich zumindest mal teilweise den "Ich weiß was, Herr Lehrer"-Finger heben kann.
Ich hab zuhause bewusst 192.168.0.0/24 gewählt, damit ich für den Fall der Fälle mal eine VPN Verbindung zur Arbeit herstellen kann. Dort ist ja wie oben erwähnt 192.168.1.0/24 angesagt.
Aber ihr habt natürlich recht. Jeder Routerhersteller gibt die 192er-Adressen per default in den Geräten an und man muss ja nicht alles übernehmen was vorgekaut wird, was ich zuhause allerdings getan habe. BTW...dort arbeitet seit 7 Jahren ein HP1810-24G hinter der Trempelwand
@aqui: Vielen Dank für die ausführliche Rückmeldung. Ich hab mich nicht aus Unhöflichkeit noch nicht gemeldet, sondern weil ich deine Links noch durcharbeite. Einen Teil hab ich glaube ich schon verstanden, aber in manchen Sachen ist noch Lesebedarf.
Es hakt bei mir glaub ich einfach an den Basics, an welcher Stelle was mit einem Paket passiert, wo der Tag eingefügt wird, wo der Tag wieder entfernt wird etc. Aber ich krieg das schon noch in den Kopf. Melde mich morgen wieder.
Grüße Arno
Ich hab zuhause bewusst 192.168.0.0/24 gewählt, damit ich für den Fall der Fälle mal eine VPN Verbindung zur Arbeit herstellen kann. Dort ist ja wie oben erwähnt 192.168.1.0/24 angesagt.
Aber ihr habt natürlich recht. Jeder Routerhersteller gibt die 192er-Adressen per default in den Geräten an und man muss ja nicht alles übernehmen was vorgekaut wird, was ich zuhause allerdings getan habe. BTW...dort arbeitet seit 7 Jahren ein HP1810-24G hinter der Trempelwand
@aqui: Vielen Dank für die ausführliche Rückmeldung. Ich hab mich nicht aus Unhöflichkeit noch nicht gemeldet, sondern weil ich deine Links noch durcharbeite. Einen Teil hab ich glaube ich schon verstanden, aber in manchen Sachen ist noch Lesebedarf.
Es hakt bei mir glaub ich einfach an den Basics, an welcher Stelle was mit einem Paket passiert, wo der Tag eingefügt wird, wo der Tag wieder entfernt wird etc. Aber ich krieg das schon noch in den Kopf. Melde mich morgen wieder.
Grüße Arno
Ich hab zuhause bewusst 192.168.0.0/24 gewählt,
War dann aber wie du den Ausführungen zum intelligenten IP Adress Design bei VPNs entnehmen konntest dann bewusst falsch !Trotzdem dann Glück gehabt das das mit dem Office Netz (das leider genau so dümmlich gewählt wurde !) nicht kollidierte.
Gerade die dümmlichen 192.168.0.0 oder 192.168.1.0 Netze sind zu 80% auf allen billigen Consumer Endgeräten im Default vergeben. Auch die 192.168.178.0 sollte man nicht mehmen weil das jede FritzBox hat.
Wenn man kann und vorher nachdenkt bei VPNs, sollte man immer die 172.16-32 Range oder das 10er Netz mit einem 24 Bit Prefix nehmen. Das wäre sinnvoll.
BTW...dort arbeitet seit 7 Jahren ein HP1810-24G hinter der Trempelwand
Igitt...ein Gruselswitch.noch nicht gemeldet
Kein Thema...immer locker bleiben
So...jetzt raucht mir der Kopf. Aber ich glaube, dass ich die Basics einigermaßen verstanden habe.
Zumindest funktioniert es.
Router:
Netze angelegt (Netz1 = 192.168.1.0/24 = VLAN-ID1, Netz2 = 192.168.2.0/24 = VLAN-ID 2, Netz3 = 192.168.3.0/24 = VLANID-3)
Die Namen der Netze sind nur zum besseren Merken. Achtung! Beim Lancom 1781VA muss das VLAN-Modul NICHT aktiviert werden.
Auf dem Router DHCP-Server eingeschaltet. Der DHCP kann für jedes Netz separat konfiguriert werden.
Für das Netz1 DHCP auf dem Router ausgeschaltet, da im Netz 1 der WSE 2016 (192.168.1.10) als DHCP steht, für die Netze 2 und 3
DHCP auf dem Router als reine Weiterleitung mit dem Ziel WSE 2016 (192.168.1.10) eingestellt.
Alle drei Netze sind im Router auf LAN-1 = ETH1 gebunden. LAN-1 wurde Port-VID 1 zugewiesen.
Switch:
Auf dem Switch die entsprechenden VLAN's 1 bis 3 angelegt, wobei ich hier das Default VLAN 1 belassen habe und nur die
Member-Ports, die dort nicht hineingehören, in die anderen VLANs aufgenommen habe. Alle Ports mit Ausnahme von Port 1 (Verbindung zum Router) sind untagged. Der Port 1 bekommt die PVID 1 und ist Mitglied aller VLANs und muss tagged sein.
Windows Server:
Auf dem WSE2016 die DHCP-Bereiche für die VLANs 2 und 3 angelegt (VLAN1 war logischerweise schon vorhanden). Im DNS die Reverse-Lookup-Zonen für die Netze 2 und 3 angelegt.
Kommunikation:
Mein Testnotebook erhält seine IP problemlos aus den Netzen 1 bis 3, je nach dem wo der Rechner eingesteckt wird. Internetzugang funktioniert auch. Ohne Firewall-Regel ist aber zwischen Geräten aus verschiedenen lokalen Netz keine Verbindung möglich (kein Ping). Allerdings funktioniert ein Ping nur z.B. von 192.168.2.11 (Netz2) nach 192.168.1.22 (Netz1). In der Gegenrichtung kein Ping möglich.
Probleme:
Innerhalb von Netz1 funktioniert die Namensauflösung. Aber von z.B. Netz2 in Netz1 funktioniert keine Namensauflösung. Ein Trace von z.B.
192.168.2.11 nach 192.168.1.22 läuft über 192.168.2.1 (Gateway Netz2) durch und löst auch auf pc01.firma.local auf. Zudem noch das Ping-Problem von Netz1 nach Netz2 (siehe w.o.).
Also nur ein Teilerfolg, aber zumindest der richtige Weg.
Zumindest funktioniert es.
Router:
Netze angelegt (Netz1 = 192.168.1.0/24 = VLAN-ID1, Netz2 = 192.168.2.0/24 = VLAN-ID 2, Netz3 = 192.168.3.0/24 = VLANID-3)
Die Namen der Netze sind nur zum besseren Merken. Achtung! Beim Lancom 1781VA muss das VLAN-Modul NICHT aktiviert werden.
Auf dem Router DHCP-Server eingeschaltet. Der DHCP kann für jedes Netz separat konfiguriert werden.
Für das Netz1 DHCP auf dem Router ausgeschaltet, da im Netz 1 der WSE 2016 (192.168.1.10) als DHCP steht, für die Netze 2 und 3
DHCP auf dem Router als reine Weiterleitung mit dem Ziel WSE 2016 (192.168.1.10) eingestellt.
Alle drei Netze sind im Router auf LAN-1 = ETH1 gebunden. LAN-1 wurde Port-VID 1 zugewiesen.
Switch:
Auf dem Switch die entsprechenden VLAN's 1 bis 3 angelegt, wobei ich hier das Default VLAN 1 belassen habe und nur die
Member-Ports, die dort nicht hineingehören, in die anderen VLANs aufgenommen habe. Alle Ports mit Ausnahme von Port 1 (Verbindung zum Router) sind untagged. Der Port 1 bekommt die PVID 1 und ist Mitglied aller VLANs und muss tagged sein.
Windows Server:
Auf dem WSE2016 die DHCP-Bereiche für die VLANs 2 und 3 angelegt (VLAN1 war logischerweise schon vorhanden). Im DNS die Reverse-Lookup-Zonen für die Netze 2 und 3 angelegt.
Kommunikation:
Mein Testnotebook erhält seine IP problemlos aus den Netzen 1 bis 3, je nach dem wo der Rechner eingesteckt wird. Internetzugang funktioniert auch. Ohne Firewall-Regel ist aber zwischen Geräten aus verschiedenen lokalen Netz keine Verbindung möglich (kein Ping). Allerdings funktioniert ein Ping nur z.B. von 192.168.2.11 (Netz2) nach 192.168.1.22 (Netz1). In der Gegenrichtung kein Ping möglich.
Probleme:
Innerhalb von Netz1 funktioniert die Namensauflösung. Aber von z.B. Netz2 in Netz1 funktioniert keine Namensauflösung. Ein Trace von z.B.
192.168.2.11 nach 192.168.1.22 läuft über 192.168.2.1 (Gateway Netz2) durch und löst auch auf pc01.firma.local auf. Zudem noch das Ping-Problem von Netz1 nach Netz2 (siehe w.o.).
Also nur ein Teilerfolg, aber zumindest der richtige Weg.
Auf dem Router DHCP-Server eingeschaltet.
Das wäre ja ziemlicher Blödsinn wenn du für alle deine VLAN Netze einen zentralen DHCP Server auf dem WSE 2016 betreibst ! Hier hast du dich wohl vertippt und meintest sicher ausgeschaltet oder ??In der Gegenrichtung kein Ping möglich.
Wenn das Windows ist musst du das ICMP Protokoll (Ping) erst erlauben in der lokalen Windows Firewall:https://www.windowspro.de/tipp/ping-windows-7-server-2008-r2-zulassen
löst auch auf pc01.firma.local
Nur mal nebenbei:.local ist keine besonders intelligente Idee für die lokale Root Domain weil sie weltweit fest dem mDNS Protokoll vergeben ist:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Da wirst du also über kurz oder lang Probleme bekommen im Netz.
Sinnvoller ist sowas wie .intern oder das deutsche .lokal zu verwenden. Noch sinnvoller das dafür reservierte .home.arpa
Dies solltest du dir dazu mal durchlesen:
https://www.heise.de/ct/ausgabe/2017-26-Interne-Domains-Auswahl-Einstell ...
Machst du die Namensauflösung mit der vollen Domain oder gibst du nur den Hostnamen an ?
Mal beides versuchen und ggf. mal mit nslookup und/oder dig checken.
Ebenso das Log im DNS Server wäre hier hilfreich.
Bedenke auch das du dem DNS Dienst in der lokalen Firewall den Zugriff aus fremden IP Netzen erlauben musst.
Komischerweise ging heute morgen an allen Windows Clients kein Internet mehr. Ich hab also erstmal alles auf "Anfang" gesetzt, sprich alle
Geräte hängen nun wieder im Netz1 (192.168.1.0/24). Ich muss zu den Themen sicher noch viel lesen und produziere noch reichlich Anfängerfehler.
Nein, kein Tippfehler. Beim Lancom 1781VA ist das so gelöst, das man den DHCP-Server des Routers einschalten muss, wenn man DHCP-Requests aus lokalen Netzen an einen anderen DHCP-Server weiterleiten will. Man kann dann im Router für jedes lokale Netz getrennt festlegen,
wie die DHCP-Anforderung verarbeitet wird. Ich hatte für Netz1 (192.168.1.0/24) festgelegt, das der DHCP-Server des Routers Anfragen aus diesem Netz nicht verarbeitet, also Routerseitig quasi nicht vorhanden ist, weil der WSE2016 hierfür zuständig ist und in diesem Netz liegt. Für die lokalen Netze2 (192.168.2.0/24) und 3 (192.168.3.0/24) habe ich im DHCP-Server des Routers festgelegt, das Anfragen aus diesen Netzen an den WSE2016 (192.168.1.10) weitergeleitet werden.
Auf dem WSE2016 habe ich dann im DHCP die Scopes der Netze2 und 3 angelegt und die entsprechenden Gateways, also 192.168.2.1 und 192.168.3.1 in den Bereichsoptionen gesetzt. Anschließend habe ich im DNS des WSE2016 noch die Reverse-Lookup-Zonen für Netz2 und 3 gesetzt.
Das hat auch alles problemlos funktioniert. Mein Testrechner hat aus dem entsprechenden Netz seinen Lease erhalten, wenn ich den Rechner
an einem Member-Port des passenden VLANs eingesteckt habe.
Beim Thema VLAN sieht das dann wie folgt aus:
Am Router ist ETH4 auf LAN-1 gebunden. Die drei im Router angelegten Netze liegen mit den VLAN-IDs 1, 2 und 3 alle auf LAN-1. Der Port ETH4 = LAN-1 ist physikalisch mit dem Port 1 am Switch verbunden. Sowohl am Router als auch am Switch ist dieser Port auf "Packet type= tagged-only", "Role = Trunk" und "PVID = 1".
(Anmerkung: Muss PVID am Trunk-Port des Switch und Routers nicht auf "None" stehen??? Bei PVID 1 würde der Switch doch den Tag eines Paketes, das vom Router kommend für VLAN2 ist, wieder in VLAN1 ändern und das Paket würde nicht im VLAN2 ankommen. Das würde vielleicht erklären, warum aus Netz2 / VLAN2 ein Ping in Netz1 / VLAN1 funktioniert, aber in der Gegenrichtung nicht?)
@aqui:
Ist es denn ok, wenn der WSE2016 den DHCP für alle lokalen Netze macht, oder meintest du, das ich DHCP für die Netze 2 und 3 durch den Router erledigen lassen soll?
Ok, wieder etwas gelernt. In der Routingtabelle des Routers ist ein werksseitiger Eintrag mit folgenden Werten:
Ich denke mal, das dieser Eintrag dazu dient, Multicasts ins Internet zu verhindern, oder? Muss ich zwingend das Suffix ändern oder
kann ich es so lassen?
Vielen Dank für die Geduld und die Tipps, auch speziell an aqui.
Geräte hängen nun wieder im Netz1 (192.168.1.0/24). Ich muss zu den Themen sicher noch viel lesen und produziere noch reichlich Anfängerfehler.
Zitat von @aqui:
Auf dem Router DHCP-Server eingeschaltet.
Das wäre ja ziemlicher Blödsinn wenn du für alle deine VLAN Netze einen zentralen DHCP Server auf dem WSE 2016 betreibst ! Hier hast du dich wohl vertippt und meintest sicher ausgeschaltet oder ??Nein, kein Tippfehler. Beim Lancom 1781VA ist das so gelöst, das man den DHCP-Server des Routers einschalten muss, wenn man DHCP-Requests aus lokalen Netzen an einen anderen DHCP-Server weiterleiten will. Man kann dann im Router für jedes lokale Netz getrennt festlegen,
wie die DHCP-Anforderung verarbeitet wird. Ich hatte für Netz1 (192.168.1.0/24) festgelegt, das der DHCP-Server des Routers Anfragen aus diesem Netz nicht verarbeitet, also Routerseitig quasi nicht vorhanden ist, weil der WSE2016 hierfür zuständig ist und in diesem Netz liegt. Für die lokalen Netze2 (192.168.2.0/24) und 3 (192.168.3.0/24) habe ich im DHCP-Server des Routers festgelegt, das Anfragen aus diesen Netzen an den WSE2016 (192.168.1.10) weitergeleitet werden.
Auf dem WSE2016 habe ich dann im DHCP die Scopes der Netze2 und 3 angelegt und die entsprechenden Gateways, also 192.168.2.1 und 192.168.3.1 in den Bereichsoptionen gesetzt. Anschließend habe ich im DNS des WSE2016 noch die Reverse-Lookup-Zonen für Netz2 und 3 gesetzt.
Das hat auch alles problemlos funktioniert. Mein Testrechner hat aus dem entsprechenden Netz seinen Lease erhalten, wenn ich den Rechner
an einem Member-Port des passenden VLANs eingesteckt habe.
Beim Thema VLAN sieht das dann wie folgt aus:
Am Router ist ETH4 auf LAN-1 gebunden. Die drei im Router angelegten Netze liegen mit den VLAN-IDs 1, 2 und 3 alle auf LAN-1. Der Port ETH4 = LAN-1 ist physikalisch mit dem Port 1 am Switch verbunden. Sowohl am Router als auch am Switch ist dieser Port auf "Packet type= tagged-only", "Role = Trunk" und "PVID = 1".
(Anmerkung: Muss PVID am Trunk-Port des Switch und Routers nicht auf "None" stehen??? Bei PVID 1 würde der Switch doch den Tag eines Paketes, das vom Router kommend für VLAN2 ist, wieder in VLAN1 ändern und das Paket würde nicht im VLAN2 ankommen. Das würde vielleicht erklären, warum aus Netz2 / VLAN2 ein Ping in Netz1 / VLAN1 funktioniert, aber in der Gegenrichtung nicht?)
@aqui:
Ist es denn ok, wenn der WSE2016 den DHCP für alle lokalen Netze macht, oder meintest du, das ich DHCP für die Netze 2 und 3 durch den Router erledigen lassen soll?
Nur mal nebenbei:
.local ist keine besonders intelligente Idee für die lokale Root Domain weil sie weltweit fest dem mDNS Protokoll vergeben ist:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Da wirst du also über kurz oder lang Probleme bekommen im Netz.
Sinnvoller ist sowas wie .intern oder das deutsche .lokal zu verwenden. Noch sinnvoller das dafür reservierte .home.arpa
.local ist keine besonders intelligente Idee für die lokale Root Domain weil sie weltweit fest dem mDNS Protokoll vergeben ist:
https://de.wikipedia.org/wiki/Zeroconf#Multicast_DNS
Da wirst du also über kurz oder lang Probleme bekommen im Netz.
Sinnvoller ist sowas wie .intern oder das deutsche .lokal zu verwenden. Noch sinnvoller das dafür reservierte .home.arpa
Ok, wieder etwas gelernt. In der Routingtabelle des Routers ist ein werksseitiger Eintrag mit folgenden Werten:
Ich denke mal, das dieser Eintrag dazu dient, Multicasts ins Internet zu verhindern, oder? Muss ich zwingend das Suffix ändern oder
kann ich es so lassen?
Vielen Dank für die Geduld und die Tipps, auch speziell an aqui.
wenn man DHCP-Requests aus lokalen Netzen an einen anderen DHCP-Server weiterleiten will.
OK, sorry, sowas komisches ist nicht gerade üblich. Warum man so einen Unsinn machen muss weiss wohl auch nur Lancom selber...aber nundenn. Dann ist der DHCP Server dort natürlich pflicht wenn ohne den kein Relay klappt.habe ich im DHCP-Server des Routers festgelegt, das Anfragen aus diesen Netzen an den WSE2016 (192.168.1.10) weitergeleitet werden.
Genau richtig gemacht !Auf dem WSE2016 habe ich dann im DHCP die Scopes der Netze2 und 3 angelegt
Auch alles perfekt richtig !Das hat auch alles problemlos funktioniert.
Ist meistens so wenn man alles richtig macht... Ich muss zu den Themen sicher noch viel lesen und produziere noch reichlich Anfängerfehler.
Na ja, im Groben hast du ja alles perfekt richtig gemacht. Die Fehler lagen sicher nur im Detail.Sowohl am Router als auch am Switch ist dieser Port auf "Packet type= tagged-only", "Role = Trunk" und "PVID = 1".
Muss PVID am Trunk-Port des Switch und Routers nicht auf "None" stehen???
as vom Router kommend für VLAN2 ist, wieder in VLAN1 ändern
Nein, das ist falsch. Damit hat PVID nichts zu tun. Guckst du hier:Muss PVID am Trunk-Port des Switch und Routers nicht auf "None" stehen???
as vom Router kommend für VLAN2 ist, wieder in VLAN1 ändern
Warum gibt es PVID bei VLANs?
Die PVID bestimmt also lediglich in welches VLAN untagged Pakete an diesem Port geforwardet werden.
Und da besteht auch die Unklarheit der Lancom Konfig.
Hier ist jetzt die große Frage WIE Lancom das "Packet type= tagged-only", "Role = Trunk" genau meint.
Tagged only bedeutet auf dem Gros der Switches das dort untagged Packete einfach gedroppet, also weggeschmissen werden. Der Port forwardet einzig nur Pakete mit einem 802.1q Tag. Dann wäre aber die Angabe einer PVID dort Blödsinn, weil sich das widerspricht. Wenn nur tagged Pakete geforwardet werden ist eine PVID Angabe eigentlich überflüssig.
Normal ist es aber so das das native, sprich physische Ethernet Interface des Routers generell die Pakete untagged versendet. Ebenso ist es beim Switch. Billige Switches wie dein Lancom forwarden immer das Default VLAN untagged auf tagged Uplinks.
Folglich liegt also dein Default VLAN 1 des Switches auch direkt auf dem physischen Ethernet 4 Port. Die IP Adressierung muss hier also übereinstimmen.
Du musst also klären ob das "Packet type= tagged-only", "Role = Trunk" wirklich nur strikt tagged Pakete forwardet oder nicht. Macht es das, ist dann natürlich dein Default VLAN 1 blockiert.
Ggf. einen Wireshark nehmen und genau nachsehen was da kommt von der Router- oder Switchseite.
Ist es denn ok, wenn der WSE2016 den DHCP für alle lokalen Netze macht
Ja, generell ist das üblich wenn man einen zentralen DHCP Server betreibt. Solltest du also so machen.das dieser Eintrag dazu dient, Multicasts ins Internet zu verhindern, oder?
Nein, er blockiert nur Multicast Pakete die das RIP Routing Protokoll verwendet.RIPv2 sendet seinen Routing Updates über 224.0.0.9. Steht ja auch so in der Beschreibung sticky RIP.
Muss ich zwingend das Suffix ändern
Langfristig ist es sicher sinnvoller das anzupassen, da du gegen einen Standard verstößt mit deiner Root Domain.
