Come interpletare correttamente i risultati del tracert, in particolare il secondo all'ultimo salto prima di un timeout

Sto risolvendo una connessione Internet wireless che continua a scendere. L'isp dice che il segnale radio è buono così deve il mio cisco asa 5505. Io non li credo …

Per la discussione assumere quanto segue:

Il sito remoto del sito pubblico è 10.1.1.50 e il suo gateway predefinito è 10.1.1.1

Quando faccio un tracert da una postazione remota a 10.1.1.50, se il secondo hop ultimo del tracert sia sempre 10.1.1.1?

Quando la connessione è in discesa, il secondo hop non è 10.1.1.1 tuttavia 10.1.1.1 è pingable e posso fare un tracert ad esso.

Penso che questo sia un problema di routing da parte dello isp.
La mia logica è valida? Se 10.1.1.1 è raggiungibile non dovrebbe essere il secondo per passare hop su un tracert prima di get timeouts?

  • Eliminazione dei file di traccia di SQL Profiler (.trc)
  • Traccia di indirizzo IP
  • Che cosa è memorizzato in% Windir% \ System32 \ LogFiles \ WMI \ RtBackup?
  • come fare lo sniffing di I / O
  • Catena di monitoraggio dei server NTP
  • One Solution collect form web for “Come interpletare correttamente i risultati del tracert, in particolare il secondo all'ultimo salto prima di un timeout”

    Nel 99% dei casi, il penultimo salto di un traceroute non sarà il gateway predefinito dell'host di destinazione. Questo è dovuto al modo in cui funziona il traceroute.

    Tutti i pacchetti IP hanno un field "misero -tempo-in-live" ( TTL ). Questo field è diminuito da uno per each router che inoltra un pacchetto. Se un router decrementa il TTL a 0, scompare il pacchetto e genera un pacchetto di errore superato ICMP TTL e lo invia alla persona che ha inviato il pacchetto originale. Il pacchetto di errore avrà un IP di destinazione dell'origine del pacchetto originale (in questo caso, l'host che ha avviato il traceroute). L'IP di origine del pacchetto di errore sarà generalmente l'indirizzo IP dell'interface in output , cioè quello rivolto verso il resto della networking.

    Traceroute sfrutta questo fatto; invia i pacchetti con TTL aumentanti in sequenza; ciò causa a ciascun router nel path tra origine e destinazione di submit i messaggi non raggiungibili ICMP all'host eseguendo il traceroute. Ogni errore avrà un IP di origine del router finale il pacchetto di sonde raggiunto prima di essere abbandonato. Ciò consente a traceroute di build un'image del path tra origine e destinazione.

    Si consideri il seguente diagramma (ignorando la possibilità di routes multipli):

    ________ 1.1____1.2 2.1____2.2 ________ |Host A|-----|Router 1|--- Internet ---|Router 2|-----|Host B| -------- ---------- ---------- -------- 

    Se l'host A sta eseguendo un traceroute per ospitare B, il primo penultimo hop sarà il router 2 che riceverà un pacchetto di sonde come segue:

     SrcIP: A | DstIP: B | TTL: 1 

    Il router 2 diminuirà il TTL a 0; che causerà la generazione di un ICMP TTL scaduto:

     SrcIP: 2.1 | DstIP: A | TTL <default> 

    Di conseguenza, quando il traceroute riceve questo messaggio di errore, l'indirizzo IP che vedrà per il salto penultimo sarà l'interface Internet di fronte del router 2, piuttosto che quella di fronte all'host B.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.