浅谈SDWAN策略框架

一开始大家对SDWAN的期待就是简化那些复杂的事情，以至于到后来大家都在谈怎么连通，如何快速开局以及如何添加其它业务。我也是一样的，起初特别喜欢Velocloud，直到最近一段时间处理各种客户的需求才有了一些更深刻的感受，特别是去年处理一个客户的平滑割接SDWAN和传统网络混合组网的事情，大量的线路overlay和underlay界限很模糊，和传统的网络双向多点重分布，各种环路搞死人，而你又不得不面对各种路由协议的限制，因此该有的路由控制策略，Route-Tag/Route-Map，条件通告等看似不重要的小功能一个都不能少，同时针对流量工程还需要基于应用的路由，而这些并不是开源的FRR/Quagga能搞定的。

另一个问题是
配置这些策略的时候，不光要考虑是否能配置生效，还要考虑软硬件平台的资源能力，例如有些是否能够访问的策略，可以通告明细路由的方式，也可以大网段汇聚路由通告，然后明细ACL过滤，这些事情怎么弄都大量的依赖于对您使用的硬件平台的理解，有些传统路由器改过来的，两者都使用TCAM涉及到容量如何分配，有些新兴的厂家拿DPDK瞎改的估计连怎么性能调优都不知道，也就只能跑到几十兆的带宽罢了。用过几家的SDWAN，有的功能极其有限，操作起来和转木取火没啥区别，虽然客户的需求都能通过一些奇奇怪怪的配置搞定。

当然也有的像思科一样的丢出一大堆工具，让你无从下手并且觉得它还做的特么乱七八糟的。

但是我跟你说这跟P4的可编程逻辑是一样的，而且你就只需要鼠标点一点就能实现灵活的包转发策略，你是不是又觉得高大上了？ 

很多年前，学网络大家都是抱着XXIE的认证在学，自然而然地各种路由协议和对应的策略路由配置学的非常溜。即便是想水过骗个证的也有各种各样的版本照着背几套就行了。现在厂商多了，各个厂都有认证了，自然大家都学不过来了，所以我一直想跟大家分享的经验是，不要在意配置的命令行和怎么去配置，更多的去透过这些配置看到一个厂商设计产品的思路，它做了哪些取舍，做了哪些创新，某个解决方案在某个场景下解决了什么独特的问题。而不是业界今天OpenFlow火就去跟，明天SDWAN火就去追，看到SRv6就想哪儿都用，最后XXIE认证考了五六个还是只能干敲命令行的活。
接下来会连续写好几篇文章来给大家分享一下SDWAN场景下的策略框架应该如何设计和实施，第一篇就大概泛泛而谈，说说架构。后面针对一些常用场景做点“版本”，一方面帮大家做做免费的XXIE培训，另一方面也希望有些经验能够帮助到大家的日常工作：）

1.SDWAN策略框架设计

说到策略，不得不提一本很不错的书，以前也推荐过，只是建议去看英文原版，因为中文的翻译真的一塌糊涂。

其中有这样一段话，写的非常深刻：

也就是说，策略本身需要从多个维度去考虑问题，关于拓扑和可达性的一些东西需要分布式的去考虑问题，最简单的一个问题就是很多人总喜欢上帝视角让控制器去算路选路。而策略更多的来自于业务决策，这些业务决策本身是和拓扑不相关的，这些逻辑可能需要集中式的策略算法。当大家部署SDWAN的时候，哪些策略该集中式配置，哪些该分布式配置，需要仔细考虑。而一个完整的SDWAN产品也需要完全的实现这两套框架，本质上也就是说我们需要从三个维度考虑策略问题：

1. 集中式vs分布式

2. 控制面策略vs数据面策略

3. 策略控制点：入方向、出方向、广域网隧道侧、局域网业务侧

所以这个问题解释清楚了，您看到下面这个图就会觉得稍微轻松一点了，本质上我们提供了大量的Policy可以供您选择，但是大多数场景下，您只会用到其中的一小部分，后面我会逐个展开介绍，也会串在一起教大家如何解决实战中遇到的问题。

当一个平台有了这么多策略后，执行顺序如何，策略使能点在哪？也是一个需要考虑的问题，当然某司也有自己的解法：

2.SDWAN策略简化：意图网络

最近看到各个厂都在催着网工学Python写DevOps的代码，结果看了一些发现很多人毕竟没有经历过严格的编程训练，最终都是依葫芦画瓢的乱写，我就开玩笑说，干脆大家都来学C，然后直接把IOS的代码给他们开发算了。

其实这样道出了一个问题，人类语言的意图是否非得用某种编程语言来实现？我看未必，本质上编程语言的实现大多是命令式的，而人类的意愿通常是声明式的，中间的巨大鸿沟并不是让人类自己去学会写代码翻译意图，而更多的是人工智能让机器去更加容易的理解人的意图。

网络的意图我们从一段自然语义说起，当你网络有故障的时候，通常的做法就是打电话给网管，或者填个工单：“我(Who)在什么时候(When),访问什么应用(Which)有问题了”，这就是一个最直观的意图，而无论是SDN还是什么控制器还是人肉运维，结果都是要反馈两点：故障源是什么(What),故障的影响有多大(How) ?然后再根据决策树这一系列的算法进行自愈修复，或者评估影响不大就不管了~

这就是从Assurance的视角看到的网络的意图，另一个方面是从部署来看，也就是如何在网络中制定规则，也就是我们常说的策略语言。思科最早的Class-map和Policy-map配合ACL，到后期Juniper和Cisco都有一些脚本一类的语言定义Routing policy，也都是类似的东西，其实从策略来看，本源是什么？“我(Who)在什么时候(When),访问什么应用(Which)需要怎么干(Action)”

其实这就非常容易的抽象出来了一个网络的意图模型, 围绕着这个模型其实就很容易定义网络的意图和如何实施网络的自动驾驶或者自愈的功能了.

具体的分析参考以前推送的一文：《意图网络的语言学思考》

而为了实现这些意图，对于报文的标记就需要从三个维度考虑，正好前段时间一个内部的讨论也最终归纳到这一点上。例如大家熟悉的VXLAN，VNID做VPN Label实现了租户隔离，思科为其添加的SGT、EPG构成了微分段，而NSH或者underlay SR、SRv6构成了流量工程。同样在SRv6中，End.X语义也构成了某种意义上的VPN Label，Option TLV也有被用作Policy Label的趋势。

最后，我从客户的角度想了一下，构建了一个场景，接下来可能就会从这些场景中慢慢的构建出一套“版本”供大家参考

1. 内网办公流量需要走MPLS专线链路，识别应用以URL域名或者SSL证书的CN为主，辅以基于IP定义的网段。

2. 一般上网流量本地互联网接口做NAT导出。

3. Office365等SAAS业务，特别是跨境业务需要指定特殊的目的业务路由器，然后由其代为转发至某些优质专线上。

4. 某些用户或者某些安全性较差业务需要专用的防火墙构建service-chain。