感谢有这样的机会，能够在SDN实战群分享我们在园区网中SDN的应用案例。目前在园区网中的SDN部署和应用还处于起步阶段，今天分享的内容一部分来自于我们的实际应用案例，还有一部分来自于我们搭建的demo环境，希望能够起到抛砖引玉的作用，同时如果有哪些不正确或者不准确的地方，还望各位及时指正。
目前我们在园区网的SDN应用，主要是聚焦在三个方面：
一是路径选择，依据一定的判断或者触发条件，通过流表来控制报文转发的路径；
第二是流量管理，一方面是要对园区内的流量进行采集、统计、分析和处理，形成相应的统计分析图表，也就是流量可视化；另一方面是需要分析异常的流量，并通过流表进行异常流量的抑制；
第三是用户管理，就是对用户接入园区网络进行相应的控制，包括用户接入网络的认证、速率和权限的控制、相应的计费等。
首先，对于路径选择和流量管理，我们会直接通过一个实际的案例来介绍。
这是我们实际部署的一个应用案例，客户一共有三个园区，采用了两台BRAS，也就是宽带接入路由器，作为全网的核心设备，分别部署在其中的两个园区。BRAS设备实现了用户接入、基于DHCP+Web Portal的认证/计费和业务控制功能，而园区中大量的汇聚和接入交换机则构成了网络的宽带接入层面。
这张图能够比较清楚的描述采用了这种架构下的园区网的功能划分。
用户比较关注的几个方面的问题：
1，汇聚到核心设备之间都是单链路上联，缺乏相应的保护机制
2，一般园区出口通过部署流控设备能够实现流量可视化和相应的控制，而园区内部就只能看到流量的大小、并发用户数等基本信息，缺乏内网流量的可视化。
3，这种架构下，汇聚和接入层交换机一起构成了高带宽的二层管道，成千上万的终端用户通过这个高带宽管道直接连接到核心BRAS设备。任何来自终端的异常或者***流量，都会直接转发到核心设备，影响稳定性。
针对这三个方面的需求，我们设计了这样的方案
首先，在每个校区分别增加SDN enabled交换机，原有的直接连接核心的汇聚交换机则分别连接到各自校区的SDN交换机上，而SDN交换机则通过双链路上联，分别连接到两台核心路由器上，SDN交换机的端口密度大，其实也扩展了核心设备的介入能力，另外我们在网络中部署了Brocade SDNController集群。
1）一方面通过Openflow实现对SDN交换机的控制，实现流表下发的动作。
2）另一方面也通过BSC控制器的netconf接口实现与核心设备的交互，目前主要是通过netconf获取核心设备的关键参数，如并发用户数、DHCP的统计信息、AAA的统计信息等，作为判断核心设备是否正常运行的依据。
以下就是SDN交换机的流表定义的例子，是描述两个汇聚交换机通过SDN交换机连接到核心BRAS的应用场景：
这里就需要通过流表实现流量的转发路径管理，我们规划了这样的一些转发流表
对于上行流量，可以简单的将来自于port2或者port4的流量直接转发到port1
而对于下行流量，则需要根据VLAN ID分别将流量转发到port2或者port4，针对汇聚/接入设备的管理地址，也就是同一个VLAN中不同的IP地址，则需要match IP地址，并转发到对应的下联端口。
因此，流表的管理和下发是个不小的工作量，这部分工作不应该手工完成，而是应该交给APP来实现。这些流表我们称之为 “基础转发流表”
另一方面，当侦测到某台核心设备出现故障且无法工作时，可以由管理员判断是否切换，并通过APP下发切换流表，将流量转发到另外一台核心设备上。需要注意的是，因为BRAS是用户会话和状态信息的，如果BRAS之间没有做session同步，切换会导致用户session的重建，所以这样的切换流表我们称之为“灾难恢复流表”
除了完成基本的路径管理外，我们希望能够通过新增的SDN交换机实现流量管理的功能，包括了流量的可视化和异常流量实时抑制。异常流量的抑制也是通过下发流表实现，这些流表我们称之为“异常流量流表”。
在SDN交换机上，我们希望能够获取到转发流量的副本，一般有这样2种方案
1、采用物理的分光设备，需要新购分光器和相应的光模块，且数量取决于上联链路的数量
2、采用端口镜像的方案，一般会将端口所有流量镜像出来，不够灵活
我们采用的方案是通过下发流表，将感兴趣的流量复制一份到监控端口方案。流量副本先经过前置Probe进行预处理，然后在送往APP进行统一的分析、处理、统计和报表展现。
通过对采集到的流量进行分析处理，能够实现园区网内部流量的可视化。
而对于异常流量监测，比如ARP、DHCP、广播报文、DNS等，则是提供了实时的统计，如设定策略为来自某个MAC地址每秒钟的ARP请求数量不超过50个，超过则触发系统自动生成一条针对该MAC地址ARP报文控制的一条流表并下发到SDN交换机中，流表的动作可以为Drop、Meter、redirect等。
流表下发后，APP会持续监测流表的counter，当counter不再增加，意味着***停止后，系统会回收这条流表。
实际上可以看做是将传统的流控设备的分析功能放到了Probe/APP上实现，而将控制功能放到了SDN交换机上实现。当然交换机只是提供了4层及以下的控制，如果要做到7层的控制，则需要将特定流量重定向到外置清洗设备来配合完成。
对于流量的分析，还有一个需要考虑的方面，就是大量的流量处理的问题，在这个系统中，采用了前置Probe+后台应用的方案，前置对流量进行预处理。但单台Probe无法处理园区内部所有的流量，因此需要部署多台Probe，需要将流量副本分配到多台Probe上。
这里我们同样也部署了SDN 交换机作为Packet Broker，也就是分流交换机，通过流表实现流量的分配。
举个例子，上行流量和下行流量分别被分配到4台Probe，我们需要在分流交换机中定义两个group，group类型为select，每个group中定义4个bucket，每个bucket的action为output到对应的probe连接端口，流量会按照五元组哈希进行分配。
这是在BSC控制器中定义group的界面
交换机中看到的group定义如下
充当分流作用的SDN交换机除了实现流量分配的功能之外，还可以在流量分配前基于流表对流量进行过滤，对一些不需要分析的流量，比如视频监控流量，可以下发流表进行匹配和过滤。
这就是这一个部分的介绍，另外一个园区网的SDN应用是基于Openflow的用户管理功能，也就是提供用户的接入、基于Portal的身份认证、权限控制以及基于时长、流量的计费。
传统上这些功能是需要通过BRAS设备来实现的，我们希望能够通过流表实现类似应用场景的需求。
这是我们搭建的demo环境，使用了Brocade MLXe路由器作为测试平台，并且部署了出口防火墙、重定向服务器、Web Portal服务器、AAA服务器以及Brocade SDN控制器。
这里比较重要的一点，是我们采用了Openflow Hybrid Port mode
所谓Hybrid Port mode，就是同一个物流端口同一个VLAN下的流量，可以同时支持传统的路由交换和基于Openflow流表的转发
工作机制是：当报文抵达开启Hybrid Port mode的端口后，首先会执行流表的查询，如果没有流表匹配，或者匹配流表的action为normal，则会按照传统的路由和交换来进行报文转发，这种方式会大大简化流表的数量和管理维护工作量，可以实现传统网络到SDN的平滑迁移。
具体的流程如下：
1. 终端用户的报文抵达MLXe路由器后，首先匹配到基础流表，流表匹配目的地址为内网地址段，动作为Normal，允许用户互访、访问内网资源、DNS服务器、DHCP服务器等等。
2. 对于没有匹配到基础流表的流量，将匹配到一条重定向流表，将流量发送到重定向服务器所在的端口，同时修改VLAN ID、目的MAC地址、目的IP地址等信息，另外也会在重定向服务器前过滤掉非http的流量。
3. 重定向服务器收到来自客户端的http请求后，会返回http 302的重定向信息，同样定义一条流表匹配来自重定向服务器的流量，action为normal，使得http 302信息能够通过正常的路由/交换返回到客户端。
4. 通过http 302，客户端的http请求将会重定向到内网的Web Portal服务器，客户端与web Portal之间交互的流量也是通过前面定义的基础流表来转发的。
5. 客户端在Web Portal上输入用户名、密码信息， Web Portal将账号信息发送到APP，APP作为Radius Client到AAA服务器上进行认证，认证成功后，一方面在Portal页面上显示认证成功信息，同时APP也要通过BSC控制器下发允许这个用户访问外网的流表，这条流表同样可以通过action normal实现。
6，如果园区网有多个出口，用户还可以通过web页面自助选择出口，这是目前比较热门的园区网多运营商的需求，可以通过流表很容易的实现，唯一要做的就是此时的流表需要定义output端口等信息了。
7，如果需要对该用户下行流量进行速率限制，可以设定用户下行方向的流表，通过meter实现速率限制。
因此，除了有限数量的基础流表外，每个用户最少只需要消耗上行和下行2条流表（如果需要下载限速的话），而且只是在需要认证访问外网时才消耗这2条流表。因此设备流表的容量决定了接入用户数的能力
基于Openflow 流表实现用户管理的方案有这几个方面的优势：
1，不需要通过DHCP触发生成session，支持DHCP或者静态IP地址用户的接入管理
2，与BRAS设备维持用户session和状态不同的是，SDN设备中的流表是无状态的，完全依赖于上层应用的流表管理和下发，因此SDN设备出现故障重启或者更换设备后，只需要通过应用重新下发流表，不需要用户重新认证
3，可以选择的设备类型很丰富，从接入层交换机到核心路由器，只需要支持Openflow Hybrid port mode即可。因此可以满足不同场景不同用户数量的接入需求
4，对IPv6的支持和流程，与IPv4完全相同
5，每个用户的不同业务可以使用多条流表进行控制，每条流表有单独的meter和counter，因此流量的控制和统计更加灵活
6，新业务的部署，比如园区网多运营商共同运营和用户自主选择运营商出口的需求，可以比较灵活的实现
这就是我今天分享的全部内容，谢谢大家！
标签：流表,二十一,用户,流量,交换机,SDN,分享,园区 来源： https://blog.51cto.com/u_15127593/2749747
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。