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

問題制作者側のミスなのでしょうか？

ミスだったら解説での解き方も成立しないと思うのですが、解説の説明は確認されてますか？

「故障ノードをクラスタノード間通信用ネットワークから切り離す」のは正しい対応と認識しておりました。

この根拠となる資料や情報があると嬉しいです。

故障ノードの故障の仕方にもよりますけど、基本的にクラスタノード間通信用ネットワークを切断すると「対向ノードの状態が確認できない（サービス停止している可能性がある）」と判断してアクティブになるかと思います。その場合、二重アクティブによるスプリットブレインとなるかと思います。
切り離すならサービス提供用ネットワークかなと思います。

そのうちのSPT（送信元ツリー）用のJoinというのはFHRからRPに送られることで送信元ツリーが作成されるという説明が他サイトやChatGPTでありました。

その辺りの詳細（他サイトのURLやChatGPTへの質問と解答の内容とか）があるとよりわかりやすいのですが…

で、ここで言うSPTっていうのが問題の方でもあまりはっきり言及されていないので微妙ですが、初期のツリー構築の話だとすると多分ここのことじゃないですかね。
https://www.cisco.com/c/ja_jp/td/docs/switches/lan/catalyst2960x/software/15_2_6_e/configuration_guide/b_1526e_consolidated_2960x_cg/b_1526e_consolidated_2960x_cg_chapter_01011.html#GUID-F6A7759F-29A2-4264-8031-7E50A10BBBD9

ホストがマルチキャスト グループに加入すると、直接接続されたルータは RP に PIM 加入メッセージを送信します。RP はマルチキャスト グループを追跡します。マルチキャスト パケットを送信するホストは、そのホストのファースト ホップ ルータによって RP に登録されます。その後、RP は、ソースに加入メッセージを送信します。この時点で、パケットが共有配信ツリー上で転送されます。

PIM-SMは

• IGMP Joinを投げたホストがいるLHRからRPに向けてPIM Joinが飛ぶ（共有ツリーができる）
• ソース（送信者）がグループにパケットを投げたら、FHRがRPにPIM Registerを投げる
• PIM Registerを受け取ったRPはソースに向かってJoinを投げる（ソースからRPへのSPTができる）
• ある程度ソース→レシーバにパケットが流れると、FHR-LHR間のSPTができる（RPからFHRへRegister Stopが飛ぶのでRPを経由しなくなる）

という流れなので、PIM Joinが飛ぶとしたら「LHR→RP」もしくは「RP→FHR」となるかと思います。

もしよければ「他サイト」や「ChatGPT」の情報も共有いただけると（私が間違ってるかもしれないので）助かります。

あれ？OSPFのINIT状態ってHello交換する前だから、show ip ospf neighbor で何も表示されなくてもおかしくないのではないでしょうか？Helloを相互に交換できてない状態ではINITのままなので、表示されないのが自然かと思います。

参考にもこう書いてありますし。

INIT・・・Helloパケットを受信し、相手を認識した状態
2WAY・・・お互いに認識した状態（DROTHER同士は経路情報を直接交換しないので「2WAY」状態でコンバージェンス）

もしTTL 1 で疎通可能なのであれば、なぜeBGPでループバックインターフェース間のピア設定をする際にTTL ２以上にする必要があるのか疑問に感じまして。

TTLについて聞きたいのかeBGPピアリング時のTTLをどう設定するのかと、話題が二つあるようなのでコメントの仕方が悩ましいですね。
加えて、どの問題IDに関連するものかがわからないので、解説や参考に疑問の解消ポイントが記載されているかが確認できないのも…

それはそれとして。

単純な話をするとeBGPはデフォルトで「直接接続した相手」とピアを張ることになるので、直接接続していないアドレス（＝対向ルータのLoopback）は「TTL=1」以内にいないと言うことでピアリングに失敗するんです。この挙動については以下のドキュメントが参考になるかと思います。
https://community.cisco.com/t5/tkb-%E3%83%8D%E3%83%83%E3%83%88%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%A4%E3%83%B3%E3%83%95%E3%83%A9-%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/7-19-webcast-quot-%E5%88%9D%E7%B4%9A%E8%80%85%E5%90%91%E3%81%91-bgp%E3%81%AE%E5%9F%BA%E6%9C%AC%E3%81%A8cisco%E3%83%AB%E3%83%BC%E3%82%BF%E3%81%AE%E5%8B%95%E4%BD%9C-quot-q-a%E3%83%89%E3%82%AD%E3%83%A5%E3%83%A1%E3%83%B3%E3%83%88/ta-p/3163961

TTL=1のパケットを送信しようとするルータは、参照したルートが「C」だったなら、パケットを送信します。それ以外の「S」や「O」を参照したなら、パケットを送信しません。

念のための確認なのですが

「CatAのFa0/1でポートプライオリティを変更して VLAN1～3の優先度を上げる」ではだめな理由が分かりませんでした。

と、言われながら

「CatAのFa0/1でポートプライオリティを144に変更」することでは実現できないのはなぜなのでしょうか。

と、「Fa0/1のポートプライオリティを下げる」やり方を想定されているようなのですが、「上げる」「下げる」どちらを考えられてますか？

ルーティングテーブルにConnectedで見えている経路については再配送されないのではないでしょうか？

これですねぇ、OSPFは「再配送するルータでOSPF有効になってるインターフェースのサブネットはOSPF経路として再配送する」んですよ。なぜかって言われると「そう言うもの」って話でしかないのですが…
同じような質問がCisco Communityでも上がってました。
https://community.cisco.com/t5/routing/route-redistribution-ospf-gt-eigrp/m-p/4700380

実験できる環境があれば、2台のルータを繋げてこんな設定入れてみてください。R2で D EX な 1.1.1.1/32 の経路が見えるはずです。

R1:
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
!
interface GigabitEthernet1
 ip address 192.168.12.1 255.255.255.0
 no shutdown
!
router ospf 1
 network 1.1.1.1 0.0.0.0 area 0
!
router eigrp 1
 network 192.168.12.0
 redistribute ospf 1 metric 1000000 100 255 1 1500

R2:
interface GigabitEthernet1
 ip address 192.168.12.2 255.255.255.0
 no shutdown
!
router eigrp 1
 network 192.168.12.0

こちらFa0/1からVLAN10と20を通すためにenabledやallowedコマンドは入力不要なのでしょうか。

どう言うコマンドを意図されているかがわからないので、具体的に必要だと想定されているコマンドを記述いただいても良いでしょうか？

とありますが、これはOSPFにとってのout方向というのが正しいのではないでしょうか？
またはEIGRPにとってのin方向という方が適切でないしょうか？

そう判断された根拠が一緒にあると嬉しいです。

正答選択肢をみると以下のように記述されています。

router eigrp 1
 distribute-list 1 out ospf 1

これは router eigrp （つまりEIGRPルーティングプロセスの中）で、distribute-list （経路情報の配送、広告）をどの方向に制御するか、と言う意味になります。つまり「EIGRPプロセスが自分の発信（out）向きに経路情報アップデートする際にACL:1を適用する。なお、OSPFプロセス番号1から学習した経路を対象とする」と言うのがこの distribute-list 1 out ospf 1 の意図になります。
なので、「EIGRPのin方向」と言うと、「EIGRPプロセスに入ってくる」と言う意味になるので、router eigrp 配下では distribute-list in になりますし、「OSPFにとってのout」と言うと、router ospf 配下で distribute-list out と言うように聞こえます。
考え方のポイントとしては「redistributeした時点で、その経路情報はredistribute元の経路情報として扱わない」と言うことですね。router eigrp 配下で redistribute ospf　したらその経路はEIGRPプロセスにとっては D EX な経路になるわけで、OSPF関係ないのです。

トポロジ図のルーティングプロセスの管理範囲（ドメイン）で考えず、どのルーティングプロトコルのプロセスで扱うのか、そのルーティングプロトコル観点で経路情報を「送信する（out）」のか「受信する（in）」のかと言う点でみると良いかと思います。

この辺のドキュメントみると参考になるかもです。
https://www.cisco.com/c/ja_jp/support/docs/ip/interior-gateway-routing-protocol-igrp/9105-34.html

指定ポートは各セグメントで選出されるのだからAのFa0/2が200、CのE0/1が219でA側を指定ポートと選択したんですが・・・。

選択するまでの全体の流れが気になるのですが、解説の以下の部分で各スイッチごとのルートパスコストが記載されているのは確認されてますか？

SwitchAとSwitchCのセグメントでは、SwitchAが持つルートパスコストは「119」、SwitchCが持つルートパスコストは「100」なので、SwitchAより小さいルートパスコストを持つSwitchC側のポート（E0/1）が指定ポートになります。

ポート単位、セグメント単位で見る前に「スイッチのルートパスコスト」の観点でどちらが上か（RP, DPになるポートを持つか）が決まってくるので、スイッチ単位での判断をしてみて、それでどうなるか確認してはどうでしょうか？

まぁ確かに。「保持」じゃなくて「扱う」ならわからないでもないですね。

「送信元ツリーでは根本にFHRが指定されている」
は、正解ではないかと思われますが、いかがでしょうか。

解説にも参考にも明記がない（他の問題の解説にならあるのかな？見てないですが）のですが、ここで言う「根本」って「ツリーの根本」です。じゃあ根本って何よ？って言うと「起点」です。何の起点かっていうと「マルチキャストツリーの起点」です。
マルチキャストって、Receiverから起点（根本）まで辿っていって出来上がるツリーを根本からReceiverまでデータ送信する際のパスとして使用するんですね。なのでこうなります。

• 送信元ツリー：送信元（Source）からReceiverまで最初から出来上がってるツリー。なので根本（起点）は「送信元（Source）」
• 共有ツリー：送信元（Source）からRPまでと、ReceiverからRPまでが別で出来上がってるツリー。Receiverから辿っていって出来上がるのはRPまでのツリーなので、根本（起点）は「RP」

FHRはSourceが存在するセグメントに直接接続されたルータのことなので、起点じゃないんですね。

興味があればこのドキュメントとか読んでみると良いかもです。
https://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_tech_oview_support_TSD_Island_of_Content_Chapter.html#wp1055129

Multicast Distribution Source Tree (Shortest Path Tree)
The simplest form of a multicast distribution tree is a source tree. A source tree has its root at the source host and has branches forming a spanning tree through the network to the receivers.

Multicast Distribution Shared Tree
Unlike source trees that have their root at the source, shared trees use a single common root placed at some chosen point in the network. This shared root is called a rendezvous point (RP).

この問題の
def network_device_list(dnac, token):
の引数で、dnacはそれより上の行で既に現れたもので、tokenは現れて
いないものになっています。

この部分のdnacは、別の名前でもよいという理解で正しいでしょうか。

別の名前でも良い、というか、ここはプログラミング言語の割と一般的な話になります。
def で始まる文は「関数定義」と言って、「こう言う名前で、こう言う引数をとり、こう言う処理をするもの」を記述しているものです。例示されたところで言うと、「引数に （関数内部で使用する名前として）dnac, token と言う2つの引数を取る network_device_list と言う関数を定義」していると言うことになります。そして、ここについてはご認識の通り「関数内で名前を合わせておけば良い」です。なので

そのあとで
network_dvice_list(dnac, login)
としても、同じでしょうか。

であってます。

変な例を出せば、こう言うのも問題なく動作するPythonコードです。関数の中で名前の不整合がなければ、関数の外で使ってる変数をそのままセットできます。

lower = 100
higher = 10

def kakezan(kakeru_kazu, kakerareru_kazu):
  return kakerareru_kazu * kakeru_kazu

print(kakezan(higher, lower))

また、url = "https://{}/api/----- の {} の部分は、どの様な
意味になるでしょうか。

これは str.format() と言う、文字列整形の様式ですね。省略されてますが設問のコードをちゃんと書けばこうですよね。

url = "https://{}/api/v1/network-device".format(host)

ここでは

• 文字列＝ https://{}/api/v1/network-device
• 文字列.format() に渡す引数は host
• format構文に従い、{}（置換指定） に host の値をセットする
• host には（これは多分 network_device_list 関数のものなので）引数となる辞書dnacの host キーの値をセットする

と言う指定になっているので、最終的には https://sandboxdnac.cisco.com/api/v1/network-device と言う文字列にする、と言うことになるのですね。
formatに指定できるパラメータは以下のドキュメントから「書式指定文字列の文法」とかへ飛んで見てみると色々見えてくるかと思います。
https://docs.python.org/ja/3/library/stdtypes.html#str.format

ご指摘の選択肢については、こう解説されています。

・他スキーマの表に索引を作成する
INDEXオブジェクト権限があれば行えますので、誤りです。

https://docs.oracle.com/cd/E29814_01/timesten.1122/b66446/privileges.htm#BABIDBFC をみると

オブジェクト権限とは、オブジェクトで特定のアクションを実行したり、別のユーザーのオブジェクトにアクセスする権限のことです。オブジェクトには、表、ビュー、マテリアライズド・ビュー、索引、シノニム、順序、キャッシュ・グループ、レプリケーション・スキームと、PL/SQLファンクション、プロシージャおよびパッケージがあります。

と記載があり、誤答解説のINDEXオブジェクト権限について確認すると

ユーザーは表またはマテリアライズド・ビューに索引を作成できます。

と書かれてます。なので、CREATE ANY INDEX システム権限がなくても「他スキーマの表」に関して索引の作成を実行するユーザーに対するINDEXオブジェクト権限があれば実行できることになり、問題の正誤にも解説にも特に誤りはないと思いますよ。

問題IDとかがわからないのですが、どの問題に関しての質問なのでしょうか？

うーん、これは確かに設問の状況がわかりにくいですね…
すごーく意図を読み取ったとしてこう言う状況ではないかと考えます。

• iBGPピアリングでは「2hop先には経路情報が伝わらない（iBGPで学習した経路を他に伝えない）」
• ルートリフレクタはiBGPで学習した経路であっても、2hop以上先へ広報できる
• ルートリフレクタ同士でルートリフレクタクライアントの設定（ neighbor route-reflector-client ）を相互に設定することで、互いの学習した経路情報を交換できる

最後のところが読み取った内容ですが選択肢の「XXとYY」とある場合は「互いにルートリフレクタの設定をする」と言う意味を含んでいるのかもしれません。それであればまぁ有りうるかもなとは思います。時間があれば環境作って検証してみようかな…

実物を見たらイメージしやすいと思います。例としてvyos（仮想ルータ）のovaを見てみるとこんな感じです。
https://support.vyos.io/en/support/solutions/articles/103000099217-vyos-1-2-9-s1

% ls
vyos-1.2.9-S1-cloud-init-vmware.ova
% file vyos-1.2.9-S1-cloud-init-vmware.ova
vyos-1.2.9-S1-cloud-init-vmware.ova: POSIX tar archive
% tar tfv vyos-1.2.9-S1-cloud-init-vmware.ova
-rw-r--r--  0 someone someone 13696  3 16 07:12 vyos-1.2.9-S1-cloud-init-vmware.ovf
-rw-r--r--  0 someone someone   227  3 16 07:12 vyos-1.2.9-S1-cloud-init-vmware.mf
-rw-r--r--  0 someone someone 102400  3 16 07:12 vyos-1.2.9-S1-cloud-init-vmware.cert
-rw-r--r--  0 someone someone 442210304  3 16 07:12 vyos-1.2.9-S1-cloud-init-vmware-disk1.vmdk