Open vSwitch流表应用实战

写在前面


本随笔参考

  • 学会了如何下发流表及删除流表的操作。
  • 第一个不用脚本的实验。

实验原理


  • 在SDN环境下,当交换机收到一个数据包并且交换机中没有与该数据包匹配的流表项时,交换机将此数据包发送给控制器,由控制器决策数据包如何处理。
  • 控制器下发决策后,交换机根据控制器下发的信息来进行数据包的处理,即转发或者丢弃该数据包。我们可以通过对流表操作来控制交换机的转发行为。

实验任务


  • Mininet创建一个默认树形拓扑。
  • 选择Mininet的控制器指定为ODL,进行基本的添加、删除流表操作,使网络实现网络通信和不通信。
  • 拓扑如下所示:

实验步骤


Opendaylight控制器

  • 打开一个终端,输入ifconfig,查看ODL所在IP为127.0.0.1(环回IP)。
  • 进入bin目录下,运行karaf文件。

Mininet创建topo

  • sudo su进入管态。
  • 输入命令mn --controller=remote,ip=127.0.0.1,port=6633

  • Mininet或默认创建一个交换机下挂两台主机的topo。

流表的简单操作

  • 输入sh ovs-ofctl dump-flows s1,查看s1中的流表项。

  • 输入pingall查看主机之间连通性。

  • 这时我们再查看s1中的流表项时,会发现多出两条由Controller下发的流表项。
  • Controller学习了h1h2的MAC地址后下发的流表。

我们看到每条流规则由一系列字段组成,它们由基本字段、条件字段和动作字段三部分组成。有了流表后交换机就根据流表来进行数据包的操作,当然我们也可以人工的进行流表的新增、修改、删除操作,在我们这个环境下可直接在终端下输入命令。

添加删除流表项

  • 我们想让h1,h2之间ping不通,只需要让交换机把从2号端口发来的数据包全部丢弃即可,1端口也可以。
  • h1即使把ICMP包发过去,h2回应的ICMP包也过不来。
  • h2h1发送ICMP包根本发不过去。
  • 下发一条流表实现上述功能:
sh ovs-ofctl add-flow s1 priority=12,in_port=2,actions=drop
  • 注意:这条流表项的优先级要高于原来流表项的优先级10
  • 增加这条流表以后,h1h2主机之间无法通信了。

  • 输入sh ovs-ofctl dump-flows s1,查看s1中的流表项。

  • 再删除一条流规则:如将删除条件字段中包含in_port=2的所有流表,如下图所示,将含有in_port=2的所有流表被删除了。
sh ovs-ofctl del-flows s1 in_port=2
  • 因为之前添加的丢弃2号端口包的流表已被删除,这时h1h2又可以正常通信了。

  • 输入sh ovs-ofctl dump-flows s1,查看s1中的流表项。

实验小结


主要是对OpenFlow流表有更进一步的了解,简略介绍一些基本的流表操作。在此基础上可以进行比如改写源和目地主机的ip和mac地址、对数据包泛洪、回环等操作,用户可以根据需求通过修改流表来自主地控制转发行为,这本身也是SDN的初衷之一,也使得我们控制网络更加的便捷、灵活、多样。

原文地址:https://www.cnblogs.com/031602523liu/p/9037671.html

时间: 2024-10-01 06:45:26

Open vSwitch流表应用实战的相关文章

ovs源码阅读--流表查询原理

segmentfault对应博文:https://segmentfault.com/a/1190000016112493 背景 在ovs交换机中,报文的处理流程可以划分为一下三个步骤:协议解析,表项查找和动作执行,其中最耗时的步骤在于表项查找,往往一个流表中有数目巨大的表项,如何根据数据报文的信息快速的查找到对应的流表项是ovs交换机的一个重要的功能. 在openflow协议中,支持多级流表的形式,可以类比于将一个复杂的功能进行打散,分解成过个小的功能,实现一个流水线的功能,具体见下图: 上图中

Neutron 理解 (4): Neutron OVS OpenFlow 流表 和 L2 Population [Netruon OVS OpenFlow tables + L2 Population]

学习 Neutron 系列文章: (1)Neutron 所实现的虚拟化网络 (2)Neutron OpenvSwitch + VLAN 虚拟网络 (3)Neutron OpenvSwitch + GRE/VxLAN 虚拟网络 (4)Neutron OVS OpenFlow 流表 和 L2 Population (5)Neutron DHCP Agent (5)TBD OVS bridge 有两种模式:“normal” 和 “flow”.“normal” 模式的 bridge 同普通的 Linux

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(8)

问题导读: 1.怎样使用arp_responder ? 2.怎样搭建l2pop环境? 3. ARP Responder arp_responder 的原理不复杂.Neutorn DB 中保存了所有的端口的 MAC 和 IP 地址数据.而 ARP 就是一个虚机要根据另一个虚机的 IP 地址查询它的 MAC.因此,只需要 Neutron server 通过 RPC 告诉每个计算节点上的 ML2 agent 所有活动端口的 MAC 和 IP,那么就可以将 br-tun 变成一个供本机适用的 ARP P

Neutron系列 : Neutron OVS OpenFlow 流表 和 L2 Population(7)

http://www.aboutyun.com/forum.php?mod=viewthread&tid=16563&highlight=neutron%2B%2B%CF%B5%C1%D0 问题导读: 1.OVS bridge有几种模式?2.Neutron 中的流表是怎样实现的? OVS bridge 有两种模式:“normal” 和 “flow”.“normal” 模式的 bridge 同普通的 Linux 桥,而 “flow” 模式的 bridge 是根据其流表(flow tables

OVS中arp响应的流表的实现

总结: 1.br-int 流表总体是按照Normal 的方式,即常规的交换机的转发方式进行转发.而br-tun 交换机则主要按照流表的方式进行转发. 2.一般情况下,VM发出的ARP请求,会在该VM的所有邻居进行广播发送和查找,大量浪费带宽.当neutron开启了l2 pop后(二次注入功能), 计算节点会学习别的主机发送的免费ARP, 从而在本地存在ARP表项. 3.当本地的VM发出ARP请求时,br-tun交换机会优先查找本地的ARP表项,从而对报文进行ARP应答. 这样的话,就不用发出AR

ryu的RESTAPI简介——我主要用于下发和查看流表

一.Rest API简介 REST即表述性状态传递(RepreSentational State Transfer),是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性. 表述性状态转移是一组构架约束条件和原则,满足这些约束和原则的应用程序或设计就是RESTful,REST是设计风格而不是标准,它通常基于使用HTTP,URI,XML以及HTML这些现有的广泛流行的协议和标准. REST定义了一组体系构架原则,可以根据这些原则设计以系统资源为中心的Web服务,包括使用不同

Openvswitch原理与代码分析(6):用户态流表flow table的操作

当内核无法查找到流表项的时候,则会通过upcall来调用用户态ovs-vswtichd中的flow table. 会调用ofproto-dpif-upcall.c中的udpif_upcall_handler函数. static void * udpif_upcall_handler(void *arg) { ????struct handler *handler = arg; ????struct udpif *udpif = handler->udpif; ? ????while (!latc

Openvswitch原理与代码分析(5): 内核中的流表flow table操作

? 当一个数据包到达网卡的时候,首先要经过内核Openvswitch.ko,流表Flow Table在内核中有一份,通过key查找内核中的flow table,即可以得到action,然后执行action之后,直接发送这个包,只有在内核无法查找到流表项的时候,才会到用户态查找用户态的流表.仅仅查找内核中flow table的情况被称为fast path. ? ? 第一步:从数据包中提取出key ? 实现函数为int ovs_flow_key_extract(const struct ip_tun

一个Netfilter nf_conntrack流表查找的优化-为conntrack增加一个per cpu cache

独悲需要忍受,快乐需要分享对Linux协议栈多次perf的结果,我无法忍受conntrack的性能,然而它的功能是如此强大,以至于我无法对其割舍,我想自己实现一个快速流表,但是我不得不抛弃依赖于conntrack的诸多功能,比如state match,Linux NAT等,诚然,我虽然对NAT也是抱怨太多,但不管怎样,不是还有很多人在用它吗.       曾经,我针对conntrack查找做过一个基于离线统计的优化,其思路很简单,就使用动态的计算模式代替统一的hash算法.我事先会对经过该BOX