Вопрос к знатокам работы ARP

Я, честно говоря, всегда считал, что ARP запрос (who has ip) всегда идет на броадкаст (как иначе)
НО, мою уверенность здорово поколебало то, что я наблюдаю собственными глазами в своей домашней сетке, а именно:

есть 2 компа (на обоих Debian GNU/Linux 4.0):
- 192.168.1.1/24 (MAC: EpoxComp_7c:ea:2a)
- 192.168.1.4/24 (MAC: AbitComp_ef:fe:06)

так вот включаем на 192.168.1.4 wireshark и видим такую картину:

С 192.168.1.1 идут ARP запросы (who has) на КОНКРЕТНЫЙ MAC компа с 192.168.1.4 !!!
Т.е.
EpoxComp_7c:ea:2a    AbitComp_ef:fe:06    ARP    Who has 192.168.1.4?  Tell 192.168.1.1

Т.е. это не вопрос какой-то, а "проверка уверенности"? :)
И на такой ARP запрос идет нормальный реплай уже в обратную сторону.

Может мне кто-то объяснить данный феномен? Я прочитал кучу доков по ARP, но нигде такая аномалия не описана :(
Может кто сталкивался?

• ARP запрос не на броадкаст,Kos, 13:53 , 03-Янв-08
  • ARP запрос не на броадкаст,snooper, 14:48 , 03-Янв-08
    • ARP запрос не на броадкаст,sfstudio, 05:15 , 05-Янв-08
      • ARP запрос не на броадкаст,Den, 17:13 , 05-Янв-08

>[оверквотинг удален]
>Т.е.
>EpoxComp_7c:ea:2a AbitComp_ef:fe:06 ARP Who has 192.168.1.4?  Tell 192.168.1.1
>
>Т.е. это не вопрос какой-то, а "проверка уверенности"? :)
>И на такой ARP запрос идет нормальный реплай уже в обратную сторону.
>
>
>Может мне кто-то объяснить данный феномен? Я прочитал кучу доков по ARP,
>но нигде такая аномалия не описана :(
>Может кто сталкивался?

Я, честно говоря, знатоком ARP не являюсь))), но может быть дело в кешировании?

>[оверквотинг удален]
>>Т.е. это не вопрос какой-то, а "проверка уверенности"? :)
>>И на такой ARP запрос идет нормальный реплай уже в обратную сторону.
>>
>>
>>Может мне кто-то объяснить данный феномен? Я прочитал кучу доков по ARP,
>>но нигде такая аномалия не описана :(
>>Может кто сталкивался?
>
>Я, честно говоря, знатоком ARP не являюсь))), но может быть дело в
>кешировании?

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

Компьютеры включены в свич? Тады всё нормально, просто свич держит в своей памяти арп таблицу и только в первый раз опрашивает все порты, далее держит запись у себя в буфере пока не истечёт таймаут/не будет вытеснена другими записями(буфер небольшо)/или не свалится "спорный" с точки зрения свича пакет (т.е. пакет с маком источником пришёл с порта 5 хотя до этого в последний раз пакет с таким маком приходил с 16 к примеру). У многих мыльниц время хранения "маршрута" - бесконечность, а значит маршрут из таблици будет удалён только по 2й или 3ей причине. Это что касается поведения. Мак адрес назначения в таком случае дописывает в заголовок свич ИМХО. Вот и вся любовь.

P.S. На 100% истинность не ручаюсь, но смысл думаю понятен.

>[оверквотинг удален]
>будет вытеснена другими записями(буфер небольшо)/или не свалится "спорный" с точки зрения
>свича пакет (т.е. пакет с маком источником пришёл с порта 5
>хотя до этого в последний раз пакет с таким маком приходил
>с 16 к примеру). У многих мыльниц время хранения "маршрута" -
>бесконечность, а значит маршрут из таблици будет удалён только по 2й
>или 3ей причине. Это что касается поведения. Мак адрес назначения в
>таком случае дописывает в заголовок свич ИМХО. Вот и вся любовь.
>
>
>P.S. На 100% истинность не ручаюсь, но смысл думаю понятен.

с каких это пор тупые свитчи работают с arp - они и понятия не имеют об IP адрессах, а в тупую строят таблицу соответствия MAC <=> PORT. И накакого кеша там нету.

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