Почему при пинге локального маршрутизатора возвращается сообщение "Узел назначения недоступен"?

Question

У меня есть два томатных маршрутизатора. Один соединен беспроводным соединением с другим.

У меня новый сервер в сети. На нем работает Ubuntu Server 11.04.

Все они связаны так:

A - Linux PC
B - New Server
C - Mac Mini
D - Macbook
T1 - Tomato 1
T2 - Tomato 2

They are connected like so:

A -----+-T1  ==== wireless bridge ==== T2----- ADSL modem
       |                               | C & D Connected wirelessly to T2
B -----+

A, C & D не испытывают никаких проблем.

У меня активный сеанс SSH с B от A, и он не испытывает никаких потерь.

B, новый сервер иногда не может пропинговать T2 и, следовательно, не может подключиться к Интернету. Однако A всегда может связаться с B, а B может пропинговать A и B. Когда сеть потеряна, B все еще может пропинговать T1, но не T2, но в то же время, как B потерял соединение с T2, A может пропинговать T2.

Любые идеи о том, что это может быть? нет ничего, что давало бы какие-либо подсказки ни в одном из журналов ни на маршрутизаторе, ни на сервере linux.

Интересно то, что я установил пинг между B и T2. Т2 имеет IP-адрес 192.68.1.1

Вот что я вижу:

From 192.168.1.1 icmp_seq=26 Destination Host Unreachable
From 192.168.1.1 icmp_seq=27 Destination Host Unreachable
From 192.168.1.1 icmp_seq=28 Destination Host Unreachable
From 192.168.1.1 icmp_seq=29 Destination Host Unreachable
From 192.168.1.1 icmp_seq=30 Destination Host Unreachable
From 192.168.1.1 icmp_seq=31 Destination Host Unreachable
From 192.168.1.1 icmp_seq=33 Destination Host Unreachable
From 192.168.1.1 icmp_seq=34 Destination Host Unreachable
From 192.168.1.1 icmp_seq=35 Destination Host Unreachable
64 bytes from 192.168.1.1: icmp_req=36 ttl=63 time=3.40 ms
64 bytes from 192.168.1.1: icmp_req=37 ttl=63 time=5.70 ms
64 bytes from 192.168.1.1: icmp_req=38 ttl=63 time=2.25 ms
64 bytes from 192.168.1.1: icmp_req=39 ttl=63 time=2.18 ms
64 bytes from 192.168.1.1: icmp_req=40 ttl=63 time=3.12 ms
64 bytes from 192.168.1.1: icmp_req=41 ttl=63 time=2.15 ms
64 bytes from 192.168.1.1: icmp_req=42 ttl=63 time=1.97 ms
64 bytes from 192.168.1.1: icmp_req=43 ttl=63 time=

И это циклы, чтобы быть достижимым и нет.

Итак, я думаю, вы могли бы ответить на вопрос: почему маршрутизатор отвечает, что он недоступен?

Answer 1

«Узел назначения недоступен» в том же сегменте сети означает, что преобразование IP-адреса в MAC-адрес с использованием ARP не удалось.

Поскольку беспроводные каналы предполагают, что на стороне клиента имеется только одно устройство, мосты (также Repeaters, кстати) не могут работать через WiFi, если не используются специальные средства, такие как relayd или WDS. Обычно вы даже не можете соединить беспроводные клиентские интерфейсы с интерфейсами Ethernet. Есть только одно исключение: специальный беспроводной драйвер Broadcom, который выполняет «маскировку MAC».

WDS, с другой стороны, должен поддерживаться как на точке доступа, так и на клиенте: в этой конфигурации беспроводной пакет несет 4 MAC-адреса вместо двух. В дополнение к адресам непосредственного отправителя и получателя, есть также адрес отправителя и получателя. Таким образом, возможен настоящий мост Ethernet.

Однако в WDS есть одна проблема: обычно она ограничивает шифрование WPA, что небезопасно. Atheros разработал собственное расширение для WPS, которое позволяет WPA2. Таким образом, есть только одно решение для стабильного моста Ethernet через WiFi: использование устройств Atheros на обоих концах.

STP не имеет к этому никакого отношения.

OpenWrt Wiki также имеет очень хорошую статью о беспроводном режиме клиента.

Answer 2

Поскольку это беспроводной мост, я бы заподозрил слабое соединение. STP не будет настоящей причиной этого. Его цель - предотвратить петли мостов, чтобы ваша сеть не была насыщена зацикливанием пакетов и стала непригодной для использования. Отключать это обычно плохая идея, так как теперь она не защитит вас от этой ситуации.

если порт "подпрыгивает", STP блокирует интерфейс, в то время как он переизбирает корневой мост. Он также заблокирует интерфейс, если обнаружит петлю моста. Я подозреваю, что в вашей топологии есть нечто большее, чем вы показываете на диаграмме. Новый сервер имеет другой интерфейс?