4

Я хотел бы соединить две пары veth на Linux-мосте и попытаться пропинговать одну пару на другую, чтобы протестировать функцию моста.

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

После некоторого устранения неполадок я обнаружил, что:

  • brctl showstp <br> сообщает, что оба порта находятся в состоянии пересылки
  • brctl showmacs <br> показывает как локальный, так и внешний маки

Вопросы:

  • Почему мост не будет пересылать пакеты? (не знаю различий между этими машинами)
  • Или как мне продолжать устранять неполадки?

Любые предложения приветствуются.

-

#!/bin/bash

BR=br1

ip link add veth0 type veth peer name veth1
ip link add veth2 type veth peer name veth3
ip link add $BR type bridge
ip netns add ns0
ip netns add ns1
ip link set veth0 netns ns0
ip link set veth2 netns ns1
ip link set veth1 master $BR
ip link set veth3 master $BR
ip link set $BR up
ip link set veth1 up
ip link set veth3 up
ip netns exec ns0 ip link set veth0 up
ip netns exec ns1 ip link set veth2 up
ip netns exec ns0 ip addr add 172.30.0.1/24 dev veth0
ip netns exec ns1 ip addr add 172.30.0.2/24 dev veth2

ip netns exec ns0 ping 172.30.0.2

РЕДАКТИРОВАТЬ

tcpdump -ni br1 показывает:

23:23:31.097396 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:23:31.097431 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
23:23:31.097443 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 1, length 64
23:23:32.096804 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 2, length 64
23:23:33.096803 IP 172.30.0.1 > 172.30.0.2: ICMP echo request, id 21210, seq 3, length 64

ip netns exec ns1 tcpdump -ni veth2 показывает

23:33:58.198790 ARP, Request who-has 172.30.0.2 tell 172.30.0.1, length 28
23:33:58.198823 ARP, Reply 172.30.0.2 is-at 9e:47:56:91:34:e6, length 28
^C

Мост соединяет пакеты arp, но не соединяет пакеты icmp?

1 ответ1

10

Я решил это.

Оказывается, это iptables который сбрасывает пакеты на мосту. Пакеты проходят через цепочку FORWARD таблицы filter , не соответствующие ее правилам, поэтому применяется политика DROP по умолчанию.

Чтобы проверить, если это вызвано iptables, мы можем попробовать

echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables

затем посмотрите, работает ли мост.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .