openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)

一.写在前面

  唉,被分配到sdn安全方向,顶不住,顶不住,感觉搞不出来什么有搞头的东西。可若是让我水水的应付,我想我也是做不到的,世上无难事只怕有心人。好了,进入正题,本次要讨论的时一个比较细节的东西,在流表项中的有关ip掩码的问题。对了,本文适合于,有一定基础的openflow使用者,一点点就行。

二、问题描述

  若不是机缘巧合,我甚至完全不会注意到这个问题,为什么,咱来看一个平时实验环境中最为常见的流表项长啥样,如图1

  

                                                           图1 常见的流表项

  当我刚开始学习openflow的时候,我看到的就是这样的流表项,当时我一度以为“喔,这和路由表中的表项是不同的,连掩码都没有,sdn是新型网络的架构设计,应该抛弃了原来的网络架构,可能连掩码都不用使用了”。其实稍微深入想一想就可以发现这个想法根本占不住脚,从实际运用的角度,现在ip网根深蒂固,sdn若想要商业化,必须是要以融入ip网为前提,那么就肯定要考虑在传统网络中具有重大作用的ip掩码了,其次流表项里都有ip地址了,怎么可能不去考虑ip掩码的问题,若不考虑,跨网段通信如何解决?

  直到我在学习ryu防火墙的时候,这个问题的再次出现,才让我恍然大悟,也顺理成章的解决了它。现在来看一下在ryu的防火墙应用中看到的流表项,如图2:

  

                                                         图2 ryuf防火墙中的流表

  有没有觉得流表中的ip地址有些奇怪,对,确实挺奇怪的,但真正奇怪的点在于,这条流表项的产生使用的curl命令为:curl -X POST -d ’{“nw_src”:"10.0.0.1/8","nw_dst:"10.0.0.2/8"}‘ http://localhost:8080/firewall/rules/0000000000000001。没错,你没有看错curl命令中的10.0.0.1/8到达流表项后变为10.0.0.0/8了。先别急这考虑为什么,咱再做个实验,这次curl 的命令为curl -X POST -d curl -X POST -d ’{“nw_src”:"10.0.0.1/32","nw_dst:"10.0.0.2/32"}‘ http://localhost:8080/firewall/rules/0000000000000001,这个curl也是ryu官方文档中的样例,实验后流表项为图3

  

                 图3 ryuf防火墙中的流表

  图3中的流表项和curl中表达的一致,等等图3中的流表项是不是在哪见过?对,和最开始图1中的一样,接下来我们开始根据这三张图的内容进行分析

三、猜想与实验论证

  首先图3中的实验,我们使用的掩码是32位的,我是从未见过有32位的掩码,所以从这点可以看出这里的掩码与我们常见的路由表中的掩码肯定在概念上是有不同。其次我们再来看这个流表的效果,图1、3可以匹配的仅为源ip为10.0.0.1,目的ip为10.0.0.2的ip,而图2可以匹配的为10.0.0.0整个网段的主机,再考虑这是防火墙的应用,肯定是既需要同时考虑整个网段也需要考虑单独的主机。现在再来看看图2的流表是怎么得到的,curl中写的是10.0.0.1/8 再流表中变为10.0.0.0/8,是不是很像10.0.0.1与255.0.0.0想与得到的结果?

对,就是这样的,通过查看ryu的源码发现,就是将你所输入的ip源码和掩码做了与操作。在数据包到达ovs之后也是先与掩码做与操作,再和ip匹配。因此如果在防火墙应用阶段如果你想表达整个网段的的ip地址,就是用低于32的掩码即可,也就是说照常用,如果你仅仅只想表达两个主机间的禁止或允许,有两种表达方式,分别就是图1和图3,图1中是在curl中写的“10.0.0.1”,没有写掩码的位数,图3中是在curl中写的“10.0.0.1/32”,写的32位掩码,32位的掩码与任何ip与的结果都是其本身。

  能读到这的都是勇士。到现在不知你心里是否有个疑惑,不管你有没有,反正我是有。疑惑在于图1与图3,图1的curl语句没有写掩码在流表中的效果却和图3中写了32位掩码效果一样,这是不是意味着如果不写掩码,那么默认的掩码就是32位的?

不是这样的,如何证明这个结论,抓包。wireshark 抓取图1和图3控制器下发的flow-mod信息如图4和图5:使用的curl命令的ip地址分别位10.0.0.0和10.0.0.0/32

图4 无掩码的情况

    图5 32位掩码的情况

从图4和图5可以看出,是有个字段has mask 控制着是否使用掩码,在不使用掩码的时候,也是没有默认掩码这一说法,此时就是精确匹配。比如说在不使用掩码时curl中的ip地址你写的是10.0.0.0,就意味者只能匹配一台ip地址为10.0.0.0的主机,而不是匹配整个网段!

四、结论

1.掩码匹配的情况,总体可分为两种,使用掩码或者不使用,不使用掩码,并不是有默认掩码的存在。

2.在不使用掩码的时候,就是完全精确匹配,IP地址要一摸一样。

3.使用掩码时,无论是使用curl下发流表还是ovs中的流表匹配都是单纯的ip地址与掩码的与操作,所以会有32掩码的存在,32位的掩码就是想表达单个主机,若想表达网段就使用低于32位的掩码。

原文地址:https://www.cnblogs.com/wxrqforever/p/11734905.html

时间: 2024-11-05 11:26:47

openflow流表项中有关ip掩码的匹配的问题(控制器为ryu)的相关文章

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

软件定义网络基础---OpenFlow流表

一:流表 (一)流的概念 我们把同一时间经过同一网络中,具有某种共同特征或属性的数据,抽象为一个流 比如:我们将访问同一个地址的数据视为一个流 流一般是由网络管理员定义的,可以根据不同的流执行不同的策略,在OpenFlow中,数据都是作为流进行处理的.所以流表就是针对特定流的策略表项的集合,负责数据包的查找和转发 一张流表包含了一系列的流表项flow entries (二)流表项组成 (包头域.计数器.动作表3个) (三)包头域 (四)计数器 (五)动作表 动作表用于指示交换机,在收到匹配的数据

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

Openflow流表应用测试--逻辑隔离

1.搭建拓扑 搭建了三层的二叉树结构网络,开启SimpleSwitch3.py无法完成pingall联通测试,于是将拓扑结构更改为简单的line,四个交换机(OF13)连成一线,每个交换机下挂两个主机,依次h1--h8 s1 = net.addSwitch('s1', cls=OVSKernelSwitch, protocols='OpenFlow13', mac='00:00:00:00:00:11')    s2 = net.addSwitch('s2', cls=OVSKernelSwit

js中的IP格式正则匹配校验详解~

IPV4的格式为x:y:z:w,其中{x,y,z,w}属于{0~255}的正整数: 下面是其校验的正则表达式: function isIP(ip) { var re =  /^(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\.(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\.(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])\.(\d{1,2}|1\d\d|2[0-4]\d|25[0-5])$/ return re.test(ip); } 其中 

OpenFlow协议中如何提高交换机流表的匹配成功率

写在前面 这段时间一直在研究如何提高流表空间的利用率.一直没能想到好的idea.有一篇文献中比较了现有研究中提到的手段,在这里记录一下都有哪些类型的手段以及这些手段存在的不足.这些手段不仅局限于如何提高流表空间的利用率,更把范围拓展至如何提高交换机流表的匹配成功率. 背景 软件定义网络(Software Defined Network,SDN)作为一种新的架构,利用分层的思想将控制平面和数据平面分离,为网络的部署和配置提供了极大的灵活性和可扩展性. 然而当前的SDN网络只能对L2-L4层的信息进

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

Floodlight中的临时流表

运行Floodlight,在Mininet中新建一个拓扑之后,并未添加相关的流表项,但是主机之间却可以相互通信.执行pingall操作,任意两个主机之间都能通.相当于没有任何路由表的路由器,它是怎么让这些网络中的主机通信的呢? 原因在于Floodlight默认启用了Forwarding模块.说这个模块之前,首先说说Floodlight 中流表的两种添加方式:主动式和反应式. 官网上的文档是这么说的:http://docs.projectfloodlight.org/display/floodli