Catalyst 6500/Sup2T和Catalyst 6880上的預設控制平面策略配置示例
簡介
本檔案將詳細介紹根據預設類別對應哪些流量型別，預設類別對應是裝置上自動設定的預設Catalyst 6500 Sup2T/Catalyst 6880 CoPP（控制平面管制）組態的一部分。這是為保護其CPU不超載而配置的。
必要條件
需求
本文件沒有特定需求。
採用元件
本文件所述內容不限於特定軟體和硬體版本。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。
設定
Catalyst 6500/SUP2T和Catalyst 6880交換機預設啟用CoPP，並基於預配置的模板。某些類別對映配置沒有相應的匹配語句，因為它們捕獲的流量不在MAC/IP訪問控制清單(ACL)中，而是轉發引擎在交換機接收流量和做出轉發決策時發出訊號通知的內部異常。
如果需要從當前CoPP策略中新增/修改/刪除特定類對映，則必須在策略對映模式下從配置模式中執行該對映。有關確切語法，請參閱Catalyst 6500版本15.0SY軟體配置指南 — 控制平面策略(CoPP)。
CoPP預設異常類具有以下說明：
| 案例 | class-map name | 說明 |
|---|---|---|
| 最大傳輸單元(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中的跳數限制。 這表示傳入Hop Limit = 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故障 (多點傳播) |
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 |
| Cisco Express Forwarding(CEF)receive（目的地IP是路由器的IP） | class-copp-receive |
如果資料包的目的IP是路由器的IP地址之一（將命中CEF接收鄰接），則軟體應該處理該內容。 |
| CEF glean（目的IP屬於路由器網路之一） | class-copp-glean |
如果資料包的目的IP屬於路由器的某個網路，但是未解析它(即，在轉發資訊庫(FIB)表中未命中)，它將命中CEF鄰接關係，被傳送到將開始解析過程的軟體。 對於IPv4，相同流量繼續觸發CEF收集，直到地址解析。對於IPv6，在解析期間會安裝與目標IP匹配的臨時FIB條目（並改為指向丟棄鄰接關係）。如果在指定的持續時間中無法解析它，則會刪除FIB條目（即，相同流開始再次命中CEF glean）。 |
| 發往組播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重定向設定。此封包是關於三元內容可定址記憶體(TCAM)相關原因的ACL橋接到CPU的單點傳播封包。 |
輸出ACL重新導向以橋接封包 |
class-copp-ucast-egress-acl-bridged | 硬體有8個與ACL相關的異常，由軟體通過ACL重定向設定。此封包是關於三元內容可定址記憶體(TCAM)相關原因的ACL橋接到CPU的單點傳播封包。 |
強制轉換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重定向設定。此問題與Cisco IOS的VLAN存取控制清單(VACL)ACL到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)。 驗證後，進行驗證(*)。 第2層介面選擇了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以作出網路快取通訊協定(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 |
初始版本 |
意見