Diagnostica e monitoraggioAvanzato
Metodo troubleshooting passo-passo per WISP
Metodologia strutturata per diagnosticare i problemi più comuni nei WISP MikroTik: assenza di internet, latenza elevata, PPPoE che non sale e apparati irraggiungibili.
Un approccio sistematico riduce il tempo di risoluzione da ore a minuti. Il principio è sempre lo stesso: isola il problema per livelli, dal basso (fisico/link) verso l'alto (routing/applicazione), usando gli strumenti di RouterOS in sequenza logica.
Caso 1 — Cliente senza internet
Checklist diagnostica: cliente senza internet
# STEP 1: verifica che il cliente abbia un IP assegnato /ip/address/print where interface~"pppoe" /ppp/active/print where name~"cliente-mario" # STEP 2: ping verso il gateway del cliente dal router /ping [IP-cliente] count=5 # STEP 3: verifica che il cliente possa raggiungere il gateway # (esegui dal router del cliente o via SSH sul CPE) /ping 10.0.0.1 src-address=[IP-cliente] count=5 # STEP 4: verifica routing — il pacchetto sa dove andare? /ip/route/print where dst-address=0.0.0.0/0 /ip/route/check 8.8.8.8 # STEP 5: verifica NAT — c'è la regola masquerade/srcnat? /ip/firewall/nat/print where chain=srcnat # STEP 6: firewall blocca qualcosa? /ip/firewall/filter/print stats where action=drop # Guarda il contatore bytes — se sale mentre il cliente prova, è il firewall # STEP 7: il problema è oltre il router? /ping 8.8.8.8 count=5 ;# DNS Google /tool/traceroute 8.8.8.8 ;# dove si perde il pacchetto?
Il 70% dei casi 'niente internet' in un WISP ha causa: (1) sessione PPPoE scaduta/non attiva, (2) IP non assegnato, (3) regola NAT mancante o errata, (4) route default mancante. Inizia sempre da questi quattro punti.
Caso 2 — Latenza alta / rete lenta
Diagnosi latenza e throughput degradato
# STEP 1: identifica da dove viene la latenza /tool/traceroute 8.8.8.8 count=3 # Se la latenza alta è al primo hop → problema sul router locale o link CPE # Se è sui hop successivi → problema upstream (ISP/peering) # STEP 2: verifica utilizzo CPU del router /system/resource/print /tool/profile cpu=total # STEP 3: cerca chi satura la banda (torch sul link uplink) /tool/torch interface=ether1-wan # Ordina per volume → identifica IP/protocollo responsabile # STEP 4: verifica errori fisici sull'interfaccia /interface/print stats where name=ether1-wan # Cerca: rx-error, tx-error, rx-drop, tx-drop # STEP 5: verifica queue — c'è congestione nelle code? /queue/simple/print stats /queue/tree/print stats # Se byte-drop > 0 → le code sono sature # STEP 6: test di throughput (in manutenzione) /tool/bandwidth-test address=[IP-router-upstream] direction=both protocol=udp duration=10s user=admin
Caso 3 — PPPoE che non sale
Debug sessione PPPoE
# STEP 1: verifica log per errori PPPoE/RADIUS /log/print where topics~"pppoe" /log/print where topics~"radius" # Cerca: "auth failed", "user not found", "no secret", "timeout" # STEP 2: verifica che il secret esista e sia abilitato /ppp/secret/print where name=[username-cliente] # Controlla: disabled=no, password corretta, service=pppoe # STEP 3: verifica che il profilo PPPoE esista /ppp/profile/print # STEP 4: verifica che l'interfaccia PPPoE server sia attiva /interface/pppoe-server/server/print # Controlla: disabled=no, interface giusta, autenticazione # STEP 5: se usi RADIUS, verifica connettività verso il server /ping [IP-RADIUS-server] count=5 /radius/print /radius/incoming/print # STEP 6: attiva debug temporaneo (attenzione: genera molto log) /system/logging/add topics=pppoe,debug action=memory # Riprova la connessione PPPoE → guarda /log/print # RIMUOVI la regola debug subito dopo! /system/logging/remove [numero-regola-debug]
Caso 4 — Apparato irraggiungibile (AP, CPE, switch)
Diagnostica apparato irraggiungibile
# STEP 1: l'IP è corretto? ARP lo risolve? /ip/arp/print where address=[IP-apparato] # Se ARP non c'è → problema livello 2 (link fisico, VLAN, bridge) # STEP 2: ping dal router verso l'apparato /ping [IP-apparato] count=5 src-address=[IP-interfaccia-corretta] # STEP 3: verifica che il traffico verso quell'IP passi per l'interfaccia giusta /ip/route/check [IP-apparato] # Mostra quale interfaccia e gateway usa # STEP 4: torch sull'interfaccia — i pacchetti partono? /tool/torch interface=[interfaccia-verso-apparato] dst-address=[IP-apparato]/32 # STEP 5: verifica VLAN se la rete è segmentata /interface/vlan/print where vlan-id=[ID-vlan] /interface/bridge/vlan/print # STEP 6: se è un AP Ubiquiti, verifica via UISP o SSH diretto # Controlla segnale radio, link state, errori fisici sul porto PoE # STEP 7: packet sniffer per vedere cosa succede a livello pacchetto /tool/sniffer/quick interface=[interfaccia] ip-address=[IP-apparato]
Per gli apparati Ubiquiti (AP, CPE, PtP) la causa più frequente di irraggiungibilità è: (1) perdita di alimentazione PoE, (2) degrado del segnale radio, (3) cambio IP per DHCP non aggiornato. Controllare sempre prima lo stato fisico (LED, PoE injector, cavo) prima di procedere con la diagnostica software.
- Principio fondamentale: divide et impera — isola il segmento guasto, testa dalla parte più vicina al router verso la periferia
- Tieni sempre un accesso out-of-band (porta seriale, accesso 3G/4G di backup) per non perdere l'accesso al router durante la diagnostica
- Dopo ogni modifica, testa immediatamente e documenta nel log delle modifiche
- Se il problema è intermittente: abilita Netwatch con soglie realistiche e lascia che registri i down automaticamente
- I contatori
/interface/print statssi azzerano al riavvio — annotali prima di riavviare
troubleshootingdiagnosino internetlatenzapppoedownirraggiungibiledebugmetodologiawispguasto
Continua con
Configura senza fatica con l'AI
In WispOS l'agente AI genera la configurazione RouterOS dalle tue parole e un tutor ti guida passo passo.
Prova WispOS