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

[sirmax]

Доброго дня!

 

Странность с протоколом 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 назад я сталкивался с таким - но ен могу найти как этоправить. По-моему какая-то опция ядра была - не помню (((

 

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

[vitalyb]

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

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

[bos9]

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

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

 

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

[vitalyb]

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

 

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

[sirmax]

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

 

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

[boco]

может вы про rp_filter?

[bos9]

может вы про rp_filter?

 

к слову пришлось?

[sirmax]

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

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

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 - специально, для эксперемента.

[[anp/hsw]]

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

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

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

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

[sirmax]

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

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

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

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

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

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

 

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

[DVM-Avgoor]

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

[sirmax]

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

Не понял...

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

[[anp/hsw]]

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

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

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

[Painter]

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

 

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

[DVM-Avgoor]

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

 

 

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

[sirmax]

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

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

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

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

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

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

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

[[anp/hsw]]

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

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

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

[vitalyb]

' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

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

[sirmax]

' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

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

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

# ip ro show | grep eth3

тоже пусто.

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

 

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

[DVM-Avgoor]

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