ARP запросы сервера на несуществующие ip адреса

[metalsoft]

Всем добра, коллеги!

Сервер 172.16.0.1 подключен к влану управления коммутаторами vlan_id 3, коммутаторы имеют адреса 172.16.1.x...172.16.35.x, коммутаторов с бОльшими ip  адресами нет. Однако tcpdump показывает следующую картину:

[root@ipoe1 ~]# tcpdump -enn -i eth1.3

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.3, link-type EN10MB (Ethernet), capture size 65535 bytes
10:59:28.777981 90:e2:ba:20:58:f2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.22.6.34 tell 172.16.0.2, length 46
10:59:28.997366 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.23 tell 172.16.0.1, length 28
10:59:28.997371 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.31 tell 172.16.0.1, length 28
10:59:28.997373 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.36 tell 172.16.0.1, length 28
10:59:28.997375 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.24 tell 172.16.0.1, length 28
10:59:28.997376 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.48 tell 172.16.0.1, length 28
10:59:28.997378 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.39 tell 172.16.0.1, length 28
10:59:28.997380 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.52 tell 172.16.0.1, length 28
10:59:28.997382 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.25 tell 172.16.0.1, length 28
10:59:28.997384 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.42 tell 172.16.0.1, length 28
10:59:28.997385 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.32 tell 172.16.0.1, length 28
10:59:28.997387 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.51 tell 172.16.0.1, length 28
10:59:28.997389 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.43 tell 172.16.0.1, length 28
10:59:28.997390 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.38 tell 172.16.0.1, length 28
10:59:28.997392 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.62 tell 172.16.0.1, length 28
10:59:28.997394 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.49 tell 172.16.0.1, length 28
10:59:28.997396 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.30 tell 172.16.0.1, length 28
10:59:28.997397 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.41 tell 172.16.0.1, length 28
10:59:28.997399 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.45 tell 172.16.0.1, length 28
10:59:28.997401 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.54 tell 172.16.0.1, length 28
10:59:28.997403 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.57 tell 172.16.0.1, length 28
10:59:28.997405 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.63 tell 172.16.0.1, length 28
10:59:28.997407 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.28 tell 172.16.0.1, length 28
10:59:28.997409 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.46 tell 172.16.0.1, length 28
10:59:28.997410 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.58 tell 172.16.0.1, length 28
10:59:28.997412 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.33 tell 172.16.0.1, length 28
10:59:28.997414 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.29 tell 172.16.0.1, length 28
10:59:28.997415 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.59 tell 172.16.0.1, length 28

Сегменты ip адреса после 172.16. разные. Насколько  я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник?

[azhur]

Для начала, на сетевке у сервера и коммутаторах маска (/12 или таки поуже) и шлюз какие настроены?

[metalsoft]

Да, маска /12 и на сервере и на коммутаторах.  И этот сервер является шлюзом в другие сети.

[ShyLion]

49 minutes ago, metalsoft said:

маска /12 и на сервере и на коммутаторах

Это Победа!

[VolanD666]

59 минут назад, metalsoft сказал:

Всем добра, коллеги!

Сервер 172.16.0.1 подключен к влану управления коммутаторами vlan_id 3, коммутаторы имеют адреса 172.16.1.x...172.16.35.x, коммутаторов с бОльшими ip  адресами нет. Однако tcpdump показывает следующую картину:

 

  Скрыть содержимое

[root@ipoe1 ~]# tcpdump -enn -i eth1.3

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.3, link-type EN10MB (Ethernet), capture size 65535 bytes
10:59:28.777981 90:e2:ba:20:58:f2 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 172.22.6.34 tell 172.16.0.2, length 46
10:59:28.997366 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.23 tell 172.16.0.1, length 28
10:59:28.997371 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.31 tell 172.16.0.1, length 28
10:59:28.997373 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.36 tell 172.16.0.1, length 28
10:59:28.997375 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.24 tell 172.16.0.1, length 28
10:59:28.997376 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.48 tell 172.16.0.1, length 28
10:59:28.997378 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.39 tell 172.16.0.1, length 28
10:59:28.997380 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.52 tell 172.16.0.1, length 28
10:59:28.997382 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.25 tell 172.16.0.1, length 28
10:59:28.997384 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.42 tell 172.16.0.1, length 28
10:59:28.997385 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.32 tell 172.16.0.1, length 28
10:59:28.997387 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.51 tell 172.16.0.1, length 28
10:59:28.997389 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.43 tell 172.16.0.1, length 28
10:59:28.997390 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.38 tell 172.16.0.1, length 28
10:59:28.997392 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.62 tell 172.16.0.1, length 28
10:59:28.997394 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.49 tell 172.16.0.1, length 28
10:59:28.997396 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.30 tell 172.16.0.1, length 28
10:59:28.997397 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.41 tell 172.16.0.1, length 28
10:59:28.997399 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.45 tell 172.16.0.1, length 28
10:59:28.997401 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.54 tell 172.16.0.1, length 28
10:59:28.997403 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.57 tell 172.16.0.1, length 28
10:59:28.997405 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.63 tell 172.16.0.1, length 28
10:59:28.997407 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.28 tell 172.16.0.1, length 28
10:59:28.997409 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.46 tell 172.16.0.1, length 28
10:59:28.997410 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.58 tell 172.16.0.1, length 28
10:59:28.997412 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.33 tell 172.16.0.1, length 28
10:59:28.997414 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.29 tell 172.16.0.1, length 28
10:59:28.997415 90:e2:ba:35:8d:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 172.16.184.59 tell 172.16.0.1, length 28

Сегменты ip адреса после 172.16. разные. Насколько  я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник?

А почему вы решили что сервер не может просто стучаться на эти адреса? Без начального пакета?

[azhur]

 

59 минут назад, metalsoft сказал:

сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы.

Если сервер "получил пакет с этих адресов" внутри соответствующего l2 сегмента, то данные из пакета (src ip, src mac) должны, насколько я помню, автоматом попадать в arp-таблицу, и соответственно arp-запросы не нужны.

Как вариант, не могут ли пакеты с такими src-адресами поступать через другой сетевой интерфейс сервера?

[Saab95]

Ага, или просто что-то или кто-то сеть сканирует на доступность, например тот же заббикс при не верных настройках.

[Ivan_83]

17 часов назад, metalsoft сказал:

Сегменты ip адреса после 172.16. разные. Насколько  я понимаю, сервер получает какие-то начальные пакеты с этих адресов, но т.к. этих адресов нет в его arp-таблице, он отправляет к ним arp запросы. Но тогда с каждого из этих адресов должно быть хотя по одному этому начальному пакету, а в выводе tcpdump я их не вижу вобще. Как вычислить источник?

 

16 часов назад, azhur сказал:

Если сервер "получил пакет с этих адресов" внутри соответствующего l2 сегмента, то данные из пакета (src ip, src mac) должны, насколько я помню, автоматом попадать в arp-таблицу, и соответственно arp-запросы не нужны.

У вас не точное представление о том как работают современные ОС.

 

1. Даже если с этих адресов кто то пришёл на хост, и хост собирается ответить - он всё равно запросит через арп.

Это делается по банальной причине - экономия цпу: слишком накладно мак адрес каждого входящего пакета чекать на присутствие в арп таблице и добавлять туда, и не факт что он вообще понадобится потом.

 

2. Нечто подобное может быть если включён прокси арп или не верно настрона таблица маршрузации: хост может думать что все остальные хосты в его сегменте и пытаться отрезолвить их адрес через арп.

 

16 часов назад, azhur сказал:

Как вариант, не могут ли пакеты с такими src-адресами поступать через другой сетевой интерфейс сервера?

Могут.

Адрес коммутатора который запрашивает идёт после tell, вот на них и смотрите что понастроено.

[mcdemon]

17 часов назад, metalsoft сказал:

Сервер 172.16.0.1

а сервер вообще для чего используется?

не является ли он маршрутизатором для кого-то?

[azhur]

5 часов назад, Ivan_83 сказал:

У вас не точное представление о том как работают современные ОС. 

  

1. Даже если с этих адресов кто то пришёл на хост, и хост собирается ответить - он всё равно запросит через арп.

Это делается по банальной причине - экономия цпу: слишком накладно мак адрес каждого входящего пакета чекать на присутствие в арп таблице и добавлять туда, и не факт что он вообще понадобится потом.

Вполне возможно, что и так, на истину в последней инстанции не претендую.

[metalsoft]

Исследавание показало, что пакеты на самом деле приходили через другой интерфейс, и было решено перестроить сегмент сети по-нормальному :) Проблема решена, спасибо всем за участие!