network_hogeさんの助け合いフォーラム投稿一覧

「Dockerコンテナ」と「Kubernetes」は類似したシステムではありますが、
厳密には異なるものになるようです。

https://cloud-ace.jp/column/detail229/
※外部サイト

そのため、「Dockerコンテナを使っている＝Kubernetesが使える」という式にはなりません。
結果、EKSに切替えた場合は「実績のあるDockerコンテナを使う」という前提要件から外れます。

この問題はあくまで、「RAで『show ip ospf neighbor』を打って出力した、RAのネイバーであるRBのステータス」に言及するものです。
出力結果に「RAのステータスそのもの」が出力しているわけではありません。

問題文で「何を求められているか」を正しく読み込むようにしてください。

interface Ethernet 0
ip access-group 1 out

問題におけるこのコマンド群については、
「ルータ1のinterface Ethernet 0(E0)から出ていく(out)通信」
をターゲットとしています。
そのため、経理部(E3)から入り(in)、人事部(E2)へ出る(out)通信については、
サーバ向けの口(E0)を経由しないのでアクセスリストの対象外になります。

CatalystにもL3機能を持ったものがありますね(中規模…3000系、大規模・コア向…9000系)

ただ、L3スイッチについては「L2スイッチ(スイッチングハブ)にL3(ルーティング)機能を付加した」というものではあるので、
大前提として「スイッチ＝L2スイッチ」、という認識でいいと思っています。

･･･、これではADの同期要件が不明確です。
オンプレミスのADと新しいAWS Directory Serviceとの間で発生する運用負荷についてもっと明確に…
これでは弱いです。だから、オンプレADを辞めて、AWS Directory Serviceに完全移行したら楽だね。という風にはなりませんし…
とても紛らわしいので、”なお、オンプレミスのADはWebアプリケーションが動作しているWindowsサーバー群のみ管理している。”の言葉を消し…

そのような「問われている部分以外の、問題の裏の裏」まで考察する必要は無いように思います。
そんなことをしていると、回答の時間が無くなります。
ただ単純に、「WebアプリケーションサーバはADで連携されているんだなぁ」「ADはWebアプリケーションサーバのみで使われているんだなぁ」
「AWSに移行した方が得をする状況なんだろうなぁ」くらいで充分でしょう。
「そこは『その会社に、それを善しとする事情と条件がある』ので、そういう構成にしている」と割り切るべきです。

『オンプレミスのADと新しいAWS Directory Serviceとの間で発生する運用負荷』

問題文中「各WindowsサーバーをEC2 Windowsインスタンスに切り替える」とあることから、
オンプレのWindowsサーバはすべてAWS移行、と考えるのが自然です。
そのうえで、上記の一文をどのように解釈しているかは判然としませんが、
「オンプレ・AWSのAD同時運用 or オンプレAD・AWS DS間連携」という観点であれば、誤答として解説されています。

IT技術者の個人ブログなどでも、一次結果が「Pending」になっているという話を最近見受けます。
どうやら2023年から一次結果を「Pending(保留)」と記載する場合が出てきているとのこと。

受験の際にピアソンへ登録されていると思います。
ピアソンのサイトを確認されるといいかと。
また「保留」とのことなので、正式結果が別途通知されると思いますから、
急ぎでなければ２～３日待ってみてはいかがでしょう。

「受信したネットワークとは異なるネットワークに通信を送信する場合」に、
MACアドレス付替えが
(1)送信元MACを、送信先ネットワークに属する自身の送出インターフェースのMAC
(2)宛先MACを、送信先ネットワークに属する終点(=宛先)インターフェースのMAC
という形で発生します。

CatA・CatBは、各機器と同じネットワークに属する機器へ中継するだけであるため、
MACアドレスの付替えは発生しません。
（『解説』の最終３行を参照）

よって本設問の構成の場合、MACアドレス付替えが以下の形で発生します。
① RAを経由してRBへ送信するとき、送信元MACがRAのSo0/0、宛先MACがRBのSo0/0
② RBを経由してFTPサーバへ送信するとき、送信元MACがRBのFa0/0、宛先MACがFTPサーバ

この場合、そもそも
「『ブロードキャストアドレス』『ネットワークアドレス』とは何か」
を理解しておく必要があります。

それぞれは、『サブネット配下のホストアドレスビット』について、
ネットワークアドレス：すべて0
ブロードキャストアドレス：すべて1
になるものを指します。

まず、設問の「10.10.10.15/28」と「10.10.10.16/28」の、
それぞれ第4オクテットをビット表記にします。
15 ⇒ 00001111
16 ⇒ 00010000

次に、「/28」は「第4オクテットの左4桁までサブネット」の意味となるので、
それぞれを以下の形に分解します。
15 ⇒ 0000(サブネット部) / 1111(ホスト部)
16 ⇒ 0001(サブネット部) / 0000(ホスト部)

つまり、
10.10.10.15/28は、
「10.10.10.0/28配下、ホストアドレスがすべて1 ⇒ 10.10.10.0/28サブネットのブロードキャストアドレス」
10.10.10.16/28は、
「10.10.10.16/28配下、ホストアドレスがすべて0 ⇒ 10.10.10.16/28サブネットのネットワークアドレス」
と見ることが出来るようになります。

あくまでも「ospfの有効化」が主眼の問題なので、
① どのコンフィグレーションモードでコマンドを投入するか
② 該当のコンフィグレーションモードで有効化コマンドを正しく投入できるか
を回答できればいいのです。

補足(蛇足？)として、実務上「隣接するL3機器間で、OSPFの『プロセスIDが合わない・合わせせられない』」という
場合が出てきます。
ここまで考えて設問されているかは不明ですし、設問のまま覚えるということもないとは思っていますが、
『RT1とRT2へ同じコマンドを使用する。』という但し書きを考慮すると、
「router ospf (process-id)」まで入れると、場合によっては…という点は片隅に置いておくといいと思いますよ。

設問およびCafeLateさんの回答に対して、koyakeiさんが「どの点」で「何」に疑問を持たれているのかが、
今までの流れからはいまいち見えてこないのですが…

調べてみた限りでの回答ですが、

① ＞lambaでRDSを起動するのが正しい。
　AWS Lambdaは単独起動しないサービスです。
　必ず何がしかのトリガーが必要で、本設については「EventBbridge」が該当です。

② ＞eventbridge のスケジュールは cron と rate　しか対応していないので～
　EventBridgeを使用したLambda起動については、cron式になるようです。
　https://docs.aws.amazon.com/ja_jp/eventbridge/latest/userguide/eb-run-lambda-schedule.html

③ ＞「朝8時から夜20時までと指定され～」→「ここが論理飛躍してます。見做さない事もできる。」
　ここでは、
　「RDSインスタンスに保存しているデータは工場が稼働する朝8時から夜20時の間しか利用されない。」
　と明言されています。
　であれば、RDSが起動していればいい時間は「朝8時から夜20時まで」と取るのが自然でしょう。
　そして、解答の大前提は「コスト削減のためにどのような提案」とあるので、
　『起動の必要がない時間帯でインスタンスを停止する』が最適解でしょう。
　であれば、
　「朝8時に『RDSインスタンスを起動するジョブ』をEventBridgeでトリガーする」
　「夜20時に『RDSインスタンスを停止するジョブ』をEventBridgeでトリガーする」
　という解答で問題ないでしょう。

　むしろ、「見做さない事もできる」のであれば、どのような「見做し」があるのかを
　提示いただかないと、解答のしようもありません。

まず、ARPは通信を制御するための情報を扱うプロトコルですが、
ARPそのものが通信に作用するのではなく、ARP応答の結果でテーブルを作成し、
通信がテーブルに従って動作します。

そして、コントロールプレーンとデータプレーンの区分けとしては、
以下のような大枠だと考えられます。

コントロールプレーン
　→各種ルーティングプロトコルやARPで得られる情報による、対応するテーブルの操作
　　＝『通信制御情報の管理・編集』
データプレーン
　→ルーティングテーブルやARPテーブル、MACアドレステーブルおよびACLによる通信の操作
　　＝『通信制御情報に従った動作の実行』

そのため、
　ARP応答による、ARPテーブルの追加・更新 ＝ コントロールプレーン
　ARPテーブルの検索と、結果による通信送出 ＝ データプレーン
ということになると考えています。

ここでいう「NATテーブルを参照する」は「(設定者・使用者が)NATテーブルを確認する」の意味です。
「ip nat inside source static」のコマンドでは、NATテーブルを「確認」出来ませんよね？

また、「ip nat inside source static」で設定が参照するのは、「NAT」ではなく「ACL」になります。

この設問において、「192.168.1.16 0.0.0.15」は「サブネット」を表現するものではありません。

Ping-t社のローカルアドレス帯は「192.168.1.0/24」であり、
ネットワークアドレスは「192.168.1.0」、ブロードキャストアドレスは「192.168.1.255」になります。

「192.168.1.16 0.0.0.15」の表記は、あくまで「192.168.1.16～192.168.1.31の区間」を指し示す表記となるため、
「フル0≠ネットワークアドレス」「フル1≠ブロードキャストアドレス」となります。

『TCP』は、「OSI参照モデルに基づいて『トランスポート層』に分類される、『コネクション型プロトコルの総称』」で、
『HTTP』は「トランスポート層に分類されるプロトコルの１つ」になります。
　参考：https://www.infraexpert.com/study/tcpip7.html

また、HTTPには「TCP(コネクション型)」と「UDP(コネクションレス型)」が存在しています。
　参考①：https://ja.wikipedia.org/wiki/TCP%E3%82%84UDP%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%9D%E3%83%BC%E3%83%88%E7%95%AA%E5%8F%B7%E3%81%AE%E4%B8%80%E8%A6%A7　⇒項目「システムポート番号」表、ポート番号80を参照
　参考②：https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=80


なお、本設問の意図は「ネットワークACL制御の、ルール適用順序の把握」です。
そのため、「ルール番号300でHTTPの許可設定を入れている」ことを踏まえ、あえて強調するような記載になっているものと思われます。

この問題では、そこまで踏み込んだ考え方をする必要はありません。

この問題の要旨は、「隣接するルータ間で、OSPFを機能させるために必要な条件」の把握、
あるいは「隣接するルータ間で、OSPFを設定した際に機能しない」という事象の分析です。

解説にある通り、OSPFネイバーの確立には以下の要件すべてが揃っている必要があります。
・Hello/Deadの間隔
・エリアID
・認証パスワード
・サブネットマスク
・スタブエリアフラグ
・MTUサイズ

そのため、『OSPFが確立しない＝要件のいずれか１つ、または複数が誤っている』ということになります。
あとは、選択肢の中から『OSPF確立の要件』を見つけ出せばいいのです。

それぞれの問題の意図する内容が異なります。
問題ID:29246‥‥デフォルトゲートウェイ「として指定する宛先」
　⇒ 通信の宛先設定の問題
問題ID:6236‥‥デフォルトゲートウェイ「を設定する機器」
　⇒ 設定を組み込む機器に関する問題

また、『デフォルトルート』と『デフォルトゲートウェイ』は異なる内容になります。
デフォルトゲートウェイ‥‥L2スイッチ・PC・サーバに設定するもの。自身の認知しないネットワークにIP通信を行うために目標とする宛先
デフォルトルート‥‥‥‥‥ルータ・L3スイッチに設定するもの。自身の認知しないネットワークにIP通信を行う場合に目標とする宛先

調べてみたところ、以下の情報がありました。
2019年で144chが追加され、20に増えているそうです。

＜wikipedia　IEEE 802.11＞
https://ja.wikipedia.org/wiki/IEEE_802.11
⇒IEEE 802.11aの項目、最終行

＜「5GHz 帯無線 LAN の周波数変更」に関するガイドライン＞
https://home.jeita.or.jp/upload_file/20200717173429_Mtlbmd8PIB.pdf

これは解答の選択肢が分かりづらいですね…。
解答の考え方は、Pnt353_127さんに間違いはありません。

それぞれの選択肢の、「スイッチにある各ポート」を「非ルートブリッジの各ポート」に
読み替えると分かりやすいでしょうか？
（運営様、ご考慮お願いします。）


補足：いわゆる「Cisco語」は、「元は英語で作成された問題」を日本語に翻訳して提供される
　　　ことによる、「日本語的におかしい語句・表記」のことを指します。
　　　本番で出くわすと解読で頭をひねることになるので、CCNAの内容をしっかり把握して
　　　惑わされないようにしましょう。

①この設問における、FastEther0/1のACL適用方向は、
　out：ルーターのFastEther0/1から出ていく(out方向)
　　　　⇒PCセグメントから見れば、「Serverセグメントに対して、行きの通信」
　　　　　Serverセグメントから見れば、「PCセグメントに対して、戻りの通信」
　in ：ルーターのFastEther0/1に入っていく(in方向)
　　　　⇒PCセグメントから見れば、「Serverセグメントに対して、戻りの通信」
　　　　　Serverセグメントから見れば、「PCセグメントに対して、行きの通信」

②ルータのACLは、双方向の通信について「その通信内容を一対で判定」はしません。
　そして、双方向の通信において「行きの通信」と「戻りの通信」では、送信元IP・宛先IP は変わります。


以上2点を念頭に、Pnt353_127さんの考え方の場合、
『ルータのFastEther0/1の「in方向（ルータに入る）」への通信にACLが適用される』ことになるのですが、
送信元IP【192.168.1.1＜PC-A＞】・宛先【172.16.1.1＜Server-A＞】で開始される通信は、

ルータのFastEther0/1を「out方向（ルータから出る）」に通過するので、ACLは適用されない
　⇒ACLの制御は「in方向（ルータに入る）」にかかる設定であるため
　　　　　　　　　　↓
　　　　　　　　　　↓
Server-Aに到達後、戻りの通信が発生
　⇒このタイミングで、送信元IP【172.16.1.1＜Server-A＞】・宛先【192.168.1.1＜PC-A＞】となる
　　　　　　　　　　↓
　　　　　　　　　　↓
ルータのFastEther0/1を「in方向（ルータに入る）」で通過するので、ACLが適用される
　⇒対象通信の大元（送信元IP【192.168.1.1＜PC-A＞】・宛先【172.16.1.1＜Server-A＞】で開始）を判定せず、
　　かつ送信元IP【172.16.1.1＜Server-A＞】のdeny設定は存在しないので、
　　最終行の『permit any any』で通過を許可

となるため、誤りとなります。

単純な「設定」の面でいえば、間違ってはいないと思います。
ですが、問題の主旨である「192.168.10.100からのsnmpリクエスト受信を制御する」ことを考慮した際に、
「接続が存在しない許可ACLのみを追加して制御する」のは迂遠と思われます。
それであれば、「接続を許可しない機器の拒否ACLを追加する」または「接続先の機能を止める」
という選択の方が考え方は簡単です。

※ 以降は、設問がどこまで意図しているか不明な上での、個人的な見解です。
もしgt81056さんの設定を導入した場合、
①構成上では無関係の設定を追加することによる、機器管理上の煩雑化
　（時期を開けて見返したときに「この設定、何のために入れた？」となりかねない）
②許可をしなくていい設定を追加したことによる、セキュリティ上の問題
　（悪意ある人物がこの設定を知った際に、許可IPを使用して悪用をする可能性がある）
という点を考慮すると、適切な解答では無いと考えられます。