Catalyst 6500/Sup2T および Catalyst 6880 上のデフォルトのコントロール プレーン ポリシーの設定例
概要
このドキュメントでは、デフォルトのクラス マップと一致するトラフィックのタイプについて詳しく説明します。このクラス マップは、デバイス上で自動的に構成される Catalyst 6500 Sup2T/Catalyst 6880 CoPP（コントロール プレーン ポリシング）設定の一部です。これは、過負荷から CPU を保護するように設定されます。
前提条件
要件
このドキュメントに特有の要件はありません。
使用するコンポーネント
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
設定
CoPP は、Catalyst 6500/SUP2T および Catalyst 6880 スイッチではデフォルトで有効になり、事前に設定されているテンプレートに基づきます。一部の class-map の設定には、対応する一致ステートメントがありません。これは、トラフィックが MAC/IP アクセス コントロール リスト（ACL）でキャプチャされるのではなく、トラフィックがスイッチによって受信されて転送を決定されるときにフォワーディング エンジンによって通知される内部例外でキャプチャされるためです。
特定の class-map を現在の CoPP ポリシーから追加、変更、削除する必要がある場合は、policy-map モードのコンフィギュレーション モードから行う必要があります。正確な構文については、『Catalyst 6500 リリース 15.0SY ソフトウェア構成ガイド - コントロール プレーン ポリシング（CoPP）』を参照してください。
CoPP のデフォルトの例外クラスの説明を次に示します。
| 大文字と小文字を区別する | class-map 名前 | 説明 |
|---|---|---|
| 最大伝送ユニット（MTU）障害 | class-copp-mtu-fail |
パケット サイズが発信インターフェイスの MTU サイズを超えています。 フラグメント禁止ビットが設定されていない場合、フラグメンテーションが必要です。 フラグメント禁止ビットが設定されている場合、「fragmentation needed and DF set」という Internet Control Message Protocol（ICMP）接続先到達不能メッセージが生成され、送信元に返送されると考えられます。 参考資料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 |
| Options | class-copp-options | オプションを含むパケット（IPv4 の場合）、ホップバイホップ拡張ヘッダーを含むパケット（IPv6 の場合）。 たとえば、ルータ アラート RFC-2113、厳密な送信元ルートなど。 IPv6 ヘッダーの宛先アドレス フィールドで示されているノード（または、マルチキャストの場合はノード セットの各ノード）にパケットが到達するまで、拡張ヘッダーはパケットの配信パスに沿ったどのノードでも検査または処理されません。唯一の例外はホップバイホップ オプション ヘッダーであり、これはパケットの配信パスに沿ったすべてのノードで検査および処理する必要がある情報を伝達します。これには、送信元ノードと宛先ノードが含まれます。オプション フィールドのハードウェア処理はサポートされません。つまり、ソフトウェアによる処理とスイッチングが必要です。 参考資料RFC-791、RFC-2460 |
| リバース パス フォワーディング（RPF）障害（ユニキャスト） | class-copp-ucast-rpf-fail | RPF 失敗パケットのチェックがフィルタ処理されます。ただし、ハードウェアの制限されたリソースのため、特定のケース（つまり、16 個より多くの RPF インターフェイスが 1 つの IP アドレスにリンクされている）では、RPF チェックをハードウェアでは実行できません。 その場合、パケットは完全な RPF チェックのためにソフトウェアに送られます。 最初の RPF 失敗データ パケット（マルチキャスト グループ宛）は、PIM（Protocol Independent Multicast）アサート プロセスを開始するためにソフトウェアに送られます。処理が完了すると、代表ルータおよびフォワーダが選択されます。次のパケット（同じフロー）が代表ルータから送信されたものではない場合は、RPF 障害がトリガーされ、ハードウェアはそれを直ちにドロップできます（サービス妨害（DoS）攻撃を防ぐため）。 |
RPF 障害 （マルチキャスト） |
class-copp-mcast-rpf-fail | 最初の RPF 失敗データ パケット（マルチキャスト グループ宛）は、PIM アサート プロセスを開始するためにソフトウェアに送られます。処理が完了すると、代表ルータおよびフォワーダが選択されます。次のパケット（同じフロー）が代表ルータから送信されたものではない場合は、RPF 障害がトリガーされ、ハードウェアはそれを直ちにドロップできます（DoS 攻撃を防ぐため）。 ただし、ルーティング テーブルが更新された場合、新しい代表ルータの選択が必要になる場合があります（PIM アサートにより）。つまり、RPF 失敗パケットがソフトウェアに到達する必要があります（PIM アサートが再び開始するため）。 そのためには、RPF 失敗パケットに関する（フローごとの）ソフトウェア メカニズムに対する定期的なリークを、ハードウェアで使用できます。フローの量が多い場合、定期的リークが多すぎてソフトウェアでは処理できない可能性があることに注意してください。それでも、ハードウェア CoPP はマルチキャスト RPF 失敗パケットのために必要です。 参考資料RFC-3704、RFC-2362 |
| ハードウェアによるパケットの書き換えがサポートされていない | class-copp-unsupp-rewrite | ハードウェアはさまざまなケースでパケットを書き換えることができますが、一部のケースは現在のハードウェア設計では実行できません。その場合、ハードウェアはソフトウェアにパケットを送信します。 |
ICMP no-route ICMP acl-drop ICMP redirect（ICMP リダイレクト） |
class-copp-icmp-redirect-unreachable | ICMP メッセージ生成のため、パケットがソフトウェアに送信されました。そのような ICMP リダイレクトで、ICMP の宛先が到達不能です（たとえば、ホストが到達不能または管理において禁止）。 参考資料RFC-792、RFC-2463 |
| シスコ エクスプレス フォワーディング（CEF）受信（宛先 IP アドレスがルータの IP アドレスである） | class-copp-receive |
パケットの宛先 IP アドレスがルータの IP アドレスの 1 つである場合（CEF の受信隣接関係にヒットします）、ソフトウェアがコンテンツを処理する必要があります。 |
| CEF 収集（宛先 IP アドレスがルータのネットワークの 1 つに属している） | class-copp-glean |
パケットの宛先 IP アドレスがルータのネットワークの 1 つに属しているが、それを解決できない場合（つまり、転送情報ベース（FIB）のテーブルでヒットしない）、CEF 収集隣接関係にヒットし、ソフトウェアに送信されて解決手順が開始されます。 IPv4 では、アドレスが解決されるまで、同じフローが CEF 収集にヒットし続けます。IPv6 では、宛先 IP アドレスと一致する（そして、代わりにドロップ隣接関係をポイントする）一時的な FIB エントリが、解決の間にインストールされます。指定された期間内に解決できない場合、FIB エントリは削除されます（つまり、同じフローが再び CEF 収集のヒットを始めます）。 |
| マルチキャスト 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 | Internetwork Packet Exchange（IPX）などの非 IP プロトコルは、ハードウェアでスイッチされません。これらはソフトウェアに送信されて、そこで転送されます。 |
| 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 | ハードウェアには、ACL リダイレクトを使用してソフトウェアによって設定される 8 つの ACL 関連例外があります。この例外は、Ternary Content Addressable Memory（TCAM）関連の理由により ACL から CPU にブリッジされるユニキャスト パケットに関係があります。 |
パケットをブリッジするための出力 ACL リダイレクト |
class-copp-ucast-egress-acl-bridged | ハードウェアには、ACL リダイレクトを使用してソフトウェアによって設定される 8 つの ACL 関連例外があります。この例外は、Ternary Content Addressable Memory（TCAM）関連の理由により ACL から CPU にブリッジされるユニキャスト パケットに関係があります。 |
パケットを CPU にブリッジするためのマルチキャスト ACL リダイレクト |
class-copp-mcast-acl-bridged | ハードウェアには、ACL リダイレクトを使用してソフトウェアによって設定される 8 つの ACL 関連例外があります。この例外はマルチキャスト処理に関係があります。 |
| サーバ ロード バランシング処理のための CPU への ACL ブリッジ | class-copp-slb | ハードウェアには、ACL リダイレクトを使用してソフトウェアによって設定される 8 つの ACL 関連例外があります。この例外は、サーバ ロード バランシング（SLB）の決定のためのハードウェア リダイレクトに関係があります。 |
| ACL VACL ログ リダイレクト | class-copp-vacl-log | ハードウェアには、ACL リダイレクトを使用してソフトウェアによって設定される 8 つの ACL 関連例外があります。この例外は、VLAN アクセス コントロール リスト（VACL）による CPU への Cisco IOS?ロギングのためのパケット リダイレクションに関係があります。 |
| DHCP スヌーピング | class-copp-dhcp-snooping | DHCP でスヌープされたパケットは、DHCP 処理のために CPU にリダイレクトされます。 |
MAC ポリシー ベースの転送 |
class-copp-mac-pbf | このケースでは、ハードウェアがパケットを転送できないため、CPU でポリシー ベースの転送を行う必要があります。 |
| IP アドミッション ネットワーク アドミッション コントロール |
class-copp-ip-admission | ホストのウイルス対策クレデンシャルに基づいてネットワーク アクセスを提供するため、次のオプションのいずれかによるポスチャ検証があります:（1）L2 インターフェイスは LAN ポート IP（LPIP）を使用し、Address Resolution Protocol（ARP）パケットは CPU にリダイレクトされます。（2）L3 インターフェイスはゲートウェイ IP（GWIP）を使用します。 検証の後で認証があります（*）。 L2 インターフェイスの場合は WebAuth であり、HTTP パケットを遮断し、URL リダイレクションを実行する場合もあります（*）。 L3 インターフェイスの場合は、AuthProxy です。 |
| ダイナミック ARP インスペクション | class-copp-arp-snooping | ARPポイズニング(man-in-the-middle)攻撃を防ぐために、ダイナミックARPインスペクション(ダイナミックARPインスペクション(DAI)とも呼ばれる)は、ARP要求/応答をインターセプトし、次のいずれかに対してCPUで処理します。（1）ユーザ設定の ARP ACL（スタティックに設定されたホスト）、（2）信頼できるデータベースに保存された MAC アドレスから IP アドレスへのバインド（つまり、DHCP バインド）。 有効な ARP パケットのみが、ローカル ARP キャッシュの更新に使用されるか、または転送されます。 検証プロセスでは、ARP パケットの CPU 関与が必要です。つまり、DoS 攻撃を防止するにはハードウェアの CoPP が必要となります。 |
| WCCP のための CPU への ACL リダイレクト | class-copp-wccp | Web Cache Communication Protocol（WCCP）の転送判断のためにパケットおよびフローを CPU にリダイレクトする必要がある場合に使用されます。 |
Service Insertion Architecture（SIA）のための CPU への ACL リダイレクト |
class-copp-service-insertion | SIA の判断のためにパケットおよびフローを CPU にリダイレクトする必要がある場合に使用されます。 |
| IPv6 ネットワーク検出 | class-copp-nd | IPv6 ネットワーク検出パケットをさらに処理するために CPU にリダイレクトします。 参考資料RFC4861 |
確認
ここでは、設定が正常に機能しているかどうかを確認します。
いずれかの設定済み CoPP class-map でトラフィックが観察されたかどうかを確認するには、show policy-map control-plane コマンドを入力します。
トラブルシュート
現在、この設定に関する特定のトラブルシューティング情報はありません。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
04-Mar-2015 |
初版 |
フィードバック