arashi1977さんの助け合いフォーラム投稿一覧
トリッキーなのではなく、正しく規定を理解できているかを問われている問題なのだと思います。
bold（太字）のためのタグではないよ、ということですかね。そういう「見た目」については CSS で定義すべきものであり、文書構造を定義する HTML タグの持つべき役目ではないということを問われているのかなと。
HTML Standard でも以下のように記載されています。
https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-b-element
The b element represents a span of text to which attention is being drawn for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood, such as key words in a document abstract, product names in a review, actionable words in interactive text-driven software, or an article lede.
個人的には日本語の方が読みやすいので、こちらの方が嬉しいかな。
https://momdo.github.io/html/text-level-semantics.html#the-b-element
b要素は、たとえば、文書の概要でのキーワード、レビューでの製品名、対話的なテキスト駆動型ソフトウェアでの使用可能語、または記事リードなど、特別な重要性を伝えることなく、代わりの声やムードの意味合いなしに、実用的な目的に対して描かれている注目すべきテキストの範囲を表す。
ここでは太字（強調）のために使うものではないとも明確に書かれてるんですよね。
他により適切な要素がない場合に、b要素は最後の手段として使用すべきである。具体的には、見出しはh1からh6までの要素を使用すべきであり、 強調はem要素を使うべき であり、重要性はstrong要素で表されるべきであり、 テキストのマークまたは強調は、mark要素を使用すべき である。
今手元に環境がないので検証できてはいないのですが、問題文と選択肢の意図を汲み取るとするなら、
- 「どうすれば良いか→fstabに記述する」だと「ファイルに書いただけでは何も起きないでしょ」ということ？
- 設問は「mount.cifsコマンドで」とあるので、
mount.cifsコマンドによるマウントを行う場合にということ？
かなぁとは思うのですが、誤答選択肢の解説からはそこまでは読み取れませんね…うーん。
mount.cifs での直接マウント時にオプション省略しても /etc/fstab の設定内容を持ってくるんだっけ？によると思うので、後で確認してみようと思います。
IPv4 のスタティックルーティングの設定は学習されていますか？
IPv6 も同じで、宛先「ネットワーク」を指定するので /64 の範囲までが記述されていれば良いのです。ですので、 2001:db8:1:2 以降は未指定（ :: ）で何も問題はないです。
IPv4 でいう、 192.168.1.0 255.255.255.0 と同じようなことです。
４．ルーティングの宛先になれない
これは参考として提示された先の情報でいう以下の部分ですね。
prefix/length
宛先ネットワークとそのプレフィックス長の指定
ルーティングの「宛先」であって、「ネクストホップ」ではないのです。
宛先（Destination）として指定すると以下のようにエラーになります。
Router(config)#ipv6 route fe80:1:2:3::1/128 g0/0
% Invalid prefix
逆にRBはダウンしたネットワークと直接接続しており、ルーティングテーブルには直接接続ルートを保持しているためqueryを送信する必要はないのではないか、とも思いました。
ここが誤認の元でしょうか。
設問では
「172.16.1.0/24」のネットワークがダウンした場合の動作はどれか。
とあり、ダウンすることで RB の直接接続ルートがなくなるから「他に誰か 172.16.1.0/24 NW への到達性がある人いますかー」って RB がきくわけですね。RA は RB から学習していたのが RB から広報されなくなるので「誰も教えてくれなくなったなぁ」って思って経路情報を消すだけなのです。（RB からの Query に「俺は到達できないぞ」って Reply は返しますが）
それらしいトポロジ作って RB で 172.16.1.0/24 をダウンさせた時の RA/RB で取得した debug eigrp fsm と debug eigrp packets terse です。
RA#
*Oct 19 11:12:15.637: EIGRP: Received QUERY on Gi0/0 - paklen 44 nbr 192.168.2.2 ←ここで Query を Receive しているが、Sendはしていない
*Oct 19 11:12:15.637: AS 1, Flags 0x0:(NULL), Seq 23/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 19 11:12:15.638: EIGRP: Enqueueing ACK on Gi0/0 - paklen 0 nbr 192.168.2.2 tid 0
*Oct 19 11:12:15.638: Ack seq 23 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 19 11:12:15.639: DUAL: AS(1) rcvquery: 172.16.1.0/24 via 192.168.2.2 from 192.168.2.2 metric 72057594037927935/72057594037927935, RD is 3072 for tid 0
*Oct 19 11:12:15.639: EIGRP-IPv4(1): Find FS for dest 172.16.1.0/24. FD is 3072, RD is 3072 on tid 0
*Oct 19 11:12:15.640: EIGRP-IPv4(1): 192.168.2.2 metric 72057594037927935/72057594037927935 not found Dmin is 72057594037927935
*Oct 19 11:12:15.640: DUAL: AS(1) Peer total 1 stub 0 template 1 for tid 0
*Oct 19 11:12:15.641: DUAL: AS(1) Dest 172.16.1.0/24 (Split Horizon) not entering active state for tid 0.
*Oct 19 11:12:15.641: DUAL: AS(1) Send REPLY(r1/n1) about 172.16.1.0/24 to 192.168.2.2 for tid 0
*Oct 19 11:12:15.643: EIGRP: Sending ACK on Gi0/0 - paklen 0 nbr 192.168.2.2 tid 0
*Oct 19 11:12:15.643: AS 1, Flags 0x0:(NULL), Seq 0/23 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 19 11:12:15.651: EIGRP: Enqueueing REPLY on Gi0/0 - paklen 0 nbr 192.168.2.2 tid 0 iidbQ un/rely 0/1 peerQ un/rely 0/0 serno 18-18
*Oct 19 11:12:15.653: EIGRP: Requeued unicast on GigabitEthernet0/0
*Oct 19 11:12:15.656: EIGRP: Sending REPLY on Gi0/0 - paklen 44 nbr 192.168.2.2 tid 0
*Oct 19 11:12:15.656: AS 1, Flags 0x0:(NULL), Seq 12/23 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1 serno 18-18
*Oct 19 11:12:15.663: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 192.168.2.2
*Oct 19 11:12:15.664: AS 1, Flags 0x0:(NULL), Seq 0/12 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 19 11:12:15.665: DUAL: AS(1) Removing dest 172.16.1.0/24, nexthop 192.168.2.2
*Oct 19 11:12:15.665: DUAL: AS(1) No routes. Flushing dest 172.16.1.0/24
RB#
*Oct 19 11:12:15.319: EIGRP-IPv4(1): rcvupdate: 172.16.1.0/24 via Connected metric 72057594037927935/72057594037927935 on tid 0
*Oct 19 11:12:15.319: EIGRP-IPv4(1): Find FS for dest 172.16.1.0/24. FD is 512, RD is 512 on tid 0 ←フィーじぶるさくせさがいない
*Oct 19 11:12:15.320: EIGRP-IPv4(1): 0.0.0.0 metric 72057594037927935/72057594037927935 not found Dmin is 72057594037927935
*Oct 19 11:12:15.320: DUAL: AS(1) Peer total 2 stub 0 template 1 for tid 0
*Oct 19 11:12:15.321: DUAL: AS(1) Dest 172.16.1.0/24 entering active state for tid 0. ← 172.16.1.0/24 を Active にする
*Oct 19 11:12:15.321: EIGRP-IPv4(1): Set reply-status table. Count is 1.
*Oct 19 11:12:15.321: EIGRP-IPv4(1): Not doing split horizon. Query stub suppressed
*Oct 19 11:12:15.331: EIGRP: Enqueueing QUERY on Gi0/0 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 16-16
*Oct 19 11:12:15.333: EIGRP: Sending QUERY on Gi0/0 - paklen 44 tid 0 ← Query 送信
*Oct 19 11:12:15.334: AS 1, Flags 0x0:(NULL), Seq 23/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 16-16
*Oct 19 11:12:15.335: EIGRP: Enqueueing QUERY on Gi0/1 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 16-16
*Oct 19 11:12:15.341: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 192.168.2.1
*Oct 19 11:12:15.342: AS 1, Flags 0x0:(NULL), Seq 0/23 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 19 11:12:15.342: EIGRP: GigabitEthernet0/0 multicast flow blocking cleared
*Oct 19 11:12:15.355: EIGRP: Received REPLY on Gi0/0 - paklen 44 nbr 192.168.2.1
*Oct 19 11:12:15.355: AS 1, Flags 0x0:(NULL), Seq 12/23 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 19 11:12:15.356: EIGRP: Enqueueing ACK on Gi0/0 - paklen 0 nbr 192.168.2.1 tid 0
*Oct 19 11:12:15.356: Ack seq 12 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 19 11:12:15.357: EIGRP-IPv4(1): dest(172.16.1.0/24) active
*Oct 19 11:12:15.357: EIGRP-IPv4(1): rcvreply: 172.16.1.0/24 via 192.168.2.1 metric 72057594037927935/72057594037927935 for tid 0
*Oct 19 11:12:15.357: EIGRP-IPv4(1): reply count is 1
*Oct 19 11:12:15.358: DUAL: AS(1) Clearing handle 0, count now 0
*Oct 19 11:12:15.358: DUAL: AS(1) Freeing reply status table
*Oct 19 11:12:15.358: EIGRP-IPv4(1): Find FS for dest 172.16.1.0/24. FD is 72057594037927935, RD is 72057594037927935 on tid 0found
*Oct 19 11:12:15.359: DUAL: AS(1) Removing dest 172.16.1.0/24, nexthop 0.0.0.0
*Oct 19 11:12:15.359: DUAL: AS(1) Removing dest 172.16.1.0/24, nexthop 192.168.2.1
*Oct 19 11:12:15.359: DUAL: AS(1) Send update about 172.16.1.0/24. Reason: rt net gone on tid 0
*Oct 19 11:12:15.359: DUAL: AS(1) Send update about 172.16.1.0/24. Reason: lost if on tid 0
*Oct 19 11:12:15.361: EIGRP: Sending ACK on Gi0/0 - paklen 0 nbr 192.168.2.1 tid 0
*Oct 19 11:12:15.361: AS 1, Flags 0x0:(NULL), Seq 0/12 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 19 11:12:15.369: EIGRP: Enqueueing UPDATE on Gi0/1 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 17-17
*Oct 19 11:12:15.370: EIGRP: Enqueueing UPDATE on Gi0/1 - paklen 44 nbr 192.168.3.2 tid 0 iidbQ un/rely 0/0 peerQ un/rely 0/0 serno 17-17
*Oct 19 11:12:15.372: EIGRP: Sending UPDATE on Gi0/1 - paklen 44 tid 0
*Oct 19 11:12:15.372: AS 1, Flags 0x0:(NULL), Seq 25/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 17-17
*Oct 19 11:12:15.375: EIGRP: Received ACK on Gi0/1 - paklen 0 nbr 192.168.3.2
*Oct 19 11:12:15.376: AS 1, Flags 0x0:(NULL), Seq 0/25 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 19 11:12:15.376: EIGRP: GigabitEthernet0/1 multicast flow blocking cleared
*Oct 19 11:12:15.376: DUAL: AS(1) No routes. Flushing dest 172.16.1.0/24
*Oct 19 11:12:17.313: %LINK-5-CHANGED: Interface Loopback0, changed state to administratively down
*Oct 19 11:12:18.313: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback0, changed state to down
指定したアドレス範囲が適切かとかをチェックしたりするのが主な目的なのかなぁと思っています。開始、終了アドレスが異なるネットワークになるようにわざと設定すると以下のようなエラーが出たりします。
Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#ip nat pool POOL1 10.0.0.1 10.0.0.65 netmask 255.255.255.255
%Pool POOL1 mask 255.255.255.255 too small; should be at least 255.255.255.128 ←ここ
%Start and end addresses on different subnets
コマンドリファレンスで見ても、
プールアドレスが属するネットワークのネットワークマスクを指定します。
としか書いてないので、pool の範囲の妥当性を見るためなのかなと。
https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst9500/software/release/17-12/command_reference/b_1712_9500_cr/ip_addressing__services_commands.html#wp6064781280
ここの理解は正しいのに結論が間違ってますね。
各RID(IP)は下記であるかと思うのですが、その場合RAがDRではないのでしょうか？
RA:10.1.1.100/24
RB:10.1.3.2/24
第1、第2オクテットは同じで、第3オクテットが RA:1 < RB:3 なので、RBの方がRIDが大きいと言えます。ブロードキャストドメイン内でDR選出のポイントはRIDの大きさであり、前述の通り「RBの方が大きい」ので、RA-RB間の 10.1.1.0/24 ネットワークでは DR:RB, BDR:RA となるのです。
ちなみに AI アシスタントの
画像を確認しました。RAは通常のブロードキャストネットワークで動作しており、IPアドレスが10.1.1.100と設定されています。一方、RBのIPアドレスは10.1.1.2です。
はトポロジの 10.1.1.0/24 ネットワークに属するインターフェースのことしか見ていなくて、RBのコンフィグからRBのルータIDが何になるかまでは読み取れなかったんじゃないかなぁと思います ^^;
これ、誤解しやすいんですよねぇ…と思いつつ、
正しくはログレベル以上ではないでしょうか。
このように判断された根拠となる情報もつけていただけると、相互理解が進みやすくなるのでありがたいです。
参考に
それぞれのレベルはその下の全てのレベルを含みます。レベルを低くする程、より少ないメッセージがログに送られます。
とあるので、「以上＝より多いメッセージ」を意味しますので、解説は正しいですよ。
レベルの数字についてはこちらにも記載があります。
Wikipedia「syslog」の「重大度」
https://ja.wikipedia.org/wiki/Syslog#%E9%87%8D%E5%A4%A7%E5%BA%A6%E3%83%AC%E3%83%99%E3%83%AB
3(Error)を指定すると、よりレベルの低い2(Critical)/1(Alert)/0(Emergency)が出力されるが、より高い4(Warning)や5(Notice)は表示されない、と言うことです。またこのことから、最もレベルの大きい7(Debug)を指定すると、syslogに送られる全て（7以下）のメッセージがログ出力されるようになる、と言うことでもあります。
どの問題IDに関するご質問かがわからないので、ご質問の意図を読み違えていたらすみません。
例えば、インスタンスから意図しない通信が開始してしまった場合、デフォルトだとアウトバンドは許可されているので、それがインターネット宛に出ていってします。ステートフルなので、この通信は帰ってきてセキュリティグループでフィルタ出来ないということでしょうか。
そうですね、基本的には「許可されたアウトバウンドトラフィックに対する戻りのインバウンドトラフィックは許可」される認識で良いかと思います。
回答に対しての返信ではなく追加質問にされているので、別の回答としてぶら下げます。
Outbounding付近のルーティングについては、
複数のNICを使い、相手のipアドレスによって使用するNICを振り分けしている感じでしょうか。
102、201範囲の「ルーティング」に関するところをもう少し補強した方が良いのかもしれませんね。時間や余裕があればCCNAの学習で「ルーティング」に関する基本だけでも押さえると理解度が上がると思います。
ルーティングは
- 自分が受信したパケットを自分が受け取るべきか別の誰かに転送（ルーティング）するべきか
- パケットをどのインターフェースからどのアドレスに（ルーティング）送信すべきか
の２パターンで発動します。前者の場合は「転送すべき」となった時点で「どのインターフェースからどのアドレス向けに出力するか」が決まっているので FORWARD チェインの後では実行されません。対して OUTPUT の前の段階では、ローカルプロセスがパケットを生成しただけで、まだ「どのインターフェースからどのアドレス向けに出力するか」が決まっていません。OSはプロセスから「パケットを受け取ってから」ルーティング処理を行い、どのインターフェースから出すのかを決定します
複数の NIC は物理的なものに限りません。 veth とか lo とか br とかの仮想インターフェースでも同じことです。
CDP(Cisco Discovery Protocol) はその名の通り「隣接しているCiscoデバイスの情報を確認」するためのシスコ独自のプロトコルです。
対してLLDP(Link-Layer Discovery Protocol) は IEEE 802.1AB で規定された「標準」プロトコルであり、シスコ以外のベンダーも実装して利用しています。
使い分けたいかどうかは環境によると思います。全部シスコ製品だから CDP 使う、でもいいですし、シスコも含むマルチベンダーで構成しているから LLDP を使う、とか。オールシスコだけど標準準拠でいきたいから LLDP ってのもありですね。
サーバ自身宛か、別のホストへ転送すべきものかを判断するための「ルーティング」ですね。サーバだからといって受け取る全てのパケットが「自分自身宛」とは限りません。
ARPテーブルってARP(Address Resolution Protocol)によって解決した情報を記録してあるものですよね。で、ARPが何のためにあるかって、「あるIPアドレスを持つ装置のMACアドレス」を知りたいからですよね。その目的って「IPで通信するために、IPパケットの送信先になるMACアドレスを知る」ことです。
で、今回の話で言うと「L2スイッチ自体が誰かとIPで通信する」場合にはARPが必要ですしそのためのARPテーブルを持つわけですが、それがない前提ですよね？（スイッチは基本的にL2フレームをスイッチングするだけなので、IPで通信するものではない）
また、「（DHCPスヌーピング）バインディングデータベースがARPテーブルと同一視できるか」と言うお話であれば、DHCPどこいった？って話になりますよね。
と言うことで結局は
単に用途の違い
と言うことになるかなぁと思います。
攻撃元が異なるアドレスに切り替わったとしても、そのアドレスからの「過剰な」リクエストレートを判断基準にしているので特に問題ないと思うのですが…
もしよければ ksjym2 さんが「適切」と思われるこの問題の他の選択肢とその理由をお聞かせいただけないでしょうか？