51129
22.07.2007, aktualisiert am 29.07.2007
6416
5
0
CISCO 7912 - 7940 IP-Adresse zurücksetzen
Hinweis auf TFTP-Dienst fehlte im DHCP-Server (Organisation)
Ich habe im Netzwerk einen zweiten DHCP-Server installiert; 2 Standorte sind über eine 2Mbit-Festverbindung verbunden und haben 2 getrennte IP-Bereiche in einem 16er SUBNETZ. Der DHCP läuft fehlerfrei und vergibt auch den angeschlossenen Rechnern IP-Adressen. 4 ebenfalls angeschlossene IP-Telefone 7912 bzw. 7940 erhalten keine neue IP (IP deshalb doppelt vergeben). Dadurch werden diese Geräte nicht im Netz (CCM) angemeldet und können keine Telefongespräche führen bzw. empfangen. Ich habe bereits im CCM v3.3 ein RESET auf den entspreichenden Telefonen versucht --> ohne Erfolg.
Was kann ich noch machen, ohne die Telefone im CCM zu löschen und neu zu initialisieren.
Danke
Ich habe im Netzwerk einen zweiten DHCP-Server installiert; 2 Standorte sind über eine 2Mbit-Festverbindung verbunden und haben 2 getrennte IP-Bereiche in einem 16er SUBNETZ. Der DHCP läuft fehlerfrei und vergibt auch den angeschlossenen Rechnern IP-Adressen. 4 ebenfalls angeschlossene IP-Telefone 7912 bzw. 7940 erhalten keine neue IP (IP deshalb doppelt vergeben). Dadurch werden diese Geräte nicht im Netz (CCM) angemeldet und können keine Telefongespräche führen bzw. empfangen. Ich habe bereits im CCM v3.3 ein RESET auf den entspreichenden Telefonen versucht --> ohne Erfolg.
Was kann ich noch machen, ohne die Telefone im CCM zu löschen und neu zu initialisieren.
Danke
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: 64407
Url: https://administrator.de/forum/cisco-7912-7940-ip-adresse-zuruecksetzen-64407.html
Ausgedruckt am: 29.04.2025 um 05:04 Uhr
5 Kommentare
Neuester Kommentar
2 DHCP Server ist in der regel problematisch funktioniert aber wenn man die grundlegende Tatsache beachtet, das die Ranges die die DHCP Server vergeben sich keinesfalls ueberschneiden sollten !!!
Das musst du also in jedem Falle sicherstellen.
Abgesehen davon sollte man in einem sauberen VoIP Design die Telefonie mit einem separaten VLAN unbedingt vom Produktivtraffic trennen. Aus Sicherheits- und Stabilitaetsgruenden ist das eins der grundlegenden Maxime fuer ein sauberes VoIP Netzdesign.
Im Internet kursieren zuhauf Capture Tools um Voice Calls als Packet Datei einfach zu capturen und danach die Kommunikation via .wav oder .mpg Datei wieder hoerbar zu machen. Sehr einfach zu realisieren wenn man Voice- und Datentraffic nicht trennt wie du es scheinbar machst
. Bei solch einer sinnvollen Trennung haben die Telefone einen eigenen DHCP Server im CCM der unabhaengig vom Datennetz ist.
Das musst du also in jedem Falle sicherstellen.
Abgesehen davon sollte man in einem sauberen VoIP Design die Telefonie mit einem separaten VLAN unbedingt vom Produktivtraffic trennen. Aus Sicherheits- und Stabilitaetsgruenden ist das eins der grundlegenden Maxime fuer ein sauberes VoIP Netzdesign.
Im Internet kursieren zuhauf Capture Tools um Voice Calls als Packet Datei einfach zu capturen und danach die Kommunikation via .wav oder .mpg Datei wieder hoerbar zu machen. Sehr einfach zu realisieren wenn man Voice- und Datentraffic nicht trennt wie du es scheinbar machst
. Bei solch einer sinnvollen Trennung haben die Telefone einen eigenen DHCP Server im CCM der unabhaengig vom Datennetz ist.
Hallo und Vielen Dank für die Antwort.
Die Ranges sind sauber getrennt; auch ist die Bezeichnung Aussenstelle im CCM besonders bezeichnet. Mir ist bekannt, dass die Trennung in unterschiedliche VLAN für Voice und Daten notwendig ist; dies war aber bisher nicht möglich, weil die eingesetzten Switche dies nicht zuließen.
Dies wird jedoch im Rahmen eines SoftwareUpgrades des CCM auf Version 4.x i.d.n.T. eingerichtet.
Wie bereits beschrieben, trat mein Problem nach dem Einrichten des 2. DHCP-Servers auf. Dies war nicht so, das hier Voice und Daten - IP's doppelt vergeben wurden. Es war vielmehr so, das einige Telefone ihre alte IP beibehielten und dadurch ein Konflikt mit der neu vergebenen IP an einem anderen VoiceGerät entstand.
Mir ging es jetzt in erster Linie darum, zu erfahren, ob ich die Geräte im CCM löschen muss oder dies durch einen anderen "Handgriff" gemacht werden kann.
Die Ranges sind sauber getrennt; auch ist die Bezeichnung Aussenstelle im CCM besonders bezeichnet. Mir ist bekannt, dass die Trennung in unterschiedliche VLAN für Voice und Daten notwendig ist; dies war aber bisher nicht möglich, weil die eingesetzten Switche dies nicht zuließen.
Dies wird jedoch im Rahmen eines SoftwareUpgrades des CCM auf Version 4.x i.d.n.T. eingerichtet.
Wie bereits beschrieben, trat mein Problem nach dem Einrichten des 2. DHCP-Servers auf. Dies war nicht so, das hier Voice und Daten - IP's doppelt vergeben wurden. Es war vielmehr so, das einige Telefone ihre alte IP beibehielten und dadurch ein Konflikt mit der neu vergebenen IP an einem anderen VoiceGerät entstand.
Mir ging es jetzt in erster Linie darum, zu erfahren, ob ich die Geräte im CCM löschen muss oder dies durch einen anderen "Handgriff" gemacht werden kann.
Oha, im Voice Bereich hast du dich zum Cisco Knecht machen lassen aber im LAN dann keine VLAN fähigen Billigswitches verwendet...passt irgendwie nicht wirklich zusammen aber du wirst ja sicher Gründe dafür haben....
Normalerweise reicht es die Telefone zu kaltstarten, dadurch requesten sie eine neue IP, Konfig und Voice Gateway wenn man die Lease Database vorher löscht. Das sollte es eigentlich gewesen sein....
Normalerweise reicht es die Telefone zu kaltstarten, dadurch requesten sie eine neue IP, Konfig und Voice Gateway wenn man die Lease Database vorher löscht. Das sollte es eigentlich gewesen sein....
Hallo!
Inzwischen habe ich meine Telefone wieder alle am laufen. Es lag letztendlich daran, dass der entsprechende Verweis auf den TFTP-Dienst in der Organisation des DHCP-Servers fehlte. Unter Win2K konnte dieser bei Nr. 150 angegeben werden; bei dem neu eingerichteten Windows 2003 Server ist dies unter Nr. 66 zu machen.
Inzwischen habe ich meine Telefone wieder alle am laufen. Es lag letztendlich daran, dass der entsprechende Verweis auf den TFTP-Dienst in der Organisation des DHCP-Servers fehlte. Unter Win2K konnte dieser bei Nr. 150 angegeben werden; bei dem neu eingerichteten Windows 2003 Server ist dies unter Nr. 66 zu machen.
