用于KVM的Linux桥接
我有一台Debian机器，我试图用桥接网络来设置KVM。不幸的是，这座桥似乎没有正确地转发交通。
我的设置如下：
物理机器有一个eth0，它连接到具有IP地址192.168.0.1的路由器。
此eth0是桥接口br0的成员，它静态地配置为IP地址192.168.0.101。
虚拟机的网络接口是物理主机上的vnet0，虚拟机中的eth0。在虚拟机中，静态地将接口配置为IP地址192.168.0.110。
在物理主机上，我可以同时切换虚拟机和路由器：
# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=0.331 ms
# ping 192.168.0.110
PING 192.168.0.110 (192.168.0.110) 56(84) bytes of data.
64 bytes from 192.168.0.110: icmp_req=1 ttl=64 time=0.417 ms在虚拟机中，我可以打开物理机器：
# ping 192.168.0.101:
PING 192.168.0.101 (192.168.0.101) 56(84) bytes of data.
64 bytes from 192.168.0.101: icmp_req=1 ttl=64 time=0.133 ms但我不能打开路由器：
# ping 192.168.0.1:
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.110 icmp_seq=10 Destination Host Unreachable据我所知，桥已经正确设置，所有连接端口都处于转发状态：
# brctl show
bridge name bridge id STP enabled interfaces
br0 8000.2cd444acf8ad no eth0
vnet0
# brctl showstp br0
br0
bridge id 8000.2cd444acf8ad
designated root 8000.2cd444acf8ad
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 0.00 bridge forward delay 0.00
ageing time 300.01
hello timer 1.20 tcn timer 0.00
topology change timer 0.00 gc timer 28.95
flags
eth0 (1)
port id 8001 state forwarding
designated root 8000.2cd444acf8ad path cost 4
designated bridge 8000.2cd444acf8ad message age timer 0.00
designated port 8001 forward delay timer 0.00
designated cost 0 hold timer 0.20
flags
vnet0 (2)
port id 8002 state forwarding
designated root 8000.2cd444acf8ad path cost 100
designated bridge 8000.2cd444acf8ad message age timer 0.00
designated port 8002 forward delay timer 0.00
designated cost 0 hold timer 0.20
flags iptables和ebtables都是空的，默认策略为ACCEPT：
# 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
# ebtables -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有没有人知道是什么原因造成了这个问题，我怎样才能解决它？
编辑：
显然，在构建MAC表时，桥认识到了与其相关的东西：
# brctl showmacs br0
port no mac addr is local? ageing timer
1 2c:76:8a:ff:88:1d no 1.28 <- ???
1 2c:d4:44:ac:f8:ad yes 0.00 <- MAC of br0 and physical eth0
2 52:54:00:53:dd:34 no 143.80 <- MAC of VM's eth0
1 c8:1f:66:ba:83:33 no 0.00 <- MAC of router interface
2 fe:54:00:53:dd:34 yes 0.00 <- MAC of vnet0编辑2:
我刚创建了第二个虚拟机。这台机器在物理机器上有接口vnet1，它的虚拟eth0被分配到IP地址192.168.0.111。这个VM也只能平平物理机器，而不是路由器或原始VM。brctl showstp显示所有端口(包括vnet1 )处于转发状态，brctl showmacs显示vnet1的MACs和新机器的虚拟eth0，以及我上面所写的内容。
回答 2
Server Fault用户
发布于 2014-07-22 12:25:20
检查内核是否设置为启用IP转发：
sysctl -a | grep forwarding您可以通过以下方式启用：
sudo sysctl net.ipv4.conf.all.forwarding=1
sudo sysctl net.ipv6.conf.all.forwarding=1ARP代理也可能有问题。向以下机构查询：
sysctl -a | grep proxy_arp并使用以下命令设置：
sudo sysctl net.ipv4.conf.eth0.proxy_arp=1您可以将键和值放在/etc/sysctl.d下的文件中，以便在重新启动时重置这些值。
从路由器子网上的另一个设备进行测试可能有助于确定问题。
- 点击虚拟机可以提供有用的诊断。
- 检查虚拟机是否可以使用ARP将指示是否可以找到服务器的MAC地址。点击后使用"arp -a“查看是否成功找到了MAC地址。
- Traceroute可以指示问题从哪里开始。
在tcpdump接口上使用eth0进行测试也可能表明连接失败的地方。
- 没有有效响应的重复
arp请求表明存在可达性问题。 - 缺少
echo或echo reply流量可能表明哪一方有问题。 - 跟踪路由器的响应或其后面的地址可能会提供更多信息。
Server Fault用户
发布于 2020-09-25 02:29:55
我知道它有点过时，有点过时，但我想在这里找到我的解决方案。如果您最近将dockerd安装到工作安装程序中，则可能需要卸载它。
我有一个工作的KVM设置数年，然后它停止工作后，重新启动。在浏览了这里的清单之后，我注意到iptables被修改了。近距离检查发现iptables经dockerd修饰。卸载Docker使Linux网桥网络和VM恢复到工作状态。
https://serverfault.com/questions/614455
复制相似问题
腾讯云开发者
