今天值班，观察流量时突然发现中中E320往中中CRS方向的OUT流量剧降，几乎为0了。登录上E320查看OSPF邻居，一切正常，查看路由表，发现OSPF下发的默认路由只有从中南CRS来的，中中CRS竟然没有下发默认路由。这可不妙，马上登录中中CRS查看中中CRS的配置，发现配置没有问题的。查看中中CRS的路由表，发现中中CRS的默认路由竟是从中南学习过来的OSPF，而正常应该是从D1路由器学习过来的EBGP路由。

　　联想到凌晨D1路由器有割接，于是想可能是割接时候配置有问题，这台D1路由器没有下发默认路由。于是立刻上报。但NOC回复说D1配置没有问题，肯定下发了BGP默认路由。查看中中CRS的BGP路由表，终于发现了原因。原来D1路由器的确下发了EBGP默认路由，这在BGP路由表里可以看到，但问题出在这个EBGP默认路由的METRIC值太大，大于中南CRS发过来的IBGP默认路由的METRIC值，而CISCO的CRS设备在这种情况下是优先选择中南CRS下发的IBGP路由的(这点和华为的设备不同，华为的设备总是优选EBGP的，不比较METRIC值)这样这条IBGP默认路由被优选出来，同时中中和中南CRS之间还建立有OSPF关系，于是中南CRS还同时把OSPF的默认路由发给中中CRS，因为IBGP的路由管理距离要大于OSPF，系统选择了OSPF做为默认路由放入了路由表，因为中中E320双挂中中和中南CRS的，所以中中CRS发过来的OSPF默认路由自然没有被接受(很正常，因为这条默认路由是由中南CRS始发的外部路由，OSPF的路由环路检测机制会丢弃从中中CRS发过来的默认路由)。当然如果是EBGP路由在BGP路由选择中胜出，情况就不一样了，因为EBGP路由管理距离要小于OSPF，系统选择了EBGP做为默认路由，这样中中CRS发给中中E320的默认路由始发就不是中南CRS了，而是自己，中中E320就会接受这条默认路由，并把从中南接受到的默认路由同时放入路由表，进行负载均担。这种情况也是正常的情况，但D1路由器割接时可能改动了METRIC值，这自然影响了中中CRS的路由选择，于是导致了上述情况发生。

　　解决方法也很简单，那就是恢复D1路由器上的原来的METRIC值，使得EBGP在BGP路由选择中胜出。但这样会在骨干网上产生路由振荡。另一种方法就是在中中CRS建立指向D1路由器的默认路由，这种方法不会产生路由振荡，影响最小，实际上最后采用的解决方法也是这一种。