Diagnostica e monitoraggioIntermedio

Ping, traceroute avanzati e MTU/MSS discovery

Sfruttare a fondo ping e traceroute di RouterOS e diagnosticare i problemi di MTU/MSS, causa frequente di 'siti che non si aprono' su PPPoE e tunnel nei WISP.

Ping e traceroute sembrano banali, ma in RouterOS hanno opzioni che li rendono strumenti diagnostici precisi: sorgente, routing-table, dimensione pacchetto, do-not-fragment, intervallo. Soprattutto, sono la chiave per diagnosticare i problemi di MTU, un classico dei WISP con PPPoE e tunnel.

Ping avanzato: oltre il semplice 'risponde / non risponde'

Ping diagnostico completo

# Verifica raggiungibilità + latenza media/jitter (count alto)
/ping 8.8.8.8 count=20

# Testa il percorso DI UN CLIENTE specifico (giusta sorgente/route)
/ping 8.8.8.8 src-address=10.50.7.33 count=10

# Forza una specifica tabella di routing (VRF / policy routing)
/ping 8.8.8.8 routing-table=clienti count=5

# Ping continuo per 'lasciare aperto' durante un intervento fisico
/ping 10.30.0.1 interval=200ms
#  (vedi quando il link cade/torna mentre muovi un'antenna)

# Misura il jitter su un radio link (intervallo fitto)
/ping 10.30.0.1 count=100 interval=20ms

Traceroute: dove si perde il pacchetto

Traceroute per isolare l'hop problematico

# Traceroute base: la latenza salta a un hop = lì c'è il problema
/tool/traceroute 8.8.8.8

# Dal punto di vista del cliente (sua sorgente)
/tool/traceroute 8.8.8.8 src-address=10.50.7.33

# Più tentativi per hop su link instabili
/tool/traceroute 8.8.8.8 count=3 timeout=2s

# Su una routing-table specifica (multi-WAN / policy routing)
/tool/traceroute 8.8.8.8 routing-table=wan2

Interpretare il traceroute: latenza alta SOLO sull'hop che risponde, poi torna bassa = quell'hop deprioritizza l'ICMP verso sé stesso, NON è un guasto. Il problema vero è quando la latenza alta (o il loss) parte da un hop e RESTA su tutti i successivi. Il primo hop con loss persistente è il sospettato.

Il problema MTU/MSS: perché 'alcuni siti non si aprono'

Su PPPoE l'header aggiuntivo riduce la MTU utile a 1492 byte (1500 - 8 di PPPoE). Sui tunnel (EoIP, GRE, IPIP, WireGuard, IPsec) la MTU scende ancora. Se un pacchetto grande con il flag Don't Fragment incontra un link con MTU minore e l'ICMP 'fragmentation needed' viene bloccato da qualche firewall lungo il percorso (Path MTU Discovery rotta), il pacchetto sparisce nel nulla: il sintomo classico è il sito carica a metà o si blocca, mentre ping e siti piccoli funzionano.

Trovare la MTU reale del percorso col ping

MTU discovery manuale con ping + do-not-fragment

# size = payload ICMP. MTU = size + 28 (20 IP header + 8 ICMP header)
# Parti da 1472 (=1500 MTU). Se passa, la MTU del path è >= 1500.

/ping 8.8.8.8 size=1472 do-not-fragment=yes count=3
#  "packet too large" / nessuna risposta -> il path NON regge 1500

/ping 8.8.8.8 size=1464 do-not-fragment=yes count=3   ;# prova 1492 (PPPoE)
/ping 8.8.8.8 size=1400 do-not-fragment=yes count=3   ;# prova 1428

# Dimezza/aggiusta finché trovi la size massima che passa.
# MTU del path = (ultima size che passa) + 28

Soluzione: MSS clamping (la cura standard nei WISP)

La cura definitiva è il MSS clamping: il router riscrive la MSS nei pacchetti TCP SYN in modo che i due capi non negozino segmenti più grandi di quanto il path regge. Si applica con una regola mangle in forward su PPPoE/tunnel. È la riga che risolve il 90% dei 'siti che si aprono a metà' sui clienti PPPoE.

MSS clamping per PPPoE e tunnel

# Auto: imposta la MSS al valore corretto per il path MTU (consigliato)
/ip/firewall/mangle/add chain=forward protocol=tcp tcp-flags=syn \
  action=change-mss new-mss=clamp-to-pmtu \
  comment="MSS clamp automatico (PPPoE/tunnel)"

# Manuale: forza MSS=1452 sui pacchetti che escono da pppoe-out1
# (1492 MTU PPPoE - 40 di header TCP/IP = 1452)
/ip/firewall/mangle/add chain=forward protocol=tcp tcp-flags=syn \
  out-interface=pppoe-out1 tcp-mss=!0-1452 \
  action=change-mss new-mss=1452 \
  comment="MSS clamp PPPoE 1452"

# Verifica la MTU effettiva delle interfacce
/interface/print where name~"pppoe"   ;# guarda colonna MTU/L2MTU

Sintomo tipico MTU: ping ok, siti piccoli ok, ma alcuni siti/HTTPS si bloccano a metà caricamento
PPPoE → MTU utile 1492, MSS 1452; con tunnel sopra, scendi di conseguenza
Non bloccare gli ICMP type 3 code 4 ('fragmentation needed') nel firewall: servono alla PMTUD
new-mss=clamp-to-pmtu è la scelta più robusta perché si adatta al path reale
Verifica sempre la MTU/L2MTU delle interfacce coinvolte con /interface/print

pingtraceroutemtumsspath mtu discoverydo-not-fragmentpmtudframmentazionepppoe mtumss clampingtunnel mtusiti che non si aprono

Continua con

Logging e syslog remoto SNMP sicuro con SNMPv3 Netwatch: monitoraggio host e automazione Strumenti diagnostici: ping, traceroute, torch e packet sniffer

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