专栏首页鹅厂网事可视化网络路径探测HashTrace

可视化网络路径探测HashTrace

引子

长期以来,探究网络质量和探索网络路径是广大网络工作者监控网络的必备工作,ping用于探究网络质量和traceroute用于探索路径。对于探测结果似乎也不是那么靠谱——有很多人都有过经历业务有明显的网络方面影响,但ping和traceroute可能是OK的。这种网络问题的处理往往也是最令运营者头疼的地方,也许是到了寻找一个更佳工具的时候了。

挑战

作为内行,大家也都造现在的网络设计讲究双节点冗余保护——几乎每一过一个hop都有2台或2个以上的冗余节点,在路由上形成非常复杂的ECMP(假设端到端路径中有n个hop均是2台节点,那么端到端ECMP一共有2^n个),传统的ping和traceroute在这种场景中有几个缺陷:

l ping和traceroute的执行是命令行方式,返回结果也是命令行环境的字符串形式,解读起来不够直观,特别是traceroute需要一定的网络功底;

l 网络设备在ECMP转发时,由于不同链路转发延时的区别,如果对于一个会话的数据包在所有ECMP路径上轮询转发,会导致jitter,网络体验会非常差,所以网络设备会将每个会话的所有数据包都发往其中一条路径,会话和路径的确立是通过hash计算来完成的,每一次ping和traceroute都是一次会话,因此每次ping和traceroute都只能探测其中一条可能路径,其余路径是无法被探测到的,也许你想到了多次ping和traceroute,但依然不一定可以探测所有路径,traceroute的解读甚至有可能是环路或者伪路径,此外由于hash算法的核心是hash因子,包括5元组、3元组甚至1元组,每次执行ping和traceroute不能保证和业务会话的hash因子一致,因此一个很有可能的情况是ping和traceroute探测到的是路径1,并不是业务实际路径——路径2,这就是为什么业务有故障,而ping/traceroute是正常的根源;

l 网络通信是双向的,网络设备的hash在两个方向是独立计算的,因此一个很现实的结果就是一个A<->B会话在A->B方向选择的是路径1,在B->A方向可能是路径2,而ping和traceroute都是单向探测,如果需要双向探测,那就需要在两个方向分别执行ping和traceroute,如果需要探测双向路径质量,就需要在两个方向执行ping和traceroute,操作复杂;

l 只能探测L3链路,如果是存在前面几期提到的L2 ECMP或者MPLS TE隧道,traceroute无法反馈L2 ECMP结果和MPLS TE隧道信息,这些信息我们称为物理路径。

我们面临的挑战是,业务最需要的是一个执行1次、可以探测业务实际双向物理路径质量、输出直观的网络路径探测工具。

对策和方案

为了探测所有可能的ECMP,Paris Trace出现了,它可以发现并探测端到端的ECMP各个冗余节点。巴黎Trace的原理是将网络看做一个黑盒,通过不断调整traceroute会话中的hash因子以遍历转发路径上所有设备可能的hash结果。但巴黎Trace并不能很好地应对挑战:

l 它的输出依然是字符串方式的,还是很不直观;

l 它可以探测出所有路径,但并不能告诉我们业务实际路径是哪个;

l 它不具备ping的功能,也不能告诉我们反向路径是哪一条;

l 对于L2 ECMP场景和MPLS TE隧道也无法探测。

应该说巴黎Trace可能更适合在互联网上探测,因为网络细节不在我们掌握的互联网是一个黑盒。如果是在一个网络细节都在我们掌握的内部网络中,我们是不是可以做的更多呢?这就是我们今天要探讨的话题,在更加可知的内部网络中完成我们的挑战:业务只需要执行1次、双向实际物理路径图形化显示、双向实际物理路径质量报告——可视化网络路径探测HashTrace。原理也比较简单,内网拓扑是规划的,对于任意两点间的路径也是规划的,路由协议也是按照规划的方式计算任意两点间的路径,如果计算路径不在规划之内,那说明路由协议计算出了问题,可以使用上一期“网络自动化监控”的方法发现并修改,因此当路由协议计算结果符合规划的时候,我们可以将网络转发中更符合业务了解路径质量的信息挖掘出来。

图1:内网中从源到目的单向转发路径示意

如图1展示了一个Source到Destination在内部网络中的实际物理路径,包含ToR到Spine到园区边界再到区域根,绿色路径经过沿途各hop设备在多路径之间实际hash后的转发路径(Sping和Zone Border之间存在L2 ECMP,Zone1 Border和Zone2 Border之间是MPLS TE隧道)。这个图是手工绘制的,如果这个图能够让一个网管系统来自动、实时地画内网端到端路径,同时告诉大家每段链路的转发路径,这个系统就有点像电影中的场景了,就是HashTrace要实现的功能——一个多层画布叠加的网络状况显示系统:

1. 系统提供实时的输入界面,输入信息包括源和目的主机信息(可以是Host name和NIC name的组合,也可以是IP地址,一个管理良好的运维数据库是一定可以做到Host name-Nic Name与IP地址的双向查找的),应用信息(协议号,如TCP/UDP,及源端口、目的端口);

2. 系统预先根据全网运行的LLDP协议发现全网拓扑,实现整个图的最底层的公共画布;

3. 第二层画布的绘制通过实时查找路由来完成,系统从源开始检查匹配目的IP地址的路由配置,查到只能匹配网关路由,而网关正好是ToR1,系统已经可以描绘出Source Server->ToR1这部分箭头图形了;

4. 第二层画布会继续沿着每一条路由的hop进行绘制,系统再从ToR1的路由表上检查匹配目的IP地址的路由,查到有2条等价ECMP了,next-hop分别是Spine1和Spine2,具体是选择Spine1还是Spine2呢?

5. 这就是第三层画布的工作——绘制hash后的实际路径,一直以来hash被认为实时性太强,是很难被网管的?这里要介绍一下神器——ToR厂商提供的hash函数,网管可以读取每一台设备所采用的hash算法(包括函数和因子,根据输入因子可以计算出选择第几个next-hop),HashTrace可以在后台模拟ToR1进行hash计算了,假设根据步骤1输入的5元组信息计算出来是选择了Spine1,系统可以画出第三层画布的绿色箭头,表示hash结果,hash结果可以通过sFLow/NetFlow检验;

6. 后面几个hop绘制工作基本相似,逐渐地系统绘制到了ToR2,系统在ToR2上查到匹配目的IP的路由是类型是direct或connected,恭喜系统,系统可以准备跳出这个循环了,再检查目的IP对应的ARP条目、MAC地址表,找到物理端口,和目的主机保存在数据库中的信息比对一下,至此HashTrace绘制出了一条端到端单向的地图——包括各hop节点信息、候选ECMP信息、实际转发信息;

7. 在第三层画布绘制过程中涉及到了hash,路由hash的结果出了可以得到具体的next-hop和egress port(转发出方向端口),假如egress port是LACP形成的虚拟聚合端口,此时又涉及到L2 ECMP,需要再次利用设备上L2 hash函数计算L2 ECMP结果,可以得到新的egress port不再是虚拟聚合端口,而是物理端口,此时就可以不用继续hash计算了,还有一种情况是路由hash结果egress port是MPLS TE隧道端口1(通过PCEP控制器根据全局信息计算所得),此时HashTrace就会向PCEP控制器所要MPLS TE隧道端口1的底层物理转发路径,这就是HashTrace得到物理转发路径的方法;

8. 前面7个步骤都是用于描绘转发物理路径,确定物理路径上的每一条链路,端到端转发质量也变得唾手可得,我们将ping探测端到端转发质量的问题化解为探测每段链路的质量,对于每条物理链路利用率、丢包统计、延时信息,当前的网管都是可以获得的,HashTrace将这些信息转化成流量箭头的粗细,用于提示哪段路径可能是重载,哪段可能是轻载的,从而得出端到端转发路径的质量,运营同事可以根据直观的图示判断哪条链路最有可能是丢包的元凶。

这个系统全程会展示每hop设备的device name,ingress/egress Port Name,以及Port的IP地址。双向路径显示是HashTrace的一大特色,只需要在系统中将source/destination信息对换一下,就可以找到反向路径,如图2所示,蓝色为反向路径,绿色为正向路径:

图2:HashTrace可以同时绘制出双向转发路径

HashTrace并不是替代巴黎Trace,HashTrace的适应场景主要在于可控的内网,而巴黎Trace可以探测任何网络特别是互联网的链路质量,尽管结果不是那么直观,巴黎Trace在内网也可以利用HashTrace的结果更有针对性。

意义

HashTrace实际上展示了利用现有网管系统能够获取的信息,稍作处理,可以挖掘出帮助运维的好工具,甚至可以帮助我们调整不同hop设备上的hash算法,以实现更佳的业务体验。继上一篇“从MH370看网络自动化监控”,HashTrace离网络用户更近,用户可以简单操作、清晰掌握其流量在内网的运行状况和质量,甚至可以根据这种流量做业务模型调优,减少对高峰期网络带宽的占用等等有意思的事情,这套系统也可以和DWDM网管结合,查看更为底层的光传输质量,总之,当前的网管可挖掘的地方还有很多,鹅厂期待与您携手。

本文分享自微信公众号 - 鹅厂网事(tencent_network)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2014-08-08

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • rpc框架之HA/负载均衡构架设计

    thrift、avro、grpc之类的rpc框架默认都没有提供负载均衡的实现,生产环境中如果server只有一台,显然不靠谱,于是有了下面的设计,这其实是前一阵...

    菩提树下的杨过
  • 腾讯海量监控体系经验分享

    提及腾讯的海量监控的挑战,将近 20 套监控系统,指标有将近 300 多个,监控的实例超过 900 万。

    腾讯大讲堂
  • IDC发布IT转型报告,现代化、自动化、转型三要素必不可少

    最新IDC发布了数字化转型报告,较为系统和全面地介绍了数字化转型从哪里开始?目标是什么?过程中需要注意的地方。虽然内容较长,需要耐心看完,但是干货很多,值得一看...

    企鹅号小编
  • 开启MySQL的binlog日志

    binlog 就是binary log,二进制日志文件,这个文件记录了mysql所有的dml操作。通过binlog日志我们可以做数据恢复,做主住复制和主从复制等...

    似水的流年
  • redis 学习笔记(4)-HA高可用方案Sentinel配置

    上一节中介绍了master-slave模式,在最小配置:master、slave各一个节点的情况下,不管是master还是slave down掉一个,“完整的”...

    菩提树下的杨过
  • 入门必读:Hadoop新手学习指导

    零基础学习hadoop,没有想象的那么困难,也没有想象的那么容易。从一开始什么都不懂,到能够搭建集群,开发。整个过程,只要有Linux基础,虚拟机化和java基...

    挖掘大数据
  • 服务器负载监控以及文字处理脚本

    运维监控总少不了一些脚本来监控自己的机器,博主自己写了个监控,并通过sleep来控制输出的间隔时间。如果想要获取其他的相关信息,可以采用类似的方式,添加即可。 ...

    用户1154259
  • PostgreSQL 与 MySQL 相比,优势何在?

    一、 PostgreSQL 的稳定性极强, Innodb 等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步,然而很多 MySQL 用户都遇到过Serve...

    张善友
  • Docker容器入门

    为什么要看docker 从去年起就或多或少的接受了docker的熏陶,主要还是Infoq在去年有很多关于docker的实践视频讲座,记得有一篇是《Docker在...

    用户1154259
  • 陈辉:蘑菇街技术架构规划与成长

    美丽联合集团旗下有美丽说、蘑菇街、淘世界等产品和服务,是中国最大的女性媒体与时尚消费团体。负责美丽联合集团电商架构工作的陈辉在现场为大家带来了“蘑菇街技术架构规...

    云加社区专栏

扫码关注云+社区

领取腾讯云代金券