PRI 撥接網路管理之探討

(1)

PRI 撥接網路管理之探討

楊峻榮

國立成功大學電算中心

[email protected]

摘要

目前 TANet 上之撥接網路所使用的通用連線速度為 56k，ISP 端大都採用 PRI 線路，實線方面雖較傳統撥接線路來的簡潔，但也潛藏著一些管理上的盲點，例如很難判斷 PRI 及其 channel 是否異常,及其異常原因為何。因此將以 PRI 撥接環境為背景，來探討整個撥接網路之管理架構及方式。本文將以描述建置時所需考量之因素及一般撥接網路的問題產生區域及原因，最後將探討如何應用各種管理的工具及方式，使其管理系統化、效率化，進而達到環境穩定、連線效率提高及資源有效應用的目標。

關鍵字：

撥接網路、PRI、RADIUS、PPP、PAP、CHAP、 T1、網路管理

壹、前言

PRI（Primary Rate Interface）目前大多應用在連接公眾交換式網路（ Public Switched Telephone Network，PSTN）中的多工器與用戶端設備（Customer Premises Equipment CPE）間的多工傳輸，其架構在 T1 及 E1 兩種界面上。而目前台灣大多是使用 T1 線路，總傳輸速率為 1.544Mbps ，其利用 TDM （ Time Division Multiplexing ）方式將實體線路劃分成 24 個 (23B+1D)64Kbps 的 channel。由於 56K/ISDN 撥接網路 Server 端大都是採用 PRI 數位傳輸，以管理者角度而言，線路方面比傳統類比線路簡潔，但也因其特性而有以下之問題： 1. 如何判斷線路及 channel 之正常與否：因 PRI 線路不像傳統線路容易檢測實線及運作是否正常。 2. PRI 設備之穩定度及負載：因 PRI 設備是 DSU 及 Terminal_server 或 Router 之集合，較不易界定問題點，所以設備穩定度就更形重要。而傳統架構中 Terminal_server 及 modem 是分開的，較易界定問題點。目前本校撥接網路提供 12 個 PRI（另有 114 線傳統 33.6K 線路及設備，不在此文討論）供使用者以 modem 或 ISDN TA 撥接上網，並在近期計劃更新舊有線路及設備為 PRI，可能總共會有 16 至 20 個 PRI，故最多可能有 460 個(23 channel X 20=460)使用者同時上線，而目前本校撥接使用者有一萭多人，因此本校之撥接網路也算是一個稍具規模的架構。而這一龐大的架構就需有一套良好的管理機制來達到以下效果： 1. 能主動找出問題點並即時讓管理者得知此問題訊息，因往往等到 user 反映時，此問題可能已存在一段時間了。 2. 當問題產生時，能在最短時間找出原因並解決。 3. 擷取及有效分析資料，以判斷其問題原因或是供作調整設備之參考及管理上之依據。 4. 良好的帳號管理及管制措施，使得能將有限的資源發揮最大的作用。

貳、架構與建置

目前本校之撥接網路之架構如圖(一)，所有設備分佈在兩個網路區段上，再透過 Router 連上

(2)

TANet，並使用兩部工作站當 RADIUS 及 DNS（撥接網路之各 IP_port 用，以便網路應用軟體之 Domain_name 反查），並使用一部傳統 modem 作為即時通報系統之撥號器。當然這架構是以成大之環境作為考量。而一般在建置撥接網路時會有下述之考量因素。

一、線路及設備數量

這是最基本的考量因素，需評估約有多少使用者帳號，而其「使用者/線路比」為何。若是新建置之單位，一般而言都因預算的關係，先提供少數之 PRI 線路及設備，待使用一段時間後，再依使用者人數及定時上線人數之統計來做評估，並依「使用者/線路比」來決定需再增加多少 PRI 線路及設備。以目前本校為例，雖已提供了近四百線/channel 之線路，但申請之使用者有一萬多人，且每當尖峰時間（23:00-01:00）使用率都在 99%左右，所以線路數量還是嚴重不足，有再增加線路及設備之必要，除非有嚴密之管制措施，但這先決的考量因素是政策問題。

二、提供之撥接服務及認證方式

(一)使用者簽入方式

PRI server 所提供 dial_in 有兩種方式，這關係著使用者簽入的方式： 1. Terminal_mode：即以終端機畫面供使用者 Login，Login 後再依其需要選用 PPP、SLIP 或其他，此方式是使用者彈性較大，但使用上較不方便。 2. 自動偵測：即是使用 PPP，其認證方式有

PAP 及 CHAP。至於 SLIP，雖然使用者感覺其是自動操作，但 SLIP 封包內無 PAP 或 CHAP 認證封包，而是使用 script 方式達成。建議採用自動偵測之 PPP 即可，因為目前絕大部份使用者皆以 Windows 95/98 之撥號網路上網，因為此方式以使用者而言較為簡單，而以其他系統（例如 Linux、NT）上網者也都有提供 PPP。

(二)PPP 認證協定方式

1. PAP（Password Authentication Protocol）使用傳統的使用者名稱及密碼的驗證方式。 2. CHAP（Challenge Handshake Authentication

Protocol）以發出「質疑」及查核「回應」來進行身份驗證，而其過程中的 challenge、 response、acknowledgement 三個步驟，由 PPP 軟體負責[4]，使用者不需去理會。其特性是送出之密碼是經編碼，安全性較高。建議採用 PAP 即可，因一般 PPP 軟體預設為 PAP 驗證，至於安全之考量，因使用者至 PRI 設備是以電話線路，並無封包被截取之顧忌。

(三)驗證軟體

某些廠牌有其特定之驗證軟體，來作為 PRI 與驗證資料庫之間的運作，但因所用的 PRI 設備不見得為同一廠牌，且設備可能會逐年增加及替換，所以多個 PRI 設備的環境就可能會有多套驗證軟體及資料庫的狀況，如此只有加重管理上的負擔及使用者之不便。所以用一套各種 PRI 設備共通的驗證軟體就成為必備的條件，目前一般皆使用 RADIUS 認證軟體，因各 PRI 設備都有支援此軟體，且其強大的 Accounting 功能更是管理上的利器。

RADIUS（Remote Authentication Dial In User Service）為 dial_in 之認證軟體，並含有 accounting 及 log 功能。而其協定描述可參考 RFC-2138（驗證）及 RFC-2139（accounting）。它是介於 dial-in 伺服器及帳號資料庫伺服器之間的 client/server 協定[1]。這資料庫可以驗證使用者，並且取得使用者的存取及設定資訊。

PRI Server PRI Server

Router Master RADIUS Master DNS Slave RADIUS Slave DNS 即時監測主機 Modem (通報系統撥號器) Internet 電話線圖(一)本校撥接網路架構

(3)

部份廠商改寫 RADIUS 程式增加功能為其特定 PRI 設備使用；或是以 RADIUS 之協定發展圖形操作界面之帳號驗證及管理軟體，且可配合各種 PRI 設備，成為一管理操作方便之工具。但建置時需考量本身之架構及環境，例如某種軟體之帳號管理功能其圖形操作之方式，就不適合本校大量使用者之批次作業。所以在採用前，最好能先試用或多了解，以免屆時受制其操作方式，使得管理方式及處理速度處處受限。

三、是否同時提供 mail 帳號

本校師生眾多，教職員及學生有各自的 mail 主機，因撥接帳號並非人人需要，如學生宿舍有宿網可使用，故本校之 mail 帳號及撥接帳號是分開的。而許多的機構或是 ISP 是兩者帳號合而為一，不管是將 mail_server 和驗證 Server 共用一主機，或是兩者分開而以 NIS 方式共用一 password_database，雖如此對使用者及帳號管理而言是較為單純，但卻有安全上之顧慮，尤其是可用 telnet 連上主機在 shell 下執行命令者，至於只開放 sendmail 及 pop 或 imapd 供使用者收送 mail 時，也需注意其系統設定值，就算不是遭惡意破壞，也會常因使用者無心之過導致系統超載而 down，如 process、port、file_system 等系統資源。

四、PRI Server 之廠牌及功能

就使用者角度而言，若只提供 PPP 服務，採用何種廠牌之 PRI 設備並無差異；但若提供 Terminal_mode 方式，就另當別論了，因為各廠牌之使用者操作界面都不儘相同。而以管理者角度而言，在採購法之規範下（公家單位），無法指定廠牌之情況下，所訂之規格就需注意是否能夠提供充足之數據以供偵測、統計及分析，至於擷取的方式倒是可用程式的方式處理使其資料之一致性及完整性。以本校而言，雖目前有兩種不同之廠牌設備，但應用 UNIX 之 expect 軟體擷取再加上程式之整理，及統一之 RADIUS accounting 格式，這些問題是可迎刃而解的。

五、驗證及 DNS 主機之數量及架構

以數量而言，最好是能提供兩部以上之 RADIUS（含驗證及 accounting 伺服器）及 DNS 主機，因為一般 PRI 設備都可設定兩部以上的 RADIUS（含驗證及 accounting 伺服器）及 DNS，如此若 Master server down 時，Slave server 可馬上運作。而這三種 Server 之 Master 可集中在一部主機或是分散在兩部主機，其各有優點，一為管理方便，另一為負載分散，但以目前主機的執行速度而言，這倒不需花太大的心思去考量。以本校為例，提供了兩部 SUN Ultra 工作站來擔任，其伺服器分配如下：主機 A：Master_Auth、Slave_Accounting、Master_DNS 主機 B：Slave_Auth、Master_Accounting、Slave_DNS

參、撥接網路問題點之區分

撥接網路並不如一般以網路卡連上乙太網路般之穩定及傳輸速度快，所以需先了解整個撥接網路之架構及問題區之劃分，當問題發生時，能快速找出問題點及原因。以撥號網路連上 Internet，以使用者之觀點，可能感覺只是自己的 PC 及連上之主機兩部份而已，但以管理者之觀點，卻有很多的環節及區段，可將其劃分如圖（二）之問題區（括號內為責任區）： 1. 問題區<1>（使用者）：使用者之設備及軟體之穩定度，宅內線路之接法及其品質。 2. 問題區<2>（線路提供單位）：使用者端之局線品質及所經交換機之品質及數量，也影響了傳輸之品質及穩定度。 3. 問題區<3>（線路提供單位）：PRI 之局端之

PRI Server RADIUS_Server 交換設備 User 端 PRI 線路使用者連上之伺服器 R <1> <2> <3> <4> <5> <6> <7> 圖(二)PRI撥接網路問題區劃分圖

(4)

界面及線路之品質，如各 PRI 之 channel 正常否，或 T1 線路是否因雜訊或信號衰減而影響傳輸速率及穩定度。 4. 問題區<4>（撥接網路 Server 端）：PRI 設備是否正常穩定或因負載影響傳輸速率。 5. 問題區<5>（撥接網路 Server 端）：網路段及 Router 是否正常，是否流量過載。 6. 問題區<6>（撥接網路 Server 端）：驗證及 DNS server 是否正常運作。 7. 問題區<7>（連上的伺服器或該網路段負責單位）：連上之伺服器或該網路段正常否。 8. 其他問題：在使用者機器及 PRI server 兩者間尚有 PPP 層的問題，含 idle 逾時、封包錯誤或是由實線及其他異常狀況所引發的 PPP 異常，其控制由 LCP （Link Control protocol）來擔當[2]，所以擷取 LCP 之狀態，可了解兩端間 PPP 層 Link 之問題。不論問題區或責任區如何劃分，當使用者反映問題時，管理者有責任先給予研判及處理： 1. 經判斷是問題點是<1>，得指導使用者細部判斷及解決問題。 2. 經判斷是<2><3>或<7>時，則需協調或反應給其負責單位解決問題，處理過程中並需不時給予追蹤。 3. 經判斷是<4><5><6>時，更得儘速處理。

肆、管理方式及工具

本章主要是敘述如何應用各種方式及工具及擷取數據來達成最佳化管理的目標。其主要分成五個部份：一為數據之擷取、統計及分析，二為即時通報，三為帳號管理及管制措施，四為使用者教育及通報，五為設備及線路之維護。

一、數據之擷取、統計及分析

其方式為全程記錄(log)、定時監控，及將所擷取之資料做統計表，以達到分析、判斷及迅速解決問題之效果。而這些資訊取得方式可分為以下三種： 1. 直接參考 PRI 設備之 log_file。 2. 用擷取處理程式擷取 PRI 設備或 Router 之值。 3. 處理 RADIUS accounting 之數據。表(一)這些資訊是擷取較常用的數據，做較常用的運用，如統計圖表、記錄整理等。當然還有其他型式運用的呈現，而可擷取的種類也不只這些。這些資訊數據，最主要乃提供做為狀況的判斷，因為很多情況乃需多種數據來交互比較核對，以找出問題的真正原因，所以盡可能的擷取各種數據。資訊種類用途定時上線使用人數得知線路使用負載

PRI 設備負載得知 PRI server 之負載如 CPU 、memory

Channel 狀態判斷各 PRI channel 是否正常

連線速度使用者之連線速度之統計

網路段傳輸量得知網路段之傳輸量以判斷其負載

IP_port 之 ping_back 得知各使用者連線是否有傳輸延遲狀況

系統 Log 記錄 PRI server 系統異常狀況

accounting 記錄各 user 上／離線之各種數據使用者 log accounting 經整理壓縮，以便處理及查詢傳輸量統計各種傳輸量，含 PRI、設備、port、user 離線原因統計離線斷線原因驗證記錄主要記錄 user 簽入是否成功表(一)

(一)定時統計上線使用人數

此數據來源也可由 RADIUS 之 accounting log 得之，但其處理較為複雜，不過較正確。但目前只是要定時統計其線路使用量，故較簡單之方法即直接由 PRI server 取得，下例乃每半小時由自動偵測擷取程式取得。其記錄檔內容如下: 0007200000|246 0007200030|239 0007200100|243 而其格式為：年月日時分（yymmddMMHH）｜上線總數若將其資料以統計圖表方式顯示，將更有助於了解其負載曲線，如圖（三）例為某一日從早

(5)

上 6:00 至隔日 5:30 每半小時之線路使用率，以 12 個 PRI 276 個 channel 的使用量來統計，可明顯看出由 23:00~01:30 為使用之尖峰時間，而這統計表也可以一段期間其平均負載方式呈現。也可以其他期間統計方式呈現，如一週內固定時段負載曲線。

(二)PRI 設備負載

這數據可定時由 PRI server 擷取，當 PRI server 負載過高時，將會影響傳輸速率，更甚者將導致 PRI server Down。若將其預警條件加入「狀況即時通報系統」，則當 CPU 或記憶體負載在某一程度時，對管理者發出預警訊號，以便即時處理。如下例乃每半小時由自動偵測擷取程式取得其 CPU 負載量。其記錄檔內容如下 0007200030|52%:71%:31%:52%:47%:63%: 0007200100|48%,:53%:42%:25%:43%:30%: 0007200130|60%:61%:60%:56%:30%:60%: 其格式為：年月日時分（yymmddMMHH）｜第 1 個 PRI 設備之 CPU_free：第 2 個 PRI 設備之 CPU_free：…………

如圖(四)為系統 CPU 負載率和線路使用率之比較，雖其兩值並非成線性比，但在尖峰時間，系統負載也有明顯提升。

(三)Channel 狀態

T1 實線信號正常，並不代表 PRI 的 23 個 channel 也都能正常使用，一般以 PRI 設備的功能是無法偵測各 channel 正常否，但可擷取數據得此列表，以判斷是否持續一段時間都沒使用的 channel，這可能就有問題，可依此列表請線路提供單位處理。如下例乃每半小時由自動偵測擷取程式取得。其記錄檔內容如下： 0007200000|AAAAAAAAAAAAAAAAAAAAAAA,AA AIAAAAAAAAAAAAAAAAAAA:AAAAAAAAAAAA AAAAAAAAAAA,AAAAAAAAAAAAAAAAAAAAIA A: 其格式如下：年月日時分（yymmddMMHH）｜第 1 個 PRI 設備第 1 個 PRI channel 使用狀況，第 2 個 PRI channel 使用狀況：第 2 個 PRI 設備第 1 個 PRI channel 使用狀況，第 2 個 PRI channel 使用狀況：……

一個 PRI 有 23 個 channel 用 23 個字元來表示，”A”表示 active，”I”表示 idle

(四)連線速度

此資訊為定時擷取各 PRI server 之值，功用在定時統計上線者其連線速度（Line_speed）為何。如下例乃每半小時由自動偵測擷取程式取得。圖(五)為一日之連線速度統計比率圖。其記錄檔內容如下： 0007200000|0,6,6,6,4,0,0:0,14,13,8,8,0,1:0,16,16,4,7,2,0:0, 9,24,5,7,1,0:0,10,18,7,7,3,0:0,12,13,12,6,1,0: 其格式如下：年月日時分（yymmddMMHH）｜第 1 個 PRI 設備之連線速度：第 2 個 PRI 設備之連線速度：………. 其連線速度種類多，故將其分成 7 個範圍，其格式為：：64k，50k~60k，40k~50k，30k~40k，20k~30k，10k~20k， 10k 以下：（七個範圍，其中數字為其數量）

(五)網路段傳輸率

此資訊主要是了解網路段之傳輸率，以判斷是否負載過高；或是和其他傳輸量交叉比較，以 0% 20% 40% 60% 80% 100% 06 :0 0 07 :3 0 09 :0 0 10 :3 0 12 :0 0 13 :3 0 15 :0 0 16 :3 0 18 :0 0 19 :3 0 21 :0 0 22 :3 0 00 :0 0 01 :3 0 03 :0 0 04 :3 0 圖 (三 )線路使用率線路使用百分比 0% 20% 40% 60% 80% 100% 06 :0 0 07 :0 0 08 :0 0 09 :0 0 10 :0 0 11 :0 0 12 :0 0 13 :0 0 14 :0 0 15 :0 0 16 :0 0 17 :0 0 18 :0 0 19 :0 0 20 :0 0 21 :0 0 22 :0 0 23 :0 0 00 :0 0 01 :0 0 02 :0 0 03 :0 0 04 :0 0 05 :0 0 圖(四)線路使用/系統負載線路使用率系統負載率圖(五) 連線速度比率圖 40K~50K 39% 50K~60K 32% 64K(ISDN) 1% 10k以下 1% 30K~40K 17% 20K~30K 8% 10K~20K 2%

(6)

判斷該網路段是否有問題，數據乃擷取 router 最近 5 分鐘之傳輸量所得之傳輸率。若要統計網路段傳輸量，可整理第九項之「使用者 log」之數據得知。如下例乃每半小時由自動偵測擷取程式取得。如圖(六)例，為某一日之網路傳輸率，同樣的還是尖峰時間傳輸率最高。其記錄檔內容如下： 0007252330|99000,506000:77000,424000: 0007260000|127000,518000:91000,540000: 0007260030|73000,455000:101000,538000: 其格式如下：年月日時分（yymmddMMHH）｜第 1 個網路段 Input 傳輸量，第 1 個網路段 Output 傳輸量: 第 2 個網路段 Input 傳輸量，第 2 個網路段 Output 傳輸量

(六)IP_port 之 ping_back

此數據是由偵測主機 ping 使用中的 IP port，所以每天只利用尖峰時間作業一次，因為一來尖峰時間負載較大較能發現問題，二來使用比例較高較能測試較多 IP_port，因未使用中之 port 將無回應。如下例，此 IP_port 7/18 偵測結果 Lose 過高，而 7/20 回應太慢，有追查原因之必要。其記錄檔內容如下 000717:10:10:0%:149:161:178 000718:10:5:50%:309:363:431 000719:10:10:0%:143:160:176 000722:10:10:0%:5595:6093:6545 其格式如下：

年月日（yymmdd）:送出的 packet 量: 回應的 packet 量: 漏失的 packet 比率:回應的最快時間(ms):回應的平均時間(ms):回應的最慢時間(ms)

(七)系統 Log

之前偵測之所有狀況大都是半小時偵測一次，若以此來偵測 PRI server 或伺服器系統（如

UNIX 主機）狀況，難免會有漏失，例如 PRI server 或伺服器系統剛好在這半小時內出現狀況又回復。所以須主動的當系統有問題時（還不致系統 Down 時），它能記錄下來。UNIX 主機本身及部份 PRI server 就有此記錄功能，但 PRI 本身記憶體有限，故欲記錄 PRI server 一般作法是記錄在 UNIX 主機上。如下例記錄著 PRI server 之系統不正常狀況。

其記錄檔內容如下：

Jul 30 17:07:34 [140.116.28.252.2.2] (36825592) listener\liststat.c:WAN 0 loss of signal

Jul 30 17:07:34 [140.116.28.252.2.2] (36825792) listelast message repeated 2 times

Jul 30 17:07:37 [140.116.28.252.2.2] (36825831) listener\listsig.c:ERROR: IsdnErr CLOSEANCHOR

(八)Accounting

當 PRI server 及 RADIUS server 將其 accounting 之功能啟動，就會在 RADIUS 之 accounting Server 內記錄了使用者上線及離線之 log，這是一項很有用之資訊，其資料量龐大，但為了日後之統計及追查，管理者應儘可能的將其保留一段時間。也可將此數據給予壓縮、整理，如下節之「使用者 log」記錄。其每筆記錄都以日期及時間開頭，記錄與記錄之間隔為一空白行，其中有幾個較重要的欄位，其用途說明如下[3]： 1. Acct-Status-Type 使用者上線 start ，或離線 stop。 2. User-Name 使用者帳號。

3. NAS-IP-Address 使用者連上的 PRI Server。 4. Framed-IP-Address PRI Server assign 給使用者

的 IP_address。 5. Called-Station-Id 使用者撥至本端的號碼 6. Calling-Station-Id 使用者的電話號碼。 7. Acct-Input-Octets 上傳傳輸量（使用者端至 server）。 8. Acct-Output-Octets 下載傳輸量（server 至使用者端）。 9. Acct-Session-Time PPP 連線時間。 10. Acct-Input-Packets 上傳的封包數目（使用者端至 server）。 0 200000 400000 600000 800000 1000000 1200000 1400000 1600000 1800000 06 :0 0 07 :3 0 09 :0 0 10 :3 0 12 :0 0 13 :3 0 15 :0 0 16 :3 0 18 :0 0 19 :3 0 21 :0 0 22 :3 0 00 :0 0 01 :3 0 03 :0 0 04 :3 0 圖(六)網路傳輸率

(7)

至使用者端）。 12. Acct-Terminate-Cause 離線原因。如下例，是節錄其中一位使用者該次上線及離線之 log：上線記錄： Tue May 30 15:19:29 2000 Acct-Status-Type = Start Acct-Session-Id = 05200395 User-Name = a2485306 NAS-IP-Address = 140.116.28.250 NAS-Port = 19 Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 140.116.28.156 Acct-Delay-Time = 0 Acct-Authentic = RADIUS NAS-Port-Type = Async Called-Station-Id = 2767550 Calling-Station-Id = 063110444 離線記錄： Tue May 30 15:44:08 2000 Acct-Status-Type = Stop Acct-Session-Id = 05200395 User-Name = a2485306 NAS-IP-Address = 140.116.28.250 NAS-Port = 19 Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 140.116.28.156 Acct-Delay-Time = 0 Acct-Input-Octets = 165028 Acct-Output-Octets = 423953 Acct-Authentic = RADIUS Acct-Session-Time = 1487 Acct-Input-Packets = 2847 Acct-Output-Packets = 2388 Acct-Terminate-Cause = User-Request NAS-Port-Type = Async Called-Station-Id = 2767550 Calling-Station-Id = 063110444

(九)使用者 log

此資訊是將 accounting 經整理後只節錄有用之欄位．並將其上線及離線合併為一記錄，以便處理及查詢。例如查詢某個使用者之連線記錄，或是當使用者有犯罪或不當行為，事後追查時，不只有帳號、上線時間也有此撥入之電話號碼。另接下來統計處理比較方便，例如傳輸量、連線時間，或是有連線計費之 ISP 也可以使用時間作連線計費統計。其記錄檔內容如下： 000530,151929:000530,154408:a2485306:140.116.28.156 :140.116.28.250:165028:423953:1487:User-Request:0631 10444 其格式如下：上線日期 yymmdd，上線時間：離線日期 yymmdd，離線時間：使用者帳號：PRI assing 之 IP:PRI server 之 IP:Upload:Download:使用時間：離線原因：使用者撥來之號碼 (十)傳輸量此資訊是由「使用者 log」數據加以整理，主要是統計各種傳輸量如 PRI 線路、PRI 設備、 port、user，或和某期間配合，而這統計主要是參考用，以便增加或調整線路或設備之依據，或是跟其他資訊配合，而找出問題之原因。如圖(七) 為節錄某一日 PRI 設備傳輸量。

(十一)離線原因

此表主要是統計離線原因，而數據來源為是「使用者 log」，主要用途可統計非正常離線原因。例如由每日之差異，可判斷出是否因天候影響線路品質而導致斷線，或是其他線路不穩定原因引起。其主要有三種狀況： 1. User-Request：使用者正常離線。 2. Lost-Carrier：因斷線而離線，但是若使用者結束連線前，先將 modem 關掉也是此狀況。 3. Idle-Timeout：使用者閒置過久而遭斷線。另需特別注意的是一些較少出現的特殊狀況，如 NAS-Error、Lost-Service、Post-Error、 Service- Unavailable 等等，這都有必要去追查原因。圖(八)為某一天離線原因統計比率圖： 0 250000000 500000000 750000000 1000000000 1250000000 1500000000 1750000000 2000000000

PRI1 PRI2 PRI3 PRI4 PRI5 PRI6 PRI7

圖(七)PRI設備傳輸量圖(八)離線原因比率 User-Request 81% Idle-Timeout 1% Lost-Carrier 18%

(8)

二、狀況即時通報系統

當定時擷取之數據、或其系統產生之 log，在事後之分析判斷及追查問題原因非常有用，但要達到能主動發覺及偵測問題，就要有一套自動即時通報的系統。因為撥接網路管理者不可能時時刻刻盯著 PRI 設備面板或連上 PRI server 看其系統是否有異常，所以有一套能自動偵測及通報系統，當系統有問題時能即時通知管理者，將使因故障影響使用者的時間減至最低。這系統可和上述之定時自動偵測擷取程式配合，也可以另一個程式來處理，但最好是以另一個程式處理，其原因為： 1. 上述之自動偵測擷取程式間隔較長，且處理時間也較長，但縮短間隔時其值變化小。 2. 因所要偵測之產生值較少、簡易，執行時間也較短，故可以另一程式來定時處理，而其時間間隔關係著通報狀況之快慢，故將其設為 5 分鐘。而其能偵測的範圍有： 1. PRI 線路 down。 2. PRI Server down。 3. 網路 down。

4. RADIUS Server or DNS down。

這是將各種擷取偵測之數據，給予須通報之狀況條件，若合乎通報之條件，則將其呼叫器號碼加上狀況代碼以 kermit 控制 modem 撥號，以即時通知管理者知其狀況，使得能馬上處理狀況，而將故障時間減至最低。這作法很簡單，只要 expect 軟體和所寫的 script，及 kermit 軟體和一個 modem、電話線路及呼叫器就可達成，其架構及流程如圖(九)：

三、帳號管理及管制措施

帳號管理須依環境及架構而規劃其作業模式，例如使用者及設備之多寡、書面作業之程序，服務之項目等。其主要作業是帳號的建立、異動及查詢。帳號資料庫型態也以使用者多寡及服務型態可來決定，如下：

1. 帳號直接建立在 PRI server 內：若 PRI server 及使用者不多（少於 100 人），可直接建在 PRI server 之記憶體內即可，但確記要保留書面資料，因為 PRI server 有可能故障而導致該帳號資料庫遺失。 2. 和 mail_server 共用帳號資料庫：若同時提供 mail 帳號，兩者可共用 UNIX 主機上之帳號資料庫，而其帳號之建立及異動，直接用 UNIX 系統上的帳號公用程式即可，或是另寫建立及異動之帳號管理界面來更改帳號資料庫內容。 3. 獨立的撥接帳號系統：本校目前所採用的方式，不過因使用者無法直接去更改密碼，故密碼之更改須有書面的行政程序，或是寫一個使用者界面讓使用者能 on_line 更改密碼及查詢。因為目前駭客橫行，及帳號外借情形嚴重，故得時常宣示使用者有保護自己帳號的義務，密碼不要設的太簡單，及不要將帳號外借等。管制之主要目的乃是能將可用之資源，充分的給予所需要的使用者，以目前本校之使用狀況為例，帳號外借的情形很嚴重，而這也影響到了有權力使用者上線的權益。而一般管制措施有下列幾種： 1. 一 user 同時只能使用一連線：當使用者上線在作認證時，認證系統須先核對此帳號是否已在連線，若是則拒絕其登入。但是這得另寫程式或購買廠商發展出來之認證及帳號管理軟體。 2. 管制同一帳號 multi_login：目前本校之管制措施尚延續舊系統之方式，即 PRI Server Router kermit 偵測程式局端呼叫器用 cron每 5分鐘自動執行之 expect 撥號及送出代碼偵測各種狀況 Server 通報系統主機之程式

(9)

系統定時去偵測是否有一個帳號多線在使用，若是，則將其帳號給予暫停使用，而其本人須親自前來更改密碼。但卻衍生了一個問題，當使用者電話有申請插撥功能時，若使用時未將插撥功能取消，在連線時有別人插撥時，將導致連線中斷，當然使用者的反應就是再連上，但殊不知上一個連線因插撥保留的關係，載波還是送給此處設備，若剛好是在系統 check multi_login 時，那其帳號也會被暫停使用。 3. 限制上線時間：直接在 PRI server 設每次最長連線時間。 4. 以 caller-ID 管制使用者只能用其登錄之號碼撥上：可管制某個 user 只能用某個或某些特定的號碼撥入，如此可防止帳號外借之情況，但需有四個基本前提： (1). 建立／異動帳號系統須有使用者欲撥入之電話號碼，且申請及異動時須使用者本人或直系親屬之電話帳單供認證。 (2). Radius server 之 user_passwd file 或資

料庫需有使用者之電話號碼欄。

(3). Radius 之 source 須改寫，以能在 check 帳號密碼時也比對 Calling-Station-Id 欄和資料庫之號碼是否相同，若不同則回應 Reject 信號給予設備，使其無法登入。 (4). 使用者撥號時，必須設定送出電話號碼，否則拒絕登入。 5. 管制已有其他上網管道者使用撥接網路，如本校住宿生已有宿網，不得申請撥接帳號。以上這幾種管制方式可視環境架構、政策及效能而定，可個別使用或多種配合使用，不過以使用者連線時間收費之 ISP 就無管制帳號外借之必要。

四、使用者教育及通報

除了由管理者應用管理工具得知問題外，另外一個很重要的管道就是使用者申告的問題了，就以大部份使用者申告的問題如下： 1. 連線使用中斷線。 2. 帳號密碼錯誤。 3. PPP negotiation 不成功（以 Windows 為例，其訊息是撥接伺服器沒回應） 4. 連不上 Internet 伺服器或無法使用 domain_name。 5. 無法撥號或是數據機無回應。 6. 不會設定或使用。 7. 連線速度比平常慢或傳輸中會暫停。 8. 忙線無法撥通。而這些問題之原因層面很廣，問題產生點可能是 server 端、線路提供機構、使用者端或所連上之網路主機段之一，而許多問題之產生及責任卻是在於使用者端及其認知不夠。管理者都有這經驗，使用者所申告之問題，常因使用者誤判或是所提供的資訊不足，而往往不知從何下手及處理，所以使用者的教育及通報資訊完整化，就成為一個很重要的課題，而主要有下列三項： 1. 教導使用者如何避免問題產生：教導其設定、安裝、使用及宅內線配置，唯有在一個穩定的環境下，發生問題的機率才會降低。而這可由定時發技術通告、開訓練課程、在網路上張貼使用說明、諮詢服務來達成。 2. 教導使用者當問題產生時如何判斷：當問題產生時，因管理者不太可能去使用者之環境中測試，所以教導其判別問題來找出原因及如何處理以排除問題。而這可由定時發技術通告、開訓練課程、在網路上張貼使用說明、諮詢服務來達成。 3. 使用者無法解決問題時，如何反映（提供給管理者或諮詢者之資訊）：為避免因使用者誤判及提供資訊之不足，導致管理者無法處理或處理方向錯誤，有必要讓使用者配合使其提供資訊格式化及完整性，不管是以電話諮詢、親自前來、mail 或 BBS 張貼

(10)

方式反映問題，而一般需使用者提供下列資訊： (1). 連絡方式：不要只是丟個問題，而無法連絡，以致不能後續處理。 (2). 連線狀況及出現之訊息：詳述從開始到遇到問題時的所有操作步驟及出現之錯誤訊息。 (3). 自行判斷的原因：供管理者參考用，使用者若判斷錯誤，可馬上教導正確的判斷及處理。

(4). 使用時間及 PRI server assign 的 IP：以便由 Log 及 PRI 設備來查原因。 (5). 若 PPP 已連上，連到何處的 Inetrnet 伺服器，及所設定之網路組態。

五、設備及線路維護

設備之維護方面，一般都有保固期或和廠商簽維護合約，所以當狀況產生時，若能判斷是設備之問題，很單純的就 call 廠商前來處理。至於如何判斷及得知設備狀況，就是多利用上兩節所提之定時偵測擷取程式及狀況即時通報系統了。但是當原因未明時（在 PRI 層以下），管理者常有此困擾，就是介於設備廠商及線路提供機構中間，兩者各說各話，沒有一個交集，以致管理者感覺這兩者互踢皮球，將責任推給對方。所以管理者唯有加強本身之專業能力，對於兩者之領域有所涉略，如此當問題產生時，可以專業能力來判斷問題出在何處，並能做一個仲裁者。目前 PRI 線路提供單位為中華電信，但因不像傳統線路般的單純可用電表或電話機判斷線路正常與否。若是單純的實體線路故障，是可由設備面板或是由 PRI server 所擷取之監控資料得知，但因 PRI 之特性，有些狀況是偵測及處理上較為棘手的，以本校 PRI 線路曾發生的的三個案例： 1. 某線群之其中的一個 PRI 皆無法撥接上使用。 2. PRI 中的某些 channel 無法撥上使用。 3. 中華電信測試 T1 線路異常，但本端設備並無警示信號。因此以 PRI 之特性而言，管理者常有以下之困擾： 1. PRI Server 是否有能力偵測出所有的線路問題，例如雜訊、信號衰減等，或 PRI 內之 channel 分配、信號或是協定是否異常。 2. 存在著無法判斷之區域，當問題產生時，較難以判斷或由測試方式斷定問題產生點，故常無法對 User 反映之問題作確實之回應。 3. 各種廠牌之 PRI 設備其管理介面、操作及其提供之資訊皆不相同，導致即時監控操作費時費力，無法取得較基本層之資訊。對線路之即時監控只有單純由面板顯示 Up/Down 4. 向線路提供機構（目前是中華電信）反映時，常因數據不足而不了了之。所以就以線路檢測及設備維護角度而言，有三個方式來處理： 1. 和線路提供單位（目前是中華電信）及設備廠商之技術人員保持良好互動，及技術的交流，唯有在兩者領域重疊性愈大時，才愈能了解彼此的情況，如此處理問題來方能事半功倍。 2. 落實定時檢測及判斷之作業，很多狀況，可由所擷取的資訊加以研判，進而找出問題點及原因何在，而這有賴於多擷取各點之數據，並不時觀察及研判。擷取了一大堆數據而不去判讀，也是無濟於事。發展一個 PRI 線路監控系統來即時監控 PRI 線路狀況，如圖(十)，其功能為： (1). 明確判斷是否為 PRI 線路或其 channel 之問題，有助於釐清問題點之所在。 (2). 全程記錄及統計線路狀況，以便問題產生時有確實數據與線路提供機構協商。 (3). 處理後為即時之資訊，可達到即時監控之效果。 (4). 由實體層擷取資料數據，為一致格式，不

(11)

需去考量 PRI 設備異同及數量，可同時顯示所有 PRI 設備之所有 channel 之狀況。 (5). 由圖形介面輸出，可使管理者快速、方便即時監看以便儘速處理，尤其是多線路及多設備之環境。 (6). 圖型介面及資料庫以 windows 方式處理，可使管理者不需在 Server 之 Console 操作。

伍、結論

對網路管理者而言，找出問題點，常比解決此問題花更多的心力，而對於非「常態」環境的撥接網路更有深切之體認，因它不如一般網路來的穩定，架構上又更複雜，且問題點又不易釐清。PRI 線路雖因其為數位線路，理論上應有良好之穩定度，但本校在設置初期（前六個月），使用者之一般反應比原有 33.6K 線路還差，但逐漸的將管理機制建立起來後，使用者的抱怨減少了，因線路故障而停滯時間及數量也顯著減少很多；而資訊的整理統計，不但能讓使用者了解許多狀況非本端之過，更能讓決策階層知道撥接網路的實際效能。故如何釐清問題點、及早發現問題並處理與有效率的管理，就有賴於一個良好的管理機制。以筆者之經驗，撥接網路的管理不似一般主機或網路的管理較有其一定的模式與工具，所以唯有利用各種可應用的方式及工具，雖這將會使管理的工作變得繁複，但將這些方式及工具加以規劃成系統化、自動化，如此方能得到事半功倍的效果。所以唯有多運用可用之資訊，並以主動面對問題的精神．方能使撥接網路達到最高的穩定度及效率，而不是無奈的認為撥接本就是一個不穩定的環境。

陸、參考文獻

[1]Patton Electronic Company ,“2800 Series Remote Access Server(RAS)”,7/27/98

[2]William Allen Simpson ,“RFC-1331：The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links”,May 1992

[3] C. Rigney. , “ RFC-2139 ： RADIUS Accounting ”,April 1997

[4]Andrew Sun ,”Using & Managing PPP”,Jan 2000 PRI Server PRI Server 信號擷取器 RADIUS Server 監控系統 Server 監控系統 Client 圖(十)PRI線路監控系統 PRI PRI Ehternet