从虚拟机到虚拟交换
提到虚拟化,大家第一印象往往是虚拟机(Virtual Machine),VMware、Virtualbox,这些大名鼎鼎的虚拟机软件不少人都耳熟能详。对企业用户来说,虚拟技术最直接的好处是通过灵活配置资源、程序来高资源的利用率,从而降低应用成本。近些年,随着虚拟化技术、交换技术以及云计算服务的发展,虚拟交换(Virtual Switch)已经越来越多的引起人们的关注。
顾名思义,虚拟交换就是利用虚拟平台,通过软件的方式形成交换机部件。跟传统的物理交换机相比,虚拟交换机同样具备众多优点,一是配置更加灵活。一台普通的服务器可以配置出数十台甚至上百台虚拟交换机,且端口数目可以灵活选择。例如,VMware的ESX一台服务器可以仿真出248台虚拟交换机,且每台交换机预设虚拟端口即可达56个;二是成本更加低廉,通过虚拟交换往往可以获得昂贵的普通交换机才能达到的性能,例如微软的Hyper-V平台,虚拟机与虚拟交换机之间的联机速度轻易可达10Gbps。
虚拟交换与Open vSwitch
2008年底,思科发布了针对VMWare的Nexus 1000V虚拟交换机,一时之间在业界掀起不小的风头,并被评为当年虚拟世界大会的最佳新产品。或许思科已经习惯了“群星捧月”,此后很长一段时间里并没有见到正式的虚拟交换标准形成。除了惠普一年多以后提出了VEPA(虚拟以太网端口聚合器),其他厂家关注的多,做事的少。随着云计算跟虚拟技术的紧密融合,以及云安全的角度考虑,技术市场曲线已经到了拐点,业界已经迫切需要一套开放的VS标准,众多门派蠢蠢欲动。
烽烟即燃之际,Open vSwitch横空出世,以开源技术作为基础(遵循Apache2.0许可),由Nicira Networks开发,主要实现代码为可移植的C代码。它的诞生从一开始就得到了虚拟界大佬——Citrix System的关注。可能有读者对Citrix不熟,但说到Xen恐怕就是妇孺皆知了,没错,Citrix正是Xen的东家。OVS在2010年5月才发布1.0版本。而早在1月初Citrix就在其最新版本的开放云平台(ref[2])中宣布将Open vSwitch作为其默认组件,并在XenServer5.6 FP1中集成,作为其商用的Xen管理器(hypervisor)。除了Xen、Xen Cloud Platform、XenServer之外,支持的其他虚拟平台包括 KVM、VirtualBox等。
OVS官方的定位是要做一个产品级质量的多层虚拟交换机,通过支持可编程扩展来实现大规模的网络自动化。设计目标是方便管理和配置虚拟机网络,检测多物理主机在动态虚拟环境中的流量情况。针对这一目标,OVS具备很强的灵活性。可以在管理程序中作为软件switch运行,也可以直接部署到硬件设备上作为控制层。同时在Linux上支持内核态(性能高)、用户态(灵活)。此外OVS还支持多种标准的管理接口,如Netlow、sFlow、RSPAN,、ERSPAN, 、CLI。对于其他的虚拟交换机设备如VMware的vNetwork分布式交换机跟思科Nexus 1000V虚拟交换机等它也提供了较好的支持。
目前OVS的官方版本为1.1.0pre2,主要特性包括
■虚拟机间互联的可视性;
■支持trunking的标准802.1Q VLAN模块;
■细粒度的QoS;
■每虚拟机端口的流量策略;
■负载均衡支持OpenFlow (参考openflow–打造弹性化的可控互联网)
■远程配置兼容Linux 桥接模块代码
OVS获取
由于是开源项目,代码获取十分简单,最新代码可以利用git从官方网站下载。此外官方网站还提供了比较清晰的文档资料和应用例程,其部署十分轻松。当前最新代码包主要包括以下模块和特性:
■ovs-vswitchd 主要模块,实现switch的daemon,包括一个支持流交换的Linux内核模块;
■ovsdb-server 轻量级数据库服务器,提供ovs-vswitchd获取配置信息
■ovs-brcompatd 让ovs-vswitch替换Linux bridge,包括获取bridge ioctls的Linux内核模块;
■ovs-dpctl 用来配置switch内核模块;
■一些Scripts and specs 辅助OVS安装在Citrix XenServer上,作为默认switch;
■ovs-vsctl 查询和更新ovs-vswitchd的配置;
■ovs-appctl 发送命令消息,运行相关daemon;
■ovsdbmonitor GUI工具,可以远程获取OVS数据库和OpenFlow的流表。
此外,OVS也提供了支持OpenFlow的特性实现,包括
■ovs-openflowd 一个简单的OpenFlow交换机;
■ovs-controller 一个简单的OpenFlow控制器;
■ovs-ofctl 查询和控制OpenFlow交换机和控制器;
■ovs-pki 为OpenFlow交换机创建和管理公钥框架;
■tcpdump的补丁,解析OpenFlow的消息;
结语
IT领域可以称得上是人类历史上最开放创新,也是最容易垄断的行业。PC行业,wintel帝国曾塑造了不朽的神话,证明谁控制了cpu跟os,谁就控制了话语权,只要PC的软硬件模式不发生革命性变化,wintel帝国的地位将是无人能撼的。后起之秀ARM借助重视能耗的东风,再加上智能终端技术的大发展才展露头角。而在互联网界,思科更是首先把握住了最核心的交换市场,早早登上至尊之位,即使是步后尘的juniper、huawei也只能是虎口夺食,各凭绝技分天下。现在虚拟交换技术的提出将给这一领域带来新的契机,究竟鹿死谁手,更待后人评说。
计算,存储,网络,安全,是构建任何大型数据中心都绕不过去的四个问题。云也不例外。在这个风起云涌的云时代,各厂商赛马般发布层出不穷的新技术,着实让我们目不暇接。很多人昨天刚玩过Xen,今天看到Redhat宣称KVM是其新的战略方向,又忍不住把KVM拿来折腾一番。大家习惯性地把注意力都放在了“计算”上,积累了不少“服务器虚拟化”的经验,却不知不觉冷落了其余三个方面。国外同行们热议Software Defined Network(SDN)和OpenFlow这些因为云而瞬间火爆的技术时,我们还卯足了劲儿一头扎进服务器虚拟化中不愿出来。
搜索了一下,网络上关于“网络虚拟化”的文章很少。工作关系长期接触这方面技术,不敢私藏,拿出来跟大家分享一下。水平有限,纯属抛砖引玉,大家扔砖头时轻一点。欢迎讨论,欢迎站短,欢迎邮件 cloudbengo@gmail.com
什么是Open vSwitch?它能给云带来什么?
官网首页精炼地回答了这个问题:(翻译自http://openvswitch.org/)
Open vSwitch的目标,是做一个具有产品级质量的多层虚拟交换机。通过可编程扩展,可以实现大规模网络的自动化(配置、管理、维护)。它支持现有标准管理接口和协议(比如netFlow,sFlow,SPAN,RSPAN,CLI,LACP,802.1ag等,熟悉物理网络维护的管理员可以毫不费力地通过Open vSwitch转向虚拟网络管理)。
图一:Open vSwitch示意图
官网的描述精准而抽象,来点通俗的,Open vSwitch是一个由Nicira Networks主导的开源项目,通过运行在虚拟化平台上的虚拟交换机,为本台物理机上的VM提供二层网络接入, 跟云中的其它物理交换机一样工作在Layer 2层。Open vSwitch充分考虑了在不同虚拟化平台间的移植性,采用平台无关的C语言开发。最为人民群众喜闻乐见的是,它遵循Apache2.0许可,不论你是自用还是商用都OK。而它的同类产品VMware的vDS(vSphere Distributed VirtualSwitch),Cisco的Nexus 1000V都是收费的。更重要的是,虽然免费,其产品质量却深得信赖。在2010年Open vSwitch 1.0.0发布之前,Citrix就宣布在XenServer中将其作为默认组件。关于这一点,也许Nicira的身世可以给出一些解释,它的投资人里有Diane Greene(VMware联合创始人)和Andy Rachleff(Benchmark Capital联合创始人),经常听朋友谈起的几个VMware网络大牛也加盟其中,是目前硅谷最炙手可热的SDN创业公司之一。
既然Citrix的企业级虚拟化产品都装备了Open vSwitch,我们还有什么理由怀疑它的可靠性呢?更何况它还是开源的!
你可能会问,我为什么有必要在自己的云架构中使用它呢?它能给我的云带来什么?
OK。需求决定一切,如果你只是自己搞一台Host,在上面虚拟几台VM做实验。或者小型创业公司,通过在五台十台机器上的虚拟化,创建一些VM给公司内部开发测试团队使用。那么对你而言,网络虚拟化的迫切性并不强烈。也许你更多考虑的,是VM的可靠接入:和物理机一样有效获取网络连接,能够RDP访问。Linux Kernel自带的桥接模块就可以很好的解决这一问题。原理上讲,正确配置桥接,并把VM的virtual nic连接在桥接器上就OK啦。很多虚拟化平台的早期解决方案也是如此,自动配置并以向用户透明的方式提供虚拟机接入。如果你是OpenStack的fans,那Nova就更好地帮你完成了一系列网络接入设置。Open vSwitch在WHY-OVS这篇文章中,第一句话就高度赞扬了Linux bridge:
“We love the existing network stack in Linux. It is robust, flexible, and feature rich. Linux already contains an in-kernel L2 switch (the Linux bridge) which can be used by VMs for inter-VM communication. So, it is reasonable to ask why there is a need for a new network switch.”
但是,如果你是大型数据中心的网络管理员,一朵没有网络虚拟化支持的云,将是无尽的噩梦。
在传统数据中心中,网络管理员习惯了每台物理机的网络接入均可见并且可配置。通过在交换机某端口的策略配置,可以很好控制指定物理机的网络接入,访问策略,网络隔离,流量监控,数据包分析,Qos配置,流量优化等。
有了云,网络管理员仍然期望能以per OS/per port的方式管理。如果没有网络虚拟化技术的支持,管理员只能看到被桥接的物理网卡,其上川流不息地跑着n台VM的数据包。仅凭物理交换机支持,管理员无法区分这些包属于哪个OS哪个用户,只能望云兴叹乎?简单列举常见的几种需求,Open vSwitch现有版本很好地解决了这些需求。
需求一:网络隔离。物理网络管理员早已习惯了把不同的用户组放在不同的VLAN中,例如研发部门、销售部门、财务部门,做到二层网络隔离。Open vSwitch通过在host上虚拟出一个软件交换机,等于在物理交换机上级联了一台新的交换机,所有VM通过级联交换机接入,让管理员能够像配置物理交换机一样把同一台host上的众多VM分配到不同VLAN中去;
需求二:QoS配置。在共享同一个物理网卡的众多VM中,我们期望给每台VM配置不同的速度和带宽,以保证核心业务VM的网络性能。通过在Open vSwitch端口上,给各个VM配置QoS,可以实现物理交换机的traffic queuing和traffic shaping功能。
需求三:流量监控,Netflow,sFlow。物理交换机通过xxFlow技术对数据包采样,记录关键域,发往Analyzer处理。进而实现包括网络监控、应用软件监控、用户监控、网络规划、安全分析、会计和结算、以及网络流量数据库分析和挖掘在内的各项操作。例如,NetFlow流量统计可以采集的数据非常丰富,包括:数据流时戳、源IP地址和目的IP地址、 源端口号和目的端口号、输入接口号和输出接口号、下一跳IP地址、信息流中的总字节数、信息流中的数据包数量、信息流中的第一个和最后一个数据包时戳、源AS和目的AS,及前置掩码序号等。
xxFlow因其方便、快捷、动态、高效的特点,为越来越多的网管人员所接受,成为互联网安全管理的重要手段,特别是在较大网络的管理中,更能体现出其独特优势。
没错,有了Open vSwitch,作为网管的你,可以把xxFlow的强大淋漓尽致地应用在VM上!
需求四:数据包分析,Packet Mirror。物理交换机的一大卖点,当对某一端口的数据包感兴趣时(for trouble shooting , etc),可以配置各种span(SPAN, RSPAN, ERSPAN),把该端口的数据包复制转发到指定端口,通过抓包工具进行分析。Open vSwitch官网列出了对SPAN, RSPAN, and GRE-tunneled mirrors的支持。
关于具体功能,就不一一赘述了,感兴趣的童鞋可以参考官网功能列表:http://openvswitch.org/features/
只是在Open vSwitch上实现物理交换机的现有功能?那绝对不是Nicira的风格。
云中的网络,绝不仅仅需要传统物理交换机已有的功能。云对网络的需求,推动了Software Defined Network越来越火。而在各种SDN解决方案中,OpenFlow无疑是最引人瞩目的。Flow Table + Controller的架构,为新服务新协议提供了绝佳的开放性平台。Nicira把对Openflow的支持引入了Open vSwitch。引入以下模块:
· ovs-openflowd --- OpenFlow交换机;
· ovs-controller --- OpenFlow控制器;
· ovs-ofctl --- Open Flow 的命令行配置接口;
· ovs-pki --- 创建和管理公钥框架;
· tcpdump的补丁 --- 解析OpenFlow的消息;
不再展开,大家感兴趣的话可以Google之。
图2 :Open Flow示意图 -- 摘自Open Flow白皮书
需求决定产品,正是由于在企业级云中,需要各种丰富的网络功能,VMware才于n年前就推出了vSwitch、vDS等虚拟交换机。正是看到了云中的网络是一块大市场,Cisco才与VMware紧密合作,以partner的形式基于VMware kernel API开发出了自己的分布式虚拟交换机Nexus 1000V(功能对应于VMware的vDS)。可惜的是,这两款产品都是收费的。Citrix倒是基于Open vSwitch快速追赶,推出了自己的Distributed Virtual Switch解决方案。但是不好意思,也是收费的。开源云的标杆OpenStack去年下半年推出了一项宏大的计划,启动了Quantum项目,志在通过引入Open vSwitch,为Open Stack Network模块勾勒出“Connectivity as a service”的动人前景。有时间的话,会再单独开一篇文章讨论。
感谢开源,Open vSwitch是坐公交车的成本,进口跑车的体验!还等什么,在你的大型开源云架构中,使用Open vSwitch吧!
(目前网上关于云环境中网络虚拟化的中文文章比较少,抛砖引玉一下,欢迎大家拍砖,欢迎留言提问或质疑,关于OVS,SDN,OpenFlow都行,大家在讨论中一起进步)
本文出自 “CloudEra” 博客,请务必保留此出处http://bengo.blog.51cto.com/4504843/791213
Open vSwitch:您可以使用开放源码分布式虚拟交换吗?
Open vSwitch发布了Cisco Nexus 1000v开放源码替代方案——是一种针对多租赁公共云计算环境优化的软件交换。Open vSwitch使管理员几乎能够对所有环境上的虚拟机(VM)及其之间运行的流量进行监控和精细控制——但是它还不支持VMware和Microsoft Hyper-V技术。
Open vSwitch项目是由新兴的网络控制软件公司Nicira Networks支持的,它提供了可下载的基于Apache 2授权的开放源码虚拟交换代码。虽然它目前只支持 Xen、XenServer、KVM和VirtualBox,但它可以迁移到其它的虚拟化环境上。
类似于vSphere中使用的Nexus 1000v,Open vSwitch解决了每一个网络人员关心的虚拟化问题:无法控制数据流和不支持VM之间的其它核心网络服务。Open vSwitch与网络控制器软件一起可以实现分布式虚拟交换功能。这意味着交换机和控制器软件能够创建在多个服务器中使用的集群级网络配置,从而不需要为每一个VM和物理主机配置网络。这种交换技术也支持VLAN中继;通过NetFlow、sFlow和RSPAN实现可见性;以及使用OpenFlow协议实现管理。
Open vSwitch的支持者——包括将在下一个版本的XenServer中支持这种交换技术的Citrix——认为它比Cisco Nexus 1000v做得更好,它实现了一种云环境的多租赁网络所需要的精细路由和管理功能。多租赁网络通过将网络的虚拟化实例分割成单独的部分来保存客户数据或应用,从而避免资源混杂。
“ 使用Open vSwitch,我们就能够将真实基础架构的VLAN扩展为虚拟的VLAN,这样客户就可以单独拥有各自的VLAN,”云集成商Telivo Managed Services的董事长兼COO John Galgay说。Telivo在它的虚拟化中使用的是Xen和KVM,所以它无法使用不开放的Cisco Nexus 1000v。
用于远程管理的OpenFlow协议和Open vSwitch
Open vSwitch实现的严密流量控制很大部分上是通过OpenFlow交换协议实现的。OpenFlow使网络控制器软件能够通过网络访问一个交换机或路由器的数据路径。网络管理员可以使用这个技术在一台PC上远程控制数据管理,这样他们就能够进行精细的路由和交换控制,并实现复杂的网络策略。
有了Open vSwitch中的这些远程管理功能,多租赁云计算的集成商和供应商就能够向客户提供在一台PC上持续管理各自虚拟网络、应用和策略的功能。
“VMware或XenServer拥有更类似于桥接而不是交换的网络功能,”Citrix CTO Simon Crosby说。通过Open vSwitch,用户可以“弯曲虚拟线路”,创建他们自己的流量流和策略,他补充说。
网络控制软件和开放源码虚拟交换
Open vSwitch很大程度上是依赖于与网络控制器软件的整合,它主要监控和控制数据流,并协调虚拟化环境中的网络策略。Nicira是Open vSwitch项目的支持者,它是这个领域的先行者之一。虽然这个公司并没有准备用这个开放源码虚拟交换来获取收益,但是它希望籍此为其新的控制器软件创造“一个网络机会”,Nicira的交换技术主管Justin Pettit说道。
虽然Nicira还处于保密阶段,但是它已经开发了一个软件服务器,它通过连接每一个Open vSwitch来协调VM之间的策略。
“XenServer有一个协议Xapi,它负责[VM]迁移。当VM迁移时,Xapi会通知我们,但是这里的资源开销是很大的。[相反]我们监控所有的网络脚本,这样当我们的虚拟接口出现在一个系统时,[它]会发送一个消息给我们的控制器,”Pettit解释说。
开放源码的虚拟交换技术可以在企业网络中使用吗?
Open vSwitch或许前景很好,但是正如一位来自大型金融公司的网络工程师所说,“不支持VMware是一个很大的问题。”
那么这个开放源码虚拟交换技术将来可以在vSphere中使用吗?
Pettit说,技术上,VMware采用和支持Open vSwitch并不存在任何问题,但是很可能还有很长的路要走。事实上,现在还没有任何的官方讨论。
而且网络供应商也不太可能销售Open vSwitch产品,甚至还不太可能开发Open vSwitch产品,因为“他们还没有进行任何的商品化行动,”Ashton Metzler & Associates的分析师Jim Metzler说。
但是,XenServer确定会使用这个技术。现在,是否进一步地开发这个交换技术取决于Nicira等公司,Metzler说。
“这个项目需要得到一些开放源码支持才能进一步向前发展,”他说,“我很期待Nicira会是其中一个支持者。”
添加名为br0的网桥
ovs-vsctl add-br br0
删除名为br0的网桥
ovs-vsctl del-br br0
列出所有网桥
ovs-vsctl list-br
判断网桥br0是否存在
ovs-vsctl br-exists br0
列出挂接到网桥br0上的所有网络接口
ovs-vsctl list-ports br0
将网络接口eth0挂接到网桥br0上
ovs-vsctl add-port br0 eth0
删除网桥br0上挂接的eth0网络接口
ovs-vsctl del-port br0 eth0
列出已挂接eth0网络接口的网桥
ovs-vsctl port-to-br eth0
网桥管理(ovsdb数据库操作)
数据库操作的一般格式为:
ovs-vsctl list/set/get/add/remove/clear/destroy table record column [value]
默认情况下ovsdb中有以下数据表:
bridge, controller,interface,mirror,netflow,open_vswitch,port,qos,queue,ssl,sflow
即table可为上面的任一个。record为数据表中name字段的值,column为数据表任一个字段的字段名,value字段值。
基本操作:
查看bridge数据表中的所有记录
获得bridge数据表_uuid字段的值
设置bridge数据表datapath_type字段的值
清除bridge数据表flood_vlans字段的值
ovs-vsctl remove bridge xenbr0 flood_vlans 23
或者
ovs-vsctl clear bridge xenbr0 flood_vlans
删除uuid为69ee0c09-9e52-4236-8af6-037a98ca704d的qos记录
ovs-vsctl destroy qos 69ee0c09-9e52-4236-8af6-037a98ca704d
应用场景设置:
QoS设置
针对网络接口的设置:设置网络接口vif0.0的带宽为1000±100kbps
ovs-vsctl set interface vif0.0 ingress_policing_rate=1000
ovs-vsctl set interface vif0.0 ingress_policing_burst=100
(ingress_policing_rate:最大发送速率(单位均为kbps)
ingress_policing_burst:超过ingress_policing_rate的最大浮动值)
针对交换机端口的设置:创建在vif0.0端口上的linux-htb QoS,linux-htb QoS可以针对具有指定特征的数据包流设置最大最小带宽,且在最大带宽范围内,某一特征的数据包流可以借用其他特征数据包流未用完的带宽。
ovs-vsctl -- set port vif0.0 qos=@newqos
-- --id=@newqos create qos type=linux-htb other-config:
max-rate=100000000 queues=0=@q0,1=@q1
-- --id=@q0 create queue other-config:min-rate=100000000 other-config:max-rate=100000000
-- --id=@q1 create queue other-config:min-rate=500000000
将带宽限制加于某特征数据包流上
(假设vif0.0的接在交换机1号端口上,ovs-ofctl命令的使用见2.2.3)
ovs-ofctl add-flow xenbr0 "in_port=2,idle_timeout=0,actions=enqueue:1:0"
端口映射
将发往eth0端口和从eth1端口发出的数据包全部定向到eth2端口
(假设eth0、eth1、eth2端口的uuid分别为:
69ee0c09-9e52-4236-8af6-037a98ca704d
69ee0c09-9e52-4236-8af6-037a98ca704e
69ee0c09-9e52-4236-8af6-037a98ca704f
端口的uuid可以通过ovs-vsctl list port命令查看)
ovs-vsctl -- set bridge xenbr0 mirrors=@m
-- --id=@m create mirror name=mymirror
select-dst-port=69ee0c09-9e52-4236-8af6-037a98ca704d
select-src-port=69ee0c09-9e52-4236-8af6-037a98ca704e
output-port=69ee0c09-9e52-4236-8af6-037a98ca704f
流规则管理
流规则组成
每条流规则由一系列字段组成,分为基本字段、条件字段和动作字段三部分:
基本字段包括生效时间duration_sec、所属表项table_id、优先级priority、处理的数据包数n_packets,空闲超时时间idle_timeout等,空闲超时时间idle_timeout以秒为单位,超过设置的空闲超时时间后该流规则将被自动删除,空闲超时时间设置为0表示该流规则永不过期,idle_timeout将不包含于ovs-ofctl dump-flows brname的输出中。
条件字段包括输入端口号in_port、源目的mac地址dl_src/dl_dst、源目的ip地址nw_src/nw_dst、数据包类型dl_type、网络层协议类型nw_proto等,可以为这些字段的任意组合,但在网络分层结构中底层的字段未给出确定值时上层的字段不允许给确定值,即一条流规则中允许底层协议字段指定为确定值,高层协议字段指定为通配符(不指定即为匹配任何值),而不允许高层协议字段指定为确定值,而底层协议字段却为通配符(不指定即为匹配任何值),否则,ovs-vswitchd 中的流规则将全部丢失,网络无法连接。
动作字段包括正常转发normal、定向到某交换机端口output:port、丢弃drop、更改源目的mac地址mod_dl_src/mod_dl_dst等,一条流规则可有多个动作,动作执行按指定的先后顺序依次完成。
基本操作
查看虚拟交换机xenbr0的信息
显示的xenbr0信息中网络接口名称前的数字为该网络接口挂接到Open vSwitch上的端口号,如1(vif0.0): 中的1为网络接口vif0.0对应的端口号,在添加包含in_port字段的流规则时可通过该命令查看网络接口对应的端口号。
查看xenbr0上各交换机端口的状态
输出的结果中包含了各网络接口上收到的数据包数,字节数,丢包数,错误数据包数等信息
查看xenbr0上的所有流规则
输出结果中共有两条流规则,第一条为默认的流规则,即对所有数据包进行正常转发,为普通二层交换机完成的功能,优先级为0,最低,永不超时。
第二条为手动添加的流规则,基本字段中不包含idle_timeout字段,表示永不超时,优先级为32768,Open vSwitch将先根据该条流规则处理收到的数据包,如从数据包中提取出的特征与条件字段不符,则该用第一条流规则处理收到的所有数据包。
添加一条流规则:丢弃从2号端口发来的所有数据包
删除一条流规则:删除条件字段中包含in_port=2的所有流规则
流规则中可包含通配符和简写形式,任何字段都可等于*或ANY,如:
丢弃所有收到的数据包
ovs-ofctl add-flow xenbr0 dl_type=*,nw_src=ANY,actions=drop
简写形式为将字段组简写为协议名,目前支持的简写有ip,arp,icmp,tcp,udp,与流规则条件字段的对应关系如下:
dl_type=0x0800dl_type=0x0806
dl_type=0x0800,nw_proto=1
dl_type=0x0800,nw_proto=6
dl_type=0x0800,nw_proto=17
(1.1.0 即以后版本支持)
dl_type=0x86dd.
dl_type=0x86dd,nw_proto=6.
dl_type=0x86dd,nw_proto=17.
dl_type=0x86dd,nw_proto=58.
应用场景设置
网站屏蔽
屏蔽由Open vSwitch管理的任何主机对主机119.75.213.50的访问,但只屏蔽ip数据包(由dl_type=0x0800指定),即所有主机将无法访问该主机上所有基于IP协议的服务,如万维网服务、FTP访问等
ovs-ofctl add-flow xenbr0 idle_timeout=0,dl_type=0x0800,nw_src=119.75.213.50,actions=drop
数据包重定向
将交换机中所有的icmp协议包(有dl_type=0x0800,nw_proto=1指定)全部转发到4号端口,包括4号端口自己发出的icmp包,该流规则将导致由Open vSwitch管理的主机间以及与外部网络间都将访问ping通,但可以使用万维网、FTP等服务。
ovs-ofctl add-flow xenbr0 idle_timeout=0,dl_type=0x0800,nw_proto=1,actions=output:4
去除VLAN tag
去除从3号端口发来的所有VLAN数据包中的tag,然后转发
ovs-ofctl add-flow xenbr0 idle_timeout=0,in_port=3,actions=strip_vlan,normal
更改数据包源IP地址后转发
将从3号端口收到的所有IP包的源IP字段更改为211.68.52.32
ovs-ofctl add-flow xenbr0 idle_timeout=0,in_port=3,actions=mod_nw_src:211.68.52.32,normal
内核模块中flow操作
查看内核模块flow
ovs-dpctl dump-flows xenbr0
后台模块控制,如日志系统、后台模块退出
查看后台模块支持的appctl命令
查看ovsdb-server支持的appctl命令,ovs-appctl必须在后台模块运行后才能针对后台模块使用,默认情况下,所有运行的后台模块都会在/usr/local/var/run/openvswitch/目录下创建一个与ovs-appctl通信的socket文件
更改Open vSwitch各后台的模块的日志级别
更改ovs-vswitchd模块的日志级别info,“ANY:ANY:info”中的前一个“ANY”代表ovs-vswitchd中的任何模块组件,“ovs-appctl --target=/usr/local/var/run/openvswitch/
ovs-vswitchd.29384.ctl vlog/list”命令输出的第一列将为ovs-vswitchd包含的所有模块组件。“ANY:ANY:info”中的后一个“ANY”代表日志的任何方式的输出,日志的输出方式有三种,分别为:console,syslog,file,分别代表将日志输出到控制台、写入到系统日志系统和写入到ovs-vswitchd启动时由—log-file参数指定的文件。“ANY:ANY:info”中的“info”表示日志级别,共有emer、err、warn、info、dbg五个日志级别,dbg为最低级别,指定为dbg时,所有的日志信息都将输出,但此时可能导致日志系统迅速膨胀,而占用越来越多的硬盘存储空间。
ovs-appctl --target=/usr/local/var/run/openvswitch/ovs-vswitchd.29384.ctl vlog/set
ANY:ANY:info
退出后台模块
让ovs-vswitchd停止运行
ovs-appctl --target=/usr/local/var/run/openvswitch/ovs-vswitchd.29384.ctl exit
启动NOX控制台:
./nox_core -v -i ptcp:6633 pyswitch
1. 加载open vswitch 模块:
insmod datapath/linux-2.6/openvswitch_mod.ko
2. 增加一条数据通路:
ovs-dpctl add-dp dp0
3. 将该数据通路与接口进行关联
ovs-dpctl add-if dp0 eth0
4. 查看关联状态,看是否关联成功
ovs-dpctl show dp0
5. 启动TCP,连接NOX控制台,默认端口为6633,192.168.0.2是NOX所在主机IP
ovs-openflowd dp0 tcp:192.168.0.2
如果网络连接是通的,则vswitch能够正常连接NOX。
看了 open vswitch 也有一陣子了,斷斷續續也在自己的 wiki 上亂寫了一些東西,但是一直覺得自己不夠熟,也不知道從哪裡開始整理,先在這寫一些概念性的解釋…
官方資料內有一個關於 porting 的文件,裡面畫了實作上的一些抽象元件,幫助你決定要移植 ovs 時,要改寫哪個部份,如下圖。一開始看這張圖應該會有點霧煞煞,對 ovs 的很多概念還不熟悉,不知道從哪裡開始瞭解,看完文件的解釋還是不太懂。
| +-------------------+ | | ovs-vswitchd |<-->ovsdb-server | +-------------------+ | | ofproto |<-->OpenFlow controllers | +--------+-+--------+ _ | | netdev | |ofproto-| | userspace | +--------+ | dpif | | | | netdev | +--------+ | | |provider| | dpif | | | +---||---+ +--------+ | | || | dpif | | implementation of | || |provider| | ofproto provider |_ || +---||---+ | || || | _ +---||-----+---||---+ | | | |datapath| | kernel | | +--------+ _| | | | |_ +--------||---------+ || physical NIC
我自己則是從他安裝完所提供的各種工具與重要背景服務的角度開始,由此開始熟悉 ovs 的概念,感覺這是一個比較好的入門點。我畫了一張類似的圖。
+---------+ +----------+ +---------+ +---------+ |ovs-ofctl| |ovs-appctl| |ovs-vsctl| |ovs-dpctl| +---------+ +----------+ +---------+ +---------+ ^ ^ USER SPACE TOOLS ^ ^ +-------|-------|------------------|-- --------|----+ v v v | +--------------+ +----------------+ | | | | | | | ovs-vswitchd | <---> | ovsdb-server | | | | | | | +--------------+ +----------------+ | ^ USER SPACE DAEMONS | +----------|-----------------------------------|----+ v KERNEL SPACE v +------------------------------------------+ | | | datapath | | | +------------------------------------------+
datapath – openvswitch_mod.so 當 ovs 以 kernel 模組運作時在核心中的單元,主要處理在核心交換封包到各介面的工作。datapath 應該也能當作 vswitch 在 kernel 中的 instance,可以有好幾個 datapath 。
USER SPACE DAEMONS - 開啟 ovs 需要啟動的兩個背景程式
- ovsdb-server:用來儲存所有 ovs 設定資料的簡易資料庫,設定完會看情況通知 datapath(kernel)同步狀態,統計資料也會存在這 。所有能設定的欄位跟解釋都在這份文件內。
- ovs-vswitchd:用來跟 openflow 控制器溝通與 ovsdb 溝通。可以讓你設定你的 vswitch 要跑在什麼模式。
USER SPACE TOOLS:
- ovs-vsctl : 對 ovsdb 操作,操作指令比較具有語意,會幫你轉化成 ovsdb 看的懂的語法,例如建立 bridge、指定 bridge port 的對應、設定 Bridge Port Interface etc
- ovs-dpctl : 管理 datapath 的工具,大部分資訊都是透過 netlink 反應出 datapath 目前的狀態,也可以直接操作 datapath 中目前的 flow。
- ovs-ofctl : openflow switch 管理工具,可以操作與 openflow 相關的設定,是設定 ovs-vswitchd 的不是 datapath 的。在這裡設定一些靜態的 flow 之後會被轉化更實體的 flow 同步到 datapath 中。例如預設的 flow 是 rule=*,action=normal,就是把 ovs-vswitchd 當成一個 learning switch。設了 controller 以後就是讓 flow 再間接去問控制器,再從控制器產生 flow 存放到 ovs-vswitchd 內,ovs-dpctl 跟 ovs-ofctl 都可以用 dump-flows 印 flows 出來看 。
- ovs-appctl : ovs-vswithd 的管理工具,可以跟 ovs-vswitchd 程序溝通,所以要指定的是 ovs-vswitchd 的 pid。例如可以用來印出 forwarding table。