Catalyst 6500/Sup2T和Catalyst 6880上的默认控制平面策略配置示例
简介
本文详细描述哪些类型的流量与默认类映射相匹配，默认类映射是设备上自动配置的默认Catalyst 6500 Sup2T / Catalyst 6880 CoPP（控制平面策略）配置的一部分。这是为了保护其CPU不会过载而配置的。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。
配置
默认情况下，CoPP在Catalyst 6500/SUP2T和Catalyst 6880交换机上启用，并基于预配置的模板。某些类映射配置没有相应的匹配语句，因为它们捕获的流量不在MAC/IP访问控制列表(ACL)上，而是在交换机收到流量并做出转发决策时由转发引擎发出信号的内部异常上。
如果需要从当前CoPP策略添加/修改/删除特定类映射，则必须在策略映射模式下从配置模式完成。有关确切的语法，请参阅Catalyst 6500版本15.0SY软件配置指南 — 控制平面策略(CoPP)。
CoPP默认异常类具有以下说明：
| 案例 | 类映射名称 | 描述 |
|---|---|---|
| 最大传输单位(MTU)故障 | class-copp-mtu-fail |
数据包大小超过传出接口MTU大小。 如果未设置“不分段”位，则需要分段。 如果设置了“不分段”位，则互联网控制消息协议(ICMP)目标不可达消息表示应生成“需要分段并设置DF”，并将其发回源。 参考:RFC-791、RFC-1191 |
| 生存时间(TTL)故障 | class-copp-ttl-fail | 数据包TTL = 1（对于IPv4），跳数限制= 0或1（对于IPv6） TTL = 0（对于IPv4）可立即在硬件中丢弃，因为当TTL减为0时，上一跳应销毁数据包。 跳数限制= 0（对于IPv6）与TTL = 0不同，因为RFC-2460第8.2节中规定“与IPv4不同，IPv6节点无需实施最大数据包生存期。这就是IPv4生存时间字段在IPv6中重命名为跳数限制的原因。 这意味着，跳数限制= 0的传入IPv6数据包仍然有效，应该发回ICMP消息。 参考:RFC-791、RFC-2460 |
| 选项 | class-copp-options | 包含选项（用于IPv4）、逐跳扩展报头（用于IPv6）的数据包。 例如，路由器警报RFC-2113、严格源路由等。 扩展报头不会由沿数据包传送路径的任何节点检查或处理，直到数据包到达IPv6报头的Destination Address字段中标识的节点（或组播情况下的每组节点）。唯一的例外是逐跳选项报头，该报头传送信息，必须由数据包的传送路径（包括源节点和目的节点）上的每个节点检查和处理。不支持选项字段的硬件处理，即需要软件处理/交换。 参考:RFC-791/RFC-2460 |
| 反向路径转发(RPF)故障（单播） | class-copp-ucast-rpf-fail | RPF检查失败的数据包被过滤。但是，由于硬件中的资源有限，RPF检查在某些情况下无法在硬件中完成（即，16个以上RPF接口链接到一个IP）。 当发生这种情况时，数据包将发送到软件进行完整的RPF检查。 第一个RPF故障数据包（发往组播组）被发送到软件，以便协议独立组播(PIM)断言进程启动。完成该过程后，将选举出指定的路由器/转发器。如果下一个数据包（相同流）不来自指定路由器，则会触发RPF故障，硬件可立即丢弃该数据包(以防止拒绝服务(DoS)攻击)。 |
RPF Failure （组播） |
class-copp-mcast-rpf-fail | 第一个RPF故障数据包（发往组播组）被发送到软件，以便PIM断言过程启动。完成该过程后，将选举出指定的路由器/转发器。如果下一个数据包（相同流）不来自指定路由器，它会触发RPF故障，并且硬件可以立即将其丢弃（以防止DoS攻击）。 但是，如果路由表更新，则可能需要（通过PIM-assert）选择新的指定路由器，这意味着RPF故障数据包需要到达软件（以便PIM-assert重新启动）。 为此，硬件中提供了RPF故障数据包的软件机制（每流）定期泄漏。但请注意，如果有大量流，则软件可能无法处理定期泄漏。组播RPF失败数据包仍需硬件CoPP。 参考:RFC-3704、RFC-2362 |
| 不支持硬件数据包重写 | class-copp-unsupp-rewrite | 虽然硬件可以在各种情况下重写数据包，但在当前硬件设计中，某些情况是无法完成的。对于这些设备，硬件会将数据包发送到软件。 |
ICMP无路由 ICMP acl-drop ICMP重定向 |
class-copp-icmp-redirect-unreachable | 发送到软件以生成ICMP消息的数据包。例如ICMP重定向，ICMP目标无法到达(例如。主机无法访问或被管理性禁止)。 参考:RFC-792/RFC-2463 |
| 思科快速转发(CEF)接收（目的IP是路由器的IP） | class-copp-receive |
如果数据包的目的IP是路由器的IP地址之一（将达到CEF接收邻接），则软件应处理该内容。 |
| CEF glean（目的IP属于路由器的一个网络） | class-copp-glean |
如果数据包的目的IP属于路由器的网络之一，但未解析(即，转发信息库(FIB)表中未命中)，则它将命中CEFglean邻接关系，并被发送到将开始解析过程的软件。 对于IPv4，在地址解析之前，相同的流会继续到达CEFglean。对于IPv6，在解析期间会安装一个与目标IP匹配（并指向丢弃邻接关系）的临时FIB条目。如果无法在指定的持续时间内解决该问题，则删除FIB条目（即，同一流开始再次达到CEFglean）。 |
| 发往组播IP 224.0.0.0/4的数据包 | class-copp-mcast-ip-control |
控制数据包需要由软件处理。 |
| 发往组播IP FF的数据包：:/8 | class-copp-mcast-ipv6-control | 控制数据包需要由软件处理。 |
| 需要复制到软件的组播数据包 | class-copp-mcast-copy | 在某些情况下，需要将组播数据包复制到软件以进行状态更新（数据包仍在同一VLAN上桥接的硬件）。 例如，(*,G/m)命中密集模式条目，双rpf SPT切换。 |
| 组播数据包在FIB表中丢失 | class-copp-mcast-punt |
目的IP（组播IP）在FIB表中为缺失。数据包被传送到软件。 |
| 直连源(IPv4) | class-copp-ip-connected |
来自直连源的组播流量将发送到可以创建组播状态的软件（并安装在硬件中）。 |
| 直连源(IPv6) | class-copp-ipv6-connected |
来自直连源的组播流量将发送到可以创建组播状态的软件（并安装在硬件中）。 |
| 广播数据包 | class-copp-broadcast |
广播数据包（例如，带广播DMAC的IP/非IP和带组播DMAC的IP单播）会泄露给软件。 |
| 硬件交换方面未知的协议（即不受支持） | class-copp-unknown-protocol | 非IP协议(如网际分组交换(IPX)等)不会进行硬件交换。它们被发送到软件并转发到该软件。 |
| 组播数据流量通过禁用PIM的路由端口进入 | class-copp-mcast-v4-data-on-routedPort | 通过路由端口（禁用PIM）传入的组播数据流量会泄露给软件。但是，无需将它们发送到软件，因此它们会被丢弃。 |
| 组播数据流量通过禁用PIM的路由端口进入 | class-copp-mcast-v6-data-on-routedPort |
通过路由端口（禁用PIM）传入的组播数据流量会泄露给软件。但是，无需将它们发送到软件，因此它们会被丢弃。 |
入口ACL重定向以桥接数据包 |
class-copp-ucast-ingress-acl-bridged | 硬件有8个与ACL相关的异常，由软件通过ACL重定向设置。此数据包与ACL桥接到CPU的单播数据包有关，原因与三态内容可寻址存储器(TCAM)相关。 |
出口ACL重定向以桥接数据包 |
class-copp-ucast-egress-acl-bridged | 硬件有8个与ACL相关的异常，由软件通过ACL重定向设置。此数据包与ACL桥接到CPU的单播数据包有关，原因与三态内容可寻址存储器(TCAM)相关。 |
组播ACL重定向到将数据包桥接到CPU |
class-copp-mcast-acl-bridged | 硬件有8个与ACL相关的异常，由软件通过ACL重定向设置。这个涉及组播处理。 |
| ACL桥接到CPU，用于服务器负载均衡处理 | class-copp-slb | 硬件有8个与ACL相关的异常，由软件通过ACL重定向设置。本文涉及用于服务器负载均衡(SLB)决策的硬件重定向。 |
| ACL VACL日志重定向 | class-copp-vacl-log | 硬件有8个与ACL相关的异常，由软件通过ACL重定向设置。此ACL与VLAN访问控制列表(VACL)ACL到Cisco IOS的CPU的数据包重定向有关?记录目的。 |
| DHCP 监听 | class-copp-dhcp-snooping | DHCP监听的数据包被重定向到CPU进行DHCP处理 |
基于MAC策略的转发 |
class-copp-mac-pbf | 基于策略的转发在CPU中完成，因为在这种情况下硬件无法转发数据包。 |
| IP准入网络准入控制 |
class-copp-ip-admission | 为了根据主机的防病毒凭证提供网络访问，可通过以下选项之一进行状态验证：(1)L2接口将使用LAN端口IP(LPIP)，其中地址解析协议(ARP)数据包被重定向到CPU;(2)L3接口使用网关IP(GWIP)。 验证后，会出现身份验证(*)。 对于L2接口，它是WebAuth，它执行HTTP数据包拦截，并可能执行URL重定向(*)。 对于L3接口，它是AuthProxy。 |
| 动态 ARP 检查 | class-copp-arp-snooping | 为防止ARP中毒（中间人）攻击，动态ARP检测(也称为动态ARP检测(DAI))会通过拦截时验证ARP请求/响应，然后根据以下其中一项在CPU中处理它们：(1)用户配置的ARP ACL（用于静态配置的主机），(2)MAC地址到存储在受信任数据库中的IP地址绑定（即DHCP绑定）。 仅有有效的ARP数据包用于更新本地ARP缓存或转发出去。 验证过程需要ARP数据包CPU参与，这意味着需要硬件CoPP来防止DoS攻击。 |
| ACL重定向到WCCP的CPU | class-copp-wccp | 在需要将数据包/流重定向到CPU以进行Web缓存通信协议(WCCP)转发决策时使用。 |
ACL重定向到服务插入架构(SIA)的CPU |
class-copp-service-insertion | 在需要将数据包/流重定向到CPU以做出SIA决策时使用。 |
| IPv6网络发现 | class-copp-nd | 为了将IPv6网络发现数据包重定向到CPU以进一步处理。 参考:RFC4861 |
验证
使用本部分可确认配置能否正常运行。
要检查在任何已配置的CoPP类映射中是否观察到流量，请输入show policy-map control-plane命令。
故障排除
目前没有针对此配置的故障排除信息。
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
1.0 |
04-Mar-2015 |
初始版本 |
反馈