Это нормально для провайдера иметь один и тот же IP дважды в маршруте?

8

Если я выхожу из своей домашней сети, я вижу один и тот же IP два раза подряд сразу после маршрутизатора:

  1     1 ms     1 ms     1 ms  router
  2    17 ms    16 ms    16 ms  217.0.117.61
  3    16 ms    16 ms    16 ms  217.0.117.61
  4    17 ms    17 ms    17 ms  87.186.233.102
  5    26 ms    24 ms    24 ms  217.239.39.2
  6    24 ms    24 ms    25 ms  ...

Это нормально, или это может быть неправильная конфигурация от имени провайдера?

networking routing

— Адам Линдберг
источник

3

Если IP находится на несмежных переходах, вероятна неверная конфигурация. но в вашем случае они соседние, что может означать, что это устройство просто уменьшает пакет TTL в два раза.

— Роберт

14

Если это случается один раз или редко

Все IP-пакеты имеют поле времени жизни ( TTL ). Это поле уменьшается на единицу каждым маршрутизатором, который пересылает пакет. Если маршрутизатор уменьшает TTL до 0, он отбрасывает пакет и создает пакет ошибок ICMP TTL превышен, и отправляет его обратно отправителю.

Traceroute использует эту функцию для отправки пакетов с последовательно увеличивающимися TTL. Это позволяет traceroute построить картину пути между источником и местом назначения.

В вашем случае было возможно два пути от вашего маршрутизатора до 217.0.117.61, где один был длиннее другого. Итак, что случилось, было:

Пакет, отправленный с TTL = 1, достиг вашего маршрутизатора, который ответил.
Пакет отправлен с TTL = 2
- достиг вашего маршрутизатора, который уменьшил TTL до 1 и отправил его,
- затем достиг 217.0.117.61, который ответил.
Пакет отправлен с TTL = 3
- достиг вашего маршрутизатора, который уменьшил TTL до 2 и отправил его,
- затем достиг неизвестного маршрутизатора, который уменьшил TTL до 1 и отправил его,
- затем достиг 217.0.117.61, который ответил.

Вот почему у вас есть одна и та же запись дважды. Могло бы быть и хуже, если бы каждый IP-адрес был указан дважды, но, очевидно, маршрутизатор, который дал первый ответ 217.0.117.61, больше никогда не участвовал в трассировке, поэтому все последующие пакеты проходили через неизвестный маршрутизатор, IP-адрес которого так и не был возвращен.

Если это всегда происходит

Тогда это из-за способа, которым ваш провайдер настроил свою сеть. IP-адреса в вашем списке принадлежат Deutsche Telekom AG, которая имеет огромную внутреннюю сеть с высокопроизводительными сложными узлами, из которых один, кажется, отвечает дважды.

Есть несколько возможных объяснений:

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

— harrymc
источник

Это всегда дважды на пути. Как могло случиться, что во втором случае он не пройдет неизвестный маршрутизатор?

— Адам Линдберг

2

Если это всегда происходит, то это связано с тем, как ваш провайдер настроил свою сеть. Есть несколько других объяснений, которые я не упомянул, потому что менее вероятно: (1) у провайдера есть брандмауэр, который отвечает на запросы traceroute, (2) запрос проходит NAT у провайдера, и вы получаете ответ от обоих его внутренних и внешние интерфейсы, но внутренний интерфейс отображает свой IP на внешний.

— Harrymc

Все перечисленные вами IP-адреса находятся внутри Deutsche Telekom AG. Логично, что у них огромная внутренняя сеть с множеством переводов,

— harrymc

1

Поскольку это происходит последовательно, я думаю, что наиболее вероятной причиной является ошибка в одной из прошивок маршрутизатора, приводящая к тому, что он либо не может отбросить пакет трассировки (и отправить отчет «Превышен TTL»), когда это необходимо, либо отправить его до него. должен. Вот пример первой проблемы со страницы руководства по BSD traceroute :

A sample use and output might be:

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
 1 helios.ee.lbl.gov (128.3.112.1)  19 ms 19 ms  0 ms
 2 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 [...]

Note that lines 2 & 3 are the same.  This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).

В этом примере это второй маршрутизатор с ошибкой, а третий маршрутизатор отображается как №2 и №3.

С другой стороны, рассмотрим, что произойдет, если на втором маршрутизаторе будет ошибка, из-за которой он отбрасывает пакеты, когда TTL достигнет 1 вместо 0:

Пакет трассировки, отправленный с TTL = 1, уменьшается до 0 на первом маршрутизаторе, который отбрасывает его и сообщает о превышении TTL, поэтому он отображается как переход № 1. Все хорошо здесь.
Пакет, отправленный с TTL = 2, уменьшается до 1 на первом маршрутизаторе; затем второй маршрутизатор уменьшает его до 0, сбрасывает и сообщает об этом, и поэтому он отображается как переход № 2. Опять все хорошо здесь.
Пакет, отправленный с TTL = 3, уменьшается до 2 на первом маршрутизаторе; затем второй маршрутизатор уменьшает его до 1, ошибочно сбрасывает и сообщает об этом, и поэтому он отображается как переход № 3.

Опять же, это второй маршрутизатор с ошибкой, но в данном случае это второй маршрутизатор, который указан дважды (в примере на странице руководства это третий, который указан дважды).

— Гордон Дэвиссон
источник