Чому для відповіді PING потрібен запит ARP для вихідних MAC хостів?

У мене є сценарій, як зображено нижче.
Тут два хост-машини підключені через концентратор:

введіть тут опис зображення

Гаразд, хост-1 хоче пінг-хост-2, і у мене є налаштування проводів на 3-му хості, підключеному до того ж концентратора. Зараз напрочуд для роботи однієї команди ping я бачу 6 пакетів, тоді як їх повинно бути 4. Ось що я бачу з wireshark:

введіть тут опис зображення

Тепер, що я не розумію, це те, що чому пакет 5 і 6 генерується, поки він не знаходиться у відповіді ARP, відповідь вже знає mac-відправника.

Або щось не так з моїм розумінням, будь ласка, допоможіть.

ping wireshark arp

— Сара
джерело

Зауважимо лише, що навіть якщо ви не можете завантажувати зображення безпосередньо, imgur буде набагато простіше вбудовувати зображення, ніж знімок зображення - для одного, ви можете просто опублікувати пряме посилання на зображення

— Journeyman Geek

спасибі, він каже, що мені потрібно 10 копій, щоб мати можливість завантажувати зображення, але тому я зараз спробую imgur

— Сара,

Кореляційна дура не передбачає причинного зв'язку. Очевидно, що ехо-відповідь надсилається перед запитом ARP, тому для відповіді PING це не потрібно. Ваша операційна система може просто вирішити трохи оновити стару таблицю ARP після того, як надіслала відповідь ехо. Крім того, я вважаю, що ви покладаєтесь лише на інформацію, яку ви самі визначили під час реалізації стеку TCP / IP. Ризик того, що хтось введе інформацію через спеціально створені пакети, занадто великий. Таким чином, ви швидше вирішуєте MAC-IP-адресу самостійно, ніж використовуєте дані, отримані з попередніх пакетів.

— Der Hochstapler

Це виглядає як деяка форма gratuitous ARP. Який цільовий mac у 5-му запиті? @OliverSalzburg Вузол отримання повинен вшановувати інформацію, отриману в пакеті ARP, і вставляти її у власну таблицю, як зазначено в RFC 826: tools.ietf.org/html/rfc826

— wmz

@wmz, ну а в 5-му запиті невідомий цільовий mac (ff: ff: ff: ff: ff: ff) і ip встановлений для host-1. Я тестував це багато разів, але це так, як це, також якщо я блокую останній арк-рек / відповідь (як це я роблю через контролер openflow), ping працює, однак команда arp yilds дійсна mac для хоста-2 всередині хоста -1 машина, при цьому показує невідомий mac для хоста / 1 ip при запуску на хості / 2 машині. Оскільки я розумів, що тільки один арп-req / відповідь повинен давати обидві системи один одному, тому я хотів дізнатися, чи це помилка чи це справді може статися як нормальна поведінка. Спасибі

— Сара

Оригінальний відповідь

Перша відповідь надходить через інтерфейс концентратора, а не інтерфейс хоста-1. При відправці речей все ще потрібно знати mac інтерфейсу з IP-хостом-1. Деякі перемикачі роблять це автоматично, інші - ні.

Удосконалена відповідь:


              .-----------.
              | hub       |
              |           |
[host-1 i1]+--+hi1     hi2+--+[i2 host-2]
              |           |
              `-----------´

network interfaces: 
i1, i2, hi1, hi2

Після надсилання чого-небудь хосту-1 від хоста-2 через IP-адресу в шарі заявки, початкова відповідь хосту-2 (і всі наступні відповіді) надійде від hi2інтерфейсу, а не i1інтерфейсу в хості-1.

Для того, щоб надіслати що-небудь на вже відомий IP-хост-1, хосту-2 все одно потрібно буде знати, куди надсилати пакети на посилальному шарі. Для цього хост-2 повинен запитати MAC-адресу інтерфейсу, що забороняє IP-хост-1.

Деякі комутатори роблять такий переклад автоматично - вони запам'ятовують мак-шлях назад . Більшість хабів цього не роблять, звідси другий запит.

— Ярослав Рахматуллін
джерело

заплутана відповідь

— Сара

@Sara нормально: \ Я сподіваюся, що це менш заплутано. Ключовим для розуміння цього є те, що існують окремі, незалежні рівні комунікації, і вони майже нічого не знають один про одного.

— Ярослав Рахматуллін