在TWAREN網路上進行MPLS與Diffserv的功能測試
(中山大學/屏科大/中研院)
工作進度與結果
網頁負責人 : 謝進忠 enic@atm.ee.nsysu.edu.tw
中山大學
|
星期一 | 星期二 | 星期三 | 星期四 | 星期五 | 星期六 | 星期日 |
第一週 | 2004/03/10 | 2004/03/11 | 2004/03/12 | 2004/03/13 | 2004/03/14 | ||
第二週 | 2004/03/15 | 2004/03/16 | 2004/03/17 | 2004/03/18 | 2004/03/19 | 2004/03/21 | |
第三週 | 2004/03/22 | 2004/03/23 | 2004/03/24 | 2004/03/25 | 2004/03/26 | 2004/03/27 | 2004/03/28 |
第四週 | 2004/03/29 | 2004/03/30 | 2004/03/31 | 2004/04/01 | 2004/04/02 | 2004/04/03 | 2004/04/04 |
屏科大
|
星期一 | 星期二 | 星期三 | 星期四 | 星期五 | 星期六 | 星期日 |
第一週 | |||||||
第二週 | 2004/03/16 | 2004/03/17 | 2004/03/18 | 2004/03/19 | 2004/03/20 | 2004/03/21 | |
第三週 | 2004/03/21 | 2004/03/23 | 2004/03/24 | 2004/03/25 | 2004/03/26 | 2004/03/27 | 2004/03/28 |
第四週 | 2004/03/29 | 2004/03/30 | 2004/03/31 | 2004/04/01 | 2004/04/02 | 2004/04/03 | 2004/04/04 |
Multiple MPLS-VPN + DiffServ
|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
MPLS VPN | 2004/08/02 | 2004/08/13 | 2004/08/14 | 2004/08/16 | 2004/08/17 |
日 期 |
2004/08/17 (二) |
工作進度 |
1. 在 CISCO-12416R上使用 IP-precedence 來測試 DiffServ的效果 2. 測試 DiffServ over MPLS 的效果 |
結 果 |
1. 在 CISCO-12416R上 , 我們可以利用 policy-map 對不同的 class 下不同頻寬的設定 , 但實際量測時並沒有 DiffServ 的效果 . 2. Diffserv over MPLS 有指令可以設定,但 是一樣測不出 bandwidth 分配的效果 |
備 註 | 1. 依照我們測試的結果 , DSCP 只能在 7609上使用, 無法在
12416上運作 2. Policy-map 在 7609上可以正常運作 , 但在12416上無法順利運作 3. ip precedence 可以在12416上設定 , 但是量測不出 DiffServ 的效果 4. 7609上 mls qos 與 trust指令, 但 12416上沒有這些指令 5. Diffserv over MPLS有指令可以設定,但測不出 bandwidth 分配的效果 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/08/16 (一) |
工作進度 | DiffServ 的一些問題 |
結 果 |
1. 在TN-12416上的output port 為POS 12/0時,發現若欲以"match ip dscp",來classify封包時, 4. Diffserv over MPLS 有指令可以設定,但測不出 bandwidth 分配的效果 , 整個測試的過程如下
|
備 註 | 1. 依照我們測試的結果 , DSCP 只能在 7609上使用, 無法在
12416上運作 2. ip precedence 可以在12416上設定 , 是否可以順利運作有待測試 3. 7609上 mls qos 與 trust指令, 但12416上沒有 4. Diffserv over MPLS有指令可以設定,但測不出 bandwidth 分配的效果 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/08/14 (六) |
工作進度 |
CISCO 7609有兩種方式可以來建立 VPN , 第一種為
redistribute connected (同2004/08/13的進度) , 第二種為
redistribute static(今天新增加的方法) 我們使用 redistribute connected 的方式讓 NSYSU 的 Sender 與 NCU 的 Receiver 形成第一個 VPN A , 再使用 redistribute static 建立 VPN C |
結 果 | 1. Topology 如下圖所示
2. 由中山大學的 NSYSU-7609 上設定成 PE NSYSU-7609R#conf t NSYSU-7609R(config)#ip route vrf
vrf-nsysu-ncu 211.73.67.0 255.255.255.192 192.168.120.1 NSYSU-7609R(config-router-af)#redistribute
static 3. 由中央大學的 NCU-7609 上設定成 PE NCU-7609R#conf NCU-7609R(config)#ip route vrf
vrf-nsysu-ncu 211.73.67.64 255.255.255.192 192.168.34.2 NCU-7609R(config-router-af)#redistribute
static 4. 由中山大學的 NSYSU 的 Sender PC 上設定成 CE , interface dummy 為CE上所接的 211.73.67.0/26 之網路 [root@eeTWAREN root]# route
5. 由中央大學的 NCU 的 Sender PC 上設定成 CE , interface dummy 為CE上所接的 211.73.67.64/26 之網路 [root@localhost root]# route 6. 檢查中山大學的 VPN 設定是否成功 NSYSU-7609R#show ip route vrf
vrf-nsysu-ncu 7. 檢查中央大學的 VPN 設定是否成功 NCU-7609R#show ip route vrf
vrf-nsysu-ncu 8. 由中山大學的 NSYSU-7609 上 traceroute vrf 到中央大學的 PC 192.168.34.1 NSYSU-7609R#traceroute vrf
vrf-nsysu-ncu 192.168.34.2 9. 由中山大學的 Sender PC 上 ping 與 traceroute到中央大學的192.168.34.2 與211.73.67.65 [root@eeTWAREN root]# ping
192.168.34.2 [root@eeTWAREN root]# ping
211.73.67.65 10. 由中央大學的 NCU-7609 上 traceroute vrf 到中山大學的 PC 192.168.120.1與 211.73.67.1 NCU-7609R#traceroute vrf vrf-nsysu-ncu
192.168.120.1 [root@localhost root]# ping 211.73.67.1
|
備 註 |
此實驗是把 NSYSU-7609R與NCU-7609R當作PE, TN-12416R與HC-12416R當作P, 然後
在中山大學與中央大學內使用Linux Router當作CE,並以MPLS
VPN的方式,讓中山大學的192.168.120.0可以與中央大學的192.168.34.0形成VPN. 然後可以在 PE上 (NSYSU-7609R與NCU-7609R) 利用 ip route vrf vrf-nsysu-ncu PE-to-CE_VPN-NETWORK PE-to-CE_VPN-NETMASK NEW-VPN 增加新的VPN,如此範例可以把中山大學內當作CE的Linux Router上新增一個 211.73.67.0 255.255.255.192然後可以與中央大學內當作CE的Linux Router上所新增的另外一個 211.73.67.64 255.255.255.192成為同一個VPN |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/08/13 (五) |
工作進度 | NSYSU 的 Sender 與 NCU 的 Receiver 形成第一個 VPN A |
結 果 | 1. Topology 如下圖所示
2. 由中山大學的 NSYSU-7609 上設定成 PE NSYSU-7609R#conf t 3. 由中央大學的 NCU-7609 上設定成 PE NCU-7609R#conf 4. 由中山大學的 NSYSU 的 Sender PC 上設定成 CE [root@eeTWAREN root]# route
5. 由中央大學的 NSYSU 的 Sender PC 上設定成 CE [root@localhost root]# route
6. 檢查中山大學的 VPN 設定是否成功 NSYSU-7609R#show ip route vrf
vrf-nsysu-ncu 7. 檢查中央大學的 VPN 設定是否成功 NCU-7609R#show ip route vrf
vrf-nsysu-ncu 8. 由中山大學的 NSYSU-7609 上 traceroute vrf 到中央大學的 PC 192.168.34.1 NSYSU-7609R#traceroute vrf
vrf-nsysu-ncu 192.168.34.2 9. 由中山大學的 Sender PC 上 ping 與 traceroute到中央大學的192.168.34.2 [root@eeTWAREN root]# ping
192.168.34.2 10. 由中央大學的 NCU-7609 上 traceroute vrf 到中山大學的 PC 192.168.120.1 NCU-7609R#traceroute vrf vrf-nsysu-ncu
192.168.120.1 |
備 註 | 此實驗是把 NSYSU-7609R與NCU-7609R當作PE, TN-12416R與HC-12416R當作P, 然後 在中山大學與中央大學內使用Linux Router當作CE,並以MPLS VPN的方式,讓中山大學的192.168.120.0可以與中央大學的192.168.34.0形成VPN. |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/08/02 (一) |
工作進度 | MPLS VPN |
結 果 | 1. 原本的Topology與設定
與 變成MPLS VPN的Topology與設定 如下圖所示
2. 由台南的 TN-12416R上設定成 PE TN-12416R#conf 3. 由台北的 TP-12416R上設定成 PE TP-12416R#conf TP-12416R(config)#interface
GigabitEthernet 0/0 4. 由台灣大學的 NTU-7609R上設定成 CE NTU-7609R#conf 5. 由中山大學的 NSYSU-7609R上設定成 CE NSYSU-7609R#conf NSYSU-7609R(config)#interface
GigabitEthernet 9/3 NSYSU-7609R(config-if)#exit 6. 由台南的 TN-12416R上顯示設定成功的MPLS VPN(vrf_nsysu) TN-12416R#show ip route vrf vrf_nsysu
7. 由台北的 TP-12416R上顯示設定成功的MPLS VPN(vrf_nsysu) TP-12416R#show ip route vrf vrf_nsysu 8. 由中山大學的 NSYSU-7609R上 ping 中研院的192.168.112.1 NSYSU-7609R#ping 192.168.112.1 9. 由台灣大學的 NTU-7609R上 ping 中山大學的192.168.111.1 NTU-7609R#ping 192.168.111.1
|
備 註 | 此實驗是把 TP-12416R與TN-12416R當作PE, NTU-7609R與NSYSU-7609R當作CE, 然後以MPLS VPN的方式,讓NSYSU-7609R的192.168.111.0可以與NTU-7609R的192.168.112.0形成VPN. |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/04/02 (五) , 2004/04/03 (六) , 2004/04/04 (日) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
工作進度 | 量測數據 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
結 果 |
A. Round Trip Time 由中山建立 LSP Tunnel 301 經由台南最後到達台北,再由中山建立 LSP Tunnel 300 經由台南、新竹到達台中,由台中建立 LSP Tunnel 302經由新竹到達台北,並由新竹建立 backup path Tunnel 303 經由台南到達台北。其中 Tunnel 300 是為了把 Traffic 導入到台中,以便可以由台中發送 Traffic 到台北間的 fast reroute 所花費的時間而Packet回來的路徑均為台北經由台南到達中山。其 Topology 如下圖所示。
我們發現由中山經由 Tunnel 301 到達台北的
Round Trip Time 為 5ms,而由中山經由 Tunnel 300 、Tunnel 302
到達台北的 Round Trip Time 為 8ms,若此時 Tunnel 302
接台北的 interface shutdown 而發生 fast reroute 到 Tunnel 303
,則其Round Trip Time 為 11 ms。
B. fast reroute fast-reroute測試的 topology 如下
NSYSU-7609R(config)#ip explicit-path identifier 300
TC-12416R(config)#ip explicit-path identifier 221 HC-12416R(config)#ip explicit-path identifier 223 NSYSU-7609R(config)#interface tunnel 300 HC-12416R(config)#interface tunnel 302 HC-12416R(config)#interface POS 10/0 2. 為了讓 traffic 可以經由 LSP tunnel 301 傳送 , 所以我們在NSYSU的 NSYSU-7609R 把目的地為192.168.111.21 加入 static route ,讓Traffic先經Tunnel 300到達台中 NSYSU-7609R(config)#ip route 192.168.111.21 255.255.255.255 tunnel 300
3.接著到TP-12416R把台北連接新竹的POS 9/0介面關掉,使LSP Tunnel
301斷線,當新竹HC-124016R的POS 10/0得到現露出問題的訊息後,會將原本經由POS 10/0出去的Traffic改由LSP
Tunnel 302傳送
我們針對 sending rate 分別為 100 Mbit/s 、200 MBit/s與 300MBit/s 的 Traffic 由中山發送到台北,量測時間為 120 秒,共發出 2000000個 packet,每個 packet 為 1000 Bytes,其所量測到的數據如下表所示
我們把數據用圖來表示,可以發現到
200Mbit/s 在 Keep alive time 為 5 秒時,其 packet drop
的數量竟然會比 300 Mbit/s 的 traffic
還高,不過此時若看一下圖二的斷線恢復時間,可以發現
200Mbit/s的 Traffic 在該次斷線恢復所花費的時間,比
300 Mbit/s 的 Traffic 高出許多,所以斷線的時間會根據 Keep
alive的設定而有所不同 ,即使是相同的 keep alive
設定,其偵測到斷線的時間也不見得一樣
圖(一) Packet drop 的數量
圖(二) 斷線恢復時間
圖(三) 實驗120秒的平均
Throughput
接下來我們我們針對不同的 packet size (1000 Byte, Auto length, 64 byte) , sending rate 均為為 100 Mbit/s 而為了使量測的時間均接近 120 秒,所以由 packet generator 所預估的傳送時間來調整要發送的封包數
我們把數據用圖來表示,可以發現 Packet
Generator packet size 使用 Auto-Length 所產生的 traffic 與使用64
Byte 的 traffic 大致相同,而在相同的速率下, packet size
較小的 packet drop 的數量會比 packet size 較大的 traffic
還高,斷線恢復時間三者頗為接近,至於 Throughput 則是
Keep alive 設定越小其斷線的時間當然越短,packet drop
的數量就比較少,當然平均的 throughput 會比較高
C. Preemption測試的 topology 如下
1. 首先建立setup priority與holding priority皆為7的 LSP tunnel 300保留頻寬200M ,接著建立 setup priority與holding priority皆為4的LSP tunnel 301保留頻寬300M,在此皆不指定路徑,但routing protocol會先找shortest path,也就是由 NSYSU 7609R 經台南到台北 NSYSU-7609R(config)#interface
tunnel 300
2. 最後建立setup priority與holding priority皆為1的 LSP tunnel 302,指定路徑為由 NSYSU-7609R 經台南到台北,由於台南與台北之間的頻寬設為550Mbps,不足以滿足LSP tunnel 302 ,所以會搶奪優先權較低的LSP tunnel 300、301的頻寬來建立LSP,而在台南到新竹的頻寬又只剩400Mbps,所以最後LSP Tunnel 301會換路徑,而LSP Tunnel 300因為pariority比301低,故會因沒有資源而斷線 NSYSU-7609R(config)#ip
explicit-path identifier 16
NSYSU-7609R(config)#interface tunnel 302
因為低優先權的 LSP Tunnel 會因為被搶奪而中斷,而每次實驗時搶奪的時間點皆不相同(手動下指令來讓高優先權的 LSP Tunnel 搶奪中、低優先權 LSP Tunnel的資源 ),所以量測所得到的低優先權 Traffic 的數據比較沒有意義,而高優先權的 Traffic 是搶奪別人的,所以不會有 packet drop 的情形出現,因此僅列出中優先權的 Traffic 數據,如下表所示
我們把數據用圖來表示,可以發現 Preemption 的斷線恢復時間是沒規則性的,有時它會迅速的找到新路徑並在1秒內就完成切換動作,但有時卻會花費數十秒時間尋找新路徑,因此 Packet drop 的數量會因斷線恢復所花費的時間不同而有差異
D. Load sharing 1. 由中山大學建立兩條 LSP tunnel 到台北 , 第一條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R 再到達台北 , 第二條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R , 新竹 HC-12416R 到達台北 , 整個 topology 如下圖所示
NSYSU-7609R(config)#ip explicit-path identifier 19
NSYSU-7609R(config)#ip explicit-path identifier 27 NSYSU-7609R(config)#interface tunnel
271
NSYSU-7609R(config)#interface tunnel 272
2.設定 load-sharing 於 tunnel 271 與 tunnel 272 上 , 並把 192.168.111.0 的子網路 static route 到這兩個 tunnel 上 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 271 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 272 NSYSU-7609R(config)#ip route 192.168.111.0 255.255.255.0 tunnel 271 NSYSU-7609R#show ip cef 192.168.111.0 3. 我們由先前的 load sharing 測試可以知道 , load sharing 的作法是根據 hash function 來分配到相同子網路的 traffic . 我們測試了三組不同的 source-destination pair 來做 load-sharing . (1) 192.168.60.51 --- > 192.168.111.21 192.168.50.53 --- > 192.168.111.21 (2) 192.168.50.52 --- > 192.168.111.21 192.168.60.51 --- > 192.168.111.21 (3) 192.168.50.53 --- > 192.168.111.21 192.168.60.53 --- > 192.168.111.21 經由測試我們可以發現 , 第一組資料會分別走不同的 LSP tunnel , 其中 192.168.60.51 到 192.168.111.21的 Traffic 會走 LSP tunnel 422 , 而 192.168.50.53 到 192.168.111.21的 Traffic 會走 LSP tunnel 421. 第二組資料會走相同的的 LSP tunnel 422 , 而第三組資料會走相同的的 LSP tunnel 421 , 所以 CISCO 的 load sharing 確實可以 work , 但是因為使用 hash function 來分配 traffic , 所以要在大量的不同 source-destination pair 下效果才會明顯 . 第一組資料的測試 傳送後
NSYSU-7609R#show interfaces tunnel 421 傳送前
E. Auto-Bandwidth 測試的 topology 如下圖所示 1. 首先我們先從中山 NSYSU-7609R 建立 LSP tunnel 311 到台北 , 並設定 auto-bandwidth 最大值為 200Mbps , 最小值為 100Mbps , 調整的時間間隔為可設定的最小值 300 秒 , 頻寬的取樣週期為可設定的最小值 30 秒 , 並把目的地為 192.168.111.21 的 packet binding 到 tunnel 311 . NSYSU-7609R(config)#interface tunnel
311 2. 我們由中山大學的
packet generator 送出 traffic , 剛開始的速率為 150 Mbps , 經過
214 秒後把速率降為 120M bps , 在 521 秒時把速率提升到 160
Mbps , 在 826 秒時再提升速率到 190
Mbps
3. 剛開始 traffic 的速率為 150 Mbps 然後在中山 NSYSU-7609R 觀察 tunnel 311 , 發現此時的取樣頻寬最大值為 149993 NSYSU-7609R# show mpls traffic-eng tunnels tunnel 311 4. 等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經變成 119994, 表示此時的 Auto-bandwidth adjustment 已經開始作用 .
5. 等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經變成 157121, NSYSU-7609R# show mpls traffic-eng tunnels tunnel 311 6. 再等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經變成 186872, NSYSU-7609R# show mpls traffic-eng tunnels tunnel 311 7. 再 等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經變成 190042, NSYSU-7609R# show mpls traffic-eng tunnels tunnel 311 Auto-bandwidth 是可以 work 的 , 只是說明文件太簡略 , 以致於我們無法得知它運作的詳細過程. 接著我們把剛剛所走的 LSP Tunnel , 增加 background traffic , 讓流量超過實際頻寬 , 此時因為 signaling 的封包很容易因為擁擠而被丟棄 , 導致 LSP tunnel 會一下子 down 一下子 up , 使得 timer 還沒 timeout 之前 , LSP tunnel 的 link state 就會變成 down 讓 Auto-bandwidth 無法正常 work .
F. Guarantee Bandwidth
關於guarantee bw 的測試 , 在 TenGigabitEthernet 的 interface
中可以用 tx-cos 來 config ,
但測試的結果無法呈現是否成功 ,也許要灌滿 10G
才知道受否有保障頻寬 , 但我們的 packet generator
最多只能產生 1G 的 traffic , 無法灌爆 10G ,
因此無法測試是否可以 work , 而 POS 及 GigabitEthernet 的
interface 上, 在 config 時就會有錯誤訊息所以無法測試 .
TN-12416R>en TN-12416R(config)#interface
GigabitEthernet 1/0 TN-12416R(config)#class-map
MPLS-EF
C:\TWAREN\Iperf>iperf
-c 211.79.56.2 -u -b 1000m -t 10 -T 0xb8
NSYSU-7609R#show
interfaces TenGigabitEthernet 3/1 NCKU-7609R#show interfaces
TenGigabitEthernet 3/1 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
備 註 | 本階段測試到此結束 . | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/04/01 (四) |
工作進度 | 暫停測試一天 |
結 果 |
|
備 註 | 配合東森電路轉移 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/30、31(二、三) | ||||||||||||||||||||||||||||||||||||||||||||
工作進度 | 測試 MPLS 的 Preemption與Reroute功能,並使用Traffic Generator測量數據 | ||||||||||||||||||||||||||||||||||||||||||||
結 果 |
A. Preemption測試的 topology 如下
1. 首先建立setup priority與holding priority皆為7的 LSP tunnel 300 ,接著建立 setup priority與holding priority皆為4的LSP tunnel 301,在此皆不指定路徑,但routing protocol會先找shortest path,也就是由 NSYSU 7609R 經台南到台北 NSYSU-7609R(config)#interface
tunnel 300
2. 最後建立setup priority與holding priority皆為1的 LSP tunnel 302,指定路徑為由 NSYSU-7609R 經台南到台北,由於台南與台北之間的頻寬設為550Mbps,不足以滿足LSP tunnel 302 ,所以會搶奪優先權較低的LSP tunnel 300、301的頻寬來建立LSP,而在台南到新竹的頻寬又只剩400Mbps,所以最後LSP Tunnel 301會換路徑,而LSP Tunnel 300因為pariority比301低,故會因沒有資源而斷線 NSYSU-7609R(config)#ip
explicit-path identifier 16
NSYSU-7609R(config)#interface tunnel 302
3.在建好LSP Tunnel 300、301後,各傳送一條 100Mbps的UDP
flow,其封包在經過 2. 的步驟後,發現在Preemption發生到LSP Tunnel 301沿新路徑重新建好,總共掉了
99,374個封包,而LSP Tunnel 300則因完全斷線,所以接下來的封包全被丟棄。
a. Packet Size固定為
1000 bytes b. Packet Size為
auto-length 附註:因為無法固定傳送時間,故在auto-length時,傳送較多的封包以滿足時要所需的時間 B. Fast-Reroute測試的 topology 如下
HC-12416R(config)#ip explicit-path identifier 223
NSYSU-7609R(config)#ip route 192.168.111.21 255.255.255.255 tunnel 300
3.接著到TP-12416R把台北連接新竹的POS 9/0介面關掉,使LSP Tunnel 301斷線,當新竹HC-124016R的POS 10/0得到現露出問題的訊息後,會將原本經由POS 10/0出去的Traffic改由LSP Tunnel 302傳送
4.在步驟 2.時我們已經在傳送100Mbps的Traffic Flow經LSP Tunnel 300在再經 LSP Tubnnel 301到台北,當新竹到台北斷線,而HC -12416R測到並Reroute之前,沿著LSP Tunnel 301傳送的封包都會被丟棄 a. Packet Size固定為 1000 bytes
a. Packet Size為 auto-length
|
||||||||||||||||||||||||||||||||||||||||||||
備 註 |
1.在Fast-Reroute實驗中,
發現從Traffic Generator中間突然收不到封包到繼續收到封包大約是26秒,試了多次皆如此,表示Cisco 12416偵測的週期約為26秒
,相較之下Preemption測驗中尋找路徑重新建立的速度便快很多,丟掉的封包也較少 2.若能調小Interface偵測斷線的timer,應該可以減少封包被丟掉的數目 |
||||||||||||||||||||||||||||||||||||||||||||
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/29 (一) |
工作進度 | 測試 MPLS 的 Preemption與Reroute功能 |
結 果 |
此次測試的 topology 如下
1. 首先建立setup priority與holding priority皆為7的 LSP tunnel 20 由 新竹HC-12416R 到台北,接著建立 setup priority與holding priority皆為3的LSP tunnel 221,由 台中 TC-12416R 經由新竹到達台北 TC-12416R(config)#ip explicit-path identifier
221 HC-12416R(config)#interface tunnel
20
TC-12416R#show mpls traffic-eng tunnels tunnel 221
2. 最後建立setup priority與holding priority皆為1的 LSP tunnel 251 由 新竹HC-12416R 到台北,由於新竹與台北之間的頻寬設為500Mbps,不足以滿足LSP tunnel 251 ,所以會搶奪優先權較低的LSP tunnel221的頻寬來建立LSP TC-12416R(config)#ip explicit-path identifier
20 HC-12416R(config)#interface tunnel
251 HC-12416R#show mpls traffic-eng tunnels tunnel 251
3.發現中優先權LSP tunnel 221的已經改走另外一條路徑,改走經由台南到台北,而低優先權的LSP tunnel 20 ,也從原本由新竹經台南到台北的路徑,變成直接由新竹到台北 TC-12416R#show mpls traffic-eng tunnels tunnel 221 HC-12416R#show mpls traffic-eng tunnels tunnel 20 4.在LSP tunnel 221被LSP Tunnel 251搶奪之後,會改走別的路經,而在LSP tunnel 20也可能會因原本的路徑上的資源被LSP tunnel221搶走,而改道原LSP tunnel 221 的路徑。如果在建立LSP時指定路徑,如20040325所做的設定,則在指定路徑資源不足時,便會直接斷線,而不會改走其他路徑
|
備 註 | 如果在建立LSP時指定路徑的話,則在指定路徑資源不足時,便會直接斷線,而不會改走其他路徑,若是DYNAMIC建立的,則會在資源被搶奪後,找其他替代路徑 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/28 (日) |
工作進度 | Load sharing 的測試 |
結 果 |
1. 由中山大學建立兩條 LSP tunnel 到台北 , 第一條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R 再到達台北 , 第二條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R , 新竹 HC-12416R 到達台北 , 整個 topology 如下圖所示
NSYSU-7609R(config)#ip explicit-path identifier 19
NSYSU-7609R(config)#ip explicit-path identifier 27 NSYSU-7609R(config)#interface tunnel
271
NSYSU-7609R(config)#interface tunnel 272
2.設定 load-sharing 於 tunnel 271 與 tunnel 272 上 , 並把 192.168.111.0 的子網路 static route 到這兩個 tunnel 上 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 271 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 272 NSYSU-7609R(config)#ip route 192.168.111.0 255.255.255.0 tunnel 271 NSYSU-7609R#show ip cef 192.168.111.0 3. 由中山的 sender PC 發出 packet C:\TWAREN\Iperf> iperf -c 192.168.111.1 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.2 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.3 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.4 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.5 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.6 -u -b 100m -l 1000 -t 10 4. 查看這兩條 tunnel NSYSU-7609R#show interfaces tunnel 271 5. 可以發現到這兩條 tunnel 均有 packet forward. 所以 load-sharing 是可以 work.
6. 經由 David 告知我們 7609 Router 是利用 hash function 來做 load-sharing 的 , 也就是說每一個 source-destination pair 均會 hash 到某一個 tunnel , 所以 load-sharing 是要在很多不同的 source-destination pair , 才會比較平均的分配 traffic 到 tunnels 中 , 如果說 flow 太少 , 則這些 flow 就可能會剛好分配到相同的 tunnel , 此時無法看出 load-sharing的功用. NSYSU-7609R#show mls cef exact-route 192.168.20.21
192.168.111.1
7. 我們利用 show ip cef exact-route [source ip] [destination ip] 來查看 flow 到底是往哪一條 tunnel 走 , 卻發現與 步驟 6 show mls cef exact-route [source ip] [destination ip] 所得到的結果有所不同 , NSYSU-7609R#show ip cef exact-route 192.168.20.21
192.168.111.1 8. 我們利用中山 sender PC 發 packet 來驗證一下看哪一邊顯示出來是對的 , 所以我們發送 packet 到 192.168.111.1 , 192.168.111.2 , 192.168.111.4 , 比較之後就可以知道哪一邊是對的 C:\TWAREN\Iperf> iperf -c 192.168.111.1 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.2 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.4 -u -b 100m -l 1000 -t 10 發送前 NSYSU-7609R#show interfaces tunnel 271 發送後 NSYSU-7609R#show interfaces tunnel 271 9 . 所以 show mls cef exact-route [source ip] [destination ip] 這個觀察指令才是對的 10. 相同的設定在台中的 TC-12416R 上還是無法 work |
備 註 | load-sharing 是可以在 7609 上 work 的 , 但 12416R上無法 work |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/27 (六) |
工作進度 | Load sharing 的測試 |
結 果 |
1. 由中山大學建立兩條 LSP tunnel 到台北 , 第一條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R 再到達台北 , 第二條 LSP 由中山 NSYSU-7609R 建立經由國網台南 TN-12416R , 新竹 HC-12416R 到達台北 , 整個 topology 如下圖所示
NSYSU-7609R(config)#ip explicit-path identifier 19
NSYSU-7609R(config)#ip explicit-path identifier 27 NSYSU-7609R(config)#interface tunnel
271
NSYSU-7609R(config)#interface tunnel 272
2. 設定 load-sharing 於 tunnel 271 與 tunnel 272 上 , 並把 192.168.111.0 的子網路 static route 到這兩個 tunnel 上 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 271 NSYSU-7609R(config)#ip cef load-sharing algorithm tunnel 272 NSYSU-7609R(config)#ip route 192.168.111.0 255.255.255.0 tunnel 271 NSYSU-7609R#show ip cef 192.168.111.0 3. 由中山的 sender PC 發出 packet C:\TWAREN\Iperf> iperf -c 192.168.111.1 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.2 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.3 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.4 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.5 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf> iperf -c 192.168.111.6 -u -b 100m -l 1000 -t 10 4. 查看這兩條 tunnel NSYSU-7609R#show interfaces tunnel 271 5. 可以發現到這兩條 tunnel 均有 packet forward. 所以 load-sharing 是可以 work. |
備 註 | load-sharing 是可以在 7609 上 work 的 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/26 (五) |
工作進度 | 找尋 queuing 相關文章 |
結 果 |
找到 1. MPLS DiffServ Tunneling Modes 2. MPLS Quality of Service (Qos) 3. Configuring IP Unicast Layer 3 Switching on Supervisor Engine 1 等文章 |
備 註 | 正在研究如何利用 queue 來達到 Guaranteed bandwidth . |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/25 (四) |
工作進度 | 測試 MPLS 的 Preemption與Fast-Reroute 功能 |
結 果 |
此次測試的 topology 如下
1. 首先建立setup priority與holding priority皆為7的 LSP tunnel 20 由 新竹HC-12416R 到台北,接著建立 setup priority與holding priority皆為3的LSP tunnel 221,由 台中 TC-12416R 經由新竹到達台北 , 再來由新竹建立 backup path LSP tunnel 223 經由台南到達台北. HC-12416R(config)#ip explicit-path identifier
20 TC-12416R(config)#ip explicit-path identifier
221 HC-12416R(config)#ip explicit-path identifier 223 HC-12416R(config)#interface tunnel
20
HC-12416R(config)#interface tunnel 223 HC-12416R(config)#interface POS 10/0
2. 為了讓 traffic 可以經由 LSP tunnel 221 傳送 , 所以我們在台中的 TC-12416R 把目的地為192.168.111.2 加入 static route .
3. 最後建立setup priority與holding priority皆為1的 LSP tunnel 251 由 新竹HC-12416R 到台北,由於新竹與台北之間的頻寬設為500Mbps,不足以滿足LSP tunnel 251 ,所以會搶奪優先權較低的LSP tunnel 20與221的頻寬來建立LSP HC-12416R(config)#interface tunnel
251 HC-12416R#show interfaces tunnel 223
4.發現最低優先權的LSP tunnel 20已被中斷了,而中優先權的LSP tunnel221也被中斷了,而我們原本認為的中優先權LSP上的traffic應該被reroute到backup path,但是並沒有reroute,我們發現這是cisco的backup path只是針對link protection作用,並不會針對被preemption的tunnel做 reroute。 HC-12416R#show interfaces tunnel 251 TC-12416R#show interfaces tunnel 221 HC-12416R#show interfaces tunnel 223 |
備 註 | cisco的preemption是可以work的,而Fast-reroute只會針對Link fail才會開始作用,故backup path只是針對link protection作用,並不會針對被preemption的tunnel做 reroute。 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/24 (三) |
工作進度 | Auto-bandwidth 的測試 |
結 果 |
1. 首先我們先從中山 NSYSU-7609R 建立 LSP tunnel 18 到台北 , 並設定 auto-bandwidth 最大值為 100Mbps , 最小值為 10Mbps , 調整的時間間隔為可設定的最小值 300 秒 , 頻寬的取樣週期為可設定的最小值 30 秒 , 並把目的地為 211.79.59.2 的 packet binding 到 tunnel 18 . NSYSU-7609R(config)#interface tunnel 18 2. 我們由中山大學的 sender PC 送出 50 Mbps 的 udp traffic 到台北 C:\TWAREN\Iperf>iperf -c 211.79.59.2 -u -b 50m -l 1000 -t 350
3. 然後在中山 NSYSU-7609R 觀察 tunnel 18 , 發現此時的取樣頻寬最大值為 51622 NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 4. 等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經變成 52300 , 表示此時的 Auto-bandwidth adjustment 已經開始作用 . NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 5. 接下來我們把 traffic 由 50Mbps 調整成 20Mbs .然後觀察 tunnel . 可以發現此時的取樣頻寬最大值為 20920 . NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 6. 再等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 由 52300 已經改成 20920, 表示此時的 Auto-bandwidth adjustment 已經開始作用而且也是成功的 . SYSU-7609R#show mpls traffic-eng tunnels tunnel 18 7. 接下來我們把 traffic 由 20Mbps 調整成 60Mbs .然後觀察 tunnel . 可以發現此時的取樣頻寬最大值為 62810 . NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 8. 再等待時間超過調整時間 300 秒間隔後 , 我們可以發現 Bandwidth Requested 已經上升為 54583 . NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 9. 再等一次調整時間 , 我們可以發現 Bandwidth Requested 由 54583 變成 61244 , 所以我們認為 Bandwidth Requested 所取的值是這段期間內的平均值 . NSYSU-7609R#show mpls traffic-eng tunnels tunnel 18 |
備 註 |
Auto-bandwidth 是可以 work 的 , 只是說明文件太簡略 , 以致於我們無法得知它運作的詳細過程. |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/23 (二) |
工作進度 | 測試 MPLS 的 Load Balancing 功能 |
結 果 |
此次測試的 topology 如下
1. 建立 LSP tunnel 221 由 台中 TC-12416R 經由新竹到達台北 , 然後再建立 LSP tunnel 222 由台中經新竹 , 台南到達台北 . TC-12416R(config)#ip explicit-path identifier
221 TC-12416R(config)#ip explicit-path identifier
222 TC-12416R(cfg-ip-expl-path)#next-address 211.79.59.186
TC-12416R(config)#interface tunnel
222
3. 在中山的 NSYSU-7609R 建 LSP tunnel 231 到台中 NSYSU-7609R(config)#interface tunnel
231 4. 我們把 tunnel 221 與 tunnel 222 開啟 load-sharing , 然後把往 192.168.111.0 的 packet 導入到 tunnel 221 與 tunnel 222. TC-12416R(config)#ip cef load-sharing algorithm tunnel 221 TC-12416R(config)#ip cef load-sharing algorithm tunnel 222 TC-12416R(config)#ip route 192.168.111.0 255.255.255.0 tunnel 221 然後我們先確定一下 load 是否可以 sharing 在這兩條 tunnel 上 TC-12416R#show ip cef 192.168.111.0
5. 在由中山 sender PC 發出 traffic 到 192.168.111.1 與 192.168.111.2 之前 , 由台中 TC-12416R 觀察 tunnel 221 與 tunnel 222 的發送數 , 然後由中山 sender PC 發出 traffic 到 192.168.111.1 與 192.168.111.2 之後 , 再觀察台中 TC-12416R 的 tunnel 221 與 tunnel 222 的發送數 TC-12416R#show interfaces tunnel 221
C:\TWAREN\Iperf>iperf -c 192.168.111.1 -u -b 100m -l 1000 -t 10 C:\TWAREN\Iperf>iperf -c 192.168.111.2 -u -b 100m -l 1000 -t 10 TC-12416R#show interfaces tunnel 221
6. 發現 packet 只從 LSP tunnel 222 傳送 , 並沒有照預期的將 traffic 分散到兩條 LSP tunnel 上
|
備 註 | Per- destination load balancing 並未成功 , 不確定我們所做的步驟是否完整 , 有待研究 . |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/22 (一) |
工作進度 | 測試 MPLS 的 fast-reroute 功能 |
結 果 |
此次測試的 topology 如下
1. 建立 LSP tunnel 221 由 台中 TC-12416R 經由新竹到達台北 , 由新竹建立 backup path LSP tunnel 223 經由台南到達台北. TC-12416R(config)#ip explicit-path identifier
221 HC-12416R(config)#ip explicit-path identifier 223
HC-12416R(config)#interface tunnel 223 HC-12416R(config)#interface POS 10/0 由新竹的 HC-12416R 看看 fast-reroute 的 database 確實有設定成功 HC-12416R#show mpls traffic-eng fast-reroute database 2. 為了讓 traffic 可以經由 LSP tunnel 221 傳送 , 所以我們在台中的 TC-12416R 把目的地為211.79.59.2 加入 static route .
3. 我們在台中發送目的地為211.79.59.2 的 ICMP 封包 .
4. 然後我們把台北連接新竹的 interface POS 9/0 shutdown .
5. 然後由台中繼續發送 ICMP 封包 , 起初因為剛斷線 , signalling 還來不及反應 , 所以封包會由原本的 路徑LSP tunnel 221 送 , 所以沒有回應 , 連續發送幾次 ICMP 封包後 , 就會發現開始收到回應 , 表示 fast reroute work , LSP tunnel 223 開始有封包輸出 . TC-12416R#ping 211.79.59.2
|
備 註 | fast reroute 是可以 work 的 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/20 (六) / 2004/03/21 (日) |
工作進度 | 測試 MPLS 的 fast-reroute 功能 |
結 果 |
1. 首先由國網台南 TN-12416R 建一條 LSP tunnel 201 到 台北科技大樓 TP-12416R, 再建立第二條 LSP tunnel 202 經由新竹國網到台北科技大樓 TP-12416R, 此第二條 LSP tunnel 202 欲當成 LSP tunnel 201的backup lsp, 然後由中山的 sender PC 發送 packet 經由第一條 LSP tunnel 201 到達台北科技大樓, 在傳遞 packet 到台北的期間中, 將台北科技大樓的 interface POS 10/0 shutdown, 希望 packet 能夠由所建立的 backup path LSP tunnel 202 轉送到台北科技大樓, 其指令如下 TN-12416R(config)#ip explicit-path identifier 201 TN-12416R(config)#ip
route 211.79.59.2 255.255.255.255 tunnel 201
中山 sender PC C:|\TWAREN\Iperf>iperf -c
211.79.59.2 -u -b 50m -l 1000 -t 400
TN-12416R#show mpls traffic-eng tunnels tunnel 201 Name: TN-12416R_t201 (Tunnel201) Destination: 211.79.59.2 TN-12416R#show interfaces tunnel 201 在傳送 packet 的途中把台北科技大樓 TP-12416R 的 interface POS 10/0 shutdown TP-12416R#conf TN-12416R#show mpls traffic-eng tunnels tunnel 201 Name: TN-12416R_t201 (Tunnel201) Destination: 211.79.59.2 TN-12416R#show interfaces tunnel 201 TN-12416R#show interfaces tunnel 202 interface tunnel 202 所顯示出來的 66 packets output 為原本就有的數量,而此數量並沒有增加, 表示在 台北科技大樓 TP-12416R 把 interface POS 10/0 shutdown 後, 傳送的 packet 並沒有經過此 backup path, 而是繼續走 LSP tunnel 201, 即使 tunnel 201 的 line protocol 為 down
|
備 註 | 以上觀察可知, 當台北科技大樓
TP-12416R 的 interface POS 10/0 shutdown 後, packet 依然會由 LSP
tunnel 201 傳送 , 而無法 reroute 到 LSP tunnel 202 ,
因此把建立LSP的起始 node 與要 reroute 的 node 均設定在同一
node (TN-12416R) 是無法 reroute 成功的. 按照 CISCO 的建議 , 改由台中的 12416R 來建立兩條 LSP ,一條經由台南國網到達台北, 另一條 backup path 由台南國網經由新竹到達台北 ,此時的建立LSP的起始 node 為台中的 12416 , 而 reroute 的 node 為台南國網 TN-12416R , 把建立LSP的起始 node 與 reroute 的 node 分開在不同點 , 然後再測試看看 , 不過我發現到台中的 TC-12416R 與 台南的 TN-12416R 似乎沒有直接相連 , 而是要透過新竹的 HC-12416R , 這一點與我所得到的 Research Network (Physical) topology 不同 . 這點需要請教相關人員來確定 Research Network的 topology . TC-12416R#traceroute 211.79.60.2 此次實驗的結論為當把建立LSP的起始 node 與要 reroute 的 node , 均設定在同一 node (TN-12416R) 時 , fast reroute 無法成功 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/19 (五) |
工作進度 |
測試 MPLS preemption 功能 |
結 果 |
1. 先建立一條 LSP tunnel 191 到台南, 並設定保留頻寬 600M, 它的 setup priority 與 holding priority 兩者均為 4 , 並確定它是 up 的, 接著再建立另外一條 LSP tunnel 192 到台南 , 一樣保留頻寬為 600M , 但它的 setup priority 與 holding priority 兩者均設為 2 , 使得 LSP tunnel 192 的 priority 比 LSP tunnel 191 高 , 之後發現 LSP tunnel 192 建立成功, 而原本建立成功的 LSP tunnel 191 會因為被搶奪頻寬而變成 down NSYSU-7609R#conf NSYSU-7609R(config)#ip explicit-path identifier 1 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.58 NSYSU-7609R(cfg-ip-expl-path)#exit NSYSU-7609R(config)#interface tunnel 191 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.60.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 600000 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 4 4 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 1 NSYSU-7609R(config-if)#exit NSYSU-7609R(config)#interface tunnel 192 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.60.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 600000 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 2 2 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 1 NSYSU-7609R(config-if)#exit NSYSU-7609R#show mpls traffic-eng tunnels tunnel 191
Name: NSYSU-7609R_t191 (Tunnel191) Destination: 211.79.60.2
NSYSU-7609R#show mpls traffic-eng tunnels tunnel 192
NSYSU-7609R#show mpls traffic-eng tunnels tunnel 191 2. 如果此時把 LSP tunnel 192 shutdown , 原本因被強奪而 down 的 LSP tunnel 191 會改變成 up 的狀態 NSYSU-7609R#conf 3. 再建立一條 priority 比 LSP tunnel 191 更低的 LSP tunnel 193, 其 setup priority 與 holding priority 皆為6 , 此時會因為 setup priority 6 小於 LSP tunnel 191 的 holding priority 2, 所以 LSP tunnel 193 無法搶奪 LSP tunnel 191 的頻寬, 故其狀態為 down. NSYSU-7609R(config)#interface tunnel 193 NSYSU-7609R#show mpls traffic-eng tunnels tunnel 193 4. 再建立一條 priority 同 LSP tunnel 193 的 LSP tunnel 194, 因 LSP tunnel 194 僅要求頻寬 50 M , 故在不需要搶奪頻寬下, LSP tunnel 194 可以成功建立. NSYSU-7609R#conf NSYSU-7609R#show mpls traffic-eng tunnels tunnel 194 Name: NSYSU-7609R_t194 (Tunnel194) Destination: 211.79.60.2 |
備 註 | preemption 的 signalling 是可以 work 的 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/18 (四) |
工作進度 | 到國網中心參加 MPLS introduction 課程 |
結 果 |
|
備 註 | |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/17 (三) |
工作進度 |
測試 Traffic generator 與 Auto bandwidth allocator 功能 |
結 果 |
1. Traffic generator 速率最高可以發送 988Mbps , 此時透過 NSYSU-7609R 該 Gigabit ethernet 介面的 RSVP signaling 會受到影嚮 , 似乎沒有保障 RSVP signaling 的封包. 2. 先建立 Tunnel 17 , 然後設定 Automatic bandwidth adjustment , 發現到該功能並沒有發揮作用 , 其設定指令如下所示. NSYSU-7609R#conf NSYSU-7609R(config)#ip explicit-path identifier 18 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.57 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.54 NSYSU-7609R(cfg-ip-expl-path)#exit NSYSU-7609R(config)#interface tunnel 18 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.59.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 100 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 1 1 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 18 NSYSU-7609R(config-if)#exit NSYSU-7609R(config)#mpls traffic-eng auto-bw timers frequency 30 NSYSU-7609R(config)#interface tunnel 18 NSYSU-7609R(config-if)#tunnel mpls traffic-eng auto-bw max-bw 10000 min-bw 100 NSYSU-7609R(config-if)#tunnel mpls traffic-eng auto-bw max-bw 10000 min-bw 100 Name: NSYSU-7609R_t18 (Tunnel18) Destination: 211.79.59.2 C:\TWAREN\Iperf>iperf -c 211.79.59.2 -u -b 50m -l 1000 -t 400 |
備 註 | 功能 Automatic bandwidth adjustment 並沒有發揮作用 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/16 (二) |
工作進度 |
測試 NSYSU-7609R 經由國網南科 TN-12416R 建立 tunnel 到其他節點 |
結 果 |
1. 可由中山 NSYSU-7609R 經由國網南科成功建立 LSP tunnel 到台北科技大樓 TP-12416R
2. 在 TP-12416R 上的設定如下 TP-12416R#conf Configuring
from terminal, memory, or network [terminal]? TP-12416R(config)#router TP-12416R(config)#router isis TWAREN TP-12416R(config-router)#mpls traffic-eng router-id loopback 0 TP-12416R(config-router)#mpls traffic-eng level-2 TP-12416R(config-router)#exit TP-12416R(config)#mpls traffic-eng tunnels TP-12416R(config)#interface POS 10/0 TP-12416R(config-if)#ip
rsvp bandwidth 500 3. 在 NSYSU-7609R 上的設定如下 NSYSU-7609R#conf NSYSU-7609R(config)#ip explicit-path identifier 16 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.57 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.54 NSYSU-7609R(cfg-ip-expl-path)#exit NSYSU-7609R(config)#interface tunnel 16 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.59.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 100 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 1 1 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 16 NSYSU-7609R(config-if)#exit NSYSU-7609R(config)#ip route 211.79.59.2 255.255.255.255 tunnel 16 4. 在中山的 sender端 PC 上用 iperf 發送 udp traffic 的指令 C:\TWAREN\Iperf>iperf -c
211.79.59.2 -u -b 100m -l 1000 |
備 註 | 在建立 LSP tunne 之前, 需注意要把 mpls 的 rsvp 功能啟動, 如 2 所示 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/15 (一) |
工作進度 |
測試 NSYSU-7609R 經由國網南科 TN-12416R 建立 tunnel 到其他節點 |
結 果 |
1. 由中山 NSYSU-7609R 可成功建立 LSP tunnel 到國網南科, 但由國網南科無法建立 LSP tunnel 回到中山 NSYSU-7609R. 2. 嘗試建立由NSYSU-7609R 經由國網南科 TN-12416R 到 CCU-7609R 的 LSP tunnel,依然無法成功建立 Name: TN-12416R_t1 (Tunnel1) Destination: 211.79.58.2 |
備 註 | 遇到困難 : 無法建立 LSP tunnel 由國網南科到其他節點. |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/14 (日) |
工作進度 |
測試 interface 與 tunnel 的頻寬限制功能 |
結 果 |
在 NSYSU-7609R 的 GigabitEthernet 9/3 設定 speed , 發現在網址 上面的Configuring Ethernet Interface Speed and Duplex Mode所記載的 speed 設定如下 To configure the port speed for a 10/100 or a 10/100/1000-Mbps Ethernet port, perform this task: 最後發現在 NSYSU-7609R 上並不能更改設定, 只能設定為 1000 Mbps,不能設定成 10/100 Mbps. NSYSU-7609R(config)#interface
GigabitEthernet 9/3
|
備 註 | 在 NSYSU-7609R 上並未提供設定 interface speed 成 10/100 Mbps 的功能 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/13 (六) |
工作進度 |
由中山 7609R 建一條 LSP tunnel
到國網南科,研究如何 bind
flow 到該 tunnel ,但由於找不到可直接 bind
flow 到該 tunnel的指令, 所以換方向思考,改成設定 static
route 將想要被 binding 的 flow 導入到該 tunnel,
整個過程如下
NSYSU-7609R#conf NSYSU-7609R(config)#ip explicit-path identifier 1 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.58 NSYSU-7609R(cfg-ip-expl-path)#exit NSYSU-7609R(config)#interface tunnel 1 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.60.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 100 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 1 1 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 1 NSYSU-7609R(config-if)#exit NSYSU-7609R(config)#ip route 211.79.60.2 255.255.255.255 tunnel 1
|
結 果 |
可以把我們想要 binding 的 flow, 成功的導入到 tunnel 1 來傳送 PC/:>iperf -c 211.79.60.2 -u -b 100m NSYSU-7609R#show interfaces tunnel 1 TN-12416R#show interfaces GigabitEthernet 13/0
|
備 註 | 此方法可達到 binding flow 的效果, 但此方法不曉得是否為 CISCO 所定義的方法? |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/12 (五) |
工作進度 | 由中山 7609R 建一條 LSP tunnel 到國網南科,研究如何 bind flow 到該 tunnel |
結 果 |
找不到如何 bind flow 到該 tunnel的指令 |
備 註 | 遇到困難 : 找不到如何 bind flow 到該 tunnel的指令 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/11 (四) |
工作進度 |
由中山 7609R 建一條 LSP tunnel 到國網南科 , 並傳送 udp packet 由PC經中山 7609R 到國網南科12416R NSYSU-7609R#conf NSYSU-7609R(config)#ip explicit-path identifier 1 NSYSU-7609R(cfg-ip-expl-path)#next-address 211.79.60.58 NSYSU-7609R(cfg-ip-expl-path)#exit NSYSU-7609R(config)#interface tunnel 1 NSYSU-7609R(config-if)#ip unnumbered loopback 0 NSYSU-7609R(config-if)#tunnel destination 211.79.60.2 NSYSU-7609R(config-if)#tunnel mode mpls traffic-eng NSYSU-7609R(config-if)#tunnel mpls traffic-eng bandwidth 100 NSYSU-7609R(config-if)#tunnel mpls traffic-eng priority 1 1 NSYSU-7609R(config-if)#tunnel mpls traffic-eng path-option 1 explicit identifier 1 NSYSU-7609R(config-if)#tunnel mpls traffic-eng autoroute announce |
結 果 |
由 PC 可知道送出去的封包數,並在中山 7609R 觀察該 tunnel也有轉送封包, 國網南科TN12416R 也有收到封包 PC/:>iperf -c 211.79.60.2 -u -b 100m NSYSU-7609R#show interfaces GigabitEthernet 9/3 TN-12416R#show interfaces GigabitEthernet 13/0 |
備 註 | 遇到困難 : 找不到如何 bind flow 到該 tunnel的指令 |
意 見 | 對此次測試發表建議 觀看建議 |
日 期 |
2004/03/10 (三) |
工作進度 | 可成功登入 NSYSU 7609 並將一PC連接到7609的 interface 9/11 |
結 果 |
Traffic 目前可由 PC 送到 NSYSU 的 7609 |
備 註 | |
意 見 | 對此次測試發表建議 觀看建議 |