環回測試是很常用的一種測試，通常用于檢查和分析端口或線路問題。如下圖所示，我們在設備端口上用命令loopback(某些端口上命令格式為 loopback diagnostic)使接口從內部將自己發送的信號轉接到自己的接收端(如紅線所示)，通過檢查數據發送和接收的情況來判定端口工作狀態是否正常。假如需要對端口進行完全的檢測，可以使用符合標準的短跳線將端口收發短接構成環。假如端口正常，可以將線路的一部分或全部包括到環中進行測試，即在線路中的某個點上進行短接構成環(如紫紅色線所示)。這些點可以是在配線架、CSU/DSU、傳輸設備等之上。在某些類型的端口上，還可以用命令 loopback line 在端口上將對方發送的信號轉接到對方的接收短，構成測試環。

觀察環回測試成功與否，首先看端口有沒有形成環，如用命令 show interface 看看端口是不是已經從down狀態變到up狀態，狀態中有沒有“(looped)”的字樣。端口的某些封裝形式，如串行口上的PPP、幀中繼等封裝會檢測環路，阻止端口變成up狀態，所以可能要臨時改為HDLC封裝以便進行測試。

其次是通過ping 產生一定的流量，觀察有沒有丟包，show interface 檢查端口計數器有沒有顯示input/output錯誤，有沒有CRC、Frame等錯誤。注重在點對點類型的端口上ping 路由器本身的地址比ping 對端路由器的地址延時要小一半，原因可以參考下面的分析。在ATM等二層端口上不能直接產生測試數據包，可能需要額外的配置，如在8500交換機上可以這樣配置:

interface atm 1/0/0 //需要進行環回測試的ATM二層端口

!

inter atm 0.1 point-to-point

atm pvc 0 100 interface atm 0/1/0 0 100 encap aal5snap

ip address 172.31.20.1 255.255.255.0

!

假如測試發現有丟包情況，可以通過命令show controller了解更多細節情況。如以下命令顯示了某ATM端口上的BIP錯誤情況:

    Router>show controllers atm 3/0/3

IF Name: ATM3/0/3 Chip Base Address: BC38E000

Port type: OC3 Port rate: 155000 Kbps Port medium: MM Fiber

Port status:Good Signal Loopback:None Flags:8308

...

Key: txcell - # cells transmitted

rxcell - # cells received

b1 - # section BIP-8 errors

b2 - # line BIP-8 errors

b3 - # path BIP-8 errors

ocd - # out-of-cell delineation errors - not implemented

g1 - # path FEBE errors

z2 - # line FEBE errors

chcs - # correctable HEC errors

uhcs - # uncorrectable HEC errors

txcell:275849733, rxcell:143010088

b1:26, b2:104, b3:34, ocd:0

g1:12, z2:0, chcs:0, uhcs:20

...

一般而言，環回測試直接了當:觀察有沒有象意料中的一樣形成環，形成環之后有沒有發現傳輸錯誤，然后根據測試結果調整線路或者設備。但是有的時候，環路測試的結果比較有迷惑性，下面舉兩個例子:

有一次在通訊機房里做環路測試，從本地E1傳輸設備上到本地路由器做環測試沒有問題，從本地E1傳輸設備到遠端路由器做環測試也沒有問題，但從遠端E1傳輸設備到本地路由器之間打環測試就會丟包。由于從本地E1傳輸設備到遠端路由器做環測試沒有問題，所以本地E1傳輸設備和遠端E1傳輸設備之間的線路不應該有問題，但只要將這段線路包括進來之后測試就會出現丟包。最后發現原來是這個通訊機房里安裝了微波傳輸設備，干擾大，線路屏蔽不好所以出現丟包。

另外一次是一臺8540 ATM 交換機和12406路由器ATM端口通過一段短短的尾纖相連卻發現大量CRC錯誤，更換了端口模塊、尾纖都沒有排除故障，反復觀察才發現原來8540交換機的時鐘同步信號存在問題。

還有一個非凡情況就是3750、3550、2950等以太網交換機在端口上發送keep alive信息以檢查端口是否激活，假如端口被環回，按照默認的錯誤檢測處理(errdisable)規則，端口將會關閉。除非設置了錯誤恢復 (errdisable recovery)功能，否則在治理員干預之前端口不會恢復到正常工作狀態。更嚴重的是網絡中短暫的環路(如錯誤的連接、生成樹配置錯誤)等都會引發這個錯誤，所以建議用端口配置命令no keepalive關閉端口激活檢測或通過全局配置命令no errdisable detect cause loop 防止因環回錯誤關閉端口，中斷網絡連接。

附:點對點端口上的ping 數據觀察與分析(ping 對端地址需要一個往返，ping 自己的地址需要兩個往返)

測試情況，R1端口地址為172.31.20.1，對端R2地址為172.31.20.254

R1#ping

PRotocol [ip]:

Target IP address: 172.31.20.254 //ping R2地址

Repeat count [5]: 1

...

Sending 1, 100-byte ICMP Echos to 172.31.20.254, timeout is 2 seconds:

!

SUCcess rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms

                         
(debug 輸出)

Apr 10 12:19:03.994: 

IP: s=172.31.20.1 (local), d=172.31.20.254 (Serial4/0/0), len 100, sending

Apr 10 12:19:03.994: 

ICMP type=8, code=0 R1發出一個Echo Request(type=8)，R2收到后以Echo Reply 相應

Apr 10 12:19:04.002: 

IP: s=172.31.20.254 (Serial4/0/0), d=172.31.20.1 (Serial4/0/0), len 100, rcvd 3

Apr 10 12:19:04.002: 

ICMP type=0, code=0 R1收到Echo Reply(type=0)，計算延時(002-994=8ms)。

R1#ping

Protocol [ip]:

Target IP address: 172.31.20.1 //ping R1自己的地址

Repeat count [5]: 1

...

Sending 1, 100-byte ICMP Echos to 172.31.20.1, timeout is 2 seconds:

!

Success rate is 100 percent (1/1), round-trip min/avg/max = 16/16/16 ms

(debug 輸出)

Apr 10 12:18:00.106: 

IP: s=172.31.20.1 (local), d=172.31.20.1 (Serial4/0/0), len 100, sending

Apr 10 12:18:00.106: 

ICMP type=8, code=0 R2發出一個Echo Request(type=8)

Apr 10 12:18:00.114: 

IP: s=172.31.20.1 (Serial4/0/0), d=172.31.20.1 (Serial4/0/0), len 100, rcvd 3

Apr 10 12:18:00.114: 

ICMP type=8, code=0 R2收到Echo Request，判定的目標地址為R1，所以將包發回

Apr 10 12:18:00.114: 

IP: s=172.31.20.1 (local), d=172.31.20.1 (Serial4/0/0), len 100, sending

Apr 10 12:18:00.114: 

ICMP type=0, code=0 R1收到自己發出的Echo Request，以Echo Reply(type=0)相應并通過端口發送

Apr 10 12:18:00.122: 

IP: s=172.31.20.1 (Serial4/0/0), d=172.31.20.1 (Serial4/0/0), len 100, rcvd 3

Apr 10 12:18:00.122: 

ICMP type=0, code=0 R2將包發回。R1收到Echo Reply (type=0),計算延時(112-106=16ms)。