8
2 DHCP Server auf 2 VLANs kanalisieren - Cisco, Microsoft, VoIP - option 242
Hallo zusammen,
ich habe eine Frage zu einem Netzwerkaufbau bzw. der korrekten Verteilung und den Befehlen der DHCP Adressvergabe.
Microsoft Netzwerk mit MS DHCP Server für VLAN1.
Switchumgebung auf Cisco mit unter anderem einem VoIP VLAN4 --- VLAN1 wird hier auch entsprechend verteilt / durchgelassen.
Angeschlossen werden VoIP Telefone im Daisy Chain Mode, also LAN -> Tel -> PC.
Die Telefone sollen die IP Adressen von einem DHCP Server ( intern über den Cisco Switch ) erhalten.
Das ist so "gewollt" bzw. die Switche sind teilweise ferngewartet...
Aktuell ist es so, das die Clients ohne Problem die DHCP Adresse aus dem VLAN1 erhalten.
Die Telefone bekommen aber keine aus dem VLAN4, sondern eben auch vom MS Server.
Final soll nun ein Kommando auf dem MS DHCP installiert werden, welches den Telefonen den Tag VLAN1 nimmt und sagt VLAN4 benutzen.
Es soll dies sein:
option 242 ascii "L2QVLAN=4 Static =3"
Kennt dies jemand bzw. wenn, wie soll dies auf dem MS Server eingetragen werden?
Vielen Dank für etwas Auf- und Erklärung!
Oder andere Lösungen
Gruß
Andy
ich habe eine Frage zu einem Netzwerkaufbau bzw. der korrekten Verteilung und den Befehlen der DHCP Adressvergabe.
Microsoft Netzwerk mit MS DHCP Server für VLAN1.
Switchumgebung auf Cisco mit unter anderem einem VoIP VLAN4 --- VLAN1 wird hier auch entsprechend verteilt / durchgelassen.
Angeschlossen werden VoIP Telefone im Daisy Chain Mode, also LAN -> Tel -> PC.
Die Telefone sollen die IP Adressen von einem DHCP Server ( intern über den Cisco Switch ) erhalten.
Das ist so "gewollt" bzw. die Switche sind teilweise ferngewartet...
Aktuell ist es so, das die Clients ohne Problem die DHCP Adresse aus dem VLAN1 erhalten.
Die Telefone bekommen aber keine aus dem VLAN4, sondern eben auch vom MS Server.
Final soll nun ein Kommando auf dem MS DHCP installiert werden, welches den Telefonen den Tag VLAN1 nimmt und sagt VLAN4 benutzen.
Es soll dies sein:
option 242 ascii "L2QVLAN=4 Static =3"
Kennt dies jemand bzw. wenn, wie soll dies auf dem MS Server eingetragen werden?
Vielen Dank für etwas Auf- und Erklärung!
Oder andere Lösungen
Gruß
Andy
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 279884
Url: https://administrator.de/forum/2-dhcp-server-auf-2-vlans-kanalisieren-cisco-microsoft-voip-option-242-279884.html
Ausgedruckt am: 23.12.2024 um 03:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
und wenn das Telefon in VLAN4 eine IP aus VLAN1 hat, kannst Du es dann anpingen?
Wenn ja ist VLAN4 ja nicht von VLAN1 getrennt und der DHCP von MS ist einfach schneller. (Problem wenn der andere DHCP auch verteilen will und es nach VLAN1 schafft)
Ist der DHCP vom Cisco an und kommt bei dem auch eine Anfrage an? Bekommt der Cisco DHCP den MS DHCP mit und sagt ich will kein RougeDHCP sein und mache nix?
Gruß
Chonta
und wenn das Telefon in VLAN4 eine IP aus VLAN1 hat, kannst Du es dann anpingen?
Wenn ja ist VLAN4 ja nicht von VLAN1 getrennt und der DHCP von MS ist einfach schneller. (Problem wenn der andere DHCP auch verteilen will und es nach VLAN1 schafft)
Ist der DHCP vom Cisco an und kommt bei dem auch eine Anfrage an? Bekommt der Cisco DHCP den MS DHCP mit und sagt ich will kein RougeDHCP sein und mache nix?
Gruß
Chonta
Wenn du Telefone Daisy-Chainst musst du denen normalerweise vorher sagen in welchem VLAN sie sind und in welchem der PC der dranhängt, am Switch Port setzt du dann beide auf tagged bzw. eins auf tagged eins auf untagged, jetzt mal unabhängig vom Hersteller. Das hast du gemacht oder?
Wenn du einen MS DHCP in zwei Netze hängen willst brauchst du lediglich ein zweites Interface dafür oder ein virtuelles das getaggt ist. Bei virtualisierten Kisten ganz easy, bei nicht virtualisierten mit Tricks evtl. auch machbar.
Wenn du einen MS DHCP in zwei Netze hängen willst brauchst du lediglich ein zweites Interface dafür oder ein virtuelles das getaggt ist. Bei virtualisierten Kisten ganz easy, bei nicht virtualisierten mit Tricks evtl. auch machbar.
Moin,
Wir haben das bei uns am Switch so gelöst:
- VLAN-Client untagged
- VLAN-VOIP tagged
Bei unseren Snom Telefonen setzen wir einfach den LAN Port auf tagged mit der VOIP-ID und alles funktioniert problemlos.
VG
Val
Final soll nun ein Kommando auf dem MS DHCP installiert werden, welches den Telefonen den Tag VLAN1 nimmt und sagt VLAN4 benutzen.
Wie soll das funktionieren?Wir haben das bei uns am Switch so gelöst:
- VLAN-Client untagged
- VLAN-VOIP tagged
Bei unseren Snom Telefonen setzen wir einfach den LAN Port auf tagged mit der VOIP-ID und alles funktioniert problemlos.
VG
Val
Im Grunde ist das ganz einfach....
Du routest ja irgendwo zwischen den VLANs auf einem Cisco L3 Switch. Dort trägst du am VLAN IP Interface für das VLAN 4 dein telefon VLAN eine sog. ip helper address xyz ein, wobei xyz auf die IP Adresse des MS servers zeigt der DHCP Server ist.
Auf diesem Server trägst du dann einen weiteren Scope (Bereich) ein für das IP netzwerk des VLAN 4 und fertig ist der Lack.
Der Cisco Switch erkennt dann DHCP Request Broadcasts der Telefone und forwardet die auf die in der Helper Adress angegebenen IP Adresse. Damit landen diese Requests dann beim MS DHCP Server der dann aus dem Scope für das VLAN 4 einen Lease zurückschickt den der Switch dann an den Client forwardet und schon hat der Client sprich Telefon eine passende IP mit Gateway, DNS etc. aus dem VLAN 4.
Wie gesagt...kein Hexenwerk und kinderleicht zu lösen ! Das ist eine standartisierte Konfig in der Masse aller VLAN segmentierten Netzen die zentralisierte DHCP Server nutzen...also quasi überall.
Kein Netzwerker arbeitet da natürlich dann mit multiplen Interfaces am Server. Wenn man 20 VLANs hat wäre das eh utopischer Unsinn.
Die Telefone booten ihre Images beim einschlaten oder Anstecken an einen PoE Switch meist zentral vom Voice Gateway per TFTP (PootP) oder PXE und bekommen von dem auch zentral ihre VLANs bzw. Konfig zugeordnet.
Alternativ geschieht das ebenfalls automatisch per LLDP. Das Telefon signalisiert dem Switch dann seine VLANs und der setzt entsprechend den Port.
Beide Verfahren sind heute simpler Standard in Voice Umgebungen. Meist ist das auch zwingend erforderlich, denn Telefon werden sehr häufig mit 802.1p im L2 priorisiert (Voice Priorisierung). 802.1p ist immer ein Teil von 802.1q also VLAN Tagging. Das heisst einen Layer 2 Priorisierung des Voice Traffics ist zwingend mit einem Tagging verbunden:
https://de.wikipedia.org/wiki/IEEE_802.1p
Das ist natürlich klar das du das sicherstellen musst, das Telefon und kaskadierter PC im entsprechenden VLAN arbeiten, was aber kein Problem ist und einfach zu machen ist mit den beiden obigen Verfahren.
Sofern deine Switch HW das supportet kann man die kaskadierten PCs auch dynamisch per 802.1x einem VLAN zuordnen.
Dazu lieferst du aber viel zuwenig Informationen um dazu etwas detailierter einzugehen.
Du routest ja irgendwo zwischen den VLANs auf einem Cisco L3 Switch. Dort trägst du am VLAN IP Interface für das VLAN 4 dein telefon VLAN eine sog. ip helper address xyz ein, wobei xyz auf die IP Adresse des MS servers zeigt der DHCP Server ist.
Auf diesem Server trägst du dann einen weiteren Scope (Bereich) ein für das IP netzwerk des VLAN 4 und fertig ist der Lack.
Der Cisco Switch erkennt dann DHCP Request Broadcasts der Telefone und forwardet die auf die in der Helper Adress angegebenen IP Adresse. Damit landen diese Requests dann beim MS DHCP Server der dann aus dem Scope für das VLAN 4 einen Lease zurückschickt den der Switch dann an den Client forwardet und schon hat der Client sprich Telefon eine passende IP mit Gateway, DNS etc. aus dem VLAN 4.
Wie gesagt...kein Hexenwerk und kinderleicht zu lösen ! Das ist eine standartisierte Konfig in der Masse aller VLAN segmentierten Netzen die zentralisierte DHCP Server nutzen...also quasi überall.
Kein Netzwerker arbeitet da natürlich dann mit multiplen Interfaces am Server. Wenn man 20 VLANs hat wäre das eh utopischer Unsinn.
Die Telefone booten ihre Images beim einschlaten oder Anstecken an einen PoE Switch meist zentral vom Voice Gateway per TFTP (PootP) oder PXE und bekommen von dem auch zentral ihre VLANs bzw. Konfig zugeordnet.
Alternativ geschieht das ebenfalls automatisch per LLDP. Das Telefon signalisiert dem Switch dann seine VLANs und der setzt entsprechend den Port.
Beide Verfahren sind heute simpler Standard in Voice Umgebungen. Meist ist das auch zwingend erforderlich, denn Telefon werden sehr häufig mit 802.1p im L2 priorisiert (Voice Priorisierung). 802.1p ist immer ein Teil von 802.1q also VLAN Tagging. Das heisst einen Layer 2 Priorisierung des Voice Traffics ist zwingend mit einem Tagging verbunden:
https://de.wikipedia.org/wiki/IEEE_802.1p
Das ist natürlich klar das du das sicherstellen musst, das Telefon und kaskadierter PC im entsprechenden VLAN arbeiten, was aber kein Problem ist und einfach zu machen ist mit den beiden obigen Verfahren.
Sofern deine Switch HW das supportet kann man die kaskadierten PCs auch dynamisch per 802.1x einem VLAN zuordnen.
Dazu lieferst du aber viel zuwenig Informationen um dazu etwas detailierter einzugehen.
Vielen Dank für die Feedbacks und auch letzte ausführliche Antwort.
Die zentralisierte DHCP Sache ist aktuell nicht machbar und soll eben über diese beiden DHCPs realisiert werden.
Die iphelper Konfiguration ist auch mir so bekannt, aber hier geht es leider auch um interne "Zuständigkeiten".
Wie auch immer dies ist ja nicht das Thema!
Ich habe noch zu den Avaya den folgenden Artikel gefunden, hier gibt es eine ähnliche Aufgabenlösung ( auch wenn dies die zentralisierten Scopes sind ) - aber vor allem betr. option242 .
http://www.ipofficeassistance.com/howto_dhcp_ip_phones/
Unsere hoffentlich einfache und funktionierende Lösung poste ich dann noch.
Danke!
Die zentralisierte DHCP Sache ist aktuell nicht machbar und soll eben über diese beiden DHCPs realisiert werden.
Die iphelper Konfiguration ist auch mir so bekannt, aber hier geht es leider auch um interne "Zuständigkeiten".
Wie auch immer dies ist ja nicht das Thema!
Ich habe noch zu den Avaya den folgenden Artikel gefunden, hier gibt es eine ähnliche Aufgabenlösung ( auch wenn dies die zentralisierten Scopes sind ) - aber vor allem betr. option242 .
http://www.ipofficeassistance.com/howto_dhcp_ip_phones/
Unsere hoffentlich einfache und funktionierende Lösung poste ich dann noch.
Danke!
Unsere hoffentlich einfache und funktionierende Lösung
Die kann es schonmal per se aufgrund deiner unsinnigen "politischen" Probleme von oben ja schon mal gar nicht geben !Dann musst du die technisch rumpelige Lösug mit den 2 unabhängigen DHCPs halt gehen...bleibt dir ja sonst nichts anderes übrig.
Sinnvoller wäre es natürlich die Politik zu regeln !
Hallo,
sorry für die etwas spätere Rückantwort, aber die ganze Umstellung hat einige Zeit in Anspruch genommen.
Wir konnten nun Dank vieler Diskussionen das Ganze anders aufziehen.
Also in der Kürze schon so wie es gehören sollte:
Avaya Server etc. alles im VLAN4 mit den entsprechenden IPs.
Die Telefone bekommen normal eine IP vom MS DHCP Server, lesen die option242 Einstellung, verbinden sich nochmals mit demselben DHCP und erhalten hier nun aus einem 2ten Scope inkl. weiterer option Einstellung eine VLAN4 IP. Danach verbinden sie sich mit dem Avaya Server und erhalten evtl. Firmware und Einstellungen.
Dazu waren noch ein paar FW Policys nötig.
Funktion ist nun endlich da, kleinere andere Baustellen gibt es natürlich noch.
Danke für die Comments.
Gruß
Andy
sorry für die etwas spätere Rückantwort, aber die ganze Umstellung hat einige Zeit in Anspruch genommen.
Wir konnten nun Dank vieler Diskussionen das Ganze anders aufziehen.
Also in der Kürze schon so wie es gehören sollte:
Avaya Server etc. alles im VLAN4 mit den entsprechenden IPs.
Die Telefone bekommen normal eine IP vom MS DHCP Server, lesen die option242 Einstellung, verbinden sich nochmals mit demselben DHCP und erhalten hier nun aus einem 2ten Scope inkl. weiterer option Einstellung eine VLAN4 IP. Danach verbinden sie sich mit dem Avaya Server und erhalten evtl. Firmware und Einstellungen.
Dazu waren noch ein paar FW Policys nötig.
Funktion ist nun endlich da, kleinere andere Baustellen gibt es natürlich noch.
Danke für die Comments.
Gruß
Andy
Sogar mit "Auweia" klappt das 
