17
Cisco Catalyst Voice VLAN und DHCP
Moinsen,
unsere Access-Switche sind in die Jahre gekommen und sind auch von der Leistung her schon ziemlich am Limit. Daher ist es geplant alle 19" Access-Switche gegen Cisco C1200-48P-4X und alle Desktop-Switche (da wo zu wenige RJ45-Anschlüsse vorhanden sind) gegen Cisco C1200-8P-E-2G zu tauschen.
Zwei Geräte haben wir bereits getestet und mittlerweile Live im Einsatz. Das passt schon mal. Noch sind die allermeisten VoIP-Telefone an den alten Switchen angeschlossen. Testweise haben wir den Betrieb mit Auto Voice VLAN und Smartport getestet und haben festgestellt, dass mit dem vorhandenen Voice VLAN (160) die Telefone keine DHCP-Adresse erhalten, wenn sie an einem der Cisco Switche angeschlossen werden.
Wir haben es sowohl mit Auto Voice VLAN / Smartport und auch ohne geprüft. Die Erkennung des Telefons über LLDP funktioniert und Smartport setzte auch Office & Voice VLAN richtig. Aber mehr passiert da auch nicht, wenn Voice VLAN ID auf 160 gesetzt ist. An einem der alten Switche klappt das sofort.
Ich habe dann ein neues VLAN erstellt (66) und auf dem Core-Stack und den Cisco hinzugefügt. Dazu ein DHCP-Bereich. Sobald ich nun auf einem Cisco Switch die 66 als Voice VLAN ID setze, bekommt das Telefon eine DHCP-Adresse.
Die VLAN-Einstellungen und DHCP sind identisch bis auf IP-Bereiche. Ich kann keinen Fehler finden, dies ist ärgerlich aber kein großes Drama, wenn alle Access-Switche getauscht sind, dann kann es Voice VLAN 66 statt 160 sein, aber wo liegt hier das Problem?
unsere Access-Switche sind in die Jahre gekommen und sind auch von der Leistung her schon ziemlich am Limit. Daher ist es geplant alle 19" Access-Switche gegen Cisco C1200-48P-4X und alle Desktop-Switche (da wo zu wenige RJ45-Anschlüsse vorhanden sind) gegen Cisco C1200-8P-E-2G zu tauschen.
Zwei Geräte haben wir bereits getestet und mittlerweile Live im Einsatz. Das passt schon mal. Noch sind die allermeisten VoIP-Telefone an den alten Switchen angeschlossen. Testweise haben wir den Betrieb mit Auto Voice VLAN und Smartport getestet und haben festgestellt, dass mit dem vorhandenen Voice VLAN (160) die Telefone keine DHCP-Adresse erhalten, wenn sie an einem der Cisco Switche angeschlossen werden.
Wir haben es sowohl mit Auto Voice VLAN / Smartport und auch ohne geprüft. Die Erkennung des Telefons über LLDP funktioniert und Smartport setzte auch Office & Voice VLAN richtig. Aber mehr passiert da auch nicht, wenn Voice VLAN ID auf 160 gesetzt ist. An einem der alten Switche klappt das sofort.
Ich habe dann ein neues VLAN erstellt (66) und auf dem Core-Stack und den Cisco hinzugefügt. Dazu ein DHCP-Bereich. Sobald ich nun auf einem Cisco Switch die 66 als Voice VLAN ID setze, bekommt das Telefon eine DHCP-Adresse.
Die VLAN-Einstellungen und DHCP sind identisch bis auf IP-Bereiche. Ich kann keinen Fehler finden, dies ist ärgerlich aber kein großes Drama, wenn alle Access-Switche getauscht sind, dann kann es Voice VLAN 66 statt 160 sein, aber wo liegt hier das Problem?
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: 73627113851
Url: https://administrator.de/forum/cisco-catalyst-voice-vlan-und-dhcp-73627113851.html
Ausgedruckt am: 23.12.2024 um 09:12 Uhr
17 Kommentare
Neuester Kommentar
wird das 160er im trunk nicht weitergeleitet? zu anderen switchen?
oder was ist wenn du einen port fix auf VLAN 160 setzt und nen PC dran klemmst?
bekommt der ne IP? Und wenn nicht wo ist das Problem? mit nem PC kannst da vielleicht besser raustesten?
mit nem tracert wo er kleben bleibt (wenn er ne fixe IP bekommt im VLAN 160) usw...
oder was ist wenn du einen port fix auf VLAN 160 setzt und nen PC dran klemmst?
bekommt der ne IP? Und wenn nicht wo ist das Problem? mit nem PC kannst da vielleicht besser raustesten?
mit nem tracert wo er kleben bleibt (wenn er ne fixe IP bekommt im VLAN 160) usw...
Trunk (Desktop-Switch) und LAG (19" Rack-Switch) kennen alle VLANs. Wenn ich IP manuell zuweise im 160er, dann geht auch nix. Dies hat mich dann zu der Idee bewegt, einem der Switche eine Interface IPv4 für VLAN 160 zu geben und die dann zu pingen.... auch nix.
Alle anderen VLAN funktionieren, das ist ja das Sonderbare daran. Auch gerade ein neu hinzugefügtes VLAN (85) mit IP-Interface klappt. Jedoch nicht das 160er, trotz statischer Route bzw. IPv4 Interface.
Alle anderen VLAN funktionieren, das ist ja das Sonderbare daran. Auch gerade ein neu hinzugefügtes VLAN (85) mit IP-Interface klappt. Jedoch nicht das 160er, trotz statischer Route bzw. IPv4 Interface.
Hallo,
https://www.wireshark.org/download.html
https://www.wireshark.org/lists/wireshark-users/200803/msg00237.html
https://wiki.wireshark.org/CaptureSetup/VLAN
Gruss,
Peter
Alle anderen VLAN funktionieren, das ist ja das Sonderbare daran.
Dann solltest du dir mal mit einen Kabelhai anschauen wer deine Daten frisst.https://www.wireshark.org/download.html
https://www.wireshark.org/lists/wireshark-users/200803/msg00237.html
https://wiki.wireshark.org/CaptureSetup/VLAN
Gruss,
Peter
Der "Kabelhai" hilft leider auch nicht aber ich bin nun ein Stückchen weiter gekommen. Die zwei C1200er Switche sind an einen Cisco CBS250 via Trunk angeschlossen. Der CBS250 war das erste Testgerät, wird aber auch ausgetauscht, da die C1200-Serie neuer ist und etwas mehr Features bietet. Dieser scheint das VLAN 160 nicht zu mögen, denn als ich einen der C1200er direkt an den L3 Core-Stack verbunden habe, war VLAN 160 nutzbar.
Warum der CBS250 sich so verhält, ist ein Rätsel. Firmware ist 3.2.1.1 von März 2023 und in den zwei nachfolgenden (Mai 2023 und Dezember 2023) gibt es keine entsprechenden Hinweise, die damit in Zusammenhang zu bringen wären.
Ich warte nun die Bestellung der C1200er ab, der CBS250 wird dann ausgetauscht und ich kann ihn patchen und resetten und dann erneut VLAN 160 prüfen.
Warum der CBS250 sich so verhält, ist ein Rätsel. Firmware ist 3.2.1.1 von März 2023 und in den zwei nachfolgenden (Mai 2023 und Dezember 2023) gibt es keine entsprechenden Hinweise, die damit in Zusammenhang zu bringen wären.
Ich warte nun die Bestellung der C1200er ab, der CBS250 wird dann ausgetauscht und ich kann ihn patchen und resetten und dann erneut VLAN 160 prüfen.
Hallo,
Gruss,
Peter
Zitat von @DerMaddin:
Dieser scheint das VLAN 160 nicht zu mögen, denn als ich einen der C1200er direkt an den L3 Core-Stack verbunden habe, war VLAN 160 nutzbar.
Die NSA hat sich das vLAN 160 gekrallt und nun ist es nicht mehr nutzbar ohne genemigung der CIA und NSA und sogenannte NDAsDieser scheint das VLAN 160 nicht zu mögen, denn als ich einen der C1200er direkt an den L3 Core-Stack verbunden habe, war VLAN 160 nutzbar.
Warum der CBS250 sich so verhält, ist ein Rätsel. Firmware ist 3.2.1.1 von März 2023 und in den zwei nachfolgenden (Mai 2023 und Dezember 2023) gibt es keine entsprechenden Hinweise, die damit in Zusammenhang zu bringen wären.
Aber CISCO kennt deine Antwort.Gruss,
Peter
1
Warum der CBS250 sich so verhält, ist ein Rätsel.
Da du es leider versäumt hast das Wichtigste, nämlich die 250er Konfig, hier einmal zu posten sind wir ja logischerweise auch nur zum Raten und Kristallkugeln gezwungen ohne zielführend das Rätsel für dich lösen zu können.Man kann nur raten das, wie oben schon vermutet, der Trunk (Uplink) am 250er (oder vielleicht auch 1200 oder beides) falsch oder fehlerhaft konfiguriert wurde. Im Default ist das ein Universal Mode was falsch wäre. Aber wie gesagt alles geraten ohne ein show run vom 250er.
Eine weitere Fehlerquelle ist das nicht kompatible Spanning Tree Verfahren beider Modellreihen zu dessen Konfig du auch leider gar nichts sagst. Ebensowenig die STP Priotity ob die entsprechend im Core erhöht wurde.
Die Catalysten verwenden im Default immer das Cisco proprietäre PVSTP+ Verfahren also ein per VLAN Spanning Tree mit proprietären BPDU Mac Adressen was nicht kompatibel ist zu den üblichen Spanning Tree Protokollen insbesondere nicht den einfachen Single Span Verfahren.
Der CBS250 verwendet im Default aber eben RSTP im Single Span Verfahren was, wie gesagt, NICHT zum Catalysten kompatibel ist. Die CBS müssen hier zwingend auch in den PVSTP+ Mode versetzt werden ansonsten kann es zu Loops im STP kommen was dann Blockings nach sich zieht die zu deinem Fehlerbild passen.
Etwas mehr Details bei den recht oberflächlichen Infos würde also allen helfen...
@aqui
Der Trunk ist ein LAG über zwei 1GbE-Ports zum Core-Stack. CBS250 und Core-Stack sprechen RSTP. Gleiches gilt für die C1200er Switche. PVSTP ist hier nicht Default gewesen. Mag sein, dass dies bei den 2960, 3560, und so weiter, der Fall ist, bei 1200 aber nicht.
Was ist ein "Universal Mode"? Meinst du vielleicht eher "General"?
STP und Trunk-Einstellung hin oder her. Dies sollte, mMn, keinen Einfluss haben auf ein VLAN und zwar exakt auf nur eines. Was ich nicht prüfen konnte, ist Voice VLAN und Smartport auf disable setzen, das VLAN löschen und dann neu hinzufügen. Ist aber aktuell im Live-Betrieb eher störend.
Der Trunk ist ein LAG über zwei 1GbE-Ports zum Core-Stack. CBS250 und Core-Stack sprechen RSTP. Gleiches gilt für die C1200er Switche. PVSTP ist hier nicht Default gewesen. Mag sein, dass dies bei den 2960, 3560, und so weiter, der Fall ist, bei 1200 aber nicht.
Was ist ein "Universal Mode"? Meinst du vielleicht eher "General"?
STP und Trunk-Einstellung hin oder her. Dies sollte, mMn, keinen Einfluss haben auf ein VLAN und zwar exakt auf nur eines. Was ich nicht prüfen konnte, ist Voice VLAN und Smartport auf disable setzen, das VLAN löschen und dann neu hinzufügen. Ist aber aktuell im Live-Betrieb eher störend.
Gleiches gilt für die C1200er Switche.
Das stimmt so nicht und kann nicht funktionieren, denn Catalysten supporten bekanntlich kein RSTP!!Die können nur PVSTP+ und den Standard MSTP!
Siehe z.B. auch HIER.
Meinst du vielleicht eher "General"?
Ja, sorry freudsche Fehlleistung. 
Dies sollte, mMn, keinen Einfluss haben auf ein VLAN und zwar exakt auf nur eines.
Auch das ist so pausch gesagt falsch. Wird es nicht richtig übertragen weder mit Tag noch als native VLAN kommt es nicht an. Es hat also dann sehr wohl gravierende Auswirkungen.Richte dir einen Mirror Port ein und sniffer das mit dem Kabelhai mit, dann hast du doch Gewissheit.
Zitat von @aqui:
Richte dir einen Mirror Port ein und sniffer das mit dem Kabelhai mit, dann hast du doch Gewissheit.
Dies sollte, mMn, keinen Einfluss haben auf ein VLAN und zwar exakt auf nur eines.
Auch das ist so pausch gesagt falsch. Wird es nicht richtig übertragen weder mit Tag noch als native VLAN kommt es nicht an. Es hat also dann sehr wohl gravierende Auswirkungen.Richte dir einen Mirror Port ein und sniffer das mit dem Kabelhai mit, dann hast du doch Gewissheit.
Das ist mir nicht klar wie das "nicht richtig übertragen" wird. Denn auf der L3-Core Seite sind alle VLANs in den LAG/Trunks bis auf das 1er getagged. Das Tag wird ja nicht auf der CBS250 LAG Seite auf wundersame Weise verschwinden. Native VLAN ist nicht verändert, also die 1, auf allen Switchen, Routern und Firewalls.
Danke für das Feedback. Dann hat man diesen "Billig" Catalysten wohl auch RSTP beigebracht. Bei den "richtigen" Catalysten gibt es diese Option de facto nicht!
Interessant auch das diese Catalysten dann scheinbar auch nicht das klassische PVSTP+ supporten was die "richtigen" Catalysten im Default machen.
Zumindestens die CBS konnten das noch. Die Policy muss man dann auch mal verstehen weil das dann bei gleichem Modellnamen in gemischen 1000er und z.B. 9000er Netzen die Migration auf MSTP erzwingt will man eine homogene STP Infrastruktur. 🤔
Sollten die 1000er die CBS Reihe vielleicht mal langfristig ablösen wäre das keine gute Nachricht.
Interessant auch das diese Catalysten dann scheinbar auch nicht das klassische PVSTP+ supporten was die "richtigen" Catalysten im Default machen.
Zumindestens die CBS konnten das noch. Die Policy muss man dann auch mal verstehen weil das dann bei gleichem Modellnamen in gemischen 1000er und z.B. 9000er Netzen die Migration auf MSTP erzwingt will man eine homogene STP Infrastruktur. 🤔
Sollten die 1000er die CBS Reihe vielleicht mal langfristig ablösen wäre das keine gute Nachricht.
sind alle VLANs in den LAG/Trunks mit auf das 1er getagged.
WAS genau ist mit dem ominösen "1er" gemeint?? 🤔 Wenn das "1er VLAN" dein native VLAN ist kann man es logischerweise NICHT taggen...?!Zitat von @aqui:
sind alle VLANs in den LAG/Trunks mit auf das 1er getagged.
WAS genau ist mit dem ominösen "1er" gemeint?? 🤔 Wenn das "1er VLAN" dein native VLAN ist kann man es logischerweise NICHT taggen...?!Hab das gerade korrigiert -> das Default VLAN1 (native) ist in jedem Trunk untagged, alle anderen tagged, so wie es sein soll.
Dann ist es richtig und man kann das als Fehler dann ausschliessen sofern es auf beiden Switchseiten des Trunks so ist?!
Kann man ja beidseitig auch testen und Clients in die betreffenden VLANs stecken und die Connectivity auf beiden Seiten trunkübergreifend checken. Ist die gegeben ist zumindestens in dem Punkt alles richtig.
Kann man ja beidseitig auch testen und Clients in die betreffenden VLANs stecken und die Connectivity auf beiden Seiten trunkübergreifend checken. Ist die gegeben ist zumindestens in dem Punkt alles richtig.
Und ob das schon nicht merkwürdig genug wäre, ich kann noch einen nachlegen. VLAN 160 auf dem CBS250 geht nicht mit z.B. einem Laptop in DHCP-Modus und auch nicht manueller Einstellung. VoIP-Telefone, hier die Modelle OpenScape Desk Phone CP700, auch keine Verbindung.
Ich habe ein OpenScape Desk Phone CP600 (Unterschied nur marginal zu CP700) angeschlossen und es funktioniert! Damit wäre es zumindest klar gestellt, dass VLAN 160 auf dem CBS250 mehr oder weniger vorhanden ist. Habe dem CBS250 für VLAN 160 eine IPv4 mit 192.168.160.80 gegeben (DHCP ist erst von .100 bis .200). Ping vom L3-Core ohne Erfolg. Ping vom CP600 klappt. Ein an den CP600 angeschlossenes Laptop bekommt eine Office-VLAN DHCP-Adresse, ein Ping zum CBS250 VLAN 160 IPv4 Interface aber geht nicht.
Wenn also Auto VLAN / Smartport hier greifen, DHCP-Requests weitergeleitet und beantwortet werden, dann sollte es bei allen anderen Geräten auch funktionieren, tut es aber nicht.
Ich habe ein OpenScape Desk Phone CP600 (Unterschied nur marginal zu CP700) angeschlossen und es funktioniert! Damit wäre es zumindest klar gestellt, dass VLAN 160 auf dem CBS250 mehr oder weniger vorhanden ist. Habe dem CBS250 für VLAN 160 eine IPv4 mit 192.168.160.80 gegeben (DHCP ist erst von .100 bis .200). Ping vom L3-Core ohne Erfolg. Ping vom CP600 klappt. Ein an den CP600 angeschlossenes Laptop bekommt eine Office-VLAN DHCP-Adresse, ein Ping zum CBS250 VLAN 160 IPv4 Interface aber geht nicht.
Wenn also Auto VLAN / Smartport hier greifen, DHCP-Requests weitergeleitet und beantwortet werden, dann sollte es bei allen anderen Geräten auch funktionieren, tut es aber nicht.
Ping vom L3-Core ohne Erfolg.
2 Fragen dazu:- Default Route bzw. Default Gateway "0.0.0.0/0 <core_192.168.160.x_ip> " hast du im 250er gesetzt?? Ansonsten scheitert die Rückroute beim Ping!
- Beim Ping vom Core solltest du eine Source IP bestimmen ansonsten nimmt der Core, da er ja prinzipbedingt mehrere (Absender) IPs zur Auswahl hat, willkürlich die niedrigste IP. Solltest du ACLs oder Firewall Regeln haben dazwischen kann der Ping dann scheitern. Ggf. also hier als Source auch seine 192.168.160.x IP setzen. Dann sollte der Ping immer klappen!
Das der Ping scheitert kann nur an irgendwelchen Accesslisten oder Firewall Regeln (ICMP Blocking) liegen oder fehlenden Default Gateways oder Routen.
Zur Erinnerung dazu nochmal das Layer 3 VLAN Tutorial als Stütze.
Hallo,
Mache einen Wireshark mitschnitt und du hast gewissheit und sparst dir und uns deine Was Wäre Wenn Theorien.
Gruss,
Peter
Mache einen Wireshark mitschnitt und du hast gewissheit und sparst dir und uns deine Was Wäre Wenn Theorien.
Wenn also Auto VLAN / Smartport hier greifen, DHCP-Requests weitergeleitet und beantwortet werden, dann sollte es bei allen anderen Geräten auch funktionieren, tut es aber nicht.
Ein Mitschnitt mit den Kabelhai sagt dir warum es eben nicht tut.Gruss,
Peter
1
Leider hat mich am Freitag eine fiese Erkältung erwischt (eigentlich alle in der Familie), so dass ich erst heute wieder arbeite, daher kann es noch bis morgen dauern, bis ich was machen kann. Aber kurz auf aqui und Pjordorf eingehen...
@aqui: Default GW ist auf dem 250er eingetragen.
@pjodorf: muss ich nochmal testen
@aqui: Default GW ist auf dem 250er eingetragen.
@pjodorf: muss ich nochmal testen
