Мосты Ubuntu 16,04 kvm не работают
У меня есть сервер v8 v8, работающий на kvm, у него был rtl nic. я установил патч на vm, сделал «dist-upgrade» на хосте, и теперь мосты, похоже, не пересылают пакеты! хост имеет несколько nics и все статически назначены. BRDMZ - это мост, который мне интересен, его назначил 192.168.4.4, и я могу выполнить ping с другого (физического) хоста. Я пробовал вернуться назад к 4.4.0-98 без везения. какие-либо предложения!? Вот некоторые результаты:
uname -a
Linux vmhost-01 4.4.0-101-generic #124-Ubuntu SMP Fri Nov 10 18:29:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
brctl show
bridge name bridge id STP enabled interfaces
brCSS 8000.001e0b480aba yes eth0
brDMZ 8000.d485644f4aee yes eth3
docker0 8000.0242823a37ed no
virbr0 8000.525400cf415c yes virbr0-nic
sudo ifconfig brDMZ
brDMZ Link encap:Ethernet HWaddr d4:85:64:4f:4a:ee
inet addr:192.168.4.4 Bcast:192.168.4.255 Mask:255.255.255.0
inet6 addr: fe80::d685:64ff:fe4f:4aee/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:168 errors:0 dropped:0 overruns:0 frame:0
TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9004 (9.0 KB) TX bytes:648 (648.0 B)
brctl showstp brDMZ
brDMZ
bridge id 8000.d485644f4aee
designated root 8000.d485644f4aee
root port 0 path cost 0
max age 20.00 bridge max age 20.00
hello time 2.00 bridge hello time 2.00
forward delay 2.00 bridge forward delay 2.00
ageing time 300.00
hello timer 0.52 tcn timer 0.00
topology change timer 0.00 gc timer 171.35
flags
eth3 (1)
port id 8001 state forwarding
designated root 8000.d485644f4aee path cost 4
designated bridge 8000.d485644f4aee message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.00
flags
brctl showmacs brDMZ
port no mac addr is local? ageing timer
1 00:06:5b:f6:8b:dc no 179.48
1 00:0c:29:04:87:83 no 157.46
1 00:0c:29:f1:90:8e no 52.99
1 00:14:5e:77:f7:d7 no 59.09
1 d4:85:64:4f:4a:ee yes 0.00
1 d4:85:64:4f:4a:ee yes 0.00
sudo ebtables -t filter -L
Bridge table: filter
Bridge chain: INPUT, entries: 0, policy: ACCEPT
Bridge chain: FORWARD, entries: 0, policy: ACCEPT
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
2 ответа
запуск tcpdump (в нескольких местах) дал мне ключ к исправлению. я заметил, что arp-трафик показывался на дампах vm и на хосте, но исходящий и входящий трафик отображался только на хосте, а не на vm. ufw бежал, но ничего не было установлено (насколько я мог сказать, ничего не знаю об этом), НО я заметил, что iptables -L показал, что в цепочке FORWARD была политика DENY! я сравнил это с другой установкой ubuntu, которую я имел, и у нее была политика ACCEPT по умолчанию, так что - достаточно уверенно - измените политику, чтобы быть ПРИНИМАЕМ, и все было хорошо!
У меня такое ощущение, что установка docker.io сделал некоторые изменения iptables, но я точно не знаю, просто рад, что эта проблема позади меня!
надеюсь, что это поможет кому-то еще
запуск tcpdump (в нескольких местах) дал мне ключ к исправлению. я заметил, что arp-трафик показывался на дампах vm и на хосте, но исходящий и входящий трафик отображался только на хосте, а не на vm. ufw бежал, но ничего не было установлено (насколько я мог сказать, ничего не знаю об этом), НО я заметил, что iptables -L показал, что в цепочке FORWARD была политика DENY! я сравнил это с другой установкой ubuntu, которую я имел, и у нее была политика ACCEPT по умолчанию, так что - достаточно уверенно - измените политику, чтобы быть ПРИНИМАЕМ, и все было хорошо!
У меня такое ощущение, что установка docker.io сделал некоторые изменения iptables, но я точно не знаю, просто рад, что эта проблема позади меня!
надеюсь, что это поможет кому-то еще
-
1Я хотел бы добавить, что команда для установки политики - sudo iptables -P FORWARD ACCEPT для вышеупомянутого сценария – jamesy829 15 January 2018 в 08:13