BGP就可以办到监控全球互联网?

懂技术的辉太狼

03-1320:18

之前的文章中,我们提到了一种基于BGPStream的分布式体系结构,并利用Apache Kafka(分布式消息系统)来执行连续的全局BGP监控。我们的目标是双重的:我们演示了BGPStream如何启用和简化开发复杂的全球监测基础设施;并且针对出现的挑战,我们在下文中提出了有效的解决方案。

为了构建开发这种复杂体系结构的背景和动机,让我们考虑两个示例应用程序,即“互联网中断:检测和分析”(IODA)和“劫持”(Hijack)研究项目。在IODA中,我们24/7全天候监视互联网来检测和描述宏观连通中断现象。对于BGP,我们的目标是了解一组前缀(例如,共享同一地理区域或同一起源AS)是否可全局访问。来自单个探测源的信息不足以验证中断的发生,事实上,由于本地路由失败,探测源可能无法访问前缀。另一方面,如果拓扑上和地理上分散的几个探测源同时丢失了部分前缀,那么这些前缀本身可能正在经历中断。在劫持中,我们感兴趣的是检测和分析基于BGP的流量劫持。由于大多数常见的劫持表现为两个或更多个AS同时宣布完全相同的前缀或相同地址空间的一部分,因此检测它们需要比较从多个探测源观察到的前缀可达性信息。

为了及时检测这些事件,我们需要保持一个全局的(如,针对每个VP)视图,并且拥有更新精细时间粒度(例如,几分钟)的更新BGP可达性信息。这种不断更新的全局视图可以在许多其他应用中使用,例如跟踪包含特定AS的AS路径、验证路径泄漏的发生、发现AS级拓扑图中出现的新的(可疑的)AS链路等。

图1 实时监控分布式架构

在图1中描绘了我们建议的体系结构:多个BGPCorsaro进程数据(每个进程收集器一个实例,以便跨多个CPU/主机分布计算),它们的输出被存储在Apache Kafka集群中,并由应用程序(消费者)进一步处理由同步服务器生成的元数据。在下面的小节中,我们描述这个体系结构的主要组件以及它们所解决的挑战:首先,我们解释了如何高效且准确地重构每个探测源的可观察的LocRIB;然后说明了如何减少我们存储的数据量,以及稍后对消费者的处理;第其次展示了如何根据应用程序需求来支持不同同步机制的问题;最后我们提供了作为消费者实现的应用程序的示例。

重新构建探测源的路由表

RIB类型的dump文件通常每2或8小时可用一次。我们的目标是以1或几分钟的粒度重构每个探测源的可观察的LocRIB(这里称为路由表)的快照。为此,我们开发了一个BGPCorsaro插件,称为路由表(RT)。RT插件使用RIB类型的dump文件作为起始引用,然后依靠Updates类型的文件来重构路由表的演进,使用后续的RIB类型的dump文件进行健全性检查和校正。然而,由于这是一个基于异构测量数据的分布式收集的推理过程,因此可能出现许多问题:BGP会话失败、数据损坏、dump文件发布无序等等。我们通过维护有限状态机和数据结构来解决这个问题。综合考虑探测源的状态,其路由表和我们认为数据正确的信息度来建模。特别是,我们处理以下四个特殊事件:E1。如果libBGPStream标记其至少一个记录被损坏,则忽略该RIB类型dump文件中的所有记录。E2。由于来自单个RIB类型dump文件的记录常常跨越几分钟的时间戳,并且RIB和Update类型dump文件可能被无序地发布,因此插件可以接收一些老的RIB类型的dump文件记录,这些记录比插件应用的最新更新记录要老。为了解决这个问题,我们检查RIB类型的dump文件的每个单独记录,并且仅当记录的时间戳比插件已经应用的信息的时间戳更近时才使用这些记录的信息。E3。在接收到损坏的更新类型dump文件记录时,我们停止应用更新并等待下一个RIB类型dump文件。E4。我们在接收到某些探测源状态消息时强制进行状态转换(例如,使用已建立的代码接收到状态消息触发到激活UP状态的转换)。

图2 有限状态机

我们将状态和路由表信息保存在多维哈希表中,该哈希表可以看作是一个前缀(prefix)作为行和探测源作为列的矩阵。每个单元格包含前缀(例如,AS路径)的可达性属性、单元格上次被Updates类型dump记录修改的时间戳、以及指示这种操作是通知还是撤回的A/W标志。此外,对于每个单元格,RT插件使用影子单元格临时存储来自新RIB类型dump的记录,直到它接收到其最后一条记录:如果没有RIB类型dump记录损坏(E1),我们将用影子单元的内容替换主单元的内容,除非RIB类型dump记录比主单元的最后修改时间(E2)要大。

图2描述了将一个探测源的路由表维护成有限状态机的过程,该有限状态机对探测源的状态进行建模。当插件启动时,探测源的路由表不可用,探测源处于Down状态(1)。当新的RIB类型的dump开始时,探测源的状态移动到Down RIB Application状态。在这个阶段,插件使用从RIB类型dump记录接收的信息填充阴影单元格,并使用Updates类型dump记录填充主单元。一旦接收到整个RIB类型dump记录,探测源的状态就变成(3);当在这种状态下,路由表被确定探测源路由表的准确表示。每个新的通知或撤回记录触发主单元的修改,而如果新的RIB类型dump开始,则探测源的状态转换到UP RIB Application状态(4),类似于(3)的状态,但是RIB类型dump记录修改单元的影子信息。一旦RIB类型dump结束,阴影和主单元合并(如前所述),并且探测源再次转换到状态(3)。此外,一个损坏的更新转储记录迫使状态改为Down状态(E3)。接收到携带有已建立代码[52]的状态消息的Updates类型dump记录将探测源的状态移动到UP状态(E4),而接收到任何其他状态消息指示探测源和收集器之间的连接未建立,因此,探测源被认为是DOWN状态 (E4)。

为了评估我们的方法的准确性,我们周期性地比较当前和阴影小区中的信息。RIS和RouteViews的错误概率(定义为所有探测源的所有前缀中不匹配前缀的数量)在31个收集器上经过12个月计算后分别是10.8和10.5。我们发现,不匹配通常由没有状态消息的无响应探测源(例如,RouteViews)或收集器在启动RIB类型dump之前没有应用所有传入的更新消息(但是之后应用它们,即使它们已经被分配了时间戳)引起。

运行时的IO情况:差异, (非)序列化, Kafka

在每个时间仓的末尾,RT插件将每个探测源的重构路由表发送到Kafka集群。然而,为了减少要由使用者存储和稍后处理的数据量,我们开发了允许RT插件计算在前一时间段生成的路由表与当前时间段生成的路由表之间的差异,并且只传输改变的部分(我们称呼为差异元素)。消费者使用互补例程从Kafka检索数据,并通过对先前存储的版本应用差异来重构完整的路由表。产生的数据结构标记路由表的更新部分,允许使用者分析这些数据。我们还定期(例如,1小时)在Kafka集群中存储整个(非差异)路由表,应用程序可以使用这些表进行同步,以便接收将来的差异数据。

图3突出了只处理路由表之间的差异而不是处理每个更新消息的优点(就处理的BGP元素数量而言)。我们在2016年3月份的来自route-views2的数据上运行RT插件:在图表中,红色圆圈显示从每个时间段内的BGP更新消息中提取的BGP元素的平均(底部)和最大(顶部)数量,而蓝色方块显示连续路由表之间的差异元素数量。当时间仓为1分钟时,仅存储差异数据比全部存储的BGP元素数量平均少3倍,这表明即使在如此短的时间尺度上更新消息也存在冗余。随着时间仓的大小增加,减少因子也增加,但以时间粒度为代价;1小时的时间仓产生的差异单元比BGP单元少13倍。此外,最大值表明,通过处理差异,消费者对突发更新(例如,由于前缀翻转)更有弹性。

图3 存储差异 VS 全部存储

数据同步

不同的收集器、不同的数据源提供数据具有不同延迟。执行数据同步需要在延迟、处理时可用的数据量和内存占用之间进行权衡。这种权衡的最佳点取决于具体的应用目标和要求。而不管延迟如何,监视应用程序可能需要当前时间段的所有可用源(或给定部分)的数据。其它应用程序可能具有严格的实时要求,并且喜欢显式设置超时。例如:在劫持的实时检测中,一旦检测到可疑的BGP事件,我们就设置几分钟的超时以执行traceroute;相反,在IODA应用程序中,我们放松延迟约束,以利于数据完整性,并使用30分钟的超时,因为它的结果是确保所有探测源的多个RT路由表在99%的时间段内可使用(在2014和2015年已经有确凿的数据可以验证它)。

我们设计了一个基于存储在Kafka中的元数据和多个同步服务器的系统,每个同步服务器实现不同的同步机制:每个BGP Corsaro RT插件在Kafka队列中写入路由表,索引元数据;这些元数据由同步服务器监控。同步服务器负责基于它们实现的同步标准,将元数据注入Kafka队列中它们自己的主题中,以将数据标记为准备使用。通过使用Kafka,所得到的系统是水平可伸缩的(因为Kafka支持跨多个节点分布数据)和健壮的(例如,由于数据复制)。此外,由于同步服务器只处理具有小内存占用的轻量级元数据,因此不会影响可伸缩性。

消费者

消费者实现分析从Kafka检索的路由表,并执行事件检测、提取统计信息作为时间序列输出。我们开发了两个消费者用于每个国家和每个AS的近实时中断检测。两个消费者都选择由全馈送VP观察的前缀,并通过计算位于每个国家并且由每个AS宣布的前缀的数量来监视这些前缀的可见性。消费者将这些数据存储到支持自动变化点检测和数据可视化的时间序列监控系统中。

图4 可见的伊拉克IP前缀(2015年6月20号-7月20号)

图4显示了在一个月期间(2015年6月20日至7月20日)每个国家和每个AS的中断数据,选择与伊拉克有关的可见前缀和伊拉克5个最大的ISP。这些明显的下降反映了在政府进行部长级预备考试时在全国范围内发生的一系列互联网中断。

分享给好友:
 
在线咨询
大带宽机柜
微信咨询

扫一扫
微信咨询客服

全国服务热线
0755-88848868
0755-88848825

售后服务
备案咨询
在线技术
工单系统
返回顶部