Сеть маршрутизирует A.com и sub.A.com по-разному

Я согласен с Zephyr, но должен добавить, что поставщик может выполнять балансировку нагрузки IP-маршрута.

Допустим, вы случайный интернет-провайдер и у вас есть 4 эквивалентных ссылки на одну и ту же точку. Вы можете выбрать балансировку нагрузки между этими ссылками. Это значит, что хмель будет не таким.

Это могло быть множество вещей.

Маршруты BGP в самом широком смысле слова - случайные. Это означает, что они зависят от того, какие маршруты BGP используются в настоящее время и как достигается конечная точка AS с наименьшими затратами для вашего провайдера верхнего уровня. Другая потенциальная проблема заключается в том, что у вас есть DNS-запись, такая как DNAME или NAPTR, которая вызвала у меня аналогичные проблемы в прошлом. Если проблема не исчезла, подумайте о том, что ваш провайдер выполняет странное формирование трафика на основе HTTP-запросов (что, по общему признанию, маловероятно). Однако было бы полезно распечатать соответствующую информацию о трассировке.

Крайне сложно сказать что-либо разумное по этому вопросу, не имея на самом деле полных трассировок и реальных IP-адресов. Пожалуйста, не скрывайте такие данные - IP-адреса не являются секретом.

Сказав это, я вижу, что это происходит только в том случае, когда IP-адреса назначения просто не совпадают. Балансировка нагрузки по пакетам иногда выполняется на (частях) каналов, что может вызвать частичные сбои. Однако тогда оба маршрута трассировки должны показывать сбои, а не только один из них.

Итак, учитывая, что IP-адреса назначения разные, я предполагаю, что один из IP-адресов назначения просто не настроен или использует более строгий брандмауэр. Traceroute будет продолжать попытки искать дальше, пока не получит ответ от целевого хоста. Если целевой хост не существует или отказывается отвечать, traceroute будет продолжаться до тех пор, пока не достигнет своего предела, для которого 30 переходов являются обычным параметром.