執行環回呼叫以測試BRI電路

簡介

本文說明如何執行回送以測試基本速率介面(BRI)電路。

必要條件

需求

本文檔的讀者應瞭解以下主題：

• debug isdn q931和debug ppp negotiation命令的輸出。

• 常規DDR撥號程式設定檔組態概念。有關撥號程式設定檔的詳細資訊，請參閱設定和疑難排解撥號程式設定檔。

在嘗試此過程之前，請從Telco獲取以下資訊：

• 要配置的交換機型別。

• 服務配置檔案識別符號(SPID)和本地目錄號(LDN)。 美國需要SPID和LDN。

• 兩個B通道是否都在尋線組中。如果他們在尋線組中，我們只需撥一個號碼即可到達其中一個B通道。

• BRI線路上的呼叫需要撥打56k還是64k

採用元件

本文中的資訊係根據以下軟體和硬體版本：

• Cisco IOS軟體版本12.0(3)T及更高版本。這是因為在Cisco IOS軟體版本12.0(3)T中引入了isdn call命令。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

背景資訊

在環回呼叫中，路由器撥打其自己的基本速率介面(BRI)的ISDN號碼。 呼叫繼續到電信雲，電信將呼叫切換到第二個BRI通道。路由器現在將此呼叫視為第二個通道上的來話呼叫。因此，路由器都會傳送和接收ISDN呼叫。

環回呼叫測試路由器發起和終止ISDN呼叫的能力。成功的環回呼叫會強烈指示通往電信網雲的ISDN電路工作正常。

有兩種型別的環回呼叫可用於測試BRI電路：

• ISDN第3層環回呼叫模???可以使用isdn call interface命令。此環回呼叫可幫助您驗證ISDN第1層、第2層和第3層是否在路由器和本地ISDN交換機之間正常工作。此測試使用D通道，並且不通過B通道測試資料。這不涉及對路由器配置的更改。首先執行此測試。如果成功，則嘗試資料環回呼叫測試。

• 資料回送呼叫方???該測試測試B通道是否真的能傳遞資料。這涉及路由器上的配置更改。

這些步驟僅允許您測試本地交換機的BRI電路是否正常工作。它不會測試端到端ISDN連線或與按需撥號路由(DDR)相關的問題。 有關BRI故障排除的詳細資訊，請參閱以下文檔：

• ISDN BRI故障排除流程圖

• 使用debug isdn q931命令排除ISDN BRI第3層故障

執行ISDN第3層回送呼叫

本節提供成功的ISDN第3層環回呼叫的示例。isdn call命令可啟用無需DDR要求的傳出ISDN呼叫（例如相關流量和路由）。此命令僅可用於測試通到第3層的ISDN電路，並且不能用於傳遞流量或替代正確的DDR配置。此命令驗證ISDN電路（尤其是第3層）是否正常工作。

圖1顯示了呼叫流程和部分debug isdn q931消息：

圖1 — 呼叫流程和某些debug isdn q931消息

maui-soho-04#isdn call interface bri 0 5551111

!--- The router dials 5551111 (the ISDN number of the router's own BRI). !--- If the BRI circuit has two different phone numbers for each B-channel, !--- use the number that belongs to the second B-channel. !--- You can use this command to make calls at 56k, with the speed 56 option
.
maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch.

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch. !--- The switch now processes the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the !--- incoming call. Remember that the router sent a Setup message (for the !--- outgoing call) and now receives a SETUP message for the same call.

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call.

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call.

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call.

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect message for the outgoing call.

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 5551111 

! --- Call is now connected. Loopback call is successful.

附註：

• 在環回呼叫期間，路由器在不同B通道上同時充當被呼叫路由器和呼叫路由器。解釋debug isdn q931輸出時，請務必跟蹤這些「雙重角色」。例如，路由器傳送設定訊息(TX -> SETUP)，並也接收一則訊息(RX <- SETUP)。 傳輸的SETUP必須與傳出呼叫關聯，而接收的SETUP消息與傳入呼叫關聯。

• 在上方範例中，第一個B通道的號碼被撥號。但是，電信公司認識到第一個B通道忙（因為它發出呼叫），並將呼叫切換到第二個B通道，並且連線成功完成。但是，電信交換機中的錯誤配置可能會導致環回呼叫失敗。當交換器嘗試將呼叫指派給第一個通道（此通道正忙於進行呼叫）時，就可能會發生這種情況。 要求電信公司將兩個B通道新增到尋線組中。但是，出於本測試的目的，我們可以在isdn call interface命令中指定第二個B通道號來解決此問題。

• 在另一個路由器上執行環回呼叫。

• 如果環回呼叫成功，並且到遠端端的呼叫仍然失敗，則可以嘗試資料環回呼叫以測試B通道資料的完整性，如下一節所述。

有關如何解決任何問題的資訊，請參閱以下文檔：

• ISDN BRI故障排除流程圖

• 使用debug isdn q931命令排除ISDN BRI第3層故障

執行資料環回呼叫

資料環回呼叫可用於測試B通道是否可以正確傳輸資料。在許多情況下，debug ppp negotiation可能會持續失敗。該測試可用於檢查B通道上的資料完整性。

注意：與先前的測試不同，此測試涉及對路由器的配置更改。

在資料環回呼叫中，我們在路由器上配置兩個撥號器介面。撥號器介面配置有必要的定址、身份驗證和DDR命令，以便在BRI線路上成功撥出、接收來電、繫結到另一個撥號器介面並成功連線。

建立撥號器配置檔案以撥打同一路由器上的另一個撥號器配置檔案。

配置路由器

要為環回呼叫配置路由器，請完成以下步驟：

1. 使用copy running-config startup-config命令的幫助儲存運行配置。執行此操作後，您可以在測試完成後重新啟動並將運行配置恢復到測試前版本。

2. 配置物理介面。

   注意：本節假定您瞭解必要的ISDN相關資訊，如交換機型別和SPID。

   interface BRI0
    no ip address
    
   !--- Do not configure an IP address on the physical interface. !--- The IP address will be configured on the dialer. 
   
    encapsulation ppp
    !--- physical interface uses PPP encapsulation
    dialer pool-member 1
    
   !--- Assign BRI0 as member of dialer pool 1. !--- Dialer pool 1 is specified in interface Dialer 1, and !--- interface Dialer 2.
   
    isdn switch-type basic-ni
    isdn spid1 71355511110101 5551111
    isdn spid2 71355511120101 5551112
    
   !--- switch-type and SPID configuration. !--- Contact the telco for this information. 
   
    ppp authentication chap callin   
    
   !--- The physical interface uses CHAP authentication. !--- Authentication is required on the physical interface to bind the !--- incoming call to the right dialer profile.
   
   

3. 配置第一個撥號器介面：

   interface Dialer1
    ip address 1.1.1.1 255.255.255.0
    
   !--- Assign an IP address to the dialer interface. !--- In this example, the IP addresses for both dialers !--- are in the same subnet.
   
    encapsulation ppp
    
   !--- The dialer interface uses PPP (same as the physical BRI interface).
   
    dialer pool 1
   
    !--- his defines Dialer pool 1. BRI 0 is a member of this pool.
   
    dialer remote-name dialer2
    
   !--- This name must match the name used by the other dialer interface to !--- authenticate itself. Dialer string 7135551112. !--- Phone number for the other B-channel. !--- If your connection only needs one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
    
   !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
   
    !--- Use one-way CHAP authentication. This is sufficient for this test.
   
    ppp chap hostname dialer1
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer1
   
    !--- CHAP Password to be sent out for authentication.
   
   

4. 配置第二個撥號器介面：

   interface Dialer2
    ip address 1.1.1.2 255.255.255.0
   
    !--- Assign an IP address to the dialer interface. !--- In this example, IP address for both dialers are in the same subnet.
   
    encapsulation ppp
    dialer pool 1
   
    !--- This defines Dialer pool 1. !--- BRI 0 is a member of this pool.
   
    dialer remote-name dialer1
   
    !--- This name must match the name used by the other dialer interface !--- (dialer1) to authenticate itself. Dialer string 7135551111. !--- Phone number for the other B-channel. !--- If your connection only has one number for both B-channels !--- (that is, they are in a hunt-group), use that number here.
   
    dialer-group 1
   
    !--- Apply interesting traffic definition from dialer-list 1.
   
    ppp authentication chap callin
    ppp chap hostname dialer2
   
    !--- CHAP hostname to be sent out for authentication.
   
    ppp chap password dialer2
   
    !--- CHAP Password to be sent out for authentication.
   
   

5. 配置用於身份驗證的使用者名稱和密碼：

   username dialer1 password 0 dialer1
   username dialer2 password 0 dialer2
   

   使用者名稱和密碼與您在每個撥號器介面下使用ppp chap hostname和ppp chap password命令進行配置的使用者名稱和密碼相同。

6. 為清楚起見，配置靜態路由：

   ip route 1.1.1.1 255.255.255.255 Dialer1
   
   !--- Note that the route for 1.1.1.1 points to dialer1.
   
   ip route 1.1.1.2 255.255.255.255 Dialer2
   
   !--- Note that the route for 1.1.1.2 points to dialer2. !--- The routes are used to determine which dialer interface is !--- used for dialout.
   
   

   提示：如果在不同的子網中配置介面撥號程式1（第3步）和介面撥號程式2（第4步）的IP地址，則不需要靜態路由。

7. 配置相關流量定義。

   dialer-list 1 protocol ip permit

   注意：撥號程式清單編號必須與撥號程式介面下的dialer-group中配置的編號相同。在本例中，配置dialer-list 1。

8. 測試完成後，重新載入路由器（不儲存配置），返回測試前使用的原始配置。

啟動資料回送呼叫

現在我們將發起資料環回呼叫，並尋找PPP協商成功完成的機會。成功的PPP協商表示B通道可以正確傳遞資料。

圖2 — 啟動資料回送呼叫

啟用以下調試：

• debug dialer

• debug isdn q931

• debug ppp negotiation

• debug ppp authentication（可選）

注意：進行環回呼叫時，路由器在不同B通道上同時充當被呼叫路由器和呼叫路由器。在解釋debug isdn q931和debug ppp negotiation命令的輸出時，請務必跟蹤這些「雙重角色」。例如，路由器傳送設定訊息(TX -> SETUP)，並也接收一則訊息(RX <- SETUP)。 傳輸的SETUP必須與撥出呼叫關聯，而接收的SETUP消息與呼入呼叫關聯。

以下是背對背ISDN呼叫的調試：

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- Because of the static route entry shown in step 6 above, !--- the call is made out from dialer 1. 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- Outgoing SETUP message.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- Incoming SETUP message on the other B-channel.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- Note that the call comes in on the second B-channel (BRI0:2). !--- Hence the outgoing call must have been on BRI0:1.

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP negotiations begin. 

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- One-way authentication (configured with PPP authentication CHAP callin).

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- Authentication begins.

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Use the alternate hostname specified with PPP CHAP hostname !--- under int Dialer 1.

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- Outgoing CHAP response sent on B-channel 1. 

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- Incoming CHAP response seen on B-channel 2.

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- Authentication is successful

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- Call (from Dialer 1) is bound to int Dialer 2. !--- This is because the dialer remote-name dialer1 command is !--- configured under int dialer 2. Binding fails when the dialer remote-name !--- command is omitted, or is incorrect, .

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP negotiation begins.

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- IPCP on B-channel 2 is Open.

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- IPCP on B-channel 1 is Open.

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

!--- Both B-channels are up.

...
Success rate is 0 percent (0/5)
router#

注意：ping可能會由於與路由相關的問題而失敗。你可以預料到的。成功的PPP協商是對B通道是否能夠在鏈路上正確傳遞資料的真正測試。如果呼叫失敗，請與電信公司聯絡以瞭解如何對線路進行故障排除的詳細資訊。

相關資訊

• ISDN BRI故障排除流程圖
• 使用debug isdn q931命令排除ISDN BRI第3層故障
• 撥號器設定檔的設定和疑難排解
• 使用ppp chap hostname和ppp authentication chap callin命令進行PPP身份驗證
• 撥號和存取技術支援
• 技術支援與文件 - Cisco Systems

修訂記錄