arashi1977さんの助け合いフォーラム投稿一覧
問題文には HTTPS とあるのに、正答が HTTP となっている。選択肢も HTTPS じゃないとおかしいのではないか？というご質問であっていますか？
上記の前提でコメントしますが、「HTTP プロトコルをセキュアにやり取り可能にできるよう TLS トンネル経由で通信するもの」が HTTPS です。この設問で言及されている HTTP 認証とは HTTP Basic 認証のことですので、HTTP/HTTPS どちらでも動作します。
この辺りは、以下の文書で規定されているので、ご興味があればご確認ください。
https://datatracker.ietf.org/doc/html/rfc9110#section-4.2.2
https://datatracker.ietf.org/doc/html/rfc7617
疑問点を誤読していないか確認なのですが、extended や standard の後ろに数字が来ているのがおかしい、ということでしょうか？
それであっていればですが、以下のように数字でも名前でも指定は可能です。
R1(config)#ip access-list standard ?
<1-99> Standard IP access-list number
<1300-1999> Standard IP access-list number (expanded range)
WORD Access-list name
R1(config)#ip access-list extended ?
<100-199> Extended IP access-list number
<2000-2699> Extended IP access-list number (expanded range)
WORD Access-list name
ご質問の内容が読み取れない部分があるので確認させてください。
192.168.1.0/24はospfでは外部経路であり、0 E2とかで学習されるはず。R3ではredistributeコマンドにおいてmatchで条件を絞っていないため、デフォルトで外部経路の再配送はしないはず
- 「R3 では…条件を絞っていない」というのは、OSPF -> RIP のことを意図していますか？つまり、「OSPF は E1/E2/N1/N2 経路をそのままでは他のプロトコルに再配送しない」という意味であっていますか？（RIP 側のはなしではない？）
- 上記の前提で、私のほうで「デフォルトで外部経路の再配送はしない」という例を探してみたのですが、見つけられませんでした。根拠とされたドキュメントまたは実機での例をご提示いただけないでしょうか？
ospfではdestribute-listコマンドにout方向は適応できませんよね?
そこの認識はあっていますでしょうか？
私の手元の環境では適用できるようですが、ご認識の根拠となる情報があればご提示いただけないでしょうか？
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#router ospf 1
R1(config-router)#distribute-list ?
<1-199> IP access list number
<1300-2699> IP expanded access list number
WORD Access-list name
gateway Filtering incoming updates based on gateway
prefix Filter prefixes in routing updates
route-map Filter prefixes based on the route-map
R1(config-router)#distribute-list 1 ?
in Filter incoming routing updates
out Filter outgoing routing updates
設問の表現が曖昧（というか初学者向きにあえて、かもしれませんが）に見えるせいかなと思いますが
linuxのtracerouteコマンドがデフォルトで使用するプロトコルはICMPではなくUDPであるため、答えが絞れないのではないでしょうか。
問題文に記載されているのが traceroute のみであればご指摘の通りかなと思いますが、設問は「pingやtracerouteコマンド」とあるのでどちらにも合うものという観点で見るべきかなと思います。
traceroute プローブ（探査用）は UDP/ICMP どちらかを選択できますが、探査の結果には ICMP 応答メッセージを利用するので、ICMP が間違いだということはありません。その上で、ping は ICMP Echo / Echo Reply を使っているので、どちらにも適合する「ICMP」が正答だと絞れるかなと思います。
https://nxmnpg.lemoda.net/ja/8/traceroute
traceroute は IP プロトコルの `time to live' フィールドを利用して、 あるホストまでの経路上の全てのゲートウェイから ICMP TIME_EXCEEDED レスポンス を引き出そうと試みます。
そもそも設問の図に
※SwitchとPCの接続はアクセス、Switch同士の接続はトランク
の記載があるので
設問で示されているCLIの範囲ではGi0/1、Gi0/2についての設定が行われているかどうかは、はっきりと判断できないように感じました。
については「はっきりと判断できる」かなぁと思いました。
MED の誤答解説にもありますが
なお、異なるASからの情報を比較させたい場合は「bgp always-compare-med」コマンドを使用します。
という話です。
65004 -> 65001 の経路を制御するということは、65001から広報する経路が65004 で受け取った時にどう見えるかという話なので、受け取った 65004 での制御である bgp always-compare-med の設定が「65004で」必要になるということですね。
bgp always-compare-med が設定されていない場合は、65002/65003双方で（MEDに関する）設定が変更されていたとしても AS65004 は MED を比較対象としないので、意味がないんですよね…
上記の２つの違いをお聞きしたいです。
解説の
以下はrpmコマンドのインストール関連の主なオプションです。
の表に違いが書いてありますが、それでは説明が足りないということでしょうか？もしそうであれば聞きたいことをもう少し具体的に教えていただけないでしょうか？
「192.168.1.1以外を拒否するACLはVTYに適用されていない」という理由で不正解となっていますが、沈黙のdenyによって拒否されるのではないでしょうか？
- 「沈黙（ちんもく）」ではなく、「暗黙（あんもく）」ですね (^^;
- 暗黙の deny は「アクセスリストの最後に存在する、何にもマッチしなければ最終的に deny とする」ものであって、ACL が適用されていない時点で暗黙の deny も発動しないのです。じゃないと、「全ての ACL を適用していないものは暗黙の deny によって拒否される」ということになり、インターフェースだろうがルーティングプロトコルの経路フィルタだろうが何も ACL を適用しなかったら全て拒否されるという非常に運用が辛いものになってしまいますね…
どちらも正しいです。ip vrf forwarding は IPv4 のみ対応、vrf forwarding は IPv4/IPv6どちらにも対応しているものです。
使い分けるとするならですが、マルチプロトコル対応する必要があるか、VRF 定義の時点でどちらが設定されているかによるかと思います。
それぞれこういう設定になります。
ip vrf 版
ip vrf VRF_NAME_only_v4
!
interface GigabitEthernet0/0
ip vrf forwarding VRF_NAME_only_v4
ip address 192.168.1.1 255.255.255.0
ipv6 address 2001:DB8::1/64
vrf definition 版
vrf definition VRF_NAME_v4
!
address-family ipv4
exit-address-family
!
interface GigabitEthernet0/1
vrf forwarding VRF_NAME_v4
ip address 192.168.1.1 255.255.255.0
!
vrf definition VRF_NAME_v6
!
address-family ipv6
exit-address-family
!
interface GigabitEthernet0/2
vrf forwarding VRF_NAME_v6
no ip address
ipv6 address 2001:DB8::1/64
vrf definition 版は、紐づけたVRFで有効にされていないアドレスファミリは無効になります。たとえば、上記の設定で GigabitEthernet0/1 で IPv6 設定を入れるとエラーになります。GigabitEthernet0/2 で IPv4 設定入れた場合も同様です。
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#interface GigabitEthernet0/1
Router(config-if)#ipv6 address 2001:db8::1/64
%GigabitEthernet0/1 is linked to a VRF. Enable IPv6 on that VRF first.
Router(config-if)#exit
Router(config)#interface GigabitEthernet0/2
Router(config-if)#ip address 192.168.1.1 255.255.255.0
%GigabitEthernet0/2 is linked to a VRF. Enable IPv4 on that VRF first.
あー、これは問題ID:7753の解説の
Southbound Interface（SBI）はネットワーク機器とコントローラが通信するインターフェースです。
が誤解の元ですかね。「ネットワーク機器とコントローラが通信する」というのは厳密には「コントローラがネットワーク機器を制御するための」なんですよね。つまり、「コントローラ発信」となるものです。そしてこの時の SNMP は SNMP Request によって制御するものです。
対して、8450では
ネットワーク機器がCisco DNA Centerに情報を通知するのに使う
と「ネットワーク機器発信」となるものを回答させるようになっています。この場合の SNMP は SNMP Trap です。ネットワーク機器が自発的に発信するものであり、7753 で正解とされている SNMP とはちょっと違うものなんですよね。
すでに学習済みかもしれませんが、この SNMP の違いについては問題ID:16456をご確認いただくと良いかと思います。
こういう話ですよね。
# TYPE DATABASE USER ADDRESS METHOD
host postgres all web1 md5 # Web サーバ1号機からの接続を許可
host postgres all web2 md5 # Web サーバ2号機からの接続を許可
# host debug-db all web2 md5 # 動作確認のために web2 から debug-db に接続できるようにするための設定行
host debug-db all devel md5 # Debug DB へは devel ホストからのみ接続を許可
Method に該当する md5 の記述以降に「「#」が記載されている」行が4つありますが、先頭に # がない「行」はコメントとして扱われないですね。（もうちょっと厳密にいうと、「その行の # 以降がコメントとして扱われる」です）
対して、3行目の debug-db に web2 から接続可能にするための設定行は「先頭に #」があるためにその行自体がコメント扱いになります。
ご質問の元になった
「pg_hba.conf」に「#」が記載されている場合はその行をコメントとして扱う
は、その記載のとおり（そしてご認識の通り）「先頭」「で始まる」などの記載がないので、必ずしも「その行」がコメントとして扱われるわけではないから正解にならない、ということですね。
（AI の回答、雑だなぁ… 😓）
pkill mycommand だと mycommand は終了されて、 mycommand2,mycommand3 は終了されないのではと思いました。
うーんそれだと例えば、grep ping-t *.txt ってやった時に、「mondai.ping-t.com や ping-t.com がマッチするみたいだが、ping-t だけがマッチしないとおかしい」と言ってるのと同じ話だと思うんですよね。
pkill（とか pgrep）のマッチは grep と同じイメージで捉えると良いです。
https://nxmnpg.lemoda.net/ja/1/pkill
ですので、
質問①そもそも [pkill mycommand]のどこに拡張正規表現があるのでしょうか。
特にメタキャラクタなどが含まれていなくても mycommand 自体が拡張正規表現ということに問題はありません。
質問②pkill mycommand で [mycommand]を「含む」プロセスを終了するという意味になるのでしょうか。
上記 grep の例と同様、「という意味になる」ものです。
参考に記載がある通り、kyoya0201 さんのご認識で特に間違っていないかと思います。
【スイッチの動作】
スイッチは フレームを受信すると、 送信元MACアドレスを学習します。
そういうもの、以外に言いようがなくて申し訳ないですが、少なくとも DMS の「ソースにできる」ものとしては記載がないようです。
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Introduction.Sources.html
（すみません、Packet Tracer は使っていないので別の知識でコメントしてます）
Packet Tracer はシミュレーターであり、実機とは異なる挙動をすることがあるという前提があるとしてですが、出力の以下の点が気になりました。
Sw1#show interfaces fa0/1
FastEthernet0/1 is down, line protocol is down (disabled)
ただの down / down ではなく (disabled) となっているので、Duplex の話ではなく Spanning-tree の機能で err-disable にされてしまっている（本来は up / up だが、その後 down / down に させられている ）のではないでしょうか？
以下のドキュメントでも、err-disable の原因の一つとして「Duplex の不一致」が挙げられています。
https://www.cisco.com/c/ja_jp/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html#toc-hId--1588818600
この機能が最初に実装されたのは、スイッチの 1 つのポートで過剰コリジョンやレイト コリジョンが検出されるような、特殊なコリジョン状態を処理するためでした。
(略)
一般的に、これらのエラーの原因には、次のようなものがあります。
(略)
二重モードの不一致