SRv6技术课堂:SRv6可靠性方案(二)

作者简介:
胡志波 华为SR与IGP高级协议专家。负责华为的SR与IGP协议规划和创新工作。
目前主要从事SR/SRv6协议以及5G切片相关技术的研究。自2017年起积极参与IETF标准创新工作,主导和参与SRv6可靠性保护,SRv6 Yang, 5G 切片,IGP协议等相关标准。致力于通过SRv6协议创新支撑网络向5G,云化的演进。
李振斌 华为首席协议专家/IETF互联网架构委员会(IAB)委员。负责华为的IP协议研究和标准推动工作。自2009年起积极参与IETF标准创新工作,主导和参与了大量IETF RFC/草案。在过去六年内持续推动了SDN演进的BGP/PCEP/Netconf/YANG的协议创新和标准化,当前研究的重点包括SRv6、网络智能、Telemetry、5G承载等。2019年当选IETF互联网架构委员会(IAB)委员,承担2019 - 2021年的互联网架构管理工作。

本文为《SRv6可靠性方案》第二篇,第一篇详见《SRv6技术课堂:SRv6可靠性方案(一)》。

3 SRv6 Endpoint故障保护

在TE场景中,我们经常要约束中间的转发路径,会在报文中指定沿途要经过的节点或链路。如下图所示,节点A要发送报文到节点F,约束中间要经过节点E,当节点E故障的时候,我们可以看到主和备路径都经过节点E,无法达到保护的效果。

图1-1 TI-LFA保护失效场景

这里我们介绍SRv6 Endpoint节点故障的保护方法。从前文我们了解到,Endpoint节点处理SRv6报文,要执行的转发行为都包括SL减1,并将下层要处理的SID拷贝到外层IPv6头。但当Endpoint节点故障的时候,它就无法完成该指令的处理,所以我们需要它的上游节点代替它完成这个转发处理,代替它完成该处理的节点我们称之为Proxy forwarding(代理转发)节点。Proxy forwarding节点感知到报文的下一跳接口故障的时候,并且下一跳是报文目的地址,SL > 0的时候,Proxy forwarding节点执行Proxy forwarding行为,代替Endpoint节点执行End行为,SL减1,并将下层要处理的SID拷贝到外层IPv6头,然后按照下层SID进行转发,绕过故障节点,这样就实现了SRv6 Endpoint节点故障的保护。

图1-2 SRv6 Endpoint节点故障保护

下面我们以上图为例,来看看SRv6 Endpoint节点故障的保护过程:

  1. 节点A转发报文给目的地址F,并在SRv6扩展头指定经过中间节点E。
  2. 节点E故障的时候,节点B感知到报文下一跳接口故障,而且自己是目的地址5::的倒数第二跳,SL > 0。所以,节点B执行Proxy forwarding行为,SL—,并将下层SID 6::拷贝到外层IPv6头,由于SL=0,POP SRH扩展头,然后根据目的地址6::查表转发。
  3. 由于目的地址6::的下一跳依然是节点E,但是节点B不是该目的地址的倒数第二跳,SL = 0,所以不执行Proxy forwarding行为,而是按照正常转发流程切换到备份路径转发,备份路径的Repair List为3::1,所以节点B插入SID 3::1,走备份路径转发到节点F。
  4. 当节点A的IGP完成收敛以后,节点A删除到节点E 5::的路由转发表项,所以节点A根据5::查表转发的时候,无法命中路由,这个时候节点A就要作为Proxy forwarding节点执行Proxy forwarding行为,SL—,并将下层SID 6::拷贝到外层IPv6头,然后根据目的地址6::查表转发到B,这样绕过节点E,到达目的节点F。

为了支持SRv6 Enpoint故障保护,我们在SRv6 SID转发伪码里插入一段转发流程(参考draft-chen-rtgwg-srv6-midpoint-protection),用于指导Endpoint节点故障时SID执行的Proxy forwarding转发动作。

初学者很难搞懂普通TI-LFA和Endpoint保护的区别,我们用一张图来讲解两者的区别,如上图所示,结点A发送报文携带Segment List:,如果根据TI-LFA计算的备份路径,由于TI-LFA是根据报文目的地址计算一条备份路径,我们可以看到TI-LFA备份路径也是经过结点E,所以如果结点E故障,普通Ti-LFA是没有办法保护的。而SRv6 Endpoint保护是根据下层Sid计算的备份转发路径,所以,它能绕过故障的Endpoint结点,从而实现了SRv6 TE的Endpoint结点故障保护功能。

4 尾节点保护

下面我们来介绍PE节点故障的FRR技术。业务报文必须要在PE节点进行终结才能往CE转发,因为P节点不会维护到私网的路由表。所以,必须要在CE双归属的网络架构中通过冗余保护才能保护PE节点故障。当前有两种方法可以实现尾节点保护:Anycast FRR和镜像保护,下面分别进行介绍。

Anycast FRR

Anycast FRR方法是在CE双归属的PE节点配置相同的SID来实现FRR。

图1-3 Anycast FRR保护

如图所示,CE双归的PE节点F和G配置相同的Locator和VPN SID,节点C预安装到目的地址7::备份路径,主路径为C->G,备份路径为C->D->F,计算的Repair List为4::6,故障前,节点C将报文转发给G,G执行VPN SID的转发行为,通过AC侧接口转发到CE节点。节点G故障后,节点C感知到下一跳直连接口故障,快速切换到备份路径,封装Repair List 4::6,报文转发到F。由于节点F和节点G VPN SID配置为一致,所以节点F也能处理7::1,查找本地SID Table,通过AC侧接口往CE转发。

Anycast FRR能够实现PE节点故障的保护,但是Anycast FRR存在如下问题:

  1. 需要静态指定VPN SID,因为需要保证两个PE的VPN SID一致。
  2. 受限于IGP层面的优选,无法进行VPN层面的选路。例如,如果VPN希望在节点F和G形成负载分担,或者优选节点G。但IGP到7::的路径优选的是节点F,没有办法控制VPN层面的选路。
  3. 当AC侧接口故障的时候,例如,节点G到CE的链路故障的时候,报文还是会转发到G,然后绕行到F,会产生流量的绕行,而且无法恢复。
  4. 当出现插花组网的时候,不同的多归集合需要规划不同Locator,难以部署。

镜像保护

鉴于Anycast FRR存在的一系列问题,下面我们介绍另外一种尾节点保护技术:镜像保护。因为在双归PE的场景下我们可以认为这两个节点可以提供相同的VPN转发服务,所以这一对PE节点可以配置成镜像组,并通过IGP把镜像关系在网络里扩散。当镜像组某个节点故障的时候,可以通过FRR到达镜像组的其他节点,以达到快速收敛的目的。

如下图所示, L3VPN over SRv6 BE场景,CE双归到节点G和节点F,节点G和节点F分别配置Locator为6::/64和7::/64,VPN SID 为6::100和7::100,同时节点F针对节点G配置Locator 6::/64的镜像SID(7::1)。节点F收到节点G发布的VPN路由的时候,会根据Mirror SID的配置生成双归PE的VPN SID的镜像表:7::1,6::100 <->7::100,这个镜像表表示7::1,6::100这两层Sid和7::100这个Sid是等价的。

图1-4 Mirror SID尾节点保护

节点F配置Mirror SID的时候,会在IGP发布一个Mirror SID TLV,同时携带该Mirror SID要保护的Locator。draft-hu-rtgwg-srv6-egress-protection-03定义了ISIS Mirror SID TLV协议扩展的范例,其格式如下图所示:

图1-5 Mirror SID TLV格式

Mirror SID TLV作为SRv6 Locator TLV的子TLV发布,同时,该文稿还定义了End.m的转发行为:

IGP网络节点收到该TLV以后,会做如下处理:

如果接受到TLV的网络节点是被保护Locator对应节点的直连节点,该节点计算Mirror SID要保护的Locator路由的备份路径的时候,会使用Mirror SID作为备份,也就是将流量引导到作为该节点的镜像保护的节点。如图所示,节点C在计算路由6::/64的备份路径的时候,会使用7::1作为Repir List作为备份路径的最后一个SID,从而将流量引导到节点F,同时Repair List会增加到节点F针对故障点G的Repair List,4::6,这样节点C计算出来的Repair List就是4::6,7::1.

Ingress PE节点A该VPN路由优选下一跳节点G,目的地址封装6::100(VPN SID)转发到节点G,节点G根据6:100索引到对应的VPN转发表,根据内层IP目的地址查表转发到CE。如图1-21所示,当节点G故障时,节点C先感知到故障,激活备份路径,封装Repair List: <4::6,7::1>,指导报文无环转发到节点F,节点F根据7::1查到本地SID是1个Mirror SID,根据下层SID 6::100查映射表,映射到本地7::100,然后根据7::100关联的本地VRF表按内层IP地址查表转发到CE。

相对于Anycast方式实现尾结点保护,Mirror保护方案不要求双归PE配置相同Locator,所以保留了Overlay层面选路的能力,同时AC侧故障头结点PE能进行收敛。

(未完待续)


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/23807.html
分享到:
相关文章
条评论

登录后才可以评论

SDNLAB君 发表于19-12-24
2