【编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成，由Brocade公司SE智勇给大家带来园区网SDN应用分享。
--------------------------------------------------------------------------
分享嘉宾
智勇，Ethan Zhi，博科通信上海office的系统工程师，之前在Juniper Networks担任系统工程师。
分享正文
--------------------------------------------------------------------------
感谢有这样的机会，能够在SDN实战群分享我们在园区网中SDN的应用案例。目前在园区网中的SDN部署和应用还处于起步阶段，今天分享的内容一部分来自于我们的实际应用案例，还有一部分来自于我们搭建的demo环境，希望能够起到抛砖引玉的作用，同时如果有哪些不正确或者不准确的地方，还望各位及时指正
目前我们在园区网的SDN应用，主要是聚焦在三个方面：
- 一是路径选择，依据一定的判断或者触发条件，通过流表来控制报文转发的路径
- 第二是流量管理，一方面是要对园区内的流量进行采集、统计、分析和处理，形成相应的统计分析图表，也就是流量可视化；另一方面是需要分析异常的流量，并通过流表进行异常流量的抑制
- 第三是用户管理，就是对用户接入园区网络进行相应的控制，包括用户接入网络的认证、速率和权限的控制、相应的计费等。
首先，对于路径选择和流量管理，我们会直接通过一个实际的案例来介绍。
这是我们实际部署的一个应用案例，客户一共有三个园区，采用了两台BRAS，也就是宽带接入路由器，作为全网的核心设备，分别部署在其中的两个园区。BRAS设备实现了用户接入、基于DHCP+Web Portal的认证/计费和业务控制功能，而园区中大量的汇聚和接入交换机则构成了网络的宽带接入层面。
这张图能够比较清楚的描述采用了这种架构下的园区网的功能划分。
用户比较关注的几个方面的问题：
1，汇聚到核心设备之间都是单链路上联，缺乏相应的保护机制
2，一般园区出口通过部署流控设备能够实现流量可视化和相应的控制，而园区内部就只能看到流量的大小、并发用户数等基本信息，缺乏内网流量的可视化。
3，这种架构下，汇聚和接入层交换机一起构成了高带宽的二层管道，成千上万的终端用户通过这个高带宽管道直接连接到核心BRAS设备。任何来自终端的异常或者攻击流量，都会直接转发到核心设备，影响稳定性。
针对这三个方面的需求，我们设计了这样的方案
首先，在每个校区分别增加SDN enabled交换机，原有的直接连接核心的汇聚交换机则分别连接到各自校区的SDN交换机上，而SDN交换机则通过双链路上联，分别连接到两台核心路由器上，SDN交换机的端口密度大，其实也扩展了核心设备的介入能力，另外我们在网络中部署了Brocade SDNController集群。
- 一方面通过Openflow实现对SDN交换机的控制，实现流表下发的动作
- 另一方面也通过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，新业务的部署，比如园区网多运营商共同运营和用户自主选择运营商出口的需求，可以比较灵活的实现
这就是我今天分享的全部内容，谢谢大家！
Q&A
Q1：计费如何实现呢？如果不保持状态计费信息应该拿不到完整的
A1：每条流表都有counter，因此流量的计费很容易实现。流表的创建和收回也可以确定时长
Q2：brocade也有bras?
A2：不是传统的BRAS设备，而是基于流表的用户管理。
Q3：BSC控制器是什么啊？
A3：BSC就是Brocade的SDN控制器，基于ODL的
Q4：一般来说一台SDN设备可以支持的最大用户量是多少?
A4：取决于流表数量，和每个用户消耗的流表。除去数量有限的基础流表，最少每个用户消耗一条流表（不做下行方向的限速）或者2条流表（做下行方向限速）
Q5：目前BSC比odl本身先进多少啊？我想自己搞个环境，可以拿到吗
A5：可以下载到试用版的
Q6：meter在接入层做的吗？流量统计汇总在控制器上完成？
A6：meter就是在对应的流表上完成，不一定在接入层，取决于SDN设备部署的位置。流量统计在APP上实现，并且可以通过与AAA系统的对接实现计费。
Q7：请问BSC控制器做了哪些改动？也就是说内部应用的功能是什么？还用提到的DHCP这功能，控制器是如何替代的？
A7： BSC一方面是有Brocade的技术支持，另外也有博科提供的一些APP，DHCP是独立的系统，在这个环境中与控制器无关。
Q8：在这种bras的替代方案中用户需要二次获取地址么
A8：不需要二次地址分配
Q9：BRAS对IPOE有啥痛点?
A9：特别是基于service的计费，BRAS做比较复杂
Q10：VXLAN是不是也是使用OPENFLOW这样的协议对设备下发流，SDN与网络设备上继续使用路由协议是不是没有任何关联？
A10：在OVS中是通过流表映射到对应的VNI，在我们的物理交换机中是通过VLAN VNI mapping实现的。Hybrid port模式下可以同时使用
Q11：除了web portal 的方式，你们有没有做传统的pppoe的尝试
A11：目前没有
Q12：SDN 交换机作为Packet Broker，具体的策略或者流表能说下吗？
A12：目前是通过group-select来做的，可以给你流表定义
Q13：用户如果从bras1移动到bras2怎么办? sdn响应流程是什么?
A13：理论上可以通过流表复制迁移的方式实现，但没做过测试
--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。
