51学通信论坛2017新版

标题: SDN实战团分享（十三）：SDN [打印本页]

作者: admin 时间: 2017-9-17 14:39
标题: SDN实战团分享（十三）：SDN
【编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成，由Brocade公司SE智勇给大家带来园区网SDN应用分享。
--------------------------------------------------------------------------
分享嘉宾

[attach]1319[/attach]

智勇，Ethan Zhi，博科通信上海office的系统工程师，之前在Juniper Networks担任系统工程师。
分享正文
--------------------------------------------------------------------------
感谢有这样的机会，能够在SDN实战群分享我们在园区网中SDN的应用案例。目前在园区网中的SDN部署和应用还处于起步阶段，今天分享的内容一部分来自于我们的实际应用案例，还有一部分来自于我们搭建的demo环境，希望能够起到抛砖引玉的作用，同时如果有哪些不正确或者不准确的地方，还望各位及时指正
目前我们在园区网的SDN应用，主要是聚焦在三个方面：

首先，对于路径选择和流量管理，我们会直接通过一个实际的案例来介绍。
这是我们实际部署的一个应用案例，客户一共有三个园区，采用了两台BRAS，也就是宽带接入路由器，作为全网的核心设备，分别部署在其中的两个园区。BRAS设备实现了用户接入、基于DHCP+Web Portal的认证/计费和业务控制功能，而园区中大量的汇聚和接入交换机则构成了网络的宽带接入层面。

[attach]1320[/attach]

这张图能够比较清楚的描述采用了这种架构下的园区网的功能划分。

[attach]1321[/attach]

用户比较关注的几个方面的问题：
1，汇聚到核心设备之间都是单链路上联，缺乏相应的保护机制
2，一般园区出口通过部署流控设备能够实现流量可视化和相应的控制，而园区内部就只能看到流量的大小、并发用户数等基本信息，缺乏内网流量的可视化。
3，这种架构下，汇聚和接入层交换机一起构成了高带宽的二层管道，成千上万的终端用户通过这个高带宽管道直接连接到核心BRAS设备。任何来自终端的异常或者攻击流量，都会直接转发到核心设备，影响稳定性。
针对这三个方面的需求，我们设计了这样的方案

[attach]1322[/attach]

首先，在每个校区分别增加SDN enabled交换机，原有的直接连接核心的汇聚交换机则分别连接到各自校区的SDN交换机上，而SDN交换机则通过双链路上联，分别连接到两台核心路由器上，SDN交换机的端口密度大，其实也扩展了核心设备的介入能力，另外我们在网络中部署了Brocade SDNController集群。

以下就是SDN交换机的流表定义的例子，是描述两个汇聚交换机通过SDN交换机连接到核心BRAS的应用场景

[attach]1323[/attach]

这里就需要通过流表实现流量的转发路径管理，我们规划了这样的一些转发流表

[attach]1324[/attach]

对于上行流量，可以简单的将来自于port2或者port4的流量直接转发到port1
而对于下行流量，则需要根据VLAN ID分别将流量转发到port2或者port4，针对汇聚/接入设备的管理地址，也就是同一个VLAN中不同的IP地址，则需要match IP地址，并转发到对应的下联端口。
因此，流表的管理和下发是个不小的工作量，这部分工作不应该手工完成，而是应该交给APP来实现。这些流表我们称之为 “基础转发流表”
另一方面，当侦测到某台核心设备出现故障且无法工作时，可以由管理员判断是否切换，并通过APP下发切换流表，将流量转发到另外一台核心设备上。需要注意的是，因为BRAS是用户会话和状态信息的，如果BRAS之间没有做session同步，切换会导致用户session的重建，所以这样的切换流表我们称之为“灾难恢复流表”
除了完成基本的路径管理外，我们希望能够通过新增的SDN交换机实现流量管理的功能，包括了流量的可视化和异常流量实时抑制。异常流量的抑制也是通过下发流表实现，这些流表我们称之为“异常流量流表”。
在SDN交换机上，我们希望能够获取到转发流量的副本，一般有这样2种方案
1、采用物理的分光设备，需要新购分光器和相应的光模块，且数量取决于上联链路的数量
2、采用端口镜像的方案，一般会将端口所有流量镜像出来，不够灵活
我们采用的方案是通过下发流表，将感兴趣的流量复制一份到监控端口方案。流量副本先经过前置Probe进行预处理，然后在送往APP进行统一的分析、处理、统计和报表展现。

[attach]1325[/attach]

通过对采集到的流量进行分析处理，能够实现园区网内部流量的可视化。
而对于异常流量监测，比如ARP、DHCP、广播报文、DNS等，则是提供了实时的统计，如设定策略为来自某个MAC地址每秒钟的ARP请求数量不超过50个，超过则触发系统自动生成一条针对该MAC地址ARP报文控制的一条流表并下发到SDN交换机中，流表的动作可以为Drop、Meter、redirect等。
流表下发后，APP会持续监测流表的counter，当counter不再增加，意味着攻击停止后，系统会回收这条流表。
实际上可以看做是将传统的流控设备的分析功能放到了Probe/APP上实现，而将控制功能放到了SDN交换机上实现。当然交换机只是提供了4层及以下的控制，如果要做到7层的控制，则需要将特定流量重定向到外置清洗设备来配合完成。

[attach]1326[/attach]

对于流量的分析，还有一个需要考虑的方面，就是大量的流量处理的问题，在这个系统中，采用了前置Probe+后台应用的方案，前置对流量进行预处理。但单台Probe无法处理园区内部所有的流量，因此需要部署多台Probe，需要将流量副本分配到多台Probe上。
这里我们同样也部署了SDN 交换机作为Packet Broker，也就是分流交换机，通过流表实现流量的分配。

[attach]1327[/attach]

举个例子，上行流量和下行流量分别被分配到4台Probe，我们需要在分流交换机中定义两个group，group类型为select，每个group中定义4个bucket，每个bucket的action为output到对应的probe连接端口，流量会按照五元组哈希进行分配。
这是在BSC控制器中定义group的界面

[attach]1328[/attach]

交换机中看到的group定义如下

[attach]1329[/attach]

充当分流作用的SDN交换机除了实现流量分配的功能之外，还可以在流量分配前基于流表对流量进行过滤，对一些不需要分析的流量，比如视频监控流量，可以下发流表进行匹配和过滤。
这就是这一个部分的介绍，另外一个园区网的SDN应用是基于Openflow的用户管理功能，也就是提供用户的接入、基于Portal的身份认证、权限控制以及基于时长、流量的计费。
传统上这些功能是需要通过BRAS设备来实现的，我们希望能够通过流表实现类似应用场景的需求。

[attach]1330[/attach]

这是我们搭建的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服务器等等

[attach]1331[/attach]

2. 对于没有匹配到基础流表的流量，将匹配到一条重定向流表，将流量发送到重定向服务器所在的端口，同时修改VLAN ID、目的MAC地址、目的IP地址等信息，另外也会在重定向服务器前过滤掉非http的流量。

[attach]1332[/attach]

3. 重定向服务器收到来自客户端的http请求后，会返回http 302的重定向信息，同样定义一条流表匹配来自重定向服务器的流量，action为normal，使得http 302信息能够通过正常的路由/交换返回到客户端。

[attach]1333[/attach]

4. 通过http 302，客户端的http请求将会重定向到内网的Web Portal服务器，客户端与web Portal之间交互的流量也是通过前面定义的基础流表来转发的。
5. 客户端在Web Portal上输入用户名、密码信息， Web Portal将账号信息发送到APP，APP作为Radius Client到AAA服务器上进行认证，认证成功后，一方面在Portal页面上显示认证成功信息，同时APP也要通过BSC控制器下发允许这个用户访问外网的流表，这条流表同样可以通过action normal实现。

[attach]1334[/attach]

6，如果园区网有多个出口，用户还可以通过web页面自助选择出口，这是目前比较热门的园区网多运营商的需求，可以通过流表很容易的实现，唯一要做的就是此时的流表需要定义output端口等信息了。
7，如果需要对该用户下行流量进行速率限制，可以设定用户下行方向的流表，通过meter实现速率限制

[attach]1335[/attach]

[attach]1336[/attach]

因此，除了有限数量的基础流表外，每个用户最少只需要消耗上行和下行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实战团微信群由Brocade中国区CTO张宇峰领衔组织创立，携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛，每周都会组织定向的技术及业界动态分享，欢迎感兴趣的同学加微信：eigenswing，进群参与，您有想听的话题可以给我们留言。
声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。

欢迎光临 51学通信论坛2017新版 (http://bbs.51xuetongxin.com/)