Я обычно запускаю тесты на время безотказной работы / время ожидания на двух серверах, которыми мы владеем на разных сайтах (и с них), и до недавнего времени я использовал DNS-серверы Google в качестве контрольной группы.
Однако я понял, что существует потенциальная проблема с мониторингом задержки в течение продолжительных периодов времени.
Почти все основные поставщики услуг используют ANYCAST.
Для коротких тестов это не имеет значения, но мне нужно запустить набор тестов в течение как минимум недели, чтобы попытаться выявить периодически возникающую проблему, и изменение приоритета anycast при попытке проверить задержку приведет к значениям задержки для этого сервер поменять соответственно.
Поскольку я отправляю графики этих данных интернет-провайдеру, мне нужно избегать / учитывать как можно больше переменных. Скачки данных только для одного из протестированных серверов вызовут только головную боль.
Кто-нибудь может порекомендовать серверы, которые:
Заранее спасибо.
Изменить: добавлены № 6 и № 7 выше.
Дополнительная информация: я пытаюсь продемонстрировать сетевую проблему для всего узла сети нашего локального интернет-провайдера. Они активно обвиняют в проблеме оборудование, установленное на объектах клиентов (наш резервный сайт является одним из них), и отказываются обострять проблему. (хотя 2 из этих компаний имеют модемы, предоставленные интернет-провайдерами, и у всех нас работают совершенно разные маршрутизаторы / службы)
Я уже хорошо знаком с необходимостью тестирования IP-адресов, контролируемых провайдерами, но они активно отбрасывают все пакеты, нацеленные на IP-адреса шлюзов, и передают только трафик, адресованный за пределы шлюзов. Итак, чтобы продемонстрировать проблему, я отправляю пакеты другим системам на том же узле, системам, находящимся на расстоянии одного шага от затронутого узла, и системам, полностью находящимся вне сети.
К сожалению, все системы, которые у меня есть в настоящее время, либо управляются непосредственно мной, либо людьми, которые достаточно предвзяты, чтобы помочь мне.
Мне нужно включить несколько систем в трассировку / журнал / графики, которые на 100% не находятся под контролем ни меня, ни провайдера, чтобы графики имели стабильную / непредвзятую контрольную группу.
Эти требования прямо из закона, я просто пытаюсь убедиться, что все, что можно аргументировать, чтобы сделать данные недействительными, уже покрыто.
Резюме: мне нужно иметь возможность отображать tcp / udp / icmp как 3 отдельные точки данных, и мне нужно иметь возможность отображать соединения внутри локального узла, от локального узла к другому соседнему узлу, от этих 2 узлов к Интернет и через Интернет как на проверяемые серверы, так и на контрольную группу, которую я не могу контролировать.
Опять же, Google / opendns / yahoo / msn / facebook / etc все используют anycast, который сбрасывает числа каждый раз, когда истекает срок действия кешей anycast, поэтому мне нужны предложения IP или сервера, доступных для этого типа тестирования.
Я надеялся, что кто-то знает о системе, управляемой кем-то вроде ISC или ICANN, или, возможно, даже о сервере .gov (может быть, fcc или nsa?), Настроенном для этого типа тестирования.
Еще раз спасибо.
Мое предложение состояло бы в том, чтобы протестировать узел на ISP, желательно удаленный конец вашей цепи / соединения. Все, что происходит в восходящем направлении от провайдера, находится вне их контроля и не имеет отношения к проблеме (это означает, что они ничего не могут сделать с потерей восходящего пакета или потерей пакетов, которая не происходит в их сети).
Кроме того, на мой взгляд, ping - не лучший инструмент для тестирования и сообщения о потере пакетов. Ответ на трафик ICMP может иметь низкий приоритет вышестоящими узлами или может быть полностью отброшен. Маршрутизаторы заботятся о маршрутизации «реального» трафика, не отвечая на ваш тест ping. Я бы посоветовал вам использовать что-то вроде Ixia QCheck или iperf для проверки потери пакетов с использованием реального трафика.
Симптомы, которые вы указываете в своем последующем обращении, очень похожи на чрезмерную подписку с одноранговым (-ыми) интернет-провайдером. Это очень сложно доказать. Большинство соглашений об уровне обслуживания охватывают только подключение к Интернет-провайдеру, а не подключение Интернет-провайдера к остальной части Интернета. Я бы нашел другого интернет-провайдера, договорился о понижении вашего уровня обслуживания с вашим текущим (если возможно) на оставшуюся часть контракта и отказался от него в конце контракта. Вы можете использовать их в качестве резервного поставщика до тех пор, пока контракт не истечет, поэтому вам не придется полностью его списывать.
Опубликуйте подробную информацию о вашем SLA, и можно будет представить тесты для измерения этих SLA.
В рамках одной из панелей мониторинга рабочего стола Symantec настроил ping.symantec.com. Я не уверен, соответствует ли он вашему №4, но в остальном все в порядке.