Создание петлевой сети Ethernet - как настроить маршруты

2

У меня есть сеть, которая должна быть настроена как петля. Он состоит из 3 узлов, каждый из которых имеет два интерфейса. Диаграмма ниже объясняет это.

+--->(eth0) Node 1 (eth1)--->(eth0) Node 2 (eth1)--->(eth0) Node 3 (eth1)--->+
|    10.0.3.1     10.0.1.1  10.0.1.2     10.0.2.2  10.0.2.3      10.0.3.3    |
+--<----------------------------<--------------------------------------------+

Я хочу сделать эхо-запрос с узла 1 на узел 3, чтобы запрос проходил через узел 2, а ответ шел прямо на узел 1 с узла 3

node1$ ping 10.0.2.3

Я настроил узлы как:

node1# route add -net 10.0.2.0/24 gw 10.0.1.2

node2# route add -net 10.0.3.0/24 gw 10.0.2.3

node3# route add -net 10.0.1.0/24 gw 10.0.3.1

При выполнении ping запрос от узла 1 поступает на узел 3. Однако узел 3 не отвечает, он не генерирует даже ответ (по крайней мере, что я могу захватить с помощью wireshark).

Не могли бы вы дать мне подсказку?

Т.А.

linux networking routing

— jlanza
источник

2

Когда узел выбирает источник IP-адрес для пакета, который он создает, если нет других ограничений, он обычно выбирает IP-адрес, «ближайший» к следующему прыжку на маршруте к месту назначения пакета.

С точки зрения узла 1, следующий переход к узлу 3 10.0.1.2, IP-адрес узла 1, ближайший к 10.0.1.2 является 10.0.1.1не 10.0.3.1, (IP-адрес в той же подсети, что и пункт назначения, считается «ближе» к месту назначения, чем IP-адрес не в той же подсети.)

Проверьте исходный IP-адрес пинга. Скорее всего, это 10.0.1.1не 10.0.3.1, Если у Узла 3 нет маршрута к 10.0.1.1не может ответить.

— David Schwartz
источник

Мне удалось сделать петлю. Я должен включить net.ipv4.conf.all.rp_filter = 0, чтобы получить сгенерированный ответ. Однако, когда пакет прибывает в узел назначения на другом интерфейсе, эхо-запрос не считает пакет хорошим, и поэтому эхо-запрос не выполняется, но пакет попал туда. Адрес назначения и адрес источника ответа не совпадают с адресами в запросе. Я думаю, что это причина.

— jlanza

Это странно. Если вы не используете NAT, нет причин, по которым адреса не будут совпадать.

— David Schwartz

Пакет, полученный, если я помню (не перед системой прямо сейчас), имеет те же адреса (извините), проблема в том, что, поскольку пакет принимается через другой интерфейс, кажется, что он не подтверждает его. Я должен дополнительно проверить, если время позволит мне сделать это.

— jlanza

1

Узлы правильно не повторяются, чтобы предотвратить широковещательную передачу по мосту. Я рекомендую вам запустить протокол Spanning Tree. Это позволит вам разместить полностью функционирующие маршруты между всеми узлами. Я не могу придумать другой способ сделать это, если вы не хотите ограничить связь между определенными ссылками на уровне 2 или уровне 3.

— OCDtech
источник

Он направляет, а не соединяет. Его узлы никогда ничего не повторяют.

— David Schwartz

Я думал об использовании моста, но, как говорит @David Schwartz, мне нужны разные потоки для каждого интерфейса. Кроме того, один из интерфейсов является беспроводным, поэтому я не могу включить его в мост.

— jlanza

0

( /sbin/route устарела, использовать ip route вместо).

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

node1# ip route add 10.0.0.0/22 via 10.0.1.2
node2# ip route add 10.0.0.0/22 via 10.0.2.3
node3# ip route add 10.0.0.0/22 via 10.0.3.1

Однако в большинстве дистрибутивов обратная фильтрация часто включена по умолчанию. Фильтрация обратного пути - это фильтр для входящего пакета, который пытается проверить, будет ли ответ на этот пакет отправляться на тот же интерфейс, что и пакет. Это хорошо в обычной сети, где маршрутизация симметрична, но в вашем случае вам нужна асимметричная маршрутизация, поэтому вы можете просто отключить фильтрацию обратного пути на интерфейсе, где вы получаете пакеты, или хотя бы уменьшить его, чтобы он просто проверял IP-адрес источника является маршрутизируемым:

node1# sysctl -w net.ipv4.conf.eth0.rp_filter=2
node2# sysctl -w net.ipv4.conf.eth0.rp_filter=2
node3# sysctl -w net.ipv4.conf.eth0.rp_filter=2

Документация о фильтрации обратного пути и других регуляторах доступна в документации ядра, по адресу Documentation/networking/ip-sysctl.txt, Где найти, это зависит от вашего дистрибутива (или просто просмотрите ip-sysctl.txt ).

Счастливого цикла!

— BatchyX
источник

в чем смысл net.ipv4.conf.eth0 = 2 ??? где я могу найти больше информации?

— jlanza

@jlanza: Ой, эти строки не так ( rp_filter скучал). Исправил это и обновил ответ указателями документации.

— BatchyX