traceroute: uneori routerele nu răspund și utilizatorul vede expirări

Sunt administrator al unei rețele mici și investighez o problemă de care se plâng utilizatorii mei. Rădăcina plângerilor lor este traceroute: uneori, routerele de-a lungul căii pur și simplu nu răspund la traceroute sondele și utilizatorii văd timeout-uri (cele *s în locul RTT).

Rețeaua constă din câteva routere Linux conectate prin Ethernet/wireless. Routere Linux 99% inactiv, utilizare a legăturii 20 Mbit/s, 2000 pachete/s. Wireless este solid. PING pentru toate routerele de-a lungul căii este de 10 ms, cu unele variații, desigur. Flood PING către oricare dintre acele gazde rulează minute în șir fără nicio pierdere de pachete (și mă refer la 0 pachete pierdute). Descărcarea unor fișiere uriașe prin rețea: 10,2 MB/s în medie.

Exemplul corect traceroute arata asa:

# traceroute -nI 10.0.0.2
traceroute la 10.0.0.2 (10.0.0.2), maxim 30 de hopuri, pachete de 60 de octeți
 1 192.168.0.1 3.919 ms 3.866 ms 4.117 ms
 2 10.41.13.1 4.149 ms 6.714 ms 6.707 ms
 3 10.41.1.11 8.475 ms 8.468 ms 8.705 ms
 4 10.0.0.2 8.697 ms 9.428 ms 9.707 ms

The problematic traceroutearata asa:

# traceroute -nI 10.0.0.2
traceroute la 10.0.0.2 (10.0.0.2), maxim 30 de hopuri, pachete de 60 de octeți
 1 192.168.0.1 3.190 ms 3.140 ms 3.128 ms
 2 10.41.13.1 3.119 ms 3.113 ms *
 3 10.41.1.11 3.697 ms * 3.683 ms
 4 10.0.0.2 4.531 ms 4.524 ms 5.171 ms
# traceroute -nI 10.0.0.2
traceroute la 10.0.0.2 (10.0.0.2), maxim 30 de hopuri, pachete de 60 de octeți
 1 192.168.0.1 3.471 ms 3.405 ms 3.388 ms
 2 10.41.13.1 3.372 ms 3.359 ms 3.350 ms
 3 10.41.1.11 5.039 ms * *
 4 10.0.0.2 5.105 ms 5.484 ms 5.473 ms

Am investigat puțin cu tcpdump și a aflat că traceroute functioneaza astfel:

1. La început trimite o grămadă de solicitări ICMP cu TTL de 1, 2, 3, 4, 5, 6. Fiecare TTL este trimis de 3 ori. Adică 18 pachete :)
2. Asteapta ceva timp pentru toate raspunsurile (Timp depășit).
3. Când revin toate răspunsurile, afișați rezultatele.
4. ..sau așteptați expirarea timpului și afișați rezultatele cu răspunsurile lipsă marcate cu asteriscuri.

Și cauza timeout-urilor este - routerele primesc toate cele 3 solicitări respective, dar uneori nu răspund, nu trimit ICMP Time Exceeded.

Bănuiesc că există unele setări care stabilesc acest comportament pe router. Și anume icmp_ratelimit, icmp_ratemask, icmp_msgs_per_sec și icmp_msgs_burst. Toate descrise cumva la documentele kernel.org. Și aici este punctul în care am eșuat. Nu am venit cu valori ale acelor variabile pentru a face traceroute lucrează tot timpul.

Am încercat să setez asta pe toate routerele:

• icmp_ratelimit setat la 0 (nu limita nimic)
• icmp_msgs_per_sec setat la 10000 (ar trebui să fie suficient de mare)
• icmp_msgs_burst setat la 5000 (destul de sus)

Nu m-a ajutat, văd același comportament, timeout-uri aleatorii. Nu m-am încurcat icmp_ratemask, pentru că nu înțeleg pe deplin cum să exclud Timp depășiteste de la limitare.

Deci, în sfârșit, întrebări:

1. Dacă sunteți familiarizat cu acest tip de traceroute probleme, cum ai rezolvat-o?
2. Dacă sunteți familiarizat cu setările kernelului menționate mai sus, care sunt valorile „suficient de bune”?
3. Care este modalitatea corectă de modificare icmp_ratemask a nu limita Timp depășit mesaje de făcut traceroute lucreaza fara probleme?
4. Și în plus - există încălcări de securitate la modificarea acestor setări (sau a altor setări asociate)? Nu vreau să fiu DoS-ul și nici să fiu o sursă de atac DDoS pentru nimeni.

Ca parte a politicilor planului de control privind hopurile, sondele ICMP sunt în mare parte ignorate. Aș sugera o instanță dedicată pentru fumatul la pret dacă doriți să aveți date istorice mai detaliate, în ceea ce privește valorile și tendințele.