登录 / 注册
IT168网络通信频道
IT168首页 > 网络通信 > 网络通信技术 > 正文

Segment Routing meet SDN

2018-08-25 19:54    SDNLAB 来源:SDNLAB  作者: 马绍文 编辑: 李雪薇

  分享嘉宾:马绍文,Juniper亚太区产品总监。领导亚太区产品经理团队管理Routing/Switching/Security/Cloud 产品线。跟欧美亚太主流OTT/SP架构师团队共同工作多年,积极参与业界SDN/NFV的发展,多次Apricot和其他亚太盛会上分享SDN/NFV等的主题演讲。最近的关注重点包括:Telco Cloud, MSDC, Automation和OTT 网络架构。对最新热门技术,EVPN/VXLAN,Segment Routing,Contrail/NorthStar SDN控制器, Appformix云运营优化软件均有独到见解

  --------------------------------------------------------------------------------------------------

  1、介绍

  

  在1990年代Yakov, Eric Rosen, Kompella很多业界先驱(仅列举了Juniper公司的MPLS业界领袖,其他公司也有 很多Fellow推动MPLS发展)的引入MPLS之后,作为一个业务传送协议,MPLS取得了极大的成功。MPLS发展出很多不同的协议,简单的LDP/RSVP-TE,组播等,承载各种VPN业务,结合各种OAM功能,甚至扩展到光传输领域。

  为什么我们需要一个新的IETF协议来指挥MPLS转发呢? 下面会介绍一下这个名叫『春天』的IETF工作组。Source Packet Routing in Networking 简称为SPRING,也有叫做Segment Routing(段式路由),我们下文一般称为SR。

  

  在介绍SR之前,我们先来看一下SDN2.0.

  2008年左右提出的Openflow促进了第一代SDN的热潮,大家都想用Openflow(ACL)去控制网络中的应用流量。Openflow在数据中心领域取得了一定的成功。 扩展到广域网和运营商网络时有了一些Hyberid SDN的部署,也遇到了重重的困难。

  其中一个重要问题是Openflow对网络抽象不够,网络核心设备中网络状态信息随着应用数目的成指数增长。无法在广域网中得到大规模的部署。并且Openflow控制的网络,往往需要控制器控制路径中的多个关键设备,网络中的Touch Point增多,导致运维困难,信令压力增大。

  采用SR来作为传输协议的时候,SDN控制器仅仅需要跟Ingress PE通讯,在Source路由器上已经通过携带多个标签,定义好了完整的路径信息。网络中的Touch Point仅有一个,就能影响到这个应用APP流量的转发。同时网络核心设备中网络状态信息完全跟承载的应用业务无关。采用SR

  的运营商可以轻松的为百万级别的应用在头端(source)路由器选用不同的路径,同时保持核心设备没有任何应用状态。(Edge Intelligence, Stateless Core)。

  2、SR协议介绍

  

  SR的基本概念类似Lego,把网络分为不同的段(Segment),然后拼接起来。首先把网络分为三中基本组件。

  邻接段(Adj-SID),连接另一个路由器邻居,local有效。

  节点段(Node SID),指示如何到达另一个本地/远端(local/Remote) 路由器

  网段(Prefix SID),指示如何到达一个IP prefix.

  在头节点(Ingress Router)就用这不同的组件来组织一个完整的LSP Path。为了避免各个厂家设备采用不同的标签块,SR借鉴了传统的K.Kompella提出的BGP VPLS的基本概念。每个路由器宣告一个SRGB(SR Global Block全局块),在同一个区域(Domain AS/Area)中的每个路由器有个唯一的Index。

  以ISIS扩展的SR为例,每个路由器都可能会宣告这三种基本的SID(还有一些其他类型的SID,比如Anycast SID等)。

  每个路由器会计算SPF路径树,来构建节点段(Node SID)的一个完整路由器互联的拓扑(跟传统ISIS一样)。

  SR路由器继承了MPLS的转发平面,仅仅是优化了控制平面。采用IGP/BGP来分发标签,取消了之前的LDP/RSVP-TE。

  

  第一步,建立拓扑:下面介绍SR网络关键的第一步,如何建立转发表和拓扑关系。

  在一个支持SR的路由器里面,MPLS转发表会包含Node SID,Adj-SID 等(Prefix SID没有在图中显示)

  Node SID表:如果路由器都采用相同的SRGB,对于任何一个远端路由器在转发表中会有一个独特的In/Out label 完全相同,也就是说Label SWAP操作之后还是相同的标签。每个标签代表唯一的一个节点。如果是相邻节点的Node,会有POP操作。

  Adj SID表: 这个转发表也只有POP操作,所有收到的Adj label最后都被POP出来。

  总结一下,SR的转发表,如果是相邻的Node/Adj会被POP弹出标签栈。所有的Node/Adj/Anycast/Prefix SID 都是IGP扩展来宣告给其他的路由器。每个路由器收到Node SID进行SPF计算,计算出一个树型MPLS转发表(跟正常OSPF/ISIS计算出来的拓扑一样),路由器收到Adj SID信息直接产生Adj POP操作。

  

  第二步在基础IGP转发拓扑之上,控制器或者VPN等应用会来构建一个LSP Path,还记得前面提到,路由器收到Adj SID/相邻的Node SID label会POP出来,移掉最外层的标签。在图中的例子里面,如果在Node 11上加上4个 Adj Node SID,在1/7/4/14节点都会移除最外层的标签。最后把Payload发送到Node14节点上。同样你也可以在头端路由器压上Adj SID标签,这样每个接口转发之后移除一个标签。

  上述过程可以想象为一个行李标签,比如我定了个机票:新加坡到洛杉矶,我买了个复杂的机票:11(新加坡)-1(香港)-7(北京)-4(旧金山)-14(洛杉矶)在新加坡时候我checkin行李,会拿到香港-北京-旧金山-洛杉矶行李Tag,行李托运之后,在中转的每个城市取下一个行李Tag,最后行李安全到达洛杉矶。在每个城市,仅仅根据最外层的Tag转发到下个城市。在头结点(source)行李的路径已经确定。

  

  当然SR可以压多个标签栈,也可以类似RSVP-TE/LDP似的仅仅采用一个标签也可以Follow IGP达到终点。比如右边的图,可以采用标签114顺利到达节点14,中间的每个路由器都收到label114,然后转发出label114,继续下个节点,直到节点14pop。

  

  上图可以看出来,SR转发可以采用不同的混合机制,灵活的采用标签栈来指导每一跳的转发,也可以根据IGP路径采用一个标签来跨越一个很大的网络。也可以添加各种流量工程的策略,来进行ECMP转发或者避免哪些SRLG来转发。

  2.1 采用Anycast进行节点保护

  

  接下来介绍一个非常好用的功能,Anycast节点保护。

  传统的MC-LAG和Virtual Chassis功能作为节电保护,总是存在各种问题,多厂家无法互通,两个设备同样版本,设备间交换私有信息无法进行ISSU,无法多个设备备份,上下行流量保护问题等等。

  SR推出了一个全新的功能Anycast SID能有效的解决这个问题。你可以选用一组设备2+,每个路由器在发布正常的Node SID的同时,还发布相同的Anycast SID。这样在R1节点收到5100的标签时,R1就会发送给4个路由器中的任意一个(outlabel 8100)。假设A1收到8100,会Pop出来8100,A3看到8070。A3就转发给R2(keep8070)。R2收到8070之后会POP,剩下Payload转发。假设A1节点失效,R1会发送给A2/A3然后发送8070到R2。

  Anycast SID适用于任何拓扑,环形/Hub&Spoke etc.也适用于ABR/ASBR保护,同时适用于Seamless MPLS(后续会继续讲解)。

  2.2 100% TI-LFA节点/Link保护

  

  SR的另一大优点是可以提供针对任何拓扑100%的FRR保护。

  大家知道LFA和Remote LFA都只能覆盖80-90%的拓扑,针对复杂的环形网络无法提供100%的拓扑情景的支持。

  针对这种场景,Juniper最早提出了TI-FRR的解决方案。采用Target LDP和RSVP-TE结合的方式,可以做到100%拓扑的50ms快速重路由。

  解决的思路是计算PQ节点集合。P节点集合:从E1出发,可以达到的节点集合,不需要经过中断路径。比如{E2,E3}是P节点集合。从E1出发到E4就可能经过中断路径。

  Q节点集合:到达C1的节点中,不需要经过终端路径的节点,以C1为根计算的反向生成树,{E4,C2}是Q节点集合。

  如果采用普通的R-LFA,PQ集合没有交集,也就是说R-LFA就不能保护这个拓扑。采用TI-FRR需要直接在E1到Q节点创建一个RSVP-TE Tunnel,这样被保护的流量就没有microloop回来,到达E4之后采用Target LDP session来确保流量流向C1。从而TI-LFA可以做到100%的拓扑保护。

  采用SR的保护机制不太一样,在disjoint PQ集合里面,首先利用Node SID选择P(E3)节点,然后压上Adj标签(E3-E4),也就是告诉流量首先发送到E3,正常情况下有可能会回流到E1-C1链路。这时候SR要求流量到了E3之后,继续转发给E4。也就是两个label,两个动作确保了100% FRR.

  2.3 利用Binding SID扩展网络规模

  

  采用SR的一个很重要的顾虑是硬件能压几个标签?比如B厂商的商业芯片一次只能压三个标签,可能通过recircle来压多个标签但是会带来性能的损耗,同时带来其他问题。

  为了让SR可以在各种场合适用(比如运营商汇聚),SR开发了Binding SID。 通过IGP/BGP来发布一条SR-LSP(从R22到R30,标签栈为{332|331|330})的标签,假设这条SR-LSP的标签为510.在R21处只需压入两个标签{22|510},当R22收到22时pop标签22,露出来510,R22会把510去掉,同时压入3个标签{332|331|330},这样报文最后会抵达R30。

  通过Binding SID也可以实现RSVP-TE/LDP和SR的互通。还有LDP mapping Server等具体的办法就不详细介绍了。

  2.4 基于PCEP/BGP-LS的SDN控制器

  

  最早利用SR来支持SDN的想法来自于PCEP/RSVP-TE类似的做法。在控制器端计算完整的流量工程路径,然后把路径列表通过PCE带给路由器上的Client端(类似RSVP-TE ERO)。非常类似RSVP-TE,好处也明显,不需要沿途的路由器发任何信令去建立LSP(RSVP需要发送 Path/Reserve message)。

  

  首先介绍一下SDN控制器来使用PCEP建立SR-TE tunnel。

  非常类似RSVP-TE的PCEP LSP建立过程。控制器的PCEP会通知路由器上的PCC来协调能力,同时采用类似SR-ERO的方式来携带Label Stack,PE收到PCCreate LSP消息之后,不需要像RSVP-TE那样在多个路由器之间传递PATH/Reserve信令消息,仅仅需要下发label 堆栈信息。同时LSP创建的状态汇报通过SR-RRO来传递回去控制器。

  采用BGP-LS来传递TEDB,并携带SR label信息送回控制器。

  对于VPN业务的映射,可以采用PE-CE之间的Openflow/PBR/QPPB/BGP Flowspec 等。

  

  可以参考Juniper的SDN控制器North Star可以动态的建立SR TE-LSP,并且观测每个链路, LSP的标签信息。同时根据流量分布,可以动态优化SR LSP。

  2.5 SR和传统LDP/RSVP-TE的对比

  

  简单的对比一下SR和LDP/RSVP-TE。

  首先网络中间节点只需保留很少的网络状态,SR甚至不需要理解网络中的远端状态信息。比如节点3,不需要任何关于link 11-1, 6-7的Non-adj转发信息(而这些信息在LDP里面是存在的)。SR的基础转发表甚至比LDP更简洁。当然比RSVP-TE状态少很多。同时不需要LDP/RSVP信令来建立LSP, ingress node上出现不同的Label Stack组合,马上代表不同的路径选择。

  

  这张图比较了传统MPLS(RSVP-TE/LDP)和SR的多种情况,控制协议,流量工程,FRR,inter-AS/Area,扩展性, OAM,和SDN集成角度,SR有一定的优势。

  3、SDN的应用场景

  

  介绍SR的各种SDN应用场景之前,我先来介绍一下云计算如何来无缝对接SR,实现云网合一。

  先看传统的Underlay网络,由路由器,交换机,防火墙等组成,连接方式很固定,一旦配置了之后大概半年/一年都不会进行更改。 采用Ansible/Puppet进行配置管理之后,可能需要进行一系列的检测和排错。总之网络比较稳定,运维简单。

  但是新的云运营模式,需要全网转去DevOps模式才能适应云计算。

  DevOps能帮助客户在物理网络之上创建一个虚拟化的网络。APP/Dockers/VM能够更快的部署在全球网络上,并采用Scale Out的方式实现海量客户的接入,更灵活的做网络的变更。Overlay网络管理的不再是物理的设备,需要管理海量的虚拟路由器(vRouter),OVS,VNF (LB/FW/DPI)等。怎么去维护管理这个虚拟化的网络,需要一个SDN控制器帮忙。

  越来越多的客户采用SDN控制器来进行DC内部Service Chaining和跨DCI的选路。

  如果在underlay网络中部署SR,云服务就可以通过BGP-LU/PCEP/Netconf等协议来对Source节点进行编程,可以选择DC里面的Leaf/Spine路径,也可以选择DCI的SR-TE LSP来进行跨DCI的流量工程调度。

  SR标签可以包含:{APP|Docker|VM|Server }映射关系,还可以包含NFV label进行Service Chaining,还可以包含VPN Label,进行VPN隔离,同时还可以包含Label Stack穿越广域网。采用不同的label组合,在增加任何影响underlay核心路由器转发表的情况下,可以支持百万级别的应用。

  

  关于SR的应用场景,我们看到越来越多的客户选择四个不同的场景来部署SR,比如

  数据中心,拓扑比较简单,EBGP来作为IGP协议,同时采用同一厂商的设备,统一的SRGB来管理大规模数据中心。

  广域网在核心/边缘路由器上部署SR, FRR特性,同时减少Core Router的状态,采用BGP-LS来上送Controller网络的标签状态。采用BGP-LU,FlowSpec来控制流量 承载在不同的SR LSP。

  城域网在汇聚路由器,移动回传的网络中,采用环形网络,利用SR的100%拓扑,采用Binding SID来跨越多个Area/AS,并且采用PW来进行业务的承载,简化Cell Site设备协议,取代传统的Seamless MPLS。

  下面详细介绍一下各个Use Cases:

  3.1 SR在超大规模数据中心的应用

  

  在介绍数据中心应用场景之前,先介绍一种新型的BGP控制器来建立SR-TE LSP的解决方案。

  BGP-LU(RFC3107)在业界有多年成功部署应用,大部分厂商设备都支持BGP-LU,包括Metro里面的很多小型Cell Site路由器。

  传统的BGP-LU仅仅能够携带一个标签,Juniper的设备扩展了RFC3107,可以在控制器和设备之间传递多个标签栈。

  这里我们采用了非常简化的ExaBGP(Github免费BGP,https://github.com/Exa-Networks/exabgp)安装在笔记本电脑上,并且跟路由器建立简单的BGP-LU session。ExaBGP Controller来发送一个BGP 消息给PE1,这个BGP-LU消息携带四个标签栈。可以指导PE1创建不同的SR LSP转发表项。

  同时如果采用QPPB/BGP FlowSpec 来映射PE-CE之间的流量到BGP-LU创建的SR LSP上,就只需一个BGP协议,SDN控制器和路由器就能协商业务流的控制。

  

  现代大规模数据中心设计,Underlay刚刚经历了VLAN到VXLAN的演进,很多客户会问,为什么要在DC引入MPLS,为什么要引入SR?引入SR的几个主要的优点如下:

  1.越来越多的Overlay采用MPLS,比如Contrail采用MPLSoGRE,MPLSoUDP, EVPN+MPLS等协议。在广域网和DC采用相同的MPLS协议,带来的运维好处显而易见。比如DC GW不需要在VXLAN和MPLS之间进行协议转换(避免性能可能下降)

  2.同时由于Telco Cloud,越来越多的NFV采用MPLS VPN协议隔离。

  3.可以更好的指导Elephant Flow转发,避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源。

  4.可以更好的进行故障隔离,传统TCP Flowlet把网络变为黑盒,拥塞之后就会调低传送速率。如果能够理解网络中拥塞,不需要降低传送速率,仅仅需要重路由到非拥塞链路,会极大的提高App的传送质量。

  经典的超大规模DC设计,取消IGP(避免网络链路震荡,路由重算)构建基于BGP 的数据中心。请参考Juniper 白皮书, EVPN IP CLOS for Next Gen DC

  在超大规模数据中心里引入SR,是一个比较热门的话题。draft-ietf-spring-segment-routing-msdc在持续讨。草案里面定义的是基础Leaf/Spine架构如何用BGP-LU+SR来构建。我们这里来介绍一下端到端的VM/Docker是如何通讯的。

  Leaf 跟控制器建立BGP-LU(3107)session,传递vRouter Prefix SID的标签信息

  Leaf/Spine建立BGP-LU session,传递Leaf labels, Spine不需要跟控制器建立session。

  控制器创建VM/Dockers时,在vRouter上给分配标签,通过BGP/XMPP上送到控制器

  在Ingress vRouter上压入三层标签栈,就可以找到egress (TOR,vRouter, VM)

  

  有了这套完整的SDN 控制器体系,配合广域网SDN控制器,可以很扩展到DC互联。在DC互联中,可以采用的技术有如下:

  SR可以很容易的利用Node SID来实现ECMP,可以利用Adj SID去精确指导选用哪条Link。

  可以利用SR的Anycast SID去保护DC GW和广域网路由器

  在图中例子可见在Ingress vRouter标签栈依次为:{ DC1 | DCI A-B-C | DC2 | DC2 vRouter | DC2 VM}, 需要说明的是,即便可能压入8-10+个标签,报文头还是比VXLAN(60-70 bytes)小。

  3.2 基于SR 的Cloud Peering应用

  

  传统的流量工程仅仅 关注在IGP域部分,越来越多的企业迁移到云服务。如何找到没有拥塞的BGP Peering提高网络云接入能力?基于SR的BGP EPE能提供一个更好的解决方案。

  ASBR通过BGP-LU(3107)跟控制器建立BGP邻居,并且给每个Peer分配一个标签。

  ASBR通过BGP-LS, Netflow, Telemtry把流量信息上送到控制器。

  控制器计算最优路径(latency/bandwidth/optical SRLG etc)

  控制器在头结点压上多个标签,外层SR标签找到ASBR,内层BGP-LU标签找到Peering,外层隧道也可以采用GRE/LDP等。

  在BGP EPE转发路径上有个比较特殊的属性,从AS内部到peer的转发,不需要查询路由表,仅仅需要MPLS转发。利用这个特性可以采用新型态的LSR /Lean Core设备做Internet Peering。

  

  完整的看一下数据中心和WAN的统一控制器,可以控制从数据中心服务器发出的流量,选择不同的ASBR,不同的BGP Peering,从而避免拥塞。 从Internet进入到数据中心的流量,控制器可以监测VM/Dockers的运行状态,从而在ASBR开始压上不同的VM标签,数据流量可以根据VM/Docker分发的不同标签来进行负载均衡。

  3.3 基于SR 的下一代接入网

  

  对于运营商来讲如何降低接入网的成本,是一个首要问题。对于采用SR的cell site 路由器,可以实现最小的协议支持,同时承载各种VPN业务。网络的传输部分简化为ISIS协议,网络的业务部分采用BGP承载VPN,甚至采用BGP FlowSpec来映射客户流量。减少Cell Site Router的协议复杂度,就会增加网络可靠性,可维护性。

  

  主流厂商多年前就已经支持Seamless MPLS(UMMT)的Mobile Backhaul解决方案。方案采用RSVP-TE做接入环网的保护,BGP-LU为多个区域粘接在一起,提供端到端的LSP隧道。加上VPN标签,和FRR标签,需要4个标签(经常导致B厂商的商业芯片无法只支持三个标签)。

  如果采用SR,可以利用协议简化机制,利用100% FRR保护,利用Anycast SID保护汇聚节点,利用Binding SID在汇聚设备扩展SR LSP跳数。

  SDN最早起始于数据中心,就是因为要管理很多TOR和Server。很多客户有上千台Cell Site路由器的规模,引入SDN控制器,并且采用ZTP自动部署SR。越来越被主流运营商接受,成为运营商采用SR的一大驱动力。

  3.4 基于SR的Telco Cloud

  

  传统运营商建网思路是以连接性为目的,买路由器,传输设备,提供管道,连通性。网络架构基本不具备智能。

  随着5G,虚拟现实,IOT,HealthCare等业务越来越多的业务承载在运营商的网络上。低延时,大带宽,大规模业务,需要运营商建设更多的Micro Data Center,更加靠近客户和应用。驱动运营商的网络从传统的连通(PIPE)导向的建设思路,转型到建设运营商云服务平台(Telco Cloud) 上来。

  为了应对新业务的出现,很多业界运营商转变思路借鉴了许多OTT的建网思路实现以超小(Micro),Ultra Low Latency数据中心为网络建设的重点。比如为应对VR/Health Care/自动驾驶等业务的低延时,大数据量应用(自动驾驶汽车需要视频识别,可能每秒钟产生1Gbps的流量),必须要建设全分布式,超小型数据中心更加靠近终端用户 。

  

  把数据中心DC Fabric网络架构应用到城域网,建设很多SP Fabric,通过SR无缝连接起来称为Telco Cloud架构的基础。

  典型的Telco Cloud在SP汇聚层会采用BGP-SR添加很多小型数据中心。在SP数据中心中Leaf节点有不同的工作职责:

  A-Leaf用来接入用户,比如ONU,Wifi,BNG客户等

  C-Leaf用来接服务器,用来虚拟化vEPC,vFW,vDPI, vOLT, vBNG 等

  P-Leaf用长距光模块做互联。

  采用BGP-SR在SP Fabric,Metro利用OSPF SR,提供端到端的SR LSP,业务采用EVPN承载。

  3.5 基于SR的网络虚拟化NFV Service Chaining

  

  网络虚拟化也是运营商最热门的话题。网络分块(Network Slicing)和业务链(Service Chaining)也越来越重要。Service chaining表现出新的趋势:

  不光局限于骨干网DC,往往分布在Front Haul的Micro DC(小微),在城域网BNG附近的中型 DC,和国家骨干网DC分别处理不同的虚拟化业务。

  Service Chaining可能无法在一个数据中心处理完毕,需要在城域范围内跨越多个DC。

  业界有厂商引入特定的NSH(network service header)头来支持业务链,但是采用专用报文头可能会带来两个问题,很多VNF(比如vFW, vEPC etc)不支持NSH,大部分硬件交换机无法支持NSH。

  由于SR可以指定访问网络中的任何节点(通过多层标签栈),同时大部分的虚拟设备和物理设备都可以支持MPLS转发平面,所以很多客户想要采用SR来支持Service Chaining。

  4、总结

  

  前面介绍了很多SR的应用场景,作为一个underlay技术,SR可以广泛应用在网络的CPE/Access/Edge/Core/DC里,同时更好的支持SDN/NFV.

  最早美国的很多Web/OTT公司Google, Microsoft非常感兴趣SR。还有一些欧洲美国的TOP SP,ATT/Comcast等,最近在亚太区,中国的OTT,日本Softbank/NTT/KDDI,加上澳洲的Telstra都很感兴趣,SR在2017会有更多的客户采用,部署。

  

  最后,分享一下最近的SDN/NFV感想。

  最早SDN起源于数据中心的Openflow,目标是通过动态配置管理上千台TOR/Server,建立连通性。数据中心基于简单拓扑,物理冗余性,交换机功能简单,网络超配, SDN Controller不大需要关心网络资源,流量状况。Automation(自动化)称为SDN控制器的最主要特性。

  随着SDN影响越来越大,SDWAN, WAN SDN, Cloud SDN需要 SDN/NFV控制器来更好的理解流量和资源分配状况,这时候需要通过Openconfig/gRPC 搜集Telemetry 信息,上送控制器。原始的信息很难被控制器理解,越来越多厂家在SDN控制器之上加入机器学习,人工智能部分,更好的指导控制器进行网络自动化。

  举个例子,Juniper最新Appformix解决方案,用来优化Openstack云部署环境,采用了机器学习,当部署新的VM/Docker时,Appformix注意到,尽管某个Server的CPU负载很低(只有20%)但是那些L3 Cache资源已经不足,Appformix会进行迁移把现有的VM移到L3 Cache充足的Server。当有个新的VM/Docker部署要求时,最简单的就是给他分配一个新的Server,但是新的VM/Docker也许和现有的一个VM有很多交互,share相同的资源,如果把新的VM/Docker部署在现有的Server上,而不是每次都分配新的server,可能整个应用更流畅。

  从上面的例子可以看出来,现有的SDN控制器仅仅是算是机械手,引入人工智能,引入Telemetry更好的理解网络。形成一个闭环的SDN自愈合控制系统。

  前面讲到的各种SR的网络优点,可以看出来采用了SR的智能边缘,无状态核心设备的网络基础架构,不但理解Underlay网络架构,同时理解Overlay云端应用,促进云网融合,会成为今后SDN/NFV发展的坚实基础。

  Juniper的网络远景是打造『自驱动的网络架构』-“Self-Driving Network”

  Q&A

  Q1:使用MPLS/SR,相比VXLAN,如何能避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源呢?

  A1:如果采用SR,可以给Leaf/Spine里面的16路/32路 ECMP,每条link分配一个不同的Adj SID,同时监测不同ECMP link的链路利用率,这样就可以避免资源竞争。比如Google要求在网络中的telemtry流量统计,最小可能10ms这种级别。这样控制器在收到大量的信息之后,通过机器学习算法,动态调整/预测网络的拥塞情况,从而避免。最小10ms,正常100+ms级别,这样还有机会影响流量

  Q2:这样做是否与flowlet不兼容,两者只能选其一?

  A:是的,可以在server端用flowlet做优化,也可以在控制器层面,下发不同的Adj SID在交换机层面,来做负载分担

  Q3:anycast那部分我也没有太看明白,例子里anycast sid是 100,为什么出标签8100?

  A:Anycast的ID是100,但是他们的SRGB,(SR 全局块)起始标签是8000,所以标签是8000+100.

  Q4:我没太听明白您说的SDN和segment routing的关系,您是把segment routing当做一种underlay技术,用来实现SDN呢,还是说在SDN上实现segment routing有先天的优势?

  A:两个层面的SDN,如果说网络的SDN,segment routing可以帮助选路,也就是我们Juniper的North Star,做流量工程,Cloud Peering等等。 如果说Cloud SDN,比如juniper的contrail,SR可以灵活的实现VM/Docker的通讯(通过contrail vrouter)。当利用Cloud SDN的时候,可以通过segment 的基础架构,更容易的连接Cloud里面的APP

  

  现在Telco Cloud, NFV里面采用了很多的label来做VPN隔离,VNF隔离等。这时候采用SR会有一定优势

  Q5:DC + DCI 的客户案例(pilot ok) 有了吗? 是OTT and 运营商?

  A:DC+DCI的应用场景,一般是运营商SPDC和OTT。跟Microsoft SWAN和Google B4,差不多,都是一个控制器,端到端来控制VM,控制ASBR,只不过SWAN准备用SR做,B4现在用GRE做,今后转向SR。

  Q6:在J看来,BGP-LU和SR是竞争关系吗?两套控制面吧,一个是BGP一个是IGP

  A:SR的信令协议,可以采用IGP(OSPF/ISIS)或者BGP,BGP还有个新的draft BGP SR-TE也会比较popular。BGP-LU是juniper用的多,SR的一些基本概念可以用BGP-LU来实现。

  Q7:关于三个SID我还有些小疑问哈,Node SID 和 Adj-SID 二者是什么关系呢,都是由控制器来分配的吗,是不是说相隔多跳的两个路由器有可能分配相同的Adj-SID呢?Prefix SID是什么作用,如何工作呢?这三者是网络中的每一跳都会具有的吗?

  A:Node SID是loopback一个路由器一个,Adj SID是相邻的接口(Adj),假设路由器有4个物理接口,其中有3个有SR的邻居,那么Adj SID就有3个。相隔多跳的路由器很可能有相同的Adj-SID,比如大家都共享一样的SRGB,第三个接口的Adj-SID就是一样,但是也没有关系,因为Adj-SID是local有效的。Prefix-SID不是必须的,比如客户仅仅是做traffic engineering,所有的traffic都是VPN traffic,这样就不需要prefix SID,只有IP traffic over在SR上的时候需要prefix SID。还有客户实现只有Node,或者只用Adj的网络。

  Q8:比epvn控制平面的vxlan有哪些好处呢?

  A:对比EVPN+VXLAN,采用SR的好处,1. VXLAN报文开销太大,我前面提到压7-8(30+bytes)个标签之后,报文头还是比VXLAN小(68 bytes). 2. WAN/DC 都采用相同的MPLS转发平面,3.不需要在DC GW那里做VXLAN到SR的转换。4. Telco Cloud里面的vRouter比如contrail天生携带MPLS 标签,VNF也是靠label来区分的,也就是说在Telco Cloud里面,即便用EVPN+VXLAN,最后也有MPLS Label,Telco Cloud更prefer用EVPN+SR。

  Q9:这个你跑通了吗。 去年我试过,没有成功。

  

  A:没问题,跑通了,我们有个白皮书,公开资料,回头可以发给大家,如果用BGP-LU来控制SR的不同路径

  Q10:想问下Prefix SID是什么作用,如何工作呢?

  A:Adj SID是个标签,prefix SID,这里没有太多介绍,可以想象为ASBR,使用BGP prefix SID,这样为这个SID分标签的时候,就要找到ASBR,同时压上prefix SID的标签,前面提到,IPoSR的时候需要prefix SID,如果是VPN traffic,只要Node或者Adj就足够了,还有客户实现只有Node,或者只用Adj的网络。

  Q11:exabgp的性能是个问题啊。只能做demo

  A:可以用vMX,最近出了个route server版本,全面开放编程接口JET,全路由,SR/MPLS编程接口

  Q12:能介绍一下Telemetry方面的标准,协议和关心的具体NFVI和VNF的哪些参数嘛?

  A:关于Telemetry,回头可以找个时间好好介绍一下,再介绍/Demo一下juniper的一个非常好用的开源工具Open NTI https://github.com/Juniper/open-nti

  Q13:在SR的实现上,CONTINUE动作被映射为MPLS 的SWAP,Next动作被映射为Pop,那么是不是说SR里的每个segment都需要被定义为一条LSP呢?

  A:Segment只是lego的基础,本身不会很多,多少个邻接,多少个node就有多少个segment,比如prefix segment数量可能很多。每个LSP可能包含多个segments,LSP的数量可能多余segments

  Q14:NSH传统SFC方法,要求SFC支持NSH头,但是像SR这种头是可变长的,例如一个firewall vfunction,一定要parse完才知道到栈底,从这点来看,我觉得他对SFC的支持并不是那么好,请问你的看法是什么?

  A:SFC支持NSH,除了Edge设备,或者vrouter,很难支持,采用SR来做,可能中间处理vFW的时候,还有多个标签(后续的VNF处理)但是找到栈底的处理不难

  Q15:vMX 怎么发 SR 的LSP啊?我记得onos有SR for DC 的项目

  A:这个是VM可以通过JET开创建多个label的SR LSP,我们给中国一个著名的OTT做了个Demo,本来我要介绍的,因为时间关系就取消了。 ONOS的那个项目是2014年的,拿Dell的交换机,用Openflow创建了个Segment Routing的网络,很古怪的想法,demo在youtube上可以找到,当时还比较原始,Openflow还只能最多压3个标签,ONOS做了个recircle可以压多个,但是性能很差

  Q16:openflow + SR..... 我的理解 Telstra 的 SDNWAN 项目也在用 open flow + SR.... 感兴趣open flow在这场景下的具体怎么与SR分工协作的,这方面有insights吗?

  A:我知道的Telstra SDWAN,很快会上线25个客户。采用跟ATT一样的CPE设备,采用netconf来配置,上行接口还是MPLS,只是考虑SR,还没有开始商用呢

  Q17:recircle指什么?芯片吗?还是流表的recircle?

  A:对,Openflow一个action可以压3个,如果需要压多个,就把多个ACL串接起来,就是ACL的最后一个action还去应一个ACL,这样就可以压多个,同一个报文要过多遍的芯片流水线

  Q18:请教一下目前Juniper的路由器标签能支持多少个

  A:硬件可以支持很多,比如MX,一个DE说最多可以支持压30+标签,PTX至少8+个,标签栈的深度不是问题,比如在DC里面,和Core里面转发都很简单,不会看到那么多标签。vRouter和MX的位置,处在网络的边缘,需要压多个标签

  Q19:open NTI 支持其他厂商的设备吗?

  A:我们全力支持兄弟厂家,包括大河

  Q20:SR的底层支持来自于MPLS,segment routing的continue动作被映射为MPLS的Swap操作,next动作被映射为MPLS的Pop操作。那么是否相当于网络中的每个prefix-ID,adj-ID和anycast-ID都需要被定义为一条LSP。

  如果是这样的话,相比于传统的MPLS,采用segment routing的方法,LSP的数量和转发标签的数量会不会变得更多,增加网络的复杂性和管理开销。

  A:其实有一张图说的比较清楚,采用SR之后,路由器的转发表比LDP还小。

  

  因为是文字分享,没有办法详细解释,你看这张图,比如LDP会保存远端Adj的转发信息,而SR仅仅保留相邻的信息。在SR里面路由器3,不关心link 11-1,link11-6等信息,在LDP里面都有。

  其实SR解决的是Core核心设备无LSP状态,边缘的设备,可以有很多SR-LSP的标签,如果你支持很多APP,每个APP走的路径都不同,当然有很多状态,但是介绍中也说了,一般Edge的LSP可以用SDN控制器来管理。

  在头结点,一个IP prefix查表的结果是一个压上一个label stack,你可以把它叫做转发表项里面的LSP,在控制平面,你有一个PCC客户端收到(PCEP配置的SR LSP)在控制器里也有。。你说他是LSP么?可以叫做SR LSP

  Q21:SR简化了core的配置之后,如果出现了故障, 传统的troushooting方式可能无效了, 是不是说在application里也要集成一些用来排错的工具?

  A:非常好的问题,比如采用PCEP的SR和采用PCEP的RSVP相比确实省去了中间Core的状态,但是SR无法track每条LSP的状态(是否真实走到要求的路径),也无法通过PCEP把流量状态带回控制器,确实需要一些APP层面的监控,还有端到端的OAM,比如seamless BFD等等

  Q22:请教一个问题,vxlan+evpn可以一个vpn同时是l2,l3转发。sr是也能实现这个功能吗?

  A:没有问题,SR+EVPN也可以实现EVPN的Type 2+Type5,L2/L3 IRB同时转发

关键字: MPLS
  • IT168企业级IT168企业级
  • IT168文库IT168文库

扫一扫关注

行车视线文章推荐

首页 评论 返回顶部