Buongiorno a tutti,
volevo sapere se è una condizione standard il completo packetloss sul gateway di TIM.
C'è un modo per risalire all'informazione corretta?
Premetto che mi serve per costruire una dashboard su Grafana.
Altra cosa, posso eliminare il gateway DHCP6? O faccio danni?
Grazie se qualcuno mi può aiutare.
stich86 che non risponda ai ping siamo pacifici, come forse non hai notato sono stato il primo ad averlo ricordato all'op...il senso del mio ultimo intervengo era un altro, riformulo: se il problema dell'op fosse stato aver inserito un host non sensato come target del traceroute/mtr, quindi di fatto un problema almeno ai miei occhi banale, per quale motivo avrebbe chiesto un consiglio...?
Pertanto in questa ottica io avevo supposto che nel suo caso i risultati venissero per qualche motivo sfalsati dal 100% di pl al primo hop ed egli non sapesse come regolarizzarli...se poi come si suol dire mi son fatto un film, meglio così 
walt si ma se il primo hop risponde e poi il resto no che senso ha? Gli è stato detto perché ha PL 100% usando il NAS, se vuole usare quella funzione per switchare linea deve mettere un next-hop esterno alla rete, di solito è prassi comune.. su apparti enterprise ne metti due, il next-hop vicino ed uno fuori rete per velocizzare le cose 
LucaTNT Ottimo! Grazie...
Vi condivido le dashboard 
Ci sono ancora un po' di cose da sistemare... Sono partito da questo repository https://github.com/VictorRobellini/pfSense-Dashboard
Poi vi condivido le modifiche 
stich86 Ma quindi consigliate di mettere il next-hop che risponde ai ping come monitor?
Running mtr -w -c 10 -i 1 1.1.1.1:
Start: 2023-06-07T12:56:43+0200
HOST: firewall.home.arpa Loss% Snt Last Avg Best Wrst StDev
1.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2.|-- 172.18.33.212 0.0% 10 4.8 4.6 4.4 4.8 0.1
3.|-- 172.18.33.228 0.0% 10 4.5 4.8 4.5 5.3 0.2
4.|-- 172.19.184.90 0.0% 10 9.0 9.0 8.9 9.5 0.2
5.|-- 172.19.177.66 0.0% 10 9.7 9.6 9.2 9.9 0.2
6.|-- ae48.milano11.mil.seabone.net 0.0% 10 9.0 9.0 8.8 9.2 0.2
7.|-- ae11.milano58.mil.seabone.net 0.0% 10 10.6 10.3 9.5 12.0 1.0
8.|-- cloudflare.milano58.mil.seabone.net 0.0% 10 10.4 12.1 8.9 20.7 4.5
9.|-- 188.114.100.3 0.0% 10 10.2 10.1 9.8 10.3 0.1
10.|-- one.one.one.one 0.0% 10 9.7 9.6 9.4 9.8 0.1In realtà pingare il NAS di TIM è ancora possibile in questo modo:
Mi sa che pure TIM non ricorda di questa cosa 
Si usava nei vecchi modem con il VoIP su sessione PPP a parte
Attenzione che con questa PPP non si può navigare su Internet, funziona solo per DNS TIM, VoIP e forse anche NTP TIM (ma non mi ricordo gli indirizzi)
La sessione di telegestione è in effetti tutt'ora utilizzata su pregresse tipologie di servizio pertanto confermo che la relativa PPPoE è instaurabile ed è terminata su unit della loopback0 cui sono assegnati IP della classe 207.* ma mi risulta che in generale la risposta al ping sia inibita anche in quel caso e rimanga abilitata soltanto per l'IP "pubblico" in senso stretto, si veda ad esempio il comportamento sul NAS di attestazione della mia linea:
[walter@ros] > ping count=4 207.xxx.xxx.xxx
SEQ HOST SIZE TTL TIME STATUS
0 207.xxx.xxx.xxx timeout
1 207.xxx.xxx.xxx timeout
2 207.xxx.xxx.xxx timeout
3 207.xxx.xxx.xxx timeout
sent=4 received=0 packet-loss=100%
[walter@ros] >> ping count=4 151.xx.xx.xxx
SEQ HOST SIZE TTL TIME STATUS
0 151.xx.xx.xxx 56 255 2ms
1 151.xx.xx.xxx 56 255 1ms
2 151.xx.xx.xxx 56 255 5ms
3 151.xx.xx.xxx 56 255 1ms
sent=4 received=4 packet-loss=0% min-rtt=1ms avg-rtt=2ms max-rtt=5msERRATA CORRIGE: in questo periodo sono distratto da eventi spiacevoli, ovviamente ho scritto una corbelleria in quanto quell'IP è pingabile sì ma ovviamente dalla PPPoE di "telegestione"...rimane un workaround interessante ma a mio avviso scomodo 
Anche io ho messo 1.1.1.1 e va bene da tempo.
jimmi A mio avviso:
Informativa privacy
-
Informativa cookie
-
Termini e condizioni
-
Regolamento
-
Disclaimer
-
🏳️🌈
P.I. IT16712091004 - info@fibraclick.it
♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile