1、在計算機網絡中，交換概念的提出是對傳統共享工作模式的改進。如集線器（Hub） 是一種物理層共享設備，Hub本身不能識別數據包的目的地址，當集線器接收到 數據包時，它以廣播的方式播送到各個端口，由每一臺主機通過驗證數據包的目 的地址來決定是否接收。如圖1所示。交換機（Switch）是一種數據鏈路層設備，它的內部程序可以檢查收到的數 據包的目的地址，并從內存中的MAC地址表中查得目的設備所在的端口，通過內 部交換機構迅速將數據包傳送到目的端口。只有當目的MAC不存在時，才將數據 廣播到所有端口。如圖2所示。Switch圖1共享式局域網圖2交換式局域網、MAC地址表MAC地址表是交換的基礎，由于它來

2、源于網橋，所以又稱網橋表。它用來記 錄各個設備是連接在交換機的哪個端口上的，這樣，當交換機收到數據包后，才 能夠決定應該向何處轉發。如圖3所示。MAC地址端口號A181C2D2E2F3G3圖3 MAC地址表為了看得清楚，在圖中我把MAC地址用主機的符號代替了，實際的MAC地址 是一個48位二進制數。1、交換機的轉發過程交換機收到一個數據幀時，查MAC地址表，如果目的端與源端不在一個端口 上，則把幀從目的端口轉發出去；如果目的端與源端在同一端口，說明該幀無需 轉發，則丟棄該幀。如A主機向D主機發送數據，當數據幀到達交換機時，它在MAC地址表中查 找主機D的MAC地址，發現它所在端口號為2,而數據

3、來源的端口號為1，則交 換機將數據幀從端口 2轉發出去。再如A主機向B主機發送數據，交換機查看 MAC地址表后發現源和目的在同一端口上，說明該幀已經通過其它路徑到達了 B 主機，不需轉發，故此丟棄該幀。2、MAC地址表的構建過程MAC地址表存放在交換機的內存之中，在最初時，它完全是空的，交換機是 通過自學習過程在工作中自動構建MAC地址表的，這個過程無需人工干預。每當交換機收到一個數據幀時，先在MAC地址表中查找源地址，如果沒有找 到，則把它及所在的端口記錄在MAC地址表中。再查找目的地址，如果有，則轉 發或丟棄，如果沒有，則廣播到所有端口。這樣，交換機在工作過程中就把MAC地址表逐漸建立起來

4、了。只要一個工作 站發送過數據，它所對應的端口就會被記錄下來，供今后轉發時使用。3、MAC地址表的維護MAC地址表的維護也由交換機自動進行。交換機會定期掃描MAC地址表，發 現在一定時間內（默認為300秒）沒有出現的MAC地址，就把它從MAC地址表中 刪除。這樣即便發生了工作站的移動、拆除等問題，交換機始終能把握網絡最新 的拓撲結構。4、MAC地址表的容量MAC地址表的容量用可存儲的MAC地址數表示，是交換機的一項參數。一般 的交換機可存儲1024個以上的MAC地址，這對于一般網絡就夠用了，如果網絡 規模很大，選購交換機時應注意一下它可存儲的MAC地址數。例：網絡拓撲和某時刻MAC地址表情況如

5、圖4所示，當依次出現如下各種傳 輸時，交換機是如何處理的？ MAC地址表如何變化？MAC地址端口號D2B1圖4A向D發送幀；C向D發送幀；D向F發送幀；A向B發送幀。解：A向D發送幀：在MAC地址表中查找A的MAC地址，沒有找到，把A 的MAC地址與所在端口號1添加到MAC地址表中；在MAC地址表中查找D的MAC 地址，找到端口號為2，與源端口不同，則從端口 2轉發數據。C向D發送幀：在MAC地址表中查找C的MAC地址，沒有找到，把C的 MAC地址與所在端口號2添加到MAC地址表中；在MAC地址表中查找D的MAC地 址，找到端口號為2，與源端口相同，則丟棄數據包。D向F發送幀：在MAC地址表中

6、查找D的MAC地址，找到端口號為2；在 MAC地址表中查找F的MAC地址，沒有找到，則把數據包廣播到各端口。A向B發送幀：在MAC地址表中查找A的MAC地址，找到端口號為1；在 MAC地址表中查找B的MAC地址，找到端口號也為1，兩端口相同，則丟棄數據 包。完成后，MAC地址表為：MAC地址端口號D2B1A1C2圖5二、交換機的交換方式交換機通常有3種交換方式。1、直通式(Cut Through)：當輸入端口檢測到一個數據包時，就檢查該包的包頭，根據包內的目的地址 把數據包直通到相應端口。優點：這種方式不需要等數據包接收完就開始轉發，交換速度快，延遲非常 小。缺點：不提供錯誤檢測服務，有可能將

7、出錯的數據包轉發出去。也不提供緩 存，不能將速率不同的端口直接接通，而且容易丟包。2、存儲轉發式(Store & Forward)：這種方式先將數據包完整的接收下來，經過CRC檢查，如果數據包沒有錯誤， 再根據地址進行轉發。優點：提供錯誤檢測服務，改善了網絡性能。支持速度不同的端口的轉發服 務，可以保證高速端口與低速端口間協同工作。缺點：傳輸延時較大，而且需要較大的緩存容量。3、碎片隔離式(Fragment Free)：它檢查數據包的長度是否夠64個字節，若小于64字節，說明是廢包，進行 丟棄，若大于64字節，則發送該包。這種方式可保證碰撞碎片不在網絡中傳播，提高了網絡效率，它的數據處理 速度

8、介于直通式和存儲轉發式之間。多用于低端交換機產品。低端交換機產品一般只具有一種交換方式，有些高端交換機產品具有兩種交 換方式，并且可以根據網絡環境自動選擇交換方式。三、交換機的工作模式1、半雙工模式（Half duplex）：在一個端口上，同一時刻只能發送數據或接收數據。也即發送和接收不能同 時進行。2、全雙工模式（Full duplex）：在一個端口上，同一時刻可同時進行數據的發送和接收。交換機與設備之間一般是用雙絞線或光纖進行連接的；雙絞線一般有8根線 芯，2根用于發送數據，2根用于接收數據；光纖一般也是采用多芯光纖，有的 用于發送，有的用于接收。所以，從理論上講網絡具有全雙工傳送的能力。

9、但在 共享式網絡中，發送數據時，主機還必須監聽碰撞信號，所以共享式網絡只能工 作在半雙工模式；而交換式網絡采用點對點的通信，不需要再監聽碰撞信號，所 以才能工作于全雙工模式，如圖6所示。全雙工模式相當于將網絡帶寬提高了一 倍。圖6集線器的半雙工工作方式和交換機的全雙工工作方式第五章案例分析：故障案例分析一：駐馬店市區劉閣基站（DE34）TRX2有7533告警（TX ANTENNA OR CONBINER CONNECTION FAULTY）由于連接在同一個合路器上的 TRX1 工作正常，初步判斷AFEA沒有故障，TX連線緊固，則判斷可能是TRX壞或 者TX連線壞，更換TRX后故障解除。但是到3

10、月9號，TRX2再次出現7533 告警，由于TRX為新換的，TX連線無故障，分析認為合路器AFEA不穩定， 存在隱患，更換AFE后故障解除，沒有重復出現。故障案例分析二：西平人和基站（DE34）BCFA故障，更換后無法自啟，檢查發現軟件包不 對應（使用的板件是返修的庫存板件，沒有考慮軟件包問題），灌入對應軟件包 重啟后，Sec2和Sec3無法正常工作，其中Sec2的TRX7正常，而TRX8和Sec3 的 TRX9 和 TRX10 均有 7514 告警（13MHZ CLOCK IS MISSING IN TRX)按照Nokia告警處理提示應更換TRX,但三塊TRX同時壞的可能性不大， 考慮可能為

11、其他原因引起。于是將Sec2正常運行的TRX7和出故障的TRX8倒 換位置，(操作過程中對該層PSUA斷電)結果Sec2兩塊TRX均恢復正常。于 是將Sec3的PSUA斷電再加電，該扇區亦恢復正常。分析認為有時TRX內部軟 件需要重新掉電初始化。這一點和后來改半速率過程中，有些DE34站雖然數據 與BSC完全對應，仍然出現OMU信令不活的現象類似，出現這種情況時，對 基站供電單元CSUA掉電再加電就可以解決。故障案例分析三：遂平紅堂基站(UltraSite)O改S后，Sec1 一直占不上用戶，且有7602 (Mismatch between BSC/MMI configuration file

12、 and the actual)告警，經檢查發 現，硬件數據庫中Sec1的數據不完整，補充完整后再上傳進去，重啟BCF，故 障解除。故障案例分析四：婦幼保健院(ULTRASITE)斷站，且斷站時有7606告警，告警提示為合路 器反射功率過高。根據以往經驗，產生這個告警的原因有兩種，駐波比過高或合 路器壞，測試駐波比正常，更換合路器重起基站后告警消失，后期觀察沒有再出 現這個告警。故障案例分析五：市區 502 基站(ULTRASITE)的 SEC3 反復閃斷，有 7705, 7706, 7723, 8102 等告警。到基站后發現傳輸板時而亮黃燈，時而亮綠燈，并且掉話非常明顯。因 為有傳輸告警，所

13、以先從傳輸板、傳輸連接件和傳輸線考慮。自環傳輸板正常， 檢查DDF架。結果發現DDF架的2M接頭松動，緊固后傳輸板沒有再出現間歇性 閃爍，基站正常運行。故障案例分析六：駐馬店市區關王廟基站(UltraSite)的Sec2反復出現7604告警(Rx levels differ too much between main and diversity antennas)，造成嚴重掉話。測量天線駐 波比正常，更換寬帶合路器WCGA和雙工器DVGA仍不能解決，對基站主設備 徹底檢測確定正常，檢查天饋部分，發現饋線進入機房后的接頭處松動，重做接 頭并緊固后告警消除。對此故障分析認為，有時天饋系統的駐波比正

14、常，并不能 說明故障一定不是出在天饋系統。有些并不嚴重的連接松動情況可能無法在駐波 比中顯示。因此在處理這類故障的時候，測量天饋系統的參數只是判斷故障的一 個參考，還需要對連接部分進行仔細的檢查。故障案例分析七：西平后呂基站(DE34)白天更改硬件，加載頻，數據更改完之后，夜間重 啟后無法起站。經現場檢查，發現硬件數據庫中的TRXSIG速率不對，更改后 恢復正常。據機務員改動數據的過程，發現一個平時沒有特別注意到的一個細節 問題。DE34基站在在硬件數據庫上改動TRX的位置或者添加、刪除TRX時， TRXSIG速率會自動更改為全速率數據及16K，故需要手動更改為半速率數據 32K之后再上傳。故

15、障案例分析八：確山、泌陽割接故障處理：割接之后以下基站不能起站：泌陽白果樹、泌陽梅林、泌陽條山、泌陽老 邱洼、確山桐樹園。現象都是OMU信令不活。故障處理：泌陽梅林一從基站環路，SXC上ET燈熄滅；斷開，入信號丟失燈亮；放通，ET 燈熄滅。即，看起來，基站到SXC線路正常。機房確認BSC到SXC正常，交 叉連接數據也正確。機房和基站對OMU信令時隙一致，看起來，線路和數據都 正常，懷疑起不來是基站吊死或數據丟失。但是機務員冷起過基站，重做過數據， 重做過開通，信令還是不活。而且基站作模擬開通，基站能夠起得來，說明基站 主設備沒有問題。現在故障只能定位到物理線路上了，于是聯系傳輸機房改落地 DD

16、F架位置，之后信令活，起站正常。而之后，在處理白果樹基站故障時，發 現白果樹從基站落地DDF架到SXC環路不正常，這是環原梅林落地，兩個ET 燈同時熄滅。原來梅林和白果樹SXC交叉機側DDF架線鴛鴦所致。泌陽條山一該站有2個機柜，2條傳輸，第一個機柜OMU信令在7、8時隙，第 二個機柜OMU信令在1、2時隙。當晚看到OMU信令不活，懷疑是2個傳輸 弄反，于是改了 SXC數據，結果還是不活。待上午，機務員到站上環路發現， 后來的連接是錯的，又改回之前的連接，信令活。本人認為可能是傳輸設備吊死， 到基站環路相當于重新激活一下。泌陽老邱洼一根據之上的處理經驗，我們先查傳輸線是否鴛鴦，結果發現是落地

17、線鴛鴦。故障案例分析九：泌陽秦老莊邊改宏后基站不能正常工作。到基站后從表面看BCFA亮紅燈， TRUA指示燈正常。對基站自身重啟后出現7829（A-BIS及D-BUS接口連接失 敗）告警，分別更換BCFA板及后備板BUS線但告警依舊。然后考慮可能是BCF 無法控制到的TRUA單元存在問題，更換TRUA后重啟告警消失，基站恢復正 常。故障案例分析十：汝南綜合樓SEC3所有載頻均出現7745告警，掉話嚴重，并且有7601告警， 到基站后經過檢查發現時鐘偏移嚴重，更改時鐘DAC數模轉換值，將13MHz 時鐘調整到誤差允許范圍內，重啟BCF后正常，可不久又再次出現時鐘偏移現 象。檢查數據發現是由于沒有

18、設置傳輸板的時鐘同步造成的，（汝南機務員在前 一天處理8150告警時更換了傳輸板）。設置傳輸同步并重作開通后基站恢復。對 此故障的處理反映出一個問題，就是我們在更換基站的板件時，一定要注意對此 板件的配置，還要注意更換板件是否對其他板件的配置產生影響。基站系統是一 個整體，要注意板件之間的關聯，這樣才能使整個系統運行正常。與此類似的故 障還有一例：汝南陶橋（DE34）新開基站，開站時傳輸板一直亮黃燈，信令不活。 檢查數據庫、分支表、BCF接口設置都正確。因此考慮傳輸原因，從DDF架直 接環到交換機房的ET，狀態正常，對基站自環傳輸板亮黃燈，初步判斷可能是 傳輸板故障，更換傳輸板后情況相同。最后

19、注意到兩個傳輸板都比較新，考慮可 能是傳輸板沒有格式化。于是對傳輸板進行格式化，重新配置分支表并激活，傳 輸板恢復正常。分析認為：隨著DE34數量越來越少，傳輸板大多是舊板返修過的，一般不用進行格式化。但如果是全新的板子，就需要對其進行格式化之后再 配置數據。故障案例分析十一：泌陽消防隊(UltraSite)O改S后基站沒有告警但是一直起不來，只有Sec3 有兩塊載頻能起來。到現場檢查基站數據完整，比較發現，能起來的載頻基帶部 分為BB2A，其余載頻基帶部分均為BB2F，于是懷疑BSC軟件包版本偏低，與 交換機房交流證實了是軟件版本原因，機房更換高版本軟件包后重啟，基站恢復 正常。此故障說明，

20、我們在處理故障時一定要注意到細節的問題，善于比較和分 析，這樣對一些雖然有故障卻并沒有相關告警提示的障礙才能做出快速準確的判 斷。故障案例分析十二：市區劉閣基站(ULTRA)擴容，與機房聯系后知道TRX8位置為空位，到 基站后加上載頻，把相應的數據庫和分支表做全后，重啟基站，發現第 TRX8 一直不能被BOIA識別，重新檢查軟件和硬件確認無誤后，故障依然存在，和 TRX6調換后，該載頻在TRX6位置可以被識別，TRX8位置的載頻仍然不能被 識別。建到第10塊空位置后，也不能被識別，因此判斷是下面六塊的公共部分。 使用的是DVGA和WCGA，檢查電源BUS線并更換后，故障依然存在，檢查 從主控層

21、到下面兩層的BUS線，發現連接下層載頻的BUS線斷裂松動，重新緊 固后重啟，基站恢復正常。故障案例分析十三：汝南陶橋(DE34)斷站，O3配置,合路器用的是RTC，起站過程中BCCH信 令在TRX1,TRX2,TRX3上來回跳躍，基站起來后隨即中斷，且有7842關于合路 器的告警，更換RTCC后重起告警消失，基站恢復正常。故障案例分析十四：西平南王莊(UltraSite)新開基站，開站后機房通知SEC2，3占不上用戶，且 沒有和設備相關的告警。到站后檢查發現BIOA中沒有硬件數據庫數據，重做數 據庫并上載后基站正常工作。分析原因可能是灌完數據庫后沒檢查，而數據庫又 沒有正常灌入；另外一種可能是

22、NOKIA工程師做數據庫時用的Nokia BTS Manager是4.0版本，由于配套設備不同步，沒能及時開站，后來開站時對基站 做開通所用的Nokia BTS Manager是3.3.3版本，這種情況下會導致數據庫丟失。 故障案例分析十五：市區農行基站(MetroSite)傳輸板出現故障，經常閃段，需要更換傳輸板， 可BTS Manager 一直連接不到基站，測量連接線正常，檢查電腦com 口也正常， 后來在File項下Options子項中把com 口的連接速率從115200改為9600，順利 連接到基站。如下圖所示：后來市區新華書店基站(ConnectSite)也出現連接不上故障，修改連接

23、速率后便 順利連上。故障案例分析十六：駐馬店市區工行產生7601 BCF OPERATION DEGRADED 告警和7607 Fault in the chain between power unit and MHA告警，到站后發現告警情況如下圖 示：| Ced它 丁珈色| Emvt : D.iptig6 6 6 6 4 T T 779 60|60|6(|&(|6(|印:601即知&040! 7TT7 7 77 T 77777 3*Jq*J3tjdtjJ M M M M M M M M M M MaOA4AMinor 7801Critical 76002007-01-25 23:06. .

24、Start200T-01-25 23:06. . Start20D7-01-25 23:06. . Start2007-01-25 23:Q6.Stsrt200T-01-25 23:06. . Start2007-01-25 23:06. . Start200T-01-25 23;OS. . St-t2007-01-25 23:05, . Stert2IXIT-01-25 23:05. . Stfcrt2MT-Q1-25 23： 06. . B Stirt2M7-01-25 23:OS. Stwt2M7-01-25 23:06. . Start2M7-01-25 23:06. . Start2

25、007=01=25 23:06. . StartMMI CONMECTED TO BASE STWIOHECF FAULTY： Fault in the TEX FAULTY： Fault in the TKX FAULTY: Fault in th色 TBX FAULTY： Fault m the TRX FAULTY Fault in 而TRX FAULTY Fault in 加ch&in between pwer chain b-etween power chain b-etween power chain between pflwer chin b#t*en powtr chin bt

26、wfltn pw*aruni t aid MHA. unit and MHA. uni I and MHA. uni t and MHA wi t and MHA uni t and MHABCF OPERATION DEGRADED; TEI OFEBATIOH DEGR皿D： TRI OFERATIOH DEGRADED: TRI OFERATIOH DEGRADED： TSI OPERATION DEGSADEik TEX OPEBATIOH DEGRADE加 EXTEMAL ALAJal 9:Ffciilt ifi tb FMt m th*F誰t in th F*.ult in tk Fault in th Fault inchtinp心宣Bitchtin皿itchain between powtr uni t eht k n beiLwen. powr uni t ekai n between powtr mik t ehikn between power w.i tg MM. g MKA. u