# 回归,带着满满的干货回来了 大家好,我是姜汁啤酒。 你可能觉得莫名其妙,从今年二月份这个经常上头版的网工兄弟,居然突然从51cto消失了,博客也不更新了?莫非,哥们,不会,和埃隆马斯克去火星了吧? 其实,需要给大家解释解释,我消失了三个月一共完成了两件大事。 1. 我在51cto写了一个专栏:《老司机网络运维干货集锦》,里面涵盖了路由、交换、安全、QOS四大模块知识点,大家感兴趣的可以猛戳此链接详细了解:[https://blog.51cto.com/cloumn/detail/2](https://blog.51cto.com/cloumn/detail/2) 。目前专栏还剩路由篇待更新,其他模块已经完毕。 2. 这三个月跳了个槽,从资深工程师摇身一变成为首席设计网络师,事情相对也多了起来。加上刚到一个新地方怎么都得装一装样子,老油条们,你懂的。 因为上述两件事,搞得最近忙的没来得及更新博客。 今天正式回归后,本来想继续更新我之前的数据中心系列。但是考虑再三,索性想和大家聊聊我对于网络运维的看法,以及写这个专栏的出发点,同时也希望和志同道合的朋友们一起分享分享网络运维的见解。 # 网络运维,痛并快乐着 当你因为这篇文章的标题,尤其是网络运维这四个字把你吸引进来时。 我大概知道你也是网络运维同行的一份子,相信你有着对网络技术的狂热爱好和对技术细节的极致追求。 可是,有时候现实的工作和理想的追求往往会不小心就差了好远,日常的网络运维工作不仅繁琐,而且出的故障都是千奇百怪,让人无法琢磨透。 更不用提反复无常的加班,通宵调整,割接等操作了。 但是苦中作乐,当每一个故障都被解决以后,内心那种酣畅淋漓的满足感,总会让你能够短暂的忘却身体的疲乏,享受片刻的欢愉和宁静。 **可是,我落井下石的提一个疑问句。你觉得问题解决了,是彻底分析透彻并从根源上解决了? 还是找了个变通方法,临时处理掉问题?** 仔细想想,其实内心五味杂陈,你不用说,我也懂。 # 有多少个故障,就有多少个故事 ## 故事1:不做过滤的路由重分发 最近作为首席设计师的角色入职新公司以后,花了些时间摸底公司网络架构。听了听同事说说以前的故障案例,以及解决方案。 听完以后,不禁让我觉得可笑,但又打寒颤。 ![](https://s4.51cto.com/images/blog/201805/10/3623f7829d1f711a6f51b74db6bd5075.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=) 一个经典的双点双向重分发场景。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。 ![](https://s4.51cto.com/images/blog/201805/10/47a2d8228abcba51686319d84e99fdf0.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=) ## 故事4:“裸奔”的网络 相信大家都知道电脑“裸奔”是什么意思,那何为“裸奔”的网络? 在我来看,裸奔的网络有两层含义。 第一:此网络不存在任何安全措施可言,恶意***可以来自内部或者外部,网络设备非常容易沦陷。 第二:网络存在的目的在于传输数据包,若发送的数据包无法尽可能的完整到达接收端,网络设备没有任何QoS保护措施保障数据包的传输,那么此网络设备也可以称作为“裸奔的”网络。 尤其第二项,Qos的设计和部署对于工程师的理论知识要求较高,若对于QoS一知半解的话,部署的Qos问题比不部署还严重。 故事还在继续。。。 ## 故事5:永不安全的防火墙 此标题很有意思,因为它违背了常理。 按理说,防火墙是为了加固网络安全才部署的,怎么说防火墙用不安全呢? 其实,防火墙是安全的,不安全的是人心。 仔细想想日常运维中,经常有很多不懂网络技术的人对你指手画脚: * 谁谁谁,我的网络怎么不通了? * 为什么上不了这个网站了? * 网速怎么这么慢啊? 最后这些非IT人士都统一得出一个结论,防火墙出问题了,他们不懂路由交换。只知道防火墙是阻挡一切的罪魁祸首。 ![](https://s4.51cto.com/images/blog/201805/11/8d7800942e5c32485ba321602e83623e.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=) 这个锅,防火墙背上了。 有上黑锅的,自然也得有卸锅人。于是,网络运维工程师就成为了拆弹专家,你需要仔细核查防火墙的安全策略,路由,逐步排查故障,确保不是防火墙问题。 那如何核查,防火墙的详细工作原理和数据包处理流程是什么? 问题分析逻辑是什么?如何下手等? 此类问题经常困扰着你和我。 # 总结:我们离真相只有一层窗户纸 其实很多问题,我们稍稍往前走一步,就可以看见真相。 但是很多运维的朋友选择在遇到奇葩问题的时候,退而求次其次,掩盖住问题就好,何必费劲力气往前冲呢? 也许短时间之内问题被掩盖了,被所谓的“解决掉了”。但是总有一天,这个问题就像星星之火一样,卷土重来,把运维人员烧的外焦里嫩。 所以,作为一个过来人,我觉得很有必要把自己日常追求问题根源的经验分享出来,供大家参考。 **而更重要的是,除了分享经验以外,是希望通过有限的例子给大家展示一个处理故障和问题的思路。** 日常运维中,你不可能套用某一个故障的具体处理办法到另外一个故障,但是处理故障分析思路却可以反复使用。 介于此,我决定写此专栏,希望自己所学所思的东西能够帮助到大家,能够有所启发。 此专栏通过“网络路由篇”,“网络交换篇”,“网络安全篇”,“QoS篇”四大典型技术模块,分别给各位讲述运维中的网络设计思路和一些运维的技术难题。相信你通读完各个模块以后,会刷新你对于某些知识的认知。 传送门如下: [老司机网络运维干货集锦](https://blog.51cto.com/cloumn/detail/2) [![](https://s4.51cto.com/images/blog/201805/14/c81233fee017f6638f1ddd460db2ff97.jpg?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=)](https://blog.51cto.com/cloumn/detail/2) 若你在日常运维中,还需要了解其他方面的问题,请给我留言。我会根据各位的反馈,继续迭代《网络运维干货集锦 II 》,《网络运维干货集锦 III》。 同样,若发现有任何纰漏,还请随时指正。 你的支持,我的动力。 记得点进去看看哦。