dominik.k
Goto Top

Vlan Routing, Unify Telefonanlage und L2 Switche

Guten Abend liebe Gemeinde,


ich stehe gerade vor folgender Aufgabe und habe vermutlich ein Verständnisproblem. Ich habe ein "flaches" Netzwerk übernommen will sagen, dass zwar switche vorhanden sind, diese aber nur in der default Konfig genutz wurden.

Folgende Strukturen sind gegeben:

Windows Server mit DHCP, PC´s, Drucker...
Unify Telefonanlage hängt ebenfalls am Netzwerk (wird für Telefonietool benötigt) Die bisherigen Telefone sind System oder Analog Telefone

Nun ist eine Erweiterung geplant. Es kam ein POE-fähiger Zyxel 1920 Switch hinzu. Dieser wurde über LWL Kabel mit bestehendem Switch verbunden.

Es wurden 3 VLans erstellt (1 = Management, 10 für Daten und 20 für VoIP). Diese VLans wurden mit TAG auf LWL-Uplink gesetzt.

Das Tagging funktioniert mit QoS 802.1q auf den restlichen Ports recht gut und mit der Funktion des Switches kann ich alle Ports auf Untaggt belassen (diese sind für die Computer, Drucker usw. und landen im VLan 10). Wenn ein VoIP Telefon mit einer bestimmten MAC kommt, wird dieses sauber in das VLan 20 gesetzt.

Nun zu meinem Problem:
Mir ist klar, dass ich ein Routing machen muss über einen Zusätzlichen Router. Nur habe ich bedenken, dass ich den Trafic falsch lenke und das QOS nicht mehr funktioniert, sprich dass ich ggf Abbrüche beim telefonieren habe.

Wäre es Sinnig, die TK-Anlage in das VLan 20 zu nehmen und die PCs auf das VLan 20 zu Routen?
Oder sollte ich die TK-Anlage im VLan 10 belassen und die IP-Telefone in das Vlan 10 lauschen lassen?
Soll ich die TK-Anlage an den Switchen lassen oder lieber am Router?

Wäre super, wenn mir jemand ne Idee hätte oder ob ich doch lieber einen L3-Switch beschaffen muss.

Content-Key: 358350

Url: https://administrator.de/contentid/358350

Ausgedruckt am: 19.03.2024 um 08:03 Uhr

Mitglied: tikayevent
tikayevent 16.12.2017 um 11:58:19 Uhr
Goto Top
Zum einen hast du einen bösen Designfehler in deinem Netz. VLAN-ID 1 ist das Defaultvlan und sollte nach der Konfiguration unbenutzt sein. In keinem Fall gehören da Managementfunktionen rein.

Bei QoS ist das Router nur eine Teilkomponente. Es müssen alle Komponenten damit umgehen können. Der Switch muss die QoS-Informationen, in der heutigen Zeit meistens auf L3 mittels DiffServ, verarbeiten können und auch akzeptieren. Avaya-Switches z.B. trauen diesen Informationen in der Grundkonfiguration nicht und verwerfen die DiffServ-Flags. Es reicht ein einziger Switch in der Kette, der falsch konfiguriert ist und dann war´s das. Bis man dieses herausgefunden hat, vergehen schon mal zwei Jahre.

Beim Routing in deinem Szenario kann man nicht so viel falsch machen. Ein Router, mindestens drei VLAN-Interfaces, der dann auch für alle Geräte als Default-Gateway eingetragen werden muss und wichtig ist, dass er deine QoS-Methode versteht. Die Flags müssen dann auch korrekt und unverändert mitgeroutet werden.

QoS innerhalb eines kleinen LANs ist nicht so zwingend nötig, wenn man das Netz nicht ständig am Limit betreibt. Es wird erst nötig, wenn man über Verbindungen arbeitet, die geringere Bandbreiten haben, damit die Pakete nicht im Stau landen.

Das Voice-VLAN hat historische Gründe. Früher waren die Embedded-Systeme, wie ein VoIP-Telefon eins ist, nicht so leistungsfähig. Daher hat man versucht, diese von unnötigen Broadcasts fern zu halten, in dem per VLAN einfach eine neue Bcast-Domäne aufgezogen wurde. In der heutigen Zeit ist es nicht mehr zwingend nötig. Ebenso wurde früher das QoS so abgewickelt, bis DiffServ aufkam. Sicherheitsrelevanz hat es nicht. In der heutigen Zeit ist es nicht mehr nötig.
Mitglied: aqui
aqui 16.12.2017 um 13:00:04 Uhr
Goto Top
Es kam ein POE-fähiger Zyxel 1920 Switch hinzu. Dieser wurde über LWL Kabel mit bestehendem Switch verbunden.
Benutzt ihr irgendeine Art von Spanning Tree in dem Netzwerk ? Wenn ja welche ?
Diese VLans wurden mit TAG auf LWL-Uplink gesetzt.
Das ist richtig wenn ihr es auf den allen Uplinks zwischen den Switches gemacht habt. Also bestehende Switches (welche sind das ?) und Zyxel.
Nur dann werden die VLANs transparent in der Infrastruktur übertragen.
Die Segmentierung ist generell ein richtiger Schritt !
Das Tagging funktioniert mit QoS 802.1q
Die Aussage ist technischer Quatsch und nur halbrichtig. .1q Tagging hat mit QoS nur bedingt was zu tun.
In sofern das die QoS Steuerung mit 802.1p gemacht wird. (PCP Bits im .1q Header)
Die 802.1p QoS Bits sind aber immer ein Teil des 802.1q Tagging Headers. Das eine bedingt also das andere, sind aber genau betrachtet 2 unterschiedliche Baustellen.
Wenn man also einen Layer Priorisierung mit 802.1p machen will z.B. der Voice Daten erzwingt das dann auch das das Voice VLAN dann immer getaggt wird.
Klar, denn ohne .1q Header keine .1p Priorisierung.
Wenn also dann bitte auch richtig !
Siehe auch hier die Tag Struktur. Doe PCP Bits innerhalb des .1q Headers sind die 802.1p Priority Bits:
https://de.wikipedia.org/wiki/IEEE_802.1Q
https://de.wikipedia.org/wiki/IEEE_802.1p
Wenn ein VoIP Telefon mit einer bestimmten MAC kommt, wird dieses sauber in das VLan 20 gesetzt.
Das passiert aber logischerweise NICHT von Geisterhand sondern dafür ist LLDP oder ein anderes Infrastruktur Protokoll zuständig zu dem du uns leider gar nicht mitteilst face-sad
Mir ist klar, dass ich ein Routing machen muss über einen Zusätzlichen Router.
Kommt drauf an WIE deinen Voice Komponenten kommunizieren und wo das Voice Gateway plaziert ist. Sprich also wie das IP Design da aussieht. Auch dazu keinerlei Infos.
Aber generell hast du Recht wenn die Anlage auch im Voice VLAN plaziert ist und sie eine SIP Connection von dort zum Provider aufbauen muss und der Provider Router in einem anderen VLAN als dem VLAN 20 steht.
Dann musst du die VLANs routen, das stimmt !
Deine 802.1p Priorisierung ist eine reine Layer 2 Priorisierung und wirkt logischerweise nur in einer Layer 2 Collision Domain, salopp gesprochen also nur in einem VLAN Segment. Routing übergreifend wird diese Information abgeschnitten also vom Router nicht weitergereicht.
Willst du das, musst du eine Layer 3 Priorisierung mit DiffServ DSCP wählen. Dort ist die QoS Priorisierung im Layer 3 IP Header gesetzt die auch Router übergreifend erhalten bleibt.
Andernfalls müsstest du im VLAN Segment wo der Provider Router steht die Voice Pakete erneut mit 802.1p prioridieren.
Auch das geht natürlich indem du den Voice Traffic auf dem Switch mit einer ACL klassifizierst und auch wieder mit .1p priorisierst. Mit einer guten Switch Hardware ist das problemlos möglich.
Nur habe ich bedenken, dass ich den Trafic falsch lenke und das QOS nicht mehr funktioniert
Das kann passieren wenn du die Infrastruktur natürlich falsch konfigurierst. Liegt dann aber logischerweise an dir !
Die Flags müssen dann auch korrekt und unverändert mitgeroutet werden.
Was eben technisch mit 802.1p Layer Priorisierung unmöglich ist. Beim Routing gehen diese Informationen vollständig verloren. Klar, denn der Router "sieht" nur auf den Layer 3 IP Header und ignoriert vollständig was im Layer 2 sprich 802.1q Header steht. Siehe oben....
QoS innerhalb eines kleinen LANs ist nicht so zwingend nötig
Sagt wer ?? Das ist wie immer Trapez ohne Sicherungsnetz. Kann man machen, muss man aber nicht.
wenn man über Verbindungen arbeitet, die geringere Bandbreiten haben, damit die Pakete nicht im Stau landen.
Na ja....recht laienhaft ausgedrückt und nicht wirklich stimmig. Es kann auch von deiner Switch Infrastruktur abhängen ob du billige Gurkenswitches hast mit internen Überbuchungen und wie deren Paket Forwarding strukturiert ist. Mit Low Budget China Switches ist die Gefahr größer als mit etwas gehobenerer Hardware.
Aber ohne detailierte Infos dazu kann man dir nur sagen: "Versuch macht klug !"
Probiere es also aus. Wenns klappt ist gut. Wenn nicht musst du dir doch Gedanken über anständiges und durchgängiges QoS machen.
wie ein VoIP-Telefon eins ist, nicht so leistungsfähig.
Sind sie heute auch nicht. Wenn du die mit Borad- oder Multicasts vollballerst legen die sich auch die Karten. Genau deshalb ist es ja sinnvoll die Voice Komponenten in ein separates VLANs zu setzen. Als Firma bist du auch rechtlich verpflichtet das zu tun. (Fernmeldegeheimnis) um nicht rechtlich angreifbar zu sein.
diese von unnötigen Broadcasts fern zu halten, in dem per VLAN einfach eine neue Bcast-Domäne aufgezogen wurde.
Was ja auch sehr sinnvoll ist...siehe oben !
In der heutigen Zeit ist es nicht mehr zwingend nötig.
Laienhafter Quatsch ! Muss man auch nicht weiter kommentieren !
Ebenso wurde früher das QoS so abgewickelt, bis DiffServ aufkam.
Auch hier no comment zu solch technischem Unsinn....
Sicherheitsrelevanz hat es nicht. In der heutigen Zeit ist es nicht mehr nötig.
Womit du dich dann vollends abgeschossen und disqualifiziert hast zu auch nur irgendwelchem Fachwissen.
Besser du verbreitest solch einen Unfug nicht weiter in einem Administrator Forum face-sad
Mitglied: tikayevent
tikayevent 16.12.2017 um 20:20:17 Uhr
Goto Top
@aqui: Sorry, dass meine Meinungen und Erfahrungen nicht mit deinen stimmig sind, aber ich bin schon lange genug dabei. Obwohl du meinst, dass es falsch wäre, funktioniert es bei mir. Ich glaube meine Technik teilt deine Meinung auch nicht. Es gibt halt immer mehrere Wege zum Ziel, dass solltest du mit deiner Erfahrung doch wissen.

Ich hab es an über 80 Standorten in ganz Deutschland so laufen und es funktioniert. Ich lasse VoIP über billige 20€-Switches laufen, ohne Probleme. Und zum Fernmeldegeheimnis: Es ist egal, ob es über ein VLAN abgewickelt wird oder nicht, es hängt nur davon ab, ob ich meinen TAP vor oder hinter das Telefon packe. Aber Switches sei Dank funktioniert es ja nur zwischen Switch und Telefon und da ist nur ein weiteres Tag vorhanden. Für das Fernmeldegeheimnis wäre eine Verschlüsselung oder eine gesonderte Verkabelung nötig. Bei der gesonderten Verkabelung kann ich auch gleich auf Zweidraht weiterarbeiten. ARP-Spoofing ist mir bekannt. Aber durch die Automatisierung der VLAN-Zuordnung anhand von MAC oder LLDP ist es kein Problem, von einem normalen Clientport ins Voice-VLAN zu gelangen, steht ja am Port auf Anforderung an.

Das es nicht ideal ist, ist klar, aber was ist schon ideal. Egal wie man es macht, es gibt immer Abweichungen von der perfekten Lösung.
Mitglied: aqui
aqui 18.12.2017 aktualisiert um 10:10:12 Uhr
Goto Top
Du meinst sicher das QoS an sich, oder ? Ich habe jetzt, ehrlich gesagt, nicht gesehen wo wir nicht einer Meinung sind. (kommt ja selten bis gar nicht vor face-wink )
Wenn es QoS an sich ist in einen Kleinstumfeld hast du Recht. Dort muss man nicht zwingend QoS machen zumal es auf 20€ Switches ja auch gar nicht geht, da diese das nicht auswerten können.
Eine VoIP Connection nutzt max. 64kBit/s dafür reicht sogar ein feuchter Bindfaden. Mit einem auch ungemanagten GiG Switch ist das so als ob man dann mit einem Tretroller auf der 6spurigen Autobahn fährt....keine Frage das das bei 1-5 und vielleicht auch bis 10 Telefonen so klappt. Es kommt halt darauf an wie viele davon immer gleichzeitig telefonieren und was noch so an "Grundrauischen" im Netz ist.
Darum ging es vermutlich, oder...?!
Generell sollte man aber den Voice Traffic trennen vom Rest, das ist gute Netzwerk Schule. Ob das nun aus Sicherheitsgründen usw. ist, ist erstmal zweitrangig.
Gesicherte und dedizierte Leitungen wie man es früher aus der analogen Telefonie zw. Teilnehmern kannte gibt es halt nicht mehr bei VoIP. Menschen sind aber seit Jahrzehnten an diese Tatsache gewöhnt und können nicht nachvollziehen warum es jetzt bei VoIP eben nicht mehr so ist und ab und zu mal "rumpelt".
Folglich sollte man als Netzwerker natürlich die Infrastruktur so einstellen das auch VoIP möglichst störungsfrei und priorisiert übertragen wird um eben diesem alten Verhalten möglichst nahe zu kommen.
Jeder Netzwerker wird wohl zustimmen das das in größeren Voice Umgebungen wohl nur mit QoS Verfahren möglich ist.
Das es in Klein- oder Kleinstumgebungen anders ist steht natürlich außer Frage. Man kann es da machen, muss es aber nicht.
Mitglied: DOMINIK.K
DOMINIK.K 18.12.2017 um 11:01:25 Uhr
Goto Top
--> Benutzt ihr irgendeine Art von Spanning Tree in dem Netzwerk ?
NEIN
--> Also bestehende Switches (welche sind das ?)
Momentan ebenfalls L2 D-Link Switche (DGS-1920) , die ich erst mitte nächstes Jahr tauschen kann
--> Die Aussage ist technischer Quatsch
OK, verkommen. Die Telefone werden aufjeden Fall über die MAC Adresse erkannt und automatisch in das VLAN für VoIP gesteckt. Das hat der Zyxel Switch mit an Bord und tut.

Ich versuche nochmals mein Problem zu schildern:
TK-Anlage hat momentan ein 10.xxx.xxx.89 und 10.xxx.xxx.88 IP. Diese könnte ich ändern. Wichtig ist wohl, dass die Beiden IP´s sich sehen.
Meine PC´s können über ein Tool auf die 10.x.x.88 Adresse zugreifen.
Ich möchte in dem VoIP Vlan eine 192.168.150.x/24 Netz aufbauen.

Nun die Frage. Belasse ich die TK Anlage im 10 ér Netz ODER wäre es sinniger, die TK Anlage in das neue Netzwerk zu stecken, damit die VoIP-Telefone ohne Routing auf die TK Anlage zugreifen können? Das Routing (was auch immer dieses erledigt (Router, FW oder L3 Switch)) wäre dann "nur" für die PC´s.
Mitglied: tikayevent
tikayevent 18.12.2017 um 13:26:03 Uhr
Goto Top
Wenn du ein extra VLAN aufziehst, lass die TK im jetzigen Netz, einfach weil die TK noch weiteren Traffic produziert, z.B. das Onlineupdate, bei Unify die Verbindung mit dem BoosterServer bzw. der BoosterCard, CSTA und solche Sachen.

Dass die Switches die Telefone anhand der MAC-Adresse in gesonderte VLANs versetzen, ist eine der älteren Methoden, aber ist heute nicht mehr die übliche Art. Heute werden die Informationen per LLDP vom Switch an das Telefon geliefert, zusammen mit z.B. weitergehenden Informationen für DiffServ, also welche DiffServ-Flags für Voice und VoiceSignaling genutzt werden. Hat auch den Grund, dass manche Switches bei der MAC-Methode den kompletten Port ins VLAN versetzen, während bei der LLDP-Methode das Telefon angewiesen wird, das VLAN-Tag zu setzen.
Ein weiterer Nachteil der MAC-Methode ist, dass man sich selbst um die Nachpflege der MAC-Bereiche kümmern muss und es kommt auch mal zu Fehleinordnungen, da z.B. auch andere Geräte aus dem gleichen MAC-Bereich kommen können.

So habe ich z.B. in meinem Cisco SG200-26 mit relativ neuer Firmware den MAC-Bereich 00-01-E3 für Siemens/Unify-Telefone eingetragen, aber direkt beim ersten Telefon, was ich gegriffen habe, steht eine MAC mit 00-1A-E8 drunter. Jetzt kommt das Fiese: Die Unify-Telefonanlagen nutzen auch MAC-Adressen aus 00-1A-E8.
Mitglied: DOMINIK.K
DOMINIK.K 18.12.2017 um 14:21:14 Uhr
Goto Top
Also d.h. Die TK und PC´s im Daten Netzwerk belassen und "nur" ein Routing aus dem VLan aus dem neuen VoIP in das Daten Netzwerk erstellen. Hmm, da hatte ich wohl einen Denkfehler, da ich eher das VoIP Netz, welches höher Priorisiert ist direkt mit der TK Anlage gekoppelt hätte und eher das Daten Netzwerk in das VoIP-Netz geroutet hätte... Gut, dass ich nachgefragt habe.

Danke euch.
Mitglied: DOMINIK.K
DOMINIK.K 25.01.2018 um 14:10:20 Uhr
Goto Top
So, nachdem verschiendene Ansätze nicht machbar waren, habe ich nun einen Layer 3 Switch beschafft.

Ich habe die Anregungen aufgenommen und das VLan 1 komplett tod gemacht.

Nun ist folgendes gegeben:
VLan 10 DATA Untagt auf allen Ports bis auf die 4 Glaß
VLAN 123 für VoIP mit QOS
VLan 5 für den Zugriff auf die Switche
VLan 100 für die Server

Es funktioniert soweit alles nur bin ich mir bei einer Sache noch nicht ganz schlüssig. In meinem DATEN und Server Netz habe ich einen Windows DHCP-Server. Die TK-Anlage bringt für die IP Telefone auch einen DHCP Server mit.
Wenn ich mich recht erinnere, dann gibt es über kurz oder Lang Probleme, wenn in einem Netz mehrere DHCP Server aktiv sind.
Es sind zwar mehrere Netze via TAG getrennt, jedoch durch den L3-Switch sind diese ja dann doch wieder miteinander verbunden.
--> Ich habe in der Kondig von dem L3 gesehen, dass man einen "Relay" beim DHCP Server angeben kann. Bringt das in meinem Fall etwas?
Mitglied: aqui
Lösung aqui 25.01.2018 aktualisiert um 16:44:08 Uhr
Goto Top
habe ich nun einen Layer 3 Switch beschafft.
Hoffentlich den richtigen ?
bis auf die 4 Glaß
Wer oder was ist "Glaß" ?
In meinem DATEN und Server Netz habe ich einen Windows DHCP-Server.
Der Klassiker !
dann gibt es über kurz oder Lang Probleme, wenn in einem Netz mehrere DHCP Server aktiv sind.
Die Betonung liegt auf einem Netz ! Du aber jast ja jetzt sinnvollerweise zwei oder sogar 3 Netze nämlich VLAN 10, VLAN 100 und VLAN 123.
Folglich gilt das also nicht für dich.
In allen diesen 3 VLANs allerdings separate DHCP Server zu haben ist natürlich ziemlicher Blödsinn wenn du einen zentralen auf dem Server hast. So musst du ja vollkommen unsinnigerweise 3 DHCP Server pflegen.
Normalerweise hat man einen zentralen, richtet auf dem L3 Switch einen sog. ip helper oder UDP (DHCP) Forwarder ein der auf die IP des zentralen DHCPs zeigt und richtet auf diesem dann die entsprechenden Scopes ein.
Das wäre der netzwerktechnisch beste und auch sinnvollste Weg.
Es sind zwar mehrere Netze via TAG getrennt
Wer oder was ist "TAG" ?
Deine IP Netze sind ja physisch durch die VLANs vollkomen getrennt, sprich also getrennte Layer 2 Collision Domains. Es ist also so als ob du 3 einzelne Switches hast.
jedoch durch den L3-Switch sind diese ja dann doch wieder miteinander verbunden.
Aber nur im Layer 3.
Wie jeder Netzwerker weiss basiert aber DHCP auf Layer 2 Broadcasts die bekanntermaßen prinzipienbedingt NICHT über Routerports weitergeleitet werden.
Kann es sein das dir hier etwas das Grundlagenwissen zum TCP/IP abhanden gekommen ist.
Am besten also nochmal lesen und verstehen !!
https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol