PfSense - Kea DHCP - IP-Telefonie
Guten Tag,
nachdem ich in meiner pfSense DHCP in Kea DHCP geändert habe, bekommen meine Cisco 7965-Telefone keine Daten. Im "alten" DHCP hatte ich die Option 150 eingeschaltet. Diese finde ich in Kea DHCP nicht.
Wie komme ich weiter? Danke!
nachdem ich in meiner pfSense DHCP in Kea DHCP geändert habe, bekommen meine Cisco 7965-Telefone keine Daten. Im "alten" DHCP hatte ich die Option 150 eingeschaltet. Diese finde ich in Kea DHCP nicht.
Wie komme ich weiter? Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8950738007
Url: https://administrator.de/contentid/8950738007
Ausgedruckt am: 21.11.2024 um 12:11 Uhr
17 Kommentare
Neuester Kommentar
Moinsen,
KEA ist noch nicht voll integriert (auch wenn die Nachricht etwas blöd formuliert ist, dass ISC DHCP ausläuft und gewechselt werden soll). Das netgate Forum ist davon ebenfalls voll ("geht nicht", "fehlt was") mit solchen Anfragen.
Aktuell ist es vermutlich am einfachsten, bei ISC dhcp zu bleiben und abzuwarten, bis KEA vollständig(er) implementiert ist (angeblich mit einer der neuen plus Versionen demnächst).
Guckste hier:
https://forum.netgate.com/topic/183930/getting-kea-dhcp-mass-entried-in- ...
https://forum.netgate.com/topic/188337/kea-dhcp-stops-working/8
und hier
https://forum.netgate.com/topic/188430/switch-over-from-isc-dhcp-to-kea- ...
KEA ist noch nicht voll integriert (auch wenn die Nachricht etwas blöd formuliert ist, dass ISC DHCP ausläuft und gewechselt werden soll). Das netgate Forum ist davon ebenfalls voll ("geht nicht", "fehlt was") mit solchen Anfragen.
Aktuell ist es vermutlich am einfachsten, bei ISC dhcp zu bleiben und abzuwarten, bis KEA vollständig(er) implementiert ist (angeblich mit einer der neuen plus Versionen demnächst).
Guckste hier:
https://forum.netgate.com/topic/183930/getting-kea-dhcp-mass-entried-in- ...
https://forum.netgate.com/topic/188337/kea-dhcp-stops-working/8
und hier
https://forum.netgate.com/topic/188430/switch-over-from-isc-dhcp-to-kea- ...
Moinsen,
jau...aber im Nachhinein ist mensch ja immer /meistens /manchmal schlauer...
Geht aber vielen so (wie im Herstellerforum ja dokumentiert) und idT ist die Formulierung der Nachricht unter Services > DHCP Server etwas ungeschickt...
Zurückstellen und abwarten, bis die Release notes grünes Licht geben (und dann noch ein paar Tage warten, bis die ersten Fehler bekannt und hoffentlich gepatcht sind).
jau...aber im Nachhinein ist mensch ja immer /meistens /manchmal schlauer...
Geht aber vielen so (wie im Herstellerforum ja dokumentiert) und idT ist die Formulierung der Nachricht unter Services > DHCP Server etwas ungeschickt...
Zurückstellen und abwarten, bis die Release notes grünes Licht geben (und dann noch ein paar Tage warten, bis die ersten Fehler bekannt und hoffentlich gepatcht sind).
Nur nebenbei:
Du benötigst die Option 150 (TFTP Server IP) für die Cisco Telefone nicht zwingend. Sofern die Telefone eine entsprechende Konfig gezogen haben booten sie danach problemlos auch ohne Option 150.
Das Cisco Telefon bootet nach einem TFTP Timeout immer die zuletzt geladene Konfig aus dem Flash.
Eigentlich benötigt man die Option 150 nur dann wenn man Änderungen an der Telefon Konfig gemacht hat so das das Telefon dann die Konfig Datei einmal neu einliest.
Siehe dazu auch HIER.
Du benötigst die Option 150 (TFTP Server IP) für die Cisco Telefone nicht zwingend. Sofern die Telefone eine entsprechende Konfig gezogen haben booten sie danach problemlos auch ohne Option 150.
Das Cisco Telefon bootet nach einem TFTP Timeout immer die zuletzt geladene Konfig aus dem Flash.
Eigentlich benötigt man die Option 150 nur dann wenn man Änderungen an der Telefon Konfig gemacht hat so das das Telefon dann die Konfig Datei einmal neu einliest.
Siehe dazu auch HIER.
In der ISC Knowledgebase steht übrigens auch das die DHCP Option 150 in KEA derzeit noch nicht supportet ist:
https://kb.isc.org/docs/standard-dhcp-options
https://kb.isc.org/docs/standard-dhcp-options
Jetzt habe ich den Fehler, daß das Cisco 7965...
Nutzt du das Telefon in einem allgemeinen SIP Umfeld wie HIER beschrieben oder in einem klassischen Cisco Call Manager Umfeld??Der Hinweis oben gilt nur für ein klassisches SIP Umfeld!
Es ist möglich das du statt eines Factory Resets des Telefons, was dann die Konfig Datei vom TFTP neu lädt und im lokalen Flash speichert, einfach nur die Konfig Datei auf dem TFTP angepasst hast und eine alte, nicht passende Konfig Datei im Flash verblieben ist?
Sofern das Telefon einen TFTP findet bootet es die Konfig immer von dort. Wird kein TFTP gefunden lädt es beim Booten die letzte im eigenen Flash gesicherte Konfig Datei. Deshalb sind diese Options eigentlich nur zum Laden der Konfig nötig, im Normalbetrieb aber nicht. Stell dir vor du müsstest in einem mobilen Office wo du das Telefon immer mitnimmst auch einen TFTP Server mitschleppen der die Konfig vorhält. Das wäre recht unsinnig in Zeiten von mobilem VoIP!
Sehr wahrscheinlich hast du also vergessen bei einer Änderung einen Factory Reset zu machen um so das neue Laden der Konfig in den Telefonflash zu erzwingen.
Auf einem Cisco Router oder Switch mit DHCP Funktion sieht das z.B. so aus:
Wie bereits gesagt: Ist die aktuelle Konfig einmal im Telefon geflasht sind diese beiden Einträge obsolet!
Sofern das Telefon einen TFTP findet bootet es die Konfig immer von dort. Wird kein TFTP gefunden lädt es beim Booten die letzte im eigenen Flash gesicherte Konfig Datei. Deshalb sind diese Options eigentlich nur zum Laden der Konfig nötig, im Normalbetrieb aber nicht. Stell dir vor du müsstest in einem mobilen Office wo du das Telefon immer mitnimmst auch einen TFTP Server mitschleppen der die Konfig vorhält. Das wäre recht unsinnig in Zeiten von mobilem VoIP!
Sehr wahrscheinlich hast du also vergessen bei einer Änderung einen Factory Reset zu machen um so das neue Laden der Konfig in den Telefonflash zu erzwingen.
Der TFTP der pfSense muß die gleiche IP haben, wie die pfSense selbst
Ja, sofern der TFTP Server ein Dienst auf der pfSense ist und dem LAN Interface zugeordnet ist.Denn egal ob ich die Option 66 / 150 mit der IP des TFTP eingetragen habe
Es müssen beide Options für das Telefon im DHCP Server eingetragen sein.Auf einem Cisco Router oder Switch mit DHCP Funktion sieht das z.B. so aus:
ip dhcp pool cisco8811
host 192.168.2.156 255.255.255.0
client-identifier 01b8.bebf.9cb7.a8
client-name c8811
option 66 ip 192.168.2.1
option 150 ip 192.168.2.1
Wenn die XML Konfig Dateien z.B. SEP32AB12C3D456.cnf.xml im TFTP Root liegen sollte das eigentlich nicht passieren.
"Unprovisioned" kann auch bedeuten das das Telefon den SIP Server nicht findet. Nutzt du da die IP oder einen Hostnamen. Bei Hostnamen beachte das der DNS Server den auflösen können muss.
Möglich auch das die SIP User/Pass Credentials nicht stimmen. Das müsste man in SIP Server Log oder per Wireshark mal checken.
Beachte auch das das Telefon den Boot Prozess 2mal bei einem Factory Reset durchläuft. Hier ist also etwas Geduld gefragt (ca. 10 Minuten).
"Unprovisioned" kann auch bedeuten das das Telefon den SIP Server nicht findet. Nutzt du da die IP oder einen Hostnamen. Bei Hostnamen beachte das der DNS Server den auflösen können muss.
Möglich auch das die SIP User/Pass Credentials nicht stimmen. Das müsste man in SIP Server Log oder per Wireshark mal checken.
Beachte auch das das Telefon den Boot Prozess 2mal bei einem Factory Reset durchläuft. Hier ist also etwas Geduld gefragt (ca. 10 Minuten).
Die spannende Frage ist dann WO diese "funktionierende" Konfig herkommt die es lädt und warum es die neue Konfig nicht lädt??
Du kannst das ja auch am TFTP64 sehen wenndu parallel das Log öffnest denn TFTP64 zeigt dir ja alle Files an die es an ein Ziel sendet was diese requested hat. Folglich muss da also eine falsche XML Datei geladen werden.
Die XML Datei enthält im Dateinamen ja immer die Mac Adresse. Checke also ob dies mit dem Aufdruck auf der Rückseite übereinstimmt und beobachte die Dateien die der TFTP sendet.
Das 7965er lädt immer nur die SEPxyz Datei die seiner Mac Adresse entspricht. Es ist zu vermuten das du ggf. die falsche XML Datei bearbeitet hast?!
Du kannst das ja auch am TFTP64 sehen wenndu parallel das Log öffnest denn TFTP64 zeigt dir ja alle Files an die es an ein Ziel sendet was diese requested hat. Folglich muss da also eine falsche XML Datei geladen werden.
Die XML Datei enthält im Dateinamen ja immer die Mac Adresse. Checke also ob dies mit dem Aufdruck auf der Rückseite übereinstimmt und beobachte die Dateien die der TFTP sendet.
Das 7965er lädt immer nur die SEPxyz Datei die seiner Mac Adresse entspricht. Es ist zu vermuten das du ggf. die falsche XML Datei bearbeitet hast?!
Oder laden sie diese jedesmal nach einem Neustart
Wie oben schon mehrfach gesagt...- TFTP Server vorhanden = Läd die Konfig Datei vom TFTP
- TFTP Server nicht vorahnden = Läd nach einem Timeout die letzte lokal geladene Konfig aus dem Flash.
Nein eigentlich nicht, denn die Firmware selber wird damit nicht verändert. Das ist lediglich eine Problematik der XML Konfig Datei.
Im Zweifel mal einen Wireshark mitlaufen lassen und checken ob sich das Telefon versucht am SIP Server zu registrieren.
Sofern das eine Fritzbox ist bedenke das in aktueller Fritzbox Firmware keine UDP Encapsulation bei SIP mehr supportet ist und es auch Änderungen an den User und Passworten gegeben hat! (Siehe Fritzbox Tips im Tutorial)
Im Zweifel mal einen Wireshark mitlaufen lassen und checken ob sich das Telefon versucht am SIP Server zu registrieren.
Sofern das eine Fritzbox ist bedenke das in aktueller Fritzbox Firmware keine UDP Encapsulation bei SIP mehr supportet ist und es auch Änderungen an den User und Passworten gegeben hat! (Siehe Fritzbox Tips im Tutorial)