摘要：
影响端到端服务可用性的主要因素中，网络组件故障可能是最无法预知得。 失败发生的频率多高，持续多久，原因是什么以及它们如何影响客户？ 传统上，回答诸如此类的问题需要在网络中广泛部署的专用（并且通常是昂贵的）仪器。
我们提出了一种替代方法：机会主义地挖掘现代网络环境中已有的“低质量”数据源。本文提出了一种方法，使用结构化数据（路由器配置和系统日志）和半结构化数据（电子邮件日志）的组合来重新创建IP网络中故障事件的简明历史记录。 使用这种技术，我们分析了由超过200台路由器组成的大型区域网络中超过五年的故障事件; 据我们所知，据我们所知，我们进行的是同类型中最大的研究。
今天的以网络为中心的企业建立在不间断服务可用性的承诺之上。 但是，实现这一承诺是一项具有挑战性的任务，因为可用性不是系统的固有设计属性; 相反，系统必须适应组件的底层故障属性。 因此，首先提供可用性需要了解故障：故障多长时间，是什么原因造成的，以及它们被掩盖的程度如何？ 这对于网络来说尤其如此，因为网络呈现出复杂的故障模式，网络越来越被认为是端到端服务中断的主要原因。
不幸的是，这种分析在实践中很少作为衡量网络故障的常用手段，以细粒度为前提的测量机制（例如IGP日志，普遍高频SNMP轮询，无源链路监视和成对活动探测），这些研究只为研究而研究，会产生巨大的资本和运营支出。事实上，即使在研究界，由于缺乏可用的经验数据，也常常使用任意的合成失效模型。
作为解决这个问题的一个步骤，我们描述了一种“廉价且肮脏”的方法，从当今生产网络中常见的“最低公分母”数据源中提取必要的测量数据。我们展示了一种方法用于重建自治系统内的历史网络故障事件，该方法使用三个近乎普遍却被人忽视数据源：路由器配置文件，系统日志归档和操作邮件列表通告。
路由器配置文件（例如，用于配置Cisco IOS和JunOS路由器）在某个时间点描述网络的静态拓扑，并且通常记录在相当大的网络中以支持配置管理。 每个配置文件描述在路由器上启用的一组接口，并且通常拥有足够的信息来推断其连接性（例如，通过通常分配给点对点链路的短IP网络前缀）。 它绝不是一个完美的数据源; 它可以省略其范围之外的拓扑结构（例如，透明的光学交叉连接）并且可以包括虚幻的拓扑结构（例如，在链路已经停用之后，条目可以在配置文件中很长时间地保持）。 但是，总体而言，当与附加数据结合时，它提供了广泛的拓扑覆盖。
然而，网络的长期拓扑结构本身并没有表明故障点。在这里需要用到系统日志，通常在现代路由器上实现，它记录了大量事件，包括链接状态变化到远程服务器。因此，它通过描述网络的动态状态（即每个时间点所有活动链路的状态）来补充路由器配置数据。然而，重构这种状态可能是痛苦的：首先，系统日志消息的非结构化质量需要解析各种各样的消息格式，并将这些事件与接口配置记录关联起来，以获得事件的完整描述。其次，由于系统日志的“尽力而为”的带内特性，一些消息必然丢失（特别是当到系统日志服务器的最短路径上的链路失败时）。然而，根据我们的经验，通过利用自然报告冗余（即两个端点通常报告链路故障），我们几乎可以在90％的时间内恢复即时链路状态。
最后，网络操作人员几乎通用的做法是维护邮件列表和故障单系统以共享操作状态的变化（例如记录对故障的响应，通告计划的维护活动等）。这种自由形式的自然语言数据既丰富又不完整：一方面，它提供系统日志中不可用的信息，例如失败的原因，但同时它是由非确定性社会过程产生的，因此，只反映主观上足够大小和持续时间的故障情况，以便得到更广泛的通知。然而，这种二元性使得这种公告数据有两个不同的目的：作为故障原因的分类器和作为可用于验证分析结果的“ground truth”的独立来源。遵循Feamster和Balakrishnan的方法[12]，我们使用关键词搜索，正则表达式和人工检查的组合来分析公告。
综合这些资料，我们分析了来自CENIC网络的五年存档数据 - 这是一个由200多台路由器组成的IP生产网络，为大多数加利福尼亚州的公共教育和研究机构提供服务。使用系统日志和路由器配置数据，我们在此期间提取故障事件，从管理员电子邮件日志中推断原因，并检查我们的结果是否与三个独立的网络故障数据源保持一致：来自CAIDA Skitter / Ark工作的网络活动探测，由路径视图项目收集的BGP日志以及来自CENIC运营商的管理通告。最后，我们使用我们重建的失败日志来呈现失败持续时间，原因和影响的具体分析，验证了一些关于网络失败的广泛持有的观点（例如，链接“扑动”的主导地位），并描述了我们的新发现数据集（例如，计划维护与非计划故障的相对重要性以及第三方电信公司在扑动事件中的作用）。
相关工作
自从第一个网络建成以来，计算机网络的设计者不得不面对频繁的故障 - 链路故障，路由器故障，接口故障等。 但是，由于实际原因，大多数故障测量都是从网络边缘发生的。 不幸的是，这种断层摄影技术不能提供网络的完整图像; “根据Huang，Feamster和Teixeira的观点，网络层析成像研究和可扩展网络监测的实际系统之间仍存在差距。 直接测量仍然是网络故障数据的黄金标准.
数据源
加利福尼亚州教育网络倡议公司CENIC运营着一个全州性的共同网络，为加州公共教育和研究机构提供互联网接入。它的成员合并入学人数超过600万，其中包括加州大学系统，加利福尼亚州立大学系统，社区学院和K-12学区。在物理上，CENIC网络是一个光纤主干网，光纤长度超过2700英里，连接主要城市的中心站点，如图1所示。此外，CENIC还管理位于中心站点外的一些小型成员设备。
在行政上，CENIC网络可以分为三个主要部分：数字加利福尼亚（DC）网络，高性能研究（HPR）网络和客户端设备（CPE），每一个部分都在下面描述。
DC网络。数字加州（DC）网络（AS 2152）是CENIC的生产网络，通过其各自的县教育办公室向加州大学的学校，加利福尼亚州立大学，加州社区学院，一些私立大学和小学提供互联网连接。 在测量期结束时（2009年12月），核心网络由53个路由器（主要是Cisco 12000系列）组成，由178个链路连接。 我们将这些链接称为DC（核心）链接。DC网络使用IS-IS路由协议进行域内路由。
HPR网络。 除了生产网络，CENIC还运营高性能研究（HPR）网络（AS 2153），该网络以10 Gb / s的速度与主要的加州研究机构相互连接。 它为大型应用用户提供“尖端服务”[7]。 在2009年底，它由在光纤骨干网上通过七条逻辑链路连接的SAC，OAK，SVL，SLO，LAX和RIV集线器站点上的六台Cisco 12000路由器组成。 HPR网络运行自己的IS-IS路由协议实例。
CPE网络。CENIC还为一些小客户管理客户端设备（CPE）。 许多CPE路由器（主要是那些具有冗余连接性的路由器）在连接到DC路由器和其他CPE路由器的链路上运行IS-IS。 截至2009年底，有102个这样的路由器和223个链路。我们将这些客户接入链路称为CPE链路。
历史信息
设备配置文件。CENIC使用RANCID [29]，这是一种流行的开源系统，可自动跟踪路由器配置的变化。所有更改都将被提交给修订控制系统，从而可以恢复网络中任何路由器的配置历史记录。我们被授权访问此存储库，其中包括2004年6月至2009年12月期间的41,867个配置文件修订版。
系统日志消息。 所有CENIC网络路由器都配置为通过网络将系统日志[21]消息发送到位于Tustin（TUS）枢纽站点的中央服务器。 这些消息通告了物理链路层，链路协议层和网络层（IS-IS）的链路故障，覆盖了网络协议层次结构的前三层。 与许多本地日志不同，集中式系统日志中的消息被时间戳为只有整秒的粒度。 我们从2004年11月至2009年12月获得了这些消息的档案，其中217,498条涉及本研究的网络。 不幸的是，存档中缺少176天的系统日志数据（9/23/2007至3/17/2008）。
管理员通知。我们还获得了用于传播有关网络公告的两个邮件列表的档案。邮件列表共包含7465条公告，涵盖了从2004年11月到2009年12月的3505个不同事件。
最后，为了帮助验证关于什么时候发生故障的结论，我们从Route Views Project [31]中提取了与CENIC网络相关的BGP通告。 特别是，我们收集加利福尼亚州帕洛阿尔托市的对等和互联网交换（PAIX）监听器接收到的属于CENIC网络属于或服务的地址块的所有BGP消息。 请注意，我们的分析不依赖于BGP数据 - 我们将其用作关于外部可见故障的小子集的基础事实。
方法
我们工作的主要目标是制定一个通用程序来挖掘三个“低质量”历史数据来源，以构建一个清晰的失败时间表，其中每个失败事件都注明了开始和结束时间，一组相关链接， 如果可能的话，还有一个潜在的原因。 此外，在适当的情况下，我们设法将多个同时链路故障汇聚成更大的事件，例如路由器和存在点（PoP）故障，并将频繁的背对背链路故障合并为封闭的振荡事件。 除了这个注释的失败时间线外，我们还生成关于链接生命周期的统计信息，作为我们分析的输入（第6节）。 图5描述了提取过程，以及我们在下一节讨论的验证实验。
修复拓扑
在开始编制故障之前，我们必须首先建立一个正在研究的网络的拓扑模型。 尽管地图可能很容易获得（实际上，目前的CENIC拓扑结构可在Web1上找到），但我们选择从历史数据推断拓扑结构。 我们的理由有两方面：首先，以前的工作表明，随着运营商改变物理拓扑以增加容量或响应故障，拓扑数据库会迅速过时。 其次，我们需要将系统日志信息与物理网络实体进行交叉关联; 提取配置文件中使用的实际标识符可以显着简化此任务。
首先，我们将系统配置文件中描述的实体映射到网络拓扑中的单个路由器和链路。然而，这个过程并不是完全简单的，因为第3层系统日志消息标识链路的两个端点路由器，而只标识生成系统日志消息的路由器的特定接口。在几种情况下，这不足以完整描述链路，例如，当两台路由器之间有多个链路时。为了准确识别链路两端的接口，我们参考了路由器的配置。每个配置文件都描述了路由器上的接口种类以及它们的配置方式;
我们收集的路由器配置文件不仅仅是一个快照，而是每个路由器的一系列配置文件，每个文件版本都用更新时间进行注释。因此，路由器配置为我们提供了一种有意义的方式，将链路“生命周期”定义为从配置文件中第一次提到它到最后一次之间的时间段。
我们使用类似于以前关于从配置文件中提取全局网络状态的工作的直接迭代过程来识别与每个链路相关的端口[13,14]。对于运行IS-IS的每个活动接口，我们确定同一子网上的一组IP地址。压倒性常见的情况是，一个接口的子网是255.255.255.254（即，点对点链路）使得它明显哪些接口彼此通信。一个重要的警告是，IP地址经常在不同的路由器上改变和重复使用，因此在整个分析过程中允许接口成为多个不同链路的一部分是至关重要的。
识别故障
通过网络中的链接集，我们分几步处理网络的故障历史。 我们从syslog归档开始，假设它包含链接失败的精确（如果不完整）枚举。
定义故障
出于我们的目的，故障是导致记录路由状态更改（第3层）系统日志消息的任何事件。因此，我们重建的事件历史记录反映了网络的路由状态，即每当路由器拒绝通过它发送流量时，就认为链路失败。因此，我们的事件历史记录可能无法准确捕获网络组件的物理状态。例如，路由器可能拒绝通过链路路由流量，因为压下计时器尚未到期，而不是由于实际断开连接。我们将故障事件的持续时间定义为从syslog中的第一个第3层“down”消息（我们可能会从链路两端的路由器接收消息）延伸到指向同一链路的第一个“up”。
回想一下，syslog还包含在物理链路层和链路协议层生成的故障消息。我们选择关注网络层，而不是链接层，因为它更忠实地捕捉了我们感兴趣的状态，即链接是否可以用于传输流量。当然，偏见是片面的：如果物理层报告链路“关闭”，那么它在网络层也必然“关闭”;另一方面，链路可能在物理层“上”，但不在网络层（例如，插入具有错误配置的VLAN的交换机的以太网链路）。
分组
一旦发现单个故障事件，我们会进一步考虑故障事件是否重叠。当故障发生在不同的链路上，或者在彼此的15秒内恢复时，我们将同时发生的故障定义为两个及以上。我们确定了三种同时发生的故障：与路由器相关的，与PoP相关的，以及其他类型。 如果所有涉及的链路共享公共路由器，则认为同时故障与路由器相关;如果所有链路共享公共PoP而不是普通路由器，则为PoPrelated;如果故障没有共同PoP，则认为是“其他”。
除了通过是否跨多个链接对同时发生的故障进行分组之外，我们还将单个链路上的back-to-back故障事件聚合到封闭的振荡事件中。 长期以来，链路振荡被理解为路由协议的挑战[33]。 根据我们在本研究中使用CENIC数据集的经验，我们将振幅定义为两次或更多次向上/向下状态变化，其中向下翻转时间不超过10分钟。 （我们在第6.2.4节中证明了我们特定的参数选择）。
损失处理
与Markopoulou等人不同的是 [23]，他们使用专门的IS-IS侦听器，而我们从路由器自己生成的系统日志消息中收集路由状态信息。 不幸的是，由于系统日志的基于UDP的传输性质不可靠，并非所有的路由器日志消息都将其传送到系统日志服务器。 因此，通常会听到一条链路发生故障而另一条链路故障。 出于这个原因，如果至少有一个端点报告它已关闭，我们会考虑关闭链接，如果至少有一个端点报告它开启，则视为开启。
看到两个“向上”消息而没有介入“向下”消息也是常见的，反之亦然。 例如，在一个实例中，系统日志显示HPR网络中的LAX和RIV路由器之间的链路失败（由RIV报告“down”，但不是LAX），然后在36天后，LAX报告相同的链路 ，没有关于链接的中间消息。 我们放弃了连续的“上行”或“下行”消息之间的这种异常时段，在这种情况下，无法从数据集中推断链路何时改变状态。 我们选择这种保守的方法来支持完整性的正确性。 对于我们的数据集，排除的时间段占HPR链接的链接小时数的12.6％，直流链接的链接小时数的9.5％，以及CPE链接上16小时的链接小时数。
故障分类
到目前为止，我们已经确定什么时候发生故障以及它们持续多久，但仅此而已。 推断这些故障的可能原因需要额外的推理和附加数据。
除了系统日志条目之外，操作公告归档还包含大量信息，如果可用，可将简单故障转化为描述良好的事件（例如，参见图4）。 在手动审查多个通告后，我们观察到大多数事件可以分为少数类别。
我们将管理员通知分为七个类别，如表2所列。我们根据匹配的关键字，短语和正则表达式手动标记每个通知。 在某些情况下，可能会有多个有关相同故障事件的公告。 将这些多个公告组合成单个事件需要在每个公告中重复一些信息。 幸运的是，关于事件的第一个公告包含事件的开始时间，以易于识别和解析的格式。 从那里，每个额外的公告或者包含原始公告或者重新说明事件的开始时间。 最后的公告还包含活动正式结束的时间。
我们使用时间相关性来匹配故障（通过处理系统日志来计算）和潜在原因（基于管理员通知），从系统日志开始和结束故障的时间以及故障原因标记为启动时间和结束时间， 。为了找到匹配的结果，我们将运营通告的开始和结束时间扩大了15分钟，以弥补时钟同步，保守时间窗口和延迟报告等潜在问题。不幸的是，盲目地将原因分配给公告窗口内的系统日志失败会导致大量的误报。为了尽量减少这种错误，我们从公告消息中提取路由器名称或缩写，并确保在消息中提到链路中至少有一台路由器，然后再将其与相应的基于syslog的推断相匹配。对于我们的CENIC数据集，我们丢弃了2,535条消息中的1,335条（53％），尽管在系统日志中发生故障事件的同时，并没有明确提及涉及故障的路由器。手工检查可能挽救其中相当大的比例。
我们使用时间相关性来匹配故障（通过处理系统日志来计算）和潜在原因（基于管理员通知），从系统日志开始和结束故障的时间以及标记着启动时间和结束时间的故障 。为了找到匹配的结果，我们将运营通告的开始和结束时间扩大了15分钟，以弥补时钟同步，保守时间窗口和延迟报告等潜在问题。不幸的是，盲目地将原因分配给公告窗口内的系统日志失败会导致大量的误报。为了尽量减少这种错误，我们从公告消息中提取路由器名称或缩写，并确保在消息中提到链路中至少有一台路由器，然后再将其与相应的基于syslog的推断相匹配。对于我们的CENIC数据集，我们丢弃了2,535条消息中的1,335条（53％），尽管在系统日志中发生故障事件的同时，并没有明确提及涉及故障的路由器。手工检查可能挽救其中相当大的比例。
验证
系统日志数据并不是用于检测故障的，因此某些遗漏和含糊不可避免是不可避免的。 一般验证网络故障数据具有挑战性的，特别是在过去五年处理事件时尤其如此。 因此，我们采取机会主义的方法，检查与我们拥有的数据的一致性，了解到会有噪音和错误反映这些不同数据源之间的不同优势点。 特别是，我们的方法有两个主要缺点：既不完整也不是100％准确：可能有失败，我们的日志不包括，可能是我们所做的失败包括虚假，错误分类或不正确时间戳。 我们将讨论我们选择数据源所产生的潜在偏差，以及我们如何验证我们的结果并帮助量化我们的错误。
测量偏差
如前所述，由于系统日志的不可靠性，可能会从系统日志中丢失一些链接状态更改消息。因此，“下行”链路状态转换可能没有对应的先前的“向上”，反之亦然。在我们迄今为止的使用中，我们发现这些差距相对较小（占连接时间的不到13％），但这也可能是我们特定网络和硬件的人为因素。
另外，我们对链路故障的定义是基于底层路由协议报告的邻接状态。例如，为了确保连接性，IS-IS协议要求路由器发送和接收hello消息。缺省情况下，路由器每10秒发送一个hello消息，如果30秒内没有收到hello消息，则声明链路已断开。因此，我们可能会将失败持续时间减少到每失败30秒。相反，ISIS会考虑修复链路，直到可配置的保持定时器到期（此过程是动态的，但应产生类似的偏差）。
另一个模棱两可的问题在于确定每个环节的“年龄”，以便计算年度化统计数据。年龄的自然定义就是链接添加到网络和删除链接之间的时间间隔。这个定义的一个小问题是，在我们的系统日志数据开始之前（离开审查），一些链接被添加到网络中，直到我们的系统日志数据用完之后才被删除，并且/或者在syslog数据丢失的月份中继续运行（权限审查）。为了解决这些问题，我们不允许在系统日志数据启动之前将任何链接添加到网络中，在系统日志数据结束后删除网络中的所有链接，并且忽略系统日志数据中缺少时间段的任何操作时间。无法直接克服的第二个问题是维护路由器配置文件的粒度。由于接口没有创建或删除时间标记，因此我们依赖于第一个和最后一个包含有效接口描述的配置文件。不幸的是，配置更新会定期记录 - 而不是即时记录 - 因此，我们很容易在以后添加到我们网络的链接，而不是实际添加它们，并在它们可能已被删除后删除它们。
内部一致性
由于我们的数据是历史数据，而且CENIC网络运营商没有收集或维护任何我们可以用作关于失败的时间或原因的基本事实的额外日志，我们被迫寻找替代的验证方法。 我们使用两种定性不同的方法。 首先是交叉验证我们的记录; 系统日志和操作电子邮件通告之间的任何不一致或不一致都会增加出错的可能性。 虽然我们不能确定缺乏不一致意味着正确性，但我们可以量化不一致的程度以提供我们方法准确性的近似上限。 其次，某些失败可能是外部可见的，在这种情况下，我们可以利用由第三方收集的日志。
首先关注内部一致性，我们使用管理员通知（第4.2.3节）来验证从系统日志归档重建的事件历史记录。在重建这段历史时，我们使用管理员通知在可用时标记故障原因 - 特别是，如果有与特定故障有关的通告。可以理解的是，电子邮件列表中的操作员只讨论链接故障的一小部分。在这里，我们尝试相反的映射。具体来说，我们检查重建的事件历史记录是否也记录相应的事件。
理想情况下，我们将确认行政公告中提及的3,505个不同事件中的每一个都出现在日志中。由于无法从自由格式的电子邮件中提取精确的细节，因此必须手动完成匹配。因此，我们验证事件的随机子集。在我们检查的35个（大约1％）事件中，只有一个不能与事件历史中相应（一组）失败（即97％的准确率）相匹配。
外部可见的事件
在设计良好的网络中，大多数故障都被冗余链路和协议所掩盖。因此，虽然网络运营商显然有兴趣了解故障，以便他们能够解决故障并恢复正常运行，但网络用户在发生故障时可能不会注意到。但是，某种类型的灾难性故障无法隐藏：那些导致网络分区的故障。 CENIC网络连接到较大的互联网，因此，这些网络中的任何网络分区都可以从商业互联网观察到。
我们知道有两个公开可用的关于可达性的数据集，这些数据集过去可以回溯到验证我们的失败日志：CAIDA Skitter / Ark活动跟踪路由测量和俄勒冈大学路由视图BGP日志。在这里，我们开发了一种方法来验证我们的失败日志 - 至少在导致网络分区的有限失败情况下 - 通过检查公开可用的traceroute和BGP记录来验证失败日志。
CAIDA Ark/Skitter traceroute
确定链接是否停止的一种直接方法是尝试使用它。大多数商业网络运营商定期进行主动式端到端探测[26]，为他们自己的网络做到这一点。 CAIDA的方舟（néSkitter）项目通过各种跟踪路由服务器在整个互联网上的多个目的地进行零星跟踪路由[5]。偶尔，Skitter在CENIC网络内探测目的地。虽然我们对实际路线本身没什么兴趣，但我们对终点的可达性有兴趣。特别是，对于CENIC内所有目的地的Skitter探测器，我们都可以通过比较Skitter探测器的成功或失败与我们的事件记录来验证我们的失败日志：对于所有成功的Skitter探测器，我们验证所有链路已经穿越由Skitter记录方便地列举出来）根据我们的故障日志在探测时“上升”。相反，如果Skitter探测器失败，我们验证1）探测器在到达或通过CENIC网络之后失败，或者2）根据我们的探测时间离开最后一次成功跳跃的链路“下降”。
CAIDA为我们提供了涵盖我们研究六个月（2007年1月至6月）的Skitter traceroute数据 - 已经超过了四千兆字节的压缩数据。 从数据中，我们从CENIC网络中提取了75,493,637针对CENIC网络中301个不同目的地的探针，覆盖了来自17个不同的traceroute服务器，覆盖了131个链路和584个不同的路径。 这7500万个Skitter探测器的结果与我们事件历史中反映的链接状态一致。 不幸的是，在CENIC网络内部没有一个Skitter探测器失败 - 换句话说，尽管日志与Skitter数据完全一致，但Skitter并没有肯定地确认日志中的任何故障事件。
路由视图BGP归档
与需要主动探测才能检测故障的traceroute不同，被动BGP侦听器是异步通知可达性信息的。 因此，在BGP监控链路连接的情况下，其故障历史可能会更加完整。 俄勒冈大学的路径视图项目已经在全球部署了十个BGP监听器来收集BGP更新，并使其日志公开可用。 然而，BGP数据的主要挑战是其粗粒度。 BGP会根据网络或IP前缀进行说明，而不是像traceroute这样的单独的第3层链路。 因此，一个BGP侦听器将只检测整个网络变得无法到达的时间。
在考虑CENIC网络的特殊情况时，我们必须记住，多个城市中的多个核心路由器将不得不同时对网络核心进行分区。 因此，我们在研究过程中没有观察CENIC核心网络中的一个分区，这并不奇怪。 但是，大多数带有CPE路由器的客户站点只有一个路由器，并且只有一个或两个到CENIC核心的链路。 因此，如果CENIC和CPE路由器之间的所有链路都失败，则该站点将从网络中分割出来。 这种事件很少发生，但偶尔会发生。
我们为CENIC服务的60个不同网络（即客户网站）确定了IP前缀。不幸的是，我们只能使用BGP来验证这些网站的一个子集，因为CENIC不会撤回居住在CENIC地址空间中的客户的前缀（这些客户通常是像K-12学区那样的小客户）。我们在CENIC故障日志中确定了19个客户站点，这些站点拥有自己的自治系统（AS），并由CENIC生成BGP撤消消息。我们通过搜索涉及所有CPE路由器与CENIC的链接的多链路故障事件，在重建的事件历史记录中识别这些站点的网络分区。我们发现这些客户网站在发生故障期间被隔离。这种方法的一个问题是，一些客户可能会多宿主 - 换句话说，有访问除CENIC以外的其他网络的链接。在这种情况下，我们会断言，一个网站实际上只是遭受退化服务而被隔离。但是，我们没有在我们的日志或与CENIC运营商的互动中发现任何此类网站的任何证据。
位于加利福尼亚州帕洛阿尔托的Peering和Internet Exchange（PAIX）位于距离CENIC网络最近的地理位置最近的Route Views BGP监听器中。不幸的是，BGP侦听器的网络（AS6447）不直接与CENIC网络（AS2152）对等，而是与几个直接与CENIC对等的AS对等。为了适应路由视图监听器2的所有对等体之间BGP会聚的特性，如果至少有四个对等AS撤回了该站点的所有前缀，我们就声明一个根据BGP隔离的CENIC站点。除了这些隔离事件之外，我们还观察到两个或三个AS撤回所有站点前缀的情况，但其他几个AS将通告多个单调递增长度的站点前缀路径。我们将这种第二种类型的事件称为BGP路径更改。虽然隔离是网络分区的有力证明，但BGP路径更改事件也可能是由于CENIC网络内发生外部可见故障，因此也可用于验证我们的错误日志。
在我们的事件历史中的147个应该在BGP中可见的隔离事件中，我们能够匹配51来完成BGP隔离 - 即完全收敛的路由撤销（表3）。 但是，如果我们更保守地考虑BGP路径更改，我们能够确认147个事件中的105个。 值得注意的是，在其余的42场事件中，其中23场属于单一环节。 这个链接可能由一个静态配置的链接来备份，这个链接并不反映在我们的IS-IS数据集中。
分析
通过将前面章节中描述的方法应用于CENIC系统日志和运营公告电子邮件日志，我们获得一个现代化规模的生产网络的超过五十年的故障数据。 因此，我们有能力就实际网络的运作提出几个基本问题。 特别是，我们认为：
❖失败发生的频率如何？ 他们持续多久？
❖失败的原因是什么？ 某些类型的链接比其他链接更容易失败吗？
❖链路故障的影响是什么？ 网络是否适应没有显着的服务中断？
虽然我们对于结果的一般性没有提出任何要求，但我们认为对这一范围和持续时间的研究在文献中是前所未有的，而且我们的研究结果可能代表了一大类教育和研究网络。
历史一瞥
垂直条纹。图中显示了几个垂直带，这对应于全系统事件。例如，图中2005年9月标记为V1的频段是需要重启路由器的全网ISIS配置更改。 （图的规模使得链路故障同时出现;该频段实际上跨越了大约一周。）2007年3月的另一个频段（标记为V2）是全网络软件升级的结果。第三个频段V3发生在2009年2月，作为准备IPv6的网络配置变更。
水平条纹。图6还包含几个水平段。在图中间标记为H1的几乎坚实的部分对应于核心路由器和县教育局之间的链路上的一系列故障。该部分由许多短时间的故障组成，每天只发生几次。在至少一次不成功的诊断问题之后，原因最终被发现是硬件故障。
图中标记为H2的水平段对应于两个HPR路由器之间的RIV-SAC链路。从2006年7月到2007年1月，这个环节经历了33,000短时间的失败。虽然最初的原因是光纤切割，但修复过程损坏了光学设备，导致难以诊断的不稳定性。由于这种单次扑动事件占HPR网络中所有链路故障的93％，我们将其从数据集中移除以避免进一步分析偏差。
综合统计
我们通过计算关于每个链路的故障频率和持续时间的汇总统计来开始我们的分析，无论是单个故障事件还是累积链路停机时间。 表4显示了每种分布的平均值，中位数和第95百分位数。 对于所有年度统计数据，我们排除了运行时间少于30天的链接，因为它们的方差膨胀。
也许我们可能会问的最自然的第一个问题是“有多少失败？”。图7显示了每年每个链路数量失效的累积分布函数（CDF）。 我们通过将失效次数除以链接的生命周期（不包括运行链接少于30天）来计算每个链接每年的失败次数。
在直流电网络中，大多数链路几乎没有发生故障，正如人们对生产网络所期望的那样。 由客户驻地上的接入链路和路由器组成的CPE网络可靠性稍差，每个链路的年平均故障率为20.5个故障。 HPR网络经历了更多的故障。
到目前为止，我们已经独立考虑了每个链路故障。然而，正如4.2.2节所讨论的那样，我们也会根据时间相关性将链路故障分为更大的事件。特别是，我们会在适当的情况下将同时发生的故障汇总到PoP或路由器故障中，并将背对背故障组合成震荡剧集。然而，CENIC网络的情况相对较少，因此我们只专注于后者。
图8（c）绘出单个链路上故障事件之间时间的CDF。我们在10分钟处画一条垂直线，这是我们对“拍打”的定义：“在相隔10分钟以内的同一链路上的两个或更多个连续失败事件被组合成一个更大的拍打事件。 10分钟刚好超过每个网络的曲线拐点 - 分布在较长的时间间隔内显得无记忆。以这种方式构建的所有扑动事件中超过50％仅包含两次失败，但是5％的事件包含超过19次失败（未示出）。图9显示了拍打剧集内的停机时间量 - 请注意，这不是剧集的持续时间，而仅仅是剧集内链接实际下降的时段。与图8（b）相比，我们发现扑动事件整体上比典型的失败事件更具破坏性。
再次，我们的研究结果加强了以前的研究。 Watson等人 [33]和Markopoulou等人。 [23]也发现，链接拍打是不稳定的主要来源。 所有三项研究都不可能反映异常网络，相反，我们建议在大型网络中短时间尺度和振荡行为可能只是“正常”。 因此，应该准备网络协议和路由算法来处理扑动作为常见情况。
故障原因
现在我们已经量化了发生故障的频率，我们将注意力转向其原因。 我们考虑特定类型的链接是否更有可能失败，然后检查运营商明确指责的情况。
链路类型
每个组成CENIC网络由许多不同的链路技术组成，包括以太网，SONET和串行线路。 图10不是通过网络（c.f.图8）分解单个故障事件，而是通过所涉及的硬件类型来分解。 图10（a）表明以太网链路比其他技术更可靠。 图10（b）显示，虽然以太网故障不像串行线那样快速修复，但它们不太频繁（图10（c））。 这无疑部分归因于以太网在短距离链路中的优势，而短链路对外部故障过程的影响较小。
标记原因
于链接失败的一个子集，我们可以通过将它们与管理员通知相匹配来为它们注释关于其原因的信息。 我们能够将5,237（19,046）个事件中的一个与此类通知相匹配，占总停机时间的37.5％。 图12显示了根据所述原因分解这些事件的情况。 多个故障事件是由于软件升级造成的，硬件升级成为下一个最常见的原因。 然而，图13显示尽管与硬件相关的事件占据了停机时间的大部分，但软件升级造成的总停机时间要少得多; 事实上，包括电力中断在内的外部因素的影响更为显着。 数据也在表6中总结。
表5提供了关于每个类别的单个故障事件持续时间的一些基本统计数据。 大多数事件都很短，但硬件和停电的中位时间要长得多 - 超过20分钟。 然而，几乎所有的类别都有严重的尾巴，导致平均故障持续时间比中间值长一个数量级。
除了识别故障原因之外，管理员通知还会指出故障是否预计或“预定”。 管理员公告中发现的大多数故障事件都是按计划进行的，但大部分实际停机时间都可能归因于意外故障，这可能是因为操作员注意确保计划停机时间尽可能有限。 实际上，计划停电的中值时间不到5分钟（未显示）。 有趣的是，似乎在影响网络运行的事件发生之前，网络运营商往往不会通知外部实体。
故障影响
总的来说，我们很难从故障日志中得知故障对网络用户造成的影响（如果有的话）。 但是，对于通过管理员通知注释的事件集，我们可以报告通知是否明确说明事件是否应该对网络产生影响。 表6的第三列指出事件的哪一部分应该对网络产生一些影响 - 不过是简短的。 在几乎所有情况下，运营商都会指出可能导致链路停机。 然而，这种现象可能是由于运营商的自我选择造成的。 无影响的失败事件 - 尤其是不定期的事件 - 似乎不太可能激励运营商发布公告。
正如第5节所讨论的那样，我们可以推断的唯一影响是隔离网络分区。 表7列出了我们在故障日志中识别的508个隔离故障，将它们分成有和没有自己的AS的网络，并提供原因注释（如果可用）。 有趣的是，分区事件失败原因的细分与所有事件有所不同 - 在这里，软件失败占主导地位。 表8总结了不同原因引起的隔离故障的修复时间分布，与所涉及的AS无关。 与非隔离事件一样，电源和硬件事件的持续时间明显长于软件故障引起的持续时间。
时间动态
像大多数复杂系统一样，CENIC网络正在不断发展。 从2008年开始，最重要的变化是将一些DC路由器指定为“核心”路由器，其余为“接入”路由器。 这导致了235个链接的退役和引入了432个新链接。 那么一个自然的问题就是，早期检查的网络质量是否也发生了变化。 图14显示了测量期间每年DC网络中的年度链路停机时间。 我们期望在6.2节中提出的基本统计数据中找到趋势。 事实上，我们发现这些绩效指标每年都不一样，没有明显的趋势。 2006年以及2008年的较低程度，脱颖而出的是与前几年和后几年相比，链接停机时间更短。 每个环节的年度失败次数也相应变化，2006年最低的中位数为0.0，2005年最高的中位数为6.0。
进一步调查，我们发现6.3.2节中研究的原因分布也不尽相同。 几个全网事件负责链路故障数量的显着变化。 最值得注意的是，与软件相关的链路故障和配置更改是几年内链路故障的重要来源，而不是其他故障。 由于网络范围内的升级和配置变更（见第6.1节），图6中的三个垂直频段对2005年，2007年和2009年的故障的中值数和中值链路停机时间产生了重大影响。纵向趋势（如果存在的话）因此是矮化的 由重大但罕见的事件。
结论
在本文中，我们提出了一种推断和分析缺少专用监控基础设施的网络的链路故障历史记录的方法。 特别是，我们表明，现有的“低质量”数据源已经广泛地集中在生产网络中 - 系统日志，路由器配置和运营邮件列表 - 可以机会性地组合以重建拓扑，动态状态和故障原因。 使用这种方法，我们分析了来自CENIC网络（一家大型加州互联网服务提供商）的五年链路故障历史，并验证了有关故障的现有理解（例如，链路振荡的普遍性）并记录了较少的赞赏性问题（例如，大 由第三方租用线路问题造成的停机时间）。 我们认为我们的整体方法相当一般，应该很容易适应各种IP网络。