измерение односторонней задержки / дрожания / потери пакетов

10

Я получаю увеличенную задержку и StDev из-за перегруженности маршрута и потери пакетов , но прямой и обратный пути проходят по разным сетям (например, одна - init7.net, другая - he.net), поэтому очень трудно понять какая сеть или хост отвечает за перегрузку, потерю пакетов, джиттер и увеличение задержки.

Есть ли способ сузить вину после того, как прямое и обратное mtrне смогли точно определить виновника, и контакты NOC @ либо не отвечают, либо утверждают, что не потеряли на рассматриваемом пути? (Я использую OpenBSD.)

Я даже пытался mtrобратиться напрямую к некоторым клиентам обеих сетей, которые могут испытывать перегрузку, но не смог найти никаких проблем, особенно потому, что, например, у he.net много POP, и часто между заданным POP входа и выхода выполняются разные маршруты, поэтому, когда я пытаюсь mtrподключиться к их хостам (например, к tserv) непосредственно на выходном POP, на котором я могу потерять пакеты в их сети, для достижения другого пути he.net та же самая POP, и не происходит потери пакетов, что не представляет никакого интереса (кроме возможного предположения, что они могут действительно перегружать некоторые маршруты, в то же время гарантируя, что другие останутся перегруженными, при этом все игнорируя запросы NOC @ от не-клиентов).

CNST
источник
Вам помог какой-нибудь ответ? Если это так, вы должны принять ответ, чтобы вопрос не появлялся вечно, ища ответ. Кроме того, вы можете предоставить и принять свой собственный ответ.
Рон Мопин

Ответы:

9

Одним из способов сделать это является временная метка ICMP, которая составляет миллисекунды с полуночи UTC. Это дает дополнительное преимущество, так как вам не обязательно контролировать оба конца, если дальний конец не защищен огнем, есть большая вероятность, что он сработает.

Однако, чтобы иметь надежные односторонние измерения, вам нужно надежно одинаковое время на обоих концах. Поскольку временная метка ICMP имеет точность только 1 мс (что недостаточно для многих приложений, но достаточно для этого), довольно легко найти даже не взаимодействующие узлы, где временная метка ICMP будет предоставлять полезные данные.

Если вы контролируете оба конца, убедитесь, что вы синхронизируете NTP только с 1 сервером и одним и тем же сервером. Абсолютные часы не очень важны, просто важно, чтобы вы испытывали как можно более точное время.

Если временной метки ICMP недостаточно, очень просто написать 10 строк ruby ​​/ perl / python или даже C для выполнения измерений, когда вы контролируете оба конца.

Я не могу предложить программное обеспечение для измерения меток времени ICMP однонаправленно, hping2 поддерживает отправку меток времени ICMP, но по некоторым причинам не выводит однонаправленные значения. Я написал патч для hping2 для отображения односторонних задержек.

ytti
источник
Вау, твоя hping --icmp-tsдополнительная арифметика такая чертовски классная! Лень получать исходники и перекомпилировать бинарный файл, я взял себе версию оболочки вашего патча hping ( stackoverflow.com/q/20172028/1122270 ), и он показывает довольно постоянное время на пути init7 к Гетцнеру и общая разница с путями he.net от hetzner! У меня наконец есть окончательное доказательство того, что init7 говорит правду! Хотя я бы поспорил против использования одного и того же ntp-сервера только для этого: просто убедитесь, что ntpd жив (мне не нужно было менять какие-либо настройки вообще, но значения выглядят разумными).
2013 года
1
Если вы заботитесь о точном времени ожидания, вам понадобится как минимум 3 NTP-сервера (чтобы иметь возможность обнаружить фальшивый тикер, 2 NTP-сервера - наихудший вариант). Но здесь мы не заботимся о времени на стене, мы заботимся о том, чтобы тикать точно в одно и то же время, независимо от стены. Таким образом, для односторонних измерений оптимальные результаты получаются из точных часов, причем время на стене не имеет значения. Рад слышать, что вы получили результаты!
ytti