Есть 2 сервера:
server1 - eth0 10.129.76.16 eth0.2 192.168.0.103
server2 - eth0 10.129.79.1 eth0.2 192.168.62.101
Адреса 192.x.x.x подключены к одному и тому же vlan (vlan2) и могут видеть друг друга. Адреса 10.x.x.x подключены к разным vlan, которые не могут видеть друг друга.
по запросу Дэвида Шварца: таблица маршрутизации на сервере 1:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
таблица маршрутизации на сервере 2:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
Когда я пингую с сервера 1 на сервер 2, кажется, что пакеты не приходят, и наоборот. Когда я проверяю маршруты (route -n), я вижу, что по умолчанию gw использует eth0.2 на обоих серверах. Но когда я использую arping, я получаю ответ в одну сторону (с сервера 2 на сервер 1), но не получаю ответа наоборот.
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
Как видите, он использует адрес 10.x.x.x вместо 192.x.x.x. Как я уже говорил, адрес 10.x.x.x недоступен с другого сервера.
Когда я заставляю arping использовать eth0.2, он работает.
У меня нет проблем с пингом других серверов с любого из этих двух серверов.
Я видел это в таблицах arp:
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
и
~# arp -n | grep 192.168.62.101
совершенно очевидно ... Как мне заставить эти серверы снова видеть друг друга?
очистить соответствующие записи в arptable и попытаться избавиться от (неполного), но я думаю, что самая большая проблема в том, что eth0 используется вместо eth0.2 для пакетов с сервера 1 на сервер 2
Из-за замечания Дэвида Шварца о таблицах маршрутизации я добавил туда маршрут, определяющий хост. я добавил
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
и
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
на соответствующие серверы, но это не решило проблему, поэтому я предполагаю, что проблема не в маршрутизации.
Думаю, проблема в следующем.
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
но я не могу удалить эту запись. (arp -d 192.168.0.103 не действует)
Спасибо, что прочитали, и еще больше спасибо за ответ!
Вот отрывок:
arpping не учитывает локальную таблицу маршрутизации:
== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess
используйте icmp для проверки:
[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem
твои вланы в порядке?
[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
Вы не упомянули, какое ядро вы используете или какую версию arping, и есть вероятность ошибки в одном или другом. То, что вы можете успешно arping когда вы указываете подинтерфейс, это означает, что вся ваша сеть уровня 2 работает правильно.
Попробуйте использовать ip route get 192.168.62.101 на server1, чтобы напрямую спросить ядро, как оно будет отправлять ваш трафик. Судя по опубликованным вами таблицам маршрутизации, отправка через eth0.2 явно является правильным поведением, и если ip route get возвращает другой ответ, возможно, вы столкнулись с ошибкой ядра. Если он вернет правильный ответ, то arping виноват, но это кажется маловероятным.
В (incomplete) запись не нужно удалять; это заполнитель, который позволяет ядру узнать, что оно действительно пыталось ARP на этот IP-адрес, поэтому ответ ARP следует считать действительным, а не ARP-ядовая атака, но не получил ответа. Время истечет.