Da vWLC a Catalyst 9800-CL: come si migrano 150 access point senza fermare la rete

Passare da un Cisco Virtual Wireless Controller a un Catalyst 9800 non è un aggiornamento. È la costruzione di un impianto nuovo accanto a quello esistente, con gli access point che attraversano dall’uno all’altro mentre la rete continua a lavorare. Cambia il sistema operativo, cambia il modello di configurazione, e cambia il modo in cui un access point trova il proprio controller: quest’ultimo punto è quello che decide se la migrazione si può fare a caldo oppure no.

Questo è il racconto di una migrazione in corso su un impianto reale: due controller virtuali nella sede centrale, 150 access point complessivi, quindici filiali collegate in VPN con access point in FlexConnect appoggiati alla controller di sede, rete cablata Cisco, e client di ogni tipo, dai telefoni VoIP ai palmari, dai PC agli smartphone fino agli AMR di magazzino. Ottantaquattro access point già passati, di cui 43 in una sola filiale remota.

Nessuna finestra di fermo. La rete non si è mai fermata, perché gli access point sono stati migrati uno alla volta, a caldo, mentre gli altri continuavano a lavorare sulla controller vecchia.

AireOS e IOS-XE non sono la stessa cosa con un’interfaccia diversa

La configurazione non si trasferisce, si riprogetta. In AireOS gli access point si organizzano in gruppi AP, con i profili RF associati. Su IOS-XE il modello è a tag e profili, e non c’è una corrispondenza uno a uno.

Concetto	AireOS (vWLC)	IOS-XE (Catalyst 9800)
Raggruppamento degli access point	gruppo AP	combinazione di policy tag, site tag e RF tag
Quali SSID trasmette un access point	WLAN associate al gruppo AP	policy tag, che lega profilo WLAN e policy profile
Appartenenza a un sito e commutazione locale	gruppo FlexConnect	site tag, con flex profile associato
Parametri radio	profilo RF sul gruppo AP	RF tag
Interfacce dei client	dynamic interface sul controller	nessuna SVI client sul controller, la VLAN si dichiara nel policy profile

Il punto di partenza di questo impianto era vWLC su AireOS 8.10.196.0, che è la build raccomandata da Cisco per quella piattaforma: si migrava da un sistema tenuto in ordine, non da uno abbandonato, e questo semplifica parecchio le cose perché il comportamento di partenza è quello documentato.

Perché la configurazione è stata rifatta a mano

Cisco mette a disposizione un traduttore di configurazione da AireOS a 9800, sia dentro l’interfaccia del controller sia come strumento online. Funziona, e su impianti semplici fa risparmiare tempo.

Su questa rete la scelta è stata un’altra: ricostruire tutto da zero. Il motivo è che il risultato del traduttore va comunque riletto riga per riga, e con quindici siti FlexConnect il tempo di revisione supera quello di ricostruzione. Le chiavi degli SSID non passano, le WLAN associate ai gruppi AP non si allineano automaticamente, e il risultato tende a generare tanti profili quanti erano i gruppi AP di partenza, che è esattamente il contrario di quello che serve quando si vuole approfittare della migrazione per semplificare.

C’è poi una ragione meno tecnica e più onesta: se ricostruisci la configurazione, la conosci. Se la traduci, no. E il giorno in cui qualcosa non funziona la differenza si sente tutta.

Cosa è stato riconfigurato prima di toccare il primo access point: tutte le WLAN e i relativi SSID, i quindici siti remoti in FlexConnect, le VLAN, le policy, i profili RF, i tag, e il RADIUS per l’autenticazione contro Active Directory.

Scegliere la versione IOS-XE: la questione degli access point Wave 1

Il 9800-CL è stato installato con IOS-XE 17.12.7a. La versione di un controller wireless non si sceglie prendendo la più recente, ma verificando prima che cosa dovrà accogliere: è l’inventario del parco access point a stabilire quale treno software si può usare.

Il caso che si incontra più spesso su reti stratificate negli anni riguarda gli access point Wave 1, cioè le serie Aironet 1570, 1700, 2700 e 3700, che con i treni IOS-XE hanno una compatibilità a intermittenza poco intuitiva.

Le serie Aironet 1570, 1700, 2700 e 3700 non sono supportate dalla 17.4 alla 17.9.2, né sui treni 17.10, 17.11, 17.13, 17.14 e 17.15. Il supporto è stato reintrodotto con la 17.9.3 e mantenuto sul treno 17.12. Dalla 17.16 in avanti gli access point basati su IOS non si uniscono più al controller. Per chi resta sul treno 17.12 Cisco raccomanda la 17.12.7a; nell’agosto 2026 ha pubblicato anche la 17.12.8 con l’hardening di sicurezza.

Il consiglio: trattare 17.12 come un ponte, non come destinazione

Il nostro consiglio è di trattare quella release come un ponte e non come una destinazione. Gli access point Wave 1 sono apparati fuori supporto, e la scelta pulita è sostituirli con modelli attuali: finché restano in rete vincolano la versione del controller e impediscono di accedere alle funzioni introdotte dopo, mentre una volta usciti dal parco il vincolo cade e il controller può salire di treno senza lasciare indietro nessuno.

Il principio generale, valido oltre il caso Wave 1, è che l’inventario degli access point viene prima della scelta della versione. Su una rete cresciuta per stratificazioni, l’apparato più vecchio decide per tutti, e conviene saperlo prima di installare il controller invece che dopo.

Il conflitto del DNS, e la soluzione a due mosse

Un access point che cerca il proprio controller usa più metodi, e uno di questi è la risoluzione del nome CISCO-CAPWAP-CONTROLLER.localdomain (gli apparati più vecchi cercano anche CISCO-LWAPP-CONTROLLER). In questo impianto quel nome risolveva, correttamente, l’indirizzo della controller vecchia: doveva farlo, perché sessantasei access point ci lavorano ancora sopra.

Il problema è evidente: ogni access point che accendi torna dove non lo vuoi.

Cambiare il record DNS non era un’opzione, perché avrebbe rotto la parte di rete ancora in produzione. La soluzione adottata lavora sulla VLAN nuova, ed è fatta di due mosse complementari.

Mossa	Cosa fa	Perché serve
Traffico verso la controller vecchia negato sulla VLAN nuova	chiude la strada vecchia	anche se l’access point risolve il vecchio nome, non riesce ad arrivarci
Option 43 nel DHCP della VLAN nuova, che punta al 9800-CL	apre la strada nuova	l’access point riceve l’indirizzo del controller corretto insieme al proprio IP

Perché serve sia il blocco sia la option 43

Una sola delle due non basta. Con la sola option 43 l’access point potrebbe comunque agganciarsi al vecchio controller attraverso il DNS, perché i metodi di scoperta convivono. Con il solo blocco resterebbe senza controller a cui presentarsi. Insieme, l’esito è deterministico: sulla VLAN vecchia si va alla controller vecchia, sulla VLAN nuova alla nuova, e nessuno dei due gruppi disturba l’altro.

Il DNS resta intatto e continua a servire gli access point non ancora migrati. Quando l’ultimo sarà passato si aggiornerà il record e si potranno rimuovere le regole di blocco.

Quando i due gruppi di access point si sentono fra loro

In questo impianto le due controller servono siti diversi e gli access point delle due non condividono lo spazio radio, quindi il problema non si pone.

Vale però la pena sapere che si pone eccome in una migrazione dove i due insiemi coprono lo stesso edificio. Due controller con nome del RF group diverso danno luogo a due domini radio separati, con due conseguenze: gli access point dell’una vedono quelli dell’altra come rogue, e l’RRM, che lavora per gruppo RF, assegna canali e potenze ignorando la metà di rete che non conosce. Il risultato è interferenza fra apparati della stessa azienda, che è il tipo di problema più fastidioso da diagnosticare perché nessuno lo sta cercando.

Se durante la migrazione i due gruppi condividono lo spazio radio, il nome del RF group va allineato prima di spostare il primo access point. È una verifica da mettere in cima alla lista, non da scoprire a metà lavoro.

Il proof of concept si fa sui client, non sull’access point

Prima di toccare la produzione, un access point di test in un ufficio isolato del CED. La verifica non è che l’access point si registri, che è la parte facile: la verifica è che i client funzionino.

Telefoni VoIP, palmari, PC, smartphone e AMR di magazzino, ciascuno con il proprio comportamento di autenticazione e di roaming. È il momento in cui si scopre se il RADIUS verso Active Directory risponde come deve, se le policy assegnano la VLAN corretta e se i dispositivi più datati digeriscono la configurazione nuova. I requisiti dei due client più esigenti sono nelle guide ai telefoni Wi-Fi di reparto e al Wi-Fi per magazzini con AMR.

Su una rete che serve anche robot mobili, un errore a questo stadio non è un disservizio di navigazione: è una linea che si ferma.

La migrazione a caldo, un access point alla volta

Nessun big bang. Ogni apparato segue la stessa sequenza, e finché non è completa non si passa al successivo.

Passo	Operazione	Cosa si verifica prima di procedere
1	clear all config sull’access point	l’apparato riparte senza residui della configurazione precedente
2	cambio della VLAN sulla porta	l’access point si trova sulla rete che punta al nuovo controller
3	verifica dell’indirizzo assegnato dal DHCP	l’IP arriva dalla VLAN nuova, con la option 43 corretta
4	verifica del join dai log del 9800-CL	l’access point si presenta al controller giusto
5	verifica del download del firmware	l’immagine si scarica e si installa completamente
6	assegnazione di tag, policy e nome corretto	l’access point entra in servizio con la configurazione definitiva

Il passo 6 va per ultimo di proposito. Prima l’apparato deve essere sano e registrato, poi riceve la sua identità. Assegnare i tag a un access point che sta ancora scaricando l’immagine significa non sapere, se qualcosa non torna, se il problema sia il join o la policy.

Una nota sul passo 5 nelle filiali remote: il download del firmware passa dalla VPN, quindi è la fase più lenta dell’intera sequenza ed è la ragione per cui una filiale da 43 access point non si migra in un pomeriggio. Va pianificata come attività distribuita, non come intervento a finestra.

Il survey a valle, con Ekahau

A migrazione dei siti completata, verifica della copertura reale sul campo con Ekahau Sidekick 2: un site survey Wi-Fi di validazione. Non è un adempimento formale: cambiando controller cambia anche chi governa potenze e canali, e la misura serve a confermare che quello che il controller dichiara corrisponda a quello che i dispositivi ricevono davvero.

L’esito ha confermato la copertura. Le migliorie individuate riguardano più il cambio dei terminali che l’infrastruttura: dispositivi diversi hanno sensibilità e comportamenti di roaming diversi, e una copertura adeguata ieri può diventare marginale quando cambia il parco client. È il motivo per cui il survey andrebbe rifatto quando cambiano i terminali, e non soltanto quando cambiano gli access point.

Cosa resta e come si convive nel frattempo

Sessantasei access point sono ancora sulla controller vecchia, e non è un’emergenza: è uno stato stabile che può durare quanto serve, perché le due reti sono separate per VLAN e per instradamento e non si disturbano a vicenda.

Quello che conta è che la convivenza sia governata e non subita: due VLAN separate, regole di instradamento esplicite e una sequenza di migrazione sempre uguale rendono la coesistenza una fase del progetto, con un ordine deciso in anticipo e un punto di arrivo definito. È lo stesso metodo della migrazione del centralino FreePBX 17: l’impianto nuovo accanto a quello vecchio, e il passaggio un pezzo alla volta.

Il caso è seguito da Netframe, system integrator IT con sede a Modena e partner certificato Cisco, che progetta e migra reti Wi-Fi Cisco per aziende con più sedi in tutta l’Emilia-Romagna.

Domande frequenti

Si può migrare da vWLC a Catalyst 9800 senza fermare la rete wireless?

Sì, spostando un access point alla volta mentre tutti gli altri continuano a lavorare sulla controller precedente. Servono due VLAN separate e un modo deterministico per indirizzare ogni access point verso il controller giusto, altrimenti gli apparati tornano da soli su quello vecchio.

Perché gli access point continuano ad agganciarsi al vecchio controller?

Quasi sempre per il record DNS CISCO-CAPWAP-CONTROLLER (o CISCO-LWAPP-CONTROLLER sugli apparati più vecchi), che punta ancora al vecchio indirizzo. Se quel record serve ancora agli apparati non migrati non va cambiato: si blocca il traffico verso il vecchio controller sulla VLAN nuova e si usa la option 43 del DHCP per indicare quello nuovo.

Il traduttore di configurazione da AireOS a 9800 è affidabile?

Fa risparmiare tempo su impianti semplici, ma il risultato va riletto interamente prima di applicarlo. Su reti con molti siti FlexConnect ricostruire la configurazione è spesso più rapido, e ha il vantaggio che alla fine la si conosce nel dettaglio.

Quale versione IOS-XE scegliere se ho ancora access point vecchi?

Non la più recente, ma quella compatibile con gli apparati più datati del parco: la versione va scelta dopo l’inventario degli access point, mai prima. Le serie Aironet Wave 1 sono supportate solo su alcuni treni e dalla 17.16 in avanti non si uniscono più al controller, quindi il treno 17.12 può servire come passaggio temporaneo. Il consiglio, però, è di sostituire quegli apparati: sono fuori supporto e finché restano in rete vincolano la versione di tutto il resto.

Quanto dura la migrazione di 150 access point?

Non è un intervento a finestra ma un’attività distribuita nel tempo. Il vincolo non è il controller, che regge senza problemi, ma il download del firmware su ogni apparato, che nelle sedi remote passa dalla VPN ed è la fase più lenta.

Chi segue una migrazione da vWLC a Catalyst 9800 in Emilia-Romagna?

Netframe, system integrator IT con sede a Modena e partner certificato Cisco, progetta e migra reti Wi-Fi Cisco per aziende con più sedi: ricostruzione della configurazione a tag e profili, siti FlexConnect, scelta della versione IOS-XE sull’inventario degli access point, migrazione a caldo un apparato alla volta e survey di validazione con Ekahau Sidekick 2. Interventi in tutta l’Emilia-Romagna.

Fonti

• Cisco, Recommended AireOS Wireless LAN Controller Releases: build raccomandate per le piattaforme AireOS, compresa la 8.10.196.0 usata come punto di partenza
• Cisco, Release Notes Catalyst 9800 IOS XE Dublin 17.12.x: treni in cui gli access point Wave 1 non sono supportati e reintroduzione del supporto dalla 17.9.3
• Cisco, Wireless Solutions Software Compatibility Matrix: compatibilità fra access point, controller e versioni software
• Cisco, Recommended Cisco IOS XE Releases for Catalyst 9800 Wireless LAN Controllers: versioni raccomandate per treno (17.12.7a per chi resta sul 17.12, 17.12.8 dell’agosto 2026 con l’hardening di sicurezza), modelli di access point supportati, fine dell’unione degli access point basati su IOS dalla 17.16, coesistenza fra controller AireOS e 9800

Fonti verificate il 10 settembre 2026.

Nota di indipendenza: Netframe è un system integrator indipendente e multi-vendor. È partner certificato Fortinet, Cisco, Huawei, AudioCodes, Patton, 3CX e Ascom. Ekahau è lo strumento di misura di proprietà con cui eseguiamo i survey, non una partnership.