使用IKEv2排除vEdge上服务隧道的IPsec问题

下载选项

  • PDF     (695.0 KB)
    在各种设备上使用 Adobe Reader 查看
已更新: 2021 年 11 月 18 日
文档 ID:217418

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

    简介

    本文档介绍如何排除配置了Internet Key Exchange版本2(IKEv2)的第三方设备的Internet协议安全(IPsec)隧道的最常见问题。最常被引用为Cisco SD-WAN文档上的服务/传输隧道。本文档还说明如何启用和读取IKE调试，并将它们关联到数据包交换，以了解IPsec协商的故障点。

    先决条件

    要求

    Cisco 建议您了解以下主题：

    • IKEv2
    • IPsec协商
    • 思科SD-WAN

    使用的组件

    本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

    背景信息

    IKE术语表

    • Internet协议安全(IPsec)是IP网络中2个通信点之间的标准协议簇，提供数据身份验证、完整性和机密性。
    • Internet密钥交换版本2(IKEv2)是用于在IPsec协议簇中设置安全关联(SA)的协议。
    • 安全关联(SA)是在两个网络实体之间建立共享安全属性以支持安全通信。SA可以包括诸如加密算法和模式等属性；流量加密密钥；以及要在连接上传递的网络数据的参数。
    • 供应商ID(VID)用于标识实施相同供应商的对等设备，以支持供应商特定功能。
    • Nonce:在exchange中创建的随机值，用于添加随机性并防止重播攻击。
    • Diffie-Hellman(DH)安全密钥交换过程的密钥交换(KE)信息。
    • 身份发起方/响应方(IDi/IDr.)用于向对等体发送身份验证信息。此信息是在公共共享密钥的保护下传输的。
    • IPSec共享密钥可以再次使用DH来确保完全向前保密(PFS)，也可以通过刷新源自原始DH交换的共享密钥来获得。
    • Diffie-Hellman(DH)密钥交换是在公共信道上安全交换加密算法的方法。
    • 流量选择器(TS)是在IPsec协商上交换的代理身份或流量，用于通过加密的隧道。

    IKEv2数据包交换

    每个IKE数据包都包含用于建立隧道的负载信息。IKE术语表解释此映像上显示的缩写，作为数据包交换负载内容的一部分。

    IKEV2 - NAT-TIKEV2-Exchange

    注意：必须验证IPsec隧道无法快速分析涉及哪些配置以有效解决问题的IKE协商的数据包交换。

    注意：本文档未深入介绍IKEv2数据包交换。有关更多参考，请导航到IKEv2数据包交换和协议级别调试

    需要将vEdge配置与Cisco IOS® XE配置相关联。此外，匹配IPsec概念和IKEv2数据包交换的负载内容也非常有用，如图所示。

    Config for vedge and IOS-XE

    注意：配置的每个部分都修改IKE协商交换的一个方面。将命令与IPsec的协议协商关联起来非常重要。

    故障排除

    启用IKE调试

    在vEdge上debug iked启用调试级别信息（IKEv1或IKEv2）。

    debug iked misc high
    debug iked event high

    可以显示vshell中的当前调试信息，并运行命令tail -f <debug path>。

    vshell
    tail -f /var/log/message

    也可以在CLI中显示指定路径的当前日志/调试信息。

    monitor start /var/log/messages

    启动IPsec问题故障排除过程的提示

    可以分离三种不同的IPsec方案。识别症状是了解入门的更好方法的一个很好的参考点。

    1. IPsec隧道未建立。
    2. IPsec隧道发生故障，它自行重建。（闪烁）
    3. IPsec隧道关闭，并且保持关闭状态。

    由于IPsec隧道未建立症状，因此需要实时调试以验证IKE协商的当前行为。

    对于IPsec隧道，它会根据自己的症状重新建立，最常见的是称为隧道交换的症状，并且需要根本原因分析(RCA)。了解隧道关闭的时间戳或估计查看调试的时间是必不可少的。

    对于IPsec隧道关闭并且保持关闭状态症状，这意味着隧道以前曾工作过，但由于任何原因，它曾关闭，我们需要知道断开原因以及当前阻止隧道重新成功建立的行为。

    在故障排除开始之前确定以下几点：

    1. IPsec隧道（编号）存在问题和配置。
    2. 隧道关闭时的时间戳（如果适用）。
    3. IPsec对等IP地址（隧道目标）。

    所有调试和日志都保存在/var/log/messages文件中，对于当前日志，它们保存在消息文件中，但是对于此特定症状，可以在问题发生后数小时/天识别抖动，最可能是在消息1、2、3.等上执行相关的调试。了解时间戳非常重要，这样才能查看正确的消息文件并分析与IPsec隧道相关的IKE协商的调试(charon)。

    大多数调试不打印IPsec隧道的编号。识别协商和数据包的最常见方法是使用远程对等体的IP地址以及在边界上发起隧道的IP地址。打印的IKE调试的一些示例：

    Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_IPsec2_1'
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1

    IKE INIT协商的调试显示IPsec隧道号，但是，数据包交换的后续信息仅使用IPsec隧道IP地址。


    Jun 18 00:31:22 vedge01 charon: 09[CFG] vici initiate 'child_ipsec2_1'
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[IKE] initiating IKE_SA ipsec2_1[223798] to 10.10.10.1
    Jun 18 00:31:22 vedge01 charon: 16[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
    Jun 18 00:31:22 vedge01 charon: 16[NET] sending packet: from 10.132.3.92[500] to 10.10.10.1[500] (464 bytes)
    Jun 18 00:31:22 vedge01 charon: 12[NET] received packet: from 10.10.10.1[500] to 10.132.3.92[500] (468 bytes)
    Jun 18 00:31:22 vedge01 charon: 12[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(HTTP_CERT_LOOK) N(FRAG_SUP) V ]
    Jun 18 00:31:22 vedge01 charon: 12[ENC] received unknown vendor ID: 4f:85:58:17:1d:21:a0:8d:69:cb:5f:60:9b:3c:06:00
    Jun 18 00:31:22 vedge01 charon: 12[IKE] local host is behind NAT, sending keep alives

    IPsec隧道配置：

    interface ipsec2
  ip address 192.168.1.9/30
  tunnel-source      10.132.3.92
  tunnel-destination 10.10.10.1
  dead-peer-detection interval 30
  ike
   version      2
   rekey        86400
   cipher-suite aes256-cbc-sha1
   group        14
   authentication-type
    pre-shared-key
     pre-shared-secret $8$wgrs/Cw6tX0na34yF4Fga0B62mGBpHFdOzFaRmoYfnBioWVO3s3efFPBbkaZqvoN
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-gcm
   perfect-forward-secrecy group-14
  !

    症状 1.  未建立IPsec隧道

    由于此问题可能是隧道的首次实施，因此它尚未启动，而IKE调试是最佳选项。

    症状 2.  IPsec隧道发生故障，已自行重建

    如前所述，通常，此症状用于了解隧道关闭的根本原因。了解根本原因分析后，有时网络管理员会阻止进一步的问题。

    在故障排除开始之前确定以下几点：

    1. IPsec隧道（编号）存在问题和配置。
    2. 隧道关闭时的时间戳。
    3. IPsec对等IP地址（隧道目标）

    DPD重新传输

    在本例中，隧道在6月18日00:31:17关闭。

    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-vedge01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

    注意：IPsec隧道关闭的日志不是标记调试的一部分，它们是FTMD日志。因此，charon和IKE都不会打印。

    注意：相关日志通常不会一起打印，它们之间有许多不与同一过程相关的信息。 

    步骤1.确定时间戳后，将时间和日志关联起来，开始自下而上地查看日志。

    Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
    Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:28:22 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)  
    Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
    Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
    Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

    上一次成功的DPD数据包交换被描述为请求# 542。

    Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
    Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 13.51.17.190[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ]

     步骤2.按正确的顺序将所有信息放在一起：

    Jun 18 00:24:08 vedge01 charon: 11[ENC] generating INFORMATIONAL request 542 [ ] 
    Jun 18 00:24:08 vedge01 charon: 11[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 10.132.3.92[4500] (76 bytes) 
    Jun 18 00:24:08 vedge01 charon: 07[ENC] parsed INFORMATIONAL response 542 [ ] 

    Jun 18 00:25:21 vedge01 charon: 08[IKE] sending DPD request 
    Jun 18 00:25:21 vedge01 charon: 08[ENC] generating INFORMATIONAL request 543 [ ] 
    Jun 18 00:25:21 vedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 
    Jun 18 00:25:51 vedge01 charon: 05[IKE] retransmit 1 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:25:51 vedge01 charon: 05[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes)

    Jun 18 00:26:45 vedge01 charon: 06[IKE] retransmit 2 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:26:45 vedge01 charon: 06[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

    Jun 18 00:28:22 vedge01 charon: 08[IKE] retransmit 3 of request with message ID 543 (tries=3, timeout=30, exchange=37, state=2) 
    Jun 18 00:28:22 Lvedge01 charon: 08[NET] sending packet: from 10.132.3.92[4500] to 10.10.10.1[4500] (76 bytes) 

    Jun 18 00:31:17 vedge01 charon: 11[IKE] giving up after 3 retransmits
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec2 DOWN
    Jun 18 00:31:17 vedge01 FTMD[1472]: %Viptela-LONDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"LONDSR01" system-ip:4.0.5.1 vpn-id:1 if-name:"ipsec2" new-state:down

    对于所描述的示例，由于vEdge01未收到来自10.10.10.1的DPD数据包，隧道会关闭。预计在3次DPD重新传输之后，IPsec对等体会设置为“lost”并且隧道会关闭。此行为有多种原因，通常与路径中数据包丢失或丢弃的ISP有关。如果问题出现一次，则无法跟踪丢失的流量，但如果问题依然存在，则可以通过在vEdge、远程IPSec对等体和ISP上使用捕获来跟踪数据包。

    症状3. IPsec隧道关闭且保持关闭状态

    如此症状中所述，隧道先前工作正常，但由于任何原因，它发生故障，无法再次成功建立隧道。在这种情况下，网络会受到影响。

    在故障排除开始之前确定以下几点：

    1. IPsec隧道（编号）存在问题和配置。
    2. 隧道关闭时的时间戳。
    3. IPsec对等IP地址（隧道目标）

    PFS不匹配

    在本示例中，故障排除不是在隧道关闭时以时间戳开始。由于问题仍然存在，IKE调试是最佳选项。 

    interface ipsec1
  description             VWAN_VPN
  ip address 192.168.0.101/30
  tunnel-source-interface ge0/0
  tunnel-destination      10.10.10.1
  ike
   version      2
   rekey        28800
   cipher-suite aes256-cbc-sha1
   group        2
   authentication-type
    pre-shared-key
     pre-shared-secret "$8$njK2pLLjgKWNQu0KecNtY3+fo3hbTs0/7iJy6unNtersmCGjGB38kIPjsoqqXZdVmtizLu79\naQdjt2POM242Yw=="
    !
   !
  !
  ipsec
   rekey                   3600
   replay-window           512
   cipher-suite            aes256-cbc-sha1
   perfect-forward-secrecy group-16 
  !
  mtu                     1400
  no shutdown

    启用调试链接并显示协商。

    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (508 bytes) 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] parsed CREATE_CHILD_SA request 557 [ SA No TSi TSr ] 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] no acceptable proposal found 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[IKE] failed to establish CHILD_SA, keeping IKE_SA 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[ENC] generating CREATE_CHILD_SA response 557 [ N(NO_PROP) ] 
    daemon.info: Apr 27 05:12:56 vedge01 charon: 16[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 

    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (76 bytes) 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] parsed INFORMATIONAL request 558 [ ] 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[ENC] generating INFORMATIONAL response 558 [ ] 
    daemon.info: Apr 27 05:12:57 vedge01 charon: 08[NET] sending packet: from 172.28.0.36[4500] to 10.10.10.1[4500] (76 bytes) 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[NET] received packet: from 10.10.10.1[4500] to 172.28.0.36[4500] (396 bytes) 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[ENC] parsed CREATE_CHILD_SA request 559 [ SA No TSi TSr ] 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ 
    daemon.info: Apr 27 05:12:58 Avedge01 charon: 07[IKE] no acceptable proposal found 
    daemon.info: Apr 27 05:12:58 vedge01 charon: 07[IKE] failed to establish CHILD_SA, keeping IKE_SA

    注意：  CREATE_CHILD_SA数据包会交换每个重新生成密钥或新SA。有关更多参考，请导航到了解IKEv2数据包交换

    IKE调试显示相同的行为，并且不断重复，因此可以获取部分信息并对其进行分析： 

    CREATE_CHILD_SA表示重新生成密钥，目的是在IPsec终端之间生成和交换新的SPIS。

    • 网关收到来自10.10.10.1的CREATE_CHILD_SA请求数据包。
    • Vedge处理请求并验证对等体10.10.10.1发送的建议(SA)
    • 该网桥将对等体发送的已接收建议与已配置的建议进行比较。
    • 交换的CREATE_CHILD_SA失败，并显示“未找到可接受的提议”。

    眼下，问题是：如果隧道以前工作并且未进行任何更改，为什么会出现配置不匹配问题？

    深入分析，对等体未发送的已配置建议上有一个额外的字段。

    配置的提议：ESP:AES_CBC_256/HMAC_SHA1_96/MODP_4096/NO_EXT_SEQ

    已收到的建议书：
    ESP:AES_GCM_16_256/NO_EXT_SEQ，
    ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQ，
    ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ，
    ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ，
    ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ，
    ESP:3DES_CBC/HMAC_SHA2_256_128/NO_EXT_SEQ

    MODP_4096是DH组16，它在第2阶段（IPsec部分）上为PFS（完全向前保密）配置了网桥。

    根据IKE协商中发起者或响应者的身份，PFS是唯一可以成功建立或不成功建立隧道的不匹配配置。但是，当重新生成密钥启动时，隧道无法继续，并且可能会出现此症状或与之相关。

    vEdge IPSec/Ikev2隧道在因DELETE事件而中断后未重新初始化

    有关此行为的详细信息，请参阅Cisco Bug ID CSCvx86427。

    随着问题的持续，IKE调试是最佳选项。但是，对于此特定漏洞，如果启用了调试，则终端和消息文件都不会显示任何信息。

    要缩小此问题范围并验证vEdge是否触及Cisco Bug ID CSCvx86427，需要查找隧道关闭的时刻。

    在故障排除开始之前确定以下几点：

    1. IPsec隧道（编号）存在问题和配置。
    2. 隧道关闭时的时间戳。
    3. IPsec对等IP地址（隧道目标）

    确定时间戳并关联时间和日志后，在隧道关闭之前查看日志。

    Apr 13 22:05:21 vedge01 charon: 12[IKE] received DELETE for IKE_SA ipsec1_1[217] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] deleting IKE_SA ipsec1_1[217] between 10.16.0.5[10.16.0.5]...10.10.10.1[10.10.10.1] 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
    Apr 13 22:05:21 vedge01 charon: 12[IKE] IKE_SA deleted 
    Apr 13 22:05:21 vedge01 charon: 12[ENC] generating INFORMATIONAL response 4586 [ ] 
    Apr 13 22:05:21 vedge01 charon: 12[NET] sending packet: from 10.16.0.5[4500] to 10.10.10.1[4500] (80 bytes) 
    Apr 13 22:05:21 vedge01 charon: 12[KNL] Deleting SAD entry with SPI 00000e77 
    Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-FTMD-6-INFO-1000001: VPN 1 Interface ipsec1 DOWN
    Apr 13 22:05:21 vedge01 FTMD[1269]: %Viptela-AZGDSR01-ftmd-6-INFO-1400002: Notification: interface-state-change severity-level:major host-name:"vedge01" system-ip:4.1.0.1 vpn-id:1 if-name:"ipsec1" new-state:down

    注意：  IPsec协商中存在多个DELETES数据包，并且DELETE for CHILD_SA是REKEY进程的预期DELETE，当接收到纯IKE_SA DELETE数据包而不进行任何特定IPsec协商时，会出现此问题。该DELETE删除所有IPsec/IKE隧道。

    相关信息

    修订历史记录

    版本 发布日期 备注
    2.0
    18-Nov-2021
    向文档添加更多信息
    1.0
    29-Sep-2021
    初始版本
    TAC Authored

    由思科工程师提供

    • 阿曼达·纳瓦·萨拉特
      思科TAC工程师

    此文档是否有帮助?

    Feedback反馈

    联系我们