☰

контекст

tag-icon • tag-icon vlan linux-networking ping gateway arp
контекст

контекст

Есть 2 сервера:

сервер1 - eth0 10.129.76.16 eth0.2 192.168.0.103

сервер2 - eth0 10.129.79.1 eth0.2 192.168.62.101

Адреса 192.xxx подключены к одному и тому же vlan (vlan2) и могут видеть друг друга. Адреса 10.xxx подключены к разным 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.xxx вместо 192.xxx. И как я уже говорил, адрес 10.xxx недоступен с другого сервера.

Когда я заставляю 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 не дает эффекта)

Спасибо за прочтение и еще больше спасибо за ответ!

решение1

Вот фрагмент:

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

в порядке ли ваши VLAN?

[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

решение2

Вы не упомянули, какое ядро ​​вы используете или какую версию arping, и есть вероятность ошибки в одном или другом. Тот факт, что вы можете успешно arpingуказать подинтерфейс, указывает на то, что все ваши сети уровня 2 ведут себя правильно.

Попробуйте использовать ip route get 192.168.62.101on server1, чтобы напрямую спросить ядро, как оно будет отправлять ваш трафик. Исходя из таблиц маршрутизации, которые вы опубликовали, отправка через eth0.2 — это явно правильное поведение, и если ip route getвозвращается другой ответ, возможно, вы смотрите на ошибку ядра. Если он возвращает правильный ответ, то arpingвиноват, но это кажется маловероятным.

Эту (incomplete)запись не нужно удалять; это заполнитель, который сообщает ядру, что оно пыталось отправить ARP-запрос на этот IP-адрес, поэтому ответ ARP следует считать действительным и неатака ARP-отравления, но ответа не получил. Истечет время ожидания.

Связанный контент