67、网络管理：配置协议、统计收集与策略控制

网络管理：配置协议、统计收集与策略控制

1. 选择配置协议

在 CORBA、XML 和 SNMP 之间做出选择并非易事，即便你已决定采用标准化技术，而非设备内置的专有配置机制。以下是对这三种协议的详细分析：
- SNMP ：它是一种成熟的网络管理协议，其 MIB 模块由 IETF 设计，通常由编写被管理协议的人员参与。MIB 模块提供了大量详细信息和精细控制，但这也在一定程度上成为其缺点，因为详细程度增加了模块对读者和实现者的复杂性。不过，无论使用何种协议管理，所需管理的信息量是固定的，所以关于管理数据量的讨论并无实际意义，关键在于编码和协议本身。SNMPv2 尽管存在安全担忧，但仍被广泛使用，MIB 模块能详细分解配置数据。虽然 ASN.1 最初较难掌握，但熟悉后文本表示易于阅读，还能自动解析以生成管理应用程序和客户端、服务器的源代码。
- XML ：它提供了一种易于扩展、人类可读且程序易于解析的编码技术。其缺点是可读性导致文本冗长，不过传输协议中的压缩技术可缓解这一问题。XML 开发简单快捷，正逐渐受到广泛欢迎。
- CORBA ：在大型服务提供商中已占据一席之地，图 13.1 所示的结构化管理网络很受欢迎。由于 CORBA 常作为 EMS 的北向接口，因此在被管理设备上提供 CORBA 支持是合理的。此外，它因其面向对象的特性以及 C++ 和 Java 中 ORB 组件的可用性，受到面向对象程序员的青睐。

此外，还可以混合使用这些协议。例如，将配置数据以 MIB 格式保存，但使用 CORBA 或 XML 作为批量数据进行传输，这样既能继续使用详细的 MIB 模块，又能避免早期 SNMP 版本的一些安全问题。

2. 选择收集统计信息

成功的网络运营不仅要配置设备，还需持续监控网络中链路和节点的状态，以检测故障、拥塞和网络“热点”。服务提供商要达到合同规定的服务水平，就必须时刻了解网络负载，并尽快发现节点和链路故障。
- SNMP 的作用 ：它通过陷阱消息提供通知，在关键事件发生时提醒管理站。同时，它还能访问计数器，提供特定接口或设备流量的基本统计信息，管理站可反复读取这些计数器以了解网络使用情况的变化。
- 实时收集统计信息的影响 ：实时收集网络统计信息可能对网络运行产生不利影响。反复在多个节点读取数据会产生大量额外流量，可能导致数据集中处周围的网络拥塞。因此，在日常操作中，应采用结构化方式收集统计信息，重点关注网络的入口和出口点，而非整个网络的每个链路和节点。这样做有助于监管网络间协议，并检查哪些外部链路接近其容量限制。
- 多收集点的使用 ：可以在网络中使用多个收集点来分担统计信息收集的负载。这些中间收集点可将数据集合并为一组有用的统计信息，然后转发到中央收集点。由于不同统计信息有不同用途，如计费、故障检测、长期规划和服务维护，中间收集点可过滤统计信息，并将信息发送给相应的使用者，同时为每个设备提供单一的联系点。
- NetFlow 架构 ：SNMP 虽然能提供必要的统计信息，但它基于请求 - 响应模式，MIB 模块主要用于广泛的配置报告，而非单纯的统计收集，因此用于网络监控时会引入较大开销。作为替代方案，Cisco 设计的 NetFlow 架构正被 IETF 考虑标准化。NetFlow 基于一系列专门设计的记录格式，用于包含统计信息并允许设备向收集点报告批量数据。设备收集 NetFlow 记录后，可根据定时器或阈值定期使用 FTP 等文件传输协议发送到收集点，中间收集点也可对数据进行处理后再转发。

3. 通用开放策略服务协议（COPS）

策略控制是网络管理的一种变体。当配置请求通过信令协议而非管理协议到达时，每个网络节点负责应用某种策略来决定如何处理这些请求。该策略可以是本地的（特定于做出决策的节点），也可以适用于更广泛的域，决策可在每个节点做出，也可委托给集中式策略服务器。IETF 在 RFC 2753 中定义了策略控制框架，并在 RFC 2748 中定义了 COPS 协议，用于在客户端和服务器之间传递策略请求。

3.1 选择应用策略

当网络中为支持集成服务或 RSVP 进行资源预留时，这些资源将从通用可用性中移除，供特定数据流专用。这通常由请求节点决定，该节点了解传输数据的特性和所需的网络资源，因此会提出相应的预留请求。网络节点会收到许多此类请求，但资源有限，必须决定满足哪些请求、拒绝哪些请求。这些决策会考虑可用带宽、认证数据（请求是否来自有效邻居）和请求优先级等因素。在大型网络中，还需基于策略做出额外决策，以确定是否将宝贵资源用于源节点和目标节点特定应用之间的数据流。

策略决策不必在每个节点进行，只需在策略管理域的入口和出口处考虑请求即可。一旦请求进入某个域，域内节点可认为本地域策略已满足，并按请求预留资源。策略控制点可配置足够信息自行做出策略决策，对于简单策略这是可行的，但对于基于网络拓扑和参与者详细信息的复杂决策，可能需要咨询外部策略服务器。

3.2 COPS 协议

COPS 是一种客户端 - 服务器协议，一个 PEP 可与零个、一个或多个远程 PDP 保持 COPS 会话，多个 PEP 可存在于一个节点上，并与相同或不同的 PDP 会话。COPS 运行在 TCP 上，使用知名端口号 3288（0xCD8），服务器在此端口监听所有客户端的连接。同一节点上与相同 PDP 通信的多个 PEP 可共享 TCP 连接。每个 COPS 消息使用“Client Type”字段标识 PEP 类型，使用消息内的“Handle”对象标识 PEP 本身，以确保与服务器的交换清晰明确。

COPS 协议的通信过程如下：
1. 建立连接 ：客户端通过发送“Client - Open”消息与服务器开启 COPS 通信，若服务器愿意与客户端合作，会以“Client - Accept”消息响应；否则，使用“Client - Close”消息拒绝客户端，并给出原因代码，还可选择返回重定向 IP 地址和端口号。
2. 监控连接状态 ：使用“KeepAlive”消息监控 TCP 连接状态。PDP 在“Client - Accept”消息中发送定时器，PEP 根据该定时器随机变化发送“KeepAlive”消息。若服务器未收到“KeepAlive”消息，将宣布连接死亡；若收到，则立即回显给客户端，使客户端也能监控连接。若同一连接上有多个客户端类型活跃，只需使用“Client - Accept”消息中最小的定时器值进行一次“KeepAlive”交换。
3. 策略请求与响应 ：客户端可向服务器发出策略请求并接收决策，通过“Request”、“Decision”和“Report - Status”三种消息实现。“Report - Status”消息用于确认客户端已按服务器指示执行策略操作，这对服务器后续的策略决策很重要。
4. 状态同步 ：若服务器重置或 TCP 连接失败后重启，服务器会发送“Synchronize - State - Request”消息，客户端以一系列“Report - State”消息响应，最后发送“Synchronize - Complete”消息，告知服务器状态同步完成。
5. 释放资源通知 ：客户端完成策略请求相关活动后，发送“Delete - Request - State”消息通知服务器释放相关资源。

3.3 COPS 消息格式

所有 COPS 消息都以通用头开始，当前版本为版本 1。S 位用于表示当前消息是否由先前的 COPS 消息请求。Opcode 字段标识消息类型，Client Type 字段标识 PEP 类型，最后一个字段给出整个消息（包括头）的字节大小。

COPS 消息由对象组成，每个对象使用特定格式编码，Object Length 表示对象的字节长度（包括前三个字段），必须是 4 的倍数。Class Number 用于标识对象类型，Class Type 提供子限定。表 13.6 列出了 COPS 的 Class Numbers 及其含义。

以下是 COPS 消息操作码的详细信息：
| Opcode | Abbreviation | Message |
| ---- | ---- | ---- |
| 1 | REQ | Request |
| 2 | DEC | Decision |
| 3 | RPT | Report State |
| 4 | DRQ | Delete Request State |
| 5 | SSQ | Synchronize State Request |
| 6 | OPN | Client - Open |
| 7 | CAT | Client - Accept |
| 8 | CC | Client - Close |
| 9 | KA | KeepAlive |
| 10 | SSC | Synchronize Complete |

COPS 客户端类型的含义如下：
| Client Type | Meaning |
| ---- | ---- |
| 0x0001 – 0x3FFF | 保留用于 IETF 标准 |
| 1 | RFC 2749 中描述的 RSVP 策略客户端 |
| 2 | RFC 3317 中描述的 DiffServ 策略客户端 |
| 0x4000 – 0x7FFF | 保留用于私有实现，未被 IANA 跟踪，未在任何标准中定义 |
| 0x8000 – 0xFFFF | 保留供其他组织注册，由 IANA 跟踪 |
| 0x8001 – 0x8004 | IP Highway |
| 0x8005 | Fujitsu |
| 0x8006 – 0x8007 | HP OpenView |
| 0x8008 | PacketCable |

COPS 类编号及其含义：
| C - Num | Meaning |
| ---- | ---- |
| 1 | Handle。在 PEP 和 PDP 之间特定 TCP 连接的客户端类型上下文中唯一的自由格式标识符，用于标识策略状态以关联请求、决策、状态报告和删除操作。其内容由客户端实现决定，例如可以是控制块指针 |
| 2 | Context。指示客户端发出请求的原因。位标志表示是否有传入协议消息、准入控制请求、资源分配请求、发送消息请求或配置请求。有一个 16 位整数用于携带因果事件的消息类型 |
| 3 | In Interface。策略请求适用的传入接口。该对象携带接口索引和 IPv4 或 IPv6 地址 |
| 4 | Out Interface。策略请求适用的传出接口。该对象携带接口索引和 IPv4 或 IPv6 地址 |
| 5 | Reason code。删除请求消息中策略状态被删除的原因。RFC 2748 指定了一长串可能的原因和子原因，包括信令状态移除、管理干预、抢占、超时和路由更改。这些值由 IANA 管理 |
| 6 | Decision。从 PDP 返回的结果。此对象定义了五种 C - Types。C - Type 1 定义了决策消息中的一个必需对象，指示请求是否成功。该对象可在决策消息中重复，以呈现其他 C - Types，提供特定于客户端类型的策略、准入控制和信令协议信息 |
| 7 | LPDP Decision。能够访问本地策略决策点的 PEP 仍可能希望向远程 PDP 发送请求消息以进行关联或进一步检查。这允许在本地快速做出决策，并在后台进行验证。在这种情况下，PEP 以与 Decision 对象相同但 C - Num 不同的一组对象发送本地决策的详细信息 |
| 8 | Error。此对象用于传达 COPS 协议错误（即不是策略失败）。它在决策消息中用于拒绝格式错误或未知的请求消息，或在客户端关闭时用于其他错误 |
| 9 | Client - Specific Info。用于在客户端打开请求时提供有关客户端的额外信息。该信息可以指示客户端的命名配置，也可以特定于客户端类型 |
| 10 | KeepAlive Timer。服务器在客户端接受消息中通过此对象返回客户端要使用的 KeepAlive 定时器的值。这是一个 4 字节的对象，但前 2 字节保留。后 2 字节以秒为单位给出时间值，零表示无限（即不运行定时器） |
| 11 | PEP Identification。一个以空字符结尾的 ASCII 字符串，用于唯一地向 PDP 标识 PEP。通常使用点分十进制表示的 IPv4 地址。请注意，此对象必须使用尾随空字符填充为 4 字节的倍数，并且对象的长度包括这些空字符 |
| 12 | Report Type。用于报告状态消息中，指示决策是否成功实现。第三个值表示该消息是对同步状态请求的响应 |
| 13 | PDP Redirect Address。拒绝客户端打开请求的 PDP 可以在客户端关闭消息中包含此对象，以建议客户端使用不同的 IP 地址和/或端口号来成功打开连接。定义了该对象的 IPv4 和 IPv6 版本 |
| 14 | Last PDP Address。PEP 在客户端打开消息中使用此对象来指示它最后成功连接到的此客户端类型的 PDP 的地址和端口号。定义了该对象的 IPv4 和 IPv6 版本 |
| 15 | Accounting Timer。PDP 在客户端接受消息中以秒为单位指定的定时器。PEP 应在此时间间隔内生成主动报告状态消息序列（即无需等待接收同步状态请求）。如果定时器设置为零，PEP 不发送此类消息 |
| 16 | Message Integrity。如果 PEP 和 PDP 为其通信配置了消息认证，则在所有消息中使用此对象。该对象包含一个密钥标识符、一个为每个消息递增的序列号以防止重放攻击，以及一个由哈希算法对消息内容和密钥 ID 标识的密钥进行操作生成的消息摘要 |

COPS 请求消息的 BNF 表示如下：

<Request Message>::=
<Common Header> 
<Client Handle> 
<Context> 
[<IN-Int>] 
[<OUT-Int>] 
[<ClientSIs>] 
[<LPDPDecisions>] 
[<Integrity>] 
<ClientSIs>::=
<ClientSI> 
[<ClientSIs>] 
<LPDPDecisions>::=
<LPDPDecision> 
[<LPDPDecisions>] 
<LPDPDecision>::=
[<Context>] 
<LPDPDecision: Flags> 
[<LPDPDecision: Stateless Data>] 
[<LPDPDecision: Replacement Data>] 
[<LPDPDecision: ClientSI Data>] 
[<LPDPDecision: Named Data>]

综上所述，在网络管理中，选择合适的配置协议、合理收集统计信息以及有效应用策略控制协议（如 COPS）对于确保网络的高效运行和服务质量至关重要。不同的协议和方法各有优缺点，需要根据具体的网络环境和需求进行综合考虑和选择。

4. 配置协议选择的实际考量

在实际网络环境中选择配置协议时，除了上述对协议本身特性的分析，还需要考虑一些实际因素。
- 部署成本 ：SNMP 虽然成熟，但 MIB 模块的复杂性可能导致开发和维护成本较高。XML 易于开发，能降低一定的开发成本，但由于其可读性导致的冗长性，可能在传输和存储方面增加成本。CORBA 在大型服务提供商中应用广泛，但对于小型网络来说，部署和维护的成本可能过高。
- 兼容性 ：需要考虑所选协议与现有网络设备和系统的兼容性。例如，某些旧设备可能只支持 SNMP，而新的应用程序可能更倾向于使用 XML 进行数据交换。
- 安全性 ：SNMP 早期版本存在安全担忧，虽然可以通过一些措施来增强安全性，但在对安全要求较高的环境中，可能需要谨慎选择。XML 本身的安全性相对较弱，需要额外的安全机制来保障数据传输的安全。CORBA 则在一些大型企业网络中，通过其自身的安全机制提供了较好的安全性。

5. 统计信息收集的优化策略

为了更高效地收集网络统计信息，除了前面提到的方法，还可以采用以下优化策略：
- 智能采样 ：对于流量较大的网络，可以采用智能采样技术，只收集部分流量的统计信息，从而减少数据收集的开销。例如，可以按照一定的比例随机采样数据包，或者根据流量的特征进行选择性采样。
- 数据聚合 ：在中间收集点对统计信息进行进一步的聚合处理，减少传输到中央收集点的数据量。例如，可以将一段时间内的流量数据进行求和、平均等操作，只保留关键的统计指标。
- 自适应调整 ：根据网络的实时状态自适应调整统计信息收集的频率和范围。当网络流量较小时，可以降低收集频率；当网络出现异常时，增加收集的范围和频率，以便及时发现问题。

6. 策略控制的应用场景与挑战

策略控制在网络管理中有广泛的应用场景，但也面临一些挑战。
- 应用场景
- 服务质量保障 ：通过策略控制，可以为不同的服务分配不同的网络资源，确保关键服务的服务质量。例如，对于实时视频流服务，可以优先分配带宽，保证视频的流畅播放。
- 网络安全 ：策略控制可以用于实施访问控制策略，限制非法访问。例如，只允许特定的 IP 地址访问某些敏感资源。
- 资源优化 ：根据网络的实时负载情况，动态调整资源的分配，提高资源的利用率。例如，在网络空闲时，将闲置的资源分配给其他需要的服务。
- 挑战
- 策略冲突 ：当多个策略同时应用时，可能会出现策略冲突的情况。例如，一个策略要求限制某个用户的带宽，而另一个策略要求为该用户提供高带宽服务。解决策略冲突需要建立有效的冲突检测和解决机制。
- 策略更新 ：随着网络环境的变化，策略需要及时更新。但更新策略可能会影响网络的正常运行，因此需要谨慎操作，确保更新过程的平滑性。
- 策略管理复杂性 ：在大型网络中，策略的数量和复杂度可能会很高，管理和维护这些策略变得困难。需要采用有效的策略管理工具和方法，提高策略管理的效率。

7. 总结

网络管理是一个复杂的领域，涉及到配置协议的选择、统计信息的收集和策略控制等多个方面。在选择配置协议时，需要综合考虑协议的特性、部署成本、兼容性和安全性等因素。对于统计信息收集，应采用结构化的方式，结合多收集点和优化策略，以减少对网络的影响并提高收集效率。策略控制在保障服务质量、网络安全和资源优化等方面具有重要作用，但也面临着策略冲突、更新和管理复杂性等挑战。

通过合理选择和应用这些技术和方法，可以提高网络的可靠性、性能和安全性，满足不同用户的需求。在未来的网络发展中，随着网络规模的不断扩大和业务需求的不断增加，网络管理将面临更多的挑战和机遇，需要不断探索和创新，以适应新的发展趋势。

以下是一个简单的 mermaid 流程图，展示网络管理的主要流程：

graph LR
    A[选择配置协议] --> B[收集统计信息]
    B --> C[应用策略控制]
    C --> D{是否满足需求?}
    D -- 是 --> E[维持现状]
    D -- 否 --> A

这个流程图展示了网络管理的基本流程，从选择配置协议开始，然后收集统计信息，应用策略控制，最后根据是否满足需求决定是否需要重新选择配置协议。这个循环过程可以不断优化网络管理，以适应网络的变化和发展。