思科运营商路由系统可以通过内嵌的可治理性，支持不间断的系统运行和服务灵活性。这种可治理性能够不断改进，满足路由技术和服务供给商的各种要求。
为多机架治理做好预备
在今天的服务供给商网络中，大部分核心路由器都是拥有大量接口，并且可以扩展到数千个的单机架系统。在治理这些路由器时，需要采集、处理和转发的数据的数量将与有效接口的数量成比例增长。
这种方式的扩展能力如何？假设有一台具有几百个接口的路由器，它的一个或者多个接口发生故障。这时，会生成一个或者一组警报，并将其发送到一个事件控制台。控制台将关联该警报，并通知操作人员。关联、通知，甚至故障的解决都可能在几秒钟或者几分钟之内完成。
现在设想一下将同样的接口设置成具有数千个通道化接口的中继时发生的情况。当一个或者多个接口发生故障时，大量的警报会被发送到事件控制台，从而迫使操作人员利用脚本语言——例如实际抽取报告语言（PERL）和工具命令语言（TCL）——分析警报，以确定故障的性质。尽管这种使用顶置脚本处理事件的常见做法变得越来越复杂和费时，但是它仍然很有效。故障会在可以接受的时间内被诊断和解决。
现在，设想一台具有数百个40Gbps插槽的Tb级多机架路由系统。它包含了几千个接口，可以为数万个客户提供支持。尽管比治理单独的、可以提供相同容量的组件简便得多，但是警报个数仍然会以指数形式迅速增长。事件治理系统能否通过扩展，支持这些负载？事件关联和响应能否以足够快的速度进行，以便为受到某个故障影响的客户保持不间断的服务和服务水平协议（SLA）？
随着多机架路由系统的出现，进行处理的时间和地点必须进行相应的改变。通过治理多个网络组件的组件治理系统（EMS）现在需要负责治理多个系统和逻辑组件。集成流程过去只需要将单个机箱的治理数据发送到北向运营支持系统（OSS）应用，而现在则必须从一个更加抽象的数据源中获得数据，再提供给这些应用。
长期以来，大型网络的操作人员一直期望和提倡将网络治理智能转移到网络本身。为了在多机架路由平台上保持不间断的系统运行，必须使用嵌入式、模块化的检测技术来自动执行运营、治理、维护和供给（OAM&P）任务。故障、配置、记帐、性能和安全（FCAPS）的治理必须符合业界标准，以提供与现有OSS应用（例如供给和计费）的集成，从而提高收入和降低运营成本。
Cisco CRS-1的可治理性
思科运营商路由系统（图1）是一个多机架路由平台，它建立在一个微内核、分布式、模块化的操作系统——Cisco IOS XR——的基础上。
图1 思科运营商路由系统
实现这种可治理性需要跟上高端路由技术的发展步伐。Cisco CRS-1根据多机架路由环境的要求设计了CRS-1的可治理性。在这种环境下，CRS-1的新型分布式、模块化架构不仅对可治理性提出了新的要求，而且还为治理流程带来了便利。
在这种微内核架构中，每个治理流程都具有全面的内存保护和故障隔离。通过将流程分配到不同的面板，治理面板既不会影响控制和数据面板上的流程，本身也不会受这些流程的影响。这种模块性不仅带来了更高的安全性，而且提供了在不影响路由控制功能或者网络流量的情况下修改治理流程的能力。
为了在一个分布式治理环境中保持性能，CRS-1分布式路由处理器架构可以在多个路由处理器之间平衡处理需求。在面临沉重的网络治理负载（例如数据采集或者警报处理）时，任务会被分配到任何可用的资源，以避免对要害任务造成不利的影响。为了支持OAM&P功能，闪存提供了永久存储，而硬盘资源可用于存储临时性的调制和诊断数据。
为了支持不间断的系统运行和灵活的治理服务，CRS-1具有三个要害的内嵌式治理功能：内嵌检测、内嵌接口、内嵌应用服务。
内嵌检测
路由器的检测和治理接口是其可治理性的两个最重要的方面。假如路由器没有合适的检测功能来提供信息和控制，操作人员和OSS应用就无法对其进行有效的治理。
Cisco CRS-1提供了远远超出简单的路由器检测的嵌入式FCAPS治理。通过执行很多以前由外部治理应用执行的治理任务，CRS-1能够以快于单机箱平台的速度响应事件和请求，并可以对数据进行整理，以帮助OSS系统扩展规模。
嵌入式故障治理
高度可扩展的多机架平台需要处理大量的流量和生成大量的警报，所以对现有的事件治理平台提出了独特的要求。
嵌入式CRS-1事件治理器支持自主的事件关联和过滤，以降低来自于数十万个接口的大量事件信息。由用户定义的过滤和关联规则可以支持很高的精确度，而事件关联功能可以自动地对像启动系统恢复任务这样的事件采取措施，例如保护交换机或者采用用户提供的TCL脚本。
例如，单个事件——例如线卡在线插拔（OIR）——可能会导致多个应用通信和接口故障警报。用户可以定义一个关联规则，将所有有关的事件连接到某个指定的根事件——假设它们都在设定的时间间隔内到达。因此，只有根事件会被转发，从而大大降低事件治理系统的警报负载。（用户仍然可以查询相关事件。）
事件治理器还支持一个由用户设置的警报缓存。一个外部治理系统或者操作人员可以组织或者查询缓存中的警报，以便分析状态或趋势。因为CRS-1的架构具有很高的可用性，缓存中的警报会进行校验，以防止警报在路由处理器进行故障切换或者流程重启时丢失。
嵌入式配置治理
尽管系统停机通常是由于网络以外的来源所导致的，但是它也有可能是由网络四周的来源——操作人员——所导致。
因为多机架路由器的配置非常复杂，而且故障或者延迟可能会对客户服务造成严重的影响，所以需要一个嵌入式的、智能的配置流程来保持不间断的系统运行和迅速的实施。
内嵌的CRS-1配置治理器可以在启动、运行和OIR事件期间优化路由器的配置流程。通过同时和批量在启动和OIR事件时分配和执行改动，平均修复时间（MTTR）将会最大限度地缩短。通过校验逐步进行的配置升级，配置治理器让CRS-1可以在正常运行过程中支持配置升级上载或者恢复。
为了解决大型边界网关协议（BGP）路由配置在多机架路由环境中带来的挑战，Cisco IOS XR软件还提供了一种新的路由策略语言（RPL），它能够将数千个BGP对等操作集中到一个或者多个紧凑的逻辑路由器配置中。
嵌入式记帐
记帐是网络治理在流量工程、计费和安全方面的一个不可或缺的重要组成部分。
为了支持嵌入式记帐治理，CRS-1提供了一个新版本的NetFlow——静态NetFlow。NetFlow是动态的，可以采集、汇聚和输出大量的数据进行分析，而静态NetFlow对分组流的处理方式与访问控制列表（ACL）类似，但是具有扩展字段，例如源和目的地的自主系统编号和多协议标签交换（MPLS）标签。利用静态NetFlow，可以定义一个具有扩展ACL的流量过滤器，以便跟踪某个特定数据流的分组和字节计数器。静态NetFlow计数器的存储和接收方式与可扩展标记语言（XML）或者简单网络治理协议（SNMP）计数器相同。
为了提高效率，静态NetFlow部署在CRS-1的硬件中（以微代码的形式），以便最大限度地降低对路由器的CPU性能的影响。一旦计数器被采集，它们就将通过线卡数据接口，输出到外部采集器。这消除了对性能的负面影响，因为CRS-1可以在控制面板和数据面板之间提供完全的隔离。
嵌入式性能监控
在基于单机箱平台的大型网络中，性能监控和趋势分析很难实现。来自于为数众多的网络组件的大量可用数据通常会超出负责采集、存储、治理和处理数据的OSS性能监控组件的能力。这些数据还可能会对组件和采集器之间的网络流量造成严重的影响。通常，可以通过只针对平台中的特定目标——而不是分析整个网络的趋势——限制所采集的数据的容量。
因为多机架路由器的规模很大，传统的基于某个集中应用的数据轮询已经无法满足需要，而且效率极低。因此，CRS-1上的性能统计数据和计数器的采集是由内嵌的性能监视器执行的。
Cisco CRS-1的性能监控能力让操作人员可以定义所要采集的统计数据、采集的频率，以及内存中保存的样本总数。采集操作可以被设置为按需运行或者定期运行（用于分析趋势）。按需采集通常用于进行迅速的调试和诊断，例如查看利用率。无论是按需还是定期采集，数据采集都不会影响同时进行的其他采集流程。在采集阶段结束之后，数据可以被外部采集器轮询，或者输出到外部采集器。
CRS-1的性能监视器可以在所有支持的实体上，将本地的计数器与用户设置的阈值相比较，例如比较错误计数器和MPLS的接口、连接利用率。阈值条件被定义为对某个相对于阈值（使用百分比或者绝对值）的属性值的逻辑操作。阈值规则将在每次采集期间进行评估。一旦达到或者超过某个阈值条件或者标准，就会立即生成一个阈值超越警报（TCA）。范围操作功能让用户可以跟踪计数器在某个特定范围中的值（例如，CPU利用率介于20%到60%之间），因而可以在系统性能超出预定范围时提供一个功能强大的通知机制。阈值重设规则指定了是否生成阈值通知——即使已经达到阈值条件。这避免了在某些情况下生成大量的阈值通知，例如在很短的时间或者间隔内阈值条件被反复超过。
搜集到的所有数据都会进行校验，以防止数据在路由处理器进行故障切换或者流程重启 时丢失。与其他事件一样，由嵌入式性能监视器生成的TCA可以像“嵌入式故障治理”部分介绍的那样，自动地对事件采取措施。
嵌入式安全
尽管必须通过检测功能防止服务供给商遭受安全故障所导致的损失，但是对这些检测功能的使用也必须得到保护。
Cisco CRS-1的安全治理访问功能是通过基于安全套接字层（SSL）、Secure Shell（SSH）协议、IP安全（IPSec）、TACACS+和RADIUS的身份验证、授权和记帐（AAA）实现的。另外，新的基于ID的安全功能可以对每项任务提供比典型的、基于角色的访问控制更加精确的控制。在基于任务ID的安全中，可以定义不同的用户类型，并将其分为不同的群组。每个群组都与某个特定的任务组——例如BGP和MPLS任务——相关联，并且设有明确的权限（读取或者写入）。
任务ID还可以在路由器治理任务授权方面提供灵活性。为了确保软件镜像的完整性，可加载的软件会在安装期间，由安装治理员进行数字签名和身份验证。假如某个软件包没有通过身份验证，它就无法执行。
嵌入式接口
为了使用嵌入式检测功能提供的信息和控制，路由平台必须通过接口--通常是通过硬件和软件--提供访问途径，即所谓的应用编程接口（API）。这些接口应当是开放的，并且建立在行业标准的基础上。假如接口是专用的，服务供给商就需要为将路由器集成到他们现有的OSS基础设施中付出高得多的成本。而且，随着OSS的发展，他们还将承担更高的维护成本，从而提高了路由器的总拥有成本。
Cisco CRS-1可通过物理接口和标准的API（如图2所示）访问Cisco IOS XR软件中内嵌的检测功能，其中包括一个内部元数据模型，它可在命令行界面（CLI）、SNMP或XML之间保持治理一致性：
图2 Cisco CRS-1可治理性架构
物理接口--因为指向某个发生故障的或者正在初始化的设备的网络连接并不总是可用的，所以CRS-1可以在路由处理器和分布式路由处理器上支持串行控制台/辅助端口和10/100/1000以太网治理接口。
作为CRS-1的治理入口，以太网接口都是可路由端口，能够通过ACL控制，根据安全策略过滤治理访问流量。
Cisco CRS-1 CLI--与大部分网络设备一样，CLI是一种为操作人员所熟悉的传统治理方法。熟悉Cisco IOS CLI的用户将能够迅速地学会和适应Cisco IOS XR CLI。
SNMP--尽管不一定总是最有效的方法，但是SNMP是治理系统使用的最为普遍的协议之一。为了支持与大部分OSS应用--尤其是事件治理--的集成，Cisco IOS XR软件支持一个广泛的MIB列表和多个SNMP版本，包括SNMPv1、v2c和v3。
XML--XML也许是最常用的供给集成ARP。它可以为在路由器和治理应用之间格式化、编码和传输复杂的数据提供一个出色的机制。
CRS-1的可编程接口是通过XML提供的。它的丰富机制让操作人员可以迅速地为路由器配置和监控开发治理脚本和顶置的应用。利用XML接口，客户端应用可以将查询请求封装在XML流中，并通过多种传输方法--例如公共对象请求代理体系结构（CORBA）--将其发送到路由器，从而访问CRS-1的治理数据。查询结果将作为一个由XML编码的响应流，返回到客户端。路由器XML机制文档中定义和公布了XML标签。客户端应用可以利用这些标签编码和解码XML流。一个带有标签的响应可以被用于定制外观和设定数据显示的格式，从而不需要分析没有格式化的ASCII文本--在基于文本的响应中经常需要这样做。
嵌入式应用服务--Craft Works接口
作为一个更加有效、界面更加友好的多机架治理工具，Craft Works接口（CWI）是一个使用了CRS-1 XML接口的内嵌式Java应用，它支持增强的CLI功能、一个文本编辑器和一个可以从Web浏览器启动的GUI（CWI Desktop）。
CWI Config Editor
利用CWI Config Editor，用户可以在不对目前正在运行的配置造成任何影响的情况下，修改配置和保存配置改动。网络操作人员可以获得标准的全屏编辑功能，例如区块复制和粘贴，命令自动输入，以及检查语法、在最后提交之前查看改动和在实际应用之前验证配置的功能。
CWI CLI
Cisco IOS XR的CLI支持增强的功能，例如历史命令调用和批处理，从而让CRS-1的治理变成了一种更加个性化的体验。在SSH/Telnet窗口中提供了一个本地命令缓存，将常用命令保存在每个用户的本地存储中。治理人员在登陆到每台路由器之后，可以调用这些常用命令，以加快治理速度和简化应用。另外，治理人员还能够以批处理的方式执行一个事先存储的命令文件。
CWI Desktop
CWI Desktop（如图3所示）提供了一个GUI，它让操作人员可以直观地查看系统的各个组件及其状态。它提供了对一些由CRS-1支持的、重要的嵌入式FCAPS功能的访问：
图3 CWI Desktop
设备树--因为CRS-1是一个多机架系统，所以左栏（如图4所示）中显示的设备树提供了系统的物理机箱或者逻辑路由器视图。这个设备栏可以显示机架、板卡、插槽和端口信息，或者将它们输出到一个结构化的文件格式。每个树条目的颜色代表该组件的状态，并且建立在所生成的最高级别的警报的基础上。CWI警报视图是上下文相关的；假如只针对某个特定的组件启动，那么就只会显示该组件的警报状态。
图4 CWI设备和警报视图
警报面板--警报面板（如图5所示）显示了隶属于每种警报严重性等级（严重、重要、次要、警报和不确定）的现有警报的总数。最右侧的计数器表示在现有进程中收到的警报总数。
图5 CWI警报面板
机架视图--熟悉CiscoView的网络操作人员会很快适应CWI机架视图工具的可视化外观。通过编程，板卡视图中的LED可以传达查看机箱视图的网络运营中心（NOC）操作人员向物理机箱所在地的现场技术人员发出的简单讯息。例如，NOC操作人员可以在某个物理卡上创建一个文本消息，告知现场技术人员该卡需要移除。
配置桌面--配置桌面（如图7所示）为简化路由策略、ACL、服务质量（QoS）和多种协议（例如BGP、中间系统－中间系统（IS-IS）、开放最短路径优先（OSPF）、MPLS-TE和资源预留协议（RSVP））的设置提供了一个GUI。例如，假设必须在所有接口上设置一个新的MTU。假如接口不多，可以使用CLI。但是，假如接口有几百个，甚至上千个，CLI设置就需要投入大量的人力。然而，操作人员只需点击几下鼠标，就可以利用CWI配置桌面，将这项改动统一地应用于所有的接口，从而提高生产率和降低运营成本。
图7 CWI配置桌面
结论
高利润的服务供给商网络依靠于可以提供不间断的系统运行和出色的服务灵活性的下一代路由平台。要为核心路由平台提供极高的可用性和方便的服务供给，要害是采用一个强大的可治理性解决方案。
通过支持嵌入式检测、接口和应用服务，思科运营商路由系统为集成在现有OSS环境中的路由和可治理性技术提供了一个重要的发展方向。
如需了解更多关于补充性EMS和OSS解决方案的信息，请联络您的思科客户代表。
