Наблюдаю аномальное поведение Cisco в отношении маршрутизаторов.
Сценарий 1:
Сценарий 2:
Когда я пытаюсь проверить связь с интерфейсом LAN 1905 года с сервера A, я получаю 0,3-0,5 мс, но когда я пытаюсь проверить связь с интерфейсом LAN маршрутизатора 1700 с сервера A, я получаю 1,02 мс.
Может ли кто-нибудь объяснить, почему эта разница в 0,7 мс не отражается, когда я пытаюсь проверить связь с сервером B с сервера A, я получаю постоянное значение 3,2 -3,3 мс
Если вы отправляете эхо-запрос на сам маршрутизатор, вы взаимодействуете с уровнем управления IOS. Поэтому операционная система должна быть разбужена и отвечать на ваш ICMP-запрос. Если у вас есть две разные платформы (1700 и 1905), возможно, с разными версиями и наборами функций, а также с разными конфигурациями, чтобы обеспечить занятость, вы должны ожидать разных результатов. Пересылка трафика между серверами с использованием уровня пересылки маршрутизаторов, вероятно, требует аппаратной поддержки и будет менее разнообразной.
С учетом всего сказанного, почему вас вообще интересуют несколько миллисекунд? Разве тебе не о чем беспокоиться поважнее ;-)
Никогда не используйте эхо-запрос к интерфейсу маршрутизатора Cisco для чего-либо, кроме диагностики общего подключения. Ответ на сообщения ICMP - это (и всегда было) самый низкий приоритет в системе. Это верно от самых маленьких до самых больших маршрутизаторов и вызывается. Ping -through- маршрутизатор к чему-то еще (например, к какому-то хосту). Кстати, это верно не только для маршрутизаторов Cisco, но и для многих других.
Единственным исключением из этого правила является мониторинг SLA, который представляет собой набор функций, выполняемых с более высоким приоритетом для измерения задержки данного канала. Однако это совсем другое дело, чем пинг интерфейса маршрутизатора.
Попытка определить место задержки в сети с помощью ping в лучшем случае непросто. В худшем - невозможно. В лучшем случае вам просто нужно учитывать тот факт, что маршрутизатор, отвечающий на ping, совершенно не связан с тем, насколько быстро маршрутизатор может отправить пакет ping с одного интерфейса на другой (большинство маршрутизаторов отвечают на ping с почти наименьшим приоритетом, поэтому время отклика ping обычно сильно различается и обычно намного превышает задержку, возникающую при простой пересылке).
Наблюдаемые вами 0,7 мс, вероятно, объясняются тем, что у 1905 года больше циклов ЦП, чем у 1700.
Использование traceroute (или аналогичного) для поиска пути, по которому соединение проходит через сеть, может быть полезным с последующей проверкой уровней трафика на промежуточных переходах. Однако это позволит выявить только задержки в точках маршрутизации. Возможно замедление работы коммутаторов и маршрутизаторов. В целом, 3 мс - это, вероятно, не слишком большая проблема, и если это так, могут быть другие способы ее решения. В прошлом я видел (некоторые) приложения OLTP, которые замедлялись, когда задержка FE / BE увеличивалась на несколько мс, но обеспечение того, чтобы у них было несколько невыполненных запросов, позаботилось о многом (параллельные запросы вместо строгой сериализации ). Я бы сказал, что чаще всего различная задержка обычно вызывает больше проблем, чем постоянная (хотя, возможно, более высокая) задержка.