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

助け合いフォーラムの投稿
2024/04/02 返信
問題文の「辞書型データ」はJSON形式の文字列ではないでしょうか?

変数dataは波括弧「{}」で囲まれた「key: value」の形式になっており、辞書型データとして定義しているように見えますが、なぜそのように思われたのでしょうか?

試しに変数dataのデータ型をtype()を使って確認すると、以下のようになります。
(dataの中身は長いので少し省略してますがご了承ください)

[test.py]

import json

data = {
    "hostname": "RouterA",
    "interfaces": {
        "Loopback0": {
            "ipv4-address": "1.1.1.1",
            "subnet-mask": "255.255.255.255",
            "shutdown": "no"
        }
    }
}

#変数dataのデータ型を出力
print(type(data))

#辞書型の変数dataを文字列型に変換して、変数data2に代入
data2 = (json.dumps(data, separators=(',', ':')))

#変数data2のデータ型を出力
print(type(data2))

#変数data2を出力
print(data2)

[実行結果]

C:\> python test.py
<class 'dict'>
<class 'str'>
{"hostname":"RouterA","interfaces":{"Loopback0":{"ipv4-address":"1.1.1.1","subnet-mask":"255.255.255.255","shutdown":"no"}}}

1行目の<class 'dict'>という出力から変数dataは辞書型だとわかります。
2行目の<class 'str'>という出力から変換後の変数data2は文字列型だとわかります。

2024/03/05 返信
どういう理由でそうなるの?

これはそういうもんだと覚えるしかないのでしょうか?

はい、そうです。

RESTCONFでネットワーク機器の設定を変更するということは、YANGモデルのデータを操作するということです。
POSTで設定を追加する際に対象のネットワーク機器が対応しているYANGモデルを使ってデータを指定してあげないと、機器側は何を追加したいのか認識できません。
つまり、あらかじめ決められているデータ構造に従って設定を追加したり変更したりする必要があります。
あなたが「"source"」や「"destination"」の方がしっくりくるなと思っても、決められたデータ構造と異なる場合、機器側には通じないということです。

試しに「"source":"any"」を使ってリクエストしてみましたが、以下のようにエラーになりました。
"error-message"に「unknown element: source」と書かれています。これは機器側が「source」というキーを知らない(あらかじめ決められているデータ構造にはない)からです。

{
  "ietf-restconf:errors": {
    "error": [
      {
        "error-type": "application",
        "error-tag": "malformed-message",
        "error-path": "/Cisco-IOS-XE-native:native/ip/access-list",
        "error-message": "unknown element: source in /ios:native/ios:ip/ios:access-list/ios-acl:extended[ios-acl:name='ACL4']/ios-acl:access-list-seq-rule[ios-acl:sequence='100']/ios-acl:ace-rule/ios-acl:source"
      }
    ]
  }
}

じゃあどうやってデータ構造を知ることができるのかという話になると思いますが、GETリクエストで実際にデータを取得したり、GitHubなどで公開されているYANGモデルを取得したりできます。
詳しくは以下のサイトが参考になると思います。
https://www.infrastudy.com/?p=1262
https://www.it-enjoy.com/entry/2021/01/26/190000#%E5%89%8D%E6%9B%B8%E3%81%8D
https://ccieojisan.net/post-2031/#RESTCONF

2024/02/28 返信
なぜイーサネットヘッダ?

ネクストホップの情報=IPヘッダに含まれる宛先IPアドレス という勘違いをされているのではないでしょうか。

実際に、次のホップの宛先アドレスを示すのは、イーサネットヘッダの宛先MACアドレスです。
ネットワークデバイスがIPパケットを転送する際、ルーティングテーブルを参照して次のホップのIPアドレスを決定しますが、このIPアドレスは直接IPヘッダに含まれるわけではありません。(IPヘッダに含まれる宛先IPアドレスは最終的な目的地であるため)
そのため、ARPを使用して、その次のホップのIPアドレスに対応するMACアドレスを取得します。
そして、このMACアドレスが外部イーサネットヘッダの宛先MACアドレスとして設定されます。
なので、VXLANパケットの転送においてネクストホップの情報を示すのは、外部イーサネットヘッダの宛先MACアドレスです。

参考URLに載っている以下のサイトに詳しく説明されています。
https://milestone-of-se.nesuke.com/nw-basic/grasp-nw/ethernet-ip-address/#toc2

2024/02/26 コメント
RとCの由来について
すみません、補足しておきます。 先ほどの回答は根拠となる情報が載っているサイトなどは見つけられなかったのですが、個人的にはそうかなと思うという話です。
2024/02/26 返信
RとCの由来について

Remoteの[R]でネイバ、Currentの[C]で自ルータを意味してると思います。

2024/02/26 返信
スタブエリアフラグ

スタブエリアか、スタブエリアではないかを識別するフラグのことだと思います。

Ciscoの情報が載っているサイト:
https://www.cisco.com/c/ja_jp/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#toc-hId-50449744

エリアがスタブとして設定されている場合、そのエリアに属するすべてのインターフェイスは、インターフェイスがスタブであることを示すフラグを付けてHelloパケットを交換します。
実際のところ、これは Hello パケット内の 1 ビット(E ビット)が 0 に設定されることで、実現されます。共通のセグメントを持つすべてのルータは、そのフラグに同意する必要があります。そうしないと、ネイバーにならず、ルーティングが有効になりません。

シスココミュニティ:
https://community.cisco.com/t5/switching/stub-area-flag-in-ospf/td-p/2672098

余談ですが、用語をネットで検索する時に「cisco stub area flag」や「cisco スタブエリアフラグ」のように英語にしたり「cisco」というキーワードを入れたりするとCisco公式の情報がヒットしやすくなり、試験勉強に役立つと思います。

2024/02/22 返信
宛先IPアドレスについて

コマンド構文の図にも記載されていますが、送信元セッションの設定と宛先セッションの設定で指定する宛先IPアドレスを一致させる必要があります。
宛先IPアドレス=対向ルータのIPアドレスではありません。
この例の場合、SwitchAが送信元、SwitchBが宛先となっているので、SwitchBのIPアドレスが宛先IPアドレスとして両方の設定で使用されます。

2024/01/16 返信
ネイティブVLANについて

「ネイティブVLANをサポートしている」という表現に対して私は別に問題はないと思いました。

この問題はIEEE 802.1Q中の記載内容について問われている訳ではないと思います。
「untagged set」より「ネイティブVLAN」の方がネットワーク用語としては広く知られてるのでわかりやすいのではないでしょうか。

トランク接続によるネイティブVLANの動作を考えてみます。
トランクポートの設定で「switchport trunk encapsulation dot1q」を使ってトランキングプロトコルをIEEE802.1Qにします。
このポートにタグ無しのフレームが流れた場合、それらのトラフィックはネイティブVLANとして認識されます。
当然、IEEE802.1Qを使用しているトランクポートではネイティブVLANがサポートされています。
ネイティブVLANがサポートされていなければタグ無しのフレームが適切に処理されなくなってしまいます。

ちなみにCiscoの公式ガイドブックには、IEEE802.1Qで規定されているタグ無しトラフィックの扱いについて以下のような記載がありました。

In the 802.1Q standard, any traffic that is transmitted or received on a trunk port without the 802.1Q VLAN tag is associated to the native VLAN.

(802.1Q規格では、トランクポートで送受信される802.1Q VLANタグがない任意のトラフィックは、ネイティブVLANに関連付けられます。)
この文からも「IEEE 802.1QはネイティブVLANをサポートしている」といっても問題なさそうだと感じました。

2023/12/19 返信
再配送について

設問のルータで設定されているルーティングプロトコルはeigrpのみ(複数のルーティングプロトコルが出てこない)であるにも関わらず、
再配送の設定が必要になるという点がいまいち理解できずにいます。

この問題のルーティングの設定にはEIGRPとスタティックルートが使用されています。
R2の設定には[ip route 3.3.3.3 255.255.255.255 10.1.2.3]があるので、
R2のルーティングテーブルに載っている[3.3.3.3]宛のルートはスタティックルートです。
(スタティックルートのAD値は1で、ルーティングテーブルに載る優先度が高い)

[redistribute static]コマンドはスタティックルートをEIGRPへ再配送するという意味で、
R2が持っている[3.3.3.3]宛のスタティックルートを再配送するための設定です。
R2はルーティングテーブルにEIGRPで学習した[3.3.3.3]宛のルートを持っているわけではないので、
EIGRP同士で再配送しているということにはなりません。

再配送とは、異なるルーティングプロトコル間でルート情報をやりとりするときに必要となる設定の認識なのですが、この認識が間違っているのでしょうか?

こちらのご認識は正しいです。
スタティックルートはEIGRPとは異なるルーティング方法なので、再配送が必要ということになります。

余談ですが、R2に対して以下の設定を行った場合でも問題の要件を満たせます。
[network 10.1.2.0 0.0.0.255]でGi0/2でEIGRPを有効にして、
[no ip route 3.3.3.3 255.255.255.255 10.1.2.3]でスタティックルートを削除すると、
R2のルーティングテーブルにはR3からEIGRPで学習した[3.3.3.3]宛のルートが載るようになるので、
再配送の設定がなくてもEIGRPによってR1へ[3.3.3.3]宛のルートが伝播されるようになります。
これはスタティックルートを削除して、3yamotさんがおっしゃっているeigrpのみ(複数のルーティングプロトコルが出てこない)の状況になった場合の話です。

2023/11/06 返信
問題の誤植

問題としては破綻していないから誤植なのかは微妙な気がしました。

トータリースタブエリアはタイプ5(External LSA)、タイプ4(Summary ASBR LSA)、およびタイプ3(Summary LSA)を受け取りません。
しかしながら、ABRはトータリースタブエリアにデフォルトルートを注入するために特別なタイプ3のLSAを用いてデフォルトルートのみを送信します。
Pnt1205_004さんの意見も間違ってはいないと思います。

ただし、他の選択肢にはLSAタイプ4,5,7とかが入っているため明らかに間違いといえます。
トータリースタブエリア内の内部ルータが受信するLSAタイプとして「1,2」が最も正しい選択肢として適切なので、問題として成立していますし、別に誤植という訳でもない気がします。

2023/10/22 コメント
SwitchAのポートについて
はい、そうですね。 解説にも以下のようにちゃんと説明されてますよ。 >passiveモードとイーサチャネルを形成するモードは activeモードなので、CatA側はactiveモードにしていることがわかります。
2023/10/21 返信
SwitchAのポートについて

「show lacp neighbor」の「Port」で表示されている番号は自分のポートのことですね。
なので、この問題で表示されているのはCatAのFa0/6とFa0/7のことです。
対向(CatB)の情報は「Flags」のところで確認しますが、ポートの番号は出力されていないです。

試しに以下のように2台を別々のポート番号で接続してみました。
・CatAのGi0/0とCatBのGi0/1を接続
・CatAのGi0/2とCatBのGi0/3を接続

CatA#sh run interface gi 0/0
Building configuration...

Current configuration : 101 bytes
!
interface GigabitEthernet0/0
 media-type rj45
 negotiation auto
 channel-group 10 mode active ←イーサチャネルの設定
end

CatA#sh run interface gi 0/1
Building configuration...

Current configuration : 71 bytes
!
interface GigabitEthernet0/1
 media-type rj45
 negotiation auto
end

CatA#sh run interface gi 0/2
Building configuration...

Current configuration : 101 bytes
!
interface GigabitEthernet0/2
 media-type rj45
 negotiation auto
 channel-group 10 mode active ←イーサチャネルの設定
end

CatA#sh run interface gi 0/3
Building configuration...

Current configuration : 71 bytes
!
interface GigabitEthernet0/3
 media-type rj45
 negotiation auto
end

CatA#show lacp neighbor
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode

Channel group 10 neighbors

Partner's information:

                  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Gi0/0     SP      32768     5003.001a.0000  15s    0x0    0xA    0x2     0x3C ←CatAでイーサチャネルの設定を行ったGi0/0
Gi0/2     SP      32768     5003.001a.0000  18s    0x0    0xA    0x4     0x3C ←CatAでイーサチャネルの設定を行ったGi0/2
CatA#
CatB#sh run int gi 0/0
Building configuration...

Current configuration : 71 bytes
!
interface GigabitEthernet0/0
 media-type rj45
 negotiation auto
end

CatB#sh run int gi 0/1
Building configuration...

Current configuration : 102 bytes
!
interface GigabitEthernet0/1
 media-type rj45
 negotiation auto
 channel-group 10 mode passive ←イーサチャネルの設定
end

CatB#sh run int gi 0/2
Building configuration...

Current configuration : 71 bytes
!
interface GigabitEthernet0/2
 media-type rj45
 negotiation auto
end

CatB#sh run int gi 0/3
Building configuration...

Current configuration : 102 bytes
!
interface GigabitEthernet0/3
 media-type rj45
 negotiation auto
 channel-group 10 mode passive ←イーサチャネルの設定
end

CatB#sh lacp neighbor
Flags:  S - Device is requesting Slow LACPDUs
        F - Device is requesting Fast LACPDUs
        A - Device is in Active mode       P - Device is in Passive mode

Channel group 10 neighbors

Partner's information:

                  LACP port                        Admin  Oper   Port    Port
Port      Flags   Priority  Dev ID          Age    key    Key    Number  State
Gi0/1     SA      32768     5003.0019.0000   5s    0x0    0xA    0x1     0x3D ←CatBでイーサチャネルの設定を行ったGi0/1
Gi0/3     SA      32768     5003.0019.0000   9s    0x0    0xA    0x3     0x3D ←CatBでイーサチャネルの設定を行ったGi0/3
CatB#

2023/10/19 返信
経路学習の順序について

問題文に「以下のネットワークではPC4が他のPCと通信できない。」とあることから自分の認識では、
この問題の通りにネットワーク機器を設定したら「"絶対"にループが発生する」と思っていたのですが、

解説にも"ルーティングループが発生する危険性があります。"と書いてあるので、ループ発生の可能性はあり得ますが、絶対に発生するかどうかは別という感じかなと思います。
発生するかどうかは各ルータやプロセスの起動タイミングとかによって変わってきます。
複数のルーティングプロトコルを使用しているとプロトコルによって収束時間も異なる(OSPFやEIGRPに比べてRIPの収束時間は遅い)ので、このあたりもネットワークが不安定になる要因になったりします。
この問題では、もしタイミング的にうまいこといってループが発生しないパターンがあったとしても、このネットワーク構成でループが発生しうる原因は「distance eigrp 90 95」が設定されている点だからこの部分をフィルタリングした方が良いよねって感じですかね。
(問題文は「PC4が他のPCと通信できない。」となっているので、ループが発生しているパターンで問われているのは明らかですが)

もし最初はループが発生しないパターンで動作していても、運用中に何かしら障害が発生してルータやプロセスやインターフェースのダウン、再起動などを機にルーティングアップデートでループが発生するパターンでルーティングテーブルが更新されるかもしれません。

そうではなく、問題の通りの設定でもループが発生しないパターンもある、ということでよろしいでしょうか?

RCがもとは自分が発信した192.168.51.0の経路情報をRAやRBから受け取らなければループは発生しないはずなので、192.168.51.0の経路情報がRA-RB-RC間でループしないパターンは以下のような場合が考えられると思います。
・RA-RC間のEIGRPでスプリットホライズンの働きによって、ネクストホップがRAとなる192.168.51.0の経路情報をRCが受信しない
 (RAはRCをネクストホップとする192.168.51.0の経路情報を受信しています)
・RA-RB間のEIGRPでスプリットホライズンの働きによって、ネクストホップがRAとなる192.168.51.0の経路情報をRBが受信しない
 (RAはRBをネクストホップとする192.168.51.0の経路情報を受信しています)
・RB-RC間のOSPFでネクストホップがRBとなる192.168.51.0の経路情報をRCが受信しない
 (OSPFではスプリットホライズンが働くわけではありませんが、LSDB、SPFアルゴリズムによってループが発生しないようになってます。RBはRCをネクストホップとする192.168.51.0の経路情報を受信しています)
このような状況になれば、RCは192.168.51.0の経路情報をRAやRBからは学習せずにRDからRIPで学習するので、RA-RB-RCのトライアングルでループすることはなくなるはずだと思います。
なので結局、RA→RCとRC→RA(またはRA→RBとRB→RA)のどっちが先に192.168.51.0の経路情報を学習して、どっちがスプリットホライズンで伝播されないようになるかのタイミングの問題なんじゃないでしょうか。

参考になりそうなサイトです↓
IOSルーティング編<第1回> 再配布の基礎
第32回再配布(3) ルーティングループ

2023/10/18 返信
経路学習の順序について

EIGRPではもともとルーティングループを回避するためのメカニズムとしてスプリットホライズンが備わっています。
スプリットホライズンは「ルートを学習したインターフェイスから同じルートをアドバタイズしない」というものです。

この問題でループが発生している状況では、RCはRAからEIGRPで「192.168.51.0/24」の経路情報を学習しているので、スプリットホライズンが発動してRCからRAに「192.168.51.0/24」の経路情報は送られないというようなことが起こっていると考えられます。
なので、nishina_dnsさんがおっしゃっている「★RCが「192.168.51.0/24」の経路情報をRAへEIGRPで送信する」の動作はスプリットホライズンで回避されているということになります。
解説の2つ目の図にあるRAのtracerouteの結果を見ると、RAは192.168.51.100へRBを経由して到達しようとしていることがわかりますので、RCを経由するルートはRAのルーティングテーブルに載っていないはずです。(これはスプリットホライズンによってRCを経由するルートは学習できていないからです。)
スプリットホライズンの参考情報です。
Enhanced Interior Gateway Routing Protocol の理解および使用

ちなみにもし、RAがRCとRBの両方から等コストで宛先が同じ経路情報を受信していたとしたら、EIGRPでは等コストロードバランシングが行われるので、ルーティングテーブルには2つのパスが載ります。
ルーティングテーブルに2つのパスが載っていたら、tracerouteの結果は両方のパスを使っていることがわかるような結果になると思います。

ルーティングループは、ルータやプロトコルの起動タイミング、ネットワークの収束タイミングなどによって、同じ構成でも発生する場合としない場合があったりして結構複雑です。
以前の質問の回答でも記載してますが、この説明はあくまでもこの問題の設定において "ループが発生する原因となっている" 経路学習の順について説明しているという点を忘れないでくださいね。

2023/10/17 返信
ルーティングテーブルに載る経路の優先度とEIGRPの再配布ルートの有効期限について

自分の勝手な認識としても再配布されたルートはそのまま残り続ける認識

こちらのご認識が違っているのかと思います。
OSPFやEIGRPを使ったダイナミックルーティングはルーター同士が常にルート情報を交換しあって、ルーティングテーブルの最適化を動的に行うものです。
再配布されるルートも、ネットワークのトポロジが変わったり、設定が変更されたりした場合には更新されます。
経路情報が変更されてもルーティングテーブルに変化がないのであれば、ダイナミックルーティングのメリットがないですよね。。。
(手動でいちいち全部変更しないといけないスタティックルーティングと同じ)

OSPFはリンクステートデータベース(LSDB)、EIGRPはトポロジテーブルを持ち、各ルータがネットワーク全体のトポロジを保持しています。
ルーティングテーブルはLSDBやトポロジテーブルから最適な経路を選んで作成されます。
OSPFでは、ネットワーク内のすべてのOSPFルータが同じLSDBの情報を持ち、リンクの状態が変化するとLSDBが更新されます。
EIGRPでは、トポロジテーブルは隣接関係を持つルータ間で情報交換が行われ、トポロジの変更があれば、その変更情報が伝播されます。
LSDBやトポロジテーブルはほぼリアルタイムで更新され、これらをもとに作成されるルーティングテーブルにも古い経路情報が残り続けるということはありません。

参考になりそうなリンクをいくつか貼っておきます↓
【EIGRP】隣接テーブルとトポロジーテーブルの確認
ルータのプロトコル再配布の設定
Dynamic Routing
ルーティングテーブルを理解する

2023/09/28 コメント
ルーティングループ発生までの流れについて
>このご説明について、経路学習については必ずRC→RB→RAの順になるのでしょうか? >RCではRIP⇔EIGRPでの再配送の設定がされているので、RC→RA→RBもあり得ると考えているのですが認識合いますでしょうか…? >(もしこれがあり得た場合でも、やはりルーティングループは生じますよね…?) この説明は、この問題の設定において "ループが発生する原因となっている" 経路学習の順について説明しています。 (各ルータは各方面から経路情報を受信しており、この順だけで経路が学習されているわけではありません) 異なるルーティングプロトコルで宛先が同じ経路情報を学習した場合、最適なルートのみをルーティングテーブルに載せます。 (経路情報を学習したからといって必ずルーティングテーブルに載るとは限りません) どのルートを載せるか決めるためには以下の順で経路情報が比較されます。 ①ロンゲストマッチ ②AD値 ③メトリック ルーティングループが発生するかしないかは "各ルータがどのように経路を学習するか"、そしてその結果、"ルーティングテーブルにどのルートが載るか" という点がポイントになります。 逆にいえば複数箇所で再配送が設定されていても最終的に各ルータのルーティングテーブルに載っている経路に問題がなければルーティングループは発生しないということです。 ループ状の構成では、再配送の方向やAD値など諸条件の設定を変えると逆回りでループが発生することももちろんあり得ます。 ただ、この問題の設定ではRCに「distance eigrp 90 95」があるため、EIGRPで学習した経路のAD値が他のものより低いから、EIGRPで学習した間違った経路情報がルーティングテーブルに載ってしまった結果、この方向でルーティングループが発生しているという話です。 再配送の設定が複数箇所において設定されたり、AD値の変更などが行われたりすると経路学習や最適経路選択が複雑化します。 なので、これらの設定は慎重に行う必要があります。
2023/09/27 返信
ルーティングループ発生までの流れについて

まず、経路学習のAD値についてのご認識が間違っていると思いますので、訂正させて頂きますね。

①RCではRIP⇔OSPF,RIP⇔EIGRP間で経路情報を再配送する設定がされていることから、RCは192.168.51.0/24の経路情報をRA,RBそれぞれに伝える。
(このとき、RA,RBが受け取るAD値は120)

・RC-RA間ではEIGRPで経路学習が行われるため、RAがRCから学習する192.168.51.0/24のAD値は170です。
 (192.168.51.0/24の経路情報は、RIPエリアの情報なので外部EIGRPの170)
・RC-RB間ではOSPFで経路学習が行われるため、RBがRCから学習する192.168.51.0/24のAD値は110です。
 (OSPFのAD値は外部、内部に関わらず110)

②RBは、受け取った192.168.1.0/24の経路情報をRAに伝える。
(このとき、RA,RBが受け取るAD値は110)

・RB-RA間ではEIGRPで経路学習が行われるため、RAが受け取る経路情報のAD値は170です。

次にこの問題の構成における経路学習について説明します。
解説の3つ目の図の水色の矢印が示しているような順で経路学習が行われて、ルーティングループが発生してしまいます。
ループが発生する経路学習の流れは以下のような感じです。
①RCが「192.168.51.0/24」の経路情報をRBへOSPFで送信する(RBが学習する情報のAD値はOSPFの110)
②RBが①で学習した「192.168.51.0/24」の経路情報をRAのEIGRPへ再配送する(RAが学習する情報のAD値は外部EIGRPの170)
③RAが②で学習した「192.168.51.0/24」の経路情報をRCのEIGRPへ送信する(RCが学習する情報のAD値は95)
※「distance eigrp 90 95」によってRCでは外部EIGRPで学習する経路情報のAD値を95にするよう設定しているため、RCが受け取る情報のAD値は95となります。
また、「distance」コマンドによるAD値の変更はローカルのみで有効なので、他のルータにこれが通知されることはありません。

RCがRDからRIPで受け取る情報(転送先がRDとなる経路)のAD値は120ですが、③でEIGRPで学習した情報(転送先がRAとなる経路)のAD値95の方が小さくなります。
このことから、RCは「192.168.51.0」宛のパケットをRAに転送してしまうので、ループが発生します。

この問題と同じような構成を作ってみたので参考までに、各ルータの「show ip route 192.168.51.0」の出力結果を載せておきます。
①RBは「192.168.51.0」の経路情報をRCからOSPFで学習

RB#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1 ←OSPFで学習していて、AD値は110であることがわかります
  Redistributing via eigrp 1
  Advertised by eigrp 1 metric 1000000 1 255 1 1500
  Last update from 172.16.1.3 on GigabitEthernet0/2, 00:20:37 ago
  Routing Descriptor Blocks:
  * 172.16.1.3, from 192.168.1.3, 00:20:37 ago, via GigabitEthernet0/2 ←ネクストホップはRCの172.16.1.3でRC(192.168.1.3)からこの経路を学習していることがわかります
      Route metric is 20, traffic share count is 1

②RAは「192.168.51.0」の経路情報をRBからEIGRPで学習

RA#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
  Known via "eigrp 1", distance 170, metric 3072, type external ←EIGRPで学習していて、AD値は170であることがわかります
  Redistributing via eigrp 1
  Last update from 10.1.1.2 on GigabitEthernet0/0, 00:21:42 ago
  Routing Descriptor Blocks:
  * 10.1.1.2, from 10.1.1.2, 00:21:42 ago, via GigabitEthernet0/0 ←ネクストホップはRBの10.1.1.2でRB(10.1.1.2)からこの経路を学習していることがわかります
      Route metric is 3072, traffic share count is 1
      Total delay is 20 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

③RCは「192.168.51.0」の経路情報をRAからEIGRPで学習

RC#sh ip route 192.168.51.0
Routing entry for 192.168.51.0/24
  Known via "eigrp 1", distance 95, metric 3328, type external ←EIGRPで学習していて、AD値は95であることがわかります
  Redistributing via eigrp 1, rip, ospf 1
  Adve          ospf 1 subnets
  Last update from 10.1.2.1 on GigabitEthernet0/1, 00:20:47 ago
  Routing Descriptor Blocks:
  * 10.1.2.1, from 10.1.2.1, 00:20:47 ago, via GigabitEthernet0/1 ←ネクストホップはRAの10.1.2.1でRA(10.1.2.1)からこの経路を学習していることがわかります
      Route metric is 3328, traffic share count is 1
      Total delay is 30 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 2rtised by rip metric 1

再配送とAD値について詳しく解説してくれているサイトがありましたので、良かったら参考に見てみてください。
https://hirotanoblog.com/cisco-administrative-distance/3068/

2023/09/08 返信
プライベートVLANを使ったIPv6ファーストホップセキュリティについて

「正規のルータを全てのセカンダリVLANと通信可能なプロミスキャスポートに接続し、他のポートはプライマリVLANとしか通信できない独立ポートにします。」
の部分から空いている他のポートに不正なルータが接続されても通信できないように正規のルータを接続するポート以外のポートはプロミスキャスポートにせずにプライマリVLANとしか通信できない独立ポートにするということだと思います。

「不正なルータがプロミスキャスポートに接続された場合はほかのポートと通信できてしまうので」とおっしゃっていますが、例えば正規のルータを外して、もともと正規のルータが接続されていたプロミスキャスポートに対して不正なルータを繋ぐということを想定されていますか?
空いているポートに不正なルータが接続されてしまっても通信できないように独立ポートにしておくのがプライベートVLANを使ったファーストホップセキュリティの仕組みだと思うので、このような場合への対策は別の手段でセキュリティを確保する必要が出てくるんじゃないでしょうか。
(そもそも攻撃者を物理的に近づけないとか、RAガードとか、ポートに接続できるMACアドレスの制限とか)

2023/09/08 返信
Eigrp メトリックについて

EIGRPのメトリック = 256 ×~

帯域幅 = 10,000,000 ÷~ 

遅延 = ~ ÷ 10

の式の値についてはデフォルトで決まっているものなのでしょうか

はい。メトリックを計算する際の公式の定数として覚えてしまって大丈夫です。

なぜこのような定数を使用するかというと、少し数学的な話になりますが、正規化して帯域幅や遅延を簡単な数字で表すことができるようになるためです。

例えば、帯域幅や遅延に(Kbps)とか(μ秒)のような単位接頭辞がついていますが、これを外して数字だけで表現すると、数字が大きくなりすぎたり小さくなりすぎたりしてわかりにくいですよね。
経路上の最小帯域幅(Kbps)= 100000 (Kbps)=100000000(bps)
経路上の遅延合計(μ秒)= 1110(μ秒)= 0.00111(秒)

[計算の例]
帯域幅 = 10000000÷100000(Kbps) = 100
遅延 =(1000(μ秒)+100(μ秒)+10(μ秒))÷10 = 111
EIGRPのメトリック = 256 ×( 100 + 111 ) = 54016
上記は解説に載っている計算式の一例ですが、公式にあてはめて定数を使って計算することで帯域幅100、遅延111のように簡単な数字になっています。
もともと、100000000(bps)、0.00111(秒)のように全然異なる値だったものが、帯域幅=100、遅延=111のように近い値になって計算しやすくなっていることがわかります。

256の数値についてはwikiより

「複合メトリック値はIGRPでは24ビットの値だが、EIGRPでは32ビットの値になっている。
したがって、24ビットの値を256倍することで8ビット左へシフトしたのと同じことになり、
値が32ビットに拡張される。」

とありますがいまいち理解できませんでした

IGRPはEIGRPの前に開発されたCisco独自のプロトコルで、複合メトリックの計算においてEIGRPとIGRPの後方互換性を保つ必要があったみたいですね。
内部的にIGRPの複合メトリックは24ビット、EIGRPでは32ビットとなっています。
EIGRPのメトリックは、内部的には32ビット値として表現されていますが、32ビットのうち実際にメトリック計算で使用されるのは上位24ビットだけです。(じゃあEIGRPも最初から24ビットにしとけば良かったんじゃないのと思ってしまいますが...)
なのでEIGRPでは上位24ビットを使用する32ビットのメトリック値(上位24ビットには値が入っていて使用しない下位8ビットは全部0)を用意するために、24ビットの値を8ビット左へシフト(2の8乗で256倍)する必要があるということになります。
シフト演算については以下が参考になると思います。
https://tech.pjin.jp/blog/developer/2022/09/28/kihonjoho_2_5/

参考になりましたら幸いです。

2023/09/07 返信
再配送におけるループ防止について

この設定の場合「distribute-list 10 in GigabitEthernet0/1」の意味は以下の通りです。
・RAからOSPFでアドバタイズされる「192.168.10.0/24」の経路情報をGi0/1でブロック
in GigabitEthernet0/1 となっているのでGi0/1のインバウンド方向(受信する経路情報)にディストリビュートリストが適用されていることを意識するといいと思います。

なので、
①RAからOSPFでアドバタイズされる「192.168.10.0/24」の経路情報を、RBとRDがOSPF側のインターフェースであるGi0/1でブロックする
②RBとRDがOSPFで受信時に「192.168.10.0/24」の経路情報をブロックしたので、この経路情報がOSPFエリアからRIPエリアへ再配送されることもなくなる
という流れでRIPへの再配送をブロックしています。

2023/09/05 返信
再配送時のsubnetsオプションについて

機種やIOSのバージョンによって「subnets」オプションを指定せずに設定しても、自動的に「subnets」が有効になることがあります。
なので、この問題では「subnets」オプションを指定してなくても再配送ができているのだと思います。

自動的に「subnets」が有効になる場合についても、「show run」の出力には異なるパターンが存在するみたいです。
このバージョンはこのパターンというようなことが記載されているCiscoのドキュメントは見つけられなかったのですが、私が試せる環境で検証してみたところ以下のようなパターンを発見出来ました。

【「subnets」が自動的に有効になって「show run」にも表示されるパターン】

Router(config)#router ospf 1
Router(config-router)#network 172.16.1.0 0.0.0.255 area 0
Router(config-router)#redistribute eigrp 1 metric-type 2 ←「subnets」を付けないで設定
Router(config-router)#do sh run | s ospf
router ospf 1
 redistribute eigrp 1 subnets  ←「subnets」が自動的に付いている
 network 172.16.1.0 0.0.0.255 area 0
Router(config-router)#do sh ip protocols
*** IP Routing is NSF aware ***
~ 省略 ~
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 172.16.1.2
  It is an autonomous system boundary router
 Redistributing External Routes from,
    eigrp 1, includes subnets in redistribution ←「subnets」が有効になっている
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    172.16.1.0 0.0.0.255 area 0
  Routing Information Sources:
    Gateway         Distance      Last Update
    172.16.2.2           110      00:21:37
  Distance: (default is 110)

【「subnets」が「show run」に表示されないけど自動的に有効になるパターン】

Cat8000V(config)#router ospf 1
Cat8000V(config-router)#network 172.16.1.0 0.0.0.255 area 0
Cat8000V(config-router)#redistribute eigrp 1 metric-type 2 ←「subnets」を付けないで設定
Cat8000V(config-router)#do sh run | s ospf
router ospf 1
 redistribute eigrp 1 ←「show run」には「subnets」オプションが表示されない
 network 172.16.1.0 0.0.0.255 area 0
Cat8000V(config-router)#do sh ip protocols
*** IP Routing is NSF aware ***
~ 省略 ~
Routing Protocol is "ospf 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 192.168.45.11
  It is an autonomous system boundary router
 Redistributing External Routes from,
    eigrp 1, includes subnets in redistribution ←「show run」には「subnets」オプションが表示されないが、実際には「subnets」が有効になっている
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa
  Maximum path: 4
  Routing for Networks:
    172.16.1.0 0.0.0.255 area 0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: (default is 110)

参考になりましたら幸いです。

2023/08/11 返信
ファイアウォールが信頼境界として適切な場所ではないのはなぜですか?

「信頼境界」をどう捉えるかの問題ですね。
ネットワークセキュリティにおけるもう少し広い意味での信頼されるエリアと信頼されないエリアとの境界を指すのであればファイアウォールも正解といっても良さそうですが、この問題の場合は違いそうです。

解説に「信頼境界とは、QoS対象となるパケットがネットワークに入ってくるエッジ(端)のことをいいます。」と書いてあります。
なのでこの問題文で言っている「信頼境界」はパケットの分類とマーキングを行う点のことなので、アクセススイッチとIP Phoneが正解になっているのだと思います。

分類とマーキングもサポートしている一部の高度なファイアウォールもありますが、ファイアウォールがQoSの分類とマーキングをメインで行う機器ではないということからアクセススイッチやIP Phoneがより適した選択肢ということだと思います。

2023/08/03 返信
シミュレーション問題について

シミュレーションの問題には既に事前に設定が済んでいる部分と、受験者が設定をしなければならない部分がありますが、
受験者がどの部分を設定しないといけないのかが曖昧で分かりづらかったです。

シミュレーション問題では、show系コマンドを使って自分がどの設定を行わなければいけないのか見極めることも大切になると思います。
show系のコマンドを使いこなせるようになっておけば、事前に設定されている箇所や自分が設定すべき箇所もわかりますし、設定コマンドを実行した後に正しく設定できているか確認することもできます。

文章の形式も、○○の機器に△△の設定をして下さい。□□となるようにしてくだ。という形であれば何をすればいいかが分かりやすいのですが、
○○は△△です。という文章がざーっと並んでいるだけで読み終わった後に、で?と心の中で思ってしまいました。

「○○は△△です」という感じのものは、「○○が△△の状態で動作するように設定しなさい」という感じで捉えると良いと思います。
1つのタスクに1つの設定コマンドを入れればよいというものではない感じで、最終的にプロセスが正常に動作していたり、疎通がとれていたりという状態にもっていく必要があるんだと思います。

また、シミュレーション問題の中にBGPとVRFを使用した問題があったのですが、その問題が特に意味が分かりませんでした。
解説されているサイトや問題集をご存知であれば教えて頂きたいです。

他のサイトの情報はわからないのですが、Ping-tのコマ問で設定コマンドに関する問題もshow系コマンドも出題されていたので、役に立つのではないかと思います。

私のわかる範囲での回答ですが、お役に立てれば幸いです。

2023/07/31 返信
DMVPNのコマ問題について

「GigabitEthernet」と「0/2」の間にスペースがなくてもコマンドは通りますね。

Router(config)#int tunnel 0
Router(config-if)#ip address 192.168.123.3 255.255.255.0
Router(config-if)#tunnel source GigabitEthernet0/2
Router(config-if)#tunnel mode gre multipoint
Router(config-if)#tunnel key 1
Router(config-if)#end

スペースありでもコマンドは通ります。

Router#conf t
Router(config)#int tunnel 0
Router(config-if)#ip address 192.168.123.3 255.255.255.0
Router(config-if)#tunnel source GigabitEthernet 0/2
Router(config-if)#tunnel mode gre multipoint
Router(config-if)#tunnel key 1

ちなみにスペースありで設定しても、なしで設定してもどちらの場合も「show run」でトンネルインターフェースの設定を見るとスペースなしで表示されていました。

!
interface Tunnel0
 ip address 192.168.123.3 255.255.255.0
 no ip redirects
 tunnel source GigabitEthernet0/2
 tunnel mode gre multipoint
 tunnel key 1
!

実際にはスペースがあってもなくても設定はできますけど、問題文に【送信元インターフェース:GigabitEthernet0/2】と記載されているので、問題文通りスペースなしの「GigabitEthernet0/2」と入力するのが正解なんじゃないでしょうか。
なんなら「Router(config-if)#tunnel source gi 0/2」のように省略しても設定は可能ですが、コマ問で正解するにはフルでコマンドを入力し、指定するパラメータやオプションは問題文通りに入力しなければならないのだと思います。

2023/07/31 コメント
コマ問プレミアムCCNP ENARSI(300-410)
以前、IOSによる違いと回答してしまったのですが… VRFの定義の仕方によって「ip vrf forwarding」を使うか、「vrf forwarding」を使うかの違いがあるみたいです。 問題集の28998や29049で解説されていたのですが、マルチプロトコルVRFの設定では 「(config)#vrf definition」でVRFを定義して、 「(config-if)#vrf forwarding」でインターフェースに適用します。 一方、「(config)#ip vrf」でVRFを定義した場合は 「(config-if)#ip vrf forwarding」で適用します。 このコマ問の場合、「vrf definition VRF_RB」という設定からこれはマルチプロトコルVRFの設定であることを読み取って、「vrf forwarding VRF_RB」コマンドで設定する必要があるんだと思います。 恐らく、修正前はマルチプロトコルVRFか普通のVRFか見分けがつかなくてどっちも正解みたいな問題になっていたのかと思います。
戻る