今天值班，觀察流量時突然發現中中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路由器的默認路由，這種方法不會產生路由振蕩，影響最小，實際上最后采用的解決方法也是這一種。