Перейти к содержимому
Калькуляторы

arp - странное поведение (вроде была опция ядра ... )

Доброго дня!

 

Странность с протоколом arp на CentOS 6.4 c ядром

uname  -a
Linux srv1 3.11.6-1.el6.elrepo.x86_64 #1 SMP Fri Oct 18 21:23:20 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

(ядро специально установлено такое - 2.6.32 не устраивает)

 

Вижу вот такое поведение:

172.31.0.21              ether   00:12:cf:dd:5f:6f   C                     eth2
172.31.0.21              ether   00:12:cf:dd:5f:6f   C                     eth1.3100
172.31.0.21              ether   00:12:cf:dd:5f:6f   C                     eth3

 

#ifconfig  eth2
eth2      Link encap:Ethernet  HWaddr 90:E2:BA:2D:F5:A6  
         inet6 addr: fe80::92e2:baff:fe2d:f5a6/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:463382436 errors:0 dropped:0 overruns:0 frame:0
         TX packets:364793571 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:586903167305 (546.5 GiB)  TX bytes:129747160617 (120.8 GiB)
         Memory:fbc20000-fbc40000 

# ifconfig  eth3
eth3      Link encap:Ethernet  HWaddr 00:1E:67:02:60:D8  
         inet6 addr: fe80::21e:67ff:fe02:60d8/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:402505154 errors:0 dropped:1 overruns:0 frame:0
         TX packets:733117290 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000 
         RX bytes:201452590049 (187.6 GiB)  TX bytes:608463747895 (566.6 GiB)
         Memory:fbc00000-fbc20000 

# ifconfig  eth1.3100
eth1.3100 Link encap:Ethernet  HWaddr 00:1E:67:02:60:D8  
         inet addr:172.31.0.1  Bcast:172.31.0.255  Mask:255.255.255.0
         inet6 addr: fe80::21e:67ff:fe02:60d8/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:477150 errors:0 dropped:1 overruns:0 frame:0
         TX packets:457856 errors:0 dropped:15 overruns:0 carrier:0
         collisions:0 txqueuelen:0 
         RX bytes:234085160 (223.2 MiB)  TX bytes:51724845 (49.3 MiB)

 

По факту я вижу что да - запросы и ответы видны на eth1 и eth3 и это нормально - вопрос как заставить систему изучать маки только на тех интерфейсах где есть соответвующие IP ?

 

По-моему года 2 назад я сталкивался с таким - но ен могу найти как этоправить. По-моему какая-то опция ядра была - не помню (((

 

Да, прокси-арп выключен

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

/proc/sys/net/ipv4/conf/*/arp_* - особенно arp_ignore и arp_filter

дока в linux/Documentation/networking/ip-sysctl.txt

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

/proc/sys/net/ipv4/conf/*/arp_* - особенно arp_ignore и arp_filter

дока в linux/Documentation/networking/ip-sysctl.txt

 

только это все касается arp reply, а не самих записей в кэш

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

логично, тогда можно сделать бридж и отфильтровать ebtables

 

еще есть arptables, но использовать его не доводилось

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не, за /proc/sys/net/ipv4/conf/*/arp_* - перечитал еще раз, но это не то.

 

Фильтровать не хочу, криво это как-то ... точнее чем городить бридж то проще уже ACL на свитче наверно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже идей нет =)

у меня тоже - после того как удалил "лишние" вланы ситуация стала еще страньше

arp -na | grep 172.31.0.254
? (172.31.0.254) at <incomplete> on eth3
? (172.31.0.254) at 70:72:cf:1f:91:54 [ether] PERM on eth1.3100
? (172.31.0.254) at <incomplete> on eth2

PERM - специально, для эксперемента.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да у вас кто-то ломится на эти адреса именно через eth3 и eth2 со стороны сервера.

"incomplete" указывает, что arp-запрос послан, а arp-ответ не пришел.

Логично предположить, что оно посылает только запрос, если есть соответствующий роут (ip route add x.x.x.x dev eth2 или ip neigh add). А если роут есть, то с точки зрения стека все корректно.

Т.е. вам нужно разобраться, почему вы кидаете в эти интерфейсы arp-запрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1386584665' post='908647']

Да у вас кто-то ломится на эти адреса именно через eth3 и eth2 со стороны сервера.

"incomplete" указывает, что arp-запрос послан, а arp-ответ не пришел.

Логично предположить, что оно посылает только запрос, если есть соответствующий роут (ip route add x.x.x.x dev eth2 или ip neigh add). А если роут есть, то с точки зрения стека все корректно.

Т.е. вам нужно разобраться, почему вы кидаете в эти интерфейсы arp-запрос.

Роутов нет, и тспдамп тоже никаких запросов не видит. Я предпологаю что их на самом деле нет ) Вопрос в ответах, не в запросах...

 

Если прочитаете с начала то увидите что изначально арп-ответ приходил И на те интефейсы где быть не должен из-за того что в свитче нейтив-влан был прописан на всех портах (что бы ноутом в случае чего с любого порта настроить можно было. Клиентов в серверной не предпологается)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А задать явным образом ипы на интерфейсах где их нет, не пробовали?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А задать явным образом ипы на интерфейсах где их нет, не пробовали?

Не понял...

Это интерфейсы на которых навешаны вланы ... мне не нужны никакие IP на "родительских" интерфейсах ....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Роутов нет, и тспдамп тоже никаких запросов не видит. Я предпологаю что их на самом деле нет ) Вопрос в ответах, не в запросах...

Не может быть. "Incomplete" в вашем тесте явным образом указывает, что запрос-таки был.

По приходу ответа (даже без запроса) не может появиться запись "incomplete", а в зависимости от настроек либо не появится ничего, либо появится запись с ip, пришедшем в ответе (incomplete туда подставить, сами понимаете, нельзя).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Покажите целиком ip route show, ip neighbor show и ip address show в момент проблемы.

 

Вам стоит начать с нормальной архитектуры сети, где нет одинаковых мак адресов на интерфейсах и интерфейсы находятся в разных вланах. Так же включите везде arp filter или arp ignore, чтобы сервера не отвечали на арп запросы, пришедшие через другие интерфейсы. Тогда все станет более "детерминированно".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это интерфейсы на которых навешаны вланы ... мне не нужны никакие IP на "родительских" интерфейсах ....

 

 

Ну ради интереса, попробуйте. Левай какой-нибудь с маской /30 накиньте.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1386773182' post='909579']

Роутов нет, и тспдамп тоже никаких запросов не видит. Я предпологаю что их на самом деле нет ) Вопрос в ответах, не в запросах...

Не может быть. "Incomplete" в вашем тесте явным образом указывает, что запрос-таки был.

По приходу ответа (даже без запроса) не может появиться запись "incomplete", а в зависимости от настроек либо не появится ничего, либо появится запись с ip, пришедшем в ответе (incomplete туда подставить, сами понимаете, нельзя).

Может - "Мамой клянусь" =))

Ну это ж первое что в голову приходит - проверить туда ли запросы уходят. Уходят они правильно - на тех интерфейсах где сейчас incomplete нет и никогда не было никаких адресов.

И естественно это первое что я проверил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Уходят они правильно - на тех интерфейсах где сейчас incomplete нет и никогда не было никаких адресов.

Наличие адреса не означает, что запрос через этот интерфейс нельзя послать (хотя сложновато будет).

Тогда прошу `ip route show cache dev ethX`, где X - каждый интерфейс, на котором у вас лишние arp-записи. Притом лучше сдампить и при incomplete, и при заполлненой таблице.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

Собственно то, что нет на интерфейсе адреса не исключает наличие маршрута на этот интерфейс. Более того, и не обязательно в основной таблице маршрутизации...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

Собственно то, что нет на интерфейсе адреса не исключает наличие маршрута на этот интерфейс. Более того, и не обязательно в основной таблице маршрутизации...

в кешах пусто (как и ожидалось)

# ip ro show | grep eth3

тоже пусто.

Никаких дополнительных неймспейсов или таблиц нет и никогда не было, никаких нестандартных модулей вроде openvswitch тоже нет и не было.

 

Кстати, а куда и зачем дели кеши? (route cache)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну раз не хотите явно задать ип, ifconfig eth3 -arp попробуйте, на вланы повлиять не должно, по идее.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.