Isolating VM traffic using VLANs
Setup:
Two Physical Networks:
- Data Network: Ethernet network for VM data traffic, which will carry VLAN tagged traffic between VMs. Your physical switch(es) must be capable of forwarding VLAN tagged traffic and the physical switch ports should be VLAN trunks (Usually this is default behavior. Configuring your physical switching hardware is beyond the scope of this document).
- Management Network: This network is not strictly required, but it is a simple way to give the physical host an IP address for remote access, since an IP address cannot be assigned directly to eth0.
Two Physical Hosts:
Host1, Host2. Both hosts are running Open vSwitch. Each host has two NICs:
- eth0 is connected to the Data Network. No IP address can be assigned on eth0.
- eth1 is connected to the Management Network (if necessary). eth1 has an IP address that is used to reach the physical host for management.
Four VMs:
VM1,VM2 run on Host1. VM3,VM4 run on Host2.
Each VM has a single interface that appears as a Linux device (e.g., “tap0″) on the physical host. (Note: for Xen/XenServer, VM interfaces appears as Linux devices with names like “vif1.0″)
Goal:
Isolate VMs using VLANs on the Data Network.
VLAN 1: VM1,VM3
VLAN 2: VM2,VM4
Configuration:
Perform the following configuration on Host 1:
Create an OVS bridge:
ovs-vsctl add-br br0
Add eth0 to the bridge (by default, all OVS ports are VLAN trunks, so eth0 will pass all VLANs):
ovs-vsctl add-port br0 eth0
Add VM1 as an “access port” on VLAN 1:
ovs-vsctl add-port br0 tap0 tag=1
Add VM2 on VLAN 2:
ovs-vsctl add-port br0 tap1 tag=2
On Host 2, repeat the same configuration to setup a bridge with eth0 as a trunk:
ovs-vsctl add-br br0
ovs-vsctl add-port br0 eth0
Add VM3 to VLAN 1:
ovs-vsctl add-port br0 tap0 tag=1
Add VM4 to VLAN 2:
ovs-vsctl add-port br0 tap1 tag=2
Trouble-Shooting:
Ping from VM1 to VM3, this should succeed.
Ping from VM2 to VM4, this should succeed.
Ping from VM1/VM3 to VM2/VM4, this should not succeed (unless you have a router configured to forward between the VLANs, in which case, packets arriving at VM3 should have the source MAC address of the router, not of VM1).
sudo kvm --boot c -hda ./dns.img -smp 1 -m 384 -net nic,model=virtio,vlan=11 -net tap,vlan=11 -nographic -vnc :29 -usbdevice tablet
http://www.kuqin.com/shuoit/20140525/340126.html
我们先来回到一个最最熟悉不过的场景,我们的大学寝室,当时我们还买不起路由器,所以一般采取的方法如下图所示:
寝室长的机器上弄两张网卡,寝室买一个HUB,其他人的电脑都接到HUB上,寝室长的电脑的两张网卡一张对外连接网络,一张对内连接HUB。寝室长的电脑其实充当的便是路由器的作用。
后来条件好了,路由器也便宜了,所以很多家庭也是类似的拓扑结构,只不过将Computer1和switch合起来,变成了一个路由器,路由器也是有多个口一个连接WLAN,一个连接LAN。
图7
现在我们想象一个寝室变成了一台物理机Hypervisor,所有的电脑都变成了虚拟机,就成了下面的样子。
图8
我们先忽略qbr和DHCP Server,以及namespace。
br-int就是寝室里面的HUB,所有虚拟机都会连接到这个switch上,虚拟机之间的相互通信就是通过br-int来的。
Router就是你们寝室长的电脑,一边接在br-int上,一边接在对外的网口上,br-ex/eth0外面就是我们的物理网络。
为什么会有个DHCP Server呢,是同一个private network里的虚拟机得到IP都是通过这个DHCP Server来的,这个DHCP Server也是连接到br-int上和虚拟机进行通信。
如果有不同的Tenant,创建了不同的private network,为了在data network上对包进行隔离,创建private network的时候,需要指定vlanid或者segmentid。
从ovs-vsctl show我们可以看到,不同的tenant的private network上创建的虚拟机,连接到br-int上的时候是带tag的,所以不同tenant的虚拟机,即便连接到同一个br-int上,因为tag不同,也是不能相互通信的,然而同一个机器上的tag的计数是仅在本机有效的,并不使用我们创建private network的时候指定的全局唯一的vlanid或者segmentid,一个compute节点上的br-int上的tag 1和另一台compute节点上的br-int的tag1很可能是两码事。全局的vlanid和segmentid仅仅在br-int以下的虚拟网卡和物理网络中使用,虚拟机所有能看到的东西,到br-int为止,看不到打通br-int所要使用的vlanid和segmentid。
从局部有效的taging到全局有效的vlanid或者segmentid的转换,都是通过openvswitch的规则,在br-tun或者br-eth1上实现。