# 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)
1. Da un PC, scarica da https://mikrotik.com/download il **Main package**
   per architettura **ARM** della versione desiderata (file `.npk`).
2. Carica il pacchetto sul router via SCP:
   ```
   scp routeros-7.xx.x-arm.npk admin@<IP-router>:
   ```
3. Verifica che sia arrivato:
   ```
   /file print
   ```
4. Riavvia: RouterOS installa il pacchetto all'avvio.
   ```
   /system reboot
   ```
5. 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:
1. **Aggiorna un router di prova** alla nuova versione (stessa dei futuri
   router di produzione).
2. **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.
3. **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`.
4. **Valida il run-after-reset** sul banco prima di usarlo in produzione.
5. 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