SDNLAB技术分享(一):ODL的SFC入门和Demo



  • 在网络通信过程中,包含各式各样的网络服务功能。既可以包含传统的像防火墙,NAT等功能,也有包含特定的网络应用功能(Service
    Function)。将特定的网络应用功能有序地组合起来,接着让流量通过这些服务功能就构成了网络服务链(Network
    Service Chain)。一般在数据中心环境下,往往会有网络服务链(Network
    Service
    Chaining)的部署需求,使得报文在数据中心传递的时候,能够经过各种各样的服务节点,保证安全、快速、稳定的网络服务。

    pt-SDNLAB-share-ODL-Service-Function-Chaining-Demo2015-09-22.jpg

    1.SDN服务链基本概述

    由于Overlay网络的发展,使得虚拟网络和物理网络分离,让数据中心的网络控制变得更加灵活,更具有扩展性。然而,在数据中心中,还存在很多介于虚拟网络和物理网络之间的中间件,如防火墙,QoS,负载均衡器等。这些中间件提供了必要的业务处理功能,即Service
    Function。灵活、便捷、高效、安全地调配流量到Service
    Function上处理,形成服务链(Service Function
    Chaining),这就是SFC项目要解决的问题。服务链可以理解为一种业务形式。

    过去也有服务链的概念,但传统的网络服务链往往和网络拓扑紧密耦合、部署复杂,在服务链变更、扩容时,都需要改动网络拓扑,重新进行网络设备的配置。而云计算环境广泛使用虚拟化技术,具有动态性、高流动性、规模易变化、多租户等特点,传统网络的服务链无法满足这些需求,SDN的出现让服务链又焕发了生机。因此,当前再谈及服务链时,默认指的是SDN服务链。

    与传统DC中配置的网络服务链相比,基于SDN的SFC具有如下的优势:

    • 传统的网络服务链往往基于手工配置,很大程度上依赖于具体的网络拓扑,以至于网络设备之间的耦合性很大。而基于SDN的配置,可以动态的添加或者删除链表上的服务节点,不仅方便使用,而且解耦了网络设备之间的关联。
    • 在数据流量经过链表的过程中,SFC还支持分类器与服务,服务与服务之间的上下文信息共享。
    • 在传统的数据服务链中,数据包往往要经过过次分类,即多次解包、封包的过程。而在SFC中,这个过程大大缩减,一般只需在分类一次即可,使得整个过程更便捷、更高效。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图1.jpg

    2.基于OpenDaylight的服务链项目

    2.1 Service Function Chaining 的架构及组件

    OpenDaylight的SFC项目是整个控制器平台内部的一个功能模块。用户可以通过控制器提供的北向API来使用的SFC的功能,例如创建、更新或者删除Service
    Chain,还可以通过配置非透明的metadata数据段用来在Service
    Function的节点间实现数据共享。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图2.jpg

    同时,项目可以向Controller的DataStore中注册、配置服务节点,并获取拓扑。南向也支持Netconf,Openflow12等协议。

    SFC核心组件如下:

    • Classification:根据初始化的(配置好的)policy匹配数据流进行封装,然后转入到Service
      Function Chain中。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图3.jpg

    • Service Function(SF):
      负责对收到的数据包进行特定功能的处理。作为一个逻辑上的组件,SF在具体实现的上可以是一个虚拟的元素,或者是嵌入在具体网络设备上的某种功能。常见的SF有:防火墙(firewall),WAN设备加速器,深层报文检测(Deep
      Packet Inspection,DPI),NAT等等。
    • Service Function Forwarder(SFF):主要负责Service Function
      Chaining上的流量转发控制。
    • Service Function Chain(SFC): SFC定义了一个抽象的Service
      Function有序集合。经过分类后的包要依次去遍历集合中的Service
      Function。比如:用户可以配置firewall->qos->dpi三种服务来构建一条SFC。
    • Rendered Service Path(RSP) : 数据包实际行走的路径。
    • Service Function Path(Service Function Path): SFP是一个逻辑概念,

    它是介于SFC和RSP之间的一层抽象,有时候会将SFP与SFC等同。

    2.2 ODL的SFC项目工作流原理

    那么,SFC项目是怎么综合起上述的组件进行工作的呢?

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图4.jpg

    一种基于NSH封装头的机制是,使用ODL配置并下发一条Service Function
    Chain,每条Chain都有自己的标识。当host1发送数据包给host2,数据包首先会到分类器中进行筛选。分类出需要经过Service
    Function
    Chaining的数据包会进行封装,并打上NSH头。头中包含了很多信息,包括走哪一条服务链,服务链有几跳等。接着数据包会依次经过SFF,由SFF将数据包传递给SF或者下一跳的SFF,直到链的最后。

    3.实验

    本篇文章旨在通过基本概念的介绍和一个SFC的实验,帮助大家了解SFC是什么,在OpenDaylight中如何去配置基本的SFC。通过对SFC有个大致的了解,有兴趣的同学可以继续深入地去研究NSH,SFC架构及应用等知识。

    3.1 实验准备

    • 系统需要是Ubuntu 14.04(Mac也可以)
    • Java 7
    • Mave 3.4
    • git OpenDaylight SFC项目到本地
    • Python3.4

    Python导入包包括:requests,flask,netifaces,paramiko等

    在Ubuntu14.04下搭建ODL环境参考:https://wiki.opendaylight.org/view/Install_On_Ubuntu_14.04
    在Ubuntu下安装Python3.4及所需包如下:

    如果没有Python3.4:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图5.jpg

    安装一个Python3.4-pip安装器

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图6.jpg

    安装flask包,其他包安装类似,根据版本不同,安装方法或者指令不一定与这里相同:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图7.jpg

    3.2 术语简表:

    • SF : Service Function
    • SFF : Service Function Forwarder
    • SFP : Service Function Path
    • RSP : Rendered Service Path
    • ODL : OpenDaylight
    • SFC Agent: Service Function Chaining Agent.

    3.3 基本配置和安装:

    ifconfig查看本地机器的ip,我这边是:192.168.2.134

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图8.jpg

    安装ODL的sfc项目:git clone http://git.opendaylight.org/gerrit/sfc

    楼主使用的SFC是5月份的版本:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图9.jpg

    可以git reset –-hard cd12dda6回到那个版本。

    如果读者在实验的时候,用的是最新版本的SFC,在sfc/sfc-py/sfc/nsh/service.py脚本有很多bug,要做适当修改。这里为方便,就使用之前版本演示。

    用maven构建一下项目:

    mvn clean install –DskipTests
    

    启动ODL:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图10.jpg

    过一会儿,就可以用浏览器进入SFC的ui界面了:http://localhost:8181/sfc/index.html
    用户名和密码都是:admin

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图11.jpg

    刚开始进来都是空的,点击System
    Info会有404也不要紧张,因为什么都没有配置。另外,在ODL中创建SFC有两种方式:第一,用北向的RESTAPI;第二,用UI来创建。本次实验用将基于UI,这样看起来比较直观,方便理解。后续有兴趣用REST来配置的参见SFC
    101文档。

    3.4 开始实验

    3.4.1 启动SFC Agent

    SFC
    Agent是用Python脚本写的一个仿真工具,位于SFC项目的sfc-py目录下。在实验的过程中,ODL在南向通过REST与Agent进行通信,即ODL通过REST将配置的信息下发给Agent,Agent根据这些信息,在数据平面仿真出相应的元素组件。使用Agent的好处就是在实验中,简化南向接口,易于实现实验。

    进入到sfc/sfc-py目录下,打开start_agent.sh文件,修改默认的ip地址为本地主机ip:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图12.jpg

    也可以将127.0.0.1改成192.168.2.134。

    启动Agent:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图13.jpg

    根据上图可以直到Agent运行的端口是5000。

    3.4.2 创建Service Function

    点击导航栏的Service Function标签,再点击”Add Service
    Function”,填写表格如下:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图14.jpg

    点击Submit,在Agent端,有如下信息输出:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图15.jpg

    表明Agent已经成功为我们创建好了SF1(firewall)。

    这里有几个地方要注意:\

    1.NSH头的使用。我们这里是基于Agent的仿真实验,没有对分类器做配置。选True
    和False都没有关系,但是实际情况下会根据NSH头的信息来选择具体的路径。具体可以研究:http://datatracker.ietf.org/doc/draft-ietf-sfc-nsh/

    2.数据平面的通信方式一定要选,这里选vxlan-gpe。要不然Agent收不到请求。

    3.SFF1暂时还没有创建,可以先填入SFF1,后面创建SFF的名字要与这里一致。

    3.4.3 创建SFF

    在导航菜单中点击Service Function Forwarder,点击”Add Service Function
    Forwarder”,填写表单信息如下:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图16.jpg

    右下角的SFF
    dictionary“Remove”掉,后面的版本也没有这个directory了。如下图:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图17.jpg

    submit以后,在Agent端,SFF创建成功信息打印如下:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图18.jpg

    3.4.4 目前拓扑和工作流

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图19.jpg

    3.4.5 创建Service Function Chain

    在导航栏点击Service Function Chain标签:

    • 点击创建Service Function Chain
    • 填入名字“Chain-1”,提交
    • 将”firewall”的SF拖拽到右边的Chain-1中
    • 保存一下,点击deploy,生成一条Service Function
      Path,命名为“Chain-1-Path-1”,这样就创建好了Service Function Paht。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图20.jpg

    3.4.6 创建Rendered Function Path

    导航栏中点击”Service Function Paths” ,将会看到我们刚创建的SFP。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图21.jpg

    根据SFP,点击上图按钮,可以生成一条RSP。如果勾上了”Symmetric
    path”就会另外生成一条对称反向的RSP。

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图22.jpg

    成功以后,记住RSP的两个重要属性“Path-ID”为63,“starting-index”为255。

    这个时候我们可以看到Agent里面打印的消息:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图23.jpg

    通过从SFC
    的创建到SFP,再到RSP的创建,是一个由抽象到具体的过程。从应用的角度来理解,SFC是对Service
    Function的一层抽象,这里的SFP是具体化每个Service
    Function到其对应的配置的SF(SF1),而RSP的生成代表包具体穿过的路径将是怎样的。

    3.4.7 发送数据包

    我们将发送数据包来遍历这条简单的SFC,“Path-ID”为63,“starting-index”为255。打开sfc/sfc-py/sfc/目录,运行如下命令:

    python3.4 sff_client.py --remote-sff-ip 192.168.2.134 --remote-sff-port 4789 --sfp-id 63 --sfp-index 255
    

    Agent获取结果如下:

    SDNLAB技术分享(一):ODL的Service-Function-Chaining入门和Demo-图24.jpg

    从上图可以看到客户端(Client192.168.2.134:4790)发送包到SFF,SFF然后再将包发送给SF进行处理。SF处理完再转回给SFF,SFF再寻找下一跳,如果没找到,判断为链表末尾。

    3.4.8 实验总结

    以上我们简单的演示了一个SFC的使用实验,只包含了一个SFF和SF。通过在ODL中使用北向UI接口配置SF的信息,配置SFF的信息并关联相应的SF下发给Agent。在这个过程里,我们还可以删除,修改这些节点信息,充分体现了基于SDN的服务链的灵活性、拓扑独立性。

    用户需要配置服务链的时候,只需要通过控制器的北向接口自由组合节点成有序序列。然后使用的时候,生成一条数据包路径,并下发即可。同时,用户也可以配置多条服务链。

    注意,在不修改原始python脚本的情况下,在南向使用Agent可以创建多SF挂到一个SFF上,但只能创建一个SFF。

    4.参考文档及后续阅读

    网络服务链ppt:

    http://wenku.baidu.com/link?url=kiiof5kXtwNnNM9xGDF6VboASaKnKw48Cz6fxW92JMgyTqsbR5c1CsWLzQp4idt6d-zDjiihHt6MsBeURiJt0kSD8DHyTcrnl6eSIan5Xay
    本实验基于SFC 101文档,具体英文原版参见:

    https://drive.google.com/file/d/0BzS_qWNqsnQbUnEzU3BqVzdueTQ/view?usp=sharing
    SFC架构:
    http://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
    SFC ppt:\

    https://wiki.opendaylight.org/view/Service_Function_Chaining:Presentations
    http://network.51cto.com/art/201312/425928.htm
    相关资料:http://packetpushers.net/service-chaining/

    Q&A

    Q:服务链与业务编排的区别是什么?
    A:这里的SFC也是一种业务形式,我认为这里服务链应该是业务编排的子集。

    Q:补充一下问题,如果SF不支持NSH,那么SF设备的回包,SFF设备如何判断它属于哪条链呢?问这个问题主要是因为我们公司正在做这块的解决方案,我还没有搞清楚怎么和传统的设备进行配合。其实整个SDN领域里面都存在和传统设备配合这种头疼的问题。\

    A:这个要看具体classify的policy了。基于nsh的数据平面识别rsp是看classifier打的path-id,识别与sf无关。但是对于基于nsh的sfc,sf只需要在处理完以后,将nsh的index字段减1,将数据包回传给sff就可以了。如果你要是新设备和老设备一起,是不是可以考虑l2,用mac来实现?详细见参考资料service
    function chain.pdf/p18。

    Q:各个SF节点间数据共享?如何实现的,谢谢
    A:基于nsh的数据之间共享是通过metadata字段来共享的。

    Q:个人比较习惯看数据包,能不能展示一下NSH的数据包呢,现在看NSH的文档只能看协议字段,感谢。
    A:nsh数据包,看rfc。实现可以看sfc/sfc-py下源码。

    Q:同上,还有ODL控制器控制器流量经过SF是用OpenFlow流表吗,流表是怎么匹配NSH头?谢谢~\

    A:openflow13也是sfc的l2另一种实现方式,这个可以不需要配置nah。详细见参考资料service
    function chain.pdf/p18。这种我没有实现过,不好意思。

    Q:控制器怎么知道各个sf的具体挂在哪个交换机的哪个端口上,是由谁告诉他的?包括物理的sf(此时挂在物理交换机上)和虚机方式的sf(此时挂在虚拟交换机上,并且可能是sf虚机是动态创建出来的)分别怎么知道的?
    A:在odl配置的时候会指定sf的data plane。

    Q:sf 设备可以是物理设备吧?
    A:sf是一个逻辑上的概念。

    Q:如果SF是NAT设备怎么办?传统的NAT设备可以正常识别到NSH的头么?还有,nat之后的包地址端口都有可能发生变化,ODL是怎样重新识别的?\

    A:odl只负责控制平面,跟具体功能无关。nsh头是附加在报文上的,在最后要remove掉的。

    Q:问个小白问题,上面提到的支持南向各种协议,特意提出了openflow12,现在of13支持吗?
    A:源代码里面写的是op12,不过坑也很多。

    Q:我记得SFF最后一条是发回给classifier 应该不会自己去nsh吧?
    A:这个我看到过在最后一个sff去掉nsh的。

    Q:我记得是传给classifier或者proxy解,以前看odl的sff发的过包。你有时间看下也帮我确认下。可能我看错了。\

    A:之前在做的时候,一般也设计sff只负责转发。但是rfc中也提到过可以由最后一个sff来去除封装。

    Q:最后一个问题多SFF你做过test么?这个总是SP SI
    conflict,一直没做成过。

    A:多SFF,可以起多个agent,每个agent负责一个sff。不过代码可能要调试一下。

    分享者介绍:

    以上内容根据2015年9月21日晚OpenDaylight
    QQ群的分享内容整理。**分享人赵伟,同济大学研究生三年级,专业软件工程,研究方向计算机仿真技术。现在江苏省未来网络创新研究院从事基于bgp的流量调度研究工作。**SDNLAB每周都会组织定向的技术分享,欢迎感兴趣的朋友加群:194240432参与,您有想听的话题或者想要分享可以给我们留言。

    原文链接:http://www.sdnlab.com/13826.html


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待