arashi1977さんの助け合いフォーラム投稿一覧

助け合いフォーラムの投稿
2024/10/26 返信
b要素

トリッキーなのではなく、正しく規定を理解できているかを問われている問題なのだと思います。
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要素を使用すべき である。

2024/10/23 返信
「/etc/fstab」ファイルに、マウントする共有の情報を記述する が誤りの理由

今手元に環境がないので検証できてはいないのですが、問題文と選択肢の意図を汲み取るとするなら、

  • 「どうすれば良いか→fstabに記述する」だと「ファイルに書いただけでは何も起きないでしょ」ということ?
  • 設問は「mount.cifsコマンドで」とあるので、 mount.cifs コマンドによるマウントを行う場合にということ?

かなぁとは思うのですが、誤答選択肢の解説からはそこまでは読み取れませんね…うーん。

mount.cifs での直接マウント時にオプション省略しても /etc/fstab の設定内容を持ってくるんだっけ?によると思うので、後で確認してみようと思います。

2024/10/22 コメント
宛先
問題ID:8340 とこのご質問との関連性がちょっとわからないのですが、まず選択肢および kunitir さんの投稿にある通りに設定すると、 `::2/64` は `::/64` に勝手に置き換えられます。 ``` Router#show running-config interface GigabitEthernet0/0 Building configuration... Current configuration : 126 bytes ! interface GigabitEthernet0/0 no ip address duplex auto speed auto media-type rj45 ipv6 address 2001:DB8:1:1::1/64 end Router#conf t Enter configuration commands, one per line. End with CNTL/Z. Router(config)#ipv6 route 2001:db8:1:2::2/64 2001:db8:1:1::2 Router(config)#end Router# *Oct 22 10:32:06.402: %SYS-5-CONFIG_I: Configured from console by console Router#show ipv6 route static IPv6 Routing Table - default - 4 entries Codes: C - Connected, L - Local, S - Static, U - Per-user Static route B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP H - NHRP, I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea IS - ISIS summary, D - EIGRP, EX - EIGRP external, NM - NEMO ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1 OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2 la - LISP alt, lr - LISP site-registrations, ld - LISP dyn-eid lA - LISP away, a - Application S 2001:DB8:1:2::/64 [1/0] via 2001:DB8:1:1::2 Router# ``` これはコマンド投入時に `/64` をつけている時点でホスト単位のルーティング( `/128` )ではないことが明らかであるため、ネットワークアドレス部だけが有効な値として扱われるためです。 「ホスト単位で」ということを重視されるのであれば、プレフィックス長が `/128` かどうかについても留意されると良いかと思います。
2024/10/22 返信
宛先

IPv4 のスタティックルーティングの設定は学習されていますか?
IPv6 も同じで、宛先「ネットワーク」を指定するので /64 の範囲までが記述されていれば良いのです。ですので、 2001:db8:1:2 以降は未指定( :: )で何も問題はないです。

IPv4 でいう、 192.168.1.0 255.255.255.0 と同じようなことです。

2024/10/21 コメント
ホールドタイムと登録タイムはどの機器に設定するのか?
あ、それです。そういうことです。 今の CCNP で DMVPN のフェーズまでやるという認識がなかったので言及しませんでしたが、Png273_009 さんのご認識の通りです。
2024/10/20 返信
IPv6のリンクローカルアドレスについて

4.ルーティングの宛先になれない

これは参考として提示された先の情報でいう以下の部分ですね。

prefix/length
 宛先ネットワークとそのプレフィックス長の指定

ルーティングの「宛先」であって、「ネクストホップ」ではないのです。
宛先(Destination)として指定すると以下のようにエラーになります。

Router(config)#ipv6 route fe80:1:2:3::1/128 g0/0
% Invalid prefix
2024/10/19 返信
RA側のqueryについて

逆に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 fsmdebug 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
2024/10/19 返信
netmask 255.255.255.0

指定したアドレス範囲が適切かとかをチェックしたりするのが主な目的なのかなぁと思っています。開始、終了アドレスが異なるネットワークになるようにわざと設定すると以下のようなエラーが出たりします。

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

2024/10/17 コメント
ホールドタイムと登録タイムはどの機器に設定するのか?
基本的に、holdtime って「無効と判断するまでの猶予時間」を設定するものなので、その情報を渡す人が設定するものなので、そう言う意味では NHS / NHC 両方で設定できるのは間違いないのですが、設定によって期待される挙動は変わるかなと思っています。 手元で検証してる途中なのですが、少なくともNHRP shortcut(Hub を介さない)が有効な場合は NHC 同士で直接 NHRP の情報を交換する(Resolution Request/Reply)ことになるので、NHS 側の hold-time 設定は効果がないんじゃないかなぁと思っているところです。
2024/10/15 返信
RAがBDRとなる理由がわかりません…

ここの理解は正しいのに結論が間違ってますね。

各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が何になるかまでは読み取れなかったんじゃないかなぁと思います ^^;

2024/10/14 コメント
VPCのデフォルトのセキュリティグループのルールについて
考慮すべきポイントがいろいろ混ざっているようなのでひとつずつ整理すべきかなと言うところではあります。 前提として、ご質問の冒頭にあるように > VPCのセキュリティグループのデフォルトのルールでは「インバウンドは全て拒否、アウトバンドは全て拒否」かと思います。ルールも許可設定しかできないはずです。 ですので、基本的には許可制であり、許可されていないものは通さないわけです。そして同様に冒頭でご認識されている通り > デフォルトだとアウトバンドは許可されている ので、ここをきちんと「不許可」とすれば良いわけです。 また、「本来この通信のみが自発かつ想定される通信パターン」と言う前提でセキュリティグループの設定をするわけですから、それ以外のトラフィックが通らないように「デフォルト許可」を編集して意図しない自発トラフィックが出て行かないようにするのも大事な対応かと思います。 さらに言えば「そのような想定外の自発トラフィックを発生させるプロセス」が存在しないようにサービスを作り込む、と言うのも必要なことかなと思います。不正プロセスが組み込まれるとしたら EC2 インスタンスがありそうですが、その場合は検知して即インスタンスをイメージから作り直すことで不正プロセスが稼働していない状態にするとか、インスタンスの元イメージの改ざんをさせないことでインスタンス生成後即時不正プロセス起動といったことが起こらないようにするとか、いろんな観点で「そもそも意図しないアウトバウンドトラフィックが発生しない」ように対策するというのが必要になる、と言うことではないかなと思います。
2024/10/14 返信
問題文誤り?

これ、誤解しやすいんですよねぇ…と思いつつ、

正しくはログレベル以上ではないでしょうか。

このように判断された根拠となる情報もつけていただけると、相互理解が進みやすくなるのでありがたいです。

参考に

それぞれのレベルはその下の全てのレベルを含みます。レベルを低くする程、より少ないメッセージがログに送られます。

とあるので、「以上=より多いメッセージ」を意味しますので、解説は正しいですよ。
レベルの数字についてはこちらにも記載があります。

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以下)のメッセージがログ出力されるようになる、と言うことでもあります。

2024/10/13 コメント
VPCのデフォルトのセキュリティグループのルールについて
> ということは、セキュリティグループのみを使って通信をフィルタしきることは難しいのでしょうか? 具体的にどのようなことをイメージされているかがわからないのでコメントできません。お役に立てずすみません。
2024/10/12 返信
VPCのデフォルトのセキュリティグループのルールについて

どの問題IDに関するご質問かがわからないので、ご質問の意図を読み違えていたらすみません。

例えば、インスタンスから意図しない通信が開始してしまった場合、デフォルトだとアウトバンドは許可されているので、それがインターネット宛に出ていってします。ステートフルなので、この通信は帰ってきてセキュリティグループでフィルタ出来ないということでしょうか。

そうですね、基本的には「許可されたアウトバウンドトラフィックに対する戻りのインバウンドトラフィックは許可」される認識で良いかと思います。

2024/10/09 コメント
屁理屈かもしれませんが・・・
横から失礼します。 ホスト型でもハイパーバイザ型でも、tomomo1109さんのコメントに変わりはないです。 - Linux KVM(ハイパーバイザ) 上で、Linux / Windows / FreeBSD などといった異なるOSを稼働できるが、それらのOSは KVM を動かしている Linux OS を共有しているわけではなく、Linux OS が稼働するハードウェアリソースを共有している。 - Windows 上の VMware Workstation で Linux / Windows / FreeBSD などといった異なるOSを稼働できるが、それらのOSは VMware Workstation を動かしている Windows を共有しているわけではなく、Windows が稼働するハードウェアリソースを共有している。 と言うことになるわけですが、どちらも仮想環境のOSは実行環境のOSを共有していないです。OSを共有すると言うのは「そのOSの機能を使う」と言うことですが、ホスト/ハイパーバイザー型は仮想環境からOS機能を呼び出さず、逆になんとかしてハードウェアに直接アクセスできるようにします。(CPU の仮想化支援機能である VT-x とか、NICやらに対する SR-IOV とか) OSを共有するのはコンテナ型ですね。Docker とかで、仮想環境は実行環境の Linux カーネルの機能を直接使います。逆に言うと、共有しているので「どれかの仮想環境だけ異なるOSにする」「どれかの仮想環境だけ Linux カーネルをバージョンアップ(ダウン)する」と言うことはできないのですよね。共有して使っているので。
2024/10/07 返信
参考における、【チェイン】の図解が良く分からない

回答に対しての返信ではなく追加質問にされているので、別の回答としてぶら下げます。

Outbounding付近のルーティングについては、
複数のNICを使い、相手のipアドレスによって使用するNICを振り分けしている感じでしょうか。

102、201範囲の「ルーティング」に関するところをもう少し補強した方が良いのかもしれませんね。時間や余裕があればCCNAの学習で「ルーティング」に関する基本だけでも押さえると理解度が上がると思います。

ルーティングは

  • 自分が受信したパケットを自分が受け取るべきか別の誰かに転送(ルーティング)するべきか
  • パケットをどのインターフェースからどのアドレスに(ルーティング)送信すべきか

の2パターンで発動します。前者の場合は「転送すべき」となった時点で「どのインターフェースからどのアドレス向けに出力するか」が決まっているので FORWARD チェインの後では実行されません。対して OUTPUT の前の段階では、ローカルプロセスがパケットを生成しただけで、まだ「どのインターフェースからどのアドレス向けに出力するか」が決まっていません。OSはプロセスから「パケットを受け取ってから」ルーティング処理を行い、どのインターフェースから出すのかを決定します

複数の NIC は物理的なものに限りません。 veth とか lo とか br とかの仮想インターフェースでも同じことです。

2024/10/07 コメント
参考における、【チェイン】の図解が良く分からない
あ、「ホスト」が物理サーバかコンテナかは問わないことに注意してください。「自分自身(のアドレス)宛ではない」と言うことがポイントです。
2024/10/07 返信
CDPのメリットはなんなのでしょうか?

CDP(Cisco Discovery Protocol) はその名の通り「隣接しているCiscoデバイスの情報を確認」するためのシスコ独自のプロトコルです。
対してLLDP(Link-Layer Discovery Protocol) は IEEE 802.1AB で規定された「標準」プロトコルであり、シスコ以外のベンダーも実装して利用しています。

使い分けたいかどうかは環境によると思います。全部シスコ製品だから CDP 使う、でもいいですし、シスコも含むマルチベンダーで構成しているから LLDP を使う、とか。オールシスコだけど標準準拠でいきたいから LLDP ってのもありですね。

2024/10/07 返信
参考における、【チェイン】の図解が良く分からない

サーバ自身宛か、別のホストへ転送すべきものかを判断するための「ルーティング」ですね。サーバだからといって受け取る全てのパケットが「自分自身宛」とは限りません。

2024/10/05 コメント
バインディングデータベースとARPテーブルの違いについて
あれ?意図と違う伝わり方してしまいました。表現下手ですみません。 L2スイッチはARPテーブル持たないですよね、って言ってるつもりでした。
2024/10/04 返信
バインディングデータベースとARPテーブルの違いについて

ARPテーブルってARP(Address Resolution Protocol)によって解決した情報を記録してあるものですよね。で、ARPが何のためにあるかって、「あるIPアドレスを持つ装置のMACアドレス」を知りたいからですよね。その目的って「IPで通信するために、IPパケットの送信先になるMACアドレスを知る」ことです。

で、今回の話で言うと「L2スイッチ自体が誰かとIPで通信する」場合にはARPが必要ですしそのためのARPテーブルを持つわけですが、それがない前提ですよね?(スイッチは基本的にL2フレームをスイッチングするだけなので、IPで通信するものではない)
また、「(DHCPスヌーピング)バインディングデータベースがARPテーブルと同一視できるか」と言うお話であれば、DHCPどこいった?って話になりますよね。

と言うことで結局は

単に用途の違い

と言うことになるかなぁと思います。

2024/10/02 コメント
なぜレートベースが正解なのか
修正されたようですが&セキュリティ本職じゃないので今更かもしれませんが。 IPアドレスを頻繁に変更するのって「対策されたから」というのがモチベーションのはずであって、「頻繁に変更 **しながら** ちょっとずつリクエストを送る」というのは手間とか効果を考えると採用されにくい攻撃方法かなぁと思います。 なので、個人的には問題としても特におかしくないのではないかなと思っています。
2024/09/30 コメント
なぜレートベースが正解なのか
なるほど。 頻繁にIPアドレスを変更する不審な外部アクセスからの「過剰な」リクエストが - 変更した IP アドレスごとに「過剰」 - 頻繁に変更した IP アドレスからのリクエストの "合計が" 「過剰」 と考えた時に後者だったら IP アドレスごとのレートが閾値を超えないので効果が低いのでは、ということですね。 逆に前者の場合であれば適切と言えるという認識をお持ちだという理解で間違いないでしょうか?
2024/09/29 返信
なぜレートベースが正解なのか

攻撃元が異なるアドレスに切り替わったとしても、そのアドレスからの「過剰な」リクエストレートを判断基準にしているので特に問題ないと思うのですが…
もしよければ ksjym2 さんが「適切」と思われるこの問題の他の選択肢とその理由をお聞かせいただけないでしょうか?

戻る