本地路由最优先 经典故障解析全过程

　　如果不是自己碰到这样的故障还真是不能相信有这道理。

　　故障现象：从办公室无论如何不能ping通目的服务器

　　解决过程：

　　先是逐步ping来排除故障点的位置，我在办公室的网段是192.168.10.0，网管是10.254，直接通过一个接入层的傻瓜交换机联入核心交换机，在核心交换机上有一个口用接口IP作为我们的网关存在，于是我就先ping我们的网关10.254，OK!能通。

　　接着就开始ping对方连接的汇聚交换机与核心交换机相连的网关地址0.254，该地址作为核心交换机上的一个vlan网关地址存在，OK!能ping通!

　　下一步开始就ping对方的汇聚交换机相连的接口地址，看能不能达到对方的局域网络，0.253能ping通!也就是说我们从办公室到对方的上联都是通的，汇聚交换机和核心交换机之间也是通的，此段路由没有问题。

　　然后就是ping最后一个网关地址5.1，这个地址在汇聚交换机上是一个接口IP，用来和目的服务器相连并作为其网关与其他局域网连接，如果这个能ping通的话哪么就说明我从办公室到她的网关都是没有问题的，既有去向路由又有回指路由，结果是5.1能ping通!

　　最后一步是ping那台服务器地址5.2，结果是超时!!

　　推想：难道是那台服务器没有指向默认网关?所以不能回来?

　　看过该服务器配置后发现已经指向了默认网关为5.1，也就是说按理说应该是能通的，但为什么就是不通?在试试从服务器上ping到目的网段能出现什么结果。

　　结果如下：我从服务器上ping到0.254都是能通的，但是ping到10.254的时候就不通了!!奇怪，为什么?到了0.254能通就证明该服务器的网段到此为止到核心交换机直接的路由都是没有问题的，如果有问题的话0.254也不应该通才对啊!

　　推想：难道是10.0网段的路由不在对方的路由中?那台汇聚交换机没有回指10.0/24位地址指向0.254?试试就知道了!登陆上核心交换机做如下测试：

　　先是使用扩展ping命令来ping 5.2这个地址，在使用其他除了10.254这个地址作为网络地址之外的其他所有ping都能通过!唯独把10.254作为源地址时超时。

　　难道真是在那台汇聚交换上没做上10.0指向0.254的路由条目吗?登陆上去看了发现此条目存在并且没有其他比她更加精细的条目，没有问题的话她应该是能回指回去的!但是我又想了，那如果是汇聚交换机和核心交换机之间的路由问题的话，我从网管ping为什么能ping到对方的5.1这个地址呢?网关通了，而5.2的网关就是5.1为什么还不通呢?

　　连最不可能的一种原因都试过还是不行：把5.1和10.254这两个接口IP地址作为网关地址的地址该为vlan地址，把相应的端口变为二层口试试看行不行，结果一样，还是不能ping到5.2，从网关能ping到5.1为止。真是见鬼了。。

　　想起来了!!奶奶的，该不是那边另外一块网卡是10的网段吧??如果是的话那就对了，正好可以解释为什么只有10.254作为源地址就是不能ping通它的原因，通过查看证实，靠!真是有一个这样的地址存在，怪不得我怎么ping都不能ping通了!!原来目的主机一样有一个10.0网段的地址，不可能回应同样为10.0网段的我从网管ping它的，本地有相同网段最优先即本地路由最优先的原则是不会回应一个相同的网络地址请求的。但是从锐捷的官方客服那边得知的是当网卡处于down状态时路由应该是不起作用的，为什么现在却能起作用它们也不知道。。。

　　最后把原先的10.0网段的地址在服务器上闲置网卡删除接着就能和办公室ping通了!!真是踏破铁鞋无觅处，得来全不费工夫!!!!

　　总结：在整件故障解决过程当中我没有做以下操作导致解决周期过长

　　1、抓包分析：我如果当时在故障服务器上抓包分析就可能看出来是什么原因导致的，后来我在该服务器上装上鲨鱼，看了以下包，如果我在闲置网卡上使用10段地址，那么我在ping的时候根本得不到任何的icmp requet信息，也即是说电脑连请求都没有发出。这种情况有两种可能，自己通过子网掩码的运算发现目的和自己不同网段，而自己没有设置网关，自然就部封装ICMP请求;另外一种可能就是自己有网卡存在和对方相同的网段，所以在本地路由表中有相应条目，不做回应。

　　2、在服务器上看以下route print：我若当时就这么做的话就能发现在server2003中有这样一条路由条目即是192.168.10.0 255.255.255.0 127.0.0.1。都存在这样的条目肯定不能通过它回指了。