変更要約: 初版
5.3CoPP（Control Plane Policing）
CoPP は、装置自身の CPU（コントロールプレーン）宛てに上がるトラフィックを分類しレート制限することで、ルーティングプロトコルや管理アクセスを DoS や過剰な制御トラフィックから守る仕組みです。MQC（class-map／policy-map／service-policy）でクラス分けとレート設計を行い、control-plane に適用します。「なぜ ACL では CPU を守れないのか」「なぜ隣接が落ちたのか」を判断できるようにします。
ルータやスイッチの転送はハードウェア（データプレーン）で行われますが、OSPF の Hello、BGP の更新、ARP、ICMP、SNMP、SSH といった装置自身が処理すべきパケットはソフトウェア処理のために CPU へパント（punt）されます。攻撃者がこの経路に大量のパケットを流し込むと、CPU が飽和して隣接がタイムアウトし、経路が落ち、管理アクセスすらできなくなる——転送は無傷でもネットワークは崩壊します。インタフェースACLは通過するトラフィックを落とせても、装置宛てに正当に見えるパケットの量は制御できません。ここを守る専用の仕組みが CoPP です。
5.3.1コントロールプレーンを守る理由
- コントロールプレーン＝経路計算や隣接維持、装置管理を担う CPU 上の処理。ここへ到達するパケットは ASIC の高速転送を離れソフトウェアで1つずつ処理されるため、単位時間あたりの処理能力がデータプレーンより桁違いに小さい。少量の攻撃トラフィックでも装置を機能不全にできるのはこのためである。
- CoPP は
control-planeという仮想インタフェースにサービスポリシーを適用し、CPU へ向かうトラフィックをクラスごとにポリシングする。重要なのは「拒否」ではなくレート制限である点＝正当なプロトコルは通しつつ、異常な量だけを落とすことで、装置が最も忙しいとき（＝攻撃時）にも隣接と管理を生かすことを狙う。 - CoPP と混同されやすいものに CPPr（Control Plane Protection）（コントロールプレーンをさらに host/transit/CEF-exception のサブインタフェースに細分）や、
access-class（管理平面の到達制御）がある。面（データ／管理／コントロール）と道具の対応を取り違えないこと。
5.3.2MQC による構成手順
- 手順1：分類。ACL でトラフィック種別を定義し、
class-map match-all CM-ROUTINGなどで束ねる。実務ではルーティング（OSPF/BGP/EIGRP/HSRP）／管理（SSH・SNMP・NTP・syslog）／到達確認（ICMP）／未定義（残り）のように用途別のクラスに分ける。分類の粒度が粗いと、攻撃対象の ICMP と隣接維持の Hello が同じバケツに入り、まとめて落ちてしまう。 - 手順2：ポリシー定義。
policy-map PM-COPP配下で各クラスにpolice <bps> conform-action transmit exceed-action dropを割り当てる。ルーティングクラスは十分に余裕のあるレート（あるいは意図的にポリシングしない）とし、ICMP や未定義クラスは低いレートに絞る。class class-defaultは分類されなかった全てを受けるため、ここを厳しくしすぎると想定外のプロトコルが死ぬ。 - 手順3：適用と検証。
control-planeモードでservice-policy input PM-COPPを適用する（方向は input＝CPU へ入る向き）。検証はshow policy-map control-planeでクラスごとの conform/exceed バイト数とドロップ数を確認し、正当なトラフィックが exceed していないかを見る。導入時はexceed-action transmitでまず計測だけ行い、実測に基づいてレートを決めてから drop に切り替えるのが安全な進め方。
CoPP＝コントロールプレーン（CPU）宛てトラフィックをクラスごとにポリシングし、DoS や過剰な制御トラフィックから装置を守る、MQC の class-map→policy-map→control-plane へ service-policy input、検証は show policy-map control-plane が最頻出です。「ACL で CPU を守れるか」という問いには守れない（面が違う）、「レートを絞りすぎると何が起きるか」には隣接断——この2つの因果を即答できるようにしてください。
あなたは ICMP フラッドで CPU 使用率が 95% に達したコアルータを救うため、CoPP を導入しました。急いでいたので class-map match-all CM-ALL に permit ip any any の ACL を当て、policy-map PM-COPP で police 32000 conform-action transmit exceed-action drop の単一クラスを定義し、control-plane に service-policy input PM-COPP を適用しました。CPU 使用率は確かに下がりましたが、数十秒後にOSPF の隣接が全滅し、BGP セッションも落ち、SSH も不安定になりました。ここで「CoPP は危険だから外そう」と結論づけるのは誤りで、問題は分類設計にあります。単一クラスで全 CPU 宛てトラフィックを 32 kbps に押し込めば、攻撃 ICMP と同じバケツで OSPF Hello や BGP KEEPALIVE も exceed 判定を受け、隣接維持に不可欠なパケットがランダムに落ちる——結果、Dead Interval 経過で隣接が切れ経路が消えます。正しい設計は用途別クラスの分離です。CM-ROUTING（OSPF/BGP/EIGRP/HSRP）はポリシングしないか十分大きなレートにし、CM-MGMT（SSH/SNMP/NTP/syslog）は中程度、CM-ICMP を低レート、そして class-default は残余として極端に絞りすぎない値を置きます。診断の道具も決まっていて、show policy-map control-plane でどのクラスが exceed しているかを見れば、落ちているのが攻撃トラフィックなのか正当なプロトコルなのかが一目で分かります。もし CM-ROUTING の exceed が増えているなら、レートが実測に対して不足している証拠です。導入手順としても、いきなり exceed-action drop を当てるのではなくまず transmit で計測し、平常時の各クラスの実レートを把握してから 2〜3 倍程度の余裕を持たせて drop に切り替えるべきでした。CoPP は「守る仕組み」であると同時に「自分で自分を落とせる仕組み」でもあり、クラス設計とレート根拠こそが設計の中身です。
| クラス例 | 対象トラフィック | レート設計 | 絞りすぎたときの症状 |
|---|---|---|---|
| CM-ROUTING | OSPF・BGP・EIGRP・HSRP | ポリシングしないか十分大きく | 隣接断・経路消失・再収束の繰り返し |
| CM-MGMT | SSH・SNMP・NTP・syslog | 中程度（運用に必要な分） | 管理接続の切断・監視の欠測 |
| CM-ICMP | ping・到達確認 | 低レート | 疎通確認が断続的に失敗 |
| class-default | 未分類の残り全て | 低めだが極端に絞らない | 想定外プロトコル（ARP等）の障害 |
ひっかけ： 「インタフェースに ACL を当てれば CPU への攻撃も防げる」は誤りです——インタフェースACLは通過トラフィックの可否を決めるもので、装置宛てに上がる正当に見えるパケットの量は制御できません。守るのは CoPP（control-plane に service-policy input）です。また「CoPP は該当トラフィックを一律に拒否する仕組み」も誤り＝本質はクラスごとのポリシング（レート制限）であり、単一クラスで全部を絞ると隣接まで落ちる点が最大の罠です。
5.3.3この節のまとめ
- CoPP は CPU へパントされるコントロールプレーン宛てトラフィックをポリシングし、DoS や過剰な制御トラフィックから隣接と管理を守る（インタフェースACLでは代替できない）
- 構成は MQC：ACL で分類→
class-map→policy-mapでpolice→control-planeにservice-policy input。用途別（ルーティング／管理／ICMP／class-default）にクラスを分けてレートを設計する - 単一クラスで一律に絞ると隣接断を招く。導入は
exceed-action transmitで計測してからレート決定し、show policy-map control-planeの conform/exceed で正当トラフィックの巻き添えを検証する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ICMPフラッドでCPUが飽和したコアルータに、`permit ip any any` を条件とする単一クラスで `police 32000 exceed-action drop` を定義し `control-plane` に適用した。CPU使用率は下がったが、直後にOSPF隣接とBGPセッションが全滅した。原因と是正として最も適切なものはどれか。
Q2. セキュリティ設計のレビューで「境界ルータの外側インタフェースに厳格な拡張ACLを `in` で適用済みなので、コントロールプレーンへのDoSは十分に防げている」と主張された。この主張への指摘として最も適切なものはどれか。
Q3. CoPPポリシー適用後、運用チームから「SNMPポーリングの欠測とSSHの切断が散発する」と報告された。攻撃は観測されていない。次に行う確認と対処として最も適切なものはどれか。