arashi1977さんの助け合いフォーラム投稿一覧
4 のようなことはできます。Ethernet 系のインターフェースでも指定可能ですよ。
「どのインターフェースから出力するか」の指定であって、ポイントツーポイントかは排除条件にならないです。
- 到達性はありますね。
- ネットワークルートでアドバタイズしたいかどうかは要件次第な気がしますね。例えば検証のためにホストルートではなくネットワークルートがアドバタイズしたいとか。
単なるコメントですみません。
設問に
ソリューションアーキテクトが推奨するキューの構成
という条件があったので気になったのですが
FIFOキューに有料会員のデータ、標準キューに無料会員のデータを処理すれば、受信側はFIFOキューから優先して受信すればいいだけです。
だと、リクエスト数によっては正答選択肢よりも高額（FIFOキューの方が同じリクエスト数で1.25〜1.45倍高い）になる点は気にしなくて良いでしょうか？（解説でも言及されていないので気にしないで良いのかもしれませんが）
https://aws.amazon.com/jp/sqs/pricing/
他の問題で「これでもできるがコスト的に不適切」みたいなのがあった気がしたので、そういう観点も気にした方が良いのかなと思いまして。
「ロンゲストマッチ」とは、「IPパケットの宛先（Destination）アドレスと経路情報のマッチングにおいて、より長くマッチするものを選択する」というものです。たとえば
- 10.0.0.0/8
- 10.10.0.0/16
- 10.10.10.0/24
の経路情報がある状態で、以下のそれぞれのパケットはどれにマッチするかという話です（それぞれ1, 2, 3にマッチ）。
10.20.30.40 宛、 10.10.100.100 宛、 10.10.10.10 宛
ご質問の問題ID: 33556 は「192.168.30.0/24のスタティックルート（ネクストホップ:192.168.10.2）がすでに設定されている状況で、同じ宛先ネットワーク192.168.30.0/24で異なるネクストホップ（192.168.20.2）のスタティックルートを設定したらどうなるか」というものです。ここでもしロンゲストマッチを考慮するとしたら 192.168.30.0/24 が同じかどうか、ぐらいでしょうか。
Fa3/0が正解だと思うですけど、答えがFa2/0になります。
なぜ Fa3/0 が正解だと思ったのかを教えていただけませんか？また、 Fa2/0 が正解の理由、Fa3/0 が不正解の理由が解説に記載がありますがその解説のどのあたりが間違えていると判断されたのかも教えていただけると、「正規の答え」を探す手掛かりになるのではないかと思います。
参考でも以下のように記載されてますし、機種やバージョンによるものかなと思います。
学習したMACアドレスは、MACアドレステーブルで管理されます。MACアドレステーブルは以下のコマンドで表示できます。
#show mac address-table
（機種によっては #show mac-address-table）
トリッキーなのではなく、正しく規定を理解できているかを問われている問題なのだと思います。
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が何になるかまでは読み取れなかったんじゃないかなぁと思います ^^;