1

让网络运维更智能 POSTED BY ADMIN ON APR 1, 2012 IN FLOWS30 | 0 COMMENTS

1.前言

随着我们的网络规模日趋庞大，网络工程师设备运维工作的压力也越来越大，如何找到

一种高效的设备管理方法，也成为了每个网络运维工程师所关心的一大问题。以路由器

管理工作为例，当网络中的路由器数目还不算太多的情况下，工程师们可以依靠自己熟

练的技术及灵活的思维来妥当完成运维的工作，但是在设备数量呈倍数增长的今天，如

果没有一个行至有效、完善的工作流程，那么保障网络及几十上百台路由器的健康，将

是一项不可能完成的任务。

在《TCP/IP 路由技术(第二卷)》一书的第九章就提到，“为了保证网络和众多路由器的

健康，必须保证能够管理它们，包括主动式管理和被动式管理。此外，利用实验室或工

具来测试和监控转发机制的效果，以确保网络和路由器能持续平滑地运行。”同时，文

中也提供了一些有效的方法，如果我们用 Mind Map 把这些思路整理出来，便可以形

成如下图所示的一个整体方案：

2

从 Mind Map 中可以看到，《TCP/IP 路由技术(第二卷)》把路由器管理工作的要点分为

4 大类，包括策略及规程定义、监控协议、日常管理以及记账，而每个大类中还有许多

分支的工作需要完成。可见路由器管理并非一件轻松的差事，那么面对这么多的细致工

作，有没有一个办法能把它们有效的整合，从而提高我们的工作效率呢？

答案是肯定的。看到《TCP/IP 路由技术(第二卷)》一书对路由器管理工作给出的定义及

工作内容，我们很容易就联想到了 Splunk，以及 5 位 Cisco 安全工程师利用 Splunk

来对分布在全球的众多防火墙进行管理的故事，既然已经有了这么一个高效管理网络设

备的典范，我们也可以依样画葫芦，来探讨利用 Splunk 来高效管理路由器的可行性。

下面我们就以 Mind Map 中描述的路由器管理工作作为思路，来做一一分析。

2.策略及规程定义

如果没有清晰的策略及规程，几乎不可能成功的管理大量路由器，必须用文档确定操作

策略，明确不同的负责人以及各自的责任时间，当路由器的配置发生变更后需要用相关

的文档记录下来，而当更熟练的工程师开始处理网络问题以及涉及网络管理时，规程则

规定了需要遵循的步骤。

在规定用户期望从网络中获得相应 QoS 的策略时应包含相应服务不能满足时所要采取

的动作，这些就被称为 SLA。

2.1 SLA

SLA 中规定的服务数量可以是向用户保证的响应时间和吞吐量等关键性能指标，一般也

以网络可用性的百分比来表示，其余包括故障最大时间、计划故障时间以及故障恢复时

3

间等，也是衡量一个网络 SLA 的重要指标，这部分内容需要由文档进行规范，而管理

员需要把 SLA 规范熟记在心，而随时监控 SLA 中所规范的性能指标。

根据实际情况制定好 SLA 规范以后，我们就可以开始监控工作了。利用 Splunk，我们

可以对违反 SLA 规范的事件次数进行监控，以便对我们的网络管理工作重点进行快速

调整。

如果我们对服务系统的业务响应时间有明确的 SLA 规范，那么对于系统的实时响应性

也应该实时进行监控，以 SLA 规定的响应时间为基准线，了解当前系统的响应性能情

况。

4

为了有效测量当前业务系统响应性能，我们需要选用一些外部协议工具，IP SLA 是一个

不错的选择。使用 IP SLA 的路由器可以执行周期性测测量，测量次数以及可用的测量

类型十分丰富，例如 ICMP ECHO 作业以及 TCP 连接作业等。唯一的问题在于如何获

取 IP SLA 的测量结果，现在，我们可以通过 Netis 的 NTR 引擎，将 IP SLA 测试包的交

互情况汇总成为具体的响应时间数值，并通过 Splunk 进行实时监控。当然，直接通过

业务数据交互的连接情况，也可以通过 Netis 的 NTR 引擎计算出当前服务的响应性能，

并且通过这种方法获得的响应时间指标更加客观直接。

2.2 变更管理

变更管理策略是说明何时可以实施变更、由谁实施变更、如何记录和发布即将实施的变

更以及如何记录整个变更的情况。

虽然每个企业的变更管理系统不尽相同，但无论是什么类型的变更管理系统，理论上都

可以通过 SQL 语句或是自带的数据导出接口获取变更记录细节，进而我们可以在

Splunk 中将其展现出来，来打造我们的路由器统一管理平台。

2.3 上报规程及更新策略

明确定义的上报规程有助于清晰化每个工程师职责，同时尽可能节省故障处理的时间。

而更新策略的重点在于通知与执行。利用 Email 或电话来进行沟通固然是最好的方法，

5

但如果可以使用RSS来发送故障或培训通知，并利用 Splunk的RSS Apps来进行接收，

则不仅可以把所有事件都有效保存下来，也能够使我们的运维工作更加智能化。

3.监控协议

3.1 SNMP/RMON

SNMP 及 RMON 都是常用的网络管理协议，管理员通常可以利用 SNMP 来获取设备的

运行信息，例如 CPU 利用率、内存利用率以及端口流量大小等，而 RMON 则大大的

增强了 SNMP 所提供的能力，让管理员能通过管理平台查看更多关于节点以及节点间

交互的信息。

我们尝试在 Splunk 上实现基于 SNMP 的路由器设备监控，为了让 Splunk 服务器可以

接受到设备的 SNMP 消息，需要借助一个叫做 Net-SNMP 的小程序。Net-SNMP 是一

个针对 SNMP 的工具集，包含了多个处理 SNMP 信息的小工具。

对于路由器上预先设置好的 SNMP Traps，需要使用 Net-SNMP 中的小工具

snmptrapd 来进行接收，并保存到一个文本文件中，snmptrapd 的命令格式示例如

下：

snmptrapd -Lf /opt/net-snmp/snmptrap.log –disableAuthorization=yes

命令运行后 snmptrapd 工具会开始接收设备发送过来的 SNMP Trap，并记录在文件

/opt/net-snmp/snmptrap.log 中。

6

除了接收设备发送过来的 SNMP Trap 之外，当然还需要监控设备运行状况的数据，于

是我们可以借助 Net-SNMP 中的另一个小工具 snmpwalk，snmpwalk 可以向路由器

设备请求设备运行状况的相关数据，命令格式示例如下：

snmpwalk –v 2c –c public 10.0.0.155

其中 2c为 SNMP协议的版本号，public为设备与服务器协商的 community字符串，

10.0.0.155 则为路由器设备发送 SNMP 信息的源端口 IP 地址。

此时屏幕输出许多数字串，看起来似乎没什么意义，但实际上这些数字串为设备存储在

mib 库中的 oid，每一个数字串都代表一个设备运行状况的指标，因此在这里我们需要

进行一些简单的翻译工作。由于每一个厂商及设备的 oid 规范不禁相同，以 Cisco 路

由 器 为 例 ， 我 们 需 要 借 助 厂 商 提 供 的 mib 查 询 工 具

(http://tools.cisco.com/ITDIT/MIBS/MainServlet)来进行查询每一个 oid的具体含义。

而我们也可以根据查找到的 oid 利用 snmpwalk 工具来得到我们所需要了解的设备信

息，例如，我们查询到 Cisco 路由器 avgBusy5(CPU5 分钟利用率的平均值)的 oid

为.1.3.6.1.4.1.9.2.1.58，我们可以把 snmpwalk 查询的命令修改为 snmpwalk -v 2c

7

-c public 10.0.0.155 .1.3.6.1.4.1.9.2.1.58 >> /opt/net-snmp/snmpavgbusy5 并且

利用 crontab 等任务计划工具让命令按一定的频率自动运行，同时把结果输出到

/opt/net-snmp/snmpavgbusy5 文件中。

如此一来，我们只需在 Splunk 中进行简单的处理，便可以对设备的 CPU 利用率进行

监控了，如果有必要，我们还可以把 SNMP 的采样时间频率提高，得到更精确的路由

器运行指标。

4.日常管理

4.1 日志记录/syslog

要掌握网络中众多路由器的运行状况，日志记录当然是必不可少的工作，一般网络设备

都会有日志记录的功能，但是要将这些日志发送到我们的统一监控平台上进行管理查询

则需要用到 syslog，syslog 是一个运行于 Unix 服务器上的守护进程，会收集信息并存

8

储在日志文件中，那么 Splunk 只需对这些日志文件进行监控即可。

为了让路由器的日志能够通过 syslog 发送到 Splunk 服务器上，首先要在路由器上做好

相关配置，以 Cisco 路由器为例，命令示例如下：

Router(config)#logging 10.0.0.150(配置 syslog 服务器地址,可以定义多个)

Router(config)#service timestamps debug datetime localtime show-timezone msec Router(config)#service timestamps log datetime localtime show-timezone

msec(syslog 信息包含时间戳)

Router(config)#logging facility local3(定义 facility 级别,缺省为 local7,可以设置

从 local0 到 local7)

Router(config)#logging trap warning(定义 severity 级别缺省为 infor 级别)

同时，我们还需要配置好 Splunk 服务器的 syslog 进程来接收路由器的日志消息，具体

方法如下：

修 改 /etc/sysconfig/syslog ， 把 SYSLOGD_OPTIONS=”-m 0″ 修 改 为

SYSLOGD_OPTIONS=”-r -m 0″

修改/etc/syslog.conf ，增加 local6.* /opt/net-snmp/routersyslog.log 一行，把设

备号为 local6 的设备日志保存在/opt/net-snmp/routersyslog.log 文件中。

完成后，所有指定的路由器日志将会保存在在 Splunk 服务器的 routersyslog.log 文件

中，我们便可以开始利用 Splunk 来对这些日志进行加工分析了。

9

4.2 配置管理

为了确保能将最近的配置恢复到路由器中，我们需要维护所有网络设备的配置文件，并

周期性的下载所有的配置文件，这样做不仅可以在路由器配置丢失时可以快速恢复，同

时也可以方便我们将所有配置都作为历史记录有效保存。

我们知道在 Cisco 的路由器中，可以通过命令 Router#copy running-config tftp 来

把当前运行的配置保存到 tftp 服务器上，但是如果可以自动、定时的完成配置的保存

会不会更智能？幸好路由器厂商们已经帮我们想好了这个问题，以Cisco路由器为例，

我们可以通过以下的配置来自动、定时的将设备的配置保存到我们的 tftp 服务器上：

Router(config)#kron policy-list tftp Router(config-kron-policy)#cli show run | redirect tftp://10.0.0.150/r2-config Router(config-kron-policy)#exit Router(config)#kron occurrence tftp at 23:28 Sun recurring Router(config-kron-occurrence)#policy-list tftp

我们已经定义好让路由器每个周日的 23:28 自动将配置保存到 tftp 服务器上，那么接

10

下来的事情就只需要在 Splunk 服务器上开启好 tftp 服务便可以了。

路由器已经自动将运行配置以文本文件 r2-config 的形式保存到了 tftp 服务器上，接下

来的工作就变得简单了，只需在基于 Splunk 的统一管理平台中做好相应的界面进行查

询展示即可。

4.3 故障管理

可信赖的网络需要良好的故障管理机制，需要尽可能快地发现潜在和现有故障，以便快

速采取措施来解决问题，希望在用户感知网络故障之前，网络管理平台就能检测到设备

的链路故障。

采用 SNMP Trap来进行故障管理是一个选择，但是由于 SNMP利用UDP来发送 Trap，

因而无法保障描述故障的消息能够到达管理平台。在《TCP/IP 路由技术第二卷》中给

出另一个建议，采用 ICMP ping 对路由器进行轮询，以确定每个路由器是否可达，因

11

此，IP SLA 的 ICMP Echo 作业也是一个不错的选择。

除此之外，我们知道 Splunk 可以通过运行脚本来获取数据，我们可以建立一个简单脚

本，内容是只是去 ping 一些 IP 地址，然后在 Splunk 的管理->数据导入->脚本界面中

增加该脚本的数据源，并设置好脚本执行的时间间隔。

完成以后 Splunk 便会定时获取脚本的运行结果了，下图便是 Splunk 定时获取脚本中

ping 22.0.0.1 –c 10 的执行结果。

12

有了轮询路由器的方法以及结果，接下来我们便可以利用这些数据来进行视图的编辑以

及告警的创建了。

4.4 安全管理

路由器的安全管理主要在于三方面，一是加密认证的方法，主要是依赖于密码管理以及

外部认证系统，我们可以利用 Splunk 的集成来完成这部分内容；二是访问控制列表的

管理，这一点我们可以通过前面配置管理的方法来进行监控；三是路由器行为的监控，

我们可以通过日志监控来实现这个目标，另外 Splunk 提供的几个 Cisco Security 的

app 也可以很好的完成这项工作。

4.5 NetFlow

收集流量流的统计信息可以用来计算网络的使用率情况，特别是在实施流量工程或基于

使用量对网络用户进行审计时。这样 NetFlow 就是一个非常有用的功能，NetFlow 可

以在路由器上标识出各种流量流，并把统计信息导出到管理平台上。

为了让基于 Splunk 的统一管理平台能够读取到路由器的 NetFlow 统计信息，我们需要

在 Splunk 主机上借助一个叫做 Flow-tools 的小工具，Flow-tools 是一个运行在 Linux

下的简易工具，专门用来收集 NetFlow 的信息，并且还可以将这些信息导出成为文本

文件。在配置好路由器的NetFlow以后，可以在 Splunk主机上下载并安装 Flow-tools，

然后建立一个文件夹来存放收集的 NetFlow 数据：

mkdir /opt/netflow

运行/usr/bin/flow-capture -N -1 -z 6 -n 250 -V 5 -w /opt/netflow 0/0/9996 让

Flow-tools 通过 9996 端口接收 NetFlow 数据。

若/opt/netflow 下有生成一个以当日日期为名的文件夹，则说明接收 NetFlowDE 配

13

置正确。

进入文件夹查看发现 NetFlow 的数据已经收集成功并保存为特定格式的文件。

下一步运行/usr/bin/flow-print -fo > ./test 将 NetFlow 数据输出成为文本文件 test，

如果需要长期对 NetFlow 进行收集还可以编写一个简单的 shell 脚本让 Flow-tools 的

工具定时自动运行。

下面便可以在 Splunk中对 test文件进行索引并根据可到的数据来加工相关的视图以及

报表了。

14

5. 结束语

当我们设定好运维目标以及运维计划之后，还需要一个管理平台来支撑我们的管理工作。

上文以路由器管理为例，描述了一个支撑管理平台的搭建过程，但是网络设备种类繁多，

为了更好的搭建适合我们自己的管理平台，平台本身理应满足以下条件：

支撑管理平台应该足够健壮灵活，能够很方便的在平台中增加新的内容；

支撑管理平台需足够安全，可以灵活设置安全策略；

支撑管理平台能够将我们的需求落地，否则没有意义；

支撑管理平台运行需足够稳定，不会遗漏任何我们需要的信息。

让我们也搭建一个属于自己的管理平台，智能化我们的网络运维工作吧！

Peter