arashi1977さんの助け合いフォーラム投稿一覧
うーん…そもそも設問が
下図のSwitchに「switchport trunk allowed vlan add 110」を設定したときの動作について
なのですから、「設定が反映されたところまで」が表示されてたらそれはすでに問題として意味がないのではないでしょうか？「この状態にこの設定を入れたらどうなる？」という問題を「この状態のスイッチの動作として正しいものは？」に変えるべきということであれば、どの段階の図を表示するかではなく問題自体を変更するようにというお話になりますよね。
この問題と回答、解説に誤りがあるわけではないのであれば、問題の形式を変える必要性はないのではないかなぁと思います。
誤答解説のこの部分ですか？
シングルAZ構成では高可用性やフェイルオーバーを実現できませんので、誤りです。
確かに「フェイルオーバー」はシングルAZ構成でもできますが、当該AZ障害の場合はフェイルオーバーする先ごとなくなるので「高い可用性を確保」しているとは言えないから、ということなのかなぁと思います。そういう意味では記述が明確ではないかなぁって気がしますね (^^;
192.168.20.18のホスト部は第４オクテットの.18を２進数表記したときの00001011の「1011」
ここが間違いですね。18を2進数表記したら 0001 0010(16+2) になります。 1011 だと「11（8+2+1）」です。
経緯や何かはこちらが参考になるかなと思います。
Geekなページ：IPv6アドレスにおける「インターフェース識別子」という名称の謎とModified EUI-64によるIPv6アドレス生成
https://www.geekpage.jp/blog/?id=2020-7-21-1
EUI-64では、グローバルに一意な値である場合にはuniversal/localビットが0なので、 64ビットのうち、最下位ビットのみが1となるような値（注：インターフェース識別子部分が「::1」となるようなアドレスのこと）は、グローバルに一意という意味があることになってしまいます。
たとえば、2001:db8::1というユニキャストIPv6アドレスを手動で設定したとき、Modified EUI-64ではなく、通常のEUI-64を採用していた場合、 インターフェース識別子に含まれるuビットが0 となるので、 64ビットのうち最下位ビットのみが1というインターフェース識別子がグローバルに一意であるものを示すことになってしまう わけです。
しかし、 手動設定での2001:db8::1というユニキャストIPv6アドレスの下位64ビットは世界で一意となるようなユニークな値ではありません。 こういう設定を行いたい人が多そうなので、 Modified EUI-64では、uビットが0の場合はlocalで、1の場合がuniversalという風に、意味を反転させたのです。
①ポリシーのデフォルト値そのものを変えてしまう
ですね。 iptables でいう、 -P オプションのことです。
①の場合、ufw resetは、ufw defaultで変える前の標準のデフォルトに戻るのではなく、
①で変えた後のデフォルトに戻ることになりますか？
その通りです。実機でやるとそのようになりますね。
$ sudo ufw status verbose
Status: inactive ←初期状態はinactive（ufwが動作していない）
$ sudo ufw --force enable
Firewall is active and enabled on system startup
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed) ←incoming:deny, outgoing allow になっている
New profiles: skip
$ sudo ufw default allow incoming ←incoming:allowにdefaultポリシーを変更
Default incoming policy changed to 'allow'
(be sure to update your rules accordingly)
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), disabled (routed) ←incoming:allowになっている
New profiles: skip
$ sudo ufw --force reset
Backing up 'user.rules' to '/etc/ufw/user.rules.20240828_140215'
Backing up 'before.rules' to '/etc/ufw/before.rules.20240828_140215'
Backing up 'after.rules' to '/etc/ufw/after.rules.20240828_140215'
Backing up 'user6.rules' to '/etc/ufw/user6.rules.20240828_140215'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20240828_140215'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20240828_140215'
$ sudo ufw status verbose
Status: inactive
$ sudo ufw --force enable
Firewall is active and enabled on system startup
$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), disabled (routed) ←reset後もdefaultで設定した incoming:allow は変わっていない
New profiles: skip
以下の内容について疑問があります。
記載内容として正確性に欠けると思われます。
疑問なのか記述に対する訂正希望なのかがいまいちわからないので疑問についてのお話として考えてみました。
ただ、疑問のポイントがよくわからないのですが、設問の条件は
AWSアカウントを持っていないユーザーに、非公開設定されたAmazon S3のデータへアクセスさせたい。
なので、「AWSアカウントベースでの制御は不可」な相手に「非公開設定＝パブリックアクセスではない」のオブジェクトを参照させたいというもののはずです。
「★1、★2 の記載」というのは「AWSアカウントを持っているユーザーがアクセス権限設定の対象なので」に対してのものだと理解したので「バケットポリシー or ACL でパブリックアクセスにすればできるじゃん」というご認識なのだと読み取りましたが、それは「非公開設定されたデータを非公開じゃなく世界中全てに公開する設定に変更すればいいじゃん」と同じことかと思いますので、上記の条件を無視（条件を勝手に変更）しているのでこの問題の回答を導くには不適切かなと思います。
GigabitEthernet0/1の場合は接続先のスイッチのMacアドレスが表示されているのでしょうか？
はい、トランクリンクなので対向スイッチの（同一） MAC アドレスが見えているという状況ですね。
また、FastEthernet0/2もトランクポートだと思うのですが、vlanが一つか複数かでMacアドレスの表示が変わってくるのでしょうか？
ここがよくわからなかったのですが、なぜトランクポートだと思ったのでしょうか？Fa0/2 が紐づいた VLAN は 20 だけしかないので、
interface FastEthernet0/2
switchport mode access
switchport access vlan 20
となっている Fa0/2 の先にスイッチまたはハブが接続されているという状況かと思うのですが…
これではFa0/11が非指定ポートになりブロッキング状態になります。そうなるとFa0/11がブロッキング状態なので、
正答は
Switch1(config)#interface FastEthernet 0/12
Switch1(config-if)#spanning-tree vlan 2 port-priority 16
と、Switch1 の Fa0/12 において VLAN2 のポートプライオリティを変更しているものです。VLAN1 の設定は変更していないので、Fa0/11 は設定前と同じく Switch1:Desg / Switch2:Root のままで転送はできると思いますが、「要件を満たせない」というのはどういう状況のことをおっしゃっていますか？
「コマンドで設定」という点を気にされているかと思いますが、コマンド投入って手入力だけじゃなくてターミナルに張り付ける形だったりもあるので、必ずしも手入力のように投入するコマンド間に無視できないほどの時間が存在するわけではないんですよね。
単純に「こういう設定を入れた」という受け取り方でも良いと思いますよ。
「ディストリビュートリストでフィルタされた情報」が「処理後の情報」という意味だと読み取ったので特に間違っていないとは思いますが、「フィルタされた情報」を「フィルタ対象の情報」と読めば間違っているようにも思えます。
ただ、そこだけじゃなくて後続の
LSDBには引き続き反映される
も考えると、
- Ping-tさんの解説：フィルタ後の状態はルーティングテーブルには反映されるがLSDBには反映されない（LSDBはオリジナルのまま、という話）
- jelicoさんの提案：フィルタ対象の情報はルーティングテーブルには反映されないがLSDBには反映される（反映の方向は？）
というように読めます。
OSPF のディストリビュートリストって、「LSDB からルーティングテーブルに登録する経路情報を制御」するものですので、「ルーティングテーブルに反映」されるものなんですよね。なので方向としては「LSDB→ディストリビュートリスト→ルーティングテーブル」となるべきで、「ディストリビュートリスト（フィルタ）→ルーティングテーブル（反映されない）」かつ「ディストリビュートリスト（フィルタ）→LSDB（反映される）」という説明の方向はちょっと違うかなぁと感じました。
「汎用的」って「いろんな用途に使える」という意味ですので、 /home /usr /var とかのさまざまなシステム領域の要件に合うという意味で使われているのではないでしょうか？
一方、「標準的」だと「選択する際の有力候補であり、特殊要件などなければこれを使う」といった意味合いになってくると思いますので、ニュアンスが違うかと思います。
あと、21930の場合は「使われていた（過去の話）」なので、今よく使われているものを回答するのはちょっと違う、ということでもあるかなと思います (^^;
※RHEL は 7 から xfs が標準（default）のファイルシステムになってます
問題ID: 29561 の参考に以下の記述がありました。
※ユーザーを作成すると、同じ名前の「スキーマ」も同時に作成されます。スキーマとは、1人のユーザーが所有するオブジェクトの集合です。
なので、「pingtユーザーでログインしている＝pingtスキーマを使用している」と言え、同じ表オブジェクトのデータを参照しているということだと判断できるので、 reo_tokeshi さんのご認識の通りかと思います。
この環境から読み取るべき前提は
- ブロードキャストネットワークである（スイッチで集約された Ethernet）
- ルータ ID はそれぞれの Fa1/0 のアドレス（Loopback や router-id の記載がない）
- 条件がないので、OSPF の各種原則に従う（起動した順番や再起動したという情報はない）
上記の前提に立つと以下の話が見えてきます。
- DR/BDR が存在する（ブロードキャスト）
- DR/BDR の選出は IP アドレス順（ルータ ID 選出のルール）
そうすると、誰がどういう役割になるかが見えて
- DR: R4(ルータ ID が最も大きい）
- BDR: R3(ルータ ID が２番目に大きい）
- 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 での動画が見れなくなってはいるもののここの説明が割と段階を追って説明してくれてるので、この問題の理解の助けになるんじゃないかなと思います。
３０分間ネットワーキング：第６回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