Чи нормально для провайдера мати один і той же 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. Корпоративний брандмауер - це власний спеціалізований комп'ютер. Він може відповідати на запити tracroute, якщо вони запрограмовані, із запрограмованою IP-адресою, яка може бути адресою вузла, який він захищає.
Корпоративний маршрутизатор може відповідати як із внутрішнього, так і із зовнішнього інтерфейсів. Такий високошвидкісний та високопропускний маршрутизатор - це фактично мережа в коробці із спеціалізованими суб-маршрутизаторами як компонентами. Відповіді можуть надходити як в прямому, так і в зворотному напрямку маршрутизаторів, відповідаючи тим самим IP.

— harrymc
джерело

Це завжди двічі на шляху. Як могло бути, що він не передає невідомий маршрутизатор у другому випадку?

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

2

Якщо це завжди відбувається, то це відбувається через те, що ваш Інтернет-провайдер налаштував свою мережу. Є кілька інших пояснень, які я не згадував, тому що менш вірогідний: (1) Інтернет-провайдер має брандмауер, який відповідає на запити слідування, (2) Запит передає NAT у провайдера, і ви отримуєте відповідь як з його внутрішнього і зовнішні інтерфейси, але внутрішній інтерфейс відображає свою IP-адресу на зовнішній.

— harrymc

Усі IP-адреси, які ви перераховували, знаходяться в Deutsche Telekom AG. Логічно, що у них є величезна внутрішня мережа з багатьма перекладами,

— harrymc

1

Оскільки це відбувається послідовно, я думаю, що найімовірнішою причиною є помилка в одному з мікропрограмних засобів маршрутизаторів, що призводить до того, що він або не зможе скинути пакет слідів (і надіслати звіт "Перевищено TTL"), коли слід, або відправити його перед ним повинен. Ось приклад першої проблеми зі сторінки " BSD traceroute man" :

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.

Знову ж таки, другий маршрутизатор має помилку, але в цьому випадку це другий маршрутизатор, який перераховується двічі (у прикладі на сторінці man - це третій, який вказаний двічі).

— Гордон Девіссон
джерело