思科IWAN解决方案分享（一）：概览及智能路径选择分解

SDNLAB君

序相较于Openflow、Segment Routing这些新技术，看完今天的分享后，你们可能会发现，IWAN是个很接地气的方案。程序员转行的“新网工”不一定会喜欢它，但老网工一定会觉得它无比亲切。
IWAN，中文称智能广域网，它的本质，是一大坨思科的广域网技术的组合，我最早学习IWAN的时候，教我的人就反复跟我强调，IWAN是一个解决方案，换言之，它是思科的研发用思科的技术做出来的一个广域网的方案。

                               
登录/注册后可看大图

IWAN包含哪些技术呢……VRF、DMVPN、IPSec、EIGRP/iBGP、AVC、QoS、WAAS以及最关键的核心科技——PfRv3 (Performance Routing) 。可以说，除了PfR很多人可能是听过没见过之外，前面这些技术，恐怕你们已经听的耳朵生茧了……
现在，思科也在努力把IWAN这一方案进一步向SD-WAN的方向转变，并逐渐的做了一些叠加在IWAN之上的软件/平台，其中包括面向企业自建WAN用的IWAN APP (APIC-EM)，面向为用户提供SD-WAN服务的服务提供商的VMS，以及最近刚收购了一家公司Viptela，未来会怎么整合，还有待观望。
IWAN的框架

                               
登录/注册后可看大图

IWAN的框架见上图，从下往上，我分了五层，其中最核心的部分是第三层的Performance Routing v3，它的细节我们下面再讲。下两层是实际上是为PfRv3服务的，其中DMVPN是必选，因为PfR对于“Path”的识别，其实就是识别Tunnel，当然，使用DMVPN还有一些其它的原因。
WAN Routing部分建议选择EIGRP或者IBGP。有不少人问过我能不能用OSPF。能么，肯定是能的，只不过我们不建议这么做。OSPF用在LAN中是一个很好的协议，但在DMVPN上，LSA的泛洪，还有单Area内路由没法控制这些“瑕疵”， 使其显得不是那么太合适。在WAN Routing上选择EIGRP或者IBGP，纯粹只是因为这两个协议在调路由上更容易。另外，还有人十分忧虑的问我，EIGRP是私有协议啊……这个忧虑真的毫无意义，因为PfR本来也只能做在我们C记的路由器上，另外，EIGRP其实已经在去年公有化了，RFC是7868。公有化使得EIGRP的学习和使用有了一份非常权威的资料，不用在cisco.com上翻来翻去，直接去找RFC就好了。
（P.S. 我一直认为做一个网络，不同的模块间异构，同一模块内同构是比较合适的做法。比如如果你一定要用三家厂商，那么Campus用H记，WAN用C记，然后Internet Edge用S……这样出问题的几率会比较低，当然如果你一定要HUB用C记，Spoke用H记，那么祝你平安。)
FVRF是非常推荐的一个技术选项，我个人对其作用的理解是解决多条WAN链路的选路问题，但同时，它也有隔离底层的WAN路由和企业的业务路由的作用，并提供一定的安全性保障。这里注意同PfRv3那一层的VRF区分，和PfRv3放在一起的VRF，是用于多租户隔离的。
再往上是一些附加的功能，和IWAN没有直接的关系但却非常有用——QoS、AVC、Netflow、WAAS。先说WAAS，它实际上是一个独立的技术，通过数据压缩等手段来节省广域网的带宽，鉴于WAAS我还没有深入研究过，这里就不多提，有兴趣的朋友可以参考下面的链接：
http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Mar2015/CVD-IWAN-WAASDesignGuide-Mar15.pdf

AVC，应用可视化，核心是NABR2的协议库，它可以直接和PfR还有QoS集成，说白了就是做策略上会方便很多。如果是对于那种企业内的应用都是自己开发的，NBAR2压根匹配不到的应用的话，抓这些应用的流量，一种方法是标记DSCP，另一种方法则是在NBAR2中创建自定义应用——五元组、URL只是比较基础的方式，还有更复杂的。

Netflow，现网中已经用的蛮多了，流量可视化全靠它。

QoS在广域网中的意义毋庸多言，但由于使用了DMVPN，IWAN中的QoS还有些不同，具体来说是一个叫做Per-Tunnel QoS的feature。
必要条件——DMVPN和WAN Routing Protocol如前所述，IWAN是一个接地气的方案，因为它的核心实际上是一个路由器上的Feature，也就是PfR。为了能让PfR正确的理解广域网的拓扑信息，需要设计好基础的路由环境。
这个路由环境我们可以分为两个层面来看，时髦点说就是Underlay和Overlay。Underlay就是你租用的运营商链路，MPLS或者Internet或者点到点的专线都可以，而Overlay就是DMVPN，也正因此，IWAN构建的广域网，现阶段还只能是Layer3 Overlay（考虑到IWAN的场景，从总部到分支的场景里，似乎也没有Layer2 Overlay的必要）。

                               
登录/注册后可看大图

2.1 为什么要用DMVPN？根本原因当然是PfRv3只认DMVPN，没有DMVPN，PfRv3压根就不会工作。其它一些原因来自于我自己的理解。
一是屏蔽底层的复杂性，无论你是专线、MPLS还是Internet，都不关心，只要能把DMVPN建起来就行(点到点专线上的DMVPN会有些特殊)。二是可以在上面只跑一个路由协议，路由的设计会变得简单。三是DMVPN本身，虽然拓扑是Hub-Spoke的形式，但是Spoke与Spoke之间的流量是可以通过NHRP自动建立隧道的，不知道这算不算是实现了“任意连接”呢？

                               
登录/注册后可看大图

Note
由于DMVPN是一个Hub-Spoke的拓扑，因此对于点到点专线需要前置三层设备对拓扑进行“改造”。
用环回口建DMVPN可否？理论可行，但有可能得不到TAC支持。
2.2 简化WAN Routing 设计在传统的企业广域网中，非常让人不舒服的一件事就是，在接入了不同的线路后，不同的线路上运行不同的路由协议，这些路由域之间通常还需要重分发，需要写各种乱七八糟的路由策略。自建的广域网稍一大一些，维护的稍差一些，那就是个“量变引起质变“的后果，足以让任何一个自诩路由学的还不错的人崩溃。
而当我们用DMVPN屏蔽了底层的复杂性之后，此时的广域网，就只是数台Hub路由器和Spoke路由器之间的一个“点到多点”的连接而已，在这之上我们可以只运行一个路由协议，这也是为什么前文说推荐EIGRP和IBGP，在单路由域的情况下，这两个协议都能很好的去调整路由。
2.3 Front Door VRF路由方面的一个可选项——FVRF， Front Door VRF，将WAN口与站点内部通过VRF进行隔离，WAN口仅用于建立DMVPN。

                               
登录/注册后可看大图

作用一：解决选路问题

当Branch Router双连两个SP的时候，譬如说双连两个Internet的SP，就会遇到这种问题。通常来说，双连两个Internet SP的时候，如果默认路由做成浮动路由的形式，于是就会出现下图的状况：

                               
登录/注册后可看大图

主路由上的出接口没有问题，有问题的是备路由，会出现右图的绕行情况，这种情况下，备路由的出接口无法正常通信，时而通时而不通。而如果是Hybrid组网，一边MPLS，一边Internet，这个问题会更加严重（ MPLS的链路和Internet的链路根本就不会通啊！ ）。
备路由的出接口无法互通，虽然并不影响同Hub端的DMVPN的建立，却会导致备用的这条链路上的Tunnel无法建立自动隧道。当然，我们可以通过主默认，备明细的方式来解决问题，但如果你的分支特别多呢？另外，IWAN 2.2的新的MTT feature中，HUB端的单台BR可以连接多个运营商了，而如果恰好是多个Internet运营商，这时候底层的路由又该怎么处理？（刷各家的路由表么？笑……）
将WAN接口划入VRF后，两条链路的路由表独立，也就解决了这个问题，毕竟Underlay的主要存在意义，是让DMVPN能够正常运行。所以FVRF是推荐的技术选项，虽然你不做也可以，但是会带来很多麻烦。
作用二：安全性

很明显，WAN口划入VRF中，对于从Internet来的入站流量，在没有做任何其它策略的情况下，是没办法进入站点内部的。
核心科技——Perfmance Routing其实如果抽丝剥茧的话，网络的问题无非就是两个大问题——速度和宽度。速度不是我们通常意义上的速度，而是指延时、抖动，宽度就是我们通常理解上的“速度”，也就是带宽。时代在变，如今的网络已经不比我们曾经在教科书上学到的那个网络了，网络上跑的流量也比以前复杂。
谁都知道专线好，延时低，安全性高，但是专线贵啊，大流量的应用跑多了，专线的费用就很可观了。反过来看，如今的Internet链路也不比从前了，只要你不是非要联通连电信，在同一个运营商的大内网里，延时也不会很大，而且更重要的是Internet便宜，带宽还大。至于说安全性的问题，IPSec早已提供了一个成熟的解法，并且随着路由器性能的提升，IPSec的性能也不再是瓶颈。
那么问题来了，即便是用DMVPN屏蔽了底层复杂性，但是多条链路怎么合理的利用起来，怎么做故障倒换？方法是很多的，只是细思下来，都不怎么好用。可能有人要说了，两条链路的倒换配置并不复杂啊，那三条呢、四条呢？然后又有人要说了，为什么要三条四条或者更多？来两条大的！OK，假设两条1G的链路吧，挂一条且不说性能的损失了，那可是钱啊……
所以，在既想要省掉庞大的专线费用，又想要合理的利用起多条线路的资源，做到性能和可靠性的平衡，就需要一个足够合适的“调度”技术，这个技术在思科，就是PfR，Performance Routing。
PfR源起于OER，对，就是那个V4大纲的CCIE考试的K3+ Lab里面的那个OER，不好用对吗？
如下图，OER的历史比较悠久，如今我们使用的PfRv3，是这个技术的第三版，相对于OER和PfRv2，PfRv3在许多方面都有了长足的进步，这也使其真的变成了一个“好用”的技术。

                               
登录/注册后可看大图

3.1 从解决问题的角度来分析PfR“好用”的技术一定是能解决实际问题的技术。
PfR首先为大家解决的，就是“选路”这一问题。怎么选？自动选。在总部和分支之间，为不同的路径定义不同的“Path-Name”，譬如一个MPLS/Internet混合组网的环境，我们就可以定义MPLS和INET两个路径名称，对同一个运营商如果有多条路径，还可以通过Path-ID来做进一步的区分。名字定义完之后，在PfR的控制器上，为你的主要业务定义主用路径就可以了，非关键业务则让其负载均衡。剩下的事就不用你操心了。
这里就引出第二个问题，PfR怎么判断路径质量的？需要配SLA么？答案是不需要的。在PfR中，主控制器会自动推送Performance Monitor的配置到域内的所有路由器，在一条路径上有实际业务流量时，依据实际的业务流量来监视性能，而没有业务流量的路径，则依靠RTP探针去探测性能，也称为Smart-Probe。这完全是自动的，不需要手动做什么配置。
第三个问题，PfR怎么调度流量的？在边界路由器之间，PfR会自动通过通信接口建立自动隧道，通过这条自动隧道去调度流量。可以理解为是策略路由的升级强化……（据说在PfRv2时代，调度流量的确是通过Dynamic Route-map来做的）。
在流量调度方式上，PfR类似于PBR，但不需要你配置PBR那复杂的策略，性能也比PBR更好。PfR也不依赖路由表，它仅仅要求路由器的拓扑表内的路由信息完整。譬如一台分支路由器通过两条路径连到中心，那么PfR要求这两条路径上都能收到去往中心的路由，至于显示在路由表中的是哪一条倒并不重要。
PfR对流量有一个Control的过程，在某一类流量第一次被收到时，PfR需要将其“Control”起来，这需要时间，在这个“Control”的时间段内，流量的转发会依据路由表来转发。譬如你从MPLS收到的路由更优，那么此时流量会沿建立在MPLS上的Tunnel转发出去，而当PfR“Control”了该流量，且该流量应该走INET路径，那么PfR就会将该流量调度到INET上。
下文我们来详细说说PfR的一些细节问题。
3.2 PfR的角色

PfR定义了如下的一些角色。
Domain
--通过定义Domain，将运行PfR的路由器关联一起
Hub Master Controller
--PfR主控制器，选路策略、性能监视器都由在Hub MC推送给其他站点的MC。
--Hub MC支持HA，避免单点故障
Hub Border Router
--真正负责转发数据的角色，DMVPN的中心路由器。
--在网域较小的情况下，可以由一台Hub BR来兼顾Hub MC的角色
Transit Site
--如果有多中心的需求，就需要建立Transit Site
--Transit Site目前最多可以支持5个
Branch Border Router
--分支站点的边界路由器
--分支节点只有单台路由器时，该路由器兼职Branch MC（即Branch Master Controller）
--分支节点为双路由器时，选择其中一台兼职Branch MC
PfR中的控制器，我们称为MC的角色，实际上就是一台路由器，每个站点都至少有一台MC，但只有Hub站点的MC负责整个PfR Domain的策略配置和推送，不过也只是推策略，具体的转发过程中的控制事务，由每个站点的MC来负责的。

                               
登录/注册后可看大图

3.3 自动识别路径和站点前缀

前文提到，路径的名字是需要定义的，除了路径的名字外，Hub节点的前缀(prefix)也需要定义。但在Branch站点，路径的识别和前缀学习都是自动的，无需人为干预（当然你也可以选择干预，譬如分支站点只有部分的prefix想要纳入PfR的控制中，那么可以选择手动配置站点的Prefix，这个行为听上去有点像是IPSec VPN中的感兴趣流。）

                               
登录/注册后可看大图

3.4 PfR的性能监视器

再说一次，性能监视器完全不需要配置，由Hub-MC推送给其他站点的MC。
自动配置的性能监视器分别在端口的出方向和入方向上进行监控，出方向的性能监视器主要干两件事——学习其他站点的prefix，以及收集带宽信息。入方向工作的性能监视器则用于测量性能，如果发生违约，譬如延时过高或者丢包过多，就会触发TCA消息，并将该消息上报给流量源站点的MC。
3.5 PfR的流量识别

在PfR中，流量被识别为Traffic-Class，简称TC。TC的建立判断基于目的Prefix、DSCP以及APP-ID。APP-ID由NBAR2的协议库来提供支持，对于同一目的prefix且同一DSCP的流量，如果APP-ID不同，也会识别为两个不同的TC。如果在PfR的策略中仅match了DSCP，那么TC的识别中就不会有APP-ID了。
前文提到PfR对流量有个Control的过程。这个过程，实际上就是识别Traffic-Class并且建立Channel的过程。PfR会为每一条TC在每条可用的路径上去建立Channel，我们可以把Channel理解为车道，流量的调度，其实就是“变道“。
3.6 PfR的流量调度

让我们来看看PfR调度流量的具体过程。理解PfR的流量调度，需要明确一个关键点：PfR是对流量的出方向进行调度（入方向好像也没法调度）。
在PfR自动推送的性能监视器中，真正用于测量性能的监视器是工作在入方向的，这刚好跟调度的方向相反。工作在入方向的监视器监测到来自某一站点的流量违约，就给源站点的MC上报一个TCA消息，源站点收到TCA消息后，就在本站点的出方向进行流量调度。

                               
登录/注册后可看大图

3.7 PfR 小结
在传统的广域网上，调度流量要么调整路由，要么做PBR。调整路由其实是一件很不开心的事，而且也不是很灵活，而SLA+PBR的配置，在网域大的时候又太过复杂，总之都不是什么太好的办法。PfR在调度流量这件事上，实际上是PBR的升级版，但不同的是，PfR对于流量的调度和性能的监控完全是自动的，唯一需要我们手动做的一件事就是标记出网络中的业务流量。你可以通过标记DSCP这种传统的方式来标记业务流量，也可以通过NBAR2协议库来抓取一些流量。
需要强调的是，PfR是一个调度技术，而不是一个保障技术。它是在你的链路质量出现问题时，将定义好的关键业务调度到好的链路上。有人问过我，在IWAN中QoS的设计是必要的吗？答案是肯定的，因为PfR并不能保障服务质量，保障服务质量这件事，从来都是QoS来做的。
另外，关于NBAR，有很多人跟我说，NBAR抓不好QQ抓不好迅雷，而这其实是搞错了NBAR的用法。在企业广域网上，我们要做的并不是干掉迅雷之类的协议，我们要做的是保障我们的关键业务，譬如我们通常拿来说事的语音、视频会议或者其他的业务，至于迅雷？QQ？丢到Default里面就好了。
对这个逻辑有疑惑的朋友，建议翻一下有关cisco的QoS技术中的CBWFQ这一经典的算法，在IWAN中，保障业务方面，用的正是CBWFQ+LLQ（通常来说，由于语音对于网络质量非常敏感，会用LLQ来做严格优先级保障）。
END由于时间（小黑催的急）和精力（做不完的测试出不完的差噫……）的关系，这次的分享只跟大家分享了IWAN的框架和PfR的内容，后续有机会我会继续撰文有关IWAN的其它内容。