NAT на тот же физический интерфейс

Хосты А и B тоже в сети 172.16.0.0/12? И вирт. машины там же через bridge?

скорее всего с раутингом проблемы, echo-request уходит (ты видишь логи на А), echo-reply не возвращается до вирт. на В

Вероятно, на машине A роутинг на всю сеть 172.16.0.0/12 заруливается на виртуалку на этой машине и до виртуалки на машину B трафик просто не доходит...

route -n с машины A какой?

Да, везде 172.16.0.0/12 и бридж. С машин хоста B я могу ходить на машины хоста A и на сам хост A.

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
77.nda.ip-addr.0      0.0.0.0         255.255.255.224 U     0      0        0 br0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
172.16.0.0      0.0.0.0         255.240.0.0     U     0      0        0 br0
0.0.0.0         77.nda.ip-addr.30     0.0.0.0         UG    100    0        0 br0

Вот так. 192.168.122.0 создал libvirt. Оно не используется. Реальный ip'шник скрыт.

Reset> 192.168.122.0 создал libvirt. Оно не используется.

virsh net-destroy default

rm /etc/libvirt/qemu/networks/autostart/default.xml

ты iptables-save смотрел? сеть default тоже NAT поднимает

а на интерфейсе br0 кроме адреса из 172.16.0.0/12 сети ещё какие-нибудь адреса есть?

можно ли как разделить адресные пространства, чтобы получились две сетки? например

1) br0 <---> (хост B и виртуалки)
2) br0:0 <---> 77.nda.ip-addr.30

всё левое убрал, естественно, ничего не заработало

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
LOG        all  --  172.16.0.0          !172.16.0.0/12       LOG level warning prefix `iptables nat'
MASQUERADE  all  --  172.16.0.0/12       !172.16.0.0/12

$ sudo iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

1) br0 <---> (хост B и виртуалки)
2) br0:0 <---> 77.nda.ip-addr.30

с точностью до наоборот

запусти

tcpdump -n -i br0 icmp

на обоих хостах и запусти пинг с вирт. на хосте В

$ sudo tcpdump -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:39:15.981954 IP 172.16.0.21 > 217.76.32.61: ICMP echo request, id 10000, seq 4, length 64
20:39:15.984648 IP 217.76.32.61 > 172.16.0.21: ICMP echo reply, id 10000, seq 4, length 64
...

Срубаю tcpdump и работать перестает. Чудеса.

На B нужно указать default route=IP A.

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

Reset> Срубаю tcpdump и работать перестает. Чудеса.

tcpdump (без -p) переводит сетвуху в promiscuous mode

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

Не работает. Только request'ы идут.

$ sudo tcpdump -p -n -i br0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:16:11.212480 IP 172.16.0.21 > 217.76.32.61: ICMP echo request, id 1060, seq 1, length 64
21:16:11.212509 IP host-a-ip > 217.76.32.61: ICMP echo request, id 1060, seq 1, length 64
21:16:12.216864 IP 172.16.0.21 > 217.76.32.61: ICMP echo request, id 1060, seq 2, length 64
21:16:12.216888 IP host-a-ip > 217.76.32.61: ICMP echo request, id 1060, seq 2, length 64
21:16:13.236695 IP 172.16.0.21 > 217.76.32.61: ICMP echo request, id 1060, seq 3, length 64

> Срубаю tcpdump и работать перестает. Чудеса.

tcpdump, наверное, ставит promiscous mode. Что намекает на проблему с конфигурацией моста.

Про promiscous mode я уже догадался. А какие могут быть проблемы с конфигурацией моста?

конфигурация выглядит так

auto lo
iface lo inet loopback
auto br0
iface br0 inet static
  address 77.nda.ip-addr.1
  netmask 255.255.255.224
  gateway 77.nda.ip-addr.30
  network 77.nda.ip-addr.0
  mtu 1450
  bridge_ports eth1
  bridge_stp off
  bridge_maxwait 0
  bridge_fd 0
auto br0:0
iface br0:0 inet static
  address 172.16.0.1
  netmask 255.240.0.0
  network 172.16.0.0

Reset> Это уже радикальное решение. Смогу попробовать только во вторник.

А как же до сих пор пинг на лор шел через хост А? Если ты добавил static routing для лора через хост А и это, как мы видим не работает, то и default route не поможет

Reset> Срубаю tcpdump и работать перестает. Чудеса.

это на хосте В?

И еще вопрос: с хоста В (не из виртуалки) пинг на ЛОР есть?

route, естественно, не поможет, default route, кстати, там стоит правильный.
сейчас я вижу два решения:
1. поставить интерфейс в promisc
2. подключить второй шнурок и скорее всего даже в другой свитч.

На хосте A.

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

Ну, смеха ради попробуй включить STP.

пробовал - не помогает

Меня интересовало есть ли пинг с хоста В через хост А

Такого пинга нет. Работает все аналогично как если пинговать из виртуалки.

похоже мост тупит, spanning tree protocol выключить надо.

sudo brctl show

bridge_stp off

а он и так выкл.

Мыслей пока больше нет.

как вариант на время отключить bridge и убедиться, что это он виноват

Да, без bridge'а работает. Значит bridge глючит.

вроде не пробегало, так какой default gw на виртуалках на B?

ip ro