路由应该设置在网桥上,而不是虚拟网卡上 ( by quqi99 )

来源:互联网 发布:继承者们 知乎 男二 编辑:程序博客网 时间:2024/05/21 08:18

路由应该设置在网桥上,而不是虚拟网卡上 ( by quqi99 )

作者:张华  发表于:2013-04-13
版权声明:可以任意转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本版权声明

( http://blog.csdn.net/quqi99 )

    

   最近遇到一个问题,两台机器上的两个网桥上的两个tap设备不能互通,查了半天,发现网桥上没路由,而是设置到虚拟网卡上了。

   之前给br-int设置ip时,系统会自动地在br-int上也设置一条路由规则,就通了,也就没注意。但是当给tap设备手工设置ip时,系统也会自动在tap设备设置路由,而不是在网桥上,所以就ping不通了。之前经常偶尔发现虚机和物理机不能互通估计都是这个原因。

          正确 route add -net 10.0.1.0 netmask 255.255.255.0 dev br-int

   错误 route add -net 10.0.1.0 netmask 255.255.255.0 dev tap0


         2013-04-26补充:

   今天使用openvswitch创建一个虚机网卡后,路由在虚拟网卡不在桥上是可以work的,但是要保证一点,将虚拟网络设置属性type=internal:

          sudo ovs-vsctl add-port br-eth0 br-eth0-if -- set interface br-eth0-if type=internal

           in /etc/network/interface, add

            auto br-eth0-if

            iface br-eth0-if inet dhcp

          文章 Connecting OVS Bridges with Patch Ports http://blog.scottlowe.org/2012/11/27/connecting-ovs-bridges-with-patch-ports/ 上提到加了type=internal后这个虚拟接口才具备L3层的功能才可能添加ip,才可以做路由相关的事情。

   这下原因清楚了,但是上述使用linux bridge时的tap设备如何也让它也具有L3层功能呢?暂不清楚。

2014-10-31再次帮同事解决上述问题, 证明理论正确, ip和路由设置在bond网卡上时一定要添加type=internal, ip和路由设置在网桥时, bond网卡就不能添加type=internal属性


比如说,network-manager有bug,如果网卡都不由它来管理时会无法使用network-manager(这样依赖于它的一些vpn也无法启动),所以我们最好让eth0直接由network-manager来管理(这样不要在/etc/network/interface里添加和eth0相关的配置),如果又想用网桥,可以:

sudo ovs-vsctl addbr br-phy

sudo ovs-vsctl -- --may-exist add-port br-phy eth0 -- set interface eth0 type=internal

如果有多网卡,避免添加两个默认路由的问题,使用network-manager来管理其他网卡,令他们为manual模式。

auto eth1
iface eth1 inet manual

   

2014-10-25

        今天使用kvm创建了一个isolated的网络, 发现两台虚机无法ping通, 从物理机上ping一台虚机时偶尔能ping通, ping另一台时偶尔发生"Redirect Host(New nexthop"现象, 查了整整一天, 人都快要疯掉了, 原因是这两台虚机上两个网桥br-phy上的mac地址重复了.


2016-05-20

1, 执行“sudo apt-get install openvswitch-switch qemu-kvm libvirt-bin”之后自动产生了virbr0(192.168.122.0/24),而刚好MaaS产生的机器有一块网卡也为192.168.122.0/24从而造成网络不通。

2, 使用type=internal时(sudo ovs-vsctl -- --may-exist add-port br-phy eth0 -- set interface eth0 type=internal)会产生另外一个问题即ovs-ofctl命令无法运行(sudo ovs-ofctl dump-flows br-phy),可用命令sudo virsh net-destroy default去除.

ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-ofctl dump-flows br-phy
ovs-ofctl: br-phy: failed to connect to socket (Connection reset by peer)
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-vsctl del-port br-phy eth7
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-ofctl dump-flows br-phy
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=11533.961s, table=0, n_packets=20103, n_bytes=6910304, idle_age=3, priority=0 actions=NORMAL
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-ofctl dump-flows br-phy
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=11584.170s, table=0, n_packets=20125, n_bytes=6912276, idle_age=0, priority=0 actions=NORMAL
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-vsctl del-port br-phy eth7
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-vsctl -- --may-exist add-port br-phy eth7 -- set interface eth7 type=internal
ubuntu@duduo:/bak/openstack/devstack$ sudo ovs-ofctl dump-flows br-phy
ovs-ofctl: br-phy: failed to connect to socket (Connection reset by peer)