sfondo
Ho un server DHCP di Windows (Server 2008 R2) che distribuisce gli indirizzi per diversi ambiti. Uno di questi ambiti è per alcuni telefoni IP Mitel. I telefoni sono configurati per utilizzare l'opzione dhcp 125 per ottenere informazioni sulla configurazione. Quando un telefono si avvia, non sa quale vlan usare e quindi ottiene solo il vlan predefinito (senza tag) di qualunque porta sia connessa. Il server DHCP fornisce una risposta che include informazioni sull'opzione 125 e il telefono è in grado di leggere quale vlan dovrebbe usare da questa risposta. Il telefono quindi rilascia il suo indirizzo originale e richiede un nuovo contratto dhcp usando il tag vlan corretto. I telefoni di solito hanno anche computer collegati a una porta pass-through. I pacchetti dai computer non vengono mai taggati, quindi i PC rimarranno sul vlan originale (senza tag) per la porta. Questo ha funzionato per noi per anni.
Problema e sintomi
Da qualche parte nelle ultime settimane, qualcosa è cambiato e non sono sicuro di cosa. I telefoni continueranno a funzionare finché non si riavvieranno, il che significa che le richieste di rinnovo DHCP devono essere elaborate correttamente. I telefoni collegati a determinati switch possono persino sopravvivere a un riavvio. I telefoni collegati ad altri switch, tuttavia, non completeranno il processo al riavvio. Tutti i nostri telefoni utilizzano PoE di cui è stato eseguito il backup da un UPS, quindi è passato molto tempo da quando si sono riavviati. Ciò significa che non ho idea di quando sia apparso il problema per la prima volta. Quello che so è che un telefono non è riuscito quando è stato riavviato ieri e nella risoluzione dei problemi oggi abbiamo ripristinato l'armadio di commutazione. Ora nessuno dei telefoni su quell'interruttore funziona (per fortuna è ancora un piccolo numero). So anche che le cose funzionavano verso la fine di gennaio,
Mentre guardo l'avvio di un telefono, riesco a vederlo ottenere correttamente il primo indirizzo. Quindi legge correttamente le informazioni sull'opzione 125, imposta il tag vlan corretto e rilascia il contratto di locazione IP originale. È persino in grado di ricevere e accettare un'offerta sul vlan corretto dal server . Tuttavia, è qui che le cose si fermano. Sul telefono è visualizzato un messaggio " DHCP: Offer 2 ACC", ma il server DHCP di Windows non ha registrato il contratto di locazione e il telefono non si sposta mai. Posso solo supporre che il pacchetto RICHIESTA DHCP non raggiunga mai il server Windows, e quindi il telefono è in attesa dell'ACK finale da Windows che va bene continuare.
Soluzione
Finalmente sono riuscito a riavviare il telefono. Per farlo, ho dovuto prima disconnettere il computer. Quindi ho impostato la porta dello switch del telefono in modo che non sia contrassegnata sul telefono vlan, senza appartenenza al PC vlan. Il telefono ora si riavvierà correttamente. A questo punto, posso riportare la configurazione della porta dello switch dove dovrebbe essere, e finché nessuno prova a chiamare quel numero mentre sto ripristinando la porta, il telefono non perde mai un colpo. Quindi posso ricollegare il computer. Ovviamente, questo non è un processo ideale, anche se dal momento che i telefoni si riavviano così raramente sarò in grado di usarlo per far lavorare di nuovo le persone fino a quando non riesco a trovare la causa principale. Gli uffici sono chiusi ora per la settimana, e quindi questo problema sarà effettivamente consentito di sedere durante il fine settimana (non ho le chiavi per i singoli uffici in cui si trovano i telefoni).
Questo telefono che ho riparato è il telefono di servizio nella sala server, collegato direttamente al nostro switch principale. È possibile che il problema sia un problema con il routing o l'elaborazione dei tag sullo switch principale, in modo tale che la soluzione alternativa non sarà efficace negli uffici remoti in cui i pacchetti vengono prima attraversati (contrassegnati da) altri switch, ma rimarrò molto sorpreso in tal caso, dato che so che è necessario elaborare correttamente i rinnovi dhcp e le conversazioni telefoniche effettive.
Una svolta è che lasciare la porta taggata sul PC vlan significa che il telefono invece fallisce con il messaggio " DHCP: Offer 1 ACC". Devo rimuovere completamente quel vlan perché questo abbia successo.
Nota: ora ho confermato che la soluzione è efficace negli edifici remoti. Questo mi porta a sospettare che i miei dispositivi non siano in qualche modo assegnati al vlan corretto. Il fatto che io abbia riscontrato il problema sul mio switch principale e che si sia verificato in più punti della rete nello stesso momento, indica che il problema potrebbe essere lo switch principale. Con nulla di specifico da guardare, sto pianificando una finestra di manutenzione verso la fine della settimana per riavviare l'interruttore. Potrei anche aggiornare il firmware.
Ambiente
Il nostro interruttore principale è un HP 5406zl. Questo switch gestisce il routing inter-vlan. Il server DHCP di Windows è collegato direttamente allo switch. Gli switch endpoint sono collegati allo switch core tramite SFP in fibra ottica e queste porte sono contrassegnate per tutti i vlan su entrambe le estremità. Il core switch configura ogni vlan con ip helper-addressun'impostazione che lo punta al nostro server DHCP e una dhcp relay-option 82 replacelinea in modo che il server dhcp sappia quale ambito usare. Queste configurazioni e le configurazioni delle porte sugli switch endpoint non sono cambiate in almeno 16 mesi. Abbiamo avuto altri ripristini di switch e telefono in quel momento.
La maggior parte dei nostri interruttori endpoint sono serie HP 2530. Questi interruttori sembrano funzionare correttamente (i telefoni su 3 diversi 2530 si sono riavviati correttamente oggi). Sono gli switch più vecchi che hanno problemi. Abbiamo un vecchio 3Com 4200 e un 4210 che non funzioneranno. Anche il telefono di servizio collegato direttamente allo switch principale menzionato in precedenza non funzionerebbe.
Domanda
A questo punto la mia ipotesi migliore è che un aggiornamento di Windows sul server DHCP ha cambiato il comportamento, ma non riesco a vedere come. O forse il core switch non sta gestendo correttamente quel pacchetto REQUEST, ma sono sicuro che nulla è cambiato lì, e non spiega il motivo per cui vengono effettuati solo determinati switch di endpoint. Come posso risolvere questo problema?
Aggiornare:
Ecco un estratto del registro dhcp da un telefono guasto:
10,03 / 06 / 15,12: 40: 40, Assegna, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 11,03 / 06 / 15,12: 40: 40, Rinnova, 10.1.2.158, , 08000F197844,, 3189088995,0 ,,, 12,03 / 06 / 15,12: 40: 41, Release, 10.1.2.158,, 08000F197844,, 3189088995,0 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,, 15,03 / 06 / 15,12: 40: 45, NACK, 10.1.2.154,, 08000F197844,, 0,6 ,,,
Gli indirizzi 10.xxx sono i PC vlan (quella scelta mi precede in questo luogo). All'inizio i telefoni dovrebbero ottenere quel tipo di indirizzo, quindi è previsto. Tuttavia, dopo il messaggio di rilascio mi aspetto anche di trovare un'offerta per un indirizzo nell'intervallo 192.168.16.x, perché posso vedere al telefono che un'offerta è stata accettata (a meno che non stia fraintendendo "ACC"). È interessante il fatto che non vedo mai il server tentare di emettere un indirizzo del genere, anche se il telefono pensa di averne ricevuto uno.
Ho considerato l'idea che ci sia un server dhcp non valido sulla rete (distribuisce un indirizzo prima del server Windows, ma senza le opzioni dhcp necessarie al telefono per continuare), ma questo non spiega perché i telefoni funzionano se e solo se Rimuovo completamente qualsiasi percorso verso il PC vlan. Lo proverò comunque al mattino collegando il mio laptop a una porta impostata per il telefono vlan, ma se nel frattempo qualcun altro ha una spiegazione migliore, mi piacerebbe ascoltarlo.
Ecco una copia della configurazione dello switch: