Ethernet 全雙工
http://www.techbang.com/posts/15880-4-introduction-to-network-architecture-networks-underlying-frame-relay-rule?page=2 以前在學網路概論的時候,總是會從ISO/OSI七層架構開始學起,Physical、Data Link、 Network、Transport、Session、Presentation、Application Layer;而在網路維運除錯的領域中,遇到網路障礙時,處理的思考邏輯也是與OSI/ISO的七層順序一致的,透過七層觀念與實務經驗,診斷出可能的障礙原因,並一一予以確認,以找出真正的障礙原因,才有辦法予以修復,以恢復網路的正常運作。 |
在所有的網路障礙事件中,扣除“變慢”與“設定錯誤”這兩個大項之外,那餘下的網路事件,將大都會與「現場分析」這個範籌有關;這也意謂者網路人員得親自或藉由遠端搖控的方式,事件現場去一趟,以便收集足夠資訊,找出主因,解決問題。以下將針對常見的現場障礙,分述如下:
|
一.實體層(Physical Layer)問題:
|
|
二.連結層(Data Link Layer)問題:
|
|
乙太網路常見障礙:
■ Speed Mismatch: 當網路設備連結時,常見的無法連結原因之一,除了網路線 不通之外,也極可能是因為Auto Negotiation時,交涉錯誤導致雙方得到了不匹 配的網路連結速度;雖然Link亮綠燈,但仍無法連線。 ■ Pair Mismatch: 當網路設備連結時,兩端的連結信號(Link Pulse)均來自於同一對線(Tx-Tx) 而導致無法成功連線(正常情況下應是Rx-Tx, Tx-Rx)。常肇因於使用到CrossOver的網 路線;通常可藉測線工具偵測,或使用具有Auto MDI/MDI-X功能的網路設備來預防。 (具有Auto MDI/MDI-X功能的設備, 可自動測試使用1,2或3,6線對來做接收或傳送工作) MDI-X : Medium Dependent Interface - Crossover ■ Level Low: 當網路連結信號太弱時,可能產生封包無法判讀;或100Mbps降速至10Mbps ;或網路連線斷斷續續等現象。常肇因於設備問題或網路線衰減過大所導致。 通常可藉由網路儀器偵測,或在佈線工程完成後要求纜線驗證來確保施工品質。 ■ Transmit Pair Open: 當兩設備透過網路線連結時,因為1,2或3,6中任一線斷線(也稱"開路" 或OPEN);而導致無法連線。常發生於外力損害(如在老舊建物中遭老鼠咬斷)或網路 線路壓接失敗所導致。通常可藉由纜線測試器定位出斷線位置以排除障礙。 ■ Polarity Reversed: 當網路設備連結時,傳送與接收線對配置為T+T- 配上R-R+ (正常情況 下應是T+T-對R+R-),使得信號極性顛倒導致網路無法連結,常肇因於網路接線圖配線 錯誤;通常可藉測線工具偵測,或使用具有Auto Polarity Detect功能的網路設備來預防。 ■ Duplex Mismatch: 當網路設備連結時,或許可正常連線,但可能因雙工狀態不匹配 而產生過多的碰撞(Collision)而速度緩慢。 |
網路層常見障礙:
Short
Frames received(also Jabber/FCS):
封包長度小於合法長度,且FSC檢查碼又是正確的封包稱為Short Frame。 Jabber是指長度超過於最大合法尺寸的封包(大於1518bytes)。 封包檢測序列(FCS)錯誤是指封包標頭資訊可能是正確的, 但是由接收端計算的FCS與加在封包末端的FCS不符。 解決辦法:檢查NIC卡或NIC驅動程式。也可能是由接線或接地問題造成的。
Excessive
utilization seen(also collisions):
網路使用率超過40%或碰撞率大於5%時定義為過高。 解決辦法: 1.如果流量過大是整個網路的問題,建議安裝Switch。 2.如果只是一台PC碰撞率很高,可以檢查接線與網卡設定是否正常。 3.請檢查網路流量是否過大(超過40%)而導致碰撞過多。 4.減少網路流量。檢查接線。更換NIC卡或交換機/集線器連接埠。 5.使用網路分析工具定本網路中佔用資源的主要站台為何? Ethernet frame-type mismatches: 為了使PC與網路通信,它們應設定為相同的封包類型 (802.3-raw、802.2、Ethernet II和SNAP)。 解決辦法: 用NetTool確定所有的封包類型。若用戶端需要,則確定用戶端封包類型與 伺服器上設定的封包類型一致。 |
由於上述事件在所有的網路事件統計中,比例並不算低,且只要是發生,便會產生網路完全無法使用的問題,因此「現場分析」也成為網路維運除錯議題中,最重要的一部分。
|
四、封包解析
|
封包解析對於應用層上的維修具有舉足輕重的地位,舉凡應用層上的反應時間(Response Time),設備本身處理及轉送封包的Latency,應用層封包型態佔用頻寬的封包數及百分比,都可使用封包解析軟體來分析,傳統的硬體環境下封包解析對網路的維運及除錯占著舉足輕重的地位,因為以往的硬體架構是Hub,所以我們可以輕易地從一個埠端(Port)擷取其他埠端(Port)的封包進而做解析,但是面臨到目前的交換器(Switch)架構時,封包解析軟體若不配合硬體可說是無用武之地.
封包解析軟體所遭遇的測試挑戰:
1.一般的網路卡效能不足,以100Mbps的網路卡為例,效能可達到60-70%就算是不錯了,也就是如果網路上的流量很高時,一般的網路卡無法做到Full Line
Rate的擷取,加上正常的網卡是會拋棄錯誤封包的,所以運用封包解析軟體不搭配專用網卡其實是沒有太大用處的.
2.交換器環境每個埠端(Port)便是一個碰撞區域,我們僅能用Mirror的方式將另一個埠端(Port)的封包 Mirror過來,而交換器並不會Forward錯誤的封包.
3.在埠端(Port)加裝Hub亦有如同第一項的問題,無法做到Full Line
Rate的擷取.
根據上述三項挑戰,我們的建議是-目前交換器環境的網路架構,必須先使用網路管理及網路監控的機制來了解您網路的基本情形,或發生問題時運用現場分析工具來發現並解決問題,至於封包解析是應用層出現問題時的分析方法,且必須使用被動的Tap將封包取出,才能做到不拋棄錯誤封包及達到Full Line Rate的擷取.
|
乙太網路錯誤封包定義:
|
資料在傳遞時,因電壓的不穩、磁場的干擾,故障的硬體或驅動程式異常...... 均可能使訊號在傳輸時被改變而造成資料接收錯誤。合法的封包長度應屆於64~1518 Bytes 之間,以下將針對乙太網路中常見的錯誤封包定義,予以說明:(資料來源:IEEE 802.3)
|
|
2016年5月14日 星期六
tx Collision
訂閱:
張貼留言 (Atom)
沒有留言:
張貼留言