в каком случае в выводе traceroute есть два соседних перехода в одной подсети? Насколько я знаю, должны быть только исходные адреса, а каждый интерфейс маршрутизатора должен быть в другой подсети?
Например:
1 * * * Request timed out.
2 2 ms 3 ms <3 ms 10.10.0.14
3 5 ms 4 ms 3 ms 10.10.0.15
4 21 ms 22 ms 25 ms 194.221.100.49
Это должно выглядеть примерно так.
(PC) 192.168.1.2 --- 192.168.1.1 (Router1) 10.10.0.X --- 10.10.0.14 (Router2) 10.10.0.x --- 10.10.0.15 (Router3) 192.221.100.X --- 192.221.100.49 (Router4) X.X.X.X
Но в Router2 есть 2 интерфейса в одной подсети, что не может быть возможным?
Какая это может быть конфигурация? Может быть Frame Relay?
решение1
каждый интерфейс маршрутизатора должен находиться в отдельной подсети?
Ошибка в вашей логике заключается в предположении, что топологии сети всегда включают маршрутизаторы, которые строго передают пакеты, полученные на интерфейсе в одной подсети, через интерфейс, определенный в другой подсети. Хотя это верно в обычных средах SOHO и среднего бизнеса, это нетольковозможный режим развертывания доступен. У сетевых инженеров могут быть причины принять другой подход, или из-за удачи и смены конфигурации они могут случайно принять один из подходов.
Существует несколько сценариев, в которых маршрутизатор может получать пакеты, которые впоследствии направляются обратно в ту же сеть, в которой они были получены. Важно, как и относительно какого устройства мы определяем наши подсети. Например, совершенно законно, чтобы маршрутизатор имел интерфейс 10.0.0.1/16, в то время как устройства, находящиеся за ним, используют адреса в подсети 10.0.x.y/24. С точки зрения устройства, пакеты из 10.0.1.x в 10.0.2.x должны были бы пройти через один или несколько маршрутизаторов, но маршрутизатор знает лучше. Это явлениесетевой тромбонобычно находится в ядре корпоративных сетей. Хотя это не обязательно эффективно, это работает, и маршрутизатор выполняет свою работу правильно.
Другое распространенное явление происходит при запуске traceroute с устройства, подключенного к концентратору VPN, который туннелирует свой трафик через VPN на удаленное устройство. Если предположить, что это было причиной вашего вывода traceroute, то устройство, .14скорее всего, будет концентратором, подключенным к корпоративной локальной сети на удаленном конце. Устройство .15является маршрутизатором для сети, к которой подключен концентратор. Пакеты принимаются (туннелируются) на .14интерфейсе и передаются обратно через тот же интерфейс для маршрутизации дальше к месту назначения. В этом нет ничего неправильного, и tracerouteэто законно показывает вам идентификаторы всех устройств, ответственных за касание пакетов на уровне IP.
Без дополнительных точных знаний топологии сети и, в частности, конфигурации промежуточного маршрутизатора(ов), невозможно точно понять, что происходит в вашем случае.
решение2
Traceroute работает, эффективно отправляя пинг с TTl (время жизни) 1. Он попадает на первый маршрутизатор, который отвечает сообщением ICMP Time Exceeded. Он повторяет это, в вашем случае в общей сложности 3 раза.
Затем он отправляет 3 пинга с TTL 2, затем 3 и т.д. Он отображает ответ каждого маршрутизатора как маршрут к хосту.
https://en.wikipedia.org/wiki/Трассировка
Мое первое предположение заключается в том, что если ваша система настроена правильно, то ваш первый маршрутизатор (настроенный так, чтобы не отправлять сообщение Time Exceeded) имеет путь по умолчанию к 10.10.0.14, который имеет статический маршрут, объявленный для подсети 194.221.100.49.