免费资源部落

这篇文章主要介绍了OpenStack SFC的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。

SFC简介

传统网络都是物理设备，网络高级服务和网络拓扑强相关的，而且要配置复杂的路由策略或者ARP欺诈等特殊处理方法才能引导流量经过这些高级服务功能单元，所有特殊处理请求都是针对报文的二层和三层头，还有一个问题就横向扩展困难。

计算虚拟化之后，对网络也提出了虚拟化的要求，虚拟网卡，虚机交换机，虚拟路由器，overlay网络拓扑自定义，虚拟机到处漂移，传统网络添加网络高级服务的方法已经无法应对这多复杂多变的局面了。

SFC全称Service Function Chain，RFC 7665 Service Function Chaining (SFC) Architecture对SFC的体系做了很详细的介绍。end to end流量中间要有序经过FW,NAT,IDS等网络功能单元，对这些网络功能的定义和管理，以及引导流量如何有序经过这些网络功能单元就是SFC。为什么现在需要SFC，是因为以前FW,NAT,IDS等网络功能单元是实体物理设备，它的部署位置是和网络拓扑强相关的，所有流量共享这些设备，而且流量经过这些设备的序列是固定死的，总结是不够灵活，而SFC可以自定义网络功能单元，自定义流量路径，很好给SDN网络提供了支撑。

SFC首先由classifier识别出要经过这条chain的流量，然后再不断地经过这条chain上的service function，从classifier到第一个service function和从上一下service function到下一个service function，报文都要做封装，目前主推的是RFC 8300 Network Service Header (NSH)，封装头一般包含chain id和chain上的位置，就是这个报文走的是哪个chain，现在在chain上走了几步了，这样靠这个头就可以保证报文走正确的chain，而且在chain上依次一个一个地走service function，不会重复走service function，也不会跳过一些service function。NSH头可以包含更多字段，携带数据以便service function之间共享信息。

从上一个service function到下一个service function由sf forwarder来转发，service function又分为service function aware和service function unaware，service function aware可以正确解析报文携带的NSH头，反之service function unaware就不能识别NSH等这样的头，需要proxy把NSH等这头去掉，再发往service function中。

2

network-sfc

networking-sfc是openstack中实现sfc功能的一个项目，openstack neutron中port是一个很重要概念，所以networking-sfc就把port连在一起形成一条chain，就是service function chain，在opnestack中叫做port chain，RFC中并没有说SFF和SF怎么传递报文，port chain明确指出用port，而且分为ingress port和egress port。networking-sfc实现了neutron extension，对外提供api，service plugin负责真正干活，plugin又包含各种各样的driver，其中就有ovs driver，ovs driver和计算节点上opensvswitch agent 中的sfc extension用rpc通信。

networking-sfc中有如下几个重要概念：

port pair

port pair就是一个service function节点上一对口，一个port是ingress进service function，另一个port是egress出service function，ingress和egress可以是同一个port，这个port能进能出，是否需要proxy由参数创建port pair时的参数--service-function-parameters correlation=xxxx来指定。

port pair group

port pair group包含一个或者多个port pair，主要是为了做流量负载均衡，假如一条chain中有两个firewall service function，流量可以走任意一个firewall就可以，port pair group就是干这事的，指导流量在这两个firewall上负载均衡，创建port pair group时指定参数，例如--port-pair-group-parameters lb_fields=ip_src&ip_dst。

port chain

port chain把一些port pair group按顺序指定好，再加一个classifier识别出流量上第一个service function就形成了一个port chain。流量怎么装由参数--chain-parameters correlation=<correlation-type>,symmetric=<boolean>]来指定。

service graph

service graph把几条chain组合在一起形成一个复杂的流量多路径，流量经过一条chain后分叉，两个分支分别走不同的chain，理论上这个graph不能形成环路。

3

networking-sfc模式

chain

流量只有一条路径，从src依次经过service function节点到dst，service function有一个ingress port和一个egress port，ingress和egress port可以是同一个port。

tap

这种模式适用于IDS等流量只进不出的模式，流量复制一份到IDS，继续流向下一个节点。

LB

流量在两个service function节点之间做负载均衡，具体由openflow的group表来实现，根据报文的信息(eth_src,eth_dst,ip_src,ip_dst,tcp_src,tcp_dst,udp_src,udp_dst)来hash。

service graph

这种模式由多条chain组成，一条分叉成几条，分叉点由re-classifier来控制流量走向。这种模式适合于报文会被service function修改，如service function是NAT功能，报文的IP被修改后，原来的classifier有可能匹配不到，所以后续创建新的port chain，关联新的classifier。

4

应用

这是一个networking-sfc service graph的例子，分为四条port chain，每个service function是一条单独的chain，service graph实现了分叉再合并。流量从src出来到sf1，分叉到sf2和sf3，sf4合并sf2和sf3出来的流量，最后送给dst。用的是networking-sfc的ovs driver，src,sf1,sf2,sf3,sf4,dst都是虚拟机，分布在两个不同的物理上，物理机之间用vxlan tunnel通信。由于ovs实现的NSH的bug，导致流量转发不通，这里用MPLS做SFC封装。

流表最大的特点就是分叉点或者合并点引进了reg0，原来的流表match in_port=xxx和 flowclassifier，然后就到group table。现在变成in_port前一个port chain的最后一个service function的egress port，把label暂存在reg0中，resubmit(,0)，然后match reg0和flowclassifier送去group table，把原来的一条流表变成了多条。group table相同就合并，group table不同就分叉了。

感谢你能够认真阅读完这篇文章，希望小编分享的“OpenStack SFC的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持，关注行业资讯频道，更多相关知识等着你来学习!