Guida Deploy Template MikroTik — RouterOS 7.x

Procedura per applicare da remoto un template di configurazione base (accesso di management via VLANX + SSH + paracadute MAC) su router MikroTik, in modo pulito e ripetibile.

Principio di fondo: il template applica solo il MINIMO per rientrare. Le VLAN dati e le regole di dettaglio si aggiungono dopo, da remoto, una volta ripreso l'accesso. Il router di prova deve avere la STESSA versione RouterOS dei router di produzione: un collaudo su versione diversa non è valido.

1. Controllo versione e (se serve) aggiornamento

1.1 Verifica la versione attuale

/system resource print

Guarda il campo version (es. 7.21.4) e architecture-name.

Controlla anche il firmware del RouterBoard:

/system routerboard print

Confronta current-firmware con upgrade-firmware: se differiscono, andrà aggiornato (passo 1.5).

1.2 Decidi la versione target

Il template va testato e applicato sulla stessa major/minor version dei router di produzione. Se la produzione è su una versione precisa (es. 7.21.4), allinea tutti i router a quella, non "all'ultima disponibile".

1.3 Aggiornamento ONLINE (se il router naviga)

Richiede connettività Internet e DNS funzionante sul router. Verifica prima:

/ping 8.8.8.8
/ping download.mikrotik.com

Se il primo va ma il secondo no, manca il DNS:

/ip dns set servers=9.9.9.9,149.112.112.112

Poi aggiorna:

/system package update set channel=stable
/system package update check-for-updates
/system package update download
/system package update install

Il comando install riavvia il router e applica la nuova versione.

Per massima stabilità si può usare channel=long-term invece di stable.

1.4 Aggiornamento OFFLINE (metodo consigliato: non dipende da Internet)

Da un PC, scarica da https://mikrotik.com/download il Main package per architettura ARM della versione desiderata (file .npk).

Carica il pacchetto sul router via SCP:

scp routeros-7.xx.x-arm.npk admin@<IP-router>:

Verifica che sia arrivato:
```
/file print
```
Riavvia: RouterOS installa il pacchetto all'avvio.
```
/system reboot
```
A riavvio completato, verifica la nuova versione:
```
/system resource print
```

1.5 Aggiorna il firmware del RouterBoard (dopo l'update di RouterOS)

/system routerboard print

Se current-firmware != upgrade-firmware:

/system routerboard upgrade
/system reboot

1.6 Backup prima di operare (sempre consigliato)

/system backup save name=pre-update
/export file=config-pre-update

2. Upload del template ed esecuzione

2.2 Carica il template via SCP

Dal tuo PC:

scp template-base-mgmt.rsc admin@<IP-router>:

Se RouterOS 7.x rifiuta la connessione per mismatch di algoritmi SSH, abilita lo strong crypto sul router e riprova:

/ip ssh set strong-crypto=yes

2.3 Verifica che il file sia arrivato col nome ESATTO

Collegati via SSH al router e:

/file print

Deve comparire template-base-mgmt.rsc. Il nome deve combaciare esattamente con quello usato nel comando del passo 2.4: se non combacia, il reset azzera il router ma NON esegue lo script.

2.4 Esegui il template con reset-con-script

/system reset-configuration no-defaults=yes skip-backup=yes run-after-reset=template-base-mgmt.rsc

Il router si azzera, applica il template e si riavvia.

2.5 Riconnetti

Dopo ~1–2 minuti, riprova l'accesso all'IP di management:

ssh admin@<IP-management-sede>

Se risponde, il deploy è riuscito. Da qui completi il resto della configurazione da remoto (VLAN dati, firewall, ecc.).

Paracadute

Il template abilita MAC-Winbox su tutte le interfacce: se la VLAN/trunk non passa, chiunque sul posto con un cavo e Winbox può entrare via MAC. Il run-after-reset non ha rollback: una volta azzerato, o il template funziona o serve un intervento fisico. Per questo il collaudo in laboratorio sulla stessa versione deve essere sempre verificato al 100%.

3. Il template: spiegazione e manutenzione

3.1 Perché NON usare le variabili globali nel template

Una versione precedente usava :global e $MGMTIP in cima al file. In un file .rsc importato, l'espansione delle variabili è fragile e cambia tra versioni di RouterOS: produce errori di parsing tipo expected end of command o expected interface value. La versione con valori diretti è robusta e portabile tra versioni. Regola: nei file di configurazione da importare, usa valori diretti, non variabili.

3.2 Mantenere il template per versioni future di RouterOS

La sintassi di alcuni comandi (soprattutto bridge VLAN filtering, routing) cambia tra major version (es. v6 → v7). Per ogni nuova versione RouterOS che adotterai:

Aggiorna un router di prova alla nuova versione (stessa dei futuri router di produzione).
Reimporta il template a mano e verifica che non dia errori:
```
/import file-name=template-base-mgmt.rsc
```
Se una riga fallisce, l'import indica riga e colonna: correggi la sintassi.
Rigenera il template dal router aggiornato partendo da una config buona:
```
/export file=nuovo-template
```
e ripulisci l'export tenendo solo le righe essenziali (bridge, VLAN mgmt, IP, route, DNS, mac-server), reinserendo i marcatori ### MODIFICA.
Valida il run-after-reset sul banco prima di usarlo in produzione.
Tieni un template per major version se gestisci un parco misto (es. template-v6.rsc, template-v7.rsc), perché la stessa sintassi non è garantita compatibile.

3.3 Checklist di collaudo prima di ogni uso in produzione

Router di prova sulla STESSA versione dei router di produzione
Import manuale del template SENZA errori
Raggiungibilità via SSH ATTRAVERSO IL TRUNK (switch a monte come in sede, VLANX taggata, native allineata)
run-after-reset riporta il router su in modo affidabile e ripetibile
MAC-Winbox raggiungibile come paracadute