arashi1977さんの助け合いフォーラム投稿一覧
この環境から読み取るべき前提は
- ブロードキャストネットワークである(スイッチで集約された Ethernet)
- ルータ ID はそれぞれの Fa1/0 のアドレス(Loopback や router-id の記載がない)
- 条件がないので、OSPF の各種原則に従う(起動した順番や再起動したという情報はない)
上記の前提に立つと以下の話が見えてきます。
- DR/BDR が存在する(ブロードキャスト)
- DR/BDR の選出は IP アドレス順(ルータ ID 選出のルール)
そうすると、誰がどういう役割になるかが見えて
- DR: R4(ルータ ID が最も大きい)
- BDR: R3(ルータ ID が2番目に大きい)
- DROTHER: R1, R2(DR/BDR どちらでもない)
となります。
ここで参考の【OSPFでよく使われる用語】を見るとそれぞれ以下のような隣接関係を結ぶことが確認できます。
- DR: 全 OSPF ルータと隣接関係を構築する
- BDR: 全 OSPF ルータと隣接関係を構築する
- DROTHER: DR、BDR と隣接関係を構築する
そうすると、
- R1: R4(DR), R3(BDR) と隣接関係を構築する(R2 とは結ばない)
- R2: R4(DR), R3(BDR) と隣接関係を構築する(R1 とは結ばない)
- R3: R1/R2(DROTHER), R4(DR) と隣接関係を構築する
- R4: R1/R2(DROTHER), R3(BDR) と隣接関係を構築する
ということが言えることがわかります。では隣接関係を結ばない相手とはどうなるのかというと、ここも参考の【OSPFステート】を見るとわかります。
2WAY・・・お互いに認識した状態
「R1 は R2 のことを知っているが隣接関係を結ばない」というのがまさにこのステートです。ですのでそれぞれのルータの状態を 2WAY も含めてまとめるとこうなります。(私の手元の環境での表示結果も一緒につけてみます)
- R1: R2(2WAY), R3(FULL), R4(FULL)
R1#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.2 1 2WAY/DROTHER 00:00:32 192.168.1.2 GigabitEthernet0/0
192.168.1.3 1 FULL/BDR 00:00:33 192.168.1.3 GigabitEthernet0/0
192.168.1.4 1 FULL/DR 00:00:34 192.168.1.4 GigabitEthernet0/0
- R2: R1(2WAY), R3(FULL), R4(FULL)
R2#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 2WAY/DROTHER 00:00:36 192.168.1.1 GigabitEthernet0/0
192.168.1.3 1 FULL/BDR 00:00:31 192.168.1.3 GigabitEthernet0/0
192.168.1.4 1 FULL/DR 00:00:32 192.168.1.4 GigabitEthernet0/0
- R3: R1(FULL), R2(FULL), R4(FULL)
R3#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 FULL/DROTHER 00:00:31 192.168.1.1 GigabitEthernet0/0
192.168.1.2 1 FULL/DROTHER 00:00:34 192.168.1.2 GigabitEthernet0/0
192.168.1.4 1 FULL/DR 00:00:37 192.168.1.4 GigabitEthernet0/0
- R4: R1(FULL), R2(FULL), R3(FULL)
R4#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.1.1 1 FULL/DROTHER 00:00:38 192.168.1.1 GigabitEthernet0/0
192.168.1.2 1 FULL/DROTHER 00:00:31 192.168.1.2 GigabitEthernet0/0
192.168.1.3 1 FULL/BDR 00:00:33 192.168.1.3 GigabitEthernet0/0
のようになるということですね。
個人的にですが、Flash での動画が見れなくなってはいるもののここの説明が割と段階を追って説明してくれてるので、この問題の理解の助けになるんじゃないかなと思います。
30分間ネットワーキング:第6回OSPF(2) DRとBDR
https://www5e.biglobe.ne.jp/aji/30min/06.html
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-comparison.html にある「踏み台サーバ」の項目の違いを学習するための問題なのではないでしょうか?
はい、そういうものです。
参考の[リソースベースのポリシーの記述例]のところでそれぞれのブロックの意味がまとめられていますが、日本語的にまとめると
「Resource で指定した(いくつかの) AWS リソースに対して(いくつかの) Action の操作を Effect で判定する」
って感じですかね。なのでResoureとActionがペアになる必要はないのです。
別の投稿への回答にも書きましたが、packet tracerはただのシミュレータなので実機の通りの挙動が全て実装されているとは限らないです。その上で確認してみていただきたいのですが、R1でプロセスリセットした後でR2で show ip ospf events
を実行した結果ってどうなってますか?
手元の環境でやってみたら、R1でプロセスリセットした後はちゃんとBDR→DRとなる挙動が見られます。
R2#sh ip os ev
OSPF Router with ID (2.2.2.2) (Process ID 1)
1 *Jul 21 01:40:32.952: End of SPF, Topo Base, SPF time 0ms, next wait-interval 10000ms
2 *Jul 21 01:40:32.952: Generic: ospf_external_route_sync 0xC
3 *Jul 21 01:40:32.952: Generic: ospf_external_route_sync 0xC
4 *Jul 21 01:40:32.952: Generic: ospf_external_route_sync 0x0
5 *Jul 21 01:40:32.952: Generic: ospf_external_route_sync 0x0
6 *Jul 21 01:40:32.952: Starting External processing, Topo Base in area 12
7 *Jul 21 01:40:32.952: Starting External processing, Topo Base
8 *Jul 21 01:40:32.952: Generic: ospf_inter_route_sync 0xC
9 *Jul 21 01:40:32.952: Generic: ospf_inter_route_sync 0xC
10 *Jul 21 01:40:32.952: Starting summary processing, Topo Base, Area 12
11 *Jul 21 01:40:32.952: Generic: post_spf_intra 0x0
12 *Jul 21 01:40:32.952: Generic: ospf_intra_route_sync 0xC
13 *Jul 21 01:40:32.952: Generic: ospf_intra_route_sync 0xC
14 *Jul 21 01:40:32.952: Starting Intra-Area SPF, Topo Base, Area 12, spf_type Full
15 *Jul 21 01:40:32.952: Starting SPF, Topo Base, wait-interval 5000ms
16 *Jul 21 01:40:32.505: Rcv Changed Type-1 LSA, LSID 10.10.10.10, Adv-Rtr 10.10.10.10, Seq# 80000004, Age 5, Area 12
17 *Jul 21 01:40:32.505: Schedule SPF, Topo Base, Area 12, spf-type Full, Change in LSA Type RLSID 10.10.10.10, Adv-Rtr 10.10.10.10
18 *Jul 21 01:40:28.491: Generate New Type-2 LSA, LSID 192.168.12.2, Seq# 80000001, Age 0, Area 12
19 *Jul 21 01:40:28.491: Schedule SPF, Topo Base, Area 12, spf-type Full, Change in LSA Type NLSID 192.168.12.2, Adv-Rtr 2.2.2.2
20 *Jul 21 01:40:28.490: Schedule SPF, Topo Base, Area 12, spf-type Full, Change in LSA Type RLSID 2.2.2.2, Adv-Rtr 2.2.2.2
21 *Jul 21 01:40:28.490: Generate Changed Type-1 LSA, LSID 2.2.2.2, Seq# 80000004, Age 0, Area 12
22 *Jul 21 01:40:28.002: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from LOADING to FULL
23 *Jul 21 01:40:28.002: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from EXCHANGE to LOADING
24 *Jul 21 01:40:27.999: Interface GigabitEthernet0/0 state changes from DR to DR
25 *Jul 21 01:40:27.999: Elect DR: GigabitEthernet0/0 2.2.2.2
26 *Jul 21 01:40:27.999: Elect BDR: GigabitEthernet0/0 10.10.10.10
27 *Jul 21 01:40:27.999: i/f state nbr chg: GigabitEthernet0/0 0x5
28 *Jul 21 01:40:27.999: Interface GigabitEthernet0/0 state changes from DR to DR
29 *Jul 21 01:40:27.999: Elect DR: GigabitEthernet0/0 2.2.2.2
30 *Jul 21 01:40:27.999: Elect BDR: GigabitEthernet0/0 10.10.10.10
31 *Jul 21 01:40:27.999: i/f state nbr chg: GigabitEthernet0/0 0x5
32 *Jul 21 01:40:27.997: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from EXSTART to EXCHANGE
33 *Jul 21 01:40:27.997: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from 2WAY to EXSTART
34 *Jul 21 01:40:27.997: nbr state adjok: 10.10.10.10 0x3
35 *Jul 21 01:40:27.997: Interface GigabitEthernet0/0 state changes from DR to DR
36 *Jul 21 01:40:27.997: Elect DR: GigabitEthernet0/0 2.2.2.2
37 *Jul 21 01:40:27.997: Elect BDR: GigabitEthernet0/0 10.10.10.10
38 *Jul 21 01:40:27.997: i/f state nbr chg: GigabitEthernet0/0 0x5
39 *Jul 21 01:40:27.997: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from INIT to 2WAY
40 *Jul 21 01:40:27.990: Interface GigabitEthernet0/0 state changes from BDR to DR ←ここ
41 *Jul 21 01:40:27.990: Elect DR: GigabitEthernet0/0 2.2.2.2
42 *Jul 21 01:40:27.990: Elect BDR: GigabitEthernet0/0 0.0.0.0
43 *Jul 21 01:40:27.990: Elect DR: GigabitEthernet0/0 2.2.2.2 ←ここ
44 *Jul 21 01:40:27.990: Elect BDR: GigabitEthernet0/0 2.2.2.2
45 *Jul 21 01:40:27.990: i/f state nbr chg: GigabitEthernet0/0 0x6
46 *Jul 21 01:40:27.990: Neighbor 10.10.10.10, Interface GigabitEthernet0/0 state changes from FULL to INIT ←ここ
47 *Jul 21 01:40:27.952: Rcv Changed Type-2 LSA, LSID 192.168.12.1, Adv-Rtr 10.10.10.10, Seq# 80000001, Age 3600, Area 12
48 *Jul 21 01:40:27.952: Schedule SPF, Topo Base, Area 12, spf-type Full, Change in LSA Type NLSID 192.168.12.1, Adv-Rtr 10.10.10.10
49 *Jul 21 01:40:27.952: Rcv Changed Type-1 LSA, LSID 10.10.10.10, Adv-Rtr 10.10.10.10, Seq# 80000003, Age 3600, Area 12
50 *Jul 21 01:40:27.952: Schedule SPF, Topo Base, Area 12, spf-type Full, Change in LSA Type RLSID 10.10.10.10, Adv-Rtr 10.10.10.10
51 *Jul 21 01:39:31.436: Timer Exp: nbr_hold_dbd 0xA0A0A0A
手元のCML環境(仮想ルータ)で確認してみましたが、設問の通りになりました。ですので間違いではないですね。
packet tracerは仮想ルータではなくシミュレータなので、実機とは異なる挙動をする事がある前提でご利用になるのが良いかなと思います。
はい、大丈夫です。
show running-config
とかしたらわかるのですがこの通りの順番で出力されるので、この出力を元にまっさらな環境に設定投入しても何も問題はないのです。
しかし、スタティックルートとしてはネクストホップがPC1のアドレスになっており、そもそも間違っているため
と、「スタティックルートが間違っている」ことは理解されているのだと理解しています。
この状況では正しくルーティングされないためそれを修正するためのコマンドが問われており、選択肢の中から適切なものを選ぶのがこの問題の主旨であって
正答の設定ではOSPFルートがダメになったらPingが成功しないので
「OSPFルートがダメになった」場合のことは問われていないので、そこは気にしないでも大丈夫です。
あと、揚げ足取りの意図ではないのですが、「正答の設定ではOSPFルートがダメになったら」との考慮についてはその他の選択肢の誤答の理由にあるように全て「設定しても期待通りの通信にならない」ので、OSPFルートが正常だろうがダメになろうが状況は変わらないのではないかなぁと思います。
ForwardAgent
は ssh_config
に設定するパラメータなので間違いではないですよ。
https://linux.die.net/man/5/ssh_config では ForwardAgent
はヒットしますが、 https://linux.die.net/man/5/sshd_config ではヒットしないことでも確認できます。
解説にもあるように「踏み台中継サーバの SSH クライアント」で利用するパラメータであって、 「踏み台中継サーバ」がローカルホストからの接続を受け付けるときに利用するパラメータではない、というところがポイントかなと思います。
AIが間違いと判定していたというお話ですが、問題をちゃんと理解できていないAIの方が間違っていますね。
preemptが無効(未設定)の場合は、自身のpriorityが他のルータよりも高くなったとしてもActiveにはならない、という事です。この設問と同様の設定をすると、CatA相当のルータでtrackingしているインターフェースがdownとなった場合、自分よりpriorityの高いルータがいるにも関わらずActiveのままになる事がわかります。
CatA#sh stand
Vlan1 - Group 1
State is Active
2 state changes, last state change 00:13:33
Virtual IP address is 192.168.1.100
Active virtual MAC address is 0000.0c07.ac01 (MAC In Use)
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.496 secs
Preemption enabled
Active router is local ←自分がActive
Standby router is 192.168.1.2, priority 100 (expires in 8.752 sec) ←Standbyはpriorityが100
Priority 90 (configured 120)
Track object 1 state Down decrement 30 ←自分はtrackingにより30減らして90になっているが、ここより上の通りActiveのまま
Group name is "hsrp-Vl1-1" (default)
プリエンプションは「設定したルータ」で機能するので、設定していなければ「他にActiveがいなくなるまでStandbyのまま」です。この設問ではCatA-CatB間の接続が切れたとはなっていないことからCatBはCatA(Activeルータ)が生きていることを知る事ができると判断でき、今のpreempt無効なCatBはActiveに切り替わらない、という事です。
細かい動作について確認したい場合は、Coup(クープ)メッセージについて調べてみると良いですよ。
問題文を見ると
仮想化されたインフラ環境をサービスとして提供
とあるので、「インフラ環境」を「サービス」として利用できるか、というのが重要な観点かと思います。SaaSアプリケーションの一例としてですが、オンライン版のMicrosoft 365を利用するにあたって、メールを送受信したりWord/Excel/Powerpointなどのファイルを編集することはできても「サーバ、ストレージ、ネットワーク等、仮想化されたインフラ環境」は直接利用できないですよね。どこのネットワークに配置されたどのようなスペックのサーバで動作するかとか、それはクラウド側が管理しているものであって、サービスとして提供されているのは「アプリケーション」なのですよね。
「クラウド事業者が何を提供しているか(ユーザーが何を用意しなくていよいか)」ではなく、「サービスとして利用しているものは何か」というのがこの問題で扱っている「クラウドのサービスモデル」の内容かなと思います。
このshow runやその他の出力からではほんとに現在SSHできてるかわかりませんし、試験学習やそのための実機確認に関するものにも思えないのでここで質問するのが適切かを考えるところからかなぁという気がします。
私が試したときは以下のように回答があったので「どういうことだ?」と思って何回かやったら、違うパターンの解説が来ました。
最初にやった時の解説冒頭
IPv6のグローバルユニキャストアドレスに関して、「前半64ビットはIPv4のネットワークアドレスに該当する」という選択肢が正しい理由を詳しく見ていきましょう。
IPv6アドレスは、128ビットの長さを持ち、これをさらに2つの主な部分に分割できます。次の点を確認してみましょう。
別の解説
すみません、「C. 前半64ビットはIPv4のネットワークアドレスに該当する」が正解であるとの説明は間違っています。「C」は実際には不正解です。正しい情報を提供するために、以下で詳しく説明します。
おそらくここで使用している(Generative)AIは基本的にいろんな情報を集めてきたものの中から質問にマッチしそうなものをピックアップしてそれらしく回答を生成したりするものですし、まさにAI Assistantの利用に書いてあるこの部分に遭遇したのかなと思います。
*AIは間違えることがあります。
白本持ってないので白本の内容に疑義があるならそちらの発行元にお問い合わせいただくのが良いかなと思います。
それはそれとして。
PVST……PVSTはISLでカプセル化されたBPDUを使用して(以下略)
PVSTはISLはCisco独自のカプセル化方式(ISL)を使うSpanning-treeの実装であり、IEEE標準の実装ではない
PVST+……PVSTではISLを使用することが前提となっています。これをIEEE802.1Qに対応させたのもが、PVST+となります。
PVST+はPVSTの実装のうち、使用するカプセル化のみをIEEE 802.1Qにしたものであり、Spanning-tree実装としてはCisco独自のままでカプセル化のみIEEE 802.1Qに変更したものなので、Cisco独自と言える
という話だと解釈しましたが、どうでしょう?
TCPの通信ではサーバ、クライアント双方が特定の「ポート」を使用します。
サーバ側は特定サービス(HTTPなら80、HTTPSなら443とか)がわかっていますが、クライアント側ポートはOSが自動的に割り振るためどのポート番号になるかは特定できません。
https://xtech.nikkei.com/it/pc/article/NPC/20070621/275460/
クライアントソフトも通信の際にはポート番号を利用します。サーバーソフトと異なり、 通信を始める際に、空いている番号をOSが自動で割り当てます。クライアントがサーバーにアクセスしたときに、クライアントのポート番号が伝わります。 そのため、クライアントのポート番号は自動で決めても問題ないのです。
なので、アウトバウンド(=クライアント向け通信)の宛先ポート番号の範囲は「利用可能なすべて」を指定しないといけないんですね。
まぁそういう意味だと、クライアントのIPアドレスも不定なので全てを意味する 0.0.0.0/0
になってるわけですが。