mierzyć jednokierunkowe opóźnienie / jitter / utratę pakietów

Dostaję większe opóźnienia i StDev z powodu przeciążenia trasy i utraty pakietów , ale ścieżki do przodu i do tyłu biegną przez różne sieci (np. Jedna to init7.net, a druga he.net), więc bardzo trudno jest ją zrozumieć która sieć lub host jest odpowiedzialny za przeciążenie, utratę pakietów, fluktuację i zwiększone opóźnienie.

Czy istnieje sposób na zawężenie winy po tym, jak naprzód i wstecz mtrnie potrafią wskazać dokładnego winowajcy, a kontakty NOC @ albo nie odpowiadają, albo twierdzą, że nie ponoszą strat na danej ścieżce? (Używam OpenBSD).

Próbowałem nawet zrobić mtrbezpośrednio z niektórymi klientami obu sieci, które mogą doświadczać przeciążenia, ale tak naprawdę nie mogłem znaleźć żadnych problemów w ten sposób, zwłaszcza, że ​​na przykład he.net ma wiele POP i często różne trasy są wybierane między danym wejściem a wyjściem POP, więc kiedy próbuję mtrdotrzeć do ich hostów (takich jak tserv) bezpośrednio przy wyjściu POP, do którego mogę tracić pakiety w ich sieci, inna ścieżka he.net jest osiągana ten sam POP i nie dochodzi do utraty pakietów, co nie świadczy o nic interesującym (poza możliwą sugestią, że rzeczywiście mogą przeciążać niektóre trasy, jednocześnie zapewniając, że inne pozostaną nietknięte, a jednocześnie ignorują żądania NOC @ od klientów niebędących klientami).

Jednym ze sposobów na to jest datownik ICMP, który jest milisekund od północy UTC. Ma tę dodatkową zaletę, że niekoniecznie musisz kontrolować oba końce, o ile drugi koniec nie jest zaporą ogniową, istnieje duża szansa, że ​​zadziała.

Jednak, aby mieć wiarygodne pomiary jednokierunkowe, potrzebujesz niezawodnie tego samego czasu na obu końcach. Ponieważ znacznik czasu ICMP ma dokładność tylko 1 ms (co nie jest wystarczające dla wielu aplikacji, ale wystarczające do tego), dość łatwo można znaleźć nawet niewspółpracujące hosty, w których znacznik czasu ICMP dostarczy użytecznych danych.

Jeśli kontrolujesz oba końce, upewnij się, że synchronizujesz NTP tylko z 1 serwerem i tym samym serwerem. Zegar absolutny nie jest bardzo ważny, ważne jest, abyś doświadczył tak blisko czasu, jak to możliwe.

Jeśli znacznik czasu ICMP nie jest wystarczający, bardzo łatwo jest napisać 10 linii ruby ​​/ perl / python lub nawet C, aby wykonać pomiary, gdy kontrolujesz oba końce.

Naprawdę nie mogę zasugerować oprogramowania do wykonywania pomiarów znacznika czasu ICMP jednokierunkowo, hping2 obsługuje wysyłanie znacznika czasu ICMP, ale z jakiegoś powodu nie generuje wartości jednokierunkowych. Napisałem łatkę dla hping2, aby wyświetlała opóźnienia w jedną stronę.