Jump to content
Калькуляторы

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites
' timestamp='1386584665' post='908647']

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

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

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

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

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

 

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

Share this post


Link to post
Share on other sites

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

Не понял...

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

 

 

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

Share this post


Link to post
Share on other sites
' timestamp='1386773182' post='909579']

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites
' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

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

Share this post


Link to post
Share on other sites
' timestamp='1386855957' post=910020]

ip route show cache dev ethX

в 3.11 нет route cache

 

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

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

# ip ro show | grep eth3

тоже пусто.

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this