标签：哥哥 数据中心 汇总 昨天 标签 需要 导致 设计 The
现在的网络工程师行业总是充斥下面这些极端现象：? 很多人做网络，可能做了那么久，连OSPF的场景都没遇到过。就算遇到了，也都是OSPF单区域，都没碰到过OSPF多区域。于是他们下了结论：OSPF多区域学了没用，因为没人用。
? 至于一些很高级的BGP，MPLS。想碰到的场景就更是少之又少了。不仅是一些小公司接过的项目基本碰不到，就算是大公司在接一些大项目的时候，也不太容易一下子就碰到带有MPLS标签的骨干网。所以又会有一些人说BGP其实也没啥用。
? 而一些所谓“大咖”，在各种论坛，各种视频教程中大书特书的双活数据中心，SDN，大二层，堆叠技术啥的。看起来给人一种“高大上”，“神秘莫测”的感觉。但是实际上，他们可能自己也很少接触这样的案例，只能是泛泛而谈，说一些很框架甚至和实际工作相背离的东西，根本就没说到点子上。
咱们还是再说一个“老生常谈”的话题，那就是IP地址规划问题。
比如，使用192.168开头的IP地址，尤其是192.168.0.0/24和192.168.1.0/24的问题上，这是个屡教不改的严重问题。在正规的局域网包括骨干网建设的时候，192.168的IP地址虽然没有被明文规定说“不准用”，但这段地址的出现，总会拉低整个网络的档次。而且192.168.0.0/24和192.168.1.0/24会和无线设备LAN端的默认地址发生冲突。所以，一开始就让网络相关专业的学员接触192.168，这是一个非常烂的习惯。
当然，有一些人不会使用192.168，他们会这么设置地址。
虽然看起来没有192.168了，而且每个互联地址的第三段都有了意义，比如R1和R2互联，IP的第三段就用12，R2和R3互联，IP的第三段就用23。但实际上，实验中这样使用IP地址也会给学员养成坏习惯。
? R1和R2、R2和R3、R3和R4之间就一条三层链路互联，只需要两个IP地址就够了，直接用/24的掩码去做两个设备之间的互联地址，浪费不？有人说：10开头的地址是私有地址，随便用不是吗？错！在实际工程中，就算是10、172.16—31这样的私有地址，也是有着严格的规划的，绝对是不能随便乱用的。
? Loopback 0的规划，使得IP子网不连续。这个问题可不是小问题呢！IP地址不连续会导致IP路由无法汇总，从而大大增加网络中路由表的数目。在大型骨干网中，路由表过于庞大会导致灾难性的后果。所以实际工程中的Loopback地址是要求专门用一段子网，比如10.112.254.0/24，分出254个/32的地址出来作为Loopback地址的。
不过也不得不说，专职的讲师，最大的弱点就是很少实战，或者是根本没有实战过。但初学者在学习网络的时候，首先面对的又是专职讲师。所以专职讲师的一些习惯，会大大影响到初学者对行业规则的认知。
本文说一个骨干网的MCE设备下面的枝叶站点，因为两个枝叶站点之间的业务IP地址规划冲突，导致两个站点之间出现时断时续的状况。当时在排错的时候，只能通过客户的TV远程桌面去进行连接，从一定程度上还增加了排错的难度。
实际上，关于大型网络（尤其是骨干网）的IP地址规划，虽然从技术上来说难度并不大，但尤其考验管理者的耐心与细心。与IP地址规划失误，而造成的网络故障或者是后期难以延伸改造的教训真的比比皆是。捷哥可能会在以后的文章中，再挑选几个典型的案例为大家详细说明。
在本文遇到的故障中，在只有一张网络结构总图，没有标记接口和互连IP地址，而且拓扑图还有可能有错误的情况下，如何花时间找出故障源头呢？
有时候，接到网络故障的CASE还真是一件让人迷茫的事情，可能会让你前往现场的过程中心都是乱的。有些故障很明显，一查就是少一条路由，配错一个IP地址，关了一个接口啥的，遇到上述情况的时候还是好的。但是呢，有些故障是现象看起来一切正常，但故障就是莫名其妙地出了。最令人无奈的是，客户此时还告诉你：“我们没动过网络啊，昨天还好好的，今天突然就出问题了！”
不过呢，任何故障都有自己的原因的。有一种原因就是由“潜伏”的隐患在某一天突然进行爆发而出现的。
那天下午三点多钟，吴雄飞接了贵阳客户的一个电话，说是一个位于陕西路的三级网点网络出了故障。这个网点是一个星期以前新建的，刚建立的时候网络都是正常的，但突然之间网络就断了，所以需要进行一番检查。客户说的是：“这个站点还暂时未投用，所以慢慢排查就是了，TV的远程ID和密码已经发送短信，操作机上有网络拓扑图，还有陕西路站点的用户名和密码。”
经过双方的简单沟通，吴雄飞了解到的“情报”也就只有这些：
吴雄飞从客户手里得到的拓扑图是这样的：
这里列出了所有WAN汇聚设备的结构，一级、二级站点为MPLS的PE设备。
一级站点字体为红色，二级站点字体为蓝色，三级站点字体为黑色。
吴雄飞大致看了一眼这个结构图，发现陕西路站下挂在瑞金路站下方。
而陕西路站点，需要访问省中心的OA服务器，IP地址是10.100.145.19，所以，陕西路站点的VRF OA下，有10.100.145.16这个IP地址相关的路由才行。
本来嘛，吴雄飞想着，如果陕西路站点上的VRF OA内没有10.100.145.19相关的路由，或者是路由下一跳地址不对，或者是瑞金路站点上没有10.113.192.0/24的路由，这都比较好办。但问题就是：当他登上陕西路站点后，一查看VRF OA下的路由，发现有一条10.100.145.0/24的路由，而且下一跳地址是10.49.206.18，而这个地址正好是瑞金路站的地址。
此时，吴雄飞在陕西路站点上，查看路由表时发现存在10.100.145.0/24的路由，而且下一跳地址也正确。于是，他决定带着源地址去ping一下10.100.145.19，得到如下现象：
ping的结果是断断续续的，而Tracer的时候也只是到第一跳就丢包了。
而此时，陕西路站上10.100.145.0/24的路由又肯定是100%正常的，所以吴雄飞判断问题肯定不会只在陕西路一个站点上，而应该对陕西路到省中心之间的路径做一个全面检查。
所以，他立刻拨通了客户的电话，说是需要所有PE设备的用户名和密码。
当时在贵阳的这个客户不算新客户，其代表黄腾还和吴雄飞一起过酒，也参加过吴雄飞这边组织的技术培训，所以俩人私交还可以。但是，黄腾这个人有点胆小，有点墨守成规了。因为，随意提供PE级别设备的用户名和密码给其他人是违规行为，而那天下午他还很忙，也没时间来帮吴雄飞输入密码。但是，如果不登录PE设备，对网络做一个全面检查，恐怕是真的再也找不到陕西路站点的问题了。
不过最后，吴雄飞还是半开玩笑半警告地说：“反正陕西路站点的设备我查了，也确实是没有问题了，如果你要不想彻底解决问题呢，那我就真的不管了哦！”
“好，PE设备的用户名和密码我还是不能提供！”黄腾还是比较坚决，他沉思了一会说：“不过，我可以喊我们现场的小伙，马上抓取所有设备上对你有用的信息给你，你看如何？”
说了半天，对方还是不肯提供PE设备的用户名和密码，这让吴雄飞心里面觉得不太舒服。不过，对方如果能把配置信息抓过来，进行逐步查看或许也还是有用。所以，吴雄飞向黄腾要了如下信息：
虽然，查看抓取的一堆配置信息，不如登上设备查看那么灵活和自由。而且在设备的CLI里面查看信息，可以使用include，begin等管道参数进行过滤。但好歹这些配置信息都已经到了自己的电脑上，可以不用远程登录到对方的电脑上了，而且嘛，这些配置信息还可以发送给紫竹他们，让大家来一起看嘛。
在拿到所需要的信息以后，已经到了下班时间。反正黄腾那边也不算太急，只要在三天之内给出答复即可。不过吴雄飞这边觉得事情没有完成，心里面总是有一件什么东西“吊着”一样。
紫竹问他：“下午贵阳那边的故障是怎么回事呢？”
这句话，让吴雄飞觉得是瞌睡遇到了枕头一般，他马上就把事情的经过和紫竹一五一十地说了，紫竹笑道：“既然是网络故障嘛，那你早就应该和我说了啊，我们可以一起解决。”
只要是搞明白了预期的网络路径，那就可以在沿途的设备上查看相关的路由是否正确了。
这也说明了，这种情况下，路由需要逐跳查看，一个设备一个设备的查看。这样查看的话，总能查出问题的所在。
紫竹决定从上往下看，她先查看会展城PE设备上的路由条目，但这么一看，她就立刻看出了问题来了：
看到这种现象，紫竹问道：“你说过，黄腾给你说这个拓扑图有问题，这里路由显示从中华路站点过来的，是哪里有问题啊？”
吴雄飞笑道：“我认为嘛，黄腾他们做事小心谨慎，即使网络结构有误，也不应该在PE这个地方有问题啊。”
“哥哥，要拿出铁证来啊！这是你以前给我们说的啊。”
怎么拿出铁证来证明GigabitEthernet 1/3接口下面就一定是中华路站点，GigabitEthernet 1/4接口下面就一定是瑞金路站点呢？此时在不和黄腾沟通，如何确定呢？
答案就是，查看OSPF邻居表和BGP邻居表，也可以进行一次确认。
还好，黄腾在抓取信息的时候，还是把OSPF邻居表也一起抓来了。
也不用在看BGP表了，直接在OSPF邻居表里面，看到了10.49.254.3，接口正好对应着Gi 1/3接口。而10.49.254.3这个地址，直接查看中华路站点设备抓取的信息，查看它的Loopback 接口，就正好可以判断出Gi 1/3下面就是中华路站点，Gi 1/4下就是瑞金路站点。
于是，结合刚才在会展城看到的10.113.192.0/24的路由信息，下一跳地址指向Gi 1/3接口，这显然是有问题的。
正常情况下，10.113.192.0/24这个陕西路站点的业务路由，应该是从Gi 1/4 接口学习过来，但现在却是在Gi 1/3接口学习过来的。既然不是静态路由写错了，那就只有一种可能，中华路PE设备下方肯定也有站点用的是10.113.192.0/24。
吴雄飞说：“谢谢亲爱你，你真聪明，一下子就发现了问题的所在啊！那现在我们就再看看中华路站点下面，看看这个10.113.192.0/24到底是在哪个站点下的。”
查看中华路站点下，10.113.192.0/24的路由
好了，现在的情况就已经很明确了
中华路PE站点下的中山路MCE站点，使用的业务路由也是10.113.192.0/24，与陕西路站点的10.113.192.0/24发生了冲突。所以，不仅陕西路站点的网络有问题，估计中山路站点的网络也不会正常。
吴雄飞说道：“现在时间还没到8点半，想必黄腾应该还没休息，我还是马上答复他吧。”
不过从那以后，吴雄飞他们也再也没有接到黄腾的电话。按照他的想法是，如果客户没有再来电话，就默认认为是问题已经解决了。
标签：哥哥 数据中心 汇总 昨天 标签 需要 导致 设计 The
原文地址：https://blog.51cto.com/51ctoblog/2447556
