2021年10月4日Facebook史上最严重宕机复盘分析

专注IP定位
• 阅读 1412

1、相关新闻

据BBC等媒体报道,UTC时间2021年10月4日15时39分(即北京时间10月4日23时39分),社交网络Facebook及其子公司Messenger、Instagram和WhatsApp全球无法使用长达7个小时。

Facebook在其twitter中发表官方声明“Our engineering teams have learned that configuration changes on the backbone routers that coordinate network traffic between our data centers caused issues that interrupted this communication. This disruption to network traffic had a cascading effect on the way our data centers communicate, bringing our services to a halt” (翻译:调度数据中心之间流量的骨干网路由器配置变化造成了这次通讯中断。这种网络流量中断对数据中心的通信产生了连锁效应,最终导致我们服务宕机。)

可以看出官方的答复并没有很清楚地说明错误原因。因此我们复盘给出宕机事故的根本原因。

2、Downdetector监测到Facebook网络波动 2021年10月4日Facebook史上最严重宕机复盘分析

图1 Downdetector监测到Facebook网络波动 Downdetector网站通过收集社交网络中的中断信息来推断断网,如图1所示。Downdetector在EDT时间的10月4日11时44分(即北京时间10月4日23时44分)检测到Facebook网络波动问题,具体原因没有说明。

3、Facebook和WhatsApp服务中断原因分析 Facebook的AS为AS32934,WhatsApp的AS为AS11917。

北京时间10月5日凌晨0时(UTC时间10月4日16时整)观察到Facebook(AS32934)出现网络波动,其Prefix数量和IP数量都有所减少。直到北京时间10月5日早上7时整,Prefix数量和IP数量恢复,如图2所示。其中,Prefix数量由10月4日23时30分的129个减少为10月5日0时的103个,Prefix数量减少了26个,共计5,888个IP。丢失IP块明细如下:

129.134.25.0/24、129.134.26.0/24、129.134.27.0/24、129.134.28.0/24、129.134.29.0/24、129.134.30.0/23、129.134.30.0/24、129.134.31.0/24、129.134.65.0/24、129.134.66.0/24、129.134.67.0/24、129.134.68.0/24、129.134.69.0/24、129.134.70.0/24、129.134.71.0/24、129.134.72.0/24、129.134.73.0/24、129.134.74.0/24、129.134.75.0/24、129.134.76.0/24、129.134.79.0/24、157.240.207.0/24、185.89.218.0/23、185.89.218.0/24、185.89.219.0/24、69.171.250.0/24

2021年10月4日Facebook史上最严重宕机复盘分析

图2 网动仪捕获到Facebook(AS32934)有明显波动情况发生

Facebook有4个权威DNS服务器,分别是a.ns.facebook.com(129.134.30.12)、b.ns.facebook.com(129.134.31.12)、c.ns.facebook.com(185.89.218.12)和d.ns.facebook.com(185.89.219.12),4个DNS服务器IP都在丢失的IP块中。

因此,这次故障的原因是调度数据中心之间网络流量的骨干路由器配置更改导致边界网关协议撤销了Facebook自治域AS32934下包含Facebook域名服务器IP的IP地址块,抹去了Facebook需要的DNS路由信息,紧接着DNS服务器离线,用户无法解析Facebook和相关域名并访问服务。

同时,在北京时间10月5日凌晨0时开始也监控到了WhatsApp(AS11917)下所有Prefix、IP和路径的丢失,如图3所示。

2021年10月4日Facebook史上最严重宕机复盘分析

图3 网动仪捕获到WhatsApp (AS11917)有明显波动情况发生

WhatsApp服务也无法访问的原因是:在2019年Facebook 合并旗下所有服务并实现集中化,使公司可以统一了解用户的互联网使用习惯。但是,这也使得本次单点故障影响了整个Facebook服务体系。

综上所述,埃文科技网动仪捕获到Facebook的AS32934和WhatsApp的AS11917的网络波动,波动时间也与新闻报道的Facebook断网时间吻合。服务中断原因是主干路由器上的配置更改导致边界网关协议(BGP) 撤销了托管Facebook域名服务器的IP地址前缀,进而引发的一系列服务异常。

点赞
收藏
评论区
推荐文章
blmius blmius
3年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
待兔 待兔
3个月前
手写Java HashMap源码
HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程HashMap的使用教程22
Jacquelyn38 Jacquelyn38
3年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
Easter79 Easter79
3年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Stella981 Stella981
3年前
HIVE 时间操作函数
日期函数UNIX时间戳转日期函数: from\_unixtime语法:   from\_unixtime(bigint unixtime\, string format\)返回值: string说明: 转化UNIX时间戳(从19700101 00:00:00 UTC到指定时间的秒数)到当前时区的时间格式举例:hive   selec
Wesley13 Wesley13
3年前
Java日期时间API系列36
  十二时辰,古代劳动人民把一昼夜划分成十二个时段,每一个时段叫一个时辰。二十四小时和十二时辰对照表:时辰时间24时制子时深夜11:00凌晨01:0023:0001:00丑时上午01:00上午03:0001:0003:00寅时上午03:00上午0
Wesley13 Wesley13
3年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
为什么mysql不推荐使用雪花ID作为主键
作者:毛辰飞背景在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究
Python进阶者 Python进阶者
9个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这