問題ID： 1394
- フォーラムは新サイトへ移行しました。
- このフォーラムではゲスト投稿が禁止されています
hcm83681
居住地: 秘密
投稿数: 89
居住地: 秘密
投稿数: 89
いつもお世話になっております。
以下、問題文です。
ちなみに正解は「ネイバーに問い合わせし、アクティブ状態となる。」です。
*****
フィージブルサクセサがない状態で、サクセサがダウンした時、EIGRPルータはどのような動作をするか選びなさい。
・現在もっているトポロジテーブル上で最小FDを持つ経路をサクセサにする
・ネイバーに問い合わせをし、パッシブ状態となる。
・サクセサがアップするまで待つ
・ネイバーに問い合わせをし、アクティブ状態となる。
・現在もっているトポロジテーブル上で最小ADを持つ経路をサクセサにする
*****
本題ですが、似たような問題を他(完全問題集)でも見かけ、「Active」状態になるが正解になっています。
自分の中ではどうも納得がいかなく、クエリーを出すのはわかるのですが、その後、「Active」状態になるとは言い切れない気がします。
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKがなかなか返ってこなかったら「Active」状態になり、もし、ネイバーからリプライがあれば「Passive」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
というわけで、正解は選べないと思うのですが、いかがでしょうか？
以上
以下、問題文です。
ちなみに正解は「ネイバーに問い合わせし、アクティブ状態となる。」です。
*****
フィージブルサクセサがない状態で、サクセサがダウンした時、EIGRPルータはどのような動作をするか選びなさい。
・現在もっているトポロジテーブル上で最小FDを持つ経路をサクセサにする
・ネイバーに問い合わせをし、パッシブ状態となる。
・サクセサがアップするまで待つ
・ネイバーに問い合わせをし、アクティブ状態となる。
・現在もっているトポロジテーブル上で最小ADを持つ経路をサクセサにする
*****
本題ですが、似たような問題を他(完全問題集)でも見かけ、「Active」状態になるが正解になっています。
自分の中ではどうも納得がいかなく、クエリーを出すのはわかるのですが、その後、「Active」状態になるとは言い切れない気がします。
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKがなかなか返ってこなかったら「Active」状態になり、もし、ネイバーからリプライがあれば「Passive」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
というわけで、正解は選べないと思うのですが、いかがでしょうか？
以上
hcm83681
居住地: 秘密
投稿数: 89
居住地: 秘密
投稿数: 89
すみません。下記の部分訂正です。
*****
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKがなかなか返ってこなかったら「Active」状態になり、もし、ネイバーからリプライがあれば「Passive」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
*****
↓
*****
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKが返ってきて、かつリプライもあれば「Passive」状態になります。もし、ACKだけ返ってきて、リプライが無ければ「Active」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
*****
*****
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKがなかなか返ってこなかったら「Active」状態になり、もし、ネイバーからリプライがあれば「Passive」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
*****
↓
*****
クエリーを出した後は、ネイバーからのACKがあるまでは「Query」状態になるわけだし、その後、ACKが返ってきて、かつリプライもあれば「Passive」状態になります。もし、ACKだけ返ってきて、リプライが無ければ「Active」状態になります。
どうも、クエリーを出したら、即座に「Active」状態になるという考えが何かしらの情報を元に蔓延しているような気がします。
*****
hcm83681
居住地: 秘密
投稿数: 89
居住地: 秘密
投稿数: 89
問題ID： 1399
も同様にクエリーを出したらアクティブ状態になるとなっています。
も同様にクエリーを出したらアクティブ状態になるとなっています。
mirin0930
投稿数: 13
投稿数: 13
hcm83681さんが気にしている「Active」状態になるという情報元は下記URLではないしょうか。
http://www.cisco.com/JP/support/public/ht/tac/100/1008009/1-j.shtml#rout_states
*****上記URLより抜粋
フィジブル サクセサが存在しない場合、ルートはアクティブ状態になり、ルート再計算が実行されます。 ルータが query パケットをすべての隣接ルータを送信することによって、ルートの再計算が開始されます。
*****
上記のように書かれているので
『ネイバーに問い合わせをし、アクティブ状態となる』
を選択できると思えるのですがいかがでしょうか。
ちなみに、「Query」状態になるという情報元はどこになるでしょうか。
http://www.cisco.com/JP/support/public/ht/tac/100/1008009/1-j.shtml#rout_states
*****上記URLより抜粋
フィジブル サクセサが存在しない場合、ルートはアクティブ状態になり、ルート再計算が実行されます。 ルータが query パケットをすべての隣接ルータを送信することによって、ルートの再計算が開始されます。
*****
上記のように書かれているので
『ネイバーに問い合わせをし、アクティブ状態となる』
を選択できると思えるのですがいかがでしょうか。
ちなみに、「Query」状態になるという情報元はどこになるでしょうか。
hcm83681
居住地: 秘密
投稿数: 89
居住地: 秘密
投稿数: 89
mirin0930殿
お返事頂いていたのに遅れて申し訳ありません。
確かに、ciscoのサイトにも公式本(p79)にも、アクティブ状態になると書いてありますが、実際、自分の検証環境で試したところActiveにはならず、Queryのままになる場合がありました。情報元は特にありません(以前探してみましたが、それといったのはなく、自分で検証した次第です。)
もう一度検証してみた結果をご連絡しますのでもう少しお待ちください。
以上
お返事頂いていたのに遅れて申し訳ありません。
確かに、ciscoのサイトにも公式本(p79)にも、アクティブ状態になると書いてありますが、実際、自分の検証環境で試したところActiveにはならず、Queryのままになる場合がありました。情報元は特にありません(以前探してみましたが、それといったのはなく、自分で検証した次第です。)
もう一度検証してみた結果をご連絡しますのでもう少しお待ちください。
以上
hcm83681
居住地: 秘密
投稿数: 89
居住地: 秘密
投稿数: 89
mirin0930殿
途中連絡です。
検証しましたが、
Query(たぶんあるのだが) → Active → トポロジーテーブルより消滅
が1秒以内に完了してしまい、コンバージェンスが速過ぎて分かりませんでした。ネイバーへのSRTTやRTOにもう少し時間を持たせるようにしないと途中遷移が確認できないのかもしれません。(下記のとおりRTOが最大でも84msだと速過ぎるようです。)
以前はQueryを確認をしたのですが、どういう状況だったか思い出せません。
もう少し工夫して頑張ってみます。
(試験も近いのであまり時間は割けませんが。)
*****
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.1.126 Se0 13 00:46:13 34 204 0 7
1 172.16.100.3 Se1 177 00:45:32 41 246 0 18
2 172.16.100.2 Se1 170 00:01:08 84 504 0 33
R1#
*****
途中連絡です。
検証しましたが、
Query(たぶんあるのだが) → Active → トポロジーテーブルより消滅
が1秒以内に完了してしまい、コンバージェンスが速過ぎて分かりませんでした。ネイバーへのSRTTやRTOにもう少し時間を持たせるようにしないと途中遷移が確認できないのかもしれません。(下記のとおりRTOが最大でも84msだと速過ぎるようです。)
以前はQueryを確認をしたのですが、どういう状況だったか思い出せません。
もう少し工夫して頑張ってみます。
(試験も近いのであまり時間は割けませんが。)
*****
R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.1.126 Se0 13 00:46:13 34 204 0 7
1 172.16.100.3 Se1 177 00:45:32 41 246 0 18
2 172.16.100.2 Se1 170 00:01:08 84 504 0 33
R1#
*****
