Instiq

CCNA Automation(Cisco・試験200-901) のナレッジマップ

CCNA Automation(Cisco・試験200-901) の主要概念 41 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(41)

  • NETCONF・RESTCONF・YANG

    YANGは機器の設定・状態をleaf/list/containerの階層で定義するデータモデリング言語。NETCONFはSSH上でXMLメッセージを使い、YANGモデルに基づく設定をcandidate/runningといったデータストア単位でトランザクション的に投入するプロトコル。RESTCONFはHTTP+JSON/XMLでYANGモデルへアクセスし、GET/POST/PUT/PATCH/DELETEをCRUD操作に対応させる、より馴染みやすいプロトコル。

    前提: CRUD操作JSON

  • HTTP

    Webブラウザとサーバー間でページやデータをやり取りする、暗号化されないアプリケーション層プロトコル(ポート80)。通信内容は平文で盗聴・改ざんの恐れがあるため、現在はTLSで保護されたHTTPSの利用が標準になっている。

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • Catalyst Center(旧DNA Center)

    Ciscoの企業ネットワーク向け一元管理コントローラ。機器の自動検出・一括プロビジョニング、SD-Accessのポリシー配布、アシュアランス(健全性の可視化)、REST APIによる自動化の起点を1つのダッシュボードに統合する。旧称DNA Center。

  • CRUD操作

    データやリソースに対する基本操作の頭文字。作成(Create)・読み取り(Read)・更新(Update)・削除(Delete)を指し、RESTful APIではそれぞれ一般にHTTPのPOST・GET・PUT(またはPATCH)・DELETEに対応する。

    前提: REST API(ネットワーク自動化)HTTP

  • Ansible(ネットワーク自動化)

    YAML形式のPlaybookに望ましい構成を宣言的に記述し、SSHやAPI経由でエージェント不要(エージェントレス)に多数のネットワーク機器へ一括適用する構成管理ツール。Pythonで書かれたモジュールが機種ごとの差異を吸収し、同じPlaybookを繰り返し実行しても結果が変わらない冪等性を重視する。

    前提: べき等性YAML

  • REST API(ネットワーク自動化)

    HTTPのメソッド(GET/POST/PUT/DELETE等)でリソースを操作する設計原則に基づくAPI。Catalyst Centerのようなコントローラへの問い合わせや設定変更をJSON形式のデータでやり取りでき、CLIへ1台ずつログインする代わりにスクリプトから多数の機器を一括操作できる。

    前提: Catalyst Center(旧DNA Center)HTTPJSON

  • Cisco SDK

    Ciscoの各プラットフォーム(Meraki・Catalyst Center・ACI等)のAPIを、生のHTTPリクエストを組み立てずにプログラミング言語から扱えるようにする開発者向けライブラリ群。認証やページネーション、エラー処理といった定型処理を吸収し、開発者はビジネスロジックに集中できる。

    前提: Catalyst Center(旧DNA Center)APIレート制限とページネーションHTTPMerakiとネットワーク管理システム

  • XML

    タグで階層構造を表すマークアップ言語。NETCONFのメッセージ形式として使われるほか、機器の構成をXML文書として表現する場面もある。JSONより冗長だが、スキーマ(XSD)による厳密な検証やコメントの記述ができる点が異なる。

    前提: NETCONF・RESTCONF・YANGJSON

  • ベアメタルとコンテナ(配備モデル)

    ベアメタルはハイパーバイザを介さず単一OSがハードウェアを専有する配備方式で、他ワークロードとの共有を前提としないため性能は最高(隔離という軸ではVM/コンテナと同列に比較しにくい)。仮想マシンは独自OSごとハイパーバイザで分離するため隔離が強いが重い。コンテナはホストOSのカーネルを共有しながらプロセスを隔離する中程度の隔離の軽量な方式で、起動が速く移植性も高い。用途に応じて隔離の強さ・軽さ・性能のトレードオフで選ぶ。

    前提: Azure Virtual Machines(VM)

  • DevNet Sandbox

    Ciscoが開発者向けに無料で提供する検証環境。実機を用意せずにMeraki・Catalyst Center・ACI等のAPIやNETCONF/RESTCONFを試せる常設・予約制の環境が公開されており、Code Exchange(サンプルコード共有)・Learning Labs(学習コンテンツ)・API docsと合わせてDevNetの中心的なリソース群を成す。

    前提: Catalyst Center(旧DNA Center)NETCONF・RESTCONF・YANGMerakiとネットワーク管理システム

  • 管理プレーン

    機器の設定・監視・ソフトウェア更新など、運用者が機器そのものを管理するための通信を扱う機能面。SSH/HTTPS/SNMP/NETCONF等がこのプレーンを通る。転送規則を決める制御プレーンや実際のパケット転送を行うデータプレーンとは役割が異なり、管理プレーンへの不正アクセスは機器全体の乗っ取りに直結するため、アクセスの制限が特に重要になる。

    前提: NETCONF・RESTCONF・YANGコントロールプレーンとデータプレーンSNMP

  • ユニットテストとシークレット管理

    ユニットテストは関数やクラスといった最小単位の処理を個別に検証するテストで、Pythonではunittestやpytestが使われ、CI/CDパイプラインに組み込んで変更ごとに自動実行する。シークレット管理はAPIキーやパスワードといった秘密情報をコードに平文で書き込まず、環境変数やvault(専用の秘密管理サービス)に外出しして扱う実践で、誤ってリポジトリへコミットしてしまう事故を防ぐ。

    前提: Basic認証・APIキー・BearerトークンCI/CD

  • Merakiとネットワーク管理システム

    Meraki(Cisco Meraki)はクラウドから一元管理できるCisco製ネットワーク機器群のブランドで、専用ダッシュボードから複数拠点の設定・監視をまとめて行える。ネットワーク管理システム(NMS)は、こうしたスイッチ・ルーター・APなどのネットワーク機器の状態監視・設定・障害検知を一元的に行うソフトウェアの総称。

  • CI/CD

    CI(継続的インテグレーション)はコード変更のたびに自動ビルド・自動テストを行い早期に不具合を検出する手法。CDには2つの意味があり、継続的デリバリーは本番リリースの直前まで(リリース可能な状態まで)を自動化し本番反映は手動承認を残す方式、継続的デプロイメントは本番反映まで全て自動化する方式を指す。

  • ロードバランサ(L4/L7)

    複数サーバへ負荷を分散する装置。L4ロードバランサはIPアドレスとポート番号までで振り分ける。L7ロードバランサはHTTPのURLパスやCookie等アプリケーション層の情報を解釈でき、パスベースの振り分けやCookieによるセッション維持(パーシステンス)を実現する。ヘルスチェックで異常サーバを自動的に振り分け対象から除外する。

    前提: HTTPポート番号

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: CI/CDJSON

  • Basic認証・APIキー・Bearerトークン

    API認証の代表的な3方式。Basic認証はユーザー名とパスワードをBase64エンコードしてヘッダに載せる簡易だが弱い方式。APIキーは発行された固定の鍵文字列をヘッダやクエリパラメータで送る方式。Bearerトークンは認証後に発行される一時的なトークン(OAuthのアクセストークン等)を「Authorization: Bearer」ヘッダで提示する方式で、有効期限を切れることでキー漏洩時の被害を抑えられる。

  • APIレート制限とページネーション

    APIレート制限は単位時間あたりのリクエスト数に上限を設け、超えると429エラーで拒否する仕組み。クライアントは制限に応じたリトライ(バックオフ)が必要になる。ページネーションは大量の結果を一度に返さず、1回の応答件数を制限してページ単位(またはトークン単位)で分割取得させる仕組みで、いずれもAPIを消費する側が意識すべき利用上の制約。

  • HTTPメソッドとHTTPステータスコード

    HTTPメソッドはリクエストの意図を表す(GET=取得・POST=作成・PUT=全体置換・PATCH=部分更新・DELETE=削除)。HTTPステータスコードは応答の結果を表す(2xx=成功・3xxリダイレクト・401=未認証・403=権限不足・404=不在・429=レート超過・5xx=サーバエラー)。API呼び出しのトラブルシューティングは、送ったメソッドと返ってきたステータスコードの組み合わせから原因を切り分ける。

    前提: HTTP

  • pyATSとCisco Modeling Labs(CML)

    pyATS(Python Automated Test System)はネットワーク機器の状態確認やテストシナリオの実行をPythonで自動化するCisco製のテストフレームワーク。Cisco Modeling Labs(CML)はルータ・スイッチ等の仮想インスタンスでネットワークトポロジをシミュレーションできる環境で、実機なしで構成変更や自動化スクリプトを事前検証するのに使う。

    前提: ネットワークトポロジ

  • Cisco Catalyst SD-WANとNSO

    Cisco Catalyst SD-WAN(旧Viptela)は拠点間のWAN接続を集中管理するコントローラベースのSD-WANソリューションで、Catalyst SD-WAN Manager(旧vManage)等のAPIから構成・監視を自動化する。NSO(Network Services Orchestrator)はマルチベンダ環境で、YANGサービスモデルとNETCONFを用いて複数機器への設定投入を宣言的に一括オーケストレーションするツール。

    前提: NETCONF・RESTCONF・YANG

  • unified diff

    2つのファイル(または同じファイルの変更前後)の差分を表す標準的なテキスト形式。変更前行を「-」、変更後行を「+」で示し、変更箇所の周辺行数を「@@」で始まるハンク見出しで示す。Gitのdiffやコードレビュー、設定変更のレビューで広く使われる。

    前提: コードレビュー(Pull Request)

  • Git

    もっとも普及している分散型バージョン管理ツール。各自が全履歴のコピーを手元に持つ。

    前提: バージョン管理システム(VCS)

  • Infrastructure as Code(IaC)

    インフラをコード(テンプレート)で宣言的に定義し、再現可能・バージョン管理可能にする考え方。手作業のドリフトを防ぎ、レビュー・自動化・複数環境の一貫構築を可能にする。AWS では CloudFormation・CDK が代表。

    前提: バージョン管理システム(VCS)

  • べき等性

    同じ操作を何度実行しても結果が変わらない性質。分散システムではネットワーク再送やリトライでリクエストが重複しやすく、べき等な設計(べき等キーの利用など)があれば重複配信されても安全に処理できる。

  • SNMP

    ネットワーク機器を監視・管理するプロトコル。マネージャがエージェントへ定期的に問い合わせるポーリング(GET)に加え、エージェントが事象発生時に自発的に通知するトラップを持つ。管理情報はMIB(OIDで識別)で構造化される。SNMPv3は認証と暗号化を備え、平文のコミュニティ名に依存する v1/v2c の弱点を解消する。

  • バージョン管理システム(VCS)

    ファイルの変更履歴を記録し、過去への巻き戻し・変更者や理由の追跡・共同作業を可能にする仕組み。

  • Azure Virtual Machines(VM)

    IaaSの仮想マシン。OSから上を自分で管理する最も自由度の高いコンピュート。

  • Dockerfile

    Dockerはコンテナを作成・実行するための代表的なプラットフォーム。Dockerfileはコンテナイメージの作り方を記述するテキストファイルで、FROM(ベースイメージ指定)・RUN(ビルド時コマンド実行)・COPY(ファイル配置)・CMD(起動時コマンド)・EXPOSE(公開ポート)等の命令を積み重ねてイメージを定義し、docker buildでイメージ化、docker runで実行する。

    前提: ベアメタルとコンテナ(配備モデル)

  • モデル駆動プログラマビリティ

    機器ごとに異なるCLIコマンドを個別に叩くのではなく、YANGのような共通のデータモデルを介して機器の構成・状態を統一的に操作する考え方。同じモデルであれば異機種・複数ベンダーの機器を同じコード・同じ処理で扱えるようになり、自動化のスケールを支える。

    前提: NETCONF・RESTCONF・YANG

  • OWASP

    Webアプリケーションのセキュリティ向上を目的とする非営利団体、およびその公開する指針群の総称。代表的な成果物であるOWASP Top 10は実際に多い脆弱性クラスを整理したリストで、2021年版ではA01アクセス制御の不備・A03インジェクション(SQLインジェクションやクロスサイトスクリプティング(XSS)を包含)等が上位に並ぶ(旧版で独立項目だったXSSはA03へ統合、CSRFは単独項目から外れた。以降も定期的に改訂される)。アプリ開発者が優先して対策すべき項目の指標として広く参照される。

    前提: クロスサイトリクエストフォージェリ(CSRF)

  • Python requestsライブラリ

    PythonからHTTPリクエストを送るための代表的なサードパーティ製ライブラリ(標準ライブラリではなくpip installが必要)。requests.get(url, headers=, auth=, params=)のように呼び出し、返り値のresp.status_codeで結果を確認し、resp.json()でレスポンスボディをPythonの辞書/リストへ変換して扱う。POST/PUTやTLS検証のverify=等も指定でき、ネットワーク機器やコントローラのREST APIをスクリプトから呼ぶ定番の手段。

    前提: HTTPJSON

  • ネットワークトポロジ

    ネットワーク機器やケーブルの接続形態。物理的な配線の形を示す物理トポロジ(スター型・バス型・リング型・メッシュ型等)と、データが実際にたどる経路を示す論理トポロジがある。現在の企業LANはスイッチを中心としたスター型の物理配線が主流。

  • Webhook

    リポジトリ/組織のイベント発生時に外部 URL へ HTTP 通知を送る仕組み。CI 連携・SIEM・チケット起票などの自動化に使う。

    前提: HTTP

  • コントロールプレーンとデータプレーン

    コントロールプレーンは経路計算やポリシー決定など転送規則を作る制御機能を、データプレーンは決定された規則に従いパケットを実際に転送する機能を指す。SDNはこの両者を分離しコントロールプレーンを集中管理することで、ネットワーク全体の柔軟な制御を可能にする。

  • ポート番号

    同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号(例:HTTP は 80、HTTPS は 443、SSH は 22)。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。

    前提: HTTP

  • ノースバウンドAPIとサウスバウンドAPI

    コントローラを基準にしたAPIの向きの呼び名。ノースバウンドAPIはコントローラが上位のアプリケーションや自動化ツールへ提供するインタフェース(例:REST API)で、サウスバウンドAPIはコントローラが配下の機器を制御するために使うインタフェース(例:NETCONF、OpenFlow)を指す。

    前提: NETCONF・RESTCONF・YANG

  • クロスサイトリクエストフォージェリ(CSRF)

    利用者が正規サイトにログイン中の状態を悪用し、罠サイト経由で利用者の意図しないリクエスト(送金・投稿等)を正規サイトへ送らせる攻撃手法。ワンタイムトークンの検証などで防止する。

  • コードレビュー(Pull Request)

    Pull Request 上で差分にコメントし、変更を承認/変更要求するプロセス。必須レビュー数や CODEOWNERS による必須レビュアー指定でマージ前の品質を担保する。

  • MACアドレス

    データリンク層でネットワークインタフェースを一意に識別する48ビットの物理アドレスで、上位24ビットのOUI(製造者識別子)と下位24ビットの製造者内シリアル番号から成る。IPアドレスのように経路によって変化せず機器に固定されている点が特徴で、同一データリンク(L2セグメント)内でのフレーム転送先の特定に用いられる。

    前提: ネットワークトポロジ