В виртуалку Centos 5 (vmware workstation) проброшены 2 железных ethernet контроллера. Каждый из них в отдельной несвязанной eth сети (два свича). Есть комп ПК в одной из сетей (eth0).
+--------+
| |
| ПК |
| |
+--------+
| IP=B.1 |
+----+---+
|
|
+--------+---------+-----+
|
|
| +-------+------------+
| |
| |
| |
+---+----+ +----+---+
|MAC=AA22| |MAC=BB22|
| | | |
| | | |
| IP=A.2 | | IP=B.2 |
+--------+-----+--------+
| eth0 eth1 |
| |
| Сервер Centos 5 |
+-----------------------+
Если ПК назначить IP=B.1, соответствующий ip-подсети из другой eth-сети (т.е. B.1 и B.2 - формально одна ip-подсеть, A.2 - другая), затем пингануть (или явно запросить arp) B.1, то в таблице arp -ne появится запись о том, что адресу B.2 соответствует MAC AA22. (пинг, конечно, не проходит, так и надо, естественно)
Считаю это поведение неправильным, B.1 никак не должен узнавать о мак-адресе B.2 (его значение BB22), т.к. они находятся в разных eth-сетях, и тем более, не должен получать чужой AA22! Почему то сетевая подсистема centos считает возможным на арп-запрос передать мак с соседнего интерфейса. Как это исправить?
Vmware тут не причем, поэтому опускаю на рисунке. Винда, установленная вместо центоси в ту же вмварю с теми же проброшенными сетевыми адаптерами не транслировала мак-адрес с соседнего интерфейса, и пинг B.2 с ПК не заполнял arp таблицу ничем.
