誰動了個人骨幹網 IP？

如今的網絡工程師行業老是充斥下面這些極端現象：

✔ 不少人作網絡，可能作了那麼久，連OSPF的場景都沒遇到過。就算遇到了，也都是OSPF單區域，都沒碰到過OSPF多區域。因而他們下告終論：OSPF多區域學了沒用，由於沒人用。

✔ 至於一些很高級的BGP，MPLS。想碰到的場景就更是少之又少了。不只是一些小公司接過的項目基本碰不到，就算是大公司在接一些大項目的時候，也不太容易一會兒就碰到帶有MPLS標籤的骨幹網。因此又會有一些人說BGP其實也沒啥用。

✔ 而一些所謂「大咖」，在各類論壇，各類視頻教程中大書特書的雙活數據中心，SDN，大二層，堆疊技術啥的。看起來給人一種「高大上」，「神祕莫測」的感受。可是實際上，他們可能本身也不多接觸這樣的案例，只能是泛泛而談，說一些很框架甚至和實際工做相背離的東西，根本就沒說到點子上。

1.IP地址規劃

我們仍是再說一個「老生常談」的話題，那就是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地址也會給學員養成壞習慣。

2.什麼問題呢？

✔ R1和R二、R2和R三、R3和R4之間就一條三層鏈路互聯，只須要兩個IP地址就夠了，直接用/24的掩碼去作兩個設備之間的互聯地址，浪費不？有人說：10開頭的地址是私有地址，隨便用不是嗎？錯！在實際工程中，就算是十、172.16—31這樣的私有地址，也是有着嚴格的規劃的，絕對是不能隨便亂用的。

✔ Loopback 0的規劃，使得IP子網不連續。這個問題可不是小問題呢！IP地址不連續會致使IP路由沒法彙總，從而大大增長網絡中路由表的數目。在大型骨幹網中，路由表過於龐大會致使災難性的後果。因此實際工程中的Loopback地址是要求專門用一段子網，好比10.112.254.0/24，分出254個/32的地址出來做爲Loopback地址的。

不過也不得不說，專職的講師，最大的弱點就是不多實戰，或者是根本沒有實戰過。但初學者在學習網絡的時候，首先面對的又是專職講師。因此專職講師的一些習慣，會大大影響到初學者對行業規則的認知。

3.骨幹網的IP地址規劃

本文說一個骨幹網的MCE設備下面的枝葉站點，由於兩個枝葉站點之間的業務IP地址規劃衝突，致使兩個站點之間出現時斷時續的情況。當時在排錯的時候，只能經過客戶的TV遠程桌面去進行鏈接，從必定程度上還增長了排錯的難度。

實際上，關於大型網絡（尤爲是骨幹網）的IP地址規劃，雖然從技術上來講難度並不大，但尤爲考驗管理者的耐心與細心。與IP地址規劃失誤，而形成的網絡故障或者是後期難以延伸改造的教訓真的比比皆是。捷哥可能會在之後的文章中，再挑選幾個典型的案例爲你們詳細說明。

在本文遇到的故障中，在只有一張網絡結構總圖，沒有標記接口和互連IP地址，並且拓撲圖還有可能有錯誤的狀況下，如何花時間找出故障源頭呢？

4.讓人一臉抓瞎的問題

有時候，接到網絡故障的CASE還真是一件讓人迷茫的事情，可能會讓你前往現場的過程當中心都是亂的。有些故障很明顯，一查就是少一條路由，配錯一個IP地址，關了一個接口啥的，遇到上述狀況的時候仍是好的。可是呢，有些故障是現象看起來一切正常，但故障就是莫名其妙地出了。最使人無奈的是，客戶此時還告訴你：「咱們沒動過網絡啊，昨天還好好的，今天忽然就出問題了！」

不過呢，任何故障都有本身的緣由的。有一種緣由就是由「潛伏」的隱患在某一天忽然進行爆發而出現的。

只是一個CASE和一個操做機權限

那天下午三點多鐘，吳雄飛接了貴陽客戶的一個電話，說是一個位於陝西路的三級網點網絡出了故障。這個網點是一個星期之前新建的，剛創建的時候網絡都是正常的，但忽然之間網絡就斷了，因此須要進行一番檢查。客戶說的是：「這個站點還暫時未投用，因此慢慢排查就是了，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，而這個地址正好是瑞金路站的地址。

5.逐步摸清網絡結構

此時，吳雄飛在陝西路站點上，查看路由表時發現存在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點半，想必黃騰應該還沒休息，我仍是立刻答覆他吧。」

不過從那之後，吳雄飛他們也再也沒有接到黃騰的電話。按照他的想法是，若是客戶沒有再來電話，就默認認爲是問題已經解決了。

網絡規劃設計實戰案例，就在訂閱專欄《骨幹網與數據中心建設案例》拼團學習，只要39￥