• SRV6基础（二）
  • SR的起源
    • SDN初了解
    • SR与SDN
    • SDN与CNF
  • SR的设计
    • 初探SR-MPLS、SRV6报文
    • “前浪”们的问题
    • SR的初设计
    • SR的设计（改进）

SRV6基础（二）

SR的起源

SDN初了解

一切要从SDN开始谈起，最早的时候软件定义网络的概念掀起浪潮，那什么是软件定义网络？我们怎么去理解软件定义网络？

这里的软件不是指的APP，而是指的是“可编程性”，网络可以被编程的，这一点很好理解呀？我们传统命令行配置接口IP地址的时候，通常这么配置：

# Huawei
system 
interface g0/0/0
	ip add 192.168.10.10 24

如上所示，配置一台网络设备需要专业的人员打这么多的单词命令，那有没有更简单的办法呢？当然有了，比较说图形界面，我们在图形界面上对接口点一下，然后写入IP地址，这样也行，图形化界面自动将图形当中操作转换为命令行自动执行，这就在一定程度上由软件（图形界面）定义了网络（自动产生配置从而配置网络）呀！

那从这个角度我们再来理解什么是软件定义网络，通过一个软件平台（如上文当中的图形界面），我们稍稍配置一下，表明自己的“意图”，然后此平台会通过程序员编写好的程序规则自动产生网络配置，下发到网络设备当中，从而达到配置网络或定义网络的目的。

基于以上理解，我们知道SDN网络当中一个相当关键的东西就是上文提到的软件平台，这个软件平台最好能够同时配置大量的网络设备，最好还带有一些管理运维功能。SDN当中最核心、也是最重要的概念我们就讲完了，总结一下，SDN的关键核心就是有能统一管理和配置网络组件（不仅仅指网络设备）的软件平台。

SR与SDN

SDN的概念大火，基于SDN的协议也相继开发，其中包括了P4、segment-routing（SR）、openflow，SR是SDN的“亲儿子”，SR是怎样通过SDN开发出来的呢？SR与SDN之间又有些什么关系呢？这两个问题我们可以简单地理解，既然SDN的核心就是要有一个控制器来管理网络组件，那如果开发了一个协议或软件支持被控制器统一管理，那是不是就能说这个协议或软件就是基于SDN的呢？可以，当然可以！我们在初期就可以这么理解SR与SDN的关系，SR就是能被控制器进行管理，它符合SDN的核心概念，所以说SR就是基于SDN开发的。

SR支持被控制器进行管理配置，SR是通过SDN概念实现的，SR继承了SDN的：

• 可编程性，这么说不太准确，应该是迎合了控制器的可编程性；控制器软件支持可编程，而SR支持被可编程后配置或数据。
• 可就将自己的控制层面交给控制器进行管理，自己只负责转发，也就是转控分离。

SDN与CNF

网络行业的内的SDN概念大火的同时，运维领域当中也有一个概念大火，云原生（CNF），我们如果去学习云原生的课程，我们一般会学到比如Prometheus，为什么Prometheus就是基于云原生的呢？到底什么是云原生？我们仅仅拿一个很小的方面讲一下。当一个软件在容器内运行时，我们想修改软件的参数配置，那传统软件一般就是进入到容器当中然后再进行修改，而甚至云原生的的软件就明确了自己将来使用场景就是容器，那此类软件在设计的时候就考虑到了用户需要经常修改容器内参数的问题，它会让用户可以非常方便的在容器外就可以修改软件参数，这类软件我们就可以简单地将看做为云原生软件。

SR的设计

初探SR-MPLS、SRV6报文

SR-MPLS是可以直接在当前基于IPV4的网络下进行增量部署的，IPV4的传统报文无法承载标签，所以数据平面依然使用MPLS去承载SR的标签，也就是说SR当中产生的“标签”在进行报文传输时依然是通过MPLS层进行体现的。而结合IPV6的SR（SRV6），IPV6报文本身有专门为SR设计好的存放SR标签的数据单元，所以SRV6报文当中不再有MPLS相关的体现。

“前浪”们的问题

• MPLS-LDP的问题在于LDP太依赖于IGP，所形成LSP路径不是最优的路径；
• MPLS-TE当中的RSVP的问题虽然自己拥有了数据库可以进行路径计算，但依然依赖于IGP，与IGP之间依然是分离设计，且TE隧道需要通过大量的报文进行保持。

SR的初设计

SR的设计我认为分为两个大的方面：

1. 迎合SDN，即随时可以将自己的控制层面交给控制器、支持控制器通过可编程性下发的配置
2. 真正要解决“前浪”遇到的问题

关于第一点，我们在前面已经提到过了，我们这里面重点来谈论一个第二点，SR要解决什么问题？前浪们的根本问题是什么？我认为MPLS-LDP与MPLS-RSVP最大的问题就是与IGP之间配合问题。LDP和RSVP始终不能抛弃IGP；反过来说也一样，IGP始终只能做最底层，也就是overlay的工作，它无法完成MPLS-LDP或MPLS-RSVP的工作，这种矛盾的问题通常有几下几种解决思路：

1. 第一：让IGP拥有MPLS的功能，能够自己自己分标签，建立LSP路径；

2. 第二：让MPLS拥有IGP的功能

3. 第三：重新设计一种机制，推翻IGP和MPLS，自己本身同时实现IGP和MPLS的功能

   ……

SR的设计是哪一种呢？哪一种不都不是，SR是第三种与第一种的结合体，SR重新设计了一种类似MPLS-LDP的机制，但这这种机制与MPLS-LDP不同的是他不会直接参与LSP路径的建立，它只会提供一些类似标签的东西，然后将这些东西交给IGP，所有路径建立都由IGP自己说了算，所以不会出现前浪们出现过的两种机制配合不好的问题，同时IGP还负责它本身的任务。

你可能有疑问了，MPLS-LDP时期路径是IGP说了算，MPLS-TE时期是RSVP说了算，前者路径不是最优秀的，后者需要大量的报文维持路径，那当前这种SR+IGP的方式就完全避免了这两个问题吗？解决了，它是怎么解决的呢？

在SR方案当中由于决策者是IGP，SR进程仅给IGP提供类似标签的东西，IGP本身是通过路由产生路径的，并不需要你RSVP-TE一样需要大量的报文维持路径，这一个问题解决了，但IGP本身形成的路径不是最优秀的，这是硬伤，这个问题怎么解决？别忘了，我们前面提到过，SR是支持把控制层面交给控制器，SR会将IGP收到的链路、带宽、开销的信息全都上报交给控制器，让控制器在一个全局客观的角度，结合大量数据，通过算法计算出一个路径，然后将这个路径下发给SR，SR再交给IGP，这个路径通常就是最优秀的路径了，那这个问题不就解决了嘛！

OK，那我们来总结一下：（下图仅仅是我们推理用到的简图，不是SR最终架构图）

上图当中有两台路由器A和B，现在两台路由器都启动了IGP-OSPF和SR进程，SR进程会率先启动收敛路由器A的信息，这些信息由管理员给定或控制器也可以推送下来，这些信息是什么呢？其实很简单，我们后续再谈，暂时我们把些信息理解为就是描述路由器为自己、为自己的链路分配的标签信息，把这些信息交给IGP，IGP会通过泛洪的方式把这些信息交给路由器B，路由器B收到之后会根据这些信息形成LSDB或TEDB，最终计算出路由表，那路由器B就知道了，去往路由器A上的网络要封装的“标签“、下一跳、出接口等信息；

同样的，路由器A也会收到路由器B的，最终路由器A和B上的LSDB或TEDB是一样的，都是对当前网络拓扑的描述信息。

OK，那我们接着说（下图仅仅是我们推理用到的简图，不是SR最终架构图）

如上图所示，第一步我们说完了，我们直接从第二步开始。

第二步：SR会把LSDB或TEDB(IGP收到的信息形成的数据库)，直接发送给控制器；

第三步：控制器同时拥有了A、B、C的LSDB，由于三份LSDB是一样的，其实控制器有一份就行，控制器再给QOS等组件收集的信息，分析之后计算出路径；

第四步：把路径下发给路由器

第五步：路径最生形成路由表，用来指导路由转发

SR的设计（改进）

我们继续向推理，上面的设计存在的疑问：

1. 如果所有的路由器都直接上报LSDB或TEDB给控制器，控制器的连接太多
2. 路由器是通过什么协议上报LSDB或TEDB的？
3. 路由器的初始配置是怎么来的？难道是人工配置的吗？
4. 控制器下发路径的时候使用什么协议？与上报是一个协议吗？

第一步：控制器上线，在控制器上规划网络，生成ZTP文件

第二步：将ZTP文件导入新上架的路由器上，路由器向前控制器进行注册，管理通道Netconf通道形成（绿色）

第三步：控制器通过Netcof推送一些基础的配置，通过这些配置形成IGP（粉红），最重要的是控制器会告诉路由谁是RR

第四步：路由器与RR通过BGP-LS建立连接（灰色），路由器收集的LSDB或TEDB以后交给RR

第五步：RR通过BGP-LS给控制器上报LSDB或TEDB（灰色）

第六步：控制器通过BGP SR-POLICY协议或PCEP协议把路径下发到路由器（紫色）（没有控制器，管理员指定也可）