透过MH370看网络自动化监控
引子
MH370已经消失4个月了，这个严重的灾难也被蒙上了神秘的面纱，找不到消失的任何记录。也意味着，马航无法确保这种事情不会再次发生，人类生活在恐惧中。这就运营者需要面对的压力——避免故障。当飞机过于依赖自动系统，而未对运行状态进行监测的时候，运营者实际上对故障发生、进展、举措是无能为力的。网络上的运营也是一样，如果无法了解网络运行状态，运营也只能靠运气，我们要通过一些技术手段逐步驱散笼罩在运营上空的恐惧。
挑战
网络监控是一个老话题了，有一个现象非常形象地描述了这种状况——网络出现故障后，往往是网络业务最先发现业务受到影响，然后运营监控大屏幕会出现流量图陡降，再然后才是运营者们开始挨个服务器/设备地ssh/telnet抓取信息，试图查找问题所在。
目前也有网管，可以对网络设备的链路状态、资源利用率，还有许多日志记录路由邻居的变化、登陆操作记录等等。就运营角度来说，这些记录都是网络原子事件，还缺乏一种手段对这些原子数据进行系统性分析，得出更有益的结论，如——2台设备之间的路由协议邻居关系中断是因为2台设备之间互联链路中断造成的，或者更进一步，某条链路中断后，其余设备的路由应该是变成什么样。
聪明地迎接挑战
当前的挑战是网管是监控原子信息，运营监控故障往往会慢业务一拍，运营排障基本靠人。解决思路尝试将运营排障思路固化，描述成机器可以运行的程序，这个程序对网管原子监控信息进行bigdata分析处理，实现更实时和自动化的网络监控——智能报警和智能定位。
原理与案例
结合案例分析原理会使这个方案更接地气。如图1所示，当前的数据中心已经是一个典型的Multi-Root,2或3级的拓扑：
l 网络运行的核心是路由；
l 路由的来源是基于网络拓扑的IP分配；
l 网络拓扑和IP分配则来源于网络规划；
l 有规划意味着路由计算有正确范本。
网络中每一台设备的路由形成都源自于在这个拓扑结构上的IP分配，拓扑的和IP分配都是来自于网络规划，而规划信息是运营者最终判断路由学习是否正确的依据——我们称之为范本。
来看一下数据中心内就范本用于以一台Spine交换机为Root的转发路径路由判断的案例：
如图2，Leaf ToR Switch2的接入子网是10.10.0.64/26，在
1. Spine Switch与Leaf ToR Switch2之间的路由邻居关系是正常的；
2. Leaf ToR Switch2上的接入子网是Up的。
Spine Switch上就应该有一条路由10.10.0.64/26 next-hop是Leaf ToR Switch2，否则，路由出了问题。
1. Spine Switch与Leaf ToR Switch1之间的路由邻居关系是正常的；
2. Spine Switch上有10.10.0.64/26这条路由。
Leaf ToR Switch1上也应该有一条路由10.10.0.64/26 next-hop是SpineSwitch，否则路由也是出了问题
多条经过不同Spine的转发路径形成相互独立的ECMP关系，因此通过独立地监控不同Spine形成的转发路径即可对网络进行完整地监控。除了路由的监控，对于数据中心服务器的NIC-VLAN-IP-MAC和交换机端口对应关系也可以形成范本，在图2中：
l 服务器的范本并不是规划得来的，而是基于当服务器上架之后手工信息的录入，这些信息通过Server DB进行维护；
l 这些信息包括服务器NIC名，连接交换机名和端口编号，NIC上配置的VLAN-IP-MAC的对应关系，这些信息Server DB也可以通过对服务器采集进行比对，确保录入信息的准确；
l Server DB保存的信息传递到网管系统后，经过处理可以得到服务器的ARP-交换机VLAN关系，MAC-交换机端口-VLAN对应关系，这就是范本；
l 将各个ToR上采集到的ARP、MAC信息和范本进行比较，就很容易判断出是否有服务器使用违规IP进行通信，是否伪造MAC等；
这种原理也很容易推广到一些更复杂的场景，比如路由聚合，大多数网络规划都会将数据中心园区外部的路由以汇聚路由的方式发送到数据中心内部，汇聚路由的处理往往会比较复杂，涉及到汇聚路由的协议类型、distance、协议内优选顺序等等，稍有考虑不周，汇聚路由就有可能不会发送到数据中心内，而从规划角度，汇聚路由下发条件很简单，以图3为例：
l Border是数据中心园区的边界，是路由汇聚点，连接着多个园区数据中心和园区外网络；
l 规划要求是只要Border上有非数据中心1始发的10.0.0.0/8范围内的路由（如数据中心2的路由和园区外路由），数据中心1就应该有一条10.0.0.0/8的路由指向Border；
l 为了避免其余路由协议邻居故障导致一些路由消失影响路由汇聚，往往会在Border添加黑洞路由引入路由协议的方式，增加了方案复杂性，对于整个方案工作正常与否，非常有必要对数据中心内的汇聚路由进行监控。
根据对以上场景的分析，对聚合路由的判断可以形成非常简单的范本，可以抛弃Distance、协议内外优选原则等，要远比路由协议的判断要简单：
1. DataCenter1 Spine与Border间的路由邻居关系是正常的；
2. Border上存在next-hop不是DataCenter1 Spine的10.0.0.0/8范围内的路由，这些路由有可能是来自于另外一个IDC，如DataCenter2，也有可能来自于Border外部的网络；
3. DataCenter1 Spine上就应该有一条路由10.0.0.0/8 next-hop是Border，否则，路由出了问题。
同样的，这个范本可以推广到Leaf上：
1. Spine Switch与Leaf ToR Switch1之间的路由邻居关系是正常的；
2. Spine Switch上有10.0.0.0/8这条路由；
3. Leaf ToR Switch1上也应该有一条路由10.0.0.0/8 next-hop是Spine Switch，否则路由也是出了问题。
虽然路由是网络转发的核心，而实际的网络中，会因为ECMP路由的原因，底层的转发表FIB在转发时使用hash的形式选择唯一的路由，对FIB hash的评判是“是否足够均匀”，而这方面的监控一直是空白：
l 所有匹配同一条路由的数据包在转发平面被不同的因子（如5元组、3元组、2元组等）定义成不同的流，不同的流通过hash算法映射到这条路由不同ECMP上，由于流的定义和流量大小没有关系，因此实际的ECMP链路利用率并不是规划中的流量负载均衡，而是流数量负载均衡；
l ECMP目前的监控也是比较薄弱的，有可能出现这种情况传统的网管是不会告警的，ECMP路由正常，但转发流量却一边是100%另外一边是0%，智能的网管应该产生告警，让我们检查一下是否hash的因子没有配置正确或者设备出现了故障；
l 在路由层面的ECMP确定好outputinterface正好是一个LACP聚合组，在流量在LACP聚合组内形成L2ECMP，这时候同样采用hash进行流数目负载均衡，也会出现物理端口在LACP中处于active成员状态，但实际链路利用率相比于其余链路利用率低很多的情况，这种情况也同样应该进行告警。
既然判断的准则是均匀，而每个物理端口上的流量信息也是可以通过网管进行采集的，因此程序进行判断处理也不会复杂：
ECMP有L3和L2两个层面，比如Leaf1上就是2条L3 ECMP路由
1. 每条activeroute都对应一个output-if；
2. 两个output-if的流量负载采集后在后台进行对比分析。
如果route1对应的output-if负载达到80%，route2则只有20%，这说明我们需要分析Leaf1上的L3Hash因子。在Spine1的情况会复杂一些，因为这是一个L2/L3混合ECMP场景：
1. L2ECMP首先要检查所有成员链路状态是否是selected；
2. 将有selected成员端口流量负载采集回后台分析。
通过后台分析，可以得出2个LACP组之间L3ECMP均衡是否正常，也可以判断某个LACP组内L2均衡是否正常，如果不正常，运营的同事可以提前介入调查，是否需要调整hash因子。
意义
从这些案例，可以总结出，只要人可以判断的网络故障，将判断条件固化之后，网管系统也可以进行判断，并且会比人的判断更加迅速和实时。
更深远的意义在于，正常情况下，人只能一台一台设备地检查是否有故障，效率低下，准确率还会因为人的疲劳程度有所变化，而采用网管系统则不会存在这个问题，对于数据中心内的海量设备，它可以轻松完成巡检，将一些配置上存在的问题、稍纵即逝的bug都发现到，可以在网络稳定时解决这些问题并且推动厂家优化实现网管响应方式，延长无故障运行时间，是一种治未病的方案，这种机制可以使MH370这种不知所踪悲剧发生的概率大大降低。
对于网络的自动化监控是一种智能的体现，本文介绍的案例只是开始，更智能的监控我们会在后面几期文章中进行分享。