The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"ARP запрос не на броадкаст"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение [ Отслеживать ]

"ARP запрос не на броадкаст"  
Сообщение от snooper on 02-Янв-08, 23:57 
Вопрос к знатокам работы 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, но нигде такая аномалия не описана :(
Может кто сталкивался?

Высказать мнение | Ответить | Правка | Cообщить модератору

 Оглавление

Сообщения по теме [Сортировка по времени | RSS]


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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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


Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

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

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

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

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру