Copyright 2015 杭州华三通信技术有限公司及其许可者版权所有, 保留一切权利 未经本公司书面许可, 任何单位和个人不得擅自摘抄 复制本书内容的部分或全部, 并不得以任何形式传播 H3C H3CS H3CIE H3CNE Aolynk H 3 Care IRF NetPilot Netfl

Transcription

1 H3C CR16000 核心路由器 网络管理和监控配置指导 杭州华三通信技术有限公司 资料版本 :6W 产品版本 :CR16000-CMW710-R7174

2 Copyright 2015 杭州华三通信技术有限公司及其许可者版权所有, 保留一切权利 未经本公司书面许可, 任何单位和个人不得擅自摘抄 复制本书内容的部分或全部, 并不得以任何形式传播 H3C H3CS H3CIE H3CNE Aolynk H 3 Care IRF NetPilot Netflow SecEngine SecPath SecCenter SecBlade Comware ITCMM HUASAN 华三均为杭州华三通信技术有限公司的商标 对于本手册中出现的其它公司的商标 产品标识及商品名称, 由各自权利人拥有 由于产品版本升级或其他原因, 本手册内容有可能变更 H3C 保留在没有任何通知或者提示的情况下对本手册的内容进行修改的权利 本手册仅作为使用指导,H3C 尽全力在本手册中提供准确的信息, 但是 H3C 并不确保手册内容完全没有错误, 本手册中的所有陈述 信息和建议也不构成任何明示或暗示的担保

3 前言 H3C CR16000 核心路由器配置指导共分为十三本手册, 介绍了 CR16000 核心路由器各软件特性的原理及其配置方法, 包含原理简介 配置任务描述和配置举例 网络管理和监控配置指导 介绍了如何对网络进行管理, 以及如何查看系统信息 对网络流量进行统计 对报文进行采样 对网络质量进行分析, 并且使用 ping tracert debug 等命令来检查 调试当前网络的连接情况等内容 前言部分包含如下内容 : 读者对象 本书约定 产品配套资料 资料获取方式 技术支持 资料意见反馈 读者对象 本手册主要适用于如下工程师 : 网络规划人员 现场技术支持与维护人员 负责网络配置和维护的网络管理员 本书约定 1. 命令行格式约定 格式意义 粗体 斜体 命令行关键字 ( 命令中保持不变 必须照输的部分 ) 采用加粗字体表示 命令行参数 ( 命令中必须由实际值进行替代的部分 ) 采用斜体表示 [ ] 表示用 [ ] 括起来的部分在命令配置时是可选的 { x y... } 表示从多个选项中仅选取一个 [ x y... ] 表示从多个选项中选取一个或者不选 { x y... } * 表示从多个选项中至少选取一个 [ x y... ] * 表示从多个选项中选取一个 多个或者不选 &<1-n> 表示符号 & 前面的参数可以重复输入 1~n 次 # 由 # 号开始的行表示为注释行

4 2. 图形界面格式约定 格 式 意 义 < > 带尖括号 < > 表示按钮名, 如 单击 < 确定 > 按钮 [ ] 带方括号 [ ] 表示窗口名 菜单名和数据表, 如 弹出 [ 新建用户 ] 窗口 / 多级菜单用 / 隔开 如 [ 文件 / 新建 / 文件夹 ] 多级菜单表示 [ 文件 ] 菜单下的 [ 新建 ] 子菜单下的 [ 文件夹 ] 菜单项 3. 各类标志 本书还采用各种醒目标志来表示在操作过程中应该特别注意的地方, 这些标志的意义如下 : 该标志后的注释需给予格外关注, 不当的操作可能会对人身造成伤害 提醒操作中应注意的事项, 不当的操作可能会导致数据丢失或者设备损坏 为确保设备配置成功或者正常工作而需要特别关注的操作或信息 对操作内容的描述进行必要的补充和说明 配置 操作 或使用设备的技巧 小窍门 4. 图标约定 本书使用的图标及其含义如下 : 该图标及其相关描述文字代表一般网络设备, 如路由器 交换机 防火墙等 该图标及其相关描述文字代表一般意义下的路由器, 以及其他运行了路由协议的设备 该图标及其相关描述文字代表二 三层以太网交换机, 以及运行了二层协议的设备 该图标及其相关描述文字代表无线控制器 无线控制器业务板和有线无线一体化交换机的无线控制引擎设备 该图标及其相关描述文字代表无线接入点设备 该图标及其相关描述文字代表无线 Mesh 设备 该图标代表发散的无线射频信号 该图标代表点到点的无线射频信号 该图标及其相关描述文字代表防火墙 UTM 多业务安全网关 负载均衡等安全设备

5 该图标及其相关描述文字代表防火墙插卡 负载均衡插卡 NetStream 插卡 SSL VPN 插卡 IPS 插卡 ACG 插卡等安全插卡 5. 端口编号示例约定本手册中出现的端口编号仅作示例, 并不代表设备上实际具有此编号的端口, 实际使用中请以设备上存在的端口编号为准 产品配套资料 H3C CR16000 核心路由器的配套资料包括如下部分 : 大类资料名称内容介绍 产品知识介绍 硬件描述与安装 业务配置 产品彩页单板 datasheet 安全兼容性手册快速安装指南安装指导 H3C 光模块手册配置指导命令参考 MIB Companion 版本说明书 帮助您了解 CR16000 的主要规格参数及亮点 帮助您了解 CR16000 的单板属性 特点 支持的标准等 列出 CR16000 的兼容性声明, 并对兼容性和安全的细节进行说明 指导您对设备进行初始安装 配置, 通常针对最常用的情况, 减少您的检索时间 帮助您详细了解 CR16000 的硬件规格和安装方法, 指导您对 CR16000 进行安装 帮助您详细了解 CR16000 设备支持的光模块的类型 外观与规格等内容 帮助您掌握 CR16000 软件功能的配置方法及配置步骤 详细介绍 CR16000 的命令, 相当于命令字典, 方便您查阅各个命令的功能 与软件版本配套的 MIB Companion 帮助您了解 CR16000 产品版本的相关信息 ( 包括 : 版本配套说明 兼容性说明 特性变更说明 技术支持信息 ) 及软件升级方法 资料获取方式 您可以通过 H3C 网站 ( 获取最新的产品资料 : H3C 网站与产品资料相关的主要栏目介绍如下 : [ 服务支持 / 文档中心 ]: 可以获取硬件安装类 软件升级类 配置类或维护类等产品资料 [ 产品技术 ]: 可以获取产品介绍和技术介绍的文档, 包括产品相关介绍 技术介绍 技术白皮书等 [ 解决方案 ]: 可以获取解决方案类资料 [ 服务支持 / 软件下载 ]: 可以获取与软件版本配套的资料

6 技术支持 用户支持邮箱 技术支持热线电话 : ( 手机 固话均可拨打 ) 网址 : 资料意见反馈 如果您在使用过程中发现产品资料的任何问题, 可以通过以下方式反馈 : info@h3c.com 感谢您的反馈, 让我们做得更好!

7 目录 1 系统维护与调试 Ping 功能 Ping 功能简介 Ping 配置 Ping 配置举例 Tracert 功能 Tracert 功能简介 Tracert 配置 Tracert 配置举例 系统调试 系统调试简介 系统调试操作 1-6 i

8 1 系统维护与调试 1.1 Ping 功能 Ping 功能简介通过使用 ping 功能, 用户可以检查指定地址的设备是否可达, 测试链路是否通畅 Ping 功能是基于 ICMP(Internet Control Message Protocol, 互联网控制消息协议 ) 协议来实现的 : 源端向目的端发送 ICMP 回显请求 (ECHO-REQUEST) 报文后, 根据是否收到目的端的 ICMP 回显应答 (ECHO-REPLY) 报文来判断目的端是否可达, 对于可达的目的端, 再根据发送报文个数 接收到响应报文个数以及 Ping 过程报文的往返时间来判断链路的质量 Ping 配置表 1-1 Ping 配置 操作命令说明 检查 IP 网络中的指定地址是否可达 ping [ ip ] [ -a source-ip -c count -f -h ttl -i interface-type interface-number -m interval -n -p pad -q -r -s packet-size -t timeout -tos tos -v -vpn-instance vpn-instance-name ] * host ping ipv6 [ -a source-ipv6 -c count -m interval -q -s packet-size -t timeout -v -tc traffic-class -vpn-instance vpn-instance-name ] * host [ -i interface-type interface-number ] ping 命令用于 IPv4 网络环境,ping ipv6 命令用于 IPv6 网络环境两条命令均可在任意视图下执行如果网络传输速度较慢, 用户在使用 ping 命令时, 可以适当增大超时时间 -t 参数的值 ping mpls 命令的详细介绍请参见 MPLS 命令参考 中的 MPLS OAM Ping 配置举例 1. 组网需求检查 Device A 与 Device C 之间是否路由可达, 如果路由可达, 需要了解 Device A 到 Device C 的路由细节 1-1

9 2. 组网图 图 1-1 Ping 应用组网图 3. 配置步骤 # 使用 ping 命令查看 Device A 和 Device C 之间路由是否可达 <DeviceA> ping Ping ( ): 56 data bytes, press CTRL_C to break 56 bytes from : icmp_seq=0 ttl=254 time=2.137 ms 56 bytes from : icmp_seq=1 ttl=254 time=2.051 ms 56 bytes from : icmp_seq=2 ttl=254 time=1.996 ms 56 bytes from : icmp_seq=3 ttl=254 time=1.963 ms 56 bytes from : icmp_seq=4 ttl=254 time=1.991 ms --- Ping statistics for packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 1.963/2.028/2.137/0.062 ms 以上显示信息表明 Device A 给 Device C 发送了 5 个 ICMP 报文, 收到 5 个 ICMP 报文, 没有报文丢失, 路由可达 # 了解 Device A 到 Device C 的路由细节 <DeviceA> ping r Ping ( ): 56 data bytes, press CTRL_C to break 56 bytes from : icmp_seq=0 ttl=254 time=4.685 ms RR: bytes from : icmp_seq=1 ttl=254 time=4.834 ms (same route) 56 bytes from : icmp_seq=2 ttl=254 time=4.770 ms (same route) 56 bytes from : icmp_seq=3 ttl=254 time=4.812 ms (same route) 56 bytes from : icmp_seq=4 ttl=254 time=4.704 ms (same route) --- Ping statistics for packet(s) transmitted, 5 packet(s) received, 0.0% packet loss round-trip min/avg/max/std-dev = 4.685/4.761/4.834/0.058 ms ping -r 的原理如图 1-1 所示 : 1-2

10 (1) 源端 (Device A) 发送 RR 选项 (ICMP 报文中的一个字段 ) 为空的 ICMP 回显请求给目的端 (Device C) (2) 中间设备 (Device B) 将自己出接口的 IP 地址 ( ) 添加到 ICMP 回显请求报文的 RR 选项中, 并转发该报文 (3) 目的端收到请求报文后, 发送 ICMP 回显响应报文, 响应报文会拷贝请求报文的 RR 选项, 并将自己出接口的 IP 地址 ( ) 添加到 RR 选项中 (4) 中间设备将自己出接口的 IP 地址 ( ) 添加到 RR 选项中, 并转发该报文 (5) 源端收到 ICMP 回显响应报文, 将自己入接口的 IP 地址 ( ) 添加到 RR 选项中 最后得到,Device A 到 Device C 具体路由为 <-> { ; } <-> Tracert 功能 Tracert 功能简介通过使用 tracert 功能, 用户可以查看 IP 报文从源端到达目的端所经过的三层设备, 从而检查网络连接是否可用 当网络出现故障时, 用户可以使用该功能分析出现故障的网络节点 图 1-2 Tracert 原理示意图 Device A Device B Device C Device D / / / / / /24 Hop Lmit=1 TTL exceeded Hop Lmit=2 TTL exceeded Hop Lmit=n UDP port unreachable Tracert 功能也是基于 ICMP 协议来实现的, 如图 1-2 所示,Tracert 功能的原理为 : (1) 源端 (Device A) 向目的端 (Device D) 发送一个 IP 数据报文,TTL 值为 1, 报文的 UDP 端口号是目的端的任何一个应用程序都不可能使用的端口号 ; (2) 第一跳 ( 即该报文所到达的第一个三层设备,Device B) 回应一个 TTL 超时的 ICMP 错误消息 ( 该报文中含有第一跳的 IP 地址 ), 这样源端就得到了第一个三层设备的地址 ( ); (3) 源端重新向目的端发送一个 IP 数据报文,TTL 值为 2; (4) 第二跳 (Device C) 回应一个 TTL 超时的 ICMP 错误消息, 这样源端就得到了第二个三层设备的地址 ( ); (5) 以上过程不断进行, 直到该报文到达目的端, 因目的端没有应用程序使用该 UDP 端口, 目的端返回一个端口不可达的 ICMP 错误消息 ( 携带了目的端的 IP 地址 ); 1-3

11 (6) 当源端收到这个端口不可达的 ICMP 错误消息后, 就知道报文已经到达了目的端, 从而得到数据报文从源端到目的端所经历的路径 ( ; ; ) Tracert 配置 1. 配置准备 IPv4 网络环境 : 需要在中间设备 ( 源端与目的端之间的设备 ) 上开启 ICMP 超时报文发送功能 如果中间设备是 H3C 设备, 需要在设备上执行 ip ttl-expires enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) 需要在目的端开启 ICMP 目的不可达报文发送功能 如果目的端是 H3C 设备, 需要在设备上执行 ip unreachables enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) IPv6 网络环境 : 需要在中间设备 ( 源端与目的端之间的设备 ) 上开启设备的 ICMPv6 超时报文的发送功能 如果中间设备是 H3C 设备, 需要在设备上执行 ipv6 hoplimit-expires enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IPv6 基础 ) 需要在目的端开启设备的 ICMPv6 目的不可达报文的发送功能 如果目的端是 H3C 设备, 需要在设备上执行 ipv6 unreachables enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IPv6 基础 ) 2. Tracert 配置表 1-2 Tracert 配置操作命令说明 查看源端到目的端的路由 tracert [ -a source-ip -f first-ttl -m max-ttl -p port -q packet-number -t tos -vpn-instance vpn-instance-name -w timeout ] * host tracert ipv6 [ -f first-hop -m max-hops -p port -q packet-number -t traffic-class -vpn-instance vpn-instance-name -w timeout ] * host tracert 命令用于 IPv4 网络环境, tracert ipv6 命令用于 IPv6 网络环境两条命令均可在任意视图下执行 tracert mpls ipv4 命令的详细介绍请参见 MPLS 命令参考 中的 MPLS OAM Tracert 配置举例 1. 组网需求 Device A 使用 Telnet 登录 Device C 失败, 现需要确认 Device A 与 Device C 之间是否路由可达, 如果路由不可达, 需要确定故障的网络节点 1-4

12 2. 组网图 图 1-3 Tracert 应用组网图 / / / /24 Device A Device B Device C 3. 配置步骤 (1) 在 Device A Device B 和 Device C 上分别配置 IP 地址,IP 地址值如图 1-3 所示 (2) 在 Device A 上配置一条静态路由 <DeviceA> system-view [DeviceA] ip route-static [DeviceA] quit (3) 使用 ping 命令查看 Device A 和 Device C 之间路由是否可达 <DeviceA> ping Ping ( ): 56 data bytes, press CTRL_C to break Request time out Request time out Request time out Request time out Request time out --- Ping statistics for packet(s) transmitted, 0 packet(s) received, 100.0% packet loss (4) 路由不可达, 使用 tracert 命令确定故障的网络节点 # 在 Device B 上开启 ICMP 超时报文发送功能 <DeviceB> system-view [DeviceB] ip ttl-expires enable # 在 Device C 上开启 ICMP 目的不可达报文发送功能 <DeviceC> system-view [DeviceC] ip unreachables enable # 在 Device A 上使用 tracert 命令确定故障的网络节点 <DeviceA> tracert traceroute to ( ), 30 hops at most, 40 bytes each packet, press CTRL_C to break ms 2 ms 1 ms 2 * * * 3 * * * 4 * * * 5 <DeviceA> 从上面结果可以看出,Device A 和 Device C 之间路由不可达 Device A 发往 Device C 的报文已经到达 Device B,Device B 和 Device C 之间的连接出了问题 此时可以在 Device A 和 Device C 上使用 debugging ip icmp 命令打开 ICMP 报文的调试开关, 查看设备有没有收发指定的 ICMP 报文 或者使用 display ip routing-table 查看有没有到对端的路由 1-5

13 1.3 系统调试 系统调试简介设备提供了种类丰富的调试功能 设备支持的大部分功能模块, 系统都提供了相应的调试信息, 帮助用户对错误进行诊断和定位 调试信息的输出可以由两个开关控制 : 模块调试开关, 控制是否生成某模块的调试信息 屏幕输出开关, 控制是否在某个用户屏幕上显示调试信息 屏幕输出开关可以使用 terminal monitor 和 terminal logging level 命令打开,terminal monitor 和 terminal logging level 命令的详细介绍请参见 网络管理与监控命令参考 中的 信息中心 如图 1-4 所示 : 假设设备可以为 三个模块提供调试信息, 用户只有将两个开关都打开, 调试信息才会在终端显示出来 在控制台上显示是最常用的调试信息输出方式, 用户还可以将调试信息发送到别的输出方向, 具体配置请参见 网络管理与监控配置指导 中的 信息中心 图 1-4 系统调试开关关系图 系统调试操作 debugging 命令一般在维护人员进行网络故障诊断时使用 由于调试信息的输出会影响系统的运行效率, 所以建议在需要进行网络故障诊断时根据需要打开某个功能模块的调试开关, 不要同时打开多个功能模块的调试开关 在调试结束后, 建议使用 undo debugging all 命令关闭所有模块的调试开关 1-6

14 表 1-3 系统调试操作 操作命令说明 打开指定模块的调试开关 ( 可选 ) 显示已经打开的调试开关 debugging { all [ timeout time ] module-name [ option ] } display debugging [ module-name ] 缺省情况下, 所有模块的调试开关均处于关闭状态该命令在用户视图下执行 该命令可在任意视图下执行 1-7

15 目录 1 NQA NQA 简介 NQA 基本概念 NQA 工作机制 支持联动功能 支持阈值告警功能 NQA 配置任务简介 配置 NQA 服务器 使能 NQA 客户端功能 在 NQA 客户端上配置 NQA 测试组 NQA 测试组配置任务简介 配置 ICMP-echo 测试 配置 DHCP 测试 配置 DNS 测试 配置 FTP 测试 配置 HTTP 测试 配置 UDP-jitter 测试 配置 SNMP 测试 配置 TCP 测试 配置 UDP-echo 测试 配置 UDP-tracert 测试 配置 Voice 测试 配置 DLSw 测试 配置 Path-jitter 测试 配置 NQA 测试组通用可选参数 配置联动功能 配置阈值告警功能 配置 NQA 统计功能 配置 NQA 历史记录功能 在 NQA 客户端上调度 NQA 测试组 在 NQA 客户端上配置 NQA 模板 NQA 模板配置任务简介 配置 ICMP 类型的 NQA 模板 1-25 i

16 1.7.3 配置 DNS 类型的 NQA 模板 配置 TCP 类型的 NQA 模板 配置 UDP 类型的 NQA 模板 配置 HTTP 类型的 NQA 模板 配置 FTP 类型的 NQA 模板 配置 NQA 模板通用参数 NQA 显示和维护 NQA 典型配置举例 ICMP-echo 测试配置举例 DHCP 测试配置举例 DNS 测试配置举例 FTP 测试配置举例 HTTP 测试配置举例 UDP-jitter 测试配置举例 SNMP 测试配置举例 TCP 测试配置举例 UDP-echo 测试配置举例 UDP-tracert 测试配置举例 Voice 测试配置举例 DLSw 测试配置举例 Path-jitter 测试配置举例 NQA 联动配置举例 ICMP 类型的 NQA 模板配置举例 DNS 类型的 NQA 模板配置举例 TCP 类型的 NQA 模板配置举例 UDP 类型的 NQA 模板配置举例 HTTP 类型的 NQA 模板配置举例 FTP 类型的 NQA 模板配置举例 1-60 ii

17 1 NQA 1.1 NQA 简介 NQA(Network Quality Analyzer, 网络质量分析 ) 通过发送探测报文, 对链路状态 网络性能 网络提供的服务及服务质量进行分析, 并为用户提供标识当前网络性能和服务质量的参数, 如时延抖动 TCP 连接建立时间 FTP 连接建立时间和文件传输速率等 利用 NQA 的分析结果, 用户可以 : 及时了解网络的性能状况, 针对不同的网络性能进行相应处理 对网络故障进行诊断和定位 NQA 基本概念 1. 测试组 NQA 测试组是一组测试参数的集合, 如测试类型 测试目的地址 测试目的端口等 NQA 测试组由一个管理员名称和一个操作标签来标识 管理员通过 NQA 测试组来实现对 NQA 测试的管理和调度 在一台设备上可以创建多个 NQA 测试组, 可以同时启动多个 NQA 测试组进行测试 2. 测试和探测启动 NQA 测试组后, 每隔一段时间进行一次测试, 测试的时间间隔由 frequency 命令来设定 一次 NQA 测试由若干次连续的探测组成, 探测的次数由 probe count 命令来设定 对于 Voice 和 Path-jitter 测试, 一次测试中只能进行一次探测, 不能通过配置修改测试中探测的次数 NQA 支持多种测试类型 :ICMP-echo DHCP DNS FTP HTTP UDP-jitter SNMP TCP UDP-echo UDP-tracert Voice Path-jitter 和 DLSw 测试 不同测试类型中, 探测的含义不同 : 对于 TCP 和 DLSw 测试, 一次探测操作是指建立一次 TCP 或 DLSw 连接 ; 对于 UDP-jitter 和 Voice 测试, 一次探测操作是指连续发送多个探测报文, 发送探测报文的个数由 probe packet-number 命令来设定 ; 对于 FTP HTTP DHCP 和 DNS 测试, 一次探测操作是指完成一次相应的功能, 例如上传或下载一个文件, 获取一个 Web 页面, 申请一个 IP 地址, 将一个域名解析为 IP 地址 ; 对于 ICMP-echo 和 UDP-echo 测试, 一次探测操作是指发送一个探测报文 ; 对于 SNMP 测试, 一次探测操作是指发送三个 SNMP 协议报文, 分别对应 SNMPv1 SNMPv2c 和 SNMPv3 三个版本 ; 1-1

18 对于 Path-jitter 测试, 一次探测操作分为两个步骤 : 首先通过 tracert 探路获取到达目的地址的路径 ( 最大为 64 跳 ); 再根据 tracert 结果, 分别向路径上的每一跳发送多个 ICMP-echo 探测报文, 发送探测报文的个数由 probe packet-number 命令来设定 ; 对于 UDP-tracert 测试, 对目的节点进行的整个 Tracert 过程称为一次测试, 对于一个特定 TTL 值的节点发送一个探测报文的操作称为一次探测, 对于同一个 TTL 值的节点发送探测报文的次数由 probe count 命令来设定 NQA 工作机制图 1-1 NQA 测试典型组网图 如图 1-1 所示,NQA 测试的典型组网中包括以下两部分 : NQA 测试的源端设备 : 又称为 NQA 客户端, 负责发起 NQA 测试, 并统计探测结果 NQA 测试组在 NQA 客户端上创建 NQA 测试的目的端设备 : 负责接收 处理和响应 NQA 客户端发来的探测报文 在进行 TCP UDP-echo UDP-jitter 和 Voice 类型测试时, 必须在目的端设备上配置 NQA 服务器功能, 开启指定 IP 地址和端口上的监听服务 此时, 目的端设备又称为 NQA 服务器 当 NQA 服务器接收到客户端发送给指定 IP 地址和端口的探测报文后, 将对其进行处理, 并发送响应报文 在其他类型的测试中, 目的端设备只要能够处理 NQA 客户端发送的探测报文即可, 不需要配置 NQA 服务器功能 例如, 在 FTP 测试中, 目的端设备上需要配置 FTP 服务器相关功能, 以便处理客户端发送的 FTP 报文, 而无需配置 NQA 服务器功能 NQA 测试的过程为 : (1) NQA 客户端构造指定测试类型的探测报文, 并发送给目的端设备 ; (2) 目的端设备收到探测报文后, 回复带有时间戳的应答报文 ; (3) NQA 客户端根据是否收到应答报文, 以及应答报文中的时间戳, 计算报文丢失率 往返时间等 支持联动功能联动功能是指在监测模块 Track 模块和应用模块之间建立关联, 实现这些模块之间的联合动作 联动功能利用监测模块对链路状态 网络性能等进行监测, 并通过 Track 模块将监测结果及时通知给应用模块, 以便应用模块进行相应的处理 联动功能的详细介绍, 请参见 可靠性配置指导 中的 Track 如图 1-2 所示,NQA 可以作为联动功能的监测模块, 对 NQA 探测结果进行监测, 当连续探测失败次数达到一定数目时, 就通过 Track 模块触发应用模块进行相应的处理 1-2

19 图 1-2 联动功能实现示意图 以静态路由为例, 用户配置了一条静态路由, 下一跳为 通过在 NQA Track 模块和静态路由模块之间建立联动, 可以实现静态路由有效性的判断 : (1) 通过 NQA 监测地址 是否可达 (2) 如果 可达, 则认为该静态路由有效,NQA 不通知 Track 模块改变 Track 项的状态 ; 如果 NQA 发现 不可达, 则通知 Track 模块改变 Track 项的状态 (3) Track 模块将改变后的 Track 项状态通知给静态路由模块 静态路由模块据此可以判断该静态路由项是否有效 支持阈值告警功能 NQA 可以对探测结果进行监测, 在本地记录监测结果, 或通过 Trap 消息将监测结果通知给网络管理系统, 以便网络管理员了解 NQA 测试运行结果和网络性能 NQA 通过创建阈值告警项, 并在阈值告警项中配置监测的对象 阈值类型及触发的动作, 来实现阈值告警功能 阈值告警项包括 invalid over-threshold 和 below-threshold 三种状态 : NQA 测试组未启动时, 阈值告警项的状态为 invalid NQA 测试组启动后, 每次测试或探测结束时, 检查监测的对象是否超出指定类型的阈值 如果超出阈值, 则阈值告警项的状态变为 over-threshold; 如果未超出阈值, 则状态变为 below-threshold 如果阈值告警项的触发动作为 trap-only, 则当阈值告警项的状态改变时, 向网络管理系统发送 Trap 消息 (1) 监测对象 NQA 阈值告警功能支持的监测对象及对应的测试类型, 如表 1-1 所示 1-3

20 表 1-1 NQA 阈值告警功能支持的监测对象及对应的测试类型 监测对象 支持的测试类型 探测持续时间 探测失败次数 报文往返时间 丢弃报文数目 源到目的或目的到源的单向时延抖动 源到目的或目的到源的单向时延 ICPIF(Calculated Planning Impairment Factor, 计算计划损伤元素 ) 值 ICPIF 的详细介绍请参见 配置 Voice 测试 MOS(Mean Opinion Scores, 平均意见得分 ) 值 MOS 的详细介绍请参见 配置 Voice 测试 ICMP-echo DHCP DNS FTP HTTP SNMP TCP UDP-echo 和 DLSw 测试类型 ICMP-echo DHCP DNS FTP HTTP SNMP TCP UDP-echo 和 DLSw 测试类型 UDP-jitter 和 Voice 测试类型 UDP-jitter 和 Voice 测试类型 UDP-jitter 和 Voice 测试类型 UDP-jitter 和 Voice 测试类型 Voice 测试类型 Voice 测试类型 (2) 阈值类型 NQA 阈值告警功能支持的阈值类型包括 : 平均值 (average): 监测一次测试中探测结果的平均值, 如果平均值不在指定的范围内, 则该监测对象超出阈值 例如, 监测一次测试中探测持续时间的平均值 累计数目 (accumulate): 监测一次测试中探测结果不在指定范围内的累计数目, 如果累计数目达到或超过设定的值, 则该监测对象超出阈值 连续次数 (consecutive):nqa 测试组启动后, 监测探测结果连续不在指定范围内的次数, 如果该次数达到或超过设定的值, 则该监测对象超出阈值 (3) 触发动作 NQA 阈值告警功能可以触发如下动作 : none: 只在本地记录监测结果, 以便通过显示命令查看, 不向网络管理系统发送 Trap 消息 trap-only: 不仅在本地记录监测结果, 当阈值告警项的状态改变时, 还向网络管理系统发送 Trap 消息 trigger-only: 在显示信息中记录监测结果的同时, 触发其他模块联动 DNS 测试不支持发送 Trap 消息 1-4

21 1.2 NQA 配置任务简介 NQA 客户端支持两种配置方式 :NQA 测试组和 NQA 模板 NQA 测试组配置完毕后, 通过调度测试组就可以进行测试操作 ;NQA 模板配置完毕后并不启动测试, 需要外部特性 ( 如负载均衡 ) 调用 NQA 模板, 为该特性创建 NQA 测试组后, 并自动启动 NQA 测试 表 1-2 NQA 配置任务简介操作说明详细配置 配置 NQA 服务器 对于 TCP UDP-echo UDP-jitter 和 Voice 为必选, 其他测试类型为可选 1.3 使能 NQA 客户端功能 必选 1.4 在 NQA 客户端上配置 NQA 测试组 至少选择一种 NQA 测试类型 1.5 在 NQA 客户端上调度 NQA 测试组 必选 1.6 在 NQA 客户端上配置 NQA 模板 可选 配置 NQA 服务器 在进行 TCP UDP-echo UDP-jitter 和 Voice 类型测试前, 必须在目的端设备上进行本配置 进行其他类型测试时, 不需要进行本配置 在一个 NQA 服务器上可以配置多个 TCP( 或 UDP) 监听服务, 每个监听服务对应一个监听的 IP 地址和一个端口号 配置的监听 IP 地址和端口号必须与 NQA 客户端上配置的目的 IP 地址和目的端口号一致, 且不能与已有的 TCP( 或 UDP) 监听服务冲突 表 1-3 配置 NQA 服务器操作命令说明进入系统视图 system-view - 开启 NQA 服务器功能 在 NQA 服务器上配置 TCP 监听服务 在 NQA 服务器上配置 UDP 监听服务 nqa server enable nqa server tcp-connect ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ] nqa server udp-echo ip-address port-number [ vpn-instance vpn-instance-name ] [ tos tos ] 缺省情况下,NQA 服务器功能处于关闭状态 二者至少选其一配置的 IP 地址和端口号必须与 NQA 客户端的配置一致, 且不能与已有的监听服务冲突通过本命令可以指定发送应答 NQA 探测报文 (TCP 报文或 UDP 报文 ) 中携带的 ToS 值 缺省情况下,ToS 值为 使能 NQA 客户端功能 只有使能 NQA 客户端功能后,NQA 客户端的相关配置才会生效 1-5

22 表 1-4 使能 NQA 客户端功能 操作命令说明 进入系统视图 system-view - 使能 NQA 客户端功能 nqa agent enable 缺省情况下,NQA 客户端功能处于开启状态 1.5 在 NQA 客户端上配置 NQA 测试组 NQA 测试组配置任务简介表 1-5 NQA 测试组配置任务简介 配置任务说明详细配置 配置 ICMP-echo 测试 配置 DHCP 测试 配置 DNS 测试 配置 FTP 测试 配置 HTTP 测试 配置 UDP-jitter 测试 配置 SNMP 测试 至少选其一 配置 TCP 测试 配置 UDP-echo 测试 配置 UDP-tracert 测 配置 Voice 测试 配置 DLSw 测试 配置 Path-jitter 测试 配置 NQA 测试组通用可选参数 可选 配置联动功能 可选 配置阈值告警功能 可选 配置 NQA 统计功能 可选 配置 NQA 历史记录功能 可选 配置 ICMP-echo 测试 ICMP-echo 测试利用 ICMP 协议, 根据是否接收到应答报文判断目的主机的可达性 ICMP-echo 测试的功能与 ping 命令类似, 但 ICMP-echo 测试中可以指定测试的下一跳设备 在源端和目的端 1-6

23 设备之间存在多条路径时, 通过配置下一跳设备可以指定测试的路径 并且, 与 ping 命令相比, ICMP-echo 测试输出的信息更为丰富 表 1-6 配置 ICMP-echo 测试操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 ICMP-echo, 并进入测试类型视图 type icmp-echo - 配置测试操作的目的地址 ( 可选 ) 配置发送的探测报文中的填充内容大小 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置探测报文出接口 ( 可选 ) 配置使用指定接口的 IP 地址作为 ICMP-echo 测试中探测报文的源 IP 地址 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 ( 可选 ) 配置探测报文的下一跳 IP 地址 destination ip ip-address data-size size data-fill string out interface interface-type interface-number source interface interface-type interface-number source ip ip-address next-hop ip-address 缺省情况下, 未配置测试操作的目的 IP 地址 缺省情况下, 发送的探测报文中的填充内容大小为 100 字节 缺省情况下, 探测报文的填充内容为十六进制数值 缺省情况下, 未配置探测报文的出接口设备通过查询路由表信息确认报文出接口 缺省情况下, 未配置测试操作中探测报文的源 IP 地址, 以报文发送接口的主 IP 地址作为探测报文中的源 IP 地址 source ip 命令和 source interface 命令是互相覆盖的关系, 新的配置会覆盖已有配置 source interface 命令指定的接口必须为 up 状态 ;source ip 命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试会失败 缺省情况下, 未配置下一跳 IP 地址 ICMP-echo 测试不支持在 IPv6 网络中使用, 如果要测试 IPv6 网络中目的主机的可达性, 可以使用 ping ipv6 命令 ping ipv6 命令的详细介绍, 请参见 网络管理和监控命令参考 中的 系统维护与调试 配置 DHCP 测试 DHCP 测试主要用来测试网络上的 DHCP 服务器能否响应客户端请求, 以及为客户端分配 IP 地址所需的时间 1-7

24 NQA 客户端模拟 DHCP 中继转发 DHCP 请求报文向 DHCP 服务器申请 IP 地址的过程,DHCP 服务器进行 DHCP 测试的接口 IP 地址不会改变 DHCP 测试完成后,NQA 客户端会主动发送报文释放申请到的 IP 地址 表 1-7 配置 DHCP 测试操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 DHCP, 并进入测试类型视图 type dhcp - 配置测试操作中探测报文的目的地址 ( 可选 ) 配置探测报文出接口 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 destination ip ip-address out interface interface-type interface-number source ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址将 DHCP 服务器的 IP 地址配置为测试操作的目的 IP 地址 缺省情况下, 未配置探测报文的出接口设备通过查询路由表信息确认报文出接口 缺省情况下, 未配置测试操作中探测报文的源 IP 地址, 设备以发送探测报文的接口 IP 地址作为探测报文的源 IP 地址 source ip 命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败存在 DHCP 中继的组网中,DHCP 服务器是根据请求报文中的 giaddr 字段来选择地址池为客户端分配 IP 地址的 DHCP 测试中, 源 IP 地址需要添加到 DHCP 请求报文中的 giaddr 字段 关于 giaddr 字段的详细介绍, 请参见 三层技术 -IP 业务 里的 DHCP 概述 配置 DNS 测试 DNS 测试主要用来测试 NQA 客户端是否可以通过指定的 DNS 服务器将域名解析为 IP 地址, 以及域名解析过程需要的时间 DNS 测试只是模拟域名解析的过程, 设备上不会保存要解析的域名与 IP 地址的对应关系 表 1-8 配置 DNS 测试操作命令说明进入系统视图 system-view - 1-8

25 操作命令说明 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 DNS, 并进入测试类型视图 type dns - 配置测试操作中探测报文的目的地址 配置要解析的域名 destination ip ip-address resolve-target domain-name 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 将 DNS 服务器的 IP 地址配置为测试操作的目的地址 缺省情况下, 没有配置要解析的域名 配置 FTP 测试 FTP 测试主要用来测试 NQA 客户端是否可以与指定的 FTP 服务器建立连接, 以及与 FTP 服务器之间传送文件的时间, 从而判断 FTP 服务器的连通性及性能 在进行 FTP 测试之前, 需要获取 FTP 用户的用户名和密码 表 1-9 配置 FTP 测试操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 FTP, 并进入测试类型视图 type ftp - 配置 FTP 测试访问的网址 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 url url source ip ip-address 缺省情况下, 没有配置 FTP 测试访问的网址 url 可以包括远端主机地址和文件名 当操作类型为 get 方式时, 必须在 url 中配置文件名 url 可以设置为 ftp://host/filename 或 ftp://host:port/filename 缺省情况下, 未配置测试操作中源 IP 地址 该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 配置 FTP 测试的操作类型 operation { get put } 缺省情况下,FTP 操作方式为 get 操作, 即从 FTP 服务器获取文件 配置 FTP 登录用户名 username username 缺省情况下, 未配置 FTP 登录用户名 配置 FTP 登录密码 ( 可选 ) 配置 FTP 服务器和客户端传送文件的文件名 password { cipher simple } password filename file-name 缺省情况下, 未配置 FTP 登录密码 缺省情况下, 未配置 FTP 服务器和客户端之间传送文件的文件名当操作类型为 put 方式时, 此配置为必选项 1-9

26 操作命令说明 配置 FTP 测试的数据传输方式 mode { active passive } 缺省情况下,FTP 测试的数据传输方式为主动方式 进行 put 操作时, 若配置了 filename, 发送数据前判断 filename 指定的文件是否存在, 如果存在则上传该文件, 如果不存在则探测失败 进行 get 操作时, 如果 FTP 服务器上没有以 url 中所配置的文件名为名字的文件, 则测试不会成功 进行 get 操作时, 设备上不会保存从服务器获取的文件 进行 get put 操作时, 请选用较小的文件进行测试, 如果文件较大, 可能会因为超时而导致测试失败, 或由于占用较多的网络带宽而影响其他业务 配置 HTTP 测试 HTTP 测试主要用来测试 NQA 客户端是否可以与指定的 HTTP 服务器建立连接, 以及从 HTTP 服务器获取数据所需的时间, 从而判断 HTTP 服务器的连通性及性能 表 1-10 配置 HTTP 测试 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 HTTP, 并进入测试类型视图 type http - 配置 HTTP 测试访问的网址 配置 HTTP 登录用户名 配置 HTTP 登录密码 url url username username password { cipher simple } password 缺省情况下, 没有配置 HTTP 测试访问的网址 url 配置形式为 或 其中 host 是远端主机的 IP 地址或主机名,port 是远端主机的端口, resource 是远端主机上的资源 缺省情况下, 未配置 HTTP 登录用户名 缺省情况下, 未配置 HTTP 登录密码 ( 可选 ) 配置探测报文的源 IP 地址 source ip ip-address 缺省情况下, 未配置测试操作中探测报文的源 IP 地址 该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 1-10

27 操作命令说明 配置 HTTP 测试的操作类型 operation { get post raw } 配置 HTTP 测试所使用的协议版本 version { v1.0 v1.1 } 缺省情况下,HTTP 操作方式为 get 操作, 即从 HTTP 服务器获取数据 缺省情况下,HTTP 测试使用的版本为 1.0 ( 可选 ) 进入配置 HTTP 测试请求报文内容视图 ( 可选 ) 配置 HTTP 测试请求报文内容 raw-request 逐个字符输入或拷贝粘贴请求报文内容 输入 raw-request 命令进入 raw-request 视图, 每次进入视图原有报文内容清除 缺省情况下, 未配置 HTTP 测试请求报文内容当配置 operation 为 raw 时, 此配置为必选项 ( 可选 ) 保存输入内容并退回测试类型视图 quit 配置 UDP-jitter 测试 建议不要对知名端口, 即 1~1023 之间的端口, 进行 UDP-jitter 测试, 否则可能导致 NQA 测试失败或该知名端口对应的服务不可用 语音 视频等实时性业务对时延抖动 (Delay jitter) 的要求较高 通过 UDP-jitter 测试, 可以获得 网络的单向和双向时延抖动, 从而判断网络是否可以承载实时性业务 UDP-jitter 测试的过程如下 : (1) 源端以一定的时间间隔向目的端发送探测报文 (2) 目的端收到探测报文后, 为它打上时间戳, 并把带有时间戳的报文发送给源端 (3) 源端收到报文后, 根据报文上的时间戳, 计算出时延抖动, 从而清晰地反映出网络状况 时 延抖动的计算方法为相邻两个报文的目的端接收时间间隔减去这两个报文的发送时间间隔 UDP-jitter 测试需要 NQA 服务器和客户端配合才能完成 进行 UDP-jitter 测试之前, 必须保证 NQA 服 务器端配置了 UDP 监听功能, 配置方法请参见 1.3 配置 NQA 服务器 表 1-11 配置 UDP-jitter 测试 操作 命令 说明 进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 UDP-jitter, 并进入测试类型视图 type udp-jitter

28 操作命令说明 配置测试操作中探测报文的目的地址 配置测试操作的目的端口 destination ip ip-address destination port port-number 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址测试操作的目的地址必须与 NQA 服务器上所配置的监听服务的 IP 地址一致 缺省情况下, 未配置测试操作的目的端口号测试操作的目的端口号必须与 NQA 服务器上所配置的监听服务的端口号一致 ( 可选 ) 配置探测报文的源端口号 source port port-number 缺省情况下, 未指定源端口号 ( 可选 ) 配置发送的探测报文中的填充内容的大小 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置一次 UDP-jitter 探测中发送探测报文的个数 ( 可选 ) 配置 UDP-jitter 测试中发送探测报文的时间间隔 ( 可选 ) 配置 UDP-jitter 测试中等待响应报文的超时时间 data-size size data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout 缺省情况下, 发送的探测报文中的填充内容大小为 100 字节 缺省情况下, 探测报文的填充内容为十六进制数值 缺省情况下, 一次 UDP-jitter 探测中发送 10 个探测报文 缺省情况下,UDP-jitter 测试中发送探测报文的时间间隔为 20 毫秒 缺省情况下,UDP-jitter 测试中等待响应报文的超时时间为 3000 毫秒 ( 可选 ) 配置探测报文的源 IP 地址 source ip ip-address 缺省情况下, 未指定源 IP 地址 该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 display nqa history 命令的显示信息无法反映 UDP-jitter 测试的结果, 如果想了解 UDP-jitter 测试的结果, 建议通过 display nqa result 命令查看最近一次 NQA 测试的当前结果, 或通过 display nqa statistics 命令查看 NQA 测试的统计信息 配置 SNMP 测试 SNMP 查询测试主要用来测试从 NQA 客户端向 SNMP agent 设备发出一个 SNMP 协议查询报文到接收响应报文的时间 表 1-12 配置 SNMP 测试 操作命令说明进入系统视图 system-view

29 操作命令说明 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 SNMP, 并进入测试类型视图 type snmp - 配置测试操作中探测报文的目的地址 destination ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 ( 可选 ) 配置探测报文的源端口号 source port port-number 缺省情况下, 未指定源端口号 ( 可选 ) 配置探测报文的源 IP 地址 source ip ip-address 缺省情况下, 未指定源 IP 地址 该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 配置 TCP 测试 TCP 测试用来测试客户端和服务器指定端口之间是否能够建立 TCP 连接, 以及建立 TCP 连接所需的时间, 从而判断服务器指定端口上提供的服务是否可用, 及服务性能 TCP 测试需要 NQA 服务器和客户端配合才能完成 在 TCP 测试之前, 需要在 NQA 服务器端配置 TCP 监听功能, 配置方法请参见 1.3 配置 NQA 服务器 表 1-13 配置 TCP 测试 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 TCP, 并进入测试类型视图 type tcp - 配置测试操作中探测报文的目的地址 配置测试操作的目的端口 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 destination ip ip-address destination port port-number source ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址必须与 NQA 服务器上配置的监听服务的 IP 地址一致 缺省情况下, 未配置测试操作的目的端口号必须与 NQA 服务器上配置的监听服务的端口号一致 缺省情况下, 未配置测试操作中探测报文的源 IP 地址该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 1-13

30 配置 UDP-echo 测试 UDP-echo 测试可以用来测试客户端和服务器指定 UDP 端口之间的连通性以及 UDP 报文的往返时间 UDP-echo 测试需要 NQA 服务器和客户端配合才能完成 在进行 UDP-echo 测试之前, 需要在 NQA 服务器端配置 UDP 监听功能, 配置方法请参见 1.3 配置 NQA 服务器 表 1-14 配置 UDP-echo 测试 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 UDP-echo, 并进入测试类型视图 type udp-echo - 配置测试操作中探测报文的目的地址 配置测试操作的目的端口 ( 可选 ) 配置发送的探测报文中的填充内容大小 ( 可选 ) 配置发送的探测报文的填充字符串 destination ip ip-address destination port port-number data-size size data-fill string 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 必须与 NQA 服务器上配置的监听服务的 IP 地址一致 缺省情况下, 未配置测试操作的目的端口号必须与 NQA 服务器上配置的监听服务的端口号一致 缺省情况下,UDP-echo 测试中发送的探测报文中的填充内容大小为 100 字节 缺省情况下, 探测报文的填充内容为十六进制数值 ( 可选 ) 配置探测报文的源端口号 source port port-number 缺省情况下, 未指定源端口号 ( 可选 ) 配置测试操作的探测报文的源 IP 地址 source ip ip-address 缺省情况下, 未配置测试操作中探测报文的源 IP 地址该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 配置 UDP-tracert 测试 UDP-tracert 测试的功能是发现原端到目的端之间的路径信息 UDP-tracert 测试和普通 Tracert 流程一致, 由原端发送一个目的端口不可达的报文, 当目的端收到该报文后, 会回复原端一个端口不可达报文, 以便使源端知道 Tracert 测试结束 配置 UDP-tracert 测试需要在中间设备 ( 源端与目的端之间的设备 ) 上开启 ICMP 超时报文发送功能 如果中间设备是 H3C 设备, 需要在设备上执行 ip ttl-expires enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) 需要在目的端开启 ICMP 目的不可达报文发送功能 如果目的端是 H3C 设备, 需要在设备上执行 ip unreachables enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) 1-14

31 表 1-15 配置 UDP-tracert 测试 操作命令说明 进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 UDP-tracert, 并进入测试类型视图 type udp-tracert - 配置测试操作中探测报文的目的地址 destination ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 ( 可选 ) 配置测试操作的目的端口 destination port port-number 缺省情况下, 测试操作的目的端口号为 该端口号必须配置成一个对端设备上未启用的端口号, 这样对端设备会回复目的端口不可达的 ICMP 差错报文 ( 可选 ) 配置发送的探测报文中的填充内容大小 ( 可选 ) 配置探测的禁止报文分片功能 data-size size no-fragment enable 缺省情况下,UDP-tracert 测试中发送的探测报文中的填充内容大小为 100 字节 缺省情况下, 禁止报文分片功能处于关闭状态 ( 可选 ) 配置测试最大连续失败次数 max-failure value 缺省情况下, 最大失败次数为 5 ( 可选 ) 配置发送的探测报文的初始跳数 ( 可选 ) 配置探测报文的出接口 init-ttl value out interface interface-type interface-number 缺省情况下,UDP-tracert 测试中探测报文初始跳数为 1 缺省情况下, 未指定探测报文的出接口设备通过查询路由表信息确认报文出接口 ( 可选 ) 配置探测报文的源端口号 source port port-number 缺省情况下, 未指定源端口号 ( 可选 ) 配置使用指定接口的 IP 地址作为探测报文的源 IP 地址 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 source interface interface-type interface-number source ip ip-address 缺省情况下, 未配置测试操作中探测报文的源 IP 地址, 以报文发送接口的主 IP 地址作为探测报文中的源 IP 地址 source ip 命令和 source interface 命令是互相覆盖的关系, 新的配置会覆盖已有配置 source interface 命令指定的接口必须为 up 状态 ;source ip 命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试会失败 UDP-tracert 测试不支持在 IPv6 网络中使用, 如果要测试 IPv6 网络中目的主机的可达性, 可以使用 tracert ipv6 命令 tracert ipv6 命令的详细介绍, 请参见 网络管理和监控命令参考 中的 系统维护与调试 1-15

32 配置 Voice 测试 建议不要对知名端口, 即 1~1023 之间的端口, 进行 Voice 测试, 否则可能导致 NQA 测试失败或 该知名端口对应的服务不可用 Voice 测试主要用来测试 VoIP(Voice over IP, 在 IP 网络上传送语音 ) 网络情况, 统计 VoIP 网络参数, 以便用户根据网络情况进行相应的调整 Voice 测试的过程如下 : (1) 源端 (NQA 客户端 ) 以一定的时间间隔向目的端 (NQA 服务器 ) 发送 G.711 A 律 G.711 µ 律或 G.729 A 律编码格式的语音数据包 (2) 目的端收到语音数据包后, 为它打上时间戳, 并把带有时间戳的数据包发送给源端 (3) 源端收到数据包后, 根据数据包上的时间戳等信息, 计算出时延抖动 单向延迟等网络参数, 从而清晰地反映出网络状况 除了时延抖动等参数,Voice 测试还可以计算出反映 VoIP 网络状况的语音参数值 : ICPIF(Calculated Planning Impairment Factor, 计算计划损伤元素 ): 用来量化网络中语音数据的衰减, 由单向网络延迟和丢包率等决定 数值越大, 表明语音网络质量越差 MOS(Mean Opinion Scores, 平均意见得分 ): 语音网络的质量得分 MOS 值的范围为 1~ 5, 该值越高, 表明语音网络质量越好 通过计算网络中语音数据的衰减 ICPIF 值, 可以估算出 MOS 值 用户对语音质量的评价具有一定的主观性, 不同用户对语音质量的容忍程度不同, 因此, 衡量语音质量时, 需要考虑用户的主观因素 对语音质量容忍程度较强的用户, 可以通过 advantage-factor 命令配置补偿因子, 在计算 ICPIF 值时将减去该补偿因子, 修正 ICPIF 和 MOS 值, 以便在比较语音质量时综合考虑客观和主观因素 Voice 测试需要 NQA 服务器和客户端配合才能完成 进行 Voice 测试之前, 必须保证 NQA 服务器端配置了 UDP 监听功能, 配置方法请参见 1.3 配置 NQA 服务器 表 1-16 配置 Voice 测试操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 Voice, 并进入测试类型视图 type voice - 配置测试操作中探测报文的目的地址 destination ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址测试操作的目的地址必须与 NQA 服务器上所配置的监听服务的 IP 地址一致 1-16

33 操作命令说明 配置测试操作的目的端口 ( 可选 ) 配置 Voice 测试的编码格式 destination port port-number codec-type { g711a g711u g729a } 缺省情况下, 未配置测试操作的目的端口号测试操作的目的端口号必须与 NQA 服务器上所配置的监听服务的端口号一致 缺省情况下, 语音编码格式为 G.711 A 律 ( 可选 ) 配置用于计算 MOS 值和 ICPIF 值的补偿因子 advantage-factor factor 缺省情况下, 补偿因子取值为 0 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 source ip ip-address 缺省情况下, 未配置测试操作中探测报文的源 IP 地址 该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 ( 可选 ) 配置探测报文的源端口号 source port port-number 缺省情况下, 未指定源端口号 ( 可选 ) 配置发送的探测报文中的填充内容大小 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置一次 Voice 探测中发送探测报文的个数 ( 可选 ) 配置 Voice 探测中发送探测报文的时间间隔 ( 可选 ) 配置 Voice 测试中等待响应报文的超时时间 data-size size data-fill string probe packet-number packet-number probe packet-interval packet-interval probe packet-timeout packet-timeout 缺省情况下, 发送的探测报文中的填充内容大小与配置的编码格式有关, 编码格式为 g.711a 和 g.711u 时缺省报文大小为 172 字节,g.729a 时为 32 字节 缺省情况下, 探测报文的填充内容为十六进制数值 缺省情况下, 一次 Voice 探测中发送 1000 个探测报文 缺省情况下,Voice 探测中发送探测报文的时间间隔为 20 毫秒 缺省情况下,Voice 测试中等待响应报文的超时时间为 5000 毫秒 display nqa history 命令的显示信息无法反映 Voice 测试的结果, 如果想了解 Voice 测试的结果, 建议通过 display nqa result 命令查看最近一次 NQA 测试的当前结果, 或通过 display nqa statistics 命令查看 NQA 测试的统计信息 配置 DLSw 测试 DLSw 测试主要用来测试 DLSw 设备的响应时间 1-17

34 表 1-17 配置 DLSw 测试 操作命令说明 进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 DLSw, 并进入测试类型视图 type dlsw - 配置测试操作中探测报文的目的地址 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 destination ip ip-address source ip ip-address 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 缺省情况下, 未配置测试操作中探测报文的源 IP 地址该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则测试将会失败 配置 Path-jitter 测试 Path-jitter 测试可以作为 UDP-jitter 测试的一种补充, 用于在抖动比较大的情况下, 进一步探测中间路径的网络质量, 以便查找出网络质量差的具体路段 Path-jitter 测试的过程如下 : (1) NQA 客户端使用 tracert 机制发现到达目的地址的路径信息 (2) NQA 客户端根据 tracert 结果, 逐跳使用 ICMP 机制探测从本机至该跳设备的路径上报文是否有丢失, 同时计算该跳路径的时延和时延抖动等信息 配置 Path-jitter 测试需要在中间设备 ( 源端与目的端之间的设备 ) 上开启 ICMP 超时报文发送功能 如果中间设备是 H3C 设备, 需要在设备上执行 ip ttl-expires enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) 需要在目的端开启 ICMP 目的不可达报文发送功能 如果目的端是 H3C 设备, 需要在设备上执行 ip unreachables enable 命令 ( 该命令的详细介绍请参见 三层技术 -IP 业务命令参考 中的 IP 性能优化 ) 表 1-18 配置 Path-jitter 测试操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 配置测试类型为 Path-jitter, 并进入测试类型视图 type path-jitter - 配置测试操作中探测报文的目的地址 ( 可选 ) 配置发送的探测报文中的填充内容大小 destination ip ip-address data-size size 缺省情况下, 未配置测试操作中探测报文的目的 IP 地址 缺省情况下, 发送的探测报文中的填充内容大小为 100 字节 1-18

35 操作命令说明 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置测试操作中探测报文的源 IP 地址 ( 可选 ) 配置一次 Path-jitter 探测中发送探测报文的个数 data-fill string source ip ip-address probe packet-number packet-number 缺省情况下, 探测报文的填充内容为十六进制数值 缺省情况下, 未配置测试操作中探测报文的源 IP 地址该命令指定的源 IP 地址必须是设备上接口的 IP 地址, 且接口为 up 状态, 否则探测将会失败 缺省情况下, 一次 Path-jitter 探测中发送 10 个 ICMP 探测报文 ( 可选 ) 配置 Path-jitter 测试中发送探测报文的时间间隔 probe packet-interval packet-interval 缺省情况下,Path-jitter 测试中发送探测报文的时间间隔为 20 毫秒 ( 可选 ) 配置 Path-jitter 测试中等待响应报文的超时时间 probe packet-timeout packet-timeout 缺省情况下,Path-jitter 测试中等待响应报文的超时时间为 3000 毫秒 ( 可选 ) 配置松散路由 lsr-path ip-address&<1-8> 缺省情况下, 未配置松散路由 ( 可选 ) 配置仅对目的地址探测 target-only 缺省情况下, 未配置仅对目的地址探测, Path-jitter 测试中会逐跳进行探测 通过 lsr-path 命令配置松散路由, 在 tracert 过程使用该配置进行探路,NQA 客户端根据该松散路由计算时延和时延抖动 Path-jitter 测试项对每一条路径记录结果, 在路径上的每一跳均记录抖动值 正向抖动值和负向抖动值 配置 NQA 测试组通用可选参数 NQA 测试组的通用可选参数, 只对当前测试组中的测试有效 除特别说明外, 所有测试类型都可以配置通用可选参数, 可以根据实际情况选择配置测试组的参数 表 1-19 配置 NQA 测试组的通用可选参数 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 进入测试组测试类型视图 nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo path-jitter snmp tcp udp-echo udp-jitter udp-tracert voice } 缺省情况下, 设备上不存在任何 NQA 测试组

36 操作命令说明 ( 可选 ) 配置测试组的描述字符串 description text 缺省情况下, 测试组没有描述字符串 ( 可选 ) 配置测试组连续两次测试开始时间的时间间隔 ( 可选 ) 配置一次 NQA 测试中进行探测的次数 frequency interval probe count times 缺省情况下,Voice Path-jitter 测试中连续两次测试开始时间的时间间隔为 毫秒 ; 其他类型的测试中连续两次测试开始时间的时间间隔为 0 毫秒, 即只进行一次测试如果到达 frequency 指定的时间间隔时, 上次测试尚未完成, 则不启动新一轮测试 缺省情况下, 对于 UDP-tracert 测试类型, 对于一个 TTL 值的节点发送的探测报文次数为 3 次 ; 其他类型的 NQA 测试一次测试中的探测次数为 1 次 Voice 和 Path-jitter 测试中探测次数只能为 1, 不支持该命令 ( 可选 ) 配置 NQA 探测超时时间 probe timeout timeout 缺省情况下, 探测的超时时间为 3000 毫秒 UDP-jitter Voice 和 Path-jitter 测试不能配置该参数 ( 可选 ) 配置探测报文在网络中可以经过的最大跳数 ( 可选 ) 配置 NQA 探测报文 IP 报文头中服务类型域的值 ttl value tos value 缺省情况下,UDP-tracert 测试探测报文在网络中可以经过的最大跳数为 30 跳 其他类型的探测报文在网络中可以经过的最大跳数为 20 跳 DHCP 和 Path-jitter 测试不能配置该参数 缺省情况下,NQA 探测报文 IP 报文头中服务类型域的值为 0 ( 可选 ) 启动路由表旁路功能 route-option bypass-route ( 可选 ) 指定测试操作所属的 VPN vpn-instance vpn-instance-name 缺省情况下, 路由表旁路功能处于关闭状态 DHCP 和 Path-jitter 测试不能配置该参数 缺省情况下, 未指定测试操作所属的 VPN 配置联动功能联动功能是通过建立联动项, 对当前所在测试组中的探测进行监测, 当连续探测失败次数达到阈值时, 就触发配置的动作类型 表 1-20 配置联动功能 操作命令说明进入系统视图 system-view

37 操作命令说明 创建 NQA 测试组, 进入 NQA 测试组视图 进入测试组测试类型视图 建立联动项 nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo } reaction item-number checked-element probe-fail threshold-type consecutive consecutive-occurrences action-type trigger-only 缺省情况下, 设备上不存在任何 NQA 测试组 UDP-jitter UDP-tracert Voice 和 Path-jitter 测试不支持联动功能 缺省情况下, 未配置联动项 退回系统视图 quit - 配置 Track 与 NQA 联动 配置 Track 与应用模块联动 配置方法请参见 可靠性配置指导 中的 Track 配置方法请参见 可靠性配置指导 中的 Track - - 联动项创建后, 不能再通过 reaction 命令修改该联动项的内容 配置阈值告警功能通过 snmp-agent target-host 命令配置 Trap 消息的目的地址 snmp-agent target-host 命令的详细介绍, 请参见 网络管理和监控命令参考 中的 SNMP 表 1-21 配置阈值告警功能 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 进入测试组测试类型视图 配置在指定条件下向网管服务器发送 Trap 消息 创建监测探测持续时间的阈值告警组 ( 除 UDP-jitter 和 Voice 测试外, 均支持 ) nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-jitter udp-tracert voice } reaction trap { path-change probe-failure consecutive-probe-failures test-complete test-failure [ cumulate-probe-failures ] } reaction item-number checked-element probe-duration threshold-type { accumulate accumulate-occurrences average consecutive consecutive-occurrences } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] 缺省情况下, 设备上不存在任何 NQA 测试组 Path-jitter 测试不支持配置阈值告警功能 缺省情况下, 不向网管服务器发送 Trap 消息 根据实际需要, 选择配置发送 Trap 消息的方法 1-21

38 操作命令说明 创建监测探测失败次数的阈值告警组 ( 除 UDP-jitter 和 Voice 测试外, 均支持 ) 创建监测报文往返时延的阈值告警组 ( 仅 UDP-jitter 和 Voice 测试支持 ) 创建监测每次测试中丢包数的阈值告警组 ( 仅 UDP-jitter 和 Voice 测试支持 ) 创建监测单向时延抖动的阈值告警组 ( 仅 UDP-jitter 和 Voice 测试支持 ) 创建监测单向时延的阈值告警组 ( 仅 UDP-jitter 和 Voice 测试支持 ) 创建监测 Voice 测试 ICPIF 值的阈值告警组 ( 仅 Voice 测试支持 ) 创建监测 Voice 测试 MOS 值的阈值告警组 ( 仅 Voice 测试支持 ) reaction item-number checked-element probe-fail threshold-type { accumulate accumulate-occurrences consecutive consecutive-occurrences } [ action-type { none trap-only } ] reaction item-number checked-element rtt threshold-type { accumulate accumulate-occurrences average } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] reaction item-number checked-element packet-loss threshold-type accumulate accumulate-occurrences [ action-type { none trap-only } ] reaction item-number checked-element { jitter-ds jitter-sd } threshold-type { accumulate accumulate-occurrences average } threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] reaction item-number checked-element { owd-ds owd-sd } threshold-value upper-value lower-value reaction item-number checked-element icpif threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] reaction item-number checked-element mos threshold-value upper-threshold lower-threshold [ action-type { none trap-only } ] DNS 测试不支持发送 Trap 消息, 即对于 DNS 测试, 触发动作只能配置为 none 在 UDP-jitter Voice 测试类型视图下执行 reaction trap 命令时, 只支持 reaction trap test-complete UDP-tracert 测试支持 reaction trap path-change reaction trap test-complete 和 reaction trap test-failure 配置 NQA 统计功能 NQA 将在指定时间间隔内完成的 NQA 测试归为一组, 计算该组测试结果的统计值, 这些统计值构成一个统计组 通过 display nqa statistics 命令可以显示该统计组的信息 通过 statistics interval 命令可以设置统计的时间间隔 1-22

39 当 NQA 设备上保留的统计组数目达到最大值时, 如果形成新的统计组, 保存时间最久的统计组将被删除 通过 statistics max-group 命令可以设置保留的最大统计组个数 统计组具有老化功能, 即统计组保存一定时间后, 将被删除 通过 statistics hold-time 命令可以设置统计组的保存时间 表 1-22 配置 NQA 统计功能操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 进入测试组测试类型视图 ( 可选 ) 配置对测试结果进行统计的时间间隔 ( 可选 ) 配置能够保留的最大统计组个数 nqa entry admin-name operation-tag type { dhcp dlsw dns ftp http icmp-echo path-jitter snmp tcp udp-echo udp-jitter voice } statistics interval interval statistics max-group number 缺省情况下, 设备上不存在任何 NQA 测试组 - 缺省情况下, 对测试结果进行统计的时间间隔为 60 分钟 缺省情况下, 能够保留的最大统计组数为 2 最大统计组个数为 0 时, 不进行统计 ( 可选 ) 配置统计组的保留时间 statistics hold-time hold-time 缺省情况下, 统计组的保留时间为 120 分钟 UDP-tracert 测试不支持配置 NQA 统计功能 如果通过 frequency 命令指定连续两次测试开始时间的时间间隔为 0, 则不生成统计组信息 配置 NQA 历史记录功能开启 NQA 测试组的历史记录保存功能后, 系统将记录 NQA 测试的历史信息, 通过 display nqa history 命令可以查看该测试组的历史记录信息 通过本配置任务还可以指定 : 历史记录的保存时间 : 历史记录保存时间达到配置的值后, 该历史记录将被删除 一个测试组中能够保存的最大历史记录个数 : 如果历史记录个数超过设定的最大数目, 则最早的历史记录将会被删除 表 1-23 配置 NQA 历史记录功能 操作命令说明进入系统视图 system-view - 创建 NQA 测试组, 进入 NQA 测试组视图 nqa entry admin-name operation-tag 缺省情况下, 设备上不存在任何 NQA 测试组 1-23

40 操作命令说明 进入测试组测试类型视图 开启 NQA 测试组的历史记录保存功能 ( 可选 ) 配置 NQA 测试组中历史记录的保存时间 ( 可选 ) 配置在一个测试组中能够保存的最大历史记录个数 type { dhcp dlsw dns ftp http icmp-echo snmp tcp udp-echo udp-tracert } history-record enable history-record keep-time keep-time history-record number number UDP-jitter Voice 和 Path-jitter 测试不支持配置历史记录 缺省情况下,UDP-tracert 类型测试组的历史记录保存功能处于开启状态, 其他类型的 NQA 测试组的历史记录保存功能处于关闭状态 缺省情况下,NQA 测试组中历史记录的保存时间为 120 分钟 缺省情况下, 一个测试组中能够保存的最大历史记录个数为 在 NQA 客户端上调度 NQA 测试组 通过本配置, 可以设置测试组进行测试的启动时间和持续时间 系统时间在 < 启动时间 > 到 < 启动时间 + 持续时间 > 范围内时, 测试组进行测试 执行 nqa schedule 命令时 : 如果系统时间尚未到达启动时间, 则到达启动时间后, 启动测试 ; 如果系统时间在 < 启动时间 > 到 < 启动时间 + 持续时间 > 之间, 则立即启动测试 ; 如果系统时间已经超过 < 启动时间 + 持续时间 >, 则不会启动测试 通过 display clock 命令可以查看系统的当前时间 若配置了 recurring, 则指定测试组每天都被调度运行 每天启动测试的时间由 < 启动时间 > 参数指定 表 1-24 在 NQA 客户端上调度 NQA 测试组操作命令说明进入系统视图 system-view - 在 NQA 客户端上调度 NQA 测试组 nqa schedule admin-name operation-tag start-time { hh:mm:ss [ yyyy/mm/dd mm/dd/yyyy ] now } lifetime { lifetime forever } [ recurring ] - 测试组被调度后就不能再进入该测试组视图和测试类型视图 对于已启动的测试组或已经完成测试的测试组, 不受系统时间调整的影响, 只有等待测试的测试组受系统时间调整的影响 1-24

41 1.7 在 NQA 客户端上配置 NQA 模板 NQA 模板是一组测试参数的集合 ( 如测试目的地址 测试目的端口 测试目标服务器的 URL 等 ) NQA 模板供外部特性 ( 如负载均衡的健康检测功能 ) 调用, 可以为外部特性提供测试数据, 以便其进行相应处理 NQA 模板通过模板名唯一标识 在一台设备上可以创建多个 NQA 模板 目前 NQA 模板支持 ICMP DNS HTTP TCP FTP 等测试类型 对于 NQA 各类型模板, 某些测试参数既可以由外部特性提供 ( 如负载均衡 ), 也可以手工直接进 行配置 若同时通过以上两种方式获取到测试参数, 则以手工配置的测试信息为准 NQA 模板配置任务简介 表 1-25 NQA 测试组配置任务简介 配置任务说明详细配置 配置 ICMP 类型的 NQA 模板 配置 DNS 类型的 NQA 模板 配置 TCP 类型的 NQA 模板 至少选其一 配置 UDP 类型的 NQA 模板 配置 HTTP 类型的 NQA 模板 配置 FTP 类型的 NQA 模板 配置 NQA 模板通用参数 可选 配置 ICMP 类型的 NQA 模板 ICMP 类型的 NQA 模板为外部特性提供 ICMP 类型的测试, 外部特性通过引用该模板来启动 ICMP 测试, 并根据是否接收到 ICMP 应答报文判断目的主机的可达性 ICMP 类型的 NQA 模板支持 IPv4 和 IPv6 网络 表 1-26 配置 ICMP 类型的 NQA 模板 操作命令说明进入系统视图 system-view - 创建 ICMP 类型的 NQA 模板, 并进入模板视图 nqa template icmp name - 配置测试操作的目的地址 配置测试操作中探测报文的目的 IPv4 地址 destination ip ip-address 两者选其一缺省情况下, 未配置测试操作中探 1-25

42 操作命令说明 配置测试操作中探测报文的目的 IPv6 地址 ( 可选 ) 配置发送的探测报文中的填充内容大小 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置使用指定接口的 IP 地址作为 ICMP-echo 测试中探测报文的源 IP 地址 destination ipv6 ipv6-address data-size size data-fill string source interface interface-type interface-number 测报文的目的地址 缺省情况下, 发送的探测报文中的填充内容大小为 100 字节 缺省情况下, 探测报文的填充内容为十六进制数值 缺省情况下, 未指定测试中探测报文的源 IP 地址, 以报文发送接口的主 IP 地址作为探测报文中的源 IP 地址 source interface 命令指定的接口必须为 up 状态 source ip 命令或 source ipv6 命令, 和 source interface 命令是互相覆盖的关系, 新的配置会覆盖已有配置 ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 up 状态, 否则测试将会失败 配置 DNS 类型的 NQA 模板 DNS 类型的 NQA 模板为外部特性提供 DNS 类型的测试 外部特性通过引用该模板来启动 DNS 测试,NQA 客户端向指定的 DNS 服务器发送 DNS 请求报文,NQA 客户端通过是否收到应答及应答报文的合法性来确定服务器的状态 DNS 类型的 NQA 模板支持 IPv4 和 IPv6 网络 在 DNS 类型的 NQA 模板视图下, 用户可以配置期望返回的地址 如果 DNS 服务器返回的 IP 地址中包含了期望地址, 则该 DNS 服务器为真实的服务器, 测试成功 ; 否则, 测试失败 在进行 DNS 测试之前, 需要在 DNS 服务器上创建域名和地址的映射关系 DNS 服务器配置方法, 请参见 三层技术 -IP 业务配置指导 中的 域名解析 表 1-27 配置 DNS 类型的 NQA 模板 操作命令说明进入系统视图 system-view - 创建 DNS 类型的 NQA 模板, 并进入模板视图 nqa template dns name - 配置测试操作的目的地址 配置测试操作中探测报文的目的 IPv4 地址 destination ip ip-address 二者选其一缺省情况下, 未配置测试操作中 1-26

43 操作命令说明 配置测试操作中探测报文的目的 IPv6 地址 destination ipv6 ipv6-address 探测报文的目的地址 ( 可选 ) 配置测试操作的目的端口号 destination port port-number 缺省情况下, 操作的目的端口号为 53 配置要解析的域名 resolve-target domain-name 缺省情况下, 没有配置要解析的域名 配置域名解析类型 resolve-type { A AAAA } 缺省情况下, 域名解析类型为 A 类型其中 A 类型表示将域名解析为 IPv4 地址,AAAA 类型表示将域名解析为 IPv6 地址 ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 up 状态, 否则测试将会失败 ( 可选 ) 配置测试操作中探测报文的源端口号 source port port-number 缺省情况下, 未配置探测报文的源端口号 ( 可选 ) 配置用户期望返回的地址 配置用户期望返回的 IPv4 地址 配置用户期望返回的 IPv6 地址 expect ip ip-address expect ipv6 ipv6-address 二者选其一缺省情况下, 未设定期望返回的地址 配置 TCP 类型的 NQA 模板 TCP 类型的 NQA 模板为外部特性提供 TCP 类型测试, 外部特性通过引用该模板, 测试客户端和服务器指定端口之间能否建立 TCP 连接 NQA 客户端通过处理服务器端的应答报文, 判断服务器指定端口上提供的服务是否可用 在 TCP 类型的 NQA 模板视图下, 用户可以配置期望的应答内容 如果用户未配置期望的应答内容, 则 NQA 客户端与服务器间只建立 TCP 连接 TCP 测试需要 NQA 服务器和客户端配合才能完成 在 TCP 测试之前, 需要在 NQA 服务器端配置 TCP 监听功能 表 1-28 配置 TCP 类型的 NQA 模板 操作命令说明进入系统视图 system-view - 创建 TCP 类型的 NQA 模板, 并进入模板视图 nqa template tcp name - 配置测试操作的目的地 配置测试操作中探测报文的目的 IPv4 地址 destination ip ip-address 两者选其一缺省情况下, 未配置测试操作中 1-27

44 操作命令说明 址 探测报文的目的地址 配置测试操作中探测报文的目的 IPv6 地址 destination ipv6 ipv6-address 必须与 NQA 服务器上配置的监听服务的 IP 地址一致, 否则探测会失败 配置测试操作的目的端口号 ( 可选 ) 配置发送的探测报文的填充字符串 destination port port-number data-fill string 缺省情况下, 未配置测试操作的目的端口号必须与 NQA 服务器上配置的监听服务的端口号一致 缺省情况下, 探测报文的填充内容为十六进制数值 ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 up 状态, 否则测试将会失败 ( 可选 ) 配置用户期望的应答内容 expect data expression [ offset number ] 缺省情况下,, 未配置期望的应答内容仅当 data-fill 和 expect data 命令都配置时, 进行期望应答内容的检查, 否则不做检查 配置 UDP 类型的 NQA 模板 UDP 类型的 NQA 模板为外部特性提供 UDP 类型测试, 外部特性通过引用该模板, 测试客户端和服务器指定端口之间 UDP 传输的联通性 NQA 客户端通过处理服务器端的应答报文, 判断服务器指定端口上提供的服务是否可用 在 UDP 类型的 NQA 模板视图下, 用户可以配置期望的应答内容 如果用户未配置期望的应答内容, 则 NQA 客户端只要收到合法的回应报文就认为探测成功 UDP 测试需要 NQA 服务器和客户端配合才能完成 在进行 UDP 测试前, 需要在 NQA 服务器端配置 UDP 监听服务 表 1-29 配置 UDP 类型的 NQA 模板操作命令说明进入系统视图 system-view - 创建 UDP 类型的 NQA 模板, 并进入模板视图 nqa template udp name - 配置测试操作的目的地址 配置测试操作中探测报文的目的 IPv4 地址 配置测试操作中探测报文的目的 IPv6 地址 destination ip ip-address destination ipv6 ipv6-address 两者选其一缺省情况下, 未配置测试操作中探测报文的目的地址 必须与 NQA 服务器上配置的监听服务的地址一致, 否则探测会失败 1-28

45 操作命令说明 配置测试操作的目的端口号 ( 可选 ) 配置发送的探测报文的填充字符串 ( 可选 ) 配置发送的探测报文中的填充内容大小 destination port port-number data-fill string data-size size 缺省情况下, 未配置测试操作的目的端口号必须与 NQA 服务器上配置的监听服务的端口号一致 缺省情况下, 探测报文的填充内容为十六进制数值 在未配置此命令情况下配置 expect data 命令则会探测失败 缺省情况下,UDP 测试中发送的探测报文中的填充内容大小为 100 字节 ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 UP 状态, 否则测试将会失败 ( 可选 ) 配置用户期望的应答内容 expect data expression [ offset number ] 缺省情况下, 未配置期望的应答内容 配置 HTTP 类型的 NQA 模板 HTTP 类型的 NQA 模板为外部特性提供 HTTP 类型测试, 外部特性通过引用该模板, 测试 NQA 客户端是否可以与指定的 HTTP 服务器建立连接, 以及从 HTTP 服务器获取数据所需的时间, 从而判断 HTTP 服务器的连通性及性能 HTTP 类型的 NQA 模板支持用户配置期望返回的数据, 对于 HTTP 测试, 仅当应答报文中存在 Content-Length 字段, 且配置了 expect data 命令时, 才进行期望应答内容的检查, 否则不做检查, 通过该功能用户可以判断 HTTP 服务器应答报文的合法性 HTTP 类型的 NQA 模板支持配置应答状态码 HTTP 报文的应答状态码是由 3 位十进制数组成的字段, 它包含 HTTP 服务器的状态信息, 用户可以根据该状态码了解 HTTP 服务器的状态 状态码的第一位规定状态码的类型, 后两位编码没有规则 在进行 HTTP 测试之前, 需要完成 HTTP 服务器的配置 表 1-30 配置 HTTP 类型的 NQA 模板操作命令说明进入系统视图 system-view - 创建 HTTP 类型的 NQA 模板, 并进入模板视图 nqa template http name

46 操作命令说明 配置 HTTP 测试访问的目的网址 配置 HTTP 登录用户名 配置 HTTP 登录密码 url url username username password { cipher simple } password 缺省情况下, 没有配置 HTTP 测试访问的网址 url 配置形式为 或 其中 host 为远端主机的地址或主机名, port 是远端主机的端口,resource 是远端主机上的资源 缺省情况下, 未配置 HTTP 登录用户名 缺省情况下, 未配置 HTTP 登录密码 配置 HTTP 的操作方式 operation { get post raw } 缺省情况下,HTTP 操作方式为 get 操作, 即从 HTTP 服务器获取数据 如果 HTTP 操作方式为 raw 操作, 使用原始报文向服务器发送探测报文, 配置为 raw 方式时, 请求报文为 raw-request 子视图中内容 ( 可选 ) 进入 raw-request 视图 raw-request 每次进入视图后, 之前配置的报文内容将会被清除当配置 operation 为 raw 时, 必须进行本配置 ( 可选 ) 配置 HTTP 测试请求报文内容 逐个字符输入或拷贝粘贴请求报文内容 缺省情况下, 未配置 HTTP 测试请求报文内容当配置 operation 为 raw 时, 必须进行本配置 ( 可选 ) 保存输入内容并退回模板类型视图 quit - ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 up 状态, 否则测试将会失败 ( 可选 ) 配置期望的应答状态码 expect status status-list 缺省情况下, 未配置期望的应答状态码 ( 可选 ) 配置期望的应答内容 expect data expression [ offset number ] 缺省情况下, 未配置期望的应答内容 1-30

47 HTTP 报文中的 Content-Length 字段用来指明 HTTP 报文正文的长度, 不包含报头的长度 当 报文中含有该字段时, 报文中的数据部分不会出现 multipart 类型, 为纯数据部分, 这时设备支持检 查期望应答的内容 配置 FTP 类型的 NQA 模板 FTP 类型的 NQA 模板为外部特性提供 FTP 类型测试, 外部特性通过引用该模板, 与指定的 FTP 服务器建立连接, 以及与 FTP 服务器之间传送文件的时间, 从而判断 FTP 服务器的连通性及性能 在进行 FTP 测试之前, 需要在 FTP 服务器上进行相应的配置, 包括 FTP 客户端登录 FTP 服务器的用户名 密码等 FTP 服务器的配置方法, 请参见 基础配置指导 中的 FTP 和 TFTP 表 1-31 配置 FTP 类型的 NQA 模板 操作命令说明进入系统视图 system-view - 创建 FTP 类型的 NQA 模板, 并进入模板视图 nqa template ftp name - 配置 FTP 测试访问的目的网址 url url 缺省情况下, 没有配置 FTP 测试访问的网址 url 内容包括远端主机地址和文件名 当操作类型为 get 方式时, 必须在 url 中配置文件名, 当操作类型为 put 方式时, 不以该配置内容为准 url 可以配置为 :ftp://host/filename 或 ftp://host:port/filename 其中 host 为远端主机的地址或主机名, port 是远端主机的端口,resource 是远端主机上的资源 配置 FTP 的操作类型 operation { get put } 缺省情况下,FTP 操作方式为 get 操作, 即从 FTP 服务器获取文件 配置 FTP 登录用户名 username username 缺省情况下, 未配置 FTP 登录用户名 配置 FTP 登录密码 ( 可选 ) 配置 FTP 服务器和客户端传送文件的文件名 password { cipher simple } password filename filename 缺省情况下, 未配置 FTP 登录密码 缺省情况下, 未配置 FTP 服务器和客户端之间传送文件的文件名当操作类型为 put 方式时, 必须进行本配置, 当配置类型为 get 方式时, 不以该配置内容为准 配置 FTP 的数据传输方式 mode { active passive } 缺省情况下,FTP 数据传输方式为主动方式 1-31

48 操作命令说明 ( 可选 ) 配置探测报文的源地址 配置测试操作中探测报文的源 IP 地址 配置测试操作中探测报文的源 IPv6 地址 source ip ip-address source ipv6 ipv6-address 二者选其一缺省情况下, 未配置测试操作中探测报文的源地址该命令指定的源地址必须是设备上接口的地址, 且接口为 up 状态, 否则测试将会失败 配置 NQA 模板通用参数 NQA 模板的通用参数, 只对当前模板的测试有效 除特别说明外, 所有类型 NQA 模板都可以根据实际情况选择配置下列通用参数 表 1-32 配置 NQA 模板通用可选参数 操作命令说明进入系统视图 system-view - 创建 NQA 模板, 并进入模板视图 配置 NQA 模板的描述字符串 配置连续两次探测开始时间的时间间隔 配置每次探测超时时间 配置探测报文在网络中可以经过的最大跳数 配置 NQA 探测报文 IP 报文头中服务类型域的值 指定操作所属的 VPN 配置连续探测成功的次数, 当连续探测成功次数达到命令配置的数值时,NQA 客户端会把探测成功的消息发送给外部特性, 使外部特性利用 NQA 测试的结果进行相应处理 配置连续探测失败的次数, 当连续探测失败次数达到命令配置的数值时,NQA 客户端会把探测失败的消息发送给外部特性, 使外部特性利用 NQA 测试的结果进行相应处理 nqa template { dns ftp http icmp tcp udp } name description text frequency interval probe timeout timeout ttl value tos value vpn-instance vpn-instance-name reaction trigger probe-pass count reaction trigger probe-fail count - 缺省情况下, 没有配置模板的描述字符串 缺省情况下, 连续两次探测开始时间的时间间隔为 5000 毫秒 如果到达 frequency 指定的时间间隔时, 上次探测尚未完成, 则不启动新一轮探测 缺省情况下, 探测的超时时间为 3000 毫秒 缺省情况下, 探测报文在网络中可以经过的最大跳数为 20 跳 缺省情况下,NQA 探测报文 IP 报文头中服务类型域的值为 0 缺省情况下, 未指定操作所属的 VPN 缺省情况下, 连续探测成功 3 次时,NQA 客户端会把探测成功的消息发送给外部特性, 使外部特性利用 NQA 测试的结果进行相应处理 缺省情况下, 连续探测失败 3 次时,NQA 客户端会把探测失败的消息发送给外部特性, 是外部特性利用 NQA 测试的结果进行相应处理 1-32

49 1.8 NQA 显示和维护 在完成上述配置后, 在任意视图下执行 display 命令可以显示配置后 NQA 的运行情况, 通过查看显示信息验证配置的效果 表 1-33 NQA 显示和维护 操作 命令 显示 NQA 测试组的历史记录 display nqa history [ admin-name operation-tag ] 显示 NQA 阈值告警功能的当前监测结果 display nqa reaction counters [ admin-name operation-tag [ item-number ]] 显示最近一次 NQA 测试的当前结果 display nqa result [ admin-name operation-tag ] 显示 NQA 测试的统计信息 display nqa statistics [ admin-name operation-tag ] 显示服务器的状态信息 display nqa server 1.9 NQA 典型配置举例 ICMP-echo 测试配置举例 1. 组网需求使用 NQA 的 ICMP-echo 测试功能, 测试本端 (Device A) 发送的报文是否可以经过指定的下一跳设备 (Device C) 到达指定的目的端 (Device B), 以及报文的往返时间 2. 组网图图 1-3 ICMP-echo 测试组网图 1-33

50 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 ICMP-echo 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1), 并配置测试操作中探测报文的目的地址为 <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type icmp-echo [DeviceA-nqa-admin-test1-icmp-echo] destination ip # 配置下一跳地址为 , 以便测试报文经过指定的下一跳设备 (Device C) 到达目的端, 而不是通过 Device D 到达目的端 [DeviceA-nqa-admin-test1-icmp-echo] next-hop # 配置可选参数 : 一次 NQA 测试中探测的次数为 10, 探测的超时时间为 500 毫秒, 测试组连续两次测试开始时间的时间间隔为 5000 毫秒 [DeviceA-nqa-admin-test1-icmp-echo] probe count 10 [DeviceA-nqa-admin-test1-icmp-echo] probe timeout 500 [DeviceA-nqa-admin-test1-icmp-echo] frequency 5000 # 开启 NQA 历史记录保存功能, 并配置一个测试组中能够保存的最大历史记录个数为 10 [DeviceA-nqa-admin-test1-icmp-echo] history-record enable [DeviceA-nqa-admin-test1-icmp-echo] history-record number 10 [DeviceA-nqa-admin-test1-icmp-echo] quit # 启动 ICMP-echo 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 ICMP-echo 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 ICMP-echo 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 2/5/3 Square-Sum of round trip time: 96 Last succeeded probe time: :00:01.2 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 ICMP-echo 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00:

51 366 3 Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00: Succeeded :00:01.1 以上显示信息表示,Device A 发送的报文可以通过 Device C 到达 Device B; 测试过程中未发生丢 包 ; 报文的最小 最大 平均往返时间分别为 2 毫秒 5 毫秒和 3 毫秒 DHCP 测试配置举例 1. 组网需求使用 NQA 的 DHCP 测试功能, 测试 Device A 从 DHCP 服务器 Device B 申请到 IP 地址所需的时间 2. 组网图图 1-4 配置 DHCP 组网图 3. 配置步骤 # 创建 DHCP 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1), 并指定进行 DHCP 测试中探测报文的目的地址为 <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type dhcp [DeviceA-nqa-admin-test1-dhcp] destination ip # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-dhcp] history-record enable [DeviceA-nqa-admin-test1-dhcp] quit # 启动 DHCP 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 DHCP 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 DHCP 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 512/512/512 Square-Sum of round trip time: Last succeeded probe time: :56:03.2 Extended results: Packet loss ratio: 0% 1-35

52 Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 DHCP 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time Succeeded :56:03.2 以上显示信息表示,Device A 可以从 DHCP 服务器获取 IP 地址, 获取 IP 地址所需的时间为 512 毫秒 DNS 测试配置举例 1. 组网需求使用 NQA 的 DNS 测试功能, 测试 Device A 是否可以通过指定的 DNS 服务器将域名 host.com 解析为 IP 地址, 并测试域名解析所需的时间 2. 组网图图 1-5 配置 DNS 组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 DNS 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type dns # 配置测试操作中探测报文的目的地址为 DNS 服务器的 IP 地址 , 要解析的域名为 host.com [DeviceA-nqa-admin-test1-dns] destination ip [DeviceA-nqa-admin-test1-dns] resolve-target host.com # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-dns] history-record enable [DeviceA-nqa-admin-test1-dns] quit # 启动 DNS 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 DNS 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 DNS 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: 1-36

53 Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 62/62/62 Square-Sum of round trip time: 3844 Last succeeded probe time: :49:37.3 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 DNS 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 62 Succeeded :49:37.3 以上显示信息表示,Device A 可以通过指定的 DNS 服务器将域名 host.com 解析为 IP 地址, 域名解析所需的时间为 62 毫秒 FTP 测试配置举例 1. 组网需求使用 NQA 的 FTP 测试功能, 测试 Device A 是否可以和指定的 FTP 服务器 Device B 建立连接, 以及往 FTP 服务器上传一个文件的时间 登录 FTP 服务器的用户名为 admin, 密码为 systemtest, 要传送到服务器的文件名为 config.txt 2. 组网图图 1-6 配置 FTP 组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 FTP 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type ftp # 配置测试操作的目的地址为 FTP 服务器的 IP 地址 [DeviceA-nqa-admin-test1-ftp] url ftp:// # 配置探测报文的源 IP 地址为 [DeviceA-nqa-admin-test1-ftp] source ip # 配置测试执行的操作为向 FTP 服务器上传文件 config.txt [DeviceA-nqa-admin-test1-ftp] operation put 1-37

54 [DeviceA-nqa-admin-test1-ftp] filename config.txt # 配置 FTP 操作的登录用户名为 admin [DeviceA-nqa-admin-test1-ftp] username admin # 配置 FTP 操作的登录密码为 systemtest [DeviceA-nqa-admin-test1-ftp] password simple systemtest # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-ftp] history-record enable [DeviceA-nqa-admin-test1-ftp] quit # 启动 FTP 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 FTP 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 FTP 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 173/173/173 Square-Sum of round trip time: Last succeeded probe time: :07:28.6 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 FTP 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time Succeeded :07:28.6 以上显示信息表示,Device A 可以和指定的 FTP 服务器 Device B 建立连接, 向 FTP 服务器上传一个文件的时间是 173 毫秒 HTTP 测试配置举例 1. 组网需求使用 NQA 的 HTTP 测试功能, 测试是否可以和指定的 HTTP 服务器之间建立连接, 以及从 HTTP 服务器获取数据的时间 1-38

55 2. 组网图 图 1-7 HTTP 测试组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 HTTP 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type http # 配置 HTTP 测试服务器的 IP 地址为 , 访问的网址为 /index.htm [DeviceA-nqa-admin-test1-http] url # 配置 HTTP 测试的操作方式为 get 操作 (get 操作为缺省操作方式, 因此, 可以不执行本配置 ) [DeviceA-nqa-admin-test1-http] operation get # 配置 HTTP 测试使用的版本为 1.0 ( 缺省情况下使用的版本为 1.0, 因此, 可以不执行本配置 ) [DeviceA-nqa-admin-test1-http] version v1.0 # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-http] history-record enable [DeviceA-nqa-admin-test1-http] quit # 启动 HTTP 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 HTTP 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 HTTP 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 64/64/64 Square-Sum of round trip time: 4096 Last succeeded probe time: :12:47.9 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 HTTP 测试的历史记录 [DeviceA] display nqa history admin test1 1-39

56 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 64 Succeeded :12:47.9 以上显示信息表示,Device A 可以和指定的 HTTP 服务器 Device B 建立连接, 从 HTTP 服务器获 取数据的时间为 64 毫秒 UDP-jitter 测试配置举例 1. 组网需求使用 NQA 的 UDP-jitter 测试功能, 测试本端 (Device A) 和指定目的端 (Device B) 的端口 9000 之间传送报文的时延抖动 2. 组网图图 1-8 UDP-jitter 测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,UDP 端口号为 9000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo (4) 配置 Device A # 创建 UDP-jitter 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-jitter # 配置测试操作的探测报文的目的地址为 , 目的端口号为 9000 [DeviceA-nqa-admin-test1-udp-jitter] destination ip [DeviceA-nqa-admin-test1-udp-jitter] destination port 9000 # 配置可选参数 : 测试组连续两次测试开始时间的时间间隔为 1000 毫秒 [DeviceA-nqa-admin-test1-udp-jitter] frequency 1000 [DeviceA-nqa-admin-test1-udp-jitter] quit # 启动 UDP-jitter 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 UDP-jitter 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 UDP-jitter 测试中最后一次测试的当前结果 1-40

57 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 15/32/17 Square-Sum of round trip time: 3235 Last packet received time: :56:17.6 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 UDP-jitter results: RTT number: 10 Min positive SD: 4 Min positive DS: 1 Max positive SD: 21 Max positive DS: 28 Positive SD number: 5 Positive DS number: 4 Positive SD sum: 52 Positive DS sum: 38 Positive SD average: 10 Positive DS average: 10 Positive SD square-sum: 754 Positive DS square-sum: 460 Min negative SD: 1 Min negative DS: 6 Max negative SD: 13 Max negative DS: 22 Negative SD number: 4 Negative DS number: 5 Negative SD sum: 38 Negative DS sum: 52 Negative SD average: 10 Negative DS average: 10 Negative SD square-sum: 460 Negative DS square-sum: 754 One way results: Max SD delay: 15 Max DS delay: 16 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 10 Number of DS delay: 10 Sum of SD delay: 78 Sum of DS delay: 85 Square-Sum of SD delay: 666 Square-Sum of DS delay: 787 SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0 # 显示 UDP-jitter 测试的统计结果 [DeviceA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1 Start time: :56:14.0 Life time: 47 seconds Send operation times: 410 Receive response times: 410 Min/Max/Average round trip time: 1/93/19 Square-Sum of round trip time: Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error:

58 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 UDP-jitter results: RTT number: 410 Min positive SD: 3 Min positive DS: 1 Max positive SD: 30 Max positive DS: 79 Positive SD number: 186 Positive DS number: 158 Positive SD sum: 2602 Positive DS sum: 1928 Positive SD average: 13 Positive DS average: 12 Positive SD square-sum: Positive DS square-sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 30 Max negative DS: 78 Negative SD number: 181 Negative DS number: 209 Negative SD sum: 181 Negative DS sum: 209 Negative SD average: 13 Negative DS average: 14 Negative SD square-sum: Negative DS square-sum: 3030 One way results: Max SD delay: 46 Max DS delay: 46 Min SD delay: 7 Min DS delay: 7 Number of SD delay: 410 Number of DS delay: 410 Sum of SD delay: 3705 Sum of DS delay: 3891 Square-Sum of SD delay: Square-Sum of DS delay: SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: SNMP 测试配置举例 1. 组网需求使用 NQA 的 SNMP 测试功能, 测试从 Device A 发出一个 SNMP 协议查询报文到收到 SNMP agent (Device B) 响应报文所用的时间 2. 组网图图 1-9 SNMP 配置测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 配置 SNMP agent(device B) # 启动 SNMP agent 服务, 设置 SNMP 版本为 all 只读团体名为 public 读写团体名为 private <DeviceB> system-view 1-42

59 [DeviceB] snmp-agent sys-info version all [DeviceB] snmp-agent community read public [DeviceB] snmp-agent community write private (4) 配置 Device A # 创建 SNMP 类型的测试组 ( 管理员为 admin, 操作标签为 test1), 并配置测试操作的探测报文的目的地址为 SNMP agent 的 IP 地址 <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type snmp [DeviceA-nqa-admin-test1-snmp] destination ip # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-snmp] history-record enable [DeviceA-nqa-admin-test1-snmp] quit # 启动测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 SNMP 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 SNMP 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 50/50/50 Square-Sum of round trip time: 2500 Last succeeded probe time: :24:41.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 SNMP 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 50 Succeeded :24:41.1 以上显示信息表示,Device A 可以和 SNMP agent(device B) 建立连接, 从 Device A 发出一个 SNMP 协议查询报文到收到 SNMP agent 响应报文所用的时间为 50 毫秒 TCP 测试配置举例 1. 组网需求使用 NQA 的 TCP 测试功能, 测试本端 (Device A) 和指定目的端 (Device B) 的端口 9000 之间建立 TCP 连接所需的时间 1-43

60 2. 组网图 图 1-10 TCP 测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,TCP 端口号为 9000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server tcp-connect (4) 配置 Device A # 创建 TCP 类型的测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type tcp # 配置测试操作中探测报文的目的地址为 , 目的端口号为 9000 [DeviceA-nqa-admin-test1-tcp] destination ip [DeviceA-nqa-admin-test1-tcp] destination port 9000 # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-tcp] history-record enable [DeviceA-nqa-admin-test1-tcp] quit # 启动测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 TCP 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 TCP 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 13/13/13 Square-Sum of round trip time: 169 Last succeeded probe time: :27:25.1 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error:

61 Failures due to other errors: 0 # 显示 TCP 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 13 Succeeded :27:25.1 以上显示信息表示,Device A 可以与 Device B 的端口 9000 建立 TCP 连接, 建立连接所需的时间为 13 毫秒 UDP-echo 测试配置举例 1. 组网需求使用 NQA 的 UDP-echo 测试功能, 测试本端 (Device A) 和指定目的端 (Device B) 的端口 8000 之间 UDP 协议报文的往返时间 2. 组网图图 1-11 UDP-echo 测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,UDP 端口号为 8000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo (4) 配置 Device A # 创建 UDP-echo 类型的测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-echo # 配置测试操作中探测报文的目的地址为 , 目的端口号为 8000 [DeviceA-nqa-admin-test1-udp-echo] destination ip [DeviceA-nqa-admin-test1-udp-echo] destination port 8000 # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-udp-echo] history-record enable [DeviceA-nqa-admin-test1-udp-echo] quit # 启动测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever 1-45

62 # 测试执行一段时间后, 停止 UDP-echo 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 UDP-echo 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 25/25/25 Square-Sum of round trip time: 625 Last succeeded probe time: :36:17.9 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 UDP-echo 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 25 Succeeded :36:17.9 以上显示信息表示,Device A 和 Device B 的端口 8000 之间 UDP 协议报文的往返时间为 25 毫秒 UDP-tracert 测试配置举例 1. 组网需求使用 NQA 的 UDP-tracert 测试功能, 探测本端 (Device A) 到指定目的端 (Device B) 之间经过的路径信息 2. 组网图图 1-12 UDP-tracert 测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 在中间设备上配置 ip ttl-expires enable 命令, 在 Device B 上配置 ip unreachables enable 命令 (4) 配置 Device A # 创建 UDP-tracert 类型的测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type udp-tracert 1-46

63 # 配置测试操作的目的地址为 , 目的端口号为 ( 目的端口号为 是缺省操作方式, 因此, 可以不执行本配置 ) [DeviceA-nqa-admin-test1-udp-tracert] destination ip [DeviceA-nqa-admin-test1-udp-tracert] destination port # 配置可选参数 : 对一个 TTL 值的节点的探测次数为 3( 探测次数为 3 是缺省操作方式, 因此, 可以不执行本配置 ), 探测的超时时间为 500 毫秒, 测试组连续两次测试开始时间的时间间隔为 5000 毫秒 [DeviceA-nqa-admin-test1-udp-tracert] probe count 3 [DeviceA-nqa-admin-test1-udp-tracert] probe timeout 500 [DeviceA-nqa-admin-test1-udp-tracert] frequency 5000 # 配置 UDP-tracert 测试的出接口为 GigabitEthernet3/0/1 [DeviceA-nqa-admin-test1-udp-tracert] out interface gigabitethernet 3/0/1 # 开启 UDP-tracert 测试的禁止报文分片功能 [DeviceA-nqa-admin-test1-udp-tracert] no-fragment enable # 配置最大连续失败次数为 6 次, 配置初始 TTL 为 1 [DeviceA-nqa-admin-test1-udp-tracert] max-failure 6 [DeviceA-nqa-admin-test1-udp-tracert] init-ttl 1 # 启动测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 UDP-tracert 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 UDP-tracert 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 6 Receive response times: 6 Min/Max/Average round trip time: 1/1/1 Square-Sum of round trip time: 1 Last succeeded probe time: :46:06.2 Extended results: Packet loss in test: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 UDP-tracert results: TTL Hop IP Time :46: :46:06.2 # 显示 UDP-tracert 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index TTL Response Hop IP Status Time Succeeded :46: Succeeded :46: Succeeded :46: Succeeded :46: Succeeded :46:

64 Succeeded :46: Voice 测试配置举例 1. 组网需求使用 NQA 的 Voice 测试功能, 测试本端 (Device A) 和指定的目的端 (Device B) 之间传送语音报文的时延抖动和网络语音质量参数 2. 组网图图 1-13 Voice 测试组网图 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (3) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,UDP 端口号为 9000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo (4) 配置 Device A # 创建 Voice 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type voice # 配置测试操作中探测报文的目的地址为 , 目的端口号为 9000 [DeviceA-nqa-admin-test1-voice] destination ip [DeviceA-nqa-admin-test1-voice] destination port 9000 [DeviceA-nqa-admin-test1-voice] quit # 启动 Voice 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 Voice 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 Voice 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1000 Receive response times: 1000 Min/Max/Average round trip time: 31/1328/33 Square-Sum of round trip time: Last packet received time: :49:31.1 Extended results: 1-48

65 Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Voice results: RTT number: 1000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 204 Max positive DS: 1297 Positive SD number: 257 Positive DS number: 259 Positive SD sum: 759 Positive DS sum: 1797 Positive SD average: 2 Positive DS average: 6 Positive SD square-sum: Positive DS square-sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 203 Max negative DS: 1297 Negative SD number: 255 Negative DS number: 259 Negative SD sum: 759 Negative DS sum: 1796 Negative SD average: 2 Negative DS average: 6 Negative SD square-sum: Negative DS square-sum: One way results: Max SD delay: 343 Max DS delay: 985 Min SD delay: 343 Min DS delay: 985 Number of SD delay: 1 Number of DS delay: 1 Sum of SD delay: 343 Sum of DS delay: 985 Square-Sum of SD delay: Square-Sum of DS delay: SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0 Voice scores: MOS value: 4.38 ICPIF value: 0 # 显示 Voice 测试的统计结果 [DeviceA] display nqa statistics admin test1 NQA entry (admin admin, tag test1) test statistics: NO. : 1 Start time: :45:37.8 Life time: 331 seconds Send operation times: 4000 Receive response times: 4000 Min/Max/Average round trip time: 15/1328/32 Square-Sum of round trip time: Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Voice results: 1-49

66 RTT number: 4000 Min positive SD: 1 Min positive DS: 1 Max positive SD: 360 Max positive DS: 1297 Positive SD number: 1030 Positive DS number: 1024 Positive SD sum: 4363 Positive DS sum: 5423 Positive SD average: 4 Positive DS average: 5 Positive SD square-sum: Positive DS square-sum: Min negative SD: 1 Min negative DS: 1 Max negative SD: 360 Max negative DS: 1297 Negative SD number: 1028 Negative DS number: 1022 Negative SD sum: 1028 Negative DS sum: 1022 Negative SD average: 4 Negative DS average: 5 Negative SD square-sum: Negative DS square-sum: 5419 One way results: Max SD delay: 359 Max DS delay: 985 Min SD delay: 0 Min DS delay: 0 Number of SD delay: 4 Number of DS delay: 4 Sum of SD delay: 1390 Sum of DS delay: 1079 Square-Sum of SD delay: Square-Sum of DS delay: SD lost packets: 0 DS lost packets: 0 Lost packets for unknown reason: 0 Voice scores: Max MOS value: 4.38 Min MOS value: 4.38 Max ICPIF value: 0 Min ICPIF value: DLSw 测试配置举例 1. 组网需求使用 NQA 的 DLSw 测试功能, 测试 DLSw 设备的响应时间 2. 组网图图 1-14 DLSw 测试组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 DLSw 类型的测试组 ( 管理员为 admin, 操作标签为 test1), 并配置测试操作中探测报文的目的地址为 <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type dlsw [DeviceA-nqa-admin-test1-dlsw] destination ip

67 # 开启 NQA 测试组的历史记录保存功能 [DeviceA-nqa-admin-test1-dlsw] history-record enable [DeviceA-nqa-admin-test1-dlsw] quit # 启动测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 DLSw 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 DLSw 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Send operation times: 1 Receive response times: 1 Min/Max/Average round trip time: 19/19/19 Square-Sum of round trip time: 361 Last succeeded probe time: :40:27.7 Extended results: Packet loss ratio: 0% Failures due to timeout: 0 Failures due to disconnect: 0 Failures due to no connection: 0 Failures due to internal error: 0 Failures due to other errors: 0 # 显示 DLSw 测试的历史记录 [DeviceA] display nqa history admin test1 NQA entry (admin admin, tag test1) history records: Index Response Status Time 1 19 Succeeded :40:27.7 以上显示信息表示,DLSw 设备的响应时间为 19 毫秒 Path-jitter 测试配置举例 1. 组网需求使用 NQA 的 Path-jitter 测试功能, 测试本端 (Device A) 到指定目的端 (Device C) 间的网络质量情况 2. 组网图图 1-15 Path-jitter 测试组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) 1-51

68 # 在 Device B 上配置 ip ttl-expires enable 命令, 在设备 C 上配置 ip unreachables enable 命令 # 创建 Path-jitter 类型的 NQA 测试组 ( 管理员为 admin, 操作标签为 test1), 并配置测试操作中探测报文的目的地址为 <DeviceA> system-view [DeviceA] nqa entry admin test1 [DeviceA-nqa-admin-test1] type path-jitter [DeviceA-nqa-admin-test1-path-jitter] destination ip # 配置可选参数 : 测试组连续两次测试开始时间的时间间隔为 毫秒 [DeviceA-nqa-admin-test1-path-jitter] frequency [DeviceA-nqa-admin-test1-path-jitter] quit # 启动 Path-jitter 测试操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever # 测试执行一段时间后, 停止 Path-jitter 测试操作 [DeviceA] undo nqa schedule admin test1 # 显示 Path-jitter 测试中最后一次测试的当前结果 [DeviceA] display nqa result admin test1 NQA entry (admin admin, tag test1) test results: Hop IP Basic Results Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 9/21/14 Square-Sum of round trip time: 2419 Extended Results Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors: 0 Packets out of sequence: 0 Packets arrived late: 0 Path-Jitter Results Jitter number: 9 Min/Max/Average jitter: 1/10/4 Positive jitter number: 6 Min/Max/Average positive jitter: 1/9/4 Sum/Square-Sum positive jitter: 25/173 Negative jitter number: 3 Min/Max/Average negative jitter: 2/10/6 Sum/Square-Sum positive jitter: 19/153 Hop IP Basic Results Send operation times: 10 Receive response times: 10 Min/Max/Average round trip time: 15/40/28 Square-Sum of round trip time: 4493 Extended Results Failures due to timeout: 0 Failures due to internal error: 0 Failures due to other errors:

69 Packets out of sequence: 0 Packets arrived late: 0 Path-Jitter Results Jitter number: 9 Min/Max/Average jitter: 1/10/4 Positive jitter number: 6 Min/Max/Average positive jitter: 1/9/4 Sum/Square-Sum positive jitter: 25/173 Negative jitter number: 3 Min/Max/Average negative jitter: 2/10/6 Sum/Square-Sum positive jitter: 19/ NQA 联动配置举例 1. 组网需求 Device A 到达 Device C 的静态路由下一跳为 Device B 在 Device A 上通过静态路由 Track 与 NQA 联动, 对到达 Device C 的静态路由有效性进行实时判断 2. 组网图图 1-16 NQA 联动配置组网图 Device B GE3/0/ /24 GE3/0/ /24 GE3/0/ /24 GE3/0/ /24 Device A Device C 3. 配置步骤 (1) 配置各接口的 IP 地址 ( 配置过程略 ) (2) 在 Device A 上配置静态路由, 并与 Track 项关联 # 配置到达 Device C 的静态路由下一跳地址为 , 并配置静态路由与 Track 项 1 关联 <DeviceA> system-view [DeviceA] ip route-static track 1 (3) 在 Device A 上配置 NQA 测试组 # 创建管理员名为 admin 操作标签为 test1 的 NQA 测试组 [DeviceA] nqa entry admin test1 # 配置测试类型为 ICMP-echo [DeviceA-nqa-admin-test1] type icmp-echo # 配置目的地址为 [DeviceA-nqa-admin-test1-icmp-echo] destination ip # 测试频率为 100ms 1-53

70 [DeviceA-nqa-admin-test1-icmp-echo] frequency 100 # 配置联动项 1( 连续失败 5 次触发联动 ) [DeviceA-nqa-admin-test1-icmp-echo] reaction 1 checked-element probe-fail threshold-type consecutive 5 action-type trigger-only [DeviceA-nqa-admin-test1-icmp-echo] quit # 启动 ICMP-echo 探测操作, 并一直进行测试 [DeviceA] nqa schedule admin test1 start-time now lifetime forever (4) 在 Device A 上配置 Track 项 # 配置 Track 项 1, 关联 NQA 测试组 ( 管理员为 admin, 操作标签为 test1) 的联动项 1 [DeviceA] track 1 nqa entry admin test1 reaction 1 4. 验证配置 # 显示 Device A 上 Track 项的信息 [DeviceA] display track all Track ID: 1 State: Positive Duration: 0 days 0 hours 0 minutes 0 seconds Notification delay: Positive 0, Negative 0 (in seconds) Tracked object: NQA entry: admin test1 Reaction: 1 # 显示 Device A 的路由表 [DeviceA] display ip routing-table Destinations : 13 Routes : 13 Destination/Mask Proto Pre Cost NextHop Interface /32 Direct InLoop /24 Static Vlan /24 Direct Vlan /32 Direct Vlan /32 Direct InLoop /32 Direct Vlan /8 Direct InLoop /32 Direct InLoop /32 Direct InLoop /32 Direct InLoop /4 Direct NULL /24 Direct NULL /32 Direct InLoop0 以上显示信息表示,NQA 测试的结果为下一跳地址 可达 (Track 项状态为 Positive), 配置 的静态路由生效 # 在 Device B 上删除接口 GigabitEthernet3/0/1 的 IP 地址 <DeviceB> system-view [DeviceB] interface gigabitethernet 3/0/1 [DeviceB-GigabitEthernet3/0/1] undo ip address 1-54

71 # 显示 Device A 上 Track 项的信息 [DeviceA] display track all Track ID: 1 State: Negative Duration: 0 days 0 hours 0 minutes 0 seconds Notification delay: Positive 0, Negative 0 (in seconds) Tracked object: NQA entry: admin test1 Reaction: 1 # 显示 Device A 的路由表 [DeviceA] display ip routing-table Destinations : 12 Routes : 12 Destination/Mask Proto Pre Cost NextHop Interface /32 Direct InLoop /24 Direct Vlan /32 Direct Vlan /32 Direct InLoop /32 Direct Vlan /8 Direct InLoop /32 Direct InLoop /32 Direct InLoop /32 Direct InLoop /4 Direct NULL /24 Direct NULL /32 Direct InLoop0 以上显示信息表示,NQA 测试的结果为下一跳地址 不可达 (Track 项状态为 Negative), 配置的静态路由无效 ICMP 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 ICMP 类型的 NQA 模板, 测试本端 (Device A) 发送的报文是否可以到达指定的目的端 (Device B) 1-55

72 2. 组网图 图 1-17 ICMP 类型的 NQA 模板配置组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 ICMP 类型的 NQA 模板, 模板名为 icmp, 并配置操作中探测报文的目的地址为 <DeviceA> system-view [DeviceA] nqa template icmp icmp [DeviceA-nqatplt-icmp-icmp] destination ip # 配置 ICMP 一次探测的超时时间为 500 毫秒, 连续两次探测开始时间的时间间隔为 3000 毫秒 [DeviceA-nqatplt-icmp-icmp] probe timeout 500 [DeviceA-nqatplt-icmp-icmp] frequency 3000 # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-icmp-icmp] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 是外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-icmp-icmp] reaction trigger probe-fail DNS 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 DNS 类型的 NQA 模板, 测试 Device A 是否可以通过指定的 DNS 服务器将域名 host.com 解析为 IP 地址 1-56

73 2. 组网图 图 1-18 DNS 类型的 NQA 模板配置组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 DNS 类型的 NQA 模板, 模板名为 dns <DeviceA> system-view [DeviceA] nqa template dns dns # 配置操作中探测报文的目的地址为 DNS 服务器的 IP 地址 , 要解析的域名为 host.com, 解析类型为 A, 用户期望返回的 IP 地址为 [DeviceA-nqatplt-dns-dns] destination ip [DeviceA-nqatplt-dns-dns] resolve-target host.com [DeviceA-nqatplt-dns-dns] resolve-type A [DeviceA-nqatplt-dns-dns] expect ip # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-dns-dns] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-dns-dns] reaction trigger probe-fail TCP 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 TCP 类型的 NQA 模板, 测试本端 (Device A) 和服务器 (Device B) 的端口之间能否建立 TCP 连接, 并处理服务器端的应答数据 2. 组网图图 1-19 TCP 类型的 NQA 模板配置组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) 1-57

74 (1) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,TCP 端口号为 9000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server tcp-connect (2) 配置 Device A # 创建 TCP 类型的 NQA 模板, 模板名为 tcp <DeviceA> system-view [DeviceA] nqa template tcp tcp # 配置 TCP 测试操作中探测报文的目的地址为 , 目的端口号为 9000 [DeviceA-nqatplt-tcp-tcp] destination ip [DeviceA-nqatplt-tcp-tcp] destination port 9000 # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-tcp-tcp] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-tcp-tcp] reaction trigger probe-fail UDP 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 UDP 类型的 NQA 模板, 测试本端 (Device A) 和服务器 (Device B) 的端口之间的 UDP 报文交互, 并处理服务器端的应答数据 2. 组网图图 1-20 UDP 类型的 NQA 模板配置组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) (1) 配置 Device B # 使能 NQA 服务器, 配置监听的 IP 地址为 ,UDP 端口号为 9000 <DeviceB> system-view [DeviceB] nqa server enable [DeviceB] nqa server udp-echo (2) 配置 Device A # 创建 UDP 类型的 NQA 模板, 模板名为 udp <DeviceA> system-view 1-58

75 [DeviceA] nqa template udp udp # 配置 UDP 测试操作中探测报文的目的地址为 , 目的端口号为 9000 [DeviceA-nqatplt-udp-udp] destination ip [DeviceA-nqatplt-udp-udp] destination port 9000 # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-udp-udp] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-udp-udp] reaction trigger probe-fail HTTP 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 HTTP 类型的 NQA 模板, 测试是否可以和指定的 HTTP 服务器之间建立连接, 以及能否从 HTTP 服务器获取数据 2. 组网图图 1-21 HTTP 类型的 NQA 模板配置组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 HTTP 类型的 NQA 模板, 模板名为 http <DeviceA> system-view [DeviceA] nqa template http http # 配置 HTTP 测试的目的 IP 地址为 , 访问的网址为 /index.htm [DeviceA-nqatplt-http-http] url # 配置 HTTP 测试的操作方式为 get 操作 (get 操作为缺省操作方式, 因此, 可以不执行本配置 ) [DeviceA-nqatplt-http-http] operation get # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-http-http] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-http-http] reaction trigger probe-fail

76 FTP 类型的 NQA 模板配置举例 1. 组网需求外部特性通过引用 FTP 类型的 NQA 模板, 测试 Device A 是否可以和指定的 FTP 服务器 Device B 建立连接, 以及能否往 FTP 服务器上传文件 登录 FTP 服务器的用户名为 admin, 密码为 systemtest, 要传送到服务器的文件名为 config.txt 2. 组网图 3. 配置步骤 # 配置各接口的 IP 地址 ( 配置过程略 ) # 配置静态路由或动态路由协议, 确保各设备之间路由可达 ( 配置过程略 ) # 创建 FTP 类型的 NQA 模板, 模板名为 ftp <DeviceA> system-view [DeviceA] nqa template ftp ftp # 配置操作的目的地址为 FTP 服务器的 IP 地址 [DeviceA-nqatplt-ftp-ftp] url ftp:// # 配置探测报文的源 IP 地址为 [DeviceA-nqatplt-ftp-ftp] source ip # 配置执行的操作为向 FTP 服务器上传文件 config.txt [DeviceA-nqatplt-ftp-ftp] operation put [DeviceA-nqatplt-ftp-ftp] filename config.txt # 配置登录 FTP 服务器的用户名为 admin [DeviceA-nqatplt-ftp-ftp] username admin # 配置登录 FTP 服务器的密码为 systemtest [DeviceA-nqatplt-ftp-ftp] password simple systemtest # 配置确定节点有效前需要连续探测成功的次数为 2 当连续探测成功次数达到 2 次时,NQA 客户端把探测成功的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-ftp-ftp] reaction trigger probe-pass 2 # 配置确定节点失效需要连续探测失败的次数为 2 当连续探测失败次数达到 2 次时,NQA 客户端把探测失败的消息发送给外部特性, 使外部特性能利用 NQA 测试的结果进行相应处理 [DeviceA-nqatplt-ftp-ftp] reaction trigger probe-fail

77 目录 1 NTP NTP 简介 NTP 基本工作原理 NTP 网络结构及时钟层数 NTP 的工作模式 NTP 安全功能 NTP 支持 VPN 多实例 协议规范 NTP 配置任务简介 开启 NTP 服务 配置 NTP 工作模式 配置 NTP 客户端 / 服务器模式 配置 NTP 对等体模式 配置 NTP 广播模式 配置 NTP 组播模式 配置 NTP 服务的访问控制权限 配置 NTP 验证功能 配置客户端 / 服务器模式的 NTP 验证功能 配置对等体模式的 NTP 验证功能 配置广播模式的 NTP 验证功能 配置组播模式的 NTP 验证功能 配置 NTP 可选参数 配置 NTP 报文的源接口 配置接口不处理收到的 NTP 报文 配置动态会话的最大数目 配置 NTP 报文的 DSCP 优先级 配置本地时钟作为参考时钟 NTP 显示和维护 NTP 典型配置举例 配置 NTP 客户端 / 服务器模式 配置 NTP 对等体模式 配置 NTP 广播模式 配置 NTP 组播模式 1-23 i

78 配置带验证功能的 NTP 客户端 / 服务器模式 配置带验证功能的 NTP 广播模式 配置采用客户端 / 服务器模式实现 MPLS VPN 网络的时间同步 配置采用对等体模式实现 MPLS VPN 网络的时间同步 SNTP SNTP 简介 SNTP 配置任务简介 开启 SNTP 服务 为 SNTP 客户端指定 NTP 服务器 配置 SNTP 验证功能 SNTP 显示和维护 SNTP 典型配置举例 2-3 ii

79 1 NTP 设备上不能同时配置 NTP 和 SNTP 功能 支持 NTP 的接口均为三层接口, 包括三层以太网接口 / 子接口 三层聚合接口 / 子接口 VLAN 接 口 Tunnel 接口等 1.1 NTP 简介 在大型的网络中, 如果依靠管理员手工配置来修改网络中各台设备的系统时间, 不但工作量巨大, 而且也不能保证时间的精确性 NTP(Network Time Protocol, 网络时间协议 ) 可以用来在分布式时间服务器和客户端之间进行时间同步, 使网络内所有设备的时间保持一致, 并提供较高的时间同步精度 NTP 采用的传输层协议为 UDP, 使用的 UDP 端口号为 123 这里的 分布式 指的是运行 NTP 的设备既可以与其他设备的时间同步, 又可以作为时间服务器为其他设备提供时间同步 NTP 主要应用于需要网络中所有设备的时间保持一致的场合, 比如 : 需要以时间作为参照依据, 对从不同设备采集来的日志信息 调试信息进行分析的网络管理系统 对设备时间一致性有要求的计费系统 多个系统协同处理同一个比较复杂的事件的场合 此时, 为保证正确的执行顺序, 多个系统的时间必须保持一致 NTP 基本工作原理 NTP 的基本工作原理如图 1-1 所示 Device A 和 Device B 通过网络相连,Device A 和 Device B 的时间不同, 需要通过 NTP 实现时间的自动同步 为便于理解, 作如下假设 : 在 Device A 和 Device B 的时间同步之前,Device A 的时间设定为 10:00:00 am,device B 的时间设定为 11:00:00 am Device B 作为 NTP 时间服务器, 即 Device A 与 Device B 的时间同步 NTP 报文从 Device A 到 Device B 从 Device B 到 Device A 单向传输所需要的时间均为 1 秒 Device B 处理 NTP 报文所需的时间是 1 秒 1-1

80 图 1-1 NTP 基本工作原理图 IP network Device A Device B 1. NTP message 10:00:00 am NTP message 10:00:00 am 11:00:01 am 2. NTP message 10:00:00 am 11:00:01 am 11:00:02 am 3. NTP message 10:00:00 am 11:00:01 am 11:00:02 am 4. Device A receives the NTP message at 10:00:03 am Device A 和 Device B 时间同步的工作过程如下 : (1) Device A 发送一个 NTP 报文给 Device B, 该报文带有它离开 Device A 时的时间戳, 该时间戳为 10:00:00 am(t1) (2) 当此 NTP 报文到达 Device B 时,Device B 在 NTP 报文上增加该报文到达 Device B 时的时间戳, 该时间戳为 11:00:01 am(t2) (3) 当此 NTP 报文离开 Device B 时,Device B 再在 NTP 报文上增加该报文离开 Device B 时的时间戳, 该时间戳为 11:00:02 am(t3) (4) 当 Device A 接收到该响应报文时,Device A 的本地时间为 10:00:03 am(t4) 至此,Device A 可以根据上述时间戳计算两个重要的参数 : NTP 报文的往返时延 Delay = (T4 T1) (T3 T2) = 2 秒 Device A 相对 Device B 的时间差 Offset = ((T2 T1) + (T3 T4)) / 2 = 1 小时 这样,Device A 就能够根据这些信息来设定自己的时间, 使之与 Device B 的时间同步 以上内容只是对 NTP 工作原理的一个粗略描述, 详细内容请参阅相关的协议规范 NTP 网络结构及时钟层数 NTP 通过时钟层数来定义时钟的准确度 时钟层数的取值范围为 1~16, 取值越小, 时钟准确度越高 层数为 1~15 的时钟处于同步状态 ; 层数为 16 的时钟处于未同步状态 1-2

81 图 1-2 NTP 网络结构 如图 1-2 所示, 实际网络中, 通常将从权威时钟 ( 如原子时钟 ) 获得时间同步的 NTP 服务器的层数设置为 1, 并将其作为主时间服务器, 为网络中其他设备的时钟提供时间同步 网络中的设备与主时间服务器的 NTP 距离, 即 NTP 同步链上 NTP 服务器的数目, 决定了设备上时钟的层数 例如, 从主时间服务器获得时间同步的设备的时钟层数为 2, 即比主时间服务器的时钟层数大 1; 从时钟层数为 2 的时间服务器获得时间同步的设备的时钟层数为 3, 以此类推 为了保证时间的准确性和可靠性, 可以为一台设备指定多个时间服务器, 设备根据时钟层数等参数进行时钟过滤和选择, 从多个时间服务器中选择最优的时钟, 与其同步 设备选中的时钟称为参考时钟 时钟优选过程的详细介绍, 请参阅相关的协议规范 在某些网络中, 例如无法与外界通信的孤立网络, 网络中的设备无法与权威时钟进行时间同步 此时, 可以从该网络中选择一台时钟较为准确的设备, 指定该设备与本地时钟进行时间同步, 即采用本地时钟作为参考时钟, 使得该设备的时钟处于同步状态 该设备作为时间服务器为网络中的其他设备提供时间同步, 从而实现整个网络的时间同步 NTP 的工作模式 NTP 支持以下几种工作模式 : 客户端 / 服务器模式 对等体模式 广播模式 组播模式用户可以根据需要选择一种或几种工作模式进行时间同步 各种模式的详细介绍, 如表 1-1 所示 1-3

82 表 1-1 NTP 模式介绍 模式工作过程时间同步方向应用场合 客户端 / 服务器模式 客户端上需要手工指定 NTP 服务器的地址 客户端向 NTP 服务器发送 NTP 时间同步报文 NTP 服务器收到报文后会自动工作在服务器模式, 并回复应答报文如果客户端可以从多个时间服务器获取时间同步, 则客户端收到应答报文后, 进行时钟过滤和选择, 并与优选的时钟进行时间同步 客户端能够与 NTP 服务器的时间同步 NTP 服务器无法与客户端的时间同步 如图 1-2 所示, 该模式通常用于下级的设备从上级的时间服务器获取时间同步 对等体模式 主动对等体 (Symmetric active peer) 上需要手工指定被动对等体 (Symmetric passive peer) 的地址 主动对等体向被动对等体发送 NTP 时间同步报文 被动对等体收到报文后会自动工作在被动对等体模式, 并回复应答报文如果主动对等体可以从多个时间服务器获取时间同步, 则主动对等体收到应答报文后, 进行时钟过滤和选择, 并与优选的时钟进行时间同步 主动对等体和被动对等体的时间可以互相同步 如果双方的时钟都处于同步状态, 则层数大的时钟与层数小的时钟的时间同步 如图 1-2 所示, 该模式通常用于同级的设备间互相同步, 以便在同级的设备间形成备份 如果某台设备与所有上级时间服务器的通信出现故障, 则该设备仍然可以从同级的时间服务器获得时间同步 广播模式 广播服务器周期性地向广播地址 发送 NTP 时间同步报文 广播客户端侦听来自广播服务器的广播报文, 根据接收的广播报文将设备的时间与广播服务器的时间进行同步广播客户端接收到广播服务器发送的第一个 NTP 报文后, 会与广播服务器进行报文交互, 以获得报文的往返时延, 为时间同步提供必要的参数 之后, 只有广播服务器单方向发送报文 广播客户端能够与广播服务器的时间同步 广播服务器无法与广播客户端的时间同步 广播服务器广播发送时间同步报文, 可以同时同步同一个子网中多个广播客户端的时间 如图 1-2 所示, 使用同一个时间服务器为同一个子网中的大量设备提供时间同步时, 可以使用广播模式, 以简化网络配置由于只有广播服务器单方向发送报文, 广播模式的时间准确度不如客户端 / 服务器模式和对等体模式 组播模式 组播服务器周期性地向指定的组播地址发送 NTP 时间同步报文 客户端侦听来自服务器的组播报文, 根据接收的组播报文将设备的时间与组播服务器的时间进行同步 组播客户端能够与组播服务器的时间同步 组播服务器无法与组播客户端的时间同步 组播模式对广播模式进行了扩展, 组播服务器可以同时为同一子网 不同子网的多个组播客户端提供时间同步组播模式的时间准确度不如客户端 / 服务器模式和对等体模式 本文中 NTP 服务器或服务器指的是客户端 / 服务器模式中工作在服务器模式的设备 ; 时间服务器指的是所有能够提供时间同步的设备, 包括 NTP 服务器 NTP 对等体 广播服务器和组播服务器 1-4

83 1.1.4 NTP 安全功能为了提高时间同步的安全性,NTP 提供了 NTP 服务的访问控制权限和 NTP 验证功能 1. NTP 服务的访问控制权限本功能是指利用 ACL 限制对端设备对本地设备上 NTP 服务的访问控制权限 NTP 服务的访问控制权限从高到低依次为 peer server synchronization query peer: 完全访问权限 该权限既允许对端设备向本地设备的时间同步, 对本地设备进行控制查询 ( 查询 NTP 的一些状态, 比如告警信息 验证状态 时间服务器信息等 ), 同时本地设备也可以向对端设备的时间同步 server: 服务器访问与查询权限 该权限允许对端设备向本地设备的时间同步, 对本地设备进行控制查询, 但本地设备不会向对端设备的时间同步 synchronization: 仅具有访问服务器的权限 该权限只允许对端设备向本地设备的时间同步, 但不能进行控制查询 query: 仅具有控制查询的权限 该权限只允许对端设备对本地设备的 NTP 服务进行控制查询, 但是不能向本地设备的时间同步 当设备接收到 NTP 服务请求时, 会按照权限从高到低的顺序依次进行匹配 匹配原则为 : 如果没有指定权限应用的 ACL 或权限应用的 ACL 尚未创建, 则继续匹配下一个权限 如果所有的权限都没有应用 ACL 或权限应用的 ACL 尚未创建, 则所有对端设备对本地设备 NTP 服务的访问控制权限均为 peer 如果存在应用了 ACL 的权限, 且该 ACL 已经创建, 则只有 NTP 服务请求匹配了某个权限应用的 ACL 中的 permit 规则, 发送该 NTP 服务请求的对端设备才会具有该访问控制权限 其他情况下 (NTP 服务请求匹配某个权限应用的 ACL 中的 deny 规则或没有匹配任何权限的任何规则 ), 发送该 NTP 服务请求的对端设备不具有任何权限 配置 NTP 服务的访问控制权限, 仅提供了一种最小限度的安全措施, 更安全的方法是使用 NTP 验证功能 2. NTP 验证功能在一些对时间同步的安全性要求较高的网络中, 运行 NTP 协议时需要使用 NTP 验证功能 NTP 验证功能可以用来验证接收到的 NTP 报文的合法性 只有报文通过验证后, 设备才会接收该报文, 并从中获取时间同步信息 ; 否则, 设备会丢弃该报文 从而, 保证设备不会与非法的时间服务器进行时间同步, 避免时间同步错误 图 1-3 NTP 验证功能示意图 1-5

84 如图 1-3 所示,NTP 验证功能的工作过程为 : (1) NTP 报文发送者利用密钥 ID 标识的密钥对 NTP 报文进行 MD5 运算, 并将计算出来的摘要信息连同 NTP 报文和密钥 ID 一起发送给接收者 (2) 接收者接收到该 NTP 报文后, 根据报文中的密钥 ID 找到对应的密钥, 并利用该密钥对报文进行 MD5 运算 接收者将运算结果与报文中的摘要信息比较, 如果相同, 则接收该报文 ; 否则, 丢弃该报文 NTP 支持 VPN 多实例设备作为 NTP 客户端或主动对等体时支持 VPN 多实例, 实现设备与位于 MPLS L3VPN 中的 NTP 服务器或 NTP 被动对等体进行时间同步 如下图所示, 私网 VPN 1 和 VPN 2 中的用户通过 PE(Provider Edge, 服务提供商网络边缘 ) 设备接入 MPLS 骨干网, 各 VPN 之间的业务相互隔离 配置 PE 设备工作在 NTP 客户端或 NTP 主动对等体模式, 并指定 NTP 服务器或 NTP 被动对等体所属的 VPN 后, 可以实现 PE 设备与各 VPN 中的设备进行时间同步 MPLS L3VPN VPN 实例和 PE 的详细介绍, 请参见 MPLS 配置指导 中的 MPLS L3VPN 图 1-4 NTP 支持 VPN 多实例组网应用图 目前只有单播方式 ( 客户端 / 服务器模式和对等体模式 ) 的 NTP 时间同步支持 VPN 多实例, 广播模 式和组播模式的时间同步暂时不支持 VPN 多实例 协议规范与 NTP 相关的协议规范有 : RFC 1305:Network Time Protocol (Version 3) Specification, Implementation and Analysis RFC 5905:Network Time Protocol Version 4: Protocol and Algorithms Specification 1-6

85 1.2 NTP 配置任务简介 配置 NTP 时, 需要注意 : 为保证时间同步的准确性, 不建议用户在组网中配置两个或者两个以上的时钟源, 以免造成时钟震荡, 甚至出现无法同步的情况 建议用户不要在聚合成员口上进行 NTP 相关配置 用户需要保证通过 clock protocol 命令, 配置在指定的 MDC(Multitenant Device Context, 多租户设备环境 ), 以 NTP 方式获取系统时间 有关 clock protocol 命令的详细介绍, 请参见 基础配置命令参考 中的 设备管理 只支持在编号为 1 的 MDC 上配置 NTP 功能 表 1-2 NTP 配置任务简介配置任务说明详细配置开启 NTP 服务必选 1.3 配置 NTP 工作模式 1.4 配置与网络中的其他设备进行时间同步 配置 NTP 服务的访问控制权限 配置 NTP 工作模式 和 配置 1.5 配置 NTP 验证功能 本地时钟作为参考时钟 两个配置任务中至少选择其一, 其他配 1.6 配置 NTP 可选参数 置任务请根据实际需要进行选择 1.7 配置本地时钟作为参考时钟 1.8 建议用户不要在聚合成员口上进行 NTP 相关配置 1.3 开启 NTP 服务 NTP 服务与 SNTP 服务互斥, 同一时刻只能开启其中一个服务 表 1-3 开启 NTP 客户端操作命令说明进入系统视图 system-view - 开启 NTP 服务 ntp-service enable 缺省情况下, 没有开启 NTP 服务 1-7

86 1.4 配置 NTP 工作模式 配置 NTP 客户端 / 服务器模式当设备采用客户端 / 服务器模式时, 需要在客户端上指定服务器的地址 配置 NTP 客户端 / 服务器模式时, 需要注意 : 服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式, 使得自己的时钟处于同步状态, 否则客户端不会将自己的时间与服务器的时间同步 当服务器端的时钟层数大于或等于客户端的时钟层数时, 客户端将不会与其同步 可以通过多次执行 ntp-service unicast-server 命令为设备指定多个服务器 表 1-4 配置 NTP 客户端 操作命令说明进入系统视图 system-view - 为设备指定 NTP 服务器 ntp-service unicast-server { server-name ip-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid priority source interface-type interface-number version number ] * 缺省情况下, 没有为设备指定 NTP 服务器 配置 NTP 对等体模式当设备采用对等体模式时, 需要在主动对等体上指定被动对等体的地址 配置 NTP 对等体模式时, 需要注意 : 被动对等体上需要执行 ntp-service enable 命令来开启 NTP 服务, 否则被动对等体不会处理来自主动对等体的 NTP 报文 主动对等体和被动对等体的时钟至少要有一个处于同步状态, 否则它们的时间都将无法同步 可以通过多次执行 ntp-service unicast-peer 命令为设备指定多个被动对等体 表 1-5 配置主动对等体 操作命令说明进入系统视图 system-view - 指定设备的被动对等体 ntp-service unicast-peer { peer-name ip-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid priority source interface-type interface-number version number ] * 缺省情况下, 没有为设备指定被动对等体 配置 NTP 广播模式广播服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式, 使得自己的时钟处于同步状态, 否则广播客户端不会将自己的时间与广播服务器的时间同步 当设备采用广播模式时, 广播服务器端和广播客户端上都需要进行配置 1-8

87 1. 配置广播客户端表 1-6 配置广播客户端操作 命令 说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number 进入要接收 NTP 广播报文的接口 配置设备工作在 NTP 广播客户端模式 ntp-service broadcast-client 缺省情况下, 设备没有工作在 NTP 广播客户端模式执行本命令后, 设备将通过当前接口接收 NTP 广播报文 2. 配置广播服务器 表 1-7 配置广播服务器 操作命令说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number 进入要发送 NTP 广播报文的接口 配置设备工作在 NTP 广播服务器模式 ntp-service broadcast-server [ authentication-keyid keyid version number ] * 缺省情况下, 设备没有工作在 NTP 广播服务器模式执行本命令后, 设备将通过当前接口周期性发送 NTP 广播报文 配置 NTP 组播模式 组播服务器需要通过与其他设备同步或配置本地时钟作为参考时钟等方式, 使得自己的时钟处于同步状态, 否则组播客户端不会将自己的时间与组播服务器的时间同步 设备采用组播模式时, 在组播服务器端和组播客户端上都需要进行配置 1. 配置组播客户端表 1-8 配置组播客户端操作命令说明进入系统视图 system-view - 进入接口视图 配置设备工作在 NTP 组播客户端模式 interface interface-type interface-number ntp-service multicast-client [ ip-address ] 进入要接收 NTP 组播报文的接口 缺省情况下, 设备没有工作在组播客户端模式执行本命令后, 设备将通过当前接口接收 NTP 组播报文 1-9

88 2. 配置组播服务器表 1-9 配置组播服务器操作 命令 说明 进入系统视图 system-view - 进入接口视图 配置设备工作在 NTP 组播服务器模式 interface interface-type interface-number ntp-service multicast-server [ ip-address ] [ authentication-keyid keyid ttl ttl-number version number ] * 进入要发送 NTP 组播报文的接口 缺省情况下, 设备没有工作在组播服务器模式执行本命令后, 设备将通过当前接口周期性发送 NTP 组播报文 1.5 配置 NTP 服务的访问控制权限 在配置对本地设备 NTP 服务的访问控制权限之前, 需要创建并配置与访问权限关联的 ACL ACL 的配置方法请参见 ACL 和 QoS 配置指导 中的 ACL 表 1-10 配置 NTP 服务的访问控制权限操作命令说明进入系统视图 system-view - 配置对端设备对本地设备 NTP 服务的访问控制权限 ntp-service { peer query server synchronization } acl acl-number 缺省情况下, 对端设备对本地设备 NTP 服务的访问控制权限为 peer ( 完全访问权限 ) 1.6 配置 NTP 验证功能 配置客户端 / 服务器模式的 NTP 验证功能配置客户端 / 服务器模式的 NTP 验证功能时, 需要在客户端和服务器上都使能 NTP 验证功能 配置验证密钥 将验证密钥设为可信密钥, 并在客户端上将可信密钥与 NTP 服务器关联 服务器端和客户端上配置的密钥 ID 和密钥值必须保持一致, 否则会导致 NTP 验证失败 表 1-11 配置客户端的 NTP 验证 操作命令说明进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 1-10

89 操作命令说明 配置指定密钥为可信密钥 将指定密钥与对应的 NTP 服务器关联 ntp-service reliable authentication-keyid keyid ntp-service unicast-server { server-name ip-address } [ vpn-instance vpn-instance-name ] authentication-keyid keyid 缺省情况下, 没有指定可信密钥 表 1-12 配置服务器端的 NTP 验证 操作命令说明 进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 客户端和服务器上进行不同的配置时,NTP 验证结果有所不同, 详细介绍请参见表 1-13 其中, 表格中的 - 表示不管此项是否配置 表 1-13 客户端和服务器上进行不同配置时的 NTP 验证结果 客户端 服务器 是否使能身份验证功能 是否与服务器关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是否配置验证密钥, 并将其指定为可信密钥 结果 是 是 是 是 是 是 是 是 是 否 是 是 是 否 - 是 是 否 - - 是 否 否 身份验证成功, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 1-11

90 1.6.2 配置对等体模式的 NTP 验证功能配置对等体模式的 NTP 验证功能时, 需要在主动对等体和被动对等体上都使能 NTP 验证功能 配置验证密钥 将验证密钥设为可信密钥, 并在主动对等体上将可信密钥与被动对等体关联 主动对等体和被动对等体上配置的密钥 ID 和密钥值必须保持一致, 否则会导致 NTP 验证失败 表 1-14 配置主动对等体的 NTP 验证 操作命令说明进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 将指定密钥与对应的被动对等体关联 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid ntp-service unicast-peer { ip-address peer-name } [ vpn-instance vpn-instance-name ] authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 表 1-15 配置被动对等体的 NTP 验证 操作命令说明 进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 主动对等体和被动对等体上进行不同的配置时,NTP 验证结果有所不同, 详细介绍请参见表 1-16 其中, 表格中的 - 表示不管此项是否配置 表 1-16 主动对等体和被动对等体上进行不同配置时的 NTP 验证结果 主动对等体 被动对等体 是否使能身份验证功能 是否与被动对等体关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是否配置验证密钥, 并将其指定为可信密钥 结果 不考虑主动对等体 是是是是是 身份验证成功, 可以正常收发 NTP 报文 1-12

91 主动对等体 被动对等体 和被动对等体的时钟层数 主动对等体时钟层数大于被动对等体 被动对等体时钟层数大于主动对等体 是否使能身份验证功能 是否与被动对等体关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是是是是否 是是是否 - 是否 - 是 - 是否 - 否 - 否 - - 是 - 否 - - 否 - 是是否 - - 是是否是 - 是是否否 - 是否配置验证密钥, 并将其指定为可信密钥 结果 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 配置广播模式的 NTP 验证功能配置广播模式的 NTP 验证功能时, 需要在广播客户端和广播服务器上都使能 NTP 验证功能 配置验证密钥 将验证密钥设为可信密钥, 并在广播服务器上指定与该服务器关联的密钥 广播服务器和广播客户端上配置的密钥 ID 和密钥值必须保持一致, 否则会导致 NTP 验证失败 表 1-17 配置广播客户端的 NTP 验证 操作命令说明进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 1-13

92 表 1-18 配置广播服务器端的 NTP 验证 操作命令说明 进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 进入接口视图 interface interface-type interface-number - 将指定密钥与对应的广播服务器关联 ntp-service broadcast-server authentication-keyid keyid 缺省情况下, 广播服务器没有与密钥关联 广播客户端和广播服务器上进行不同的配置时,NTP 验证结果有所不同, 详细介绍请参见表 1-19 其中, 表格中的 - 表示不管此项是否配置 表 1-19 广播客户端和广播服务器上进行不同配置时的 NTP 验证结果 广播服务器 广播客户端 是否使能身份验证功能 是否与广播服务器关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是否配置验证密钥, 并将其指定为可信密钥 结果 是 是 是 是 是 是 是 是 是 否 是 是 是 否 - 是 是 否 是 - 是 是 否 否 - 是 否 - 是 - 是 否 - 否 - 否 - - 是 - 否 - - 否 - 身份验证成功, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 1-14

93 1.6.4 配置组播模式的 NTP 验证功能配置组播模式的 NTP 验证功能时, 需要在组播客户端和组播服务器上都使能 NTP 验证功能 配置验证密钥 将验证密钥设为可信密钥, 并在组播服务器上指定与该服务器关联的密钥 组播服务器和组播客户端上配置的密钥 ID 和密钥值必须保持一致, 否则会导致 NTP 验证失败 表 1-20 配置组播客户端的 NTP 验证 操作命令说明进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 表 1-21 配置组播服务器端的 NTP 验证 操作命令说明 进入系统视图 system-view - 使能 NTP 身份验证功能 配置 NTP 身份验证密钥 配置指定密钥为可信密钥 ntp-service authentication enable ntp-service authentication-keyid keyid authentication-mode md5 { cipher simple } value ntp-service reliable authentication-keyid keyid 缺省情况下,NTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 NTP 身份验证密钥 缺省情况下, 没有指定可信密钥 进入接口视图 interface interface-type interface-number - 将指定密钥与对应的组播服务器关联 ntp-service multicast-server [ ip-address ] authentication-keyid keyid 缺省情况下, 组播服务器没有与密钥关联 组播客户端和组播服务器上进行不同的配置时,NTP 验证结果有所不同, 详细介绍请参见表 1-22 其中, 表格中的 - 表示不管此项是否配置 表 1-22 组播客户端和组播服务器上进行不同配置时的 NTP 验证结果 组播服务器 组播客户端 是否使能身份验证功能 是否与组播服务器关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是否配置验证密钥, 并将其指定为可信密钥 结果 是是是是是 是是是是否 身份验证成功, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 1-15

94 组播服务器 组播客户端 是否使能身份验证功能 是否与组播服务器关联密钥 是否配置关联的验证密钥, 并将其指定为可信密钥 是否使能身份验证功能 是否配置验证密钥, 并将其指定为可信密钥 结果 是 是 是 否 - 是 是 否 是 - 是 是 否 否 - 是 否 - 是 - 是 否 - 否 - 否 - - 是 - 否 - - 否 - 身份验证失败, 不可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 身份验证失败, 不可以正常收发 NTP 报文 不进行身份验证, 可以正常收发 NTP 报文 1.7 配置 NTP 可选参数 配置 NTP 报文的源接口如果指定了 NTP 报文的源接口, 则设备在主动发送 NTP 报文时,NTP 报文的源地址为指定的源接口的地址 建议将 Loopback 接口指定为源接口, 以避免设备上某个接口的状态变化而导致 NTP 报文无法接收 设备对接收到的 NTP 请求报文进行应答时, 应答报文的源地址始终为接收到的 NTP 请求报文的目的地址 配置 NTP 报文的源接口时, 需要注意 : 如果在命令 ntp-service unicast-server 或 ntp-service unicast-peer 中指定了 NTP 报文的源接口, 则优先使用 ntp-service unicast-server 或 ntp-service unicast-peer 命令指定的接口作为 NTP 报文的源接口 如果在接口视图下配置了 ntp-service broadcast-server 或 ntp-service multicast-server, 则 NTP 广播或组播模式报文的源接口为配置了 ntp-service broadcast-server 或 ntp-service multicast-server 命令的接口 如果指定的 NTP 源接口处于 down 状态, 则设备不再发送 NTP 报文 表 1-23 配置 NTP 报文的源接口 操作命令说明进入系统视图 system-view

95 操作命令说明 配置 NTP 报文的源接口 ntp-service source interface-type interface-number 缺省情况下, 没有指定 NTP 报文的源接口 配置接口不处理收到的 NTP 报文启动 NTP 服务后, 缺省情况下所有接口都可以处理收到的 NTP 报文 如果出于安全性 简化网络管理等方面的考虑, 不希望设备为某个接口对应网段内的对端设备提供时间同步, 或不希望设备从某个接口对应网段内的对端设备获得时间同步, 则可以在该接口上执行本配置, 使该接口不处理收到的 NTP 报文 表 1-24 配置接口不处理收到的 NTP 报文 操作 命令 说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number - 配置接口不处理收到的 NTP 报文 undo ntp-service inbound enable 缺省情况下, 接口处理收到的 NTP 报文 配置动态会话的最大数目 NTP 会话分为两种 : 静态会话 : 用户手动配置 NTP 相关命令而建立的会话 动态会话 :NTP 协议运行过程中建立的临时会话, 若系统长期没有报文交互就会删除该临时会话 各种模式中, 会话的建立情况如下 : 客户端 / 服务器模式中, 在客户端上指定了 NTP 服务器后, 客户端上会建立一个静态会话, 服务器端在收到报文之后只是被动的响应报文, 而不会建立会话 ( 包括静态和动态会话 ) 对等体模式中, 在主动对等体上指定了被动对等体后, 主动对等体上会建立静态会话, 被动对等体端会建立动态会话 广播模式和组播模式中, 在广播 / 组播服务器端上会建立静态会话, 而在广播 / 组播客户端上会建立动态会话 设备同一时间内最多可以建立的会话数目为 128 个, 其中包括静态会话数和动态会话数 本配置用来限制动态会话的数目, 以避免设备上维护过多的动态会话, 占用过多的系统资源 表 1-25 配置动态会话的最大数目 操作命令说明进入系统视图 system-view - 配置 NTP 动态会话的最大数目 ntp-service max-dynamic-sessions number 缺省情况下,NTP 动态会话的最大数目为

96 1.7.4 配置 NTP 报文的 DSCP 优先级 DSCP 优先级用来体现报文自身的优先等级, 决定报文传输的优先程度 通过本配置可以指定 NTP 服务器发送的 NTP 报文的 DSCP 优先级 表 1-26 配置 NTP 报文的 DSCP 优先级 操作命令说明进入系统视图 system-view - 配置 NTP 报文的 DSCP 优先级 ntp-service dscp dscp-value 缺省情况下,NTP 报文的 DSCP 优先级为 配置本地时钟作为参考时钟 配置本地时钟作为参考时钟时, 需要注意 : 配置本地时钟作为参考时钟后, 本地设备的时钟将处于同步状态, 可以作为时间服务器为网络中其他设备的时钟提供时间同步 如果本地设备的时钟不正确, 则会导致网络中设备的时间错误, 请谨慎使用本配置 在执行本命令之前, 建议先调整本地系统时间 设备重启后, 系统时间会变成系统初始化的时间 建议不要在这些设备上配置本地时钟作为参考时钟, 并且不要将这些设备指定为时间服务器 本配置用来指定设备与本地时钟进行时间同步, 使得该设备的时钟处于同步状态 表 1-27 配置本地时钟作为参考时钟操作命令说明进入系统视图 system-view - 配置本地时钟作为参考时钟 ntp-service refclock-master [ ip-address ] [ stratum ] 缺省情况下, 设备未采用本地时钟作为参考时钟 1.9 NTP 显示和维护 在完成上述配置后, 在任意视图下执行 display 命令可以显示配置后 NTP 的运行情况, 通过查看显示信息验证配置的效果 表 1-28 NTP 显示与维护 操作 显示 NTP 服务的状态信息 display ntp-service status 命令 显示 NTP 服务的所有 IPv4 会话信息 display ntp-service sessions [ verbose ] 显示从本地设备回溯到主时间服务器的各个 NTP 时间服务器的简要信息 display ntp-service trace 1-18

97 1.10 NTP 典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 DOWN 状态 如果要使这些接口能够正常 工作, 请先使用 undo shutdown 命令使接口状态处于 UP 配置 NTP 客户端 / 服务器模式 1. 组网需求为了通过 NTP 实现 Device B 与 Device A 的时间同步, 要求 : 在 Device A 上设置本地时钟作为参考时钟, 层数为 2; 配置 Device B 工作在客户端模式, 指定 Device A 为 NTP 服务器 2. 组网图图 1-5 配置 NTP 客户端 / 服务器模式组网图 NTP server NTP client / /24 Device A Device B 3. 配置步骤 (1) 按照图 1-5 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device A # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceA] ntp-service refclock-master 2 (3) 配置 Device B # 开启 NTP 服务 <DeviceB> system-view [DeviceB] ntp-service enable # 设置 Device A 为 Device B 的 NTP 服务器 [DeviceB] ntp-service unicast-server 验证配置 # 完成上述配置后,Device B 向 Device A 进行时间同步 同步后查看 Device B 的 NTP 状态 可以看出,Device B 已经与 Device A 同步, 层数比 Device A 的层数大 1, 为 3 [DeviceB] display ntp-service status Clock status: synchronized Clock stratum:

98 System peer: Local mode: client Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0c6033f.b Wed, Dec :58: # 查看 Device B 的 NTP 服务的所有 IPv4 会话信息, 可以看到 Device B 与 Device A 建立了会话 [DeviceB] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [12345] Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured. Total sessions : 配置 NTP 对等体模式 1. 组网需求网络中存在时间服务器 Device A 为了通过 NTP 实现 Device B 与 Device A 进行时间同步, 要求 : 在 Device A 上设置本地时钟作为参考时钟, 层数为 2; 配置 Device A 工作在对等体模式, 指定 Device B 为被动对等体, 即 Device A 为主动对等体, Device B 为被动对等体 2. 组网图图 1-6 配置 NTP 对等体模式组网图 3. 配置步骤 (1) 按照图 1-6 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device A # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceA] ntp-service refclock-master 2 # 设置 Device B 为被动对等体 Device A 处于主动对等体模式 [DeviceA] ntp-service unicast-peer

99 (3) 配置 Device B # 开启 NTP 服务 <DeviceB> system-view [DeviceB] ntp-service enable 4. 验证配置 # 完成上述配置后,Device B 选择 Device A 作为参考时钟, 与 Device A 进行时间同步 同步后查看 Device B 的状态 可以看出,Device B 已经与 Device A 同步, 层数比 Device A 的层数大 1, 为 3 [DeviceB] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: sym_passive Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-17 Root delay: ms Root dispersion: ms Reference time: 83aec681.deb6d3e5 Wed, Jan :33: # 查看 Device B 的 NTP 服务的 IPv4 会话信息, 可以看到 Device B 与 Device A 建立了会话 [DeviceB] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [12] Notes: 1 source(master), 2 source(peer), 3 selected, 4 candidate, 5 configured. Total sessions: 配置 NTP 广播模式 1. 组网需求为了实现 Device C 作为同一网段中多个设备的时间服务器, 同时同步多个设备的时间, 要求 : 在 Device C 上设置本地时钟作为参考时钟, 层数为 2; Device C 工作在广播服务器模式, 从接口 GigabitEthernet3/0/1 向外广播发送 NTP 报文 ; Device A 和 Device B 工作在广播客户端模式, 分别从各自的接口 GigabitEthernet3/0/1 监听 NTP 广播报文 1-21

100 2. 组网图 图 1-7 配置 NTP 广播模式组网图 GE3/0/ /24 Device C NTP broadcast server GE3/0/ /24 Device A NTP broadcast client GE3/0/ /24 Device B NTP broadcast client 3. 配置步骤 (1) 按照图 1-7 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device C # 开启 NTP 服务 <DeviceC> system-view [DeviceC] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceC] ntp-service refclock-master 2 # 设置 Device C 为广播服务器, 从接口 GigabitEthernet3/0/1 发送广播报文 [DeviceC] interface gigabitethernet 3/0/1 [DeviceC-GigabitEthernet3/0/1] ntp-service broadcast-server (3) 配置 Device A # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 设置 Device A 为广播客户端, 从 GigabitEthernet3/0/1 监听广播报文 [DeviceA] interface gigabitethernet 3/0/1 [DeviceA-GigabitEthernet3/0/1] ntp-service broadcast-client (4) 配置 Device B # 开启 NTP 服务 <DeviceB> system-view [DeviceB] ntp-service enable # 设置 Device B 为广播客户端, 从 GigabitEthernet3/0/1 监听广播报文 [DeviceB] interface gigabitethernet 3/0/1 [DeviceB-GigabitEthernet3/0/1] ntp-service broadcast-client 1-22

101 4. 验证配置 # Device A 和 Device B 接收到 Device C 发出的广播报文后, 与其同步 以 Device A 为例, 同步后查看 Device A 的状态 可以看出,Device A 已经与 Device C 同步, 层数比 Device C 的层数大 1, 为 3 [DeviceA-GigabitEthernet3/0/1] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: bclient Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0d289fe.ec43c720 Sat, Jan :00: # 查看 Device A 的 NTP 服务的 IPv4 会话信息, 可以看到 Device A 与 Device C 建立了会话 [DeviceA-GigabitEthernet3/0/1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 配置 NTP 组播模式 1. 组网需求为了实现 Device C 作为不同网段中多个设备的时间服务器, 同时同步多个设备的时间, 要求 : 在 Device C 上设置本地时钟作为参考时钟, 层数为 2; Device C 工作在组播服务器模式, 从接口 GigabitEthernet3/0/1 向外组播发送 NTP 报文 ; Device A 和 Device D 工作在组播客户端模式,Device A 从接口 GigabitEthernet3/0/1 监听 NTP 组播报文,Device D 从接口 GigabitEthernet3/0/1 监听 NTP 组播报文 1-23

102 2. 组网图 图 1-8 配置 NTP 组播模式组网图 GE3/0/ /24 Device C NTP multicast server GE3/0/ /24 GE3/0/ /24 GE3/0/ /24 Device A NTP multicast client Device B GE3/0/ /24 Device D NTP multicast client 3. 配置步骤 (1) 按照图 1-8 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device C # 开启 NTP 服务 <DeviceC> system-view [DeviceC] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceC] ntp-service refclock-master 2 # 设置 Device C 为组播服务器, 从接口 GigabitEthernet3/0/1 发送组播报文 [DeviceC] interface gigabitethernet 3/0/1 [DeviceC-GigabitEthernet3/0/1] ntp-service multicast-server (3) 配置 Device D # 开启 NTP 服务 <DeviceD> system-view [DeviceD] ntp-service enable # 设置 Device D 为组播客户端, 从接口 GigabitEthernet3/0/1 监听组播报文 [DeviceD] interface gigabitethernet 3/0/1 [DeviceD-GigabitEthernet3/0/1] ntp-service multicast-client (4) 验证配置一 # 由于 Device D 和 Device C 在同一个网段, 不需要配置组播功能,Device D 就可以收到 Device C 发出的组播报文, 并与其同步 同步后查看 Device D 的状态 可以看出,Device D 已经与 Device C 同步, 层数比 Device C 的层数大 1, 为 3 [DeviceD-GigabitEthernet3/0/1] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: bclient 1-24

103 Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0d289fe.ec43c720 Sat, Jan :00: # 查看 Device D 的 NTP 服务的所有 IPv4 会话信息, 可以看到 Device D 与 Device C 建立了会话 [DeviceD-GigabitEthernet3/0/1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 1 (5) 配置 Device B 由于 Device A 与 Device C 不在同一网段, 所以 Device B 上需要配置组播功能, 否则 Device A 收不到 Device C 发出的组播报文 # 配置组播功能 <DeviceB> system-view [DeviceB] multicast routing [DeviceB-mrib] quit [DeviceB] interface gigabitethernet 3/0/2 [DeviceB-GigabitEthernet3/0/2] pim dm [DeviceB-GigabitEthernet3/0/2] quit [DeviceB] interface gigabitethernet 3/0/1 [DeviceB-GigabitEthernet3/0/1] igmp enable [DeviceB-GigabitEthernet3/0/1] igmp static-group [DeviceB-GigabitEthernet3/0/1] quit (6) 配置 Device A # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 设置 Device A 为组播客户端, 从接口 GigabitEthernet3/0/1 监听组播报文 [DeviceA] interface gigabitethernet 3/0/1 [DeviceA-GigabitEthernet3/0/1] ntp-service multicast-client (7) 验证配置二 # 同步后查看 Device A 的状态 可以看出,Device A 已经与 Device C 同步, 层数比 Device C 的层数大 1, 为 3 [DeviceA-GigabitEthernet3/0/1] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: bclient Reference clock ID: Leap indicator:

104 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0c b1193f Wed, Dec :03: # 查看 Device A 的 NTP 服务的所有 IPv4 会话信息, 可以看到 Device A 与 Device C 建立了会话 [DeviceA-GigabitEthernet3/0/1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1234] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 配置带验证功能的 NTP 客户端 / 服务器模式 1. 组网需求为了通过 NTP 实现 Device B 与 Device A 的时间同步, 并保证时间同步的安全性, 要求 : 在 Device A 上设置本地时钟作为参考时钟, 层数为 2; Device B 工作在客户端模式, 指定 Device A 为 NTP 服务器 ; Device A 和 Device B 上同时配置 NTP 验证 2. 组网图图 1-9 配置带身份验证的 NTP 客户端 / 服务器模式组网图 3. 配置步骤 (1) 按照图 1-9 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device A 的本地时钟作为参考时钟 # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceA] ntp-service refclock-master 2 (3) 配置 Device B # 开启 NTP 服务 <DeviceB> system-view [DeviceB] ntp-service enable # 在 Device B 上启动 NTP 验证功能 [DeviceB] ntp-service authentication enable 1-26

105 # 创建编号为 42 的 NTP 验证密钥, 密钥值为 anicekey, 以明文形式输入 [DeviceB] ntp-service authentication-keyid 42 authentication-mode md5 simple anicekey # 配置编号为 42 的密钥为可信密钥 [DeviceB] ntp-service reliable authentication-keyid 42 # 设置 Device A 为 Device B 的 NTP 服务器, 并将该服务器与编号为 42 的密钥关联 [DeviceB] ntp-service unicast-server authentication-keyid 42 以上配置将使得 Device B 与 Device A 进行时间同步, 但由于 Device A 没有使能 NTP 身份验证, 所以,Device B 还是无法与 Device A 同步 (4) 在 Device A 上配置 NTP 验证功能 # 在 Device A 上启动 NTP 验证功能 [DeviceA] ntp-service authentication enable # 创建编号为 42 的 NTP 验证密钥, 密钥值为 anicekey, 以明文形式输入 [DeviceA] ntp-service authentication-keyid 42 authentication-mode md5 simple anicekey # 配置编号为 42 的密钥为可信密钥 [DeviceA] ntp-service reliable authentication-keyid 验证配置 # 完成上述配置后,Device B 可以与 Device A 的时间同步 同步后查看 Device B 的状态 可以看出,Device B 已经与 Device A 同步, 层数比 Device A 的层数大 1, 为 3 [DeviceB] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: client Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0c62687.ab1bba7d Wed, Dec :28: # 查看 Device B 的 NTP 服务的所有 IPv4 会话信息, 可以看到 Device B 与 Device A 建立了会话 [DeviceB] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 配置带验证功能的 NTP 广播模式 1. 组网需求 Device C 作为同一网段中多个设备的时间服务器, 同时同步多个设备的时间 Device A 和 Device B 要求对时间服务器进行验证, 以保证时间同步的安全性 为了实现上述需求, 要求 : 1-27

106 在 Device C 上设置本地时钟作为参考时钟, 层数为 3; Device C 工作在广播服务器模式, 从接口 GigabitEthernet3/0/1 向外广播发送 NTP 报文 ; Device A 和 Device B 工作在广播客户端模式, 从接口 GigabitEthernet3/0/1 监听 NTP 广播报文 ; 在 Device A Device B 和 Device C 上配置 NTP 验证功能 2. 组网图图 1-10 配置带身份验证的 NTP 广播模式组网图 GE3/0/ /24 Device C NTP broadcast server GE3/0/ /24 Device A NTP broadcast client GE3/0/ /24 Device B NTP broadcast client 3. 配置步骤 (1) 按照图 1-10 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device A # 开启 NTP 服务 <DeviceA> system-view [DeviceA] ntp-service enable # 使能 NTP 验证功能, 创建 ID 为 88 的 NTP 验证密钥, 密钥值为 , 以明文形式输入, 并将密钥 88 指定为可信密钥 [DeviceA] ntp-service authentication enable [DeviceA] ntp-service authentication-keyid 88 authentication-mode md5 simple [DeviceA] ntp-service reliable authentication-keyid 88 # 设置 Device A 为 NTP 广播客户端, 从接口 GigabitEthernet3/0/1 监听广播报文 [DeviceA] interface gigabitethernet 3/0/1 [DeviceA-GigabitEthernet3/0/1] ntp-service broadcast-client (3) 配置 Device B # 开启 NTP 服务 <DeviceB> system-view [DeviceB] ntp-service enable # 使能 NTP 验证功能, 创建 ID 为 88 的 NTP 验证密钥, 密钥值为 , 以明文形式输入, 并将密钥 88 指定为可信密钥 [DeviceB] ntp-service authentication enable 1-28

107 [DeviceB] ntp-service authentication-keyid 88 authentication-mode md5 simple [DeviceB] ntp-service reliable authentication-keyid 88 # 设置 Device B 为 NTP 广播客户端, 从接口 GigabitEthernet3/0/1 监听广播报文 [DeviceB] interface gigabitethernet 3/0/1 [DeviceB-GigabitEthernet3/0/1] ntp-service broadcast-client (4) 配置 Device C 作为 NTP 广播服务器 # 开启 NTP 服务 <DeviceC> system-view [DeviceC] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 3 [DeviceC] ntp-service refclock-master 3 # 设置 Device C 为 NTP 广播服务器, 从接口 GigabitEthernet3/0/1 向外发送广播报文 [DeviceC] interface gigabitethernet 3/0/1 [DeviceC-GigabitEthernet3/0/1] ntp-service broadcast-server [DeviceC-GigabitEthernet3/0/1] quit (5) 验证配置一 # 由于 Device A 和 Device B 上使能了 NTP 验证功能,Device C 上没有使能 NTP 验证功能 因此, Device A 和 Device B 无法与 Device C 的时间同步 以 Device B 为例, 查看 NTP 服务的状态 [DeviceB-GigabitEthernet3/0/1] display ntp-service status Clock status: unsynchronized Clock stratum: 16 Reference clock ID: none (6) 在 Device C 上配置 NTP 验证功能 # 在 Device C 上使能 NTP 验证功能, 创建 ID 为 88 的 NTP 验证密钥, 密钥值为 , 以明文形式输入, 并将密钥 88 指定为可信密钥 [DeviceC] ntp-service authentication enable [DeviceC] ntp-service authentication-keyid 88 authentication-mode md5 simple [DeviceC] ntp-service reliable authentication-keyid 88 # 设置 Device C 为 NTP 广播服务器并指定关联的密钥编号为 88 [DeviceC] interface gigabitethernet 3/0/1 [DeviceC-GigabitEthernet3/0/1] ntp-service broadcast-server authentication-keyid 88 (7) 验证配置二 # 在 Device C 上使能 NTP 验证功能后,Device A 和 Device B 可以与 Device C 的时间同步 以 Device B 为例, 查看 NTP 服务的状态信息, 可以看到 Device B 已经与 Device C 同步, 层数比 Device C 的层数大 1, 为 4 [DeviceB-GigabitEthernet3/0/1] display ntp-service status Clock status: synchronized Clock stratum: 4 System peer: Local mode: bclient Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^

108 Root delay: ms Root dispersion: ms Reference time: d0d287a f Sat, Jan :50: # 查看 Device B 的 NTP 服务的所有 IPv4 会话信息, 可以看到 Device B 与 Device C 建立了连接 [DeviceB-GigabitEthernet3/0/1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 配置采用客户端 / 服务器模式实现 MPLS VPN 网络的时间同步 1. 组网需求 PE 1 和 PE 2 上同时存在两个 VPN:VPN 1 和 VPN 2 CE 1 和 CE 3 是 VPN 1 内的设备 为了通过 NTP 实现 PE 2 与 VPN 1 内的 CE 1 时间同步, 要求 : 在 CE 1 上设置本地时钟作为参考时钟, 层数为 2; 采用客户端 / 服务器模式实现 PE 2 向 CE 1 进行时间同步, 并指定 VPN 为 VPN 1 2. 组网图图 1-11 配置 MPLS VPN 网络的时间同步组网图 VPN 1 CE 1 NTP server VPN 1 CE / /24 PE 1 P PE 2 NTP client /24 MPLS backbone CE 2 CE 4 VPN 2 VPN 2 3. 配置步骤 在下面的配置之前,MPLS VPN 的相关配置必须完成,CE 1 和 PE 1 之间 PE 1 和 PE 2 之间 PE 2 和 CE 3 之间都必须有路由可达 MPLS VPN 的配置方法请参见 MPLS 配置指导 中的 MPLS L3VPN (1) 按照图 1-11 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 1-30

109 (2) 配置 CE 1 # 开启 NTP 服务 <CE1> system-view [CE1] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [CE1] ntp-service refclock-master 2 (3) 配置 PE 2 # 开启 NTP 服务 <PE2> system-view [PE2] ntp-service enable # 设置 VPN 1 中的 CE 1 为 PE 2 的 NTP 服务器 [PE2] ntp-service unicast-server vpn-instance vpn1 4. 验证配置 # 经过一段时间之后在 PE 2 上可以查看 NTP 服务的所有 IPv4 会话信息 状态信息等, 可以看出 PE 2 已经同步到 CE 1 了, 层数为 3 [PE2] display ntp-service status Clock status: synchronized Clock stratum: 3 System peer: Local mode: client Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0c62687.ab1bba7d Wed, Dec :28: [PE2] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 1 [PE2] display ntp-service trace Server Stratum 3, jitter 0.000, synch distance Server Stratum 2, jitter , synch distance RefID

110 配置采用对等体模式实现 MPLS VPN 网络的时间同步 1. 组网需求 PE 1 和 PE 2 上同时存在两个 VPN:VPN 1 和 VPN 2 CE 1 和 CE 3 是 VPN 1 内的设备 为了通过 NTP 实现 PE 1 与 VPN 1 内的 CE 1 时间同步, 要求 : 在 CE 1 上设置本地时钟作为参考时钟, 层数为 2; 采用对等体模式实现 PE 1 向 CE 1 进行时间同步, 并指定 VPN 为 VPN 1 2. 组网图图 1-12 配置采用对等体模式实现 MPLS VPN 网络的时间同步组网图 3. 配置步骤 (1) 按照图 1-12 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 CE 1 # 开启 NTP 服务 <CE1> system-view [CE1] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [CE1] ntp-service refclock-master 2 (3) 配置 PE 1 # 开启 NTP 服务 <PE1> system-view [PE1] ntp-service enable # 设置 VPN 1 中的 CE 1 为 PE 1 的被动对等体 [PE1] ntp-service unicast-peer vpn-instance vpn1 4. 验证配置 # 经过一段时间之后在 PE 1 上可以查看 NTP 服务的所有 IPv4 会话信息 状态信息等, 可以看出 PE 1 已经同步到 CE 1 了, 层数为 3 [PE1] display ntp-service status 1-32

111 Clock status: synchronized Clock stratum: 3 System peer: Local mode: sym_active Reference clock ID: Leap indicator: 00 Clock jitter: s Stability: pps Clock precision: 2^-10 Root delay: ms Root dispersion: ms Reference time: d0c62687.ab1bba7d Wed, Dec :28: [PE1] display ntp-service sessions source reference stra reach poll now offset delay disper ******************************************************************************** [1245] Notes: 1 source(master),2 source(peer),3 selected,4 candidate,5 configured. Total sessions : 1 [PE1] display ntp-service trace Server Stratum 3, jitter 0.000, synch distance Server Stratum 2, jitter , synch distance RefID

112 2 SNTP 设备上不能同时配置 NTP 和 SNTP 功能 2.1 SNTP 简介 NTP 时间同步过程中需要进行复杂的时钟优选运算, 时间同步速度较慢, 并且占用较多的系统资源 SNTP(Simple NTP, 简单 NTP) 是由 RFC 4330 定义的客户端版本的简单 NTP, 采用与 NTP 相同的报文格式及交互过程, 但简化了 NTP 的时间同步过程, 以牺牲时间精度为代价实现了时间的快速同步, 并减少了占用的系统资源 在时间精度要求不高的情况下, 可以使用 SNTP 来实现时间同步 SNTP 只支持客户端 / 服务器模式, 在模式中提供客户端功能, 即作为客户端, 从 NTP 服务器获得时间同步, 不能作为服务器为其他设备提供时间同步 如果同时为 SNTP 客户端指定了多个 NTP 服务器, 则 SNTP 客户端根据如下方法选择与哪个服务器的时间同步 : (1) 优先选择时钟层数值最小的 NTP 服务器 (2) 如果时钟层数相同, 则选择接收到的第一个 NTP 报文对应的 NTP 服务器 与 SNTP 相关的协议规范有 : RFC 4330:Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI 2.2 SNTP 配置任务简介 配置 SNTP 时, 需要注意 : 用户需要保证通过 clock protocol 命令, 配置在指定的 MDC, 以 NTP 方式设置系统时间 只支持在编号为 1 的 MDC 上配置 SNTP 功能 表 2-1 SNTP 配置任务简介配置任务说明详细配置开启 SNTP 服务必选 2.3 为 SNTP 客户端指定 NTP 服务器必选 2.4 配置 SNTP 验证功能可选 开启 SNTP 服务 NTP 服务与 SNTP 服务互斥, 同一时刻只能开启其中一个服务 2-1

113 表 2-2 开启 NTP 客户端 操作命令说明 进入系统视图 system-view - 开启 SNTP 服务 sntp enable 缺省情况下, 没有开启 SNTP 服务 2.4 为 SNTP 客户端指定 NTP 服务器 NTP 服务器的时钟只有处于同步状态时, 才能作为时间服务器为 SNTP 客户端提供时间同步 当 NTP 服务器的时钟层数大于或等于客户端的时钟层数时, 客户端将不会与其同步 表 2-3 为 SNTP 客户端指定 NTP 服务器操作命令说明进入系统视图 system-view - 为设备指定 NTP 服务器 sntp unicast-server { server-name ip-address } [ vpn-instance vpn-instance-name ] [ authentication-keyid keyid source interface-type interface-number version number ] * 缺省情况下, 没有为设备指定 NTP 服务器可以通过多次执行 sntp unicast-server 命令配置多个 NTP 服务器 authentication-keyid 参数用来将指定密钥与对应的 NTP 服务器关联 使用验证功能时, 需要指定本参数 2.5 配置 SNTP 验证功能 在一些对时间同步安全性要求较高的网络中, 运行 SNTP 协议时需要启用验证功能 通过客户端和服务器端的身份验证, 保证客户端只与通过验证的服务器进行时间同步, 提高了网络安全性 要使 SNTP 验证功能正常工作, 在配置 SNTP 验证功能时应注意以下原则 : 在 NTP 服务器和 SNTP 客户端上都需要使能验证功能 NTP 服务器和 SNTP 客户端上必须配置相同的验证密钥 ( 包括密钥 ID 和密钥值 ), 并将密钥设为可信密钥 NTP 服务器上验证功能的配置方法, 请参见 网络管理与监控配置指导 中的 NTP 在客户端需要将指定密钥与对应的 NTP 服务器关联 如果客户端没有成功启用 SNTP 验证功能, 不论服务器端是否使能验证功能, 客户端均可以与服务器端同步 表 2-4 在 SNTP 客户端配置验证功能操作命令说明进入系统视图 system-view - 2-2

114 操作命令说明 使能 SNTP 身份验证功能 配置 SNTP 身份验证密钥 sntp authentication enable sntp authentication-keyid keyid authentication-mode md5 { cipher simple } value 缺省情况下,SNTP 身份验证功能处于关闭状态 缺省情况下, 没有配置 SNTP 身份验证密钥 配置指定密钥为可信密钥 sntp reliable authentication-keyid keyid 缺省情况下, 没有指定可信密钥 将指定密钥与对应的 NTP 服务器关联 sntp unicast-server { server-name ip-address } [ vpn-instance vpn-instance-name ] authentication-keyid keyid 缺省情况下, 没有为设备指定 NTP 服务器 2.6 SNTP 显示和维护 在完成上述配置后, 在任意视图下执行 display 命令可以显示配置后 SNTP 的运行情况, 通过查看显示信息验证配置的效果 表 2-5 SNTP 显示与维护 操作 命令 显示 SNTP 服务维护的会话信息 display sntp sessions 2.7 SNTP 典型配置举例 1. 组网需求 Device B 对时间精度要求不高 为了实现 Device B 与 Device A 的时间同步, 要求 : 在 Device A 上设置本地时钟作为参考时钟, 层数为 2; Device B 工作在 SNTP 客户端模式, 指定 Device A 为 NTP 服务器 Device B 要求对 NTP 服务器进行验证, 以保证时间同步的安全性 2. 组网图图 2-1 SNTP 配置组网图 3. 配置步骤 (1) 按照图 2-1 配置各接口的 IP 地址, 并确保路由可达, 具体配置过程略 (2) 配置 Device A # 开启 NTP 服务 2-3

115 <DeviceA> system-view [DeviceA] ntp-service enable # 设置本地时钟作为参考时钟, 层数为 2 [DeviceA] ntp-service refclock-master 2 # 在 Device A 上启动 NTP 验证功能 [DeviceA] ntp-service authentication enable # 创建编号为 10 的 NTP 验证密钥, 密钥值为 anicekey, 以明文形式输入 [DeviceA] ntp-service authentication-keyid 10 authentication-mode md5 simple anicekey # 设置编号为 10 的密钥为可信密钥 [DeviceA] ntp-service reliable authentication-keyid 10 (3) 配置 Device B # 开启 SNTP 服务 <DeviceB> system-view [DeviceB] sntp enable # 在 Device B 上启动 SNTP 验证功能 [DeviceB] sntp authentication enable # 创建编号为 10 的 SNTP 验证密钥, 密钥值为 anicekey, 以明文形式输入 [DeviceB] sntp authentication-keyid 10 authentication-mode md5 simple anicekey # 设置编号为 10 的密钥为可信密钥 [DeviceB] sntp reliable authentication-keyid 10 # 设置 Device A 为 Device B 的 NTP 服务器, 并将该服务器与编号为 10 的密钥关联 [DeviceB] sntp unicast-server authentication-keyid 验证配置 # 查看 Device B 的 SNTP 会话信息, 可以看到 Device B 与 Device A 建立了会话, 并且处于已同步状态 [DeviceB] display sntp sessions SNTP server Stratum Version Last receive time Tue, May :11: (Synced) 2-4

116 目录 1 SNMP SNMP 简介 SNMP 的网络架构 MIB 和 MIB 视图 SNMP 基本操作 SNMP 版本介绍 SNMP 支持的访问控制方式 配置 SNMP 基本参数 配置 SNMPv1/v2c 版本基本参数 配置 SNMPv3 版本基本参数 配置 SNMP 日志 配置 SNMP 告警 开启告警功能 配置告警信息发送参数 SNMP 显示和维护 SNMPv1/v2c 典型配置举例 SNMPv3 典型配置举例 1-13 i

117 1 SNMP 设备运行于 FIPS 模式时, 本特性部分配置相对于非 FIPS 模式有所变化, 具体差异请见本文相关描 述 有关 FIPS 模式的详细介绍请参见 安全配置指导 中的 FIPS 1.1 SNMP 简介 SNMP(Simple Network Management Protocol, 简单网络管理协议 ) 是互联网中的一种网络管理标准协议, 广泛用于实现管理设备对被管理设备的访问和管理 SNMP 具有以下优势 : 支持网络设备的智能化管理 利用基于 SNMP 的网络管理平台, 网络管理员可以查询网络设备的运行状态和参数, 设置参数值, 发现故障, 完成故障诊断, 进行容量规划和制作报告 支持对不同物理特性的设备进行管理 SNMP 只提供最基本的功能集, 使得管理任务与被管理设备的物理特性和联网技术相对独立, 从而实现对不同厂商设备的管理 SNMP 的网络架构 SNMP 网络架构由三部分组成 :NMS Agent 和 MIB NMS(Network Management System, 网络管理系统 ) 是 SNMP 网络的管理者, 能够提供友好的人机交互界面, 方便网络管理员完成大多数的网络管理工作 Agent 是 SNMP 网络的被管理者, 负责接收 处理来自 NMS 的 SNMP 报文 在某些情况下, 如接口状态发生改变时,Agent 也会主动向 NMS 发送告警信息 MIB(Management Information Base, 管理信息库 ) 是被管理对象的集合 NMS 管理设备的时候, 通常会关注设备的一些参数, 比如接口状态 CPU 利用率等, 这些参数就是被管理对象, 在 MIB 中称为节点 每个 Agent 都有自己的 MIB MIB 定义了节点之间的层次关系以及对象的一系列属性, 比如对象的名字 访问权限和数据类型等 被管理设备都有自己的 MIB 文件, 在 NMS 上编译这些 MIB 文件, 就能生成该设备的 MIB NMS 根据访问权限对 MIB 节点进行读 / 写操作, 从而实现对 Agent 的管理 NMS Agent 和 MIB 之间的关系如图 1-1 所示 图 1-1 NMS Agent 和 MIB 关系图 1-1

118 1.1.2 MIB 和 MIB 视图 MIB 以树状结构进行存储 树的每个节点都是一个被管理对象, 它用从根开始的一条路径唯一地识别 (OID) 如图 1-2 所示, 被管理对象 B 可以用一串数字 { } 唯一确定, 这串数字是被管理对象的 OID(Object Identifier, 对象标识符 ) MIB 视图是 MIB 的子集合, 将团体名 / 用户名与 MIB 视图绑定, 可以限制 NMS 能够访问的 MIB 对象 当用户配置 MIB 视图包含某个 MIB 子树时,NMS 可以访问该子树的所有节点 ; 当用户配置 MIB 视图不包含某个 MIB 子树时,NMS 不能访问该子树的所有节点 图 1-2 MIB 树结构 SNMP 基本操作 SNMP 提供四种基本操作 : Get 操作 :NMS 使用该操作查询 Agent MIB 中节点的值 Set 操作 :NMS 使用该操作设置 Agent MIB 中节点的值 Trap 操作 :Agent 使用该操作向 NMS 发送 Trap 报文 Agent 不要求 NMS 发送回应报文, NMS 也不会对 Trap 报文进行回应 SNMPv1 SNMPv2c 和 SNMPv3 均支持 Trap 操作 Inform 操作 :Agent 使用该操作向 NMS 发送 Inform 报文 Agent 要求 NMS 发送回应报文, 因此,Inform 报文比 Trap 报文更可靠 如果 Agent 在一定时间内没有收到 NMS 的回应报文, 则会启动重发机制 只有 SNMPv2c 和 SNMPv3 支持 Inform 操作 SNMP 版本介绍目前, 设备运行于非 FIPS 模式时, 支持 SNMPv1 SNMPv2c 和 SNMPv3 三种版本 ; 设备运行于 FIPS 模式时, 只支持 SNMPv3 版本 只有 NMS 和 Agent 使用的 SNMP 版本相同,NMS 才能和 Agent 建立连接 SNMPv1 采用团体名 (Community Name) 认证机制 团体名类似于密码, 用来限制 NMS 和 Agent 之间的通信 如果 NMS 设置的团体名和被管理设备上设置的团体名不同, 则 NMS 和 Agent 不能建立 SNMP 连接, 从而导致 NMS 无法访问 Agent,Agent 发送的告警信息也会被 NMS 丢弃 SNMPv2c 也采用团体名认证机制 SNMPv2c 对 SNMPv1 的功能进行了扩展 : 提供了更多的操作类型 ; 支持更多的数据类型 ; 提供了更丰富的错误代码, 能够更细致地区分错误 SNMPv3 采用 USM(User-Based Security Model, 基于用户的安全模型 ) 认证机制 网络管理员可以设置认证和加密功能 认证用于验证报文发送方的合法性, 避免非法用户的访问 ; 1-2

119 加密则是对 NMS 和 Agent 之间的传输报文进行加密, 以免被窃听 采用认证和加密功能可以为 NMS 和 Agent 之间的通信提供更高的安全性 SNMP 支持的访问控制方式 SNMP 支持的访问控制方式包括 VACM(View-based Access Control Model, 基于视图的访问控制模型 ) 和 RBAC(Role Based Access Control, 基于角色的访问控制 ) 1. VACM 方式将团体名 / 用户名与指定的 MIB 视图进行绑定, 可以限制 NMS 能够访问哪些 MIB 对象, 以及对 MIB 对象不同的操作权限 2. RBAC 方式创建团体名 / 用户名时, 可以指定对应的用户角色 拥有用户角色为 network-admin 或 level-15 的 SNMP 团体 / 用户, 可以对所有的 MIB 对象进行读写操作 ; 拥有用户角色为 network-operator 的 SNMP 团体 / 用户, 可以对所有的 MIB 对象进行读操作 ; 拥有用户角色为自定义角色的 SNMP 团体 / 用户, 则根据该用户角色下 rule 命令创建的用户角色规则来对相应 MIB 对象进行操作 对于同一 SNMP 用户名 / 团体名, 只能配置一种控制方式, 多次使用两种控制方式配置同一用户名 / 团体名时, 以最后一次的配置方式为准, 推荐使用 RBAC 方式, 安全性更高 有关用户角色及 rule 命令的详细情况, 请参见 基础配置 中的 RBAC RBAC 配置方式要求 NMS 在访问 Agent 时, 不仅需要授予 NMS 对 MIB 节点的访问权限, 还要求团体名 / 用户名所绑定的用户角色具有执行相应操作的权限, 而 VACM 方式只需通过控制 MIB 节点的访问权限即可, 所以推荐使用 RBAC 配置方式, 安全性更高 1.2 配置 SNMP 基本参数 由于 SNMPv3 版本的配置和 SNMPv1 版本 SNMPv2c 版本的配置有较大区别, 所以下面分两种情况介绍 SNMP 基本功能的配置, 详见表 1-1 和表 配置 SNMPv1/v2c 版本基本参数 设备运行于 FIPS 模式时, 不支持 SNMPv1/v2c 版本 表 1-1 配置 SNMPv1/v2c 版本基本参数 操作命令说明 进入系统视图 system-view - 1-3

120 操作命令说明 ( 可选 ) 启动 SNMP Agent 服务 ( 可选 ) 配置设备的维护联系信息 ( 可选 ) 配置设备的物理位置信息 启用 SNMPv1/v2c 版本 ( 可选 ) 设置本地 SNMP 实体的引擎 ID ( 可选 ) 创建 MIB 视图或更新 MIB 视图内容 snmp-agent snmp-agent sys-info contact sys-contact snmp-agent sys-info location sys-location snmp-agent sys-info version { all { v1 v2c } * } snmp-agent local-engineid engineid snmp-agent mib-view { excluded included } view-name oid-tree [ mask mask-value ] 缺省情况下,SNMP Agent 服务处于关闭状态执行除 snmp-agent calculate-password 外任何以 snmp-agent 开头的命令, 都可以启动 SNMP Agent 服务 缺省情况下, 系统维护联系信息为 Hangzhou H3C Technologies Co.,Ltd. 缺省情况下, 物理位置信息为 Hangzhou, China 缺省情况下, 系统启用的 SNMP 版本号版本为 SNMP v3 缺省情况下, 设备引擎 ID 为公司的 企业号 + 设备信息 缺省情况下, 设备上已创建了四个视图, 视图名均为 ViewDefault: 视图一包含 MIB 子树 iso 视图二不包含子树 snmpusmmib 视图三不包含子树 snmpvacmmib 视图四不包含子树 snmpmodules.18 MIB 视图是 MIB 的子集, 由视图名和 MIB 子树来唯一确定一个 MIB 视图 视图名相同但包含的子树不同, 则认为是不同的视图 除缺省视图外, 用户最多可以创建 16 个 MIB 视图 VACM 方式 : 设置访问权限 直接设置 间接设置 创建 SNMP 团体 创建 SNMPv1/v 2c 组 创建 SNMPv1/v 2c 用户 snmp-agent community { read write } [ simple cipher ] community-name [ mib-view view-name ] [ acl acl-number acl ipv6 ipv6-acl-number ] * RBAC 方式 : snmp-agent community [ simple cipher ] community-name user-role role-name [ acl acl-number acl ipv6 ipv6-acl-number ] * snmp-agent group { v1 v2c } group-name [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number acl ipv6 ipv6-acl-number ] * snmp-agent usm-user { v1 v2c } user-name group-name [ acl acl-number acl ipv6 ipv6-acl-number ] * 二者选其一直接设置是以 SNMPv1 和 SNMPv2c 版本的团体名进行设置间接设置是先创建 SNMP 组, 再向创建的组中添加的用户, 用户相当于 SNMPv1 和 SNMPv2c 版本的团体名, 在 NMS 上配置的团体名需要跟 Agent 上配置的用户名一致缺省情况下, 不存在任何 SNMP 组和 SNMP 团体 1-4

121 操作命令说明 ( 可选 ) 创建 SNMP 上下文 snmp-agent context context-name 缺省情况下, 设备上没有配置 SNMP 上下文 ( 可选 ) 创建一个团体名到 SNMP 上下文的映射 ( 可选 ) 设置 Agent 能处理的 SNMP 报文的最大长度 ( 可选 ) 设置 Agent 接收 SNMP 报文的端口号 snmp-agent community-map community-name context context-name snmp-agent packet max-size byte-count snmp-agent port port-num 缺省情况下, 设备上没有团体名到 SNMP 上下文的映射 缺省情况下,Agent 能接收 / 发送的 SNMP 信息包长度的最大值为 1500 字节 缺省情况下, 使用 161 端口接收 SNMP 报文 配置 SNMPv3 版本基本参数 1. 配置限制和指导建立 SNMPv3 连接时, 是否进行认证和加密, 受 snmp-agent group v3 和 snmp-agent usm-user v3 两条命令的影响 : 创建组时, 如果不指定 authentication 和 privacy 参数, 则表示不认证不加密 此时, 使用和该组绑定的用户名建立 SNMP 连接时, 均不认证不加密 即便用户配置了认证密码 / 加密密码, 认证密码 / 加密密码也不生效 创建组时, 如果指定 authentication 参数, 则表示认证不加密 此时, 使用和该组绑定的用户名建立 SNMP 连接时, 均认证不加密 即便用户配置了加密密码, 加密密码也不生效 该组内的用户必须配置认证密码, 否则, 不能建立 SNMP 连接 创建组时, 如果指定 privacy 参数, 则表示认证加密 此时, 使用和该组绑定的用户名建立 SNMP 连接时, 均认证加密 该组内的用户必须配置认证密码和加密密码, 否则, 不能建立 SNMP 连接 2. 配置步骤表 1-2 配置 SNMPv3 版本基本参数 操作命令说明进入系统视图 system-view - ( 可选 ) 启动 SNMP Agent 服务 ( 可选 ) 配置设备的维护联系信息 ( 可选 ) 配置设备的物理位置信息 snmp-agent snmp-agent sys-info contact sys-contact snmp-agent sys-info location sys-location 缺省情况下,SNMP Agent 服务处于关闭状态执行除 snmp-agent calculate-password 外任何以 snmp-agent 开头的命令, 都可以启动 SNMP Agent 服务 缺省情况下, 系统维护联系信息为 Hangzhou H3C Technologies Co.,Ltd. 缺省情况下, 物理位置信息为 Hangzhou, China 1-5

122 操作命令说明 启用 SNMPv3 版本 ( 可选 ) 设置本地 SNMP 实体的引擎 ID ( 可选 ) 设置远端 SNMP 实体的引擎 ID ( 可选 ) 创建 MIB 视图或更新 MIB 视图内容 创建 SNMPv3 组 ( 可选 ) 计算用户给定明文密码通过加密算法处理后得到的密文密码所对应的摘要 snmp-agent sys-info version v3 snmp-agent local-engineid engineid snmp-agent remote { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] engineid engineid snmp-agent mib-view { excluded included } view-name oid-tree [ mask mask-value ] 非 FIPS 模式下 : snmp-agent group v3 group-name [ authentication privacy ] [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number acl ipv6 ipv6-acl-number ] * FIPS 模式下 : snmp-agent group v3 group-name { authentication privacy } [ read-view view-name ] [ write-view view-name ] [ notify-view view-name ] [ acl acl-number acl ipv6 ipv6-acl-number ] * 非 FIPS 模式下 : snmp-agent calculate-password plain-password mode { 3desmd5 3dessha md5 sha } { local-engineid specified-engineid engineid } FIPS 模式下 : snmp-agent calculate-password plain-password mode sha { local-engineid specified-engineid engineid } 缺省情况下, 系统启用的 SNMP 版本号版本为 SNMP v3 缺省情况下, 设备引擎 ID 为公司的 企业号 + 设备信息 SNMPv3 版本的用户名 密文密码等都和引擎 ID 相关联, 如果更改了引擎 ID, 则原引擎 ID 下配置的用户名 密码失效 缺省情况下, 设备上没有配置远端 SNMP 实体的引擎 ID 当设备需要向目的主机 ( 能够解析 Trap 和 Inform 报文的设备, 通常为 NMS) 发送 SNMPv3 Inform 报文时, 该步骤必选 缺省情况下, 设备上已创建了四个视图, 视图名均为 ViewDefault: 视图一包含 MIB 子树 iso 视图二不包含子树 snmpusmmib 视图三不包含子树 snmpvacmmib 视图四不包含子树 snmpmodules.18 MIB 视图是 MIB 的子集, 由视图名和 MIB 子树来唯一确定一个 MIB 视图 视图名相同但包含的子树不同, 则认为是不同的视图 除缺省视图外, 用户最多可以创建 16 个 MIB 视图 缺省情况下, 设备上没有配置 SNMP 组, 新配置的 SNMP 组采用不认证 不加密方式 - 1-6

123 操作命令说明 非 FIPS 模式下 : 创建 SNMPv3 用户 ( 可选 ) 为通过 RBAC 方式创建的 SNMPv3 用户添加角色 ( 可选 ) 创建 SNMP 上下文 ( 可选 ) 设置 Agent 能处理的 SNMP 报文的最大长度 ( 可选 ) 设置 Agent 接收 SNMP 报文的端口号 VACM 方式 : snmp-agent usm-user v3 user-name group-name [ remote { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] [ { cipher simple } authentication-mode { md5 sha } auth-password [ privacy-mode { aes128 3des des56 } priv-password ] ] [ acl acl-number acl ipv6 ipv6-acl-number ] * RBAC 方式 : snmp-agent usm-user v3 user-name user-role role-name [ remote { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] [ { cipher simple } authentication-mode { md5 sha } auth-password [ privacy-mode { aes128 3des des56 } priv-password ] ] [ acl acl-number acl ipv6 ipv6-acl-number ] * FIPS 模式下 : VACM 方式 : snmp-agent usm-user v3 user-name group-name [ remote { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] { cipher simple } authentication-mode sha auth-password [ privacy-mode aes128 priv-password ] [ acl acl-number acl ipv6 ipv6-acl-number ] * RBAC 方式 : snmp-agent usm-user v3 user-name user-role role-name [ remote { ip-address ipv6 ipv6-address } [ vpn-instance vpn-instance-name ] ] { cipher simple } authentication-mode sha auth-password [ privacy-mode aes128 priv-password ] [ acl acl-number acl ipv6 ipv6-acl-number ] * snmp-agent usm-user user-name v3 user-role role-name snmp-agent context context-name snmp-agent packet max-size byte-count snmp-agent port port-num 当设备需要向目的主机发送 SNMPv3 Inform 报文时,remote ip-address 参数必选如果使用 cipher 参数, 则后面的 auth-password 和 priv-password 都必须输入并被视为密文密码 缺省情况下, 设备上没有配置通过 RBAC 方式创建的 SNMPv3 用户 缺省情况下, 设备上没有配置 SNMP 上下文 缺省情况下,Agent 能接收 / 发送的 SNMP 信息包长度的最大值为 1500 字节 缺省情况下, 使用 161 端口接收 SNMP 报文 1-7

124 1.3 配置 SNMP 日志 SNMP 日志可以记录 NMS 对 Agent 的 Get 请求 Set 请求和 Set 响应信息及 SNMP 认证失败信息, 不能记录 Get 响应信息 同时 SNMP 日志可以记录 Agent 对 NMS 的 Trap 和 Inform 操作信息 当进行 Get 操作时,Agent 会记录 NMS 用户的 IP 地址 Get 操作的节点名和节点 OID 当进行 Set 操作时,Agent 会记录 NMS 用户的 IP 地址 Set 操作的节点名 节点 OID 节点值以及 Set 操作返回的错误码和错误索引 当打开 SNMP 认证失败的日志开关时, 如果 Agent 收到来自 NMS 的 SNMP 请求但是没有通过认证,Agent 会记录相关信息保存到设备的信息中心 当进行 Trap 和 Inform 操作时,Agent 会向 NMS 发送告警,Agent 会记录告警相关的信息 这些日志将被发送到设备的信息中心, 级别为 informational 通过设置信息中心的参数, 最终决定 SNMP 日志的输出规则 ( 即是否允许输出以及输出方向 ) SNMP 每条日志信息中记录的 node 域 ( 信息内容对应的 MIB 节点名 ) 和 value 域 ( 信息内容对应的 MIB 节点值 ) 的长度之和不能超过 1024 字节, 超出的部分将不会被输出 有关信息中心的详细介绍请参见 网络管理和监控配置指导 中的 信息中心 表 1-3 配置 SNMP 日志功能操作命令说明进入系统视图 system-view - ( 可选 ) 打开 SNMP 日志开关 ( 可选 ) 打开 SNMP 告警日志开关 snmp-agent log { all get-operation set-operation authfail } snmp-agent trap log 大量的日志记录会占用设备的存储空间, 影响设备的性能 正常情况下, 建议关闭 SNMP 日志功能 缺省情况下,SNMP 日志开关处于关闭状态 缺省情况下,SNMP 告警日志功能处于关闭状态 1.4 配置 SNMP 告警 SNMP 告警信息包括 Trap 和 Inform 两种, 用来告知 NMS 设备上发生了重要事件, 比如, 用户的登录 / 退出, 接口状态变成 up/down 等 如无特殊说明, 本文中的告警信息均指 Trap 和 Inform 两种信息 开启告警功能因为告警信息通常较多, 会占用设备内存, 影响设备性能, 所以建议用户根据需要开启指定模块的告警功能, 生成相应的告警信息 如果要求接口在链路状态发生改变时生成相应的告警信息, 需要在全局和接口下均开启接口链路状态变化的告警功能 如果要生成其它模块的告警信息, 除了使用 snmp-agent trap enable 命令开启告警功能外, 还可能需要执行各个模块的相关配置, 详情请参见各模块的相关描述 1-8

125 表 1-4 开启告警功能 操作命令说明 进入系统视图 system-view - 在全局下开启告警功能 进入接口视图 开启接口链路状态变化的告警功能 snmp-agent trap enable [ configuration protocol standard [ authentication coldstart linkdown linkup warmstart ] * system ] interface interface-type interface-number enable snmp trap updown 缺省情况下,SNMP 配置告警 标准告警和系统告警功能处于开启状态, 其他各模块告警功能是否开启请参见各模块手册 - 缺省情况下, 接口状态变化的告警功能处于开启状态 配置告警信息发送参数如果配置了 snmp-agent target-host inform 命令, 则设备会向指定目的主机 ( 能够解析 Trap 和 Inform 报文的设备, 通常为 NMS) 发送 Inform 报文 ; 如果配置了 snmp-agent target-host trap 命令, 则设备会向指定目的主机发送 Trap 报文, 由于设备 NMS 收到 Trap 报文并不会为此发送确认信息, 所以发送 Trap 报文比 Inform 报文不可靠且占用系统资源 1. 配置指导对 linkup/linkdown 告警信息进行私有扩展后, 设备生成和发送的该信息由标准 linkup/linkdown 告警信息后增加接口描述和接口类型信息构成 如果 NMS 不支持该扩展信息, 请禁用私有扩展功能 为了成功发送 Inform 报文, 请确保以下两点 : NMS 通过 SNMPv2c 或者 SNMPv3 版本对 Agent 进行监控管理 如果要通过 V3 版本对 Agent 管理, 当进行 SNMPv3 基础配置时, 你必须配置 NMS 所管理设备的引擎 ID, 同时在创建 SNMPv3 用户时指定 SNMP 引擎的 IP 地址 设备第一次发送告警信息时, 会检查设备和目的主机是否路由可达 如果可达, 则直接发送 如果不可达, 则先将告警信息缓存在消息队列里, 等路由可达后, 再发送 为防止告警信息累积占用太多内存, 用户可以设置该队列的长度以及告警信息在队列里的保存时间 如果在告警信息的发送队列满时系统又收到了新的告警信息, 则系统会自动删除最先收到的告警信息来保存新的告警信息 如果告警信息的发送队列中的某信息到达了已设定的保存时间, 则系统会自动删除该告警信息 2. 配置准备如果要将告警信息发送给 NMS, 则需要进行以下配置准备 : (1) 配置 SNMP 基本参数 (2) 确保设备与 NMS 路由可达 1-9

126 3. 配置步骤表 1-5 配置告警信息发送参数操作 命令 说明 进入系统视图 system-view - 设置 Inform 报文的发送参数 设置 Trap 报文的发送参数 ( 可选 ) 设置发送告警信息的源地址 ( 可选 ) 对标准 linkup/linkdown 告警信息进行私有扩展 ( 可选 ) 设置告警信息发送队列的长度 ( 可选 ) 设置告警信息的保存时间 非 FIPS 模式下 : snmp-agent target-host inform address udp-domain { ip-address ipv6 ipv6-address } [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params securityname security-string { v2c v3 [ authentication privacy ] } FIPS 模式下 : snmp-agent target-host inform address udp-domain { ip-address ipv6 ipv6-address } [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params securityname security-string v3 { authentication privacy } 非 FIPS 模式下 : snmp-agent target-host trap address udp-domain { ip-address ipv6 ipv6-address } [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params securityname security-string [ v1 v2c v3 [ authentication privacy ] ] FIPS 模式下 : snmp-agent target-host trap address udp-domain { ip-address ipv6 ipv6-address } [ udp-port port-number ] [ vpn-instance vpn-instance-name ] params securityname security-string v3 { authentication privacy } snmp-agent { inform trap } source interface-type { interface-number interface-number.subnumber } snmp-agent trap if-mib link extended snmp-agent trap queue-size size snmp-agent trap life seconds 缺省情况下, 设备上没有设置 Inform 报文的目的主机 缺省情况下, 设备上没有设置 Trap 报文的目的主机 缺省情况下, 由 SNMP 选择路由出接口的 IP 地址作为告警信息的源 IP 地址 缺省情况下, 系统发送的 linkup/linkdown 告警信息的格式为标准格式, 不对其进行私有扩展 缺省情况下, 告警信息的消息队列最多可以存储 100 条告警信息 缺省情况下, 告警信息的保存时间为 120 秒 对 linkup/linkdown 告警信息进行私有扩展后, 设备生成和发送的该信息由标准 linkup/linkdown 告警信息后增加接口描述和接口类型信息构成 如果 NMS 不支持该扩展信息, 请禁用私有扩展功能 1-10

127 1.5 SNMP 显示和维护 在完成上述配置后, 在任意视图下执行 display 命令, 均可以显示配置后 SNMP 的运行情况, 通过查看显示信息, 来验证配置的效果 表 1-6 SNMP 显示和维护 操作 显示系统维护联络信息 系统位置信息及 SNMP 版本信息 显示 SNMP 报文统计信息 显示设备的 SNMP 实体引擎 ID 命令 display snmp-agent sys-info [ contact location version ] display snmp-agent statistics display snmp-agent local-engineid 显示 SNMP 组信息 display snmp-agent group [ group-name ] 显示远端 SNMP 实体引擎信息 显示告警信息队列的基本信息 显示系统当前可以发送告警信息的模块及其告警信息的使能状态 显示 SNMPv3 用户信息 显示 SNMPv1 或 SNMPv2c 团体信息 (FIPS 模式下不支持该命令 ) 显示 MIB 视图的信息 显示当前 SNMP 支持的 MIB 节点信息 display snmp-agent remote [ ip-address [ vpn-instance vpn-instance-name ] ipv6 ipv6-address [ vpn-instance vpn-instance-name ] ] display snmp-agent trap queue display snmp-agent trap-list display snmp-agent usm-user [ engineid engineid username user-name group group-name ] * display snmp-agent community [ read write ] display snmp-agent mib-view [ exclude include viewname view-name ] display snmp-agent mib-node [ details index-node trap-node verbose ] 显示指定的 SNMP 上下文 display snmp-agent context [ context-name ] 1.6 SNMPv1/v2c 典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 DOWN 状态 如果要使这些接口能够正常工作, 请先使用 undo shutdown 命令使接口状态处于 UP 设备运行于 FIPS 模式时, 不支持本例 SNMPv1 和 SNMPv2c 的配置方法相同, 下面以 SNMPv1 为例进行配置 1. 组网需求 NMS 与 Agent 相连, 设备的 IP 地址和掩码如图 1-3 所示 NMS 通过 SNMPv1 对 Agent 进行监控管理,Agent 在故障时能够主动向 NMS 发送告警信息 1-11

128 2. 组网图 图 1-3 SNMPv1 配置组网图 3. 配置步骤 (1) 配置 Agent # 配置 Agent 的 IP 地址为 /24, 并确保 Agent 与 NMS 之间路由可达 ( 配置步骤略 ) # 设置 Agent 使用的 SNMP 版本为 v1 只读团体名为 public, 读写团体名为 private <Agent> system-view [Agent] snmp-agent sys-info version v1 [Agent] snmp-agent community read public [Agent] snmp-agent community write private # 设置设备的联系人和位置信息, 以方便维护 [Agent] snmp-agent sys-info contact Mr.Wang-Tel:3306 [Agent] snmp-agent sys-info location telephone-closet,3rd-floor # 设置允许向 NMS 发送告警信息, 使用的团体名为 public [Agent] snmp-agent trap enable [Agent] snmp-agent target-host trap address udp-domain params securityname public v1 snmp-agent target-host 命令中指定的版本必须和 NMS 上运行的 SNMP 版本一致, 因此需要将 snmp-agent target-host 命令中的版本参数设置为 v1 否则,NMS 无法正确接收告警信息 (2) 配置 NMS # 设置 NMS 使用的 SNMP 版本为 SNMPv1, 只读团体名为 public, 读写团体名为 private 另外, 还可以根据需求设置 超时 时间和 重试次数 具体配置请参考 NMS 的相关手册 NMS 侧的配置必须和 Agent 侧保持一致, 否则无法通信 (3) 结果验证 # 通过查询 Agent 上相应的 MIB 节点获取 NULL0 接口的 MTU 值, 结果为 1500: Send request to / Protocol version: SNMPv1 Operation: Get Request binding: 1: Response binding: 1: Oid=ifMtu Syntax=INT Value=1500 Get finished 1-12

129 # 当使用错误的团体名获取 Agent 上的 MIB 节点信息时,NMS 上将看到认证失败的 Trap 信息, 即 authenticationfailure: /2934 V1 Trap = authenticationfailure SNMP Version = V1 Community = public Command = Trap Enterprise = GenericID = 4 SpecificID = 0 Time Stamp = 8:35: SNMPv3 典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 DOWN 状态 如果要使这些接口能够正常工作, 请先使用 undo shutdown 命令使接口状态处于 UP 1. 组网需求 NMS 与 Agent 相连, 设备的 IP 地址和掩码如图 1-4 所示 NMS 通过 SNMPv3 只能对 Agent 的 SNMP 报文的相关信息进行监控管理,Agent 在出现故障时能够主动向 NMS 发送告警信息,NMS 上接收 SNMP 告警信息的默认 UDP 端口号为 162 NMS 与 Agent 建立 SNMP 连接时, 需要认证, 使用的认证算法为 SHA-1, 认证密码为 TESTauth&! NMS 与 Agent 之间传输的 SNMP 报文需要加密, 使用的加密协议为 AES, 加密密码为 TESTencr&! 2. 组网图图 1-4 SNMPv3 配置组网图 3. 通过 RBAC 方式配置步骤 (1) 配置 Agent # 配置 Agent 的 IP 地址为 /24, 并确保 Agent 与 NMS 之间路由可达 ( 配置步骤略 ) # 创建用户角色 test 并设置访问权限 : 用户只能读写节点 snmp(oid 为 ) 下的对象, 不可以访问其它 MIB 对象 <Agent> system-view [Agent] role name test [Agent-role-test] rule 1 permit read write oid

130 # 配置用户角色 test 具有 system(oid 为 ) 与 hh3cuimgt(oid 为 ) 的读权限, 以便用户登录 退出设备时,Agent 会向 NMS 发送告警信息 [Agent-role-test] rule 2 permit read oid [Agent-role-test] rule 3 permit read oid [Agent-role-test] quit # 创建用户名 managev3user, 为其绑定用户角色 test, 认证算法为 SHA-1, 认证密码为 TESTauth&!, 加密算法为 AES, 加密密码是 TESTencr&! [Agent] snmp-agent usm-user v3 managev3user user-role test simple authentication-mode sha TESTauth&! privacy-mode aes TESTencr&! # 设置设备的联系人和位置信息, 以方便维护 [Agent] snmp-agent sys-info contact Mr.Wang-Tel:3306 [Agent] snmp-agent sys-info location telephone-closet,3rd-floor # 设置允许向 NMS 发送告警信息, 使用的用户名为 managev3user [Agent] snmp-agent trap enable [Agent] snmp-agent target-host trap address udp-domain params securityname managev3user v3 privacy (2) 配置 NMS # 设置 NMS 使用的 SNMP 版本为 SNMPv3, 用户名为 managev3user, 启用认证和加密功能, 认证算法为 SHA-1, 认证密码为 TESTauth&!, 加密协议为 AES, 加密密码为 TESTencr&! 另外, 还可以根据需求设置 超时 时间和 重试次数 具体配置请参考 NMS 的相关手册 NMS 侧的配置必须和设备侧保持一致, 否则无法进行相应操作 4. 通过 VACM 方式配置步骤 (1) 配置 Agent # 配置 Agent 的 IP 地址为 /24, 并确保 Agent 与 NMS 之间路由可达 ( 配置步骤略 ) # 设置访问权限 : 用户只能读写节点 iftable(oid 为 ) 下的对象, 不可以访问其它 MIB 对象 <Agent> system-view [Agent] undo snmp-agent mib-view ViewDefault [Agent] snmp-agent mib-view included test iftable [Agent] snmp-agent group v3 managev3group privacy read-view test write-view test # 设置访问权限 : 配置用户具有 system ( OID 为 ) 与 hh3cuimgt ( OID 为 ) 的读权限, 以便用户登录 退出设备时,Agent 会向 NMS 发送告警信息 [Agent] snmp-agent mib-view included test [Agent] snmp-agent mib-view included test [Agent] snmp-agent group v3 managev3group privacy read-view test # 设置 Agent 使用的用户名为 managev3user, 认证算法为 SHA-1, 认证密码为 TESTauth&!, 加密算法为 AES, 加密密码是 TESTencr&! [Agent] snmp-agent usm-user v3 managev3user managev3group simple authentication-mode sha TESTauth&! privacy-mode aes TESTencr&! 1-14

131 # 设置设备的联系人和位置信息, 以方便维护 [Agent] snmp-agent sys-info contact Mr.Wang-Tel:3306 [Agent] snmp-agent sys-info location telephone-closet,3rd-floor # 设置允许向 NMS 发送告警信息, 使用的用户名为 managev3user [Agent] snmp-agent trap enable [Agent] snmp-agent target-host trap address udp-domain params securityname managev3user v3 privacy (2) 配置 NMS # 设置 NMS 使用的 SNMP 版本为 SNMPv3, 用户名为 managev3user, 启用认证和加密功能, 认证算法为 SHA-1, 认证密码为 TESTauth&!, 加密协议为 AES, 加密密码为 TESTencr&! 另外, 还可以根据需求设置 超时 时间和 重试次数 具体配置请参考 NMS 的相关手册 NMS 侧的配置必须和设备侧保持一致, 否则无法进行相应操作 5. 结果验证 # 通过查询 Agent 上相应的 MIB 节点获取 sysname, 结果为 Agent: Send request to / Protocol version: SNMPv3 Operation: Get Request binding: 1: Response binding: 1: Oid= sysname.0 Syntax=OCTETS Value=Agent Get finished # 通过 Agent 上 sysname 节点设置设备名称时, 由于没有权限, 操作失败 : Send request to / Protocol version: SNMPv3 Operation: Set Request binding: 1: Response binding: Session failed! SNMP: Cannot access variable, No Access, error index=11: Oid=sysName.0 Syntax=OCTETS Value=h3c Set finished 只有通过 RBAC 方式配置才会产生如下日志 : %Aug 14 16:13:21: Agent SNMP/5/SNMP_SETDENY: -IPAddr= SecurityName=managev3user-SecurityModel=SNMPv3-OP=SET-Node=sysName( )-Value=h3c; Permission denied. # 某个用户登录设备,NMS 上将看到相应的 Trap 信息 : hh3clogin inform received from: at 2013/8/14 17:36:16 Time stamp: 0 days 08h:03m:43s.37th Agent address: Port: Transport: IP/UDP Protocol: SNMPv2c Inform Manager address: Port: Transport: IP/UDP Community: public 1-15

132 Bindings (4) Binding #1: sysuptime.0 *** (timeticks) 0 days 08h:03m:43s.37th Binding #2: snmptrapoid.0 *** (oid) hh3clogin Binding #3: hh3cterminalusername.0 *** (octets) testuser [ hex)] Binding #4: hh3cterminalsource.0 *** (octets) VTY [ (hex)] 1-16

133 目录 1 RMON RMON 简介 RMON 概述 RMON 的工作机制 RMON 组 告警组和扩展告警组的采样类型 协议规范 配置 RMON 统计功能 配置 RMON 以太网统计功能 配置 RMON 历史统计功能 配置 RMON 告警功能 配置准备 配置限制和指导 配置步骤 RMON 显示和维护 RMON 典型配置举例 统计功能典型配置举例 历史统计功能典型配置举例 告警功能典型配置举例 1-9 i

134 1 RMON 1.1 RMON 简介 RMON 概述 RMON(Remote Network Monitoring, 远程网络监视 ) 主要实现了统计和告警功能, 用于网络中管理设备对被管理设备的远程监控和管理 统计功能指的是被管理设备可以按周期或者持续跟踪统计其端口所连接的网段上的各种流量信息, 比如某段时间内某网段上收到的报文总数, 或收到的超长报文的总数等 告警功能指的是被管理设备能监控指定 MIB 变量的值, 当该值达到告警阈值时 ( 比如端口速率达到指定值, 或者广播报文的比例达到指定值 ), 能自动记录日志 生成告警信息发送给 SNMP 模块, 由 SNMP 模块发送给管理设备 有关告警信息的详细介绍, 请参见 网络管理和监控配置指导 中的 SNMP RMON 和 SNMP 都用于远程网络管理 : SNMP 是 RMON 实现的基础 RMON 使用 SNMP 告警信息发送机制向管理设备发送告警信息告知告警变量的异常 虽然 SNMP 也定义了告警功能, 但通常用于告知被管理设备上某功能是否运行正常 接口物理状态的变化等, 两者监控的对象 触发条件以及报告的内容均不同 RMON 是 SNMP 功能的增强 RMON 能更有效 更积极主动地监测远程网络设备, 为监控子网的运行提供了一种高效的手段 RMON 协议规定达到告警阈值时被管理设备能自动生成告警信息发送给设备的 SNMP 模块, 所以管理设备不需要多次去获取 MIB 变量的值, 进行比较, 从而能够减少管理设备同被管理设备的通讯流量, 达到简便而有力地管理大型互连网络的目的 RMON 的工作机制 RMON 允许有多个监控者, 监控者可用两种方法收集数据 : 第一种方法利用专用的 RMON probe( 探测仪 ) 收集数据, 管理设备直接从 RMON probe 获取管理信息并控制网络资源 这种方式可以获取 RMON MIB 的全部信息 ; 第二种方法是将 RMON Agent 直接植入网络设备 ( 路由器 交换机 HUB 等 ), 使它们成为带 RMON probe 功能的网络设施 管理设备使用 SNMP 的基本操作与 RMON Agent 交换数据信息, 收集网络管理信息, 但这种方法受设备资源限制, 不能获取 RMON MIB 的所有数据, 只收集事件组 告警组 历史组和统计组四个组的信息 H3C 采用第二种方法, 在设备上实现了 RMON Agent 功能 通过该功能, 管理设备可以获得与被管网络设备端口相连的网段上的整体流量 错误统计和性能统计等信息, 进而实现对网络的管理 RMON 组 RMON 协议中定义了多个 RMON 组, 设备实现了公有 MIB 中支持的统计组 历史组 事件组 告警组 代理配置组和用户历史组 此外,H3C 还自定义和实现了扩展告警组, 以增强告警组的功能 1-1

135 其中, 代理配置组和用户历史组只支持 MIB 操作, 具体内容请参考 Comware V7 Platform MIB Companion 中 RMON 章节 1. 统计组统计组规定系统将持续地对端口的各种流量信息进行统计 ( 目前只支持对以太网端口的统计 ), 并将统计结果存储在以太网统计表 (etherstatstable) 中以便管理设备随时查看 在指定接口下创建统计表项成功后, 统计组就对当前接口的报文数进行统计, 它统计的结果是一个连续的累加值 统计信息包括网络冲突数 CRC 校验错误报文数 过小 ( 或超大 ) 的数据报文数 广播 多播的报文数以及接收字节数 接收报文数等 2. 历史组历史组规定系统将按指定周期对端口的各种流量信息进行统计, 并将统计结果存储在历史记录表 (etherhistorytable) 中以便管理设备随时查看 历史组统计的是每个周期内端口接收报文的情况, 统计数据包括带宽利用率 错误包数和总包数等, 周期的长短可以通过命令行来配置 3. 事件组事件组用来定义事件索引号及事件的处理方式 事件组定义的事件用于告警组表项和扩展告警组表项中 当监控对象达到告警条件时, 就会触发事件, 事件有如下几种处理方式 : Log: 将事件相关信息 ( 事件发生的时间 事件的内容等 ) 记录在本设备 RMON MIB 的事件日志表中, 以便管理设备通过 SNMP Get 操作进行查看 Trap: 表示事件被触发时, 会生成告警信息发送给设备的 SNMP 模块 Log-Trap: 表示事件被触发时, 既在本设备上记录日志, 又会生成告警信息发送给设备的 SNMP 模块 None: 不做任何处理 4. 告警组 RMON 告警管理可对指定的告警变量 ( 如端口收到的报文总数 etherstatspkts) 进行监视 用户定义了告警表项后, 系统会按照定义的时间周期去获取被监视的告警变量的值, 当告警变量的值大于或等于上限阈值时, 触发一次上限告警事件 ; 当告警变量的值小于或等于下限阈值, 触发一次下限告警事件, 告警管理将按照事件的定义进行相应的处理 当告警变量的采样值在同一方向上连续多次超过阈值时, 只会在第一次产生告警事件, 后面的几次不会产生告警事件 即上限告警和下限告警是交替产生的, 出现了一次上限告警, 则下一次必为下限告警 如图 1-1 所示, 告警变量的值 ( 如图中黑色曲线所示 ) 多次超过阈值 ( 如图中蓝色直线所示 ), 产生了多个交叉点, 但只有红叉标识的交叉点才会触发告警事件, 其它交叉点不会触发告警事件 1-2

136 图 1-1 上下限告警示意图 5. 扩展告警组扩展告警表项可以对告警变量进行运算, 然后将运算结果和设置的阈值比较, 实现更为丰富的告警功能 用户定义了扩展告警表项后, 系统对扩展告警表项的处理如下 : (1) 对定义的扩展告警公式中的告警变量按照定义的时间间隔进行采样 (2) 将采样值按照定义的运算公式进行计算 (3) 将计算结果和设定的阈值进行比较, 大于或等于上限阈值时, 触发一次上限告警事件 ; 小于或等于下限阈值, 触发一次下限告警事件 与告警组一样, 当扩展告警组的运算结果在同一方向上连续多次超过阈值时, 只会在第一次产生告警事件, 后面的几次不会产生告警事件, 即上限告警和下限告警是交替产生的 告警组和扩展告警组的采样类型 RMON Agent 支持如下采样类型 : absolute: 采样类型为绝对值采样, 即采样时间到达时直接提取变量的值 delta: 采样类型为变化值采样, 即采样时间到达时提取的是变量在采样间隔内的变化值 协议规范与 RMON 相关的协议规范有 : RFC 4502:Remote Network Monitoring Management Information Base Version 2 RFC 2819:Remote Network Monitoring Management Information Base Status of this Memo 1.2 配置 RMON 统计功能 RMON 的统计功能可以通过 RMON 统计组或者 RMON 历史组来实现, 但是两者统计的对象不同, 请根据实际需要配置 1-3

137 RMON 统计组统计的是 RMON 以太网统计表里定义的变量, 记录的是从 RMON 统计表项创建到当前阶段变量的累加值, 具体配置请参见 配置 RMON 以太网统计功能 RMON 历史组统计的是 RMON 历史记录表里定义的变量, 记录的是每个周期内变量的累加值, 具体配置请参见 配置 RMON 历史统计功能 配置 RMON 以太网统计功能表 1-1 配置 RMON 以太网统计功能操作命令说明进入系统视图 system-view - 进入以太网接口视图 创建统计表项 interface interface-type interface-number rmon statistics entry-number [ owner text ] - 缺省情况下, 统计表中没有任何表项 每个接口下只能创建一个统计表项, 整个设备允许创建的统计表项最大数目为 100 条 当统计表项的总数大于 100 条时, 创建操作失败 配置 RMON 历史统计功能配置 RMON 历史统计功能时, 需要注意 : 历史控制表项的 entry-number 必须全局唯一, 如果已经在其他接口下使用, 则创建操作失败 同一接口下, 可以创建多条历史控制表项, 但要求不同表项 entry-number 和 sampling-interval 的值必须不同, 否则创建操作失败 整个设备允许创建的控制历史表项最大数目为 100 条 当控制历史表项的总数大于 100 条时, 创建操作失败 在创建历史控制表项时, 如果指定的 buckets number 参数值超出了设备实际支持的历史表容量时, 该历史控制表项会被添加, 但该表项对应生效的 buckets number 的值为设备实际支持的历史表容量 表 1-2 配置 RMON 历史统计功能 操作命令说明进入系统视图 system-view - 进入以太网接口视图 创建历史控制表项 interface interface-type interface-number rmon history entry-number buckets number interval sampling-interval [ owner text ] - 缺省情况下, 历史控制表中没有任何表项 1-4

138 1.3 配置 RMON 告警功能 配置准备如果触发告警事件时, 需要向管理设备 (NMS) 发送告警信息, 则在配置 RMON 告警功能之前, 必须保证 SNMP Agent 已经正确配置 SNMP Agent 的配置请参见 网络管理和监控配置指导 中的 SNMP 配置限制和指导 系统不允许创建两个配置完全相同的表项 如果新建表项参数的值和已存在表项对应参数的值完全相同, 则创建操作失败 不同表项需要比较的参数不同, 请参见表 1-3 系统对每种类型表项的总数均进行了限制, 具体数目请参见表 1-3 当某种类型表项的总数达到系统允许创建的最大数目时, 创建操作失败 表 1-3 RMON 配置约束表 表项名需要比较的参数最多可创建的表项数 事件表项 告警表项 扩展告警表项 事件描述 (description string) 事件类型 (log trap logtrap 或 none) 和团体名 (security-string ) 告警变量 (alarm-variable) 采样间隔 (sampling-interval) 采样类型 (absolute 或 delta) 上限阈值 (threshold-value1) 和下限阈值 (threshold-value2) 告警变量公式 (prialarm-formula) 采样间隔 (sampling-interval) 采样类型 (absolute 或 delta) 上限阈值 (threshold-value1) 和下限阈值 (threshold-value2) 配置步骤 表 1-4 配置 RMON 告警功能 操作命令说明 进入系统视图 system-view - ( 可选 ) 创建事件表项 创建告警表项 创建扩展告警表项 rmon event entry-number [ description string ] { log log-trap security-string none trap security-string } [ owner text ] rmon alarm entry-number alarm-variable sampling-interval { absolute delta } [ startup-alarm { falling rising rising-falling } ] rising-threshold threshold-value1 event-entry1 falling-threshold threshold-value2 event-entry2 [ owner text ] rmon prialarm entry-number prialarm-formula prialarm-des sampling-interval { absolute delta } [ startup-alarm { falling rising rising-falling } ] rising-threshold threshold-value1 event-entry1 falling-threshold threshold-value2 event-entry2 entrytype { forever cycle cycle-period } [ owner text ] 缺省情况下, 事件表中没有任何表项 二者至少选其一缺省情况下, 告警表 / 扩展告警表中没有任何表项配置时如果指定的事件表项 event-entry 不存在也允许配置, 但触发告警时不会有事件动作 1-5

139 1.4 RMON 显示和维护 在完成上述配置后, 在任意视图下执行 display 命令可以显示配置后 RMON 的运行情况, 通过查看显示信息, 验证配置的效果 表 1-5 RMON 显示和维护 操作 显示 RMON 统计信息 显示 RMON 历史控制表及历史采样信息 显示 RMON 告警表项的相关信息 显示 RMON 扩展告警表项的相关信息 显示 RMON 事件表项的相关信息 命令 display rmon statistics [ interface-type interface-number] display rmon history [ interface-type interface-number ] display rmon alarm [ entry-number ] display rmon prialarm [ entry-number ] display rmon event [ entry-number ] 显示事件日志表项的相关信息 display rmon eventlog [ entry-number ] 1.5 RMON 典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 Down 状态, 如果要使这些接口能够正常工作, 请先使用 undo shutdown 命令使这些接口处于 UP 状态 统计功能典型配置举例 1. 组网需求 Device 通过以太网线缆连接 Server 现需要通过 RMON 统计表对以太网接口 GigabitEthernet3/0/18 接收的报文进行性能统计 管理员随时查看统计数据了解接口接收报文的情况 1-6

140 图 1-2 配置 RMON 组网图 2. 配置步骤 # 使用 RMON 对接口 GigabitEthernet3/0/18 进行流量统计 <Sysname> system-view [Sysname] interface GigabitEthernet 3/0/18 [Sysname-GigabitEthernet3/0/18] rmon statistics 1 owner user1 以上配置完成后系统就开始对接口 GigabitEthernet3/0/18 接收的报文进行分类统计, 统计的结果可以通过多种方式查看 : 查看接口的统计信息 <Sysname> display rmon statistics GigabitEthernet 3/0/18 EtherStatsEntry 1 owned by user1 is VALID. Interface : GigabitEthernet3/0/18<ifIndex.3> etherstatsoctets : 21657, etherstatspkts : 307 etherstatsbroadcastpkts : 56, etherstatsmulticastpkts : 34 etherstatsundersizepkts : 0, etherstatsoversizepkts : 0 etherstatsfragments : 0, etherstatsjabbers : 0 etherstatscrcalignerrors : 0, etherstatscollisions : 0 etherstatsdropevents (insufficient resources): 0 Incoming packets by size: 64 : 235, : 67, : : 1, : 0, : 0 在 NMS 上通过软件执行 Get 操作, 直接获取 MIB 节点的值 历史统计功能典型配置举例 1. 组网需求 Device 通过以太网线缆连接 Server 现需要每 1 分钟通过 RMON 历史统计表对以太网接口 GigabitEthernet3/0/18 接收的报文进行周期性统计 管理员能够随时了解短时间内接口是否有数据突发 1-7

141 图 1-3 配置 RMON 组网图 2. 配置步骤 # 使用 RMON 对接口 GigabitEthernet3/0/18 进行周期性流量统计 <Sysname> system-view [Sysname] interface GigabitEthernet 3/0/18 [Sysname-GigabitEthernet3/0/18] rmon history 1 buckets 8 interval 60 owner user1 以上配置完成后, 系统就开始对接口 GigabitEthernet3/0/18 接收的报文进行周期性分类统计, 每 1 分钟统计一次, 历史统计列表里会保存最近的 8 次统计的结果, 以便管理员查看 统计的结果可以 通过以下方式查看 : 查看接口的历史统计信息 [Sysname-GigabitEthernet3/0/18] display rmon history HistoryControlEntry 1 owned by user1 is VALID Sampled interface : GigabitEthernet3/0/18<ifIndex.3> Sampling interval : 60(sec) with 8 buckets max Sampling record 1 : dropevents : 0, octets : 834 packets : 8, broadcast packets : 1 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 2 : dropevents : 0, octets : 962 packets : 10, broadcast packets : 3 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 3 : dropevents : 0, octets : 830 packets : 8, broadcast packets : 0 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 4 : dropevents : 0, octets :

142 packets : 8, broadcast packets : 0 multicast packets : 7, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 5 : dropevents : 0, octets : 898 packets : 9, broadcast packets : 2 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 6 : dropevents : 0, octets : 898 packets : 9, broadcast packets : 2 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 7 : dropevents : 0, octets : 766 packets : 7, broadcast packets : 0 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 Sampling record 8 : dropevents : 0, octets : 1154 packets : 13, broadcast packets : 1 multicast packets : 6, CRC alignment errors : 0 undersize packets : 0, oversize packets : 0 fragments : 0, jabbers : 0 collisions : 0, utilization : 0 在 NMS 上通过软件执行 Get 操作, 直接获取 MIB 节点的值 告警功能典型配置举例 1. 组网需求 Device 通过以太网线缆与 Server 和 NMS 相连 GigabitEthernet3/0/10 接口连接 Server, 现需要对该服务器的流量进行统计 以 5 秒的采样间隔采样, 当流量过大或过低时发送相应的告警信息给设备的 SNMP 模块, 由 SNMP 模块通知 NMS 1-9

143 图 1-4 配置 RMON 组网图 2. 配置步骤 # 配置 SNMP Agent ( 请注意 : 这些参数的值应与 NMS 侧的配置一致, 假设 NMS 上运行 SNMP v1, 访问设备时使用的可读团体名为 public, 可写团体名为 private,nms 的 IP 地址为 ) <Sysname> system-view [Sysname] snmp-agent [Sysname] snmp-agent community read public [Sysname] snmp-agent community write private [Sysname] snmp-agent sys-info version v1 [Sysname] snmp-agent trap enable [Sysname] snmp-agent trap log [Sysname] snmp-agent target-host trap address udp-domain params securityname public # 使用 RMON 对以太网接口 GigabitEthernet3/0/10 进行统计 [Sysname] interface GigabitEthernet 3/0/10 [Sysname-GigabitEthernet3/0/10] rmon statistics 1 owner user1 [Sysname-GigabitEthernet3/0/10] quit # 配置 RMON 告警表项 ( 当节点 的相对采样值超过 100 时或者低于 50 时, 都触发事件 1 生成告警信息发送给设备的 SNMP 模块 ) [Sysname] rmon event 1 trap public owner user1 [Sysname] rmon alarm delta rising-threshold falling-threshold 50 1 owner user1 # 查看 RMON 告警表信息 <Sysname> display rmon alarm 1 AlarmEntry 1 owned by user1 is VALID. Sample type : delta Sampled variable : <etherStatsOctets.1> Sampling interval (in seconds) : 5 Rising threshold : 100(associated with event 1) Falling threshold : 50(associated with event 1) Alarm sent upon entry startup : risingorfallingalarm Latest value : 0 # 查看以太网接口的统计信息 <Sysname> display rmon statistics GigabitEthernet 3/0/10 EtherStatsEntry 1 owned by user1 is VALID. Interface : GigabitEthernet3/0/10<ifIndex.3> etherstatsoctets : 57329, etherstatspkts : 455 etherstatsbroadcastpkts : 53, etherstatsmulticastpkts :

144 etherstatsundersizepkts : 0, etherstatsoversizepkts : 0 etherstatsfragments : 0, etherstatsjabbers : 0 etherstatscrcalignerrors : 0, etherstatscollisions : 0 etherstatsdropevents (insufficient resources): 0 Incoming packets by size : 64 : 7, : 413, : : 0, : 0, : 0 完成以上配置后, 当告警事件被触发时, 在 NMS 的告警管理部分可以查看相应的记录 在设备侧也会有相应信息, 如下所示 [Sysname] %Mar 28 09:23:53: MDC4 SNMP/6/SNMP_NOTIFY: -MDC=4; Notification fallinga larm( ) with alarmindex( )=1;alarmvariab le( )= ;alarmsampletype( )=2;alarmValue( )=0;alarmFallingThreshold( )=

145 目录 1 NETCONF NETCONF 简介 NETCONF 协议结构 NETCONF 报文格式 如何使用 NETCONF 协议规范 NETCONF 配置任务简介 使能 NETCONF over SOAP 功能 使能 NETCONF over SSH 功能 建立 NETCONF 会话 进入 XML 视图 交换能力集 向设备进行事件订阅 订阅事件 订阅事件举例 给当前配置加锁 / 解锁 给当前配置加锁 给当前配置解锁 当前配置加锁举例 业务处理功能 <get>/<get-bulk> 获取信息 <get-config>/<get-bulk-config> 获取配置信息 <edit-config> 编辑指定模块数据 举例 获取所有模块所有配置数据 举例 获取 Syslog 模块的所有配置数据 举例 取接口表的一条数据 举例 修改参数值 设置空闲配置自动回滚 配置回滚点设置 主动下发配置回滚 主动下发配置确认 配置保存 回滚 加载 配置保存 1-21 i

146 配置回滚 加载文件 配置保存举例 数据过滤功能 三种数据过滤方式 正则表达式操作举例 条件匹配操作举例 命令行操作 命令行操作 命令行操作举例 获取会话信息 获取会话信息 获取会话信息举例 关闭另一个会话 Kill-session 操作 Kill-session 举例 退出 XML 视图 附录 附录 A Comware V7 中支持的 NETCONF 操作类型 2-1 ii

147 1 NETCONF 设备运行于 FIPS 模式时, 本特性的部分配置相对于非 FIPS 模式有所变化, 具体差异请见本文相关 描述 有关 FIPS 模式的详细介绍请参见 安全配置指导 中的 FIPS 1.1 NETCONF 简介 NETCONF(Network Configuration Protocol, 网络配置协议 ) 是一种基于 XML 的网络管理协议, 它提供了一种可编程的 对网络设备进行配置和管理的方法 用户可以通过该协议设置参数 获取参数值 获取统计信息等 NETCONF 报文使用 XML 格式, 具有强大的过滤能力, 而且每一个数据项都有一个固定的元素名称和位置, 这使得同一厂商的不同设备具有相同的访问方式和结果呈现方式, 不同厂商之间的设备也可以经过映射 XML 得到相同的效果, 这使得它在第三方软件的开发上非常便利, 很容易开发出在混合不同厂商 不同设备的环境下的特殊定制的网管软件 在这样的网管软件的协助下, 使用 NETCONF 功能会使网络设备的配置管理工作, 变得更简单更高效 NETCONF 协议结构 NETCONF 协议采用了分层结构, 分成四层 : 内容层 操作层 RPC(Remote Procedure Call, 远程调用 ) 层和通信协议层 表 1-1 XML 分层与 NETCONF 分层模型对应关系 NETCONF 分层 Content Operations RPC XML 分层 配置数据 状态数据 统计信息等 <get>,<get-config>, <edit-config> <rpc>,<rpc-reply> 说明 内容层表示的是被管理对象的集合, 可以是配置数据 状态数据 统计信息等 NETCONF 协议具体可读写的数据请参见 NETCONF XML API 手册 操作层定义了一系列在 RPC 中应用的基本的原语操作集, 这些操作将组成 NETCONF 的基本能力 NETCONF 全面地定义了对被管理设备的九种基础操作设备支持的操作请参见 2.1 附录 A Comware V7 中支持的 NETCONF 操作类型 RPC 层为 RPC 模块的编码提供了一个简单的 传输协议无关的机制 通过使用 <rpc> 和 <rpc-reply> 元素分别对 NETCONF 请求和响应数据 ( 即操作层和内容层的内容 ) 进行封装 1-1

148 NETCONF 分层 Transport Protocol XML 分层 非 FIPS 模式下 : Console/Telnet/SS H/HTTP/HTTPS/TL S FIPS 模式下 : Console/SSH/HTTP S/TLS 说明 非 FIPS 模式下 : 通信协议层为 NETCONF 提供面向连接的 可靠的 顺序的数据链路 NETCONF 支持 Telnet SSH Console 等 CLI 登录方式 / 协议, 即 NETCONF over SSH/Telnet/Console;NETCONF 支持 HTTP HTTPS 登录协议, 即 NETCONF over HTTPS/HTTP;NETCONF 还支持封装成 SOAP(Simple Object Access Protocol, 简单对象访问协议 ) 报文后通过 HTTP HTTPS 协议传输, 即 NETCONF over SOAP over HTTP/HTTPS FIPS 模式下 : 通信协议层为 NETCONF 提供面向连接的 可靠的 顺序的数据链路 NETCONF 支持 SSH Console 等 CLI 登录方式 / 协议, 即 NETCONF over SSH/Console;NETCONF 支持 HTTPS 登录协议, 即 NETCONF over HTTPS;NETCONF 还支持封装成 SOAP 报文后通过 HTTPS 协议传输, 即 NETCONF over SOAP over HTTPS NETCONF 报文格式 1. NETCONF NETCONF 命令必须符合 XML 语言的基本格式 NETCONF 和 NETCONF over SOAP 报文格式请遵循 RFC 4741 NETCONF 操作以及可操作的数据项, 请参见 NETCONF XML API 手册 NETCONF 报文的数据合法性都将经过校验才会下发, 如果校验失败则会向客户端报错 其中, 数据合法性校验通过 XML Schema 的方式完成 在 XML 视图下进行 NETCONF 配置时,XML 报文最后需要添加 ]]>]]>, 否则设备无法识别, 本手册举例中, 为方便识别 XML 格式, 均未添加此结束符, 实际操作中, 请自行添加 如下为一个 NETCONF 报文示例, 用于获取设备上所有接口的所有参数 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-bulk> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-bulk> </rpc> 1-2

149 2. NETCONF over SOAP NETCONF over SOAP 之后,NETCONF 报文会放在 SOAP 报文的 BODY 元素里, 这些报文除了 需要遵循纯 NETCONF 报文的规则外, 还需要遵循以下规则 : SOAP 消息必须用 XML 来编码 SOAP 消息必须使用 SOAP Envelope 命名空间 SOAP 消息必须使用 SOAP Encoding 命名空间 SOAP 消息不能包含 DTD(Decoument Type Definition, 文件类型定义 ) 引用 SOAP 消息不能包含 XML 处理指令 如下为一个 NETCONF over SOAP 报文示例, 用于获取设备上所有接口的所有参数 : <env:envelope xmlns:env=" <env:header> <auth:authentication env:mustunderstand="1" xmlns:auth=" <auth:authinfo>800207f c</auth:authinfo> </auth:authentication> </env:header> <env:body> <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-bulk> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-bulk> </rpc> </env:body> </env:envelope> 如何使用 NETCONF 用户可通过以下三种方式来使用 NETCONF 协议配置 / 管理设备 : 用户可以通过 Telnet SSH Console 登录到设备的 CLI 界面, 通过命令行界面编辑下发 NETCONF 指令 该方式一般用于研发和测试环境 在 XML 视图下, 将合法的 NETCONF 报文直接拷贝 粘贴到命令行提示符处, 即可验证设备的 NETCONF 功能是否运行正常 非 FIPS 模式下, 用户可以通过 HTTP HTTPS 登录到设备的 Web 页面, 系统会自动将 Web 页面的配置转换成 NETCONF 指令下发给设备来实现对设备的访问 ;FIPS 模式下, 用户可以通过 HTTPS 登录到设备的 Web 页面, 系统会自动将 Web 页面的配置转换成 NETCONF 指令下发给设备来实现对设备的访问 该方式为 NETCONF 最普遍的使用方式, 用户在简洁易用的图像化 Web 页面上完成配置, 配置结果也会以简洁清晰的方式呈现给用户, 整个 NETCONF 的交互过程对用户透明 1-3

150 用户使用自己开发的 Web 配置工具给设备下发 NETCONF 指令来实现对设备的访问 因为用户开发的 Web 页面的 URL 和设备出厂支持的 Web 页面的 URL 不一致, 用户需要将下发 NETCONF 指令用 SOAP 封装成一种通用的格式, 以便设备能够正常转换 因此, 使用该方式前必须使能 NETCONF over SOAP 功能 协议规范与 NETCONF SOAP 协议相关的协议规范有 : RFC 3339:Date and Time on the Internet: Timestamps RFC 4741:NETCONF Configuration Protocol RFC 4742:Using the NETCONF Configuration Protocol over Secure SHell (SSH) RFC 4743:Using NETCONF over the Simple Object Access Protocol (SOAP) RFC 5277:NETCONF Event Notifications RFC 5381:Experience of Implementing NETCONF over SOAP RFC 5539:NETCONF over Transport Layer Security (TLS) RFC 6241:Network Configuration Protocol 1.2 NETCONF 配置任务简介 表 1-2 NETCONF 配置任务简介配置任务 说明 详细配置 使能 NETCONF over SOAP 功能 可选 1.3 使能 NETCONF over SSH 功能 可选 1.4 建立 NETCONF 会话 必选 1.5 向设备进行事件订阅 可选 1.6 给当前配置加锁 / 解锁 可选 1.7 <get>/<get-bulk> 获取信息 可选 <get-config>/<get-bulk-config> 获取配置信息 可选 <edit-config> 编辑指定模块数据 可选 配置保存 回滚 加载 可选 1.9 通配符和过滤器功能 可选 1.11 命令行操作 可选 1.12 获取会话信息 可选 1.13 关闭另一个会话 可选 1.14 退出 XML 视图 可选

151 1.3 使能 NETCONF over SOAP 功能 NETCONF 支持封装成 SOAP 报文后通过 HTTP HTTPS 协议传输, 即 NETCONF over SOAP over HTTP/HTTPS, 使用该功能后, 用户可以通过开发 Web 配置工具给设备下发 NETCONF 指令来实现对设备的访问 表 1-3 配置 SOAP 服务操作命令说明进入系统视图 system-view - 使能 HTTP 的 SOAP 功能 使能 HTTPS 的 SOAP 功能 netconf soap http enable netconf soap https enable 该命令在系统视图下执行 FIPS 模式下, 不支持本命令缺省情况下, 基于 HTTP 的 SOAP 功能处于关闭状态 该命令在系统视图下执行缺省情况下, 基于 HTTPS 的 SOAP 功能处于关闭状态 1.4 使能 NETCONF over SSH 功能 NETCONF 支持标准协议规范中描述的 NETCONF over SSH 功能, 使能该功能后, 用户可以通过使用支持 NETCONF over SSH 登录方式的客户端配置工具给设备下发 NETCONF 指令来实现对设备的访问 表 1-4 配置 NETCONF over SSH 服务操作命令说明进入系统视图 system-view - 指定 NETCONF over SSH 的监听端口 使能 NETCONF over SSH 功能 netconf ssh server port port-number netconf ssh server enable 该命令在系统视图下执行缺省情况下,NETCONF over SSH 使用端口 830 该命令在系统视图下执行缺省情况下,NETCONF over SSH 功能处于关闭状态 1-5

152 1.5 建立 NETCONF 会话 客户端必须给设备发送 hello 信息, 完成能力集的交互后, 设备才会处理客户端发送的其它请求 设备同一时间内允许建立的最大连接数可以通过 aaa session-limit 命令配置, 关于该命令的详细描述, 请参见 安全命令参考 中的 AAA 用户数超过上限后, 新登录的用户将登录失败 进入 XML 视图表 1-5 进入 XML 视图 操作命令说明进入 XML 视图 xml 该命令在用户视图下执行 交换能力集 进入 XML 视图后, 客户端和设备必须交换各自支持的能力集, 双方收到对方的能力集后才可以进 行下一步操作 1. 设备发送给客户端的报文 客户端进入 XML 视图后, 设备会发送如下报文自动告知客户端支持的 NETCONF 能力集 : <?xml version="1.0" encoding="utf-8"?><hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities><capability>urn:ietf:param s:netconf:base:1.1</capability><capability>urn:ietf:params:netconf:writable-running</cap ability><capability>urn:ietf:params:netconf:capability:notification:1.0</capability><cap ability>urn:ietf:params:netconf:capability:validate:1.1</capability><capability>urn:ietf :params:netconf:capability:interleave:1.0</capability><capability>urn:ietf:params:netcon f:capability:h3c-netconf-ext:1.0</capability></capabilities><session-id>1</session-id></ hello>]]>]]> 其中 : <capabilities> 和 </capabilities> 之间的内容表示设备支持的能力集 <session-id> 和 </session-id> 之间的内容表示为本次会话分配的会话 ID, 用来唯一标识本次会话 2. 客户端发送给设备的报文 客户端收到设备发送的能力集协商报文后, 需要给设备发送如下格式的报文, 告知设备客户端支持哪些 NETCONF 能力集 Hello 协商报文格式如下 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> 1-6

153 capability-set </capability> </capabilities> </hello> 其中,capability-set 表示客户端支持的能力集, 由用户定义 一个 <capability> 和 </capability> 选项对中填写一个能力集, 可以使用多个选项对, 发送多个能力集 1.6 向设备进行事件订阅 用户向设备订阅事件后, 设备上发生用户订阅的事件时, 设备会自动向订阅的客户端发送事件的相关信息, 信息内容包括事件的 code group severity 以及发生时间和描述信息 此处可订阅的事件, 即系统支持的日志信息 具体可以订阅哪些模块的事件, 请参见 日志信息参考手册 需要注意的是 : 订阅只对当前连接生效 如果连接断开, 订阅会自动取消 多次发送订阅报文, 可以订阅多个事件 订阅事件 1. 客户端发送报文事件订阅报文格式如下 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <stream>netconf</stream> <filter> <event xmlns=" <Code>code</Code> <Group>group</Group> <Severity>severity</Severity> </event> </filter> <starttime>start-time</starttime> <stoptime>stop-time</stoptime> </create-subscription> </rpc> 其中 : stream 表示支持的事件流, 目前只支持 NETCONF event 表示订阅的事件 code 表示日志信息中的助记符 group 表示日志信息中的模块名 severity 表示日志信息中的安全级别 start-time 表示订阅的开始时间 stop-time 表示结束订阅的时间 1-7

154 2. 结果验证设备收到订阅报文后会回应客户端, 当客户端收到如下报文时, 表示订阅成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns:netconf="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply > 当订阅出错时设备会返回错误信息, 例如 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>error-type</error-type> <error-tag>error-tag</error-tag> <error-severity>error-severity</error-severity> <error-message xml:lang="en">error-message</error-message> </rpc-error> </rpc-reply> 错误报文的详细定义请参见 RFC 订阅事件举例 1. 组网需求客户端订阅没有时间限制的全部事件 订阅后在断开连接之前, 设备发生的所有事件都会发送给客户端 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 订阅全部事件, 不限制订阅时间 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <create-subscription xmlns ="urn:ietf:params:xml:ns:netconf:notification:1.0"> <stream>netconf</stream> </create-subscription> </rpc> 1-8

155 3. 结果验证 # 如果客户端收到如下报文, 则表示订阅成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <ok/> </rpc-reply> 当设备上的风扇 1 有问题时, 设备会发送如下报文来通知订阅客户端 : <?xml version="1.0" encoding="utf-8"?> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventtime> t12:30:46</eventtime> <event xmlns=" <Group>DEV</Group> <Code>FAN_DIRECTION_NOT_PREFERRED</Code> <Slot>6</Slot> <Severity>Alert</Severity> <context>fan 1 airflow direction is not preferred on slot 6, please check it.</context> </event> </notification> 当用户 (IP 地址为 ) 登录设备时, 设备会发送如下报文来通知订阅客户端 : <?xml version="1.0" encoding="utf-8"?> <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> <eventtime> t12:30:52</eventtime> <event xmlns=" <Group>SHELL</Group> <Code>SHELL_LOGIN</Code> <Slot>6</Slot> <Severity>Notification</Severity> <context>vty logged in from </context> </event> </notification> 1.7 给当前配置加锁 / 解锁 因为设备同时最多能建立 5 个 NETCONF 连接, 即最多支持 5 个用户同时使用 NETCONF 功能管理和监控设备 所以, 当用户管理 维护设备或者定位网络问题时, 为防止其他 NETCONF 用户修改当前配置 引入干扰, 可以使用本特性给当前配置加锁 给当前配置加锁后, 只有持有锁的用户可以修改设备的当前配置, 其他 NETCONF 用户只能读取, 不能修改当前配置 只有持有锁的用户可以解锁, 解锁后其他用户才可以修改设备的当前配置或另外加锁 如果持有锁的用户的当前连接断开, 系统会自动解锁 给当前配置加锁 1. 客户端发送报文 目前设备只支持对当前配置加锁, 不能对具体的功能模块进行加锁 请将以下报文拷贝 粘贴到客户端, 用户即能完成加锁操作 : 1-9

156 <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc> 2. 结果验证设备收到加锁报文后会回应客户端, 当客户端收到如下报文时, 表示加锁成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 给当前配置解锁 只有锁的持有用户才能解锁, 其它用户不能解锁 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端, 用户即能完成解锁操作 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <unlock> <target> <running/> </target> </unlock> </rpc> 2. 结果验证设备收到解锁报文后会回应客户端, 当客户端收到如下报文时, 表示解锁成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 当前配置加锁举例 1. 组网需求给设备加锁, 以免其它用户使用 XML 语言修改设备的当前配置 1-10

157 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 对当前配置加锁 请将以下报文拷贝 粘贴到客户端 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc> 3. 结果验证 # 如果客户端收到如下报文, 则表示加锁成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 用户加锁成功后, 另一客户端发送加锁报文, 设备会返回如下报文 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error> <error-type>protocol</error-type> <error-tag>lock-denied</error-tag> <error-severity>error</error-severity> <error-message xml:lang="en">lock failed, lock is already held.</error-message> <error-info> <session-id>1</session-id> </error-info> </rpc-error> </rpc-reply> 以上报文表明 : 加锁失败,session-id 是 1 的用户已经持有锁 1-11

158 1.8 业务处理功能 NETCONF 支持用户对设备进行业务操作, 包括对指定信息的获取和修改 基本标签有 <get> <get-bulk> <get-config> <get-bulk-config> 和 <edit-config>, 分别用来获取所有数据 获取配置 数据和编辑指定模块的数据 详细规则参见 NETCONF XML API 手册 <get>/<get-bulk> 获取信息 <get> 操作用来获取数据, 包括运行状态数据和配置数据 <get-bulk> 操作用来从指定索引的下一条开始批量获取后续 N 条数据 ( 索引行数据不返回 ), 包括运行状态数据和配置数据 用户通过 index 属性由指定索引, 通过 count 属性指定 N 如未指定索引, 则以第一条为索引 ; 如未指定 N, 或者数据表中符合条件的数据记录不足 N 条, 则返回表中所有剩下的数据条目 <get> 操作会返回所有符合条件的数据, 在某些情况下, 会导致获取数据效率不高 <get-bulk> 允许用户从固定数据项开始, 向后获取指定条目的数据记录 1. 客户端发送报文 <get> 和 <get-bulk> 报文的通用格式如下 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <getoperation> <filter> <top xmlns=" 指定模块, 子模块, 表名, 列名 </top> </filter> </getoperation> </rpc> 其中,getoperation 可以为 get 或者 get-bulk <filter> 选项用于过滤信息,<filter> 中可包括模块名 子模块名 表名和列名 : 如果不指定模块 ( 子模块 ), 则表示全部模块 ( 子模块 ) 一旦指定模块( 子模块 ), 则返回数据只包含指定模块 ( 子模块 ) 如果模块下不指定表, 则表示全部表 一旦指定表, 则返回数据只包含指定表 如果只指定索引列, 则返回的数据包括全部的列 如果同时指定了索引列之外的其他列, 则意味着返回的数据仅仅包含索引列和指定的列 <get-bulk> 操作报文中还可以携带 count 和 index 参数, 如下为一个携带了 count 和 index 参数的 <get-bulk> 操作报文示例 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc=" <get-bulk> <filter type="subtree"> <top xmlns=" xmlns:base=" <Syslog> 1-12

159 <Logs xc:count="5"> <Log> <Index>10</Index> </Log> </Logs> </Syslog> </top> </filter> </get-bulk> </rpc> 其中,get-bulk 操作报文中的 count 属性遵循如下约定 : count 属性的位置在可以从 top 下的节点开始, 到表节点为止, 即 : 模块节点, 表节点这几个位置都能放置 count 属性, 其他位置的 count 将不被解释 如果 count 放在模块节点上, 则报文中指定的子孙节点 ( 表 ) 中没有 count 的都默认 count 属性的值和模块一致 如果不指定 count, 则获取出从指定索引开始的所有数据 2. 结果验证设备收到配置获取请求报文后会将相应参数的值通过如下报文反馈给客户端 : <?xml version="1.0"?> <rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <data> 全部配置数据和状态数据 </data> </rpc-reply> <get-config>/<get-bulk-config> 获取配置信息 <get-config> 和 <get-bulk-config> 用来获取系统中所有可配置的变量的值, 配置的方式包括 CLI MIB Web 等 <get-config> 和 <get-bulk-config> 操作报文中可以包含子标签 <filter>, 用来对要获取的信息进行过滤 1. 客户端发送报文 : <get-config> 和 <get-bulk-config> 的通用报文格式如下 : <?xml version="1.0"?> <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter> <top xmlns=" 指定模块, 子模块, 表名, 列名 </top> </filter> </get-config> 1-13

160 </rpc> 2. 结果验证 设备收到配置获取请求报文后会将相应配置通过如下报文反馈给客户端 : <?xml version="1.0"?> <rpc-reply message-id="100" <data> 所有指定 filter 内的数据 </data> </rpc-reply> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> 编辑指定模块数据 <edit-config> 支持如下选项 :merge create replace remove delete 默认操作选项 默认错误处理选项 测试处理, 关于这些选项的详细描述请参见 2.1 附录 A Comware V7 中支持的 NETCONF 操作类型 1. 客户端发送报文 <?xml version="1.0"?> <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target><running></running></target> <error-option> 失败时默认操作 </error-option> <config> <top xmlns=" 指定模块名, 子模块名, 列名, 表名 </top> </config> </edit-config> </rpc> 2. 结果验证 设备收到 edit-config 请求后会回应客户端, 当客户端收到如下报文时, 表示设置成功 : <?xml version="1.0"> <rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 另外, 用户还可以通过 <get> 操作可以查看参数的当前值是否和 edit-config 操作设置的值一致 举例 获取所有模块所有配置数据 1. 组网需求获取所有模块所有配置数据 1-14

161 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 获取所有模块所有配置数据 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> </get-config> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 : <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <data> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <IfIndex>1307</IfIndex> <Shutdown>1</Shutdown> </Interface> <Interface> <IfIndex>1308</IfIndex> <Shutdown>1</Shutdown> </Interface> <Interface> <IfIndex>1309</IfIndex> <Shutdown>1</Shutdown> </Interface> <Interface> <IfIndex>1311</IfIndex> <VlanType>2</VlanType> 1-15

162 </Interface> <Interface> <IfIndex>1313</IfIndex> <VlanType>2</VlanType> </Interface> </Interfaces> </Ifmgr> <Syslog> <LogBuffer> <BufferSize>120</BufferSize> </LogBuffer> </Syslog> <System> <Device> <SysName>H3C</SysName> <TimeZone> <Zone>+11:44</Zone> <ZoneName>beijing</ZoneName> </TimeZone> </Device> </System> <Fundamentals> <WebUI> <SessionAgingTime>98</SessionAgingTime> </WebUI> </Fundamentals> </top> </data> </rpc-reply> 举例 获取 Syslog 模块的所有配置数据 1. 组网需求获取 Syslog 模块的所有配置数据 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> 1-16

163 </capabilities> </hello> # 获取 Syslog 模块的所有配置数据 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns=" <Syslog/> </top> </filter> </get-config> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <data> <top xmlns=" <Syslog> <LogBuffer> <BufferSize>120</BufferSize> </LogBuffer> </Syslog> </top> </data> </rpc-reply> 举例 取接口表的一条数据 1. 组网需求取接口表的一条数据 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> </capabilities> 1-17

164 </hello> # 取接口表的一条数据 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-bulk> <filter type="subtree"> <top xmlns=" xmlns:web=" <Ifmgr> <Interfaces web:count="1"> </Interfaces> </Ifmgr> </top> </filter> </get-bulk> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 : <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <data> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <IfIndex>1302</IfIndex> <Name>GigabitEthernet6/0/2</Name> <AbbreviatedName>GE6/0/2</AbbreviatedName> <PortIndex>3</PortIndex> <iftypeext>22</iftypeext> <iftype>6</iftype> <Description>GigabitEthernet6/0/2 Interface</Description> <AdminStatus>2</AdminStatus> <OperStatus>2</OperStatus> <ConfigSpeed>0</ConfigSpeed> <ActualSpeed>100000</ActualSpeed> <ConfigDuplex>3</ConfigDuplex> <ActualDuplex>1</ActualDuplex> </Interface> </Interfaces> </Ifmgr> </top> </data> </rpc-reply> 1-18

165 1.8.7 举例 修改参数值 1. 组网需求 修改 syslog 模块中的日志缓冲区可存储的信息条数为 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability>urn:ietf:params:netconf:base:1.0</capability> </capabilities> </hello> # 把 Syslog 模块 LogBuffer 表中的 BufferSize 列, 改成 512 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:web="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <top xmlns=" web:operation="merge"> <Syslog> <LogBuffer> <BufferSize>512</BufferSize> </LogBuffer> </Syslog> </top> </config> </edit-config> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 1.9 设置空闲配置自动回滚 Comware V7 NETCONF 支持会话在空闲一段时间 或者某些情况导致无法继续会话时进行配置回滚 当前会话已经存在配置回滚点的情况下, 配置回滚在下面几个情况下发生 : 1-19

166 NETCONF 客户端主动下发配置回滚指令 NETCONF 客户端在指定的时间内无任何指令 NETCONF 客户端和设备的长连接断开 要使用此功能, 需要下面步骤 : (1) 对当前系统加锁 ( 推荐 ) (2) 下发 save-point/begin 功能进行配置回滚点标记 (3) 下发 NETCONF edit-config 操作 (4) 下发 save-point/commit 接受当前配置, 或者下发 save-point/rollback 进行配置回滚, 或者因 为操作空闲超过配置的回滚空闲超时时间而自动进行配置回滚 (5) 对当前系统解锁 ( 推荐 ) 配置回滚点设置 1. 客户端发送报文 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save-point> <begin> <confirm-timeout>100</confirm-timeout> </begin> </save-point> </rpc> 配置回滚的默认空闲时间 <confirm-timeout> 为可选, 单位为秒, 如果不指定, 缺省为 600 秒 当前会话已经存在配置回滚点时不能继续设置新的配置回滚点, 必须先撤销原来的或者等待超时回滚后 因为多个会话并行使用配置回滚功能可能在配置回滚时可能使系统状态不一致, 如果存在多个会话同时配置的情况, 建议下发前先用 lock 锁定系统 2. 验证结果 当客户端收到如下报文时, 表示成功 : <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok></ok> </rpc-reply> 主动下发配置回滚 1. 客户端发送报文 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save-point> <rollback> </rollback> </save-point> </rpc> 1-20

167 2. 验证结果当客户端收到如下报文时, 表示成功 : <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok></ok> </rpc-reply> 主动下发配置确认 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save-point> <commit> </commit> </save-point> </rpc> 2. 验证结果当客户端收到如下报文时, 表示成功 : <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok></ok> </rpc-reply> 1.10 配置保存 回滚 加载 使用 NETCONF 功能, 用户可以对设备配置进行保存 回滚和加载操作 配置保存 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端, 用户即可将设备的当前配置保存到指定名称的文件中, 同时该文件将自动作为下次启动配置文件 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save OverWrite="false"> <file> 指定文件的名称 </file> </save> </rpc> 其中, 指定文件的名称 必须以存储介质的名称开头, 后缀为.cfg 当报文中存在 <file> 列时, 必须输入指定文件的名称, 不能为空 ; 如果不存在该列, 则设备会自动将当前配置保存到缺省的主用下次启动配置文件中 1-21

168 OverWrite 标志的默认取值为 true 缺省情况下, 当指定的配置文件名与原有配置文件名相同时, 原文件将被覆盖, 当前配置保存成功 如果指定 OverWrite 的值为 false, 则当指定的配置文件名与原有配置文件名相同时, 当前配置保存失败, 同时返回错误提示信息 2. 结果验证设备收到配置保存请求后会回应客户端, 当客户端收到如下报文时, 表示保存成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> < ok/> </rpc-reply> 配置回滚 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端, 用户即可将设备的当前配置恢复到指定配置文件中的配置 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rollback> <file> 指定文件的名称 </file> </rollback> </rpc> 2. 结果验证设备收到配置回滚请求后会回应客户端, 当客户端收到如下报文时, 表示配置回滚成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 加载文件 <load> 操作执行后, 指定文件中的配置会被合并到设备的当前配置中 设备会将指定文件中的配置中的配置和当前配置进行比较 : 对于指定文件中有, 但当前配置中没有的配置, 直接运行 ; 对于指定文件中和当前配置中不一致的配置, 则用指定文件中的配置替换当前配置中的对应配置 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端, 用户即可将指定文件中的配置追加到当前配置中 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <load> <file> 指定文件的名称 </file> </load> </rpc> 其中, 指定文件的名称 必须以存储介质的名称开头, 后缀为.cfg 如果不指定文件名, 则缺省保存到主用下次启动配置文件中 1-22

169 2. 结果验证设备收到配置加载请求后会回应客户端, 当客户端收到如下报文时, 表示配置加载成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 配置保存举例 1. 组网需求将设备的当前配置保存到配置文件 my_config.cfg 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 将设备的当前配置保存到配置文件 my_config.cfg 请将以下报文拷贝 粘贴到客户端 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save> <file> my_config.cfg</file> </save> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 1-23

170 1.11 数据过滤功能 三种数据过滤方式 当用户执行 <get> <get-bulk> <get-config> 或者 <get-bulk-config> 操作时, 在 XML 语言中增加过 滤条件, 可以使用户只看到自己关心的数据 数据过滤包括严格匹配 正则表达式匹配过滤和条件匹配过滤三种 需要注意的是, 同时指定多种过滤条件, 则只能生效一个, 其优先级从高到底依次为 : 严格匹配 正则表达式匹配过滤和条件匹配过滤 1. 严格匹配 严格匹配包括两种匹配方式, 一种是元素值方式, 还有一种是属性名方式 用户在 XML 语言中直接指定对应的元素值, 设备将对这些值进行严格匹配 如果指定了多个元素的值, 则返回同时符合这几个条件的数据 只有完全匹配条件才返回成功 如下为一个 NETCONF 报文示例, 用于获取所有状态为 UP 的接口的配置信息 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <AdminStatus>2</AdminStatus> </Interface> </Interfaces> </Ifmgr> </top> </filter> </get> </rpc> 当用户在行的位置上放置的某个属性的名称和当前表的某个列的名称一致, 则这个属性的值将与用户下发配置中同名称的列的值进行严格匹配, 例如, 上面例子用属性名方式的等价 XML 请求为 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface data:adminstatus="2" /> </Interfaces> </Ifmgr> </top> </filter> </get> </rpc> 1-24

171 以上两个 NETCONF 报文示例说明通过不同的严格匹配方式都可以获取所有状态为 UP 的接口配置 信息 2. 正则表达式匹配 当过滤条件比较复杂时, 可以在指定元素上设置 regexp 属性为一个正则表达式, 以完成过滤的目 的 如下为一个 NETCONF 报文示例, 用于获取接口的描述信息, 并要求这些描述信息全部为大写字母, 不能有其它字符 <rpc message-id="1-0" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:h3c=" > <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <Description h3c:regexp="^[a-z]*$" /> </Interface> </Interfaces> </Ifmgr> </top> </filter> </get-config> </rpc> 3. 条件匹配 由于正则表达仅能够完成字符匹配, 对于数值逻辑的判断过滤实现起来比较麻烦, 此时, 可使用条件匹配过滤功能 条件匹配通过在元素中增加 match 属性完成, 属性的值 ( 即过滤条件 ) 可以为数字 字符串 表 1-6 条件匹配命令 操作命令说明 大于 match= more:value 值大于 value, 支持的数据类型为 : 日期 数字 字符串 小于 match= less:value 值小于 value, 支持的数据类型为 : 日期 数字 字符串 不小于 match= notless:value 值不小于 value, 支持的数据类型为 : 日期 数字 字符串 不大于 match= notmore:value 值不大于 value, 支持的数据类型为 : 日期 数字 字符串 等于 match= equal:value 值等于 value, 支持的数据类型为 : 日期 数字 字符串 OID BOOL 不等于 match= notequal:value 值不等于 value, 支持的数据类型为 : 日期 数字 字符串 OID BOOL 包含 match= include:string 包含字符串 string, 支持的数据类型为 : 字符串 1-25

172 操作 命令 说明 不包含 match= exclude:string 不能包含字符串 string, 支持的数据类型为 : 字符串 开始于 match= startwith:string 以字符串 string 开头, 支持的数据类型为 : 字符串 OID 结束于 match= endwith:string 以字符串 string 结束, 支持的数据类型为 : 字符串 如下为一个 NETCONF 报文示例, 用于获取实体扩展信息中 CPU 利用率大于 50% 的实体 <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:h3c=" > <get> <filter type="subtree"> <top xmlns=" <Device> <ExtPhysicalEntities> <Entity> <CpuUsage h3c:match="more:50"></cpuusage> </Entity> </ExtPhysicalEntities > </Device > </top> </filter> </get> </rpc> 正则表达式操作举例 1. 组网需求 取 Ifmgr 模块下 Interfaces 表下 Description 列包含冒号的所有数据 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 取 Ifmgr 模块 Interfaces 表下 Description 列包含冒号的所有数据 请将以下报文拷贝 粘贴到客户端 : <?xml version="1.0"?> <rpc message-id="100" 1-26

173 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg=" <get> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <Description reg:regexp=":" /> </Interface> </Interfaces> </Ifmgr> </top> </filter> </get> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:reg=" message-id="100"> <data> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <IfIndex>2681</IfIndex> <Description>Ten-GigabitEthernet6/0/49:1 Interface</Description> </Interface> <Interface> <IfIndex>2682</IfIndex> <Description>Ten-GigabitEthernet6/0/49:2 Interface</Description> </Interface> <Interface> <IfIndex>2683</IfIndex> <Description>Ten-GigabitEthernet6/0/49:3 Interface</Description> </Interface> <Interface> <IfIndex>2684</IfIndex> <Description>Ten-GigabitEthernet6/0/49:4 Interface</Description> </Interface> <Interface> <IfIndex>2685</IfIndex> <Description>Ten-GigabitEthernet6/0/50:1 Interface</Description> </Interface> <Interface> <IfIndex>2686</IfIndex> <Description>Ten-GigabitEthernet6/0/50:2 Interface</Description> 1-27

174 </Interface> <Interface> <IfIndex>2687</IfIndex> <Description>Ten-GigabitEthernet6/0/50:3 Interface</Description> </Interface> <Interface> <IfIndex>2688</IfIndex> <Description>Ten-GigabitEthernet6/0/50:4 Interface</Description> </Interface> <Interface> <IfIndex>2689</IfIndex> <Description>Ten-GigabitEthernet6/0/51:1 Interface</Description> </Interface> <Interface> <IfIndex>2690</IfIndex> <Description>Ten-GigabitEthernet6/0/51:2 Interface</Description> </Interface> <Interface> <IfIndex>2691</IfIndex> <Description>Ten-GigabitEthernet6/0/51:3 Interface</Description> </Interface> <Interface> <IfIndex>2692</IfIndex> <Description>Ten-GigabitEthernet6/0/51:4 Interface</Description> </Interface> </Interfaces> </Ifmgr> </top> </data> </rpc-reply> 条件匹配操作举例 1. 组网需求取 Ifmgr 模块 Interfaces 表下 ifindex 值大于等于 5000 的 Name 列信息 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> 1-28

175 # 取 Ifmgr 模块 Interfaces 表下 ifindex 值大于等于 5000 的 Name 列信息 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc=" <get> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <IfIndex nc:match="more:5000"/> <Name/> </Interface> </Interfaces> </Ifmgr> </top> </filter> </get> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:nc=" message-id="100"> <data> <top xmlns=" <Ifmgr> <Interfaces> <Interface> <IfIndex>7241</IfIndex> <Name>NULL0</Name> </Interface> <Interface> <IfIndex>7243</IfIndex> <Name>Register-Tunnel0</Name> </Interface> </Interfaces> </Ifmgr> </top> </data> </rpc-reply> 1.12 命令行操作 通过 NETCONF 功能, 用户可以将命令行封装在 XML 报文中对设备进行操作 1-29

176 命令行操作 1. 客户端发送报文当需要给设备发送命令时, 请使用格式如下的 NETCONF 报文 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Execution> 命令行 </Execution> </CLI> </rpc> 一对 <Execution> 子标签中可以包含多个命令行, 一条命令输入完毕, 换行, 再输入下一条命令即可 2. 结果验证设备收到命令行指令后会回应客户端, 当客户端收到如下报文时, 表示命令行执行成功 ( 注意命令响应被 CDATA 节点包含 ): <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Execution> <![CDATA[ 对应命令行响应 ]]> </Execution> </CLI> </rpc-reply> 命令行操作举例 1. 配置需求向设备发送显示当前配置命令 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 向设备发送显示当前配置命令 请将以下报文拷贝 粘贴到客户端 : 1-30

177 <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Execution> display current-configuration </Execution> </CLI> </rpc> 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Execution><![CDATA[ # version , Demo , # sysname ab # ftp server enable ftp update fast ftp timeout 2000 # irf mac-address persistent timer irf auto-update enable undo irf link-delay # domain default enable system # telnet server enable # vlan 1 # vlan 1000 # radius scheme system primary authentication ]]> </Execution> </CLI> </rpc-reply> 1.13 获取会话信息 使用该功能用户可以获取当前设备的所有 NETCONF 会话信息 1-31

178 获取会话信息 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-sessions/> </rpc> 2. 结果验证设备收到命令行指令后会回应客户端, 当客户端收到如下报文时, 表示命令行执行成功 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-sessions> <Session> <SessionID> 用户会话 ID 信息 </SessionID> <Line> line 信息 </Line> <UserName> 用户登陆名称 </UserName> <Since> 用户登录时间 </Since> <LockHeld> 用户是否持有锁 </LockHeld> </Session> </get-sessions> </rpc-reply> 获取会话信息举例 1. 配置需求获取会话信息 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 获取设备上当前存在的 NETCONF 会话的信息 请将以下报文拷贝 粘贴到客户端 : <?xml version="1.0" encoding="utf-8"?> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-sessions/> </rpc> 1-32

179 3. 结果验证 # 如果客户端收到类似如下的报文, 则表示操作成功 <?xml version="1.0" encoding="utf-8"?> <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101"> <get-sessions> <Session> <SessionID>1</SessionID> <Line>vty0</Line> <UserName></UserName> <Since> T00:24:57</Since> <LockHeld>false</LockHeld> </Session> </get-sessions> </rpc-reply> 以上信息表明 : 目前有一个 NETCONF 连接,SessionID 是 1, 登录用户类型 vty0, 登录时间是 T00:24:57, 此用户不持有锁 1.14 关闭另一个会话 NETCONF 支持一个用户关闭除自己外的另一个 NETCONF 会话, 被关闭会话的用户退回到用户视图 Kill-session 操作 1. 客户端发送报文请将以下报文拷贝 粘贴到客户端, 用户即能关闭指定的会话 : <rpc message-id="101" <kill-session> <session-id> 指定 session-id </session-id> </kill-session> </rpc> 2. 结果验证 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> 设备收到会话关闭请求后会回应客户端, 当客户端收到如下报文时, 表示指定会话已经被关闭 : <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 1-33

180 Kill-session 举例 1. 配置需求当前有两个 NETCONF 登录用户,session ID 分别是 1 和 2,session ID 为 1 的用户要关闭另一个用户的会话 2. 配置步骤 # 进入 XML 视图 <Sysname> xml # 进行能力交换 请将以下报文拷贝 粘贴到客户端 : <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> </capabilities> </hello> # 关闭 session ID 为 2 的用户会话 请将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>2</session-id> </kill-session> </rpc> 3. 结果验证如果客户端收到如下报文, 则表明 session ID 为 2 的 NETCONF 会话已经被关闭 建立该会话的用户会从 XML 视图退回到用户视图 <?xml version="1.0" encoding="utf-8"?> <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 1.15 退出 XML 视图 1. 客户端发送报文对于处于 XML 视图的用户, 要退回到用户视图, 使用命令行来配置设备时, 需要将以下报文拷贝 粘贴到客户端 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session/> </rpc> 2. 结果验证设备收到以上请求后会返回如下报文并退回到用户视图 : <?xml version="1.0" encoding="utf-8"?> 1-34

181 <rpc-reply message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <ok/> </rpc-reply> 1-35

182 2 附录 2.1 附录 A Comware V7 中支持的 NETCONF 操作类型 Comware V7 平台对 NETCONF 标准协议做了一些修订, 删除了不常用的操作, 增加部分新的操作, 如表 2-1 所示 表 2-1 NETCONF 协议支持的操作操作说明 XML 格式样例 get get-config 获取数据, 包括运行状态数据和配置数据 获取配置数据, 和 get 不同, 它只返回非缺省的配置数据 如果没有配置数据, 则返回一个空的 <data> 获取 Syslog 模块的全部数据的 XML 请求如下 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc=" <get> <filter type="subtree"> <top xmlns=" > <Syslog> </Syslog> </top> </filter> </get> </rpc> 获取接口表内所有配置的 XML 请求如下 : <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc=" <get-config> <source> <running/> </source> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces> <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-config> </rpc> 2-1

183 操作说明 XML 格式样例 get-bulk 从指定索引的下一条开始批量获取后续 N 条数据 ( 索引行数据不返回 ), 包括运行状态数据和配置数据 用户通过 index 属性指定索引, 通过 count 属性指定 N 如未指定索引, 则以第一条为索引 ; 如未指定 N, 或者数据表中符合条件的数据记录不足 N 条, 则返回表中所有剩下的数据条目 get 操作会返回所有符合条件的数据, 这在某些情况下会导致效率问题 get-bulk 允许用户从固定数据项开始, 向后获取指定条目的数据记录 取全部接口的数据的 xml 请求如下 : <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-bulk> <filter type="subtree"> <top xmlns=" <Ifmgr> <Interfaces xc:count= 5 xmlns:xc= > <Interface/> </Interfaces> </Ifmgr> </top> </filter> </get-bulk> </rpc> get-bulk-con fig 从指定索引的下一条批量获取配置数据 和 get-config 类似, 只返回非默认配置 ; 其它约束类似 get-bulk 获取全部接口配置信息的 xml 请求如下 : <rpc message-id ="100" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" > <get-bulk-config> <source> <running/> </source> <filter type="subtree"> <top xmlns=" <Ifmgr> </Ifmgr> </top> </filter> </get-bulk-config> </rpc> 2-2

184 操作说明 XML 格式样例 edit-config: merge edit-config: create edit-config: replace 在当前运行配置的基础上直接运行指定配置 merge 操作必须指定具体的操作对象 ( 行 ): 如果指定的对象存在, 则直接配置该对象 如果指定的对象不存在, 但允许创建, 则先创建再配置该对象 如果指定的对象不存在且不允许创建, 则返回 merge 失败 创建指定对象 create 操作必须指定配置对象 create 操作的 XML 数据格式和 merge 类似, 只是 operation 属性需要指定为 create 如果当前配置表支持创建对象, 且当前对象不存在, 则先创建配置对象, 再创建指定的配置 如果配置对象下对应的配置项已经存在, 则返回 data-exist 错误 如果指定的对象存在, 则替换指定对象的配置为当前配置 如果指定的对象不存在, 但允许创建, 则先创建再配置该对象为当前配置 如果指定对象不存在且不允许创建, 则不进行 replace 操作, 返回 invalid-value 错误, 提示用户配置对象不存在 将 BufferSize 设置为 120 的 xml 请求如下 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <config> <top xmlns=" <Syslog xmlns=" xc:operation="merge"> <LogBuffer> <BufferSize>120</BufferSize> </LogBuffer> </Syslog> </top> </config> </edit-config> </rpc> 同上, 把 merge 修改为 create 即可 同上, 把 merge 修改为 replace 即可 2-3

185 操作说明 XML 格式样例 删除指定配置 edit-config: remove edit-config: delete edit-config 默认操作选项 当指定的删除对象中只有表索引时, 则删除此配置指定对象的所有配置, 同时删除指定对象 当指定的删除对象中不仅仅有表索引还存在配置项时, 则删除此对象下面的指定配置 如果系统中指定对象不存在, 或者 XML 消息未指定对象, 则直接返回成功 删除指定配置 当指定的删除对象中只有表索引时, 则删除此配置指定对象的所有配置, 同时删除指定对象 当指定的删除对象中不仅仅有表索引还存在配置项时, 则删除此对象下面的指定配置 如果系统中指定对象不存在, 则直接返回不存在的错误消息 edit-config 操作用于修改当前系统配置 NETCONF 定制了四种修改配置的方式 :merge create delete 和 replace 当 XML 消息中未指定修改配置方式的时候, 则使用默认操作做为当前指令的操作方式, 不会修改默认操作的缺省值默认操作的缺省值是 merge, 在 XML 消息中可以通过 <default-operation> 节点来设置默认操作, 取值为 : merge: 当配置方式和默认操作方式均未指定时, 使用该方式 replace: 当配置方式未指定, 默认操作指定为 replace 的时候,edit-config 操作会默认为 replace 操作 none: 当配置方式未指定, 默认操作指定为 none 的时候, edit-config 操作会默认为 none 操作 none 操作主要用来检查, 下发为 none 操作的配置仅仅做 Schema 校验, 不进行真正的配置下发 语法检查通过, 就返回 ok 成功, 否则失败 同上, 把 merge 修改为 remove 即可 同上, 把 merge 修改为 delete 即可 下发一个空的操作, 该操作仅仅验证格式, 并不真正下发给系统,xml 请求如下 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <default-operation>none</default-operation> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns=" <Ifmgr > <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222222</Description> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc> 2-4

186 操作说明 XML 格式样例 edit-config 默认错误处理选项 edit-config 将指定的配置设置到系统上, 完成配置设置的操作 在执行 edit-config 的过程中, 如果遇到一个实例配置出错, 默认情况下会直接返回错误, 但是为了使我们的应用更加灵活,edit-config 为我们提供了错误选项, 通过错误选项取值的不同, 在发生错误的时候进行不同的处理操作 <error-option> 节点用于设置一个实例配置出错后, 后续实例配置的处理方式, 缺省值为 stop-on-error, 全部取值为 : stop-on-error: 停止处理, 返回错误 此选项为默认选项 continue-on-error: 继续处理, 但是报告错误 rollback-on-error: 停止并回滚配置 下发两个接口的配置, 当下发第一个接口的配置发生错误时, 继续进行下一个接口配置的下发,XML 请求如下 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <error-option>continue-on-error</error-option> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns=" <Ifmgr xc:operation="merge"> <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222</Description> <ConfigSpeed> </ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> <Interface> <IfIndex>263</IfIndex> <Description>333</Description> <ConfigSpeed> </ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc> 2-5

187 操作说明 XML 格式样例 edit-config 测试处理选项 action 在真正执行 edit-config 操作时, 可指定一个测试选项, 使用 <test-option> 节点来决定当前配置是否真正下发 该节点的缺省值为 test-then-set, 全部取值为 : test-then-set: 如果没有错误则将配置设置到系统 set: 将配置设置到系统 test-only: 只测试, 并不下发配置到系统 语法检查通过, 就返回 ok 成功, 否则失败 下发非配置数据的设置动作, 比如, reset 操作 下发一个接口的配置, 仅测试,XML 请求如下 : <rpc message-id ="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <edit-config> <target> <running/> </target> <test-option>test-only</test-option> <config xmlns:xc="urn:ietf:params:xml:ns:netconf:base:1.0"> <top xmlns=" <Ifmgr xc:operation="merge"> <Interfaces> <Interface> <IfIndex>262</IfIndex> <Description>222</Description> <ConfigSpeed> </ConfigSpeed> <ConfigDuplex>1</ConfigDuplex> </Interface> </Interfaces> </Ifmgr> </top> </config> </edit-config> </rpc> 清除全部接口的统计信息,XML 请求如下 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <action> <top xmlns=" <Ifmgr> <ClearAllIfStatistics> <Clear> </Clear> </ClearAllIfStatistics> </Ifmgr> </top> </action> </rpc> 2-6

188 操作说明 XML 格式样例 lock unlock get-session s close-sessio n kill-session 锁保护的是配置数据, 即 edit-config 中可以指定的那些模块的配置数据, 其它操作不受锁的限制 NETCONF 锁仅仅保护 NETCONF 会话, 不保护 SNMP 等其它请求下发的配置 取消锁保护当会话结束时锁也会被自动释放 获取当前系统中所有 NETCONF 会话的信息 ( 不能指定 sessions-id) 关闭当前 NETCONF 会话, 并释放锁和这个 session 用到的内部资源 ( 如内存等 ), 退出 XML 视图 关闭其他 NETCONF 会话, 不支持关闭用户自己的 NETCONF 会话 禁止 NETCONF 会话修改设备的当前配置,XML 请求如下 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <lock> <target> <running/> </target> </lock> </rpc> 取消锁保护, 允许 NETCONF 会话修改设备的当前配置 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <unlock> <target> <running/> </target> </unlock> </rpc> 获取当前系统中所有 NETCONF 会话的信息 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <get-sessions/> </rpc> 关闭当前 NETCONF 会话, 并释放锁和这个 session 用到的内部资源 ( 如内存等 ), 退出 XML 视图 <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <close-session /> </rpc> 关闭 session-id 为 1 的 NETCONF 会话 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <kill-session> <session-id>1</session-id> </kill-session> </rpc> 2-7

189 操作说明 XML 格式样例 CLI save 执行命令行的命令 请求消息将命令行语句封装在 <CLI> 标签中, 命令行输出信息被封装在 <CLI> 标签中返回 CLI 支持 Configuration 和 Exec 两种方式 : Execution: 在用户视图下执行 Configuration: 在系统视图下执行对于其它视图下命令, 则需要在 Configuration 下先指定进子视图的命令, 在指定配置命令 保存系统运行配置 save 操作可以使用子元素 <file> 来指定保存的配置文件名称 当 save 操作中不存在子元素 <file> 列时, 则设备会自动将当前运行配置保存到主用下次启动配置文件中 OverWrite 属性用来判断当指定的配置文件名存在时, 当前配置是否覆盖原配置文件并保存成功 在系统视图下执行 display this 命令 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <CLI> <Configuration>display this</configuration> </CLI> </rpc> 将设备当前配置保存到文件 test.cfg 中 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <save OverWrite= false > <file>test.cfg</file> </save> </rpc> load rollback 配置加载 <load> 操作执行后, 指定文件中的配置会被合并到设备的当前配置中 配置回滚 <rollback> 操作必须使用子元素 <file> 来指定需要回滚的配置文件名称 <rollback> 操作执行后, 当前系统运行配置会被完全替换为指定文件中所描述的配置 将文件 a1.cfg 中的配置合并到设备的当前配置中 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <load> <file>a1.cfg</file> </load> </rpc> 将设备当前配置回退到文件 1A.cfg 中配置的状态 : <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rollback> <file>1a.cfg</file> </rollback> </rpc> 2-8

190 目录 1 端口镜像 端口镜像简介 基本概念 端口镜像的分类和实现方式 配置本地端口镜像 配置任务简介 创建本地镜像组 配置源端口 配置源 VLAN 配置目的端口 配置二层远程端口镜像 配置任务简介 配置远程目的镜像组 配置远程源镜像组 端口镜像显示和维护 端口镜像典型配置举例 本地端口镜像配置举例 ( 源端口方式 ) 本地端口镜像配置举例 ( 源 VLAN 方式 ) 二层远程端口镜像配置举例 ( 非固定反射端口方式 ) 流镜像 流镜像简介 流镜像配置任务简介 配置流镜像 配置报文匹配规则 配置流行为 配置 QoS 策略 应用 QoS 策略 流镜像典型配置举例 2-21 i

191 1 端口镜像 1.1 端口镜像简介 端口镜像通过将指定端口 VLAN 的报文复制到与数据监测设备相连的端口, 使用户可以利用数据监测设备分析这些复制过来的报文, 以进行网络监控和故障排除 基本概念 1. 镜像源镜像源是指被监控的对象, 该对象可以是端口 VLAN, 我们将之依次称为源端口和源 VLAN 经由被监控的对象收发的报文会被复制一份到与数据监测设备相连的端口, 用户就可以对这些报文 ( 称为镜像报文 ) 进行监控和分析了 镜像源所在的设备就称为源设备 2. 镜像目的镜像目的是指镜像报文所要到达的目的地, 即与数据监测设备相连的那个端口, 我们称之为目的端口, 目的端口所在的设备就称为目的设备 目的端口会将镜像报文转发给与之相连的数据监测设备 由于一个目的端口可以同时监控多个镜像源, 因此在某些组网环境下, 目的端口可能收到对同一报文的多份拷贝 例如, 目的端口 Port 1 同时监控同一台设备上的源端口 Port 2 和 Port 3 收发的报文, 如果某报文从 Port 2 进入该设备后又从 Port 3 发送出去, 那么该报文将被复制两次给 Port 1 3. 镜像方向镜像方向是指在镜像源上可复制哪些方向的报文 : 入方向 : 是指仅复制镜像源收到的报文 出方向 : 是指仅复制镜像源发出的报文 双向 : 是指对镜像源收到和发出的报文都进行复制 4. 镜像组镜像组是一个逻辑上的概念, 镜像源和镜像目的都要属于某一个镜像组 根据具体的实现方式不同, 镜像组可分为本地镜像组 远程源镜像组和远程目的镜像组三类, 有关这三类镜像组的具体介绍, 请参见 端口镜像的分类和实现方式 5. 反射端口和远程镜像 VLAN 反射端口和远程镜像 VLAN 都是在二层远程端口镜像的实现过程中用到的概念 远程镜像 VLAN 是将镜像报文从源设备传送至目的设备的专用 VLAN; 反射端口位于源设备上, 用来将镜像报文发送到远程镜像 VLAN 中 有关反射端口 远程镜像 VLAN 和二层远程端口镜像的具体介绍, 请参见 端口镜像的分类和实现方式 在实现端口镜像的设备上, 将除源端口 目的端口和反射端口外的其他端口统称为普通端口 1-1

192 1.1.2 端口镜像的分类和实现方式根据镜像源与镜像目的是否位于同一台设备上, 可以将端口镜像分为本地端口镜像和远程端口镜像两大类 1. 本地端口镜像当源设备与数据监测设备直接相连时, 源设备可以同时作为目的设备, 即由本设备将镜像报文转发至数据检测设备, 这种方式实现的端口镜像称为本地端口镜像 对于本地端口镜像, 镜像源和镜像目的属于同一台设备上的同一个镜像组, 该镜像组称为本地镜像组 图 1-1 本地端口镜像示意图 如图 1-1 所示, 现在需要设备将进入端口 GigabitEthernet3/0/1 的报文复制一份, 从端口 GigabitEthernet3/0/2 将报文转发给数据监测设备 为满足该需求, 可以配置本地镜像组, 其中源端口为 GigabitEthernet3/0/1, 镜像方向为入方向, 目的端口为 GigabitEthernet3/0/2 2. 远程端口镜像当源设备与数据监测设备不直接相连时, 与数据监测设备直接相连的设备作为目的设备, 源设备需要将镜像报文复制一份至目的设备, 然后由目的设备将镜像报文转发至数据监测设备, 这种方式实现的端口镜像称为远程端口镜像 对于远程端口镜像, 镜像源和镜像目的分属于不同设备上的不同镜像组 : 镜像源所在的镜像组称为远程源镜像组, 镜像目的所在的镜像组称为远程目的镜像组, 而位于源设备与目的设备之间的设备则统称为中间设备 根据源设备与目的设备之间的连接关系, 又可将远程端口镜像细分为 : 二层远程端口镜像 : 源设备与目的设备之间通过二层网络进行连接 三层远程端口镜像 : 源设备与目的设备之间通过三层网络进行连接 目前暂不支持三层远程端口镜像 二层远程端口镜像的实现方式包括 : 反射端口方式和出端口方式 目前设备不支持出端口方式 反射端口方式 : 源设备将进入源端口的报文复制一份给反射端口, 再由该端口将镜像报文在远程镜像 VLAN 中广播, 最终镜像报文经由中间设备转发至目的设备 目的设备收到该报文后判别其 VLAN ID, 若与远程镜像 VLAN 的 VLAN ID 相同, 就将镜像报文通过目的端口转发给数据监测设备 过程如下图所示 1-2

193 图 1-2 二层远程端口镜像 ( 反射端口方式 ) 示意图 反射端口方式又可分为固定和非固定两种, 区别在于 : 支持前者的设备内部有一个固定的反射端口, 因此无需人工配置反射端口 ; 而支持后者的设备则需人工配置反射端口 目前设备不支持固定反射端口方式 对于反射口方式, 由于镜像报文将被源设备在远程镜像 VLAN 中广播, 因此通过将源设备上的非源端口加入远程镜像 VLAN, 也可实现本地端口镜像的功能 为确保源设备与目的设备之间的镜像报文可以二层转发, 中间设备连接到源设备和目的设备方向的端口上需允许远程镜像 VLAN 通过 1.2 配置本地端口镜像 配置任务简介在完成源端口 ( 或源 VLAN) 和目的端口的配置之后, 本地镜像组才能生效 表 1-1 本地端口镜像配置任务简介 配置任务 说明 详细配置 创建本地镜像组 必选 配置源端口 二者至少选其一 配置源 VLAN 源端口和源 VLAN 可以只配其一, 也可以都配置

194 配置任务说明详细配置 配置目的端口必选 创建本地镜像组表 1-2 创建本地镜像组 操作命令说明进入系统视图 system-view - 创建本地镜像组 mirroring-group group-id local [ sampler sampler-name ] 缺省情况下, 不存在任何本地镜像组 配置源端口 可以在系统视图下为指定镜像组配置一个或多个源端口, 也可以在接口视图下将当前接口配置为指定镜像组的源端口, 二者的配置效果相同 配置源端口时, 需要注意 : 请不要将源端口加入到源 VLAN 中, 否则会影响镜像功能的正常使用 一个镜像组内可以配置多个源端口 通常, 一个端口只能被一个镜像组使用 如果源端口上配置了 outbound 关键字, 则不能在该端口上配置 Flow 采样功能 1. 在系统视图下配置源端口表 1-3 在系统视图下配置源端口操作命令说明进入系统视图 system-view - 为本地镜像组配置源端口 mirroring-group group-id mirroring-port interface-list { both inbound outbound } 缺省情况下, 本地镜像组没有源端口 2. 在接口视图下配置源端口表 1-4 在接口视图下配置源端口操作 命令 说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number - 配置本端口为本地镜像组的源端口 mirroring-group group-id mirroring-port { both inbound outbound } 缺省情况下, 端口不是任何本地镜像组的源端口 1-4

195 1.2.4 配置源 VLAN 配置源 VLAN 时, 需要注意 : 一个镜像组内可以配置多个源 VLAN 一个 VLAN 只能配置为一个镜像组的源 VLAN 表 1-5 配置源 VLAN 操作命令说明进入系统视图 system-view - 为本地镜像组配置源 VLAN mirroring-group group-id mirroring-vlan vlan-list { both inbound outbound } 缺省情况下, 本地镜像组没有源 VLAN 配置目的端口 可以在系统视图下为指定镜像组配置目的端口, 也可以在接口视图下将当前接口配置为指定镜像组的目的端口, 二者的配置效果相同 配置目的端口时, 需要注意 : 请不要将目的端口加入到源 VLAN 中, 或在目的端口上使能生成树协议, 否则会影响镜像功能的正常使用 当二层聚合接口作为目的端口时, 请勿将其成员端口配置为源端口或将其加入源 VLAN, 否则会影响镜像功能的正常使用 从目的端口发出的报文包括镜像报文和其他端口正常转发来的报文 为了保证数据监测设备只对镜像报文进行分析, 请将目的端口只用于端口镜像, 不作其他用途 一个镜像组内只能配置一个目的端口 配置同方向的镜像支持的目的端口的数量, 请参见表 1-6 表 1-6 以太网接口板上同方向的镜像支持目的端口的数量单板类型支持的目的端口个数详细说明 48 端口千兆以太网接口板 2 前 24 个接口支持 1 个, 后 24 个接口支持 1 个 4 端口万兆以太网接口板 2 每 2 个接口支持 1 个 8 端口万兆以太网接口板 4 每 2 个接口支持 1 个 16 端口万兆以太网接口板 8 每 2 个奇数位接口支持 1 个, 每 2 个偶数位接口支持 1 个 20 端口万兆以太网接口板 1 支持 1 个 32 端口万兆以太网接口板 4 接口 支持 1 个 ; 接口 支持 1 个 ; 接口 支持 1 个 ; 接口 支持 1 个 1-5

196 单板类型支持的目的端口个数详细说明 40 端口万兆以太网接口板 2 前 20 个接口支持 1 个, 后 20 个接口支持 1 个 48 端口万兆以太网接口板 4 接口 1~12 支持 1 个 ; 接口 13~24 支持 1 个 ; 接口 25~36 支持 1 个 ; 接口 37~48 支持 1 个 4 端口 100G 以太网接口板 2 前 2 个接口支持 1 个, 后 2 个接口支持 1 个 2. 在系统视图下配置目的端口表 1-7 在系统视图下配置目的端口操作 命令 说明 进入系统视图 system-view - 为本地镜像组配置目的端口 mirroring-group group-id monitor-port interface-type interface-number 缺省情况下, 本地镜像组没有目的端口 3. 在接口视图下配置目的端口表 1-8 在接口视图下配置目的端口操作 命令 说明 进入系统视图 system-view - 进入接口视图 配置本端口为本地镜像组的目的端口 interface interface-type interface-number mirroring-group group-id monitor-port - 缺省情况下, 端口不是任何本地镜像组的目的端口 1.3 配置二层远程端口镜像 配置任务简介二层远程端口镜像的配置需要分别在源设备和目的设备上进行 ; 如果存在中间设备, 则需要在中间设备上允许远程镜像 VLAN 通过, 以确保源设备与目的设备之间的二层网络畅通 二层远程端口镜像的配置方式包括 : 固定反射端口方式 非固定反射端口方式 目前设备不支持以固定反射端口方式实现的二层远程端口镜像 配置二层远程端口镜像时, 需要注意 : 1-6

197 在镜像报文从源设备到达目的设备的过程中, 请确保其 VLAN ID 不被修改或删除, 否则二层远程镜像功能将失效 在配置二层远程端口镜像时不建议启用 MVRP(Multiple VLAN Registration Protocol, 多 VLAN 注册协议 ) 功能, 否则 MVRP 可能将远程镜像 VLAN 注册到不需要监控的端口上, 导致目的端口收到很多不必要的报文 有关 MVRP 的详细介绍, 请参见 二层技术 - 以太网交换配置指导 中的 MVRP 建议用户先配目的设备, 再配中间设备, 最后配源设备, 以保证镜像流量的正常转发 在一个镜像组中对同一个端口收发的报文进行双向镜像时, 需要在源设备 中间设备和目的设备上关闭远程镜像 VLAN 的 MAC 地址学习功能, 以保证镜像功能的正常进行 关于 MAC 地址学习功能的详细介绍, 请参见 二层技术 - 以太网交换配置指导 中的 MAC 地址表 1. 非固定反射端口方式首先在目的设备上为远程目的镜像组配置远程镜像 VLAN 和目的端口, 然后在源设备上为远程源镜像组配置源端口 ( 或源 VLAN) 反射端口和远程镜像 VLAN 表 1-9 二层远程端口镜像配置任务简介 ( 非固定反射端口方式 ) 配置任务说明详细配置创建远程目的镜像组必选 配置远程目的镜像组 配置目的端口必选 配置远程镜像 VLAN 必选 将目的端口加入远程镜像 VLAN 必选 创建远程源镜像组必选 配置远程源镜像组 配置源端口 根据需要选择配置其中一 配置源 VLAN 个或多个 配置反射端口必选 配置远程镜像 VLAN 必选 配置远程目的镜像组请在目的设备上进行如下配置 1. 创建远程目的镜像组表 1-10 创建远程目的镜像组 操作命令说明进入系统视图 system-view - 创建远程目的镜像组 mirroring-group group-id remote-destination 缺省情况下, 不存在任何远程目的镜像组 1-7

198 2. 配置目的端口可以在系统视图下为指定镜像组配置目的端口, 也可以在接口视图下将当前接口配置为指定镜像组的目的端口, 二者的配置效果相同 配置目的端口时, 需要注意 : 请不要将目的端口加入到源 VLAN 中, 或在目的端口上使能生成树协议, 否则会影响镜像功能的正常使用 当二层聚合接口作为目的端口时, 请勿将其成员端口配置为源端口或将其加入源 VLAN, 否则会影响镜像功能的正常使用 从目的端口发出的报文包括镜像报文和其他端口正常转发来的报文 为了保证数据监测设备只对镜像报文进行分析, 请将目的端口只用于端口镜像, 不作其他用途 一个镜像组内只能配置一个目的端口 同一个目的端口不能配置在两个镜像组内 (1) 在系统视图下配置目的端口表 1-11 在系统视图下配置目的端口操作命令说明进入系统视图 system-view - 为远程目的镜像组配置目的端口 mirroring-group group-id monitor-port interface-type interface-number 缺省情况下, 远程目的镜像组没有目的端口 (2) 在接口视图下配置目的端口 表 1-12 在接口视图下配置目的端口操作 命令 说明 进入系统视图 system-view - 进入接口视图 配置本端口为远程目的镜像组的目的端口 interface interface-type interface-number mirroring-group group-id monitor-port - 缺省情况下, 端口不是任何远程目的镜像组的目的端口 3. 配置远程镜像 VLAN 在配置远程镜像 VLAN 之前, 需配置远程镜像 VLAN 所使用的静态 VLAN 配置远程镜像 VLAN 时, 需要注意 : 当一个 VLAN 已被指定为远程镜像 VLAN 后, 请不要将该 VLAN 再作其他用途 源设备和目的设备上的远程镜像组必须使用相同的远程镜像 VLAN 表 1-13 配置远程镜像 VLAN 操作命令说明进入系统视图 system-view - 为远程目的镜像组配置远程镜像 VLAN mirroring-group group-id remote-probe vlan vlan-id 缺省情况下, 远程目的镜像组没有远程镜像 VLAN 1-8

199 4. 将目的端口加入远程镜像 VLAN 表 1-14 将目的端口加入远程镜像 VLAN 操作 命令 说明 进入系统视图 system-view - 进入目的接口视图 interface interface-type interface-number - 目的端口为 Access 端口 port access vlan vlan-id 将目的端口加入远程镜像 VLAN 目的端口为 Trunk 端口 port trunk permit vlan vlan-id 三者选其一 目的端口为 Hybrid 端口 port hybrid vlan vlan-id { tagged untagged } 有关 port access vlan port trunk permit vlan 和 port hybrid vlan 命令的详细介绍, 请参见 二层技术 - 以太网交换命令参考 中的 VLAN 配置远程源镜像组请在源设备上进行如下配置 1. 创建远程源镜像组表 1-15 创建远程源镜像组 操作命令说明进入系统视图 system-view - 创建远程源镜像组 mirroring-group group-id remote-source [ sampler sampler-name ] 缺省情况下, 不存在任何远程源镜像组 2. 配置源端口 可以在系统视图下为指定镜像组配置一个或多个源端口, 也可以在接口视图下将当前接口配置为指定镜像组的源端口, 二者的配置效果相同 配置源端口时, 需要注意 : 请不要将源端口加入到源 VLAN 和远程镜像 VLAN 中, 否则会影响镜像功能的正常使用 一个镜像组内可以配置多个源端口 通常, 一个端口只能被一个镜像组使用 如果源端口上配置了 outbound 关键字, 则不能在该端口上配置 Flow 采样功能 (1) 在系统视图下配置源端口 1-9

200 表 1-16 在系统视图下配置源端口 操作命令说明 进入系统视图 system-view - 为远程源镜像组配置源端口 mirroring-group group-id mirroring-port interface-list { both inbound outbound } 缺省情况下, 远程源镜像组没有源端口 (2) 在接口视图下配置源端口 表 1-17 在接口视图下配置源端口操作 命令 说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number - 配置本端口为远程源镜像组的源端口 mirroring-group group-id mirroring-port { both inbound outbound } 缺省情况下, 端口不是任何远程源镜像组的源端口 3. 配置源 VLAN 配置源 VLAN 时, 需要注意 : 一个镜像组内可以配置多个源 VLAN 一个 VLAN 只能配置为一个镜像组的源 VLAN 表 1-18 配置源 VLAN 操作命令说明进入系统视图 system-view - 为远程源镜像组配置源 VLAN mirroring-group group-id mirroring-vlan vlan-list { both inbound outbound } 缺省情况下, 远程源镜像组没有源 VLAN 4. 配置反射端口 可以在系统视图下为指定镜像组配置反射端口, 也可以在接口视图下将当前接口配置为指定镜像组的反射端口, 二者的配置效果相同 配置反射端口时, 需要注意 : 请不要将反射端口加入到源 VLAN 中, 否则会影响镜像功能的正常使用 建议选择设备上未被使用的端口作为反射端口, 并不要在该端口上连接网线, 否则会影响镜像功能的正常使用 在将端口配置为反射端口时, 该端口上已存在的所有配置都将被清除 ; 在配置为反射端口后, 该端口上不能再配置其他业务 一个镜像组内只能配置一个反射端口 1-10

201 只有当端口的双工模式 端口速率和 MDI 属性值均为缺省值时, 才能将其配置为反射端口 当端口已配置为反射端口后, 不能再修改其双工模式 端口速率和 MDI 属性值, 即这些属性 只能取缺省值 (1) 在系统视图下配置反射端口 表 1-19 在系统视图下配置反射端口操作 命令 说明 进入系统视图 system-view - 为远程源镜像组配置反射端口 mirroring-group group-id reflector-port interface-type interface-number 缺省情况下, 远程源镜像组没有反射端口 (2) 在接口视图下配置反射端口 表 1-20 在接口视图下配置反射端口操作 命令 说明 进入系统视图 system-view - 进入接口视图 配置本端口为远程源镜像组的反射端口 interface interface-type interface-number mirroring-group group-id reflector-port - 缺省情况下, 端口不是任何远程源镜像组的反射端口 5. 配置远程镜像 VLAN 在配置远程镜像 VLAN 之前, 需配置远程镜像 VLAN 所使用的静态 VLAN 配置远程镜像 VLAN 时, 需要注意 : 当一个 VLAN 已被指定为远程镜像 VLAN 后, 请不要将该 VLAN 再作其他用途 源设备和目的设备上的远程镜像组必须使用相同的远程镜像 VLAN 表 1-21 配置远程镜像 VLAN 操作命令说明进入系统视图 system-view - 为远程源镜像组配置远程镜像 VLAN mirroring-group group-id remote-probe vlan vlan-id 缺省情况下, 远程源镜像组没有远程镜像 VLAN 1.4 端口镜像显示和维护 在完成上述配置后, 在任意视图下执行 display 命令可以显示配置后镜像组的运行情况, 通过查看显示信息验证配置的效果 1-11

202 表 1-22 端口镜像显示和维护 操作 显示镜像组的配置信息 命令 display mirroring-group { group-id all local remote-destination remote-source } 1.5 端口镜像典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 DOWN 状态 如果要使这些接口能够正常 工作, 请先使用 undo shutdown 命令使接口状态处于 UP 本地端口镜像配置举例 ( 源端口方式 ) 1. 组网需求 Device 通过端口 GigabitEthernet3/0/1 和 GigabitEthernet3/0/2 分别连接市场部和技术部, 并通过端口 GigabitEthernet3/0/3 连接 Server 通过配置源端口方式的本地端口镜像, 使 Server 可以监控所有进 出市场部和技术部的报文 2. 组网图图 1-3 本地端口镜像配置组网图 市场部 GE3/0/1 Device GE3/0/3 技术部 GE3/0/2 Server 源端口 目的端口 3. 配置步骤 # 创建本地镜像组 1 <Device> system-view [Device] mirroring-group 1 local 1-12

203 # 配置本地镜像组 1 的源端口为 GigabitEthernet3/0/1 和 GigabitEthernet3/0/2, 目的端口为 GigabitEthernet3/0/3 [Device] mirroring-group 1 mirroring-port GigabitEthernet 3/0/1 GigabitEthernet 3/0/2 both [Device] mirroring-group 1 monitor-port GigabitEthernet 3/0/3 # 在目的端口 GigabitEthernet3/0/3 上关闭生成树协议 [Device] interface GigabitEthernet 3/0/3 [Device-GigabitEthernet3/0/3] undo stp enable [Device-GigabitEthernet3/0/3] quit 4. 验证配置 # 显示所有镜像组的配置信息 [Device] display mirroring-group all Mirroring group 1: Type: Local Status: Active Mirroring port: GigabitEthernet3/0/1 Both GigabitEthernet3/0/2 Both Monitor port: GigabitEthernet3/0/3 配置完成后, 用户可以通过 Server 监控所有进 出市场部和技术部的报文 本地端口镜像配置举例 ( 源 VLAN 方式 ) 1. 组网需求 Device 通过端口 GigabitEthernet3/0/1 和 GigabitEthernet3/0/2 分别连接市场部和技术部, 且 GigabitEthernet3/0/1 和 GigabitEthernet3/0/2 都属于 VLAN 2, 并通过端口 GigabitEthernet3/0/3 连接 Server 通过配置源 VLAN 方式的本地端口镜像, 使 Server 可以监控所有进 出市场部和技术部的报文 2. 组网图图 1-4 本地端口镜像配置组网图 1-13

204 3. 配置步骤 # 创建本地镜像组 1 <Device> system-view [Device] mirroring-group 1 local # 创建 VLAN 2, 并将端口 GigabitEthernet3/0/1 和 GigabitEthernet3/0/2 加入 VLAN 2 [Device] vlan 2 [Device-vlan2] port GigabitEthernet 3/0/1 GigabitEthernet 3/0/2 [Device-vlan2] quit # 配置本地镜像组 1 的源 VLAN 为 VLAN 2, 目的端口为 GigabitEthernet3/0/3 [Device] mirroring-group 1 mirroring-vlan 2 both [Device] mirroring-group 1 monitor-port GigabitEthernet 3/0/3 # 在目的端口 GigabitEthernet3/0/3 上关闭生成树协议 [Device] interface GigabitEthernet 3/0/3 [Device-GigabitEthernet3/0/3] undo stp enable [Device-GigabitEthernet3/0/3] quit 4. 验证配置 # 显示所有镜像组的配置信息 [Device] display mirroring-group all Mirroring group 1: Type: Local Status: Active Mirroring VLAN: 2 Both Monitor port: GigabitEthernet3/0/3 配置完成后, 用户可以通过 Server 监控所有进 出市场部和技术部的报文 二层远程端口镜像配置举例 ( 非固定反射端口方式 ) 1. 组网需求 在一个二层网络中,Device A Device B Device C 及 Server 如下图所示连接 其中, Device A 通过端口 GigabitEthernet3/0/1 连接市场部 通过配置二层远程端口镜像, 使 Server 可以监控所有进 出市场部的报文 1-14

205 2. 组网图 图 1-5 二层远程端口镜像配置组网图 3. 配置步骤 (1) 配置 Device C # 配置端口 GigabitEthernet3/0/1 为 Trunk 口, 并允许 VLAN 2 的报文通过 <DeviceC> system-view [DeviceC] interface GigabitEthernet 3/0/1 [DeviceC-GigabitEthernet3/0/1] port link-type trunk [DeviceC-GigabitEthernet3/0/1] port trunk permit vlan 2 [DeviceC-GigabitEthernet3/0/1] quit # 创建远程目的镜像组 2 [DeviceC] mirroring-group 2 remote-destination # 创建 VLAN 2 作为远程镜像 VLAN [DeviceC] vlan 2 # 关闭 VLAN 2 的 MAC 地址学习功能 [DeviceC-vlan2] undo mac-address mac-learning enable [DeviceC-vlan2] quit # 配置远程目的镜像组 2 的远程镜像 VLAN 为 VLAN 2, 目的端口为 GigabitEthernet3/0/2, 在该端口上关闭生成树协议并将其加入 VLAN 2 [DeviceC] mirroring-group 2 remote-probe vlan 2 [DeviceC] interface GigabitEthernet 3/0/2 [DeviceC-GigabitEthernet3/0/2] mirroring-group 2 monitor-port [DeviceC-GigabitEthernet3/0/2] undo stp enable [DeviceC-GigabitEthernet3/0/2] port access vlan 2 [DeviceC-GigabitEthernet3/0/2] quit (2) 配置 Device B # 创建 VLAN 2 作为远程镜像 VLAN <DeviceB> system-view [DeviceB] vlan 2 # 关闭 VLAN 2 的 MAC 地址学习功能 [DeviceB-vlan2] undo mac-address mac-learning enable 1-15

206 [DeviceB-vlan2] quit # 配置端口 GigabitEthernet3/0/1 为 Trunk 口, 并允许 VLAN 2 的报文通过 [DeviceB] interface GigabitEthernet 3/0/1 [DeviceB-GigabitEthernet3/0/1] port link-type trunk [DeviceB-GigabitEthernet3/0/1] port trunk permit vlan 2 [DeviceB-GigabitEthernet3/0/1] quit # 配置端口 GigabitEthernet3/0/2 为 Trunk 口, 并允许 VLAN 2 的报文通过 [DeviceB] interface GigabitEthernet 3/0/2 [DeviceB-GigabitEthernet3/0/2] port link-type trunk [DeviceB-GigabitEthernet3/0/2] port trunk permit vlan 2 [DeviceB-GigabitEthernet3/0/2] quit (3) 配置 Device A # 创建远程源镜像组 1 <DeviceA> system-view [DeviceA] mirroring-group 1 remote-source # 创建 VLAN 2 作为远程镜像 VLAN [DeviceA] vlan 2 # 关闭 VLAN 2 的 MAC 地址学习功能 [DeviceA-vlan2] undo mac-address mac-learning enable [DeviceA-vlan2] quit # 配置远程源镜像组 1 的远程镜像 VLAN 为 VLAN 2, 源端口为 GigabitEthernet3/0/1, 反射端口为 GigabitEthernet3/0/3 [DeviceA] mirroring-group 1 remote-probe vlan 2 [DeviceA] mirroring-group 1 mirroring-port GigabitEthernet 3/0/1 both [DeviceA] mirroring-group 1 reflector-port GigabitEthernet 3/0/3 This operation may delete all settings made on the interface. Continue? [Y/N]: y # 配置端口 GigabitEthernet3/0/2 为 Trunk 口, 并允许 VLAN 2 的报文通过 [DeviceA] interface GigabitEthernet 3/0/2 [DeviceA-GigabitEthernet3/0/2] port link-type trunk [DeviceA-GigabitEthernet3/0/2] port trunk permit vlan 2 [DeviceA-GigabitEthernet3/0/2] quit 4. 验证配置 # 显示 Device C 上所有镜像组的配置信息 [DeviceC] display mirroring-group all Mirroring group 2: Type: Remote destination Status: Active Monitor port: GigabitEthernet3/0/2 Remote probe VLAN: 2 # 显示 Device A 上所有镜像组的配置信息 [DeviceA] display mirroring-group all Mirroring group 1: Type: Remote source Status: Active Mirroring port: 1-16

207 GigabitEthernet3/0/1 Both Reflector port: GigabitEthernet3/0/3 Remote probe VLAN: 2 配置完成后, 用户可以通过 Server 监控所有进 出市场部的报文 1-17

208 2 流镜像 2.1 流镜像简介 流镜像是指将指定报文复制到指定目的地, 以便于对报文进行分析和监控 流镜像通过 QoS 策略来实现, 即使用流分类技术为待镜像报文定义匹配条件, 再通过配置流行为将符合条件的报文镜像至指定目的地 其优势在于用户通过流分类技术可以灵活地配置匹配条件, 从而对报文进行精细区分, 并将区分后的报文复制到目的地进行分析 有关 QoS 策略 流分类和流行为的详细介绍, 请参见 ACL 和 QoS 配置指导 中的 QoS 配置方式 根据报文镜像的目的地不同, 流行为可分为以下三种类型 : 流镜像到接口 : 将符合条件的报文复制一份到指定接口 ( 与数据检测设备相连的接口 ), 利用数据检测设备分析接口收到的报文 流镜像到 VLAN: 将符合条件的报文复制一份到指定 VLAN 中广播 流镜像到 CPU: 将符合条件的报文复制一份到 CPU( 这里的 CPU 是指配置了流镜像的单板上的 CPU), 通过 CPU 分析报文的内容, 或者将特定的协议报文上送 2.2 流镜像配置任务简介 表 2-1 流镜像配置任务简介 配置任务 说明 详细配置 配置报文匹配规则 必选用来匹配待镜像的报文 配置流行为 必选用来指定将报文镜像到哪里 ( 即报文的目的地址 ) 配置 QoS 策略 必选为流分类指定采用的流行为, 即指定哪些报文需要镜像到哪里 应用 QoS 策略 基于接口应用 三者至少选其一 基于 VLAN 应用 指定对来自哪个端口 VLAN 等的流量进行镜像 基于全局应用 实现流镜像功能时, 仅入方向支持 配置流镜像 除 mirror-to 命令外的其他配置命令及相关显示命令的详细介绍, 请参见 ACL 和 QoS 命令参考 中的 QoS 策略 2-18

209 2.3.1 配置报文匹配规则表 2-2 配置报文匹配规则 操作命令说明进入系统视图 system-view - 定义流分类, 并进入流分类视图 traffic classifier tcl-name [ operator { and or } ] 缺省情况下, 不存在任何流分类 配置报文匹配规则 if-match match-criteria 缺省情况下, 流分类中不存在任何报文匹配规则 配置流行为表 2-3 配置流行为 操作命令说明进入系统视图 system-view - 定义流行为, 并进入流行为视图 traffic behavior behavior-name 缺省情况下, 不存在任何流行为 在流行为中配置流量的目的地 配置流镜像到接口 配置流镜像到 VLAN 配置流镜像到 CPU mirror-to interface interface-type interface-number [ sampler sampler-name ] mirror-to vlan vlan-id mirror-to cpu 三者必选其一缺省情况下, 流行为中未指定流量的目的地 在完成上述配置后, 在任意视图下执行 display traffic behavior 命令可以显示用户定义流行为的配置信息, 通过查看显示信息验证配置的效果 允许将流量镜像到尚未创建的 VLAN, 待该 VLAN 被创建并有端口加入后, 本配置将在这些端口上自动生效 上述 CPU 是指配置了流镜像的单板上的 CPU 配置 QoS 策略表 2-4 配置 QoS 策略 操作命令说明进入系统视图 system-view - 定义 QoS 策略, 并进入 QoS 策略视图 qos policy policy-name 缺省情况下, 不存在任何策略 2-19

210 操作命令说明 为流分类指定采用的流行为 classifier tcl-name behavior behavior-name 缺省情况下, 没有为流分类指定采用的流行为 在完成上述配置后, 在任意视图下执行 display qos policy 命令可以显示用户定义策略的配置信息, 通过查看显示信息验证配置的效果 应用 QoS 策略 1. 基于接口应用将 QoS 策略应用到某接口, 可以对该接口指定方向上的流量进行镜像 一个 QoS 策略可以应用于多个接口, 而接口在每个方向上只能应用一个 QoS 策略 表 2-5 基于接口应用 操作 命令 说明 进入系统视图 system-view - 进入接口视图 interface interface-type interface-number - 应用 QoS 策略到接口 qos apply policy policy-name { inbound outbound } - 应用 QoS 策略到接口时, 仅 inbound 方向配置生效 2. 基于 VLAN 应用将 QoS 策略应用到某 VLAN, 可以对该 VLAN 内各端口指定方向上的流量进行镜像 表 2-6 基于 VLAN 应用操作命令说明进入系统视图 system-view - 应用 QoS 策略到指定 VLAN qos vlan-policy policy-name vlan vlan-id-list { inbound outbound } - 应用 QoS 策略到指定 VLAN 时, 仅 inbound 方向配置生效 3. 基于全局应用 将 QoS 策略应用到全局, 可以对设备各端口指定方向上的流量进行镜像 2-20

211 表 2-7 基于全局应用 操作命令说明 进入系统视图 system-view - 应用 QoS 策略到全局 qos apply policy policy-name global { inbound outbound } - 应用 QoS 策略到全局时, 仅 inbound 方向配置生效 2.4 流镜像典型配置举例 缺省情况下, 以太网接口 VLAN 接口及聚合接口处于 DOWN 状态 如果要使这些接口能够正常工作, 请先使用 undo shutdown 命令使接口状态处于 UP 1. 组网需求 某公司内的各部门之间使用不同网段的 IP 地址, 其中市场部和技术部分别使用 /24 和 /24 网段, 该公司的工作时间为每周工作日的 8 点到 18 点 通过配置流镜像, 使 Server 可以监控技术部访问互联网的 WWW 流量, 以及技术部在工作时间发往市场部的 IP 流量 2. 组网图图 2-1 流镜像典型配置组网图 2-21