スイッチ : Cisco Catalyst 6500 シリーズ スイッチ

Catalyst 6500/Sup2T および Catalyst 6880 設定例の既定のコントロール平らなポリシー

2015 年 11 月 26 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料はどのようなトラフィックがデバイスで自動的に設定されるデフォルト Catalyst 6500 Sup2T/Catalyst 6880 CoPP (コントロール プレーン ポリシング)設定の一部であるデフォルト クラスマップと一致するか詳しく記述します。 これはオーバーロードから CPU を保護するために設定されます。

Mariusz Kazmierski によって貢献される、Cisco TAC エンジニア。

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

設定

CoPP は Catalyst 6500/SUP2T でおよび Catalyst 6880 スイッチ デフォルトで有効に なり、前もって構成されたテンプレートに基づいています。 いくつかのクラスマップコンフィギュレーションに MAC/IP Access Control List (ACL)のトラフィックをないキャプチャ するが、むしろトラフィックが奪取 される スイッチおよび転送の決定によって受信されるときフォワーディングエンジンによって信号を送られる内部例外でありませんというファクトによる対応した マッチ ステートメントが。

仕様 class-map が CoPP 現在のポリシーから追加されることを/修正されることを/取除かれる必要がある場合 policy-map モードのコンフィギュレーションモードからする必要があります。 参照して下さい Catalyst 6500 リリース 15.0SY ソフトウェア コンフィギュレーション ガイド-正しい 構文のためのコントロール プレーン ポリシング(CoPP)

CoPP デフォルト例外クラスにこれらの説明があります:

ケースclass-map name説明
最大伝送ユニット (MTU)失敗

クラス copp MTU 故障する

パケットサイズは発信インターフェイス MTU サイズを超過します。

Don't Fragment ビットが設定 されない場合、フラグメンテーションが必要となります。

Don't Fragment ビットが設定 される場合、インターネット制御メッセージ プロトコル (ICMP) 宛先に到達不可能なメッセージは「フラグメンテーション必要とし、DF が」が設定 するためにソースに生成され、送返されるはずであることを示します。

参照: RFC-791、RFC-1191

Time To Live (TTL)失敗クラス copp TTL 故障する

パケット TTL = 1 (IPv4 のために)、ホップ制限 = 0 か 1 (IPv6 のために)

TTL はハードウェアで = 0 (IPv4 のために) TTL が 0 に減少されるとき前のホップがパケットを破棄するはずであると同時にすぐに廃棄することができます。

ホップ限界は = 0 (IPv6 のために)それが RFC-2460 で示されるので異なっていますと TTL = 0、「IPv4 とは違って、IPv6 ノードが最大 パケット ライフタイムを実施するように要求されないセクション 8.2。 それは IPv4 存続可能時間 フィールドが IPv6" のホップ制限と名前を変更された原因です。 これはホップ限界の着信 IPv6 パケットが = 0 まだ有効であり、ICMP メッセージが送返す必要があることを意味します。

参照: RFC-791、RFC-2460

オプションクラス copp オプション

オプションのパケット(IPv4 のために)、ホップバイホップ 拡張 ヘッダ(IPv6 のために)。

たとえば、ルータアラート RFC-2113、厳密なソース ルート、等。

拡張 ヘッダはパケットの配達パスに沿うあらゆるノードによってパケットが theIPv6 ヘッダの宛先 アドレス フィールドで識別されるノード(またはケース ofmulticast のノードのセットのそれぞれに)到着するまで、検査されませんし、処理されません。 唯一の例外は発信 および 着信ノードが含まれているパケットの配信パスに沿う各ノードによって検査され、処理する必要がある情報を伝えるホップバイホップ オプション ヘッダです。

Option フィールドで処理するハードウェアは、それですソフトウェア/切り替え処理です必要サポートされません。

参照: RFC-791/RFC-2460

予約パス転送(RPF)失敗(ユニキャスト)クラス copp ucast rpf 故障するパケット失敗 RPF チェックはフィルタ処理されたです。 ただし、ハードウェアの限られたリソースが原因で、RPF チェックはハードウェアである特定の場合することができません(すなわち、1 IP にリンクされる 16 以上の RPF インターフェイス)。 それが起こるとき、パケットは完全な RPF チェックのためのソフトウェアに送信 されます。

最初の RPF はデータパケット Protocol Independent Multicast (PIM)のためにソフトウェアに開始するために(マルチキャスト グループに当たる)送信 されます-アサートしますプロセスを失敗しました。 プロセスが実行されれば、代表ルータ/フォワーダは選ばれます。 次 の パケット(同じフロー)が代表ルータから来ない場合、RPF障害を引き起こし、ハードウェアはそれをすぐに廃棄できます(サービス拒絶 (DoS) 攻撃を防ぐため)。

RPF Failure

(マルチキャスト)
クラス copp mcast rpf 故障する

最初の RPF はデータパケット ソフトウェアに PIM アサート プロセスが開始することができるように(マルチキャスト グループに当たる)送信 されます失敗しました。 プロセスが実行されれば、代表ルータ/フォワーダは選ばれます。 次 の パケット(同じフロー)が代表ルータから来ない場合、RPF障害を引き起こし、ハードウェアはそれをすぐに廃棄できます(DoS攻撃を防ぐため)。

ただし、ルーティング テーブルが更新済なら、意味するソフトウェアに達する RPF は必要パケット失敗したことを新しい代表ルータは(PIM アサートによって)選択される必要があるかもしれません、(再度開始するべき PIM アサートのために)。 それを、定期的なリークは(フローごとに) RPF 失敗 された パケットのためのソフトウェアメカニズムにするためにハードウェアで利用できます。 莫大な量フローがそして定期的なリークあればしかし注は処理するべきソフトウェアのため、あまりである場合もあります。 マルチキャスト RPF パケットにまだハードウェア CoPP が失敗しました必要となります。

参照: RFC-3704、RFC-2362

サポートされないハードウェア パケットリライトクラス copp unsupp 書き換えハードウェアがさまざまなケースのパケットを書き換えることができる間、いくつかのケースは現在のハードウェアデザインですることができません。 そしてそれらのために、ハードウェアはソフトウェアにパケットを送信 します。

ICMP 非ルート

ICMP ACL ドロップする

ICMP リダイレクト
クラス copp icmp リダイレクト到達不能

パケットは ICMP メッセージの生成のためのソフトウェアに送信 しました。 ICMP リダイレクトのような、到達不能 ICMP 宛先(たとえば。 ホスト 到達不可能または管理上禁止される)。

参照: RFC-792/RFC-2463

Cisco Express Forwarding (CEF) レシーブ(宛先IP はルータの IP です)

クラス copp レシーブ

パケットの宛先IP がルータの IP アドレスの 1 つ(CEF レシーブ 隣接関係を見つけます)なら、ソフトウェアはコンテンツを処理するはずです。
CEF グリーニング(宛先IP はルータのネットワークの 1 に属します)

クラス copp グリーニング

パケットの宛先IP がルータのネットワークの 1 に属するが、解決されない(すなわち、転送情報ベース (FIB) 表のヒット無し)場合、CEF グリーニング隣接関係を、見つけま決定手順が開始するソフトウェアに送信 されます。

IPv4 に関しては、同じフローはアドレスが解決されるまで CEF グリーニングを見つけ続けます。 IPv6 に関しては、一致する一時 FIB 隣接関係を代りに廃棄するエントリ 宛先IP (およびポイント解決の間に)インストールされます。 それが指定 期間に解決することができない場合 FIB エントリは削除されます(すなわち、同じフローは CEF グリーニングを再度見つけ始めます)。
マルチキャストIP 224.0.0.0/4 に向かうパケット

クラス copp mcast IP コントロール

制御パケットはソフトウェアによって処理される必要があります。
 マルチキャストIP FF::/8 に向かうパケット class-copp-mcast-ipv6-control制御パケットはソフトウェアによって処理される必要があります。
 ソフトウェアにコピーされる必要があるマルチキャスト パケット クラス copp mcast COPY(ビット 0)場合によっては、マルチキャスト パケットは状態アップデートのためのソフトウェアにコピーされる必要があります(パケットは今でも同じ VLAN で繋がれるハードウェアです)。 たとえば、(*、G/m)稠密モード エントリのために見つけられて、二重 rpf SPT スイッチオーバ。
FIBテーブルのミスを得るマルチキャスト パケット

クラス copp mcast パント

宛先IP (マルチキャストIP)は FIBテーブルのミスです。 パケットはソフトウェアにパントされます。
直接接続されたソース(IPv4)

クラス copp IP 接続される

直接接続されたソースからマルチキャストトラフィックはマルチキャスト状態が作成することができるソフトウェアに送信 され、(ハードウェアにインストールされて)。
直接接続されたソース(IPv6)

class-copp-ipv6-connected

直接接続されたソースからマルチキャストトラフィックはマルチキャスト状態が作成することができるソフトウェアに送信 され、(ハードウェアにインストールされて)。
ブロードキャスト パケット

クラス copp ブロードキャスト

ブロードキャストパケットはソフトウェアに(たとえば、ブロードキャスト DMAC の IP/Non IP およびマルチキャストDMAC の IPユニキャスト)リークします。
ハードウェア スイッチングの点ではプロトコル未知数への(すなわち、によってサポートされていない)クラス copp 未知プロトコル非IPプロトコルは、等 Internetwork Packet Exchange (IPX)のような、切り替えられたハードウェアではないです。 それらはソフトウェアに送信 され、そこに転送されます。
PIM が無効であるルーテッドポートによって入って来マルチキャスト データトラフィックclass-copp-mcast-v4-data-on-routedPort(PIM が無効であるかところで)ルーテッドポートを通って入るマルチキャスト データトラフィックはソフトウェアにリークします。 ただし、ソフトウェアにそれらを送信 することは必要ではないです従って廃棄されます。
PIM が無効であるルーテッドポートによって入って来マルチキャスト データトラフィック

class-copp-mcast-v6-data-on-routedPort

(PIM が無効であるかところで)ルーテッドポートを通って入るマルチキャスト データトラフィックはソフトウェアにリークします。 ただし、ソフトウェアにそれらを送信 することは必要ではないです従って廃棄されます。

パケットを繋ぐ入力 ACL リダイレクト

クラス copp ucast 入力 ACL 繋がれる

ハードウェアに ACL リダイレクトによってソフトウェアによって設定 される 8 つの ACL関連例外があります。 この 1 つは Ternary Content Addressable Memory (TCAM)関連原因で ACL によって CPU に繋がれるユニキャスト パケットに関連しています。

パケットを繋ぐ出力 ACL リダイレクト

クラス copp ucast 出力 ACL 繋がれるハードウェアに ACL リダイレクトによってソフトウェアによって設定 される 8 つの ACL関連例外があります。 この 1 つは Ternary Content Addressable Memory (TCAM)関連原因で ACL によって CPU に繋がれるユニキャスト パケットに関連しています。

CPU へのブリッジパケットへの Mcast ACL リダイレクト

クラス copp mcast ACL 繋がれるハードウェアに ACL リダイレクトによってソフトウェアによって設定 される 8 つの ACL関連例外があります。 この 1 つは処理をマルチキャストするために関連しています。
Server Load Balancing 処理のための CPU への ACL ブリッジ クラスcopp slb

ハードウェアに ACL リダイレクトによってソフトウェアによって設定 される 8 つの ACL関連例外があります。 この 1 つは Server Load Balancing (SLB)デシジョンのためのハードウェア リダイレクトに関連しています。

ACL VACL ログ リダイレクトクラス copp VACL ログ

ハードウェアに ACL リダイレクトによってソフトウェアによって設定 される 8 つの ACL関連例外があります。 この 1 つは VLAN Access Control List (VACL) ACL に Cisco IOS のための CPU によってパケット リダイレクションに関連していますか。 目的の記録。

DHCP スヌーピングクラス copp dhcp スヌーピング

DHCP はパケット Dhcp処理のための CPU にリダイレクトされますスヌーピングしました

MAC ポリシーはフォワーディングを基づかせていました

クラス copp MACpbfポリシーによって基づくフォワーディングはパケットをこの場合転送するためにハードウェアが可能ではないので CPU でされるべきです。
 

IP 許可 ネットワーク アドミッション コントロール 

 クラス copp IP 許可 ホストのウイルス対策資格情報に基づいてネットワーク アクセスを提供するためにこれらのオプションの 1 つによってポスチャ 検証があります: (1) L2 インターフェイスはアドレス解決プロトコル (ARP)パケットが CPU にリダイレクトされるかところ、LAN ポート IP (LPIP)を(2) L3 インターフェイス使用しますゲートウェイ IP (GWIP)を使用します。 検証の後で、認証があります(*)。 L2 インターフェイスに関しては HTTP パケット途中受信を行い、また URL リダイレクションを行うかもしれないのは WebAuth です、(*)。 L3 インターフェイスに関しては、それは AuthProxy です。
ダイナミック ARP 検査クラス copp arp スヌーピング

ARP 中毒(マン イン ザ ミドル)攻撃を防ぐため、ダイナミック ARP 検査(別名ダイナミック ARP 検査(戴)) それがの 1 つに対して CPU でそれらをこれら代行受信し、次に処理するとき ARP要求/応答をによって検証します: (1)ユーザ設定 ARP ACL (静的に設定されたホストのために)、(2)信頼されたデータベース(すなわち、DHCP バインディング)で保存される IP アドレス バインディングへの MAC アドレス。 有効な ARPパケットだけローカル ARPキャッシュをアップデートするのに使用されているか、または転送されます。

検証プロセスは DoS攻撃を防ぐためハードウェア CoPP は必要であることを意味する ARPパケット CPU 介入を必要とします。

WCCP のための CPU への ACL リダイレクトクラスcopp wccpパケット/フローが Web Cache Communication Protocol (WCCP) 転送の決定のための CPU にリダイレクトされる必要があれば使用される。

サービス挿入 アーキテクチャ(SIA)のための CPU への ACL リダイレクト

クラス copp サービス挿入パケット/フローが SIA デシジョンのための CPU にリダイレクトされる必要があれば使用される。
IPv6 ネットワーク開発クラス copp nd

IPv6 ネットワーク開発 パケットを更に処理するために CPU にリダイレクトするため。

参照: RFC4861

確認

このセクションでは、設定が正常に機能していることを確認します。

CoPP 設定されたクラスマップの何れかで観察されたトラフィックがあったかどうか確認するために show policy-map コントロール・プレーン コマンドを入力して下さい。 

トラブルシューティング

現在のところ、この設定に関する特定のトラブルシューティング情報はありません。

関連情報


関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


Document ID: 118806