路由應該設定在網橋上，而不是虛擬網路卡上 ( by quqi99 )

路由應該設定在網橋上，而不是虛擬網路卡上 ( by quqi99 )

 

作者：張華  發表於：2013-04-13
版權宣告：可以任意轉載，轉載時請務必以超連結形式標明文章原始出處和作者資訊及本版權宣告

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

 

　　　　

　　　最近遇到一個問題，兩臺機器上的兩個網橋上的兩個tap裝置不能互通，查了半天，發現網橋上沒路由，而是設定到虛擬網路卡上了(eg: 從VM中不能ping host上的tap及閘道器, 也是因為VM裡的NIC被plug到了網橋中所致)。

　　　之前給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)