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

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

你们好，我是姜汁啤酒。

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

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

1. 我在51cto写了一个专栏:《老司机网络运维干货集锦》，里面涵盖了路由、交换、安全、QOS四大模块知识点，你们感兴趣的能够猛戳此连接详细了解：https://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》。

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

你的支持，个人动力。

记得点进去看看哦。