Cisco 200-301: IPサービス、NAT、サービス品質 — 学習ガイド

By Laurynas Brazys · 14 August 2026 · #cisco #200-301 #certification #exam-prep #study-guide

こちらの一部です： Cisco CCNA 200-301 — 学習ガイド. 検証済みの解答で練習： Cisco試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

概要

IPサービスは、ネットワークを相互に接続し、負荷がかかった状態でもネットワークを観測可能、到達可能、かつ予測可能に保ちます。このセクションでは、コアサービスの提供 (DHCP, DNS, NTP)、可視性とシグナリング (SNMP, syslog, NetFlow, テレメトリ)、アドレス変換 (NAT)、トラフィックハンドリング (QoS) を取り上げ、さらにファーストホップ冗長化と運用上の検証に結びつけます。設計上の選択では、決定論的な動作、最小権限、障害発生時のグレースフルな機能低下を重視します。

コアIPサービス: DHCP、DNS、NTP

DHCP

• コンポーネントとフロー: クライアントはDORA (Discover, Offer, Request, Acknowledgment) を使用します。サーバープール (スコープ) は、アドレス範囲、マスク、ゲートウェイ (Option 3)、DNS (Option 6)、タイマー、ベンダーオプション (例: IP電話用のTFTPを指定するOption 150) を定義します。
• リレー: サーバーがクライアントのサブネット上にない場合、レイヤー3インターフェイスが ip helper-address を使用してブロードキャストを中継し、リクエストをサーバーにユニキャストします。DHCPスヌーピングはOption 82 (circuit-id/remote-id) を挿入し、サーバーがロケーションを意識した決定を下せるようにします。
• スコープと除外: 予想されるクライアント数に加えて成長分を考慮した、ちょうどよい大きさのプールを構築します。静的アドレスは、MAC予約によって確保するか、ip dhcp excluded-address で動的割り当てから除外します。
• リース: アドレスの変動 (churn) と再利用のバランスを取ります。短いリースは解放を早めますが、DHCPトラフィックを増加させます。
• 一般的な障害モード:
  • リレーの helper-address がない、または間違っている。あるいはACLがUDP 67/68をブロックしている。
  • 一致するスコープがない、プールが枯渇している、またはサブネットが重複している。
  • デフォルトゲートウェイのオプションが不正で、起動後の到達可能性に障害が発生する。
  • DHCPスヌーピングの信頼設定が間違っており、サーバーからの応答が破棄される。

• 便利なコマンド:

undefined

undefined

• 最小限のリレー設定例:

undefined

DNS

• 名前解決フロー: スタブリゾルバはホストのキャッシュとhostsファイルをチェックし、次に再帰リゾルバに問い合わせます。再帰サーバーは、ルート、TLD、権威サーバーに繰り返し問い合わせ、TTLに従って応答をキャッシュし、回答を返します。障害にはNXDOMAIN (名前が存在しない) やSERVFAIL (解決に問題あり) があります。
• 設計ガイダンス: 冗長化された再帰リゾルバを使用し、局所性と可用性のためにエニーキャストを優先します。TTLを調整して、俊敏性とキャッシュ効率のバランスを取ります。機密性の高いセグメントにはDNSの許可リストを適用します。
• 一般的な障害モード:
  • UDP/TCP 53がブロックされている、または非対称である。EDNSの処理が壊れている、またはMTU/フラグメンテーションの問題がある。
  • 検索ドメインの設定が間違っており、不正なFQDN解決を引き起こす。
  • 古い/汚染されたキャッシュ。DNSSECの検証失敗。
• デバイスの基本設定:

undefined

NTP

• 時刻同期により、相関分析 (ログ、フロー、セキュリティ) や、正確な遅延/ジッター測定が可能になります。階層はstratum値を使用します (1は参照クロックに直接接続、16は非同期)。
• クライアント、サーバー、ピアは安定した時刻ツリーを形成します。スプーフィングを防ぐために、キーを使用してNTPを認証します。
• IP SLAとジッター: 一方向遅延の測定や、ノード間で有効なジッター計算を保証するためには、(NTPなどによる) 正確な時刻同期が必要です。
• 一般的な障害モード: サーバーへの到達不能、非対称なパス/スキュー、夏時間/タイムゾーンの混乱、または認証されていないサーバーを誤って受け入れてしまう。

• 便利なコマンド:

undefined

undefined

可視性と制御: SNMP、Syslog、NetFlow、テレメトリ

SNMP

• バージョン: v2c (コミュニティベース) vs v3 (認証/プライバシー)。完全性と機密性のために、authPrivを指定したv3を推奨します。
• ポーリング vs トラップ/インフォーム: 定期的なメトリクスにはポーリングを使用し、状態変化時にはトラップ/インフォームを送信します。インフォームは確認応答により信頼性を確保します。
• セキュリティとスケール: ACLでマネージャーを制限し、トラップをレートリミットし、負荷の高いOIDを最小限に抑え、public/communityのデフォルト値を避けます。

Syslog

• レベル: 0 emergency, 1 alert, 2 critical, 3 error, 4 warning, 5 notice, 6 informational, 7 debugging。
• タイムスタンプとシーケンス番号を有効にし、冗長化されたコレクターに送信します。ノイズを避けるために、機能ごとにファシリティ/レベルを設定します。

• 設定例:

undefined

NetFlow

• 通信のメタデータ (5タプル、カウンター、タイムスタンプ) をキャプチャします。v5は固定形式ですが、v9/IPFIXはテンプレートベースで拡張可能です。
• 設計: 少なくとも2つのコレクターにエクスポートし、CPU負荷を軽減するために必要に応じてサンプリングします。正確な分析のために時刻同期 (NTP) を保証します。

• 典型的な設定例:

undefined

モデル駆動型テレメトリ

• 選択されたYANGモデルのデータを、効率的なトランスポート (例: gRPC) を介してプッシュベースでストリーミングします。利点: SNMPの定期的なポーリングよりも低遅延、予測可能なCPU使用率、優れたスケーラビリティ。
• トレードオフ: モデルを理解するコレクターが必要です。ストリーム自体のトランスポートセキュリティとQoSも考慮する必要があります。

一般的な障害モードと緩和策

• 過剰なロギングやポーリングによるCPUスパイク: レベルの調整、バッチ処理、またはサンプリングを行います。
• 時刻のずれ: NTPを修正し、イベントの順序の乱れや不正確なフローの結合を防ぎます。
• ファイアウォール/ACLによる管理プレーンのブロック: 専用のOOB管理またはVRF、およびコントロールプレーンポリシングを導入します。

NATとアドレス変換

概念

• 用語:
  • Inside local: 元のプライベートアドレス。
  • Inside global: 外部から見える変換後のアドレス。
  • Outside local/global: 内部/外部から見た外部ホストのアドレス。
• タイプ:
  • スタティックNAT: 1対1の固定マッピング。安定したインバウンド到達性を実現。
  • ダイナミックNAT: プールを介した多対多。変換が割り当てられるまでアウトバウンドのみ。
  • PAT (オーバーロード): TCP/UDPポートを使用した多対1または多対少数。インターネットへのegressで最も一般的。

設計上の考慮事項とトレードオフ

• インバウンドアクセスが必要なサーバーにはスタティックNAT、クライアントにはパブリックIPを節約するためにPATを使用。
• NATはエンドツーエンドの透過性を損なう。一部のプロトコル（FTP、SIPなど）はALGを必要とする。境界でアプリケーションを意識した設計を優先するか、変換に耐性のあるプロトコルを使用する。
• 高可用性: FHRPはデフォルトゲートウェイを移動させるが、NATの状態はデバイスごと。ステートフルNATがない場合、フェイルオーバーでフローがリセットされる。状態複製をサポートするHAファイアウォール/ルーターにNATを配置するか、egressを決定論的に制御する。

設定例

• WANインターフェースを使用したPAT:
  • access-list 1 permit 10.10.10.0 0.0.0.255
  • interface Gi0/0 ip address 203.0.113.2 255.255.255.252 ip nat outside
  • interface Gi0/1 ip address 10.10.10.1 255.255.255.0 ip nat inside
  • ip nat inside source list 1 interface Gi0/0 overload
• サーバー用のスタティックNAT:
  • ip nat inside source static 10.10.10.50 203.0.113.50

確認とトラブルシューティング

• show ip nat translations, show ip nat statistics
• clear ip nat translation *
• 一般的な問題: インターフェースでの inside/outside の欠落、プールへのルートがない、プールの重複、ACLの不一致、PATでのポート枯渇、複数の出口にまたがる非対称ルーティング、ヘアピンNATの要件が未対応。

QoSの基礎: 分類、マーキング、キューイング、輻輳処理

分類とマーキング

• ACL、IP precedence/DSCP、CoS、またはNBARで分類する。エッジでマーキングし、信頼できる範囲ではマーキングを維持する。
• DSCPとCoS:
  • 音声ベアラにはDSCP EF (46)、シグナリングにはCS3/AF31–AF33、インタラクティブビデオにはAF41–AF43/CS4を使用。
  • 802.1Qトランク上のCoS値は、L3境界でDSCPへのマッピングが必要。
• 信頼境界 (Trust Boundary):
  • 責任を負うことができるデバイス（例: Cisco IP phone）のみを信頼する。電話機が接続されたアクセスポートでは、デバイスベースの信頼を使用し、下流の優先度を維持する:
    • mls qos
    • interface Fa0/1 mls qos trust device cisco-phone mls qos trust cos switchport priority extend trust

キューイングと輻輳管理

• CBWFQ: 帯域保証による重み付けスケジューリング。
• LLQ: CBWFQに厳密優先キューを追加し、遅延に敏感なクラス（音声、インタラクティブビデオ）に対応。
• PQ: 純粋な厳密優先。ポリシングされない場合、他のトラフィックを枯渇させる可能性がある。LLQは設計上、優先トラフィックをポリシングするため、より好ましい。
• WRED: TCPグローバル同期を回避するための早期ランダムドロップ。優先キューには適用しない。

ポリシングとシェーピング

• ポリシング: 超過分をドロップ/再マーキングすることでレートを強制する。遅延は少ないが、損失とジッターが増加する。
• シェーピング: バーストをバッファリングして指定されたレートに合わせる。遅延は増加するが、下流でのドロップを削減する。階層型ポリシーの前に、低速なegressリンクでシェーピングを適用する。
• LLQポリシーの例:
  • class-map match-any VOICE match dscp ef
  • class-map match-any VIDEO match dscp af41 af42 af43 cs4
  • policy-map WAN-OUT class VOICE priority percent 10 class VIDEO bandwidth percent 20 class class-default fair-queue
  • interface Serial0/0/0 service-policy output WAN-OUT

音声とビデオの目標値

• 音声: 片道遅延 <150 ms、ジッター <30 ms、損失 <1%。ベアラにはLLQを使用し、シグナリングは別途保護する。
• ビデオ: インタラクティブビデオは帯域とジッターの制御が必要。ストリーミングは損失耐性が高いが、帯域を大量に消費する。個別のキューとアドミッションコントロールを検討する。

検証と測定

• IP SLAを使用して合成RTP/UDPを生成し、遅延、ジッター、損失を測定する。時刻の正確性のためにNTPを確保する。
• show policy-map interface を使用して、クラスごとのカウンタとドロップを確認する。

耐障害性：FHRPの影響と運用上の検証

FHRP

• HSRP/VRRPは、ファーストホップの障害を乗り越えるための仮想デフォルトゲートウェイを提供します。GLBPはゲートウェイのロードバランシングを追加します。
• 設計：コンバージェンスと安定性のバランスを考慮してタイマーを調整します。インターフェイスダウンだけでなく、アップストリーム/WANの損失時にもフェイルオーバーするためにオブジェクトトラッキングを使用します。
• サービスへの影響：フェイルオーバー中、ARPのリフレッシュとリハッシュにより、短時間の中断が発生する可能性があります。パスの対称性や複製されたNATステートを持たないリアルタイムフローはリセットされることがあります。優先トラフィックについては、出力パスを一貫させることが重要です。

運用上の検証とトラブルシューティング

• DHCP：ヘルパーアドレスとプール使用率を確認します。DORAを観測するためにパケットキャプチャを実施し、DHCPスヌーピングテーブルをチェックします。
• DNS：nslookup/digで検証します。リゾルバの冗長性をチェックし、ファイアウォールルールとMTU/EDNSの動作を調査します。
• NAT：アクティブなフロー中の変換を検証します。内部ローカルアドレスとプールへのルートを確保し、外部からインバウンドの静的NATをテストします。
• NTP：stratumが同期され、オフセットが低いことを確認します。認証を要求します。
• QoS：trust設定を検証します。現実的な負荷のもとでservice-policyカウンターをチェックし、IP SLA音声テストを実行します。優先トラフィックにおけるポリサーによるドロップを監視します。
• 可視性：SNMPv3が機能し、トラップが配信されていることを確認します。syslogのタイムスタンプが正しいこと、NetFlowエクスポーターがコレクターと連携していること、テレメトリストリームが安定していることを確認します。

実践的な問題シナリオ

Acme Manufacturing社は、2つ目のISPを追加し、新しいルーターでPATを有効にした後、ブランチオフィスでIP電話の音声途切れや散発的なDHCP障害を経験しています。

1. FHRPによるルーティングとゲートウェイ可用性の安定化

• 2台のルーターにまたがるブランチVLANのSVIにHSRPを設定し、preemptとプライオリティを設定し、WANアップリンクをトラックします。
• 理論的根拠：仮想デフォルトゲートウェイは、エンドポイントからルーターのフェイルオーバーを隠蔽します。オブジェクトトラッキングは、アップストリームへの到達性を失ったルーターからゲートウェイを移動させます。

2. NAT動作の正常化と非対称な出力パスの防止

• HSRPのアクティブルーターにのみPATを配置します。スタンバイルーターがアクティブでない限りデフォルトルートをアドバタイズしないようにするか、PBRを実装して音声VLANの出力パスを単一のルーターに固定します。
• 理論的根拠：非対称な出力パスは、ステートフルPATやSIP/RTP用のALGを破壊します。一貫した出力パスは、変換と通話の安定性を維持します。

3. DHCPリレーの信頼性の修正

• 両方のSVIゲートウェイで、中央のDHCPサーバーへのip helper-addressを設定します。アップリンク方向へのDHCPスヌーピングのtrustと、アクセスポート方向へのuntrustを検証します。静的IP範囲を除外します。
• 理論的根拠：適切なリレーはDORAがサーバーに到達することを保証します。スヌーピングは、サーバーからの応答を許可しつつ、不正なサーバーを防ぎます。除外設定は競合を回避します。

4. 正確な時刻の確立と測定の有効化

• 両方のルーターに認証付きサーバーを使用するNTPクライアントを設定し、stratumを検証した後、本社コールマネージャーに向けたIP SLA udp-jitterオペレーションを設定します。
• 理論的根拠：正確な時刻は、片道遅延とジッター計算の基礎となります。IP SLAは、QoSが音声をサポートできることを検証します。

5. trust境界を持つエッジからWANへのQoSポリシーの実装

• Cisco IP電話が検出された場合にのみ、アクセスポートでCoSをtrustします。音声のDSCPをEFに、シグナリングをCS3にリマークします。音声に10%を割り当てるLLQ、ビデオ用の帯域幅、デフォルトのフェアキューを適用します。物理インターフェイスが契約レートより速い場合は、ポリシーを適用する前にプロバイダーのCIRに合わせてシェーピングします。
• 理論的根拠：適切なtrust設定は、ホストによる優先度の不当な引き上げを防ぎます。LLQは低遅延を保証します。シェーピングは、プロバイダーエッジでのダウンストリームのドロップを回避します。

6. 可視性の強化と管理プレーンセキュリティの厳格化

• NMSへのSNMPv3、タイムスタンプ付きの冗長コレクターへのsyslog、分析ツールへのNetFlow v9エクスポーターを有効にします。SNMPとロギングのためにコントロールプレーンポリシングを追加します。
• 理論的根拠：可観測性により、改善を確認し、リグレッションを発見できます。セキュアな管理は、テレメトリを維持しつつ、攻撃対象領域を削減します。

7. 検証、そして障害のシミュレーション

• テスト通話中にshow policy-map interfaceを使用して優先トラフィックカウンターが増加することを確認します。IP SLAのジッターのベースラインを観測します。tracerouteを実行し、HSRPの状態を強制的に変更してフェイルオーバーをテストします。
• 理論的根拠：負荷をかけた状態での運用検証は、設計意図を証明します。制御されたフェイルオーバーは、耐障害性を証明し、NATやコンバージェンスに関するエッジケースを明らかにします。

← 動的ルーティングとIP接続性 · すべてのドメイン · 無線LANの設計と運用 →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →