L2SWと在庫管理端末のLLDP情報はMIBへ保存される。運用管理サーバはそれを直接取得できる。一方、店舗ルータの管理はRT管理コントローラだけに許される。

問題

解説：ルータには管理経路の制約がある。運用管理サーバから直接SNMP取得するのではなく、許可されたコントローラが収集した結果をAPIで受け取る。

店舗の担当者が機器を構成図に従って接続する。機器自体は検品済みで、初期不良はない。作業後にLLDPからポート接続リストを自動作成する。

問題

解説：機器が動くかだけではなく、意図した機器同士が正しいポートで接続されているかを確認する。

L2SW01のIF2と端末011のIF1を直接接続していた。この間にLLDP有効の管理外スイッチL2SW-Xを挿入する。

管理サーバはL2SW01と端末011からMIBを取得する。L2SW-Xの管理IPは不明であり、Xからの直接取得は行わない。

問題

解説：LLDPは直接の隣接相手を通知するため、両側の既存機器からXが見える。一方、X自身のMIBを取得しないので、Xを自機器とする取得行は作れない。

管理サーバはSNMPで受信オクテット数を5分間隔で取得する。今回の値をXₜ、前回の値をXₜ₋₁とする。1オクテットは8ビットであり、この間にカウンタラップは発生していない。

問題

解説：累積値の差が5分間に受信したバイト数である。8倍してビット数に直し、5分＝300秒で割る。累積カウンタ値そのものを時間で割るのではない。

管理サーバはSNMPカウンタの差から、5分間の平均ビットレートを計算する。専用線には、平均値だけでは見えにくい短時間の輻輳が発生している。

問題

解説：短い時間だけ帯域を使い切っても、残りの時間の通信量が少なければ平均値は低くなる。5分平均が低いことは、その全期間に輻輳がなかったことを意味しない。

32ビットの累積カウンタは最大値に達した後、0へ戻る。前回値Xₜ₋₁から今回値Xₜまでの間に、カウンタラップがちょうど1回発生したことが分かっている。

問題

解説：32ビットカウンタの周期は2³²である。最大値2³²−1ではなく、一周分の2³²を今回値へ足す。補正後の増分はXₜ＋2³²−Xₜ₋₁となる。

複数のコントローラが、制御セグメントのL2SWを介して制御サーバへ測定データを常時送る。L2SWの1ポートだけをミラー対象にして、これらの通信をまとめて収集する。

問題

解説：すべての測定データの共通の宛先が制御サーバである。個別コントローラのポートでは、そのコントローラの通信しか取得できない。

社内のネットワーク機器、サーバ、PCはNTPサーバで時刻を補正する。syslogサーバには、各機器のアクセスログ、認証ログ、通信ログ、システムログを保存し、障害原因などを調べる。

問題

解説：一つの通信が複数装置に記録されたとき、時刻がずれていると前後関係を誤って読む可能性がある。目的は時計表示を合わせること自体ではなく、別装置の記録を同じ時系列に並べることである。

PCにはL3スイッチのDHCPサーバ機能がIPアドレスを割り当てる。FWの通信ログから、不正な通信の送信元IPアドレスと時刻が分かった。

問題

解説：動的割当てでは、現在の割当先と過去の割当先が同じとは限らない。不正通信が発生した時刻のリース情報と対応付ける必要がある。FWの記録だけでは、アドレスがどのPCに割り当てられていたかは確定しない。

監視サーバは1分ごとにICMPエコー要求を3パケット送る。5回連続で一つも応答を受信しない場合に障害を通知する。専用線の輻輳を検知するため、接続先のルータ10Z・11Zを監視対象へ加える案がある。

問題

解説：pingの応答有無だけでは、帯域の使われ方や廃棄の程度は分からない。また、無応答の原因は輻輳に限られない。検出したい状態と監視指標の対応を確認する必要がある。

管理サーバには、SNMPで得た通信量の時系列統計と、FW・プロキシサーバから転送された通信ログを保存している。

機械学習監視製品は、過去データの傾向や周期性から予測値を作り、新しい実測値との差を検知する。通信量統計だけでなく、保存済みの別データも対象にする。

問題

解説：原問の解答対象はログ量の異常な増減である。攻撃者の特定や個別攻撃の断定までを求めているわけではない。通信バイト数とログ量は異なる観測値として組み合わせる。

IKEv2では、まず暗号アルゴリズムなどを合意してIKE SAを確立する。その後、認証とデータ通信用の条件を交渉してChild SAを確立する。

問題

解説：IKE SAが成立しているかを先に確認する。その上でChild SAの状態を見ると、初期交渉とデータ通信用の交渉のどちらで失敗しているかを分けられる。

PCとSaaSはIPv4・IPv6の両方に対応する。PCはAとAAAAの応答を受信し、通常はIPv6を優先する。IPv6ネットワークだけが不通になっても、Webページを引き続き閲覧できる場合がある。

問題

解説：利用者から見たサービス継続は、IPv6経路が正常である証明にはならない。原問では、そのためIPv6のインターネット到達性と拠点のGUAを専用に監視する設計にしている。

拠点間のIPsecトンネルインタフェースに、BFDを設定する。MPLS VPNとインターネットの二つの経路を利用できる。

問題

解説：切替用の別経路があっても、障害を認識しなければ切り替えられない。BFDはこの構成でトンネルの転送可否を素早く判断するために使う。

店舗の在庫管理端末と本社の運用管理サーバは、ルータのブリッジポート間のL2 over IPトンネルで接続される。両端は同一ブロードキャストドメインである。

問題

解説：内部パケットは途中のL3ルータを経由せず、L2として運ばれる。外側のインターネット経路を構成するルータは、内側のtracerouteのホップとしては表示されない。

LBは障害のあるECサーバを振分け対象から除外する。監視方法には、ネットワークの到達性を見るL3、TCP接続を見るL4、サービスの応答を見るL7がある。

問題

解説：IP到達やTCP接続が成功しても、実際のEC処理が正常とは限らない。必要なサービスの応答を確認するL7監視で、振分け可否を判断する。

監視サーバはICMPによるping監視を実施している。プロキシの監視では、アプリケーションが待ち受けるTCPポートへの接続確認も追加する。

問題

解説：OSがICMPに応答していても、プロキシ処理が正常に動作しているとは限らない。監視対象を、装置の到達性とサービスの動作に分けて考える。

学校職員はAPとフロアL2SWの故障交換・設定復旧を行う。動画コンテンツサーバの保守も学校側で行う。ほかの基幹設備は保守業者が担当する。複数リンクを持つ構成のため、作業後のループ対策を検討する。

問題

解説：L2ループがあると、ブロードキャストフレームが循環・増殖する。配線の復旧だけでなく、リンク集約などの設定を正しく戻すことも必要である。

全600台のPCが朝の同じ時間帯にクラウドサービスへアクセスする。一部かつ不特定のPCではログイン画面が表示されず、タイムアウトする。ログインできたPCでも応答が遅い。校内動画サーバへのアクセスには不具合がない。

問題

解説：全員が遅いという観察と、一部の端末だけ新しい通信を開始できないという観察を分ける。後者は、接続時点で共有資源が足りない可能性を示す。本問では、後続のログでNAPT変換テーブル枯渇を確認している。

LBは配信サーバにHTTPアクセスして死活確認する。停止したサーバには新規アクセスを振り分けない。監視方法をICMP Echoへの応答確認に置き換える案がある。

問題

解説：IP通信への応答とHTTPサービスの稼働は別である。確認したい対象が配信サービスなら、そのサービスを実際に利用する監視が必要になる。

監視サーバは、IP到達性、TCP接続、HTTPのリソース取得をそれぞれ確認する。

問題

解説：三つの監視は確認する階層が異なる。ping成功だけで、HTTPアプリケーションが正常に応答すると判断することはできない。

コンテナサーバaのping監視が失敗した。サーバa上のAP0aに対するTCP監視とURL監視も失敗した。サーバbとAP0b、共有リバースプロキシ経由のURL監視は正常である。

問題

解説：AP0aだけでなく、その実行基盤のIP到達性も失われている。原問では共通する基盤であるコンテナサーバaを障害箇所として推測する。

コンテナサーバaのping監視は正常である。一方、AP0aに対するTCP監視とURL監視は失敗した。その他の監視は正常である。

問題

解説：物理・OS側の到達性は残っている。コンテナ単位の監視だけが失敗するため、AP0aを切り分け対象とする。監視結果からの推測であり、故障部位を直接観測した結果ではない。

既存出口R11に加えてR13を新設し、両者でVRRPを構成する。FW10はVRRPの仮想IPをネクストホップにする。作業手順では、BGPによる経路交換を確認した後にVRRPを導入する。

問題

解説：マスターになることと、宛先への経路を持つことは別である。利用者のパケットをR13へ渡す前に、R13の転送経路を整える必要がある。

R13をL2SW10経由でFW10・R11へ接続する。R13と事業者側R14の間には新しい専用線を設ける。IPアドレス設定後、BGP接続の前に追加設備の通信を確認する。

問題

解説：本社LANへの接続と、新設専用線への接続を分けて確認する。各組の送信方向は逆でも確認できる。

旧APサーバと新WebAPコンテナを並行稼働させる。全利用者向けのDNSはまだ旧構成を指している。テストPCだけを新しい共有リバースプロキシへ接続したい。

問題

解説：利用者全体の名前解決は変えず、テストPCだけでFQDNの対応先を上書きする。HTTPのHostに同じFQDNを使ったまま確認できる。

DNSを移行先に切り替えた。旧APサーバは当面稼働させている。PCやDNSのキャッシュには以前の対応が残る可能性がある。

問題

解説：DNSレコードを変更したという作業結果だけでは、全クライアントの切替完了は分からない。旧サーバへの実際のアクセスの有無を確認する。

AP0a・AP0bの両方が稼働する場合、AP0aだけが停止する場合、AP0bだけが停止する場合の3パターンで業務動作を確認する。共有リバースプロキシが正常なコンテナへ振り分ける構成である。

問題

解説：両系稼働時の成功だけでは、片方の不備が隠れることがある。停止する側を入れ替えれば、残った各系の動作と振り分けを確認できる。

FWと拠点L3スイッチの間では、OSPFv3の隣接関係にLLAを使う。PC・サーバを直接接続しないこの区間にも、GUAを静的に割り当てる。

問題

解説：経路制御の成立条件と、運用時に機器を見分けやすいことは別の要件である。固定したアドレスで応答することで、経路調査の結果と管理対象機器の対応を把握しやすくする。

旧FWと新FWは、DMZ側ゲートウェイに同じ仮想IP172.16.254.1を使う。切替時に新旧DMZのL2SWを接続する。手順では先に旧FW―旧DMZ間のケーブルを抜く。

問題

解説：分離中は同じアドレスを使えても、L2で接続すると一つのセグメント上に同じ仮想IPが現れる。共存中のアドレス設計と接続順序を合わせて考える。

インターネット回線は新ルータ1へ移した。新ルータ1―新L2SW0―新FW1―新L2SW1の順でDMZへ接続する。新L2SW1は旧L2SW1へ接続済みである。

新公開Webサーバに不具合が見つかった。旧公開Webサーバは稼働しており、旧L2SW1に接続している。

問題

解説：外部公開用のアドレスや回線を再び戻すのではなく、NATの内部転送先を切り替える。新旧DMZ間のL2接続を準備したことが、この切戻しを可能にする。

新Webサーバと新外部DNSは新FWの内側にある。外部クライアントが利用するフルサービスリゾルバに、Webサーバの名前解決結果はキャッシュされていない。

問題

解説：Webアクセスに先立ち、権威DNSへの問い合わせが必要となる。キャッシュがないという条件が、DNS通信も確認できる根拠である。

大阪本社ではPC、サーバセグメント、インターネット接続用FW10がL3SW10に接続する。WAN接続用R10・R11もL3SW10に接続する。東京支社とC社SaaSへはWANを通る。

通常のWAN通信は広域イーサ網を利用する。大阪側はR10、東京側はR20、SaaS側はR30を経由する。代替経路はR11・R21・R31によるIPsec VPNである。R10を更改するとき、PCから継続的にpingを実行して影響を監視する。

問題

解説：大阪本社からインターネットとサーバへの通信は、本社内で完結するためR10を通らない。東京支社からこれらへ向かう通信は、大阪本社へ入るR10を通る。監視対象は、作業対象装置の影響を受ける経路から選ぶ。

R10の通信を迂回させた後、全物理インタフェースを閉塞する。通信に問題がないことを確認してから、設定を保存し、電源を切って装置を交換する。

問題

解説：閉塞の解除で戻せる段階を先に設ける。電源断後の復旧では起動待ちが必要になる。変更を段階化することで、異常を確認した時点で短い手順で元に戻せる。

旧R10のイーサネットケーブルをすべて抜き、新R10に接続し直す。接続先のインタフェースを誤らないため、ケーブルを抜く前に準備を行う。

問題

解説：ケーブルと接続先の対応を、抜去前に残す。作業後のpingだけでは、誤接続そのものを防ぐことはできない。作業前の識別と作業後の確認は別の対策である。

新R10の物理インタフェースを開放した。新R10は本社側でL3SW10とR11に到達し、広域イーサ網側では東京支社R20とSaaS側R30に到達する。OSPFコストを通常値に戻す前に、新R10からpingを実行する。

問題

解説：本社側とWAN側の両方を確認する。業務通信を新R10へ戻す前に、交換装置が必要な隣接・対向機器と通信できることを確かめる。

既存の静的経路を維持しながら二回線化する。機器設置・配線・物理ポートのIP設定・疎通確認は完了している。

ルータ10・11のiBGPはループバックアドレスを使用する。ループバック間の到達性はOSPFで確保する。外部との経路交換はeBGPで行う。

問題

解説：ピアに使うアドレスを先に作る。次に内部到達性を確保してからiBGPを張る。内部で経路を伝播できる状態を整えた後、外部経路を受け入れる。

更改前のインターネット接続は、ISPのルータ10Z、社内のルータ10、FW10の経路で構成される。この三つの機器には静的経路が設定されている。新設したルータ11Z・11は、動的ルーティングで導入した。

問題

解説：静的ルートの削除対象は、旧経路を成立させていた機器である。新設側の機器を含めるのではなく、切替前の転送経路をたどって設定の所在を確認する。

BGPによる経路交換を開始した後も、同じ宛先への既存の静的経路を残している。本問の機器設定では、静的経路がBGP経路より優先される。

問題

解説：経路の受信と、その経路が転送用に採用されることは別である。優先される既存経路を削除すると、準備済みのBGP経路が採用される。

二回線化が完了し、ルータ11側にも利用可能な経路がある。ルータ10を交換する前に、通信をルータ10側から退避させたい。社内向け・ISP向けの経路はBGPで交換している。

問題

解説：外部とのピアを停止してルータ10側の経路を取り下げる。代替経路への切替を確認してから機器を交換する。物理的な取り外しを最初の障害通知にしない手順である。

PCのインタフェース識別子を、固定MACアドレスからではなく疑似乱数で生成する。利用者のプライバシー保護に有用だが、PC管理上の配慮が必要である。

問題

解説：固定の識別子に頼れなくなるため、アドレスと管理対象PCの対応を追うことが難しくなる。プライバシー上の利点と、管理上の追跡のしやすさは、同じ性質を異なる立場から評価している。

Gメーターは内部時計に従って毎時測定し、決められた時刻にデータを送信する。長期間の稼働によって内部時計のずれが増える。

問題

解説：測定値だけでなく、いつ測ったかも管理対象となる。時計がずれると測定時刻と送信スケジュールの両方が本来の時刻から外れる。

管理サーバの時刻はNTPサーバで補正する。Gメーターと管理サーバはCoAPで通信できる。端末側の時計誤差を抑えたい。

問題

解説：時刻が補正されたサーバを基準にする。端末がその現在時刻を取得し、自分の時計へ反映するところまでが処理の内容となる。

PCで映像を視聴する方法には、カメラ管理サーバのWebページでカメラを選ぶ方法と、各PCのデスクトップアプリへカメラを登録する方法がある。

問題

解説：選択対象の管理をサーバ側へ集約できる。各PCのアプリへ個別にカメラを登録し直す作業が不要になる。