网络运维 - 你与真相就差一层窗户纸

Posted 2020-11-04

回归，带着满满的干货回来了

大家好，我是姜汁啤酒。

你可能觉得莫名其妙，从今年二月份这个经常上头版的网工兄弟，居然突然从51cto消失了，博客也不更新了？莫非，哥们，不会，和埃隆马斯克去火星了吧？

其实，需要给大家解释解释，我消失了三个月一共完成了两件大事。

1. 我在51cto写了一个专栏:《老司机网络运维干货集锦》，里面涵盖了路由、交换、安全、QOS四大模块知识点，大家感兴趣的可以猛戳此链接详细了解：http://blog.51cto.com/cloumn/detail/2 。目前专栏还剩路由篇待更新，其他模块已经完毕。

2. 这三个月跳了个槽，从资深工程师摇身一变成为首席设计网络师，事情相对也多了起来。加上刚到一个新地方怎么都得装一装样子，老油条们，你懂的。

因为上述两件事，搞得最近忙的没来得及更新博客。

今天正式回归后，本来想继续更新我之前的数据中心系列。但是考虑再三，索性想和大家聊聊我对于网络运维的看法，以及写这个专栏的出发点，同时也希望和志同道合的朋友们一起分享分享网络运维的见解。

网络运维，痛并快乐着

当你因为这篇文章的标题，尤其是网络运维这四个字把你吸引进来时。

我大概知道你也是网络运维同行的一份子，相信你有着对网络技术的狂热爱好和对技术细节的极致追求。

可是，有时候现实的工作和理想的追求往往会不小心就差了好远，日常的网络运维工作不仅繁琐，而且出的故障都是千奇百怪，让人无法琢磨透。

更不用提反复无常的加班，通宵调整，割接等操作了。

但是苦中作乐，当每一个故障都被解决以后，内心那种酣畅淋漓的满足感，总会让你能够短暂的忘却身体的疲乏，享受片刻的欢愉和宁静。

可是，我落井下石的提一个疑问句。你觉得问题解决了，是彻底分析透彻并从根源上解决了？ 还是找了个变通方法，临时处理掉问题？

仔细想想，其实内心五味杂陈，你不用说，我也懂。

有多少个故障，就有多少个故事

故事1：不做过滤的路由重分发

最近作为首席设计师的角色入职新公司以后，花了些时间摸底公司网络架构。听了听同事说说以前的故障案例，以及解决方案。

听完以后，不禁让我觉得可笑，但又打寒颤。

一个经典的双点双向重分发场景。A和B均把MPLS和LAN的路由互相重分发到两端的网络内。结果有一天LAN内部某一条路由震荡，结果此路由非但没消失。反而导致整个网络三层环路。

最后的解决方法就是把B点的备用链路给断掉，问题解决了，但是从此B链路再也没有开启过。

这就是所谓的解决方案。

我觉得滑稽，是因为很明显此类的重分发一定要在A和B上面做路由过滤，千万不能让两端的路由互相在A和B点之间互相发布。

而我打寒颤，则是觉得如此重要的网络节点居然单点运行，而且未来还得为了这个问题再次返工修改，费时费力。

最根本的原因在于，当出故障以后，未能认真分析问题根源，并把它解决掉。而是草草收场，等待下一次隐患。

故事2：一台小交换机造成的血案

上面的故事，是单独的案例么？

答案肯定是“不”。

不知道你是否经历过插入新的交换机结果把全网的VLAN冲掉的惊慌失措。

也许，当某些经验不足的工程师接到无数的投诉以后，仍然百思不得其解，不就是插入一个交换机么，怎么可能会造成几百米开外的其他大楼网络全挂了。

我相信若他知道全网VLAN信息全消失以后，加之VLAN数据库从来不备份的话，此次事故将是永生难忘的一堂课。

针对以上问题，很多朋友的解决方案就是：禁止一切Cisco交换机使用VTP协议，一切VLAN全网手工配置。

本来VTP带来的巨大便利就因为对于协议理解不透彻，协议的便利和优势就彻底丧失掉了。

故事3：Port-channel干掉全网

我的一个朋友告诉我，他们配置Port-channel居然也把全网干掉了。

我说，这Port-channel该不会怪罪到VTP上了吧，人家可是彻底躺枪了。他其实也不太明白，为什么配置一个简单的Port-channel居然能够把全网弄摊了，这网络得有多么的脆弱才行。而且，Port-channel日常工作中配置了无数遍，怎么这一次就栽在这上面了。

不对，肯定是软件bug问题，或者什么不可解释的神秘力量？

同样的，问题的根源没有分析清楚。取而代之的则是全网禁止使用port-channel。

故事4：“裸奔”的网络

相信大家都知道电脑“裸奔”是什么意思，那何为“裸奔”的网络？

在我来看，裸奔的网络有两层含义。

第一：此网络不存在任何安全措施可言，恶意渗透可以来自内部或者外部，网络设备非常容易沦陷。
第二：网络存在的目的在于传输数据包，若发送的数据包无法尽可能的完整到达接收端，网络设备没有任何QoS保护措施保障数据包的传输，那么此网络设备也可以称作为“裸奔的”网络。

尤其第二项，Qos的设计和部署对于工程师的理论知识要求较高，若对于QoS一知半解的话，部署的Qos问题比不部署还严重。

故事还在继续。。。

故事5：永不安全的防火墙

此标题很有意思，因为它违背了常理。

按理说，防火墙是为了加固网络安全才部署的，怎么说防火墙用不安全呢？

其实，防火墙是安全的，不安全的是人心。

仔细想想日常运维中，经常有很多不懂网络技术的人对你指手画脚：

• 谁谁谁，我的网络怎么不通了？

• 为什么上不了这个网站了？

• 网速怎么这么慢啊？

最后这些非IT人士都统一得出一个结论，防火墙出问题了，他们不懂路由交换。只知道防火墙是阻挡一切的罪魁祸首。

这个锅，防火墙背上了。

有上黑锅的，自然也得有卸锅人。于是，网络运维工程师就成为了拆弹专家，你需要仔细核查防火墙的安全策略，路由，逐步排查故障，确保不是防火墙问题。

那如何核查，防火墙的详细工作原理和数据包处理流程是什么? 问题分析逻辑是什么？如何下手等？

此类问题经常困扰着你和我。

总结：我们离真相只有一层窗户纸

其实很多问题，我们稍稍往前走一步，就可以看见真相。

但是很多运维的朋友选择在遇到奇葩问题的时候，退而求次其次，掩盖住问题就好，何必费劲力气往前冲呢？

也许短时间之内问题被掩盖了，被所谓的“解决掉了”。但是总有一天，这个问题就像星星之火一样，卷土重来，把运维人员烧的外焦里嫩。

所以，作为一个过来人，我觉得很有必要把自己日常追求问题根源的经验分享出来，供大家参考。

而更重要的是，除了分享经验以外，是希望通过有限的例子给大家展示一个处理故障和问题的思路。

日常运维中，你不可能套用某一个故障的具体处理办法到另外一个故障，但是处理故障分析思路却可以反复使用。

介于此，我决定写此专栏，希望自己所学所思的东西能够帮助到大家，能够有所启发。

此专栏通过“网络路由篇”，“网络交换篇”，“网络安全篇”，“QoS篇”四大典型技术模块，分别给各位讲述运维中的网络设计思路和一些运维的技术难题。相信你通读完各个模块以后，会刷新你对于某些知识的认知。

传送门如下：
老司机网络运维干货集锦

若你在日常运维中，还需要了解其他方面的问题，请给我留言。我会根据各位的反馈，继续迭代《网络运维干货集锦 II 》，《网络运维干货集锦 III》。

同样，若发现有任何纰漏，还请随时指正。

你的支持，我的动力。

记得点进去看看哦。