史萊姆論壇

返回   史萊姆論壇 > 教學文件資料庫 > 網路軟硬體架設技術文件
忘記密碼?
註冊帳號 論壇說明 標記討論區已讀

歡迎您來到『史萊姆論壇』 ^___^

您目前正以訪客的身份瀏覽本論壇,訪客所擁有的權限將受到限制,您可以瀏覽本論壇大部份的版區與文章,但您將無法參與任何討論或是使用私人訊息與其他會員交流。若您希望擁有完整的使用權限,請註冊成為我們的一份子,註冊的程序十分簡單、快速,而且最重要的是--註冊是完全免費的!

請點擊這裡:『註冊成為我們的一份子!』

Google 提供的廣告


 
 
主題工具 顯示模式
舊 2003-10-22, 04:23 PM   #1
psac
榮譽會員
 
psac 的頭像
榮譽勳章
UID - 3662
在線等級: 級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時級別:30 | 在線時長:1048小時 | 升級還需:37小時
註冊日期: 2002-12-07
住址: 木柵市立動物園
文章: 17381
現金: 5253 金幣
資產: 33853 金幣
預設 鄰居哪去了?

鄰居哪去了?

赫赫,文章講的不是Windows的網路芳鄰,而是OSPF路由傳輸協定中鄰居關係的建立問題。對OSPF瞭解的朋友應該知道,兩個相連的執行OSPF的路由器間在交換路由信息之前,兩台路由器必須先建立起OSPF的鄰居/鄰接關係,但有時候這種鄰居關係就是建立不起來,問題是出在哪裡呢?

案例一
一個客戶前段時間打電話給我,說他們的網路出了點問題。客戶的網路是個省網,整網都採用OSPF路由傳輸協定,客戶所在的點是一個市級節點,下聯各個縣級節點,最近下屬縣級節點2600上又增加了一個節點1760,通過乙太網口連接起來,在26上ping對端1760的直連接頭是通的,但ping不通1760上的區域網路口,用戶反覆檢查了OSPF的配置也沒發現什麼不對的地方。

首先撥號上到縣級節點的26上,然後再telnet到1760上檢視,在1760上用show ip ospf nei發現顯示結果是空的,說明鄰居關係根本就沒建立起來,再看了一下OSPF的配置也是對的,用show ip ospf int看兩個乙太網口也都正確地加入到了OSPF工作中,那問題出在哪裡呢?

在1760上開啟debug,debug ip ospf event,然後觀察結果:

01:02:57: OSPF: Rcv hello from 192.168.0.2 area 0 from Ethernet0 10.1.1.2
01:02:57: OSPF: Mismatched hello parameters from 10.1.1.2
01:02:57: OSPF: Dead R 40 C 40, Hello R 10 C 10 Mask R 255.255.255.252 C 255.255.255.248

可以看到出錯原因為ospf hello資料包的參數不匹配,下面一句給出了出錯原因,其中的R代表對端的hello參數,C代表本機的hello參數,可以看到hello及dead interval的參數兩端都是一致的,但mask值就不一樣了,本機的為255.255.255.248,而對端的卻為255.255.255.252。

原來用戶在做規劃時雖然要求兩邊位址都用/30的掩碼,但以前一直用的/29的掩碼,後來新增節點後也忘記改了。

雖然近端網址為10.1.1.1,遠端位址為10.1.1.2,都落在了/30及/29的範圍內,但OSPF傳輸協定規定,在乙太網這樣的broadcast環境中,兩端的掩碼必須保持一致,而在點對點的網路連接中則沒有這樣的要求。

找到問題原因後,將近端網址的掩碼改為/30,幾秒鐘後再show ip ospf n,可以看到鄰居關係已正確建立,路由信息也正確地傳播了過來:

Neighbor ID Pri State Dead Time Address Interface
192.168.0.1 1 FULL/BDR 00:00:39 10.1.1.1 Ethernet0

案例二
一個省網工程,中心用的75,採用ATM OC3 155M接頭,下面的分支節點都用畫格中繼接上來。ATM線路剛拉通後,我的一個同事到用戶現場進行配置,打了一個電話給我,說遠端路由學不到,電話上扯了一會後扯不清,就趕到現場看實際情況。

到現場後大概看了看配置和線路,沒什麼大問題,接下來看OSPF的鄰居關係:

Head_7507#sh ip ospf nei

Neighbor ID Pri State Dead Time Address Interface
192.168.0.2 1 EXSTART/- 00:00:34 172.16.0.2 ATM1/0

怎麼回事呢?因為問題已經解決,事後我在試驗環境裡模擬了一下故障現場,現假設RouterA是中心的75路由器,在RouterA上開啟debug:

RouterA#debug ip ospf adj
OSPF adjacency events debugging is on

00:21:38: OSPF: Rcv DBD from 192.168.0.2 on Serial0 seq 0x335 opt 0x42 flag 0x7 len 32 mtu 1300 state INIT
00:21:38: OSPF: 2 Way Communication to 192.168.0.2 on Serial0, state 2WAY
00:21:38: OSPF: Send DBD to 192.168.0.2 on Serial0 seq 0x1391 opt 0x42 flag 0x7 len 32
00:21:38: OSPF: First DBD and we are not SLAVE
00:21:43: OSPF: Rcv DBD from 192.168.0.2 on Serial0 seq 0x335 opt 0x42 flag 0x7 len 32 mtu 1300 state EXSTART
00:21:43: OSPF: First DBD and we are not SLAVE
00:21:43: OSPF: Retransmitting DBD to 192.168.0.2 on Serial0
00:21:43: OSPF: Up DBD Retransmit cnt to 1 for 192.168.0.2 on Serial0
00:21:43: OSPF: Send DBD to 192.168.0.2 on Serial0 seq 0x1391 opt 0x42 flag 0x7 len 32
00:21:48: OSPF: Rcv DBD from 192.168.0.2 on Serial0 seq 0x335 opt 0x42 flag 0x7 len 32 mtu 1300 state EXSTART

可以看到RouterA在不斷的重發DBD包,但一直維持在EXSTART狀態,不進行到下一步LOADING狀態。

telnet到對端RouterB上,看OSPF鄰居關係:

RouterB#sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface
192.168.0.1 1 EXSTART/- 00:00:37 172.16.0.1 Serial1

一樣的OSPF鄰居狀態,在RouterB上開啟debug:

RouterB#debug ip ospf adj

00:24:28: OSPF: Retransmitting DBD to 192.168.0.1 on Serial1
00:24:28: OSPF: Up DBD Retransmit cnt to 6 for 192.168.0.1 on Serial1
00:24:28: OSPF: Send DBD to 192.168.0.1 on Serial1 seq 0x467 opt 0x42 flag 0x7 len 32
00:24:28: OSPF: Rcv DBD from 192.168.0.1 on Serial1 seq 0x4C2 opt 0x42 flag 0x7 len 32 mtu 1500 state EXSTART
00:24:28: OSPF: Nbr 192.168.0.1 has larger interface MTU
00:24:33: OSPF: Retransmitting DBD to 192.168.0.1 on Serial1
00:24:33: OSPF: Up DBD Retransmit cnt to 7 for 192.168.0.1 on Serial1

可以看到RouterB上同樣也有DBD重發的現象,但可以注意到RouterB上多了一條提示信息:
OSPF: Nbr 192.168.0.1 has larger interface MTU

好,現在再看看RouterA的S0口的MTU信息:

RouterA#sh ip int s0
Serial0 is up, line protocol is up
Internet address is 172.16.0.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes

RouterB的S1口的MTU信息:
RouterB#sh ip int s1
Serial1 is up, line protocol is up
Internet address is 172.16.0.2/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1300 bytes

結論出來了,RouterA串列阜的MTU值大於RouterB串列阜的MTU值,造成兩機的OSPF鄰居關係不能正確建立。

而在75上,看ATM口的信息:

Head_7507#show interface atm 1/0
ATM1/0 is up, line protocol is up
Hardware is cxBus ATM
MTU 4470 bytes, sub MTU 4470, BW 155520 Kbit, DLY 80 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ATM, loopback not set
Keepalive not supported
Encapsulation(s): AAL5, PVC mode
256 TX buffers, 256 RX buffers,

可以看到ATM口的MTU值為4470字元,而分支節點路由器串列阜的MTU值預設為1500字元,解決辦法有兩個,一個是將ATM口的MTU值改為1500,另一個辦法是在兩端設備接頭上增加如下指令:

interface atm1/0
ip ospf mtu-ignore

(註:此指令在12.1.3 版本後才予支持)

另:本文中所用到的IP位址為保密起見,都是修改後的IP位址,和實際情況有差別。
作者Alien
psac 目前離線  
送花文章: 3, 收花文章: 1630 篇, 收花: 3204 次
 


主題工具
顯示模式

發表規則
不可以發文
不可以回覆主題
不可以上傳附加檔案
不可以編輯您的文章

論壇啟用 BB 語法
論壇啟用 表情符號
論壇啟用 [IMG] 語法
論壇禁用 HTML 語法
Trackbacks are 禁用
Pingbacks are 禁用
Refbacks are 禁用


所有時間均為台北時間。現在的時間是 03:00 AM


Powered by vBulletin® 版本 3.6.8
版權所有 ©2000 - 2020, Jelsoft Enterprises Ltd.


SEO by vBSEO 3.6.1